understanding web shells

Understanding Web ShellsInsights and Practices to Prevent Advanced Attacks

www.fidelissecurity.com

Contents

3 Executive Summary

4 Introduction

15 Recommendations

16 Available Tools

17 References

18 Appendix A — Examples of Obfuscation

21 Appendix B — Overview of Select Tools

28 Appendix C — Signature Fingerprints

Understanding Web Shells

©Fidelis Cybersecurity TA_Fidelis_Webshells_1605 www.fidelissecurity.com 3

Executive Summary

By providing a means for unauthorized users to access and manipulate targeted web servers and web applications, web shells pose a significant security threat to enterprises.

Bad actors use web shells as attack vectors, for attack propagation and as a primary and secondary means of access. Web shells can be installed on systems running web applications ranging from corporate web servers to internal file servers.

In many cases, a web shell’s primary purpose is isolated to the system where it resides. For example, some bad actors use web shells to facilitate spam email campaigns. Once installed on a system, bad actors use can leverage web shells to introduce additional functionality, such as a spam emailer application. In some cases, they use web shells to facilitate deep access into a target’s enterprise or to provide back-up access after the primary means, such as compromised credentials, are remediated.

Web shells leverage programming languages used in web applications on an affected server. Fidelis Cybersecurity frequently encounters web shells on servers running content management systems (CMS), such as Drupal and WordPress. However, any web server — whether external or internal facing — with a targeted programming language, including PHP or Java, can be targeted.

This paper serves as a primer on web shells for cybersecurity practitioners, network and system defenders and decision makers at all levels of responsibility. Our goal is to provide insight and action to devise effective means of detection, investigation and defense.

This report covers the following:

z How bad actors use web shells to access systems and networks.

z How web shells operate “in the noise” of expected and normal web traffic.

z How bad actors frequently obfuscate web shells heavily to avoid detection and frustrate analysis.

z How analysts can detect web shells through network and file system artifacts.

z How defenders can implement measures, processes and applications to hamper bad actor web shell introduction and use.



Introduction

Web shells are a form of Remote Access Trojan (RAT), or backdoor, that provide a means for an attacker to interact with a web server. Web shells vary in size — from a very basic backdoor of a few bytes, to a fully featured graphical user interface complete with embedded images and different utilities of thousands of bytes. Web shells commonly enable file system and database manipulation, facilitate system command execution and provide file upload/download capability.

Web shells may be used as an initial foothold into a network, or as an “insurance plan” to help ensure access into an already-compromised network. Web servers typically sit behind a firewall with ports 80 and 443 open to allow web traffic into the network. Once placed on a web server, a web shell can be used to access other services on other ports — even if those ports are blocked by the perimeter firewall — since the traffic “originates” from the web server behind the firewall. Internet-facing assets are commonly placed within a demilitarized zone (DMZ). However, inadequate DMZ isolation is a common problem, so limiting and logging traffic between the internal network and DMZ is recommended.

Figure 1: Typical Web Server N/W Location

Web shells take advantage of pre-existing components of web servers that provide dynamically generated web pages. Examples of these include PHP, Active Server Pages (ASP) and JavaServer Pages (JSP). They allow code execution for certain types of requests to generate the content of the web page dynamically. Therefore, if a file is placed in an appropriate location on a webserver, it may then be requested — causing the web server to process or execute the code within the file and return the generated output.



The following diagram shows how server-side scripts are typically handled and executed on web servers:

Figure 2: Typical Web Server Script Handling

1. An HTTP request is sent to the web server requesting a resource, (e.g. /pages/myapp.php)

2. The web server determines how to handle the request based on its configuration (e.g. handler mappings). Handlers are typically configured based on characteristics such as file extension, path, or MIME type.

3. Once an appropriate handler is identified, it is executed in conjunction with the requested resource (e.g. myapp.php may be executed by php-cgi.exe).

4. Output generated by the script is provided to the web server.

5. The web server generates and returns an HTTP response, which contains the output generated from the execution of the script by its handler.

While web shells may often be found as standalone files, it is possible to insert the code for a web shell into a pre-existing, legitimate file. In some cases, this can increase the difficulty of detection.

Web shells can be placed onto a web server in multiple ways:

z Exploitation of a vulnerable web application

z Exploitation of a poorly or misconfigured web server

z Exploitation of file upload functionality

z Regular or typical means by a compromised user

After a web server is exploited and successful placement and execution of a web shell occurs, attackers commonly browse files, upload tools and run commands. Threat actors wishing to gain access to resources deeper within the network may attempt to escalate privileges and pivot to additional hosts. If the web shell was placed onto the web server by a compromised account, then privileged escalation is presumably unnecessary. During forensic examination, lack of evidence of web server exploitation in access logs and elsewhere may lend credence to the possibility of a compromised user account.

The presence of a web shell on a web server does not necessarily mean that the web shell is accessible to the “outside world.” However, this is usually the case. Web shells typically run within the context of the web server, and therefore, the restrictions — or lack of — for the user/group the server is running (e.g. http, nobody, www-data, IUSR/IIS_IUSRS)



also applies to the web shell. For a properly locked-down web server, additional exploitation must occur after the web shell is introduced in order to gain root/SYSTEM privileges. Additionally, hard-coded credentials used by a web application (e.g. database credentials), which may not normally be accessible to users of the application, may be accessible via the web shell since it is running within the context of the web application.

US-CERT lists the following uses for web shells:

z Harvest and exfiltrate sensitive data and credentials

z Upload additional malware, for example, by creating a watering hole for infection and the scanning of further victims

