Web Shells: How Attackers Use Them and How to Detect Them

Exploits targeting internet-facing web applications were the leading initial access vector for the sixth consecutive year in 2025, according to Mandiant’s M-Trends 2026 report. Web shells are central to how those exploits are sustained — threat groups deployed them in 35% of incidents in Q4 2024, more than triple the rate of the previous quarter. Once planted on a compromised web server, a web shell gives attackers long-term persistence, the ability to move laterally, and direct access to sensitive data — all without triggering the alerts that conventional malware would generate.

In 2025, the median time between initial compromise and attacker hand-off collapsed to 22 seconds. Web shells are a key enabler of that speed — they allow threat actors to maintain silent access while a second group takes over for ransomware deployment or data exfiltration. Let’s dissect a classic PHP web shell to show how it works in practice, and why these scripts remain so effective at turning a single unpatched vulnerability into a lasting breach.

Why web shells matter

A web shell is a small script (usually written in PHP, ASP, or JSP) that attackers upload to a vulnerable web application.

Think of a web shell as a hidden control panel. Once installed, it lets hackers run commands, browse files, and take over the server from their browser. What starts as a single flaw in a web app can quickly become a permanent backdoor.

According to CISA, web shells can operate on Linux, Microsoft Windows, macOS, and Network platforms.

Attackers usually plant web shell scripts through:

• Remote code execution bugs in public web apps
• Poorly secured file upload forms
• Remote or local file inclusion (RFI/LFI) flaws
• Outdated CMS plugins or themes, such as in WordPress

Over the years, some shells have become infamous:

• C99 web shell: A feature-packed PHP shell with tools for file management, command execution, and databases
• China Chopper webshell: A tiny but powerful web shell often used for stealthy persistence
• R57 and WSO web shells: Older but still active web shells with basic file and command features
• B374K web shell: A PHP web shell that can view processes and run commands

Let’s look at some of these web shells in action.

Case studies: Real-life web shell incidents

Before we break down their components, let’s look at some real-life examples of the damage web shells can do. They accounted for 35% of cyberattack incidents in Q4 2024, making them a major malicious script to watch out for.

• April 2025: According to The Hacker News, critical bug let attackers upload JSP web shells, then use tools like Brute Ratel to escalate and steal data. Scans found hundreds of vulnerable servers exposed online.
• July 2023: CISA reported that threat actors exploited the Citrix NetScaler/ADC flaw (CVE-2023-3519) to drop web shells (often JSP), gain remote command execution and persistence, and move laterally.
• June 2022: MITRE ATT&CK documented how a web shell was deployed during the Ukraine Electric Power Attack, executed by a threat group with Russian connections.

In short, web shells can quickly turn any vulnerable app into a compromised web server, with devastating consequences.

C99: A webshell analysis

C99 is a classic PHP webshell example that packs a lot of capability into a single script, including:

• File manager
• Upload/ download
• Command execution
• Database helpers
• Self-delete option

C99 clearly demonstrates the full attacker workflow: an adversary drops a tiny PHP file through a vulnerable upload or RCE, then uses that same script to browse the webroot, run OS commands, pull credentials and stage further tools.

Let’s break down what the C99 webshell can look like in more detail.

1. File system navigation

• What it does: file-system navigation lets an attacker list folders, open files, and read their contents. They might use functions like scandir() or opendir() to see what’s on the server, file_get_contents() to read files, and file_put_contents() to drop or update files.
• Why it matters: This is how hackers can find config files, API keys, backups and other sensitive data, and where they stage additional payloads.
• What to watch for: Requests repeatedly hitting the same PHP path that return directory listings. Also check for new or recently-modified files in webroot (odd timestamps), and sudden reads of config files or large downloads initiated from the web server.

The snippet below is a simplified example to show the behaviour, although exact implementations and function names vary by variant.

Figure 3: Example of file system navigation in PHP programming language.

2. File upload/ download

• What it does: C99-style shells often include a file upload form so an attacker can drop extra tools (malware, scanners, or large payloads) onto the server. They also let attackers download files from the server. Common upload mechanisms are move_uploaded_file() (standard browser file uploads), handlers that accept raw POST bodies, or POST fields carrying base64-encoded files.
• Why it matters: An attacker uses uploads to stage further malware or replace app files. Downloads let them pull configuration files or database dumps out of your environment, all through the webserver process.
• What to watch for: Keep an eye out for large or unusual POST requests to the same PHP endpoint (especially those containing long base64 strings) followed by new or oddly named files appearing in web-accessible folders or spikes in outbound traffic.

3. Command execution/ Remote access

• What it does: C99 gives an attacker a tiny web terminal. They can send a command via the web UI or a POST request and get the command output back in the browser.
• Why it matters: This is how attackers spawn reverse shells, run privilege-escalation scripts, or launch other tools from the web server.
• What to watch for: Monitor for web processes spawning shell commands or unexpected outbound connections immediately after requests to a single PHP endpoint.

