TDL4 revisited

I just saw an article by Mathew Schwartz for Information Week focused on a series of articles by Aleksandr Matrosov, Eugene Rodionov and myself for Infosec Institute.

The articles are actually based on previous analyses of TDL3 and TDL4 by Aleksandr and Eugene, but even if you’ve seen those, you might find the aggregation of older and newer information and the separation of the topics useful. Anyway, the subversion of 64-bit Windows is certainly still an interesting topic.

All three articles are linked on the white papers page at

TDSS part 1: The x64 Dollar Question: Considers and contrasts the distribution and installation of the TDL3 and TDL4 bootkits.

TDSS part 2: Ifs and Bots: Looks in more depth at the internals of the TDSS malware.

 TDSS part 3: Bootkit on the other foot: The last part of the series describes the TDSS loading process.


Author David Harley, ESET

  • Joshua

    Concerning specifically the TDL3 and TDL4 RK/BK. Could you explain why both of these versions of the RK are going straight into a Bootkit infection?
    I am a computer repair tech/malware researcher/security consultant, both of these versions on my clients machines have gone straight into a BK infection. In the past six months I have dealt with over 150 or more BK infections between these versions of the RK on both x86 and x64 systems.
    I would love to learn more of your's and others sides about this RK/BK.

    • David Harley

      The main reason why the TDL3 rootkit has been transformed into a bootkit is the need to be able to infect x64 operating systems with kernel-mode code signing policy enforced. The way TDL3/TDL3+ infects the system doesn’t work anymore on x64 versions of Microsoft Windows operating systems. In the case of TDL3/TDL3+ the infected driver won’t be loaded, which will definitely result in an unbootable operating system.

      To target x64 operating systems with kernel-mode code signing policy the malware has to be loaded prior to the OS kernel to subvert protection mechanisms and, therefore, infecting the MBR is the perfect way to achieve this target. When the OS loader receives control the bootkit is already resident in memory and is able to counterfeit any data being read by the loader from the hard drive. Moreover the bootkit can patch OS modules to achieve desired behavior.

  • Joshua

    Thanks for the information.
    I love your white papers they are a great source of information on specific threats as well as the threat landscape.
    I'm working on figuring out how to completely stop RK and BK infections could you point me to a white paper on the delivery methods of the TDSS RK/BK as well as any other resources that may help me in my quest to stop the RK/BK infections. I've been able to analyze some active RK infections because of samples taken off of clients machines (with their ok of course). Is there a way to analyze the MBR in a BK infection?
    Thanks for your time I greatly appreciate it.

    • David Harley

      Thank you, Joshua. TDSS has been addressed in quite a few Virus Bulletin papers over time, but I haven’t seen much material anywhere that covers the recent variants in much detail. We tend not to do “how to…” educational material: not because we’re against it in principle, but because of time and resource issues. Somewhere like SANS or Infosec Institute may have material that will help you.

  • Joshua

    Thank you.
    Are any of ESET personel on virus total? If so ask them if they would look me up my nickname is "Mohreus", I would love to talk with some antimalware designers as I am designing an android malware removal tool.

  • Paul

    I've seen this sleep through most antivirus and antimalware software, even pass Kaspersky TDSS remover undetected. Is there any kind of operative system modification or software protection we can use against TDL4? Thanks.

    • David Harley

      There is no patch or viable absolute protection against TDL4. Common sense and basic security software go a long way, though.

Follow us

Copyright © 2017 ESET, All Rights Reserved.