Lab 10-1 Solutions

Short Answers

If you run procmon to monitor this program, you will see that the only call to write to the registry is to RegSetValue for the value HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed. Some indirect changes are made by the calls to CreateServiceA, but this program also makes direct changes to the registry from the kernel that go undetected by procmon.
To set a breakpoint to see what happens in the kernel, you must open the executable within an instance of WinDbg running in the virtual machine, while also debugging the kernel with another instance of WinDbg in the host machine. When Lab10-01.exe is stopped in the virtual machine, you first use the !drvobj command to get a handle to the driver object, which contains a pointer to the unload function. Next, you can set a breakpoint on the unload function within the driver. The breakpoint will be triggered when you restart Lab10-01.exe.
This program creates a service to load a driver. The driver code then creates (or modifies, if they exist) the registry keys \Registry\Machine\SOFTWARE\Policies\Microsoft\WindowsFirewall\StandardProfile and \Registry\Machine\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile. Setting these registry keys disables the Windows XP firewall.

Detailed Analysis

We begin with some basic static analysis. Examining the executable, we see very few imports other than the standard ones included with every executable. The imports of interest are OpenSCManagerA, OpenServiceA, ControlService, StartServiceA, and CreateServiceA. These indicate the program creates a service, and probably starts and manipulates that service. There appears to be little additional interaction with the system.

The strings output reveals a few interesting strings. The first is C:\Windows\System32\Lab10-01.sys, which suggests that Lab10-01.sys probably contains the code for the service.

Examining the driver file, we see that it imports only three functions. The first function is KeTickCount, which is included in almost every driver and can be ignored. The two remaining functions, RtlCreateRegistryKey and RtlWriteRegistryValue, tell us that the driver probably accesses the registry.

The driver file also contains a number of interesting strings, as follows:

EnableFirewall
\Registry\Machine\SOFTWARE\Policies\Microsoft\WindowsFirewall\StandardProfile
\Registry\Machine\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile
\Registry\Machine\SOFTWARE\Policies\Microsoft\WindowsFirewall
\Registry\Machine\SOFTWARE\Policies\Microsoft

These strings look a lot like registry keys, except that they start with \Registry\Machine, instead of one of the usual registry root keys, such as HKLM. When accessing the registry from the kernel, the prefix \Registry\Machine is equivalent to accessing HKEY_LOCAL_MACHINE from a user-space program. An Internet search reveals that setting the EnableFirewall value to 0 disables the built-in Windows XP firewall.

Since these strings suggest that the malware writes to the registry, we open procmon to test our hypothesis. This shows several calls to functions that read the registry, but only one call to write to the registry: RegSetValue on the value HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed. This registry value is changed all the time and is meaningless for malware analysis, but since kernel code is involved, we need to make sure that the driver isn’t modifying the registry covertly.

Next, we open the executable, navigate to the main function shown in Example C-22, and see that it makes only four function calls.

Example C-22. main method of Lab10-01.exe

00401004   push    0F003Fh           ; dwDesiredAccess
00401009   push    0                 ; lpDatabaseName
0040100B   push    0                 ; lpMachineName
0040100D  ❶call    ds:OpenSCManagerA ; Establish a connection to the service
0040100D                             ; control manager on the specified computer
0040100D                             ; and opens the specified database
00401013   mov     edi, eax
00401015   test    edi, edi
00401017   jnz     short loc_401020
00401019   pop     edi
0040101A   add     esp, 1Ch
0040101D   retn    10h
00401020 loc_401020:
00401020   push    esi
00401021   push    0               ; lpPassword
00401023   push    0               ; lpServiceStartName
00401025   push    0               ; lpDependencies
00401027   push    0               ; lpdwTagId
00401029   push    0               ; lpLoadOrderGroup
0040102B  ❸push    offset BinaryPathName ; "C:\\Windows\\System32\\Lab10-01.sys"
00401030   push    1               ; dwErrorControl
00401032  ❹push    3               ; dwStartType
00401034   push    1               ; dwServiceType
00401036   push    0F01FFh         ; dwDesiredAccess
0040103B   push    offset ServiceName ; "Lab10-01"
00401040   push    offset ServiceName ; "Lab10-01"
00401045   push    edi             ; hSCManager
00401046  ❷call    ds:CreateServiceA

