Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2015 > June
2015

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.

The RSA Content team is pleased to announce the addition of new and updated content to the RSA Live Content Library! 

 

Let’s take a look at what we have released to RSA Live during the month of May:

 

  • 2 New Event Steaming Analysis (ESA) rules
    • These additions to our ESA rule library will help analysts detect rogue DHCP servers. This is important detection in order for customers to defend against man-in-the-middle attacks


  • 6 Updates to Event Streaming (ESA) rules
    • This will limit noise in customer ESA environments and ensure the most targeted intelligence in our rule library


  • 6 New Application rules
    • These additions to our Application rule set allows analysts to detect potential denial of service attacks


  • 10 Updates to Application rules
    • This will increase the accuracy of our out-of-the-box Application rules


  • 1 New Lua parser
    • This new FTP protocol parser provides visibility into file transfers


  • 6 Updates to Lua parsers
    • Improves protocol parsing accuracy


  • 1 New Log parser
    • BigIP Advanced Firewall Manager – Network based firewall. Based on the set policies, AFM has the ability to accept/reject/drop the traffic


  • 24 Updates to Log parsers
    • Improves parsing accuracy and supports newer versions of event sources

 

 

 

For a full breakdown of new/updated content released to RSA Live, go here:

 

May Announcements


 

Also, you can view our holistic content library and content request portals here:

 

RSA Live Content

Content Request Portals

 

 

The next few months will be busy on the content front! In addition to our ESA rule library project , we will be releasing rules and reports to help our customers detect ShadowIT within their organization. We also will be releasing some great content that provides visibility into AWS environments. To top it all off, we will be delivering reports for Security Analytics auditing use cases!

 

We look forward to sharing some great updates with you next month!

 

 

Regards,


The ASOC Content Team

ASOC.Content@rsa.com

Filter Blog

By date: By tag: