Understanding What a Web Shell Is and How to Combat It

What is a Web Shell?

Web shells are malicious scripts that allow cybercriminals to maintain persistent access to compromised web servers and execute terminal commands, brute-force passwords, access the file system, and more. 

Most often, threat actors exploit vulnerabilities in the website code or use brute force to deliver the malicious script.

How Does a Web Shell Work?

A web shell gives an attacker remote control of a web server, letting them run commands on the server’s operating system from anywhere on the internet. This includes reading, changing, or deleting files and running programs, without a server account or physical access. 

Attackers plant the script somewhere the server will run it, then send ordinary web requests to reach it. The server then executes the commands and returns the results, all over the same web traffic that a normal visitor would generate.

A web shell operates in four basic steps.

1. The attacker plants the script. After exploiting a vulnerability, the attacker writes the web shell into a location the server can execute, often a directory meant for uploads or an existing page they have modified.
2. The attacker sends commands over the web. The attacker opens the web shell’s address in a browser or sends it crafted requests. The commands ride inside those requests, usually tucked into parameters or headers so they blend with normal traffic.
3. The server runs the commands. The web server runs the script in its own process, with the same privileges the server holds. The script carries out the command, whether that means reading a file, running a program, or launching another tool.
4. The results come back in the response. The server returns the output as part of a normal web response, so the attacker can read it in a browser like any other page.

Web shells are effective because their traffic blends in with normal visitors, using the same web ports and protocols, and their commands run inside a process the server already trusts. 

A web shell also acts as a backdoor. Once it is in place, the attacker can return whenever they like, even after the initial vulnerability is patched. Removing the original flaw does not remove the shell.

Newer web shells are harder to spot. Some run only in the server’s memory and never save a file to disk, while others encrypt their traffic so inspection tools cannot read the commands being sent.

Common Types of Web Shells

Web shells come in several variations, programmed in different languages, each designed to exploit specific vulnerabilities and environments. However, the most common languages are PHP, Python, Ruby, Perl, ASP, and ASP.NET

Understanding web shell types is key to developing strong detection and mitigation strategies.

PHP web shells

PHP is one of the most common scripting languages used in web development, making PHP-based web shells a prevalent threat. Attackers often upload these scripts through vulnerable file-upload forms and execute them to manage files, run system commands, and modify server configurations.

ASP and ASP.NET web shells

For servers running Microsoft’s Internet Information Services (IIS), ASP or ASP.NET web shells are common. Attackers exploit misconfigured servers or outdated software to upload malicious scripts that allow them to control the server remotely.

Perl and Python web shells

Although less common than PHP- or ASP-based shells, Perl and Python web shells can be used in environments where these scripting languages are active. Their presence usually indicates a deeper compromise, as attackers often use them for advanced persistence and stealth operations.

Each type of web shell may be used in a web shell attack and can also be classified as web shell malware when bundled with other malicious code. Cybersecurity professionals must remain vigilant in monitoring and detecting any anomalies associated with these tools.

How Are Web Shells Installed?

Attackers install a web shell by first exploiting a weakness in a web application or server, then using that access to write the shell, which the server will run. Common delivery vectors include:

• Unrestricted file uploads. Applications that fail to properly validate file types, extensions, or contents allow attackers to upload executable scripts (such as PHP, JSP, or ASPX) directly to the server. Once uploaded, the attacker simply requests the file via URL to execute it. This remains one of the most common infection vectors.
• Remote code execution (RCE) flaws. RCE vulnerabilities let attackers run arbitrary commands on the host operating system. Attackers often use this access to fetch or write a web shell to disk, establishing persistent backdoor access. Remote code execution was the entry point in the 2025 SharePoint attack.
• SQL injection (SQLi). While SQLi is primarily associated with data exfiltration, attackers with sufficient database privileges can exploit features such as MySQL’s SELECT … INTO OUTFILE to write a web shell directly to the web root, bridging the gap from database access to full server execution.
• Local and remote file inclusion (LFI and RFI). These occur when applications dynamically include files based on unvalidated user input. With Remote File Inclusion (RFI), the server loads and executes a payload hosted on an external system. With Local File Inclusion (LFI), attackers trigger the execution of existing files already on the server, often by first poisoning log files or session data with executable code.
• Server and application misconfigurations. Exposed admin interfaces, weak file permissions, and outdated software give attackers an opening to upload or plant a web shell.

Modern web shells add features that make them harder to detect and control, such as obfuscation and encryption to hide their code and traffic, and password protection so that only the attacker can use the shell once it is planted.

Real-World Examples of Web Shell Attacks

Some of the most serious server compromises of recent years began with an attacker planting a web shell on an internet-facing system, then using that foothold to steal data and move deeper into the network. 

The two cases below, both against widely used Microsoft server products, show how the technique works in practice:

2025 SharePoint ToolShell attacks

In July 2025, attackers exploited a chain of Microsoft SharePoint vulnerabilities, tracked as “ToolShell,” to break into on-premises SharePoint servers and plant web shells. According to CISA’s malware analysis, the attackers chained two flaws to gain access, then deployed malicious ASPX files, including one named spinstall0.aspx, to run commands, upload files, and keep control of the server.

One move set this web shell attack apart from earlier ones. Rather than only installing a backdoor, the attackers stole the server’s cryptographic machine keys, the ValidationKey and DecryptionKey that SharePoint uses to sign and trust requests. With those keys copied, an attacker can forge trusted access and return to the server even after the original vulnerability is patched, which means fixing the hole still does not secure the server.

The campaign reached high-value targets across the U.S. government. According to SecurityWeek’s reporting, affected organizations included the Department of Homeland Security, the National Nuclear Security Administration, the Department of Education, and the National Institutes of Health. 

However, the Nuclear Security Administration said it found no evidence that classified information was exposed. The same reporting linked the activity to Chinese state-sponsored groups tracked as Linen Typhoon and Violet Typhoon, along with a third actor, Storm-2603, that deployed Warlock and LockBit ransomware. 

2021 Microsoft Exchange Server attacks

In early 2021, Microsoft reported a sharp rise in web shell attacks against on-premises servers, including its Exchange email servers. Attackers exploited server vulnerabilities to upload small, powerful scripts, often written in PHP, ASP, or .NET, that gave them persistent remote access to compromised systems. 

One of the most common was China Chopper, a web shell whose payload is only a few bytes but lets an attacker run commands, read and write files, and control the server via a simple browser request.

Once the web shells were in place, attackers used them to harvest email, access sensitive internal data, and maintain a foothold even after defenders began responding. Microsoft pointed to how easily these scripts can be written and deployed as a main reason the attacks spread so fast, which is why prompt patching and continuous monitoring matter.

Web Shell Exploits: How Attackers Leverage Them

Once deployed, a web shell gives attackers a persistent beachhead in the environment, allowing them to harvest confidential data, run system-level commands, and pivot deeper into the network.

This level of unauthorized access is highly valuable in the cybercriminal underground. According to the Group-IB High-Tech Crime Trends Report 2025, corporate network access listings on the dark web rose 15% in 2024, with web shells serving as a prime tool for establishing and maintaining persistence.

Attackers typically leverage web shells for several primary objectives:

Command execution and file manipulation

With a web shell, cyber attackers can execute arbitrary commands on the server, limited only by the web server’s privileges. They use this to explore the system, checking user accounts, network settings, and running processes, and to read sensitive files such as configuration and credential data. The same access lets them create, change, or delete files, install more malware, and alter logs to hide their activity, turning the server into a foothold for further attacks.

Data exfiltration 

Attackers use a web shell to steal sensitive data from compromised systems, such as customer records, credentials, and internal documents. They often compress and encrypt the data before sending it to a server they control, so the transfer blends in with normal traffic and is hard to spot while the breach is still underway. 

Lateral movement

Lateral movement is when attackers use one compromised machine to reach others across the network. From the web shell, they use harvested credentials and the server’s internal access to move to systems that are not exposed to the internet, such as databases and domain controllers. This turns a single foothold into a route toward the whole network rather than one server.

Persistence and backdoor installation

Persistence lets attackers maintain access over time, and a web shell serves that purpose. It acts as a hidden backdoor, so attackers can return even after patching the original vulnerability. Some attackers plant multiple shells or additional backdoors and even fix the flaw they exploited to avoid drawing attention, so removing a single shell is rarely enough.

Group-IB Cloud Security Posture Management (CSPM) identifies misconfigurations and vulnerabilities that let attackers establish this kind of persistence in cloud environments.

How Often Are Web Shells Used in Cyber Attacks?

Web shells are among the most widely used and well-documented attack techniques. MITRE ATT&CK tracks the web shell as a sub-technique (T1505.003, under Server Software Component) and records more than 60 procedure examples of its use across tracked threat groups, campaigns, and tools, including nation-state groups such as APT28 and APT29. 

In 2020, the NSA and the Australian Signals Directorate reported that attackers were increasingly deploying web shells on victim servers to run system commands, and the pattern has held since, as the 2025 SharePoint attacks show.

