{
	"id": "e7e9370e-987e-49c9-89b2-349eb1239ae2",
	"created_at": "2026-04-10T03:20:18.063321Z",
	"updated_at": "2026-04-10T03:22:16.666038Z",
	"deleted_at": null,
	"sha1_hash": "dad63208a602a61b43df73a05ccb83f584085bc6",
	"title": "TDSS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1488391,
	"plain_text": "TDSS\r\nBy Vyacheslav Rusakov\r\nPublished: 2010-08-05 · Archived: 2026-04-10 02:08:48 UTC\r\nEven the longest day comes to an end.\r\nRussian folk saying\r\nThe TDSS rootkit first appeared in 2008. Since then, it has become far more widespread than the notorious rootkit\r\nRustock. The rootkit’s malicious payload and the difficulties it presents for analysis are effectively similar to those\r\nof the bootkit. The bootkit infect (as its name suggests) infects the boot sector, ensuring that the malicious code is\r\nloaded prior to the operating system. TDSS implements the concept of infecting drivers; this means it is loaded\r\nand run at the very early stages of the operating system. This greatly complicates the detection of TDSS and\r\nmakes removing it treatment a serious challenge.\r\nTDSS: Rootkit techolnogies\r\nThe Beginning: TDL-1\r\nThe first version of TDSS was detected by Kaspersky Lab on April 6, 2008, as Rootkit.Win32.Clbd.a. This name\r\nechoes the names of the driver, clbdriver.sys, and the DLL, clbdll.dll, which deliver the main payload.\r\nBig oaks grow from little acorns, and this was very much the case with TDSS; the rootkit technologies\r\nimplemented in the first version (driver functionality) was relatively simple even back in 2008.\r\nInterestingly, some parts of the rootkit have remained unchanged since the first version, namely:\r\n1. 1 The TDL identifiers;\r\n2. 2 Driver infection tools;\r\n3. 3 Use of configuration files,\r\n4. 4 Working with the С\u0026C panel.\r\nFragment of Rootkit.Win32.Clbd.o, an early version of TDSS,\r\nwhich infected the beep.sys driver\r\nhttps://securelist.com/tdss/36314/\r\nPage 1 of 23\n\nThe most important functions of this rootkit are:\r\nProtecting critical registry keys by hiding them;\r\nProtecting critical files on the disk by hiding them;\r\nInjecting malicious code into system processes from a kernel-mode driver;\r\nHiding TCP network ports;\r\nExecuting some functions (terminating processes, terminating threads, hiding injected DLL modules etc.)\r\nFiles are hidden by adding a malicious filter to the system driver stack. This is done cyclically for each volume in\r\nthe system. This approach helps kill two birds with one stone: the rootkit hides files on the disk which have names\r\nstarting with the string “tdl”, and returns an error when an attempt is made to open \\Device\\HarddiskVolumeX.\r\nThis causes errors in various anti-rootkit tools which need to open this volume to conduct a low-level analysis of\r\nfile system structures.\r\nThe error returned by the malware reads “STATUS_TOO_MANY_SECRETS”; this highlights the cybercriminals’\r\nrather peculiar sense of humor which has become their hallmark.\r\nNetwork ports are also hidden by adding a malicious filter to the \\Device\\Tcp device stack.\r\nRegistry keys associated with the malicious service and configuration data are hidden by hooking the system\r\nfunction NtEnumerateKey. This is done by splicing, a method based on replacing a certain number of bytes at the\r\nstart of the function with a redirector leading to the malicious driver.\r\nAn infected system: splicing functions NtEnumerateKey and NtFlushInstructionCache\r\nThe hooking of the system function NtFlushInstructionCache is an interesting feature of the malware. By calling\r\nthis function, the driver can execute additional commands as follows:\r\nhttps://securelist.com/tdss/36314/\r\nPage 2 of 23\n\nTerminate a thread;\r\nBlock thread execution;\r\nTerminate a current process;\r\nObtain the name of a current process;\r\nHide an injected DLL module;\r\nUnload a driver;\r\nObtain a list of running processes.\r\nFunction executing additional rootkit commands\r\nThe rootkit uses the relatively simple method of excluding the loaded module from PsLoadedModuleList, the\r\nsystem list of loaded drivers.\r\nThe interesting features of TDL-1 are covered above. Today’s anti-malware technologies can easily detect and\r\nneutralize this rootkit, and the appearance of TDL-2 is good evidence of this.\r\nTDL-2: the saga continues\r\nAnti-rootkit technologies are continually evolving, and rootkit technologies have followed suit. TDL-2 (TDSS), a\r\nnew modification of the malicious program, first appeared in early 2009.\r\nhttps://securelist.com/tdss/36314/\r\nPage 3 of 23\n\nIt should be noted that there were several modifications of TDL-2, each with modified functions. For this reason,\r\ndescriptions from different sources may vary in the information they offer.\r\nIn order to prevent the malicious driver from being analyzed, the cybercriminals both obfuscated and encrypted\r\nthe body of the rootkit. They also added random words from “Hamlet” to the malware file in order to confuse\r\nmalware analysts.\r\nFragment of the malicious file containing random words\r\nAlthough the rootkit’s functionality remained relatively unchanged in comparison with the previous version, the\r\ntechniques used to combat analysis and to conceal the rootkit changed. The malicious driver uses splicing to hook\r\na number of kernel functions as follows:\r\nIofCallDriver\r\nIofCompleteRequest\r\nNtFlushInstructionCache\r\nNtEnumerateKey\r\nNtSaveKey (in some versions)\r\nNtSaveKeyEx (in some versions)\r\nNtQueryValueKey (in some versions)\r\nNtSaveKey (in some versions)\r\nNtSaveKeyEx (in some versions)\r\nNtQueryValueKey (in some versions)\r\nhttps://securelist.com/tdss/36314/\r\nPage 4 of 23\n\nHooked operating system functions\r\nAn attempt could have been made to reconcile the inconsistencies shown above; however, the rootkit uses several\r\nkernel threads to check if the rootkit hooks are present and to restore them if required. Similarly, the rootkit checks\r\nif the system registry contains an entry for the malicious service and restores it if necessary.\r\nJust as the first version of the rootkit does, TDL-2 hooks NtEnumerateKey to hide the rootkit’s configuration data\r\nand its critical registry keys.\r\nTwo new functions, NtSaveKey and NtSaveKeyEx, are hooked to prevent some anti-rootkit tools from detecting\r\nanomalies in the system registry and consequently, the presence of active malware in the system.\r\nNtFlushInstructionCache is hooked in order to ensure the malware components can access kernel mode.\r\nThe malware hooks the system functions IofCallDriver and IofCompleteRequest so that the malicious driver can\r\nfilter system IRP packets. This helps hide the rootkit files, and restrict access to them. In Windows, the I/O system\r\nis based on a unified interface and is the heart of the operating system. The I/O manager links applications and\r\nsystem components with a range of various devices. Most I/O requests take the form of special IRP packets\r\n(Input/Output request packets). Thus, hooking the above functions allows a process to filter a range of IRP packets\r\ne.g. file open operations. While intercepting IofCallDriver makes it possible to filter out a packet before it is\r\nprocessed by the system, hooking IofCompleteRequest makes it possible to cancel a successful operation, such as\r\na file open operation.\r\nThe hooking of IofCallDriver is implemented in a relatively unconventional way. The hook unwinds the execution\r\nstack; if it finds any driver in the stack which is not in the rootkit’s allowlist, and that driver attempts to read\r\ncertain files, a fake “reading successful” status is returned. However, the file is not actually read.\r\nWhen the system function IofCompleteRequest is hooked, the error message “STATUS_SECRET_TOO_LONG”\r\nis returned, and the successful operation is canceled.\r\nThe rootkit also employs a trick using the system registry key ServiceGroupOrder. This registry key is responsible\r\nfor handling driver loading priority. As soon as the rootkit finds a driver which is given top priority, i.e.it is listed\r\nprior to “System reserved”, the registry record for this service will be modified so that the service will be started\r\nmuch later. This is another method used to counteract anti-rootkit technologies.\r\nhttps://securelist.com/tdss/36314/\r\nPage 5 of 23\n\nThis malicious functionality is still sophisticated enough to counteract most antivirus products currently available\r\n(http://www.anti-malware-test.com/?q=node/180), as it helps the rootkit remained undetected in an infected\r\nsystem. However, the cybercriminals behind this malware preferred not to rest on their laurels; their efforts lead to\r\nthe appearance of TDL-3 in the autumn of 2009. This rootkit is the most sophisticated, powerful, and interesting\r\nrootkit to date.\r\nTDL-3: the end of the story?\r\nThe latest version of this malicious program implements state-of-the-art virus-writing technologies. Apart from\r\ndeveloping the rootkit proper, the authors have consistently worked on improving its self-protection capabilities,\r\nbug-fixing, developing the payload, and reacting promptly to new detection technologies developed by antivirus\r\ncompanies.\r\nTo ensure the rootkit gains a firm foothold within the operating system, the cybercriminals used a popular method:\r\na file virus which infects system components. The target is the MiniPort/Port Driver of the disk. This ensures the\r\nrootkit is loaded almost immediately after the operating system starts.\r\nLater modifications of the rootkit randomly select and infect system drivers which meet certain criteria. However,\r\nlet’s start by examining earlier versions of the rootkit which infect the atapi.sys driver. In order to prevent\r\ndetection by anti-rootkit tools which check the file size at high- and low-level, the file is infected in such a way so\r\nthat the size does not change.\r\nThe infector replaces a number of bytes in the resources section of the target file with a small loader of the main\r\nbody of the rootkit and modifies the driver’s entry point.\r\nEntry point in atapi.sys prior to infection\r\nhttps://securelist.com/tdss/36314/\r\nPage 6 of 23\n\nEntry point in atapi.sys after infection\r\nThe loader’s primary goal is to load the main body of the rootkit from the last sectors on the disk to memory, and\r\nto pass control to it.\r\nMain body of the rootkit on disk, marked “TDL3”\r\nHowever, this isn’t all the rootkit does. TDL-3 uses its own implementation of an encrypted file system in which it\r\nsaves its configuration data and additional user-mode DLLs. As a result, TDL-3 doesn’t require the FAT or NTFS\r\nfile systems in order to operate.\r\nhttps://securelist.com/tdss/36314/\r\nPage 7 of 23\n\nExample of rootkit configuration data located in the disk’s last sectors\r\nThe main purpose of any rootkit is to block and/or hide critical malware data. In order to do this, TDL-3 spoofs\r\nthe object servicing a system device.\r\nDisk device stack\r\nAll functions servicing this device lead to one thing: the malicious driver’s hook function:\r\nhttps://securelist.com/tdss/36314/\r\nPage 8 of 23\n\nIn this way, the rootkit filters attempts to access disk sectors where critical data is located. If an attempt is made to\r\nread an infected driver (in this case, atapi.sys) is attempted, the rootkit returns the contents of the clean file (i.e.\r\nthe content of the file prior to infection.).\r\nTDS-3 is a highly sophisticated piece of malware. The cybercriminals who created it track the work of antivirus\r\ncompanies and react swiftly to them by releasing updates for the rootkit. At the time of writing, the current version\r\nof the rootkit was 3.273. It’s likely that the functionality of the rootkit will be modified in the near future to better\r\ncounteract anti-rootkit technologies.\r\nTDSS Online\r\nAt the start of March 2009, Kaspersky Lab identified an upsurge in TDSS activity.\r\nNumber of TDSS variants and components detected daily\r\n(statistics from Kaspersky Security Network)\r\nThis burst of activity called for more detailed analysis of TDSS. The results are detailed below.\r\nThe “Partnerka”\r\nTDSS was spread using affiliate marketing programs. Today, affiliate marketing is the most popular way for\r\ncybercriminals to work with each other in order to make money. According to Wikipedia, “Affiliate marketing is a\r\nmarketing practice in which a business rewards one or more affiliates for each visitor or customer brought about\r\nby the affiliate’s marketing efforts. Examples include rewards sites, where users are rewarded with cash or gifts,\r\nfor the completion of an offer, and the referral of others to the site.” For cybercriminals who are involved in\r\npartnership, or affiliate, programs, the goods are malicious programs, while the services offered are the attraction\r\nof users to infected web sites and the subsequent infection of their computers. There is a wide variety of affiliate\r\nhttps://securelist.com/tdss/36314/\r\nPage 9 of 23\n\nmarketing programs; in this specific case we are talking about the affiliate programs promoting malicious\r\nprograms and/or rogue antivirus solutions.\r\nIt should be stressed that those involved in affiliate programs promoting malware are not limited in the amount\r\nthey can earn: the more infected machines, the more the partner earns. Most partners use a range of exploits,\r\nworms and viruses to install malware on victim machines. For instance Conficker (which Kaspersky Lab detects\r\nas Worm.Win32.Kido), which caused an epidemic in early 2009, included a tool to download and launch a file\r\nlinked to the “Traffic converter” affiliate program which distributed rogue antivirus solutions\r\nMost affiliate marketing programs disseminating malicious code use the Pay-Per-Install model (PPI). In other\r\nwords, the amount the partner earns depends on how many times the malware is installed, and on where the victim\r\nmachines are located.\r\nPMSoftware, an affiliate marketing program which distributes rogue antivirus solutions and TDSS.\r\nThe Pay-per-Install sum depends on the physical location of the victim machine\r\nAffId\r\nSince TDSS is distributed by means of an affiliate program, it includes a tool which transmits data about the\r\npartner who installed the rootkit to the victim computer. The value given in the AffId file in the rootkit’s\r\nconfiguration file contains this information.\r\nhttps://securelist.com/tdss/36314/\r\nPage 10 of 23\n\nFragment of TDD configuration file showing the AffId field giving the partner’s ID\r\nThe AffId identifier is sent to the administration panel to determine which partner installed TDSS on a particular\r\ncomputer and that it is this partner who should be paid. The physical location of the infected computer is\r\ndetermined by the C\u0026C panel using the IP address from which the AffId identifier was sent.\r\nAn analysis of new TDSS infections and their sources makes it possible to determine which partners are using\r\nwhich methods to distribute the rootkit. For example, the partner with ID# 20106 infects computers using fake\r\ncodecs that are allegedly needed to watch a video clip on a specific web site.\r\nMessage prompting the user to install a codec to watch a video\r\nThe partners with ID # 10438 and 11418 prompt users to install a key generator for popular software. The rootkit\r\nis then installed together with the key generator.\r\nhttps://securelist.com/tdss/36314/\r\nPage 11 of 23\n\nKey generator installation prompt, which will also install TDSS\r\nThe partner ID # 20273 infects computers with the help of drive-by downloads, while versions of the rootkit with\r\nthe AffId# 00123 were downloaded to machines which belonged to two different botnets CnC ZeuS. This may\r\nindicate that both botnets have the same owner.\r\nConnect\r\nThe configuration file also contains addresses for the C\u0026C panel. TDSS contacts them when it is launched for the\r\nfirst time on a victim machine. Each configuration file typically contains 3 C\u0026C addresses. All in all, there are\r\nthirty-three known addresses for the third version of the rootkit.\r\nThe C\u0026C servers are located in China, Luxembourg, Hong Kong, the Netherlands and Russia.\r\nGUID|AffId|status|erType|erCode|OS\r\nGUID is the unique identifier for the victim machine;\r\nAffid is the partner’s ID;\r\nStatus is the status of the current task;\r\nerType is the rootkit runtime error;\r\nerCode is the error type;\r\nOS is the version of the operating system used by the infected computer.\r\nhttps://securelist.com/tdss/36314/\r\nPage 12 of 23\n\nThe rootkit contacts the C\u0026C via HTTPS; during this communication, the C\u0026C server uses a security certificate\r\nsigned by the cybercriminals and issued by Internet Widgits Pty Ltd. For developers, this certificate is used as the\r\nstandard certificate while working with SSL.\r\nThe standard C\u0026C security certificate\r\nThe “standard” certificate is used while working via HTTPS in order to achieve two aims:\r\n1. 1 Prevent antivirus solutions from detecting packet content characteristic of malware and consequently\r\nblocking malicious network traffic.\r\n2. 2 Prevent fake C\u0026C servers from gaining control over the botnet.\r\nIn addition to using a secure connection, the third version of TDSS also uses encryption algorithms for GET-requests. A request is encrypted at the C\u0026C domain name using the RC4 algorithm and is then encoded into\r\nBASE64. The GET-requests generated by earlier version of the rootkits could be intercepted and detected.\r\nHowever, the GET-requests generated by the third version of TDSS are practically impossible to detect as\r\nprocessing each GET-request sent from the user’s computer requires too much CPU time.\r\nBASE64(RC4(“domain.org”,”f1344ab7-e226-4385-b292-328fd91e5209|20123|0|1|0|5.1 2600 SP2.0″)) =\r\nnaRV/t1H20oohxzGEVXPMbdVVOjvK0PMUE\r\nVzuYWyEDHKsOFud57tO4HMkrkf0abk5UC3XtwDW/7Fmc\r\ns7Vy14niX4t3eRARHRlnGKP14CcOwASIdVHac\r\nExample of how an HTTP GET-request is encrypted by TDSS\r\nhttps://securelist.com/tdss/36314/\r\nPage 13 of 23\n\nC\u0026C\r\nDifferent versions of TDSS use different sets of scripts and databases to control botnets and store information\r\nabout them. Thus, TDL2 used the SENEKA engine (this is what this version of TDSS is called in some antivirus\r\nproducts). Currently, the TDSS botnet is managed by the DM-Engine. If the packet format and the encryption\r\nalgorithm is known, a request can be sent to the botnet C\u0026C in order to get commands sent to infected computers\r\nas well as information about the C\u0026C structure and the contents of its database. It’s possible to identify the\r\nlocation and names of files used to service the botnet by deliberately sending sending malformed requests to the\r\nC\u0026C.\r\n/data/www/dm_engine/library/classes/DBase.php\r\n/data/www/dm_engine/public/enginestatusn.php\r\n/data/www/dm_engine/library/models/mSystems.php\r\n/data/www/dm_engine/public/index.php\r\nExample of file locations in the TDSS C\u0026C\r\nIt’s also possible to find out how bot parameters are processed by the C\u0026C if the request format and parameters\r\nare known.\r\nPart of request GUID Affid status erType erCode OS\r\nType of variable char Char num num char char\r\nOperations on variables Select/Insert Select/Insert Insert Select Select Select/Insert\r\nTable of C\u0026C operations on parameters sent by TDSS\r\nAll this data makes it possible to find out the contents of some of the fields in the C\u0026C which services the TDSS\r\nbotnet.\r\nBlind SQL Injection\r\nThe C\u0026C database is designed to fly below the radar, making it impossible to get messages about requests sent to\r\nit. Given this, blind SQL injection can be used, with subsequent analysis of the request results being based on the\r\ntime it takes for an HTTP response to arrive. The main problem with this method is establishing which table and\r\nfield names should be used. In this case the cybercriminals, when developing the C\u0026C, used field and table names\r\nwhich correspond to the botnet request names; this makes the task less challenging.\r\nThus, when TDSS contacts the C\u0026C, the “GUID” field is called “Systemid”. The table storing IDs of all infected\r\ncomputers is predictably called “Systems”. All partner IDs, or “AffId”s, are stored in the “Affiliate” tables. Using\r\nthe vulnerable number fields that TDSS sends to C\u0026C, the following request can be sent: return 1 if the number of\r\n“systemId” records containing IDs of infected computers is larger than 1; otherwise, calculate MD5 hash 20\r\nmillion times.\r\nhttps://securelist.com/tdss/36314/\r\nPage 14 of 23\n\n“26344ab7-e226-4385-b292-328fd91e5209|20123|0|1\r\nAND\r\nIF ((SELECT COUNT(systemId) From systems) \u003e 1,1,Benchmark(20000000,md5(1)))\r\n|0|5.1 2600 SP2.0″\r\nRequest to the TDSS C\u0026C database\r\nThis request is encrypted using the C\u0026C server name as a key. When a C\u0026C server receives a request, a response\r\non execution status is returned within a second. If the request above is modified to include 100,000 infected\r\ncomputers (..if the number of “systemId” records containing IDs of infected computers is larger than 100,000…),\r\nthe response will be sent within ten seconds.\r\n“26344ab7-e226-4385-b292-328fd91e5209|20123|0|1\r\nAND\r\nIF ((SELECT COUNT(systemId) From systems) \u003e 100000,1,Benchmark(20000000,md5(1)))\r\n|0|5.1 2600 SP2.0″\r\nModified request to the TDSS C\u0026C database\r\nBy sending repeated requests generated in this manner, it can be established that the C\u0026C at the domain\r\n873hgf7xx60.com services 243 infected computers, while the C\u0026C at zz87jhfda88.com only services 119 infected\r\ncomputers. In early June, some 2000 “affiliate partners” were distributing TDSS.\r\n26345ab7-e226-4385-b292-328fd91e5209|20023|0|1\r\nAND\r\nIF ((SELECT COUNT(affid) From affiliates) \u003e 1691,1,Benchmark(20000000,md5(1)))\r\n|0|5.1 2600 SP2.0\r\nRequest to the TDSS C\u0026C. The instruction is: If the number of AffId records containing partners’ IDs is larger\r\nthan 169, then return 1, otherwise execute calculation of the MD5 hash-function for 20 million times\r\nQuite obviously, this technique can be used both to delete all tables on the botnet’s C\u0026C panel and to boost\r\npartners’ earnings.\r\nFrom Kernel to User mode\r\nThe technologies which TDSS uses to communicate have not changed since the first versions of the rootkit. It\r\nreads reads Config.ini, which typically shows the following data by default:\r\n[Main]: the main section which identifies the rootkit in the system.\r\nQuote: quotes from films, cartoons etc. displayed when the debugger attaches.\r\nVersion: the version of the rootkit installed.\r\nBotid: the bot’s ID for the C\u0026C.\r\nAffId: the affiliate’s (partner’s) ID.\r\nSubid: a parameter for further identification of the bot if a botnet is split (Default value is zero)\r\nInstalldate: the date when the rootkit was installed on the victim computer.\r\nhttps://securelist.com/tdss/36314/\r\nPage 15 of 23\n\nBuilddate – the rootkit assembly date.\r\n[injector] is the section which defines the rootkit payload.\r\nThe first field contains names of processes (by default it contains “*” which stands for “all processes”.\r\nThe second field indicates the name of the DLL to be loaded to these processes.\r\n[tdlcmd] is the payload section.\r\nServers: the addresses of the C\u0026C servers, typically 3 addresses.\r\nWspservers: addresses used for search services.\r\nPopupservers: server addresses from which pages will be opened.\r\nVersion: payload version\r\nExample of TDSS configuration file\r\nThe format of the configuration file can vary depending on the version of TDSS, the payload, or on commands\r\nsend from the C\u0026C.\r\nTDSS: the enrichment kit\r\nMoney\r\nRootkit.Win32.TDSS is a universal malicious program which can hide the presence of any other malicious\r\nprograms in the system and provide enhanced privileges on an infected system. The bootkit implemented similar\r\ntechnologies: in our analysis of the bootkit, we noted that such malicious programs were very likely to gain\r\npopularity among cybercriminals as they are simple to use and offer broad possibilities. In essence, TDSS is a\r\nframework which is constantly being updated and added to. By default, TDSS only implements Trojan-clicker\r\nfunctionality (https://encyclopedia.kaspersky.com/knowledge/trojan-clicker/) and is used by cybercriminals to\r\nhttps://securelist.com/tdss/36314/\r\nPage 16 of 23\n\nmake money by manipulating traffic ratings of different sites. This payload is found in the DLL, typically named\r\n“tdlcmd.dll”, which is part of virtually all standard configurations. Obviously, the rootkit has much wider\r\ncapabilities, and can be used in different ways depending on the aims of the authors and/or renters or purchasers of\r\nthe botnet created using the malware. In 2009, an estimated 3 million infected machines were controlled by TDSS,\r\nwith approximately half of them being located in the USA. (www.networkworld.com/news )\r\nA detailed analysis of everything relating to TDSS seems to indicate that the author or authors are Russians or\r\nRussian speakers. They constantly update the malware while retaining control over it – TDSS itself has never been\r\navailable for purchase. Rather, it is the botnets controlled by TDSS, typically made up of some 20,000 infected\r\ncomputers, which get sold.\r\nIt is up to the purchaser how they use the TDSS botnet. While we’ve been monitoring it, spam-bots, rogue\r\nantivirus solutions and data stealing Trojans have all been uploaded to such a botnet.\r\nPayload\r\nThe creators of TDSS have been careful to ensure that money can be made from botnets created using their\r\nmalware. One of the default TDSS payloads is tdlcmd.dll.\r\nIn most cases, tdlcmd.dll is delivered together with TDSS and is loaded by the rootkit to all processes. However,\r\nthe malicious DLL delivers its malicious payload only in the case of browser processes and in the Windows\r\nupdate service, utilizing the fact that these processes interact with the Internet.\r\nList of processes in which tdlcmd.dll operates\r\nWhen run, the DLL:\r\n1. 1 Receives commands from the botnet C\u0026C and runs them.\r\n2. 2 Intercepts user searches and spoofs the search results.\r\n3. 3 Creates search requests to popular search engines.\r\n4. 4 Mimics user activity on web sites.\r\nThe owners of botnets created using TDSS owners can potentially profit from all of these activities.\r\nhttps://securelist.com/tdss/36314/\r\nPage 17 of 23\n\nC\u0026C commands\r\nBy default, tldcmd.dll can execute the following commands sent from the C\u0026C:\r\nDownloadCrypted: download an encrypted file.\r\nDownloadAndExecute: download and execute a file.\r\nDownloadCryptedAndExecute: download an encrypted file, decrypt and run it.\r\nDownload: Download a file.\r\nConfigWrite: modify the configuration file.\r\nIf an encrypted command arrives from the C\u0026C, it is decrypted using RC4. The source domain name is used as\r\nthe decryption key. Once the C\u0026C command has been executed, a [Tasks] section will be created in config.ini;\r\nthis is a logall actions performed by the bot.\r\nExample of a config.ini record, created once tdlcmd.dll updates are downloaded\r\nGiven that all communication with the C\u0026C is conducted via HTTPS, reading the “Tasks” section helps malware\r\nanalysts track TDSS activity.\r\nUnlike the bootkit or Conficker (a.k.a. Kido – http://mtc.sri.com/Conficker/), TDSS does not have an algorithm to\r\nsearch for migrating C\u0026C center domains. However, the “ConfigWrite” command used to modify the “Servers”\r\nfield in the section [tdlcmd] arrives when the C\u0026C is first contacted and subsequently approximately once a week.\r\nExample of C\u0026C location\r\n“The page spoofing virus”\r\nWhen running in a browser process, tdlcmd.dll tracks user requests made to the following sites:\r\n.google. .yahoo.com .bing.com\r\n.live.com .msn.com .ask.com\r\n.aol.com .google-analytics.com .yimg.com\r\nhttps://securelist.com/tdss/36314/\r\nPage 18 of 23\n\nupload.wikimedia.org img.youtube.com powerset.com\r\n.aolcdn.com .blinkx.com .atdmt.com\r\n.othersonline.com .yieldmanager.com .fimserve.com\r\n.everesttech.net .doubleclick.net .adrevolver.com\r\n.tribalfusion.com .adbureau.net .abmr.net\r\nEach time any of these sites is contacted, tdlcmd.dll generates a request to the server specified in the wspserver\r\nfield of the configuration file. Information about the infected system and the request made to the specified site is\r\nsent to the server. In reply, the C\u0026C server sends a link to a page to be displayed to the user. This link can lead the\r\nuser to any site, which could be a legitimate site, but could equally be a phishing site. Yandex.ru, the Russian\r\nsearch site, wrote about a such an attack in 2008 (http://help.yandex.ru/search/?id=1008281). At that time, such\r\ntools were incorporated into many malicious programs.\r\nInterestingly, the payload of the second version of TDSS did not work with Firefox; the cybercriminals therefore\r\ninstalled a browser add-on which performed a similar function.\r\nExample of a FireFox add-on to redirect the user’s search queries\r\nBlackhat SEO\r\nOnly a few years ago, the first page of results for a Google search query containing the word “antivirus” would\r\nonly contain links forrogue antivirus solutions. This was achieved by so-called black search engine optimization\r\n(SEO) techniques.\r\nhttps://securelist.com/tdss/36314/\r\nPage 19 of 23\n\nTdlcmd.dll incorporates a tool to “push” sites if specific keywords are used in the search query. A file called\r\n“keywords” is created in the disk section encrypted by the rootkit; this file contains words to be automatically sent\r\nto the search engine in a query. A designated site is selected to be displayed in the search engine’s result page.\r\nJavaScript is incorporated into the browser to fully mimic user activity by by pressing jump buttons as needed.\r\nhttps://securelist.com/tdss/36314/\r\nPage 20 of 23\n\nExample of a results page containing a malicious link\r\nhttps://securelist.com/tdss/36314/\r\nPage 21 of 23\n\nClicker\r\nThe rootkit communicates with the C\u0026C server via HTTPS. However, when tdlcmd.dll contacts servers in order\r\nto increase hitcounts, it simply encrypts the GET-request using the same RC4 algorithms and converting the result\r\ninto BASE64. Tdlcmd.dll contacts the server specified in the “popupservers” parameter in the configuration file.\r\nThe server responds with a file name, a link to the site and the URL from which to follow that link. The\r\nconfiguration file also specifies how often the site should be accessed. Unlike other malicious programs with a\r\nsimilar payload, TDSS creates a real browser window to fully emulate the user visiting the site. In this way, TDSS\r\ndisplays popup ads for rogue antivirus solutions or any other sites chosen by the botnet owner.\r\nThe spread of TDSS\r\nAs TDSS is spread via an affiliate program which uses all means possible means to deliver malware to victim\r\nmachines, the rootkit has attacked computers around the world.\r\nAttempts to infect computers using TDSS, 1H2010 (data fromKaspersky Security Network)\r\nGiven that payment for1000 infected machines in the USA will be higher than in any other country (as shown\r\nabove), it is hardly surprising that TDSS is spreading most actively in the USA.\r\nIn addition to KSN statistics, data can be also obtained directly from the botnet C\u0026C:\r\nC\u0026C URL\r\nNo. of infected users,\r\nas reported by C\u0026C\r\nhttps://securelist.com/tdss/36314/\r\nPage 22 of 23\n\nzz87jhfda88.com 119\r\nd45648675.cn 108\r\n873hgf7xx60.com 243\r\nThe story continues\r\nGiven that the cybercriminals have put considerable effort into continuing to support this malware, fixing errors,\r\nand inventing various techniques for bypassing signature-based, heuristic and proactive detecting, TDSS is\r\ncapable of penetrating a computer even if an antivirus solution is installed and running.\r\nThe fact that bot communication with the C\u0026C is encrypted makes it significantly more difficult to analyze\r\nnetwork packets. An extremely powerful rootkit component hides both the most important malware components,\r\nand the fact that the computer has been infected. The victim machine becomes part of a botnet, and will have other\r\nmalware installed to it. The cybercriminals profit by selling small botnets and using blackhat SEO.\r\nAs long as a malicious program is profitable, cybercriminals will continue to support and develop it. TDSS\r\nrepresents a serious headache for antivirus companies. At Kaspersky Lab, we devote a lot of time to the issues\r\nraised by TDSS, and particularly detecting and removing active infections. We hope that our colleagues\r\nthroughout the industry are doing the same so that users will be protected against this very particular threat.\r\nSource: https://securelist.com/tdss/36314/\r\nhttps://securelist.com/tdss/36314/\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://securelist.com/tdss/36314/"
	],
	"report_names": [
		"36314"
	],
	"threat_actors": [],
	"ts_created_at": 1775791218,
	"ts_updated_at": 1775791336,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dad63208a602a61b43df73a05ccb83f584085bc6.pdf",
		"text": "https://archive.orkl.eu/dad63208a602a61b43df73a05ccb83f584085bc6.txt",
		"img": "https://archive.orkl.eu/dad63208a602a61b43df73a05ccb83f584085bc6.jpg"
	}
}