VB2014 paper: Unveiling the kernel: rootkit discovery using selective automated kernel memory differencing

To select which areas of the kernel to examine, it is necessary to understand what effect kernel-mode rootkits have on the kernel. For a kernel-mode rootkit to have a presence in the kernel it must load a driver. The driver will then modify various functions or pointers to hide malicious activity from the user, other programs, and sometimes from itself.

A driver object represents an individual driver in the system [7]. The DRIVER_OBJECT structure contains information about a driver including its name, initialization routine, unload routine, a pointer to the loaded driver image, a pointer to its device object, and its MajorFunction dispatch table.

When a rootkit loads its driver, a DRIVER_OBJECT structure is created for it. The DriverStart field points to the loaded image of the rootkit driver. When the initialization routine is executed, as well as creating its own driver object, a rootkit driver can modify the driver objects of other drivers.

To track changes, driver objects and device objects are enumerated, and data from each is extracted and dumped. For speed and memory efficiency, only specific fields from the structures are dumped.

A kernel module is a loaded image file that resides in kernel address space. The address space typically comprises drivers and the Windows kernel. Currently, the information dumped to the JSON file is minimal, consisting of the module name, image base and module size. By comparing before and after snapshots of the module list, it is possible to tell which modules have been added (indicating the possible presence of a new driver), and which modules have been changed. Changes to the image base or size of a module suggest that the module has been replaced, thus indicating the presence of a rootkit.

The System Service Dispatch Table (SSDT) is an array of function pointers that resides in kernel address space. The entries in the array reference core functions exported by the Windows kernel (e.g. ntoskrnl). These functions provide an interface for user-mode programs to perform tasks such as opening a file or querying a directory. By modifying the address of a function pointer or the code that an entry points to, rootkits can hook a function and control the data that is passed to and from it.

To detect changes to the SSDT, the entire table is dumped. The addresses in the table are checked (during processing) against the ones saved in the baseline snapshot to detect any hooks. Typically, when the code of a function is hooked, an assembly language ‘jmp’ instruction is written to the beginning of the function which jumps to hook the code. To detect such code hooks, the first eight bytes of each function are also dumped, to enable the processing module to compare them against the baseline snapshot.

The IDT is a processor-specific array that has 256 entries. Each entry (an interrupt vector) in the array contains information about its corresponding interrupt handler. Interrupts are operating system conditions that divert the processor to code from the normal flow of execution of a program [8]. These interrupts are called (using the INT x assembly language instruction) by both hardware and software. As defined by Intel, the first 32 entries are reserved for exceptions [8] (i.e. INT 0 - Division by 0), and the rest are ‘user’ defined. The Windows operating system and various core system drivers also install interrupts, but there remain spare entries that rootkit developers can use to their advantage.

The entire IDT for each processor is dumped to the JSON log to enable us to find new IDT additions and hooks.

A callback is a function that is executed on completion of a specific event. The Windows operating system provides routines that allow driver writers to register callbacks on a number of events that rootkit writers can exploit. The routines that are of most interest are:

A rootkit registering any of these callbacks will be able to hide processes, images, threads or registry entries upon creation.

The callbacks of each type are enumerated and added to the JSON log.

Rootkits reside in kernel address space, but bootkits begin outside the operating system. Their execution begins in either a modified Master Boot Record (MBR) or a modified Volume Boot Record (VBR). A common task of a bootkit is to load a driver, typically from hidden storage at the end of the disk, which may proceed to hide the modified MBR/VBR. As the bootkit executes before the operating system is fully started, it can bypass detection by security software.

To detect the presence of a bootkit, checksums of the MBR and VBRs for all partitions are written to the JSON log. In addition to the initial boot code, the MBR also contains the disk’s partition table [9]. The entire partition table is also dumped and written to the JSON log so that changes in partition location/size (also indicative of a hidden file system) can be detected.

This category shows the changes to the kernel introduced during the analysis. For example, in Figure 1 we can see that a new device was attached to \Filesystem\FltMgr and \Filesystem\RAW. Also, the MBR SHA1 has been changed.

