Hunting Web Backdoors

Hunting Web Backdoors

This is not a vulnerability audit. You are looking for code an attacker already planted — a webshell, a one-line eval backdoor, a fake plugin, a malicious line appended to a legitimate file. The weakness that let them in is auditing-php-applications' job; this skill finds what they left behind.

Two things make it hard. The malicious code is deliberately hidden — obfuscated, split, or buried in a tree of thousands of legitimate files — so a naive grep misses it. And the tells (eval, base64_decode, dynamic calls) appear in plenty of benign code, so a naive grep also drowns you in false positives. The work is the discrimination.

When to Use

• A web server is suspected or confirmed compromised and you need every shell
• Cleaning a hacked WordPress, Magento, Joomla, or custom PHP site
• Vetting a downloaded plugin, theme, or codebase before deploying it
• A file contains eval, assert, or system on decoded or request-derived input
• Triaging a web root full of unfamiliar PHP for planted malice

When NOT to Use

• Finding the vulnerability that allowed the upload — use auditing-php-applications
• Deep single-sample analysis (a specific shell you want to fully reverse, its C2, its capabilities) — use analyzing-malware
• The broader incident (scoping, timeline, containment) — use responding-to-incidents; this skill is the source-tree sweep within it
• Malicious dependencies / package install scripts — use auditing-supply-chain
• Host-level persistence (cron, systemd, LD_PRELOAD) — use analyzing-linux-persistence

Never Execute to Deobfuscate

The single rule that must not bend: the obfuscated code is the payload. Do not run it, do not "just let PHP decode it," do not replace eval( with echo( and execute the file, do not paste it into an online sandbox that runs it. Deobfuscation is a static transformation:

• Decode the layers by hand or with a decode-only tool (base64_decode, gzinflate, gzuncompress, str_rot13, hex/\xNN, strrev) applied as string operations, not as executed PHP.
• If you must automate, use a de-obfuscator that decodes without executing (UnPHP's decoder, a Python reimplementation of the decode chain) — never the PHP interpreter on the sample.
• Replacing the final eval( with file_put_contents('out.php', ...) and running it is executing the payload if any prior layer has side effects. Decode statically, then read.

"Most webshells are three or four layers of encoding around ten lines of logic" — peel to the logic, do not detonate the wrapper.

Triage a Directory at Scale

You cannot read every file. Rank candidates by cheap signals, then read the top of the list:

# 1. PHP where PHP should not be — uploads, cache, images, media dirs
find wp-content/uploads -name '*.php' -o -name '*.php[0-9]' -o -name '*.phtml' 2>/dev/null

# 2. Recently modified, clustered in time (attackers touch many files at once)
find . -name '*.php' -newermt '2026-07-01' -printf '%T+ %p\n' | sort

# 3. High entropy / long single lines — the shape of packed obfuscation
find . -name '*.php' -exec awk 'length>1000{print FILENAME": "length; nextfile}' {} \;

# 4. The dangerous-sink grep — leads, NOT verdicts (see the FP problem below)
grep -rnE '\b(eval|assert|system|passthru|shell_exec|proc_open|popen|create_function)\s*\(' --include='*.php' .
grep -rnE '(base64_decode|gzinflate|gzuncompress|str_rot13|hex2bin)\s*\(' --include='*.php' .

# 5. Request-driven code execution — the webshell core
grep -rnE '\$_(GET|POST|REQUEST|COOKIE|SERVER)\s*\[[^]]*\]\s*\(' --include='*.php' .
grep -rnE '(eval|assert|system|passthru)\s*\(\s*\$_(GET|POST|REQUEST|COOKIE)' --include='*.php' .

The most reliable single lead is variable execution of request data — $_POST['x'](), ev[a]l($_GET[...]), ass[e]rt($_REQUEST[...]), call_user_func($_GET['f'], ...). Legitimate code almost never dispatches a function name straight from a superglobal.

The Grep Is Not Clean Just Because It Is Empty

A source tree that returns nothing for grep eval can still be backdoored. Attackers defeat the obvious grep deliberately:

• Concatenation: $a='ev'.'al'; $a($code); or ('e'.'v'.'a'.'l')(...).
• Variable variables / indirection: $f='system'; $f($_GET['c']);, ${'_'.'GET'}, $$x.
• Char/hex/octal escapes: "\x65\x76\x61\x6c" is eval; chr(101).chr(118)....
• Callback sinks: array_map, array_filter, usort, preg_replace_callback, register_shutdown_function, ob_start with a user-controlled callback.
• String-eval that is not eval: assert($str) (pre-8.0), preg_replace('/./e', $str, ...) (pre-7.0), create_function('', $str) (pre-8.0), mb_ereg_replace with e.
• Comment and whitespace insertion between token pieces to break naive regex.

So grep is a lead generator, not a coverage guarantee. When grep is empty and you still suspect infection, fall back to: entropy/long-line ranking, mtime clustering, and diffing against a known-good copy (below).

Append-Infections Are the Ones You Miss

The hardest infection is a backdoor appended to or inserted into a legitimate file — index.php, wp-config.php, a theme's functions.php, vendor/ autoloaders. The file is 99% real, so it does not stand out by name, location, or entropy overall. Find these by comparison, not by inspection:

# Diff the tree against a pristine copy of the same CMS/plugin version
# (download the exact version from wordpress.org / the vendor)
diff -rq ./site /known-good/wordpress-6.x/

# WordPress core/plugin integrity via checksums
wp core verify-checksums; wp plugin verify-checksums --all

# git/composer/npm: what changed vs the committed/locked state
git status --porcelain; git diff

If you have no known-good baseline, the tells are: code after the closing ?> of an otherwise-normal file, a lone eval/base64_decode line wedged at the top of a config file, or a <?php ... ?> block whose style clashes with the surrounding file.

Version-Gated Tells Date the Code

The presence of a removed language feature tells you something:

• preg_replace with the /e modifier — removed in PHP 7.0. Its presence means the backdoor targets (or predates) PHP 5.x.
• create_function() and string-argument assert() as code execution — removed in PHP 8.0. Common in older shells; on a PHP 8 server they would fault, which is itself a signal about when the code was planted.

Known Families Are Leads, Not Verdicts

Fingerprints speed triage but do not replace reading the code:

IOC strings in this section are bracket-broken — ev[a]l is eval, ass[e]rt is assert. Written literally they match Backdoor:PHP/Chopper and this file, a defensive hunting skill, gets quarantined on download. The grep patterns above are intact and safe to copy. See "Antivirus false positives" in the repo README.

• China Chopper — a one-liner: <?php @ev[a]l($_POST['pass']);?> (or assert), often under 30 bytes. Tiny, so easy to miss and easy to append.
• WSO, b374k, c99, r57, indoxploit — full-featured panels; grep their banner strings, characteristic function names, or auth-cookie names as leads.
• Weevely — generates obfuscated, password-gated shells that change per build; signature matching is weak, so rely on the request-driven-execution and obfuscation signals instead.

A signature hit confirms a shell. It does not confirm you found them all — attackers plant several, and the second one rarely matches the first's family.