How attackers used a company's own firewall to reach inside its network without a password

The Context

Palo Alto Networks is the largest dedicated cybersecurity company in the world by revenue. Its PAN-OS operating system runs on PA-Series hardware firewalls and VM-Series virtual firewalls deployed by more than 70,000 customers globally, including 90% of Fortune 10 companies. These devices sit at the perimeter of corporate networks, inspecting traffic, enforcing access policies, and in many cases acting as the primary boundary between the public internet and internal systems including operational technology networks in energy, manufacturing, and critical infrastructure.

PAN-OS includes a feature called the User-ID Authentication Portal, also known as the Captive Portal. Its job is to identify users whose identities cannot be automatically mapped by the firewall, typically by presenting them with a login page before granting network access. Because it handles traffic from users who have not yet been identified, it is reachable by design from untrusted or internet-facing zones when enabled.

The Attack, Phase by Phase

Phase 1: Reconnaissance and Initial Exploitation

Beginning April 9, 2026, the attacker group tracked by Palo Alto Networks' Unit 42 as CL-STA-1132 began probing a PAN-OS device whose User-ID Authentication Portal was exposed to the internet. Around April 16, the attackers succeeded.

The exploit worked by sending specially crafted packets to the portal service on ports 6081 or 6082, supplying more data than the service's internal buffer could hold. This out-of-bounds write corrupted adjacent memory and allowed the attackers to redirect the firewall's execution flow to their own shellcode, injected directly into an nginx worker process already running on the device. The result was arbitrary code execution at root level, with no credentials required and no user interaction needed.

Phase 2: Anti-Forensic Log Destruction

The attackers' first action after gaining root access was to erase the evidence of how they got in. Within hours of the initial compromise, they cleared crash kernel messages, deleted nginx crash log entries, and removed core dump files that would have recorded the buffer overflow. Days later, they returned to delete ptrace injection evidence from the audit log and remove the binary used for privilege escalation.

This was a systematic, sequenced operation designed to prevent incident responders from reconstructing the attack chain. By the time anyone examined the device, the forensic record of the exploit had been destroyed.

Phase 3: Tunneling, Credential Abuse, and Active Directory Enumeration

Four days after the initial compromise, the attackers deployed two open-source tunneling tools: EarthWorm and ReverseSocks5. EarthWorm is a cross-platform proxy utility previously linked to Volt Typhoon and APT41. ReverseSocks5 establishes outbound connections from the compromised device to attacker-controlled servers, making traffic appear to originate from the firewall itself and bypassing inbound blocking rules.

With these tunnels in place, the attackers used the firewall's own service account credentials to query the organization's Active Directory environment, targeting domain root and DomainDnsZones. The firewall held those credentials legitimately—User-ID requires them to map usernames to IP addresses. Those same credentials became the pivot point into internal identity infrastructure.

Phase 4: HA Failover Abuse and Second Device Compromise

On April 29, the attackers executed a SAML flood against the originally compromised device. SAML (Security Assertion Markup Language) is the protocol many organizations use for single sign-on. Flooding the device with SAML requests overwhelmed it, triggering the high-availability failover mechanism. The standby device automatically became active and inherited the same internet-facing traffic, including exposure of the same vulnerable portal.

The attackers then exploited CVE-2026-0300 against this second device. This demonstrated that the attackers understood PAN-OS HA mechanics well enough to use them as an amplification technique, doubling their foothold with a single deliberate action.

What Made This Possible

1. The portal was reachable from the internet. The User-ID Authentication Portal is not enabled by default, but when enabled without IP restrictions it is reachable by anyone. The vulnerability exists in the code path that runs before authentication, so any device with the portal internet-exposed was fully vulnerable with no prerequisites.

2. The firewall had no meaningful telemetry on itself. Firewalls generate logs about other devices' traffic, but the operating system layer of the firewall itself is rarely subjected to behavioral monitoring or file integrity checks. The attackers exploited this blind spot for weeks, operating through intermittent sessions timed to stay below automated alerting thresholds.

3. The firewall held credentials that unlocked the internal network. User-ID requires the firewall to authenticate against Active Directory to map usernames to IP addresses. Those credentials are legitimate, trusted, and rarely monitored for abuse. Once the attackers had root on the firewall, they had those credentials too.

The perimeter device was simultaneously the least monitored and the most trusted asset in the environment.

What Should Have Stopped This

Every defense that would have reduced the blast radius here shares one trait: it does not depend on the firewall's own integrity to function.

• Restrict the portal to trusted IP ranges. The User-ID Authentication Portal should never be reachable from the public internet. Restricting it to known internal IP ranges eliminates the attack surface entirely for external attackers. Palo Alto Networks and CISA both recommended this as the primary workaround before patches were available.
• Apply the Threat Prevention signature. Palo Alto Networks released Threat ID 510019 on May 5, 2026, for PAN-OS 11.1 and above. Organizations with Threat Prevention enabled could block exploitation attempts before patches arrived.
• Monitor the firewall OS layer independently. File integrity monitoring and log forwarding to an external, write-protected log store would have detected the log deletion campaign. If the firewall's own logs can be erased by an attacker who controls the device, those logs cannot be the sole forensic record.
• Audit service account usage. The firewall's Active Directory service account should have been scoped to minimum permissions and monitored for queries outside its normal pattern. Domain root enumeration from a firewall service account is not normal behavior.

The Takeaway

This attack follows the same class of failure as the Stryker Intune wipe: a trusted infrastructure tool weaponized against the organization it was built to protect. The meta-pattern is consistent—systems fail when the attacker controls the boundary the organization trusts most.

