.png){kind=logo}
A notable trend in cyber threats nowadays is the exploitation of vulnerabilities in drivers through the Bring Your Own Vulnerable Driver (BYOVD) technique. BYOVD poses a significant risk as it allows attackers to bypass security measures and gain unrestricted access to targeted systems. This method, along with the long-standing use of rootkits, emphasizes the necessity for ongoing testing and vigilance to identify and mitigate potential vulnerabilities.
Throughout this article, we provided detailed explanations of the methodological aspects one should take into consideration when using their own infrastructure and OSINT platforms as the source of intelligence to identify possible vulnerable drivers that could be exploited by threat actors to covertly bypass protection layers.
The article in a nutshell:
[+] BYOVD Technique: It has become a notable technique to execute malicious code at the kernel level, bypassing security controls altogether to gain unrestricted full access.
[+] Proactive Hunting: Like Security Joes, both Red & blue teams should adopt a proactive approach to discover vulnerable drivers, utilizing frameworks for automated analysis.
[+] Community Collaboration: Security Joes team share frequently share research findings within the cybersecurity community to bolster collective defenses against emerging threats.Security Joes is a multi-layered incident response company strategically located in nine different time-zones worldwide, providing a follow-the-sun methodology to respond to any incident remotely. Security Joes' clients are protected against this threat.
Contact us at response@securityjoes.com for more information about our services and technologies and get additional recommendations to protect yourself against this kind of attack vector.
A Glance into Cyber Security Today
The dynamic landscape of cybersecurity continues to evolve, presenting an ever-increasing complexity that demands continual adaptation. With each passing day, new tools emerge to fortify the security posture of companies and individuals worldwide.
This evolution is palpable within the industry, where a myriad of products now facilitate the management of intricate cybersecurity operations, seamlessly handling thousands of assets from a centralized cloud-based console. Concurrently, regulatory frameworks have evolved, compelling companies to adhere to best practices in safeguarding their own and their customers' data, which lately has become one of the most valuable technological assets.
This confluence of factors has created an environment in which companies with the financial means to invest in cybersecurity can establish a multi-layered protection strategy. Such a strategy not only provides comprehensive visibility into their infrastructure but also facilitates proactive hunting for suspicious activities across the environment and reactive detection of known artifacts and behaviours.
However, amidst the abundance of capable technologies aimed at safeguarding endpoints, it's crucial not to underestimate the paramount significance of ongoing testing of technological environments. This testing is essential to identify vulnerabilities that could compromise the technological infrastructure. Novel exploitation tactics, often crafted to evade detection with minimal traces, pose a significant threat. Even the most substantial cybersecurity investments can falter during a real attack if they haven't undergone rigorous testing against these evolving threats.
Among all these Tactics, Techniques and Procedures (TTPs), there's a technique that has garnered significant attention as a potential weapon in the arsenal of threat actors aiming to breach organizational defenses: Bring Your Own Vulnerable Driver (BYOVD). This strategy capitalizes on vulnerabilities within drivers that lack adequate hardening measures. These vulnerabilities are then used to execute malicious code directly on the kernel, a critical area of the operating system where code can operate without constraints.
This could enable threat actors to disable security controls and gain unrestricted access to targeted devices, posing a significant risk to organizations' security posture, no matter the size of them or the budget spent to build the cyber security defense strategy.
A Recap on Kernel Land Threats
For a long time, rootkits have been employed by malware authors to conceal malicious activities on compromised systems, evading detection by antivirus software, security analysts, and system administrators. To achieve this, a rootkit modifies the fundamental structures of the operating system, aiming to hide files, network connections, processes, and other resources. Deployment of a rootkit can occur in various ways, including vulnerability exploitation, social engineering attacks, or unauthorized access. However, another common practice is the installation of malicious drivers directly into the kernel of the system, granting the rootkit full access and control over the compromised host.
Recognizing the severity of this issue, Microsoft has implemented several security controls to prevent malicious code from running directly from the kernel. One such measure is PatchGuard, integrated into the Windows kernel with the introduction of 64-bit versions of Windows XP. PatchGuard's primary purpose was to safeguard critical areas of the kernel against unauthorized modifications by third-party software. It achieves this by preventing drivers and other kernel components from altering specific data structures and internal functions of the system.
Furthermore, with the release of Windows Vista, Microsoft introduced "Driver Signature Enforcement" (DSE), initially available exclusively in its 64-bit versions starting in January 2007. DSE serves as a vital security measure designed to protect the system against malicious or unsigned drivers. When activated, DSE meticulously verifies the digital signature of drivers before loading them, making it challenging for rootkits and other forms of malware to infiltrate and conceal themselves within the system by tampering with drivers.
However, the emergence of the BYOVD tactic poses a significant challenge when defending the kernel space of a system. In this tactic, attackers obtain drivers with valid signatures that harbor known vulnerabilities and deploy them on compromised systems. Subsequently, attackers exploit these vulnerabilities to gain control over the kernel of the operating system, potentially seizing complete control of the system without triggering any significant alert.
The adoption of BYOVD has become a prevailing trend among threat actors, with groups like Lazarus exploiting vulnerabilities such as CVE-2021-21551 in a vulnerable Dell DBUtil driver to bypass Windows security protections and install backdoors like Blindingcan.
In addition to Lazarus, numerous other threat actors have also embraced the BYOVD technique, including notorious ransomware gangs. These groups are known for their sophisticated tactics and wide-ranging impact on organizations and individuals alike. Some of the notable ransomware gangs that have employed BYOVD include:
Group Name | Vulnerable Driver | Description |
Kasseika Ransomware | viragt64.sys | Vulnerable driver in VirIT Agent System was used to disable various security tools. Reported by Trend Micro. |
AvosLocker | aswarpot.sys | Legitimate Avast Anti-Rootkit Driver was abused to disable security products. Reported by Trend Micro. |
Cuba Ransomware | aswarpot.sys | Legitimate Avast Anti-Rootkit Driver was abused to disable security products. Reported by Kaspersky. |
BlackByte | RTCore64.sys | Micro-Star’s MSI AfterBurner was abused to disable security products. Reported by Sophos. |
Akira ransomware | zamguard64.sys | Tools such as PowerTool or KillAV, were used to terminate processes belonging to security solutions, as reported by Trend Micro. These tools are known because they use a vulnerable driver from Zemana AntiMalware. |
For additional information on attacks utilizing the BYOVD technique and other related cybersecurity threats, we highly recommend reviewing the following link.
It is worth mentioning that the implementation of the BYOVD technique varies based on the Threat Actor's skills and expertise level. While all implementations involve dropping vulnerable drivers into targeted machines, the method to trigger the vulnerability can differ. This can include using Powershell scripts, custom C++ compiled samples, or leveraging open-source projects such as PowerTool, KillAV, Mhyprot2DrvControl, and EDRSandblast.
To counter such threats, the infosec community has introduced initiatives like Living Off The Land Drivers (LOLDrivers) and Screwed-Drivers. These initiatives are crucial for cataloging a repository of signed drivers used by adversaries to bypass security controls and carry out attacks. They also offer detection rules that can be implemented to enhance the security posture and resilience against such attacks. Moreover, proactive measures have been adopted by organizations like ESET, Eclypsium, and VMware to detect and resolve vulnerabilities in drivers before they are exploited by malicious actors.
Following this proactive approach, we have decided to release this blog post to the community. Our aim is to educate both red teamers and blue teamers about the technical aspects they must consider to protect an organization from such threats. Additionally, we provide a methodology they can follow to proactively discover such type of drivers in the wild or within the organization's assets.
Vulnerable Drivers to Kill Your Security
As previously mentioned, vulnerable drivers offer attackers an enticing opportunity to disrupt the victim's environment and carry out further activities discreetly. While the range of exploitation possibilities is extensive and cannot be fully addressed in a single blog post, we have categorized the main techniques employed by threat actors during intrusions into two distinct groups. The first involves escalating privileges, allowing attackers to gain higher levels of access within the system. The second entails terminating processes associated with security products, leaving the asset completely unprotected. Each of these use cases is explained in detail in the following sections.
Privilege Escalation
As its name implies, the ultimate goal of privilege escalation techniques is to obtain higher-level permissions on the compromised machine, thereby allowing attackers to continue their intrusion and inflict more damage.
It's important to note that attackers typically initiate intrusions with low privileges, depending on the infrastructure's hardening and environment configurations. This may limit their ability to directly install a vulnerable driver, as Windows restricts the addition of them to the kernel to only high-level privileged accounts.
In this scenario, the threat actor targets drivers already installed on machines, particularly those popular among users, that also possess vulnerabilities. Upon exploiting these vulnerabilities, the attacker gains the highest possible privilege on the machine, thus escalating the attack and granting additional control. This type of exploitation is among the most critical a device could face, as it grants threat actors greater control and power over a compromised system once they have gained a foothold.
While exploits targeting privilege escalation are less common than those aimed at disabling security tools, they do exist and have been reported by security researchers in the past. One such case is a vulnerability reported in 2020 in the Realtek driver rtkio64.sys, which allowed threat actors to escalate privileges to NTAuthority\SYSTEM from any unprivileged user.
Impair Defenses
Threat actors also exploit vulnerable drivers to disable security tools, enabling them to dismantle environment restrictions and execute attacks. However, this tactic relies on high-privilege accounts for driver installation. As drivers can only be installed by accounts with elevated privileges in Windows, this limitation highly reduces the risk of exploitation; from a defense perspective, safeguarding these accounts with strong passwords and vigilant monitoring can significantly mitigate the threat, although the possibility of occurrence persists.
It's important to note that while having high privileges on a machine is a prerequisite for disabling an EDR (Endpoint Detection and Response) tool without resorting to exploits, it's not the sole requirement. Typically, EDRs and security tools safeguard themselves from unauthorized uninstallation or tampering by employing tokens and closely monitoring and blocking attempts to interact with registries and files associated with them. However, driver exploitation presents an advantage to attackers due to the simplicity of bypassing these controls and terminating the processes of security tools without any restrictions.
Disabling security tools within a targeted environment can be implemented in several different ways, however the most prevalent mechanisms used by threat actor to perform this activity while also exploiting vulnerabilities in drivers is by directly killing the processes related to the security tools, or by removing the Kernel callbacks set by these tools. Each of these techniques will be described below.
Killing security-related processes
Windows provides driver functions such as ZwCreateProcess/ZwCreateProcessEx, ZwTerminateProcess, and ZwOpenProcess, essential for process management. Operating within a privileged context, these kernel functions demand meticulous checks by drivers to authorize operations. Neglecting these checks could lead to unauthorized access, enabling any non-administrator process on the machine to communicate with the driver process via IOCTL (Input/Output Control). This, in turn, allows unrestricted creation, management, or termination of processes.
As an example, the following driver, discovered during our proactive hunting, exemplifies the main components of a typical vulnerable driver, which allows to terminate processes in a machine where it is installed. The driver expects a PID, passed in the input buffer via the IOCTL with code 0xB822200C, as depicted in steps 1 and 2. Subsequently, the kernel acquires a handle for the target process and employs ZwTerminateProcess to terminate its execution, as shown in steps 3 and 4.
In a real attack scenario, an attacker will first check if the vulnerable driver is already installed in the system. If not, they may attempt to load it, which is why the technique is named "Bring Your Own Vulnerable Driver" (BYOVD); the attacker introduces a vulnerability into the system using a known driver they possess. However, it's crucial to note that loading a driver typically requires admin permissions.
Once the attacker has obtained high-privilege permissions and installed the vulnerable driver in the system, they can proceed to issue the IOCTL code 0xB822200C and provide the PID of the targeted process. With these actions, the process identified by the provided PID in the IOCTL interaction will be terminated.
The following video demonstrates how we can utilize this kind of vulnerability to terminate or interfere with system processes or security solutions running on the system. In this scenario, a non-administrator process can leverage the vulnerable driver to disrupt the operation of Windows Defender processes, despite attempts to relaunch the Windows Defender service.
Clear the Kernel Callbacks
Another notable method for disabling security tools involves removing the kernel callbacks utilized by EDRs and antivirus programs to detect and prevent malware in the system. This exploitation technique emerged as a side effect of Microsoft's introduction of PatchGuard in 2005.
While PatchGuard was introduced as an additional protection layer to prevent any running process from directly patching Kernel critical code, it's understood that security tools require kernel access to provide comprehensive threat coverage. Consequently, Microsoft also provided a set of callbacks that security tools must register to access kernel details.
However, this inadvertently created an issue where threat actors with kernel access could disable all security tools installed in the system. Since PatchGuard essentially consolidated all interactions with the kernel in one single place via kernel callbacks, security tools are required to register callbacks in the kernel to function effectively. As a result, an attacker simply needs to delete the registry containing all these callbacks, rendering the defense tools blind automatically.
This technique was initially documented by a security researcher in 2020. Their research provides comprehensive technical details and a Proof of Concept (PoC) code capable of removing several kernel callbacks used by various endpoint security products. This research also served as inspiration for the development of the open-source tool EDRSandblast, which has been utilized as the base code for custom tools developed by threat actors such as the Ransomware BlackByte to disable EDRs in compromised environments and bypass security controls.
Hunting the Next Vulnerable Driver
Whether you're a red teamer eager to test the quality and resilience of security controls or a blue teamer focused on enhancing your organization's security posture, adopting a proactive approach to continuously hunt for vulnerable drivers is crucial. Actively searching for vulnerable drivers existing in your environment and in the wild, which could be exploited to bypass security solutions, is far more effective than reacting to incidents as they occur.
In line with this proactive approach, our research methodology emphasizes the continuous collection of drivers from OSINT platforms as well as internal infrastructure. We then analyze these drivers to proactively detect vulnerabilities and leverage this intelligence to enhance the quality of security controls in place, as well as to improve the efficacy of red teaming exercises. This process involves indexing and analyzing drivers using a combination of open-source tools and in-house developments, ensuring scalability and operability over time.
One notable open-source project that played a fundamental role in executing this research and creating an automated analysis methodology is the POPKORN analysis framework. This framework utilizes taint analysis and targeted symbolic execution to identify potential vulnerabilities within drivers. Taint analysis tracks user input flow, while symbolic execution explores all program paths using symbolic values, helping uncover security flaws in Windows kernel drivers. Following symbolic execution, we often conduct manual analysis to confirm previous findings or discover new vulnerabilities. To enhance manual analysis, we utilize fuzzing techniques to validate our results.
It's important to note that we meticulously filtered our driver samples based on the presence of functions from the Windows Driver Kit (WDK) API categorized as highly likely to be associated with common vulnerabilities within drivers. After a comprehensive analysis of these drivers, we categorized the findings into two distinct groups: known vulnerable drivers and new vulnerable drivers identified by our team.
For brevity, our primary focus was on vulnerabilities identified in drivers that had never been reported before. During our testing phase, which spanned less than a month, we identified 25 drivers with known vulnerabilities and 11 drivers that had never been reported as vulnerable before. It's also worth noting that some of the 25 known vulnerable drivers were already being utilized by threat actors. Although we discovered additional new vulnerable drivers, not all of them were deemed potentially exploitable by attackers within the context of BYOVD, so they were excluded from the list presented below:
Filename | Hash |
amifldrv64.sys | 785045F8B25CD2E937DDC6B09DEBE01A |
ALSysIO64.sys | D9AAFC513BE1C4C57B9F9827E986039C |
amifldrv.sys | 7B9717C608A5F5A1C816128A609E9575 |
amifldrv64.sys | 6AB7B8EF0C44E7D2D5909FDB58D37FA5 |
AsIO3.sys | 1CE19950E23C975F677B80FF59D04FAE |
AsrDrv.sys | DBDAC970026703DFA5CCAF69B04086EC |
AsUpIO.sys | 6D4159694E1754F262E326B52A3B305A |
aswArPot.sys | 2E32AF6EA403EB297E34D4516CC3A2F1 |
ATSZIO.sys | DBF11F3FAD1DB3EB08E2EE24B5EBFB95 |
cpuz154_x64.sys | 7AC07D3033BAFFC378488F13F2E648CF |
dbutil_2_3.sys | C996D7971C49252C582171D9380360F2 |
gdrv.sys | 9AB9F3B75A2EB87FAFB1B7361BE9DFB3 |
gmer64.sys | A822B9E6EEDF69211013E192967BF523 |
inpoutx64.sys | 9321A61A25C7961D9F36852ECAA86F55 |
iQVW64.sys | 1898CEDA3247213C084F43637EF163B3 |
mhyprot2.sys | 3F79EA5D2BBD2023D2F3E47D531F0E33 |
MsIo64.sys | 61B068B10ABFA0776F3B96A208D75BF9 |
NTIOLib.sys | 064B34B577A6010C620E21DBDF3F6DAD |
RTCore64.sys | 0A2EC9E3E236698185978A5FC76E74E6 |
RwDrv.sys | 60E84516C6EC6DFDAE7B422D1F7CAB06 |
Rzpnk.sys | B4598C05D5440250633E25933FFF42B0 |
semav6msr64.sys | 0A430B184878A92E6C94E1B6A7F217B3 |
Ucorew64.sys | A17C58C0582EE560C72F60764ED63224 |
WinRing0.sys | 0C0195C48B6B8582FA6F6373032118DA |
zamguard64.sys | 21E13F2CB269DEFEAE5E1D09887D47BB |
Discovered Vulnerable Drivers
As previously mentioned, we have successfully identified several vulnerabilities in drivers that had never been reported before. Following our analysis, we categorized these vulnerabilities into several clusters to enhance understanding. Below, we provide details of each of these clusters.
Unauthorized Process Management
This set of vulnerabilities is related to drivers that improperly manage access to the Windows functions provided in the Kernel space. These functions include operations to create, open, or terminate processes, such as ZwCreateProcess/ZwCreateProcessEx, ZwOpenProcess and ZwTerminateProcess.
While using these functions is not inherently malicious, the concern arises when drivers directly expose them in the system via IOCTL (Input/Output Control), allowing any process within the system to access the corresponding IOCTL and execute these functions without any restriction.
As an example, one of the drivers found acquires a handle to a process in kernel land and returns it via the IOCTL. This essentially provides complete control over a process, posing a significant security risk.
Unrestricted Access to MSRS
Model Specific Registers (MSRs) are specialized registers found in x86 and x86-64 processors, granting direct access to processor-specific resources and configurations. Primarily utilized for advanced configuration, performance monitoring, and control of processor-specific resources inaccessible via conventional assembly instructions, MSRs play a pivotal role in optimizing processor behavior.
Incorporated within the processor's register set, MSRs are accessed through dedicated instructions such as RDMSR (Read Model Specific Register) for reading and WRMSR (Write Model Specific Register) for writing. They serve as essential tools utilized by operating systems, hypervisors, device drivers, and low-level software to fine-tune processor behavior, monitor performance metrics, and execute other hardware-specific operations.
Among the vulnerable drivers identified, we found one that grants users the ability to access and modify Model-Specific Registers (MSRs). Improper handling of these registers may lead to alterations in critical system settings, paving the way for kernel code execution, data corruption, and subsequently, potential risks such as bypassing security mechanisms or escalating privileges.
Additionally, it allows a user to read and write to I/O ports and control parameters for the MmMapIoSpace function. This function enables the mapping of a physical address range to a virtual address space, returning a virtual address pointing to the newly mapped area, thereby providing the user with control over this region.
The code snippet below demonstrates how a user can receive an MSR address along with a value to be written to that address, thereby enabling direct writing to a register. For instance, the MSR address 0xC0000082 holds the system call handler address. If a user has permission to modify this value, the kernel will execute the code provided at the address specified by the user. While Intel processors feature protections like SMEP (Supervisor Memory Execute Protection), which prevent the kernel from executing code residing in user address space, there still exist other means to control the code executed by the kernel.
Unrestricted Access to Control Registries
The Control Registers (CRs) constitute a set of special registers found in x86 and x86-64 processors, responsible for controlling and managing various aspects of processor and system operation. They are essential for the operating system and low-level software, which utilize them to configure and control processor behavior, as well as manage critical system aspects such as memory access control, paging, and interrupts. Some of the most common CRs include:
CR0: Controls the processor's operating mode, including settings such as memory protection enablement, performance monitoring, and cache control.
CR2: Stores the address of the last page fault occurrence.
CR3: Holds the base address of the page table used by the operating system to translate virtual addresses into physical addresses.
CR4: Controls specific processor features, such as enabling System Management Protection Extensions (SMEP) and executing 64-bit code.
Another set of vulnerable drivers allow reading and writing to certain control registers, such as CR0, CR3, and CR4, by a non-administrator user. Allowing a user to alter the values in these registers can lead to various consequences, such as changing system settings, removing processor security protections, system instability, data corruption, or arbitrary code execution.
Taking the CR4 control register as an example, we can observe the presence of bits representing various protections such as SMEP and SMAP. As mentioned earlier, SMEP acts as a security layer, preventing the kernel from executing code located in user address space, while SMAP (Supervisor Mode Access Prevention) determines whether user space memory can be accessed in privileged mode. If a driver allows direct modification of the CR4 register, it implies that these protections can be disabled without the need for complex kernel attacks, which would have a significant impact on system security.
Detection Opportunities & Recommendations
Detecting and safeguarding your infrastructure from such attacks heavily relies on the context in which the exploitation occurs. In the simplest scenario where a threat actor brings their own driver and installs it on the targeted machine, several strategies can be employed for detection and protection.
Firstly, monitoring Windows Event Logs for Event ID 7045, as suggested by Trend Micro, can be effective. This event indicates a service was installed or registered with the system, which could signify the installation of a new driver.
Additionally, leveraging the telemetry provided by your Endpoint Detection and Response (EDR) system can help identify unknown or suspicious drivers that have been installed on your endpoints. Paying attention to uncommon locations such as temporary or user-related folders can be particularly useful, as legitimate drivers are typically installed in system directories.
The most challenging scenario arises when the driver is already present on the machine and being exploited by the attacker. In this situation, recognition of the exploitation may depend on additional behaviors observed before or after the exploitation, such as the execution of suspicious command lines, scripts, or tools, as well as the absence of telemetry from endpoints. This scenario underscores the importance of adopting a proactive stance to cybersecurity. Being prepared or at least aware of the current drivers installed in the infrastructure that could be exploited is crucial.
Furthermore, Microsoft provides the Microsoft Recommended Driver Block Rules, a set of guidelines and rules aimed at preventing specific drivers from being loaded into the Windows operating system. These rules can be used in conjunction with proactive hunting for vulnerable drivers. If resources are limited, relying on open-source projects such as Living Off The Land Drivers (LOLDrivers) and Screwed-Drivers, which maintain lists of known vulnerable drivers, can also be beneficial.