My Second look at W97.DOWNLOADER – Dridex dropper.

I performed it very quickly during the time my two devils (wife and son) are not active anymore (late night) with blurred eyes [In my personal isolated home based AV lab ;-)]… sorry for any mistakes.

The goal of my research was to get better understanding about the infection way, up to stage 4 [See Figure 1]:

Questions I asked (You can find the answers as indicators  … I will attempt to create some rules once time allow):

  • What is the obfuscation method for the first stage dropper (Office document itself)?
  • What are available tools/methods for Macro analysis
  • What can be done to improve the detection rate directly on the mail server?
  • Are there any Application Control rules which could spot such activity?

[Figure 1]

If you want to get more details from stage 5, please consult the blog from where I’ve taken this fancy figure 😉

In-depth analysis of a Dridex malware dropper



FILE: 6650_dc4e85fa6.doc (MD5: ae55d02cf8272772a6985a656866a675)

  • Initially not detected:

  • After manual submission to Symantec Security Response, file determined as W97M.Downloader



  • The File-type determined by VirusTotal is  HTML but file’s extension is .doc … it’s a strong indication of an obfuscation and should be taken into account by mail server solution.




Interesting HTTP requests:, GET, POST and /download.php?i=eWJNCzhb … but at this time the content on pastebin was already unavailable.

  • In the consequence the vbs file that was supposed to dropped and executed, failed to execute due to incorrect file content:

Note: In the same report you can see that the same VBS file does contain an html replay from the server instead of the code -> Type:  errwertttt.vbs – HTML document, ASCII text, with very long lines, with CRLF line terminators


Malware uses wscript.exe to start one of dropped files:

Note: Next indicators:

  • winword.exe starting wscript.exe which then launches a vbs file from %temp% ???… [Possibly a good candidate for a Device and Application Control rule]
  • winword.exe creating .vbs file ??? Really? [Possibly a good candidate for a Device and Application Control rule]


Oledump 0.16 (by Didier Stevens) C:\BIN\W97.DOWNLOADER\6650_DC4E85FA6.doc
-> Error: C:\BIN\W97.DOWNLOADER\6650_DC4E85FA6.doc is not a valid OLE file.

That was somehow expected, since it’s not an OLE file … reminder: VirusTotal says that the file type is: HTML … so let’s see:

Looks like mix of XML and  HTML … if we just search for “Content-Location” string, we do get info about .htm, .mso, .xml:

Line 7: Content-Location: file:///C:/EC2C4CD1/1.htm
Line 207: Content-Location: file:///C:/EC2C4CD1/1.files/editdata.mso
Line 374: Content-Location: file:///C:/EC2C4CD1/1.files/filelist.xml

So the actual type would be .mht file renamed to .doc (The use case is following: At this stage, we cannot see if it’s macro enabled or not, unless we decode mso)

Note: Next indicators:

  • File extension .doc with un-matching file content “Content-Location: *.htm”, “Content-Location: *.xml”, “Content-Location: *.mso” [String signature is feasible]

The interesting part is the .mso content encoded in base64:

Decoded the encoded part and saved it as ActiveMime.file:

That was the first time I heard about ActiveMime … I realized that it’s NOT documented and that it likely contains a header followed by a simple Zlib stream which ends with ADLER checksum… hopefully Zlib implementation automatically finds the end of the stream 😉

Info about ZLib signature:

78 01 – No Compression/low
78 9C – Default Compression
78 DA – Best Compression

I wrote “” and run against decoded “ActiveMime.file” (9Kb) -> Result: “ActiveMime.file.decoded.0” (44Kb) … so it seems that the decompression went fine.

Result: Finally OLE file (the MS Word doc) C:\BIN\W97.DOWNLOADER\ActiveMime.file.decoded.0 -p plugin_http_heuristics,plugin_dridex,plugin_vba_summary C:\BIN\W97.DOWNLOADER\ActiveMime.file.decoded.0


Olevba 0.11 (By Philippe Lagadec(decalage))

Initially version 0.10 failed with similar error then previous tool:

TypeError: C:\BIN\W97.DOWNLOADER\6650_DC4E85FA6.doc is not an OLE nor an OpenXML file, cannot extract VBA Macros.

Note: It’s good that the newest version of olevba has better support for MHTML and ActiveMime/MSO files parsing.


Lazy way (By Me)

Note: Of course you need to have a snapshot prior to the operation…

->Configure MS Word to DO NOT execute macros!
->Open the 6650_dc4e85fa6.doc (It will open in mht view + Protected View as far as I remember)
->Unlock and Save the document as real .doc (Word 2003, macro enabled)  [_LOADED_RESAVED_AS_DOC_6650_DC4E85FA6.doc]
->Patch Macro password protection 😉 … so you know the new password.

->Enjoy the Visual Basic Macro:



-errwertttt.vbs – (MD5: 38434c7549426071dc9782f96c1a502e) -> Determined as VBS.Downloader.Trojan  [VirusTotal: 24/56 (Submitted on 2015-06-17 14:35:08 UTC)]

  • Note that the detection rate is still quite low, keeping in mind simplicity of this threat and since how long it’s known (likely from 19th May 2015)

Google Search: “errwertttt.vbs” &

I crafted the script (based on Xavier Mertens script) which translates Chr() obfuscated strings to human readable string.

-> > errwertttt.vbs.txt.decoded

How does it work [Stage 2 .vbs]?

  • Script downloads the 435777658788888.exe from “hxxp//”
  • Once downloaded, the .exe will be executed via Shell.Application from %temp% folder
  • Script then downloads “hxxp//” … maybe to communicate that the script got executed?
  • Check if .exe process is running, if not sleep and re-check in a loop
  • Once the process is running and the loop quits, then it downloads hxxp// … Maybe to communicate a success?

At this time the pictures were removed from the server, but I think I saved one of them … I just love it!







All opinions and rants expressed are solely my own and do not express the views or opinions of my employer

All content and data is my own and does not represent work I have done for my employee