CrowdStrike Falcon Prevents Multiple Vulnerable Driver Attacks in Real-World Intrusion

• Over the last 18 months, bring your own vulnerable driver (BYOVD) attacks have escalated significantly as adversaries attempt to bypass endpoint detection and response (EDR) products including the CrowdStrike Falcon® sensor.
• BYOVD attacks involve an adversary writing to disk and loading a kernel driver with known vulnerabilities that is then abused to perform privileged operations. This could involve terminating security products, bypassing EDR anti-tampering protections, dumping privileged processes or other actions normally prevented by the Windows operating system or security software.
• In early September 2024, a CrowdStrike customer experienced an intrusion where the adversary brought six vulnerable drivers in an attempt to bypass the Falcon sensor. All were detected or blocked by Falcon BYOVD protections.
• In total, across endpoints targeted in the intrusion, the customer had 48 alerts stemming from the custom malware execution, use of vulnerable drivers and other malicious activity.

BYOVD Background

BYOVD involves adversaries writing to disk and loading a legitimate, but vulnerable, driver to access the kernel of an operating system. This allows them to evade detection mechanisms and manipulate the system at a deep level, often bypassing protections like EDR. For the exploitation to succeed, attackers must first ensure the driver is brought on the target system. This is followed by the initiation of a privileged process to load the driver, setting the stage for further malicious activities.

Historically, code execution within the Windows kernel had virtually no restrictions, permitting unrestricted memory access. However, this landscape changed with the introduction of Microsoft's security initiatives like PatchGuard and virtualization-based security (VBS) with hypervisor-protected code integrity (HVCI), which have established new protective barriers. Nevertheless, the kernel continues to be an attractive target for malicious actors due to the powerful privileges it offers.

To safeguard the kernel, Windows 64-bit operating systems enforce a requirement that all drivers must be digitally signed to be loaded, a security measure facilitated by the Code Integrity () module known as Driver Signature Enforcement (DSE). This requirement significantly challenges malicious entities attempting to execute inside the kernel space, compelling them to seek alternative methods.

In response to these stringent security measures, adversaries have developed the BYOVD strategy to gain kernel access. Once the driver is in place, it becomes a target for exploitation, enabling attackers to leverage its vulnerabilities to achieve a range of malicious objectives, underscoring the ongoing cat-and-mouse game between security defenders and adversaries in the realm of kernel security.

Some adversary objectives include:

• Reading or writing arbitrary kernel memory regions in an attempt to read encryption keys or tamper with OS features
• Disabling DSE to allow loading of unsigned malicious drivers
• Manually mapping unsigned malicious drivers
• Removing kernel callbacks to hinder the visibility of EDR products
• Tampering with protected processes or protected registry keys
• Performing destructive actions by accessing and overwriting to raw disk sectors
• Tampering with CPU model-specific registers (MSR) to control various CPU features
• Tampering with protected OS registers
• Obtaining handles to protected processes
• Hiding objects like processes, network sockets or files

Vulnerable, Weaponizable and Malicious Drivers

To aid detection development, CrowdStrike categorizes abused drivers into three classes: vulnerable, weaponizable and malicious. The former two categories fall under the BYOVD attack chain.

Vulnerable drivers are legitimate drivers with a software flaw that allows attackers to exploit them to perform actions beyond their intended functionality. For example, a flaw could include arbitrary reading and writing of kernel memory in the context of the driver. This would allow loading of a second malicious unsigned driver, bypassing Windows code signing restrictions.