Akamai's CSIRT team advises companies to check their systems for Web shells, executable code running on a server that gives attackers remote access to a variety of critical functions.
Online adversaries can install Web shells by compromising legitimate Web applications on a server, using such tried-and-true techniques as SQL injection, Remote File Inclusion, an unvalidated file upload feature or through a valid user's stolen credentials.
Here are the basics of the CSIRT advisory, as written by Akamai Security Response Engineer Patrick Laverty:
A Web shell can also be seen as a type of Remote Access Tool (RAT) or backdoor Trojan file. The shell may be a full-featured administrative GUI or as simple as a single line of code that simply takes commands through a browser's URL field and passes them on to the back-end server.
Web shells can be written in any language that a server supports and some of the most common are PHP and .NET languages. These shells can be extremely small, needing only a single line of code or can be full featured with thousands of lines. Some are self-sufficient and contain all needed functionality while others require external actions or a "Command and Control" (C&C) client for interaction. When the shell is installed, it will have the same permissions and abilities as the user who put it on the server.
One of the most common PHP Web shells seen is the c99madshell. It is approximately 1,500 lines long and some of its features include displaying security measures the server may have in place, a file viewer that includes the files' permissions, an area where the user can run custom PHP code on the server, and the contents of phpinfo(). Phpinfo() is a core PHP function that creates a Web page and outputs valuable information about the OS, Web server and PHP configurations. It also has the ability to search the server for configuration files, password files and other writeable files and directories. It also has tools built in to encode/decode strings from various formats as well as a brute-force password cracker. It has a GUI to directly connect to a database server and if the attacker is concerned about detection, it has a function to self-delete the shell.
The big question we always try to answer is how those affected can fix the problem. Guidance in the advisory includes the following:
The main goal is to prevent a shell from getting on a server in the first place. The methods of infection include SQL injection and remote file inclusion through a vulnerable Web application. With frequent testing and monitoring, these vectors can be minimized.
For all types of shells, a search engine can be extremely helpful. Often, the shells will be used to spread malware onto a server and the search engines are able to see it. But some check the User-Agent and will display differently for a search engine spider than for a regular user. To find a shell, you may need to change your User-Agent to one of the search engine bots. Some browsers have plugins that allow you to easily switch a User-Agent.
Once the shell is detected, simply delete the file from the server.