Part of the appeal is simplicity. An attacker does not need extra tools to run a web shell. They only need a target system with a vulnerability they can exploit. Once the shell is in place, it lets them run commands, elevate privileges, and maintain access to the server even after the original vulnerability is patched.

Attackers also pair web shells with other techniques. Phishing might provide initial access, after which the web shell issues commands to systems on the network. A compromised server can also be pulled into a botnet as a command-and-control point.

Attackers use web shells in several ways.

• Stealing sensitive data and credentials.
• Installing malware to enable further infection.
• Defacing websites.
• Redirecting visitors to advertising or attacker-controlled content.
• Planting hidden links on compromised sites to boost another site’s search ranking.
• Running cryptomining scripts on the server or on visitors’ devices.
• Sending visitors to exploit kits that infect their devices.
• Injecting web skimmers into payment pages to steal card details.

How Are Web Shells Detected?

Web shells are detected by watching for signs that a server is behaving abnormally, not only by scanning files for known malicious code. 

They are hard to catch because attackers hide them inside normal-looking files, blend their activity into ordinary web traffic, and increasingly use versions of web shell malware that leave no file on disk. 

The most reliable approach combines behavioral, log, file, and network analysis:

• Behavioral detection and EDR. Web servers follow predictable patterns. When a web server process launches system tools it rarely uses, such as whoami, ipconfig, or cmd, that behavior often points to an active web shell. Endpoint detection and response (EDR) tools flag these anomalies in system calls and process lineage. The NSA and Australian Signals Directorate guidance treats this behavior-based method as one of the more dependable ways to find web shells, because it does not depend on recognizing the shell’s code.
• Log analysis. Web server logs record who requested what. A web shell leaves traces such as requests to an unusual file, odd user-agent strings, or repeated access from an unexpected IP address. Reviewing logs helps identify the addresses attackers used and the commands they ran.
• File integrity monitoring. Web shells are usually uploaded as files, so watching web directories for new or changed files can surface one. A script appearing in a folder meant only for images is a strong signal.
• Network analysis. Monitoring traffic can reveal web shell activity, such as unexpected outbound connections or unusual request patterns from a server that should mostly receive requests.
• Signature and pattern matching. Automated tools scan files for code that matches known web shells. This works against off-the-shelf shells but not custom or obfuscated ones, so it cannot be relied on alone.

Two newer techniques weaken the file- and traffic-based methods above. Some web shells now run entirely in memory and never write to disk, leaving file integrity monitoring and signature scanning with nothing to find. 

Others encrypt their traffic, so network inspection sees scrambled data instead of readable commands. Both trends push detection toward monitoring server behavior rather than the contents of its files or traffic.

How to Defend Against Web Shell Attacks? 

Defending against web shells takes more than preventing the initial break-in. Closing the initial vulnerability does not remove a shell already on the server because a web shell is a backdoor that survives patching, 

A strong defense works in three layers. The first reduces the ways in, the second detects shells that get through, and the third removes them.

Reduce the ways in

Harden the server and its applications to reduce the number of openings available for exploitation. The highest-value step is least privilege. Do not let the web application write to the directories it serves, which blocks the most common install path. Keep software patched, validate user input, and put a web application firewall (WAF) in front of the site to filter malicious requests. The Web Shell Prevention Best Practices section below covers these steps in detail.

Detect what gets through

Assume some attempts will succeed, and watch for the signs. Behavioral monitoring is the most dependable method, because it flags a server acting out of character, such as a web server process running system commands, instead of relying on recognizing the shell’s code. This matters more than ever, since newer shells run only in memory or encrypt their traffic to slip past file and network scanning. Pair it with file integrity monitoring to catch new or changed files in web directories.

Be ready to respond

Because patching the entry point does not remove an installed shell, plan to remove it before you need it. That means isolating the affected server, finding and removing every shell and backdoor, and closing the flaw that let the attacker in. Attackers often plant more than one shell, so the most reliable recovery is to rebuild from a known-good backup, which makes keeping clean, tested backups a control in its own right. 

How to Remove a Web Shell From a Compromised Server

Removing a web shell is rarely as simple as deleting a single file. Attackers typically plant multiple redundant shells and hidden secondary backdoors, meaning a backdoor can easily survive the initial vulnerability patch. 

Complete removal requires a structured incident response process rather than a quick cleanup: contain the immediate compromise, eliminate all persistent access points, and harden the system so the attacker cannot return.

1. Isolate the compromised server 

Start by cutting the server off from the network so the attacker loses access and cannot spread further. Take it offline or block its outbound connections, but preserve the server rather than wiping it right away, since its files and logs are the evidence you need to understand what happened. Isolating the server also stops any ongoing data theft or lateral movement.

