SANS ISC: Spam Backscatter

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Over the weekend I dealt with a (rather massive) spam campaign side effects.

In a few minutes about 10,000 messages arrived on a "catch-all" email address. Those messages consisted of:

• Non-Delivery Reports (NDR)
• Delivery Status Notifications (DSN)
• Out of Office messages
• Automated responses indicating the target does not work anymore where he was working
• Questions to confirm the message is genuine
• Automated reports informing it was considered spam
• Automated reports informing it contained a virus
• Automated reports informing it contianed bad links
  
• ...

These messages come in at an incredible rate where they contain the original headers you can see they are spammed from all over the address space (so it's likely to be a botnet sending it out). The error messages are in at least half a dozen languages.

The spams were spoofed to come from random names at a domain and all those responses from the victims only create more victims.

So in order to keep the Internet a place where we all can survive it is critical:

• Your email servers know which messages can be accepted or not and refuse the message if it needs to bounce before letting the sender move on and need a NDR or DSN to be sent to another victim.
• You do this by NOT having fallback MX records where these messages are dumped and then generate all the bounces. The fallback MX mechanism is only useful if you have a very unreliable link and actually use something like ETRN to fetch your email. But if you can surf the Internet reliably, the MTAs will work perfectly without a fallback MX.And should your sefver be down: the orginating MTA will store it till the next queue run.
  
• You do this by scanning for active mailboxes before accepting the email.
• You do this by scanning for unwanted content before accepting the email.
• Kill all vacation, out of office messages, does nto work here anymore, .... automated replies: it's a risk. And if you get a few thousand of them while you didn't send those people anything it's a real pain.
• Stop grey-listing: this is really the cheap solution and it is protecting yourself and putting the burden on the rest of us who don't even want to have anything to do with you in the first place.
• Automated scanning; if you do need to send somebody somethign that a unwanted message got filtered: send it to the recipient. If (s)he wanted the message, it can be gotten out of quarantine, but don't bother others with it, you're sending it toward the wrong people. And those that did send it to you: they know.

How do you survive this onslaught? You stop accepting the catch-all email and refuse all those incoming messages and/or -for those addresses you need to accept email- you start to drop all of those unwanted messages in a filter. Dropping MX records only works if you have no A record, but it might be an option. And no: you don't reply to any of them, there have been enough victims.

Personally I feel it's long overdue to really start implementing a usable alternative to the current email system. One of the requirements would be sender authentication and inability to create just a new identity after you got blocklisted.

Next comes that you might not be able to send much email anymore as there will be enough people who are misguided in assuming you or your domain in fact did send that message (the header forgery was not that bad, so some might even believe you relayed the messages).

If you do think you absolutely need fallback MX records, need DSN, ... well I'm sure you might sing a slightly different tune when are the victim of 10K messages in the first few minutes, and still going strong after many hours.