Since its announcement to the public in September of 2014, security researchers have ranked the Shellshock vulnerability as one of the most severe disclosed vulnerabilities. In an attacking scenario, the attacker would send a crafted request to an Internet facing service. If a vulnerable version of the Bash shell was configured to process the request, the attacker would be able to use it to execute commands on a victim machine. Because of this system administrators rushed to apply patches to the Unix-based shell used in many servers around the Internet.
Webservers in the RSA FirstWatch honeypot started receiving crafted HTTP requests that try to exploit the Shellshock bug. Below is a screenshot from RSA Security Analytics that shows how an attacker embeds the malicious code in the User Agent string field of the HTTP header:
In this scenario, the attacker is using the command line to download a perl script to the tmp directory of the victim machine, to run it and then to delete it. The downloaded script is a perlb0t script that has been around for a very long time. The bot communicates with its master through IRC channels. The IP address of the IRC server and the channel name are hard coded in the script. One of the functions in the script suggests the following features of the bot:
- Port Scanning
- HTTP Flooding
- TCP Flooding
- UDP Flooding
- Google search of servers running unpatched Mambo software
Below are screenshots of that perl function:
How to detect this using RSA Security Analytics?
If indexing is enabled on the client meta key, then you can create an app rule in RSA Security Analytics to detect these kind of scans. The app rule shall use the following query:
client begins '()'
Note: All IOCs from this attack were added to RSA FirstWatch Live feeds.
