Malspam pushing ransomware using two layers of password protection to avoid detection

Published: 2018-04-20
Last Updated: 2018-04-20 04:12:50 UTC
by Brad Duncan (Version: 1)
0 comment(s)


Last month, I wrote a diary about malicious spam (malspam) using password-protected Word documents to distribute Sigma ransomware.  The campaign has remained active since then, with emails as recent as Wednesday 2018-04-18.  I investigated it again this week, and found this campaign was pushing GlobeImposter ransomware.  It was also using a password-protected Windows executable, which I assume is an attempt to avoid detection.

Shown above:  Flow chart for this infection chain.

Most users are well-protected against this threat.  Spam filters will generally catch these emails.  Furthermore, Protected View in recent versions of Microsoft Office should prevent users from accidentally getting to the macros in these malicious Word documents.  Default security settings for Windows Defender in Windows 10 should also prevent these infections.

However, people running previous versions of Windows might be affected, depending on their security settings.  Today's diary reviews what we've seen from this malspam campaign so far this week.

The emails

Malspam from this campaign follows the same general patterns reported last month, as shown in the images below.  This week, these Word documents used 123456 as the password.

Shown above:  Spreadsheet tracker for some of this week's malspam.

Shown above:  Screenshot from one of the emails.

Shown above:  Each of these attached Word documents asks for a password.

Shown above:  After the password is entered, I had to enable macros to get infected.

The infection traffic

Infection traffic consists of HTTP requests to, which is the same domain I reported last month.  This time, it's using update.bin instead of email.bin.  Since this is GlobeImposter ransomware, no post-infection traffic was noted.

Shown above:  Traffic from an infection as seen in Wireshark.

The infected Windows host

When I monitored a test host in my lab environment, I enabled macros and saw a file named taskwgr.exe appear in the user's AppData\Roaming directory.  I grabbed a copy and found it required a password to execute.

Shown above:  The password-protected executable for GlobeImposter ransomware.

People have removed the password protection from these Word documents and have submitted samples to  Do a Google search for "" and you'll find several examples.  I checked a recent sample and found a password in the process list.  In this case, the password for the executable was 252589.

Shown above:  Finding the password for taskwgr.exe.

My lab host showed signs of infection from GlobeImposter ransomware.  All encrypted files were appended with ..txt as the file extension.  And I found a decryption instructions in a file named Your files HERE.txt.

Shown above:  Examples of encrypted files on my lab host.

Shown above:  The message I got from Your files HERE.txt.

I accessed the decryptor through a Tor browser, and it asked for roughly $1000 US dollars as the ransom payment.

Shown above:  GlobeImposter decryptor.

Final words

This trend is somewhat troubling, because I can find hundreds of examples from this campaign using VirusTotal Intelligence that show zero detection.  In the image below, I searched VirusTotal Intelligence with the following parameters and found 183 examples of Word documents from this most recent wave:

tag:attachment tag:doc positives:0 fs:2018-04-18+ size:39424

Shown above: 183 examples with zero detection on VirusTotal.

I've seen this trick before, where a malicious macro, VBS, or JS file retrieves follow-up malware that's password-protected.  In these cases, the password is stored and implemented by the macro, VBS, or JS code.  I'm not sure how effective this is, because I was still unable to infect a Windows 10 host with default security settings.  And as usual, any properly-administered Windows host in an environment that follows best security practices should be well-protected against this threat.

I expect we'll see more examples of this malspam in the coming weeks.

Brad Duncan
brad [at]

0 comment(s)


Diary Archives