Malspam on 2017-04-11 pushes yet another ransomware variant

Published: 2017-04-12
Last Updated: 2017-04-12 02:04:44 UTC
by Brad Duncan (Version: 1)
1 comment(s)


I ran across some interesting malicious spam (malspam) on Tuesday morning 2017-04-11.  At first, I thought it had limited distribution.  Later I found several other examples, and they were distributing yet another ransomware variant.  I personally haven't run across this paricular ransomware until now.

The ransomware is very aware of its environment, and I had use a physical Windows host to see the infection activity.  This diary examines the malspam and its associated ransomware.

Shown above:  Chain of events for an infection from this malspam.

The emails

I collected 14 samples of the malspam on Tuesday 2017-04-11.  It started as early as 14:12 UTC and continued through at least 17:03 UTC.  Each email had a different subject line, a different sender, different message text, and a different link to click.

Shown above:  An example of the malspam.


  • "USPS Ground" <>
  • "USPS Station Management" <>
  • "USPS Priority" <>
  • "USPS Ground" <>
  • "USPS International" <>
  • "USPS Ground" <>
  • "USPS Priority Delivery" <>
  • "USPS Ground" <>
  • "USPS SameDay" <>
  • "USPS Priority" <>
  • "USPS Ground" <>
  • "USPS Ground" <>
  • "USPS Express Delivery" <>
  • "USPS Ground" <>

Subject lines:

  • Delivery problem, parcel USPS #07681136
  • Delivery problem, parcel USPS #766268001
  • Delivery problem, parcel USPS #886315525
  • New status of your USPS delivery code: 74206300
  • New status of your USPS delivery code: 573677337
  • New status of your USPS delivery code: 615510620
  • Our USPS courier can not contact you parcel # 754277860
  • Please recheck your delivery address USPS parcel 67537460
  • Please recheck your delivery address USPS parcel 045078181
  • Re:
  • Status of your USPS delivery ID: 45841802
  • We have delivery problems with your parcel # 30028433
  • We have delivery problems with your parcel # 48853542
  • We have delivery problems with your parcel # 460730503

The traffic

The following links were in the emails.  All are subdomains of on port 80.  The domain was registered the day before on Monday 2017-04-10.

  • - GET /u844
  • - GET /tiyau72
  • - GET /p41733
  • - GET /zjhyi265
  • - GET /yxot3007
  • - GET /qnympenw4
  • - GET /avega046508
  • - GET /hip44
  • - GET /zuhjxai826625
  • - GET /qlwevgya2715078
  • - GET /fgl0067027
  • - GET /acai8521471
  • - GET /ysiwc47537447
  • - GET /uzoxy330

Any given moment, each email link led to a 404.html page that redirected to the same fake Office portal URL.  The following were Microsoft Office portal pages with links to the ransomware:

  • port 80 - - GET /wp-content/plugins/counter/1.htm
  • port 80 - - GET /.simg/counter/1.htm
  • port 80 - - GET /temp_cms/libs/sysplugins/counter/1.htm
  • port 80 - - GET //wp-content/counter/1.htm

Shown above:  Example of a 404.html page leading to a fake Office portal URL.

These fake portal pages all had links for Google Docs URLs that returned the ransomware.  The ransomware was disguised as an Office plugin.  Those URLs (at least the ones I've seen so far) were all reported to Google.

Shown above:  One of the fake Office portal pages with a Google Docs link for the ransomware.

The ransomware

The ransomware samples didn't run properly on my virtual machine (VM).  The samples also didn't run properly on free sandbox tools like and  I finally got an infection using a physical Windows host.  The encrypted files were all renamed with .MOLE as a file extension.  Decryption instructions were dropped as a text file named INSTRUCTION_FOR_HELPING_FILE_RECOVERY.TXT to the desktop and any directory with encrypted files.  Email addresses from the instructions were and

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  Personal files on my infected host had .MOLE for a file extension.

Shown above:  Screen shot of the decryption instructions.

Shown above:  Registry entries created for persistence.

There wasn't much on the post-infection traffic.  The infected host merely retrieved a public key and provided a file count (for the encrypted files) during the ransomware callback.  Characteristics of the ransomware binaries follow.

First example:

Second example:

Post-infection callback by the ransomware:

  • port 80 - - POST /scripts/superfish/js/supersubs.php

Shown above:  Callback traffic from the pcap in Wireshark.

Final words

My final words today are similar to my final words for yesterday's diary on Dridex malspam.

As usual, humans are the weakest link in this type of infection chain.  If people are determined to bypass all warnings, and their systems are configured to allow it, they will become infected.  Unfortunately, that's too often the case.  I don't believe the situation will improve any time soon, so we can expect these types of malspam campaigns to continue.

Emails, malware samples, and pcaps associated with the 2017-04-11 ransomware malspam can be found here.

Brad Duncan
brad [at]

Keywords: ransomware
1 comment(s)


Update: The first sample I had didn't run properly on or The second sample did.


Diary Archives