Recent Dridex activity

Published: 2015-05-13
Last Updated: 2015-05-13 00:07:11 UTC
by Brad Duncan (Version: 1)
10 comment(s)


Botnet-based Dridex malspam is like the Energizer Bunny.  It just won't quit.  We see it almost every day.

Since last year, botnet hosts pushing Dridex have been using macros in Microsoft Word documents or Excel spreadsheets to deliver the malware [1].  These files are most often attachments in malicious spam (malspam).

Dridex traffic has evolved somewhat since I last blogged about it [2].  For this diary, we'll look at a wave from Tuesday, 2015-05-12 as described on the Dynamoo Blog [3].  I saw a few of these messages while reviewing emails blocked by my employer's spam filters.  Let's take a closer look...

Email Example

Nothing really ground-breaking here.  In this wave, hosts associated with Dridex malspam used the recipient as part of the name for the malicious attachment, but we've seen this before.

Traffic Generated by the Malware

I infected a host by running the Excel spreadsheet and enabling macros.  Reviewing the traffic with Security Onion revealed several info and policy events.  It also alerted for likely Dridexs cert in the SSL traffic.

A pcap of the traffic is available at:

Below is a list of HTTP GET requests and other indicators of compromise (IOCs) associated noted in the pcap file:

  • port 80 - - GET /download.php?i=5K5YLjVu
  • port 8080 - - GET /bt/get.php 
  • port 80 - - GET /7257790.jpg
  • port 443 - TLS traffic
  • port 443 - TLS traffic
  • port 3443 - TLS traffic
  • port 443 - TLS traffic
  • port 8000 - TLS traffic
  • port 443 - TLS traffic
  • port 443 - TLS traffic
  • port 80 - encrypted traffic
  • port 80 - encrypted traffic / TLS traffic
  • port 443 - SYN packet only (no response)
  • port 443 - SYN packet only (no response)
  • port 443 - SYN packet only (no response)
  • port 1443 - SYN packet only (no response)
  • port 80 - SYN packet only (no response)
  • port 443 - SYN packet only (no response)

Screenshots from the Traffic

After enabling macros for the malicious Excel spreadsheet, the host called for a visual basic script (VBS) file from pastebin:

The VBS file generated an HTTP GET request to download a Windows executable file (the Dridex malware):

Shortly after that, a small JPG image was downloaded by the infected host:

Dridex activity included SSL traffic to various IP addresses, mostly with SSL certificates.  I also noted an SSL certificate for as shown below:

SSL traffic happened on various TCP ports, including port 80:


People have submitted the Windows executable to various public sites for malware analysis:

A zip archive of the malware is also available at:

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

Final Notes

The last time I looked into Dridex traffic, I saw a lot of post-infection HTTP GET requests over port 80.  In this example, the post-infection traffic was mainly SSL or otherwise encrypted.  Can't wait to see what Dridex has in store for us next!

Brad Duncan, Security Researcher at Rackspace
Blog: - Twitter: @malware_traffic



10 comment(s)


See <>:
"Use Software Restriction Policies to Help Protect Your Computer Against an Email Virus"
I have read up that the malware is sandbox aware, did you do anything before running the malware? I tried and can't get some samples I had taken online to run it in my sandbox.
Mostropi, I'll generally use a physical host when I generate traffic for these diary write-ups.
that's cool to know. I am thinking of turning my old laptop to for these kind of sandbox aware malware. Is there any risk involve? I think ransomware or cryptolocker may just encrypted the whole thing which I think would even make system restore don't work? How did you usually turn it back to clean?
For a physical host, I'll usually use a write-blocker I got from a previous SANS course and examine the hard drive on a linux box. In most cases, the CryptoLocker/CryptoWall only encrypts personal files and leaves the rest of the computer usable, so you won't have to do that. Getting the host back to clean? I normally wipe the hard drive and re-install the OS, which is time-consuming. There are other methods to get back to a clean state, but I like doing the clean wipe and re-install.
That's some really good practice, i am considering doing something similar like that next year. how much that cost you for that physical host? Is it an old computer or you just get a really cheap one off the market? Just interested as I am looking for some real hands on in that aspect, the way you did it give me a really idea on where to start, some information on the cost would help me.
You can grab a cheap used computer like a dual core Dell from some reseller for well under $200. I've seen local resellers have computers available for under $100 (not counting the keyboard, monitor and mouse). Anything within the past 5 years will do. I personally like to build, so I'll just buy a cheap motherboard, hard drive, cpu, case, etc. and make my own.
how do you get that output for the vbs script? It doesnt seems like something that wireshark will display. Would appreciate if you could go through on that step to your findings?
Mostropi, that was some image editing, where I substituted the actual VBS script for the gzip compressed data that Wireshark would show. I got an uncompressed copy from the infected host.
I had check and confirm that wireshark doesn't display the truncated compressed gzip. The starting strings 337 of the packet can be found by the control + F function. However, when wireshark reconstructed the tcp streams, that portion was cut off.

Diary Archives