How Palo Alto Firewalls Match Signatures for Threat Detection

Palo Alto Networks’ Next-Generation Firewalls (NGFWs) use signature-based detection as a core component of their Threat Prevention suite to identify and block threats like viruses, spyware, and exploits. These signatures are not just simple binary patterns (e.g., 01010101010) but complex rules that combine pattern matching, contextual analysis, and sometimes behavioral thresholds. Below, we dive into specific examples for antivirus, anti-spyware, and vulnerability protection signatures, explaining what they look like, how they match payloads, and how they identify malformed or malicious packets. Since SSL/TLS decryption is often required to inspect encrypted traffic, we’ll touch on its role where relevant.

1. Antivirus Signature Example: Detecting a Malware Download

Scenario

Imagine a user downloading a malicious executable (e.g., a trojan disguised as a legitimate file) over HTTP. The antivirus profile in Palo Alto’s Threat Prevention is designed to catch this.

What the Signature Looks Like

An antivirus signature targets specific patterns in file content or structure. For example, a signature for a trojan like “Emotet” might look like this (simplified for clarity):

Signature ID: 123456
Name: Emotet Trojan Variant
Type: Antivirus
Pattern: hex:4D5A9000.*E8.*\x00\x00\x00\xFF
Protocols: HTTP, HTTP2
File Types: PE (Portable Executable)
Action: Block
Severity: Critical

• Explanation:
  • 4D5A9000: This hexadecimal pattern represents the MZ header, common in Windows PE files, ensuring the signature targets executables.
  • .*E8.*\x00\x00\x00\xFF: A sequence of bytes unique to the Emotet trojan’s code, identified through Palo Alto’s threat research or WildFire sandbox analysis.
  • Context: The signature applies to HTTP/HTTP2 traffic and PE files, ensuring it only triggers for relevant downloads.
  • Action: If matched, the firewall blocks the download and logs the event.

How It Matches the Payload

1. Traffic Inspection: The firewall uses App-ID to identify the traffic as HTTP and confirms it’s a file download. If encrypted (HTTPS), SSL/TLS decryption is applied to access the payload.
2. Stream-Based Scanning: The antivirus engine scans the data stream in real-time without buffering the entire file. It looks for the MZ header (4D5A9000) to confirm it’s a PE file, then searches for the specific byte sequence (E8.*\x00\x00\x00\xFF) within the file’s code section.
3. Pattern Matching: The engine uses regex-like matching to compare the payload against the signature. If the byte sequence appears in the correct context (e.g., within a PE file over HTTP), it flags the file as malicious.
4. Identifying Malformed Packets: The signature may also check for structural anomalies, like an invalid PE header or unexpected padding, which could indicate a malformed or obfuscated file designed to evade detection.

False Positives and Mitigation

• Risk: A legitimate PE file might coincidentally contain a similar byte sequence, triggering a false positive. For example, a benign application with a similar code structure could be flagged.
• Mitigation:
  • Contextual Checks: The signature includes protocol (HTTP) and file-type (PE) filters to reduce false positives.
  • Exceptions: Admins can create an exception for the signature ID (123456) in the antivirus profile, setting it to “alert” instead of “block” for specific IPs or applications. This is done via Objects > Security Profiles > Anti-Virus > Exceptions.
  • Tuning: Monitor threat logs (Monitor > Logs > Threat) to identify false positives and report them to Palo Alto for signature refinement.
  • WildFire Integration: If the signature match is uncertain, the file is sent to WildFire for sandbox analysis to confirm maliciousness.

Decryption Note: For HTTPS downloads, decryption is critical to inspect the file content. Without it, the firewall can’t access the payload, limiting detection to metadata like URLs.

2. Anti-Spyware Signature Example: Detecting Command-and-Control (C2) Traffic

Scenario

A compromised device is communicating with a botnet’s C2 server over DNS, sending encoded data in DNS queries (DNS tunneling).

What the Signature Looks Like

An anti-spyware signature for DNS-based C2 might look like this (simplified):

Signature ID: 789012
Name: DNS Tunneling C2
Type: Anti-Spyware
Pattern: regex:[a-f0-9]{32}\.maliciousdomain\.com
Protocols: DNS
Threshold: 10 queries in 60 seconds
Action: Reset-Both
Severity: High

• Explanation:
  • [a-f0-9]{32}\.maliciousdomain\.com: A regex pattern matching a 32-character hexadecimal string (common in encoded C2 data) in DNS queries to a known malicious domain.
  • Threshold: Triggers only if 10 such queries occur within 60 seconds, indicating tunneling behavior.
  • Action: Resets the connection for both client and server to disrupt communication.

How It Matches the Payload

