# Kernel Shield

*Your organization's incident response team has been called in after a devastating ransomware attack encrypted critical servers across the network. During forensic analysis, the team discovered that the ransomware didn't just encrypt files — it first deployed a malicious kernel driver named 'NSecKrnl' to neutralize all endpoint detection and response (EDR) solutions running on the target machines.* *By operating at the kernel level, the driver was able to intercept process handle operations, strip security tool access rights, and forcefully terminate any protective processes before the ransomware payload executed. Without EDR visibility, the ransomware operated completely undetected.* *Your task as a malware analyst is to load this kernel driver into IDA Pro and fully reverse engineer its capabilities. Uncover how it initializes, how it evades kernel integrity checks, how it communicates with its usermode ransomware component via IOCTL codes, and how it systematically kills EDR processes. Your findings will be critical to understanding the full attack chain and building detections to prevent future incidents.* *** Hi all,\ welcome to my writeup for the real world challenge **Kernel Shield** from [malops.io](https://malops.io/). Malops.io is an advanced Malware Analysis Training Platform, providing a guided path to dissect and analyze real world malware, created and maintained by Nextron Threat Researcher Gameel Ali. The goal is to practice reversing real malware samples, to understand the behavior and used techniques used by the provided sample. During my analysis I renamed most of the generic names created by the Disassembler and Debugger, to better understand the malware and the purpose of the variables, functions etc. As far it is possible, I will try not to make the answer too obvious (e.g. omitting technical terms) so you can follow along in your own analysis environment. After answering the provided question, which focused solely on analysing the kernel component, I took a quick look at the user-mode application because I was interested in understanding [BYOVD attack paths](https://attack.mitre.org/techniques/T1068/) in more depth and how they work. > **Important:**\ > This writeup focuses on answering the provided questions in an explanatory/educational manner. Therefore, the analysis was conducted superficially and does not claim to be exhaustive. To answer the questions, some quick and dirty approaches have been used to catch the solutions. This article is not a substitute for a thorough analysis in case of infection via a BYOVD attack! *** ## Questions ### 1) The driver exposes itself to usermode applications under a specific name. What is this name? In order to be able to communicate with user-space applications via IOCTLs, the kernel driver must create a DEVICE\_OBJECT by calling the API IoCreateDevice and make it accessible for user-mode processes via IoCreateSymbolicLink. These operations are performed inside the DriverEntry function.

### 2) During initialization, the driver tampers with its own loader entry to bypass a kernel security check. What hex value is OR'd into that field? The kernel driver accesses the DriverSection member of the DRIVER\_OBJECT struct and from here the LDR\_DATA\_TABLE\_ENTRY struct to manipulate a specific flag. The DriverSection member points to the LDR\_DATA\_TABLE\_ENTRY struct. \ At offset 0x68, the Flags member is located. The original value is ORed with 0x20. > [Kernel data structures](https://www.codemachine.com/articles/kernel_structures.htmlhttps://www.codemachine.com/articles/kernel_structures.html)\ > [LDR\_DATA\_TABLE\_ENTRY](https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/api/ntldr/ldr_data_table_entry.htm)

### 3) At what byte offset from the base of the loader data table entry does this tampering occur? The tampering occurs at offset 0x68 of the LDR\_DATA\_TABLE\_ENTRY struct. ### 4) One of the IOCTL codes handled by the dispatch function leads to forced process termination. What is this code in hex? {% hint style="info" %} IOCTL:\ Stands for input and output control and is an interface through which applications communicate with device drivers. To accomplish this, the user-mode application uses the API DeviceIoControl to send specific control codes to the requested device object. An IOCTL code is a 32 bit value with several fields, to access specific device types or the type of access requested. [IOCTL](https://learn.microsoft.com/en-us/windows/win32/devio/device-input-and-output-control-ioctl-) [DeviceIoControl](https://learn.microsoft.com/en-us/windows/win32/api/ioapiset/nf-ioapiset-deviceiocontrol) [IOCTL code structure](https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/defining-i-o-control-codes?source=recommendations) {% endhint %} To solve this question, I worked backwards starting from the API call to ZwTerminateProcess. This API is called only one time, namely inside a function, that has been registered with the DriverObject->MajorFunction member previously. It is moved into an array located at the end of the DRIVER\_OBJECT struct and contains pointers to various entry points for dispatch routines. Each index represents an IRP function code. In this case, the entry point at index 0xE represents the IRP\_MJ\_DEVICE\_CONTROL [function](https://github.com/ayoubfaouzi/windows-internals/blob/master/IRP%20Major%20Functions%20List.md).

### 5) When the dispatch function receives an unrecognized IOCTL or a NULL input buffer, it returns a specific NTSTATUS code. What is it in hex? In the above picture we can see a hardcoded status code, set up at the beginning of the function. If every IOCTL check fails, this code is returned. Otherwise the returned status code is STATUS\_SUCCESS. ### 6) The driver maintains internal tracking arrays with a fixed capacity. How many entries can each array hold? For this question I checked the contents of the .data section because it is the only writable section of the PE file and is used to track various stuff. Inside this section we can see huge arrays, filled with NULL bytes. The size of these arrays is 8192 bytes. Dividing it with 8 bytes (size of a QWORD) returns 1024 entries that can be stored.

### 7) The driver registers a kernel callback to intercept handle operations at a specific altitude. What is this altitude number? {% hint style="info" %} To register object notifications. a kernel driver can register object-callback routines via calls to nt!ObRegisterCallbacks. Basically, when calling this API, a new callback operation is registered for a specific object type (PsProcessType, PsThreadType or ExDesktopObjectType). When setting up object-callback routines, multiple structs and members are involved. \ For example, the Altitude member of the OB\_CALLBACK\_REGISTRATION struct, defines the order in which the callback routines should be invoked. Matt Hand - Evading EDR, p. 62ff [ObRegisterCallbacks](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-obregistercallbacks) [OB\_CALLBACK\_REGISTRATION structure](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_ob_callback_registration) [OB\_OPERATION\_REGISTRATION structure](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_ob_operation_registration) {% endhint %} To answer this question, I searched for calls to the API ObRegisterCallbacks and analyzed, how the different struct members of the OB\_CALLBACK\_REGISTRATION struct are filled. ```c typedef struct _OB_CALLBACK_REGISTRATION { USHORT Version; USHORT OperationRegistrationCount; UNICODE_STRING Altitude; PVOID RegistrationContext; OB_OPERATION_REGISTRATION *OperationRegistration; } OB_CALLBACK_REGISTRATION, *POB_CALLBACK_REGISTRATION; ``` In the pickture below, we can see how a unicode string is moved into the Altitude member. This unicode string is treated as a decimal number in the struct.

filling the OB_CALLBACK_REGISTRATION struct

In case of this driver, the ObjectType specified in the OB\_OPERATION\_REGISTRATION struct is the PsProcessType. This defines, that the callback routine is executed, everytime a handle to a process (in our case) is obtained. ```c typedef struct _OB_OPERATION_REGISTRATION { POBJECT_TYPE *ObjectType; OB_OPERATION Operations; POB_PRE_OPERATION_CALLBACK PreOperation; POB_POST_OPERATION_CALLBACK PostOperation; } OB_OPERATION_REGISTRATION, *POB_OPERATION_REGISTRATION; ``` In the picture below, we can see the PsProcessType is moved into RAX and later moved into the OB\_OPERATION\_REGISTRATION struct.

### 8) When the driver opens a handle to a process it is about to forcefully terminate, what handleattribute value (hex) does it request? Before a process can be terminated via a call to ZwTerminateProcess, a valid handle to this process must be obtained. To accomplish this, the malware uses the API ObOpenObjectByPointer, which returns a handle to the desired object. ```c NTSTATUS ObOpenObjectByPointer( [in] PVOID Object, [in] ULONG HandleAttributes, [in, optional] PACCESS_STATE PassedAccessState, [in] ACCESS_MASK DesiredAccess, [in, optional] POBJECT_TYPE ObjectType, [in] KPROCESSOR_MODE AccessMode, [out] PHANDLE Handle ); ``` The handle is stored in a variable, pointed to by the last parameter of this API call. Additionally, we also find the answer for this question in this function.

function to terminate a specific process

The HandleAttributes value is an ORed combination of multiple values, defining the desired attributes for the object handle. In case of this kernel driver, this value is set to OBJ\_KERNEL\_HANDLE. The values are defined in the ntdef.h header file. > [ntdef.h header file](https://github.com/tpn/winsdk-10/blob/master/Include/10.0.10240.0/shared/ntdef.h) ### 9) What is the PDB filename embedded in the binary? The answer can be found by statically examining the driver.

### 10) The driver creates its device object with a specific device type constant. What is this value in hex? A device object is created via a call to IoCreateDevice. The DeviceType parameter specifies the underlying hardware for the driver. [This type is later stored in the DEVICE\_OBJECT structure.](https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/specifying-device-types) ```c NTSTATUS IoCreateDevice( [in] PDRIVER_OBJECT DriverObject, [in] ULONG DeviceExtensionSize, [in, optional] PUNICODE_STRING DeviceName, [in] DEVICE_TYPE DeviceType, [in] ULONG DeviceCharacteristics, [in] BOOLEAN Exclusive, [out] PDEVICE_OBJECT *DeviceObject ); ```

In case of this driver, the DeviceType FILE\_DEVICE\_UNKNOWN will be created, represented by a specific hex value. ### 11) All four IOCTL codes are evenly spaced. What is the stride (difference) between consecutive codes? Examining the function responsible for calling a specific function based on the IOCTL, reveals that various calculations are performed alongside if-statements.

### 12) Before the handle interception callback checks its internal tables, it performs a self-check to avoid interfering when a process operates on itself. What kernel API provides the current process pointer for this comparison? In the above questions we understood, that the kernel driver uses callbacks to monitor handle operations in regards to processes. The function used as a callback routine is moved onto the stack too, similar to the PsProcessType described above.

This function performs several checks, also if the current process is the same like the process it is operating on.

### 13) After unregistering the handle interception callback during driver teardown, the registration handle global is set to a specific value. What is it? Every DRIVER\_OBJECT struct also contains a member (DriverUnload) that points to a function, that is called when the driver is unloaded. In the first questions we were able to see, how this member is filled with a pointer to an unloading function.

This function is responsible for removing various callback routines and device objects, but also for removing the registered object callback routine (highlighted line).

unregistering the object callback routine

A NULL-pointer is assigned to the global registration handle variable. ### 14) The handle interception monitors two types of operations simultaneously. What is the combined flag value (decimal) in the operation registration structure? The OperationRegistration member is filled via stack operations. Then the stack address is moved into this member (at 0x140001581).

The Operations member specifies, if the callback routines should be executed if new handles are created or if they will be duplicated (OB\_OPERATION\_HANDLE\_CREATE and OB\_OPERATION\_HANDLE\_DUPLICATE). ### 15) The termination function must release a reference on the process object before returning. What kernel API performs this dereferencing? During the function responsible for terminating the desired process, a specific API is called to release references on process objects. This happens before returning.

### 16) During initialization, the driver registers a notification callback for image loading events. The function registered for this purpose is unusually small. What is its size in bytes (hex)? A callback routine for image loading events is set up via a call to the PsSetLoadImageNotifyRoutine API. Like other notifications, a function will be executed on image loading (e.g. DLL, EXE) events. The function set as NotifyRoutine is small and visible in the picture below.

### 17) The address of the function that the driver assigns as its DriverUnload handler is what?

function prologue of the driver unload function

*** ## Continuation of work Since I am interested in how BYOVD attacks are used to interfere negatively with processes of security tools, I decided to take a deeper look into the whole situation here.\ The blog post of the Malops team provided information regarding the [CVE-2025-68947](https://nvd.nist.gov/vuln/detail/CVE-2025-68947) abused here. > Sources: > > > > > > > > > > ### CVE-2025-68947 The NSecKrnl driver for Windows allows local and authenticated attackers to terminate processes owned by other users, but also SYSTEM or Protected Processes. To achieve this goal, the attacker used crafted IOCTL requests to the driver. Regarding this CVE, SentinelOne mentions that the driver does not validate the authorization to request process termination. This means that, with specific IOCTL requests, target processes can be terminated even if the caller is not authorized to request it. A proper authorization check isn't implemented, as we were able to see while answering the questions for this challenge. ### Attack vector In order to exploit the vulnerability in the NSecKrnl driver, the attacker must meet the following prerequisites (as per SentinelOne): 1. The attacker obtains or deploys the vulnerable NSecKrnl driver on the target system 2. The attacker opens a handle to the driver's device object 3. The attacker crafts IOCTL requests specifying target process identifiers 4. The driver executes the process termination with kernel-level privileges 5. Target processes, including security software, are forcibly terminated ### Own analysis In order to understand BYOVD techniques better, I decided to take my own look into the user-mode application, responsible for controlling the driver, although there already exist some excellent and deep-technical writeups like the ones on the blog on [Hexastrike](https://hexastrike.com/resources/blog/threat-intelligence/valleyrat-exploiting-byovd-to-kill-endpoint-security/#elementor-toc__heading-anchor-4) and on [VXUG](https://vx-underground.org/Malware%20Analysis/2025/2025-09-07%20-%20ValleyRAT%20Exploiting%20BYOVD%20to%20Kill%20Endpoint%20Security). From their reports, I found the user-application with the SHA256 hash: > b4ac2e473c5d6c5e1b8430a87ef4f33b53b9ba0f585d3173365e437de4c816b2 Instead of just reading the writeups, I decided to use my knowledge of the challenge and the answered questions, to find crucial aspects in the user-mode application, responsible for the communication with the device object and the deployment of the kernel driver itself. #### Communication with the driver From the analysis performed above, we know that the user-space application communicates via IOCTL codes with the kernel driver. This happens via the API DeviceIoControl.

enumerating processes with calls to DeviceIoControl

The malware fills multiple variables with hardcoded process names. Then, it creates a snapshot of all running processes via CreateToolhelp32Snapshot and uses the gathered processes for a check with each process of the hardcoded list. For every targeted process (20 in total), a new snapshot is created and looped through until it finds a match. At address 0x140006D7F in the above picture we see, that the do-while loop runs 20 times, checking each hardcoded process name individually with a snapshot taken before.

When a match is found, the malware proceeds with a call to DeviceIoControl with the IOCTL code, we discovered when analyzing the kernel driver. The third parameter (lpInBuffer) is a pointer to a buffer, that contains information for the driver to perform the operation (in this case the PID of the targeted process). #### Dropping the driver The .rsrc section of the user-mode application contains our driver in plaintext.

The triage information, especially the file hashes of this PE file, are identical to the binary we analyzed during this challenge.

This PE file is dropped into the Temp directory during execution with a file name generated randomly.

#### Loading the driver The dropped driver file is used to create a Registry key responsible for setting up a service (SYSTEM\CurrentControlSet\Services\\). Notable here is the service type 1, indicating a SERVICE\_KERNEL\_DRIVER. The assignment happens through setting the value for the Type key via a call to RegSetKeyValueW with the value to be written as fifth parameter.

modification of the ImagePath and Type keys during service setup

After the Registry key has been created, the user-mode application loads the APIs RtlAdjustPrivilege and NtLoadDriver dynamically from ntdll.dll and uses them, to escalate the privileges and load the driver, based on the set Registry key as the only parameter needed for a call to NtLoadDriver.

instructions to load the driver manually

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://txc.gitbook.io/documentation/writeups/malops.io/kernel-shield.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.