Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: ahsonbol
1 2 Previous Next

RSA NetWitness Platform

17 Posts authored by: ahsonbol

Trojan.BLT is a remote access trojan associated with a major APT campaign. In this blog post, we will discuss how to detect its network activity using RSA Security Analytics.

When it infects a victim machine, the RAT launches a new instance of cmd.exe and uses the “ipconfig/all” command to collect the system MAC address. It sends the MAC address in clear text to its C2 server via an HTTP POST request as seen in the screenshot below:


125815


The URL varies from one Trojan.BLT variant to another:


125826


Assuming the appropriate meta keys are enabled, the following query can be used to detect Trojan.BLT network activity:

          action = 'put' && extension = 'asp' && (query begins 'rsv_info=' || query begins 'hostid=')


Scan results for a Trojan.BLT variant can be viewed here.


All of the IOCs from those HTTP sessions were added to the following RSA FirstWatch Live feeds:

  • RSA FirstWatch APT Threat Domains
  • RSA FirstWatch APT Threat IPs

If threat.desc meta key is enabled then you can use the following app rule:

          threat.desc = 'apt-blt-c2'

For the last few weeks, Dridex campaigns have been on the rise. The banking trojan spreads through well-crafted spam e-mails that employ social engineering techniques to trick a user into running a macro in an attached Microsoft Word document or a Microsoft Excel spreadsheet. In this blog post, we will discuss how to detect Dridex network activity using RSA Security Analytics.


When the macro code runs, it downloads Dridex to the infected machine. This is how the download session looks like in RSA Security Analytics:


125791


Downloading executables is not necessarily malicious but it is always worth another look. One way to find this kind of traffic in Security Analytics is to use the following query:

          service = 80 && filetype='windows_executable'


Newer variants of Dridex use SSL to communicate with their C2 servers over non-standard ports. As with other malware families, the servers use self-signed certificates for SSL communication.


125792


Although the SSL network activity shown above is not unique to Dridex, it is safe to say that it is suspicious enough to draw an analyst interest. Assuming the appropriate meta keys are enabled, the following query can be used to detect it:

          risk.suspicious = 'ssl certificate self-signed' && risk.info = 'ssl over non-standard port'


You can find VirusTotal scan results for one Dridex variant here.


All of the IOCs from those sessions were added to the following RSA FirstWatch Live feeds:

  • RSA FirstWatch Command and Control IPs
  • RSA FirstWatch Command and Control Domains

If threat.desc meta key is enabled then you can use the following app rule:
          threat.desc = ' c2-dridex'

Mirage is a remote access trojan that has been associated with different targeted attacks. The malware family got its name from one of its embedded strings. In this blog post, we will discuss how to detect its C2 beaconing activity.


Once it infects a machine, Mirage starts collecting system information like:

  • MAC address
  • CPU information
  • System name
  • Username


The collected information is then encoded using a custom algorithm and sent to the C2 server in the payload of an HTTP POST request:


124250


The screenshot below shows the network activity in RSA Security Analytics investigator:


124251


Assuming the appropriate meta keys are enabled, the following query can be used:

          action = 'put' && directory = '/' && (filename begins 'search' || filename begins 'result') && (filename contains 'gid' || filename contains 'meta') && extension = '<none>' && content = 'application/x-www-form-urlencoded'


Scan results for a Mirage variant can be viewed here.


All of the IOCs from those HTTP sessions were added to the following RSA FirstWatch Live feeds:

  • RSA FirstWatch APT Threat Domains
  • RSA FirstWatch APT Threat IPs

If threat.desc meta key is enabled then you can use the following app rule:

          threat.desc = 'apt-mirage-c2'


Cmstar is a custom downloader that was used in cyber espionage attacks. The name comes from one of the strings its author writes to a text file on an infected machine for debugging purposes. Cmstar network activity is close to Enfal; a malware family that has been used in targeted attacks for years.


Cmstar collects some information about the infected system like the Windows version, the CPU architecture and whether an antivirus is installed or not. It encodes all that info using a single byte XOR algorithm and sends them to its C2 server via an HTTP POST request. Cmstar uses the same XOR algorithm to build the URL and other HTTP request parameters from embedded encoded strings.


Event reconstruction of one of those sessions shows the encoded information being passed from the infected system to the C2 server:


121643


Values for both directory and filename meta keys were the same in all samples analyzed by FirstWatch:


121665


Assuming the appropriate meta keys are enabled, the following query can be used to detect Cmstar network activity:


          action = 'put' && directory = '/cgl-bin/' && extension = 'cgi' && client !exists


You can read more about Cmstar on Palo Alto unit 42 blog.


All of the IOCs from those HTTP sessions were added to RSA FirstWatch Live feeds.

In this blog post, we will discuss the beaconing activity of new Daserf variants that surfaced last week. The backdoor communicates with its C2 domain over HTTP using both GET and POST requests.