2. Identify and remove malicious files

With the server isolated, find every web shell and related file the attacker left behind. Compare the server’s files against a known-good baseline to see what was added or changed, review web directories for scripts that should not be there, and check logs for the URLs the attacker requested. Remove each shell you find, and treat the goal as finding all of them rather than just the first, because attackers commonly plant backups in multiple locations.

3. Investigate the initial access vector

Find out how the attacker got in, or they will return through the same vulnerability. Trace the entry point back through your logs to the vulnerability or misconfiguration that allowed the upload, whether that was an unpatched flaw, a weak file-upload form, or exposed credentials. Removing the shell without closing this entry point leaves the door open for the next one.

4. Reset compromised credentials 

Assume the attacker collected any credentials and secrets the server could reach, and reset them. This includes local and administrative passwords, service accounts, API keys, and any cryptographic keys stored on the server. 

The 2025 SharePoint attacks showed why this matters, since attackers who steal a server’s machine keys can forge trusted access and return even after everything else is cleaned up.

5. Monitor for persistence and reinfection 

After cleanup, watch the server closely for signs that the attacker has returned. Web shell operators often leave hidden persistence, such as scheduled tasks, altered services, or extra backdoors, so keep behavioral monitoring and file integrity monitoring in place and review logs for renewed activity. 

If you cannot be confident the server is fully clean, the safest option is to rebuild it from a known-good backup and restore only verified data.

Web Shell Prevention Best Practices

Preventing web shells means closing the openings attackers use to plant them and catching unwanted changes early. No single measure is foolproof, so the practices below work together to lower the risk and shrink the window an attacker has. These precautions sit alongside the detection and response measures described earlier.

1. Harden web servers and applications

Hardening removes the easy openings an attacker would use to upload and run a web shell. The goal is to limit what the server allows and close what it does not need.

• Apply least privilege. Do not let the web application write to the directories it serves or change web-accessible code. This alone blocks the most common install path.
• Keep software patched. Update the operating system, web server, and applications promptly to close known vulnerabilities.
• Reduce the attack surface. Close unused ports and services, disable directory browsing, and change default passwords.
• Filter and segment traffic. Put a web application firewall (WAF) in front of the site, use a reverse proxy server to restrict administrative URLs to known-legitimate ones, and place internet-facing servers in a demilitarized zone (DMZ) separated from internal networks.

2. Implement secure development practices

Many web shells get in through flaws in the application’s own code, so secure development closes those gaps before the application ships. Validate and sanitize all user input so attackers cannot use it to include or run their own files, which addresses local and remote file inclusion. 

Restrict file uploads by checking file types and extensions, renaming uploaded files, and storing them outside the web root so they cannot be executed as code. Disable dangerous functions that run system commands, and require code review before release.

3. Monitor critical web directories

Attackers plant web shells in web-accessible folders, so monitoring those directories closely helps catch a shell soon after it lands. Use file integrity monitoring on the web root and upload folders to alert on new or changed files, and tune it to flag anything that should not be there, such as a script appearing in a folder meant only for images. Watching the highest-risk directories shortens the time a web shell can sit undetected.

4. Conduct regular vulnerability assessments

Regular testing finds the weaknesses an attacker would exploit to plant a web shell, so you can fix them first. Run frequent vulnerability scans to surface unpatched software, misconfigurations, and exposed services, and use penetration testing to find gaps that scanners miss. 

Feed the results into patching and hardening so you fix the highest-risk issues first. Scanning does not catch zero-day flaws, so treat it as one layer, not a guarantee.

How Group-IB Helps Organizations Defend Against Web Shell Attacks

Web shells are built to persist. They survive the patch meant to stop them, blend into normal web traffic, and increasingly run in memory or encrypt their activity to slip past file and network scanning. 

Defending against them takes a layered approach: reduce entry points, detect what gets through, and respond before the damage spreads. Here’s how Group-IB helps your organization develop that approach:

• Attack Surface Management continuously maps your internet-facing assets and flags exposed, unpatched, or misconfigured servers that attackers target. 
• Managed XDR uses behavioral analysis across endpoints and network traffic. The platform detects when a server acts out of character, such as a web server running system commands. It inspects encrypted traffic where modern shells hide their activity, and responds by isolating the host and collecting forensic data.
• Threat Intelligence tracks and hunts hundreds of web shells, including widely available public ones and private shells used by advanced persistent threat (APT) groups, so defenders can recognize them faster.

Backed by Group-IB Incident Response and Digital Forensics, our team can help close the gap between the moment a web shell lands and the moment you remove it.

Talk to Group-IB experts to detect and stop web shell attacks in your environment.