KERNEL DEBUGGING FOR MALWARE ANALYSIS

A method used to read data in kernel memory and perform analysis to detect malicious activities in memory.

Kernel Debugging

Note-The purpose of this blog is to show how we can use kernel debugging to analyse kernel malware not the full analysis of this sample.

CREATING A DRIVER

• First, the executable uses “CreateServiceA” to create a service named “Process Helper” and uses “StartServiceA” and runs a driver named “ProcHelper” as per the below screenshots.

Service Creation

Calling DeviceIoControl

• In figure 2 this sample uses “DeviceIoControl” to pass instructions to the driver to perform some tasks.
• DeviceIoControl — It's a communication method used for user-kernel communication, a user-space application can make a kernel-mode device driver perform a specific task using the “DeviceIoControl” function (by sending a code).
• Before analyzing the DeviceIoControl code, let's analyse the driver first because the driver is the one receiving the DeviceIoControl code which will inform the driver to perform a specific task.

ANALYZING DRIVER -

Device_Creation

• The driver first creates a device “\\Device\\ProcHelper\\” using “IoCreateDevice” and then creates a symbolic link for the user space program to access using “IoCreateSymbolicLink” as you can see in the below screenshot.

SymbolicLink Creation

But what is the driver doing in memory??..see below

Pre-requisites for kernel debugging -

• Host — Linux
• Created 2 VM on VirtualBox
• Debugger — Windows 7
• Debuggee — Windows XP
• Connected the 2 virtual machines using Serial Ports present in VirtualBox.

ANALYZING DRIVER IN MEMORY

Our first step is to search for the _DRIVER_OBJECT structure as it contains the Major Function table which has pointers to all the functions that it can perform.

• As we know that the device object is at “\Device\Prochelper\”, we ran the query “!devobj ProcHelper”.

_DEVICE_OBJECT

From the above result, we know that the _DRIVER_OBJCET structure is stored at 8223cda0.

• Now we run the query to see its members — “dt nt! _DRIVER_OBJECT 8223cda0”

_DRIVER_OBJECT

At offset “0x038” we have the major function table which contains pointers to all the functions that it can perform.

To see which are all the functions present- we run the query — “dd 8223CDA0+0x38 L1C”

In this table, most of the entries have the value 0x804fa87e, lets's see what this function does…

Function handling invalid requests.

0x804fa87e — It basically handles invalid request.

Looking at other entries we have — “f8c2a606” at 0x0, “f8c2a606” at 0x2 and “f8c2a666” at 0xe.

After researching on the internet, I found that for wdm.h the below offsets have the following functions -

• 0x0 — Create
• 0x2 — Close
• 0xe — DeviceIoControl

Let's examine CREATE & CLOSE first- 0xf8c2a606- it simply calls “IofCompleteRequest” telling the request has been successful.

CREATE & CLOSE

Analyzing “DeviceIoControl” at 0xf8c2a666,

We can see that first, it calls “IoGetCurrectProcess” to get access to the current process’s _EPROCESS data structure, a pointer to which will be stored in the EAX register. If we see the members of the _EPROCESS below, we know that at offset 0x88 we have ActiveProcessLinks (“_LIST_ENTRY”) which is a doubly-linked list data structure which holds 2 pointers pointing to the next and previous process so that windows or any process tracking software can traverse this doubly-linked list to list the processes running in the system.

_EPROCESS

_LIST_ENTRY

MANIPULATING DOUBLY-LINKED LIST

Further analysing the function at 0xf8c2a666, we got to know that it is manipulating a doubly-linked list.

• The instruction at (1) access the BLINK pointer which points to the previous Process.
• The instruction at (2) access the FLINK pointer which points to the next process.
• The instruction at (3) overrides the FLINK pointer of the previous process so that it points to the next Process instead of the current process.
• The next 3 instructions follow the same process except they overwrite the BLINK pointer so that it points to the Previous process instead of the current one.

Reference from “Practical Malware Analysis”

These instructions basically unlink the malware from the linked list, so when windows iterate over the linked list, it is hidden from it and can continue to do malicious activities.

Reference — “Practical Malware Analysis”.