T1505.003: Web Shell

A web shell is, at its core, a small program placed in a web-accessible directory on a compromised server. It accepts commands via HTTP or HTTPS requests and executes them on the underlying operating system with whatever privileges the web server process holds. The shell is typically a single file — sometimes only a few lines of code — written in the scripting language supported by the target web server: PHP for Apache and Nginx, ASP/ASPX for IIS, JSP for Tomcat and JBoss, or Python for frameworks like Django and Flask.

Web shells are the bridge between initial exploitation (T1190) and everything that follows. After exploiting a vulnerability in a public-facing application, the attacker's first action is almost always to establish persistent access so they do not need to re-exploit the vulnerability every time they want to interact with the compromised system. A web shell provides that persistence. It is the foothold from which credential harvesting, lateral movement, data exfiltration, and ransomware deployment begin.

MITRE documents over 50 threat groups and malware families that use web shells, making it one of the most widely adopted persistence techniques in the framework. The technique is used by nation-state espionage groups, ransomware operators, hacktivists, and cybercriminals alike — because a web shell is simple, reliable, and difficult to detect when properly disguised.

How Web Shell Deployment Works

The deployment chain begins after the attacker gains the ability to write files to a web-accessible directory on the target server. This capability is obtained through the initial exploitation phase — a file upload vulnerability in a web application, a remote code execution flaw in a server framework, or an authentication bypass on a management interface. Once the attacker can create or modify files, the web shell is written to disk.

The shell itself is designed to be small and inconspicuous. Sophisticated web shells use obfuscation to avoid signature-based detection — encoding function names, splitting functionality across multiple files, or embedding the shell within legitimate application code. The attacker then accesses the web shell by navigating to its URL in a browser or using a purpose-built client tool (like the China Chopper client) and sends commands through HTTP parameters, POST data, or custom headers.

Once active, the web shell provides the attacker with a command-line interface to the server's operating system. From this interface, the attacker can enumerate the local system and network, download additional tools, harvest credentials from configuration files and memory, establish reverse tunnels to bypass firewall rules, and pivot to internal systems that are not directly accessible from the internet.

Web Shell Types by Language

Language	Target Servers	Notable Examples	Detection Notes
PHP	Apache, Nginx, LiteSpeed	c99, r57, WSO, b374k	Look for eval(), base64_decode(), system(), passthru(), shell_exec() in files written to web roots
ASP/ASPX	IIS, Exchange	China Chopper, OwaAuth, SIMPLESEESHARP	Monitor \inetpub\wwwroot\, \aspnet_client\, and OWA directories for new .aspx/.ashx files
JSP	Tomcat, JBoss, WebLogic, WebSphere	SLAYSTYLE, JspSpy, reGeorg, Godzilla	Java web shells are common on enterprise application servers; monitor deployment directories and WAR file changes
Python	Django, Flask, custom WSGI	Weevely (generates Python payloads), custom scripts	Less common but used against Python-based web applications; look for new .py files in application directories
Perl/CGI	Apache (legacy), embedded systems	CGI backdoors on legacy web infrastructure	Found primarily on older systems and embedded devices with web interfaces

Real-World Case Studies

SLAYSTYLE and the BRICKSTORM Campaign — JSP Web Shells at Scale

China-linked APT clusters UNC5221 and UNC6201 deployed a JavaServer Pages web shell named SLAYSTYLE across U.S. enterprise environments, maintaining undetected access for an average of 393 days. SLAYSTYLE was deployed on Java-based application servers after initial exploitation, providing the attackers with persistent command execution capabilities that survived application restarts and routine patching. The web shell was part of a broader campaign known as BRICKSTORM that also exploited CVE-2026-22769, demonstrating how web shells serve as the persistence layer in multi-stage espionage operations.

Related: SLAYSTYLE and the JSP Web Shell Threat — What Every Security Professional Needs to Know

HAFNIUM and China Chopper — Exchange Server Mass Web Shell Deployment

During the ProxyLogon exploitation campaign, HAFNIUM deployed China Chopper web shells — and several custom variants — on tens of thousands of compromised Exchange servers worldwide. The web shells were written to IIS web directories accessible through Outlook Web Access paths, giving the attackers persistent access to email servers that often held elevated privileges within Active Directory. In many environments, the web shells remained active for weeks or months after patches were applied because the patches addressed the vulnerability but did not remove the web shells that had already been deployed.

Ivanti Connect Secure — VPN Web Shells That Survive Factory Resets