First, it calls OpenSCManagerA at ❶ to get a handle to the service manager, and then it calls CreateServiceA at ❷ to create a service called Lab10-01. The call to CreateServiceA tells us that the service will use code in C:\Windows\System32\Lab10-01.sys at ❸ and that the service type is 3 at ❹, or SERVICE_KERNEL_DRIVER, which means that this file will be loaded into the kernel.

If the call to CreateServiceA fails, the code calls OpenServiceA with the same service name, as shown in Example C-23 at ❶. This opens a handle to the Lab10-01 service if the CreateServiceA call failed because the service already existed.

Example C-23. Call to OpenServiceA to get a handle to the service for Lab10-01

00401052   push    0F01FFh            ; dwDesiredAccess
00401057   push    offset ServiceName ; "Lab10-01"
0040105C   push    edi                ; hSCManager
0040105D  ❶call    ds:OpenServiceA

Next, the program calls StartServiceA to start the service, as shown in Example C-24 at ❶. Finally, it calls ControlService at ❷. The second parameter to ControlService is what type of control message is being sent. In this case, the value is 0x01 at ❸, which we look up in the documentation and find that it means SERVICE_CONTROL_STOP. This will unload the driver and call the driver’s unload function.

Example C-24. Call to ControlService from Lab10-01.exe

00401069   push    0               ; lpServiceArgVectors
0040106B   push    0               ; dwNumServiceArgs
0040106D   push    esi             ; hService
0040106E  ❶call    ds:StartServiceA
00401074   test    esi, esi
00401076   jz      short loc_401086
00401078   lea     eax, [esp+24h+ServiceStatus]
0040107C   push    eax             ; lpServiceStatus
0040107D  ❸push    1               ; dwControl
0040107F   push    esi             ; hService
00401080  ❷call    ds:ControlService ; Send a control code to a Win32 service

Viewing Lab10-01.sys in IDA Pro

Before we try to analyze the driver with WinDbg, we can open the driver in IDA Pro to examine the DriverEntry function. When we first open the driver and navigate to the entry point, we see the code in Example C-25.

Example C-25. Code at the entry point of Lab10-01.sys

00010959  mov      edi, edi
0001095B  push     ebp
0001095C  mov      ebp, esp
0001095E  call     sub_10920
00010963  pop      ebp
00010964  jmp     ❶sub_10906

This function is the entry point of the driver, but it’s not the DriverEntry function. The compiler inserts wrapper code around the DriverEntry. The real DriverEntry function is located at sub_10906 ❶.

As shown in Example C-26, the main body of the DriverEntry function appears to move an offset value into a memory location, but otherwise it doesn’t make any function calls or interact with the system.

Example C-26. The DriverEntry routine for Lab10-01.sys

00010906  mov     edi, edi
00010908  push    ebp
00010909  mov     ebp, esp
0001090B  mov     eax, [ebp+arg_0]
0001090E  mov     dword ptr [eax+34h], offset loc_10486
00010915  xor     eax, eax
00010917  pop     ebp
00010918  retn    8

Analyzing Lab10-01.sys in WinDbg

Now, we can use WinDbg to examine Lab10-01.sys to see what happens when ControlService is called to unload Lab10-01.sys. The code in the user-space executable loads Lab10-10.sys and then immediately unloads it. If we use the kernel debugger before running the malicious executable, the driver will not yet be in memory, so we won’t be able to examine it. But if we wait until after the malicious executable is finished executing, the driver will already have been unloaded from memory.

In order to analyze Lab10-01.sys with WinDbg while it is loaded in memory, we’ll load the executable into WinDbg within the virtual machine. We set a breakpoint between the time that the driver is loaded and unloaded, at the ControlService call, with the following command:

0:000> bp 00401080

Then we start the program and wait until the breakpoint is hit. When the breakpoint is hit, we are presented with the following information in WinDbg:

Breakpoint 0 hit
eax=0012ff1c ebx=7ffdc000 ecx=77defb6d edx=00000000 esi=00144048 edi=00144f58
eip=00401080 esp=0012ff08 ebp=0012ffc0 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
image00400000+0x1080:

Once the program is stopped at the breakpoint, we move out of the virtual machine in order to connect the kernel debugger and get information about Lab10-01.sys. We open another instance of WinDbg and select File ▸ Kernel Debug with pipe set to \\.\pipe\com_1 and a baud rate of 115200 to connect the instance of WinDbg running in the host machine to the kernel of the guest machine. We know that our service is called Lab10-01, so we can get a driver object by using the !drvobj command, as shown in Example C-27.

Example C-27. Locating the device object for Lab10-01

