• strict warning: Non-static method view::load() should not be called statically in /home/chmag/chmag_28042011/sites/all/modules/views/views.module on line 906.
  • strict warning: Declaration of views_handler_argument::init() should be compatible with views_handler::init(&$view, $options) in /home/chmag/chmag_28042011/sites/all/modules/views/handlers/views_handler_argument.inc on line 744.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/chmag/chmag_28042011/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/chmag/chmag_28042011/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /home/chmag/chmag_28042011/sites/all/modules/views/handlers/views_handler_filter_boolean_operator.inc on line 159.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/chmag/chmag_28042011/sites/all/modules/views/plugins/views_plugin_row.inc on line 134.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/chmag/chmag_28042011/sites/all/modules/views/plugins/views_plugin_row.inc on line 134.
  • strict warning: Non-static method view::load() should not be called statically in /home/chmag/chmag_28042011/sites/all/modules/views/views.module on line 906.
  • strict warning: Non-static method view::load() should not be called statically in /home/chmag/chmag_28042011/sites/all/modules/views/views.module on line 906.

Rootkits are Back with the Boot Infection








Windows rootikits have been around since year 2005 and have become a buzzword in the security industry over recent years. While rootkits have traditionally been used by sophisticated attackers to hide their presence on compromised machines, recent malwares with rootkit capabilities have started using them to complicate efforts to detect and clean the infections. This article aims to give an idea about Windows rootkits with advanced techniques observed in the recent years, mainly rootkits with boot infections.
Windows Rootkits
This is not year 2005, when the word “Rootkit” was not known to the most of the people in cyber world besides security researchers. The technique used by rootkits to hide the presence of malwares has been, for longer time, to steal more information, send out more spam, launch more DDOS attacks, and ultimately make millions of dollars, was the matter of concern for only the cyber security researchers. But some commercial ethical software had adopted the same technique for self protection. Among all of them Sony Digital Rights Management (DRM) software received intense media attention and criticism in late 2005 and the word “Rootkit” became common term in the cyber security world.
You will find more than dozen of definitions of the “Rootkit”. But to understand the term in very simple manner we have following definition of rootkit:
A Rootkit is a set of tools used by an intruder after cracking a computer system. These tools can help the attacker maintain his or her access to the system and use it for malicious purposes. Root kits exist for a variety of operating systems.
The term rootkit is used to describe the mechanisms and techniques whereby malware, including viruses, spyware, and trojans, attempt to hide their presence from antispyware, antivirus, and various system management utilities. In other words, a rootkit is a set of programs and code that allows a permanent or consistent, undetectable presence of other components, mostly the malwares.
Windows rootkits are the rootkits which work on Microsoft Windows Operating system’s versions to hide the presence of malwares’ components like files, registry, processes, drivers etc. They do achieve this by using techniques like user mode hooking, SSDT hooking, IRP hooking and Direct kernel Object Manipulation (DKOM)   etc.
Initially PoC (proof of concept) Windows rootkits were constantly being released to demonstrate new methods of bypassing rootkit detection and prevention mechanisms provided by various security vendors for Windows operating system. Some proof of concept also got published in one of the bestselling books about Windows rootkits; “Subverting The Windows Kernel: ROOTKITS”. But eventually most of the PoCs got transformed into real world rootkits that made their way into the hands of attackers. The current state of rootkits is no more than just an arms race but has become warfare between the rootkit writers and the anti-rootkit industry which is responsible for protecting millions of systems. 
Advanced Windows Rootkits with boot infection: TDSS
We can divide Windows rootkits' era in two parts, one as pre TDSS (also known as TDL, Alureon Family) and other is TDSS family. The TDSS family rootkit first appeared in 2008. Since then, it has become far more widespread than one of the most notorious rootkits like Rustock. It has been more than two years since this family of rootkits began to evolve. The rootkit writers of this family have developed one of the most sophisticated and advanced mechanisms for bypassing various protective measures and security mechanisms embedded into the operating system. TDSS implements the concept of infecting operating system drivers and MBR; this means it is loaded and run at the very early stages of the operating system. This effectively complicates the detection of TDSS and makes the task of cleaning it too difficult and challenging.
TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled. 
When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.
The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.
The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data. 
The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows:
  • Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector.
  • Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object.
  • If kernel debugging is enabled then this TDL4 does not install any of it’s components.
TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files. 
All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.
Stealthy variant of Bootkit.Trup
We will go through the technical details of the one more new generation malware with bootkit ability which is simpler in design than TDL4 but again using boot infection as a key. The new variant of Bootkit. Trup was making rounds 2-3 months back, which is updated to protect the infected MBR. The encryption used in Bootkit. Trup.B is very similar to its old variant "Bootkit. Trup.A" which is simple rotate right (ROR) operation.
It gets Drive geometry of the infected disk and then calculates position near end of the partition to store original MBR and other components. These components are written into unallocated part of the partition, in case disk becomes full there is chance of it getting overwritten with other data.
The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.
MBR protection mechanism was previously seen in TDSS.TDL4 which was sitting at the bottom of the storage stack to monitor read and write operations to first sector and its encrypted components in unpartitioned disk space.
Having insights of the technical details of these new generation Windows rootkits, the reader must have got an idea that how difficult it is for anti-rootkit tools to counter them.


In the past few years there were no great concerns about the malware infecting boot sectors and they were even told to be no more in the wild. But looking at the changing threat landscape in the last year or two, we have to mention that these types of malwares are coming back with more rootkit capabilities.
Most of the anti-rootkit softwares available resulted in the failure while detecting the presence of these rootkits, as these antirootkit tools use techniques like cross view based detection, user mode or kernel mode hook detection or DKOM detection. These rootkits don’t provide any chance to scan the “Rooms”, where their components are residing.
As Current Anti-Rootkit softwares are not helping us more in tackling such highly advanced rootkits, need of specialized bootkit detection and removal tool arises. Most of Security vendors have already developed and released these kinds of specialized tools to counter these rootkits. Analysis of such complex malwares becomes harder with unavailability of dropper samples.  
The war against rootkits has been taken up to a newly changed battle¬ground as insights of case studies mentioned above give clear idea that how rootkit driver protects infected Master Boot Record, which keeps those advanced rootkits ahead than traditional bootkits. We have to be ready for all such techniques never seen before in malware threats and next generation of rootkits, bootkits, kernel infectors and boot sector infectors written by highly technical and professional malware writers.


I would like to give sincere thanks to Mr. Sanjay Katkar (CTO, Quick Heal Technologies) for his most valuable guidance. Also I would like to thank to my colleague Mr. Rajesh Nikam and Mr. Rajendra Kumbhar for their help in the analysis and valuable inputs.

Swanand Shinde

Swanand Dattaram Shinde is working with Quick Heal Technologies (P) Ltd. since 2005 as a Sr.Software Engineer. He holds Masters in Computer Science. He is currently working in Research and Development of Antivirus Quick Heal. He has researched on various security products like Antivirus, AntiRootkit etc.