Detecting Web Shells in HTTP Access Logs

<p>While much of the focus of intrusion detection is on phishing messages and malware command and control channels, a sizable amount of intrusions rely upon server side compromises with the actor as the client. One of the mainstay tools in a good actors chest is the webshell. A webshell allows the actor to essentially have command line access to the web server through an executable script placed on the web server. Actors often place these scripts on the web server themselves, either after lateral movement from other compromised hosts and user accounts, or after exploiting a Remote File Include or Local File Include vulnerability on the web server itself. Other times the actor is able to find a helpful script left behind by a web administrator that gives  them the ability to execute commands. </p><p>Web Shells can be crafted in every scriptable web language, but most of the webshells I’ve encountered have been .asp, .aspx, .js, .jsp, or .php scripts. Web Shells can be extremely simple, relying upon a small amount of code to execute. </p><p><img alt="Web Shell Example" src="https://cdn.filestackcontent.com/bLZMjxiZTLeuBlYieCrc"/></p><p>In this example “pass” is replaced with the password the actor uses to access the webshell.     </p><h2>Detection</h2><p>Detecting webshells can be done in many different ways. The most robust method is to establish a regular change-management policy for your web servers, and to monitor for any changes to servable content with a file integrity system such as Samhain or TripWire. Another method is to run scripts on your web servers to search for common web shell patterns such as the “%eval(RequestItem” above. This method can result in surprising amount of false positives in web applications. </p><h3>Client Side malicious IP addresses</h3><p>This method seems simple at first. In practice, the actors tend to come from dynamically allocated IP addresses, or through pools of VPN hosts. Searching for known client IP addresses can be very effective in a hunting workflow, but they aren’t very useful for alerting. </p><h3>Server Side Web Shell Script Location </h3><p>The first characteristic to note is that the actors often place the server side web shell execution code in it’s own file. The web shell script is often found deep within the web servers directory structure. </p><p>One specific APT actor group has a tendency to name their web shells with a combination of two extensions (examples: deaspx.js or bonjs.asp).  Some actors place their web shells within already existing scripts, in these cases the following methods of web shell detection are still useful.</p><h3>User-Agents </h3><p>Most of the programs designed to interact with web shells allow the actor to change the reported User-Agent. Most of the time the actor does not.  A good indicator of the China Chopper web shell program is a User-Agent entry of "Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1)" in IIS access logs. Many of the User-Agents that are manually entered by the actors tend to be short variations of the Mozilla theme, sometimes as simple as "Mozilla/5.0”.</p><p>A less precise method of searching for malicious access is looking for User-Agents that are a bit older and out of date such as "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1623.0 Safari/537.36". Most of the actors who do change the default User-Agents of their tools to a valid value tend to set-it-and-forget-it for a few years. This method can be prone to false positives, but after learning what normal client behavior looks like on your web properties it becomes easy to notice the malicious activity.</p><h3>Referer</h3><p>One of the simplest methods for searching for Web Shell activity is to look through web access logs for traffic that is missing a referer. The traffic from most Web Shell programs does not leave a referer behind.  </p><h3>New URIs</h3><p>If your org has a strong monitoring system in place, searching for accessed URIs that have not been seen before is a good way to detect newly installed web shells. </p><h3>Client Characteristics </h3><p>Other characteristics of typical attacker Web Shell traffic can be discovered through a daily analysis of web access logs.  One characteristic of web shells that stands out is that the client host will often access the web shell script and ONLY the web shell script.  This is extremely strange, as most URIs often load additional content from the web server, and are usually browsed to via a linked page. </p><p>Often the malicious actors will access the web shell script using only one or two client hosts per day. Most valid URIs on a web server will be accessed by many client hosts.  You can often discover web shells (and staged exfiltration archives)  by performing frequency analysis on the web access logs, and evaluating any URIs accessed by only one or two client hosts. </p><p>In cases where the malicious actors use many client side IP addresses in a single day, frequency analysis of URI and User-Agent pairs can surface web shells.  Most legitimate URIs on a web server will be accessed by many different clients each with their own User-Agent. By searching for URIs that are only accessed by the least number of User-Agents you can often find a malicious web shell.</p>