ahsonbol

Detecting Upatre variants using Security Analytics

Blog Post created by ahsonbol on Jun 12, 2015

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.

Outcomes