PRACTICAL MALWARE ANALYSIS: KERNEL DEBUGGING WITH WINDBG (LAB 10-01)

Tools Used

  1. IDA Pro
  2. VirtualKD
  3. Proc Mon
  4. Regshot

Sample:

  1. Lab10-01.exe SHA256: e55cfa92acc2fac8b3b41002ebbef343bfdb61abf876e9c713f323e143d5e451
  2. Lab10-01.sys SHA256: d12a2c116a12993cfcf2f432a4fe53f8f6b3686e33ed8f7e8ff4628a37bd616e

VirusTotal:

  • Detection Rate: 7/56 (1), 4/56 (2)
  • Analyzed on 2016-03-08
  • Compilation Date: 2011-03-11 10:55:44(1), 2012-01-14 09:13:34(2)
  • View report here(1) & here(2)

Lab 10-1
This lab includes both a driver and an executable. You can run the executable
from anywhere, but in order for the program to work properly, the
driver must be placed in the C:\Windows\System32 directory where it was originally
found on the victim computer. The executable is Lab10-01.exe, and the
driver is Lab10-01.sys.
Questions
1. Does this program make any direct changes to the registry? (Use procmon
to check.)

Not really. Looking at the following figure, the only direct changes made by the malware is RNG\Seed. However if you were to look into the registries created by services.exe, we will see that it is trying to add a service.

procmon_services
Figure 1. Registry changes

but this is not the case for regshot! There are some HKLM policies added to the machine.

regshot
Figure 2. More Registry changes in Regshot

2. The user-space program calls the ControlService function. Can you set a
breakpoint with WinDbg to see what is executed in the kernel as a result
of the call to ControlService?

lab10
Figure 3. ControlService

The above figure shows the malware opening Lab10-01 service, starting the service and eventually closing it via ControlService; SERVICE_CONTROL_STOP.

breaking the kernel debugger and using the following command !object \Driver shows the loaded drivers…

objects
Figure 3. !object \Driver

SERVICE_CONTROL_STOP will call DriverUnload function. To figure out what is the address of DriverUnload function is I would first place a breakpoint on Lab10-01 Driver entry.

kd> bu Lab10_01!DriverEntry

Note that “-” is converted to “_”. Next we need to step till Lab10_01.sys is loaded. Use step out till you see this nt!IopLoadUnloadDriver+0x45.

kd> !object \Driver

to list the loaded drivers, then we use display type (dt) to display out the LAB10-01 driver.

dt
Figure 4. dt _DRIVER_OBJECT

In the above image, we can see the address for DriverUnload. Now we just need to set breakpoint on that address as shown below.

bp2
Figure 5. breakpoint unload

Stepping through the functions we will see RtlCreateRegistryKey and RtlWriteRegistryValue being called.

createkey
Figure 6. RtlCreateRegistryKey

The following image is the dissembled code of the driver in IDA Pro. Stepping the above instructions is the same as going through the instructions below.

ida pro
Figure 7. Lab10-01.sys IDA Pro

3. What does this program do?

The malware creates a service Lab10-01 that calls the driver located at “c:\windows\system32\Lab10-01.sys”. It then starts the service, executing the driver and then stops the driver causing the driver to unload itself. In the driver’s unload function the driver attempts to create and write registry key using kernel function call. The following are the registry modification made by the driver.

  • RtlCreateRegistryKey: \\Registry\\Machine\\SOFTWARE\\Policies\\Microsoft
  • RtlCreateRegistryKey: \\Registry\\Machine\\SOFTWARE\\Policies\\Microsoft\\WindowsFirewall
  • RtlCreateRegistryKey: \\Registry\\Machine\\SOFTWARE\\Policies\\Microsoft\\WindowsFirewall\\DomainProfile
  • RtlCreateRegistryKey: \\Registry\\Machine\\SOFTWARE\\Policies\\Microsoft\\WindowsFirewall\\StandardProfile
  • RtlWriteRegistryValue: \\Registry\\Machine\\SOFTWARE\\Policies\\Microsoft\\WindowsFirewall\\DomainProfile – 0 (data)
  • RtlWriteRegistryValue: \\Registry\\Machine\\SOFTWARE\\Policies\\Microsoft\\WindowsFirewall\\StandardProfile – 0 (data)

According to msdn, the above registry modifications will disable Windows Firewall for both the domain and standard profiles on the victim’s machine.

Advertisements
PRACTICAL MALWARE ANALYSIS: KERNEL DEBUGGING WITH WINDBG (LAB 10-01)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s