In early 2024, exploitation of Ivanti Connect Secure VPN appliances (CVE-2023-46805 and CVE-2024-21887) led to the deployment of multiple custom web shells — WIREFIRE (Python), BUSHWALK, and SLIGHTPULSE — on compromised VPN appliances. These web shells were specifically designed for the Ivanti platform's embedded web server and provided capabilities for file read/write, arbitrary command execution, and proxying traffic through the VPN appliance into the internal network. In certain configurations, the web shells persisted even through Ivanti's integrity checker tool and factory reset procedures, forcing CISA to issue an emergency directive requiring federal agencies to disconnect affected devices entirely.

APT28 — reGeorg on OWA Servers

APT28 (Fancy Bear, Russia) has deployed modified and obfuscated versions of the open-source reGeorg web shell on Outlook Web Access servers to maintain persistent tunneled access into target networks. By placing the web shell on the OWA server, the attackers leveraged the server's legitimate HTTPS certificate and domain name, making web shell traffic indistinguishable from normal email access at the network level. The modification of the open-source tool demonstrates how publicly available web shells are customized by nation-state actors to evade specific detection signatures.

FIN13 — Web Shells for Financial Theft

FIN13, a financially motivated threat group targeting organizations in Latin America, has used a diverse arsenal of web shells — JspSpy, reGeorg, MiniWebCmdShell, and the Vonloesch Jsp File Browser — to maintain access to compromised web servers and execute operations aimed at financial system manipulation. The group's use of multiple different web shell families demonstrates that attackers often deploy redundant persistence mechanisms, ensuring access survives even if one web shell is discovered and removed.

Detection Strategies

Web shell detection combines file-based analysis (finding the shell on disk), network-based analysis (identifying web shell traffic), and behavioral analysis (detecting the actions the attacker takes through the web shell). No single method catches everything — effective detection requires layering all three.

File-Based Detection

# Sysmon Event ID 11 — File creation in web-accessible directories
# Detect new script files written to IIS, Apache, or Tomcat web roots

index=wineventlog sourcetype="XmlWinEventLog:Sysmon" EventCode=11
| where match(TargetFilename, "(?i)(\\\\inetpub\\\\|\\\\wwwroot\\\\|\\\\aspnet_client\\\\|\\\\OWA\\\\|\\\\webapps\\\\)")
| where match(TargetFilename, "(?i)\\.(aspx|ashx|asmx|jsp|jspx|php|cfm|war)$")
| table _time, Computer, Image, TargetFilename
| sort -_time

# Linux — find recently modified files in web roots
# Run as a scheduled hunt on web servers

find /var/www/ /opt/tomcat/webapps/ /usr/share/nginx/ \
  -type f \( -name "*.php" -o -name "*.jsp" -o -name "*.jspx" \) \
  -mtime -7 \
  -exec grep -l -i "eval\|base64_decode\|Runtime.getRuntime\|ProcessBuilder\|cmd.exe\|/bin/sh" {} \;

Network-Based Detection

# Detect web shell interaction patterns
# Web shells typically receive POST requests with command parameters
# and return large response bodies relative to the request size

index=web sourcetype="iis" OR sourcetype="apache:access"
| where method="POST"
| where match(uri_path, "(?i)\\.(aspx|ashx|jsp|php)$")
| where NOT match(uri_path, "(?i)(login|api|auth|upload)")
| stats count, avg(bytes_out) as avg_response, dc(src_ip) as unique_callers
  by uri_path
| where unique_callers < 3 AND count > 10
| sort -count

Behavioral Indicators

Indicator	What It Means
Web server process spawning cmd.exe, powershell.exe, or /bin/sh	The web application is executing operating system commands — almost always malicious in production environments
New files in web-accessible directories not deployed through the normal CI/CD pipeline	Files written directly to disk by an attacker, bypassing version control and deployment processes
POST requests to static-looking URLs that do not correspond to known application endpoints	Attacker interacting with a web shell disguised as a static asset or using an unusual URL path
Outbound connections from the web server to unusual external IPs or domains	Web shell establishing C2 communication, downloading additional tools, or exfiltrating data
Web server process accessing SAM, NTDS.dit, LSASS, or /etc/shadow	Attacker using web shell access to dump credentials for lateral movement
Sysmon Event ID 1 showing w3wp.exe or java.exe as parent process for suspicious child processes	The web server worker process is spawning commands — a definitive indicator of web shell execution on Windows

# Detect web server process spawning command interpreters (Windows)
# Sysmon Event ID 1 — Process creation

index=wineventlog sourcetype="XmlWinEventLog:Sysmon" EventCode=1
| where match(ParentImage, "(?i)(w3wp|httpd|tomcat|java|nginx|php-cgi)")
| where match(Image, "(?i)(cmd\\.exe|powershell\\.exe|pwsh\\.exe|certutil|whoami|net\\.exe|net1\\.exe)")
| table _time, Computer, ParentImage, ParentCommandLine, Image, CommandLine
| sort -_time

