Systems and methods for controlling access to an operating system kernel driver

Abstract

Computing systems and methods are provided for controlling access to a kernel driver in an operating system. In particular, the processor of a computer loads a defensive kernel driver. The processor then monitors a plurality of loaded kernel drivers. It then detects a vulnerable kernel driver from amongst the plurality of loaded kernel drivers, and the vulnerable drive matching an entry on a vulnerable kernel driver list. It then hooks the defensive driver into the vulnerable kernel driver. The processor then intercepts request data, such as input / output request packets (IRPs), with the defensive kernel driver, evaluates the same, and, after determining the request data is safe, forwards the request data to the vulnerable kernel driver.

Description

SYSTEMS AND METHODS FOR CONTROLLING ACCESS TO AN OPERATING SYSTEM KERNEL DRIVERRELATED APPLICATIONS

[0001] The present application claims priority to US Provisional Patent Application 63 / 540,602 filed September 26, 2023, and titled “SYSTEMS AND METHODS FOR CONTROLLING ACCESS TO AN OPERATING SYSTEM KERNEL DRIVER”, herein incorporated by reference in its entirety.TECHNICAL FIELD

[0002] The disclosed exemplary embodiments relate to computer- implemented systems and methods for controlling access to a kernel driver in an operating system and, in particular, to systems and methods that monitor input / output request packets (IRPs).BACKGROUND

[0003] A computer operating system (OS) includes a kernel, which is a key supervisory program that enables the operating system to function. In some cases, the kernel is the first program to load after a bootloader. After loading, it controls and coordinates every other program and process. The kernel is also the bridge between the user and the hardware, and it translates user instructions for the hardware and mediates access to the hardware, over which it has control. Some of the supervisory actions performed by the kernel include scheduling, launching, and ending processes; and, initializing, running drivers (programs that communicate with hardware), and ensuring that memory is allocated correctly.

[0004] When malware compromises a computer running an operating system, in some cases there are a few initial steps that are usually taken, including: disabling security software to avoid detection; and obtaining user credentials (i.e. , passwords or passcodes) to enable access to other systems. In some cases, security software may be disabled by terminating its process, and credentials may be obtained by accessing the Local Security Authority Subsystem Service (e.g., LSASS.exe).

[0005] In some operating systems, such as the operating system versions under the tradename Windows® by Microsoft Corporation, there are included protections for these types of attacks in the form of Protected Processes (PPL).Protected process are security critical processes which prevent users, even Administrators, from accessing them. Trusted code can be loaded into protected processes and they are protected from other attacks such as code injection or memory dumping.

[0006] The operating system kernel in Windows® is considered the most privileged part of the operating system and has full access to the hardware and software of the computer. Third party code runs in the kernel through drivers which are digitally signed to verify the integrity of the code and to identify the vendor of the software. For malware to gain access to the kernel, the malware may attempt to exploit a security vulnerability in the kernel or in drivers. In some cases, vulnerable drivers are listed on third-party websites and can be utilized by bad actors.

[0007] In some cases, malware exploits a vulnerable driver by opening a handle to the driver's device path and then sending device input / output control messages (lOCTLs) or the analogous file system control messages (FSCTLs) crafted to trigger the vulnerability. An example of this is when a bad actor (e.g., the hacking group known as “Lazarus”) was caught exploiting a driver to disable security software as part of a hacking campaign, later identified in the Common Vulnerabilities and Exposures (CVE) bulletin CVE-2021-21551. The vulnerability in this case was in the dbutil_2_3.sys driver in Dell® computers which allowed user applications to send lOCTLs, which then provided direct read and write access to kernel memory, and which could be used to bypasses security mitigations in the Windows® operating system.

[0008] If a vulnerable driver is not already present on the system, malware running as an administrator user can bring its own copy of a vulnerable driver and install it. This type of attack, called Bring Your Own Vulnerable Driver (BYOVD), has recently become more common. One example is the group known as Advanced Persistent Threat 41 (APT41 ) using BYOVD with a driver from Zemana Anti-Malware.

[0009] With the rise in attacks using BYOVD, there has also been interest in how malware could abuse this. In some cases, BYOVD could be used in disabling Endpoint Detection and Response (EDR). In some case, BYOVD could be used in dumping credentials from the Local Security Authority service.

[0010] Conventional attempts to protect against vulnerable drivers include the utilization of block lists, such as Microsoft’s published vulnerable driver block list (https: / / learn.microsoft.com / en-us / windows / security / application-security / application-control / windows-defender-application-control / design / microsoft-recommended-d river- block-rules).SUMMARY

[0011] The following summary is intended to introduce the reader to various aspects of the detailed description, but not to define or delimit any invention.

[0012] In at least one broad aspect, there is provided an apparatus for controlling access to a kernel driver in an operating system. The apparatus includes: a memory storing instructions; and one or more processors coupled to the memory. The one or more processors are configured to execute the instructions to: load a defensive kernel driver; monitor a plurality of loaded kernel drivers (e.g., using kernel callback); detect a vulnerable kernel driver from amongst the plurality of loaded kernel drivers, and the vulnerable drive matching an entry on a vulnerable kernel driver list; hook the defensive kernel driver into the vulnerable kernel driver; intercept a request data with the defensive kernel driver, evaluate the same, and, after determining the request data is safe, forward the request to the vulnerable kernel driver.

[0013] In some cases, after determining the request data does not satisfy the safe condition, block the request data from being sent to the vulnerable kernel driver.

[0014] In some cases, the apparatus further includes an input / output (IO) manager residing in the memory. The IO manager is configured to build and send the IRP to the vulnerable kernel driver. After the defensive kernel driver is hooked into the vulnerable kernel driver, the IO manager is configured to send the IRP to the defensive kernel driver.

[0015] In some cases, the IRP includes data associated with a device input / output control (IOCTL) call, and the defensive kernel driver inspects the data associated with the IOCTL call to evaluate the IRP to determine if it satisfies the safe condition. After the defensive kernel driver determines the IRP satisfies the safe condition, the defensive kernel driver returns the IRP to the IO manager, and the IO manager directly transmits the IRP to the vulnerable kernel driver.

[0016] In some cases, the IRP includes data associated with a device input / output control (IOCTL) call, and the defensive kernel driver inspects the data associated with the IOCTL call to evaluate the IRP to determine if it satisfies the safe condition.

[0017] In some cases, the data associated with the IOCTL call comprises: an input parameter, and an output parameter when the IOCTL call is permitted. In some cases, the data associated with the IOCTL call comprises a user mode caller, which is retrievable by an Application Programming Interface of the operating system.

[0018] In some cases, after the defensive kernel driver determines the IRP satisfies the safe condition, the defensive kernel driver is configured to log the IOCTL call to build a known safe baseline.

[0019] In some cases, the one or more processors identify a plurality of vulnerable kernel drivers from amongst the plurality of loaded kernel drivers, wherein the plurality of vulnerable kernel drivers matches a plurality of entries on the vulnerable kernel driver list. The one or more processors then hook the defensive kernel driver into each of the plurality of vulnerable kernel drivers; use the defensive kernel driver to intercept and evaluate a plurality of IRPs corresponding respectively to the plurality of vulnerable kernel drivers; and, after determining that each of the plurality of IRPs satisfy a plurality of safe conditions respectively associated with the plurality of vulnerable kernel drivers, the defensive kernel driver forwards the plurality of IRPs respectively to the plurality of vulnerable kernel drivers.

[0020] In another broad aspect, an apparatus for controlling access to a kernel driver in an operating system is provided. The apparatus comprises a memory storing instructions, and one or more processors coupled to the memory. The one or more processors being configured to execute the instructions to: load a defensive kernel driver; hook the defensive kernel driver into a loaded kernel driver; identify a baseline of IOCTL and / or FSCTL activity by monitoring the loaded kernel driver; detect an anomalous activity of the loaded kernel driver that deviates beyond a threshold of the baseline, and label the loaded kernel as a vulnerable kernel driver; intercept an input / output request packet (IRP) with the defensive kernel driver and evaluate the IRP to determine if it satisfies a safe condition; and, after determining the IRP satisfies the safe condition, forward the IRP to the vulnerable kernel driver.

[0021] In some cases, the one or more processors are configured to execute the instructions to further: after determining the IRP does not satisfy the safe condition, block the IRP from being sent to the vulnerable kernel driver.

[0022] In another broad aspect, a system is provided for controlling access to a kernel driver in an operating system. The system comprises a profiling computer anda plurality of computers that each store thereon a respective instance of a subject kernel driver and a respective instance of the operating system. Each of the plurality of computers comprise: a network interface; a memory storing instructions; and one or more processors coupled to the memory. The one or more processors are configured to execute the instructions to: load a defensive kernel driver; hook the defensive kernel driver into a loaded instance of the subject kernel driver; use the defensive kernel driver to obtain IOCTL and / or FSCTL activity data associated with the loaded instance of the subject kernel driver, and transmit the IOCTL and / or FSCTL activity data using the network interface to the profiling computer; and, receive from the profiling computer, using the network interface, a baseline derived from at least the IOCTL and / or FSCTL activity data and a threshold of the baseline. In a given computer of the plurality of computers, the one or more processors in the given computer are configured to execute the instructions to further: detect an anomalous activity of the loaded instance of the subject kernel driver that deviates beyond the threshold of the baseline, and label the loaded instance of the subject kernel driver as a vulnerable kernel driver; intercept an input / output request packet (IRP) with the defensive kernel driver and evaluate the IRP to determine if the IRP satisfies a safe condition; and, after determining the IRP satisfies the safe condition, forward the IRP to the vulnerable kernel driver.