First, the malware issues a GET HTTP request to download a GIF file from its C2 server. The response is not a GIF file but an XOR encoded URL string. While the GIF filename varies from one Daserf sample to another, the directory name remains the same.


121451

 

Daserf decodes the URL received from the server and concatenates it to an ASP filename. It uses the new URL for further communication with the C2 server using POST HTTP requests. The first of them contains encoded information about the infected system like its hostname, its IP address and its language.


121467


The malware uses a hard coded list of pseudorandom ASP filenames. Every filename is exactly 5 characters long. In addition, all the analyzed samples use the same hardcoded user-agent string in their HTTP communication with the server.


121468


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


          action = 'get' && directory = '/images/' && extension = 'gif' && filetype != 'gif' && client = 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; SV1) '


          action = 'post' && filename length 9 && extension = 'asp' && content = 'application/x-www-form-urlencoded' && client = 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; SV1)'


You can find VirusTotal scan results for one Daserf sample here.


All of the IOCs from those HTTP sessions were added to RSA FirstWatch Live feeds.

XtremeRAT is a publicly available remote access tool that has been around for few years now. It has been used by different malicious actors for targeted attacks as well as cybercrime operations. In this blog post, we will discuss how to detect the traffic between an infected host and the C2 server controlled by the attacker.


Once a host is infected, it sends an HTTP POST request to the C2 server as shown in the screenshot below:


119109


There are some interesting artifacts in the session above. XtremeRAT embeds information about the infected host in its UA string. The information contains the hostname, the username, date of infection as well as the version of Windows.


Developing an app rule based on those UA string values is a bit tricky. Unless all the hostnames in your environment follow a certain pattern, you might miss some of the infected machines. Luckily, enough information is available to detect the beaconing activity. This screenshot from RSA Security Analytics shows the network traffic between a group of XtremeRAT infected machines and their C2 servers:


119110


Other filenames that XtremeRAT variants are known to use:

  • is-enum-driver
  • is-enum-faf
  • is-enum-process


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:

          action = 'put' && filename begins 'is-' && extension = '<none>'


Scan results for an XtremeRAT sample can be found here.

Elise is a backdoor malware family used in operation Lotus Blossom, the cyber espionage campaign identified by Palo Alto unit 42 last month. Elise variants communicate with their C2 servers using HTTP or HTTPS. In this blog post, we will discuss how to detect Elise network activity using RSA Security Analytics.


In case of communication over HTTP, a variant sends the following GET request:


116310


Directory names differ from one variant to another as Elise uses the last four octets of the infected machine MAC address to derive its value. That means the length of the directory field is fixed. In addition, Elise uses the current time of the system as a seed to generate a random value for the second part of the filename. However, the first part of the filename value is the same for all variants as seen in the screenshot below:


116311


Assuming the appropriate meta keys are enabled, the following query can be used to detect Elise HTTP behavior:

          directory length 10 && filename begins 'page_' && extension = 'html'


As for HTTPS communication, the subjects and CAs of the self-signed certificates used in those sessions simply stand out:


116312


116313


Scan results for an Elise variant can be viewed here.


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

A couple of weeks ago, security researchers at Palo Alto blogged about a new keylogger malware family called KeyBase. According to Palo Alto blog, the keylogger could be purchased directly from its author for $50. Although it is quite unsophisticated, KeyBase remains a threat that spreads through phishing campaigns mainly targeting high tech, higher education and retail industry.


Once it runs on an infected host, the malware sends a notification to its C2 server. Time on the host and its name are sent in clear in the query string of the URL:


115465


For KeyBase variants C2 beaconing activity, filename and query string format are fixed. However, directory names vary from one server to another:

 

115466


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:

          filename = 'post.php' && query begins 'type=' && client !exists


Scan results for a couple of KeyBase variants can be found on VirusTotal:

     SHA1: 6569a933f82c9ff8c06c2cfc70da0efd92d78a95
     SHA1:
ef0d13645fab775a21f00ffff5b587955884498c


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

Sakula is a remote access tool associated with multiple APT campaigns. Once it infects a victim machine, Sakula can perform many tasks including launching remote shells, enumerating processes and downloading files. In this blog post, we will discuss how to detect Sakula C2 beaconing activity.


Sakula variants try to connect to their C2 domains or C2 IP addresses using HTTP GET and POST requests. Below is a screenshot of reconstructing one of the sessions in RSA Security Analytics:


114316


The User-Agent string in this session stands out and could be used to develop an app rule:

          client='iexplorer'


Applying this rule in Security analytics shows that the UA string is used to beacon to C2 domains from multiple infected machines in RSA FirstWatch malware analysis systems:


114317


Although the UA string above is commonly used by Sakula, we have seen samples that follow the same URL pattern but with a totally different UA string. So it is better to develop an app rule that focuses on the URL elements. Assuming the appropriate meta keys are enabled, the following query can be used:

          extension = 'asp','jpg' && query begins 'imageid=','cstring=','resid='


Scan results for a Sakula variant can be viewed here.


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

