From Dangerous PHP Functions to Webshell Hunting

What it is

A DFIR walkthrough of PHP command-execution functions that survive a naive disable_functions hardening, and the detection artifacts they leave. It names the concrete bypass functions, shows working PoC webshells, and dissects the fallback logic in p0wny-shell and the on-disk obfuscation of weevely.

How it works

The default disable_functions shipped in the shown php.ini (/etc/php/8.0/apache2/php.ini) blocks only the pcntl_* family — it does not block popen, proc_open, passthru, or preg_replace. So a shell can still fork a command via popen($_REQUEST['code'],'r') or a proc_open reverse shell. p0wny-shell probes each method in order and uses the first available one, so blocking a subset is worthless:

flowchart TD
    A[executeCommand] --> B{exec?}
    B -->|no| C{shell_exec?}
    C -->|no| D{system + ob_*?}
    D -->|no| E{passthru + ob_*?}
    E -->|no| F{popen/feof/fread/pclose?}
    F -->|no| G{proc_open/stream_get_contents?}
    B & C & D & E & F & G -->|yes| H[run command]

To block execution you must disable the entire chain, not just exec/system/shell_exec.

What to do

Extend disable_functions to cover the fallback set, e.g. beyond the obvious three, add popen, proc_open, passthru, pcntl_exec, and preg_replace. The HackTricks reference the post cites is the source for the fuller (still "possibly not exhaustive") list.

For hunting, the post argues Yara rules are weak against webshells and points instead at: manual analysis, frequency analysis of web-server logs (rarely-hit endpoints), and collection with Velociraptor and UAC.

A concrete weevely signature: the generated agent.php is a phar loader whose readable header is hex/octal-escaped and truncated by __HALT_COMPILER, e.g.

<?php include "\160\x68\141\x72\72\57\57".basename(__FILE__)."\57\x78";__HALT_COMPILER(); ?>

That \160\x68\141\x72\72\57\57 decodes to phar:// — grepping for escaped phar:// plus __HALT_COMPILER in .php files is a usable hunt.

Caveats

The post itself flags that its bypass list is "possibly not exhaustive," so a disable-list approach is inherently incomplete — treat it as defense-in-depth, not a boundary. It also notes preg_replace reaches code execution indirectly (via the deprecated /e modifier calling system()), so its presence in the list is conditional on legacy PHP behavior.