Figure 1. A new device attached to \Filesystem\FltMgr and \Filesystem\RAW.

(Click here to view a larger version of Figure 1.)

This section shows a breakdown of all the driver objects found in kernel memory after running the sample. The breakdown also shows the I/O request packet handlers for each object.

Figure 2. Drivers.

(Click here to view a larger version of Figure 2.)

This section shows all modules found on the system by enumerating the linked list of modules starting with ntoskrnl.exe. For each module we get the name, address and size.

Figure 3. Modules.

(Click here to view a larger version of Figure 3.)

This section shows the entries in the system service dispatch table. For each system call we get its address and starting bytes. This shows if any inline hooks are added to the system calls.

Figure 4. SSDT.

(Click here to view a larger version of Figure 4.)

These sections show any callbacks installed by any drivers. For each callback we list its type, the driver path that installed it, the address and SHA1 of the driver.

Figure 5. Callbacks.

(Click here to view a larger version of Figure 5.)

This section contains information available in the MBR and its SHA1. In addition to listing each partition’s detailed information by parsing the partition table entries, we also list the SHA1 of the VBR that this partition points to and the address of the last sector of the formatted file system and the last sector of disk.

Figure 6. MBR.

(Click here to view a larger version of Figure 6.)

This section shows the descriptors in the interrupt descriptor table. For each descriptor we show its type and address.

Figure 7. IDT.

(Click here to view a larger version of Figure 7.)

TDL has many variants. We tested a variant that employs an MBR infection technique to load its malicious driver. TDL4 is discussed thoroughly in [10], [11]. According to [10], on an x86 system, the kernel-mode drivers are tasked with maintaining the hidden file system to store the bootkit components, injecting the payload into system processes, and performing self-defence. The dropper tries to employ the print spooler provider load method to load its driver in kernel memory. The sample we looked at employed direct writes to disk by getting a handle to PhysicalDrive0 using NtCreateFile, and then used a sequence of DeviceIOControls to write to the disk, as explained in [11].

The SHA of the sample we analysed was c46ac210e06aad56dda12df3c0ccebb45108a745. Figure 8 and Figure 9 show the changes introduced in the kernel.

\Filesystem\RAW
{u’devicename’:u’(unnamed)’,
u’devobj_extension’:
  {u’deviceobject’: u’0x8482c030’},
u’driverobject’: u’0x83e1f1b8’,
u’deviceobject’: u’0x8482c030’,
u’attacheddevice’:
    {u’devicename’: u’(unnamed)’,
    u’devobj_extension’: 
      {u’attachedtoname’: u’(unnamed)’,
      u’attachedtoobject’: u’0x8482c030’, 
      u’deviceobject’: u’0x84895710’}, 
    u’driverobject’: u’0x84a41c40’, 
    u’deviceobject’: u’0x84895710’,
    u’drivername’: u’\\FileSystem\\FltMgr’, 
    u’type’: u’FILE_DEVICE_DISK_FILE_SYSTEM’},
u’drivername’: u’\\FileSystem\\RAW’, 
u’type’: u’FILE_DEVICE_DISK_FILE_SYSTEM’}}]}

\Filesystem\FltMgr
{u’devicename’: u’(unnamed)’, 
u’devobj_extension’: 
    {u’attachedtoname’: u’(unnamed)’,
    u’attachedtoobject’: u’0x8482c030’, 
    u’deviceobject’: u’0x84895710’}, 
u’driverobject’: u’0x84a41c40’,
u’deviceobject’: u’0x84895710’,
u’drivername’: u’\\FileSystem\\FltMgr’, 
u’type’: u’FILE_DEVICE_DISK_FILE_SYSTEM’}}]}

Figure 8. Changes introduced in the kernel.

(Click here to view a larger version of Figure 8.)

Figure 9. Kernel memory changes.

(Click here to view a larger version of Figure 9.)

What we observe from the changes to the driver objects are the changes seen in the DEVICE_OBJECTs relating to two drivers: \FileSystem\FltMgr and \FileSystem\RAW. If we examine the changes above, we see that a single device has been created and attached to the device pointed to by \Filesystem\RAW. That same device is now pointed to by \FileSystem\FltMgr. The DEVICE_OBJECT is represented as the one at address 0x84895710.

