ISC Stormcast For Wednesday, August 9th 2017

How are people fooled by this? Email to sign a contract provides malware instead.

Published: 2017-08-09
Last Updated: 2017-08-09 00:05:00 UTC
by Brad Duncan (Version: 1)
4 comment(s)


Many security professionals often review malicious spam (malspam) as part of their daily work.  If you fall in this category, every once in a while you run across an email so obviously malicious, you wonder how people could be fooled by it.  I saw one such email on Tuesday 2017-08-08.

The link in this email led to a zip archive containing Sharik/Smoke Loader malware.  Sharik/Smoke Loader then retrieved TeamViewer to use as a backdoor on the infected host.  It also downloaded ransomware calling itself "Diamond Computer Encryption."

Shown above:  Chain of events for this infection.

In today's diary, I investigate that malspam and its associated malware.

The email

The email consists of an image from that links to  The image is followed by a random string on numbers barely visible in the message, because the text is a very light shade of grey.  Of note, the domain name was registered through NameCheap on the same day I saw the email (2017-08-08).

Shown above:  Screenshot of the email.

Just look at it.  The recipient was not someone in any position of authority to sign a contract.  The email sender is named "Contract" and uses some random email address.  And there is absolutely no context to the message.  I always ask myself how someone could be fooled by this, and the answer is apparently "you'd be surprised."

Clicking on the image from the message sent a zip archive.  The zip archive came from an Amazon Web Services (AWS) server, and it contained an executable file (barely) disguised as a contract for the recipient to sign.

Shown above:  Download pop-up after clicking the email link.

Shown above:  Contents of the zip archive sent from the AWS server.

Network traffic

After the malware was download from an AWS server, the infected Windows host generated post-infection traffic that included HTTP requests to (a legitimate domain) and (a malicious domain).  Network traffic triggered alerts for Sharik/Smoke Loader as I monitored it using Security Onion running Suricata with the EmergingThreats open ruleset.  I also saw TeamViewer traffic from the infected Windows host.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  TeamViewer traffic from the infection noted in Wireshark.

Shown above:  Events that triggered in Security Onion while monitoring the traffic.

The infected Windows host

Signs of a ransomware infection were apparent in the infected Windows host.  All encrypted files had random extensions appended to their file names, and the decryption instructions call the ransomware "Diamond Computer Encryption."  This ransomware was first reported by @PolarToffee on Monday 2017-08-07 on Twitter, but it appears to be a complete scam without any way to decrypt your files.  The bitcoin address from the decryption instructions doesn't change.  No email address or other contact info is available.  The instructions state all files will be automatically decrypted after making the bitcoin payment, but that apparently does not happen.

Shown above:  Examples of encrypted files from an infected Windows host.

Shown above:  Decryption instructions (part 1 of 2).

Shown above:  Decryption instructions (part 2 of 2).

I noticed two things about this ransomware.  First, it causes no post-infection traffic, except for a URL in the decryption instructions.  That URL causes an HTTP request for an image of a diamond from (a legitimate website).  Second, you must have version 4.0.30319 or higher of the .NET Framework installed, or the ransomware doesn't encrypt your files.

Shown above:  An isolated HTTP request to for this URL?  It could be associated with Diamond ransomware.

Shown above:  The ransomware didn't run properly until I updated my .NET Framework.


The Diamond ransomware was stored in a folder under the user's AppData\Roaming directory, and it used a Visual Basic (.vbe) file in the Startup folder to ensure persistence.  However, the ransomware deleted itself after encrypting files in my lab host, so that .vbe file generated an error after rebooting.

Shown above:  Location of Diamond ransomware executable on the infected host.

Shown above:  VBE file in the startup folder calling for the Diamond ransomware.

Although the Diamond ransomware deleted itself, the Sharik/Smoke Loader stayed persistent on the infected host through an entry in the Windows registry.  It had moved itself to a folder under the user's AppData\Roaming\Microsoft directory.

Shown above:  Windows registry update to keep Sharik/Smoke Loader persistent after reboot.

Shown above:  Location of the Sharik/Smoke Loader malware.

Shown above:  TeamViewer artifacts from the infected host.

Indicators of Compromise (IOCs)

The following are email headers from the malspam:

  • Date:  Tue, 2017-08-08 12:36 UTC
  • From:  Contract <>
  • Subject:  Please sign the contract.
  • X-PHP-Originating-Script:  0:class.phpmailer.php
  • Message-ID:  <>

The following are IOCs for network traffic related to this infection.  First is the link from the email and redirect to the AWS download:

  • port 80 - - GET /
  • port 443 - - GET /contrac9821/

Next is post-infection traffic during the infection to legitimate domains.  None of these are inherently malicious on their own:

  • - GET /
  • - POST /kb/2460049
  • Various IPs over TCP ports 443 and 5938 - TeamViewer domains - TeamViewer traffic

Finally, we have Sharik/Smoke Loader doing check-in traffic and downloading the Diamond ransomware executable:

  • port 80 - - POST /
  • port 80 - - GET /mariconets.exe

SHA256 hashes related to this infection are:

Final words

I saw some Twitter traffic stating Diamond ransomware also downloads TeamViewer.  However, in this case TeamViewer appears to have been downloaded by Sharik/Smoke Loader.  I tried the Diamond ransomware executable on its own, and it didn't generate any TeamViewer traffic.

Once again, I can't stress how obviously malicious I find this email.  Furthermore, any organization following best security practices shouldn't have anything to worry about.  But this example provides a somewhat interesting infection chain, and we must remain vigilant.  There's still a possibility this malspam might actually infect someone.

Email, artifacts, and a pcap of the network traffic for today's diary can be found here.

Brad Duncan
brad [at]

4 comment(s)
Diary Archives