|
Introduction 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: http://malware-traffic-analysis.net/2015/05/12/2015-05-12-dridex-traffic.pcap Below is a list of HTTP GET requests and other indicators of compromise (IOCs) associated noted in the pcap file:
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 example.com SSL certificates. I also noted an SSL certificate for example.net as shown below:
SSL traffic happened on various TCP ports, including port 80:
Malware People have submitted the Windows executable to various public sites for malware analysis:
A zip archive of the malware is also available at: http://malware-traffic-analysis.net/2015/05/12/2015-05-12-dridex-malware.zip The zip file is password-protected with the standard password. If you don't know it, email me at admin@malware-traffic-analysis.net 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! --- References: [1] http://researchcenter.paloaltonetworks.com/2015/01/dridex-banking-trojan-begins-2015-bang/ |
Brad 335 Posts ISC Handler |
| Subscribe |
May 13th 2015 4 years ago |
|
See <https://technet.microsoft.com/en-us/library/hh994580.aspx>:
"Use Software Restriction Policies to Help Protect Your Computer Against an Email Virus" |
Anonymous |
| Quote |
May 14th 2015 4 years ago |
|
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 27 Posts |
| Quote |
May 21st 2015 4 years ago |
|
Mostropi, I'll generally use a physical host when I generate traffic for these diary write-ups.
|
Brad 335 Posts ISC Handler |
| Quote |
May 21st 2015 4 years ago |
|
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?
|
Mostropi 27 Posts |
| Quote |
May 21st 2015 4 years ago |
|
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.
|
Brad 335 Posts ISC Handler |
| Quote |
May 21st 2015 4 years ago |
|
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.
|
Mostropi 27 Posts |
| Quote |
May 21st 2015 4 years ago |
|
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.
|
Brad 335 Posts ISC Handler |
| Quote |
May 21st 2015 4 years ago |
|
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 27 Posts |
| Quote |
May 28th 2015 4 years ago |
|
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.
|
Brad 335 Posts ISC Handler |
| Quote |
May 28th 2015 4 years ago |
|
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.
|
Mostropi 27 Posts |
| Quote |
Jun 3rd 2015 4 years ago |
Sign Up for Free or Log In to start participating in the conversation!
