Microsoft Under Pressure to Bolster Defenses for BYOVD Attacks

Part 1 in a series. Stay tuned for Part 2 next week.

When it comes to bring-your-own-vulnerable-driver (BYOVD) attacks, Microsoft may be stuck between a rock and a hard place.

Over the past year, threat actors — most notably, ransomware groups — have increasingly embraced the BYOVD technique to disable security products in a targeted network. The technique involves threat actors identifying a vulnerable driver that they can exploit and dropping it on a targeted system. Attackers then use the kernel-level access and elevated privileges of the driver to kill security processes on a system before deploying their payload, be it ransomware, infostealers, or backdoors.

The rising usage of BYOVD for tools like EDR killers has put Microsoft in a tricky position. The software giant has taken many steps over the past two decades to shore up defenses around the Windows kernel. However, security researchers say these measures have considerable security gaps, ones that threat actors have exploited repeatedly.

Related:Claude Source Code Leak Highlights Big Supply Chain Missteps

The size and nature of some of these gaps defy logic. Case in point: Ransomware actors recently weaponized a legitimate driver that had its digital certificate revoked in 2010, exploiting a massive loophole in Windows defenses. 

The rise in BYOVD attacks has raised questions about Microsoft's security policies and its efforts to prevent these debilitating attacks, while much of the burden has fallen on EDR vendors — the very targets of these evasion tools. Unfortunately, researchers say many potential fixes aren't feasible because they could crash systems — or worse, cause additional security risks to the OS. 

Security Gaps Allow BYOVD Attacks to Thrive

The conundrum with vulnerable drivers isn't an easy one to untangle. Software drivers are critical components that enable applications and devices to communicate with the operating system. With Windows, drivers are typically given "ring 0" or kernel-level access, the highest privilege level possible.

These drivers must be signed with digital certificates in order to be trusted by the OS (more on this aspect later). Windows loads drivers during the boot process, which complicates matters because the OS can't check certificate revocation lists (CRLs) since network connections are prohibited during the process; checking CRLs and driver blocklists at startup would negatively impact system performance and potentially create new risks, according to experts. 

"If you look at Windows and compare it to something like macOS, the vulnerable driver becomes very clear," says Peter Morgan, vice president of research at Halcyon. "Apple kicked everyone out of the kernel a number of years ago, and they'll never have this problem."

Related:Chainguard Unveils Factory 2.0 to Automate Hardening the Software Supply Chain

Microsoft's OS, on the other hand, was designed to support "just about everything that's ever worked on Windows at any point in time," he says. By supporting countless kernel drivers, the company has inadvertently created yet another arms race for attackers and defenders.

To its credit, Microsoft over the years has made several efforts to improve kernel defenses and, more specifically, keep vulnerable drivers out of the OS. Most notably, Windows Vista introduced Driver Signature Enforcement, a feature that requires kernel drivers to be signed by a trusted certificate authority (CA). Microsoft added another measure with Windows 10 that mandates new kernel drivers must be signed through its Hardware Dev Center. 

But a truck-sized loophole exists in these defenses. Microsoft granted backward compatibility for older, cross-signed drivers to make sure they can properly load. Therefore, drivers signed with certificates issued before July 29, 2015, that also are chained to a supported cross-signed CA, are permitted to load — even if they have expired or revoked certificates.

Related:Axios NPM Package Compromised in Precision Attack

The gap was highlighted by a recent attack documented by Huntress researchers in which threat actors weaponized a driver for EnCase, a digital forensics suite from Guardian Software. The certificate for the driver expired in 2010 and was subsequently revoked by Guardian.

"What use case could there be to load a driver with a revoked certificate? It doesn't make sense," says Jakub Souček, senior malware researcher at ESET. "When the certificate is revoked, that means the issuer or the actual vendor of specific software driver made the necessary step to proactively revoke the driver, because they realized there are some issues. And when that's done, I think that's a clear signal that this driver should not be allowed to load under any circumstances."

Vulnerable Driver Blocklists Only Go So Far

Fortunately, researchers say most of the drivers that are abused by attackers don't have revoked or expired certificates. And while Windows doesn't check CRLs to block older drivers with expired or revoked certificates, Microsoft maintains a Vulnerable Driver Blocklist to prohibit ones that have been exploited in attacks. 

Since the Windows 11 2022 update, the blocklist has been enabled by default on all systems, which prevents the OS from loading many vulnerable drivers known to be used in attacks. But experts say this measure also falls short, for a variety of reasons. 

