Generic Rootkit.d Strikes Again in New Variant

A few days ago I got a chance to look at a recent variant of the DNSChanger.ad. It drops a common rootkit that is mostly associated with FakeAlert and DNSChanger Trojans. Over a period of time the dropped sys file names have changed from tdss*.sys to seneka*.sys to skynet*.sys and so on. Our memory detection and cleaning for this rootkit is Generic Rootkit.d. The techniques of this threat are well known now. It basically uses inline hooks on IofCallDriver, IofCompleteRequest, NtFlushInstructionCache, NtEnumerateKey, etc. This Trojan removes permissions from its registry entries as well.

The malware has a hidden sys file in the system32\drivers directory with a name like skynet*.sys. One can use a rootkit analysis tool or just windbg to restore the inline hooks installed by the malware. Even though the malicious file is no longer hidden after hook restoration, the malware can recreate the file after its deletion. It is common that malware try to “watch” or recreate their components but the curious thing was that File Monitor (filemon) did not show any activity and other API-tracing approaches also didn’t point to anything that could explain the rebirth of this file.

Taking a closer look, we found that the malware uses one of the delayed system worker threads to call, at regular intervals, ZwCreateFile in a loop created using KeDelayExecutionThread. The following figure shows the relevant malware code and thread.

This explains how the file is recreated after its deletion. This thread also watches the malware’s registry. This thread continuously restores the system service descriptor table (SSDT) using the code shown below. So any tracing utility that hooks SSDT to monitor activity would not work.

If it were just SSDT rewriting, then filemon should have reported the file activity. But the malware also removes all filesystem filter drivers; because filemon also uses a filesystem filter, it didn’t report anything. The figure below shows the device stack before and after infection. Note that all filters are removed after infection.

And here is the code that removes attached filters.

Actually the attached device field only for NTFS is nulled out, and the rest of the stack remains dangling.

Figure 3 also shows that not only is the filemon filter driver removed but even the Filter Manager has been effectively removed. Removing all filters and rewriting SSDT will thwart analysis tools that use these techniques but may also break other software as well. Obviously it does not matter to malware as long as its rootkit works in a stealthy manner in most environments. It’s a tradeoff that many malware make and this one has made its choice.