PHP Webshells on Linux: Cookie-Controlled Evasion

Introduction

Microsoft has published new research on a stealthy PHP webshell technique affecting Linux hosting environments. Instead of using obvious URL parameters or request bodies, attackers are using HTTP cookies as the trigger and control channel for malicious execution, making these webshells harder to spot in normal web traffic and application logs.

For security teams and administrators managing Linux-hosted web apps, this matters because the technique enables low-noise persistence, delayed activation, and more evasive post-compromise access.

What’s new

Microsoft observed multiple PHP webshell variants that all rely on cookie-gated execution:

• Cookie-controlled activation: The webshell stays inactive unless the attacker sends specific cookie values.
• Layered obfuscation: Some variants dynamically rebuild PHP functions and execution logic at runtime to avoid static detection.
• Payload staging: Several samples reconstruct and write secondary payloads to disk only when the required cookie conditions are met.
• Interactive webshell behavior: Simpler versions use a single cookie as a key to enable command execution or file upload.
• Cron-based persistence: In one investigated case, attackers used legitimate hosting control panel workflows to register scheduled tasks that recreated the malicious PHP loader if it was removed.

Why this is harder to detect

Cookies often receive less scrutiny than request paths, query strings, or POST bodies. In PHP, cookie values are directly accessible through $_COOKIE, which makes them a convenient input channel for attackers. Combined with obfuscation and staged payload deployment, this allows malicious files to appear inert during normal traffic and activate only during deliberate attacker interactions.

Impact on administrators and defenders

For IT and security administrators, the key risk is persistent remote code execution within a compromised hosting account, even without root-level access. In shared hosting or restricted shell environments, attackers may still have enough permissions to:

• Modify web content
• Deploy PHP loaders
• Recreate deleted malware through cron jobs
• Maintain long-term access with minimal logging footprint

This can complicate remediation, especially when a “self-healing” scheduled task restores the webshell after cleanup.

Recommended next steps

Administrators should review Microsoft’s guidance and prioritize these actions:

• Audit PHP applications and web roots for suspicious obfuscated scripts
• Review scheduled tasks and cron jobs for unauthorized persistence mechanisms
• Monitor cookie patterns associated with unusual server-side execution
• Enable and investigate Microsoft Defender XDR detections and threat analytics
• Hunt for web-accessible PHP files that write or include secondary payloads
• Tighten file integrity monitoring and permissions in Linux hosting environments

Organizations running internet-facing PHP workloads should also ensure incident response playbooks include cron persistence checks, cookie-based webshell hunting, and follow-up validation after cleanup.