Nytro Posted December 8, 2014 Report Posted December 8, 2014 Dyre Attackers Shift TacticsDecember 8, 2014 By Ronnie Tokazowski On December 4th, several employees using PhishMe’s Reporter Button for Outlook reported new waves of Dyre phishing. The email appeared normal at first, but further analysis showed that the attackers have made a big shift in order to remain hidden. Here’s what the email looks like: Figure 1 — Dyre phishing email I’m not sure if this was on purpose, if the attacker’s script had some trouble, or if they were click happy, but the same user received several voice message emails. Figure 2 — Several emails reported with the PhishMe Reporter button Upon clicking the link, the user is presented with the option to download a zip file that contains an executable. Once the user visits the page, the background code also renders a counter that counts clicks. Figure 3 — GET request for the counter We can see that this counter has tracked around 10,000 clicks. These aren’t unique, as refreshing the page makes the counter increment by one. Figure 4 — Counter used by Dyre attackers The attackers are also changing the file names per download. Thankfully in our case, the hashes still match. Figure 5 — Hashes of files downloaded from Dyre campaign Once executed, the malware (in this case, Upatre) downloads an encoded payload which is Dyre. Upatre likes to use update-related user-agent strings when grabbing the payload. Figure 6 — Upatre downloading with the user agent string “realUpdate” Upatre also uses other user-agent strings such as “update” and “myupdate”. Looking for user-agent strings that contain these can help find potential infections in a network. Next, Dyre injects into the top-most svchost.exe. We saw this in early versions of Dyre as documented here (http://phishme.com/new-whitepaper-evolution-phish-phishing-delivery-mechanisms/) however it’s only recently that newer versions of Dyre have been capable of injecting into svchost.exe in Windows 7. By dumping the memory, running strings, and grepping for “:443” or “:4443” (ports Dyre uses for communication) we can see C2 IP’s, as well as a new addition. Figure 7 — IP’s dumped from memory with the addition of an i2p address While there is currently no response from this i2p node (Figure 8) there is successful i2p traffic going out from the infected system. (Figure 9) Figure 8 — Failed query for i2p address Figure 9 — Possible i2p traffic attempts For those who are unfamiliar with i2p, think of it as a more secure version of TOR, as things such as the true DNS destination are natively tunneled. I2p has aspects that are peer-to-peer, and every node is considered an exit node. In the case of Dyre, this could be to give the attackers a separate channel for communication, making it more difficult to analyze and detect. However, there are a few things we can do to cut them off. In the memory dump in Figure 7, we can see that the malware is configured to connect to an i2p domain via port 443. In Figure 8, we can see the actual DNS request going out. While we can’t specifically tell what’s going on in this case, by black holing i2p at the top-level domain we stop the propagation of the malware, as well as neuter any possible i2p traffic from a network. On the off chance that the attackers change domains to go over other ports for i2p, by configuring IDS systems to drop “GET /netdb/routerinfo”, we can cut off communications even further. (Figure 10) This applies to both HTTP and HTTPS protocols as well. Figure 10 — Portion of i2p traffic to block Here are the VirusTotal reports for the infections. Upatre: https://www.virustotal.com/en/file/2faf099c27af2c6f93601240e8e5525d6a66abd34a3431929da55982d0e728bc/analysis/Dyre: https://www.virustotal.com/en/file/5a148aa655b2e175e67205c398736e2a4bfe318cdcc990c1e77da354d8d3db39/analysis/Thanks to employees clicking the PhishMe Reporter button, we were able to quickly modify our Yara rule to match this latest strain. See the updated Yara rule here: Dyre_12_4Sursa: Dyre Attackers Shift Tactics - PhishMe Quote