4. Database connections and data extraction

• What it does: C99-style shells often include quick tools to read config files (where apps store DB credentials) and run SQL queries using those credentials. That lets an attacker dump user tables, steal API keys, or write new records to help persistence.
• Why it matters: With DB access an attacker can exfiltrate customer data, take over accounts, or use the same credentials to access other services, multiplying the breach impact.
• What to watch for: Look out for unexpected reads of config files plus unusual DB connections/queries originating from the web server process.

5. Obfuscation and anti-forensics

C99 variants sometimes hide strings or logic using base64_decode(), gzinflate() or eval() wrappers, and may compress or split payloads to avoid simple signature detection. They may also self-delete after use. These tricks make signature-based scanners and quick manual reviews miss the implant.

How attackers deliver web shells

Now we’ve seen the inner workings of a web shell operating system, let’s explore how hackers get them into a compromised system in the first place.

• Exploited remote code execution (RCE) in a public app: Attacker runs code on your server
• Unsafe file-upload endpoints or misconfigured permissions that let attackers drop files
• Remote File Inclusion (RFI) or Local File Inclusion (LFI) chains that let an attacker force the server to write or execute a remote file
• Compromised plugins or themes, stolen admin credentials, or phishing that gives access to admin panels (common in WordPress)

Checklist: How to catch a web shell

Here’s a clear checklist you can use during hunts or triage. Each item is one place to look, and what it usually means.

1. New or oddly named PHP files in web folders: Check for files that weren’t there before, have strange names (random strings), or timestamps that don’t match your last deploy.
2. Unexpected outbound connections from the web server: Repeated, periodic connections to unknown IPs can be a beacon to command-and-control.
3. Webserver spawning new processes or running shell commands: If your web process suddenly forks sh, bash, or other unexpected binaries, treat it as high priority.
4. Changes to CMS core files, plugins, or unknown admin accounts: Look for modified core files, new admin users, or plugin files that don’t match vendor hashes.
5. Odd POST requests with long bodies or base64-like data: Large or frequent POSTs to the same PHP endpoint (especially with long encoded strings) often indicate uploads or remote writes.

You can also benefit from monitoring tools.

For example, you can use file-integrity monitoring to spot new or changed webroot files, web application firewall (WAF) and web-server logs for weird POSTs, EDR alerts when the web process spawns shells or writes binaries, and network/ IDS for beaconing or unexpected egress. Combine those feeds and you’ll spot implants faster.

CybelAngel can complement this process. It can manage your public and internet-facing assets (which often hold the most sensitive data) and flag any issues before they turn into a full-blown breach.

7 tactical cybersecurity measures for CISOs

Here are some fixes that CISOs should prioritize to stay ahead of web shells.

• Patch public-facing apps and plugins: Apply vendor fixes quickly and automate updates where safe.
• Harden upload endpoints: Validate file types, strip metadata, reject executables, and store uploads outside the webroot.
• Tune your WAF for suspicious POSTs: Block or challenge large/encoded POST bodies and known web-shell signatures.
• Run file-integrity checks on the webroot: Hash content regularly and alert on new or modified PHP files.
• Lock down egress from web servers: Allowlist outbound destinations and block unexpected outbound ports.
• Improve credential hygiene: Rotate secrets, enforce MFA on admin panels, and alert on new/ privileged accounts.
• Use external threat intelligence to prioritise remediation: Map exposed apps, focus fixes on high-risk assets first, with tools like CybelAngel to automate the process.

FAQs

Wrapping up

Web shells are not sophisticated. That’s exactly what makes them dangerous. A few hundred lines of PHP, uploaded through a single unpatched vulnerability, can give an attacker persistent access to your environment for weeks or months, long after the original flaw is fixed.

Mandiant’s 2026 data confirms the pattern: exploits remain the number one initial access vector, and internet-facing web application servers are the primary target. Web shells are the bridge between initial exploitation and everything that follows — lateral movement, credential theft, ransomware deployment.

The organisations that detect web shells early share one capability: continuous visibility into their external attack surface. They know which internet-facing applications are running, which are unpatched, and they receive alerts when unexpected files appear on web servers. CybelAngel’s attack surface management maps your internet-facing assets continuously, identifying exposed and vulnerable applications before attackers can plant a foothold.

About the author

Orlaith Traynor

Orlaith is a Paris-based B2B content marketing strategist specializing in cybersecurity and tech, with deep expertise in SEO, AEO, editorial planning, and CMS management. Having led content at companies like CybelAngel and PhantomBuster, she helps technology brands create content strategies that drive organic visibility and buyer trust in competitive markets.

read all the articles