Attackers Used a Firewall Flaw to Reach the Directory Behind It, Then Pulled a Service Account Password. Would Your Identity Logs Show It?

A PHP2Shell attack chain reportedly started on an exposed firewall management interface, reached the internal directory, and took an LDAP service-account credential from the network. According to Unite.AI's report on Dream's investigation, published 26 October 2026, 25 servers were compromised: 24 perimeter firewalls and one internal management server. One of the affected environments was a U.S. government-affiliated network. The flaws themselves are covered in our PHP2Shell timeline, so this article looks at what happened after the first foothold.

The pivot, step by step

According to the same report, the path ran in three stages:

1. Exposed management. The firewall's management interface was reachable from the internet. PHP2Shell gave the attacker code execution on the device.
2. Directory access. From the firewall, the attacker reached internal identity infrastructure. Firewalls often hold LDAP or Active Directory bind credentials so they can look up users for VPN and admin login. Those credentials are the valuable part.
3. Service account and enumeration. Dream confirmed the extraction of an LDAP service-account credential and directory enumeration. Enumeration is the step where an attacker maps users, groups and privileged accounts before choosing where to move next.

The pattern matters more than the one bug. A service account is rarely watched like a person's login. It has a fixed password, no MFA, and often broad read access to the directory. Once it is stolen, the attacker can look like a normal part of the network.

What is and is not established

Only one news outlet, Unite.AI, has reported these details, and we could not locate Dream's primary publication, so the figures should be checked against it before you rely on them. Dream also did not claim the operation was autonomous, and it had no direct evidence that AI tools wrote the exploit or the post-exploitation scripts. Its suggested China-nexus link was tentative, and it named no threat actor. Dream withheld the affected vendor and firmware versions.

What to detect this week

• Service-account binds from unusual sources. An LDAP bind from a firewall, or from any host that is not your usual directory client, is a strong signal. Alert on it.
• Bulk directory queries. Enumeration shows up as large numbers of user, group and admin-group lookups in a short window. Set a baseline for the service account and alert on spikes.
• Management-plane exposure. Confirm that firewall admin interfaces are not reachable from the internet. If one is, treat the device as possibly compromised and review its configuration and stored credentials.
• Rotate the bind credential. If a firewall stores a directory service account, rotate its password after patching, and restrict the account to the read scope the device actually needs.

How Obiguard SOC fits

This is a detection problem. The attacker's first request to the directory and the bulk enumeration that follows are the moments to catch. Obiguard SOC covers the detection side, so an unexpected service-account bind can be seen when it happens rather than found in a later review. SOC does not patch the firewall or remove a stored credential; those steps stay with your operations team. Pair SOC alerts with an external view of which management interfaces you expose, which is what Obiguard Scout maps.

The question to take away

If a firewall were compromised tonight, would anyone notice that its directory service account had started enumerating your users?