Botnet-based malicious spam seen this week

Published: 2015-06-17
Last Updated: 2015-06-17 00:01:41 UTC
by Brad Duncan (Version: 1)
7 comment(s)


Botnets continually send out malicious spam (malspam).  As mentioned in previous diaries, we see botnet-based malspam delivering Dridex and Dyre malware almost every day [1, 2].  Recently, someone sent us a malicious Word document from what appeared to be Dridex malspam on Tuesday 2015-06-16.  (Thanks, Wayne... You know who you are!)  Unfortunately, while investigating the malware, I could not generate the full range of infection traffic.  Otherwise, the traffic follows the same general patterns we've previously seen with Dridex [1].

Examples of the malspam

Dridex has been using Microsoft Word documents and Excel spreadsheets designed to infect a computer if macros are enabled, which matches the infection vector used by this malspam.  Shown below are two examples of the malspam from Tuesday 2015-06-16.  Both examples claim the recipient has made an error in tax forms.  This wave of malspam used a Word document for the malicious attachment.  As seen before with botnet-based malspam, the emails have different senders, subject lines, attachment names, and message text.  Due to these many differences, people usually have a hard time blocking it from their mail servers.

Examples of the Word documents

The image below shows an example of a Word document sent on 2015-06-16.  File names consist of random characters.  Random characters are also seen in the "Authors" and "Last saved by" fields.

Macros are not enabled in the default installation for Microsoft Office.  To infect a computer, most people will have to enable macros after the document is opened, as shown below.


Below is a screenshot of Wireshark displaying traffic seen from an infected host.

Traffic seems typical of Dridex we've seen the past couple of months.  Last month, the follow-up executable was retrieved from a URL over HTTP.  This time, the follow-up executable was retrieved from a URL using HTTPS.

The attempted TCP connections shown below would normally result in SSL traffic, but the servers did not respond.  That's probably an issue for this particular sample or possibly my environment's connection to the Internet.

  • port 80 - - GET /tmp/89172387.txt
  • port 80 - - GET /tmp/lns.txt
  • - Echo (ping) request
  • - GET /s/2djqlpaqdudzlrx/iol.exe?dl=1 (https)
  • port 80 - - GET /7230030.png
  • port 80 - - GET /images/notfound.png
  • port 2443 - attempted TCP connection
  • port 7443 - attempted TCP connection
  • port 8443 - attempted TCP connection
  • port 2443 - attempted TCP connection
  • port 7443 - attempted TCP connection

Reviewing the traffic in Security Onion using the Emerging Threats and ET PRO signature sets shows a few Snort events, as shown in the image below.  There's nothing Dridex-specific in the events, and I've seen used before with malspam using Chanitor to send Vawtrak [3, 4].  At first, I wasn't certain this was Dridex, but the VirusTotal entry for the downloaded EXE indicates this is probably Dridex [5].


The following artifacts were retrieved from the infected Windows host:

  • C:\Users\username\AppData\Local\Temp\21807.bat
  • C:\Users\username\AppData\Local\Temp\21807.ps1
  • C:\Users\username\AppData\Local\Temp\21807.vbs
  • C:\Users\username\AppData\Local\Temp\8.exe
  • C:\Users\username\AppData\Local\Temp\444.jpg

The file 8.exe is an executable that deletes itself shortly after it is executed.

Final words

Botnet-based malspam is something we see almost every day.  A quick Google search on Dridex returns several articles with good insight into this malware.  However, traffic from Dridex and other botnets continually evolve.  What's current one week could be out-of-date the next.

If you run across any interesting malspam, feel free to use our contact form and send us a copy.  We might not be able to investigate all submissions; however, we're always interested in the samples.

Traffic and the associated malware for this diary can be found at:

The zip file is protected with the standard password.  If you don't know it, email and ask.

Brad Duncan
ISC Handler and Security Researcher at Rackspace
Blog: - Twitter: @malware_traffic



7 comment(s)