z Use as a relay point to issue commands to hosts inside the network without direct Internet access

z Use as command-and-control infrastructure, potentially in the form of a bot in a botnet or in support of compromises to additional external networks (e.g. if adversary Intends to maintain long-term persistence)

Functionality

At its core, a web shell provides a means to execute commands or code. A minimalistic web shell may be very small, making it easy to remain hidden if inserted in large code bases. The following 26 bytes implements a minimalistic web shell that allows arbitrary PHP code execution:

<?php eval($_GET[‘c’]); ?>

Code to execute can be sent in a parameter named ‘c’ in the GET request:

Figure 3: Example Minimalistic Web Shell Operation

One consequence of minimalistic web shells is that the functional logic is displaced from the code file itself onto network traffic/memory. Inadequate logging and monitoring can greatly reduce or eliminate any visibility into how these web shells are being used by an attacker.

Other web shells provide vast functionality built-in to the server-side script itself. This image depicts the user interface of the File Manager feature of WSO web shell, which is the default page displayed when the web shell is executed:



The ability to navigate the filesystem, in addition to viewing, uploading, downloading, renaming, deleting and time-stamping files, is a common feature of web shells. Other utilities related to application, service and system discovery are also common. For example, the following image of a variant of PhpSpy shows the port scan feature along with the default ports it scans:

Figure 4: PhpSpy Port Scan Feature



Database access functionality is also common. The ability to connect to database servers and list databases, tables and data are often available. The following image shows the client-side interface provided for database manipulation implemented by a JSP web shell:

Figure 5: JSP Web shell DB Manipulation Artifacts and Detection

Many web shell artifacts created as a result of installation and/or execution are dependent on the platform the web shell executes on, as well as its environment. For example, a JSP web shell running within the context of an Apache Tomcat server may leave different traces than its PHP counterpart running under IIS.



File System

Dates and Times

In some cases, reviewing file modification dates and times is sufficient to identify potentially suspicious files. The following image shows a default WordPress install alongside a maliciously placed web shell. The modification date clearly stands out from the surrounding files:

Figure 6: File Dates and Times

Although some web shells provide time-stamping functionality, this feature is not always utilized. Therefore, looking for outliers in file modification times may prove fruitful.

Residual File System Artifacts

Depending on the platform, web shells may indirectly create additional files during execution. For example, execution of a JavaServer Pages script or ASP.NET script may result in the creation of additional files. In the case of the JSP script, the script is converted into Java source code (.java), which is then byte-compiled into a java class (.class) file. The class file is ultimately executed by the Java Virtual Machine (JVM). Temporal analysis focused on file dates and times, as well as file name inspection, may disclose intermediary files, such as .java and .class files — indicating malicious web shell activity.



The following diagram shows the event pipeline for a JSP web shell:

Figure 7: Event Pipeline of JSP Execution and Intermediary File Creation

1. HTTP request made from attacker to JSP web shell on infected server. Web shell expects specific parameters to be included in request, sent in request string (URI) or in post data.

a) If JSP has not yet been compiled into a Java Servlet Class file, or if JSP file is newer than corresponding class file, then process to re-compile will occur.

b) If cached class file is not older than JSP, then re-compilation may not occur.

2. JSP is transformed into a Java Servlet (e.g. via Jasper component of Apache Tomcat).

3. Servlet is compiled into Java class file.

4. Class file is loaded and executed by Java Virtual Machine (JVM).

5. Container invokes servlet’s service method. Request parameters parsed and appropriate command executed, sending any output back in response to attacker.

Volatile/Temporary File System Locations

On *nix systems, the /tmp directory is commonly used by attackers for staging malware because it is typically world readable, writable and executable. Both c99 and WSO web shells contain functionality to use /tmp to write C or perl backdoors. Another popular location is /dev/shm, which is typically used to implement shared memory with a RAM backing store. It is worth noting, on modern systems, /tmp is commonly mounted as the volatile memory-resident tmpfs filesystem. As a result, all files stored in either /dev/shm or /tmp will be lost on reboot. It is strongly recommended, during a web shell infestation investigation, to collect and examine the contents of these directories if they exist and are mounted as tmpfs.



Web Server Access Logs

Access logs may provide useful information about identified web shells, including the volume of data transferred between the server and client, the client IP address, User-Agent string and when access occurred. Additionally, filtering access logs for accesses to scripts with no referrer and/or strange or no User-Agent string may help identify potential web shells. The type of traffic a web server logs may vary greatly from server to server depending on the type of environment, specific application(s) it hosts and usage patterns of its typical clients. To help detect web shells, use a web log review to identify anomalies. This is performed by filtering specific fields (e.g., request type, user-agent string, client IP address).

The following command line uses grep and awk to filter the lines from the web access log that contain POST requests to. php files, returned a 200 status code and do not contain “XML-RPC”1:

1 While constructing the command line, many records of POSTs to xmlrpc.php returning 200 were returned and diluting the output. Once xmlrpc.php was determined to be a valid resource, records referring to it were Filtered using grep –v. This type of process can be very common when filtering web log records, and will vary from server to server depending on typical traffic patterns.

Figure 8: Example /tmp Directory Listing

Figure 9: Filtering Web Logs



Review of output reveals 4 HTTP POSTs to /sites/all/modules/views/modules/locale/comments.api.php all within a few seconds of each other, with identical user-agent strings and a varying number of returned bytes. If this file is found to be a web shell (or other malware), then other types of filtering on the full log set — with additional information gleaned from these records — should be performed (e.g. filtering on user-agent string, client IP, or date/time ranges). This filtering can potentially provide additional information and insight.

