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:
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:
However, analyzing the traffic using SA shows that the directory values follow a pattern as shown in this screenshot:
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:
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:
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:
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.
