• Stars
    star
    951
  • Rank 48,061 (Top 1.0 %)
  • Language YARA
  • License
    Other
  • Created almost 5 years ago
  • Updated over 1 year ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Guidance for mitigation web shells. #nsacyber

Mitigating Web Shells

This repository houses a number of tools and signatures to help defend networks against web shell malware. More information about web shells and the analytics used by the tools here is available in NSA and ASD web shell mitigation guidance Detect and Prevent Web Shell Malware.

Table of Contents

Background

Web shells are malicious files or code snippets that attackers put on compromised web servers to perform arbitrary, attacker-specified actions on the system or return requested data to which the system has access. Web shells are a well-known attacker technique, but they are often difficult to detect because of their proficiency in blending in with an existing web application.

Detecting/Blocking Web Shells

"Known-Good" file comparison

The most effective method of discovering most web shells is to compare files on a production web server with a known-good version of that application, typically a fresh install of the application where available updates have been applied. Administrators can programmatically compare the production site with the known-good version to identify added or changed files. These files can be manually reviewed to verify authenticity. NSA provides instructions below on how to perform the file comparison in either a Windows or Linux environment.

WinDiff Application

Microsoft developed a tool called WinDiff that allows file or directory comparison for ASCII files. In most cases, this simple but powerful tool is sufficient for comparing known-good and production images. Details about using this utility are provided by Microsoft here.

PowerShell utility for known-good comparison

The provided PowerShell script will compare two directories, a known-good version and a production image. The script will report any new or modified files in the production version. If a web shell is in the web application, then it will appear on this report. Because of the high likelihood that benign file changes occurring, each result will need to be vetted for authenticity.

Requirements
  • PowerShell v2 or greater
  • Read access to both the known-good image and the production image
Usage

PS > .\dirChecker.ps1 -knownGood "<PATH>" -productionImage "<PATH>"

Example: Scanning default IIS website: PS > .\dirChecker.ps1 -knownGood .\knownGoodDir\ -productionImage "C:\inetpub\logs\"

Linux Diff utility for known-good comparison

Most distributions of Linux include the "diff" utility, which compares the contents of files or directories.

Requirements
  • diff utility (typically pre-installed on Linux)
  • Read access to both the known-good image and the production image
Usage

$ diff -r -q <known-good image> <production image>

Example: Scanning default Apache website: $ diff -r -q /path/to/good/image/ /var/www/html/

Detecting anomalous requests in web server logs

Because they are often designed to blend in with existing web applications, detecting web shells can be difficult. However, some properties of web shells are difficult to disguise or are commonly overlooked by attackers and can guide defenders to concealed web shells. Of particular interest are the user agent, referrer, and IP address used to access the web shell.

  • User agent HTTP header: Without an established presence within a network, it is unlikely that an attacker will know which user agent strings are common for a particular web server. Therefore, at a minimum, early web shell access is likely to be performed using a user agent that is uncommon on a target network.
  • Referrer HTTP header: For most web applications, each user request is appended with a referrer header indicating the URL from which the user request originated. The major exception to this is root level pages, which are often bookmarked or accessed directly. Attackers may overlook the referrer tag when disguising their web shell traffic. If so, these requests should appear anomalous in web server logs.
  • IP Addresses: Depending on the attacker’s tactics and the victim environment, IP addresses used to conduct the attack may appear anomalous. For instance, a web application may primarily be visited by internal users from a particular subnet. However, the attacker may access the web shell malware from an IP address outside the normal subnet.

This analytic is likely to produce significant false positives in many environments, so it should be employed cautiously. Additionally, attackers who understand this analytic can easily avoid detection. Therefore, this analytic should only be one part of a broader defense in depth approach to mitigating web shells.

Splunk queries for web server logs

The provided Splunk queries can help to identify Uniform Resource Identifiers (URIs) accessed by few User Agents, IP addresses, or using uncommon Referer [sic] headers. Results of these queries are likely to include mostly or entirely benign URIs. However, if a web shell is present on the target server, it is likely to be among the returned results.

PowerShell script for Microsoft IIS logs

The provided PowerShell script will attempt to identify anomalous entries in IIS web server logs that could indicate the presence of a web shell. The script calculates the URIs successfully handled by the server (status code 200-299) which have been requested by the least number of user agents or IP addresses. This analytic will always produce results regardless of whether a web shell is present or not. The URIs in the results should be verified benign.

