With the exception of a few unconfirmed reports of Dridex targeting Baltic countries (which doesn’t make much sense economically), infection campaigns have ceased since mid August when Dridex briefly resumed spreading to propagate multiple new botnets aimed at Switzerland.

This morning a friend of mine, Liam, reported receiving a malicious email which unusually didn’t get caught by his spam filter.

Looking at the mail header we could quickly see exactly why the spam filter didn’t pick it up (it passed an SPF checked), which means the server sending the email was authorized by the domain owner. Due to the fact Necurs (the main source of Dridex spam) uses spoofed sender addresses we can rule that out, which would explain why I didn’t catch the spam in my botnet monitoring system.

As we can see from a lookup on the domain using OpenDNS Investigate, the site is small but active and was registered in 2013, making it unlikely that the Dridex crew bought the domain themselves with the intention of spamming.

Looking at the email body we can see that more thought has gone into ensuring the spam campaign flies under the radar. The malicious rtf (Word Document) has been encrypted with a password given in the email, this would prevent most automated systems from extracting and scanning the attachment for malicious code, as most aren’t able to handle password extraction or document decryption.

The Word documents also seem to have been give a new look and are padded with 1 px white and light grey text (enlarged and color corrected for illustration purposes) to foil any attempt at blocking the encrypted documents by hash. Unfortunately I’ve never looked at the actual macro which downloads and executes the Dridex loader, so I’m unsure if there’s anything new in the code; however, I did notice that the script artificially delays execution by running cmd.exe with the parameter “ping 8.8.8.8 -n 250 > nul” which will ping the google DNS server 250 times and disregard the results, delaying execution.

Conclusion

Overall this campaign does seem to pack a bit more of a punch that the ones we’re used to, possibly with the intention of infection corporate systems with more advanced threat protection rather than home users.

I’m on a bit of a weird timezone right now so I plan to take a look at the sample tonight when I wake up (hooray for nocturnal malware researcher), until then here are some hashes and info.

<botnet>302</botnet>
<nodes>210.65.11.155:443,211.115.202.139:443,59.188.249.197:433,
190.11.240.163:433,193.224.93.48:443,37.0.26.86:443,
187.242.24.89:8443,89.41.25.73:8443,82.118.119.138:8443,
94.6.249.253:8443,105.103.16.42:8443</nodes>

Malicious doc (Password: tRgHs8UOo): d969039f45723e5cb83b2f358b2f69db3aabf47d18d07237c79f03ffb6acf8c8
Malicious doc (Password: TVOS3v8): 49ec6f36bb1d84fe8a34291857aa03e9bc9f83cf350a69f46d0eca39d697b6fa
Malicious doc (Password: xpaGK1x0r): 2a75c7493803f4cb5325d19bad26043556c087030b2e28769305292bbdca2725