An examination of the WP2Shell RCE chain on WordPress Core for Linux systems through CrowdStrike Falcon telemetry, built-in webshell visibility, and behavioral Custom IOA rules.
Modern EDR platforms surface the processes, file activities, script contents, and parent-child relationships running on the endpoint through strong telemetry. Even so, the successful exploitation of a vulnerability in an internet-facing web application does not always translate into a high-severity endpoint alert at the earliest stage. Steps such as SQL injection, privilege manipulation, and abuse of the application's legitimate administrative functions frequently remain within the application and database layers. From an endpoint perspective, the critical moment is the point at which the attack chain begins to execute operating system commands, drop files, or use post-exploitation tooling.
In this article, the WP2Shell chain published for WordPress Core is examined for Linux systems in the InfinitumIT test environment from the CrowdStrike Falcon perspective. The goal is not to judge the CrowdStrike product on the basis of a single successful or failed alert; it is to show what telemetry a specific public PoC produces, which built-in mechanisms come into play, and how detection coverage can be expanded with Custom IOA rules tailored to the organization's own risk model.
WP2Shell Case Study
The attack chain published under the name WP2Shell combines the WordPress REST batch behavior with the effect of SQL injection, allowing an unauthenticated attacker to create an administrator account and then obtain remote code execution (RCE). The public PoC used in this work provides several subcommands for verifying the vulnerability and executing a controlled shell flow. Repository used in the research: https://github.com/0xsha/wp2shell
When no credentials are supplied, the shell flow of the public PoC creates a new WordPress administrator account, logs in with that account, uploads a token-controlled plugin webshell, and runs the given command under the web server user. This chain is not just the writing of a PHP file to disk; it forms a sequential attack path between privilege acquisition at the application layer and process execution at the endpoint layer.
InfinitumIT Test Environment
The test environment consists of two Ubuntu virtual machines running on VMware Workstation, in an isolated 192.168.77.0/24 segment. The attacker host at 192.168.77.10 was used for the public PoC and controlled payload tests, while the target host at 192.168.77.20 was used for WordPress 6.9.4, Apache 2.4.58, PHP 8.3.6, MariaDB 10.11.14, and CrowdStrike Falcon Sensor 7.39.0-19203. Attack traffic was kept exclusively within the lab segment, while the target system's controlled NAT access was preserved for Falcon cloud communication.
Figure 1. InfinitumIT WP2Shell Detection Lab architecture: the controlled test network between the isolated attacker host and the WordPress target with the CrowdStrike Falcon Sensor.
The WordPress environment's REST API access, a published test post, and plugin installation functions were prepared to satisfy the requirements of the public PoC. Test results were compared through Falcon Advanced Event Search, the Falcon process tree, Linux Auditd records, PoC terminal output, and the user and plugin artifacts generated on WordPress.
Figure 2. The WP2Shell Detection Lab home page prepared on WordPress 6.9.4 and the published EDR test content.
Non-Destructive Verification Prior to Exploitation
Before moving on to the full RCE chain, the "check" subcommand of the public PoC was used to verify the target application's preconditions for the vulnerability. In this step, the WordPress version, REST batch endpoint access, and route confusion behavior were checked; because the shell subcommand was not executed, no operating-system-level command execution, creation of a new administrator account, or plugin webshell deployment was intended.
In the PoC output, WordPress 6.9.4 was marked as vulnerable, the /wp-json/batch/v1 endpoint was seen to be accessible unauthenticated, and the route confusion behavior was observed to be active. This check established the application-level foundation for the subsequent RCE tests.
Figure 3. In the public PoC check subcommand, WordPress 6.9.4 is identified as vulnerable, batch endpoint access is confirmed, and the route confusion behavior is verified.
End-to-End RCE with the Public PoC
In the first controlled test, the PoC was given only the id command. Nevertheless, before reaching the command execution stage, the tool completed the pre-authentication administrator creation and plugin webshell deployment operations.
In the PoC output, a new administrator account in the format wp2_<hex>, a plugin directory in the format wp2shell_<hex>, and the result uid=33(www-data) were observed. Comparing the WordPress users and plugins confirmed the new account and the webshell file. The webshell test artifact was created under wp-content/plugins by www-data.
Figure 4. On the attacker host terminal: creation of the pre-authentication administrator account, plugin webshell deployment, and execution of the id command with www-data privileges.
Auditd records and Falcon ProcessRollup2 events corroborated the same chain: the Apache worker process executed /usr/bin/dash, and dash in turn spawned the /usr/bin/id process. Both execve operations succeeded and the command output was returned to the attacker. Although no built-in detection or prevention fired for this specific PoC flow, Falcon provided the process ancestry, command line, and user context needed to investigate the event as telemetry log data.
Verifying the Chain with Operating System and Falcon Telemetry
Figure 5. Successful execve operations for /usr/bin/dash and /usr/bin/id in Linux Auditd records and the view of the webshell working directory.
While Auditd records confirmed process execution at the operating system level, Falcon telemetry centrally correlated the same events with parent-child relationships and command-line context.
Figure 6. Correlation of the apache2, dash, and id process chain via the ParentProcessId and TargetProcessId fields in CrowdStrike Advanced Event Search.
A more narrowly scoped query isolated the shell process launched directly by the web server, exposing the fundamental detection signal of RCE behavior.
Figure 7. In a query focused on web server child process behavior, the /usr/bin/dash process launched by apache2 and the sh -c -- id command line.
Why an Alarm May Not Fire Even When Telemetry Exists
From an EDR standpoint, id, whoami, curl, chmod, or dash are not malicious on their own. These tools are normal components of the Linux operating system and can be legitimately used in administrative, deployment, monitoring, or application workflows. The early stages of the WP2Shell test likewise proceeded within the WordPress, PHP, and MariaDB layers; the creation of a new administrator account did not directly produce any new Linux binary or known malware artifact.
For this reason, the real security signal is not the name of the binary but the process ancestry and context. Under normal conditions, an internet-facing Apache worker launching a shell interpreter and running utilities beneath that shell is high-value behavior with respect to web application RCE or webshell activity. The detection engineering effort aimed precisely at converting this telemetry into behavioral rules that distinguish it from the organization's normal workloads.
Controlled Post-Exploitation Behaviors
To evaluate Falcon visibility over a broader set of behaviors, the commands whoami, id, uname, useradd, getent, curl, chmod, sh, and cat were executed through the same webshell.
The "useradd" attempt failed due to www-data privileges, but the process was seen to have been executed and the corresponding command line was recorded in Falcon telemetry.
In the benign payload transfer test, a harmless shell script on the attacker host was downloaded to /tmp with curl, made executable with chmod, and launched with /bin/sh. In this chain, Falcon made apache2, dash, curl, chmod, and the second shell process visible; however, no built-in detection was produced for this controlled and benign content. The result shows that web server ancestry can be more meaningful than isolated binary reputation.
Figure 8. Discovery commands, the failed useradd attempt, the benign payload transfer, and execution of the downloaded script on the attacker host.
While the output on the attacker terminal showed that the commands were actually executed on the target, the process telemetry on the Falcon side revealed how these activities were chained together beneath the web server ancestry.
Figure 9. A broad view in CrowdStrike Advanced Event Search of the shell, discovery, account management, and file transfer processes executed through the webshell.
Following the broad telemetry view, the query was narrowed down to only the post-exploitation processes that are more meaningful from a security perspective.
Figure 10. The useradd, curl, chmod, dash, and cat processes in filtered Falcon telemetry focused on post-exploitation behaviors.
Verifying the Anti-Malware Channel with EICAR
To independently verify Falcon's response to known test content, the EICAR (European Institute for Computer Antivirus Research) file was written via curl to the path /tmp/eicar.com. Falcon produced an Informational severity detection named "EICARTestFileWrittenLin" and showed the systemd, apache2, dash, and curl chain in the process tree. Because the Actions taken field was None, writing of the test file was not blocked.
This result is not evidence of WP2Shell or webshell detection coverage. EICAR is used only to safely verify whether anti-malware products recognize known test content. EICAR standard: https://www.eicar.org/download-anti-malware-testfile/
Figure 11. Downloading of the EICAR test file from the attacker host to the path /tmp/eicar.com via curl, and verification that the file was created.
After the file was written to the target system, Falcon recognized the known EICAR test content and produced a separate built-in detection.
Figure 12. Informational severity detection named EICARTestFileWrittenLin in the Falcon Console and the systemd, apache2, dash, curl process chain.
PHP Webshell Visibility: Why the Second Test Triggered an Alarm
Falcon Linux and PHP Visibility Prerequisites
Before the PHP webshell test, it was verified that Filesystem visibility, Enhance PHP visibility, and On write script file visibility settings were enabled on the Linux Prevention Policy assigned to the target host.
Filesystem visibility allowed new file and script activities to become visible along with their context information, On write script file visibility enabled generation of script telemetry at the moment of writing, and Enhance PHP visibility made it possible to inspect content dynamically evaluated inside the PHP runtime through events such as PhpEvalString.
Figure 13. The enabled state of Filesystem visibility, Enhance PHP visibility, and On write script file visibility settings on the Linux Prevention Policy assigned to the test host.
These settings are important for interpreting the NewScriptWritten and PhpEvalString telemetry observed in the test below. Different sensor versions and policy configurations may produce a different event scope in the same test.
To test the built-in webshell visibility mechanism with a more overt behavior, a second PHP test file was prepared. This file Base64-decoded attacker-controlled POST data, executed it via eval, and ran the shell_exec("whoami") call inside the decoded content.
The PHP file was written directly to the WordPress uploads directory using curl through the web server process chain. Falcon showed with the NewScriptWritten event that the file was written and indicated the curl context as the writer process. Thanks to Enhance PHP visibility, the actual evaluated content became visible in the PhpEvalString event in the form echo shell_exec("whoami");. The Falcon Console additionally produced a High severity LinWebshell detection.
Figure 14. Writing of the PHP test webshell to the WordPress uploads directory on the attacker host and execution of shell_exec("whoami") with a POST request.
Following this invocation, Falcon made the behavior visible across complementary layers: PHP runtime content, new script writing, and built-in webshell detection.
Falcon PHP and Script Visibility
Figure 15. The echo shell_exec("whoami"); content evaluated in the Falcon PhpEvalString event becoming visible.
While the PhpEvalString event showed the executed dynamic PHP content, the stage at which the file was written to disk was separately recorded by NewScriptWritten telemetry.
Figure 16. The PHP file written by the curl process to the wp-content/uploads/2026/07 directory in the NewScriptWritten event.
As a result of evaluating the runtime and file-write signals together, a High severity detection named "LinWebshell" was generated in the Falcon Console.
Figure 17. High severity LinWebshell detection in the Falcon Console and the process tree of the curl process that wrote the webshell file.
When the detection process tree is examined, the file transfer performed via dash and curl under the web server processes can be clearly traced.
Figure 18. Execution details of the dash and curl processes running under apache2 in the process chain associated with the "LinWebshell" event.
Separating the Detection and Prevention Outcome
Although the "LinWebshell" event produced a High severity built-in detection, the Actions taken field in the Falcon Console was shown as None. The PHP file was written to the target directory, the POST request was processed, and the result of shell_exec("whoami") was returned to the attacker terminal as www-data. Therefore, in this test, runtime and file-write visibility as well as alert generation were confirmed, but no built-in prevention was applied for the corresponding behavior. This distinction shows that the generation of a detection does not mean that the same event is automatically blocked.
Difference Between the Original WP2Shell and a Classic Webshell
The webshell of the original public PoC is a small, plain PHP file. It was written under wp-content/plugins via the normal WordPress plugin upload mechanism, appeared similar to a legitimate plugin installation operation from WordPress's perspective, and did not use eval or Base64 decode.
In the second test, curl was executed through the web server process chain, the PHP file was written directly to the uploads directory, attacker-controlled data was Base64-decoded and executed with eval. The evaluated content additionally called shell_exec. The presence of PHP under WordPress uploads and the dynamic eval behavior formed a more classic and pronounced webshell pattern.
This difference does not mean that Falcon's webshell visibility feature does not work. On the contrary, the fact that "NewScriptWritten", "PhpEvalString", and "LinWebshell" detections were produced in the second test showed that the relevant components were active. The findings reveal that different webshell implementations can produce different telemetry and detection outcomes.
Detection Engineering: Falcon Custom IOA Rule Set
The telemetry obtained throughout the tests was used to develop behavioral rules not tied only to the WP2Shell naming. In particular, the first two rules focus on parent-child process relationships that can also be applied in general Linux web application RCE and webshell scenarios.
⚠ Warning: These rules were validated in the isolated InfinitumIT test environment with a limited amount of live data. They should not be applied directly to production environments with Process Kill or any other prevention action. They should first be run in Monitor or Detect mode on test host groups; normal deployment, maintenance, backup, monitoring, and plugin update behaviors should be observed; and required false-positive tuning and narrowly scoped exclusion work should be completed. Blocking should be enabled only gradually, after a limited pilot, change management approval, and a rollback plan.
Common IOA Fields Used During Testing
In the initial validation phase of the rules, only the fields defining the behavior were narrowed down; the other fields were kept broad due to possible telemetry differences. In the Process Creation rules, the Grandparent Command Line, Parent Command Line, and Command Line fields that were not used were set to .*. In the File Creation rules, the Grandparent Image Filename, Grandparent Command Line, Parent Image Filename, Parent Command Line, Image Filename, and Command Line fields were left as .*; and Select All was used for the File Type selection. This structure was applied to verify matching within the test scope; after production tuning, the process, command line, file type, and host scope fields should be narrowed down.
INFNT-IOA-0001 - Web Server Spawning Shell Interpreter
The purpose of this rule is to detect Apache, Nginx, HTTPD, or PHP worker processes launching sh, dash, bash, and similar shell interpreters, and to block them in suitable environments. The rule is not specific to WP2Shell; the same behavior can be observed in PHP webshells, CMS compromises, and general Linux web application RCE cases.
In the Detect mode test, the dash process spawned under apache2 generated a Critical Custom IOA detection. After switching to Process Kill mode and the new action reaching the endpoint, the repeated run terminated the dash process and no command result was returned to the attacker terminal. The Actions taken: Process killed information in the Falcon Console confirmed the prevention outcome.
Detect and Process Kill Verification
Figure 19. In the Detect mode verification of the INFNT-IOA-0001 rule, the Critical Custom IOA detection generated for the dash process that started under apache2.
After the rule produced an alert on the correct process lineage in Detect mode, the action was changed to Process Kill and the same behavior was re-executed.
Figure 20. Running the same command twice on the attacker host: output being received in the first attempt, and no command result being returned in the attempt after the Process Kill action reached the endpoint.
The output difference on the attacker side showed that after the new action was applied to the endpoint, the shell process was terminated before it could execute.
Figure 21. The Process killed result shown in the Actions taken field for INFNT-IOA-0001 in the Falcon Console.
INFNT-IOA-0002 - Web Shell Spawning Post-Exploitation Utility
The second rule detects the execution of utilities such as curl, wget, chmod, useradd, Python, netcat, or systemctl under a shell launched by the web server. Payload transfer, permission changes, account creation attempts, script execution, and use of tools for persistence purposes all fall within the scope of this behavioral pattern.
In the benign payload test, the curl and chmod processes running under dash generated separate Custom IOA detections. Because this rule contains a broader binary list than the first rule, it requires a longer baseline and false-positive tuning process before production.
Figure 22. Terminal output of the benign payload download and execution commands on the attacker host and of the tests writing a PHP file to the WordPress uploads directory.
Because the curl and chmod operations in the command chain are spawned as separate child processes, they were recorded as independent detections by INFNT-IOA-0002.
Figure 23. The INFNT-IOA-0002 rule detecting the /usr/bin/chmod 700 /tmp/ioa-benign.sh command as a Critical Custom IOA.
Within the same parent-child context, the curl process was also independently matched as payload transfer behavior.
Figure 24. The INFNT-IOA-0002 rule detecting the benign script download behavior via curl under the web server and shell ancestry.
INFNT-IOA-0003 - PHP File Created in WordPress Uploads
The WordPress uploads directory normally hosts media and documents. Writing a PHP file to this directory is highly suspicious behavior in most WordPress architectures. The following path pattern was monitored using the File Creation rule type.
In the validation test, uploads/ioa-validation/infnt-validation.php was created with curl and the rule produced a Critical Custom IOA detection. On dedicated WordPress servers this rule can be a high-confidence signal; nevertheless, specific deployment and application behaviors should be baselined.
Figure 25. Writing of the infnt-validation.php file to the wp-content/uploads/ioa-validation directory on the attacker host and verification of the file permissions.
Once the file was created in the target directory, the Falcon File Creation Custom IOA mechanism produced a match via the path pattern.
Figure 26. The Critical detection produced by the INFNT-IOA-0003 rule for the PHP file creation behavior in the WordPress uploads directory.
INFNT-IOA-0004 - WP2Shell Public PoC Plugin Webshell Creation
This rule targets the wp2shell_<8 hex> directory and filename naming pattern of the public PoC. It has a low false-positive potential; however, since it can easily be bypassed by an attacker changing the file or directory name, it does not replace behavioral rules.
The regex and File Creation behavior of the rule were validated directly through a curl file-write test, and a Custom IOA detection was produced. Because it was not additionally verified whether the same File Creation event occurs during the real plugin ZIP upload and extraction phase of the public PoC, the rule should be regarded as an auxiliary, PoC-specific coverage layer.
Validation of PoC-Specific and General Plugin Directory Rules
Figure 27. The INFNT-IOA-0004 rule detecting the PHP file creation behavior matching the wp2shell_a1b2c3d4 directory and filename pattern.
The same file-write behavior was evaluated not only by the narrow rule tied to the PoC naming, but also by the more general rule covering the plugin and theme directories.
INFNT-IOA-0005 - PHP File Created in WordPress Plugin or Theme Directory
The fifth rule monitors general PHP writes to WordPress plugin or theme directories. It can cover different webshell and malicious plugin/theme scenarios; however, it has a high likelihood of producing false positives during legitimate plugin installations, updates, and deployments.
In the direct-write validation test, the general path rule also successfully produced a detection. In a production environment, this rule is not suitable for Process Kill by default; it should be used in Monitor or Detect mode, with a narrow host scope and well-defined maintenance behaviors.
Figure 28. The detection produced by the INFNT-IOA-0005 rule for the general PHP file creation behavior in the WordPress plugins directory.
From Detect to Process Kill: The Real Limits of Prevention
INFNT-IOA-0001 in Process Kill mode successfully terminated the dash process and prevented the operating system command result from being returned to the attacker. However, the PoC output shows that the administrator account and the plugin webshell can be created before the shell process starts. For this reason, process termination does not automatically roll back application-level compromise artifacts.
Even after a successful prevention outcome, new administrator accounts, PHP files under wp-content, Apache access logs, and database changes should be examined. An endpoint rule can stop a critical stage of the attack chain; however, incident response must cover the application, database, and endpoint layers together.
Comparative Summary of Test Results
The various tests showed that the telemetry, built-in detection, and Custom IOA layers of Falcon play different roles in the same attack chain. The following table summarizes the primary results observed in the tests in a single view.
Table 1. Comparison of the telemetry, detection, and prevention outcomes observed in the WP2Shell and Custom IOA tests.
Beyond WP2Shell — Linux Web Application RCE Coverage
Although this study was carried out on WP2Shell, INFNT-IOA-0001 and INFNT-IOA-0002 are not tied to WordPress or the public PoC naming. A web server launching a shell interpreter and running post-exploitation utilities under that shell are common behaviors that can arise in different CMS products, PHP frameworks, internet-facing services, and various Linux web application RCE scenarios.
INFNT-IOA-0003 and INFNT-IOA-0005, on the other hand, depend on the WordPress directory structure. INFNT-IOA-0004 is a narrow rule focused solely on the naming pattern of the public PoC. This distinction allows signature-like PoC indicators and more resilient behavioral detections to be positioned within the same rule set for different purposes.
Layered Defense: WAF, Patching and Endpoint Controls
This test was carried out only at the EDR level. In real production environments, a properly configured WAF can block an attacker's REST API and batch endpoint requests before they reach the application layer. Rapid upgrading to a secure WordPress version, attack surface reduction, secure plugin management, reverse proxy controls, and application log monitoring are layers that either prevent the attack from reaching the endpoint or make it visible earlier.
CrowdStrike Falcon is not an alternative to these controls, but a complementary endpoint visibility and prevention layer. Falcon's process ancestry, file creation, and PHP visibility telemetry — when correlated with WAF logs, Apache access logs, and WordPress artifacts — provides a stronger incident investigation and containment capability.
The Role of MDR and Continuous Threat Hunting
Activities that do not produce a built-in detection but are present as telemetry can be surfaced through continuous threat hunting work carried out under the MDR service. A web server launching a shell, a payload being downloaded within the web process context, PHP being written to WordPress directories, or the web server user running post-exploitation utilities can all be examined through periodic hunting queries.
In this process, suspicious behaviors within the telemetry are identified first. Verified behaviors are converted into detection engineering use cases and validated in Monitor or Detect mode on test host groups. Then false-positive tuning and operational scoping are completed. Once a sufficient confidence level is achieved, controlled prevention is applied and the rule's performance is reviewed regularly. In this way, the MDR service does not merely manage existing alarms but also produces new detection coverage from the telemetry on the platform.
Recommendations for the WP2Shell Case
• WordPress should be upgraded to a secure and supported version across all production and staging instances.
• On the WAF or reverse proxy, REST batch API and unusual plugin upload requests should be monitored, and unnecessary access should be restricted.
• New or unexpected administrator accounts, especially names similar to wp2_<hex>, should be investigated regularly.
• New PHP files and integrity changes under wp-content/plugins, wp-content/uploads, and wp-content/themes should be examined.
• Falcon process tree, NewScriptWritten, and PhpEvalString telemetry should be correlated by time with Apache access logs.
• Custom IOA rules should first be tested in Monitor or Detect mode, with a narrow host scope and over a sufficient baseline period.
• Even after Process Kill, application-level artifacts should be removed, and credentials and WordPress secrets should be rotated according to the risk level.
• If server integrity cannot be reliably verified, the system should be rebuilt from a clean and up-to-date image.
Conclusion
The WP2Shell case study has shown that strong endpoint telemetry does not guarantee the same built-in detection or prevention outcome for every web application exploit implementation. In the first public PoC test, Falcon Sensor made the process ancestry and command-line context fully visible, while in the more pronounced eval and Base64-based webshell test it produced NewScriptWritten, PhpEvalString, and High severity LinWebshell detections.
Through the detection engineering effort, organization-focused coverage was developed for a web server launching a shell interpreter, running post-exploitation utilities under that shell, and PHP being written to WordPress directories. INFNT-IOA-0001 was tested in Process Kill mode and stopped the OS command execution stage. However, the fact that artifacts such as the attacker account and the plugin webshell can be created earlier makes it necessary to consider endpoint prevention together with WAF, patching, application monitoring, and incident response processes.
The most important operational takeaway of this study is that suspicious behaviors residing within telemetry can be discovered through continuous threat hunting, converted into rules through detection engineering, and should only be moved to the prevention layer after a controlled Monitor, Detect, and tuning process.
Disclaimer: This document is intended solely for informational and defensive purposes. Rules may produce different results depending on the product version, sensor policy, application architecture, and normal workload. Before applying them in a production environment, controlled testing, false-positive tuning, change management, and a rollback plan are required. The content describes only tests conducted in the author's isolated lab environment.
© 2026 INFINITUMIT · InfinitumIT MDR - Detection Engineering & Threat Hunting
Hakan AKSUNGUR — L2 MDR Analyst
InfinitumIT MDR — Detection Engineering & Threat Hunting
This article is based on the results of controlled tests conducted in an isolated CrowdStrike Falcon test environment belonging to InfinitumIT. The IOA expressions and test scenarios presented are illustrative in nature.