Requirements
  • PowerShell v2 or greater
  • Full Language Mode of PowerShell enabled (see here)
    • This is the default mode for most systems
  • Read access to IIS logs
Usage

PS > .\LogCheck.ps1 -logDir "<path to IIS log directory>"

Example: Scanning logs stored at the default IIS location: PS > .\LogCheck.ps1 -logDir "C:\inetpub\logs\"

Additionally, the size of the percentile returned can be modified with the β€˜-percentile N’ option. The default is to show URIs in the bottom 5 percentile for unique user agent requests and client IP addresses.

Python script for Apache httpd logs

The provided Python script will attempt to identify anomalous entries in Apache web server logs that could indicate the presence of a web shell. The script calculates the URIs successfully handled by the server (status code 200-299) which have been requested by the least number of user agents or IP addresses. This analytic will always produce results regardless of whether a web shell is present or not. The URIs in the results should be verified benign.

Requirements
  • Python 3
  • Read access to Apache logs
Usage

$ LogCheck.py "<path to Apache log file>"

Detecting host artifacts of common web shells

Web shells are easy to modify without losing functionality and can thus be tailored to avoid host base signatures such as file artifacts. In rare cases, web shells may even run entirely in memory (i.e., fileless execution) making file based detection impossible. However, attackers may make little to no modifications to web shells for a variety of reasons. In these cases, it may be possible to detect common web shells using pattern-matching techniques, such as YARA rules. YARA rules can be imported by a variety of security products or can be run using a standalone YARA scanning tool. The instructions below assume use of the standalone YARA scanning tool. For other security products, consult documentation or talk to the vendor to determine if YARA is supported.

YARA rules for detecting common web shells

The YARA rules contain a variety of signatures for common web shells and some heuristic approaches to identifying artifacts typically found in web shells. Two sets of signatures are provided, core (compiled core rules) and extended (compiled extended rules). It is recommended to use the compiled versions of the rules, as some host-based security systems will falsely flag the uncompiled rules as malicious.

  • core rules include only indicators for common web shells that are unlikely to occur in benign web application files. These rules should return minimal false positive results but are also less likely to detect variations of common shells
  • extended rules include both indicators for common web shells and indicators of techniques frequently used in web shells, such as obfuscation, dynamic execution, and encoding. Because these techniques are also sometimes used in benign web applications, these rules are likely to produce a significant number of false positive results but are also detect a broader range of web shells.

Administrators should prioritize vetting results from the core rules before investigating results from the extended rules. For some applications, the extended rules will result in too many false positives to be useful.

Requirements
  • a YARA compatible security application or the standalone YARA tool (v3+)
  • file-level, read access to the web directories for the target web application
Usage

> .\yara64.exe -r -C <yara file> <path to web directory>

Example: Scanning default IIS web directories using the base ruleset > .\yara64.exe -r -C base.yara.bin C:\inetpub\wwwroot\

Example: Scanning default Apache web directories using the extended ruleset $ yara -r extended.yara.bin /var/www/html/

Detecting network artifacts of common web shell malware

Web shells frequently use encryption and encoding to evade network-based detection. Additionally, "hard-coded" parameters can easily be modified to further evade signatures. However, if network architectures allow for TLS inspection for web servers (e.g., through a reverse proxy or web application firewall), then administrators may be able to detect unmodified or slightly modified common web shell malware at the network level. Network signatures are, at best, only partially effective at detecting web shells and should be used as one part of a defense-in-depth strategy.

Network signatures for common web shell malware

The provided Snort signatures can be used to detect some common web shells that have not been modified to evade detection. Some intrusion detection/preventions systems and web application firewalls may already implement these or other web shell signatures. Organizations are encouraged to understand their existing network signature posture in this regard.

Detecting unexpected network flows

In some cases, web shell traffic will cause unexpected network flows. For example, when a web shell infected web server is being used proxy requests into a network, the web server would make web requests to internal network nodes. This behavior is abnormal and could be easily recognized in network activity logs. Another example would be for a non-web server node (e.g., a network device) to suddenly be replying to responding to a web requests from outside the network. Administrators should have an intimate network knowledge and understand which protocols that nodes should be using. Contradictions to these norms should be investigated.

Snort signatures to detect unexpected network flows

