In this blog we continue our analysis of the recently discovered Tidserv variant that is capable of infecting 64-bit Windows operating systems. While we gave a quick overview of the threat yesterday, today we’re going to talk more about how Tidserv installs itself on 32- and 64-bit operating systems.
While Backdoor.Tidserv.L arrives as a 32-bit Windows executable, it checks if it's running under a 32- or 64-bit version of Windows and chooses an architecture-specific method of installing itself. If it finds that it’s running on a 32-bit system, it uses the same method as older Tidserv variants to gain necessary privileges—by executing itself in the Print Spooler service. Next, it drops a 32-bit version of the malicious kernel driver and loads it into the Windows kernel. Once the driver is loaded, it infects the Master Boot Record (MBR) with a malicious version.
It then stores a copy of the backdoor components and configuration data in a normally unused area at the end of the hard disk. All of the malicious data written to disk by the backdoor is in an encrypted format, except for the first 42 bytes of MBR code. With the malicious MBR in place and backdoor components stored at the end of the hard disk, the backdoor will run every time Windows is started. This may allow for Tidserv to survive if someone attempts to reinstall Windows, unless the MBR is replaced with a clean version, since no Tidserv code is written into the Windows partition.
Given that 64-bit versions of Windows require signed kernel drivers, Tidserv uses a different installation strategy in this case. The malicious kernel drivers are not signed and the backdoor does not attempt to load them directly on the running system. Instead, the dropper infects the MBR and copies the backdoor to the end of the hard disk directly from user mode, and then forces the computer to restart. When computer restarts, the backdoor is loaded into the Windows kernel.
Tidserv now loads using the same method on both 32- and 64-bit Windows versions. When system is started, the malicious MBR is executed. This in turn loads the "ldr16" Tidserv component from the encrypted area at the end of the hard disk. The purpose of "ldr16" is to hook the disk-read functionality provided by the BIOS, which is later used by the Windows loader.
Next, it loads a copy of the original MBR, which was saved by Tidserv during infection, and executes it. When Windows starts loading, the files read from the Windows partition will be examined by the "ldr16" hook and modified so that the backdoor will be loaded in memory. In particular, the "ldr16" hook modifies boot configuration data that may affect the policies for the verification of kernel driver signatures.
The loading method implemented by Backdoor.Tidserv.L was chosen to bypass the 64-bit Windows requirement for signed kernel drivers. It also allows for the backdoor to load into memory even if no files on the Windows partition are modified. This is nothing new and has been around for years. Similar concepts were already developed and implemented by frameworks such as Stoned Bootkit and Vbootkit. Not only that, it appears as though some code fragments used in Tidserv may have originated in other code found on the Internet. Regardless, it appears as though this could be an early version of the threat, given some quality issues that exist within the code.
----------------------------------------------
Note: We would like to thank the Emsisoft Team for sharing additional samples for analysis.