Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2015 > March > 09

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.

Knowing that the attackers usually have more time to come up with new ideas and methods to cause harm, those on the defensive side are always looking for new solutions that raise the bar higher for an attacker to do damage. In this blog post, we will discuss how built in security enhancements for popular software can be effective against an attacker.


The example we will use starts with an unusual User Agent string found in one of our RSA Security Analytics reports. The sample analyzed was using Google Chrome in its HTTP sessions. Below is a screenshot from RSA Security Analytics that shows HTTP traffic originating from the infected machine:


There are three files of interest in those sessions:

  • lgchknjnpaaohlppjfmhkcpbiibkclfh_.crx
  • external_extensions.json
  • id.php

But looking closely, we can see that the infected machine is also connecting to a sub domain. These are the domains provided by Google Blogger service. In response, the page returned some kind of a code or command to the infected machine:


Running the sample in a more controlled environment showed that the response above is necessary for the binary to continue its malicious behavior. The presence of the string is an indication for the binary that the download server is up so it can download the rest of the files on the infected machine.

Next, the malicious binary reaches out to a domain to download a JSON file, a PHP file and a CRX file:



And the string returned in the session above is used to as the filename in the following one:


On an infected machine that has Google Chrome browser installed, the downloaded JSON file is used to replace the existing external_extensions.json file located under

C:\Program Files\Google\Chrome\Application\40.0.2214.93\default_apps\

The external_extensions.json contains meta information about external extensions to Google Chrome browser. Information like name, version and location of the CRX file for each extension can be found in it. A CRX file has the extension code itself.

The malware downloads the CRX file to the same directory above. It copies itself to a temp directory under the name “YoutubeEveryday.exe”. It also modifies the registry to gain persistency on the system by adding a new entry to the auto run key.

So, the main goal of the malware is to remove all the existing extensions from Google Chrome and install the newly downloaded one.

Unfortunately for the malware (and fortunately for the rest of us), this method doesn’t work anymore. To protect Windows users, Google now allows external extensions installation if they’re only hosted on the Chrome Web Store. You can read more about the steps that Google took to make its popular Chrome browser more secure. This is an example of raising the bar higher for the attacker.

As of this writing, VirusTotal has a low detection rate for the sample under investigation.


The IOCs discussed in this blog post were added to RSA FirstWatch Live feeds.

Sometimes, it is really easy to spot the differences between regular and malicious network traffic. In this blog post, we will discuss how to detect a new Kazy based on the traffic originating from a couple of infected virtual machines in RSA FirstWatch Malware Analysis Systems.

The screenshot below shows the HTTP traffic between the bots and their C2 domains:


Using RSA Security Analytics to reconstruct one of those sessions we can see that the User Agent string is missing from the HTTP headers


Given all the network artifacts mentioned above and assuming the appropriate meta keys are enabled, an analyst can develop an app rule on RSA Security Analytics to detect the malicious traffic. The following query can be used:

            directory = '/spa0wejk2490234jsdf0rta/' && action = 'put' && filename = '<none>' && client !exists


As of this writing, VirusTotal has a low detection rate of the sample under investigation.

Finally, all of the IOCs from those HTTP sessions were added to RSA FirstWatch Live feeds.

Filter Blog

By date: By tag: