When analyzing tools, tactics, and procedures for different malware campaigns, we normally don’t see huge changes on the attackers’ part. However, in the Dropbox campaign we have been following, not only have the attackers shifted to a new delivery domain, but they have started to use a new malware strain, previously undocumented by the industry, named “Dyre”. This new strain not only bypasses the SSL mechanism of the browser, but attempts to steal bank credentials.
Figures 1 and 2 show the phishing emails that were used against us:
My first instinct was to gather intelligence on the “Cubby” domain. Upon investigation, it‘s a legitimate service from LogMeIn that allows for file sharing. According to their website, “Files are stored in the cloud for anywhere access, shared with others publicly or privately, or even directly synced between devices without using the cloud.” Since Dropbox has been quick to block phishing links, the attackers needed a new legitimate service.
[Disclosure: I called LogMeIn support (owners of Cubby), and reported these attacks to the correct personnel.]
The malware downloads as a screen saver file inside of a zip file. Once the user opens the zip file and runs the .scr file, the malware beacons out to several hard coded IP addresses as seen here:
Once the IP addresses can be reached, the malware will make the following GET request for a path to /publickey/. The current function of this data is unknown.
Next, the malware sends a beacon containing the OS in a GET request:
Then the malware makes a GET request to “/1/”, where a potential command is sent back to the malware.
Once complete, the malware continues to beacon, more than likely to let the attackers know “I’m still here”.
At this point, the malware kept beaconing out with the same “I’m alive” beacon, and no other data was being pulled down. Wanting to entice the malware to do a little more, I opened Firefox, directed the browser to Google and was amazed at what happened next. Here’s a picture of the pcap:
There are several takeaways from Figure 7:
1. POST request goes out to the attackers IP, 199.9.6[d]61
2. Content length is 466 bytes
3. A second POST request? Shouldn’t that go to Google, not the attackers?
4. Blue response is a 502 from attackers command-and-control
5. Back to 3. Didn’t Google go HTTPS with everything…?
As previously stated, there are 2 POST requests showing up. This is by design, it’s not a mistake. Using another search engine, what happens when an infected user performs a Bing search?
In Figure 8, the user’s search query is presented to the attacker. Not only that, but, their session could be hijacked as their cookie is passed also, allowing the attacker to log in as that user if they so desired.
The malware is highly packed and obfuscated, giving low AV detection. At the time of writing, a little more than half of AV vendors detect it.
When performing malware analysis, one of the first things an analyst will do is run the command strings on the malware in order to get an idea of what they are working with. With a heavily obfuscated or packed sample like this, you can’t run strings, as you’re going to get gibberish that’s of little use. From a memory forensics / malware analysis perspective, for most code to execute, it must first be unpacked to be executed. By dumping the memory and then running strings on the dump file, we get a better picture of what the attackers are really after. (Figure 10) Additional analysis of the strings in memory yield a project name of “C:CPP_PROJECTS_GITDYREx64Releaseiebattle.pdb”, which is usually added by the compiler at compile time. This is the project path, giving us insight about the malware author and the project. For this, the source code may sit on the author’s C drive in the folder CPP_PROJECTS_GIT as the project DYRE. (Why I’m calling this new malware strain project Dyre).
In Figure 9, attackers are looking for queries to places such as Bank of America, Citigroup, and the Royal Bank of Scotland. In Figure 10, if a user attempts to log into one of the banks, their data is also POSTed back to the attackers without alerting the user.
A few things to point out from Figure 10:
1. Company ID used at login
2. Username associated with Company ID
3. Referrer coming back from https
4. Previously used username, included in the cookie
Here’s the kicker. All of this should be encrypted and never seen in the clear. By using a sleight of hand, the attackers make it appear that you’re still on the website and working as HTTPS. In reality your traffic is redirected to the attackers page. In Figure 11, infected users are being directed to the hard coded IP address of “85.25.148[d]6” with a host field of “c1shproonline.bankofamerica[d]com”.
To successfully redirect traffic in this manner, the attackers need to be able to see the traffic prior to encryption, and in the case of browsers, this is done with a technique called browser hooking. No DNS queries were performed for the c1sh Bank of America domain, suggesting the attackers simply appended this to the Host field in the network traffic.
In closing, this appears to be a brand new malware family targeting users. (And if it’s not, please let us know!) Browser hooking is a very effective technique, and from the samples and screenshots above, an attacker can successfully bypass the SSL mechanism of a webpage while appearing to have the session encrypted. For protection and remediation, here’s what you can do:
1. Remove above emails from inboxes
2. Check your proxy logs for traffic to Cubby, downloading zip files containing the name “documents” or “invoice”
3. Search for traffic / block the IPs 22.214.171.124, 126.96.36.199, and 188.8.131.52
4. IDS rules looking for double POST within a short period of time (this will catch copy cats, too)
5. Look for zip files containing .exe or .scr files (web, IDS, host-based, etc)