Another change is in the MBR SHA which indicates that the sample has written the malicious MBR to disk:

[{u’Original’:u’4b1713e6d41c71667f2af1681fad8be1e101163f’}, 
{u’Changed’: u’a192e0fa1db37219932b17ecdd23ad59e5c57ef0’}]

Finally, there are changes in the SSDT that are the result of paging in parts of the kernel. These are marked as paged in during processing of the raw results. While they might not necessarily be system calls made by the sample, they could lie within a page that was paged in and thus show up in the differencing (see Table 2).

Gapz is a bootkit that is famous for its sophistication. It was thoroughly analysed in [12]. Gapz comes as two different variants: an MBR infector and a VBR infector. The MBR infecting version of the bootkit hijacks the boot process to hook the int 13 handler. The VBR-infecting variant only alters a DWORD: the ‘hidden_sectors’ value in the BIOS Parameter block of the VBR, which will instruct the VBR code to transfer control to a malicious loader instead of the standard IPL. The kernel-mode changes include writing blocks of its malicious kernel module to kernel memory in addition to hooks to IRP_MJ_INTERNAL_DEVICE_CONTROL and IRP_MJ_DEVICE_CONTROL handlers of the disk miniport driver. Both variants employ the same kernel-mode component.

The SHA of the VBR infector we used was 1f206ea64fb3ccbe0cd7ff7972bef2592bb30c84. As documented in [12], this sample injects the shellcode responsible for writing to disk into explorer.exe. The sample gets a handle to the volume and to the disk by calling NtCreateFile on GLOBALROOT\ArcName\multi(0)disk(0)rdisk(0)partition(1) and PhysicalDrive0, respectively. As with TDL, it issues a series of DeviceIOControls to write to them.

As can be seen in Figure 10 and Figure 11, the differencing identified a change in the VBR for partition 0.

{u’vbrsha1sum’: [{u’Original’: u’7a781423dbb768786a81633441f8d533594583f5’},
{u’Changed’: u’64f08b44562578234af25a1cfef84d2bccf1a5’}]}

Figure 10. A change in VBR is noted.

Figure 11. A change in the VBR for partition 0 is identified.

(Click here to view a larger version of Figure 11.)

Figure 12. MBR.

(Click here to view a larger version of Figure 12.)

We can also see changes in the SSDT that are showing as paged in calls (see Table 3).

In our standard system set-up we did not capture the changes introduced in kernel memory during our standard test. We caught the write to the VBR, which is sufficient indication of malicious behaviour. The reason we could not see the kernel memory changes is because the dropper requests a reboot in order to kick off the VBR/MBR loading of its kernel-mode component.

In March 2014, German security firm G Data released a red paper which contained an analysis of the Uroburous rootkit [13]. Shortly afterwards, BAE Systems also released a comprehensive white paper on the rootkit [4]. The G Data paper indicated that the rootkit may have been involved in a Russian cyber attack against the US. Due to tensions between Russia and Ukraine at the time, multiple news companies covered the story, including the New York Times [14].

As described in [4] and [13], the rootkit comprises a driver and a virtual file system that is contained in a file on the disk. The rootkit creates an entry in the Interrupt Descriptor Table (IDT). The code for several functions in the SSDT is then hooked with an INT instruction (see [8] for details) that triggers the malicious software interrupt. A parameter is passed to the interrupt, identifying from which function it was called. This is used to look up a function in a custom dispatch table which executes the appropriate code for the hook.

From running an analysis on sample 39e492e839ad47ab6b58608f0f6b7290b52122eb, we get the results shown in Figure 13. The results tell us that SSDT functions have been hooked, and that the IDT has been modified, which is consistent with the behaviour of Turla.

Figure 13. Results of sample analysis.

Upon closer inspection of the SSDT (see Figure 14), we can see that a number of functions have been modified. Functions like NtQuerySystemInformation and NtReadFile are often targeted by rootkits.

Figure 14. A number of functions have been modified.

(Click here to view a larger version of Figure 14.)