[0023] In some cases of the system, the one or more processors in the given computer are configured to execute the instructions to further: after determining the IRP does not satisfy the safe condition, block the IRP from being sent to the vulnerable kernel driver.

[0024] In some cases of the system, the profiling computer comprises: a network interface of the profile computer; a memory of the profiling computer storing instructions; and, one or more processors of the profiling computer coupled to the memory of the profiling computer. The one or more processors of the profiling computer are configured to execute the instructions to: receive a plurality of instances of the IOCTL and / or FSCTL activity data respectively from the plurality of computers; process the plurality of instances of the IOCTL and / or FSCTL activity data to generate the baseline and the threshold for the baseline; and transmit the baseline and the threshold of the baseline to each of the plurality of computers.

[0025] In some cases of the system, the plurality of computers comprises at least one hundred computers. In some cases of the system, the plurality of computerscomprises at least one thousand computers. In some cases of the system, the plurality of computers comprises at least ten thousand computers.

[0026] In another broad aspect, an apparatus is provided for controlling access to a kernel driver in an operating system. The apparatus comprises: a memory storing instructions; and one or more processors coupled to the memory. The one or more processors are configured to execute the instructions to: load a defensive kernel driver; hook the defensive kernel driver into each of a plurality of loaded kernel drivers; identify a pattern by monitoring IOCTL and / or FSCTL activity associated with the plurality of loaded kernel drivers; generate a baseline and a threshold of the baseline using the pattern; detect an anomalous activity related to a given loaded kernel driver from amongst the plurality of loaded kernel drivers, the anomalous activity deviating beyond the threshold of the baseline, and label the given loaded kernel driver as a vulnerable kernel driver; intercept an input / output request packet (IRP) with the defensive kernel driverand evaluate the IRP to determine if it satisfies a safe condition; and, after determining the IRP satisfies the safe condition, forward the IRP to the vulnerable kernel driver.

[0027] In some cases, the one or more processors are configured to execute the instructions to further: after determining the IRP does not satisfy the safe condition, block the IRP from being sent to the vulnerable kernel driver.

[0028] In another broad aspect, a method is provided for controlling access to a kernel driver in an operating system, the method executed in a computing environment comprising a memory and one or more processors coupled to the memory. The method comprises: loading a defensive kernel driver; monitoring a plurality of loaded kernel drivers; detecting a vulnerable kernel driver from amongst the plurality of loaded kernel drivers, and the vulnerable kernel driver matching an entry on a vulnerable kernel driver list; hooking the defensive kernel driver into the vulnerable kernel driver; intercepting an input / output request packet (IRP) with the defensive kernel driver and evaluate the IRP to determine if it satisfies a safe condition; and, after determining the IRP satisfies the safe condition, forwarding the IRP to the vulnerable kernel driver.

[0029] In some cases, the method further comprises: after determining the IRP does not satisfy the safe condition, blocking the IRP from being sent to the vulnerable kernel driver.

[0030] In some cases, the method further comprises an input / output (10) manager building and sending the IRP to the vulnerable kernel driver; and, after the defensive kernel driver is hooked into the vulnerable kernel driver, the 10 manager sending the IRP to the defensive kernel driver.

[0031] In some cases, the IRP comprises data associated with a device input / output control (IOCTL) call, and the method further comprises: the defensive kernel driver inspecting the data associated with the IOCTL call to evaluate the IRP to determine if it satisfies the safe condition; after the defensive kernel driver determines the IRP satisfies the safe condition, the defensive kernel driver returning the IRP to the IO manager; and the IO manager directly transmitting the IRP to the vulnerable kernel driver.

[0032] In some cases, the IRP comprises data associated with a device input / output control (IOCTL) call, and the method further comprises: the defensive kernel driver inspecting the data associated with the IOCTL call to evaluate the IRP to determine if it satisfies the safe condition.

[0033] In some cases, the data associated with the IOCTL call comprises: an input parameter, and an output parameter when the IOCTL call is permitted.

[0034] In some cases, the data associated with the IOCTL call comprises a user mode caller, which is retrievable by an Application Programming Interface of the operating system.

[0035] In some cases, the method further comprises: after the defensive kernel driver determines the IRP satisfies the safe condition, the defensive kernel driver logs the IOCTL call to build a known safe baseline.

[0036] In some cases, the method further comprises: identifying a plurality of vulnerable kernel drivers from amongst the plurality of loaded kernel drivers, wherein the plurality of vulnerable kernel drivers matches a plurality of entries on the vulnerable kernel driver list; hooking the defensive kernel driver into each of the plurality of vulnerable kernel drivers; using the defensive kernel driver to intercept and evaluate a plurality of IRPs corresponding respectively to the plurality of vulnerable kernel drivers; and, after determining that each of the plurality of IRPs satisfy a plurality of safe conditions respectively associated with the plurality of vulnerable kernel drivers, thedefensive kernel driver forwarding the plurality of IRPs respectively to the plurality of vulnerable kernel drivers.

[0037] In another broad aspect, a method is provided for controlling access to a kernel driver in an operating system, the method executed in a computing environment comprising a memory and one or more processors coupled to the memory. The method comprises: loading a defensive kernel driver; hooking the defensive kernel driver into a loaded kernel driver; identifying a baseline of device input / output control (IOCTL) and / or file system control code (FSCTL) activity by monitoring the loaded kernel driver; detecting an anomalous activity of the loaded kernel driver that deviates beyond a threshold of the baseline, and labelling the loaded kernel as a vulnerable kernel driver; intercepting an input / output request packet (IRP) with the defensive kernel driver and evaluating the IRP to determine if it satisfies a safe condition; and, after determining the IRP satisfies the safe condition, forwarding the IRP to the vulnerable kernel driver.

[0038] In some cases, the method further comprises: after determining the IRP does not satisfy the safe condition, blocking the IRP from being sent to the vulnerable kernel driver.

[0039] In another broad aspect, a method is provided for controlling access to a kernel driver in an operating system, the method executable by a system comprising a profiling computer and a plurality of computers that each store thereon a respective instance of a subject kernel driver. The method comprises each of the plurality of computers performing at least: loading a defensive kernel driver; hooking the defensive kernel driver into a loaded instance of the subject kernel driver; using the defensive kernel driver to obtain IOCTL and / or FSCTL activity data associated with the loaded instance of the subject kernel driver, and transmitting the IOCTL and / or FSCTL activity data using the network interface to the profiling computer; and, receiving from the profiling computer, using the network interface, a baseline derived from at least the IOCTL and / or FSCTL activity data and a threshold of the baseline. In a given computer of the plurality of computers, the method further comprises: detecting an anomalous activity of the loaded instance of the subject kernel driver that deviates beyond the threshold of the baseline, and label the loaded instance of the subject kernel driver as a vulnerable kernel driver; intercepting an input / output request packet (IRP) with the defensive kernel driver and evaluating the IRP to determine ifthe IRP satisfies a safe condition; and, after determining the IRP satisfies the safe condition, forwarding the IRP to the vulnerable kernel driver.

[0040] In some cases, the method further comprises: the given computer, after determining the IRP does not satisfy the safe condition, blocking the IRP from being sent to the vulnerable kernel driver.

[0041] In some cases, the method further comprises: the profiling computer performing: receiving a plurality of instances of the IOCTL and / or FSCTL activity data respectively from the plurality of computers; processing the plurality of instances of the IOCTL and / or FSCTL activity data to generate the baseline and the threshold for the baseline; and, transmitting the baseline and the threshold of the baseline to each of the plurality of computers.

[0042] In some cases, the plurality of computers comprises at least one hundred computers. In some cases, the plurality of computers comprises at least one thousand computers. In some cases, the plurality of computers comprises at least ten thousand computers.

[0043] In another broad aspect, a method is provided for controlling access to a kernel driver in an operating system, the method executed in a computing environment comprising a memory and one or more processors coupled to the memory. The method comprises: loading a defensive kernel driver; hooking the defensive kernel driver into each of a plurality of loaded kernel drivers; identifying a pattern by monitoring IOCTL and / or FSCTL activity associated with the plurality of loaded kernel drivers; generating a baseline and a threshold of the baseline using the pattern; detecting an anomalous activity related to a given loaded kernel driver from amongst the plurality of loaded kernel drivers, the anomalous activity deviating beyond the threshold of the baseline, and label the given loaded kernel driver as a vulnerable kernel driver; intercepting an input / output request packet (IRP) with the defensive kernel driver and evaluate the IRP to determine if it satisfies a safe condition; and after determining the IRP satisfies the safe condition, forwarding the IRP to the vulnerable kernel driver.

