Reversing Stuxnet: 3 (Filesystem hooking)

Stuxnet is a very sophisticated rootkit. Since it runs in the kernel, it has ultimate control over what userspace sees/experiences. Stuxnet exploits its privileges to hide certain payload files. When I first installed Stuxnet in my Virtual Machine, it came as 3 files: "~WTR4132.tmp", "~WTR4141.tmp" and "Copy of Shortcut to.lnk". These are the files that are supposed to come preloaded on the infected USB drive that is connected to the target machine.

Once Stuxnet is installed, it hides the aforementioned files from system calls that try to enumerate the files in the current directory. By doing so, a regular user would be unaware that his machine is infected with Stuxnet. For example, in the screenshot below, the displayed folder actually contains 2 additional files (~WTR4132.tmp and ~WTR4141.tmp), which have been filtered out of the result of the Windows shell's query to the filesystem for all files in that directory(see NTQueryDirectoryFile).

I set a breakpoint in the mrxnet module that was loaded into the windows kernel so we can trace the execution at certain points in time. The function in which I placed the breakpoint(let's call it EvaluateFileHidingRules) contains the logic that Stuxnet uses to figure out whether or not it should hide a file(more on this in a future post). Below is the call stack at the point in time that we try to navigate to the folder with the hidden files (folder screenshot above):

What's interesting is that we can see the Stuxnet code (anything marked with mrxnet in the above call stack) executing at different layers in the call stack. This is probably due to the fact that Stuxnet installs itself as a file system filter driver, and registers callbacks in the windows kernel.

Another occurrence I noticed (which is supported by the above call stack) is that the number of times that my breakpoint in EvaluateFileHidingRules was hit is linearly proportional to the number of files in the current directory when I run the dir command from the Windows commandline. This is due to fact that one of the functions that NtQueryDirectoryFile indirectly calls for each file in the folder, in turn calls EvaluateFileHidingRules. In general, the number of calls to EvaluateFileHidingRules is as follows:

#calls = (#files in Dir) + 2

NOTE: #files in Dir reflects what is actually on the disk, not what is returned to userspace after filtering.