What makes this case distinct is the telemetry dimension. The attackers exploited the fact that the firewall is treated as a monitoring device, not a monitored one. The log destruction campaign worked because there was no independent record of what the firewall OS was doing. The intermittent session cadence worked because no behavioral baseline existed for the firewall's own process activity. The credential abuse worked because service account queries from a firewall are not typically reviewed.

The attacker cluster operated for nearly four weeks before public disclosure, and the forensic evidence of how they entered was gone within hours of their arrival.

Pattern to remember: Any internet-facing service that processes unauthenticated input before identity is verified is a high-value attack surface, regardless of what device it runs on.

What changed: Perimeter security devices can no longer be treated as the observers of network behavior. They are themselves targets that require independent observation.

The Technical Mechanism

CVE-2026-0300 is a CWE-787 (Out-of-Bounds Write) vulnerability in the User-ID Authentication Portal service of PAN-OS, also referred to as the Captive Portal. The portal listens on TCP ports 6081 and 6082 and is responsible for mapping IP addresses to usernames for user-based policy enforcement. Because the portal must handle traffic from unauthenticated users by design, the vulnerable code path is reached before any authentication check is performed.

The vulnerability is triggered by sending a specially crafted network packet to the portal service that supplies more data than the service's internal buffer can accommodate. The excess data writes beyond the allocated buffer boundary into adjacent memory regions (CWE-787). By controlling the content and placement of this overflow, an attacker can corrupt memory structures used to manage execution flow, ultimately redirecting execution to attacker-controlled shellcode.

Unit 42 observed that successful exploitation resulted in shellcode injection directly into an nginx worker process running on the firewall, achieving arbitrary code execution at root privilege level. The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N confirms the attack is fully network-reachable, requires no authentication, no user interaction, and no special preconditions beyond the portal being reachable. Palo Alto Networks confirmed the vulnerability is automatable, making it viable for mass-exploitation campaigns.

Post-exploitation tradecraft observed by Unit 42 included:

• Shellcode injection into a running nginx worker process via ptrace
• Systematic deletion of crash kernel messages, nginx crash logs, and core dump files
• Removal of ptrace injection evidence from the audit log
• Deletion of a SetUserID (SUID) binary used for privilege escalation
• Deployment of EarthWorm (cross-platform SOCKS5 proxy, previously linked to Volt Typhoon and APT41) and ReverseSocks5 (outbound SOCKS5 tunnel to attacker-controlled infrastructure)
• Active Directory enumeration using the firewall's service account credentials, targeting domain root and DomainDnsZones
• SAML flood to trigger HA failover, followed by exploitation of the newly active peer device

The reliance on open-source tooling rather than proprietary malware was deliberate: it minimizes signature-based detection and reduces the forensic footprint. Intermittent interactive sessions over a multi-week period were timed to remain below behavioral alerting thresholds.

CVE and Advisories

• CVE-2026-0300: CWE-787 Out-of-Bounds Write in PAN-OS User-ID Authentication Portal. CVSS 4.0 score 9.3 (Critical) when internet-exposed; 8.7 (High) when restricted to trusted internal IPs.
• PAN-SA-2026-0028: Palo Alto Networks PSIRT advisory confirming limited in-the-wild exploitation, affected versions, workarounds, and patch schedule.
• Threat Prevention signature Threat ID 510019 released May 5, 2026, for PAN-OS 11.1 and above as an interim blocking control.
• First patch wave: PAN-OS 10.2.18-h6, 11.1.x, 11.2.x, 12.1.x hotfix branches, May 13, 2026.
• Second patch wave: remaining affected branches, May 28, 2026.
• Prisma Access, Cloud NGFW, and Panorama management appliances are not affected.

MITRE ATT&CK Mapping

Indicators of Compromise

Detection is complicated by the attackers' systematic log destruction campaign. The following indicators were identified by Unit 42 and represent post-exploitation artifacts rather than exploitation-phase indicators:

• Presence of EarthWorm (ew) or ReverseSocks5 (rs5) binaries in non-standard filesystem locations on PAN-OS devices
• Unexpected outbound SOCKS5 connections from firewall management or data-plane interfaces to external IP addresses
• Active Directory queries from the firewall's service account targeting domain root or DomainDnsZones outside normal User-ID polling patterns
• Gaps or deletions in PAN-OS system logs, particularly in crash log directories and kernel message buffers
• Unexpected SUID binaries created and subsequently deleted on the PAN-OS filesystem
• Anomalous HA failover events not correlated with hardware or network failures, particularly if preceded by elevated SAML authentication traffic

Palo Alto Networks' Threat Prevention signature Threat ID 510019 provides network-layer detection and blocking for exploitation attempts against PAN-OS 11.1 and above. Organizations should forward PAN-OS system logs to an external, write-protected SIEM to preserve forensic integrity independent of the device's own log store.

Attribution

Unit 42 tracks the observed exploitation activity as CL-STA-1132, assessed as a likely state-sponsored threat cluster. No specific nation-state sponsor has been publicly named. Palo Alto Networks stated on May 7, 2026, that it believes the attacks are likely the work of state-sponsored threat actors.

Contextual indicators supporting a nation-state assessment include:

• Use of EarthWorm, an open-source tunneling tool previously linked to Volt Typhoon and APT41
• Disciplined operational cadence: intermittent interactive sessions over a multi-week period, timed to remain below behavioral alerting thresholds
• Prioritization of identity trust abuse (Active Directory enumeration via service account) over traditional network-layer pivoting
• Targeting pattern consistent with cyber-espionage objectives: concentrations in Asia and North America, focus on internal identity infrastructure
• No ransomware or financially motivated activity observed

The vulnerability was discovered internally by Palo Alto Networks' Deep Product Security Research Team, with threat research and intelligence support from Unit 42 and the Xpanse Internet Listening Initiative (Xpanse ILI).

Primary Sources