The provided Snort signature can aid administrators in identifying unexpected network flows. This signature simply alerts when a node in the targeted subnet responds to an HTTP(s) request. This signature should be tailored for a specific network by targeting only non-web server nodes.

alert tcp 192.168.1.0/24 [443,80] -> any any (msg: "potential unexpected web server"; sid 4000921)

Note: ensure that the subnet above (192.l68.1.0) is changed to something appropriate for the target subnet

Endpoint Detection and Response (EDR) capabilities

Some EDR and enhanced logging solutions may be able to detect web shells based on system call or process lineage abnormalities. These security products monitor each process on the endpoint including invoked system calls. Web shells usually cause the web server process to exhibit unusual behavior. For instance, it is uncommon for most benign web servers to launch the ipconfig utility, but this is a common reconnaissance technique enabled by web shells. EDRs and enhanced logging solutions will have different capabilities, so administrators are encouraged to understand the solutions available for their environment.

Detecting Web Shells in Windows with Sysmon

Microsoft Sysmon is a logging tool that enhances logging performed on a Windows system. Among other things, Sysmon logs information about how each process is created. This information is valuable for identifying anomalous behavior, such as in the case of malicious web shells. Sysmon can be obtained from Microsoft and must be installed on a system to begin enhanced logging. Ideally, Sysmon and other Windows logging should be mirrored to a central Security Information and Event Management (SIEM) server where it can be aggregated and queried.

The query below will report executables launched by an IIS web server process. In many cases, the web application will cause IIS to launch a process for entirely benign functionality. However, there are several executables commonly used by attackers for reconnaissance purposes, which are unlikely to be used by a normal web application. Some of these executables are listed below.

PowerShell script to identify Sysmon entries for IIS

Get-WinEvent -FilterHashtable @{logname="Micorosft-Windows-Sysmon/Operational";id=1;} | Where {$_.message -like "*ParentImage: C:\Windows\System32\inetsrv\w3wp.exe*"} | %{$_.properties[4]} | Sort-Object -Property value -Unique

Windows executables commonly used by attackers and rarely launched by benign IIS applications
  • arp.exe
  • at.exe
  • bitsadmin.exe
  • certutil.exe
  • cmd.exe
  • dsget.exe
  • dsquery.exe
  • find.exe
  • findstr.exe
  • fsutil.exe
  • hostname.exe
  • ipconfig.exe
  • nbstat.exe
  • net.exe
  • net1.exe
  • netdom.exe
  • netsh.exe
  • netstat.exe
  • nltest.exe
  • nslookup.exe
  • ntdsutil.exe
  • pathping.exe
  • ping.exe
  • powershell.exe
  • qprocess.exe
  • query.exe
  • qwinsta.exe
  • reg.exe
  • rundll32.exe
  • sc.exe
  • schtasks.exe
  • systeminfo.exe
  • tasklist.exe
  • tracert.exe
  • ver.exe
  • vssadmin.exe
  • wevtutil.exe
  • whoami.exe
  • wmic.exe
  • wusa.exe

Detecting Web Shells in Linux with Auditd

Auditd is the userspace component of the Linux Auditing System. Auditd can provide users with insight into process creation logs. The information is valuable for identifying anomalous behavior, such as in the case of malicious web shells. Auditd is available in default repositories for many Linux distributions and must be installed and configured before it can log relevant web server process data. Ideally, auditd and other Linux logging should be mirrored to a central Security Information and Event Management (SIEM) server where it can be aggregated and queried.

The query below will report applications launched by an Apache web server process. In many cases, the web application will cause Apache to launch a process for entirely benign functionality. However, there are several applications commonly used by attackers for reconnaissance purposes, which are unlikely to be used by a normal web application. Some of these applications are listed below.

Configuring Auditd
  1. Determine the web server uid: After installing auditd (i.e., using "apt -y install auditd"), determine the uid of the web server using: apachectl -S This will return apache details including the user id in a line such as: User: name="www-data" id=33 Here the uid is "33"

  2. Add the following auditd rules (/etc/audit/rules.d/audit.rules) replacing "XX" with the uid identified above: -a always,exit -F arch=b32 -F uid=XX -S execve -k apacheexecve -a always,exit -F arch=b64 -F uid=XX -S execve -k apacheexecve

  3. Restart auditd: service auditd restart

