PAN-OS PHP2Shell Exploit: From Firewall to AD
A chained PAN-OS exploit rooted 25 servers and reached Active Directory. Learn how the attack worked, what remains uncertain, and what defenders should do.
How a PAN-OS Exploit Chain Reached Active Directory
A firewall is supposed to control the boundary between an organization and the internet. In this case, an exposed PAN-OS management interface turned that boundary into a doorway - and, eventually, into a path to Active Directory. Dream researchers described a custom exploit chain that combined remote code execution with a Linux kernel privilege escalation, rooting 25 servers across several countries, including systems in a US government-affiliated environment.
The point isn't just that the vulnerabilities existed. The attackers used the access to set up persistence, reach an internal firewall management server, pull service credentials, and enumerate the organization's directory. Some follow-on actions are confirmed; others aren't clear from the recovered evidence. That uncertainty matters - because "contained" should be a conclusion, not an assumption.
This article summarizes the reported exploit chain, how the campaign shifted from scanning to an internal pivot, what the recovered artifacts show (and what they can't), and what defenders should prioritize during response. It also separates what the report supports from attribution and AI-use claims, which are easy to oversell in a fast-moving incident.
What happened in the PAN-OS campaign
Dream researchers said they found artifacts from an operation that exploited internet-facing Palo Alto Networks PAN-OS systems. The chain reportedly started with PHP2Shell (listed in the report as CVE-2026-109618 and CVE-2026-109619), followed by a kernel privilege-escalation vulnerability called Fragnesia (CVE-2026-46300). Together, the exploits reportedly let an unauthenticated attacker move from the management web server to root privileges.
The exposed target was the PAN-OS management web server, which also fronts the GlobalProtect portal. That detail matters: management services carry administrative access and configuration data, so exposing them isn't the same as publishing a typical customer-facing website. A compromise can reveal network structure and credentials that help an attacker move beyond the firewall itself.
The researchers recovered target lists, exploitation logs, version profiles, and about 40 custom post-exploitation scripts. They described a narrowing funnel: the attacker identified roughly 19,000 internet-facing firewalls, found about 5,000 that responded with version information, reduced the list to 240 targets based on geography and software version, and then rooted 24 firewalls. After pivoting through a government-affiliated environment, they say an additional internal firewall management server was compromised, bringing the total to 25 servers.
Not every rooted system received the same level of attention. The report says 22 of the 24 initially compromised firewalls were left with a webshell and showed less follow-on activity. The attacker focused on two systems tied to a US government-affiliated organization. After one firewall crashed, the attacker exploited a second device, built a tunnel into the internal network, and used that access to reach the organization's management server.
From there, the recovered artifacts show directory enumeration and decryption of an LDAP service-account password. The researchers also found scripts for password spraying, account creation attempts, and other identity-focused activity. They couldn't determine whether all those attempts succeeded because the relevant results weren't recovered. Operationally, that distinction matters: confirmed access is a serious incident, while unknown outcomes require investigation rather than guessing.
Key takeaways: The initial foothold was a publicly reachable management surface. The impact grew because the compromised firewall had trusted access to internal systems and identity services. Root access on a perimeter device should trigger investigation of the connected environment - not just a device rebuild.
How the PHP2Shell and kernel exploits worked together
The PHP2Shell component reportedly targeted PHP's session.upload_progress behavior in the PAN-OS management web server (appweb). The research says affected builds used PHP 8.0.30 with a memory limit that allowed the exploit's memory-corruption chain to work. The researchers also described their recovered exploit as a custom implementation rather than a straightforward copy of a known public proof of concept.
In broad terms, the exploit shaped the PHP process's memory using a sequence of large multipart requests. First, crafted filenames and session data consumed a large amount of memory. A later request then abused a stale session identifier to trigger an out-of-bounds read. In the response, the Set-Cookie header exposed a pointer value that helped the attacker infer where the PHP library sat in memory.
Next, the attacker applied more memory pressure to create a stale reference and influence which freed region would get reused. In the final stage, the exploit forged a PHP hash-table entry. The destructor callback was set to PHP's system() function, and the data for that entry pointed to a shell command. When PHP cleaned up the structure, it invoked the forged callback and executed the command as the restricted nobody user.
That achieved code execution, but it wasn't root yet. The report says SELinux confined the web-server process and prevented it from modifying protected system files. The attacker then chained in Fragnesia, a Linux kernel vulnerability in the XFRM ESP-in-TCP subsystem. The exploit used page-cache writes to change /etc/pam.d/su, swapping its authentication rules for pam_permit.so. That change allowed su root without a password.
The practical takeaway is that exploit impact depends on the chain, not just the headline vulnerability. The PHP flaw provided command execution; the kernel flaw crossed the privilege boundary. The source report says both ran as part of the final HTTP request, with the overall sequence - from an unauthenticated HTTPS connection to a persistent root webshell - finishing in under 15 minutes.
The chain also relied on version-specific details. Recovered files included 11 PAN-OS version profiles, with offsets and memory-layout parameters tied to particular libphp.so binaries. Some profiles were calibrated against running virtual machines, while others were provisional. That gap is a reminder that "known vulnerability" doesn't automatically mean "reliably exploitable across builds" - attackers still need testing, correct offsets, and careful tuning.
How the attacker moved from scanning to Active Directory
The campaign's scale and its later targeting are different parts of the story. During discovery, the attacker used FOFA, an internet asset search service, to find exposed PAN-OS systems. A custom scanner checked roughly 19,000 candidate targets using 200 concurrent threads. About 5,000 responded with version information, and then geography and vulnerable software versions narrowed the list to 240.
A batch runner attempted exploitation in groups of five, using a timeout per target. On success, the attacker planted a small PHP webshell in a publicly accessible directory, checked for root access, and logged the result. Once exploitation and version profiling are in place, automation makes broad targeting cheap. It also explains why defenders shouldn't treat a quiet system as "safe" just because they don't see obvious operator activity after the first compromise.
The campaign changed character once the attacker identified systems associated with one US government-affiliated environment. Configuration data from the first firewall exposed a map of internal services: domain controllers, a central firewall management server, a Keycloak single sign-on service, GitLab, VPN gateways, and the Active Directory domain. The first firewall later crashed and never came back online. The attacker monitored it, then shifted to a second firewall tied to the same organization and exploited it successfully.
The second firewall became a bridge into the internal network. The attacker installed an eight-port reverse SSH tunnel, forwarding access to internal services and providing a SOCKS5 proxy for broader internal access. The tunnel was configured to persist across reboots using both a systemd service and an rc.local hook. In practice, that meant the internal route might still exist even if someone patched or isolated the initially compromised external device.
Less than 90 minutes after compromising the second firewall, the attacker used the tunnel to compromise the internal firewall management server with the same exploit chain. That server wasn't directly reachable from the internet. Its value was the access it provided to other firewalls and the configuration, credentials, and network settings it held. From there, the attacker used LDAP connectivity to enumerate directory users and groups and decrypt the LDAP service-account password stored in the device configuration.
The researchers also recovered scripts for password spraying, attempts to create user and machine accounts, analysis of Active Directory permissions, and attempts to extract SAML signing material or probe Keycloak. The outcome of these actions is unknown. Again, that uncertainty shapes incident response: defenders should treat the identity layer as potentially exposed until they can validate account changes, authentication logs, service-account use, and SSO configuration.
What defenders should verify and do next
Start with exposure, but don't stop there. Inventory PAN-OS devices across every site and any cloud-connected environment, including management interfaces that could be reachable through an unexpected public address or an inherited firewall rule. Compare installed builds against Palo Alto Networks' current security guidance and apply the relevant fixed releases. The source report doesn't provide a complete version-by-version remediation table, so rely on vendor advisories instead of guessing what's "safe" based on the exploit profiles.
If a device was internet-accessible and running an affected build, treat it as potentially compromised until you have evidence otherwise. Preserve logs and relevant system state before rebuilding whenever that's operationally possible. Look for unexpected PHP files in public directories, changes to PAM configuration, suspicious services or boot hooks, reverse SSH processes, unusual outbound connections, and files or scripts in paths such as /usr/local/lib/.panops/. These are examples from the reported activity, not an exhaustive checklist.
Next, inspect trust relationships around the firewall. Review device configuration for directory service credentials, certificates, private keys, VPN settings, and routes to management systems. Rotate any exposed service-account credentials and relevant keys from a clean administrative environment. If a firewall management server was reachable from a compromised device, validate its integrity and assess which configurations and credentials it could have accessed. Simply replacing a perimeter appliance may not remove the attacker's internal access.
Investigate persistence both on the compromised device and on the systems accessible through it. Check systemd units, boot scripts, scheduled tasks, SSH authorized keys, web-accessible directories, and outbound tunnel destinations. Confirm whether the reverse tunnel or proxy is still active, and look for similar connections in network telemetry from other firewalls. The report describes 22 additional rooted firewalls that were left with webshells - so don't assume they were abandoned permanently.
Treat identity services as part of the incident scope. Review LDAP and Active Directory authentication logs for unusual queries, password-spray patterns, account creation, machine-account activity, and changes to directory permissions. Confirm that the organization's account lockout policy is behaving as intended; the researchers reported a zero lockout threshold in the affected environment, which enabled unlimited attempts. Review Keycloak configuration and SAML signing material, and rotate secrets if exposure can't be ruled out.
A practical response sequence is:
- Contain exposure: Restrict management interfaces to trusted administrative networks and block suspicious outbound access.
- Establish scope: Identify all affected builds, exposed devices, webshells, tunnels, and systems accessed through them.
- Protect credentials: Rotate service accounts, certificates, and keys that may have been readable from compromised devices.
- Validate identity: Investigate directory, SSO, VPN, and account-change activity for signs of follow-on access.
- Recover from a trusted state: Rebuild or restore affected systems using verified software and configuration, then monitor for renewed access.
The trade-off is between speed and confidence. If the impact seems limited to the device itself, a tightly controlled rebuild might be enough. But when a firewall has root-level compromise and trusted paths into identity infrastructure, recovery should wait until those paths and credentials have been assessed. Otherwise, a "clean" appliance may simply reconnect into an environment where the attacker still has access.
What the evidence says about attribution and AI
The report doesn't name a specific threat actor. Palo Alto Networks' Unit 42 tracks the activity as CL-UNK-1280 and describes the operator as Chinese-speaking and active in the UTC+8 time zone. Dream researchers also listed indicators consistent with a Chinese-nexus operation: focus on the United States, Japan, Taiwan, and South Korea; use of FOFA; a Chinese-developed tunneling tool; Chinese-language prompts; and infrastructure timestamps aligned with China Standard Time.
These indicators support an assessment about language, infrastructure choices, and targeting. They don't, by themselves, prove state direction or identify a specific group. The report's discussion of the targeted countries as strategically relevant is useful context, but geopolitical alignment isn't attribution.
The report also describes offensive tooling and AI-related components found in the attacker's environment, including Claude Code, an offensive security platform called aiscan configured with DeepSeek and Kimi models, and API keys for FOFA. The researchers explicitly said they don't have direct evidence that the AI tools wrote the exploit or the post-exploitation scripts. The consistency across roughly 40 scripts suggests AI-assisted development, but that's still an inference, not a confirmed fact.
This distinction matters because "AI was present" can distract from the operational evidence. The actionable findings here are the exploit chain, the version profiling, the successful compromises, the persistent tunnel, and attempts to reach identity systems. Even if an LLM helped draft some code, that doesn't change containment priorities. It might explain how an operator produced tooling efficiently, but it doesn't automatically establish autonomy, sophistication, or state sponsorship.
Conclusion
This campaign is a clear example of how an exposed management interface can turn a device vulnerability into an identity-security incident. The PHP2Shell and kernel exploits gave the attacker a path to root, but the bigger risk came from what the compromised firewalls could reach: internal management systems, credentials, VPN infrastructure, and Active Directory.
For defenders, the priority isn't just patching. Inventory exposure, investigate persistence, rotate credentials and keys that may have been accessible, and verify what systems were connected to the compromised firewalls. When the identity-focused outcome is unclear, treat that uncertainty as work to validate - not as evidence that the attacker stopped at the perimeter.