Cookie-Controlled PHP Web Shells: Stealth Tradecraft on Linux Hosts

Summary

Threat actors are abusing HTTP cookies as a covert “activation key” for PHP web shells on Linux hosting servers. The implants remain inert until a specific cookie value is supplied, then decode and execute attacker-provided payloads. This approach helps reduce obvious indicators in routine logs while enabling persistent remote code execution. Common supporting tradecraft includes layered obfuscation, cron-based self-healing, and living-off-the-land use of standard server utilities.

Investigation

Researchers reviewed multiple compromised hosting accounts and found PHP loaders that only reconstruct capability from Base64-encoded blobs when the trigger cookie is present. Persistence was maintained through cron jobs created via hosting control panels (such as cPanel) that periodically restore the web shell if it is removed. Execution commonly flowed through php-fpm and other web workers, which spawned shell interpreters and fetched secondary payloads to extend access.

Mitigation

Require MFA for hosting control panels and administrative access paths. Constrain web-server processes so they cannot spawn shells or invoke common staging utilities like base64, curl, or wget. Monitor cron creation and modifications closely, and alert on unexpected file writes or changes within web directories. Additional hardening includes restricting jail shell access and enabling real-time endpoint protections on Linux servers.

Response

If identified, isolate the host, disable and remove malicious cron entries, delete suspicious PHP artifacts, and rotate credentials for affected hosting accounts. Preserve and review evidence, including trigger cookie values and associated command lines, then apply hardening controls to prevent re-deployment and repeat compromise.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic. Abstract or unrelated examples will lead to misdiagnosis.

• Attack Narrative & Commands:
  An attacker who has already compromised the web server obtains a malicious PHP webshell (malicious.php). To activate it, the attacker issues an HTTP request that injects a crafted cookie. The web server’s PHP handler interprets the cookie and spawns a Bash process that executes the webshell file. For testing, we simulate the same effect locally by manually invoking Bash with a command line that includes “.php”. This produces the exact telemetry the Sigma rule monitors (shell interpreter + “.php” in the command line).

  1. Create a dummy PHP webshell (no harmful code, just a harmless phpinfo() for visibility).
  2. Execute the webshell via Bash, embedding the .php filename in the command line.
  3. Verify that the process creation event appears in audit logs with the expected fields.

• Regression Test Script:

  #!/usr/bin/env bash
  set -euo pipefail
  
  # 1. Deploy a harmless PHP file (simulated webshell)
  WEBROOT="/tmp/webshell_test"
  mkdir -p "$WEBROOT"
  cat > "$WEBROOT/malicious.php" <<'EOF'
  <?php
  // Simulated webshell – safe payload
  echo "Webshell executed at " . date('c') . "n";
  ?>
  EOF
  
  # 2. Trigger execution via a Bash interpreter (command line contains ".php")
  echo "[*] Executing webshell via Bash to generate detection telemetry..."
  /bin/bash -c "php $WEBROOT/malicious.php"
  
  # 3. Pause briefly to allow auditd to flush logs
  sleep 2
  
  echo "[*] Simulation complete. Review SIEM for a match on:"
  echo "    process.name in (bash, sh, dash, jailshell) AND process.command_line contains '.php'"

• Cleanup Commands:

  #!/usr/bin/env bash
  set -euo pipefail
  
  WEBROOT="/tmp/webshell_test"
  
  echo "[*] Removing test webshell directory..."
  rm -rf "$WEBROOT"
  
  echo "[*] Cleanup complete."