[0044] In some cases, the method further comprises: after determining the IRP does not satisfy the safe condition, blocking the IRP from being sent to the vulnerable kernel driver.

[0045] According to some aspects, the present disclosure provides a non- transitory computer-readable medium storing computer-executable instructions. The computer-executable instructions, when executed, configure a processor to perform any of the methods described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The drawings included herewith are for illustrating various examples of articles, methods, and systems of the present specification and are not intended to limit the scope of what is taught in any way. In the drawings:FIG. 1 is a schematic block diagram of an operating system for a computer in accordance with at least some embodiments;FIG. 2 is a block diagram of a computer in accordance with at least some embodiments;FIG. 3 is a schematic block diagram of an operating system, including a user mode and a kernel mode, and further showing a user mode process to execute an IOCTL and the associated look-up process performed by a kernel in a kernel mode to locate the correct driver function in accordance with at least some embodiments;FIG. 4 is a schematic block diagram of an operating system, including a user mode and a kernel mode, and further showing an I / O Manager of a kernel delivering an IRP to the top of a device stack of a vulnerable driver in accordance with at least some embodiments;FIG. 5 is a schematic block diagram of an operating system, including a user mode and a kernel mode, and further showing a filter device and deriver configured to intercept lOCTLs for inspection and enforcement, in accordance with at least some embodiments;FIG. 6 is a schematic block diagram of an operating system, including a user mode and a kernel mode, and further showing a DRIVER_OBJECT hook configured to intercept lOCTLs for inspection and enforcement, in accordance with at least some embodiments;FIG. 7 is a schematic block diagram of a process handle table in an operating system, in accordance with at least some embodiments;FIG. 8 is a schematic block diagram of an operating system, including a user mode and a kernel mode, and further showing a process handle table entry being changed to point to a different DEVICE_OBJECT, in accordance with at least some embodiments;FIG. 9 is a flow diagram of controlling access to a kernel driver in an operating system using a defensive kernel driver, in accordance with at least some embodiments;FIG. 10 is a flow diagram of controlling access to a kernel driver in an operating system using a defensive kernel driver, and further including using a baseline, in accordance with at least some embodiments;FIG. 11 is a system diagram of a profiling computer for generating a baseline, and a plurality of computers configured to control access to a kernel driver in an operating system using a defensive kernel driver, in accordance with at least some embodiments;FIG. 12A is a flow diagram of controlling access to a kernel driver in an operating system using a defensive kernel driver, computed by each of the plurality of computers in the system, and further including using a baseline provided by the profiling computer, in accordance with at least some embodiments;FIG. 12B is a flow diagram for generating the baseline using the profiling computer, in accordance with at least some embodiments;FIG. 12C is a flow diagram for a given computer in the system for detecting an anomalous activity using the baseline, in accordance with at least some embodiments;FIG. 13 is a system diagram of a computer showing a defensive kernel driver hooked into a plurality of kernel drivers, in accordance with at least some embodiments; andFIG. 14 is a flow diagram of controlling access to the plurality of kernel drivers in an operating system using a defensive kernel driver, including using a baseline, in accordance with at least some embodiments.DETAILED DESCRIPTION

[0047] A problem with block lists is that there are known vulnerable drivers which may still be required in some cases and cannot be blocked without adverselyimpacting the functionality of a system. In some cases, third party software packages will utilize, or include, vulnerable drivers that cannot be blocked without directly impacting function of software or hardware, or both. This reduces the applicability or suitability of driver block lists, and as such the problem of vulnerable driver persists in modern operating systems, including, for example, the Windows® operating system.

[0048] Turning to FIG. 1 , an example diagram showing components of a Windows® operating system 100 is shown, including both user-mode and kernelmode components. Drivers call routines that are exported by various kernel components. For example, to create a device object, the computer calls an loCreateDevice routine which is exported by the I / O manager. In addition, drivers respond to specific calls from the operating system and can respond to other system calls.

[0049] The following are example aspects of an operating system, including a Windows® operating system.

[0050] A kernel driver refers to a program written against an operating system’s native application programming interface (API) and is executed in the kernel mode on the underlying hardware. In some cases, the kernel driver for Windows, also called a Windows Kernel Driver, is a Win32 Portable Executable format binary that is loaded into the kernel address space with the operating system.

[0051] A driver object refers to a unique DRIVER_OBJECT that is assigned to a Windows Kernel Driver when it is loaded into the Windows kernel, which represents the driver within the context of the Windows kernel. It contains a series of function pointers which are used for various types of driver interaction.

[0052] A device object refers to an instance of a DEVICE_OBJECT that represents a Windows Kernel Driver’s interest in a particular device stack.

[0053] Device Input and Output Control (IOCTL) refers to one of the mechanisms (e.g., in some cases, a primary mechanism) that a user mode application can communicate with drivers in the Windows kernel, including setting information and querying information about underlying device or driver state.

[0054] File System Control Code (FSCTL) refers to a command issued to a file system driver (or Windows kernel) to control and / or query information about a file system.

[0055] A Handle Table refers to a per-process table of unique values that represent objects in the Windows kernel. In some cases, the Handle Table is used for providing user mode access to system resources in a way that provides a layer of indirection and easier accessibility. In some cases, it requires a per-access look-up at runtime in order to translate a handle to an object pointer.

[0056] Referring now to FIG. 2, there is illustrated a simplified block diagram of a computer 200 in accordance with at least some embodiments. The computer 200 is also herein referred to as a computing system. Computer 200 is an example implementation of a computer that stores and runs an operating system. For example, the computer stores and runs the operating system 100 shown in FIG. 1. Computer 200 has at least one processor 210 operatively coupled to at least one memory 220, at least one communications interface 230 (also herein called a network interface), and at least one input / output device 240.

[0057] The at least one memory 220 includes a volatile memory that stores instructions executed or executable by processor 210, and input and output data used or generated during execution of the instructions. Memory 220 may also include nonvolatile memory used to store input and / or output data - e.g., within a database - along with program code containing executable instructions. In some cases, the operating system is stored in the memory 220.

[0058] Processor 210 may transmit or receive data via communications interface 230, and may also transmit or receive data via any additional input / output device 240 as appropriate.

[0059] In some cases, the processor 210 includes a system of central processing units (CPUs) 212. In some other cases, the processor includes a system of one or more CPUs and one or more Graphical Processing Units (GPUs) 214 that are coupled together.

[0060] In some cases, the CPU or the GPU, or both, are used to execute computations to detect to identify unknown vulnerabilities by potentially vulnerable drivers, and automatically identify outliers (e.g., outlier drivers, outlier lOCTLs, and / or outlier FSCTLs). For example, in some cases, machine learning is utilized to identify baselines associated with driver actions, without having any knowledge of any specific driver, IOCTL, or existing call pattern.

[0061] Identifying Exploitation in Real Time

[0062] Windows kernel drivers that utilize IOCTL and / or FSCTL codes define a set of numeric values which map to functionality provided by the driver. These codes can map to many types of functionality, ranging from the ability to query information about the driver, associated device or physical hardware, or set information or state associated with those same types of entities. These capabilities can also have a series of input or output parameters, which can be unique to each lOCTLs or FSCTLs. These capabilities are “exported” to user mode, and subsequently accessed by user mode, in the following manner:

[0063] IOCTL - set the IRP_MJ_DEVICE_CONTROL function pointer within the driver’s DRIVER_OBJECT (MajorFunction array at index 14), which is then accessed by user mode applications via calls to DeviceloControl (Win32) or NtDeviceloControlFile (system service).

[0064] FSCTL - set the IRP_MJ_FILE_SYSTEM_CONTROL function pointer within the driver’s DRIVER_OBJECT (MajorFunction array at index 13), which is then accessed by user mode applications via calls to DeviceloControl (Win32) or NtDeviceloControlFile (system service).

[0065] Referring to FIG. 3, a visualization is provided of the flow of a user mode process calling an IOCTL, which flows into executing code within the kernel driver. In other words, a user mode process is shown using DeviceloControl to execute an IOCTL, and the associated look-up process is performed by the Windows kernel to locate the correct driver function to execute.

[0066] Internal aspects of the Windows kernel and IO Manager are omitted from FIG. 3 in order to focus on the IOCTL execution, rather than the managing components. For example, IOCTL I FSCTL calls are delivered to drivers, via a device (DEVICE_OBJECT), through a data structure and mechanism called an I / O Request Packet (IRP).

[0067] In FIG. 3, in the user mode, the process (e.g., process.exe) calls on Kernel32.dll (Win32), and the DevicelOControl of Kernel32.dll call on ntdll.dll. The NtDeviceControlFile of ntdll.dll calls on the Windows Kernel, which is in the kernel mode.

[0068] In the kernel mode, the I / O Manager of the Windows Kernel builds and sends the IRP to the driver.sys, which is received by the IRP_MI_DEVICE_CONTROL Handler. In particular, a function pointer retrieval is performed by the DEVICE_OBJECT to the DRIVER_OBJECT, and then extracts the function to call in driver.sys.

[0069] The DeviceloControl function uses a handle to a device stack, which contains the DEVICE_OBJECT associated with the DRIVER_OBJECT, which represents the Windows kernel driver that implements the code associated with the IOCTL / FSCTL code. The following is the prototype for the Win32 function DeviceloControl, which illustrates these parameters, along with the input and output buffers associated with IOCTL activity.BOOL DeviceloControl[in] HANDLE hDevice, < — Handle to the device stack[in] DWORD dw!oControlCode,< — IOCTL / FSCTL code value[in, optional] LPVOID IpInBuffer,[in] DWORD nlnBufferSize,[out, optional] LPVOID IpOutBuffer,[in] DWORD nOutBufferSize,[out, optional] LPDWORD IpBytesReturned,[in, out, optional] LPOVERLAPPED IpOverlapped);

[0070] While permissions can be applied to each IOCTL I FSCTL, the ability to call some these functions from user mode in a largely unrestricted manner is the initial vector of exploitation if a vulnerability exists within the driver that has provided a given IOCTL I FSCTL. When it comes to exploiting vulnerabilities associated with the kernel driver code that processes a given IOCTL I FSCTL, it is the input / output parameters that are in some cases manipulated in order to trigger and exploit the vulnerability. Additionally, call patterns or frequency of a vulnerable IOCTL I FSCTL are also sometimes methods of exploitation, but in some cases, it will depend on the type of vulnerability and the needs of exploitation.

[0071] To protect against exploitation, in some cases, a computing system is provided that recognizes and filters IOCTL I FSCTL call patterns. In some cases, a computing system is provided that recognizes and filters IOCTL I FSCTL input and output parameters (to recognize malformed data). In some cases, a computing system is provided that recognizes and filters an IOCTL I FSCTL caller, such as the process or dynamic library from which a given call is originating.

[0072] In some cases, such as when profiled on a system-wide scale or on a multiple host scale, a baseline of expected IOCTL I FSCTL call patterns, expected calling processes on a per IOCTL I FSCTL basis, and actual calling entities in user mode, are established. This baseline can be considered the set of “known good accessors”. Additionally, given that IOCTL I FSCTL exploitation occurs outside of that baseline, the ability to block either known or unknown exploitation attempts can depend on the ability to establish that known good baseline. For example, any accesses outside of the known good baseline can be assumed to be suspicious.

[0073] In some cases, the process of profiling including intercepting all IOCTL I FSCTL calls between user mode and drivers includes count profiles of IOCTL I FSCTRL calls over various time periods (such as per hour, per day, etc.).

[0074] In some cases, the process of profiling, including intercepting all IOCTL I FSCTRL calls between user mode and driver, further includes using per-call information. Examples of per-call information includes process name, path, creator / parent process, signing information, hash information and other metadata about the process file on disk. Another example of per-call information includes the size of the input parameters and consistency of data (e.g., high / low entropy, heavy NULL space or heterogeneity, etc.). Another example of per-call information includes composition of calling process address space, such as loaded dynamic libraries (and similar metadata about dynamic libraries as described in the previous bullet), environment variables, non-attributable executable pages, etc.

[0075] For example, consider version 1 .2.5 of a driver called “buggydriver.sys” having the following defined lOCTLs:IOCTL_SET_INFO_1 - sets information of type 1 ;IOCTL_SET_INFO_2 - sets information of type 2;IOCTL_QUERY_INFO_1 - queries information of type 1 ; andIOCTL_QUERY_INFO_2 - queries information of type 2.

[0076] Continuing with the example, after a period of analysis using the above profiling approach on 500 hosts with the software installed, it is found that each of these lOCTLs have the following known good baseline of accessors:• IOCTL_SET_INFO_1 - sets information of type 1 o Accessed by thirdparty.exe o Accessed by svchost.exe running a verified Windows service o Accessed by services.exe• IOCTL_SET_INFO_2 - sets information of type 2 o Accessed by thirdparty.exe o Accessed by svchost.exe running a verified Windows service o Accessed by services.exe• IOCTL_QUERY_INFO_1 - queries information of type 1 o Accessed by thirdparty.exe• IOCTL_QUERY_INFO_2 - queries information of type 2 o Accessed by thirdparty.exe o Accessed by svchost.exe running a verified Windows service o Accessed by services.exe o Accessed by lsass.exe

[0077] Protective Scenarios - Examples using buqqydriver.svs

[0078] In this example, this particular version 1.2.5 of the driver may be considered a vulnerable driver (e.g., also herein called “buggydriver.sys”) that is packaged with a third-party software package and is considered to be vital to its functionality. Additionally, continuing with the example of buggydriver.sys, there are thousands of computers that use this software package as part of their critical business operations. This means that the existing approach of preventing the driverfrom loading and running is not an acceptable or appropriate solution if a vulnerability were to be found.

[0079] For the purposes of this example, it is considered that a vulnerability was reported in this version of the driver, specifically in the code path that processesIOCTL_SET_INFO_2 which can be exploited by using a 2 megabyte (MB) malformed buffer as an input parameter, which is larger than the normal parameter sizes seen during profiling of no more than 1 kilobyte (KB).

[0080] Given the established known good baseline generated by profiling the 500000 hosts, three protective scenarios that utilize the known good baseline as automatic detection can be utilized. In all three scenarios, the extensive nature of the data that went into the baseline generation process can be utilized to provide a high level of efficacy and confidence.

[0081] Scenario 1 : Known Vulnerability, Exploitation Identified by Non- Standard Process(es)

[0082] In this scenario, an unsigned process called “sneakyprocess.exe” is accessing IOCTL_SET_INFO_2. This particular access profile is an outlier. Because this process is outside of the baseline, the access attempt can be blocked in real-time and the process can be immediately terminated.

[0083] It should be noted as well that rather than take the approach of identifying activity outside of the baseline indirectly, a protection approach could be to identify known attackers directly. In some cases, this approach may have a lower chance of false positives.

[0084] Scenario 2: Known Vulnerability, Exploitation Identified by Non- Standard Parameters

[0085] In this scenario, a signed system process called “svchost.exe” is accessing IOCTL_SET_INFO_2. This scenario is considered more ambiguous because the process hosting a verified Windows service is in the known good baseline. In some cases, after detecting this scenario, verifying the input parameters is required. For example, it is observed that the parameter size is well above the baselined 1 k in size, and therefore it is deemed to be potentially malicious, and is subsequently blocked and terminated.

[0086] Scenario 3: Unknown Vulnerability, Exploitation Identified by Non- Standard Process(es) and Parameters

[0087] In this scenario, an unknown vulnerability actually exists in the kernel driver code path that processes the IOCTL, IOCTL_SET_INFO_1 . This vulnerability is known by an attacker who injects attack code into a third party program“thirdparty.exe”. This presents two challenges from a defensive standpoint: the vulnerability is unknown, and the attacker is performing the attack from a process in the known good baseline set of processes. However, in an example aspect, the attack is detected by observing unexpected input parameter characteristics, allowing it to be deemed to be potentially malicious, and subsequently blocked and terminated.

[0088] Access Control Mechanisms

[0089] Example systems, apparatuses, and methods are provided to monitor and / or control IOCTL I FSCTL communications. In some cases, this includes preventing bad behavior or malicious actions associated with IOCTL I FSCTL communications. In some cases, the monitoring and / or controls also includes the ability to intercept their utilization via the call from user mode to kernel mode.

[0090] Filter Driver and Device - Access Control Mechanism

[0091] In some cases, a computing system adds a DEVICE_OBJECT to facilitate IOCTL call filtering for a device stack.

[0092] This method includes intercepting the flow of all input / output to a particular device stack. Not only can this approach be used to filter on IOCTL I FSCTL code execution, but it can also be used to intercept all functionality for a given device stack.

[0093] Using the example above of a third-party software package including buggydriver.sys, a driver that utilizes IOCTL I FSCTL communication would create at least one device (represented by a DEVICE_OBJECT), which is the endpoint for receiving IRPs containing IOCTL I FSCTL execution instances. FIG. 4 is a visualization of the DRIVER_OBJECT and created DEVICE_OBJECT associated with buggydriver.sys. The I / O Manager of the Windows Kernel delivers the IRP to the buggydriver.sys at the top of the device stack.

[0094] To utilize a Filter Driver to intercept, monitor and control IOCTL I FSCTL communication between user mode and buggydriver.sys, the computing system uses a defensive kernel driver (named “protect.sys” for the sake of this example) to create a new DEVICE_OBJECT (also called a defensive device object) and attach it above the DEVICE_OBJECT created by buggydriver.sys (which is also herein called the vulnerable driver) in the device stack. This is shown in FIG. 5. This allows protect.sys to inspect IRPs destined for the device stack, because it now represents the top of thedevice stack, and by virtue of the mechanism, receives IRPs before the next device in the stack. A DRIVER_OBJECT created by the defensive kernel driver is also created, and is also called a defensive driver object.

[0095] In some cases, the flow of interception as shown in FIG. 5 includes:

[0096] Operation 1 : The Windows I / O Manager builds an IRP (e.g., containing the details of the IOCTL call) and sends the IRP to the driver that manages the top device in the device stack. In this case, that driver is protect.sys.

