Two Attacks… Two Dyres… All Infrastructure

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
$domain1 = “” nocase
$domain2 = “” nocase
$domain3 = “” nocase

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

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


(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
$hdr = “PK”

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

$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
$s1 = “voice message” nocase
$s2 = “voice redirected message” nocase
$s3 = “sent: ” nocase

2 of them

For indicators, I have included 22 different Dyre C2 nodes, banks targeted, and a set of yara rules. You can download the Yara rules here:





Or download the .zip file here:dyre_indicators

Read More Related Phishing Blog Posts


We use our own and third-party cookies to enhance your experience by showing you relevant content, personalizing our communications with you, and remembering your preferences when you visit our website. We also use them to improve the overall performance of our site. You can learn more about the cookies and similar technology we use by viewing our privacy policy. By clicking ‘Accept,’ you acknowledge and consent to our use of all cookies on our website.

This site is registered on as a development site.