And the conclusion is:
while an unsuspecting (really: uninformed) user may be fooled to turn of her first line of defense, i.e. enable execution of macros in Microsoft Office for her user account and thus allow the first stage of the malware (typically a dropper/downloader) to run, the second line of defense, AppLocker or SAFER alias software restriction policies, which was set by her not so uninformed administrator and can not be turned off by unprivileged users, effectively blocks the execution of the payload (which typically is the real malware).

So: administrators, start your eng^W^W^Wenable AppLocker or SAFER!
An important takeaway from this example that I always use in my security awareness training, is that both of the sample email messages are poorly written and each contain several grammatical errors. I use these type of messages in my training to illustrate that if it doesn't look right, then it probably isn't.
Thanks, Ian. These types of malspam are good to train with, and there are many to be found.
Ian B:
| if it doesn't look right, then it probably isn't.

But if it /DOES/ look right, it might still be wrong!

Last month I personally received two e-mails, purportedly sent by German DHL with no e-mail content but with a PDF attachment (I'm Dutch but understand German, and I have ordered packages from Germany in the past).

One can find quite some similar PDF's on the net, for example by Googling "das DHL Paket mit der Sendungsnummer" (including quotation marks):

Those two PDF's contain a few grammatical errors (that may be overlooked). However, the last PDF that _I_ received contained the following visible German text:

Hoch geschätzte Kundin, hoch geschätzter Kunde,

das DHL Paket mit der Sendungsnummer 623846298612 werden wir voraussichtlich am 29.05.2015 zustellen.
(ZIP Format)

Freundliche Grüße sendet
Team Versand, DHL

The only grammatical comment I can make is that "das" in the second sentence doesn't start with a capital-D.

As expected, the actual link points to a zip file on a different (compromised) host than shown. Such a zip file typically contains a PE file with a long file name, for example "DHL_Report_4145196367____ID29_DHL_DE_M05___BD29_05_2015___T23_09_15___MessageId_445670.exe" ( The file's icon is the one Explorer usually shows for PDF files, while the ".exe" part of the file name is usually invisible because of the long file name, if extensions are displayed at all.

I'm not sure whether these PDF's are actually malicious. According to VirusTotal, for example AVG reports "Script/PDF.Exploit.F" in 99a294160035169393099384eb1c292abfbbd551b701a371c00dac20d1549dfa, while F-Prot reports "PDF/UrlSpoof.F". Of interest for reverse engineers might be that the PDF's contain a lot of invisible text, that can be copied to clipboard using Sumatra PDF (that's what I used anyway). It looks like BASE64 but it's not, as it contains characters such as ! which are not part of base64 (see

On the other hand: last Monday, the person handling info@ mails in the company where I work, asked me to have a look at at typical malware mail, with grammatical errors all over the place and attached a 1MB "quotation" PDF. The bottom of the mail mentioned "Dit bericht is gescand op virussen, spam en gevaarlijke inhoud door <redacted>" while one the the mail headers said: "X-Spam-Processed: <redacted>, Mon, 15 Jun 2015 13:47:25 +0200 (not processed: message size (1772161) exceeds spam filter configured max size of (102400))". Purportedly this mail was sent by a _security_ company. After some research I concluded that it was legit...

Conclusion: perfect grammar and zero typo's do NOT mean it is safe to process an e-mail or document (and vice versa). Being asked to click on links (or permit macro execution) in order to read some text, should ring alarm bells, in particular if the link points to another site than shown and/or expected.
The biggest tell for me on these emails is that the sender's email address bears no similarity to the person's name used to sign the email off.

That's the first thing I look for.
I always love these diaries involving dridex, its very hard to get a dridex pcap without a logical host or bypass the VM detection. Keep up the great work!
[quote=comment#34387]I always love these diaries involving dridex, its very hard to get a dridex pcap without a logical host or bypass the VM detection. Keep up the great work![/quote]
Thank you for your feedback and ongoing support, Mostropi.

Diary Archives