top of page

The Poachers in the Digital Wilderness: How PHP2Shell Turned the Web Into a Hunting Ground

hace 10 minutos
7 min de lectura

The forest was vast.

Millions of digital creatures moved through it: government systems, financial platforms, airports, online stores, and corporate applications.

Each occupied its own territory. Each depended on the same ecosystem to survive.

And somewhere beyond the perimeter, poachers were watching.

They didn’t charge through the trees with weapons raised. They studied the trails, tested the boundaries, and waited for signs of weakness.

Some hunted indiscriminately.

Others were far more selective.

They weren’t looking for every target. They were looking for prey that could be taken without raising an alarm.

This was the landscape surrounding PHP2Shell, two critical PHP vulnerabilities that triggered widespread exploitation attempts and became the focus of a suspected North Korea-linked reconnaissance campaign.


Phase 1 — A Forest With 37 Million Potential Targets


The digital wilderness runs on infrastructure that most visitors never see.

PHP is one of its most widespread foundations, supporting content management systems, online stores, enterprise applications, and countless websites.

According to Bitsight, nearly 37 million internet-facing systems run PHP or PHP-related software.

For attackers, that represents an enormous potential hunting ground.

But not every system is vulnerable.

The challenge for the poachers is identifying which environments run affected PHP versions, which remain unpatched, and which might provide valuable access.

Unlike a vulnerability confined to a single application, a flaw in the PHP runtime can potentially affect many different services.

The poachers weren’t searching for one particular species. They were searching for a weakness shared across the ecosystem.


Phase 2 — The Scent of PHP2Shell


Two critical vulnerabilities gave the hunters something to investigate:

  • CVE-2026-109618

  • CVE-2026-109619

Collectively known as PHP2Shell, the flaws can allow remote code execution in affected PHP environments.

The underlying exploitation techniques involve manipulating PHP’s memory behavior.

According to Datadog, attackers must trigger a carefully timed allocation failure and overcome address space layout randomization (ASLR).

Certain form-field names can cause PHP to create additional copies during processing. Under vulnerable conditions, specially crafted requests can contribute to memory exhaustion and corruption.

Successful exploitation may allow an unauthenticated attacker to execute code on the server.

To the poachers, the vulnerabilities represented possible openings in the protective perimeter.

But finding the weakness and successfully exploiting it were different challenges.

A broken branch might reveal a trail. It doesn’t guarantee the prey has been captured.


Phase 3 — The First Footprints


After PHP2Shell became public, automated activity spread rapidly.

Cloudflare reported detecting millions of exploitation attempts.

The forest was suddenly full of footprints.

Some requests were broad probes, testing whether servers exhibited vulnerable behavior. Others represented more deliberate exploitation efforts.

The distinction mattered.

An attempted exploit is not proof of successful compromise.

A scan may identify a potentially exposed target without giving the attacker access.

But reconnaissance provides valuable information.

Every response can help an attacker distinguish a hardened system from a promising one.

Before poachers set their traps, they learn where the animals travel.


Phase 4 — Twenty-One Hidden Hunting Posts


Among the widespread activity, CYFIRMA reported a more selective operation suspected of being associated with North Korean threat actors.

Rather than flooding the internet with requests, the operators allegedly used 21 compromised nodes to probe a prioritized list of 216 unpatched or partially mitigated hosts.

The targets spanned the United States, Japan, South Korea, Thailand, Indonesia, Australia, Taiwan, India, Singapore, the United Arab Emirates, Saudi Arabia, and the European Union.

They included government agencies, banks, logistics providers, airports, manufacturing organizations, and online transaction platforms.

The activity was described as deliberately slow.

Nodes were rotated, and operators reportedly abandoned them when blocking or rate-limiting appeared.

The strategy resembled poachers shifting between concealed observation posts.

One location would test the perimeter.

Another would continue the search.

A third would remain silent until attention moved elsewhere.

No stampede. No obvious assault. Just a patient search for the weakest prey.


Phase 5 — The Poachers’ Secret Meeting Place


CYFIRMA reported that the suspected operation was coordinated through a closed I2P channel.

According to the researchers, participants shared target lists, infrastructure information, and operational priorities.

The campaign was attributed with moderate confidence to a Korean-speaking operator associated with the broader Lazarus Group ecosystem.

The assessment drew on reported linguistic indicators, historical infrastructure associations, targeting patterns, and previous activity involving PHP and WordPress compromises.

CYFIRMA also cited earlier campaigns in which Lazarus-associated actors had used compromised web servers and malicious web shells.

However, the attribution was not definitive.

The presence of language patterns or infrastructure associations does not independently establish the identity of every operator.

The researchers reported that the group intended to shortlist promising targets and adapt publicly available exploits.

That suggested preparation for further attacks.

It did not establish that all 216 hosts had been successfully exploited.

The poachers had drawn their map. Whether every trap would be set remained another question.


Phase 6 — A Separate Hunt, an Unproven Weapon


A different investigation by Palo Alto Networks Unit 42 initially appeared to connect PHP2Shell with an intrusion against a European government entity.

The observed attacker reportedly accessed password hashes and multifactor authentication secrets within approximately two hours of the initial compromise.

The intrusion also involved:

  • Reconnaissance of authentication databases.

  • LDAP queries against Active Directory.

  • Discovery of internal hosts and privileged accounts.

  • Establishment of an NTLM-relay tunnel.

  • Attempts to escalate privileges toward Domain Admin.

