{ "id": "aa0ca61f-ee7b-4170-b310-e06bddc64f4b", "created_at": "2026-04-06T00:17:21.899762Z", "updated_at": "2026-04-10T03:31:18.997638Z", "deleted_at": null, "sha1_hash": "dfb02b2ef1dc47514a55bcc2bcec1c96cb2b3af5", "title": "Signed kernel drivers – Unguarded gateway to Windows’ core", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 751824, "plain_text": "Signed kernel drivers – Unguarded gateway to Windows’ core\r\nBy Michal Poslušný\r\nArchived: 2026-04-05 16:26:33 UTC\r\nThere are various types of kernel drivers; the first that come to mind are device drivers that provide a software\r\ninterface to hardware devices like plug and play interfaces or filter drivers. These low-level system components\r\nhave a strict development process including scrutiny regarding security. However, there are additional “software”\r\ndrivers that are designed to run in Ring 0 and provide specific, non-hardware related features like software\r\ndebugging and diagnostics, system analysis, etc. As you can see below, these are prone to extend the attack surface\r\nsignificantly.\r\nWhile directly loading a malicious, unsigned driver is no longer possible in the newer versions of Windows\r\n(unless driver signature enforcement is explicitly disabled during boot) and kernel rootkits are considered to be a\r\nthing of the past, there are still ways to load malicious code into the kernel. While actual vulnerabilities and\r\nexploits that achieve that get a lot of attention, there is a much easier way: abusing legitimate, signed drivers.\r\nThere are many drivers from various hardware and software vendors lying around that offer functionality to fully\r\naccess the kernel with minimal effort.\r\nVulnerabilities in signed drivers are mostly utilized by game cheat developers to circumvent anti-cheat\r\nmechanisms, but they have also been observed being used by several APT groups and in commodity malware\r\nalike.\r\nThis paper discusses the types of vulnerabilities that commonly occur in kernel drivers, provides several case\r\nstudies of malware utilizing such vulnerable drivers, analyzes examples of vulnerable drivers that we discovered\r\nduring our research, and outlines effective mitigation techniques against this type of exploitation. While this\r\nproblem is not new and relevant research about the topic has been presented in the past, mainly during 2018 and\r\n2019 ([1], [2], [3]), it is still a problem as of this writing.\r\nCommon types of driver vulnerabilities\r\nWhile every vulnerability is different, similar types of vulnerabilities seem to be recurrent in unrelated kernel\r\ndrivers. This may be partially caused by (ancient) driver code samples that were created back when access to\r\nkernel mode was not restricted to signed drivers and developers did not take security into consideration (malware\r\ncould simply load unsigned rootkit drivers instead). The following sections describe the vulnerabilities most\r\nfrequently observed in drivers from a large variety of, and even high-profile, hardware and software vendors.\r\nMSR read/write\r\nModel-specific registers (MSRs) were introduced in Pentium 80586 CPUs in 1993. MSRs can be thought of as\r\n“global variables” of a CPU (or of a specific core). Some contain various information about the processor or\r\nspecific CPU core – such as temperature, power, …. Additionally, there are also many MSRs that contain data\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 1 of 22\n\ncritical for the working of a system, such as IA32_LSTAR (0xC0000082) for SYSCALL or\r\nIA32_SYSENTER_EIP (0x00000176) for SYSENTER, both of which contain pointers to an address in the kernel\r\nwhere the CPU jumps when a SYSCALL or SYSENTER instruction is executed. On newer Windows x64\r\nplatforms such as Windows 10 or 11, SYSCALL is used for both AMD and Intel CPUs where IA32_LSTAR\r\nshould point to the KiSystemCall64 function found in ntoskrnl.exe. The mechanism of the transition to Windows\r\nkernel when executing SYSCALL is displayed in Figure 1.\r\nFigure 1. How SYSCALL is handled in x64 Windows\r\nMSRs are indexed by a number and accessed by the privileged RDMSR and WRMSR instructions, which can only\r\nbe executed in kernel mode. Many commercial drivers implement functionality for user-mode applications to\r\naccess these instructions through an IOCTL mechanism. This is usually intended to be able to read or write a few\r\nspecific innocent MSRs (like CPU voltage, temperature, …), but developers sometimes do not add any additional\r\nchecks to restrict access to critical MSRs, such as the example seen in Figure 2. This gives potential attackers an\r\nopportunity to, for example, patch the SYSCALL/SYSENTER entry point MSRs, which are pointers to a function\r\nthat handles any system call from user mode.\r\nFigure 2. Vulnerable MSR IOCTL handler in the AMDPowerProfiler.sys driver\r\nOverwriting the system call pointer was trivial and very powerful on older CPUs and systems before mitigations\r\nlike Supervisor Mode Execution Prevention (SMEP) were introduced. On such systems, simply changing the\r\npointer to the address of an arbitrary user-mode executable buffer containing malicious code, and then\r\nimmediately executing a system call instruction on a same CPU core, was enough to gain kernel-level code\r\nexecution. This is no longer the case with newer systems due to modern exploitation mitigations. That being said,\r\nwith clever use of various techniques, it is still possible to bypass most of these mitigations and achieve kernel-level code execution on Windows 10 or even brand-new Windows 11 systems (as of December 2021).\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 2 of 22\n\nAll the mitigations in the following sections are in place on most modern machines and need to be bypassed to\r\nachieve successful kernel-mode exploitation.\r\nSMEP\r\nSMEP is a protection mechanism introduced in 2011 in Intel processors based on the Ivy Bridge architecture and\r\nenabled by default since Windows 8.0. It prevents execution of code in user-mode pages from Ring 0, and is\r\nimplemented by assigning a user-mode or kernel-mode value to a flag bit on every virtual memory page in the\r\npage table. If a system attempts to execute code in a user-mode page from kernel space, a 0x000000FC error\r\n(ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY) will be triggered and cause a BSOD. SMEP can be\r\ndynamically toggled on and off during execution with its status saved in the CR4 register for each CPU core\r\nindividually (see Figure 3).\r\nFigure 3. CR4 register flags of a CPU (image credit: Wikipedia)\r\nSMEP mitigates the naïve exploitation technique of abusing an MSR R/W IOCTL in order to change the LSTAR\r\nMSR to point directly to malicious user-mode code. That being said, since the attacker is in control of the stack\r\nthat is passed to kernel mode on system calls, they may utilize a technique called a ROP chain to manipulate the\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 3 of 22\n\nstack. By placing a chain of return addresses on the stack, the attacker can arrange to execute a carefully picked\r\nset of instructions in kernel mode by changing the LSTAR MSR via a vulnerable IOCTL. With the stack suitably\r\nprepared, executing the system call instruction results in the first “gadget” in the ROP chain executing and when\r\ncomplete its code will “return” to the next gadget in the chain, which was supplied on the stack with the rest of the\r\nchain.\r\nThe functionality of such a ROP chain is limited by the availability of suitable code chunks, called gadgets,\r\navailable in the kernel’s modules. Since an attacker can read kernel modules from the file system and knows at\r\nwhich addresses the modules are loaded, the gadgets can be easily looked up and if those gadgets exist, a working\r\nROP chain can then be constructed.\r\nTo properly initialize the transition to kernel, the ROP chain needs to swap the GS register using the SWAPGS\r\ninstruction. On 64-bit Windows, the GS register holds the address of the Thread Environment Block (TEB) in user\r\nmode, and the address of the Kernel Processor Control Region (KPCR) in kernel mode. Therefore, it is crucial that\r\nthose two addresses change before any operations happen in the kernel. It is no surprise that the SWAPGS\r\ninstruction is also the first instruction in the Windows kernel KiSystemCall64 function.\r\nThe next step is restoring the original value of the LSTAR MSR using the WRMSR instruction, in order to avoid\r\nexecuting the ROP chain on the next execution of the SYSCALL instruction.\r\nAt this point, the malicious code properly executes in the kernel and the attacker can execute whatever payload is\r\ndesired. This can be additional ROP gadgets to, for example, disable SMEP or SMAP protections by overwriting\r\nCR4, or even be direct calls to an exported ntoskrnl API function.\r\nThe attacker can overwrite CR4 utilizing a MOV CR4 gadget to disable SMEP and also SMAP, which is covered\r\nin the next section. They then can proceed to execute a user-mode payload directly. The only difficulty with this\r\napproach is precalculating a valid CR4 value. Although most of the CR4 values can be guessed from user mode by\r\nrunning the CPUID instruction, there may be some inconsistencies between different versions of Windows.\r\nTo transition back to user mode safely, once the attacker’s ROP chain has run they need to execute the SWAPGS\r\ninstruction again and then execute the SYSRET instruction.\r\nOlder exploits bypassing SMEP are described in [4], (2015).\r\nSMAP\r\nSupervisor Mode Access Prevention (SMAP) is a newer mitigation that has been introduced to complement SMEP\r\nand further restrict access from the kernel to user-mode pages – it disallows both reads and writes. Just as SMEP,\r\nits status is stored as a bit in the CR4 register (see Figure 3).\r\nSMAP should render the previously described ROP chain technique useless, since the stack containing the ROP\r\nchain is in fact a user-mode page. A system with SMAP active will bluescreen the moment it tries to access the\r\nstack after transitioning to the kernel via the system call.\r\nSMAP can also be temporarily disabled by setting the AC flag in the EFLAGS CPU register. This feature is also\r\nthe downfall of this mitigation in regard to MSR exploitation – it turns out the AC flag can be set from user mode,\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 4 of 22\n\nright before transitioning to kernel mode, by utilizing the POPF and PUSHF instructions. This is caused by the\r\nSFMASK MSR that controls which EFLAGS register bits are cleared when the SYSCALL instruction is executed.\r\nEven on the newest Windows 11 machines, the mask does not have the AC flag bit set, which means it is not\r\ncleared upon transitioning to the kernel so SMAP can be disabled by the user.\r\nAs the SFMASK is controlled by another MSR (0xC0000084), even if Microsoft changed SFMASK to implicitly\r\nclear the AC flag, theoretically the attacker could patch this MSR prior to the exploitation anyway.\r\nIt is worth noting that SMAP has only recently been enabled by default in Windows 10 x64 with newer hardware.\r\nKVA shadowing\r\nKVA shadowing was introduced as a software mitigation for the Meltdown CPU vulnerability discovered at the\r\nend of 2017.\r\nThe basic idea of this mitigation is that the virtual address space is split into two – user mode and kernel mode.\r\nThe user-mode address space has access only to very restricted parts of the ntoskrnl module, specifically a single\r\ncode section called .KVASCODE that is responsible for low-level operations like entering and leaving the kernel\r\nwhen handling a system call. This is handled by implementing “Shadow” equivalents of the responsible functions,\r\nlike KiSystemCall64Shadow that works as the original KiSystemCall64, but contains differences responsible for\r\nhandling KVA shadowing and switching the address space context properly (see Figure 4). The rest of the kernel is\r\ncompletely separated and mapped to its own address space and cannot be accessed even directly by the CPU from\r\nuser-mode address space until the context is appropriately switched.\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 5 of 22\n\nFigure 4. Comparison of KiSystemCall64 and KiSystemCall64Shadow versions of the system call handler – minor\r\ndifferences can be spotted at the beginning of the function\r\nWhile KVA shadowing was designed as a fix for the Meltdown vulnerability, it also potentially causes trouble for\r\nother kinds of vulnerabilities, including the MSR one.\r\nThere are generally two approaches to disable the mitigation – one is to disable it as a setting in the registry. This\r\nrequires admin access and a reboot afterwards for the changes to take effect.\r\nAlternatively, when building a ROP chain for MSR exploitation, an attacker tries to find gadgets exclusively in the\r\n.KVASCODE section of the ntoskrnl module – since that section handles the system call transition, it is possible to\r\nbuild a working ROP chain.\r\nSimilar mitigation was also introduced in Linux systems, where it is called Kernel Page Table Isolation (KPTI).\r\nPhysical memory read/write\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 6 of 22\n\nBeing able to directly read and write physical memory seems to be a common feature in many low-level kernel\r\ndrivers. This is achieved by mapping a specific range of physical memory to a virtual memory buffer that can be\r\nread or written and even passed to a user-mode application. There are several ways to achieve this, the most\r\ncommon one being an ability to map the \\Device\\PhysicalMemory section to virtual memory, as shown in Figure\r\n5.\r\nFigure 5. Physical memory map vulnerability in Passmark DirectIO64.sys driver\r\nA potential drawback for the attackers is that they first need to translate the virtual address to a physical one.\r\nDrivers that implement physical memory I/O sometimes also offer an IOCTL for physical to virtual address\r\ntranslation, but even if the driver does not have any such address conversion, there are still many ways to utilize\r\nthis feature.\r\nThe most straightforward use case is simply to walk through all the physical memory looking for specific artifacts\r\nthat represent critical data structures that the attacker wants to find. For example, the attacker might try to look for\r\nthe EPROCESS structure of the malicious process and elevate it to SYSTEM privileges by stealing a token from a\r\nmore privileged process or modifying its rights. Some of these strategies are demonstrated here and here.\r\nSince physical memory mappings disregard any virtual memory protection features, it is also possible to write to\r\nexecutable memory pages. This gives the attacker an opportunity to look up specific kernel modules and chunks of\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 7 of 22\n\ncode, carefully modify them and, if patched code can be executed via a system API or an IOCTL of a driver, to\r\nachieve malicious kernel-level code execution.\r\nVirtual memory read/write\r\nVirtual memory access IOCTLs are not as commonly found in these drivers as physical memory ones, but they\r\nhave very similar repercussions. Utilizing these is even easier, as there is no address translation needed and all the\r\nvirtual kernel addresses found from user mode can be accessed directly. A potential downside is that the access is\r\nlimited by the memory protection of the target address, so it is not possible to write read-only memory pages\r\nwithout changing the protection first.\r\nTherefore, this vulnerability is commonly used to manipulate various kernel data structures to achieve things like\r\nelevating a malicious process to SYSTEM rights by stealing tokens from such kernel structures.\r\nThe most common way this vulnerability arises is via an IOCTL with a simple pointer dereference in kernel mode,\r\nso it can be hard to detect this vulnerability using heuristic methods.\r\nCase studies\r\nWhen malware actors need to run malicious code in the Windows kernel on x64 systems with driver signature\r\nenforcement (DSE) in place, carrying a vulnerable signed kernel driver seems to be a viable option for doing so.\r\nThis technique is known as Bring Your Own Vulnerable Driver (BYOVD) and has been observed being used in\r\nthe wild by both high-profile APT actors and in commodity malware.\r\nIn the following sections we present some examples.\r\nSlingshot APT\r\nSlingshot is a cyberespionage platform that was uncovered by Kaspersky in 2018 [5] and is believed to have been\r\nactive since at least 2012. The actors behind this malware decided to implement their main module, called\r\nCahnadr, as a kernel-mode driver. On older x86 systems, the driver would be loaded directly by the user-mode\r\nmodule. On newer systems with active DSE, they decided to implement a custom driver loader that leverages the\r\nfollowing signed kernel drivers with MSR vulnerabilities: Goad, SpeedFan (CVE-2007-5633), Sandra (CVE-2010-1592), and ElbyCDIO (CVE-2009-0824). The exploitation targeted pre-Windows 8 systems, so the\r\nexploitation was a simple modification of the LSTAR MSR to point to a malicious payload in a user-mode buffer.\r\nNote that the Kaspersky researchers estimated these threat actors to have been active from 2012 to 2018, which\r\nmeans that these exploits were quite old and well known, but that was no reason for the attackers to stop using\r\nthem as the certificates of those vulnerable drivers were never revoked.\r\nInvisiMole\r\nIn 2018, fellow ESET researchers uncovered a sophisticated APT actor that they named InvisiMole [6]. The group\r\nhas been tracked by ESET ever since and in 2020 an extensive white paper about the group and its toolset was\r\npublished. In that white paper, our colleagues reported that InvisiMole used the BYOVD technique, exploiting the\r\nMSR vulnerability in the speedfan.sys driver (CVE-2007-5633) to load a malicious unsigned driver. While this\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 8 of 22\n\ncampaign was targeting older x86 systems and the exploitation using a malicious driver was trivial from the\r\nmodern standpoint, due to the fact there were no mitigations like SMEP in place, it was still an interesting case\r\nshowing that the group behind this malware is very technically capable.\r\nLater during that investigation, however, a newer variant of the InvisiMole malware using the BYOVD technique\r\nwas discovered. This variant is the only case to date that we have observed of MSR exploitation on Windows 10\r\nx64 systems being used in the wild by a malicious actor. It employs advanced techniques to bypass mitigations\r\nlike SMEP and even SMAP. That being said, the exploitation is mitigated by KVA shadowing, which the authors\r\nfailed to take care of. Coincidentally, MSR exploitation was used to deploy a malicious driver that attempted to\r\ndisable our security products. Although the whole compromise chain is more extensive, we will focus on a\r\nspecific part of the malware that leverages the BYOVD technique and MSR exploitation that happens in the main\r\nuser-mode module.\r\nUser-mode module\r\nInvisiMole’s authors seem to have developed a sophisticated ROP chain exploitation framework that they use for\r\nMSR exploitation – although the sample contains many debug messages in the code, we were not able to identify\r\nand link them to any known projects. This leads us to believe the framework is an original work of these malware\r\nauthors and that non-negligible resources have been spent on developing it. The framework is an extensive C++\r\ncodebase with various classes.\r\nIt appears that InvisiMole’s authors did not know about the possibility of setting the AC flag with the PUSHF and\r\nPOPF instructions as described in the SMAP section, and instead chose a very complex ROP gadget found in the\r\nMiDbgCopyMemory kernel function that starts with the privileged STAC instruction, which is dedicated to setting\r\nthe AC flag (see Figure 6). On top of that, InvisiMole utilizes the IRETQ instruction after every gadget that\r\nexplicitly sets the RFLAGS register with the AC flag set, which stabilizes the exploit even further.\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 9 of 22\n\nFigure 6. ROP gadget used by InvisiMole to disable SMAP mitigation\r\nThe initial gadget jumps directly to the STAC instruction, which immediately disables SMAP by setting the AC\r\nflag. Since this gadget appears in the middle of the MiDbgCopyMemory function, the malware carefully prepares\r\nthe stack and registers to safely leave the function. Once the MiDbgCopyMemory function returns, the ROP chain\r\nproceeds to the SWAPGS gadget [7] in order to properly switch to kernel mode, followed by the WRMSR gadget\r\nto set the LSTAR MSR back to its original value. At this point, InvisiMole will proceed with executing the\r\npayload, which may be an exported kernel function or the entry point of a loaded malicious driver.\r\nDriver loader\r\nThe driver loading technique is quite complex – InvisiMole will first install a “driver loader” – another kernel\r\ndriver module that is used to load the malicious payload (yet another driver) passed as an argument. To initialize\r\nthe driver loader, InvisiMole executes several separate MSR exploitations, where every instance carries a\r\ndedicated ROP chain with a single API call payload. The malware will start by executing ExAllocatePoolWithTag\r\nto allocate an executable kernel memory buffer for the loader, followed by preparing the image in user mode to\r\nreflect its future address in the kernel – sections are moved to their virtual offsets; imports are resolved, and\r\nrelocations fixed. Once the image is ready, it is copied over from user mode to the allocated kernel buffer using\r\nmemcpy from the ntoskrnl module.\r\nTo transfer code execution to the loader once it is copied to the kernel, InvisiMole’s authors also leverage the\r\nMSR vulnerability and designed several dedicated PE exports in the loader (see Figure 7 for an example) that are\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 10 of 22\n\nintended to handle transitions from user-mode system calls. It works very similarly to the ROP chain gadgets –\r\nswap the GS register, swap the user-mode and kernel-mode stacks, save all registers on the stack, restore the\r\noriginal LSTAR MSR value and then call the actual function. Once finished, this process is reversed.\r\nFigure 7. Exported function in the driver loader module that is called by changing LSTAR MSR\r\nWhen the loader is properly initialized in the kernel, an export named _Start64 is executed by changing LSTAR\r\nMSR to the export address in the kernel. After handling the transition to the kernel, _Start64 registers a deferred\r\nroutine that is responsible for loading the payload driver, and returns to user mode. The deferred loader routine\r\nwill attempt to initialize the payload driver in a “proper” fashion – creating registry keys and kernel driver objects,\r\nperforming all the necessary steps to register the driver in the system as if the operating system were loading the\r\ndriver itself, and eventually calling IoCreateDriver. The proper initialization approach was chosen so the loaded\r\npayload driver can process I/O request packets and communicate with a user-mode module using IOCTLs.\r\nPayload driver\r\nThe payload driver offers IOCTL functionality for disabling various notification callbacks (see Figure 8), mostly\r\naimed at disarming third-party security solutions, and the possibility of protecting a file in the file system. The\r\nspecific commands are passed from the user-mode module. Interestingly, the user-mode module will attempt to\r\ndisable various parts of ESET protection in the kernel.\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 11 of 22\n\nFigure 8. IOCTL handler in the InvisiMole payload driver\r\nRobbinHood\r\nSeeing a BYOVD technique in commodity malware that aims to reach as many people as possible is rare, but the\r\nRobbinHood ransomware family shows that it may still prove useful [8].\r\nThis ransomware leverages a vulnerable GIGABYTE motherboard driver GDRV.SYS (CVE-2018-19320; see\r\nFigure 9 and Figure 10) to disable DSE in order to install its own malicious driver.\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 12 of 22\n\nFigure 9. GIODrv driver exploitation in RobbinHood sample\r\nThe way DSE is disabled depends on the Windows version – on Windows 7 and older, an nt!g_CiEnabled variable\r\nis modified directly in the ntoskrnl module. On newer Windows 8 through Windows 11 systems, the variable\r\nci!g_CiOptions in the ci.dll module is modified instead. Finding this variable is slightly more complicated and it\r\nlooks like the authors adopted a method found in an open-source project called DSEFix that is available on\r\nGitHub. Moreover, since Windows 8.1, the variables in ci.dll are protected by PathcGuard and tampering with the\r\nmodule will eventually cause the system to BSOD, even if the variable is changed back to an original value.\r\nThe malicious driver is then used to kill a long list of processes and delete their files, mainly focusing on endpoint\r\nprotection software and other utilities. Since the termination is done from kernel mode, most self-protection\r\nmechanisms employed by security software are circumvented and the technique is more likely to succeed than\r\nattempting to disarm the protections from user mode.\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 13 of 22\n\nFigure 10. WriteVirtualMemory IOCTL handler in GIODrv\r\nLoJax\r\nIn 2018, ESET researchers discovered the first-ever UEFI rootkit used in the wild. In order to have access to\r\nvictims’ UEFI modules, the malware utilizes a powerful utility called RWEverything.\r\nThe RWEverything driver was recently disabled by Microsoft directly in Windows 10 and 11 using the HVCI\r\nmemory integrity feature described in the Virtualization-based security section.\r\nDiscovered vulnerabilities\r\nDuring our research we decided not only to catalog existing vulnerabilities, but also to look for new ones. We set\r\nup YARA rules to hunt for kernel drivers with specific functionality and indicators of being potentially vulnerable.\r\nWe also created a proof-of-concept exploitation framework for testing the newly found drivers and confirming\r\nthat they are exploitable.\r\nWe went through hundreds of different kernel drivers that matched our criteria and aside from finding the already\r\ndiscovered drivers, we also found three drivers previously not known to be vulnerable, some containing several\r\nunrelated bugs. The fact that even after several independent research groups tackled this area we were still able to\r\nfind new vulnerabilities, even from reputable vendors, shows that Windows driver security is still an issue.\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 14 of 22\n\nWhile we were looking for all kinds of vulnerabilities described in previous sections, finding ones with MSR\r\naccess turned out to be the easiest, appearing most commonly due to the use of special privileged instructions\r\n(RDMSR/WRMSR) that give away this functionality. Interestingly enough, in many cases it would turn out that\r\nthis class of drivers also contained other kinds of vulnerabilities like arbitrary physical or virtual memory read and\r\nwrite functions.\r\nAMD μProf (CVE-2021-26334)\r\nWe have identified an MSR vulnerability in the AMDPowerProfiler.sys kernel driver, which is a part of\r\nAMD μProf profiling software.\r\nWhat makes this driver stand out is that once the underlying software package is installed, the driver runs on every\r\nsystem boot. The unfiltered MSR IOCTL access combined with the lack of FILE_DEVICE_SECURE_OPEN\r\nflags (see Figure 11) and on-boot presence gives the attacker a good opportunity to exploit the driver even as an\r\nunprivileged user – this is an advantage compared to the BYOVD approach when the attacker needs to load the\r\ndriver themselves.\r\nFigure 11. AMD uProf kernel driver device creation without the FILE_DEVICE_SECURE_OPEN flag allowing\r\nnon-admin access\r\nOn the other hand, the software is a niche utility for developers and not a package distributed to a large number of\r\nsystems. We have not identified any other vulnerability in the driver.\r\nThe vulnerable IOCTL is IOCTL_ACCESS_MSR (0x222030).\r\nAMD acknowledged the vulnerability (CVE-2021-26334) and released a fix in the November 2021 Patch Tuesday\r\nrelease.\r\nPassmark software\r\nPassmark is a company offering various computer benchmark and diagnostic tools. To achieve such functionality\r\nin user mode, a lot of low-level system features need to be accessed by leveraging a kernel-mode driver.\r\nPassmark’s DirectIo32.sys and DirectIo64.sys kernel drivers are a common framework shared and distributed\r\namong several of the vendor’s applications – namely BurnInTest, PerformanceTest and OSForensics.\r\nThe driver contains direct, unfiltered MSR R/W access (CVE-2020-15480), an ability to map physical memory\r\n(CVE-2020-15481) for both reading and writing, and the IOCTL handler also contains a buffer overflow (CVE-https://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 15 of 22\n\n2020-15479) due to blindly copying, without any size check, an IOCTL input buffer of arbitrary size to a local\r\nvariable on the stack.\r\nPassmark acknowledged these vulnerabilities and released a fixed version soon thereafter.\r\nCVE-2020-15479\r\nWhen the driver receives an IOCTL request from a user-mode program, it will first copy the requested input\r\nbuffer into a local buffer on the stack. The size of the memmove is based only on the size of the input buffer (see\r\nFigure 12) and does not consider the capacity of the stack buffer. This may lead to a buffer overflow, if a large\r\nenough IOCTL buffer is provided. There are multiple unchecked memmove calls in the IOCTL handler function\r\nand several IOCTLs can be used to leverage the buffer overflow.\r\nFigure 12. Buffer overflows in the vulnerable Passmark drivers\r\nCVE-2020-15480\r\nThis driver offers RDMSR and WRMSR functionality exposed via an IOCTL that allows an unprivileged user-mode program to read and write arbitrary CPU MSRs without any additional checks. The vulnerable IOCTLs are\r\nIOCTL_READ_MSR (0x80112060) and IOCTL_WRITE_MSR (0x80112088).\r\nCVE-2020-15481\r\nPhysical memory mapping functionality is exposed via a single control code –\r\nIOCTL_MAP_PHYSICAL_MEMORY (0x80112044). The implementation is split into two parts: the primary\r\nversion is done through the ZwMapViewOfSection API; if for some reason this method fails, the function also\r\nimplements a secondary approach as a backup, through the MmMapIoSpace and MmMapLockedPages kernel\r\nAPIs. Both are illustrated in Figure 13.\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 16 of 22\n\nFigure 13. Physical memory IOCTL implementation in Passmark's drivers\r\nDevid Espenschied PC Analyser\r\nPC Analyser is another utility for inspecting various details about the machine. The PCADRVX64.sys kernel\r\ndriver distributed with the application contains two separate vulnerabilities – unfiltered MSR access (CVE-2020-\r\n28921) and ability to read from and write to arbitrary physical memory addresses (CVE-2020-28922). When\r\ncreating the driver device, the FILE_DEVICE_SECURE_OPEN flag is unspecified, allowing unprivileged users\r\nto retrieve a handle to the driver.\r\nDevid Espenschied acknowledged the vulnerabilities and released an updated version.\r\nCVE-2020-28921\r\nAs with previous drivers, MSR access is unrestricted (see Figure 14) and the IOCTL code handler contains\r\nFILE_ANY_ACCESS flags allowing even an unprivileged user to leverage the functionality.\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 17 of 22\n\nFigure 14. MSR IOCTL implementation in PC Analyser driver\r\nCVE-2020-28922\r\nThe driver’s physical memory read and write functionality is implemented with separate IOCTLs based on the\r\nsize of the read or write request. It offers the following control codes, none of which make any checks on the\r\nmemory addresses targeted by the request:\r\nIOCTL_READ_PHYSICAL_MEMORY_BYTE (0x82002400)\r\nIOCTL_READ_PHYSICAL_MEMORY_WORD (0x82002500)\r\nIOCTL_READ_PHYSICAL_MEMORY_DWORD (0x82002600)\r\nIOCTL_WRITE_PHYSICAL_MEMORY_BYTE (0x82002700)\r\nIOCTL_WRITE_PHYSICAL_MEMORY_WORD (0x82002800)\r\nIOCTL_WRITE_PHYSICAL_MEMORY_DWORD (0x82002900)\r\nMitigations\r\nWhile we have already mentioned several mechanisms employed by the CPU and/or the operating system, most of\r\nthem can be bypassed with some clever techniques and are not very effective if the attacker prepares for them\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 18 of 22\n\nahead of time. In this section we would like to mention some mitigation ideas that are actually effective at\r\ncompletely stopping the abuse of vulnerable drivers.\r\nVirtualization-based security\r\nVirtualization-based security or VBS is a feature introduced in Windows 10 that leverages hardware virtualization\r\nand makes the kernel sandboxed by a hypervisor in order to secure the operating system with various protections.\r\nVBS offers several protection features with the most prominent one being Hypervisor-Protected Code Integrity\r\n(HVCI), which also comes as a standalone feature. HVCI enforces code integrity in the kernel and allows only\r\nsigned code to be executed. It also employs blocklisting functionality, where a known piece of code signed by a\r\nspecific, valid signature can be blocklisted and not allowed to be run or to be loaded. One of the drivers that has\r\nbeen blocklisted already via this method is the RWEverything utility.\r\nHVCI effectively prevents vulnerable drivers from being abused to execute unsigned kernel code or load\r\nmalicious drivers (regardless of the exploitation method used) and it seems that malware abusing vulnerable\r\ndrivers to load malicious code was one of the main motivations behind Microsoft implementing this feature:\r\nVBS provides significant security gains against practical attacks including several we saw last year, including\r\nhuman-operated ransomware attacks like RobbinHood and sophisticated malware attacks like Trickbot, which\r\nemploy kernel drivers and techniques that can be mitigated by HVCI. Our research shows that there were 60%\r\nfewer active malware reports from machines reporting detections to Microsoft 365 Defender with HVCI enabled\r\ncompared to systems without HVCI. The Surface Book 3 shipped in May 2020 and the Surface Laptop Go\r\nshipped in October 2020, and users may not have noticed they are running VBS and are therefore better protected\r\nbased on the work done under the hood. [emphasis added]\r\nAside from enforcing kernel code integrity, VBS also secures important MSRs and disallows any changes to them.\r\nUnsurprisingly, this protection also affects the LSTAR MSR and mitigates all of the exploitation possibilities\r\ndescribed above.\r\nWhile VBS is an effective protection against MSR exploitation and running malicious code in the kernel in\r\ngeneral, the adoption of this new feature is quite limited, as it has several hardware requirements that only newer\r\nmachines can fulfill. There are also some drawbacks with the most notable being a performance hit, which may be\r\nquite noticeable depending on the workload. While some benchmarks estimate the performance hit being as high\r\nas 25% in specific video games, the more detailed benchmarking by Tom’s Hardware estimates the performance\r\nhit being around 5% depending on the specific benchmarks and hardware configuration (see Figure 15), which is\r\nstill not a negligible amount and may lead some users to consider turning this feature off. There might also be\r\nsome compatibility issues with legacy drivers and software. With the release of Windows 11, Microsoft has\r\ndecided to enable HVCI by default for all compatible devices.\r\nThird-party hypervisor\r\nSimilar to Microsoft’s VBS, with new enough hardware, a third-party security solution may deploy its own\r\ncustom hypervisor. Running the operating system under a hypervisor gives a detailed oversight of the state of the\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 19 of 22\n\nmachine and provides the possibility of inspecting and intercepting any event including execution of a specific\r\ninstruction. As with VBS, this comes at a cost, namely performance and compatibility.\r\nCertificate revocation\r\nOn modern Windows systems, drivers need to have a valid signature based on an “acceptable” certificate. Hence,\r\nrevoking the certificate of a vulnerable driver would be an easy way to “disarm” it and render it useless in most\r\ncases.\r\nSadly, revocation rarely ever happens and of the vulnerable drivers documented in our research above, not a single\r\none of them has had its signature revoked. There are probably a multitude of reasons why such revocations are not\r\nhappening, but the primary ones are likely to be time and cost. As nobody requires the revocation, it does not\r\nmake much sense from the vendor’s standpoint to ask for revocation, as this will be a costly and time-consuming\r\nprocess. Moreover, a signing certificate is usually shared among other projects, so the potential revocation because\r\nof a single driver could hinder the development of every project.\r\nFurther, during our research we learned that drivers with revoked certificates are not always blocked and that this\r\nproblem is more complicated than it seemed at first. Revocation may not be the easiest solution after all.\r\nDriver blocklisting\r\nDriver blocklisting is a practice adopted by both Microsoft and various third-party security product vendors.\r\nSeveral of the most notorious vulnerable drivers are detected by ESET security products and deleted when found\r\non a system. Microsoft also opted to blocklist drivers not only with its security solution, but also directly by the\r\noperating system utilizing their HVCI mitigation, which is part of virtualization-based security. While blocklisting\r\nis effective, it is not a proactive solution – only previously discovered vulnerable drivers can be blocklisted, and it\r\nmust be done manually by each vendor. This means that this mitigation will not be effective against previously\r\nunknown, zero-day driver vulnerabilities that may be used in a sophisticated APT attack.\r\nProbably the most prominent blocklisted driver is the Capcom “anti-cheat” driver Capcom.sys, which explicitly\r\nimplements an IOCTL that simply executes the contents of the provided buffer in kernel mode (see Figure 16). To\r\nbe able to execute a buffer provided from user mode, it even temporarily disables SMEP!\r\nWhen discovered, the driver made several headlines and many unsigned driver loader tools were created based on\r\nabusing this function of the driver. Consequently, the driver was eventually blocklisted by many security product\r\nvendors including Microsoft and ESET.\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 20 of 22\n\nFigure 16. Code snippet from Capcom anti-cheat driver\r\nConclusion\r\nVulnerable drivers have been a known problem for a long time and have been abused by the game-cheating\r\ncommunity and malware authors alike, and while some effort has been made to mitigate the effects, it is still an\r\nongoing battle. It seems that all the responsible parties involved want to solve this problem – the vendors we\r\ncontacted were incredibly proactive during the disclosure process, eager to fix the vulnerabilities we uncovered.\r\nMicrosoft is trying to strengthen the operating system from the inside and last but not least, third-party security\r\nvendors are trying to come up with clever ways to detect and mitigate such drivers themselves.\r\nHowever, it seems that there is still a piece missing – a common, unified way of handling these issues including\r\nmore thorough “disarming” of the drivers, whether by revoking or blocklisting their certificates, or some public,\r\nshared blocklists adopted by the security companies.\r\nBibliography\r\n[1] J. Desimone and G. Landau, \"BlackHat 2018: Kernel-mode Threats and Practical Defences,\" 9 August 2018. [Online].\r\n[2] R. Warns and T. Harrison, \"INFILTRATE 2019: Device Driver Debauchery and MSR Madness,\" 2 May 2019. [Online].\r\n[3] J. Michael and M. Skhatov, \"Defcon 27: Get off the Kernel if you can't Drive,\" 13 August 2019. [Online].\r\n[4] N. Economou and E. Nissim, \"ekoparty 2015: Windows SMEP bypass: U=S,\" 2015. [Online].\r\n[5] A. Shulmin, S. Yunakovsky, V. Berdnikov and A. Dolgushev, \"The Slingshot APT,\" 6 March 2018. [Online].\r\n[6] Z. Hromcová and A. Cherepanov, \"InvisiMole: The Hidden Part of the Story – Unearthing InvisiMole's Espionage Toolset and\r\nStrategic Cooperations,\" 18 June 2020. [Online].\r\n[7] A. Ionescu, \"UMPOwn: Ring 3 to Ring 0 in 3 acts,\" in PoC||GTFO, vol. 2, No Starch Press, 2018, p. 768.\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 21 of 22\n\n[8] A. Brandt and M. Loman, \"Living off another land: Ransomware borrows vulnerable driver to remove security software,\" Sophos, 7\r\nFebruary 2020. [Online].\r\nSource: https://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nhttps://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/\r\nPage 22 of 22\n\nexecution. This with clever is no longer use of various techniques, the case with it is newer systems still possible due to modern to bypass most exploitation mitigations. of these mitigations That and achieve being said, kernel\u0002\nlevel code execution on Windows 10 or even brand-new Windows 11 systems (as of December 2021).\n Page 2 of 22", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/" ], "report_names": [ "signed-kernel-drivers-unguarded-gateway-windows-core" ], "threat_actors": [ { "id": "11f52079-26d3-4e06-8665-6a0b3efdc41c", "created_at": "2022-10-25T16:07:23.736987Z", "updated_at": "2026-04-10T02:00:04.732021Z", "deleted_at": null, "main_name": "InvisiMole", "aliases": [ "UAC-0035" ], "source_name": "ETDA:InvisiMole", "tools": [ "InvisiMole" ], "source_id": "ETDA", "reports": null }, { "id": "67bf0462-41a3-4da5-b876-187e9ef7c375", "created_at": "2022-10-25T16:07:23.44832Z", "updated_at": "2026-04-10T02:00:04.607111Z", "deleted_at": null, "main_name": "Careto", "aliases": [ "Careto", "The Mask", "Ugly Face" ], "source_name": "ETDA:Careto", "tools": [ "Careto" ], "source_id": "ETDA", "reports": null }, { "id": "72aaa00d-4dcb-4f50-934c-326c84ca46e3", "created_at": "2023-01-06T13:46:38.995743Z", "updated_at": "2026-04-10T02:00:03.175285Z", "deleted_at": null, "main_name": "Slingshot", "aliases": [], "source_name": "MISPGALAXY:Slingshot", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "12b5d602-4017-4a6f-a2a3-387a6e07a27b", "created_at": "2023-01-06T13:46:39.095233Z", "updated_at": "2026-04-10T02:00:03.21157Z", "deleted_at": null, "main_name": "InvisiMole", "aliases": [], "source_name": "MISPGALAXY:InvisiMole", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "f55c7778-a41c-4fc6-a2e7-fa970c5295f2", "created_at": "2022-10-25T16:07:24.198891Z", "updated_at": "2026-04-10T02:00:04.897342Z", "deleted_at": null, "main_name": "Slingshot", "aliases": [], "source_name": "ETDA:Slingshot", "tools": [ "Cahnadr", "GollumApp", "NDriver" ], "source_id": "ETDA", "reports": null }, { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null }, { "id": "392aed78-4ef6-46ac-afba-c3920ea05d28", "created_at": "2022-10-25T16:07:23.323349Z", "updated_at": "2026-04-10T02:00:04.541652Z", "deleted_at": null, "main_name": "APT 6", "aliases": [ "1.php Group" ], "source_name": "ETDA:APT 6", "tools": [ "Chymine", "Darkmoon", "Gen:Trojan.Heur.PT", "Poison Ivy", "SPIVY", "pivy", "poisonivy" ], "source_id": "ETDA", "reports": null }, { "id": "f5bf6853-3f6e-452c-a7b7-8f81c9a27476", "created_at": "2023-01-06T13:46:38.677391Z", "updated_at": "2026-04-10T02:00:03.064818Z", "deleted_at": null, "main_name": "Careto", "aliases": [ "The Mask", "Ugly Face" ], "source_name": "MISPGALAXY:Careto", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434641, "ts_updated_at": 1775791878, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/dfb02b2ef1dc47514a55bcc2bcec1c96cb2b3af5.pdf", "text": "https://archive.orkl.eu/dfb02b2ef1dc47514a55bcc2bcec1c96cb2b3af5.txt", "img": "https://archive.orkl.eu/dfb02b2ef1dc47514a55bcc2bcec1c96cb2b3af5.jpg" } }