On the week of February 20th 2017, ProtectWise began observing a rather successful malicious spam (malspam) campaign distributing the Hancitor Downloader. The downloader has been observed delivering a variety of malware, such as Zloader, a Send-Safe spambot and other malware utilizing Tor. The campaign likely began toward the end of 2016 and the authors have been continually improving their methods in the months since, with a noticeable leap in success rates over the past few weeks.
The purpose of this post is to provide investigation details that will aid in a root cause analysis and remediation of such infections, while also providing insight into the TTPs behind such campaigns. Additionally, due to short-lived weaknesses in the attacker procedures, we are able to provide victim demographics related to the campaign activity over the past two weeks.
Special thanks to all of the independent researchers who openly publish their own findings. Such details aided in corroborating the below information - see references for direct links.
With the captured full fidelity network packets for many successful and unsuccessful infections, the investigation can be properly scoped and benefit from various points of added context. For the sake of simplicity in understanding the entire infection process, I’ve detailed each step of the infection below. These steps also touch on the iterations the malspam author is performing.
Step 1: Malspam Email Delivery
The malspam campaign follows a basic pattern and methodology for infecting its targets. The process starts by delivering a variety of malicious emails to a list of target email addresses. The email templates used within this campaign have been observed as spoofed eFax notifications (see Figure 1.), Amazon notifications, ADP notifications, and recently USPS notifications. Older and less successful templates have been observed as imageless generic notifications. The malicious emails do not contain attachments, instead they attempt to entice the recipients into clicking a malicious link.
Figure 1: Spoofed eFax email. Malspam containing link to malicious URL.
Step 2: Malicious Document Delivery
Immediately after the email recipient clicks one of the links, a single HTTP GET request is sent to one of many attacker-controlled compromised WordPress websites. This GET request includes an ID variable in the URI, which is a base64 encoded string of the email address for the recipient. As detailed later, the inclusion of the victim email address is a method the attacker uses to document the success of their malspam campaign and deliver next steps.
Figure 2: Outbound GET request caused from clicking malspam link. URI containing victim email.
The server then responds to the GET request by sending a Microsoft Office document. This document is named on a per-victim basis, such as eFax_email_name.doc - the titles differ based on malspam agenda, such as USPS_email_name.doc. The average user is much more likely to trust the email since it contains their own name. However in cases when the malspam was delivered to mailing group they are less successful (such as eFax_careers.doc)
Figure 3: Successful reply with malicious Office document titled efax_email_name.doc
The author holds a list of IPs which are considered a blacklist. An IP on this list will not be delivered a malicious document response as a method to evade certain email providers and fellow security organizations.
Step 3: Malicious Document Execution
If the download of the Office document was successful, as we observed in multiple cases, the user is then presented with another attempt at enticing them to initiate an action. The document contains a message to enable macros, which if done, will cause the host to beacon out to multiple destinations to download new malware.
Figure 4: Open Office document enticing the user to enable macro to initiate download.
Amusingly the Office documents related to this campaign have had their malicious macro code buffered with music lyrics to potentially help evade some detection methods. Some recent songs include:
- Major Lazer - Be Together (see Figure 5.)
- XV - Awesome 2.0
- Chris Brown - Look At Me Now
- Hurts - Illuminated
- Halou - Honeythief
Figure 5: Example macro code containing Major Lazer lyrics.
Step 4: Downloader Beacon and Malware Delivery
Following the step of enabling the Office document macro the host is then instructed to install malware commonly referred to as the Hancitor downloader. The downloader performs a multitude of beacons in order to checkin the victim host, and then attempt to download additional malware. The approach and external infrastructure of this process will differ by each deployed variant of Hancitor from the attacker. The average lifespan of the infrastructure availability has been roughly 24-48 hours.
First the host performs a public IP lookup of the victim network using the legitimate ipify.org lookup service API URL, or occasionally checkip.dyndns.org. This IP lookup being performed by the malware is a method used by the attacker for documentation, delivering the proper malware, and potentially to avoid infecting hosts on their blocked IPs list.
Figure 6: Public IP lookup of victim host from Hancitor downloader infection.
Next, the host will perform a downloader checkin back to its own C2 infrastructure (compromised WordPress sites). The beacon consists of an HTTP POST request to one of multiple destinations from the downloader. The beacon attempts will cycle through each destination repeatedly as long as the host remains infected. This process has been rather successful at evading web-filter and firewall blacklists that only know the first domain as malicious. This beacon contains the victim ID, domain, hostname, OS type/version, and public IP gained in the previous GET request. The goal of the Hancitor downloader is to distribute their own customer’s malware as a paid business model.
Figure 7: Successful downloader beacon with encoded reply.
Following a successful downloader beacon (figure 7), the victim host then downloads one, or in some cases multiple, new pieces of additional malware, encrypted over the wire (figure 8). At this point, the victim is assigned its own malware. Each additional malware has its own beaconing/infection patterns, such as Zloader PE downloads and a Send-Safe spambot UDP traffic.
Figure 8: One example of successful downloader beacon retrieving additional malware.
During investigations for our customers across many successful and unsuccessful infections, we have also identified interesting methods within the campaign to document and track victims. The infrastructure is designed to not deliver malware to well known security organizations and email providers who may put the malspam campaign at risk.
As noted above, the infrastructure behind the malspam campaign tends to quickly rotate, about every 24-48 hours. Based on our findings, each email blast successfully entices roughly 10,000 users to click the malicious link inside the email (requesting the document download) before rotating to the next iteration. The quantity of users who receive the email is currently unknown. Interestingly noted from our detections, the average enterprise network prevents roughly 60% of these link clicks from going outbound. These quantities appear to have increased to the 10,000 a day with the use of more legitimate formatted emails with pictures. Prior to this change, the exact quantities are unconfirmed but estimated to be much less successful.
The below indicators are only a small sample of the entire campaign. Keep in mind that due to the rotating infrastructure and constant flow of new files, these will provide little value in a blacklist type function. Instead use them for education, hunting, and confirmation of coverage by your current toolset.
Malicious Document SHA256 Hash:
Hancitor Downloader SHA256 Hash:
Post-Infection Downloads SHA256 Hash:
Link Click, Document Delivery Domains:
Downloader Beacon Domains:
Downloader Malware Delivery Domains: