Two Attacks… Two Dyres… All Infrastructure

November 6, 2014

Share Now

Over the last few days, we have seen two waves of Dyre. The attackers have changed things up a bit and made it harder to analyze. By using memory forensics techniques, we took a peek into their command and control (C2) infrastructure. The #1 rule of memory forensics…everything has to eventually be decoded, and we’re going to use this to our advantage. Here’s a quick look at the waves of emails we received. (Figures 1 and 2)

Figure 1 phishing fax — Figure 1 — First wave of Dyre

Upon clicking the link, the user is directed to a page and prompted to download a very small zip file that contains an executable.

Figure 2 -- vm fax — Figure 2 — Second wave of Dyre

Figure 3 -- .exe download — Figure 3 — Download of a small executable

Once opened, the user is presented with an executable inside of a zip file. If we take note of the modified date of the .exe inside of the .zip, we can see that this sample was uploaded to the attacker’s page a little over two hours before we received the wave of emails.

Figure 4 -- small executable — Figure 4 — Small executable, modified date of 11/6/2014 at 6:30 AM

Once executed, the malware attempts to beacon out for the second stage download. The file it requests is a PDF; however by looking at the headers of the content, it’s easy to see it’s not a PDF. (PDFs usually start with PDF-).

Figure 5 headers — Figure 5 — Packet Capture

Once downloaded, a very strange thing happened. Explorer.exe wanted to access the Internet, something that (should) rarely happen.

Figure 6 explorer.exe — Figure 6 — explorer.exe asking to go out to the Internet

At this point, I’m rather skeptical because explorer.exe normally doesn’t need to access the Internet. But lo and behold…the firewall is serious.

Figure 8 explorer connecting out — Figure 7 — explorer.exe connecting out through our Firewall

After confirming that the code was potentially injected into explorer.exe (based off of connections out), we dumped the memory of the process. Doing this allowed us to see what was “around” the memory location for the 46 IP address.

Figure 9 -- dumping explorer.exe — Figure 8 – Dumping explorer .exe memory

In Figure 9, we can see two things. First, we’re presented with our familiar Dyre URL requests. (#1) This is especially important because in the first annotation, this shows that the malware is attempting to communicate via HTTPS out, confirmed by both packet capture and explorer.exe connection ports. By dumping memory, we’re able to see this in the clear. Think of this as a little sweet justice when Dyre does browser hooking to bypass SSL.Second, we can see possible IP address configurations based off of potential communication ports from memory. (#2) This is where it gets fun.

FIgure 10 -- C2 IPs in memory — Figure 9 – C2 IPs in memory

By grepping 10 lines before and after the IP address and using a colon as a second grep filter, we find even more goodies.

Figure 11 IPs and configurations — Figure 10 – IPs and configurations

In #1 of Figure 11, we can see more IP addresses with the port of 443. Since there are also instances of 4443 too, we can use command line to see what other IP addresses are there. (Figure 12)

Figure 12 C2 IP addresses — Figure 11 – C2 IP addresses from memory

And by using a little more command line kung-fu, we can clean up this list of IP addresses, giving us an idea of how many C2 IP addresses Dyre is now using, currently 19 potential C2 nodes.

Figure 13 C2 IP addresses for Dyre — Figure 12 – Many C2 IP addresses for Dyre

In Figure 11 #2, there is a different looking IP address with the tag of . By grepping for this, we can see that many banks will be targeted with this.

Figure 14 Looking at Dyre's configurations — Figure 13 – Looking at Dyre configurations

Figure 15 Targeted banks — Figure 14 – Targeted banks

Since the bank URL configurations are shown in the tag, we can split and find out how many unique bank URLs are being targeted with this: 169 to be exact.And by looking at the litem tag, we can grep down to bank URLs that are being targeted. Here, it’s 281 unique URLs.

Figure 16 Targeted bank URLs — Figure 15 – Targeted bank URLs

For fax variants of the email, we have had success with the following Yara rule:

rule PM_Dyre_Delivery : dyre cryptowall crimeware
{
strings:
$domain1 = “goo.gl” nocase
$domain2 = “cubby.com” nocase
$domain3 = “dropbox.com” nocase

$subject1 = “fax message” nocase
$subject2 = “new fax” nocase
$subject3 = “fax report” nocase

$constant = “Resolution: 400×400 DPI” nocase

condition:

(1 of ($domain*) and 1 of ($subject*)) or ($constant)
}

For catching zip files with executables inside of them, we have had much success with the following rule:

rule PM_Zip_With_Exe
{
strings:
$hdr = “PK”

$e1 = “.exe” nocase
$e2 = “.scr” nocase

condition:
$hdr at 0 and (($e1 in (filesize-100..filesize)) or ($e2 in (filesize-100..filesize)))
}

And for catching voicemail variants, the following Yara signature can be used.

rule PM_Dyre_Voice_Message
{
strings:
$s1 = “voice message” nocase
$s2 = “voice redirected message” nocase
$s3 = “sent: ” nocase

condition:
2 of them
}