Sometimes, web shells receive commands or actions via request variables that may show up in access logs. For example, usage of a c99 web shell variant generated the following data in Apache’s access log on a Linux system:

192.168.1.177 - - [14/Dec/2015:10:24:19 -0500] “GET /c99.php?act=encoder&d=%2Fsrv%2Fhttp%2F HTTP/1.1” 200 3254

192.168.1.177 - - [14/Dec/2015:10:24:27 -0500] “GET /c99.php?act=tools&d=%2Fsrv%2Fhttp%2F HTTP/1.1” 200 3197

192.168.1.177 - - [14/Dec/2015:10:24:36 -0500] “GET /c99.php?act=processes&d=%2Fsrv%2Fhttp%2F HTTP/1.1” 200 7063

192.168.1.177 - - [14/Dec/2015:10:24:46 -0500] “GET /c99.php?act=ftpquickbrute&d=%2Fsrv%2Fhttp%2F HTTP/1.1” 200 3000

192.168.1.177 - - [14/Dec/2015:10:24:50 -0500] “GET /c99.php?act=security&d=%2Fsrv%2Fhttp%2F HTTP/1.1” 200 4248

192.168.1.177 - - [14/Dec/2015:10:25:28 -0500] “GET /c99.php?act=processes&d=%2Fsrv%2Fhttp%2F HTTP/1.1” 200 7066

192.168.1.177 - - [14/Dec/2015:10:25:30 -0500] “GET /c99.php?act=sql&d=%2Fsrv%2Fhttp%2F HTTP/1.1” 200 3221

192.168.1.177 - - [14/Dec/2015:10:25:31 -0500] “GET /c99.php?act=eval&d=%2Fsrv%2Fhttp%2F HTTP/1.1” 200 2908

Some of the actions of the attacker and the working directory can be seen in the request string itself, such as process enumeration:

GET /c99.php?act=processes&d=%2Fsrv%2Fhttp%2F

The strings of these parameters can be used to find additional activity in logs, as well within live network traffic. Many web shells receive commands through POST data, and will not show up in standard access logs.

The following excerpt is from an Apache server running in a Windows environment and is the result of interaction with a variant of the WSO web shell:

192.168.1.177 - - [10/Dec/2015:14:51:03 -0500] “GET /mysite/wso.php HTTP/1.1” 200 120 “-” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64)”

192.168.1.177 - - [10/Dec/2015:14:51:05 -0500] “POST /mysite/wso.php HTTP/1.1” 200 10656 “http://mysite.example/mysite/wso.php” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64)”












Notice the first request is a GET request with no referrer specified. Subsequent requests are POSTs with the referrer being the PHP script itself. These patterns are common for a number of web shells, especially those used interactively. Here, the initial GET request presents a password prompt, and the second request sends the password and returns the initial page for the web shell. The following figure displays the password prompt presented by a variant of the WSO web shell:

The following log excerpt is taken from an instance of IIS and shows a similar pattern of accesses to an ASP script:

#Software: Microsoft Internet Information Services 7.5

#Version: 1.0

#Date: 2015-12-08 20:40:34

#Fields: date time s-ipcs-method cs-uri-stem cs-uri-query s-port cs-username c-ipcs(User-Agent) sc-status sc-substatus sc-win32-status time-taken

2015-12-08 20:40:41 192.168.1.177 GET /ntdaddy.asp - 80 - 192.168.1.100 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 0 249

2015-12-08 20:41:04 192.168.1.177 POST /ntdaddy.asp - 80 - 192.168.1.100 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) 200 0 0 390



By default, the following fields were not logged but could potentially contain useful information:

z URI Query (cs-uri-query)

z Bytes Sent (sc-bytes)

z Bytes Received (cs-bytes)

z Cookie (cs(Cookie))

z Referer (cs(Referer))



IIS can be configured to log these fields2, which is recommended.

Often, web shells will only be accessed by the attacker, which may appear in the logs as a single or a few IP addresses. Frequency analysis, in which the number of unique IP addresses is examined against requested resources, may help identify suspicious files. A client host accessing a single resource, and only a single resource, is very rare in most environments. Likewise, a similar approach can be applied by analyzing the number of unique User-Agent strings associated with a requested resource.

It is not uncommon for access logs to lack the detailed data required to gain insight into actual web shell usage. However, tools such as ModSecurity can provide increased data collection and logging facilities to help address this hole in visibility.

Obfuscation

Web shells are sometimes obfuscated in order to avoid detection or make analysis harder, especially if the web shell is password protected. While code obfuscation may make it easier to avoid automated detection, it may also make it easier to identify potentially malicious code manually, since it is somewhat rare to find legitimately obfuscated server-side scripts.

The following functions are commonly used in obfuscated scripts:

z eval

z base64_decode

z gzinflate

z rot13

z preg_replace (used in conjunction with the ‘e’ flag)

Searching across scripts containing these functions may aid in the detection of web shells. Additionally, searching for script files with long base64-encoded strings may help identify obfuscated code. The following regular expression matches base64-encoded strings of length 100 or more:

/[a-zA-Z0-9\+\/]{100,}/

The following is an example of what an obfuscated PHP web shell may look like:

<?php eval(gzinflate(base64_decode('3X1rc2PHdeBnukr/4Q4E6wISiBc5L3LIGQ7J4XDEITkEOS+SBV8AF8AdArjQBUA ONZ4fk02qkt3sVizLr8SKtbbklaU8pI0de3ernMqmnOx6s/kQ78N5lLb2PLr7dt97wcdITrZ2bBFA9zmnT79Onz59+vQNNw j8oBq4fT8Yer1W5nJ29qUv3Bi4g4Hn96qDo

<…truncated…>

6HsONfHwNOn/Ag==’))); ?>

A method used to avoid manual detection involves prepending many spaces to injected code within a legitimate file. When the file is viewed in an application that does not provide line wrapping, the malicious code would not be shown. The injected code would typically be off screen to the right. Searching for script files containing lines prepended with many spaces may help find this type of “injected” code:

/^ {80,}[^\s]/

2 https://technet.microsoft.com/en-us/library/cc754702(v=ws.10).aspx



Recommendations

To address web server security in the context of web shells, Fidelis Cybersecurity created some general recommendations. This is not an exhaustive list, and, as with most configuration alterations, some may break certain applications that rely on particular features or expect certain functionality. Common sense and an understanding of the system and environment in which these are applied are required.

z Review anomalies in access and error logs regularly.

z Ensure server software and web applications are updated regularly.

z Prevent the web server from divulging specific details/information about itself. Some example configurations are:

— Apache: set ServerSignature to Off and ServerTokens to Prod

— IIS: Install and configure URLScan; set RemoveServerHeader to 1

— Nginx: set server_tokens to off

z Install and configure a Web Application Firewall (WAF) such as ModSecurity to provide full HTTP transaction logging capability, including the ability to log POST requests and their bodies, which can be used to determine web shell attacker activity.

z Use the disable_functions PHP directive to disable certain functions web shells often use if no legitimate application uses them. Some examples include: curl_exec, curl_multi_exec, dl, exec, parse_ini_file, passthru, phpinfo, popen, preg_replace, proc_nice, proc_open, shell_exec and show_source. Disabling allow_url_fopen and allow_url_include if unneeded is recommended.

z Use the php_admin_value and/or php_admin_flag to set values for directives that should not be overridden by .htaccess files or the ini_set function such as error_log and log_errors.

z Disable PHP assertions completely in production environments (set zend.assertions to -1).

z Ensure filesystem permissions are as restrictive as necessary.

z Ensure PHP’s open_basedir configuration option is as restrictive as necessary.

z Ensure that web server, application and system logging is enabled and configured to provide enough verbosity in the event of a compromise. Ensure that log retention is reasonable.

z Diverge from default values when it is reasonable to do so. For example, use a name other than ‘admin’ for administrative accounts or a table prefix other than ‘wp_’ for a WordPress deployment.

z On *nix systems, enable shell history and timestamps. Most setups record command history but not timestamps by default. Setting HISTTIMEFORMAT environment variable will cause bash to record timestamps along with the commands. (e.g. export HISTTIMEFORMAT=”%m/%d/%y %T “).

z If possible, mount /tmp and/or /dev/shm with nodev, nosuid and noexec options to prevent the system from interpreting character/block device nodes, disallow set-user-identifier and set-group-identifier bits from taking effect, and forbid direct execution of any files in these hierarchies.

z Disable any HTTP verbs that are not used.

z Disable any default handler mappings that are not used.



Available Tools

These tools may aid in the detection and/or prevention of web shells and/or provide security plugins/tools for popular CMSs.

z jHackGuard — a Joomla Security Plugin that protects by filtering the data from the users’ input and implements additional PHP security settings. https://www.siteground.com/joomla-hosting/joomla-extensions/ver1.5/jhack.htm

z ModSecurity - a toolkit for real-time web application monitoring, logging and access control. https://www.modsecurity.org

z NeoPI — a Python script that uses various statistical methods to detect obfuscated and encrypted content within text/script files. https://github.com/Neohapsis/NeoPI

z OSSEC — an Open source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response. https://ossec.github.io/

z RIPS — a tool written in PHP to find vulnerabilities in PHP applications using static code analysis. http://rips-scanner.sourceforge.net/

z Sucuri Security WordPress Plugin — a security suite to complement an existing security posture offering activity auditing, file integrity monitoring, remote malware scanning, and security hardening. https://wordpress.org/plugins/sucuri-scanner/

z UrlScan — a security tool that restricts the types of HTTP requests that IIS will process. By blocking specific HTTP requests, UrlScan helps prevent potentially harmful requests from reaching applications on the server.

z Web Shell Detector — a Python/PHP script that helps to identify PHP, CGI (Perl), ASP and ASP .NET web shells. Note: This script will submit files to shelldetector.com by default. If this behavior is undesired, modification of the script is recommended. https://github.com/emposha/PHP-Shell-Detector

z WPScan — a black box WordPress vulnerability scanner. http://wpscan.org/

https://www.siteground.com/joomla-hosting/joomla-extensions/ver1.5/jhack.htm

https://www.modsecurity.org

https://www.modsecurity.org

https://github.com/Neohapsis/NeoPI

https://ossec.github.io/

http://rips-scanner.sourceforge.net/

http://rips-scanner.sourceforge.net/

https://wordpress.org/plugins/sucuri-scanner/

https://wordpress.org/plugins/sucuri-scanner/

https://github.com/emposha/PHP-Shell-Detector

http://wpscan.org/



References

z Achour, M., Betz, F., Dovgal, A., Lopes, N., Magnusson, H., Richter, G., . . .Vrana, J. (2015). PHP Manual (P. Cowburn, Ed.). Retrieved December 9, 2015.

z Akamai. (2013). Web Shells, Backdoor Trojans and RATs. Retrieved December 17, 2015, from https://www.akamai.com/us/en/multimedia/documents/report/akamai-security-advisory-web-shells-backdoor-trojans-and-rats.pdf.

z Kazanciyan, R. (2012). Old Web Shells, New Tricks. Retrieved December 17, 2015, from https://www.owasp.org/images/c/c3/ASDC12-Old_Webshells_New_Tricks_How_Persistent_Threats_haverevived_an_old_idea_and_how_you_can_detect_them.pdf.

z Shelmire, A. (2015). Detecting Web Shells in HTTP Access Logs. Retrieved December 8, 2015, from https://www.threatstream.com/blog/detecting-web-shells-in-http-access-logs.

z Soni, A. (2014). Closing the Door on Web Shells. Retrieved December 8, 2015, from https://digital-forensics.sans.org/summit-archives/dfir14/Closing_the_Door_on_Web_Shells_Anuj_Soni.pdf.

z Torre, J. (2013). Stealrat: An In-Depth Look at an Emerging Spambot. Retrieved December 4, 2015, from https://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-stealrat.pdf.

z US-CERT. (2015). Compromised Web Servers and Web Shells — Threat Awareness and Guidance. Retrieved December 18, 2015, from https://www.us-cert.gov/ncas/alerts/TA15-314A.

z WordPress. (n.d.). Hardening WordPress. Retrieved December 7, 2015, from https://codex.wordpress.org/Hardening_WordPress.

https://www.akamai.com/us/en/multimedia/documents/report/akamai-security-advisory-web-shells-backdoor-trojans-and-rats.pdf

https://www.akamai.com/us/en/multimedia/documents/report/akamai-security-advisory-web-shells-backdoor-trojans-and-rats.pdf

https://www.owasp.org/images/c/c3/ASDC12-Old_Webshells_New_Tricks_How_Persistent_Threats_haverevived_an_old_idea_and_how_you_can_detect_them.pdf



https://www.threatstream.com/blog/detecting-web-shells-in-http-access-logs

https://www.threatstream.com/blog/detecting-web-shells-in-http-access-logs

https://digital-forensics.sans.org/summit-archives/dfir14/Closing_the_Door_on_Web_Shells_Anuj_Soni.pdf

https://digital-forensics.sans.org/summit-archives/dfir14/Closing_the_Door_on_Web_Shells_Anuj_Soni.pdf

https://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-stealrat.pdf

https://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-stealrat.pdf

https://www.us-cert.gov/ncas/alerts/TA15-314A

https://codex.wordpress.org/Hardening_WordPress

https://codex.wordpress.org/Hardening_WordPress



Appendix A — Examples of Obfuscation

This appendix contains various examples of code obfuscation, which may be used to infer pattern-based detection mechanisms.

Example 1

This method uses a custom character substitution table with base64-encoding, random variable name generation, and string concatenation (presumably to bypass long string detection). The character substitution table is defined in the following manner, followed by the definition of the function that decodes a string given the decoding table to use:

$vSLUEZF = Array(‘1’=>’m’, ‘0’=>’X’, ‘3’=>’h’, ‘2’=>’C’, ‘5’=>’D’, ‘4’=>’0’, ‘7’=>’o’, ‘6’=>’8’, ‘9’=>’q’, ‘8’=>’V’, ‘A’=>’Y’, ‘C’=>’p’, ‘B’=>’7’, ‘E’=>’M’, ‘D’=>’4’, ‘G’=>’J’, ‘F’=>’1’, ‘I’=>’j’, ‘H’=>’g’, ‘K’=>’E’, ‘J’=>’K’, ‘M’=>’f’, ‘L’=>’A’, ‘O’=>’d’, ‘N’=>’W’, ‘Q’=>’S’, ‘P’=>’c’, ‘S’=>’e’, ‘R’=>’6’, ‘U’=>’Z’, ‘T’=>’l’, ‘W’=>’y’, ‘V’=>’n’, ‘Y’=>’G’, ‘X’=>’z’, ‘Z’=>’P’, ‘a’=>’L’, ‘c’=>’O’, ‘b’=>’r’, ‘e’=>’2’, ‘d’=>’B’, ‘g’=>’x’, ‘f’=>’I’, ‘i’=>’N’, ‘h’=>’v’, ‘k’=>’w’, ‘j’=>’3’, ‘m’=>’5’, ‘l’=>’a’, ‘o’=>’F’, ‘n’=>’t’, ‘q’=>’s’, ‘p’=>’H’, ‘s’=>’R’, ‘r’=>’u’, ‘u’=>’b’, ‘t’=>’k’, ‘w’=>’T’, ‘v’=>’9’, ‘y’=>’i’, ‘x’=>’Q’, ‘z’=>’U’);

function v0C4IU8($v547WAY, $vXVW27Z){$v48THXC = ‘’; for($i=0; $i < strlen($v547WAY); $i++){$v48THXC .= isset($vXVW27Z[$v547WAY[$i]]) ? $vXVW27Z[$v547WAY[$i]] : $v547WAY[$i];}

return base64_decode($v48THXC);}

This is followed by the encoded payload, which is broken out into randomly-sized strings and concatenated together:

$vK7JRPJ = ‘lNA7l0iXU0x7Gov<…truncated…>Htt0’. ‘FiozTUo<…truncated…>2sM’.’z48Q8t…

Following this declaration, the string is decoded using the previously defined function and substitution table and evaluated:

eval(v0C4IU8($vK7JRPJ, $vSLUEZF));

Example 2

This method declares a string containing base64-encoded code to execute:

