Death By A Thousand Cuts - Rustock Botnet Sending More Encrypted Spam
Posted on behalf of Dan Bleaken, Malware Analyst, Symantec Hosted Services
In the past few days we have noticed that the Rustock botnet has been sending a lot more spam using TLS (Transport Layer Security). TLS is the successor to SSL and is a popular way of sending email through an encrypted channel, rather than sending it in the clear like most emails are sent. MessageLabs Intelligence tracks the use of TLS in order to determine how much spam is sent over TLS, and which botnets are sending it.
Not all mail servers force clients to use TLS, but it is frequently used for securing the communications channel between the client email sender and the email server to which the message is being delivered. It prevents eavesdropping of email traffic that would otherwise be sent in plain sight for anyone else on the network to see if they so wished, perhaps using network analysis tools. Some businesses mandate TLS for remote clients, for example, an employee connecting via a wireless hot-spot. Often other security mechanisms are used as well, in order to authenticate the client, such as SMTP-AUTH, as many email servers don’t force clients to provide a valid TLS certificate, particularly when the client isn’t an employee, but just another mail server on the internet.
TLS uses far more server resources and is much slower than a plain-text email; with TLS it takes time and resources to perform the necessary handshake where ciphers are negotiated and encryption keys exchanged and then to encrypt and decrypt the messages. There is a two-way conversation between the sending client computer and receiving email server, requiring both inbound and outbound traffic. In bandwidth terms, this outbound traffic frequently outweighs the size of the spam message itself and can significantly increase the workload being placed on corporate email servers.
Some stats on what proportion of spam uses TLS are included below, and as you can see, MessageLabs Intelligence is already tracking a large amount of spam that uses TLS. Should the volume of spam from botnets that use TLS increase over the coming weeks and months, businesses need to carefully think about the resources required to handle this type of spam. With corporate email servers coming under more pressure to handle these expensive, but unnecessary TLS connections, it becomes a death by a thousand cuts – on its own the overhead of processing a single spam received with TLS may appear insignificant, but at large volumes, the overall impact can be enormous.
The majority of the spam-requesting TLS connections come from the Rustock botnet. In fact, as much as 70% of spam sent from the Rustock botnet uses TLS currently. I believe that Rustock has rolled-out an updated version of its spam agent to some of its bots in order to achieve this. Not all of the Rustock bots are using TLS yet, but eventually it’s possible that all spam from Rustock will be sent over TLS.
Moreover, there are some other botnets that we have also seen using TLS, namely Grum, Cutwail and Bagle. For these, we have seen TLS used only in relatively tiny volumes. It’s important to note that TLS on its own does not provide sender authentication, as after all, most TLS connections are “opportunistic” – and some TLS enabled email servers are using self-signed certificates – which cannot be validated as they are not issued by a generally trusted certificate authority (CA). Unless an email server is validating the client’s certificate it is not possible to authenticate the client. Most client-to-server TLS encrypted traffic doesn’t require a client certificate at all, requiring only that the client trusts the server’s certificate before negotiating the key exchange prior to starting the TLS session.
Last week, spam using TLS accounted for approximately 20 percent of all spam, rising to approximately 35 percent of spam today. MessageLabs Intelligence will continue to track this in the coming weeks and months. It is also interesting to note that since TLS-enabled spam has increased, there has been a large increase in the volume of outbound traffic also. This is because when TLS is used it requires not only inbound traffic (such as for a typical spam email), but also a significant amount of outbound traffic to negotiate the encryption protocols. The volume of this traffic often exceeds the size of the spam email itself. The average additional inbound and outbound traffic due to TLS is an overhead of around one kilobyte. Many spam mails are often much lower than one kilobyte in size.
How Rustock determines when to use TLS seems to depend on the individual bot being used, rather than on the spam “run” or “campaign” or recipient. It seems that currently some of Rustock’s bots are TLS-enabled and others are not.
Below are two examples of spam from the same Rustock spam run, with virtually identical message bodies (apart from precise wording or subtle differences between subjects and URLs). The first one uses TLS and the second one doesn’t. For each one I’ve included the header, and a screenshot of the email message as it would appear when opened in a mail client.
[example 1 – Rustock spam using TLS]
[example 2 – Rustock spam not using TLS]
Note that the first example successfully negotiated a TLS connection using ESMTPS (Extended SMTP Secure), whereas the non-TLS message used ESMTP. Both bots connected using the EHLO SMTP command to request Extended SMTP, but only the first one requested a TLS connection using STARTTLS. The servers in both cases support incoming TLS connections, and only accept inbound email connections to TCP port 25.
Not all email servers will add the same level of detail to the received headers as seen above, but the encryption protocols used for a TLS connection will be similar.
Botnet operators may be finding that some mail servers and ISPs are mandating the use of TLS in their email connections and consequently as botnets are sending spam through these networks, they are simply asking for TLS connections in advance. Perhaps Rustock’s controllers mistakenly believe that TLS will add a level of legitimacy to their email traffic, or maybe they are just concerned about someone eavesdropping on their spamming operation.
These latest MessageLabs Intelligence findings seem to concur with the comments in a blog posted by Terry Zinc, which can also be read here: blogs.msdn.com/tzink/archive/2010/03/02/more-spam-via-tls.aspx.
[Visual representation of the Rustock botnet]