Thursday, October 30, 2014

Last night I took a quick look at BlackEnergy 2, a rootkit that surfaced in 2010. BlackEnergy 2 was essentially a rewrite of its predecessor as BlackEnergy 2 contains rootkit techniques, process-injection, and encryption. Surprisingly for being a now 'dated' rootkit, there's really not too much accessible (or not buried) reverse kernel-debugging documentation for the rootkit aside from when it was first surfacing. A lot of misc. information pops up throughout very few blogs/forums that are Russian, but that's about it.

There's a lot of additional lore behind the rootkit, but I really won't go into that. If you're interested about where the rootkit core came from before it was implemented into BlackEnergy 2, BlackReleaver is the answer!

!chkimg compares the current loaded executable with the version within the symbol store. This is a helpful command to detect corruptions with images, and especially helpful when dealing with rootkits. The -d parameter displays a summary of all mismatched areas. The -v parameter makes the information verbose. In this case, the -v parameter is optional.

As noted above, we have two out-of-range values. We're interested in disassembling nt!KiBBTUnexpectedRange+8, but not nt!KeInsertQueueApc (+0x6c47). nt!KeInsertQueueApc (+0x6c47) as I commented above is in relation to the Chameleon technology from Malwarebytes. I had MWB ARK installed on this VM for testing purposes, so that is where it was spawning from.

nt!KiBBTUnexpectedRange+8 Disassembly - Healthy

If we disassemble nt!KiBBTUnexpectedRange+8 on a system not infected with BlackEnergy 2, we should expect similar results:

So, why do we have corruptions in ntoskrnl and a corrupted nt!KiBBTUnexpectedRange+8 output? It's a side effect of the rootkit creating additional 'fake' service tables. It does this by patching the ETHREAD SystemTable pointer, which allows for things such as user threads to be patched, thread creation notification and service table pointer updating by using PsSetCreateThreadNotifyRoutine, etc.

The main use behind creating fake service tables is it gives anti-rootkit software a much harder time (harder back in 2010, at least) detecting its presence. It doesn't just 'hook' and/or modify the SSDT (which as we know would be a big red flag), it instead creates its own fake service tables, and then hooks (acquires?) the following functions:

Given we're adding new/fake service tables, we need applications to be able to access them. This is done by using pointers as discussed above, which is accomplished in the KTHREAD Structure. Every single thread has a pointer to a ServiceTable which is ultimately set by KeInitThread. Additionally, if the thread requires GUI functions within the Shadow SSDT, PsConvertToGuiThread is called.

