Fingerprinting Palo Alto Firewalls Through ETag Timestamps

Hook

Every time a Palo Alto GlobalProtect portal serves a CSS file, it inadvertently broadcasts the exact date its software was compiled. This operational security oversight has become a reconnaissance goldmine.

Context

Palo Alto Networks firewalls running PAN-OS have been targeted by some of the most critical vulnerabilities in recent years—CVE-2024-3400 offered pre-authentication remote code execution, while CVE-2020-2021 allowed authentication bypass. When these zero-days drop, security teams face a brutal race: identify exposed instances, verify patch status, and remediate before exploitation. The problem? GlobalProtect portals and management interfaces don't advertise their version numbers. Unlike web servers that cheerfully announce "Apache/2.4.41" in response headers, PAN-OS keeps this information behind authentication walls. You can't simply scan your external attack surface and generate a list of unpatched firewalls.

This creates an asymmetry where attackers with stolen credentials can verify versions while defenders conducting legitimate security assessments cannot. Red teams performing external reconnaissance hit the same wall during penetration tests. The traditional approach involves authenticated API calls to the PAN-OS XML API, but that assumes you already have credentials—precisely what you're trying to protect. Bishop Fox's panos-scanner flips this equation by exploiting an unintended side channel: static resources served by the web interface contain ETags with hexadecimal-encoded build timestamps that directly correlate to specific PAN-OS releases.

Technical Insight

The scanner's elegance lies in its simplicity. When PAN-OS serves static resources like CSS or JavaScript files, it generates ETags using a format that includes the file's last modification time. These aren't random cache-busting strings—they're predictable, structured values that leak build metadata. The tool makes unauthenticated HTTP requests to known static resource paths and extracts timing information from response headers.

Here's a typical workflow using the scanner:

# Basic usage against a GlobalProtect portal
python3 panos-scanner.py -t vpn.example.com

# The tool requests static resources like:
# https://vpn.example.com/global-protect/portal/css/login.css
# https://vpn.example.com/js/Pan.js

# Response headers contain:
# ETag: "5d41c7f-5a3b"
# Last-Modified: Wed, 31 Jul 2019 18:22:07 GMT

# The tool converts the hex timestamp and cross-references
# against version-table.txt to output:
# [+] PAN-OS version: 8.1.9

The magic happens in the correlation logic. The version table maps build dates to releases because Palo Alto's build process is deterministic—each official release compiles at a specific timestamp. When static files from that build are deployed, they carry forward those original modification times. The scanner doesn't rely on banner grabbing or service enumeration that might trigger intrusion detection systems. It's passive reconnaissance that looks identical to a user loading the login page.

The architecture is deliberately minimal—a single Python script with no exotic dependencies. The core logic extracts timestamps from multiple header formats (ETags can be weak or strong validators, Last-Modified headers use HTTP date formats) and handles the edge cases where different PAN-OS versions might share build infrastructure:

# Pseudocode of the matching algorithm
def identify_version(etag, last_modified, version_table):
    # Extract hex timestamp from ETag (format: "<hex>-<size>")
    timestamp = int(etag.split('-')[0], 16)
    build_date = datetime.fromtimestamp(timestamp)
    
    # Check version table for matching build dates
    matches = []
    for version, date in version_table.items():
        if date == build_date:
            matches.append(version)
    
    # Return all matches (some builds serve multiple versions)
    return ','.join(matches) if matches else 'Unknown'

This approach yields multiple benefits for security practitioners. First, it's stealthy—the HTTP requests are indistinguishable from legitimate traffic, leaving minimal forensic footprint. Second, it scales: you can scan thousands of GlobalProtect portals without worrying about account lockouts or authentication rate limits. Third, it works against the most common deployment pattern where GlobalProtect portals face the internet for remote access.

The tool also demonstrates an important security principle: metadata is data. Developers often focus on protecting primary information channels (authentication, authorization, data encryption) while overlooking side channels like cache headers, timing information, or error messages. PAN-OS likely uses standard web server practices for ETag generation without considering the reconnaissance implications. This isn't a vulnerability in the traditional sense—no memory is corrupted, no authentication is bypassed—but it's an operational security gap that enables reconnaissance at scale.

For security teams, this tool fits into the reconnaissance phase of both offensive and defensive operations. Red teams use it to build target profiles before launching sophisticated attacks. Blue teams use it to inventory external assets and verify patch compliance without needing to authenticate to every device. SOC analysts can integrate it into continuous monitoring workflows to detect when new, potentially vulnerable PAN-OS instances appear on the network perimeter.

Gotcha

The scanner's Achilles heel is the version table maintenance burden. That text file mapping build dates to versions becomes stale the moment Palo Alto releases a new PAN-OS version or hotfix. Unlike tools that fingerprint based on behavior or protocol analysis, this approach requires someone to manually update the correlation database. If you're scanning against a recently released version that's not in your table, you'll get "Unknown" results even though the fingerprinting technique still works perfectly. The repository doesn't include automated update mechanisms, so practitioners need to establish their own process for tracking PAN-OS releases and updating the table.

Ambiguity represents another practical limitation. When multiple versions return from a single scan (like "7.1.24-h1,8.0.19-h1,8.1.9-h4"), you're left with uncertainty. These collisions occur when Palo Alto's build infrastructure compiles different branches at the same timestamp, or when hotfixes don't rebuild all static resources. For vulnerability assessment, this ambiguity matters—if you're checking for a specific CVE that affects 8.0.x but not 8.1.x, a result spanning both branches doesn't give you a clear answer. You'll need secondary verification through authenticated checks or behavioral fingerprinting.

The tool also assumes default configurations and accessible endpoints. Organizations that customize their GlobalProtect portal paths, place web application firewalls in front of management interfaces, or deploy PAN-OS in environments without external GlobalProtect access won't benefit from this approach. Internal-only deployments or situations where static resources are served through CDNs (breaking the direct timestamp correlation) fall outside the scanner's scope. It's a specialized tool for a specific deployment pattern, not a universal PAN-OS version detection solution.

Verdict

Use if: You're conducting security assessments against internet-facing Palo Alto infrastructure, need to inventory GlobalProtect portals across large networks without authentication, or operate a red team that requires stealthy reconnaissance capabilities. This tool excels in external penetration tests, vulnerability management programs tracking patch compliance, and continuous monitoring scenarios where you want to detect newly exposed PAN-OS instances. It's particularly valuable when critical CVEs drop and you need rapid identification of potentially affected systems. Skip if: You already have authenticated access to target systems (just use the XML API directly), need to assess PAN-OS deployments without standard GlobalProtect configurations, or can't commit to maintaining the version table as new releases appear. Also skip if you require definitive version identification without ambiguity—the multi-match results won't satisfy compliance requirements that demand certainty.