This is a follow-up to a previous article on Tidserv and MS10-015.
The word spread that the Tidserv gang have patched their rootkit to avoid the infinite reboot issue due to API offsets changes in the kernel module introduced by MS10-015, so we ran our own tests on the following samples, which are said to cope with such kernel updates:
MD5: 0370db3da46a580c600e99efd6d44d1b
MD5: e1212a8cf64d5157d02bf2175c16ab25
These samples use the following two configuration files (config.ini extracted from Tidserv's Encrypting File System) and are the latest Tidserv samples we have in our lab:
--- (0370db3da46a580c600e99efd6d44d1b)
[main]
quote=Jebus where are you? Homer calls Jebus!
version=3.25
botid=[CLSID]
affid=[NUMBER]
subid=0
installdate=[DATE]
builddate=16.2.2010 0:45:2
[injector]
*=tdlcmd.dll
[tdlcmd]
servers=https://a57990057.cn/;https://94.228.209.145/;https://94.228.209.146/
wspservers=http://c36996639.cn/;http://c58446658.cn/
popupservers=http://m2121212.cn/
version=3.74
--- (e1212a8cf64d5157d02bf2175c16ab25)
[main]
quote=F*ck damnation, man! F*ck redemption! We are God's unwanted children!
version=3.26
botid=[CLSID]
affid=[NUMBER]
subid=0
installdate=[DATE]
builddate=16.2.2010 17:3:20
[injector]
*=tdlcmd.dll
[tdlcmd]
servers=https://a57990057.cn/;https://94.228.209.145/;https://94.228.209.146/
wspservers=http://c36996639.cn/;http://c58446658.cn/
popupservers=http://m2121212.cn/
version=3.74
---
One can observe the time difference between the build dates of these two versions is about 16 hours, which is quite small compared to other threats.
Another thing worth mentioning is that the installer/dropper's debug message has been changed to:
"We should have shotguns for this kind of deal."
After successful installation the infected drivers were indeed able to cope with changes in the kernel API offsets. In order to achieve that they now use hash functions on required API names to retrieve their addresses on the fly:
This technique is known to have been used in viruses and other threats for years, and yet they had to disable most of their bot network in order to use it, as Symantec's IPS monitoring system shows:
Note the drop in infection pings once the MS10-015 was released on 02/09/2010.
Here's how the infection distribution by top 15 countries looks like:
However, with both samples that was just a fortunate case where the driver was correctly infected; the majority of the time the computer was found to infinitely loop into the infamous BSoD at restart, and that's without applying MS10-015:
Yes, that's a digital picture: we had to use a real machine to try the latest variants, since they were a bit 'shy' inside virtual machines. In other words, they wouldn't install properly in VMs.
After some post-mortem analysis, it turns out that the EntryPoint and Checksum fields in the PE header structure of the infected drivers have been changed, while the viral code injection did not complete, thus leaving the entry point of the driver with invalid code:
The code shown above represents the original data bytes from the driver's resource section, which the CPU did not like so much.
Properly infected driver entry point should look like this:
Statistically it has been shown that the number of bugs in a program is proportional to its complexity, or it's source code size. Also, in kernel mode, the smallest mistake leads, in most cases, to a BSoD. Add to that a bit of laziness, rush and lack of QA and you can guess what's going to happen. On the other hand this may mark the beginning of the end of an otherwise advanced rootkit. Sadly, the end users who got infected are the ones who've paid the price.
Thanks to Vikram Thakur for his assistance in generating the infection statistics.