- IDA Pro
- Proc Mon
- Lab10-01.exe SHA256: e55cfa92acc2fac8b3b41002ebbef343bfdb61abf876e9c713f323e143d5e451
- Lab10-01.sys SHA256: d12a2c116a12993cfcf2f432a4fe53f8f6b3686e33ed8f7e8ff4628a37bd616e
- 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)
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.
1. Does this program make any direct changes to the registry? (Use procmon
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.
but this is not the case for regshot! There are some HKLM policies added to the machine.
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?
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…
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.
In the above image, we can see the address for DriverUnload. Now we just need to set breakpoint on that address as shown below.
Stepping through the functions we will see RtlCreateRegistryKey and RtlWriteRegistryValue being called.
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.
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.