If you run procmon to monitor this program, you will see that the only call to write to the registry is to
RegSetValuefor the valueHKLMSOFTWAREMicrosoftCryptographyRNGSeed. Some indirect changes are made by the calls toCreateServiceA, 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
!drvobjcommand 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
RegistryMachineSOFTWAREPoliciesMicrosoftWindowsFirewallStandardProfileandRegistryMachineSOFTWAREPoliciesMicrosoftWindowsFirewallDomainProfile. Setting these registry keys disables the Windows XP firewall.
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:WindowsSystem32Lab10-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 RegistryMachineSOFTWAREPoliciesMicrosoftWindowsFirewallStandardProfile RegistryMachineSOFTWAREPoliciesMicrosoftWindowsFirewallDomainProfile RegistryMachineSOFTWAREPoliciesMicrosoftWindowsFirewall RegistryMachineSOFTWAREPoliciesMicrosoft
These strings look a lot like registry keys, except that they start with RegistryMachine, instead of one of the usual registry root keys, such as
HKLM. When accessing the registry from the kernel, the prefix
RegistryMachine 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 HKLMSOFTWAREMicrosoftCryptographyRNGSeed. 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:WindowsSystem32Lab10-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:OpenServiceANext, 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
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_10906This 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.
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 \.pipecom_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 DriverLab10-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 "DriverLab10-01" +0x024 HardwareDatabase : 0x80670ae0 _UNICODE_STRING "REGISTRYMACHINE HARDWAREDESCRIPTIONSYSTEM" +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 0xf7c47486Having 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.