Reviewing Auditd Log
  1. Identify applications launched by Apache with: cat /var/log/auditd/audit.* | grep "apacheexecve" This will return the path to the launched application (see bolded path in the example output below): type=SYSCALL msg=audit(1581519503.841:47): arch=c000003e syscall=59 success=yes exit=0 a0=563e412cbbd8 a1=563e412cbb60 a2=563e412cbb78 a3=7f065d5e5810 items=2 ppid=15483 pid=15484 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33 egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="cat" exe="/bin/cat" key="apacheexecve"

  2. Analyze the results to determine if unusual applications are launched (see list below)

  3. Detailed information, including call arguments, can be obtained using: /var/log/auditd/audit.* | grep "msg=audit(1581519503.841:47)" Replace the value of msg=audit with the value returned in step #1

Linux applications commonly used by attackers and rarely launched by benign Apache applications
  • cat
  • crontab
  • hostname
  • ifconfig
  • ip
  • iptables
  • ls
  • netstat
  • pwd
  • route
  • uname
  • whoami

Preventing Web Shells

McAfee Host Intrusion Prevention System (HIPS) rules to lock down web directories

Web shells almost always rely on modifying existing web application files or creating new files in a web accessible directory. Using a file integrity monitoring system can block file changes to a specific directory or alert when changes occur. The provided McAfee Host Intrusion Prevention System rules can be tailored for a specific web application to block file system changes that web shell exploitation usually relies on. Other file integrity monitoring systems are likely able to accomplish similar blocking as well; consult documentation or seek vendor guidance for other such products.

Requirements

  • McAfee Host Based Security System (HBSS)

Usage

HIPS File integrity rules can be added to HBSS through the ePolicy Orchestrator portal. Before adding the rules, administrators should tailor them the target environment. This is initially done by modifying the "Include" path to target one or more web applications. Then exceptions to the rule can be added on the signature page under the exception rule tab. Exceptions should include things like allowed file extensions of benign file types that the target web application is required to handle (e.g., ".pdf", ".jpg", ".png"). HIPS rules should be added as an Informational alert (Level 1) for logging purposes to help administrators identify possible exceptions to the rule. Once administrators are confident that exceptions have been added, the rule(s) should be changed to Level 4 to block file changes.

Related Content

Date Press Release Report
2021-07-01 NSA, Partners Release Cybersecurity Advisory on Brute Force Global Cyber Campaign CSA: Russian GRU Conducting Global Brute Force Campaign to Compromise Enterprise and Cloud Environments
2021-05-07 NSA CISA, FBI, and the UK NCSC further expose Russian Intelligence Cyber Tactics CSA: Further TTPs associated with SVR cyber actors
2021-04-15 n/a CSA: Russian SVR Targets U.S. and Allied Networks

License

See LICENSE.

Contributing

See CONTRIBUTING.

Disclaimer

See DISCLAIMER.

More Repositories

1

Windows-Secure-Host-Baseline

Configuration guidance for implementing the Windows 10 and Windows Server 2016 DoD Secure Host Baseline settings. #nsacyber
HTML
1,538
star
2

WALKOFF

A flexible, easy to use, automation framework allowing users to integrate their capabilities and devices to cut through the repetitive, tedious tasks slowing them down. #nsacyber
Python
1,191
star
3

goSecure

An easy to use and portable Virtual Private Network (VPN) system built with Linux and a Raspberry Pi. #nsacyber
Python
971
star
4

GRASSMARLIN

Provides situational awareness of Industrial Control Systems (ICS) and Supervisory Control and Data Acquisition (SCADA) networks in support of network security assessments. #nsacyber
Java
910
star
5

Event-Forwarding-Guidance

Configuration guidance for implementing collection of security relevant Windows Event Log events by using Windows Event Forwarding. #nsacyber
PowerShell
840
star
6

Hardware-and-Firmware-Security-Guidance

Guidance for the Spectre, Meltdown, Speculative Store Bypass, Rogue System Register Read, Lazy FP State Restore, Bounds Check Bypass Store, TLBleed, and L1TF/Foreshadow vulnerabilities as well as general hardware and firmware security guidance. #nsacyber
C
748
star
7

ELITEWOLF

OT security monitoring #nsacyber
560
star
8

Windows-Event-Log-Messages

