PHP2Shell Exploit Toolkit Found on Attacker Server as Researchers Uncover Live Target Reconnaissance

Description

PHP2Shell exploit tooling was discovered on an attacker-controlled server by SOCRadar researchers through passive collection of files exposed by an open directory listing.

The central artifact, aslr_exploit.py, was described by its operator as a one-click exploit for PHP 8.4.26 running under Apache mod_php. The server also hosted scripts for fingerprinting PHP deployments, probing for exploitable configuration settings, and performing additional website reconnaissance.

The findings illustrate how attackers can progress from vulnerability research to automated target identification. Although the recovered exploit was tested in a controlled environment, the examined live websites did not satisfy its prerequisites, and researchers found no evidence of successful shell access during the reported screening.

The PHP2Shell exploit chain combines memory-address disclosure with PHP session handling to attempt remote command execution.

The recovered exploit uses three broad stages:

• PHP worker manipulation: Recycles the target's PHP worker as part of preparing the exploit.

• ASLR bypass: Leaks memory addresses through session-cookie behavior to work around memory randomization.

• Command execution: Abuses PHP session upload-progress handling to trigger shell-command execution.

The exploit includes two calibration profiles: one for the official PHP 8.4.26 Apache container image and another for a custom laboratory build. It defaults to a local target, suggesting the operator tested the exploit against controlled environments before attempting to identify suitable public-facing targets.

The technique is configuration-dependent. SOCRadar identified the following conditions as important to the recovered exploit chain:

• PHP errors displayed to visitors.

• Session upload-progress functionality enabled.

• Session strict mode disabled.

• A very low PHP memory limit.

• A single Apache worker.

These settings can make the exploit chain more viable than it would be against a hardened production configuration. However, configuration hardening should be treated as a temporary risk-reduction measure, not a substitute for installing fixed PHP releases.

The activity documented by SOCRadar can be summarized as follows:

1. Exploit development: The operator builds and tests a PHP2Shell RCE chain in a controlled environment.

2. Target discovery: A fingerprinting script identifies publicly accessible websites and collects information about their PHP versions and server configurations.

3. Configuration probing: Additional scripts check whether PHP errors, session behavior, and other configuration settings expose the conditions needed by the exploit.

4. Vulnerability assessment: The operator evaluates potential targets for conditions that could enable exploitation.

5. Potential follow-on activity: A successful exploit could provide a route to command execution, although SOCRadar did not observe successful shell access on the websites examined.

The researchers also recovered a separate WordPress reconnaissance script that enumerates users, identifies popular plugins, examines XML-RPC methods, tests pingback functionality, and searches for exposed debug logs. This activity should be distinguished from the PHP2Shell exploit chain itself.

The primary file, aslr_exploit.py, implements the exploit against PHP 8.4.26 under Apache mod_php.

The exploit relies on a combination of memory manipulation and session-related behavior. By recycling the PHP worker and obtaining memory-address information, it attempts to bypass ASLR. It then abuses session upload-progress processing to reach command execution.

SOCRadar noted that the command execution capability was limited to a very short command. A real intrusion would therefore likely require additional tooling or a second-stage script to carry out more extensive operations.

The presence of the exploit indicates that the operator had developed and tested a working laboratory chain. It does not establish that the same chain successfully compromised the public websites examined by the researchers.

The script php2shell_fp.py was used to examine approximately 20 public websites across Europe, North America, and Asia.

The screening included websites in the United Kingdom, Finland, Poland, France, Canada, the United States, and China.

The script collected PHP and server information from response headers, including:

• X-Powered-By

• Server

It used these headers to infer whether a website might be running PHP through Apache mod_php.

The script also sent multipart HTTP requests containing a PHP session upload-progress field and a randomly generated session identifier to assess how the target handled the session.

This technique allowed the operator to screen potential targets without immediately deploying the full exploit chain.

The second-stage script, deep_probe.py, performed more detailed checks against 11 websites.

Its activities included:

• Triggering a PHP warning to determine whether errors were displayed.

• Checking six common phpinfo paths for exposed configuration information.

• Examining PHP memory limits and session upload-progress settings.

• Testing 11 common parameters for potential file-inclusion weaknesses.

• Sending upload requests with unique MARKER_ filenames to test session-injection behavior.

The results showed that six websites ran PHP 8.4 releases older than the fix, including four running PHP 8.4.26. The other websites reported PHP 8.3, 8.2, or end-of-life PHP 5.6.

Despite the presence of older PHP versions, none of the 11 deeply examined sites exposed the required errors, accessible phpinfo information, file-inclusion conditions, or session behavior needed by the recovered exploit chain.

This finding is specific to the recovered tooling and the websites examined. It does not establish that those websites were immune to other vulnerabilities or attack techniques.

The recovered wp_attack.py script targeted five WordPress websites.

Its functionality included:

• Enumerating user accounts through the WordPress REST API and author redirects.

• Checking for approximately two dozen popular plugins.

• Enumerating XML-RPC methods.

• Testing XML-RPC pingback functionality.

• Searching for exposed WordPress debug logs.

These capabilities could help an operator identify potentially vulnerable components, exposed information, and additional attack opportunities. However, the presence of reconnaissance tooling alone does not demonstrate that a vulnerability was exploited or that any website was compromised.

Other files found on the same server indicated that the operator was involved in activities beyond PHP2Shell.

The recovered tooling included:

• Secret harvesting: Extracting API keys and backend URLs from client-side JavaScript.

• Endpoint sweeping: Testing web and API routes, including administrative paths, for unauthenticated access.

• Proxy rotation: Routing requests through a rotating proxy pool to distribute traffic and potentially evade rate limits or blocking.