$o=”JGNvbG9yID0gIiNkZjUiOwokZGVmYXVsdF9…”;

This string is subsequently decoded and evaluated:

eval(base64_decode($o));

The variable ‘$o’ may be used across samples.



Example 3

This example does not use the eval() function to execute code, but makes heavy use of string obfuscation to make it difficult to understand. Many strings are defined as global variables in the following fashion:

${“\x47L\x4f\x42\x41\x4c\x53”}[“d\x74\x63\x64\x73\x66\x64\x71”]=”\x70or\x74”;

${“\x47\x4cO\x42\x41\x4c\x53”}[“\x77qp\x65\x68\x6a\x65f\x77e\x72\x6f”]=”\x75\x72\x6c”;

${“\x47\x4c\x4f\x42A\x4c\x53”}[“cao\x6f\x71\x65”]=”\x75\x72\x69”;

This method replaces random characters in strings with hex-escaped values. These strings decoded are:

${“GLOBALS”}[“dtcdsfdq”]=”port”;

${“GLOBALS”}[“wqpehjefwero”]=”url”;

${“GLOBALS”}[“nzujklx”]=”ips”;

The names designated for the global variables are randomly generated and may change from sample to sample.

Example 4

Another technique is to declare a randomly generated string that contains all characters needed to generate the desired code to execute. This string is then used to generate the code by concatenating the characters as referenced by their offset in the string. The “alphabet” string is typically defined as a global variable using a hex-encoded string:

GLOBALS[‘g83db2’] = “\x2c\x7e\x5a\x21\x64\x3d\x4b\x3c\x4a\x61\x39\x46\x6a\x28\x22\x69\x6e\x66\x58\x67\x65\x30\x44\xd\x4c\x5d\x32\x75\x49\x55\x54\x7c\x40\x2a\x62\x3a\x71\x6d\x2d\x48\x20\x5f\x41\x37\x38\x7a\x6b\x56\x25\x63\x60\x78\x79\x35\x4f\x27\x3e\x72\x45\x7b\x2e\x7d\x70\x53\x73\x68\x52\x59\x33\x36\x5b\x4d\x50\x6f\x2f\x47\x3b\xa\x51\x23\x31\x29\x24\x26\x3f\x9\x74\x34\x5e\x57\x2b\x43\x4e\x76\x5c\x42\x6c\x77”;

The code is then constructed in the following manner:

$GLOBALS[$GLOBALS[‘g83db2’][51].$GLOBALS[‘g83db2’][34].$GLOBALS[‘g83db2’][44].$GLOBALS[‘g83db2’][69].$GLOBALS[‘g83db2’][44].$GLOBALS[‘g83db2’][17].$GLOBALS[‘g83db2’][87].$GLOBALS[‘g83db2’][69].$GLOBALS[‘g83db2’][53]] = $GLOBALS[‘g83db2’][49].$GLOBALS[‘g83db2’][65].$GLOBALS[‘g83db2’][57];

Note that the samples using this technique were observed to use variables whose names were pseudo-randomly generated which begin with a lowercase letter and a length of 6. This decodes to the following equivalent statement:

$GLOBALS[‘xb868f465’] = ‘chr’;

Here, randomly named global variables are used to store function names so that the code may refer to function names by the obfuscated variable name, rather than its meaningful one.



Example 5

The ability to XOR string literal types natively in PHP is sometimes exploited to obfuscate code. For example, the following sample declares three variables, which are used to call a function to disable error reporting. The actual value of the two string variables is obfuscated by using the binary XOR operator ‘^’ on two apparently meaningless strings:

