Back to Articles

Fingerprinting PAN-OS Versions Through HTTP Headers: A Clever Side-Channel Approach

[ View on GitHub ]

Fingerprinting PAN-OS Versions Through HTTP Headers: A Clever Side-Channel Approach

Hook

An eight-character hexadecimal timestamp buried in an HTTP ETag header can tell you whether a firewall is vulnerable to critical RCE exploits—no authentication required.

Context

Palo Alto Networks’ GlobalProtect portal has been a goldmine for security researchers, with multiple critical vulnerabilities enabling authorization bypass and unauthenticated remote code execution. The problem? From an external perspective, there’s no straightforward way to determine what version of PAN-OS a remote portal is running. Unlike many web applications that cheerfully advertise their version numbers in response headers or login pages, GlobalProtect stays silent. This creates a painful blindspot for both security teams trying to inventory their attack surface and administrators racing to patch newly-disclosed vulnerabilities.

Traditional vulnerability scanners struggle with this opacity. They can detect that a GlobalProtect portal exists, but confirming whether it’s running a vulnerable version typically requires authenticated API access or complex exploit-based detection that risks disrupting production systems. The noperator/panos-scanner tool, developed by Bishop Fox’s Cosmos team (formerly CAST), takes a different approach: it exploits a subtle implementation detail in how PAN-OS serves static web resources. By examining HTTP response headers for assets like favicon.ico and CSS files, the tool can fingerprint exact or approximate PAN-OS versions without ever attempting authentication or sending malicious payloads.

Technical Insight

GET /global-protect/*

ETag: 6e185d5daf9a

Extract hex: 5d5daf9a

Unix timestamp: 1566420890

Build date: Aug 21 2019

Date-to-version mappings

PAN-OS 8.1.10

Resources

favicon.ico

login.esp

CSS files

JS files

User Input: Target URL

PAN-OS Scanner

HTTP Request Handler

Target PAN-OS Device

ETag Parser

Hex to Timestamp Converter

version-table.txt

Date-Version Matcher

Version Output

System architecture — auto-generated

The core insight behind panos-scanner is elegantly simple: static web assets included in PAN-OS releases carry metadata that betrays their build time. When you request a resource like /global-protect/portal/images/favicon.ico, the server responds with standard HTTP caching headers including an ETag. Here’s what a typical response looks like:

$ curl -skI https://example.com/global-protect/login.esp
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
ETag: "6e185d5daf9a"

The magic happens in the ETag header. The last 8 characters (5d5daf9a) represent a hexadecimal-encoded Unix epoch timestamp. Converting this to decimal gives 1566420890, which translates to August 21, 2019 at 20:54:50 UTC. This timestamp corresponds to when the static asset was built during the PAN-OS release process.

The scanner maintains a version-table.txt file that maps build dates to specific PAN-OS releases. By cross-referencing the extracted timestamp, the tool can identify which version(s) were built on that date. For example:

$ awk '/Aug.*21.*2019/ {print $1}' version-table.txt
8.1.10

This reveals the target is running PAN-OS 8.1.10—a version vulnerable to CVE-2020-2034, a critical OS command injection flaw.

The tool queries multiple static resources including ESP pages, CSS files, SVG images, and JavaScript files. Here’s a typical invocation:

$ python3 panos-scanner.py -s -t https://example.com | jq '.match'
{
  "date": "2018-05-04",
  "versions": [
    "8.0.10"
  ],
  "precision": "exact",
  "resource": "global-protect/portal/images/favicon.ico"
}

The -s flag tells the scanner to stop after finding one exact match, saving time when you just need quick confirmation. The JSON output makes it trivial to integrate into automated security workflows or feed into vulnerability management platforms.

The precision field is crucial. When multiple PAN-OS versions were released on the same date, the tool returns all candidates as a comma-separated list and marks the precision as “approximate.” For instance, builds from August 15, 2019 could be 7.1.24-h1, 8.0.19-h1, or 8.1.9-h4. In these cases, you’ll need additional context—like knowing which major version family your organization uses—to narrow down the exact version.

What makes this approach particularly powerful is its passivity. The scanner makes only standard HTTP GET requests for legitimate static resources. It doesn’t exploit vulnerabilities, attempt authentication, or send any payloads. From a network defender’s perspective, this traffic appears similar to standard web browsing behavior.

Gotcha

The biggest limitation is version table coverage. The version-table.txt file requires updates as Palo Alto releases new PAN-OS versions. If you’re testing against a recently-released version that isn’t in the table, you’ll get no results. The repository has received updates from contributors like k4nfr3, but gaps in coverage for the latest releases may exist. You may need to monitor Palo Alto’s security advisories and update the version table yourself to ensure comprehensive coverage.

Ambiguous matches are common enough to be frustrating. When Palo Alto builds multiple versions on the same date—particularly during coordinated security updates across version families—the scanner returns multiple candidates. For example, a scan might return 8.1.12,9.1.0 with one marked as “exact” and another as “approximate.” If you’re managing a heterogeneous environment with multiple PAN-OS major versions, you’ll still need to manually verify which version you’re actually dealing with before making patching decisions. The tool relies on examining HTTP response headers for static resources, which means it depends on these implementation details remaining consistent across PAN-OS releases. Changes to how Palo Alto serves these resources could impact detection effectiveness.

Verdict

Use panos-scanner if you’re conducting authorized security assessments of PAN-OS installations, managing a large fleet of GlobalProtect portals that need rapid vulnerability triage, or if you lack direct administrative access to check versions through official channels. It’s particularly valuable during those stressful hours after a critical CVE drops when you need to quickly identify which external-facing portals are vulnerable. The passive nature makes it safe for production environments, and the JSON output integrates cleanly into automation workflows. Skip it if you need guaranteed accuracy for compliance reporting—the ambiguous matches make it unsuitable as a sole source of truth. Also skip it if you’re dealing with recently-released PAN-OS versions and don’t want to maintain the version table yourself, or if you have proper administrative access and can query versions through official API endpoints. This is a reconnaissance tool that trades perfect accuracy for speed and stealth—understand that tradeoff before depending on it for critical security decisions.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/developer-tools/noperator-panos-scanner.svg)](https://starlog.is/api/badge-click/developer-tools/noperator-panos-scanner)