The diff is showing that there is a difference in the first eight bytes of each function. Closer examination of the NtCreateThread start bytes reveals that it is only the first five bytes that have changed.

{u’startbytes’: [{u’Original’: u’682403006820b4’}, {u’Changed’: u’6a08cdc3906820b4’}]}

On translating the modified bytes into assembly language we get:

6A08  push byte +0x8
CDC3  nt 0xc3
90    nop

Looking up the IDT entry at index 0xc3 on the IDT tab (see Figure 15), we see that the code for the interrupt is located at 0x8495a2b0. Cross referencing this address with the IDT entry in the kernel diff (Figure 16), we see that 0xc3 is the newly added IDT entry.

Figure 15. Looking up the IDT entry at index 0xc3 on the IDT tab.

Figure 16. Cross referencing 0x8495a2b0 with the IDT entry in the kernel diff.

The Necurs rootkit was first discovered in May 2011[15] , but became well established in 2012. It was one of the first widespread rootkits to target x64 systems. It was originally packaged with fake anti-virus malware, but recently it has been used with the infamous Gameover Zeus variant [16]. Although it has been around for a while, the rootkit is as prevalent as ever.

Necurs is the name for the kernel-mode part of the rootkit. It consists of a driver file which, when installed on a system, works alongside other malware to hide its presence and make it difficult to remove. The way this is achieved differs depending on the processor architecture and operating system of the host computer. As our analysis system is only running on x86 Windows 7, we will only discuss the effects of the rootkit on this particular set-up.

When Necurs is installed on Windows 7, a service is created and the malicious driver is loaded. The driver hides the service and the driver file on disk by installing a file system filter driver. It also installs a LoadImageNotify callback to control which programs can be loaded.

By looking at the signatures (Figure 17 and Figure 18) after running a Necurs sample (412769f14bbc629a16208cda5fd6dc25e5f8e8bb), we see that a number of kernel modifications have occurred. These indicate that a new driver and a new callback have been installed.

Figure 17. Signatures after running a Necurs sample.

Figure 18. Signatures after running a Necurs sample.

Closer examination of the driver object (Figure 19) shows a name but no path. This means that our system could not access the driver. The most likely reason for this is that the driver is hidden. Something is hiding it from the file system, yet the driver object exists in memory. While this is not necessarily a malicious trait, it is certainly suspicious, and is worth investigating further.

Figure 19. Closer examination of the driver object.

The next point of interest is the addition of device objects. By looking at the kernel diff (Figure 20) we see that a device has been added to /FileSystem/FtlMgr, which is the file system filter manager. This is definitely of interest. Examination of the added data shows that the driver object related to the added device belongs to the newly added driver.

Figure 20. A device has been added to /FileSystem/FtlMgr.

Similarly, examining the callback that has been added (Figure 21) also reveals that the code for the callback is contained in the newly added driver.

Figure 21. Examining the callback.

(Click here to view a larger version of Figure 21.)

To summarize, the scan has revealed:

This collection of traits is indicative of rootkit-like behaviour, and is consistent with the behaviour of the Necurs rootkit.

We observed from our first experiment that not all successfully loaded drivers produced kernel memory data. From the set of successfully loaded malicious drivers, 82.3% produced kernel memory data that could be used later for differencing. From the clean set, 51.2% returned kernel memory data.

The reasons for failure were shared by clean and malicious drivers. A common reason was insufficient time for the log to be generated. Because the scan starts 105 seconds into the 120 seconds available for the analysis, and can take between 10 and 15 seconds, we sometimes miss the log by a second or two. Since the agent terminates before the machine shuts down fully, this is time taken from the 120 seconds. There is a trade-off between speed of analysis and data gathered. Our testing produced enough successful replication from malicious files for an automated analysis system.

From a set of malicious driver files:

Total drivers successfully loaded: 1,854

Total tasks with kernel data retrieved: 1,525

