PHP2Shell chain roots 25 servers, hits U.S. government-affiliated network

The compromise started at the network edge. According to cybersecurity firm Dream, the affected devices run specific versions of a large vendor's firewall software. From there the intrusion moved inward rather than stopping at the perimeter device.

The same chain was used repeatedly. Rooted systems span the U.S., Japan, Taiwan, and South Korea, which points to reuse of one tested method against many targets rather than a single hand-built operation.

Two pieces were combined. PHP2Shell provided the initial foothold, and a kernel privilege escalation exploit tracked as CVE-2026-46300 turned that foothold into root on the affected devices.

The identity stage followed a clear order. The attacker targets Active Directory to decrypt the LDAP service account password, enumerate users, and spray passwords against every user account using organization-themed passwords in an attempt to extract credentials.

Work outward from the firewall to the directory, in that order.

1. 01

   Confirm the exact firewall build you are running

   Pull the running version from each appliance management console or CLI, not from your asset inventory, which often lags. Compare every result against the vendor's advisory for CVE-2026-46300. Any device on a build the vendor lists as affected, or any device whose version you cannot confirm, is a bad result.

2. 02

   Look for PHP files that should not exist

   On the appliance filesystem or its backup image, list web-root and upload directories sorted by modification time, for example find /var/www -name '*.php' -mtime -30 -ls. Compare file hashes against a clean image of the same version. Unknown PHP files, or known files with changed hashes, warrant isolation of the device.

3. 03

   Review the LDAP service account

   Find where that account's password is stored on edge devices and in configuration backups. Check its group memberships and the rights it holds in Active Directory. A service account that is a member of a privileged group, or one whose password has not been rotated since the device was last exposed, is a bad result.

4. 04

   Hunt for password spraying in authentication logs

   Query domain controller security logs for event ID 4625 grouped by source address and by hour, and flag sources touching many distinct accounts with few attempts each. Include accounts that are disabled or dormant, since spraying hits those too. A single source spanning most of your user base is the signal to chase.

5. 05

   Check for directory enumeration

   Enable and review LDAP diagnostic logging on domain controllers, including expensive and inefficient search logging via event 1644. Look for broad subtree queries returning large user sets from hosts that do not normally run them. Queries originating from an appliance or a jump host are worth a full review.

6. 06

   Test your password policy against themed guesses

   Run an offline audit of domain hashes against a wordlist built from your own organisation name, products, sites and seasons. Count how many accounts fall. Any match on a privileged or service account means forced rotation and a policy change, not just a note in a report.