A few days ago I got a chance to look at a recent variant of the DNSChanger.ad. It drops a prevalent rootkit which 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 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 it was interesting to note that malware is able to re-create the file upon deletion. It is common that malware try to ‘watch’ or recreate their components but the curious thing was that filemon was not showing any activity and other API tracing based approaches also didn’t point to anything that could explain recreation of this file.

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

Figure 1 File Creation loop

That explains how the file is recreated upon deletion. This thread also watches the malware’s registry. Additionally, 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.

Figure 2 SSDT rewrite

If it was just SSDT rewriting then filemon should have been able to report the file activity. But the malware also removes all filesystem filter drivers and since 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.

Figure 3 Device stack before and after infection

Figure 3

And here is the code that removes attached filters.

Figure 4 Detach filter

Actually the attached device field for only 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 trade off that many malware make and this one has made its choice as well.