1. Traffic Inspection: App-ID identifies DNS traffic. If encrypted (e.g., DNS over HTTPS), decryption is needed to inspect query contents.
2. Pattern Matching: The firewall examines DNS query names in the packet payload, looking for the regex pattern [a-f0-9]{32}\.maliciousdomain\.com. For example, a query like a1b2c3d4e5f6…32chars.maliciousdomain.com would match.
3. Behavioral Threshold: The firewall counts matching queries over 60 seconds. If the threshold (10 queries) is met, it flags the traffic as C2 communication.
4. Identifying Malformed Packets: The signature may detect malformed DNS packets, such as oversized query names or unusual query types (e.g., TXT records), which are common in tunneling.

False Positives and Mitigation

• Risk: Legitimate DNS queries to a similar domain (e.g., a CDN using long subdomains) could trigger the signature.
• Mitigation:
  • Thresholds: The 10-query threshold reduces false positives by requiring sustained suspicious activity.
  • Exceptions: Admins can exclude specific domains or IPs in the Anti-Spyware profile (Objects > Security Profiles > Anti-Spyware > Exceptions).
  • Dynamic Updates: Palo Alto’s threat intelligence refines signatures to exclude benign patterns, based on customer feedback.
  • Monitoring: Use threat logs to review matches and adjust policies.

Decryption Note: For DNS over HTTPS, decryption is required to inspect query contents. Standard DNS is unencrypted, so no decryption is needed.

3. Vulnerability Signature Example: Detecting a SQL Injection Exploit

Scenario

An attacker sends a malicious HTTP request to exploit a SQL injection vulnerability in a web application.

What the Signature Looks Like

A vulnerability signature for SQL injection might look like this (simplified):

Signature ID: 345678
Name: SQL Injection Attempt
Type: Vulnerability
Pattern: regex:(\%27|\')(\s)*(OR|AND)(\s)*(\%27|\')|\bSELECT\b.*\bFROM\b
Protocols: HTTP, HTTP2
Context: URI, POST parameters
Action: Block
Severity: Critical

• Explanation:
  • (\%27|\’)(\s)*(OR|AND)(\s)*(\%27|\’): Matches SQL injection patterns like ‘ OR ‘1’=’1′ (URL-encoded or plain) in HTTP URIs or POST data.
  • \bSELECT\b.*\bFROM\b: Catches attempts to inject SQL commands like SELECT * FROM users.
  • Context: Applies only to HTTP URI or POST parameters, ensuring relevance.
  • Action: Blocks the request to protect the web server.

How It Matches the Payload

1. Traffic Inspection: App-ID identifies HTTP traffic, and the firewall inspects the URI and POST data. If encrypted (HTTPS), decryption is applied.
2. Pattern Matching: The firewall scans the HTTP payload (e.g., /login?user=’ OR ‘1’=’1′) for the regex pattern. It checks both URL-encoded (%27) and plain (‘) forms to catch variations.
3. Contextual Analysis: The signature only triggers if the pattern appears in specific fields (URI or POST), reducing irrelevant matches.
4. Identifying Malformed Packets: SQL injection attempts often involve malformed HTTP requests (e.g., oversized URIs or invalid characters). The signature may include checks for such anomalies, like unexpected control characters or excessive query length.

False Positives and Mitigation

• Risk: Legitimate web inputs containing SQL-like terms (e.g., a blog post about SQL with “SELECT FROM” in the text) could trigger the signature.
• Mitigation:
  • Contextual Filters: Limiting the signature to URI/POST fields avoids matching benign content in HTTP bodies.
  • Exceptions: Create an exception for the signature ID (345678) in the Vulnerability Protection profile, specifying trusted IPs or applications.
  • Tuning: Set to “alert” initially to monitor for false positives, then switch to “block” after validation.
  • Feedback: Report persistent false positives to Palo Alto for signature updates.

Decryption Note: HTTPS traffic requires decryption to inspect URIs and POST data. Without it, the firewall can’t analyze the payload for SQL injection patterns.

Why Decryption Matters

All three examples—antivirus, anti-spyware, and vulnerability protection—rely on inspecting packet payloads. For encrypted traffic (HTTPS, DNS over HTTPS), SSL/TLS decryption is essential to access the content. Configure decryption policies (Policies > Decryption) to decrypt relevant traffic while exempting sensitive categories (e.g., banking) for privacy. Be mindful of performance impacts and use hardware appropriately sized for decryption loads.

Key Takeaways

• Signatures Are Complex: They go beyond simple binary matches (e.g., 01010101010), using regex, contextual rules, and behavioral thresholds to identify threats.
• Matching Process: The firewall decodes protocols, scans payloads, and applies signatures in context, catching malformed or malicious packets.
• False Positives: Mitigated through contextual filters, thresholds, exceptions, and monitoring threat logs.
• Decryption: Critical for inspecting encrypted traffic, enabled via policy-based decryption rules.

For network admins, start with Palo Alto’s best practices: enable decryption selectively, monitor threat logs, and tune signatures to balance security and performance. Check Palo Alto’s documentation for detailed setup guides. Got questions or tips? Share them in the comments!