TorrentLocker spam has DMARC enabled

Posted by   Virus Bulletin on   Mar 2, 2015

Use of email authentication technique unlikely to bring any advantage.

Last week, Trend Micro researcher Jon Oliver (who presented a paper on Twitter abuse at VB2014) wrote an interesting blog post about a spam campaign that was spreading the 'TorrentLocker' ransomware and which, unusually, was using DMARC.

TorrentLocker is one of the most prominent families of encryption ransomware — a worryingly successful kind of malware that first appeared two years ago. The malware initially implemented its cryptography rather poorly, but has since become one of the most successful of its kind.

DMARC is an email technology that builds on both SPF and DKIM. Both these technologies allow a domain owner to take some responsibility for the emails sent from their domain: SPF by listing those IP addresses used to send email; DKIM by digitally signing the emails.

DMARC adds to SPF and DKIM a mechanism that allows a domain owner to advise senders what to do about emails that claim to come from the domain, but which fail both DKIM and SPF checks. Moreover, it provides a mechanism for receiving mail servers to send feedback to the domain owner about those emails, helping the latter detect phishing campaigns against the domain and also to fine-tune their email settings.

For spammers who use their own domain, using SPF and DKIM makes little sense as it only allows spam filters to be more confident that they are blocking the correct emails. (An exception might be a low-volume campaign where the spammers try hard to make their messages look genuine, and use SPF and DKIM to do so.)

Using DMARC makes even less sense, as spammers aren't worried about others spoofing their domain — and even if people were interested in doing so, spam domains tend to be active for a very short period of time.

Using DMARC to detect a misconfiguration
  Using DMARC to detect a misconfiguration. From Terry Zink's VB2014 paper.

The TorrentLocker spammers did use their own domain (one that looks vaguely like that of the government of New South Wales) in this campaign, which mostly targeted Australians. The domain's DMARC record told senders to reject emails that failed SPF and DKIM and to receive feedback on those emails.

Oliver suggests that this gives the spammers "the ability to refine future spam runs". I am not sure I agree. At best it helps the spammers detect incorrect SPF and DKIM settings, but given that the domain is active only for a very short time, they will have little to no time to fix mistakes they might have made.

What DMARC reports explicitly do not do is provide feedback on emails that are blocked by spam filters for any reason other than failing SPF or DKIM. The specification says:

Mail Receivers are only obligated to report reject or quarantine policy actions in aggregate feedback reports that are due to DMARC policy. They are not required to report reject or quarantine actions that are the result of local policy. If local policy information is exposed, abusers can gain insight into the effectiveness and delivery rates of spam campaigns.

We can only guess as to the real reason why the TorrentLocker spammers used DMARC. Perhaps they wanted to make their domain look even more legitimate, or perhaps they simply misunderstood how DMARC works. It is also possible that they rented the email infrastructure from another party and that it came with DMARC pre-configured.

To users who did open the email, this brings little comfort. Current versions of TorrentLocker do not have any known vulnerabilities and decryption is only possible with the private key owned by the cybercriminals.

In 2012, John Levine wrote an introduction to DMARC for Virus Bulletin. At VB2014, Microsoft's Terry Zink presented a paper (available here as a PDF) on the subject, in which (among other things) he explained how he used its feedback mechanism to fine-tune Microsoft's email settings. You can also watch Terry's presentation on our YouTube channel.



Posted on 02 March 2015 by Martijn Grooten
twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest posts:

In memoriam: Yonathan Klijnsma

We were very sorry to learn of the passing of researcher Yonathan Klijnsma last week. Here, former VB Editor Martijn Grooten shares his memories of a talented researcher and a very kind person: this month, infosec lost a really good one.

VB2020 localhost videos available on YouTube

VB has made all VB2020 localhost presentations available on the VB YouTube channel, so you can now watch - and share - any part of the conference freely and without registration.

VB2020 presentation & paper: 2030: backcasting the potential rise and fall of cyber threat intelligence

At VB2020 localhost, threat intelligence consultant Jamie Collier used the analytical technique of backcasting to look at the rise and fall of the cyber threat intelligence industry.

VB2020 presentation: Behind the Black Mirror: simulating attacks with mock C2 servers

At VB2020 localhost, Carbon Black's Scott Knight presented an approach he and his colleagues have taken to more realistically simulate malware attacks.

VB2020 presentation & paper: Advanced Pasta Threat: mapping threat actor usage of open-source offensive security tools

At VB2020, researcher Paul Litvak revealed how he put together a comprehensive map of threat actor use of open-source offensive security tools.

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.