[0097] Operation 2: The protect.sys driver can inspect the IOCTL call, including the input parameters (and output parameters if the call is permitted), the user mode caller (e.g., by retrieving the process information using standard Windows kernel APIs and mining techniques), and any other information that is desired. It can also decide to take one of the following actions:

[0098] Action 2(a): Log the call and associated information, and, in some cases to build the known good baseline. The protect.sys driver then proceeds with allowing the call to proceed per 2b below.

[0099] Action 2(b): Allow the call to proceed to the next driver because it has been deemed to be safe.

[0100] Action 2(c): Block the call because it was deemed to be unsafe and a potential exploitation attempt.

[0101] Operation 3: If the call was allowed (Action 2(b)), the IRP is returned to the IO Manager and it will send it to the driver associated with the next device, which in this case would be buggydriver.sys.

[0102] Operation 4: If the call was blocked (Action 2(c)), the I RP status is set to STATUS_ACCESS_DENIED and the I / O operation is completed with loCompleteRequest. This prevents the IOCTL from being delivered to the next driver (buggydriver.sys) and subsequently prevents exploitation.

[0103] In some cases, the computing system is configured to extract and analyze the information and use the same to establish a known good baseline. In turn, the baseline can be used to enforce granular protection.

[0104] Driver Object Hook - Access Control Mechanism

[0105] In some cases, a function hook is used in the DRIVER_OBJECT to intercept lOCTLs being delivered to the driver.

[0106] This method is performed in the context of the I / O Manager retrieving the function pointer for handling a particular type of IRP. In this case, the target function is that which was registered to handle IRP_MJ_DEVICE_CONTROL IRPs (i.e., IOCTL IRPs) within the DRIVER_OBJECT associated with buggydriver.sys. By replacing this function pointer with the IRP_MJ_DEVICE_CONTROL handler function provided by a defensive kernel driver (e.g., protect.sys), the I / O Manager will call that function instead of the one that was registered by the vulnerable driver (e.g., buggydriver.sys). This allows the defensive kernel driver (e.g., protect.sys) to inspect and control all IOCTL execution attempts, and subsequently prevent exploitation of any vulnerability in that code path. However, in the case where IOCTL calls are permitted it is the responsibility of protect.sys to call the original IRP_MJ_DEVICE_CONTROL handler function registered within its DRIVER_OBJECT by buggydriver.sys. Referring to FIG. 6, a diagram shows the placed hook (i.e., interception mechanism) and flow of the IRP from the I / O Manager.

[0107] In computing, a hook refers to a mechanism by which a software application can intercept events, such as messages, mouse actions, and keystrokes. A function that intercepts a particular type of event is known as a hook procedure. A hook procedure can act on each event it receives, and then modify or discard the event. In this example, the hook can be connected to the defensive kernel driver (e.g., protect.sys), thereby hooking the defensive kernel driver into the vulnerable driver (e.g., buggydriver.sys). The defensive kernel driver can then intercept the flow of IRPs from the I / O Manager, and evaluate the same.

[0108] In particular, as per FIG. 6, a DRIVER_OBJECT hook is provided to intercept lOCTLs for inspection and enforcement.

[0109] In some cases, the flow of interception in FIG. 6, includes:

[0110] Operation 1 : The Windows I / O Manager builds an IRP (containing the details of the IOCTL call) and sends the IRP to the driver that manages the top device in the device stack. The I / O Manager thinks it is sending it to the driver associated with the top DEVICE_OBJECT (via the DRIVER_OBJECT), but because a hook was placed it is actually calling protect.sys.