• Additional reconnaissance: Artifacts associated with web-archive reconnaissance and automated CAPTCHA solving.

Some of the wider toolset targeted cryptocurrency and Web3 platforms. SOCRadar assessed that the broader operation appeared financially motivated, but the operator remained unattributed. These findings should not be treated as proof that every tool on the server belonged to the same PHP2Shell campaign.

We identified the following infrastructure associated with the exposed attacker server and its tooling.

IPv4 Addresses

• 102.210.149.166

• 104.219.251.31

• 107.150.31.151

• 122.10.110.72

• 122.10.17.49

• 139.162.165.136

• 157.230.117.70

• 206.188.197.105 — Attacker staging and operations server; previously identified in the investigation

• 217.160.132.82

• 41.223.30.7

• 45.198.224.88

• 47.100.125.108

• 54.169.109.7

• 58.221.60.160

• 85.11.167.243

• 89.32.41.16

• 89.32.41.50

• 92.118.112.100

CIDR Range

• 45.198.224.0/24

Domains

• *.botlesscucks.st

• *.gettingheadfromduckysmom.st

• *.godofthunder.st

JA4H Fingerprint

• po11cn050000_0a87faf13e54_fe81d65a9ab0_0b5a6e5841d5

HTTP User-Agent Indicators

• User-Agent containing php2shell

• php2shell-scan/109618

• php2shell-109618

PHP-FPM Error Indicator

• Allowed memory size exhausted

Previously Identified Attacker Infrastructure

• 206.188.197.105:9999 — Exposed working directory over HTTP

• 206.188.197.105:8899 — Rotating proxy pool

• 206.188.197.105:8888 — Out-of-band interaction listener

Additional Behavioral Indicators

• Session-injection screening filenames following the pattern MARKER_[8 hex characters].txt

• PHP session ID prefixes fprint and dp

These indicators are reported in the SOCRadar research. Validate them against internal telemetry and threat-intelligence sources before applying blocking or incident-classification decisions. The presence of a connection to the reported infrastructure should be correlated with timestamps, destination ports, processes, users, and associated HTTP requests.

If a compatible PHP deployment is exposed and successfully exploited, PHP2Shell could potentially enable remote command execution on the affected server.

Potential consequences include:

• Unauthorized command execution under the privileges of the PHP or web-server process.

• Access to application files, configuration files, and sensitive information.

• Exposure of credentials, API keys, or backend service URLs.

• Follow-on exploitation through additional payloads or scripts.

• Unauthorized access to connected databases or internal services, depending on permissions and network exposure.

• Further reconnaissance and lateral movement if the compromised environment permits it.

• Business disruption and incident-response costs.

The recovered exploit's command execution was reportedly limited, and SOCRadar did not observe successful shell access on the screened websites. These potential impacts should not be interpreted as confirmed outcomes of this specific screening activity.

Immediate Actions

1. Update PHP: Upgrade to a fixed release appropriate for the deployed PHP branch.

2. Block and investigate the reported infrastructure: Review firewall, proxy, DNS, and web-server logs for connections to 206.188.197[.]105 and its reported service ports.

3. Hunt for screening traffic: Investigate unusual multipart POST requests containing PHP_SESSION_UPLOAD_PROGRESS, particularly when accompanied by upload filenames matching MARKER_ followed by eight hexadecimal characters.

4. Review PHP error handling: Ensure PHP errors are not displayed to unauthenticated visitors in production.

5. Inspect session configuration: Review upload-progress settings and enforce strict session handling.

6. Remove exposed diagnostic pages: Search for public phpinfo pages and other configuration-disclosure endpoints.

7. Review web-server logs: Look for suspicious requests to PHP endpoints, unexpected session identifiers, repeated probing, and unusual upload behavior.

8. Investigate suspected compromise: Correlate web-server activity with endpoint telemetry, process execution, file changes, and outbound connections.

Preventive Actions

• Maintain supported PHP versions and apply security updates promptly.

• Upgrade end-of-life PHP deployments to supported branches.

• Set display_errors to Off in production.

• Set session.use_strict_mode=1.

• Disable session.upload_progress.enabled where it is not required by the application.

• Set expose_php=Off to reduce PHP version disclosure through response headers.

• Apply appropriate memory limits and web-server worker configurations without relying on these measures as substitutes for patching.

• Restrict access to diagnostic endpoints and administrative interfaces.

• Deploy a web application firewall (WAF) with logging and rules for suspicious session-upload behavior.

• Monitor for unexpected PHP child processes, command interpreters, and outbound connections.

• Perform regular vulnerability assessments of internet-facing applications.

• Include PHP applications, WordPress installations, plugins, and dependencies in ongoing attack-surface management.

• Establish incident-response procedures for suspected web-server compromise.

SOCRadar identifies fixed PHP releases 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as remediation targets in its report. Confirm the appropriate fixed release for your environment and the current official PHP security guidance before deployment.

 Conclusion

The discovery of PHP2Shell exploit tooling on an exposed attacker server demonstrates how vulnerability research can be translated into automated target screening and exploit attempts. The recovered scripts combined PHP version fingerprinting, configuration probing, session behavior testing, and a laboratory-tested RCE chain targeting PHP 8.4.26 under Apache mod_php.

Although the examined websites did not meet the exploit's prerequisites and no successful shell access was observed, organizations should not rely on hardened settings alone. Updating PHP, removing exposed diagnostics, securing session handling, and monitoring suspicious HTTP requests remain important defensive priorities.

The broader tooling recovered from the server also highlights the value of monitoring for credential harvesting, endpoint enumeration, and proxy-based reconnaissance. Organizations should use the reported indicators as investigation pivots while distinguishing observed activity from confirmed compromise.