The Internet threat alert status is currently normal. At present, no major epidemics or other serious incidents have been recorded by Kaspersky Lab’s monitoring service. Internet threat level: 1

TDL4 – Top Bot

TDSS variants

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.

Botnet access to the Kad network

One of the most outstanding new features of TDL-4 is the kad.dll module, which allows the TDSS botnet to access the Kad network. So what do the cybercriminals want with a publicly accessible file exchange network?

We have known about botnets controlled via P2P for some time now, although until now, these were closed protocol connections created by the cybercriminals themselves. In contrast, TDSS uses a public P2P network in order to transmit commands to all infected computers in the botnet. The initial steps of how TDSS makes use of Kad are given below:

  1. The cybercriminals make a file called ktzerules accessible on the Kad network. The file is encrypted and contains a list of commands for TDSS.
  2. Computers infected with TDSS receive the command to download and install the kad.dll module.
  3. Once installed, kad.dll downloads the file nodes.dat, which contains the publicly accessible list of IP addresses of Kad network servers and clients.
  4. The kad.dll module then sends a request to the Kad network to search for the ktzerules file.
  5. Once the ktzerules files has been downloaded and encrypted, kad.dll runs the commands which ktzerules contains.

Encrypted kad.dill updates found on the Kad network

Below is a list of commands from an encrypted ktzerules file.

  • SearchCfg – search Kad for a new ktzerules file
  • LoadExe – download and run the executable file
  • ConfigWrite – write to cfg.ini
  • Search – search Kad for a file
  • Publish – publish a file on Kad
  • Knock – upload a new nodes.dat file to the C&C which contains a list of Kad server and clients IP addresses, including those infected with TDSS.

The most interesting command is Knock. This command allows the cybercriminals to create their own Kad P2P, the clients of which are exclusively TDSS-infected computers.

How publicly accessible and closed KAD networks overlap

Essentially, the TDSS botnet kad.dll module is more or less the same as cmd.dll in terms of control function. By running nodes.dat files containing a list of IP addresses of Kad clients in addition to ktzerlrules, which contains a command to download a new nodes.dat file from cybercriminal servers, the owners of the botnet can both include their infected computers in the publicly accessible Kad network and remove them from the network. The publicly accessible Kad network contains no more than 10 TDSS infected computers. This makes replacing the ktzerules file as inefficient as possible, which prevents other cybercriminals from taking control over the botnet. The total number of TDSS infected computers on the closed network number tens of thousands.

Kad.dll code responsible for sending commands from the TDL-4 cybercriminals

Furthermore, access to Kad makes it possible for the cybercriminals to download any files to botnet machines and make them accessible to the P2P users. This includes adult content files and stolen data bases.

The key threat that such a botnet poses is that even when its command and control centers are shut down, the botnet owners will not lose control over infected machines. However, the system does face two major obstacles:

  1. By using the publicly accessible Kad network, the cybercriminals still run the risk of fake botnet commands.
  2. When developing the kad.dll module for maintaining communication with the Kad network, code with a GPL license was used — this means that the authors are in violation of a licensing agreement.

Extended functionality

In addition to its known adware function, TDL-4 has added some new modules to its arsenal. This article has already touched on the ‘antivirus’ function and the P2P module. The owners of TDSS have also added several other modules to their malware, and now offer services such as anonymous network access via infected machines and 64-bit support.

The proxy server module

A file called Socks.dll has been added to TDSS’s svchost.exe; it is used to establish a proxy server on an infected computer. This module facilitates the anonymous viewing of Internet resources via infected machines.

Having control over such a large number of computers with this function, the cybercriminals have started offering anonymous Internet access as a service, at a cost of roughly $100 per month. For the sake of convenience, the cybercriminals have also developed a Firefox add-on that makes it easy to toggle between proxy servers within the browser.

Firefox add-on for anonymous Internet use via the TDSS botnet

64-bit support

The appearance of a 64-bit malicious driver in TDSS was another innovation in malware in 2010. In order to support operations with 64-bit systems in user mode, TDL-4 contains a module called cmd64.dll, a version of cmd.dll for 64-bit systems. However, due to the limitations of working with 64-bit programs, cmd64.dll code only provides communication with the botnet command and control servers.

List of botnet command and control center commands

