Threat & Content Services

Why

How

Base Threat Prevention is really four different questions asked at once, each targeting a different stage of an attack:

• Antivirus — "is this file itself known malware?" Signature matching against files in the stream.
• Anti-spyware — "is an already-compromised host talking to its controller?" This is aimed downstream of initial infection: even if malware got in some other way, anti-spyware watches for the traffic pattern of a host phoning home to a command-and-control server.
• Vulnerability protection (IPS) — "is this traffic trying to exploit a known bug?" Pattern-matches exploit attempts against known vulnerabilities, catching the actual attack attempt rather than a malicious file.
• Built-in external dynamic lists + DNS-query analysis — ready-made, continuously updated lists of known-bad hosts/domains, so you get baseline coverage against known-malicious infrastructure without building your own blocklist.

What Advanced Threat Prevention adds, and why it needs a different technique entirely. All four base capabilities above ultimately rely on known patterns — a signature, a listed bad domain. That's a structural blind spot against C2 traffic that's deliberately novel or evasive enough to have no matching signature yet. Advanced Threat Prevention closes that gap with an inline, cloud-based deep-learning engine trained on Palo Alto's threat intelligence — instead of matching a known pattern, it's inferring "does this traffic behave like C2" from characteristics of the traffic itself, in real time, which is what lets it catch genuinely unknown C2 rather than just previously catalogued C2.

How severity actually turns into an action — the part that trips people up. Every vulnerability/spyware signature is tagged with a severity (critical, high, medium, low, informational) — but severity alone doesn't decide what happens to the traffic. The security profile's rule maps each severity to an action (alert, allow, reset, block, drop), and different predefined profiles (e.g. "strict" vs. "default") make different choices for the same severity. This means "Threat Prevention is enabled" tells you nothing about whether a given signature actually blocks anything — you have to check what action that profile maps the relevant severity to, and a custom profile inherits none of a predefined profile's choices until you explicitly set them.

Why

How

The core idea — why "detonate it and watch" beats "compare it to a known-bad list." A signature can only ever catch malware someone has already seen and catalogued. WildFire sidesteps that limit entirely: an unknown file crossing the firewall gets forwarded to the WildFire cloud (or an on-prem WF-500 appliance for organizations that can't send files off-site), actually detonated — run for real — inside multiple OS/application environments, and observed through both static analysis (examining the file's structure without running it) and dynamic analysis (watching what it actually does once executed: what it writes to disk, what it connects to, what it modifies). This is what lets WildFire flag malware on its very first appearance anywhere, rather than only after someone has manually reverse-engineered a signature for it.

A subscription is what turns "detonate occasionally" into a genuinely fast pipeline: it unlocks faster signature turnaround (so a verdict from one detonation becomes a protective signature for everyone else sooner), coverage of more file types (APK, PDF, Office documents, Java — the formats attackers actually favor for delivery), and API-based uploads for integrating WildFire into other tooling.

Advanced WildFire — closing the gap malware itself tries to exploit. Sophisticated malware doesn't just try to look benign — some samples actively detect that they're running inside a sandbox (checking for virtualization artifacts, unusual timing, absence of real user activity) and simply behave innocently while watched, only doing anything malicious once they believe they're on a real machine. Standard detonation-based analysis can be fooled by this. Intelligent Run-time Memory Analysis is built specifically to counter it: a cloud engine that inspects in-memory behavior during execution rather than relying purely on observed file-system/network actions, catching malware that's actively trying to hide from the sandbox it's running in.

Why

How

The base layer: category-based control. A URL Filtering security profile doesn't work site-by-site — it enforces an action against each PAN-DB category (e.g. "malware," "gambling," "social-media"), which is what makes policy scale: you write one rule per category instead of maintaining a list of millions of individual domains yourself. Beyond simple allow/block, the profile also detects corporate credential submissions (feeding into the Credential Phishing Prevention mechanism covered on the Identity page) and restricts which categories are allowed to receive them, and can log HTTP headers or enforce SafeSearch so users can't quietly turn off content filtering on search engines.

Why a crawled database alone structurally can't keep up. PAN-DB is built by crawling and categorizing the web ahead of time — which means there's an inherent lag between a domain being newly registered for a phishing campaign and PAN-DB having crawled and categorized it. A single-use phishing page might exist for hours before anyone crawls it.

Advanced URL Filtering — inspecting the page itself, not a pre-built record about the page. Instead of only checking which category a URL was assigned in the past, Advanced URL Filtering layers in a cloud-based ML engine that inspects the actual page content and behavior in real time, at the moment of the request — which is what lets it flag a phishing or exploit page that's brand new and has no crawl history at all.

When PAN-DB gets a category wrong. Misclassification happens — a legitimate business site landing in "malware," say. There's a two-track fix: submit a category-change request to Palo Alto for permanent review, and in the meantime, apply a custom URL category locally to override the classification immediately, without waiting on that review to complete.

Why

How

Why DNS specifically is worth its own dedicated inspection layer. Almost every piece of malware needs to resolve a domain name at some point — to reach its C2 server, to exfiltrate data, or as part of fast-flux/DGA (domain-generation-algorithm) evasion techniques that cycle through many auto-generated domains to dodge static blocklists. That makes DNS a genuine choke point: it's small, cheap to inspect compared to full payload analysis, and hard for malware to route around entirely since it still needs names resolved to actually connect anywhere.

Sinkholing, mechanically — and why it does double duty as detection. When a lookup for a known-malicious domain is detected, the firewall doesn't just drop the query — it returns a firewall-controlled IP address instead of the real (malicious) answer. The infected host, none the wiser, then tries to actually connect to that fake IP — and because that connection attempt lands in ordinary traffic logs, it instantly tells you exactly which internal host queried the bad domain. This is often faster and more certain than waiting for Threat Prevention to separately notice that host's C2 traffic pattern — sinkholing catches the DNS lookup itself, the very first step of the attack chain.

Where the verdicts actually come from. The DNS Security cloud service isn't working off a static list someone manually curates — it continuously analyzes passive DNS telemetry (query patterns, how recently a domain was registered, whether its name structure looks algorithmically generated rather than human-chosen) aggregated across Palo Alto's entire global customer base, which is what lets it flag freshly-weaponized infrastructure quickly rather than only after it's been manually catalogued.

Advanced DNS Security — catching hijacking, not just known-bad domains. Sinkholing a known-bad domain doesn't help against domain hijacking — a legitimate, previously-trusted domain whose DNS records get silently altered to point somewhere malicious. The Advanced tier adds cloud-based engines that inspect DNS responses themselves in real time, watching for exactly that kind of unexpected change happening to a domain's records, rather than only checking the domain's name against a reputation list.