First, Microsoft's blocklist is updated only once or twice a year, so recent BYOVD attacks are likely to slip through the cracks for several months.

Second, the decision to fully block a driver across all Windows systems can be a complicated matter. When a new vulnerable driver is used by attackers, Soucek says ESET typically finds that legitimate use of that driver still makes up between 80% and 90% of the activity. "We still see a lot of those drivers being used by systems that just use them for the actual intended purpose," he says.

Morgan says Microsoft has to weigh the pros and cons of blocking drivers that, for example, may be used for critical legacy systems in healthcare organizations. 

"From Microsoft's perspective, they see the whole the world," he says. "For them to block a driver for everyone, it has to be catastrophic and not really have a good use case."

Anna Pham, senior hunt and response analyst at Huntress, tells Dark Reading that more frequent updates to Microsoft's blocklist could narrow the window of opportunity for threat actors. "Cloud-based real-time updates, similar to how Defender definitions work, could help," she says.

But some infosec professionals say Microsoft isn't doing enough to at least explore additional solutions to the growing BYOVD threat. Dick O’Brien, principal intelligence analyst for the Symantec and Carbon Black Threat Hunter Team, called for the software giant to take more proactive measures.

"This is an issue that Microsoft needs to take more seriously because these drivers are signed by Microsoft," he says. "There needs to be more thorough review prior to signing as well as active revocation of existing vulnerable drivers, not allowing such drivers to load once they are discovered to be vulnerable."

Additionally, O'Brien says Microsoft needs to improve its driver policies to ensure exclusive usage by the legitimate application. 

"Drivers that were created to implement legitimate functionality can be used maliciously because they are allowed by Microsoft to be leveraged by third-party applications for malicious purposes," he notes. "Microsoft should enforce a policy of only allowing the original intended application to use the driver."

Researchers acknowledge that many of the proposed improvements will be difficult for Microsoft to implement, but they argue that the BYOVD problem will only get worse.

"I sympathize with Microsoft because it's a very tough problem," Morgan says, "but I do think there are steps they can take."

Short-Term Fixes for the Long-Term BYOVD Problem

Microsoft says it takes several actions to mitigate the abuse of vulnerable drivers when they're detected in attacks like the recent "Reynolds" ransomware campaign. In that activity, researchers with the Symantec and Carbon Black Threat Hunter Team discovered the threat actors had embedded a vulnerable NsecSoft NSecKrnl driver with the ransomware payload — a clear sign that cybercriminals are pushing the BYOVD technique forward. 

"We take customer security seriously and have established processes in place to help keep customers protected from vulnerable driver abuse," a Microsoft spokesperson tells Dark Reading. "When these reports surface, we evaluate impact, work with publishing partners to ensure a fixed version is available, and use layered protections in Microsoft Defender to reduce risk while customers update. Once safer versions are broadly available, we take additional actions such as blocking vulnerable versions through our driver blocklist. We will continue to take a careful, customer-focused approach to deter threat actor activity while minimizing disruption for organizations that rely on these components."

There are other alternatives besides Microsoft's Vulnerable Driver Blocklist. Most notably, the open source project called Living Off the Land Drivers, or LOLDrivers, maintains a larger and more frequently updated list of abused drivers. 

Additionally, cybersecurity companies can a cast a wide net and not only block vulnerable drivers that have been abused but also prohibit ones that are likely to be exploited. ESET's Soucek says EDR vendors can also take a more curated approach and flag or prohibit types of drivers that possess the functionality that could terminate security processes in a targeted environment. The vendors will also know whether a driver has any relevancy to a specific network or not.

But this, perhaps unfairly, has shifted much of the burden for BYOVD threat detection to the EDR vendors themselves. It also requires heavy lifting on the part of end user organizations, many of which lack the expertise or resources to identify and address kernel driver risks, Morgan says.

It's unclear if Microsoft will make any changes or improvements to further mitigate BYOVD threats. "It's a challenging problem," Morgan says. "Even if Microsoft threw everything they had at it, I don't think they'd be able to make everyone happy."

In the meantime, experts tell Dark Reading that a layered security approach is the best way to prevent BYOVD attacks from disabled enterprise defenses. In addition to blocking vulnerable drivers, they recommend tailoring detection platforms for the telltale signs of a BYOVD threat, which includes obtaining administrative privileges required to load drivers. 

"Once the driver is loaded and is allowed to run, you need to realize what you're dealing with," Soucek says. "Because once that happens, there really isn't any effective way to defend it."

For more on how cybersecurity vendors and researchers are mitigating the BYOVD threat, stay tuned for part 2 of this series.