We expect that a successfully loaded driver would create a driver object and a new module. All of the malicious drivers created a new driver object on loading, except for one. This driver installed ‘CreateProcessNotify’ and ‘LoadImageNotify’ callbacks pointing to an ‘unknown/module’, and installed inline hooks at ‘NTEnumerateKey’ and ‘NtFlushInstructionCache’. This is indicative of highly suspicious behaviour.

Figure 22. The driver installed ‘CreateProcessNotify’ and ‘LoadImageNotify’ callbacks.

(Click here to view a larger version of Figure 22.)

Figure 23. Callbacks pointing to an ‘unknown/module’.

(Click here to view a larger version of Figure 23.)

Another interesting find was a sample that created a new driver object upon loading, but which did not show a newly added module in the differencing data. Looking at the job we find that the sample installs an SSDT hook by altering the VA of the service function ‘NtMapViewOfSection’. Again, this is highly suspicious behaviour.

Figure 24. The sample installs an SSDT hook by altering the VA of the service function ‘NtMapViewOfSection’.

(Click here to view a larger version of Figure 24.)

From a set of running clean driver files:

Total drivers successfully loaded: 1,053

Total tasks with kernel data retrieved: 5,40

These results show that the number of hits on newly created drivers corresponds to the hits on the new module. This makes sense, since a successfully loaded driver would also have added a module. An interesting finding was that on the Windows 7 machine, the percentage of samples that installed SSDT hooks was higher. Delving into those clean samples showed that they were either security software drivers that installed hooks in the SSDT or ones used for general system administration. For example, in Figure 25 we can see the SSDT hooks installed by regmon.sys from Microworld Technologies Inc.

Figure 25. SSDT hooks installed by regmon.sys from Microworld Technologies Inc.

(Click here to view a larger version of Figure 25.)

Another interesting sample was a clean driver that installed an IDT hook. Checking the results for that job shows that the driver also hooks NtOpenKey and NtCreateKey. Furthermore, it modifies the disk driver object by hooking an IRP, namely IRP_MJ_POWER. While it looks suspicious, this is actually a driver from Aladdin Knowledge Systems called ‘aksfridge.sys’ of ancillary function driver type. We are still investigating the function of this driver.

We collected a set of malicious PE files (detected by a static detection) and ran them for analysis to see whether our system can identify rootkit behaviour from executables.

First, we observed that the percentage of jobs that produced kernel memory data was much higher than any of the driver replication sets. This is positive news for us, since PE files constitute a large proportion of malicious files.

Number of malicious PEs: 319

Number of malicious PEs with kernel memory log: 303

It is clear that the number of malicious PEs that induced rootkit like behaviour was not large. We can still infer useful information by delving into the samples that triggered some of those signatures.

We can see an example of a sample that created two new driver objects in addition to installing an SSDT hook (Figure 26 and Figure 27). This sample is detected as Troj/NtRootK-DJ. The sample drops two driver files in %SYSTEM32%\drivers\. We could see the two objects for the two drivers created in addition to the SSDT hook installed below in the kernel memory differencing. By comparing the VAs, we see that the SSDT hook lies in the second driver.

Figure 26. Two driver files are dropped in %SYSTEM32%\drivers\.

(Click here to view a larger version of Figure 26.)

Figure 27. The SSDT hook lies in the second driver.

(Click here to view a larger version of Figure 27.)

Figure 28 is a screen capture of the kernel memory differencing produced by a sample of Mal/DownLdr-BZ. The sample drops a malicious driver file in several locations. The dropped driver file is detected as Mal/Rootkit-X. We can see that in the kernel memory differencing there is a newly attached device object to the PnP Manager driver. This device object is of type FILE_DEVICE_CONTROLLER. This could indicate that the sample is trying to hide the existence of malicious files. The type of the device in addition to the location to which it is attached is sufficiently interesting to warrant further investigation.

Figure 28. Kernel memory differencing produced by a sample of Mal/DownLdr-BZ.

(Click here to view a larger version of Figure 28.)

Combining the data for all the malicious files versus all the clean files, we get a clearer picture of the high-contributing signatures. It is important to note that our set of malicious files is larger than the set of the clean files.

Total number of malicious files with kernel data: 1,828

Total number of clean files with kernel data: 540

