BLOG

Spamming to hide fraud

An interesting article at NetworkWorld last month, describing spam bombs to victims of fraud and identity theft to hide the transactions and notifications from financial institutions.

The targets are individuals, whose identity and personal information the thieves already have. The victims’ email inboxes suddenly get flooded with thousands upon thousands of emails — as many as 60,000 during a 12- to 24-hour period — that contain no links, no graphics, and no advertisements. “[The contents are] nothing but mash-ups of words and phrases from literature,” he wrote.

[...] the real point is to distract the user from valid email, which will likely include confirmations of purchase receipts or balance transfers from fraudulent transactions made with the victim’s credentials.

This doesn’t seem to be a widespread problem currently, and I expect that many of the major ISPs will identify this as a mailbomb and stop the mail. As many of these mails are coming from botnets, too, many ISPs will block the mail during the SMTP transaction. I think for most people, there isn’t a huge risk. However, that doesn’t mean we shouldn’t be aware.

2 comments

  1. Martijn Grooten says

    Brian Krebs wrote about this last year: http://krebsonsecurity.com/2012/07/cyberheist-smokescreen-email-phone-sms-floods/

    He says that the crooks claim delivery rates of 60% or more. That sounds credible to me. And then it’s far more than a nuisance.

    You’re right that this shouldn’t be a concern for most people, but I wouldn’t be so sure that many ISPs/filters will (be able to) block these emails.

  2. Brian says

    I saw this form of abuse for the first time last week. I was really confused by the content I was seeing [ http://pastebin.com/euP2pQvL. There are no links or images, nothing actually malicious just a ton of seemingly random text.

    The good news is that some anti-spam products caught the messages. CloudMark Authority Engine detected the message properly as SPAM, but SpamAssassin totally whiffed scoring the message at 0 on default scoring.

    Tracing the messages and watching the patterns was interesting. Messages were sent in small batches, about 5 to 10 messages per batch all to the same email address. The source was a bot (who’s IP was listed in the CBL) which pushed messages into another bot that which was then relaying the messages through an exchange server on the network for final delivery. The delivery IP had an excellent reputation and little damage was done my the small amount of messages processing. Odds are a lot of these messages were reaching the inbox.

    There was no major uptick in SMTP/network traffic because of the small rate of messages being generated and sent. Only about 150 to 250 messages processed a day out of this particular compromised point. The failure rate of the messages was really very low, although some ISP had shut down the receiving accounts already.

    It will be interesting to see if this becomes pervasive.

Comment:

Your email address will not be published. Required fields are marked *

  • AOL problems

    Lots of people are reporting ongoing (RTR:GE) messages from AOL today.  This indicates the AOL mail servers are having problems and can't accept mail. This has nothing to do with spam, filtering or malicious email. This is simply their servers aren't functioning as well as they should be and so AOL can't accept all the mail thrown at them. These types of blocks resolve themselves. 1 Comment


  • Fixing discussion lists to work with new Yahoo policy

    Al has some really good advice on how to fix discussion lists to work with the new Yahoo policy. One thing I would add is the suggestion to actually check dmarc records before assuming policy. This will not only mean you're not having to rewrite things that don't need to be rewritten, but it will also mean you won't be caught flat footed if (when?) other free mail providers start publishing p=reject.No Comments


  • Sendgrid's open letter to Gmail

    Paul Kincaid-Smith wrote an open letter to Gmail about their experiences with the Gmail FBL and how the data from Gmail helped Sendgrid find problem customers. I know a lot of folks are frustrated with Gmail not returning more than statistics, but there is a place for this type of feedback within a comprehensive compliance desk.No Comments


Archives