If we however use a 3rd party registry tool (any will probably work so long as it doesn't use Windows API calls):

We catch our culprit and the dropped driver red-handed. The driver renames after each reboot, so if you remove it and don't get the driver+registry entry at once, it'll just re-create with a different name.

Friday, October 10, 2014

Here we are, part two! I thought rather than doing a live debugging of runtime2 as I discussed in my last rootkit debugging post, I'd debug a different rootkit. I chose Rustock.B (PE386) as it's a pretty notorious rootkit, and in my opinion is a lot of fun to debug. It's always a great learning experience to debug, reverse, and research things for yourself as well. I have a map of rootkits I want to debug and reverse as the weeks go by, so expect many more of these.

Let's get started!

First off, before we get into the fun debugging/reversal, what do we know about Rustock? We know a lot! It's a fairly dated rootkit, and has been reversed time and time again by researchers, etc. It's a great example to use when showing some of the neat things a rootkit can do. It was originally developed to distribute spam email, which was way back in the day. It was first discovered in 2006, and began to increase by a significant number in 2008. By mid 2010, it was one of the most known rootkit related threats (and arguably malware in general).

Rustock has three encrypted components which we will discuss below, one at a time:

Dropper Component

The dropper is the bad guy, the guy nobody likes. Malware droppers have one primary job, and it's once they are executed, install the specified malware. Malware writers can have their droppers do other things however, which Rustock's of course does. They are called droppers because they essentially 'drop' the malware onto the target system.

Rustock's dropper runs specifically in user-mode, and decrypts/drops the rootkit component driver (our 3rd component that we will discuss later on). Interestingly enough, during the rootkit's time period of prevalence, the dropper also went ahead and contacted a Command and Control (C&C) Server to check for updates. C&C's have different structures, all of which are different. In most cases however, especially in its most basic definition, C&C's are used to send commands and receive outputs of machines part of a botnet.

In addition to contacting a C&C server, thedropper component also checks the registry to ensure that a previous Rustock infection hasn't already taken place so reinfection (which could cause obvious problems) doesn't happen. It checks the registry as there are keys which are installed when an infection takes place, such as PE386 (the key used to survive a reboot among other things).

Driver Installer Component

Our second component is the driver installer, which runs in kernel-mode as a disguised Windows system driver (textbook rootkit behavior). It historically replaces drivers such as beep.sys as well as null.sys with a copy, and then afterwards replaces it once started. If however this replacement method is unsuccessful, it falls back to a method I've seen occur much more, which the dropper will instead use a randomly-generated or hard-coded filename for the driver.

Two hard-coded filenames have been glaide32.sys and lzx32.sys, with the latter being the most popular. As far as randomly-generated filenames go, 7005d59.sys was the most typical. Older versions of the rootkit would install themselves to null shares to hide in a system driver, and then proceed to drop the installer as an alternate data stream (ADS) (%Windir%\System32:lzx32.sys, for example). Modern versions of the rootkit however use system service hooking.

Rootkit Driver Component

Our third and final component is the rootkit driver, which runs in kernel-mode like the driver installer. As we discussed above regarding our first component, this component is decrypted by the dropper which then allows the rootit driver to inject a copy of its decrypted code into itself before transferring control over to the newly instantiated copy. The decryption process is accomplished inside a buffer allocated in kernel memory by using ExAllocatePool. It specifically contains the code managing the backdoor functionality, such as the actual ability to contact the C&C server discussed above, and executing instructions sent by Rustock operators.

The kernel-mode side of the rootkit communicates with its user-mode bot component (C&C, etc) using INT 2Eh interrupts for NT/2k (a bit different for XP), which will be shown in action coming up. Aside from communication, the rootkit component hid itself by hooking different SSDT functions such as:

It hid its network/disk operations by hooking ntoskrnl.dll and ntdll.dll functions, as well as various network drivers such as:

tcpip.sys

wanarp.sys

ndis.sys

It hooked the following network drivers to bypass firewalls and manipulate packets.

In addition to the INT 2Eh interrupts being shown in action, I'll also be showing all of the various hooking, etc.

Now that we've gotten some of the history and information out of the way, let's start with the debugging and reversal of the rootkit.

Rootkit Debugging/Reversal

I had to go through a few hoops to create an environment in which Rustock.B could be properly examined. It wasn't unfortunately as simple as executing it on an XP VM, although it wasn't excruciatingly painful to set up either. Also, for any amateur malware analysts who get curious (like me) and try to execute Rustock on Windows 7 x86 to see what will happen, it throws an access violation : ) Nothing too cool, unfortunately! I have however read reports saying it runs on the beta of Vista.

After I had the basics done (isolated from host network, etc), I had to make three changes to get the rootkit to properly execute on an XP SP2 guest:

1. Disable both Physical Address Extension (PAE) and Data Execution Prevention (DEP). This is easily done by modifying the boot.ini to look like the following:

/execute parameter is another way of saying /noexecute=alwaysoff, which disables DEP and PAE.

/fastdetect parameter disables detection on all serial and parallel ports. It's not necessary in this case by any means, but it does allow for a slightly faster boot time. It's just a habit from the XP days : )

/NUMPROC=1 and NUMPROC=4 are almost self-explanatory, really. This parameter limits the OS when it boots to either 1 core or 4 cores. In our case, Rustock (afaik) cannot execute on anything more than 2 cores, so I went with 1 for safety (thanks EP_X0FF). Here's what it looks like at the boot selection screen:

One of the first few things Rustock does as discussed above is create a registry subkey associated with a hidden service known as pe386. By using SwishDbgExt as we've used many times before in my blog posts, we can dump the list of services on the system using the !ms_services command:

As we can see, this successfully shows us our hidden service, and notes it is in fact running. With this said, we can confirm infection was a success.

