Shells and Trojans

A “shell” is simply any user interface for access to an operating system’s services. Most computer systems will offer either a command-line interface (CLI) such as bash (Linux) or DOS (Windows), or else offer a graphical user interface (GUI), depending on a computer’s role and particular operation. A shell can be presented directly via a connected monitor and peripherals, or else across the network – for example via SSH on Linux, or RDP (Remote Desktop Protocol) on Windows.

Since these formal “front door” accesses are often closely monitored and regulated, hackers have long used techniques to establish unofficial and alternative shells as “back doors” into computer systems, unknown to the system owner. Historically, these can include malicious code left in place by rogue developers, or so-called “Trojan” software (named after the Trojan horse) that present themselves as legitimate and useful tools and are deliberately installed by system owners, but contain malicious code that can present a remote attacker with a back door into the system.

What is a web shell?

A web shell is a web-based implementation of the shell concept. There’s plenty of legitimate examples where a web shell might be useful functionality – for example to provide an administrative web GUI to an appliance such as a firewall, but for the purposes of this article we will consider malicious web shells – scripts that can be uploaded by an attacker to a web server to enable remote administration of the machine unknown to the system’s proper owner. Because the web shell is a back door, it is not monitored by security controls such as logging that official shells may be, and so access may go undetected.

A web shell uses code that leverages existing web-server software on a compromised host – such as WordPress, ASP or PHP code running on a web-server such as IIIS or Apache – so the code can be minimal (several kilobytes only) in size, and live within a single or handful of files that are hard to detect. Traditional Trojans and other backdoor software may open up new ports for the attacker to access them via. Because webshells piggyback off existing web services, it has the advantage from an attacker’s perspective that it doesn’t need to open any additional ports – it can be accessed by navigating to a particular page on an existing web service. Accessing the specific page that calls the webshell code allows the attacker to do things as if they were logged in to the server directly, and cannot be easily detected.

How common are web shells?

Web shells are commonly seen, and because they are hard to detect, access can be long-lived before an organisation is aware of them. Web shells such as China Chopper, WSO, C99 and B374K are frequently chosen by attackers.

How would a system become infected?

An attacker can take advantage of common vulnerabilities such as SQL injection, remote file inclusion (RFI), FTP, or even use cross-site scripting (XSS) as part of a social engineering attack in order to upload the malicious script to the server.

Once it is in place on a running web server, the web shell provides Persistent Remote Access – that is, it can be accessed at will by an attacker, either directly via a GUI, or programatically via a command and control script for malicious control of multiple compromised hosts.

Malicious use of web shells

The most basic malicious functionality offered by a web shell is the further compromise of the infected host – executing local shell commands and code, performing database enumeration and file access and data exfiltration. However, infected web servers may themselves have either outbound access to the internet or further access to the organisation’s internal network – the web shell can then therefore be used to enable “pivot” attacks against additional external or internal (and usually screened) hosts.

Web shells can be interacted with programatically via command and control scripts from a remote attacker’s system to make individual compromised hosts part of a botnet – a set of compromised systems that an attacker has access to and can control en masse, either to use themselves or to lease to other criminals. The web shell or backdoor is connected to a command and control (C&C) server from which it can take commands on what instructions to execute. This setup is commonly used in distributed denial of service (DDoS) attacks and, more recently, “crypto-mining”.

Detecting a Web Shell

Detection of web shells is incredibly difficult, often described as like looking for a needle in a haystack. Although there are “off the shelf” web shells that an attacker can use and that can be detected by examination of files for a given pattern by antivirus tools using static analysis and similar, there are hundreds of variants, and a knowledgeable attacker can write their own code in just a few kilobytes. However, there are some practical steps that can be taken:

Host-Based Detection

1. Monitor for abnormal high web server usage (due to heavy downloading and uploading by the attacker);
2.  Regularly scan and check for files with an abnormal timestamp (e.g. newer than the last modification date) or unauthorised modification to files that should be immutable;
3. Unknown connections in the logs of web server

Network-Based Detection

1. Monitor the network for unusual network traffic and connections using netstat

Prevention & Mitigation

Since detection of web shells is so difficult, it is important to try and prevent their introduction in the first place.

Host-Based Prevention

1. Use tools such as CIS Benchmarks to establish a secure configuration of web servers in line with best practices;

2. Ensure that web servers run in “least privilege” mode, i.e. that the process is owned by and executed as a non-privileged user and not the “root” user or other similar user with administrative privileges;

3. If using an application or CMS such as WordPress, try to avoid installing third-party plugins if you do not need them since these are often not subject to review and can contain either malicious code such as web shells, or simply weak/vulnerable code that can be used to install a web shell. If you need to make use of a plugin, ensure it is reputable and frequently updated

4. Where possible, restrict the write access of the web server as far as possible. If the web server interacts with a database but has no need to write files locally to disk, then set its permissions accordingly;

5. Perform a vulnerability scan of your web-server to limit local and remote file inclusion vulnerabilities

Network-Based Prevention

1. Establish a proper “DMZ” for web-servers, with strong network segregation from the rest of your network – that means limiting access between web servers and the rest of your network using firewalls to the minimal set of ports and services needed;
2. Use firewalls also to limit and restrict the establishment of outbound network connections from your hosts to the rest of the internet if this functionality is not required. If this is not possible, then use a reverse proxy service to restrict access.

Further Information

If you’d like any further information or would like to see what vulnerabilities we can pick up in your web applications then feel free to email us at info@localhost where an AppCheck representative can set up your free vulnerability assessment.