secskills
secskills / core / hunting-web-backdoors

hunting-web-backdoors

core verified 2026-07-27

Hunt planted webshells and backdoors across a web source tree — PHP first (also JSP, ASP, Node) — triaging a directory at scale, statically decoding obfuscation layers without ever executing the payload, finding append-infections and fake plugins, and treating known shell families as leads rather than verdicts. Use when a web server is suspected compromised, cleaning a hacked WordPress/Magento/CMS site, vetting a downloaded PHP codebase or plugin for hidden malicious code, or when a file contains eval on decoded input.

$ /plugin install secskills-core

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

When NOT to Use

auditing-php-applications

its C2, its capabilities) — use analyzing-malware

responding-to-incidents; this skill is the source-tree sweep within it

auditing-supply-chain

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:

gzinflate, gzuncompress, str_rot13, hex/\xNN, strrev) applied as string operations, not as executed PHP.

(UnPHP's decoder, a Python reimplementation of the decode chain) — never the PHP interpreter on the sample.

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:

${'_'.'GET'}, $$x.

chr(101).chr(118)....

preg_replace_callback, register_shutdown_function, ob_start with a user-controlled callback.

preg_replace('/./e', $str, ...) (pre-7.0), create_function('', $str) (pre-8.0), mb_ereg_replace with e.

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:

means the backdoor targets (or predates) PHP 5.x.

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.

assert), often under 30 bytes. Tiny, so easy to miss and easy to append.

banner strings, characteristic function names, or auth-cookie names as leads.

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.

When You Confirm One, Assume More

  1. Preserve before you delete. A confirmed shell is evidence — copy it

(hash it) to a holding location before removing it, per responding-to-incidents. Deletion alone loses the timeline and, if you miss the entry point, the attacker re-plants within hours.

  1. Find the entry point. A shell got there somehow — a vulnerable upload,

a known-CVE plugin, stolen credentials. Hand that to auditing-php-applications (source) or responding-to-incidents (logs); a cleaned site with the hole still open is re-infected by morning.

  1. Keep hunting. One shell found is a reason to raise suspicion of the

whole tree, not to close the case. Re-run the sweep after removing the obvious one.

Rationalizations to Reject

escapes, and callback sinks all evade it. Empty grep is not coverage — fall back to entropy, mtime, and diff-against-known-good.

payload. Decode statically, always.

frameworks use eval legitimately. The tell is eval on decoded or request-derived input, not eval itself.

obfuscated (ionCube, Zend Guard, licensing). Obfuscation raises suspicion; it does not convict. Decode and read the logic.

find the entry point, and re-sweep — attackers plant redundancy.

exactly those files precisely because you assume that. Verify by checksum.

nothing. Signatures are leads; behaviour (request-driven execution, obfuscation) is the evidence.

References

capabilities

sweep sits inside