Disrupt PHP2Shell Post-Exploitation with CrowdStrike Controls

Two servers can have the same PHP2Shell vulnerability and very different levels of exposure. A list of affected CVEs tells security teams what needs to be patched. It does not, by itself, show which server an attacker could reach first, which defenses apply to that connection, or how much of an attack those defenses could stop.

CrowdStrike reports Falcon coverage for activity commonly associated with PHP2Shell post-exploitation, including web-shell deployment, suspicious child processes, and malicious command execution. That creates another opportunity to reduce exposure while teams work through patching. The important questions for security teams are which servers are reachable and whether the relevant Falcon protections are actually active on those hosts. 

Using Reach, and its new Exposure Intelligence capabilities, security teams can quickly understand which vulnerable systems attackers can reach, then assess the endpoint protections that can interrupt what happens next.

Same vulnerability, different exposure

Consider two equally important PHP servers running the same affected version. Both have CrowdStrike Falcon installed.

Server A: The application accepts requests from the internet. The permitted network path has no applicable exploit-blocking control, and some Falcon prevention settings have been weakened.

Server B: The firewall denies the assessed internet connection. Access is permitted only from a designated application subnet, so security teams also need to assess whether an attacker operating from that subnet could reach the service.

For an attack starting on the internet, Server A deserves more immediate attention. Server B still needs patching, and its permitted internal paths need their own review. Calling a server “internal” does not tell you whether it is reachable from every relevant attacker origin.

In a real environment, business impact and the quality of the evidence also affect priority. But this example shows why the most useful response starts with the actual path to the vulnerable service and the protections applied along that path.

Understand what each defense can actually stop

There are different opportunities to interrupt an attack. A network control can deny the connection before it reaches the vulnerable PHP service, or block a malicious request that matches a known exploit. Falcon may detect or prevent suspicious activity on the server after an attacker has reached the application.

That endpoint layer can be valuable, but the stage of the attack also comes into play. The original PHP2Shell research demonstrated memory disclosure as well as code execution. If Falcon prevents a suspicious child process from running, that is useful protection against that behavior. It does not prove the earlier memory-disclosure or code-execution step was stopped.

The same care applies when evaluating visibility features. CrowdStrike’s Linux reference distinguishes suspicious-process prevention from capabilities such as Memory Visibility and enhanced PHP visibility, which provide telemetry for investigation. Teams should know whether a setting actively blocks activity or helps them detect and investigate it.

A server with effective endpoint protection may still need a network access restriction and a PHP update. Knowing which part of the attack each control addresses helps teams choose the next action.

Follow the attack path, then inspect the host in Reach

In Reach Exposure Intelligence – our new module in Reach that allows you to deploy compensating controls to mitigate vulnerabilities – an analyst can start with the CVE and affected host, then look at the traffic paths an attacker might use. Views such as “Where protection stops” and “Rules in evaluation order” help explain whether a given origin can reach the service and which network policies apply along the way.

The investigation then moves to the host. Reach’s CrowdStrike Falcon integration reviews host inventory, sensor telemetry, prevention settings across host groups, and inconsistencies in how policies are applied. This helps teams check whether the intended endpoint protections are present and configured on a specific affected server.

For the two-server example, that means answering two practical questions: Can an attacker reach this PHP service from the origin being assessed? And, if the connection remains open, which Falcon controls can detect or interrupt the relevant attacker behavior?

Check the protection at each stage of the exploit

Reach also maps the stages of an exploitation chain to potentially relevant security controls. That lets analysts examine the defense in the context of the attacker behavior it is meant to address, rather than relying on a product name or an installed sensor as proof of protection.

The exploit-chain view shows how CrowdStrike capabilities map to different stages of the researched attack. In this example, Heap Spray Preallocation is marked “Partly effective” for heap spraying, while Force ASLR is marked “Bypassed” at two information-disclosure-based ASLR-bypass stages. These are stage-specific capability assessments, not evidence that a particular customer’s Falcon deployment was bypassed.

Reach also identifies whether the underlying chain analysis is Demonstrated, Described, or Hypothetical. These labels help the analyst understand the evidence and where further validation is needed.

Before treating any mapped capability as a protection on an affected server, the team still needs to check the operating system, Falcon sensor, applicable hardware requirements, assigned policy, and any exclusions. It also needs to confirm whether the capability blocks the behavior or only generates visibility into it.

For example, the source analysis marks Heap Spray Preallocation as “Partly effective” for a selected Heap Spraying stage. That finding points to a potentially relevant defense, but it does not establish that exploitation would be prevented on a particular host.

The useful output is a clear record of what was assessed: the attack stage, the control that may apply, its actual enforcement state on the host, and the exposure that remains. Research-based mappings, configuration evidence, and a successful exploit-blocking test should be kept distinct.

Turn the findings into a targeted change

Once a vulnerable server and its reachable paths are understood, the team can decide which existing controls offer the most immediate improvement. Depending on the environment, that could mean restricting an unnecessary source, restoring inspection on an allowed network path, strengthening an applicable Falcon prevention setting, or accelerating the patch.

Reach organizes available options as Recommended, Alternative, and Required actions, including their dependencies. Current Exposure describes the assessed state today; Achievable Exposure shows the improvement modeled from proposed changes. Security teams still need to implement those changes and reassess the environment to confirm the resulting protection.

Every affected server still needs software remediation. In the meantime, reachability analysis and host-level control evidence help security teams focus first on the systems attackers can reach and on the specific changes most likely to reduce exposure.

Explore Reach’s CrowdStrike Falcon integration or learn more about how to mitigate vulnerabilities using compensating controls.

Want a demo of this new capability? Sign up at www.reach.security/connect