For quite some time, malicious actors have relied upon Upatre to deliver their malware to the endpoints. While Upatre is capable of downloading any malware family to an infected machine, it has been mostly used in conjunction with the infamous Dyreza banking trojan. Delivered through spam campaigns, Upatre usually downloads and displays a PDF document to the infected user while performing its malicious functionality in the background.


Since it was first spotted in August 2013, Upatre has been evolving dramatically making it harder for analysts to detect it and to understand the communication between an infected system and the command and control server. In this blog post, we will discuss multiple ways to detect different variants of Upatre using RSA Security Analytics.


Initial variants of Upatre were easy to detect because they used a pretty unique User-Agent string in all their HTTP communication as shown in the screenshot below:


114286


It is worth mentioning that those variants are not extinct just yet so you can detect them using the following app rule in SA:
          client = ‘Mazilla/5.0’

 

Later, Upatre authors moved to a more regular User-Agent string trying to blend in with normal traffic:

 

114287

 

However, analyzing the traffic using SA shows that the directory values follow a pattern as shown in this screenshot:


114312


You can detect those variants using the following app rule in SA:
          directory begins '/smak21/'

 

The only problem here is that Upatre authors keep changing the parent directory name. For example, this is another variant using a similar directory structure but a slightly different parent directory name:


114313


Some of the parent directory names that RSA FirstWatch has seen in the last few weeks include:

     SWA22
      TDK11
      TK11
      TKB11
      TKB77
      TL11
      TL12
      TSI22
      WK11
      WK21
      WK22
      WOK22
      WSB21
      IMG21
      KAA1
      KAS11
      KAS12
      KAS21


Fortunately, when the authors started abandoning the ‘Mazilla/5.0’ User-Agent string, they also made another change. Instead of checking the IP address of the infected machine by issuing a request to checkip.dyndns.org, they are currently using only icanhazip.com. Presence of HTTP GET requests to the latter service could indicate that one of the systems in your network is infected. You can use the following rule on SA to detect those requests:

          alias.host = 'icanhazip.com'


To add more obscurity to the communication between a client and a server, Upatre authors made yet another move by using SSL instead of HTTP. As one might expect, self-signed certificates are heavily used in this scenario:

 

114314


Studying more Upatre variants with similar network behavior shows that the Certificate authority is not only random looking but always 24 characters long. Assuming the appropriate meta keys are enabled, an analyst can use the following rule to detect the malicious traffic:
          service = 443 && risk.suspicious = 'ssl certificate self-signed' && ssl.ca length 24

This is a screenshot from SA reporter module that show some of the anomalies in SSL CAs in RSA FirstWatch malware analysis systems in one day:


114315


More information on the discussed samples can be found on VT:

     (md5: 765548804940bc4cdab32ae12c7f5847)
     (md5:
d27d89044db2e7efea81fc4f2705fb02)
     (md5:
98d7d8f304898f0d9839bdf3254b88ee)


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

Last week, Symantec blogged about a new reconnaissance tool used in attacks that target the energy sector with a focus on the Middle East. Laziok, as called by Symantec, is an information stealer that collects configuration data about the compromised machines to help the attackers tailor their attacks against the victims. The collected data include:

  • Computer name
  • Installed software
  • RAM size
  • Hard disk size
  • GPU details
  • CPU details
  • Antivirus software

 

According to the Symantec blog post, the campaign started in January which is about the same time that RSA FirstWatch Malware Analysis systems started processing some of those binaries.The screenshot below shows Laziok activity in our systems between mid-January and late-March:


109985


Digging deeper into the traffic between the infected machines and the C2 domains, there are some observations to make:


109987


The User-Agent string is pretty unique but it is not present in all of the HTTP sessions so it can’t be used to detect all the HTTP GET requests to the C2 domains. However, the directory name and file extensions are unique and seem to be present in all of the related sessions.


Reconstructing one of the sessions using RSA Security Analytics clearly shows the kind of information collected from the infected machine and sent to the C2 domain in the query string:


109986


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:

action = 'get' && directory = '/panel/includes/' && extension = 'php'

You can find VirusTotal scan results for one Laziok sample here.


All of the IOCs from those HTTP sessions were added to RSA FirstWatch Live feeds.

Tinba is an info stealer malware that uses web injects to trick users of different financial institutions into giving their personal information like social security number, address and credit card information. The malware family; that was first identified by security researchers at Trend Micro and CSIS; got its name from its small size. That’s right, a tiny banker Trojan.


We identified a new Tinba variant in RSA FirstWatch Malware Analysis Systems. This is a screenshot from the investigator module in our RSA Security Analytics instance:


108551


As expected the communication between the infected machine and its C2 domain is encoded and/or encrypted.


108552


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 = '/el0hjkd76ghs65dhj0it/' && action = 'put' && filename = '<none>' && extension = '<none>'    


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


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

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:


108172


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:


108173


108174


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:


108167


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 blogspot.com 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:


108168


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:


108170

108169


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


108171


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:


108165


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


108166


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: