Tuesday, November 15, 2011

TDSS in layman's terms

Since 2008 it has been a constant factor in malware-land: the TDSS rootkit (also known as Alureon rootkit).  
There is a lot of good in-depth information and analysis posted all over the internet, a few examples are TDSS - Securelist and TDSS aka TDL: A Botnet Framework. However, I often get questions from people who are looking for a simple description: how are the different variants being identified and what is the difference between them? For that reason I have posted this (very) general overview.

  • TDL1: Classic TDSS; created a hidden driver service named TDSSserv, which loaded c:\windows\system32\drivers\tdssserv.sys

  • TDL2: Same as TDL1, but the names differ and contain a random string. There are many different versions, each of them containing new tricks to avoid detection and deletion. Examples are UACxxxxx, SKYNETxxxxx, GEYEKxxxxx, GASFKxxxxx, H8SRTxxxxx, PRAGMAxxxxx (where xxxxx represents a random string).

  • TDL3: The aim is to patch the hard disk controller driver (atapi.sys/iastor.sys) in order to get control over the system. Classic TDL3 directly patches atapi.sys on disk, later versions patch a random .sys file in the c:\windows\system32\drivers folder, which in turn patches atapi.sys in memory only, thus making detection/removal more difficult.

  • TDL4: The aim of this variant is the same as that of TDL3, however instead of patching a file, the Master Boot Record is patched, which makes infection of 64 bit systems possible and detection/removal harder. 

  • The latest version (at this moment still called TDL4) no longer patches the MBR. It alters the partition table so that its own hidden HPFS partition is set to Active. That way, when the computer is started, it will boot from the TDLFS partition, and load the infection from there, thus gaining control over the machine (it can then alter the MBR in memory and from there acts similar to TDL4 as described above). Fixing the MBR is no longer an option; the only way to fix this is to alter the partition table.

10 comments:

  1. Fabulous overview.

    As a computational physist with quite alot of *nix and w*ndows programming experience, I never figured I would fall victim to brower-based malware. But low-and-behold, I was stung by TDL2 months ago and recently "the latest version" -- all while doing quite benign web activities (really!). My friend google has betrayed me!

    Outdated Java may have been a common factor -- but is there a most common infection mode? Are most of these browser based?

    Cheers,

    DRC

    ReplyDelete
  2. Glad you like it! Outdated Java and Adobe Reader software are indeed an important infection vector, even if your browsing behavior is otherwise safe.
    Older versions of these programs have security vulnerabilities that can (and will) be exploited by malware.

    ReplyDelete
  3. Just wanted to thank you for the assistance and wealth of knowledge you have made available to others - truly benevolent. One of the XP SP3 PC's on our home network recently contracted one of the variants above, and it really shocked us how dangerous this malware has become. I suspect as this crazy world system devolves into deeper chaos, and people become increasingly desperate, it will only get worse too.
    Sincere thanks,
    Chris.

    ReplyDelete
  4. Think I just found TDL5, and it's a bitch.

    ReplyDelete
  5. Yep, TDLFS partition. Just what I needed today. I deleted the TDLFS partition, and made my NTFS active again. Well it still boots, and thats good...right?

    ReplyDelete
  6. Excellent description of TDSS!! Best one I've seen in layman's terms.

    Can you let us know what other guidance you have written?

    ReplyDelete
  7. I'm cleaning up right now a TDL4-like rootkit infection that differs from all the descriptions I've seen before by having 2 hidden partitions, not just 1. The first is a 0 length partition at slot 1 in the partition table (Intel, on an XP SP3 machine), the second is the well-known end space partition (4, in this case) of standard TDL4. Presumably the 2nd is booted by the VBR code in the 1st.

    Has anyone else seen this and are there any surprises with this variant which I should be aware of?

    ReplyDelete
    Replies
    1. This is something that can be observed after certain tools or applications attempt to clean the infection. In my experience the simplest solution is manually altering the partition table, however this is something that I would only recommend if you feel comfortable doing so. You'd need to move up partition 2 and 3 one slot and zero out partition 4. Also make sure you adjust the bootflag correctly. Afterwards, back in windows you can run any tool that detects the TDLFS filesystem to clean that up.
      Once again, do not attempt this if you're not sure what you are doing!

      Delete
    2. Thanks, Elise. Actually, just deleting part 1 and setting the boot flag got XP booting cleanly again. TDLFS is now quarantined for study and will clean up the partition table and null the freespace on the disk after some other scans finish running. I did write a new MBR to the disk too, just be on the safe side.

      Delete
  8. Hi there Elise!
    Awesome!!
    Great material.
    Thank you so much!!

    EdioIlha

    ReplyDelete