kd> !drvobj lab10-01
Driver object  ❶ (8263b418) is for:
Loading symbols for f7c47000     Lab10-01.sys ->   Lab10-01.sys
*** ERROR: Module load completed but symbols could not be loaded for Lab10-01.sys
 \Driver\Lab10-01
Driver Extension List: (id , addr)

Device Object list: ❷

The output of the !drvobj command gives us the address of the driver object at ❶. Because there are no devices listed in the device object list at ❷, we know that this driver does not have any devices that are accessible by user-space applications.

Note

To resolve any difficulty locating the service name, you can get a list of driver objects currently in the kernel with the !object \Driver command.

Once we have the address of the driver object, we can view it using the dt command, as shown in Example C-28.

Example C-28. Viewing the driver object for Lab10-01.sys in WinDbg

kd> dt _DRIVER_OBJECT 8263b418
nt!_DRIVER_OBJECT
   +0x000 Type             : 4
   +0x002 Size             : 168
   +0x004 DeviceObject     : (null)
   +0x008 Flags            : 0x12
   +0x00c DriverStart      : 0xf7c47000
   +0x010 DriverSize       : 0xe80
   +0x014 DriverSection    : 0x826b2c88
   +0x018 DriverExtension  : 0x8263b4c0 _DRIVER_EXTENSION
   +0x01c DriverName       : _UNICODE_STRING "\Driver\Lab10-01"
   +0x024 HardwareDatabase : 0x80670ae0 _UNICODE_STRING "\REGISTRY\MACHINE\
                             HARDWARE\DESCRIPTION\SYSTEM"
   +0x028 FastIoDispatch   : (null)
   +0x02c DriverInit       : 0xf7c47959     long  +0
   +0x030 DriverStartIo    : (null)
   +0x034 DriverUnload     :  ❶0xf7c47486     void  +0
   +0x038 MajorFunction    : [28] 0x804f354a     long  nt!IopInvalidDeviceRequest+0

We’re trying to identify the function called when the driver is unloaded—information at offset 0x034, DriverUnload, as shown at ❶. Then we set a breakpoint using the following command:

kd> bp 0xf7c47486

Having set the breakpoint, we resume running our kernel. Then we return to the version of WinDbg running on the executable on our virtual machine and resume it as well. Immediately, the entire guest OS freezes because the kernel debugger has hit our kernel breakpoint. At this point, we can go to the kernel debugger to step through the code. We see that the program calls the RtlCreateRegistryKey function three times to create several registry keys, and then calls the RtlWriteRegistryValue twice to set the EnableFirewall value to 0 in two places. This disables the Windows XP firewall from the kernel in a way that is difficult for security programs to detect.

If the unload function at 0xf7c47486 were long or complex, it would have been difficult to analyze in WinDbg. In many cases, it’s easier to analyze a function in IDA Pro once you have identified where the function is located, because IDA Pro does a better job of analyzing the functions. However, the function location in WinDbg is different than the function location in IDA Pro, so we must perform some manual calculations in order to view the function in IDA Pro. We must calculate the offset of the function from the beginning of the file as it is loaded in WinDbg using the lm command, as follows:

kd> lm
start      end        module name
...
f7c47000❶  f7c47e80   Lab10_01   (no symbols)
...

As you can see, the file is loaded at 0xf7c47000 at ❶, and from earlier, we know the unload function is located at 0xf7c47486. We subtract 0xf7c47000 from 0xf7c47486 to get the offset (0x486), which we then use to navigate to the unload function in IDA Pro. For example, if the base load address in IDA Pro is 0x00100000, then we navigate to address 0x00100486 to find the unload function in IDA Pro. We can then use static analysis and IDA Pro to confirm what we discovered in WinDbg.

Alternatively, we can change the base address in IDA Pro by selecting Edit ▸ Segments ▸ Rebase Program and changing the base address value from 0x00100000 to 0xf7c47000.

Note

If you tried to use a deferred breakpoint using the bu $iment(Lab10-01), you may have run into trouble because WinDbg changes hyphens to underscores when it encounters them in filenames. The correct command to break on the entry point of the driver in this lab would be bu $iment(Lab10_01). This behavior is not documented anywhere and may be inconsistent across versions of WinDbg.

Table of Contents for Practical Malware Analysis

Lab 10-1 Solutions

Short Answers

Detailed Analysis

Viewing Lab10-01.sys in IDA Pro

Analyzing Lab10-01.sys in WinDbg

Note

Note

Table of Contents for
Practical Malware Analysis