Until recently, I hadn't personally seen much malicious spam (malspam) using Microsoft office documents with Hancitor-based Visual Basic (VB) macros to send Pony and Vawtrak. It still happens, though. Occasionally, I'll find a report like this one from 2016-12-19, where Hancitor/Pony/Vawtrak malspam was disguised as a LogMeIn account notification, but I rarely come across an example on my own. And apparently, there's been a recent lull in Hancitor/Pony/Vawtrak malspam until yesterday.
This diary describes a wave of Hancitor/Pony/Vawtrak malspam from Tuesday 2017-01-10.
The example I saw was a fake parking ticket notification.
The link from the malspam downloaded a Microsoft Word document. The document contains a malicious VB macro described has Hancitor, Chanitor or Tordal. I generally call it Hancitor. If you enable macros, the document retrieves a Pony downloader DLL. The Pony downloader then retrieves and installs Vawtrak malware.
The link from the email contains a base64-encoded string representing the recipient's email address. Based on that string, the downloaded file will have the recipient's name from the email address. I used a base64 string for email@example.com (a made-up name/address) and received a file named parking_bert.doc.
Pattern-wise, URLs from this infection are similar to previous cases of Hancitor/Pony/Vawtrak malspam reported during the past two or three months.
You won't see any Vawtrak-specific activity until you start your browser and try to look at a something. Once you do, you'll see Vawtrak callback traffic.
Indicators of Compromise (IOCs)
Email links noted on Tuesday 2017-01-10 to download the Hancitor Word document:
Traffic after enabling macros on the Word document:
Vawtrak traffic noted after trying to browse the web:
Associated file hashes:
Speaking as a security professional, we often become jaded as yet another wave of malspam does the same thing it's done before. Patterns behind such activity are often well-documented. So why bother with discussion, if there's nothing new? Why bother talking about it, when we have the technical means to prevent these types of infections?
Why indeed! That attitude only encourages the criminal groups behind malspam. For various reasons, many environments don't follow best security practices, and they're still vulnerable. If we discuss on-going waves of malspam in high-visibility forums like this one, more people will be aware of the threat.
If you know any blogs or Twitter channels you find helpful, feel free to leave a comment below. Let's keep the discussion going!
Pcap and malware for this diary can be found here.
Jan 11th 2017
1 week ago
Quote:Why bother talking about it, when we have the technical means to prevent these types of infections?
The technical means you refer to disable the first weak point (alias attack vector) only.
EVERY administrator should but exercise defense in depth, ie. disable the other weak points used here too, ie. disable execution in data directories, or employ W^X in the (NTFS) filesystem: no properly written Windows application executes code from %TEMP% or %APPDATA% or %USERPROFILE% or any other user-writable location.
Use SAFER alias SRPv1 or AppLocker alias SRPv2 to enforce that!
Jan 12th 2017
1 week ago