{
	"id": "64b48858-ec8b-4b0e-9e03-409fa385aa1c",
	"created_at": "2026-04-06T01:30:53.435587Z",
	"updated_at": "2026-04-10T13:11:21.89903Z",
	"deleted_at": null,
	"sha1_hash": "d937a7c24b94913f4991681106a9260bc5fe583e",
	"title": "GitHub - nsacyber/Mitigating-Web-Shells: Guidance for mitigation web shells. #nsacyber",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 118906,
	"plain_text": "GitHub - nsacyber/Mitigating-Web-Shells: Guidance for mitigation\r\nweb shells. #nsacyber\r\nBy iadgovuser47\r\nArchived: 2026-04-06 01:06:12 UTC\r\nThis repository houses a number of tools and signatures to help defend networks against web shell malware. More\r\ninformation about web shells and the analytics used by the tools here is available in NSA and ASD web shell\r\nmitigation guidance Detect and Prevent Web Shell Malware.\r\nNSA press release\r\nASD press release\r\nTable of Contents\r\nMitigating Web Shells\r\nBackground\r\nDetecting/Blocking Web Shells\r\n\"Known-Good\" file comparison\r\nWinDiff Application\r\nPowerShell utility for known-good comparison\r\nLinux Diff utility for known-good comparison\r\nDetecting anomalous requests in web server logs\r\nSplunk queries for web server logs\r\nPowerShell script for Microsoft IIS logs\r\nPython script for Apache httpd logs\r\nDetecting host artifacts of common web shells\r\nYARA rules for detecting common web shells\r\nDetecting network artifacts of common web shell malware\r\nNetwork signatures for common web shell malware\r\nDetecting unexpected network flows\r\nSnort signatures to detect unexpected network flows\r\nEndpoint Detection and Response (EDR) capabilities\r\nDetecting Web Shells in Windows with Sysmon\r\nDetecting Web Shells in Linux with Auditd\r\nPreventing Web Shells\r\nMcAfee Host Intrusion Prevention System (HIPS) rules to lock down web directories\r\nRelated Content\r\nLicense\r\nContributing\r\nhttps://github.com/nsacyber/Mitigating-Web-Shells\r\nPage 1 of 10\n\nDisclaimer\r\nBackground\r\nWeb shells are malicious files or code snippets that attackers put on compromised web servers to perform\r\narbitrary, attacker-specified actions on the system or return requested data to which the system has access. Web\r\nshells are a well-known attacker technique, but they are often difficult to detect because of their proficiency in\r\nblending in with an existing web application.\r\nDetecting/Blocking Web Shells\r\n\"Known-Good\" file comparison\r\nThe most effective method of discovering most web shells is to compare files on a production web server with a\r\nknown-good version of that application, typically a fresh install of the application where available updates have\r\nbeen applied. Administrators can programmatically compare the production site with the known-good version to\r\nidentify added or changed files. These files can be manually reviewed to verify authenticity. NSA provides\r\ninstructions below on how to perform the file comparison in either a Windows or Linux environment.\r\nWinDiff Application\r\nMicrosoft developed a tool called WinDiff that allows file or directory comparison for ASCII files. In most cases,\r\nthis simple but powerful tool is sufficient for comparing known-good and production images. Details about using\r\nthis utility are provided by Microsoft here.\r\nPowerShell utility for known-good comparison\r\nThe provided PowerShell script will compare two directories, a known-good version and a production image. The\r\nscript will report any new or modified files in the production version. If a web shell is in the web application, then\r\nit will appear on this report. Because of the high likelihood that benign file changes occurring, each result will\r\nneed to be vetted for authenticity.\r\nRequirements\r\nPowerShell v2 or greater\r\nRead access to both the known-good image and the production image\r\nUsage\r\nPS \u003e .\\dirChecker.ps1 -knownGood \"\u003cPATH\u003e\" -productionImage \"\u003cPATH\u003e\"\r\nExample: Scanning default IIS website: PS \u003e .\\dirChecker.ps1 -knownGood .\\knownGoodDir\\ -productionImage\r\n\"C:\\inetpub\\logs\\\"\r\nLinux Diff utility for known-good comparison\r\nhttps://github.com/nsacyber/Mitigating-Web-Shells\r\nPage 2 of 10\n\nMost distributions of Linux include the \"diff\" utility, which compares the contents of files or directories.\r\nRequirements\r\ndiff utility (typically pre-installed on Linux)\r\nRead access to both the known-good image and the production image\r\nUsage\r\n$ diff -r -q \u003cknown-good image\u003e \u003cproduction image\u003e\r\nExample: Scanning default Apache website: $ diff -r -q /path/to/good/image/ /var/www/html/\r\nDetecting anomalous requests in web server logs\r\nBecause they are often designed to blend in with existing web applications, detecting web shells can be difficult.\r\nHowever, some properties of web shells are difficult to disguise or are commonly overlooked by attackers and can\r\nguide defenders to concealed web shells. Of particular interest are the user agent, referrer, and IP address used to\r\naccess the web shell.\r\nUser agent HTTP header: Without an established presence within a network, it is unlikely that an attacker\r\nwill know which user agent strings are common for a particular web server. Therefore, at a minimum, early\r\nweb shell access is likely to be performed using a user agent that is uncommon on a target network.\r\nReferrer HTTP header: For most web applications, each user request is appended with a referrer header\r\nindicating the URL from which the user request originated. The major exception to this is root level pages,\r\nwhich are often bookmarked or accessed directly. Attackers may overlook the referrer tag when disguising\r\ntheir web shell traffic. If so, these requests should appear anomalous in web server logs.\r\nIP Addresses: Depending on the attacker’s tactics and the victim environment, IP addresses used to conduct\r\nthe attack may appear anomalous. For instance, a web application may primarily be visited by internal\r\nusers from a particular subnet. However, the attacker may access the web shell malware from an IP address\r\noutside the normal subnet.\r\nThis analytic is likely to produce significant false positives in many environments, so it should be employed\r\ncautiously. Additionally, attackers who understand this analytic can easily avoid detection. Therefore, this analytic\r\nshould only be one part of a broader defense in depth approach to mitigating web shells.\r\nSplunk queries for web server logs\r\nThe provided Splunk queries can help to identify Uniform Resource Identifiers (URIs) accessed by few User\r\nAgents, IP addresses, or using uncommon Referer [sic] headers. Results of these queries are likely to include\r\nmostly or entirely benign URIs. However, if a web shell is present on the target server, it is likely to be among the\r\nreturned results.\r\nPowerShell script for Microsoft IIS logs\r\nhttps://github.com/nsacyber/Mitigating-Web-Shells\r\nPage 3 of 10\n\nThe provided PowerShell script will attempt to identify anomalous entries in IIS web server logs that could\r\nindicate the presence of a web shell. The script calculates the URIs successfully handled by the server (status code\r\n200-299) which have been requested by the least number of user agents or IP addresses. This analytic will always\r\nproduce results regardless of whether a web shell is present or not. The URIs in the results should be verified\r\nbenign.\r\nRequirements\r\nPowerShell v2 or greater\r\nFull Language Mode of PowerShell enabled (see here)\r\nThis is the default mode for most systems\r\nRead access to IIS logs\r\nUsage\r\nPS \u003e .\\LogCheck.ps1 -logDir \"\u003cpath to IIS log directory\u003e\"\r\nExample: Scanning logs stored at the default IIS location: PS \u003e .\\LogCheck.ps1 -logDir \"C:\\inetpub\\logs\\\"\r\nAdditionally, the size of the percentile returned can be modified with the ‘-percentile N’ option. The default is to\r\nshow URIs in the bottom 5 percentile for unique user agent requests and client IP addresses.\r\nPython script for Apache httpd logs\r\nThe provided Python script will attempt to identify anomalous entries in Apache web server logs that could\r\nindicate the presence of a web shell. The script calculates the URIs successfully handled by the server (status code\r\n200-299) which have been requested by the least number of user agents or IP addresses. This analytic will always\r\nproduce results regardless of whether a web shell is present or not. The URIs in the results should be verified\r\nbenign.\r\nRequirements\r\nPython 3\r\nRead access to Apache logs\r\nUsage\r\n$ LogCheck.py \"\u003cpath to Apache log file\u003e\"\r\nDetecting host artifacts of common web shells\r\nWeb shells are easy to modify without losing functionality and can thus be tailored to avoid host base signatures\r\nsuch as file artifacts. In rare cases, web shells may even run entirely in memory (i.e., fileless execution) making\r\nfile based detection impossible. However, attackers may make little to no modifications to web shells for a variety\r\nof reasons. In these cases, it may be possible to detect common web shells using pattern-matching techniques,\r\nsuch as YARA rules. YARA rules can be imported by a variety of security products or can be run using a\r\nhttps://github.com/nsacyber/Mitigating-Web-Shells\r\nPage 4 of 10\n\nstandalone YARA scanning tool. The instructions below assume use of the standalone YARA scanning tool. For\r\nother security products, consult documentation or talk to the vendor to determine if YARA is supported.\r\nYARA rules for detecting common web shells\r\nThe YARA rules contain a variety of signatures for common web shells and some heuristic approaches to\r\nidentifying artifacts typically found in web shells. Two sets of signatures are provided, core (compiled core rules)\r\nand extended (compiled extended rules). It is recommended to use the compiled versions of the rules, as some\r\nhost-based security systems will falsely flag the uncompiled rules as malicious.\r\ncore rules include only indicators for common web shells that are unlikely to occur in benign web\r\napplication files. These rules should return minimal false positive results but are also less likely to detect\r\nvariations of common shells\r\nextended rules include both indicators for common web shells and indicators of techniques frequently used\r\nin web shells, such as obfuscation, dynamic execution, and encoding. Because these techniques are also\r\nsometimes used in benign web applications, these rules are likely to produce a significant number of false\r\npositive results but are also detect a broader range of web shells.\r\nAdministrators should prioritize vetting results from the core rules before investigating results from the extended\r\nrules. For some applications, the extended rules will result in too many false positives to be useful.\r\nRequirements\r\na YARA compatible security application or the standalone YARA tool (v3+)\r\nfile-level, read access to the web directories for the target web application\r\nUsage\r\n\u003e .\\yara64.exe -r -C \u003cyara file\u003e \u003cpath to web directory\u003e\r\nExample: Scanning default IIS web directories using the base ruleset \u003e .\\yara64.exe -r -C base.yara.bin\r\nC:\\inetpub\\wwwroot\\\r\nExample: Scanning default Apache web directories using the extended ruleset $ yara -r extended.yara.bin\r\n/var/www/html/\r\nDetecting network artifacts of common web shell malware\r\nWeb shells frequently use encryption and encoding to evade network-based detection. Additionally, \"hard-coded\"\r\nparameters can easily be modified to further evade signatures. However, if network architectures allow for TLS\r\ninspection for web servers (e.g., through a reverse proxy or web application firewall), then administrators may be\r\nable to detect unmodified or slightly modified common web shell malware at the network level. Network\r\nsignatures are, at best, only partially effective at detecting web shells and should be used as one part of a defense-in-depth strategy.\r\nNetwork signatures for common web shell malware\r\nhttps://github.com/nsacyber/Mitigating-Web-Shells\r\nPage 5 of 10\n\nThe provided Snort signatures can be used to detect some common web shells that have not been modified to\r\nevade detection. Some intrusion detection/preventions systems and web application firewalls may already\r\nimplement these or other web shell signatures. Organizations are encouraged to understand their existing network\r\nsignature posture in this regard.\r\nDetecting unexpected network flows\r\nIn some cases, web shell traffic will cause unexpected network flows. For example, when a web shell infected\r\nweb server is being used proxy requests into a network, the web server would make web requests to internal\r\nnetwork nodes. This behavior is abnormal and could be easily recognized in network activity logs. Another\r\nexample would be for a non-web server node (e.g., a network device) to suddenly be replying to responding to a\r\nweb requests from outside the network. Administrators should have an intimate network knowledge and\r\nunderstand which protocols that nodes should be using. Contradictions to these norms should be investigated.\r\nSnort signatures to detect unexpected network flows\r\nThe provided Snort signature can aid administrators in identifying unexpected network flows. This signature\r\nsimply alerts when a node in the targeted subnet responds to an HTTP(s) request. This signature should be tailored\r\nfor a specific network by targeting only non-web server nodes.\r\nalert tcp 192.168.1.0/24 [443,80] -\u003e any any (msg: \"potential unexpected web server\"; sid 4000921)\r\nNote: ensure that the subnet above (192.l68.1.0) is changed to something appropriate for the target subnet\r\nEndpoint Detection and Response (EDR) capabilities\r\nSome EDR and enhanced logging solutions may be able to detect web shells based on system call or process\r\nlineage abnormalities. These security products monitor each process on the endpoint including invoked system\r\ncalls. Web shells usually cause the web server process to exhibit unusual behavior. For instance, it is uncommon\r\nfor most benign web servers to launch the ipconfig utility, but this is a common reconnaissance technique enabled\r\nby web shells. EDRs and enhanced logging solutions will have different capabilities, so administrators are\r\nencouraged to understand the solutions available for their environment.\r\nDetecting Web Shells in Windows with Sysmon\r\nMicrosoft Sysmon is a logging tool that enhances logging performed on a Windows system. Among other things,\r\nSysmon logs information about how each process is created. This information is valuable for identifying\r\nanomalous behavior, such as in the case of malicious web shells. Sysmon can be obtained from Microsoft and\r\nmust be installed on a system to begin enhanced logging. Ideally, Sysmon and other Windows logging should be\r\nmirrored to a central Security Information and Event Management (SIEM) server where it can be aggregated and\r\nqueried.\r\nThe query below will report executables launched by an IIS web server process. In many cases, the web\r\napplication will cause IIS to launch a process for entirely benign functionality. However, there are several\r\nhttps://github.com/nsacyber/Mitigating-Web-Shells\r\nPage 6 of 10\n\nexecutables commonly used by attackers for reconnaissance purposes, which are unlikely to be used by a normal\r\nweb application. Some of these executables are listed below.\r\nPowerShell script to identify Sysmon entries for IIS\r\nGet-WinEvent -FilterHashtable @{logname=\"Micorosft-Windows-Sysmon/Operational\";id=1;} | Where\r\n{$_.message -like \"*ParentImage: C:\\Windows\\System32\\inetsrv\\w3wp.exe*\"} | %{$_.properties[4]} | Sort-Object -Property value -Unique\r\nWindows executables commonly used by attackers and rarely launched by benign IIS applications\r\narp.exe\r\nat.exe\r\nbitsadmin.exe\r\ncertutil.exe\r\ncmd.exe\r\ndsget.exe\r\ndsquery.exe\r\nfind.exe\r\nfindstr.exe\r\nfsutil.exe\r\nhostname.exe\r\nipconfig.exe\r\nnbstat.exe\r\nnet.exe\r\nnet1.exe\r\nnetdom.exe\r\nnetsh.exe\r\nnetstat.exe\r\nnltest.exe\r\nnslookup.exe\r\nntdsutil.exe\r\npathping.exe\r\nping.exe\r\npowershell.exe\r\nqprocess.exe\r\nquery.exe\r\nqwinsta.exe\r\nreg.exe\r\nrundll32.exe\r\nsc.exe\r\nschtasks.exe\r\nsysteminfo.exe\r\nhttps://github.com/nsacyber/Mitigating-Web-Shells\r\nPage 7 of 10\n\ntasklist.exe\r\ntracert.exe\r\nver.exe\r\nvssadmin.exe\r\nwevtutil.exe\r\nwhoami.exe\r\nwmic.exe\r\nwusa.exe\r\nDetecting Web Shells in Linux with Auditd\r\nAuditd is the userspace component of the Linux Auditing System. Auditd can provide users with insight into\r\nprocess creation logs. The information is valuable for identifying anomalous behavior, such as in the case of\r\nmalicious web shells. Auditd is available in default repositories for many Linux distributions and must be installed\r\nand configured before it can log relevant web server process data. Ideally, auditd and other Linux logging should\r\nbe mirrored to a central Security Information and Event Management (SIEM) server where it can be aggregated\r\nand queried.\r\nThe query below will report applications launched by an Apache web server process. In many cases, the web\r\napplication will cause Apache to launch a process for entirely benign functionality. However, there are several\r\napplications commonly used by attackers for reconnaissance purposes, which are unlikely to be used by a normal\r\nweb application. Some of these applications are listed below.\r\nConfiguring Auditd\r\n1. Determine the web server uid: After installing auditd (i.e., using \"apt -y install auditd\"), determine the uid\r\nof the web server using: apachectl -S This will return apache details including the user id in a line such\r\nas: User: name=\"www-data\" id=33 Here the uid is \"33\"\r\n2. Add the following auditd rules (/etc/audit/rules.d/audit.rules) replacing \"XX\" with the uid identified above:\r\n-a always,exit -F arch=b32 -F uid=XX -S execve -k apacheexecve -a always,exit -F arch=b64 -F\r\nuid=XX -S execve -k apacheexecve\r\n3. Restart auditd: service auditd restart\r\nReviewing Auditd Log\r\n1. Identify applications launched by Apache with: cat /var/log/auditd/audit.* | grep \"apacheexecve\"\r\nThis will return the path to the launched application (see bolded path in the example output below):\r\ntype=SYSCALL msg=audit(1581519503.841:47): arch=c000003e syscall=59 success=yes exit=0\r\na0=563e412cbbd8 a1=563e412cbb60 a2=563e412cbb78 a3=7f065d5e5810 items=2 ppid=15483\r\npid=15484 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33 egid=33 sgid=33 fsgid=33 tty=\r\n(none) ses=4294967295 comm=\"cat\" exe=\"/bin/cat\" key=\"apacheexecve\"\r\n2. Analyze the results to determine if unusual applications are launched (see list below)\r\nhttps://github.com/nsacyber/Mitigating-Web-Shells\r\nPage 8 of 10\n\n3. Detailed information, including call arguments, can be obtained using: /var/log/auditd/audit.* | grep\r\n\"msg=audit(1581519503.841:47)\" Replace the value of msg=audit with the value returned in step #1\r\nLinux applications commonly used by attackers and rarely launched by benign Apache applications\r\ncat\r\ncrontab\r\nhostname\r\nifconfig\r\nip\r\niptables\r\nls\r\nnetstat\r\npwd\r\nroute\r\nuname\r\nwhoami\r\nPreventing Web Shells\r\nMcAfee Host Intrusion Prevention System (HIPS) rules to lock down web directories\r\nWeb shells almost always rely on modifying existing web application files or creating new files in a web\r\naccessible directory. Using a file integrity monitoring system can block file changes to a specific directory or alert\r\nwhen changes occur. The provided McAfee Host Intrusion Prevention System rules can be tailored for a specific\r\nweb application to block file system changes that web shell exploitation usually relies on. Other file integrity\r\nmonitoring systems are likely able to accomplish similar blocking as well; consult documentation or seek vendor\r\nguidance for other such products.\r\nRequirements\r\nMcAfee Host Based Security System (HBSS)\r\nUsage\r\nHIPS File integrity rules can be added to HBSS through the ePolicy Orchestrator portal. Before adding the rules,\r\nadministrators should tailor them the target environment. This is initially done by modifying the \"Include\" path to\r\ntarget one or more web applications. Then exceptions to the rule can be added on the signature page under the\r\nexception rule tab. Exceptions should include things like allowed file extensions of benign file types that the target\r\nweb application is required to handle (e.g., \".pdf\", \".jpg\", \".png\"). HIPS rules should be added as an Informational\r\nalert (Level 1) for logging purposes to help administrators identify possible exceptions to the rule. Once\r\nadministrators are confident that exceptions have been added, the rule(s) should be changed to Level 4 to block\r\nfile changes.\r\nhttps://github.com/nsacyber/Mitigating-Web-Shells\r\nPage 9 of 10\n\nRelated Content\r\nDate Press Release Report\r\n2021-\r\n07-01\r\nNSA, Partners Release Cybersecurity\r\nAdvisory on Brute Force Global Cyber\r\nCampaign\r\nCSA: Russian GRU Conducting Global Brute Force\r\nCampaign to Compromise Enterprise and Cloud\r\nEnvironments\r\n2021-\r\n05-07\r\nNSA CISA, FBI, and the UK NCSC\r\nfurther expose Russian Intelligence Cyber\r\nTactics\r\nCSA: Further TTPs associated with SVR cyber\r\nactors\r\n2021-\r\n04-15\r\nn/a\r\nCSA: Russian SVR Targets U.S. and Allied\r\nNetworks\r\nLicense\r\nSee LICENSE.\r\nContributing\r\nSee CONTRIBUTING.\r\nDisclaimer\r\nSee DISCLAIMER.\r\nSource: https://github.com/nsacyber/Mitigating-Web-Shells\r\nhttps://github.com/nsacyber/Mitigating-Web-Shells\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://github.com/nsacyber/Mitigating-Web-Shells"
	],
	"report_names": [
		"Mitigating-Web-Shells"
	],
	"threat_actors": [],
	"ts_created_at": 1775439053,
	"ts_updated_at": 1775826681,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d937a7c24b94913f4991681106a9260bc5fe583e.pdf",
		"text": "https://archive.orkl.eu/d937a7c24b94913f4991681106a9260bc5fe583e.txt",
		"img": "https://archive.orkl.eu/d937a7c24b94913f4991681106a9260bc5fe583e.jpg"
	}
}