Cremes rootkit scan
In August of this year, we published information about a new state-sponsored malware called Cremes (aka Remsec). ESET antivirus products detect its components as Win32 / Cremes and Win64 / Cremes . Cremes is a sophisticated trojan with a variety of components that are used for cyber espionage. Information about Cremes was also published by experts from the Federal Security Service (FSB), since Cremes was used for cyber espionage by government officials.
Cremes includes the Ring 0 component (rootkit), which is used by attackers as an LPE gateway (kernel gate) for executing its code in kernel mode. Unlike such well-known rootkits and bootkits like ZeroAccess, TDL4, Mebroot, Gapz and others, Cremes does not burden itself with complicated procedures for compromising the MBR and early stages of loading the NT kernel to execute its Ring 0 code in the system bypassing DSE, instead It uses legitimate drivers for this.
Cremes authors resorted to using two plugins with the names kgate and xkgate for placing Ring 0 code there. We managed to find timestamps inside both plugins that indicate the date the plugins were developed and were used by the authors for debugging purposes. According to these tags, the authors resorted to developing xkgate later than kgate . The validity of the date in xkgate is also confirmed by the time stamp from the header of the PE file (although they differ by one day).
Fig. Timestamps inside both plugins
')
The kgate plugin is used as an installer to the Ring 0 code system on both 32-bit and 64-bit versions of Windows. For a 32-bit system, kgate uses the functions of the Agnitum Sandbox.sys driver, which allows using a special IOCTL request to load the rootkit driver into the system. To do this, the plugin extracts the Sandbox.sys driver from its body (the .rdata section) and writes it to disk, after which it forms a PE file for its malicious Ring 0 code and writes it to the aswfilt.dll file. Below are the properties of this driver.
Fig. The plugin resets the Agnitum Sandbox.sys driver to the file system, creates its service in the registry and loads it into memory for later use.
Fig. The plugin generates the rootkit file, writes it to the registry and tells Sandbox.sys to download the driver.
The answer to the question why the authors needed to write the contents of the rootkit in the aswfilt.dll file is covered in the Sandbox.sys driver. If we look at its code, we will see a link to it inside the driver.
Fig. Link to aswfilt.dll inside the legitimate Sandbox.sys driver.
After a little analysis of the Sandbox.sys code, we managed to find that the link to this file inside the driver is related to the IOCTL code that the plugin sends to the driver. The peculiarity lies in the fact that aswfilt.dll is the name of the Agnitum plug-in, which the Sandbox.sys driver can load into memory after the IOCTL code has been sent to it.
Fig. When processed by the IOCTL code driver, it checks the file name and loads it into system memory using the ZwLoadDriver kernel API .
The rootkit is used by the kgate plugin for only one purpose - the execution of the function specified in the user mode in kernel mode with SMEP bypass. To communicate with the client, the rootkit creates a device object \ Device \ rwx , while the client uses the path \\. \ GLOBALROOT \ Device \ rwx to open the device. To disable SMEP and execute the feature, the client sends Ring 0 to the IOCTL code with the code 0x1173000C.
Fig. The rootkit disables SMEP for executing the function from user mode, while first assigning the thread to the current processor.
The following structure is used by the rootkit as the context (DeviceObject-> DeviceExtension).
The driver uses an interesting procedure for unloading by timer and allows the client to set the waiting interval from the user mode. To do this, the driver creates a separate system thread, which waits on the timer and in case of time expires, calls the ZwUnloadDriver function. Unloading the driver from its own code may not be performed correctly, since the stream may return to a non-existent page of memory.
Fig. The fnCreateDriverRegKeyOrRemoveIt function deletes the driver service and unloads it using ZwLoadDriver .
Below is the structure of the plug-in executable.
Fig. Plugin PE file structure kgate .
The name of the xkgate plugin can be interpreted as extended kgate , i.e. extended kgate . Unlike its predecessor, it does not have a 32-bit version on board, but is designed only for a 64-bit version of Windows. The table below shows a comparison of the capabilities of both plugins.
Below is information about the digital signatures of the used AV product drivers by Cremes.
Fig. Digital signatures of drivers Avast and Agnitum.
As you can see, both plugins contain identical code in sections with 64-bit code krwkr64 and krdrv64. To download this Ring 0 code, the Cremes authors chose another victim - the Avast driver. The operation of this driver is more difficult than the driver Agnitum, consider it in more detail.
The first thing that xkgate does to load the Ring 0 code is to create a special mutex to prevent re-loading the Avast driver into memory (a function).
Fig. Code to open / create mutex.
After this, the code calls the fnDropAvastDriverAndPrepareEnv function, which performs the following actions.
Fig. Call fnDropAvastDriverAndPrepareEnv function inside fnLoadAvast .
After that, fnLoadAvast calls fnCreateAvastServiceAndLoadDriver to create a registry key for Avast. Below are the actions taken.
After the aswSnx.sys is loaded, fnLoadAvast deletes the snxhk.dll and snxhk64.dll files with NtSetInformationFile . Next, the function creates a process called aswSnx.exe, which is notepad.exe. After this, a handle to the Avast device with the name \ Device \ aswSnx is created .
Fig. The pseudo creation function is aswSnx.exe.
After creating the aswSnx.exe process with the starting thread stopped, the function duplicates the open descriptor on the device \ Device \ aswSnx from the plugin process to the new aswSnx.exe process. Further, there is also copied a special code from the section of the .avit plugin, which is responsible for interaction with the Avast driver. It performs the function DeviceIoControl , which leads to the execution of malicious Ring 0 code.
Fig. The function of the driver Avast.
The following are the characteristics of the downloadable Ring 0 code.
To simplify the analysis, consider an identical 32-bit version of the Ring 0 code, which is stored in the kgate plugin.
Since the kernel mode code is not loaded by the Windows kernel itself and does not constitute a full-fledged driver file, a driver object has not been created for the loaded code, which must be passed to it through the DriverEntry . Therefore, the first thing a rootkit does is create a driver object for itself with ObCreateObject .
Fig. The function of creating a driver object and inserting it into the Windows system queue via the undocumented ObInsertObject function.
In order to process the DeviceControl request, the driver registers the handler IRP_MJ_DEVICE_CONTROL, which is not standard in such cases, and instead uses the DriverObject-> FastIoDispatch.FastIoDeviceControl fast I / O function.
Fig. The registration function DriverObject-> FastIoDispatch.FastIoDeviceControl.
This handler function is used only to execute the code required by the client in kernel mode.
Fig. Handler Fast I / O rootkit.
The methods used by the authors of Cremes for loading the rootkit into memory are really interesting, since they use the legitimate drivers of the kernel mode of the antivirus products. Unlike other well-known rootkits, Cremes is not interested in intercepting any API calls or system operations to hide its activity in the system. Instead, the authors were simply interested in the possibility of guaranteed execution of their code in kernel mode, i.e., increasing their privileges in the system. Using the approach they use, this technique is quite successful.
Cremes includes the Ring 0 component (rootkit), which is used by attackers as an LPE gateway (kernel gate) for executing its code in kernel mode. Unlike such well-known rootkits and bootkits like ZeroAccess, TDL4, Mebroot, Gapz and others, Cremes does not burden itself with complicated procedures for compromising the MBR and early stages of loading the NT kernel to execute its Ring 0 code in the system bypassing DSE, instead It uses legitimate drivers for this.
Cremes authors resorted to using two plugins with the names kgate and xkgate for placing Ring 0 code there. We managed to find timestamps inside both plugins that indicate the date the plugins were developed and were used by the authors for debugging purposes. According to these tags, the authors resorted to developing xkgate later than kgate . The validity of the date in xkgate is also confirmed by the time stamp from the header of the PE file (although they differ by one day).
Fig. Timestamps inside both plugins
')
Kgate plugin
The kgate plugin is used as an installer to the Ring 0 code system on both 32-bit and 64-bit versions of Windows. For a 32-bit system, kgate uses the functions of the Agnitum Sandbox.sys driver, which allows using a special IOCTL request to load the rootkit driver into the system. To do this, the plugin extracts the Sandbox.sys driver from its body (the .rdata section) and writes it to disk, after which it forms a PE file for its malicious Ring 0 code and writes it to the aswfilt.dll file. Below are the properties of this driver.
- It has a compact size and can fit on one page of virtual memory (4KB).
- Since the PE file itself is generated on the fly, it does not have a timestamp in the PE header. It also has one nameless NONPAGED section with code and driver data.
- The driver uses dynamically loaded imports and stores them in a special structure DeviceObject-> DeviceExtension.
- The driver uses the obfuscation of offsets within the code.
- In terms of coding, the driver is written by qualified authors.
Fig. The plugin resets the Agnitum Sandbox.sys driver to the file system, creates its service in the registry and loads it into memory for later use.
Fig. The plugin generates the rootkit file, writes it to the registry and tells Sandbox.sys to download the driver.
The answer to the question why the authors needed to write the contents of the rootkit in the aswfilt.dll file is covered in the Sandbox.sys driver. If we look at its code, we will see a link to it inside the driver.
Fig. Link to aswfilt.dll inside the legitimate Sandbox.sys driver.
After a little analysis of the Sandbox.sys code, we managed to find that the link to this file inside the driver is related to the IOCTL code that the plugin sends to the driver. The peculiarity lies in the fact that aswfilt.dll is the name of the Agnitum plug-in, which the Sandbox.sys driver can load into memory after the IOCTL code has been sent to it.
Fig. When processed by the IOCTL code driver, it checks the file name and loads it into system memory using the ZwLoadDriver kernel API .
The rootkit is used by the kgate plugin for only one purpose - the execution of the function specified in the user mode in kernel mode with SMEP bypass. To communicate with the client, the rootkit creates a device object \ Device \ rwx , while the client uses the path \\. \ GLOBALROOT \ Device \ rwx to open the device. To disable SMEP and execute the feature, the client sends Ring 0 to the IOCTL code with the code 0x1173000C.
Fig. The rootkit disables SMEP for executing the function from user mode, while first assigning the thread to the current processor.
The following structure is used by the rootkit as the context (DeviceObject-> DeviceExtension).
struct RootkitStruct {
PVOID ExAllocatePool;
PVOID ExFreePool;
PVOID IoCompleteRequest;
PVOID IoCreateDevice;
PVOID IoDeleteDevice;
PVOID KeAcquireSpinLock;
PVOID KeCancelTimer;
PVOID KeInitializeEvent;
PVOID KeInitializeSpinLock;
PVOID KeInitializeTimer;
PVOID KeQueryInterruptTime;
PVOID KeReleaseSpinLock;
PVOID KeSetEvent;
PVOID KeSetTimer;
PVOID KeWaitForMultipleObjects;
PVOID ObfReferenceObject;
PVOID ObDereferenceObject;
PVOID PsCreateSystemThread;
PVOID PsGetVersion;
PVOID PsTerminateSystemThread;
PVOID ZwClose;
PVOID ZwCreateKey;
PVOID ZwDeleteKey;
PVOID ZwEnumerateKey;
PVOID ZwOpenKey;
PVOID ZwSetValueKey;
PVOID ZwUnloadDriver;
PVOID KeQueryActiveProcessors;
PVOID KeSetSystemAffinityThread;
PVOID KeRevertToUserAffinityThread;
ULONG Flag;
KEVENT Event;
ULONG dwField1;
KTIMER Timer;
KSPIN_LOCK SpinLock;
ULONG dwField2;
LARGE_INTEGER IntervalTime;
UNICODE_STRING unDriverRegistryPath;
};
The driver uses an interesting procedure for unloading by timer and allows the client to set the waiting interval from the user mode. To do this, the driver creates a separate system thread, which waits on the timer and in case of time expires, calls the ZwUnloadDriver function. Unloading the driver from its own code may not be performed correctly, since the stream may return to a non-existent page of memory.
Fig. The fnCreateDriverRegKeyOrRemoveIt function deletes the driver service and unloads it using ZwLoadDriver .
Below is the structure of the plug-in executable.
Fig. Plugin PE file structure kgate .
Xkgate plugin
The name of the xkgate plugin can be interpreted as extended kgate , i.e. extended kgate . Unlike its predecessor, it does not have a 32-bit version on board, but is designed only for a 64-bit version of Windows. The table below shows a comparison of the capabilities of both plugins.
Below is information about the digital signatures of the used AV product drivers by Cremes.
Fig. Digital signatures of drivers Avast and Agnitum.
As you can see, both plugins contain identical code in sections with 64-bit code krwkr64 and krdrv64. To download this Ring 0 code, the Cremes authors chose another victim - the Avast driver. The operation of this driver is more difficult than the driver Agnitum, consider it in more detail.
The first thing that xkgate does to load the Ring 0 code is to create a special mutex to prevent re-loading the Avast driver into memory (a function).
Fig. Code to open / create mutex.
After this, the code calls the fnDropAvastDriverAndPrepareEnv function, which performs the following actions.
- Creates the \ SystemRoot \ Temp \ aswSnx directory where it writes the Avast files.
- Resets the aswSnx.sys file to the file system.
- Dumps the snx_lconfig.xml file system
- It also pulls out snx_gconfig.xml.
- Creates an empty snxhk.dll file.
- Creates an aswSnx.exe file and writes the contents of notepad.exe to it.
Fig. Call fnDropAvastDriverAndPrepareEnv function inside fnLoadAvast .
After that, fnLoadAvast calls fnCreateAvastServiceAndLoadDriver to create a registry key for Avast. Below are the actions taken.
- Creates the System \ CurrentControlSet \ Services \ aswSnx registry key.
- Creates an ImagePath parameter in it with the value \ SystemRoot \ Temp \ aswSnx \ aswSnx.sys.
- Creates a Type parameter.
- Creates a subsection Parameters.
- Creates a DataFolder parameter in it with the value \ ?? \ Global \ GLOBALROOT \ SystemRoot \ Temp \ aswSnx.
- Creates a ProgramFolder parameter with the value \ ?? \ Global \ GLOBALROOT \ SystemRoot \ Temp \ aswSnx.
- Creates an Instances subsection.
- Creates a subkey DefaultInstance in it.
- Creates Altitude and Flags parameters in it.
- Downloads aswSnx.sys using NtLoadDriver .
After the aswSnx.sys is loaded, fnLoadAvast deletes the snxhk.dll and snxhk64.dll files with NtSetInformationFile . Next, the function creates a process called aswSnx.exe, which is notepad.exe. After this, a handle to the Avast device with the name \ Device \ aswSnx is created .
Fig. The pseudo creation function is aswSnx.exe.
After creating the aswSnx.exe process with the starting thread stopped, the function duplicates the open descriptor on the device \ Device \ aswSnx from the plugin process to the new aswSnx.exe process. Further, there is also copied a special code from the section of the .avit plugin, which is responsible for interaction with the Avast driver. It performs the function DeviceIoControl , which leads to the execution of malicious Ring 0 code.
Fig. The function of the driver Avast.
The following are the characteristics of the downloadable Ring 0 code.
- It has a compact size and fits in one page of virtual memory.
- Uses dynamic imports, which are also stored in the device context.
- The kgate plugin has a 32-bit counterpart of this code.
- Does not contain the DriverEntry function.
- Executes client-requested code through the FastIoDeviceControl fast DeviceControl (Fast I / O) mechanism.
- Uses undocumented features of the Windows kernel.
To simplify the analysis, consider an identical 32-bit version of the Ring 0 code, which is stored in the kgate plugin.
Since the kernel mode code is not loaded by the Windows kernel itself and does not constitute a full-fledged driver file, a driver object has not been created for the loaded code, which must be passed to it through the DriverEntry . Therefore, the first thing a rootkit does is create a driver object for itself with ObCreateObject .
Fig. The function of creating a driver object and inserting it into the Windows system queue via the undocumented ObInsertObject function.
In order to process the DeviceControl request, the driver registers the handler IRP_MJ_DEVICE_CONTROL, which is not standard in such cases, and instead uses the DriverObject-> FastIoDispatch.FastIoDeviceControl fast I / O function.
Fig. The registration function DriverObject-> FastIoDispatch.FastIoDeviceControl.
This handler function is used only to execute the code required by the client in kernel mode.
Fig. Handler Fast I / O rootkit.
Conclusion
The methods used by the authors of Cremes for loading the rootkit into memory are really interesting, since they use the legitimate drivers of the kernel mode of the antivirus products. Unlike other well-known rootkits, Cremes is not interested in intercepting any API calls or system operations to hide its activity in the system. Instead, the authors were simply interested in the possibility of guaranteed execution of their code in kernel mode, i.e., increasing their privileges in the system. Using the approach they use, this technique is quite successful.
Source: https://habr.com/ru/post/312872/
All Articles