Working with search engines

The cmd.dll module (see for details) remains almost completely unchanged. This module facilitates communication with the botnet command and control servers and substitutes search results, i.e. fraudulently manipulates advertising systems and search engines. The newest innovation in the list of commands for TDSS is the SetName command, which assigns a number to each infected computer. For search engines and banner networks, TDSS uses the same fake click and traffic technologies as similar malicious programs. However, TDSS has the longest list of search engines for which it substitutes search results.

List of search engines supported by TDSS

Botnet command and control servers

When running, TDSS uses several sources to obtain lists of command and control server addresses. The default list is taken from cmd.dll; if these addresses are inaccessible, then TDSS gets a list from cfg.ini. If for some reason no command and control server listed is accessible, then a list is created from an encrypted file called bckfg.tmp, which the bot receives from the command and control server on first connection. Since the beginning of the year, around 60 command and control centers have been identified across the globe.

Control server
Server address at the
beginning of February
Server address at the
beginning of March
Percentage of
mentions in C&C lists
01n02n4cx00.cc noip noip 0,05%
01n02n4cx00.com noip 0,43%
01n20n4cx00.com 0,21%
0imh17agcla.com 0,80%
10n02n4cx00.com 0,22%
1il1il1il.com 6,89%
1l1i16b0.com 0,43%
34jh7alm94.asia noip 0,03%
4gat16ag100.com noip noip 2,07%
4tag16ag100.com 6,69%
68b6b6b6.com noip noip 0,03%
69b69b6b96b.com noip 6,89%
7gaur15eb71.com 6,85%
7uagr15eb71.com noip noip 2,07%
86b6b6b6.com 0,14%
86b6b96b.com noip noip 0,24%
9669b6b96b.com 0,22%
cap01tchaa.com noip noip 2,19%
cap0itchaa.com noip noip 0,58%
countri1l.com 6,89%
dg6a51ja813.com 6,85%
gd6a15ja813.com 2,07%
i0m71gmak01.com noip noip 0,80%
ikaturi11.com noip 6,89%
jna0-0akq8x.com 0,80%
ka18i7gah10.com 6,85%
kai817hag10.com noip noip 2,07%
kangojim1.com noip noip 0,14%
kangojjm1.com noip noip 0,24%
kur1k0nona.com 2,19%
l04undreyk.com noip noip 0,58%
li1i16b0.com noip noip 0,05%
lj1i16b0.com noip noip 0,05%
lkaturi71.com noip noip 0,14%
lkaturl11.com 0,22%
lkaturl71.com 7,13%
lo4undreyk.com 2,19%
n16fa53.com noip 0,05%
neywrika.in noip noip 0,14%
nichtadden.in noip noip 0,02%
nl6fa53.com noip noip 0,03%
nyewrika.in noip noip 0,03%
rukkeianno.com noip noip 0,08%
rukkeianno.in noip noip 0,08%
rukkieanno.in noip noip 0,03%
sh01cilewk.com noip 2,19%
sho1cilewk.com noip noip 0,58%
u101mnay2k.com noip noip 2,19%
u101mnuy2k.com noip noip 0,58%
xx87lhfda88.com noip 0,21%
zna61udha01.com 6,85%
zna81udha01.com noip noip 2,07%
zz87ihfda88.com noip noip 0,43%
zz87jhfda88.com 0,05%
zz87lhfda88.com noip noip 0,22%

A careful examination of this list reveals that the IP addresses of command and control centers are constantly changing, while some command and control centers are phased out altogether. These changes are due to the use of proxy servers, which hide the true location of the command and control centers.

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.

To be continued…

This heading of this last section has become traditional in our articles on TDSS. In this case, we have reason to believe that TDSS will continue to evolve. The fact that TDL-4 code shows active development — a rootkit for 64-bit systems, the malware running prior to operating system start launches, the use of exploits from Stuxnet’s arsenal, P2P technology, its own ‘antivirus’ and a lot more — place TDSS firmly in the ranks of the most technologically sophisticated, and most complex to analyze, malware. The botnet, with more than 4.5 million infected computers, is used by cybercriminals to manipulate adware and search engines, provide anonymous Internet access, and acts as a launch pad for other malware.

TDSS and the botnet that unites all the computers it infects will continue to cause problems for users and IT security professionals alike. The decentralized, server-less botnet is practically indestructible, as the Kido epidemic showed.


Oldest first
Threaded view

Christophe Brocas

2011 Jun 27, 13:49

TDLx detection DNS

Thank you for this analysis :)

In corporate environment, a http/https proxy is often (almost always) used. Proxies do the DNS name request and not individual desktops.

My question : does TDL4 malware try to do direct HTTPS access to its C C server first before eventualy try the corporate proxy ? If so, TLD4 infected PCs can be detected in corporate DNS server logs.

Every DNS request to resolv Internet domains coming from PCs and not corporate proxies can be interpreted as signals on infection on that PCs.

Am I right or totally wrong (I think I am wrong ... too simple solution to be the right one but I ask ...) ?

Thank you for your reading and answer :)


Sergey Golovanov

2011 Jun 27, 15:23

Re: TDLx detection DNS

Surprise! You are right) So you can detect tdl4 connections over proxy.


Venus V.

2011 Jul 01, 15:30

Re: Re: TDLx detection DNS

I've noticed that if you boot into a live linux distro of any sort (I mainly use the Kaspersky Rescue Disk at this point) that lists all of the services and processes called in detail, an infected computer will always have several references to local loopbacks being called at and to through and that nearly always, the proxy that the infection specifies is either the localhost ( or some variant of it (e.g. If TDSS is the only bootkit in residence on my crippled systems, that is...

Wonderful to see a blog article where the authors are so engaged in the commentary discussions. Thanks!


Brian Angel

2011 Jul 19, 22:29

BIOS ????

Hi Sergey,

Would enabling the old MBR "change detection" in the BIOS stop this thing from infecting the MBR in the first place ??? Or does it have someway of getting around that protection.


Ralf-Philipp Weinmann

2011 Jun 30, 16:01

Encryption algorithm

"The cybercriminals replaced RC4 with their own encryption algorithm using XOR swaps and operations. "

I'm interested in that algorithm. I've had a quick look at the 0.175 cmd.dll in IDA this morning and that still seems to contain the RC4 cipher for encrypting control traffic (loc_100055AE). Where did you find that algorithm used? Can you share pseudocode or an IDB for that cipher so that its security can be evaluated?


Sergey Golovanov

2011 Jul 05, 14:59

Re: Encryption algorithm

This research was done in march and there was about 50% samples without RC4. Right now we are receiving samples just with RC4 algorithm. So 0.175 is not so old and it's really have a RC4. +
Sorry but we have very strong security policy for sharing malware IDBs...



2011 Jul 01, 09:29


"When developing the kad.dll module for maintaining communication with the Kad network, code with a GPL license was used — this means that the authors are in violation of a licensing agreement."

Why would this be of a concern to people who are creating malware?


Al Dowd

2011 Jul 03, 20:52

Re: GPL?

During the Prohibition Era in the U.S., 1920-1933, Al Capone, one of the major crime lords, was arrested, convicted, and imprisoned for tax evasion, not the numerous other criminal activities that he was responsible for. It's all about the paper (or electronic) trail...

http://en.wikipedia.org/wiki/Prohibition_in_the_United_Stat es


Paul Mullen

2011 Jul 01, 10:40

Detection when booting from an infected computer,

I wonder if a small program that can directly send ATA commands to the disk controller could retrieve the real MBR sector (rather than the original MBR, which is what the stealth code wants you to see. (I'm guessing this is the basis of the various boot detection kits)

If so, then a small free program could compare it with up to a dozen MBR variants (including many manufacturer additions, much as DEll's MediaPlayer or perhaps more simply the stealth copy of the MNBR which is returned when you request the LB 0 from the oopeerating systen. Since the program would carry common varients of MBRs automatically, I will attempt to send the boot sector to our lab,where we can analyse it.

Edited by Paul Mullen, 2011 Jul 01, 17:36


Sergey Golovanov

2011 Jul 05, 15:03

Re: Detection when booting from an infected computer,

Yes! We already have whitelisting for MBR but there are lot of questions with LILOs like staff...


Venus V.

2011 Jul 01, 15:16

Have you heard of TDSS using Xen/BusyBox/X11 to virtualize the *BIOS*???

I apologize for writing from a compromised computer, but I haven't any other options at this point. I have switched my educational focus from information science to studying the patterns of malware information transfer - using basic social engineering to determine how different malware groups are not only competing but also working together... at least in the case of my systems.

I'm a rank beginner when it comes to security, but I'm finding that my training in informatics is serving me well. What I'd like to know, is have you found any modules of TDSS employing firmware viruses? I definitely have problems with TDSS, but even without any writeable media attached to a system, the infection is still able to disable the BIOS passwords.

Further, in three cases of initial infection on new systems, quite literally, the *only* possible vectors for transmission of infection were through peripherals (in one a mouse and keyboard, another by a monitor, and the last a multifunction printer).

Is this happening anywhere else that you've heard? In the IO.SYS and MOUSE.SYS hex dumps that I was able to access at one point on an infected Win XP Pro system in February, I found several string references to xen, busybox, and x11 error messages, that's why I think that it has somehow managed to virtualize the BIOS and file structures out of RAM somehow... since those same strings appeared on the same machine when I booted it without a HDD from a *known* good copy of a DOS 6.22 boot floppy (reverified in a different computer later to confirm the strings were not actually located on the disk).

Kaspersky's tools (like all the other tools I've tried) are unable to conquer the infections so far, but the 2010 Rescue Disk lets me get farther in my forensic discoveries than anywhere else... and the licenses I bought of Kaspersky Internet Security 2011 were able to stave off full disabling of a system... such as giving me almost a full month before the infection took down my Win 7 x64 machine. I noticed that using the combination of Safe Run for programs and the Virtual Keyboard for all credentials seemed to slow the compromisation of my online accounts quite a bit! I also noticed that screenshots I took were all blacked out when a program was open under Safe Run, so I'm hoping that it works to block out screenshots of the Virtual Keyboard as well!

I look forward to reading more of your articles, thank you!
Venushakti V.
amateur in virus forensics (mostly at VirusTotal for now)
specializing in "search-engine pessimization"
(I apologize in advance if this message gets garbled by bots)


Paul Mullen

2011 Jul 01, 17:55

To Venushakti

I doubt that a mouse, keyboard or monitor contain sufficient programmable memory to be a source of infection. While a MFP certainly could, it would be way too complicated to program because of the many different possible models out there. So I think that is extremely unlikely.

Instead you should consider:
- could the hard drives have been infected at the factory?
- Was a system image installed, if so did it come from an infected computer?
- How was the hard drive formatted? Was it done from an infected drive or CD?
- Were the computers connected to a local area network?
- Were the computers connected, even briefly, to the internet to download Windows updates?



Venus V.

2011 Jul 08, 14:47

Re: To Venushakti

Thanks for reading my comment and composing a thoughtful response!

Unfortunately, there are no hard drives attached to the computers in question... I can't get far enough to save BIOS settings to turn off the Wifi and Bluetooth anymore so that I can feel safe enough to reconnect the hard drives to format them. I'm getting notification of the ram hooks from the live disks I'm running, at shut down (when they inform me that they are unable to unmount the physical addressing something-or-other in RAM and briefly flash a list of approximately 20 entries of physical hooks in RAM that I guess are permanent as long as the bootkits are in charge. :(

Do you think swapping out the memory would allow me to boot from floppy again and flash the BIOS successfully? I haven't been able to get the BIOS to reenable floppy support (it's been specifically and *permanently* disabled in the BIOS - the supervisor password will not unlock security for that item)...

This was an x64 W7 box that got hit by a version of TDL4 that apparently also installed Poison, Dybalom, and Gen.Nullo (according to the few file detections on VirusTotal and with AVG/ESET/Kaspersky/MBAM/SB S D on the rare occasions I can get something through without it getting patched).

Of course, it could just be hackers trying to make me *think* that's what's happening so that everyone will just think I'm crazy. ;>



2013 Sep 28, 04:34

Re: Re: To Venushakti

This old post got my attention and yes, they WILL think you are crazy, lol. XD

That's a fake BIOS, it's a distraction and anything you do in it is futile. If it gets reinfected or patched, it's likely because there is something scripted or part of the rootkits impressive arsenal of automated routines and triggers... IF the machine is connected to the NET, the widely varied means that it is self healing, updating, logging and anchoring itself withing hardware, software and data... are what make it so hard to repair... The evolution of this code as a system is not isolated to TDL4 but has components that I suspect are carried on to subsequent generations and may be unnoticed if refitted for the use of another aspiring botnet operator...

Here are some sanity checks and notes... that were learned the hard way.

The firmware likely needs to be flashed on the motherboard... I have several motherboards that have bogus Bios Screens or a 'award6.00' bios that is actually a bogus FreeDOS environment that does an amazing job evading detection and removal.

The detection, remediation and prevention methods that were overkill in the past are insufficient in fighting TDL4+ Unlike other threats of the past... the complexity, multiple and novel routes of transmission, the fact that it can update itself, is scripted and has events triggered by LACK of human activity... and tasks that hide when user input is detected, (Mouse, Camera, Microphone)

--Uninstall Java Completely, UPDATE AND PATCH ALL software, drivers, flash all motherboard .
--Check and flash CD/DVD Firmware, programable controllers, Networked PRINTERs. (I have a FIOS set top box that is LINUX/MOTOROLA/MEDIACENTER that is transmissing RAWpackets and one that never had media center turned on... 1 sinks my network, guess which? :)

(If it can be flashed, it will, as an eventuality, get pwned. Securing one area makes less secure areas more desirable as entry points... Increases in security eventually reveals the motivation levels of adversaries... If there is enough motivation or desire then they simply stop messing with software code and use a hammer or just steal your whole computer... :)

Old firmware is a losing battle for sure, but nobody want's to hear that their relatively new computer that runs perfectly well and has a antivirus subscription and 0 threats could be the problem... let alone the BIOS having being FREEdos in it or about how they are in a Virtualized Desktop... like an antfarm... :)

UBCD or a BootDisk with firmware that comes up BEFORE your fake bios... I have one motherboard that F12 brings up boot screen which let's F4 continue boot OUTSIDE of the dos environment and then the CD can boot LIVEcd or Util...

--Check Network Card Firmware
--Disable DHCP --- disable Bootp
--CLEAR CMOS with JUMPER or remove Battery, ETC
--ALWAYS UNPLUG POWER (Notebook remove battery) and Let SYSTEM discharge Capacitors for at least 30 seconds... FAKE BIOS means FAKE BIOS beep or suspend to ram...
--It is virtually impossible to clean infected system from within that system. Kaspersky disc, live CD's fully patched and secure machine that is not networked or online...
--DISABLE all DHCP servers
--GET OUT OF and address space being used as default and do something that will indicate if your setings change or new device is introduced...
--use passwords that long and don't reuse them or for multiple devices... complex passwords are hard for humans to remember, brute cracking takes more time for longer passwords...
--CHANGE and Set USER and Password BEFORE connection of ANY Device to A NETWORK
--OUTGOING TRAFFIC needs to be blocked/denied/disallowed by default... not triggered to be allowed if requested inside...
--REMOVE WIRELESS CARDS and IF they are used... MAC Authentication is CRITICAL/ESSENTIAL (No WEP, etc)
--Remove BLUETOOTH devices
--Simple format or partition WILL NOT clean HDD --- research DCO and HDD firmware - Overwrite FREEspace with CCleaner and/or Bleachbit for instance. CHKDSK /F from windowsrepair disk is CRITICAL to cleaning MFT and Extended Attributes... and FS overlays that are hiding on disk. (Consider Storing files on something OTHER than NTFS formatted drives)

--CONSIDER using Alternate Bootloader

--Linux Machines with WINE1.4 WINE1.5 CERTAINLY get hit with something that seems to be related...

--Netstat -a and look for High UDP ports that are sequential in group of 5... As I recall 49152,49153,49154,49155,49156

--DISABLE DHCP on networked computers
--BLOCK OUTGOING traffic on firwalls and Close ALL ports by default and OPEN only ports required. (start with 80,443,53 for HTTP, HTTPS, DNS)
--DISABLE UPNP features on Routers and Firewalls
--DD-wrt Moded Firewalls have been very effective and can block JAVA traffic, some specific routes of transmission...

--USE VARIED virus removal tools. 0 detections just mean 0 detected, test a known infected drive to verify that the program works... Conduct remediation under the assumption that 0 threats found IS evidence of infection or intrusion.

--By the time you get a full windows install complete, chances are the machine has fallen... (Long Hang on Install) ACCESSING old file folders, exe's or if you see RECYCLE.BIN folders Shortcuts instead of actual folders... payloads that are delayed by timers that are initiated when there is LACK of User input....

Disconnect ALL devices not needed to boot, ClearCMOS, Start From Full unplugged state (boot to USB based linux live CD without HDD, DVD, then Connect and flash) The problem is complicated trying to obtain a clean image file is needed and anything download on that network or computer has to be treated as suspect until verified... but verification through experimentation and inference without a reference computer to WILL make you go a bit nutty. XD

IF there is a device on the network that is infected or if router is compromised... Live CD's that auto-config net settings WILL get DNS redirected... Any software downloaded over DNS redirect firewall is likely compromised...

Start with router, modem and 1 machine...disconnect other devices... Build from the ground up and if it doesn't work... start over from the beginning and only change 1 thing at a time...

It's not the things you know about that are going to be the problem. :)

IF you are reading this... it means that DNS is likely working in your favor...



Venus V.

2011 Jul 08, 15:03

To Paul:

sorry, forgot to say, yes, it was connected to a LAN, by ethernet to an infected vDSL modem/wifi router (I didn't know that routers could be infected at that time, nor that the modem I had actually had dual processors and an OS as well as software hardware firewalls that were not enabled by default)

Yes, the x64 box was connected to WUPD, but it showed signs of browser redirections, cross-domain jscript injections, malformed css/xhtml errors, and forcible installing of Google desktop and Windows Live (*both* by **Windows Update** - I've never heard of WUPD installing Google desktop/toolbar before, have you?) -- I didn't know this had occurred until I rebooted after the final update (W7 SP1) and the programs began at startup. This was not an OEM install, this was a w7 box set I bought from a large computer chain, printed by Microsoft's disk mfrs.

The hard drive could indeed already have been infected when it came to me, the event logs (before I lost access to MMC) said that the "certified refurbishing" had consisted only of a system restore from the system backup partition... followed by a long list of errors in the log within seconds after the tech who did the restore rebooted the system... then MMC crashed and I've not been able to get back in. However, there hasn't been any writable media in that box for weeks.

If you have time to read my messages and offer your thoughts, wonderful... but even your response so far has sparked some questions for further research (now that I have a browser that can do at least partially-effective searches for the moment - on another computer).

I don't want to admit *total* defeat on the nicest computer I've ever owned (the x64) especially now that I'm learning so much about how nice Windows 7 can be, and the security improvements (bootkit notwithstanding) to the OS overall (I don't know enough about other OS's to protect them as well yet)... so any comments are appreciated!

If there is a way to send PMs on here so we can spare everyone my laundry list of desktop dramas, I will see if I can reach it with one of my systems... if not, perhaps I can get to the library again in the next few days. :)

Thank You!



2011 Jul 02, 20:51

Detection and/or Protection?


With all that in mind (MBR, drivers also in x64, firmware/BIOS issues) - how can the average or advanced home user, soho admin or medium business admin detect that kind of infections?
Beside detecting it by Proxy, DNS or traffic logs is it possible to scan the MBR, the OS, firmware or something like that? Is there an easy-to-use application to detect TDSS?

Regards, Martin


Sergey Golovanov

2011 Jul 05, 15:13

Re: Detection and/or Protection?

Hello Martin! Yes sure. http://support.kaspersky.com/faq/?qid=208283363



2011 Jul 06, 03:01

Re: Re: Detection and/or Protection?


Question - how robust is the approach in tdsskiller versus TDL-4? Are there indications that TDL-4 is evolving protection measures against tdsskiller, or is it a pretty safe bet that something basic to TDL-4 is so unchangeable that protection will be (at least somewhat) lasting?

Thanks much,



Sergey Golovanov

2011 Jul 06, 17:49

Re: Re: Re: Detection and/or Protection?

It's always a challenge) we release tdsskiller update each ~2 weeks. Last version is " Jul 1 2011 18:45:21"...



2011 Jul 03, 08:49


My ears pricked up when you said there is a root (MBR) component. A sophisticated rootkit could hypothetically detect the flavor of OS being booted and install an initialization payload appropriate to the OS. Are there any indications of advancement of TDL4/TDSS beyond the Windows framework?


Sergey Golovanov

2011 Jul 05, 15:16

Re: Rootkit??

No and it is a good news)


Francis Turner

2011 Jul 04, 17:53

decrypting ktzerules / locating the nodes.dat

so from what I've read above the P2P part works like this?
1) use standard kad p2p bootstrap process (same as any other kad client e.g. emule) and standard nodes.dat
2) download ktzerules
3) via ktzerules commands download new private nodes.dat
4) use new nodes.dat to talk to C C servers, other bots etc

I'm wondering if you can explain how to locate the real nodes.dat for the p2p botnet and/or how to decrypt ktzerules. I've dled one of those using emule/kad whioch is 224 bytes long and is clearly encrypted/compressed


Sergey Golovanov

2011 Jul 11, 13:42

Re: decrypting ktzerules / locating the nodes.dat

Sorry. No reply)


Peter Dodwell

2011 Jul 05, 07:59

Thtreats to Linux users?

I've stumbled across this forum after checking out info about "XP Recovery" malware. The technical issues as discussed here are way above my level. I'm interested in how to help fellow members of my computer club who might fall foul of this menace. Also, as a Linux user, I'm interested in the level of vulnerability for:- 1) a stand alone Linux system, 2) running Linux from a live CD. Your thoughts on this aspect would be most welcome


Sergey Golovanov

2011 Jul 05, 15:54

Re: Thtreats to Linux users?

TDSS is working only on Windows systems so Linux is safe for that. For fighting with such kind of threats I can suggest our free tools like http://support.kaspersky.com/faq/?qid=208283363 )



2011 Jul 23, 11:15

We need a hardware based solution...

I worked for SMC Networks back in 1998-2000. Back then I was trying to convince the Director of Technology and Marketing that we need a Hardware Based NIC+AV solution to stop threats before it could write to the computer. Costs have come down significantly...this is doable with today's capabilities. Integrated into every MB NIC, the average Joe will have a fighting chance!