Combining the results above with our experience in analysing rootkits, we assigned maliciousness indexes to each signature following the Cuckoo signatures severity style. In Cuckoo, a signature’s severity field indicates its maliciousness. For example, a signature that triggers to highlight an action that is usually performed by clean software will have the lowest severity value of ‘1’. An action frequently performed by clean software will trigger a signature of a higher severity value, ‘2’. Actions that are largely only exhibited by malicious software will trigger a signature that has the highest severity value of ‘3.’

Our previous assumption that modifying the IDT or the SSDT should mainly be performed by malicious drivers proved to be incorrect. It transpires that the registration of a new callback is more suspicious than, for example, an SSDT hook. We showed earlier how a clean driver installed an IDT hook in addition to hooking the IRP table of the disk driver. An expected finding for us was the low severity of generic_new_driver and generic_new_module, since this is behaviour that can be induced by both clean and malicious files. Generic_ssdt_hook was also relatively low, but we attribute that to the high number of clean software security drivers in our clean set. Most of these will add SSDT hooks for monitoring purposes. We decided to make the severity of this signature medium. Generic_modified_driver, generic_new_callback and generic_attached_device provided most results from this experiment. We can assign a medium severity to those, since they are more likely to be performed by malicious files. For the rest of the samples where we did not get any hits, we assigned a severity based on past experience and our understanding of how malicious rootkits operate.

It became obvious from the results that no single signature from those that fired is a clear indication of maliciousness. Some were weighted when it came to malicious behaviour, but none were sufficiently high on their own. Some signatures failed to trigger so we had to resort to our experienced opinion to assign a severity level. Table 4 is a breakdown of the severity levels we assigned to indicate maliciousness.

It is still worth exploring the possibility of examining other areas of kernel memory. For instance, checking the functions exported by ntoskrnl for hooks (TDSS hooks IofCallDriver, which is a function exported by the kernel). As part of our future work we intend to improve the identification of modifications to modules. We currently only present the image base, size and name of a module. Additionally, research will be done into comparing individual kernel objects, to see if any useful information can be obtained as long as the analysis processing time is not increased too much.

An obvious enhancement to the system would be the ability to handle 64-bit files. At the moment the system does not have this functionality, but with common rootkits [2] now infecting x64 systems, this would be a worthwhile improvement.

Straying from the kernel, investigation will be conducted into the ability to detect user-mode rootkits building on the system we have already. Families like Beta Bot [17] utilize user-mode API hooking and other rootkit techniques in order to remain on system. This would be useful information to get from an automated analysis.

Finally, the reporting needs improvement in order to show where the same device is being attached to several driver objects. With more data being produced through the kernel memory scan like objects, ntoskrnl exports, we also intend to give more focus to devices.

Overall, we believe that such an automated system will provide greater visibility into the state and prevalence of rootkits in the wild. It will enhance the tracking of families and the identification of rootkit behaviour whether by clean or malicious files. It functions as a system that could flag malicious behaviour and also as an enabler to flag samples that could prove to be worthy of further investigation.

Sample clustering is not just a problem for rootkits, but for all malware, with numerous papers being penned on the subject. Identifying common behaviours and traits in large sample sets is a problem every anti-virus vendor faces. The system presented in this paper is not intended to solve sample clustering problems. However, we believe that it can serve as a platform for identifying behaviour exhibited by samples in ways that other systems cannot. For example, many rootkits will typically install a service and load a driver. This information alone cannot be relied on for clustering purposes. Our system exposes information per service and/or driver loaded, such as device names and types, that can be used to cluster samples. While the usual static and dynamic analysis methods provide a lot of data that can be used to cluster samples, the ability to access, dump, and diff areas of kernel memory gives a whole new dimension to the dataset.

Using the data exported by our system (as described in Section 2.1), it is possible to write signatures (as described in Section 2.4) which can be used to identify common traits. Clustering samples that, for example, commonly hook the same APIs, or insert devices into the device stack of the same drivers is a good way to group rootkits into the respective families.

As the next stage of this project we would like to expose the signature output to be utilized by our existing sample clustering system to increase the accuracy of clustering rootkit samples.