The Evolution of Upatre and Dyre
Over the last few months, we’ve been tracking Dyre and reporting changes to the malware on this blog. Dyre’s latest iteration shows yet another shift in tactics – one that combines characteristics of Dyre with Upatre code to create a new downloader… Figures 1, 2, 3 and 4 shows three different emails, all with the same content but with different malicious links, which we we’ll use interchangeably in our examples.
These scripts generate more GET requests that download a base64 encoded .zip file (file-header:PK and content:outlook_setting_pdf.exe) as shown in Figure 6. The file download and redirections used in our analysis example do not always work with GET requests, but do respond to POST requests. This indicates that attackers want to allow only traffic from compromised users to come through as opposed to new users clicking the link. This applies on a case-by-case basis.
In Figure 7, the user downloads the .zip file (that was generated using the steps presented thus far) and is quickly re-directed to Microsoft.com in the background to make the download appear legitimate. (Figure 8)
Upon execution of the malware, the malware makes an interesting beacon.
While this is part of the January 12th campaign targeting the UK (1201uk1 string) we can see that the traffic is in the clear. Dyre traffic is normally sent via HTTPS over port 443 or over port 4443. Typically, we shouldn’t be able to see it in the clear (for stage 1). However, in Figure 10, we can see the typical Upatre download of an encoded binary file.
By dumping strings from the malware’s memory, not only do we see the download of the file from Upatre, but we are seeing references to the IP address from the Dyre beacon from Figure 9. This is significant because this shows a blending of Dyre and Upatre code into a new downloader, which we’ve dubbed Mini-Dyre.
Once Dyre is downloaded, it’s saved as a randomly named executable to C:Windows, executed, and injected into the memory of the top-most svchost.exe. By dumping the memory of the top-most svchost.exe and grepping for :443 or :4443, we can get a list of the C2 IP addresses that they are using. (Author note: doing memory dumps like this can cut off the first number of an IP address. Check them before blocking)
After a few minutes of being connected, Dyre downloads another tool, a mass-mailer. The communications are encrypted via SSL; however, if we step through the code with IDA (Figures 13 through 16), we can capture the requests to see what’s being transmitted.
They even set the locale to Russian.
The malware communicates with IP 37.187.71[d]173, which can be seen as both hard coded in the malware and the packet capture. Based on the sample we analyzed, we are seeing this to be true. It does not have to be necessarily true in all cases or for various other malware samples.
The IP address is also related to Feodo, which can be seen from the listing on Feodo tracker.
Additional strings can show what the malware is capable of.
Indicators pertaining to the file in the incident, “outlook_setting_pdf.exe” was the executable being carried by the zip file. The following Yara rule can help trigger on any matches to this condition.
$a1 = “PK”
$a2 = “outlook_setting_pdf.exe”
$a1 at 0 and $a2
With the rapid evolution of the phishing delivery mechanisms, malware downloaders and the malware itself, we will have a very interesting year. The rate at which Dyre and Upatre have changed is rather amazing.
In conclusion, it’s better to be aware of the context behind the email, such as the sender, sender’s email, attachment, link, etc., so that users can protect themselves from becoming victims of such evolving attack mechanisms.
Links to the samples can be found here:
Mini-Dyre / Upatre with Dyre: