Your Firewall Isn't a Wall. It's a Safe Full of Keys to Your Domain.

Quick Answer: When attackers used PHP2Shell to root internet-facing firewalls, they did not find an empty edge of the network. They found a device holding a directory service password, private keys and a full map of the internal network, with a clear line of sight to the domain controllers. External scanning cannot see any of this. It confirms the perimeter is patched and closed, which is exactly the false comfort that let a patched-looking environment lose its domain. The question that matters is not "is the edge patched" but "what could someone reach from it", and only assumed-breach testing, run from inside the network, answers that.

In the confirmed PHP2Shell compromises, attackers rooted internet-facing firewall management interfaces. But rooting the firewall was the opening move, not the goal. How they got from the web shell to root is covered in our article on PHP2Shell chained with the Fragnesia kernel bug.

Once on the device, the running configuration handed them a map of everything worth reaching: the domain controllers, an internal management server, the single sign-on platform, a code repository and the Active Directory domain itself. The config also held a directory service account password, which was decrypted, and the private keys the device used for replication, TLS and its own authentication. With that, the attacker enumerated the domain's users and groups and moved toward the management server deeper inside the network.

Some later steps, such as attempts at domain admin and planting backdoor accounts, were tried but could not be confirmed from the artifacts. Either way, the shape is clear: an unauthenticated flaw on an edge device led, within hours, to real credentials and a foothold inside the network.

Run an external scan of that same environment the day after patching and it comes back clean: perimeter patched, management interface closed, nothing exposed.

An external scan answers one question, what can I see from the outside. It has no way to know that the edge device is also a credential store: that the firewall config holds a domain password, that the device can open a path to a domain controller, or that a service account on it has more rights than it needs. None of that is visible from the internet, and all of it decides what happens once someone is through.

This is the gap the PHP2Shell cases exposed. The environments that lost ground did not have sloppy perimeters. Internet-facing management interfaces are rare: Palo Alto's own exposure data put them at well under a hundredth of a percent of its installed base. What mattered was what sat directly behind that single open door. Our PHP2Shell appliances guide lists which firewalls, NAS boxes and panels carry a PHP management interface.

The test that would have caught this does not start at the perimeter. It starts from a question external scanning never asks: suppose an attacker already has a foothold on one exposed host. What happens next?

That is assumed-breach testing, and it surfaces the things that decide the outcome of a real intrusion:

An external assessment tells you what is exposed and how current your runtimes are. Assumed-breach testing is what you add when that exposed host sits next to something you cannot afford to lose.

The external assessment finds the exposed edge. It does not walk the path behind it, because that work is a different engagement: internal, assumed-breach testing that maps what a foothold on one host can reach across your identity and management infrastructure.

You want that second step when the honest answer to "what sits behind our edge devices" is "the domain". If a compromised firewall, VPN or web server is one or two hops from a domain controller or a secrets store, external scanning will keep reporting a clean perimeter while that path stays wide open. We scope that testing on top of the assessment once we can see what your perimeter is actually guarding. See internal vs external penetration testing for which one your situation needs, or contact us to scope an internal test.