Archive for July, 2011

TDL4 – Super Bot

Posted in Application, Encryption, Malware, Network Security on July 18, 2011 by keizer


The malware detected by Kaspersky Anti-Virus as TDSS is the most sophisticated threat today. TDSS uses a range of methods to evade signature, heuristic, and proactive detection, and uses encryption to facilitate communication between its bots and the botnet command and control center. TDSS also has a powerful rootkit component, which allows it to conceal the presence of any other types of malware in the system.

Its creator calls this program TDL. Since it first appeared in 2008, malware writers have been perfecting their creation little by little. By 2010, the latest version was TDL-3, which was discussed in depth in an article published in August 2010.

The creators of TDSS did not sell their program until the end of 2010. In December, when analyzing a TDSS sample, we discovered something odd: a TDL-3 encrypted disk contained modules of another malicious program, SHIZ.

TDL-3 encrypted disk with SHIZ modules

At that time, a new affiliate program specializing in search engine redirects had just emerged on the Internet; it belonged to the creators of SHIZ, but used TDL-3.

The changes that had been made to the TDL-3 configuration and the emergence of a new affiliate marketing program point to the sale of TDL-3 source code to cybercriminals who had previously been engaged in the development of SHIZ malware.

Why did the creators of TDL decide to sell source code of the third version of their program? The fact is that by this time, TDL-4 had already come out. The cybercriminals most likely considered the changes in version 4 to be significant enough that they wouldn’t have to worry about competition from those who bought TDL-3.

In late 2010, Vyacheslav Rusakov wrote a piece on the latest version of the TDSS rootkit focusing on how it works within the operating system. This article will take a closer look at how TDL-4 communicates with the network and uploads data to the botnet, which numbered over 4.5 million infected computers at the time of writing.

Yet another affiliate program

The way in which the new version of TDL works hasn’t changed so much as how it is spread – via affiliates. As before, affiliate programs offer a TDL distribution client that checks the version of the operating system on a victim machine and then downloads TDL-4 to the computer.

Affiliates spreading TDL

Affiliates receive between $20 to $200 for every 1,000 installations of TDL, depending on the location of the victim computer. Affiliates can use any installation method they choose. Most often, TDL is planted on adult content sites, bootleg websites, and video and file storage services.

The changes in TDL-4 affected practically all components of the malware and its activity on the web to some extent or other. The malware writers extended the program functionality, changed the algorithm used to encrypt the communication protocol between bots and the botnet command and control servers, and attempted to ensure they had access to infected computers even in cases where the botnet control centers are shut down. The owners of TDL are essentially trying to create an ‘indestructible’ botnet that is protected against attacks, competitors, and antivirus companies.

The ‘indestructible’ botnet

Encrypted network connections

One of the key changes in TDL-4 compared to previous versions is an updated algorithm encrypting the protocol used for communication between infected computers and botnet command and control servers. The cybercriminals replaced RC4 with their own encryption algorithm using XOR swaps and operations. The domain names to which connections are made and the bsh parameter from the cfg.ini file are used as encryption keys.

Readers may recall that one of the distinguishing features of malware from the TDSS family is a configuration file containing descriptions of the key parameters used by various modules to maintain activity logs and communications with command and control servers.

Example of configuration file content

Compared to version 3, there are only negligible changes to the format of the configuration file. The main addition is the bsh parameter, an identifier which identifies the copy of the malware, and which is provided by the command and control sever the first time the bot connects. This identifier acts as one of the encryption keys for subsequent connections to the command and control server.

Part of the code modified to work with the TDL-4 protocol.

Upon protocol initialization, a swap table is created for the bot’s outgoing HTTP requests. This table is activated with two keys: the domain name of the botnet command and control server, and the bsh parameter. The source request is encrypted and then converted to base64. Random strings in base64 are prepended and appended to the received message. Once ready, the request is sent to the server using HTTPS.

The new protocol encryption algorithm for communications between the botnet control center and infected machines ensures that the botnet will run smoothly, while protecting infected computers from network traffic analysis, and blocking attempts of other cybercriminals to take control of the botnet.

An antivirus of its own

Just like Sinowal, TDL-4 is a bootkit, which means that it infects the MBR in order to launch itself, thus ensuring that malicious code will run prior to operating system start. This is a classic method used by downloaders which ensures a longer malware lifecycle and makes it less visible to most security programs.

TDL nimbly hides both itself and the malicious programs that it downloads from antivirus products. To prevent other malicious programs not associated with TDL from attracting the attention of users of the infected machine, TDL-4 can now delete them. Not all of them, of course, just the most common.

TDSS module code which searches the system registry for other malicious programs