$enbi=’&6W%Q(Z3UVEG[^&’^’CD%J#w(V%97320A”9JY”BN’;

$ylhbew=’8!::$L*UB(^’^’QOSeW)^’;

$vto=0;

$ylhbew($enbi,$vto);

The first two lines decode to the following:

$enbi=’error_reporting’;

$ylhbew=’ini_set’;

Therefore, upon execution the last line is equivalent to the following function call:

ini_set(‘error_reporting’, 0);

Example 6

This example is similar to Example 2, however, no variables are declared and the entire web shell is executed in a single logical line. The web shell logic is compressed and base64-encoded. The following excerpt shows the method used to execute the code:

eval(gzinflate(base64_decode(‘3X1rc2PHdeBnukr/4Q4E6wISiBc5L3LIGQ7J4XDEITkEOS+SBV…<many characters removed for brevity>…wNOn/Ag==’)));

Searching across scripts with very long base64-encoded strings may help identify other instances of obfuscated Web Shells or other malicious data. This is not a foolproof method. There is always the possibility of false positives in the case of valid large base64-encoded strings in scripts (e.g. embedded encoded images), but a cursory review of all such cases may help to quickly identify potentially malicious/obfuscated logic.

Example 7

This example uses a feature of PHP’s preg_replace function to evaluate obfuscated PHP code. The following code sample provides an example of how this function is used:

preg_replace(“/.+/e”,”\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28’xVdtc9pGEP4Mv2<…truncated…>3fo3DzfwA=’\x29\x29\x29\x3B”,”.”);

The first parameter to the preg_replace function is a regular expression. This value is commonly either /.+/e or /.*/e. The trailing ‘e’ flag is necessary for the code to be evaluated. The second parameter contains the code to be evaluated, which coincides with the replacement string. In this instance, the code to be evaluated is hex-encoded. The decoded values are:

eval(gzinflate(base64_decode(‘xVdtc9pGEP4Mv2<…truncated…>3fo3DzfwA=’)));

This in turn evaluates code that has been compressed and base64-encoded.



Appendix B — Overview of Select Tools

ModSecurity

ModSecurity is a web application firewall engine. However, customization and some tweaking or specification of rules is required to harness the power and usefulness of this tool. No rules or configurations are supplied in a default installation. Documentation may be found at https://www.modsecurity.org/documentation.html.

Additionally, the Open Web Application Security Project (OWASP) provides a Core Rule Set (CRS) for ModSecurity that provides generic protection from unknown vulnerabilities commonly found in web applications. These rules are commented to allow it to be used as a step-by-step deployment guide. These rules and documentation are hosted on github at https://github.com/SpiderLabs/owasp-modsecurity-crs.

NeoPI

NeoPI is a python script that provides several statistical tests htat help aid in the detection of potentially malicious text/script files. This tool is helpful to use in conjunction with other more traditional signature/keyword based detection tools.

The following transcript sample depicts example usage of NeoPI:

[root@WebServer2 opt]# python neopi.py -a -A /var/www/html/

[[ Average IC for Search ]]

0.0372337579606

[[ Top 10 IC files ]]

0.0156 /var/www/html/webmedia/shell3.php

0.0178 /var/www/html/phpadmin/phpMyAdmin-3.3.8-all-languages/lang/chinese_simplified-utf-8.inc.php

0.0184 /var/www/html/wordpress/wordpress/wp-admin/weevely.php

0.0217 /var/www/html/joomla/templates/system/index.php

0.0217 /var/www/html/joomla/administrator/templates/system/index.php

0.0225 /var/www/html/wordpress/wordpress/wp-admin/js/revisions-js.php

0.0229 /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Base/Mail/language/phpmailer.lang-ch.php

0.0239 /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Base/Mail/language/phpmailer.lang-zh.php

0.0240 /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Base/Mail/language/phpmailer.lang-zh_cn.php

0.0248 /var/www/html/phpadmin/shell2.php

[[ Top 10 entropic files ]]

6.3978 /var/www/html/phpadmin/phpMyAdmin-3.3.8-all-languages/lang/chinese_simplified-utf-8.inc.php

6.0651 /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Base/Mail/language/phpmailer.lang-ch.php

6.0061 /var/www/html/webmedia/shell3.php

5.9870 /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Base/Mail/language/phpmailer.lang-zh.php

5.9797 /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Base/Mail/language/phpmailer.lang-zh_cn.php

5.9245 /var/www/html/phpadmin/shell2.php

5.8895 /var/www/html/wordpress/wordpress/wp-admin/js/revisions-js.php

5.8580 /var/www/html/phpadmin/phpMyAdmin-3.3.8-all-languages/lang/japanese-utf-8.inc.php

5.8400 /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Base/Mail/language/phpmailer.lang-ja.php

5.7602 /var/www/html/wordpress/wordpress/wp-admin/weevely.php

https://www.modsecurity.org/documentation.html

https://github.com/SpiderLabs/owasp-modsecurity-crs



[[ Top 10 longest word files ]]

111571 /var/www/html/webmedia/shell3.php

2510 /var/www/html/webmedia/htdocs/templates/main.tpl.php

1312 /var/www/html/joomla/shell.php

728 /var/www/html/wordpress/wordpress/wp-admin/js/revisions-js.php

536 /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Libs/QuickForm/3.2.11/HTML/QuickForm/Rule/Email.php

522 /var/www/html/wordpress/wordpress/wp-includes/functions.php

516 /var/www/html/phpadmin/phpMyAdmin-3.3.8-all-languages/libraries/tcpdf/tcpdf.php

516 /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Libs/PHPExcel/lib/PHPExcel/Shared/PDF/tcpdf.php

516 /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Libs/TCPDF/tcpdf4/tcpdf.php

516 /var/www/html/joomla/libraries/tcpdf/tcpdf.php

[[ Highest Rank Files Based on test results ]]

83% /var/www/html/webmedia/shell3.php

56% /var/www/html/phpadmin/phpMyAdmin-3.3.8-all-languages/lang/chinese_simplified-utf-8.inc.php

43% /var/www/html/wordpress/wordpress/wp-admin/js/revisions-js.php

36% /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Base/Mail/language/phpmailer.lang-ch.php

26% /var/www/html/webmedia/htdocs/templates/main.tpl.php

26% /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Base/Mail/language/phpmailer.lang-zh.php

23% /var/www/html/wordpress/wordpress/wp-admin/weevely.php

23% /var/www/html/joomla/shell.php

20% /var/www/html/joomla/templates/system/index.php

20% /var/www/html/epesiBIM/epesi-1.1.3-rev7318/modules/Base/Mail/language/phpmailer.lang-zh_cn.php

OSSEC

OSSEC is an open source Host-based Intrusion Detection System (HIDS) that provides a “correlation and analysis engine, integrating log analysis, file integrity checking, Windows registry monitoring, centralized policy enforcement, rootkit detection, real-time alerting and active response.” It runs on most operating systems including Linux, Open/FreeBSD, OS X, Solaris, and Microsoft Windows. The server/agent software in addition to documentation may be downloaded from https://ossec.github.io/downloads.html.

A virtual appliance is also available for download, which contains the following facilities:

z CentOS

z OSSEC

z OSSEC WebUI

z Elasticsearch

z Logstash

z Kibana

z Kopf

z XAMPP

https://ossec.github.io/downloads.html



The virtual appliance is provided as an Open Virtualization Archive (OVA), which can be imported into most virtual systems, to include VirtualBox. The following screenshots showcase the web-based user interfaces provided:

Figure 10: OSSEC Events Kibana Interface

Figure 11: OSSEC Web Interface



Sucuri

The Sucuri WordPress plugin may be installed through the WordPress Dashboard interface. The plugin may be located by searching for “Sucuri” under the Plugins -> Add New WordPress dashboard page:

Figure 12: OSSEC Elasticsearch kopf Interface



Upon clicking “Install Now”, WordPress will download, unpack and install the plugin. After successful installation, click “Activate Plugin” to activate it:

Upon activation, a notification may appear indicating that in order to get full functionality, a free API key is required as shown below:

This key “is used to authenticate the HTTP requests sent by the plugin to a public API service managed by Sucuri Inc. Do not generate the key if you disagree with this.” Key generation requires a unique domain name and email address.

To configure the plugin, a new WordPress dashboard tab is created:

From here, the plugin can be configured and certain features exercised.



UrlScan

UrlScan 3.1 requires IIS Metabase to install. This may be achieved by enabling the IIS Metabase and IIS 6 configuration compatibility role, for example:

Installation is straightforward and does not require any configuration:



Upon successful installation, there should be a UrlScan folder in %windir%\system32\inetsrv and %windir%\syswow64\inetsrv with a UrlScan.dll file in both. Additionally, the UrlScan.ini configuration file should exist in those directories as well:

UrlScan can be configured on a global or per-site basis and is configured to use a global filter by default.



Appendix C — Signature Fingerprints

The following table contains strings and regular expressions which may aid in the detection of some web shells.

Search Criteria Format Type Description

eval$$_(?:GET|POST)[ Regex File Detects PHP eval from direct GET or POST variables

[a-zA-Z0-9\+\/]{100,} Regex File Detects long Base64-encoded strings

^[ ]{80,}[^\s] Regex File Detects lines prepended with at least 80 spaces

<\?php[ ]{80,}[^\s] Regex File Detects first lines of PHP script tag with text after at least 80 spaces

eval(gzinflate(base64_decode( String File Detects compressed and base64-encoded PHP code

preg_replace\((?:”|’)\/\(?\.(?:\+|\*)$?\/e

Regex File Detects some instances of PHP code evaluation via preg_replace

(?:\\x[a-f0-9]{1,2}){20,} Regex File Detects hex-encoded/escaped strings of at least 20 characters

eval(base64_decode( String File Detects evaluation of base64-encoded code

(?:\?|\&)act=(?:sql|eval|cmd|processes)(?:\&|$)

Regex Network/Logs

Detects possible operation of c99 shell

PCT4BA6ODSE_ String File Detects obfuscated minimal backdoor commonly injected

=”stop_”; String File Detects obfuscated minimal backdoor commonly injected

str_rot13$[‘”]riny[‘”]$ Regex File Detects rot13 encoded eval statement

(?:^|&|\?)z0=(?:UTF-8|GB2312|BIG5|Euc-KR| Euc-JP|Shift_JIS|Windows-1251|Windows-874| ISO-8859-1)(?:$|&|\?)

Regex Network Detects character encoding string in ChinaChopper HTTP traffic

->|1|<- String Network Detects success status code returned by some Web Shells

\t(?:[A-Z]:)+\|<- Regex Network Detects string returned by some Web Shells via HTTP

(?:^|&|\?)z2=\d{4}-\d{2}-\d{2}\+\d{2}%3A\d{2}%3A\d{2}(?:$|&|\?)

Regex Network Detects date modification parameter used by some Web Shells via HTTP

->|ERROR:// String Network Detects error string used by some Web Shells via HTTP

Execute Successfully!\t String File Detects string used in some JSP Web Shells

devilzShell String File Detects some unobfuscated variants of devilzShell

password=”jspspy” String File Detects some unobfuscated variants of JSPSpy

g00nshell String File Detects some unobfuscated variants of g00nshell

c99madshell String File Detects some unobfuscated variants of c99madshell

INTO TABLE tmp_angel String File Detects some unobfuscated variants of PHPSpy



Search Criteria Format Type Description

ASPShell - String File Detects some unobfuscated variants of ASPShell

ntdaddy String File Detects some unobfuscated variants of ntdaddy

AK-74 Security Team Web Shell String File Detects some unobfuscated variants of the AK-47 web shell

powered by zehir String File/Network

Detects some unobfuscated variants of the zehir ASP web shell

Ru24PostWebShell String File Detects some unobfuscated variants of the ru24 web shell

directory,will be delete all String File/Network

Detects some variants of AspxSpy

National Cracker Crew String File Detects some unobfuscated variants of NCC web shell

eval(gzinflate(str_rot13(base64_decode String File Detects compressed, rot13-encoded, and base64-encoded PHP eval

(?:\\x[0-9a-f]{1,2}\\\d{3}|\\x[0-9a-f]{1,2}){5,}

Regex File Detects strings obfuscated by alternate hex and octal escape characters

©Fidelis Cybersecurity TA_Fidelis_Webshells_1605

Fidelis Cybersecurity is creating a world where attackers have no place left to hide. We reduce the time it takes to detect attacks and resolve security incidents. Our Fidelis Network™ and Fidelis Endpoint™ products look deep inside your traffic and content where attackers hide their exploits. Then, we pursue them out to your endpoints where your critical data lives. With Fidelis you’ll know when you’re being attacked, you can retrace attackers’ footprints and prevent data theft. To learn more about Fidelis Cybersecurity products and incident response services, please visit www.fidelissecurity.com and follow us on Twitter @FidelisCyber.

understanding web shells

Documents