You are ‘Shell’ed Part 3: No crime is perfect
In part 2 of the web shell series, we provided a deep exploration of the China Chopper web shell and the dangers associated with it. In this part, we explore the various detection mechanisms we could use to detect web shells.
How easy are they to detect?
Web shells are written using almost any programming language from PHP to GO. This allows an attacker to hide them in plain sight using generic names such as index.php. Sometimes, the web shell code might be embedded into existing legitimate files on the server.
An attacker could employ various obfuscation techniques to hide the true intent of the web shell code. Removing whitespaces, scrambling, encoding and encrypting the web shell scripts are some techniques that make it hard to detect them.
In the previous post, we have seen that the China Chopper has a client and server component. The server component serves as a backdoor and the client connects to the server on HTTP. The CnC traffic looks like this:
This is traffic for a simple ‘ls’ from the terminal access feature of the web shell client. As can be noted, the client component is making a POST request to the server backdoor. We can notice the base64 encoded data. The data translates to this PHP code:
Most of the communication is seen as base64 encoded data.
Based on the traffic presented before, we could write various snort rules to detect the communication (CnC) traffic of the web shell:
There are various places on the web server that we could search for the files and strings associated with a web shell. An administrator could regularly check for certain files, strings and suspicious network connections on the server host.
We could search for files and their timestamps. Recently changed files can be investigated. Here we are looking for recently changed files in the past 30 days:
We could search for patterns typical to a web shell:
We could get a snapshot of file hashes and compare them over time. Alternatively, the file hashes could be checked for maliciousness.
A web shell itself does not attack a vulnerable web application or server. A vulnerability is discovered in the app/server, and the web shell is bundled with the exploit. The web shell is implanted on the server following a successful exploit. In order to discover the vulnerabilities, threat actors use several reconnaissance tools such as vulnerability scanners to discover the underlying vulnerabilities. Two such commonly used scanners are ZmEu and Muieblackcat.
Both scanners look for vulnerabilities in various PHP modules such as phpMyAdmin. The typical files that are scanned for are:
The scanning activity could be detected with snort rules:
In conclusion, web shells are a credible threat to enterprise networks but are often overlooked. Given that they target web servers, the attack surface is quite broad and hence pervasive. The successful detection and prevention of web shells require a multi-pronged security approach such as regular patching, security assessment of internet facing systems, blocking of reconnaissance attempts, blocking of exploit attempts and prevention of lateral movement.