Threat actors are increasingly abusing HTTP cookies as a control channel for PHP-based webshells on Linux servers. Instead of exposing command execution through URL parameters or request bodies, these webshells rely on threat actor-supplied cookie values to gate execution, pass instructions, and activate malicious functionality.
This approach reduces visibility by allowing malicious code to remain dormant during normal application behavior and execute only when specific cookie conditions are met. This technique has been observed across multiple execution contexts, including web requests, scheduled tasks, and trusted background workers.
The consistent use of cookies as a control mechanism suggests reuse of established webshell tradecraft. By shifting control logic into cookies, threat actors enable persistent post-compromise access that can evade many traditional inspection and logging controls.
Across the activity analyzed, HTTP cookies acted as the primary trigger for malicious execution. Instead of exposing functionality through visible URL parameters or request bodies, the webshell logic remained dormant unless specific cookie values were present. Only when those conditions were satisfied did the script reconstruct and execute threat actor–controlled behavior.
Threat actors likely prefer this approach because cookies blend into normal web traffic and often receive less scrutiny than request paths or payloads. In PHP, cookie values are immediately available at runtime, for example through the $_COOKIE superglobal, allowing malicious code to consume attacker-supplied input without additional parsing. By shifting execution control into cookies, the webshell can remain hidden in normal traffic, activating only during deliberate interactions. This reduces routine logging and inspection visibility while enabling persistent access without frequent changes to files on disk.
Although the core technique remained consistent across incidents, the PHP implementations varied in structure and complexity. The following examples illustrate how attackers adapted the same cookie-controlled execution model across different environments.
One observed implementation introduced an additional execution gate before processing any cookie input. The loader first evaluated request context and reconstructed core PHP functions dynamically using arithmetic operations and string manipulation. Sensitive function names were intentionally absent in cleartext, significantly reducing obvious indicators and complicating pattern-based detection.
After the initial base64 decoding, the PHP script did not immediately reveal obvious command functionality. Instead, it exposed a second, deliberate layer of obfuscation. Critical operations were rebuilt programmatically at runtime, with function names and execution logic assembled character-by-character. This design ensured that meaningful behavior remained concealed until execution conditions were satisfied.
Only after these runtime checks passed did the script begin parsing structured cookie input. Cookie values were segmented and transformed into function identifiers, file paths, and decoding routines. If a secondary payload was not already present, the loader reconstructed it from encoded data, wrote it to a dynamically determined location, and transferred execution using ‘include’.
This layered approach separated deployment, obfuscation, and activation into distinct stages. Under routine traffic, the file appeared inert. When supplied with deliberate attacker-controlled input, however, it transitioned into a fully functional execution framework.
Another observed implementation relied on structured cookie data without extensive preliminary gating. The script segmented cookie input to reconstruct operational components such as file handling and decoding functions. As with the previous loader, it conditionally wrote a secondary payload to disk and executed it if absent.
Although simpler in structure, this variant achieved the same objective: staged deployment and execution controlled by cookie values rather than visible request parameters.
A streamlined variant was also observed in which a single cookie value acts as an execution key. When the expected cookie condition is met, the script enables threat actor–controlled actions, including direct execution of supplied input and, in some cases, file upload. Unlike staged loader chains, this implementation operates within a single script and does not rely on a separate secondary payload written to disk.
In this design, cookies primarily serve as a validation mechanism rather than a payload container.
During incident investigation, we analyzed a compromise in which the threat actor prioritized durable, low-noise persistence within a hosted Linux environment. After obtaining access to the victim’s hosting account, the threat actor used the platform’s legitimate management interface, such as a control panel workflow, to register a cron job. In environments that provide restricted shell access, for example via /usr/local/cpanel/bin/jailshell, authenticated users can execute commands within their account boundary, including registering or launching scheduled tasks. Because these actions follow normal administrative paths, they appear as routine account-level operations rather than overt system modifications.
In shared hosting scenarios, this level of access is typically equivalent to user-level control within the account’s isolated environment. While it does not indicate root-level compromise or control of the underlying server, it provides sufficient capability to modify web content, deploy PHP scripts, and schedule recurring execution through cron. These permissions are often enough to convert temporary access into persistent remote code execution within the hosted account.
As illustrated in the diagram, the cron job executed at regular intervals and invoked a shell routine that reconstructed an obfuscated PHP loader into a web-accessible location. This behavior was intentionally implemented to maintain persistence. If the loader was removed, the scheduled task recreated it on the next execution cycle. The job also applied restrictive file permissions, making manual modification or removal more difficult during incident response.
This “self-healing” mechanism, controlled by the threat actor, allowed the malicious file to reappear after cleanup attempts, complicating remediation and enabling a more stable foothold within the affected hosting account.
Once deployed, the PHP loader followed the same low-visibility pattern described earlier. It remained inactive during normal traffic and activated only when specific cookie conditions were met. On activation, it dynamically rebuilt functionality at runtime and transferred execution to threat actor–controlled logic. By separating persistence through cron-based re-creation from execution control through cookie-gated activation, the threat actor reduced operational noise and limited observable indicators in routine application logs.
Across the activity analyzed, a consistent operational pattern emerged. While individual implementations varied in structure, each relied on multi-layer obfuscation to conceal sensitive functionality and cookie-gated execution to control activation. Under routine traffic conditions, the scripts remained dormant. Only when specific cookie values were supplied did the malicious logic reconstruct and execute. Whether deployed as a staged loader or an interactive webshell, the objective remained consistent: controlled activation with minimal observable footprint.
The delivery mechanism followed a similarly deliberate design. In multiple environments, web-facing processes such as php-fpm spawned shell commands that reconstructed obfuscated PHP files using the recognizable echo | base64 -d > file.php pattern. In other cases, equivalent commands were executed within restricted shell environments, such as through cPanel jailshell, or established via scheduled tasks at the hosting account level.
Rather than relying on complex exploit chains, the threat actor leveraged legitimate execution paths already present in the environment, including web server processes, control panel components, and cron infrastructure, to stage and preserve malicious code. The repeated use of base64 reconstruction combined with multi-layer runtime obfuscation separated deployment, concealment, and activation into distinct phases. This layered design allowed the malicious code to blend into normal operational activity while maintaining reliable remote code execution.
In the attacks analyzed, persistence was deliberate, not incidental. Rather than depending on a single exploit or a short-lived foothold, the threat actor turned initial access into a repeatable mechanism for remote code execution (RCE). By combining scheduled tasks with obfuscated PHP loaders, they preserved the ability to execute code even after the original entry point was remediated or access paths were disrupted.
Persistent RCE provides long-term flexibility. It allows threat actors to return on demand to run additional commands, deploy follow-on payloads, alter application behavior, or pivot to other resources without repeatedly re-triggering the same exploit chain. This reduces operational risk and can limit the number of noisy intrusion attempts that might otherwise raise alerts.
In shared hosting environments, account-level access is often sufficient to create scheduled tasks, modify web content, and run arbitrary PHP within the affected site’s boundaries. When execution is further protected behind cookie-gated activation, the malicious logic can remain dormant during routine activity and activate only when the threat actor supplies the correct input. Over time, this durable access can support data theft, expansion to adjacent applications, or compromise of connected services, often with minimal visible disruption.
Microsoft recommends the following mitigations to reduce the impact of PHP webshell–based compromises discussed in this report. These recommendations build on established guidance from previous Microsoft Defender research and align with protections available across Microsoft Defender XDR to help organizations prevent, detect, and respond to post-compromise web shell activity targeting web servers and application workloads.
Strengthen Hosting Account Security
Enforce multi-factor authentication for hosting control panels, SSH access, and administrative interfaces. Monitor for unusual login activity, particularly from unfamiliar IP addresses or geographies, as compromised account credentials are often sufficient to deploy webshells and create persistence mechanisms.
Restrict Web Server Process Execution
Limit the ability of web‑facing services such as php‑fpm or application worker workloads to spawn shell processes. Restrict the execution of shell interpreters (sh, bash, dash) and commonly abused encoding or file ingress utilities such as base64, curl, and wget from web server execution contexts unless they are explicitly required by the application.
Advanced Hunting can be used to surface cases where web server workloads spawn shell interpreters or execute encoded or file‑retrieval commands, as these patterns provide high‑signal indicators of webshell execution and command injection attempts.
Audit and Monitor Scheduled Tasks
Regularly review account‑level cron jobs and scheduled tasks across web servers and application hosts. Unexpected entries that invoke shell commands or write files into web‑accessible directories may indicate persistence mechanisms used to deploy, restore, or re‑activate malicious webshell loaders.
Advanced Hunting can be used to identify cron‑initiated execution patterns, including unusually short execution intervals (for example, recurring one‑minute jobs) and command lines associated with file creation, script execution, encoding utilities, or file ingress tools. These behaviours are commonly observed during web shell persistence and recovery activity following initial compromise
Inspect Suspicious File Creation in Web Directories
Focus on suspicious content deployment into web directories by monitoring the command‑line techniques used to write or retrieve files, rather than relying on file creation telemetry alone. Attackers frequently deploy PHP web shells by decoding obfuscated payloads inline (for example, using echo piped to base64 -d with output redirection) or by downloading scripts via file ingress tools such as curl or wget from web server or application execution contexts.
Advanced Hunting can be used to identify these behaviors by querying process execution events for decoding pipelines, redirection operators, or network retrieval utilities associated with web-facing workloads, providing high‑signal visibility into webshell deployment activity.
Limit Control Panel Shell Capabilities
Where hosting control panels are used, restrict or disable shell access such as jailshell wherever possible. If shell access is required, enforce strict access controls and closely monitor command execution to reduce the risk of attackers abusing these environments to deploy or interact with malicious PHP loaders and webshells.
Advanced hunting queries that track command execution from control panel restricted shells can help identify abuse patterns in which attackers leverage legitimate hosting features to maintain access or execute post-compromise tooling.
Microsoft recommends the following mitigations to reduce the impact of this threat in Linux environments protected by Microsoft Defender for Endpoint:
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence. Security teams can leverage Copilot to assist with the analysis and interpretation of obfuscated or heavily encoded scripts, helping accelerate triage and improve understanding of attacker tradecraft during web shell and post-compromise investigations.
| Tactic | Observed activity | Microsoft Defender coverage |
| Initial Access, Execution, Defense Evasion | An obfuscated or encoded script is executed by the cron service, indicating suspicious scheduled execution activity potentially used to bypass direct user interaction and evade detection. | Microsoft Defender for Endpoint Suspicious script launched, Suspicious shell command execution Suspicious file and directory permission modification |
| Execution Persistence | A new cron job is created by a hosting control panel process (such as cPanel), to establish persistence by scheduling recurring execution of attacker-controlled commands or scripts without further user interaction. | Microsoft Defender for Endpoint Suspicious cron job Suspicious execution of elevated process |
| Persistence | A PHP file (for example, index.php) is dropped or modified in a web-accessible directory, suggesting the deployment of a server-side script that may be used to execute arbitrary commands or maintain long-term access to the web server | Microsoft Defender for Endpoint Possible Web Server compromise activity |
| Persistence | A PHP webshell file (such as index.php) is written to disk and identified as active malware, indicating confirmation of server-side backdoor deployment intended for remote command execution via HTTP requests. | Microsoft Defender Antivirus An active ‘Webshell’ malware was blocked ‘WebShell’ malware was prevented An active ‘Obfuse’ malware was blocked |
Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:
Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.
Web Server Spawning Shell
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("php-fpm", "httpd", "apache2", "nginx")
| where FileName in~ ("bash", "sh", "dash")
| project Timestamp, DeviceName, AccountName,
InitiatingProcessFileName, InitiatingProcessCommandLine,
FileName, ProcessCommandLine, FolderPath
| order by Timestamp desc
Base64 Decode Writing PHP File
DeviceProcessEvents
| where FileName in~ ("bash", "sh", "dash", "jailshell")
| where ProcessCommandLine has "base64"
| where ProcessCommandLine has ".php"
| project Timestamp, DeviceName, AccountName,
ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp desc
tee Writing PHP Files
DeviceProcessEvents
| where ProcessCommandLine has "tee"
| where ProcessCommandLine has ".php"
| project Timestamp, DeviceName, AccountName,
InitiatingProcessFileName,
ProcessCommandLine
| order by Timestamp desc
cPanel / jailshell Abuse
DeviceProcessEvents
| where FileName in~ ("jailshell", "cpanel")
| project Timestamp, DeviceName, AccountName,
FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
High-Risk Combined Pattern
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("php-fpm", "httpd", "apache2", "nginx", "cron", "crond")
| where ProcessCommandLine has "base64"
| where ProcessCommandLine has_any (".php", "public_html", "vendor")
| project Timestamp, DeviceName, AccountName,
InitiatingProcessFileName,
ProcessCommandLine
| order by Timestamp desc
Unexpected Shell from Backend Workers
DeviceProcessEvents
| where InitiatingProcessCommandLine has_any ("artisan", "queue:work", "fwconsole")
| where FileName in~ ("bash", "sh", "dash")
| project Timestamp, DeviceName,
InitiatingProcessCommandLine,
ProcessCommandLine
| order by Timestamp desc
Repeated Execution Pattern (1-Minute Cron)
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("cron", "crond")
| summarize count() by DeviceName, ProcessCommandLine, bin(Timestamp, 1m)
| where count_ > 10
| order by count_ desc
This campaign exhibited the following MITRE ATT&CK™ techniques across multiple tactics. For detailed detection and prevention capabilities, see the Microsoft Defender XDR Detections section below.
| Tactic | Technique ID | Technique Name | How it Presents in This Campaign |
| Initial Access | T1190 | Exploit Public-Facing Application | Attackers gain access through exposed web applications or hosting environments and use that access to introduce server-side tooling that blends into the web stack. |
| Persistence | T1505.003 | Server Software Component: Web Shell | A PHP webshell is placed in a web-accessible location and designed to remain dormant during normal traffic, enabling long-term access through web requests. |
| Defense Evasion | T1027 | Obfuscated/Encrypted File or Information | Payloads and scripts are obfuscated or encoded (for example, high-entropy strings and base64-encoded blobs) to reduce inspection and evade simple content-based detections. |
| Defense Evasion | T1140 | Deobfuscate/Decode Files or Information | Attackers decode inline payloads at runtime, such as echo <blob> | base64 -d > <file> to reconstruct PHP content on disk with minimal interactive footprint. |
| Command and Control | T1105 | Ingress Tool Transfer | Additional files or second-stage scripts are retrieved using file ingress utilities such as curl or wget, often writing directly into web directories or application paths. |
| Execution | T1059.004 | Command and Scripting Interpreter: Unix Shell | Web-facing workloads (for example, php-fpm, apache2, nginx) spawn shell interpreters (sh, bash, dash) to execute attacker-provided commands from webshell logic or injected requests. |
| Persistence | T1053.003 | Scheduled Task/Job: Cron | Persistence is established via cron, including jobs created by hosting tooling (for example, cPanel) and recurring execution patterns (including short intervals such as one-minute loops). |
| Defense Evasion | T1222.002 | File and Directory Permissions Modification | File or directory permissions are modified to enable write/execute access in web paths or to ensure persistence artifacts remain accessible to the compromised runtime context. |
This research is provided by Microsoft Defender Security Research with contributions from Yashashree Gund and other members of Microsoft Threat Intelligence.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps
Explore how to build and customize agents with Copilot Studio Agent Builder
Microsoft 365 Copilot AI security documentation
How Microsoft discovers and mitigates evolving attacks against AI guardrails
Learn more about securing Copilot Studio agents with Microsoft Defender
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。