Webshells Explained: How Attackers Keep Access to Your Server

A webshell is a small script, usually PHP on WordPress and Linux hosting, that an attacker uploads to your web server so they can control it through a browser. Once it is in place, they can browse files, upload more malware, read your database credentials and run system commands, all while looking like normal web traffic.

Think of a webshell as a spare key the intruder cut while they were inside. The original break-in might have been a vulnerable plugin, a stolen password or a neighbouring site on the same server. The webshell is what lets them come back tomorrow, next week or after you have "fixed" the obvious damage.

Webshells range from a single line of obfuscated code to full file-manager kits with a login page, a terminal, a database browser and a mass-defacement tool. Kits such as ALFA and KINGSMAN, which we regularly find during server malware removal, fall into the second group: they are polished, password-protected control panels built for managing many compromised sites at once.

Webshells arrive through whatever weakness the attacker found first: an unpatched plugin or theme with a file-upload flaw, a stolen WordPress admin or FTP password, a compromised site sharing the same server user, or an exposed file manager. The webshell is the second stage; the entry point is the problem you actually need to fix.

The most common routes we see are:

• Vulnerable upload handlers. A plugin form that accepts files without checking type lets an attacker upload image.php straight into wp-content/uploads.
• Stolen admin credentials. With admin access, the built-in theme and plugin editors will happily write PHP to disk.
• Cross-site contamination. On servers where several sites run as one system user, one hacked site can write into every other site. Our guide to VPS security explains why.
• Leaked FTP, SFTP or control panel logins. Old credentials in a developer's config file or a phished hosting account.

Every webshell tells a story about how it arrived. File timestamps, web server access logs and the user that owns the file usually point back to the entry point, which is why forensic analysis comes before clean-up.

Most webshells are deliberately hard to read. They hide behind encoding functions such as base64_decode, gzinflate and str_rot13, build function names from string fragments, and take their instructions from request parameters or cookies. File names are chosen to blend in: wp-cache.php, class-wp-rest.php or favicon_5d1e.ico.

The examples below are illustrative, defanged and truncated. They show the patterns to look for, not working code.

# One-liner style: runs whatever arrives in a request parameter
<?php @$_="as"."se"."rt"; @$_(str_rot13(base64_decode($_REQUEST['...'])));  [truncated]

# Obfuscated loader: a long encoded blob unpacked at runtime
<?php $k='x7'; eval(gzinflate(base64_decode('7X1rc9s2su/7V8C6VQ... [truncated 48 KB]')));

# Kit-style login gate seen in ALFA / KINGSMAN-type panels
if(md5($_POST['pass'] ?? '') !== '5f4dcc3b...'){ header('HTTP/1.0 404 Not Found'); exit; }

Notice the last pattern: many kits return a fake 404 page to anyone without the password. If you visit the file in a browser it looks as though nothing is there, which is exactly why "I checked and the file is gone" is not proof of a clean site.

Finding webshells means combining several signals: PHP files where PHP should never be, files changed around the time of the incident, encoded or dynamically executed code, and files that do not match the official WordPress, plugin or theme checksums. No single grep catches everything, so use all four checks together.

1. Look for PHP in upload folders. WordPress never needs executable PHP inside wp-content/uploads. Anything found there deserves investigation.
2. Sort by modification time. Attackers often backdate files, but new files still cluster around the intrusion window.
3. Search for dangerous functions. Expect false positives from legitimate plugins; each match needs reading, not deleting blindly.
4. Verify checksums. WP-CLI can compare core and plugin files against the official copies on WordPress.org.

# 1. PHP files inside uploads (should return nothing)
find /var/www/example.co.uk/wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \)

# 2. PHP files modified in the last 30 days, newest first
find /var/www -type f -name "*.php" -mtime -30 -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' | sort -r | head -50

# 3. Common obfuscation and execution patterns
grep -rlE "eval\(|gzinflate\(|str_rot13\(|base64_decode\(|assert\(|create_function" /var/www --include="*.php"

# 4. Compare WordPress core and plugins with official checksums
wp core verify-checksums --path=/var/www/example.co.uk
wp plugin verify-checksums --all --path=/var/www/example.co.uk

On a server hosting many sites, repeat this for every document root and check files owned by unexpected users. The PatientZero Forensic scan (dfir-fast) and Malware sweep (malware-intelligence) profiles run these checks, and many more, across every site on the server in one pass.

Safe webshell removal follows a fixed order: preserve evidence, contain access, remove every malicious file, remove any other persistence, then close the entry point and rotate credentials. Deleting the one file you found while the attacker still has a cron job, a rogue admin user or a second shell simply starts the cycle again.

1. Preserve. Copy suspicious files, with their timestamps, to a quarantine folder outside the web root and record a hash of each.
2. Contain. Put the site behind a maintenance response or firewall rule so the shell can no longer be reached while you work.
3. Remove. Delete confirmed webshells and replace modified core, plugin and theme files with clean copies from official sources.
4. Hunt persistence. Check crontabs, systemd services, .htaccess and .user.ini files, rogue WordPress administrators and SSH authorized_keys.
5. Close the door. Patch or remove the vulnerable component, then rotate WordPress, database, SFTP, SSH and hosting passwords and the WordPress salts.

# Quarantine with hashes before deleting anything
mkdir -p /root/quarantine/2026-09-29
sha256sum /var/www/example.co.uk/wp-content/uploads/2026/08/thumb-cache.php >> /root/quarantine/2026-09-29/hashes.txt
cp -p /var/www/example.co.uk/wp-content/uploads/2026/08/thumb-cache.php /root/quarantine/2026-09-29/

# Then check for other persistence
crontab -l -u www-data
find /var/www -name ".user.ini" -o -name ".htaccess" -newer /var/www/example.co.uk/wp-config.php

The single most effective control is to stop PHP executing anywhere users can upload files. Combine that with prompt updates, separate system users per site, disabled in-dashboard file editing and ongoing file-integrity monitoring, and a newly dropped webshell either cannot run or is detected quickly.

# Block PHP execution in WordPress uploads
location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

Our full WordPress hardening checklist goes further, and the PatientZero Harden playbooks apply these controls consistently across every site on a server.

Get help if you have found more than one webshell, if files reappear after deletion, if the server hosts several sites, or if you find signs of system-level access such as unknown cron jobs, services or SSH keys. Those point to a compromise deeper than one WordPress install.

A webshell on a server often sits alongside reverse shells, rogue users and scheduled re-download jobs. Removing them properly means investigating the whole server, not just the site that showed symptoms. PatientZero connects over SSH, runs a forensic scan across every site, quarantines what it finds with evidence kept, fixes the entry point and hardens the server afterwards. Unlimited malware removal is included on every plan.

If you think you have a webshell right now, start with our security triage, or go straight to emergency help and we will start triage as soon as you get in touch.