Automated Rootkit Detection with ThreatSCOPE

• July 27, 2016

This article will show how you can use the ThreatSCOPE feature of WindowsSCOPE to detect rootkits installed on a system. One of the difficulties in detecting rootkits and other advanced malware is that they’re often packed, encrypted, or injected by other means than being run from an executable file on the disk. This means they can easily slip past most common antivirus tools that only look on the disk. This is why you need an in-memory tool like WindowsSCOPE to detect these types of advanced threats. In this post we’ll show how to detect the Hacker Defender rootkit (hxdef) using the new ThreatSCOPE feature.

One of the most effective ways to detect rootkits and other malware is by comparing against a known-good system state. When a rootkit is suspected, huge amounts of time can be saved in finding malicious changes by narrowing the search to only what has changed in the system. This is the idea that ThreatSCOPE is based on, and how we quickly detected changes that were made by the hxdef rootkit. So the first thing we did before running the hxdef loader was to take a memory snapshot before introducting the rootkit. Then, after installing hxdef, we took a second memory snapshot. After importing these snapshots into WindowsSCOPE, we used ThreatSCOPE to run a code comparison on ntdll.dll. You can see the comparison results in this screenshot:

Based on the analysis results, it looked like the rootkit was injecting hooks into ntdll, as this code shouldn’t be changing after it’s loaded. To find out for sure what was actually happening here, we looked up the code at the address of one of the 4 byte code changes both before and after the change. Looking in the disassembled view, we discovered that the original code at this address:

Had been changed to:

Based on this we were able to identify this change as an inline hook injected into ntdll by the hxdef rootkit. We found the same results for each of the other 4 byte code modifications – a jmp instruction that was redirecting control flow to code injected by the rootkit.

Looking a little bit further, we were able to identify exactly which code was being hooked. We did this by searching the address of the inline hook in the export table for ntdll:

We found that this particular change was hooking NtCreateFile. By looking up the rest of the changes in the export table we were able to get a full list of hooks that were created in ntdll by the rootkit: NtCreateFile, NtDeviceIoControlFile, NtEnumerateKey, NtEnumerateValueKey, NtOpenFile, NtOpenProcess, NtQueryDirectoryFile, NtQuerySystemInformation, NtQueryVolumeInformationFile, NtReadVirtualMemory, NtResumeThread, and NtVdmControl.

This is just one example of how ThreatSCOPE can be used to speed up a rootkit investigation. ThreatSCOPE can also be used to quickly identify changes in the SSDT, IDT, process list, open sockets, open files, open registry keys, and other system data structures. Once suspicious changes are found you can perform more in-depth reverse engineering as necessary.