Palo Alto Advanced Threat Prevention: — Anti-Spyware, Vulnerability Protection & Inline Cloud ML

① The two IPS profiles — Anti-Spyware vs Vulnerability Protection

Meet Sneha, an L2 engineer at Infosys. She's already built her zones, written a clean Security policy, and turned on Content-ID scanning. Then a pentest report lands: an internal box got popped through an unpatched web service, and a second machine was quietly beaconing to an attacker server for two weeks. "But I allowed the app and attached a WildFire profile," she says. That's exactly the trap. Threat Prevention — the firewall's IPS layer — is a different job from scanning files.

Threat Prevention is two security profiles, and the cleanest way to remember them is by what direction the badness flows. Anti-Spyware watches traffic going out — it blocks malware that's already inside from phoning home to its command-and-control (C2) server. Vulnerability Protection watches traffic coming in at your services — it matches exploit attempts against known software vulnerabilities (CVEs), client-side and server-side.

Both profiles run inside the same single-pass scan, so attaching them adds no extra latency hop — they read the same stream App-ID already identified. You attach them to an allow rule through a Security Profile Group. Critically, keep them distinct from their neighbours: files are Antivirus/WildFire's job, web categories are URL Filtering's, and malicious domains are DNS Security's — although, as you'll see, Anti-Spyware's DNS sinkhole is the hand-off point into DNS Security.

Four cards to lock the split in your head

Tap each — these are the exact distinctions an interviewer probes when they ask "what does Anti-Spyware actually do?"

② Severity, actions & packet capture — picking the right cut

Every signature ships with a severity — critical, high, medium, low or informational — and that's how you configure these profiles: per severity, not signature by signature. For each severity you choose an action, the firewall's response when a packet matches. Getting these actions right is the difference between cleanly blocking an attack and accidentally breaking a legitimate app.

Here's the full action menu, from gentlest to hardest. allow lets it pass with no log. alert logs the threat but lets traffic through — your tuning mode. drop silently discards the matching packet (but the TCP endpoints don't know, so they can hang and retransmit). reset-client / reset-server drop the packet and send a TCP RST to that one side. reset-both drops the packet and resets both ends — the cleanest cut. block-ip blocks the source (or the source-destination pair) for a number of seconds you set.

The subtle one is drop vs reset-both. A plain drop throws away the bad packet but says nothing to the client or server, so a TCP session can sit half-open, retransmitting, until it times out — sometimes looking to the user like a slow hang. reset-both drops the packet and fires a TCP RST at both endpoints, so the connection dies instantly and cleanly. For most exploit and C2 blocking, reset-both is the workhorse. (One quirk to expect: when reset-both fires right at session start, the Threat log can show reset-server — the client got a block page so only the server side needed resetting.)

You don't build these from scratch. Palo Alto ships two predefined profiles you clone and tune. The default profile applies each signature's shipped action to critical/high/medium and ignores low + informational. The strict profile is more aggressive: it forces reset-both on critical, high and medium severities, using the default action only for low + informational. A common production pattern is: start from strict for inbound server protection, start from a cloned default for general user traffic, then watch the Threat log and tune.

Two more knobs live on each rule. Packet capture can be set to single-packet (grab the one triggering packet) or extended-capture (1–50 packets, default 5) — invaluable when you need to prove a detection or argue a false positive with TAC. And the threat ID shown in every log line is the handle you'll use to tune and to look the threat up later.

admin@PA-VM> show threat id 86672

Result:
  threat id      : 86672
  threat name    : NewPOSThing Command and Control Traffic Detection
  category       : spyware
  severity       : high
  direction      : client2server
  default action : reset-both
  cve            : -

③ DNS sinkhole, signature exceptions & Threat Vault

Now the feature that makes Anti-Spyware so loved by incident responders: the DNS sinkhole. Here's the problem it solves. When malware on a laptop looks up its C2 domain, the request goes to your internal DNS resolver first, and the resolver asks the internet. If you simply block that lookup, your Threat log shows the DNS server's IP as the source — not the actual infected laptop. You've blocked the symptom but can't find the patient.

Sinkholing fixes that. Instead of blocking, the firewall forges the DNS answer to point at a controlled sinkhole IP. The infected laptop then tries to connect to the sinkhole address — and now the Traffic log shows 10.20.5.40 → sinkhole IP, naming the real infected host by its own IP. You configure it under the Anti-Spyware profile's DNS Policies tab by setting the DNS signature source action to sinkhole. The default sinkhole FQDN is sinkhole.paloaltonetworks.com.

The flip side of aggressive blocking is the false positive, and tuning it correctly is what separates an L2 from an L1. Say a new content update ships a signature that starts matching a legitimate internal app or a security scanner. The wrong move is to disable the whole category — that blinds you to real threats. The right move is a signature exception on that one threat ID.

The workflow: open Objects > Security Profiles > Anti-Spyware (or Vulnerability Protection) → the Exceptions tab → tick Show all signatures → search the threat ID you saw in the log → set its action to alert (or to allow if you're certain), or add the specific source/destination IPs to exempt — up to 100 IPs per signature. Before you do, confirm the threat in Threat Vault: search the threat ID, read what it actually detects, and check the CVE. If Threat Vault says it's a real exploit signature, the false positive is probably your app doing something odd — escalate, don't just allow.

④ Content updates, inline cloud ML, the CLI & the exam

Signatures don't appear by magic. New Anti-Spyware and Vulnerability Protection signatures ship inside the Applications and Threats content update — a dynamic update you schedule under Device > Dynamic Updates. You can run it as often as every 30 minutes, hourly, daily or weekly. Because the same package carries new App-IDs (which can change what an app is identified as) and new threat signatures, you set a threshold — a hold time (say 6–12 hours) before installing — so a brand-new signature can't break production the instant it's published.

This is where the real-world stakes show up. In February 2025, Palo Alto disclosed CVE-2025-0108, a management-interface auth-bypass that was being actively exploited. Alongside the patch, Palo Alto shipped Threat IDs 510000 and 510001 in the content update so that customers with a Threat Prevention subscription could block the exploit attempts while they scheduled patching. That's the whole value of this layer in one story: a fresh content update turned every Threat-Prevention-licensed firewall into a shield against an in-the-wild attack — before the box itself was even patched.

Signatures only catch known threats. The Advanced in Advanced Threat Prevention is inline cloud analysis — deep-learning models in Palo Alto's cloud that inspect suspicious traffic in real time to catch zero-day C2 channels and exploit attempts (including command-injection and SQL-injection) that no signature has been written for yet. You enable it per profile on the Inline Cloud Analysis tab and set an action per detection engine. It's what turns a classic signature IPS into something that can stop patient-zero attacks the rest of the world hasn't seen.

admin@PA-VM> show system info | match content-version
admin@PA-VM> request content upgrade check
admin@PA-VM> show counter global filter delta yes severity drop

content-version: 8901-9234

Version       Date              Available    Downloaded
8902-9240     2026/06/11 04:00  yes          no

global counters:
name                  value  rate severity  category    description
flow_policy_deny          7     0 drop      flow        session denied by threat profile (reset-both)
flow_ips_reset            3     0 drop      ips         packets reset by vulnerability signature

For the exam, this lesson sits in the heart of the PCNSE (and PCNSA) security-profiles domain. Expect questions on: which profile blocks C2 vs which blocks exploits; what reset-both does versus drop; how DNS sinkhole reveals the infected host; how to tune a false positive by threat ID exception (and why you never disable a category); and the role of inline cloud analysis for zero-days. If you can teach this section back, you've covered a big, reliable slice of the blueprint.