As we discussed above, older versions of Rustock use alternate data streams (ADS). It goes one step further and prevents access from NTFS.sys (NT File System driver) or FASTFAT.sys (FAT File System driver), therefore they cannot directly communicate with the files in the data stream. It does this by hooking various file system related IRP functions that control create/delete operations regarding the ADS stream. Rustock often hooks IoCallDriver, which sends an IRP to certain drivers. We can the act of filtering in action here:

The poi operator is used so when the parameter contains IofCallDriver, WinDbg will break at the specified address.

lkd> !address f6fb9dae
address f6fb9dae not found in any known Kernel Address Range ----

The !address command is used afterwards on the SP to show memory region usage and attributes.

Rustock hooks IA32_SYSENTER_EIP (0x176) for XP (remember, INT 2Eh interrupts for NT/2k), which is the kernel's EIP for SYSENTER. SYSENTER is an Intel instruction which enables fast entry to the kernel, avoiding interrupt overhead. AMD's version is known as SYSCALL, which overall does the same thing, although operates a bit differently. In any case, as I discussed earlier in the post, this is what Rustock uses to communicate between user-mode and kernel-mode. It's also ultimately hooked to execute code every time a system call is made.

As we have a modified SYSENTER handler, this is where SSDT functions labeled above come into play. This was done to intercept system calls on a thread-level basis rather than using KeServiceDescriptorTable to hook on a global basis.

1. ZwOpenKey's API was modified so that whenever anything but services.exe tried to obtain a handle, it'd return STATUS_OBJECT_NAME_NOT_FOUND. This was done to prevent unauthorized access to the pe386 key.

2. ZwCreateKey's API was modified similarly to that of OpenKey, which is when any other process other than services.exe tries to create a key named pe386, CreateKey returns the same error as OpenKey.

3.ZwQuerySystemInformation's API was modified to zero out the usage time in kernel and user mode for services.exe, and adds it to the first process in the processes list (sysidle process). This was primarily done to counteract if a user were to check services.exe with Process Explorer, as it would raise red flags.

We can check for the 0x176 hook manually and automatically using a script. Let's first view the manual way:

lkd> rdmsr 0x176
msr[176] = 00000000`806ccc3d

The rdmsr command is used to view the state of a model-specific register (MSR).

Using our familiar !address command, we can see that to avoid easy hook detection, Rustock has the EIP address point to the same module as KiFastCallEntry (ntoskrnl.exe, or another variation of the NT Kernel). I've seen ntkrnlpa.exe as well.

dc is actually a parameter to show ASCII characters and dwords. d* on its own simply means 'display memory'. I've discussed this command in a previous blog post, but I believe it was dd that I used in that scenario. dd is the same as dc, except it doesn't display ASCII characters.

By using this command on the 0x176 MSR address, this is where we can see Rustock replaced the FATAL_UNHANDLED_HARD_ERROR string with malicious code that's ultimately used to execute various functions of the rootkit. Hilariously enough, the original meaning of this string is a bug check code (0x4C).

We can see where it performs a jump to its malicious code by further disassembling the MSR address. Unfortunately I forgot to bring the .txt file containing the WinDbg code, so I loaded up a snapshot and did the disassembly real quick to show in an image:

Now that we've seen how to manually view the 0x176 hook manually, let's view it automatically using another tool we've used before, the SysecLabs script:

As mentioned earlier above, Rustock also hooks INT 2Eh to communicate between its user and kernel mode components. This is done specifically for older systems/hardware that don't support SYSENTER fastcalls, as KiSystemService is a user mode functions dispatcher and handler. We can see the hook here:

These days, the removal of Rustock is extremely trivial. When I ran GMER, Rustock would cause it to hang inevitably. I imagined this would occur, even with the random .exe name. However, I tried something strange out of curiosity and it ended up working, which was to run as owner. Before it successfully scanned however without hanging interruptions, here's what it displayed:

After pressing 'OK' for both, GMER successfully scanned. Here were the results:

We can see GMER detected the rootkit without too much issue, and we can also see our best friend pe386.

Removal was pretty painless, all I had to do was kill and delete the service by right-clicking it within GMER, and also ridding of the process, library, and module. After a restart was completed, performing a live debugging showed completely opposite (and normal) results. I will show them below, one at a time.