Known Threat Actors

T1505.003 has one of the largest documented user bases in the ATT&CK framework, with over 50 threat groups and malware families observed using web shells. The following represents a selection of the groups with the most significant web shell operations:

• HAFNIUM (China) — Mass deployment of China Chopper and custom ASPX web shells on Exchange servers via ProxyLogon exploitation
• UNC5221 / UNC6201 (China) — SLAYSTYLE JSP web shells deployed for long-duration espionage operations averaging 393 days of undetected access
• APT41 (China) — Web shells deployed on compromised government and enterprise web servers as part of combined espionage and financially motivated operations
• Threat Group-3390 (China) — OwaAuth web shell designed specifically for Exchange servers, installed as an ISAPI filter for deep integration
• APT28 / Fancy Bear (Russia) — Modified reGeorg web shells deployed on OWA servers for tunneled persistent access
• Sandworm (Russia) — Web shells deployed on compromised infrastructure including OT/ICS-connected systems during destructive attacks against Ukraine
• OilRig / APT34 (Iran) — Persistent web shell access used to maintain long-term footholds in targeted government and energy sector networks
• Dragonfly / Energetic Bear (Russia) — Web shells on publicly accessible email and web servers used to maintain access and stage further attacks
• FIN13 — Multiple web shell families (JspSpy, reGeorg, MiniWebCmdShell) used for financial theft operations in Latin America
• BlackByte Ransomware — Web shells deployed after initial exploitation to establish persistent access before ransomware deployment

Defensive Recommendations

1. Implement file integrity monitoring (FIM) on all web-accessible directories: Monitor IIS web roots (\inetpub\wwwroot\, \aspnet_client\), Apache/Nginx document roots (/var/www/), and Java application server deployment directories (/webapps/) for any file creation or modification. Alert on new script files (.aspx, .jsp, .php) that were not deployed through the authorized change management process.
2. Monitor web server process trees: Configure Sysmon or EDR to alert when web server worker processes (w3wp.exe, httpd, java, tomcat) spawn command interpreters (cmd.exe, powershell.exe, /bin/sh, /bin/bash). This is a high-fidelity indicator of web shell activity in production environments.
3. Restrict write permissions on web directories: The web server process should have read-only access to application directories. Writable directories (upload folders, temp directories) should never be configured to execute scripts. Separate application code from user-uploaded content.
4. Disable dangerous functions in server configurations: In PHP, disable eval(), exec(), system(), passthru(), and shell_exec() through php.ini if they are not required by the application. In Java environments, restrict Runtime.getRuntime().exec() and ProcessBuilder through security manager policies.
5. Deploy application-aware WAF rules: Configure web application firewall rules to detect and block HTTP requests that contain shell command syntax, encoded payloads, or known web shell interaction patterns in POST bodies, URL parameters, and headers.
6. Conduct post-exploitation web shell hunts after every vulnerability patching event: Every time a public-facing application is patched for a remote code execution or file write vulnerability, hunt for web shells in all web-accessible directories before considering the incident closed. Patching removes the entry point but not the persistence.
7. Baseline legitimate web application files: Maintain a cryptographic hash baseline of all legitimate application files. Use this baseline to identify unauthorized additions or modifications during routine security scans and incident response investigations.
8. Segment web servers from internal networks: Web servers should reside in a DMZ with strict firewall rules governing traffic to internal networks. A web shell on a properly segmented web server has limited ability to access Active Directory, databases, or file shares on the internal network.

MITRE ATT&CK Mapping

Field	Value
Technique ID	T1505.003
Technique Name	Server Software Component: Web Shell
Tactic	Persistence
Platforms	Windows, Linux, macOS, Network Devices
Parent Technique	T1505 Server Software Component
Data Sources	File (Creation, Modification), Process (Creation), Network Traffic (Content, Flow), Application Log (Web Server)
Mitigations	Disable or Remove Feature or Program, User Account Management (least privilege), Network Segmentation, Software Update
MITRE Reference	attack.mitre.org/techniques/T1505/003

Sources and References

• MITRE ATT&CK — T1505.003 Web Shell: attack.mitre.org
• CISA — Web Shell Malware Advisory (AA20-133A): cisa.gov
• CISA — Emergency Directive 24-01 (Ivanti Connect Secure): cisa.gov
• Mandiant — Ivanti Connect Secure Zero-Day Exploitation (2024): cloud.google.com
• NSA/CISA — Detecting and Preventing Web Shell Malware: nsa.gov