Searching for malspam

Published: 2016-06-09
Last Updated: 2016-06-09 00:11:10 UTC
by Brad Duncan (Version: 1)
1 comment(s)


About a week ago, I stopped seeing the daily deluge of malicious spam (malspam) distributing Dridex banking trojans or Locky ransomware.  Before this month, I generally noticed multiple waves of Dridex/Locky malspam almost every day.  This malspam contains attachments with zipped .js files or Microsoft Office documents designed to download and install the malware.

I haven't found much discussion about the current absence of Dridex/Locky malspam.  Since the actor(s) behind Dridex started distributing Locky in back in February 2016 [1], I can't recall any lengthy absence of this malspam.

Shown above:  Have others noticed a lull in Dridex/Locky? [2]

Of course, other campaigns are ongoing, so I figure it's time to review other examples of malspam.  These campaigns are somewhat harder to find than Dridex/Locky malspam, but they're certainly out there.

However, my field of view is limited, and I can only report on what I'm seeing.  With that in mind, this diary reviews two examples of malspam I found on Wednesday 2016-06-08.

First example

Our first example was sent to one of the ISC handlers' email aliases.  This example has a zipped .js file attachment.

Shown above:  Malspam sent to one of the ISC hander distros on 2016-06-08.

Shown above:  Contents of the zip file attachment from the malspam.

Shown above:  The extracted .js file opened in a text editor.

Running the extracted .js file on a Windows host generated plenty of HTTP traffic.

Shown above:  A pcap of the infection traffic filtered in Wireshark.

I saw plenty of artifacts on the infected host, and at least one of the items appears to be Andromeda, based on alerts seen when I played back a pcap of the traffic in Security Onion using Suricata with the ETPRO ruleset.

Shown above:  Alerts generated on the pcap from Sguil in Security Onion.

The Snort subscriber ruleset also generated alerts on the same traffic that triggered Andromeda hits with the ETPRO ruleset.

Some of the alerts after reading the pcap in Snort using the Talos Snort subscriber ruleset.

Second example

Our second example is Brazilian malspam in Portuguese sent to a different email address.  Instead of an attachment, this one has a link to download the malware.

Shown above:  Malspam sent to a recipient using a Brazilian email address.

Shown above:  Translation of the message from Portuguese to English.

The link from the malspam redirected to malware hosted on

Shown above:  Traffic caused by clicking on the link from the malspam.

Shown above:  Malware downloaded from the malspam link.

Here's what the HTTP traffic looked like from the infected host:

Shown above:  HTTP traffic from the second infection filtered in Wireshark.

In addition to the HTTP traffic, I saw IRC activity on TCP port 443 from the infected host to a server on at 

Shown above:  My infected host signing in to the IRC channel.

Shown above:  More IRC activity from my infected Windows host.

Of note, the hostname/username for my infected Windows host in this pcap is a throwaway.  Also, the IP address listed in the IRC channel is not the actual IP address of my infected host.

Alerts from this traffic show a Mikey variant, and this infection apparently added my Windows host to a botnet.

Shown above:  Alerts generated on the second infection from Sguil in Security Onion.

Indicators of compromise (IOC) - first example

Domain used for the initial malware download by the .js file:

  • port 80 -
  • port 80 -
  • port 80 -
  • port 80 -

Post infection traffic that triggered alerts for Andromeda malware:

  • port 80 - - POST /new_and/state.php 

Other HTTP traffic during this infection:

  • port 80 - - GET /prova/sd/Lnoort.exe
  • port 80 - - GET /prova/sd/Lnoort.exe
  • port 80 - - GET /prova/sd/romeo.exe
  • port 80 - - GET /prova/sd/romeo.exe
  • port 80 - - GET /audio/js.mod
  • port 80 - - GET /js/calc.pack
  • port 80 - - GET /statfiles/pz/
  • port 2352 - Attempted TCP connection to
  • port 80 - - HTTP POST triggered alert for Ursnif variant

Indicators of compromise (IOC) - second example

Traffic to retrieve the initial malware:

  • port 80 - - GET /m.php?id=[name] 
  • NOTE: See the pcap for the URL from hosting the initial malware

Post-infection traffic: 

  • port 80 - - Callback from the infected host
  • port 80 - - Callback from the infected host 
  • port 80 - - Callback from the infected host
  • port 80 - - GET /fix.dll
  • port 443 - attempted TCP connections to
  • port 443 - IRC traffic to

Final words

Malspam is a pretty low-level threat, in my opinion.  Most people recognize the malspam and will never click on the attachments or links.  For those more likely to click, software restriction policies can play a role in preventing infections.  And finally, people should be using properly administered Windows hosts and follow best security practices (up-to-date applications, latest OS patches, etc).

The same thing goes for Dridex/Locky malspam, which I expect will return soon enough.

But many vulnerable hosts are still out there, and enough people using those hosts are still tricked by this malspam.  That's probably why malspam remains a profitable method to distribute malware.

Pcaps and malware for this ISC diary can be found here.

Brad Duncan
brad [at]



1 comment(s)


Arubis has published some interesting information regarding the activity of Necurs here:
and Proofpoint has published a recent blog on this as well:

Diary Archives