{
	"id": "38093e84-5daf-4d61-8d24-e5590919db8e",
	"created_at": "2026-04-06T00:09:19.733918Z",
	"updated_at": "2026-04-10T03:21:56.187887Z",
	"deleted_at": null,
	"sha1_hash": "dff84bf89f565aaa93b2f7a2730bbc5d3054260a",
	"title": "What Is a Web Shell? How to Detect Web Shells and Protect Your Web Server",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2430182,
	"plain_text": "What Is a Web Shell? How to Detect Web Shells and Protect Your\r\nWeb Server\r\nBy Pavle Culum, Roman Kroshinsky\r\nPublished: 2022-09-28 · Archived: 2026-04-05 15:17:25 UTC\r\nUpdated June 5, 2025\r\nIn this article, we look at common web shell functionality, encryption, and obfuscation techniques, as well as\r\nseveral web shell management frameworks. Next, we will explore detection and investigation opportunities,\r\nfollowed by an example of reversing the obfuscation or encryption scheme of an example web shell. Finally, we\r\nwill discuss proactive infrastructure protection measures that reduce the likelihood of successful web shell activity\r\nagainst managed systems.\r\nTable of Contents\r\nWhat Is a Web Shell?\r\nWeb Shell Functionality\r\nCommon Web Shell Management Frameworks\r\nHow to Detect and Investigate Web Shells\r\nWeb Shell Deobfuscation\r\nWeb Shell Protection\r\nFAQs\r\nConclusion\r\nA web shell is an internet-accessible malicious file implanted in a victim web server’s file system that enables an\r\nattacker to execute commands by visiting a web page. Once placed on a compromised web server, it allows an\r\nattacker to perform remote command execution to the operating system running on the host machine. The web\r\nshell provides the attacker with a form of persistence in the compromised system and the potential to further pivot\r\nthrough the network to compromise hosts and data that may not otherwise be externally accessible.\r\nSuccess of a targeted cyber attack is often directly related to the efficacy of the initial access to the victim’s\r\nenvironment and how well it can be leveraged. Threat groups who establish their initial access through the\r\nexploitation of a web application vulnerability often opt to use web shells to further facilitate their ability to\r\noperate efficiently within the context of the foothold system.\r\nWeb Shell Functionality\r\nMany web application programming languages implement functions such as exec() , eval() , system() , and\r\nos() , or process strings as syntax with special characters (such as “`”, or backtick, in the case of PHP) that can\r\nbe used to execute system commands. In cyber attacks, threat groups abuse this functionality by smuggling these\r\ndefault functions and commands via web shells, allowing for remote tasking and code execution. The scope and\r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 1 of 11\n\nbreadth of code execution are arbitrary and only limited by the capabilities of the underlying victim server\r\noperating system shell.\r\nSome of the common post-installation reconnaissance commands that attackers initially use include:\r\nwhoami\r\nnetstat\r\nip route or route print\r\nls –latr or dir\r\nuname –a or systeminfo\r\nifconfig or ipconfig\r\nThis set of commands allows the attackers to get their bearings within the victim system and understand what kind\r\nof privileges are available from the perspective of the compromised server. Additionally, attackers gain the ability\r\nto discover what applications and data reside on the local file system and perform additional reconnaissance to\r\ndetermine their next action in relation to escalating access or moving laterally to another host.\r\nFigure 1. Simple PHP web shell example.\r\nFigure 2. Simple ASPX web shell example.\r\nFigure 3. Simple JSP web shell example.\r\nWhile attackers may opt to upload new files to the compromised web servers to enable web shell functionality,\r\nthey may also append web shell functionality and code to an existing resource hosted on the server. An attacker\r\nmay prefer this action to avoid raising potential suspicion in the event that file creation events are monitored.\r\nComplicating matters further, an attacker may identify a web application parameter that is already being used as\r\ninput inside of one of these risky default functions (a web form or an interactive application), thereby facilitating\r\nweb shell functionality without requiring the attacker to upload a backdoor to the victim server. While this\r\napproach has the downside of having the remote tasking input and output flowing across the network without any\r\nobfuscation (allowing for potential detection by monitoring services), this capability would be used briefly to\r\ngraduate remote access to a more covert method.\r\nWeb shell behavior is highly dependent on the configuration of the compromised web service. Rather than\r\nopening a new service on the network, like a traditional bind implant (which would be relatively simple to detect\r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 2 of 11\n\nand alert on), web shells most often use the preexisting HTTP(S) service already hosted on the victim system to\r\nfacilitate backdoor access. For example, if the web service is hosted on HTTP 80/TCP, the web shell will be\r\naccessible via HTTP 80/TCP. However, if the web service is hosted on HTTPS 443/TCP, the web shell will also\r\nuse 443/TCP and inherit any existing SSL/TLS configuration, including using the legitimate victim web\r\napplication SSL/TLS certificate and all associated metadata for connections flowing to the web shell. This is one\r\nof the reasons why web shells have the potential to go undetected for a longer duration compared to other types of\r\nimplants. They are simply buried too deep in the daily HTTP noise.\r\nTo avoid detection, threat actors rely on obfuscation techniques which are commonly chained together in order to\r\nhide the true functionality of the web shell. These techniques are often used in combination and include, but are\r\nnot limited to:\r\nString rotations\r\nArray segmentation\r\nHex encoding\r\nBase64 encoding\r\nCompression\r\nWhitespace removal\r\nMany web shells observed in the wild also encrypt the remote command input and output through hard-coded pre-shared keys. While code obfuscation or encryption isn’t a new concept in the context of cyber attacks, it\r\nintroduces an additional layer of challenge when it comes to detecting and investigating web shell implants.\r\nCommon Web Shell Management Frameworks\r\nThe desire to enhance and automate tradecraft has led to development of various fully featured web shell\r\nmanagement frameworks alongside continuous improvements and automation functionality. Table 1 lists some of\r\nthe publicly available web shell management frameworks which have been used in the more recent events.\r\nWeb Shell Framework Source\r\nAntSword https://github.com/AntSwordProject/antSword\r\nBehinder https://github.com/rebeyond/Behinder\r\nGodzilla https://github.com/BeichenDream/Godzilla\r\nTable 1. Public web shell management frameworks.\r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 3 of 11\n\nWhile some frameworks are relatively simple scripts, others come with a myriad of functionality, ease-of-use\r\nelements, and modular capabilities. This makes web shells extremely potent as a threat vector and provides\r\nattackers with a multitude of options during their attack.\r\nThe figures below demonstrate sample HTTP requests and responses for web shell interactions using these\r\nframeworks:\r\nFigure 4. Godzilla web shell POST request and response. (Click image for larger size.)\r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 4 of 11\n\nFigure 5. Behinder web shell POST request. (Click image for larger size.)\r\nFigure 6. Behinder web shell server response. (Click for larger size.)\r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 5 of 11\n\nFigure 7. AntSword web shell POST request and response. (Click image for larger size.)\r\nIf the attack objective requires access to other systems beyond the compromised web server, the attacker can use\r\nthe web shell to relay subsequent interactions to other systems of interest. To increase the pace of killchain\r\nexecution, an attacker may use the web shell to establish SOCKS tunneling capabilities that can facilitate\r\nsubsequent access to specific networked applications and resources internal to the organization.\r\nHow to Detect and Investigate Web Shells\r\nIn previous sections, we discussed how input provided during an HTTP client request can contain malicious\r\ninstructions. Therefore, a key element of network-based web shell detection is to identify the presence of\r\noperating system commands associated with administrative/situational awareness operations within the contents of\r\ninbound web traffic flows.\r\nThere are several inherent challenges in detecting and investigating web shells that analysts should be aware of.\r\nThe heavy use of layered obfuscation techniques can evade static signature-based detections with relative ease\r\nwhile also making it challenging for the analysts to perform manual analysis on PCAPs and web logs.\r\nAdditionally, web shells are passive implants and don’t require regular “keep-alives” with the C2 infrastructure,\r\nfurther avoiding pattern-based detection mechanisms.\r\nTo increase probability and confidence in web shell detection efforts, analysts should:\r\nIdentify patterns: Look for a combination of potentially suspicious sets of events relating to inbound\r\nHTTP(S) flows. For example, tracking access attempts to specific web pages without valid referrers or\r\nhistoric precedents, unique or never-before-seen user agents, or anomalous GET/POST requests flowing to\r\na web server without a corresponding set of prior activity.\r\nPerform statistical/anomaly-based analytics: Get comprehensive visibility into web traffic patterns to\r\nbuild a baseline of aggregated network traffic flows. Compare expected inputs (baseline data) versus abuse\r\nof dynamic content on a web application. When used in conjunction with an understanding of adversary\r\ntechniques and operations, powerful, intelligence-informed models can flag potential web shell activity in\r\nvictim networks.\r\nTrack URIs: If a web shell were to be planted onto an external facing asset into a net-new file, interaction\r\nwith the web shell would transit using an endpoint or URI that had not previously existed and would be\r\nvisited by less than a handful of source IP addresses over a set period of time.\r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 6 of 11\n\nCompare URIs to existing files: In cases where the attacker opts to implant web shell functionality to an\r\nexisting file, focus on validating the contents of the existing files and cross referencing them against URI\r\ntraffic patterns to those resources. Use identified source IP addresses associated with access to a previously\r\nunknown URI to determine if subsequent traffic remains limited to the suspected web shell URI or if there\r\nare other requests to legitimate pages on the destination server or other servers on the perimeter.\r\nWeb Shell Deobfuscation\r\nWhen investigating suspected web shell implants and network traffic, analysts benefit from rapidly testing\r\ndecryption schemes with the aid of tools such as Cyberchef. The following is an example of analysis of the default\r\nBehinder web shell template. Behinder web shell accepts attacker input from HTTP POST requests. Attacker input\r\nis shaped by the Behinder client to be a valid class written in the syntax of the target web server, in this case PHP.\r\nFigure 8. Behinder web shell sample. (Click image for larger size.)\r\nTo recover attacker instructions from network traffic requires recovery of the hardcoded pre-shared key from the\r\nweb shell script. In this case, the default AES key supplied by the source code is “ e45e329feb5d925b ” (first 16\r\ncharacters of the MD5 hash of the “ rebeyond ” string). The contents are base64 encoded before being AES\r\nencrypted, so the string must be decoded prior to the encryption key being used:\r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 7 of 11\n\nFigure 9. Decoding and decrypting the obfuscated string. (Click image for larger size.)\r\nDeobfuscating the string reveals the arbitrary instructions passed to the server as a PHP class. Operator\r\ninstructions to the web shell are encoded inside of the $cmd parameter:\r\nFigure 10. Contents of the deobfuscated function. (Click image for larger size.)\r\nThe value of the cmd parameter is base64 decoded before being evaluated. In the case of our example, the\r\ncommand “ Y2QgL3Zhci93d3cvaHRtbC87d2hvYW1p ” decodes to cd /var/www/html/;whoami:\r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 8 of 11\n\nFigure 11. Decoded system command. (Click image for larger size.)\r\nWhile obfuscation techniques can mask the contents of a script, in cases where TLS is not being used, the query\r\nresponses from the server will be displayed in plain text via the web logs and PCAPs. To remain stealthy under\r\nthese conditions, attackers opt to also encrypt their web shell responses using the same hardcoded pre-shared key.\r\nSuccessfully deobfuscating the script explains what the script is capable of. However, obtaining the pre-shared key\r\ncan be further used to understand what input was issued and what output was produced from a compromised asset.\r\nThis information can be leveraged in the event that a packet capture or HTTP application content logs of the event\r\nare generated and made available to the analysts.\r\nWeb Shell Protection\r\nIn terms of web server hardening, there are a few measures that can be taken to limit the functionality of\r\npotentially implanted web shells.\r\nAvoid using dangerous operations and methods: Web applications should avoid using dangerous\r\noperations and methods including, but not limited to: exec() , eval() , or os()\r\nFollow Robust input validation and sanitization best practices: Practices including OWASP Proactive\r\nControl C5: Validate all Inputs, should be followed and implemented during the software development life\r\ncycle (SDLC), as well as validated periodically through recurring application security testing.\r\nInvestigating potential and detecting actual web shell activity: This requires maturity within the\r\nsecurity organization, including, but not limited to, timely access to:\r\nAn up-to-date, accurate hardware inventory\r\nAn up-to-date, accurate software inventory\r\nNetwork traffic flow logs for traffic to and from any zone that hosts web applications and services\r\nWeb server logs\r\nFAQs\r\nHow does a web shell attack work?\r\nA web shell is a common cyber attack technique used by attackers to gain access to an organization’s server or\r\ndatabase. Attackers will upload malicious scripts to a web server known as a web shell script. Then, they acquire\r\nroot account access, which they can use to execute commands remotely via a web interface. \r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 9 of 11\n\nHow do attackers use web shells?\r\nAttackers use web shells to obfuscate malicious activity and gain access to an organization’s server. Access is not\r\ntemporary but persistent, meaning they can return later and continue the attack. Attackers use a web server to\r\nexecute system commands and move laterally within a network.\r\nWhat are common web shell functionalities?\r\nUsing a web shell, attackers can:\r\nExecute commands: Attackers use web shells to remotely execute commands on an organization’s server\r\nvia a web browser.\r\nSteal data: With root account access, attackers can access sensitive data and confidential information.\r\nManipulate files: Attackers can manipulate any files on an organization’s server, whether that may be\r\nPDFs, documents, or website files.\r\nTunnel: Depending on the capabilities of your server, attackers may be able to use web shells to access\r\nadditional systems.\r\nLaunch DDoS attacks: With access to your server, attackers can flood your network with traffic and cause\r\nservice overloads and outages\r\nDistribute malware: Attackers can use web shells to infect website visitors with malware. \r\nHow do you detect web shells?\r\nTo monitor for webshells, it’s important to:\r\nAnalyze web logs: Keep an eye out for suspicious activities like requests to files or suspicious payloads.\r\nMonitor files: Unexpected changes to files may be a sign of a cyber attack.\r\nLook for unusual activity: Keep an eye out for users with excess privileges.\r\nMonitor application behavior: Use tools for application filtering to identify suspicious behavior and signs\r\nof web shell activity.\r\nBuild a zero trust architecture: Building a zero trust architecture helps detect web shells by continuously\r\nverifying user and device identities, enforcing least-privilege access, and monitoring all traffic, even within\r\nthe network.\r\nHow does Gigamon help protect against web shell attacks?\r\nGigamon provides deep observability and advanced threat detection to identify web shell attacks before they can\r\ndo damage. Our tools make it easy to monitor threats and take preventative steps to mitigate cyber attacks.\r\n Gigamon can also help your organization build a zero trust architecture. Require every user on every device to\r\nauthenticate before they can access your network. In the event that a web shell attack occurs, an attacker won’t be\r\nable to access any systems or applications within your server.\r\nConclusion\r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 10 of 11\n\nOnce an adversary achieves initial access to a web server, deploying one or multiple web shells has been observed\r\nto be a common next step in the attack lifecycle. Organizations can gain insight into potential web shell activity by\r\nanalyzing highly available NetFlow data. The network profile of client interaction with a web server when\r\nsearching for an attack vector is distinct from interaction with a web shell that has been successfully\r\noperationalized. These network profiles can be observed within network metadata regardless of the obfuscation\r\nand encryption schemes used by the attacker.\r\nCombining these investigative techniques alongside proactively employing infrastructure hardening measures,\r\norganizations can detect and eliminate web shell attacks in their earliest stages.\r\nReady to get started?\r\nSource: https://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nhttps://blog.gigamon.com/2022/09/28/investigating-web-shells/\r\nPage 11 of 11\n\n https://blog.gigamon.com/2022/09/28/investigating-web-shells/   \nFigure 5. Behinder web shell POST request. (Click image for larger size.)\nFigure 6. Behinder web shell server response. (Click for larger size.)\n  Page 5 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.gigamon.com/2022/09/28/investigating-web-shells/"
	],
	"report_names": [
		"investigating-web-shells"
	],
	"threat_actors": [],
	"ts_created_at": 1775434159,
	"ts_updated_at": 1775791316,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dff84bf89f565aaa93b2f7a2730bbc5d3054260a.pdf",
		"text": "https://archive.orkl.eu/dff84bf89f565aaa93b2f7a2730bbc5d3054260a.txt",
		"img": "https://archive.orkl.eu/dff84bf89f565aaa93b2f7a2730bbc5d3054260a.jpg"
	}
}