Let's get this party started...Contact me!



2011 Sep 03, 02:53


how the virus is to fool the antivirus and infiltrate in MBR?



2011 Sep 15, 06:56

Does the TDL4 infect the EFI bios?


Mark JM Jonckheere-Hundhausen

2011 Sep 16, 13:14

Infection Code TDSS

There is a keyboard-hook somewhere which looks for ftp-connections ... and finds index.* ... then it adds: var t="";var arr="646f6 ... 2)t+=String.fromCharCode(parseInt(arr[i]+arr[i+1],16));eval(t); after the last char (usual ).
... (contains the rest of the script) ...
With this the first "obfuscated" is installed ... which installes the rootkit.
It thries to infect all index.php on your system and remote ftp-connections.


Rafa Rodríguez

2011 Nov 21, 17:21

Name of the version of TDL4 with kad.dll

I'm very interested in the communication through Kad of TDL4. What is the name that Kaspersky use for the version of TDL4 with the kad.dll module? Could you facilitate the md5 of the sample you analyzed? I would like to see the report of virustotal about it.

Thank you and great work!



2012 Jul 04, 11:22

How to detect ???

First thanks for your article(s) and taking time to answer in blogs too..
Really great attitude !

At the moment, i'm asking myself how to detect the presence of TDL4 on the network ? If i see DNS resolution from hosts to C C urls, probably hosts are infected.. So now?? Where can i start (proxies logs, captures on hosts, searching for special traffic). My questions is more on the network level with an IDS in mind / networking traffic to identify indicators of the malicious traffic. If you can point to some links/tools/clues, wou'd be great...
Thanks !



2013 Mar 19, 13:12


i herdy from a little birdy that some parts of tdl were originally written by anakata. good thing he can't do that for a living anymore.



2013 Sep 24, 16:06

communication through Kad

thanks for the article. I have some questions:
1)does TDL-4 use p2p as primary communication channel or as stated in (SoK: P2PWNED — Modeling and Evaluating the Resilience of Peer-to-Peer Botnets) it use p2p as backup channel?
2)can I have the md5 or the binary of TDL-4?
3) do you any other live botnet that use a public p2p network as communication channel like TDL-4 (parasitic behavior)?

If you would like to comment on this article you must first

Bookmark and Share