0x7A Rootkit Debugging

Hello everyone, hope you're all well!

Late last night I received a crash dump, specifically an 0x7A dump. In most cases, 0x7A's are either some sort of HDD problem (connections to the drive/controller), faulty HDD (bad sectors, etc), antivirus causing file system conflicts, etc. You can generally find out if it's likely a drive/connections problem right away as opposed to a software problem by knowing what the 2nd parameter status codes imply. This one however is fairly interesting considering it's being caused by a rootkit (so it appears), and I love interesting kernel-dumps, so let's take a look!

-- You can read my first rootkit debugging post here. It was an 0x3B bug check as opposed to 0x7A.

---------------------------

KERNEL_DATA_INPAGE_ERROR (7a)

This bug check indicates that the requested page of kernel data from the paging file could not be read into memory.

BugCheck 7A, {4, 0, fffffa8009bc11f0, fffff8a009446220}

The 1st parameter of our bug check is 4, which indicates that the 2nd parameter is an error status code (typically I/O status code). With this said, the 3rd parameter in our case AFAIK is the PTE contents, and the 4th parameter is the faulting address.

The 2nd parameter in our case is 0, which is the following NTSTATUS value - STATUS_SUCCESS (0x00000000). Quite simply, it implies that the operation completed successfully.

---------------------------

Let's have a basic look at the call stack:

1: kd> k
Child-SP          RetAddr           Call Site
fffff880`177104d8 fffff801`52f2906c nt!KeBugCheckEx
fffff880`177104e0 fffff801`52eeabb7 nt! ?? ::FNODOBFM::`string'+0x24cc6
fffff880`177105c0 fffff801`52ea8def nt!MiIssueHardFault+0x1b7
fffff880`17710690 fffff801`52e6beee nt!MmAccessFault+0x81f
fffff880`177107d0 fffff801`532ba031 nt!KiPageFault+0x16e
fffff880`17710960 fffff801`532ba8a8 nt!CmEnumerateKey+0x191
fffff880`17710a10 fffff801`52e6d453 nt!NtEnumerateKey+0x308
fffff880`17710b90 000007ff`2b3e2f0a nt!KiSystemServiceCopyEnd+0x13
00000042`a4baf118 00000000`00000000 0x000007ff`2b3e2f0a

Very interesting call stack we have here! The first big red flag/question we are asking ourselves here is 'Why is a low-level NT function calling into a pagefault?' The answer is... we likely have a rootkit!

First off, the CmEnumerateKey routine returns information about a subkey of an open registry key, and if we remember, the 2nd parameter of the bug check was 0 (STATUS_SUCCESS). This indicates that it was successful in its attempt to return information regarding the subkey. Many newer generation rootkits use a technique labeled DKOM (Direct kernel object manipulation) to hide themselves in legitimate Windows processes. In our case here, it appears to have hooked itself into NtEnumerateKey.

Expanding off of DKOM, one of the most common ways of going undetected is hooking registry API functions such as - RegOpenKey, RegEnumKey, RegEnumValue. To further increase effectiveness of the rootkit regarding its ability to go undetected, it will specifically hook the low-level NT versions of these functions, such as - NtOpenKey, NtEnumerateKey and NtEnumerateValueKey.

---------------------------

With all of that said, if the rootkit is so sophisticated at hiding itself, why is this showing in a call stack of a crash dump? Also, why is the system even crashing in the first place? One of the ways to effectively discover a rootkit hooked to such entries listed above is to directly invoke said functions. In this case, the user was attempting to run scans with various software that would detect the rootkit (such as TDSSKiller, etc). Every time the user ran a scan with such software, the system would call an 0x7A bug check. I may be wrong, but this may be a 'defense' mechanism of the rootkit, or the scan is actually conflicting with the rootkit/what it's trying to accomplish regarding hooking, therefore it forces a bug check or kernel corruption will occur.

What's the problem? Well, we can surely almost confirm a rootkit, however, at the same time, we also actually cannot be too sure. Why? Well, this is pretty clear that hooks are occurring and we've caught them, however, what's interesting to know is that intrusion prevention-based software also hooks like this. The user is crashing every single time he/she runs a scan, so that could also be a possibility of buggy software.

---------------------------

1: kd> dl nt!PsActiveProcessHead  10 2
fffff801`530acc80  fffffa80`03088328 fffffa80`0a0b1828
fffffa80`03088328  fffffa80`067aec28 fffff801`530acc80
fffffa80`067aec28  fffffa80`07314ae8 fffffa80`03088328
fffffa80`07314ae8  fffffa80`07d45c28 fffffa80`067aec28
fffffa80`07d45c28  fffffa80`07d13368 fffffa80`07314ae8
fffffa80`07d13368  fffffa80`07d13ae8 fffffa80`07d45c28
fffffa80`07d13ae8  fffffa80`07d787e8 fffffa80`07d13368
fffffa80`07d787e8  fffffa80`07d65c28 fffffa80`07d13ae8
fffffa80`07d65c28  fffffa80`07d63368 fffffa80`07d787e8
fffffa80`07d63368  fffffa80`07d63c28 fffffa80`07d65c28
fffffa80`07d63c28  fffffa80`091c2368 fffffa80`07d63368
fffffa80`091c2368  fffffa80`091eb7e8 fffffa80`07d63c28
fffffa80`091eb7e8  fffffa80`07428c28 fffffa80`091c2368
fffffa80`07428c28  fffffa80`0742dc28 fffffa80`091eb7e8
fffffa80`0742dc28  fffffa80`0742ac28 fffffa80`07428c28
fffffa80`0742ac28  fffffa80`07463c28 fffffa80`0742dc28

The first entry is the System Process, which we can confirm:

 1: kd> dt nt!_EPROCESS ActiveProcessLinks.Blink poi(PsInitialSystemProcess)
   +0x2e8 ActiveProcessLinks       :  [ 0xfffffa80`067aec28 - 0xfffff801`530acc80 ]
      +0x008 Blink                    : 0xfffff801`530acc80 _LIST_ENTRY [ 0xfffffa80`03088328 - 0xfffffa80`0a0b1828 ]

From here, we can walk along the linked list to confirm whether or not it is corrupt:

1: kd> !validatelist fffff801`530acc80
Found list end after 118 entries

It's not corrupt, however, I don't believe this implies that a rootkit is not present on the system, and that it hasn't been modified.

For now, that's about it regarding this post! I just wanted to share my findings thus far. I will have to wait until the user has a chance to run addition recommended scans, such as GMER. I am almost certain in this case that we have a rootkit present, but you never want to be too sure.

Thanks for reading!

References/extra reading:

http://books.google.com/books?id=ENnSA91Bt_4C&dq=zwenumeratekey+rootkit&source=gbs_navlinks_s

http://books.google.com/books?id=VvFlEmS57LQC&dq=NtEnumerateKey&source=gbs_navlinks_s

http://bsodtutorials.blogspot.com/2014/01/rootkits-direct-kernel-object.html