TDSS contains code to remove approximately 20 malicious programs, including Gbot, ZeuS, Clishmic, Optima, etc. TDSS scans the registry, searches for specific file names, blacklists the addresses of the command and control centers of other botnets and prevents victim machines from contacting them.

This ‘antivirus’ actually helps TDSS; on the one hand, it fights cybercrime competition, while on the other hand it protects TDSS and associated malware against undesirable interactions that could be caused by other malware on the infected machine.

Which malicious programs does TDL-4 itself download? Since the beginning of this year, the botnet has installed nearly 30 additional malicious programs, including fake antivirus programs, adware, and the Pushdo spambot.

TDSS downloads

Notably, TDL-4 doesn’t delete itself following installation of other malware, and can at any time use the r.dll module to delete malware it has downloaded.

Command and control server statistics

Despite the steps taken by cybercriminals to protect the command and control centers, knowing the protocol TDL-4 uses to communicate with servers makes it possible to create specially crafted requests and obtain statistics on the number of infected computers. Kaspersky Lab’s analysis of the data identified three different MySQL databases located in Moldova, Lithuania, and the USA, all of which supported used proxy servers to support the botnet.

According to these databases, in just the first three months of 2011 alone, TDL-4 infected 4,524,488 computers around the world.

Distribution of TDL-4 infected computers by country

Nearly one-third of all infected computers are in the United States. Going on the prices quoted by affiliate programs, this number of infected computers in the US is worth $250,000, a sum which presumably made its way to the creators of TDSS. Remarkably, there are no Russian users in the statistics. This may be explained by the fact that affiliate marketing programs do not offer payment for infecting computers located in Russia.

SSL Sniffing

Posted in Encryption, Network Security on July 10, 2011 by keizer

Some History:

This tool was originally written to demonstrate and exploit IE’s vulnerability to a specific “basicConstraints” man-in-the-middle attack. While Microsoft has since fixed the vulnerability that allowed leaf certificates to act as signing certificates, this tool is still occasionally useful for other purposes.

It is designed to Man-In-The-Middle (MITM) all SSL connections on a LAN and dynamically generates certs for the domains that are being accessed on the fly. The new certificates are constructed in a certificate chain that is signed by any certificate that you provide.

The New Scoop:

Version 0.6 has been significantly updated to additionally support  the null-prefix attacks. These allow for completely silent MITM attacks against SSL/TLS in the NSS, Microsoft CryptoAPI, and GnuTLS stacks — ultimately allowing for SSL communication in Firefox, Internet Explorer, Chrome, Thunderbird, Outlook, Evolution, Pidgin, AIM, irssi, and every other client that uses the Microsoft CryptoAPI to be intercepted.

sslsniff is useful for deploying other vulnerabilities as well. This is the tool that the people who pulled the recent MD5 hash collision publicity stunt used to demonstrate MITM attacks with their rogue CA-certificate. Also, anyone who is capable of obtaining a forged certificate by any means can easily deploy it through sslsniff with the targeted mode designed for null-prefix attacks.

The three steps to get this running are:

Installing sslsniff

  • Install the sslsniff dependencies (openssl, libboost1.35-dev, libboost-filesystem1.35-dev, libboost-thread1.35-dev, liblog4cpp5-dev)
  • Unpack sslsniff-0.7.tar.gz, run ‘./configure’, run ‘make’

sslsniff requires Linux 2.4/2.6, although it can easily be ported to other platforms.

Running sslsniff

  • sslsniff can now be run in the old “authority” mode or the new “targeted” mode. You can specify a single cert to sign new certificates with, or you can specify a directory full of certificates to use for targeted attacks.
  • sslsniff can now also defeat OCSP, fingerprint clients to attack, and hijack auto-updates.
  • See the README for more information on how to run sslsniff

Setting up iptables

  • Flip your machine into ip_forward mode: echo 1 > /proc/sys/net/ipv4/ip_forward
  • Add a rule to intercept SSL traffic: iptables -t nat -A PREROUTING -p tcp –destination-port 443 -j REDIRECT –to-ports <$listenPort>
  • If you wish to fingerprint clients and only intercept some traffic based on client type, add a rule to intercept HTTP traffic: iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-ports <$httpListenPort>

Running arpspoof

Assuming we want to intercept SSL traffic from, we need to trick that host into thinking that we’re the router. Using arpspoof, we can convince the target that the router’s MAC address is our MAC address.

  • arpspoof -i eth0 -t

At this point, any SSL traffic should get proxied by sslsniff and logged to the file you specify.


The current sslsniff development branch can be found on github.

Thanks to thoughtcrime and palisafe