Why send spam over TLS?

In my previous post, I noted that rustock had started sending us a whole pile of spam over the TLS protocol.  The question now is why do it at all?  I mentioned in my post that this is clever behavior and one of my readers posted in a comment “What makes this so clever?”

The issue of authentication, reputation and security is one that comes round and round in the world of email.  Why do we authenticate?  And what does it buy you?  There are plenty of reasons to send authenticated mail, here are three:

1.
It allows you to track abusive behavior.
If an organization is sending outbound spam, then determining who is responsible for it allows that organization to track down who is sending it and shut them down.  This, of course, presumes that organizations want to do the right thing.  But if you are taking responsibility for the quality of what you send, then identification of your users is done using authentication.

2. It allows you to combat fraud.

   Up until this point, the principle mechanism that we have used with regards to authenticated mail is using it to combat phishing.  Organizations that use SPF or SenderID and have a “-all” in their SPF records are saying that any mail that purportedly comes from us, but is not from our designated IP range, can be discarded (or heavily weighted in the negative).  Organizations like Paypal or eBay have a vested interest in this.  If a spammer wants to spoof security @ paypal.com, then looking up the SPF record for paypal.com will reveal that it is a phish and can be discarded.

   Of course, this doesn’t work if the phisher does security @ paypal.does.not.exist.com (ie, makes it look like Paypal at a glance).  However, we don’t use it to combat all phishing, we use it to combat some phishing.  That is where we have gotten the most mileage.

3. To fast track mail you want to receive.

   This is the Holy Grail of filtering.  If you know who mail is coming from and can authenticate that it indeed comes from them, then you can put said contacts on a white list to bypass filtering such that false positives never occur.  For example, if I always wanted to hear from my girlfriend (for the sake of argument, let’s call her Christine), I would whitelist her email address in the event that her email account can be authenticated in some regard.  Only mail that genuinely comes from her would I want to fast track.

   The Holy Grail parts comes in on the theory that for mail that is unauthenticated, you could put through a more weighted rule set (or more aggressive rule set).  The good mail you always receive because it is unauthenticated, but the rest of it is subject to more antispam filtering.  For example, I would always want to hear from Christine, but my friend Frank will have a tougher time getting through to me [Of course, in real life, Frank owes me money so I would always want to hear from him too, to see when he’s going to cough up my cash].

   Unfortunately, I call this the Holy Grail of filtering because while it is a noble goal, it is unattainable.  There are far too many people in the world who I want to hear from who don’t authenticate their mail with any technology.  Thus, any attempt to increase the aggressiveness of a spam filter will result in false positives from people you invariably want to hear from.  Similarly, there are cases when you do want to hear from new people (such as going to a conference and collecting business cards) who you have yet to authenticate.  I don’t know the full list of my friends, old and especially new, and increasing a filter’s aggressiveness only results in the case of false positives.  That’s my real life experience.

None of these really fit the profile of a spammer.  Why would he want to track abusive behavior?  Or combat fraud?  The one that does make sense is getting onto a whitelist.

To a spammer, they may believe that only good institutions authenticate their mail.  And furthermore, when filters see that the mail is authenticated, they relax their settings and allow the mail to pass through to the end user.  In other words, there is a hope that an authenticated connection means that the receiver assumes that the sender is a good player.  Who else would take the time to authenticate their mail?

Yet this view doesn’t really hold up in real life.  No one in the antispam world worth their salt believes that authenticated mail is de facto good mail.  We like it when mail is authenticated, but we don’t naively believe that because it is authenticated, it is good.  There is a higher probability that it is, true, but there is no guarantee.  Just take a look at my other stats, we get plenty of spam from mail that is authenticated.  In other words, if spammers actually think that authentication will help them, they are soundly mistaken.  Authentication is used to hear from people we want to hear from, not from anyone.

There is another reason to send mail over an encrypted channel, however: for security for the spammer.  Why would a spammer need to worry about security?  Because their drones sending out the spam need to communicate with their command-and-control centers.  If the communication is going out over an encrypted channel it means that anti-botnet activists out there cannot discern, intercept or observe what type of traffic is going out over the clear text.  In other words, it makes their communication channel more resistant to tampering.  Observe in the past 4 months what has happened:

• Mega-D infiltrated
• Lethic infiltrated
• Waledac infiltrated
• Mariposa infiltrated (more on this in a future post)

By encrypting the communication channels, a botnet can make its instruction set more difficult for a security official to disrupt because obtaining proof of malicious behavior means that the observer must connect directly to the botnet C&C (or drone).  They cannot sit back and intercept packets and observe what is going on.

Thus, my theory is that the rustock botnet uses TLS (or SSL, or something) as a means of disguising its behavior in an attempt to make its infrastructure more robust.  It then sends email the same way but doesn’t necessarily care that it is being slowed down somewhat.  It has so wide a footprint that it is able to absorb the cost of the delays introduced by sending over an encrypted channel.

It makes the task of stamping out rustock that much more difficult.

Comments

• Anonymous
  March 03, 2010
  But what does TLS have to do with authentication? You aren't using client certificates with SMTP so you are not authenticating the client. I don't see how points 2 and 3 three relate to TLS. The first point is true that you can't listen to the outbound SMTP traffic.

• Anonymous
  March 04, 2010
  We're seeing a lot of Rustock spam via TLS on some of the outbound traffic that we filter for major ISPs. I think that in addition to doing this with the intention of bypassing some of the spam checks at receivers, the Rustock operator is encrypting because he/she knows that this makes it impossible for someone to man-in-the-middle filter the spam out before it reaches the receiving system. If other botnets get the idea that TLS is a good strategy, this will hurt efforts to control spam outbound by watching content as it leaves ISP's networks. Clearly this represents another move by the spammers that requires a response...

• Anonymous
  March 05, 2010
  Doesn't it just push responsibility for filtering back onto the TLS receiver which already has spam filtering?  Certainly it's good if spam can be stopped before it leaves a network, but how many bots send directly vs using an ISPs outbound mail servers?  Some probably do, some probably don't. Agreed that TLS would seem to greatly complicate (outbound or) inband monitoring though.  Therefore the main target of bots using TLS would seem to be bot spam detectors placed on in-transit mail flow sensors.   If so, it would seem to be a small battle won, but certainly not a decisive victory for the bad guys.

• Anonymous
  March 06, 2010
  They can connect to our outbounds with TLS all they want to (apart from us not supporting STARTTLS) - even if they did, our MTAs are the endpoint of that encrypted channel - and they have full-content access to the message once received. There is no effective difference to non-TLS'd mail. Similar on the inbound side - not supported by us, but if we did support it, once it's out of the TLS decryption, we have full access to the content (and envelope data). No win for the bad guys, just more resources on our part for TLS, if we had it enabled.

• Anonymous
  April 13, 2010
  If you want to anoy anyone with spam then just visit http://hacxx.byethost15.com/ and enter the respective email