Unit 42 observed structured command output containing delimiters such as ==SHELLUSER== and ==PASSWD==.

Researchers considered this behavior potentially consistent with an agentic AI-assisted attacker, because the delimiters made command results easier for automated systems to interpret.

But the investigation reached an important limitation.

Unit 42 retracted its earlier assessment linking the intrusion to the PHP2Shell vulnerabilities.

The company confirmed that the incident occurred in the context of a vulnerable PHP application but could not verify that either PHP2Shell CVE had provided initial access.

The intrusion was real.

The suspicious behavior was observed.

The claimed PHP2Shell connection was not confirmed.

And the European government intrusion should not be treated as evidence of the suspected North Korean campaign.

Finding an injured animal doesn’t prove which poacher attacked it—or which weapon was used.


Phase 7 — Testing the Traps


Other researchers observed activity consistent with attackers searching for PHP2Shell exposure.

On October 25, Defused Cyber reported probes against Palo Alto Networks GlobalProtect honeypots.

The traffic reportedly originated from:

204.76.203[.]7

The requests contained a PHP session upload-progress marker, p2s-rider, alongside a dummy file upload without a malicious payload.

This suggested attempts to test for vulnerable behavior and identify promising targets.

The observations did not demonstrate successful remote code execution.

Instead, they illustrated a reconnaissance technique: testing the environment before attempting a more consequential intrusion.

The poachers were checking the trails.

They were not necessarily taking down their prey.


Phase 8 — The Tracks Left Behind


Even failed exploitation attempts can leave traces.

ReliaQuest reproduced CVE-2026-109618 in a controlled laboratory and documented a sequence of potentially useful detection artifacts.

These included:

  1. An HTTP POST request returning a 500 error.

  2. PHP memory exhaustion messages.

  3. Evidence of heap corruption.

  4. A crash affecting the Apache worker processing the request.

Individually, these events may have innocent explanations.

Together, particularly when they occur in a suspicious sequence, they can justify further investigation.

Defenders should correlate PHP error logs, Apache access logs, Apache error logs, and system events.

They should also look beyond simple request-volume thresholds.

An attacker using multiple compromised nodes to distribute a small number of requests may avoid detection rules designed to identify large traffic spikes.

The quietest poachers may leave the fewest footprints. That makes every trace more important.


Phase 9 — Another Trap in the Undergrowth


While organizations responded to the primary PHP2Shell vulnerabilities, the PHP Foundation warned about another remote code execution issue:

CVE-2026-115560.

This vulnerability requires an unusual combination of configuration and application behavior.

The affected scenario involves an application configuring session.serialize_handler as php_binary or php_serialize, then switching it to php at runtime using ini_set() before calling session_start().

Session upload progress must also be enabled.

Applications that do not change their serialization handler at runtime are not exposed through that specific condition.

The PHP Foundation indicated that the issue would be addressed through the regular release cycle.

For defenders, the lesson was to evaluate the precise exposure conditions rather than assume that every PHP system faced identical risk.

Not every trail leads into a trap. But every genuine weakness deserves attention.


Phase 10 — Protecting the Wildlife


Stopping poachers requires more than watching the obvious paths.

Organizations need visibility into their PHP infrastructure and the ability to identify both vulnerable systems and suspicious activity.

Patch the runtime. Apply the relevant PHP security releases. Updating WordPress plugins or deploying WAF rules alone does not eliminate vulnerabilities inside PHP itself.

Map the hunting ground. Inventory internet-facing PHP installations, including older applications, hosting environments, and services that may not openly advertise their PHP dependency.

Watch for unusual tracks. Correlate suspicious POST requests, HTTP 500 responses, memory exhaustion, heap corruption, and Apache worker crashes.

Look for patient hunters. Detect distributed, low-volume reconnaissance across longer periods and multiple source addresses.

Investigate signs of capture. Examine unexpected web shells, newly created accounts, suspicious processes, credential access, and unauthorized outbound connections.

Separate sightings from confirmed attacks. Distinguish scanning, attempted exploitation, successful compromise, and suspected attribution.

The objective is not simply to frighten the poachers away from one location.

It is to remove the vulnerabilities that make the environment attractive to them.


The Final Hunt — When the Forest Goes Silent


PHP2Shell illustrates the difference between noisy attacks and patient reconnaissance.

Millions of requests may strike exposed infrastructure after a critical vulnerability becomes public.

But some operators reportedly prefer a narrower strategy.

They select high-value targets, rotate compromised infrastructure, probe slowly, and retreat when defenders notice them.

The suspected North Korea-linked campaign described by CYFIRMA reflects that pattern, although its attribution remains an assessment rather than a confirmed identity.

Meanwhile, Unit 42’s retraction demonstrates why investigators must avoid turning an unconfirmed technical connection into an established fact.

For defenders, the priority remains clear.

Identify vulnerable PHP environments. Patch the runtime. Monitor the subtle signs of reconnaissance. Investigate suspicious activity before an attacker establishes persistence.

Because in a forest this vast, not every predator announces its arrival.

The most dangerous poachers aren’t the ones who make the loudest noise.

They’re the ones who know exactly which prey has been left unprotected.



The Hacker News


 
 
 

Comentarios


bottom of page