Retrieves the definitions of Windows Event Log messages embedded in Windows binaries and provides them in discoverable formats. #nsacyber
C#
392
star
9

Mitigating-Obsolete-TLS

Guidance for mitigating obsolete Transport Layer Security configurations. #nsacyber
PowerShell
269
star
10

nsacyber.github.io

NSA Cybersecurity. Formerly known as NSA Information Assurance and the Information Assurance Directorate
PowerShell
257
star
11

AppLocker-Guidance

Configuration guidance for implementing application whitelisting with AppLocker. #nsacyber
PowerShell
204
star
12

Pass-the-Hash-Guidance

Configuration guidance for implementing Pass-the-Hash mitigations. #nsacyber
PowerShell
196
star
13

HIRS

Trusted Computing based services supporting TPM provisioning and supply chain validation concepts. #nsacyber
Java
171
star
14

simon-speck

The SIMON and SPECK families of lightweight block ciphers. #nsacyber
167
star
15

unfetter

Identifies defensive gaps in security posture by leveraging Mitre's ATT&CK framework. #nsacyber
163
star
16

Control-Flow-Integrity

A proposed hardware-based method for stopping known memory corruption exploitation techniques. #nsacyber
C
152
star
17

BAM

The Binary Analysis Metadata tool gathers information about Windows binaries to aid in their analysis. #nsacyber
Python
146
star
18

WALKOFF-Apps

WALKOFF-enabled applications. #nsacyber
YARA
141
star
19

Maplesyrup

Assesses CPU security of embedded devices. #nsacyber
C
140
star
20

RandPassGenerator

A command-line utility for generating random passwords, passphrases, and raw keys. #nsacyber
Java
118
star
21

BitLocker-Guidance

Configuration guidance for implementing BitLocker. #nsacyber
HTML
113
star
22

Certificate-Authority-Situational-Awareness

Identifies unexpected and prohibited certificate authority certificates on Windows systems. #nsacyber
PowerShell
107
star
23

netfil

A kernel network manager with monitoring and limiting capabilities for macOS. #nsacyber
C
103
star
24

LOCKLEVEL

A prototype that demonstrates a method for scoring how well Windows systems have implemented some of the top 10 Information Assurance mitigation strategies. #nsacyber
JavaScript
99
star
25

HTTP-Connectivity-Tester

Aids in discovering HTTP and HTTPS connectivity issues. #nsacyber
PowerShell
96
star
26

Splunk-Assessment-of-Mitigation-Implementations

Automatically scores how well Windows systems have implemented some of the top 10 Information Assurance mitigation strategies. #nsacyber
Python
72
star
27

netman

A userland network manager with monitoring and limiting capabilities for macOS. #nsacyber
C
71
star
28

serial2pcap

Converts serial IP data, typically collected from Industrial Control System devices, to the more commonly used Packet Capture (PCAP) format. #nsacyber
Python
65
star
29

PRUNE

Logs key Windows process performance metrics. #nsacyber
C#
62
star
30

paccor

The Platform Attribute Certificate Creator can gather component details, create, sign, and validate the TCG-defined Platform Credential. #nsacyber
Java
53
star
31

Blocking-Outdated-Web-Technologies

Guidance for blocking outdated web technologies. #nsacyber
PowerShell
51
star
32

Detect-CVE-2017-15361-TPM

Detects Windows and Linux systems with enabled Trusted Platform Modules (TPM) vulnerable to CVE-2017-15361. #nsacyber
PowerShell
49
star
33

Driver-Collider

Blocks drivers from loading by using a name collision technique. #nsacyber
C
45
star
34

simon-speck-supercop

Fast implementations of the SIMON and SPECK lightweight block ciphers for the SUPERCOP benchmark toolkit. #nsacyber
C
43
star
35

Cyber-Challenge

Supporting files for cyber challenge exercises. #nsacyber
Jupyter Notebook
39
star
36

Chinese-State-Sponsored-Cyber-Operations-Observed-TTPs

Supporting files for the Chinese State-Sponsored Cyber Operations: Observed TTPs Cybersecurity Advisory. #nsacyber
34
star
37

AtomicWatch

Intel Atom C2000 series discovery tool that parses log files and returns results if a positive match is found. #nsacyber
Python
25
star
38

CodeGov

Creates a code.gov code inventory JSON file based on GitHub repository information. #nsacyber
PowerShell
22
star