[0111] Operation 2: The protect.sys driver can inspect the IOCTL call, including the input parameters (and output parameters if the call is permitted), the user mode caller (by retrieving the process information using standard Windows kernel APIs and mining techniques, and any other information that is desired. It can also decide to take one or more of the following actions:

[0112] Action 2(a): Log the call and associated information, in some cases to build a known safe baseline, and then proceed with allowing the call to proceed per Action 2b below.

[0113] Action 2(b): Allow the call to proceed to the next driver because it has been deemed to be safe.

[0114] Action 2(c): Block the call because it was deemed to be unsafe and a potential exploitation attempt.

[0115] Operation 3: If the call was allowed (Action 2(b)), the IRP is returned to the I / O Manager and it directly call the original IRP_MJ_DEVICE_CONTROL function provided by buggydriver.sys.

[0116] Operation 4: If the call was blocked (Action 2(c)), the I RP status is set to STATUS_ACCESS_DENIED and the I / O operation is completed with loCompleteRequest. This prevents the IOCTL from being delivered to the next driver (buggydriver.sys) and subsequently prevents exploitation.

[0117] In some cases, the computing system is configured to extract and analyze the information and use the same to establish a known good baseline. In turn, the baseline can be used to enforce granular protection.

[0118] This computing system (and method executed by the computing system) allows for precision implementation on a per-driver basis of protection and can be enabled or disabled at the discretion of protect.sys.

[0119] Handle to Driver Object Replacement - Access Control Mechanism

[0120] In some cases, a computing system is configured to replace the value in the handle table to reference a different DEVICE_OBJECT than what was opened.

[0121] In some cases, this method manipulates the relationship between a process’s handle table in the Windows® operating system, and the I / O Manager’s translation of the handle to the target device stack. The Windows® operating systemuses a numeric translation table that translates simple numeric values (e.g., divisible by 4) to kernel object pointers. The main use of this construct is to allow processes to access kernel resources, without knowing the kernel memory address of where those resources reside, which has various benefits including a better security posture for the operating system. Referring to FIG. 7, a flow diagram showing data components includes the handle table.

[0122] In some cases, each process has its own handle table, which means both that system objects that a process is accessing are private to the process, and that each handle value is relative to the process. For example, handle value 0x0000640 for Process A will almost assuredly not be valid for any other process, or at the very least it will not reference the same underlying object in kernel space.

[0123] To utilize this mechanism in the Windows® operating system, the computing system is configured to executed a process that includes:

[0124] Operation 1 : The protect.sys driver creates a new DEVICE_OBJECT that is not attached to the DEVICE_OBJECT created by buggydriver.sys.

[0125] Operation 2: When a new handle is created to the DEVICE_OBJECT created by buggydriver.sys, the handle table entry for that new handle is located via manual handle table inspection.

[0126] Operation 3: After being found, the computing system replaces the contents of the handle table entry with the pointer to the DEVICE_OBJECT created by protect.sys.

[0127] When that handle is subsequently used by the user mode process to send an IOCTL or FSCTL, the I / O Manager will instead send it in relation to the DEVICE_OBJECT created by protect.sys rather than the one created by buggydriver.sys. This allows the desired level of interception and control of IOCTL I FSCTL flow, which is visualized in FIG. 8.

[0128] As per FIG. 8, a process handle table entry is shown being changed to point to a different DEVICE_OBJECT.

[0129] The flow of interception as shown in FIG. 8, includes:

[0130] Operation 1 : The Windows I / O manager receives the incoming IOCTL call from user mode and translates the handle to the DEVICE_OBJECT referenced bythe handle value, and instead of getting the pointer to the DEVICE_OBJECT created by buggydriver.sys, it receives a pointer to the DEVICE_OBJECT created by protect.sys. The Windows I / O Manager is not aware that an object swap was made.

[0131] Operation 2: The Windows I / O Manager builds an IRP (containing the details of the IOCTL call) and sends the IRP to the driver associated with the retrieved DEVICE_OBJECT.

[0132] Operation 3: The protect.sys driver can inspect the IOCTL call, including the input parameters (and output parameters if the call is permitted), the user mode caller (by retrieving the process information using standard Windows kernel APIs and mining techniques, and any other information that is desired. It can also decide to take one of the following actions:

[0133] Action 3(a): Log the call and associated information, perhaps to build the known good baseline, and then proceed with allowing the call to proceed per Action 3(b) below.

[0134] Action 3(b): Allow the call to proceed to the next driver because it has been deemed to be safe.

[0135] Action 3(c): Block the call because it was deemed to be unsafe and a potential exploitation attempt.

[0136] Operation 4: If the call was allowed (Action 3(b)), the IRP is returned to the I / O Manager and it directly call the original IRP_MJ_DEVICE_CONTROL function provided by buggydriver.sys.

[0137] Operation 5: If the call was blocked (Action 3(c)), the I RP status is set to STATUS_ACCESS_DENIED and the I / O operation is completed with loCompleteRequest. This prevents the IOCTL from being delivered to the next driver (buggydriver.sys) and subsequently prevents exploitation.

[0138] In some cases, the computing system is configured to extract and analyze the information and use the same to establish a known good baseline. In turn, the baseline can be used to enforce granular protection.

[0139] In some cases, this computing system (and this method performed by the computing system) does not make any changes to any device stack or DRIVER_OBJECT, and as such is stealthy and will work for any third-party driver. Forexample, this approach works with the Windows® operating system kernel patch protection, also called PatchGuard.

[0140] In some cases, this approach includes addressing the race condition that may exist due to the time between when a handle is opened by the user mode entity (i.e. , and placed in a handle table), to when an object pointer swap can be made, to when lOCTLs are sent.

[0141] Turning to FIG. 9, an example method 900 is provided for controlling access to a kernel driver in an operating system.

[0142] Block 902: The computer system loads a defensive kernel driver.

[0143] In some cases, although loaded, the defensive kernel driver is not initially attached or hooked to any other kernel drivers.

[0144] Block 904: The computer system monitors a plurality of loaded kernel drivers.

[0145] Block 906: The computer system detects a vulnerable kernel driver from amongst the plurality of loaded kernel drivers. In particular, the vulnerable kernel driver matches an entry on a vulnerable kernel driver list.

[0146] In some cases, the vulnerable kernel driver list is stored in memory of the computing system, or is accessible to the computing system over a network interface.

[0147] Block 908: The computing system hooks (or functionally attaches) the defensive driver into the vulnerable kernel driver.

[0148] Block 910: The defensive kernel deriver then intercepts a request data (e.g., IRPs, lOCTLs, or FSCTLs) that is intended to be sent to the vulnerable kernel driver.

[0149] Block 912: The computer system evaluates the request data to determine it satisfies a safe condition.

[0150] Block 914: After determining that the request data satisfies a safe condition, the computing system forwards the request data from the defensive kernel driver to the vulnerable kernel driver.

[0151] In the case in which the request data is determined not to satisfy the safe condition (i.e., the safe condition is unsatisfied), then the computing system blocks the request data from being sent to the vulnerable kernel driver.

[0152] In some cases, the computing system has identified a plurality of vulnerable kernel drivers from amongst the plurality of loaded kernel drivers, wherein the plurality of vulnerable kernel drivers matches a plurality of entries on the vulnerable kernel driver list. In these cases, the defensive kernel driver is hooked into each of the plurality of vulnerable kernel drivers. The defensive kernel driver intercepts and evaluates a plurality of input / output request packets (IRPs) corresponding respectively to the plurality of vulnerable kernel drivers so as to determine if the control messages satisfy a plurality of safe conditions respectively associated with the plurality of vulnerable kernel drivers. If the plurality of safe conditions is met, the defensive kernel driver forwards the plurality of IRPs respectively to the plurality of vulnerable kernel drivers.

[0153] In other words, a defensive kernel driver can be hooked to or attached to multiple vulnerable kernel drivers.

[0154] Referring to FIG. 10, in some cases, a defensive kernel driver is hooked into a loaded kernel driver without previously identifying whether the loaded kernel driver is vulnerable to security risk. A baseline of IOCTI and / or FSCTL activity is used to determine whether there is anomalous activity associated with a loaded kernel driver. If so, the loaded kernel driver is monitored so that safe IRPs are forward to kernel driver and unsafe IRPs are blocked by the defensive kernel driver. The operations of FIG. 10 include the following:

[0155] Block 1002: The computer system loads a defensive kernel driver.

[0156] Block 1004: The computer system hooks the defensive kernel driver into a loaded kernel driver.

[0157] Block 1006: The computer system identifies a baseline of IOCTL and / or FSCTL activity by monitoring the loaded kernel driver.

[0158] In some cases, the defensive kernel driver performs the monitoring.

[0159] In some cases, machine learning is used to process the IOCTL and / orFSCTL activity over time to compute a baseline.

[0160] Block 1008: The computer system detects an anomalous activity of the loaded kernel driver that deviates beyond a threshold of the baseline, and labels the loaded kernel driver as a vulnerable kernel driver.

[0161] Block 1010: The computer system intercepts an IRP with the defensive kernel driver.

[0162] Block 1012: The computer system evaluates the IRP to determine it satisfies a safe condition.

[0163] Block 1014: After determining the safe condition is satisfied, the computing system forwards the IRP from the defensive kernel driver to the vulnerable kernel driver.

[0164] In some cases, in FIG. 10, vulnerabilities are not known ahead of time, so no vulnerable driver list is required, or determination of a vulnerable kernel driver is not limited to just the vulnerable driver list. A kernel driver is hooked and anomalies are identified by monitoring and processing activity detected to be outside the baseline.

[0165] The principles of FIG. 10 are applicable to FIG. 11 , in which a subject kernel driver runs on hundreds or thousands of computers, which are profiled by a profiling computer to establish a baseline.

[0166] Referring to FIG. 11 , a system 1100 is shown that includes a profiling computer 1104 that is in data communication with multiple other computers 1102a, 1102b, 1102n. These computers, in some cases, have the architecture of components shown in FIG. 2. The computers 1102 each have an operating system, an instance of a subject kernel driver and a defensive kernel driver. Activity data is sent from these computers 1102 to the profiling computer 1104, and this activity data is used by the profile computer to generate a baseline and a threshold, which is sent to the computers 1102 and is used for anomaly detection. Below are operations 1200 performed by each one of the computers 1102, which are described in FIG. 12A.

[0167] Block 1202: The computer system loads a defensive kernel driver

[0168] Block 1204: The computer system hooks the defensive kernel driver into a loaded instance of subject kernel driver

[0169] Block 1206: The computer system uses the defensive kernel driver to obtain IOCTL and / or FSCTL activity data associated with the loaded instance of the subject kernel driver

[0170] Block 1208: The computer system transmits IOCTL and / or FSCTL activity data to profiling computer.

[0171] Block 1209 refers to operations of the profiling computer described in FIG. 12B.

[0172] Block 1210: The computer system receives from the profiling compute a baseline and a threshold of the baseline

[0173] Block 1211 refers to operations of the a given computer from amongst the plurality of computers described in FIG. 12C.

[0174] Turning to FIG. 12B, operations 1209 performed by the profiling computer 1104 are provided.

[0175] Block 1204: The profiling computer receives a plurality of instances of the ioctl and / or fsctl activity data respectively from the plurality of computers

[0176] Block 1204: The profiling computer processes the plurality of instances of the ioctl and / or fsctl activity data to generate the baseline and the threshold of the baseline

[0177] Block 1224: The profiling computer transmits the baseline and the threshold of the baseline to each of the plurality of computers 1102.

[0178] Referring now to FIG. 12C, the operations 1211 are described fora given computer from amongst the plurality of computers 1102.

[0179] Block 1230: The given computer detects an anomalous activity of the loaded instance of the subject kernel driver that deviates beyond the threshold of the baseline, and label the loaded instance of the subject kernel driver as a vulnerable kernel driver.

[0180] Block 1232: The given computer intercepts an IRP with the defensive kernel driver and evaluate the IRP to determine if the IRP satisfies a safe condition.

[0181] Block 1234: After detecting the safe condition is satisfied, the given computer forwards the IRP to the vulnerable kernel driver. Otherwise, the IRP is blocked from being sent to the vulnerable kernel driver.

[0182] Referring to FIG. 13, in some cases, the defensive kernel driver is hooked into multiple kernel drivers that are loaded in the operating system. In some cases, the defensive kernel driver is hooked into all the loaded kernel drivers, and anomalies are extrapolated based on IOCTL and / or FSCTL patterns. In this way, unknown vulnerabilities could be detected (e.g., in 0 days in some cases).

[0183] Block 1402: The computer system loads a defensive kernel driver.

[0184] Block 1404: The computer system hooks the defensive kernel driver into a plurality of loaded kernel drivers. In some cases, the defensive kernel driver is hooked into all the loaded kernel drivers in the computer system.

[0185] Block 1406: The computer system identifies a pattern by monitoring IOCTL and / or FSCTL activity associated with the plurality of loaded kernel drivers.

[0186] In some cases, this includes using machine learning.

[0187] Block 1408: The computer system generates a baseline and a threshold of the baseline using the pattern.

[0188] Block 1410: The computer system detects an anomalous activity related to a given loaded kernel that deviates beyond the threshold, and label the given loaded kernel driver as a vulnerable kernel driver

[0189] Block 1412: The computer system intercepts the IRP with the defensive kernel driver.

[0190] Block 1414: The computer system evaluates the IRP to determine it satisfies a safe condition.

[0191] Block 1416: After determining the safe condition is satisfied, the computer system forward the IRP from the defensive kernel driver to the vulnerable kernel driver.

[0192] It will be appreciated that the access control computations and data mechanisms described herein provide a more targeted approach. Additionally, in some cases, these computations and data mechanisms can be used to identifyunknown vulnerabilities by utilizing large scale analytics across thousands of hosts to establish known good call baselines, and automatically identify outliers. Furthermore, in some cases, machine learning is utilized to achieve these known good baselines without having any knowledge of any specific driver, IOCTL, or existing call pattern.

[0193] It will be appreciated that, while many of the examples herein refer to the Windows® operating system, in some other cases, the systems, apparatuses and methods described herein can be applied to other types of operating systems.

[0194] Various systems or processes have been described to provide examples of embodiments of the claimed subject matter. No such example embodiment described limits any claim and any claim may cover processes or systems that differ from those described. The claims are not limited to systems or processes having all the features of any one system or process described above or to features common to multiple or all the systems or processes described above. It is possible that a system or process described above is not an embodiment of any exclusive right granted by issuance of this patent application. Any subject matter described above and for which an exclusive right is not granted by issuance of this patent application may be the subject matter of another protective instrument, for example, a continuing patent application, and the applicants, inventors or owners do not intend to abandon, disclaim or dedicate to the public any such subject matter by its disclosure in this document.

[0195] For simplicity and clarity of illustration, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth to provide a thorough understanding of the subject matter described herein. However, it will be understood by those of ordinary skill in the art that the subject matter described herein may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the subject matter described herein.

[0196] The terms “coupled” or “coupling” as used herein can have several different meanings depending in the context in which these terms are used. For example, the terms coupled or coupling can have a mechanical, electrical or communicative connotation. For example, as used herein, the terms coupled or coupling can indicate that two elements or devices are directly connected to oneanother or connected to one another through one or more intermediate elements or devices via an electrical element, electrical signal, or a mechanical element depending on the particular context. Furthermore, the term “operatively coupled” may be used to indicate that an element or device can electrically, optically, or wirelessly send data to another element or device as well as receive data from another element or device.

[0197] As used herein, the wording “and / or” is intended to represent an inclusive-or. That is, “X and / or Y” is intended to mean X or Y or both, for example. As a further example, “X, Y, and / or Z” is intended to mean X orY or Z or any combination thereof.

[0198] Terms of degree such as "substantially", "about", and "approximately" as used herein mean a reasonable amount of deviation of the modified term such that the result is not significantly changed. These terms of degree may also be construed as including a deviation of the modified term if this deviation would not negate the meaning of the term it modifies.

[0199] Any recitation of numerical ranges by endpoints herein includes all numbers and fractions subsumed within that range (e.g., 1 to 5 includes 1 , 1.5, 2, 2.75, 3, 3.90, 4, and 5). It is also to be understood that all numbers and fractions thereof are presumed to be modified by the term "about" which means a variation of up to a certain amount of the number to which reference is being made if the result is not significantly changed.

[0200] Some elements herein may be identified by a part number, which is composed of a base number followed by an alphabetical or subscript-numerical suffix (e.g., 112a, or 1121). All elements with a common base number may be referred to collectively or generically using the base number without a suffix (e.g., 112).

[0201] The systems and methods described herein may be implemented as a combination of hardware or software. In some cases, the systems and methods described herein may be implemented, at least in part, by using one or more computer programs, executing on one or more programmable devices including at least one processing element, and a data storage element (including volatile and non-volatile memory and / or storage elements). These systems may also have at least one input device (e.g., a pushbutton keyboard, mouse, a touchscreen, and the like), and at least one output device (e.g., a display screen, a printer, a wireless radio, and the like)depending on the nature of the device. Further, in some examples, one or more of the systems and methods described herein may be implemented in or as part of a distributed or cloud-based computing system having multiple computing components distributed across a computing network.

[0202] Some elements that are used to implement at least part of the systems, methods, and devices described herein may be implemented via software that is written in a high-level procedural language such as object-oriented programming language. Accordingly, the program code may be written in any suitable programming language for an operating system. Alternatively, or in addition thereto, some of these elements implemented via software may be written in assembly language, machine language or firmware as needed. In either case, the language may be a compiled or interpreted language.

[0203] At least some of these software programs may be stored on a storage media (e.g., a computer readable medium such as, but not limited to, read-only memory, magnetic disk, optical disc) or a device that is readable by a general or special purpose programmable device. The software program code, when read by the programmable device, configures the programmable device to operate in a new, specific, and predefined manner to perform at least one of the methods described herein.

[0204] Furthermore, at least some of the programs associated with the systems and methods described herein may be capable of being distributed in a computer program product including a computer readable medium that bears computer usable instructions for one or more processors. The medium may be provided in various forms, including non-transitory forms such as, but not limited to, one or more diskettes, compact disks, tapes, chips, and magnetic and electronic storage. Alternatively, the medium may be transitory in nature such as, but not limited to, wire-line transmissions, satellite transmissions, internet transmissions (e.g., downloads), media, digital and analog signals, and the like. The computer usable instructions may also be in various formats, including compiled and non-compiled code.

[0205] While the above description provides examples of one or more processes or systems, it will be appreciated that other processes or systems may be within the scope of the accompanying claims.

[0206] To the extent any amendments, characterizations, or other assertions previously made (in this or in any related patent applications or patents, including any parent, sibling, or child) with respect to any art, prior or otherwise, could be construed as a disclaimer of any subject matter supported by the present disclosure of this application, Applicant hereby rescinds and retracts such disclaimer. Applicant also respectfully submits that any prior art previously considered in any related patent applications or patents, including any parent, sibling, or child, may need to be revisited.

Claims

What is claimed is:1 . An apparatus for controlling access to a kernel driver in an operating system, comprising: a memory storing instructions; and one or more processors coupled to the memory, the one or more processors being configured to execute the instructions to: load a defensive kernel driver; monitor a plurality of loaded kernel drivers; detect a vulnerable kernel driver from amongst the plurality of loaded kernel drivers, and the vulnerable kernel driver matching an entry on a vulnerable kernel driver list; hook the defensive kernel driver into the vulnerable kernel driver; intercept an input / output request packet (IRP) with the defensive kernel driver and evaluate the IRP to determine if it satisfies a safe condition; and after determining the IRP satisfies the safe condition, forward the IRP to the vulnerable kernel driver.

2. The apparatus of claim 1 , wherein the one or more processors are further configured to execute the instructions to: after determining the IRP does not satisfy the safe condition, block the IRP from being sent to the vulnerable kernel driver.

3. The apparatus of claim 1 , further comprising an input / output (IO) manager residing in the memory; the IO manager configured to build and send the IRP to the vulnerable kernel driver; and, after the defensive kernel driver is hooked into the vulnerable kernel driver, the IO manager configured to send the IRP to the defensive kernel driver.

4. The apparatus of claim 3, wherein the IRP comprises data associated with a device input / output control (IOCTL) call, and the defensive kernel driver inspects the data associated with the IOCTL call to evaluate the IRP to determine if it satisfies the safe condition; after the defensive kernel driver determines the IRP satisfies the safe condition, the defensive kernel driver returns the IRP to the IO manager; and the IO manager directly transmits the IRP to the vulnerable kernel driver.

5. The apparatus of claim 1 , wherein the IRP comprises data associated with a device input / output control (IOCTL) call, and the defensive kernel driver inspects the data associated with the IOCTL call to evaluate the IRP to determine if it satisfies the safe condition.

6. The apparatus of claim 5, wherein the data associated with the IOCTL call comprises: an input parameter, and an output parameter when the IOCTL call is permitted.

7. The apparatus of claim 5, wherein the data associated with the IOCTL call comprises a user mode caller, which is retrievable by an Application Programming Interface of the operating system.

8. The apparatus of claim 5, wherein after the defensive kernel driver determines the IRP satisfies the safe condition, the defensive kernel driver is configured to log the IOCTL call to build a known safe baseline.

9. The apparatus of claim 1 , wherein the one or more processors are further configured to execute the instructions to: identify a plurality of vulnerable kernel drivers from amongst the plurality of loaded kernel drivers, wherein the plurality of vulnerable kernel drivers matches a plurality of entries on the vulnerable kernel driver list; hook the defensive kernel driver into each of the plurality of vulnerable kernel drivers; use the defensive kernel driver to intercept and evaluate a plurality of IRPs corresponding respectively to the plurality of vulnerable kernel drivers; and after determining that each of the plurality of IRPs satisfy a plurality of safe conditions respectively associated with the plurality of vulnerable kernel drivers, the defensive kernel driver forwards the plurality of IRPs respectively to the plurality of vulnerable kernel drivers.

10. An apparatus for controlling access to a kernel driver in an operating system, comprising: a memory storing instructions; and one or more processors coupled to the memory, the one or more processors being configured to execute the instructions to: load a defensive kernel driver; hook the defensive kernel driver into a loaded kernel driver; identify a baseline of device input / output control (IOCTL) and / or file system control code (FSCTL) activity by monitoring the loaded kernel driver; detect an anomalous activity of the loaded kernel driver that deviates beyond a threshold of the baseline, and label the loaded kernel as a vulnerable kernel driver; intercept an input / output request packet (IRP) with the defensive kernel driver and evaluate the IRP to determine if it satisfies a safe condition; and, after determining the IRP satisfies the safe condition, forward the IRP to the vulnerable kernel driver.11 . The apparatus of claim 10, wherein the one or more processors are configured to execute the instructions to further: after determining the IRP does not satisfy the safe condition, block the IRP from being sent to the vulnerable kernel driver.

12. A system for controlling access to a kernel driver in an operating system, the system comprising a profiling computer and a plurality of computers that each store thereon a respective instance of a subject kernel driver, and each of the plurality of computers comprising: a network interface; a memory storing instructions; and one or more processors coupled to the memory, the one or more processors being configured to execute the instructions to: load a defensive kernel driver; hook the defensive kernel driver into a loaded instance of the subject kernel driver;use the defensive kernel driver to obtain IOCTL and / or FSCTL activity data associated with the loaded instance of the subject kernel driver, and transmit the IOCTL and / or FSCTL activity data using the network interface to the profiling computer; and, receive from the profiling computer, using the network interface, a baseline derived from at least the IOCTL and / or FSCTL activity data and a threshold of the baseline, wherein, in a given computer of the plurality of computers, the one or more processors in the given computer are configured to execute the instructions to further: detect an anomalous activity of the loaded instance of the subject kernel driver that deviates beyond the threshold of the baseline, and label the loaded instance of the subject kernel driver as a vulnerable kernel driver; intercept an input / output request packet (IRP) with the defensive kernel driver and evaluate the IRP to determine if the IRP satisfies a safe condition; and after determining the IRP satisfies the safe condition, forward the IRP to the vulnerable kernel driver.

13. The system of claim 12, wherein the one or more processors in the given computer are configured to execute the instructions to further: after determining the IRP does not satisfy the safe condition, block the IRP from being sent to the vulnerable kernel driver.

14. The system of claim 12, wherein the profiling computer comprises: a network interface of the profile computer; a memory of the profiling computer storing instructions; and one or more processors of the profiling computer coupled to the memory of the profiling computer, the one or more processors of the profiling computer being configured to execute the instructions to: receive a plurality of instances of the IOCTL and / or FSCTL activity data respectively from the plurality of computers; process the plurality of instances of the IOCTL and / or FSCTL activity data to generate the baseline and the threshold for the baseline; andtransmit the baseline and the threshold of the baseline to each of the plurality of computers.

15. The system of claim 12, wherein the plurality of computers comprises at least one hundred computers.

16. The system of claim 15, wherein the plurality of computers comprises at least one thousand computers.

17. The system of claim 16, wherein the plurality of computers comprises at least ten thousand computers.

18. An apparatus for controlling access to a kernel driver in an operating system, comprising: a memory storing instructions; and one or more processors coupled to the memory, the one or more processors being configured to execute the instructions to: load a defensive kernel driver; hook the defensive kernel driver into each of a plurality of loaded kernel drivers; identify a pattern by monitoring IOCTL and / or FSCTL activity associated with the plurality of loaded kernel drivers; generate a baseline and a threshold of the baseline using the pattern; detect an anomalous activity related to a given loaded kernel driver from amongst the plurality of loaded kernel drivers, the anomalous activity deviating beyond the threshold of the baseline, and label the given loaded kernel driver as a vulnerable kernel driver; intercept an input / output request packet (IRP) with the defensive kernel driver and evaluate the IRP to determine if it satisfies a safe condition; and after determining the IRP satisfies the safe condition, forward the IRP to the vulnerable kernel driver.

19. The apparatus of claim 18, wherein the one or more processors are configured to execute the instructions to further: after determining the IRP does not satisfy the safe condition, block the IRP from being sent to the vulnerable kernel driver.

20. A method for controlling access to a kernel driver in an operating system, the method executed in a computing environment comprising a memory and one or more processors coupled to the memory, the method comprising: loading a defensive kernel driver; monitoring a plurality of loaded kernel drivers; detecting a vulnerable kernel driver from amongst the plurality of loaded kernel drivers, and the vulnerable kernel driver matching an entry on a vulnerable kernel driver list; hooking the defensive kernel driver into the vulnerable kernel driver; intercepting an input / output request packet (IRP) with the defensive kernel driver and evaluate the IRP to determine if it satisfies a safe condition; and after determining the IRP satisfies the safe condition, forwarding the IRP to the vulnerable kernel driver.21 . The method of claim 20, further comprising: after determining the IRP does not satisfy the safe condition, blocking the IRP from being sent to the vulnerable kernel driver.

22. The method of claim 20, further comprising an input / output (IO) manager building and sending the IRP to the vulnerable kernel driver; and, after the defensive kernel driver is hooked into the vulnerable kernel driver, the IO manager sending the IRP to the defensive kernel driver.

23. The method of claim 22, wherein the IRP comprises data associated with a device input / output control (IOCTL) call, and the method further comprising: the defensive kernel driver inspecting the data associated with the IOCTL call to evaluate the IRP to determine if it satisfies the safe condition; after the defensive kernel driver determines the IRP satisfies the safe condition, the defensive kerneldriver returning the IRP to the IO manager; and the IO manager directly transmitting the IRP to the vulnerable kernel driver.

24. The method of claim 20, wherein the IRP comprises data associated with a device input / output control (IOCTL) call, and the method further comprising: the defensive kernel driver inspecting the data associated with the IOCTL call to evaluate the IRP to determine if it satisfies the safe condition.

25. The method of claim 24, wherein data associated with the IOCTL call comprises: an input parameter, and an output parameter when the IOCTL call is permitted.

26. The method of claim 24, wherein the data associated with the IOCTL call comprises a user mode caller, which is retrievable by an Application Programming Interface of the operating system.

27. The method of claim 24, wherein after the defensive kernel driver determines the IRP satisfies the safe condition, the defensive kernel driver logs the IOCTL call to build a known safe baseline.

28. The method of claim 20, further comprising: identifying a plurality of vulnerable kernel drivers from amongst the plurality of loaded kernel drivers, wherein the plurality of vulnerable kernel drivers matches a plurality of entries on the vulnerable kernel driver list; hooking the defensive kernel driver into each of the plurality of vulnerable kernel drivers; using the defensive kernel driver to intercept and evaluate a plurality of IRPs corresponding respectively to the plurality of vulnerable kernel drivers; and after determining that each of the plurality of IRPs satisfy a plurality of safe conditions respectively associated with the plurality of vulnerable kernel drivers, the defensive kernel driver forwarding the plurality of IRPs respectively to the plurality of vulnerable kernel drivers.

29. A method for controlling access to a kernel driver in an operating system, the method executed in a computing environment comprising a memory and one or more processors coupled to the memory, the method comprising: loading a defensive kernel driver; hooking the defensive kernel driver into a loaded kernel driver; identifying a baseline of device input / output control (IOCTL) and / or file system control code (FSCTL) activity by monitoring the loaded kernel driver; detecting an anomalous activity of the loaded kernel driver that deviates beyond a threshold of the baseline, and labelling the loaded kernel as a vulnerable kernel driver; intercepting an input / output request packet (IRP) with the defensive kernel driver and evaluating the IRP to determine if it satisfies a safe condition; and, after determining the IRP satisfies the safe condition, forwarding the IRP to the vulnerable kernel driver.

30. The method of claim 29, further comprising: after determining the IRP does not satisfy the safe condition, blocking the IRP from being sent to the vulnerable kernel driver.31 . A method for controlling access to a kernel driver in an operating system, the method executable by a system comprising a profiling computer and a plurality of computers that each store thereon a respective instance of a subject kernel driver, and the method comprising: each of the plurality of computers performing: loading a defensive kernel driver; hooking the defensive kernel driver into a loaded instance of the subject kernel driver; using the defensive kernel driver to obtain IOCTL and / or FSCTL activity data associated with the loaded instance of the subject kernel driver, and transmitting the IOCTL and / or FSCTL activity data to the profiling computer; and, receiving from the profiling computer, using the network interface, a baseline derived from at least the IOCTL and / or FSCTL activity data and athreshold of the baseline, wherein, in a given computer of the plurality of computers, the method further comprises: detecting an anomalous activity of the loaded instance of the subject kernel driver that deviates beyond the threshold of the baseline, and label the loaded instance of the subject kernel driver as a vulnerable kernel driver; intercepting an input / output request packet (IRP) with the defensive kernel driver and evaluating the IRP to determine if the IRP satisfies a safe condition; and after determining the IRP satisfies the safe condition, forwarding the IRP to the vulnerable kernel driver.

32. The method of claim 31 , further comprising: the given computer, after determining the IRP does not satisfy the safe condition, blocking the IRP from being sent to the vulnerable kernel driver.

33. The method of claim 31 , further comprising: the profiling computer performing: receiving a plurality of instances of the IOCTL and / or FSCTL activity data respectively from the plurality of computers; processing the plurality of instances of the IOCTL and / or FSCTL activity data to generate the baseline and the threshold for the baseline; and transmitting the baseline and the threshold of the baseline to each of the plurality of computers.

34. The method of claim 31 , wherein the plurality of computers comprises at least one hundred computers.

35. The method of claim 34, wherein the plurality of computers comprises at least one thousand computers.

36. The system of claim 35, wherein the plurality of computers comprises at least ten thousand computers.

37. A method for controlling access to a kernel driver in an operating system, the method executed in a computing environment comprising a memory and one or more processors coupled to the memory, the method comprising: loading a defensive kernel driver; hooking the defensive kernel driver into each of a plurality of loaded kernel drivers; identifying a pattern by monitoring IOCTL and / or FSCTL activity associated with the plurality of loaded kernel drivers; generating a baseline and a threshold of the baseline using the pattern; detecting an anomalous activity related to a given loaded kernel driver from amongst the plurality of loaded kernel drivers, the anomalous activity deviating beyond the threshold of the baseline, and label the given loaded kernel driver as a vulnerable kernel driver; intercepting an input / output request packet (IRP) with the defensive kernel driver and evaluate the IRP to determine if it satisfies a safe condition; and after determining the IRP satisfies the safe condition, forwarding the IRP to the vulnerable kernel driver.

38. The method of claim 37, further comprising: after determining the IRP does not satisfy the safe condition, blocking the IRP from being sent to the vulnerable kernel driver.

Images