www.elastic.co Open in urlscan Pro
2a04:4e42:400::729  Public Scan

Form analysis
0 forms found in the DOM

Text Content

About
Topics
Vulnerability updatesReportsTools

SubscribeStart free trialContact sales

Open navigation menu
24 August 2023•Gabriel Landau


FORGET VULNERABLE DRIVERS -  ADMIN IS ALL YOU NEED

Bring Your Own Vulnerable Driver (BYOVD) is an increasingly popular attacker
technique whereby a threat actor brings a known-vulnerable signed driver
alongside their malware, loads it into the kernel, then exploits it to perform
some action within the kernel that they would not otherwise be able to do.
Employed by advanced threat actors for over a decade, BYOVD is becoming
increasingly common in ransomware and commodity malware.

8 min readPerspectives



INTRODUCTION

Bring Your Own Vulnerable Driver (BYOVD) is an increasingly popular attacker
technique wherein a threat actor brings a known-vulnerable signed driver
alongside their malware, loads it into the kernel, then exploits it to perform
some action within the kernel that they would not otherwise be able to do. After
achieving kernel access, they may tamper with or disable security software, dump
otherwise inaccessible credentials, or modify operating system behavior to hide
their presence. Joe Desimone and I covered this in-depth, among other kernel
mode threats, at Black Hat USA 2018. Employed by advanced threat actors for over
a decade, BYOVD is becoming increasingly common in ransomware and commodity
malware.

Driver Signing Enforcement (DSE), first deployed in 2007 by Windows Vista x64,
was the first time that Microsoft attempted to limit the power of admins. With
DSE in place, admins could no longer instantly load any code into the kernel.
Admin restrictions grew over time with the rollout of Boot Guard, Secure Boot,
and Trusted Boot to protect the boot chain from admin malware, which could
previously install their own boot loaders / bootkits.

Further limiting admins' power, Microsoft recently deployed the Vulnerable
Driver Blocklist by default, starting in Windows 11 22H2. This is a move in the
right direction, making Windows 11 more secure by default. Unfortunately, the
blocklist's deployment model can be slow to adapt to new threats, with updates
automatically deployed typically only once or twice a year. Users can manually
update their blocklists, but such interventions bring us out of “secure by
default” territory.


SECURITY BOUNDARIES

When determining which vulnerabilities to fix, the Microsoft Security Response
Center (MSRC) uses the concept of a security boundary, which it defines as
follows:

> A security boundary provides a logical separation between the code and data of
> security domains with different levels of trust. For example, the separation
> between kernel mode and user mode is a classic and straightforward security
> boundary.

Based on this definition, one might be inclined to think that malware running in
user mode should not be able to modify kernel memory. The boundary is
“straightforward” after all. Logically, any violation of that boundary should be
met with a remedial action such as a patch or blocklist update.

Unfortunately, the situation gets murkier from here. That document later states
that administrator-to-kernel is not a security boundary, with the following
explanation:

> Administrative processes and users are considered part of the Trusted
> Computing Base (TCB) for Windows and are therefore not strong [sic] isolated
> from the kernel boundary.

At this point, we have two seemingly conflicting viewpoints. On one hand, MSRC
states that admin-to-kernel is an indefensible boundary and not worth fixing. On
the other hand, Microsoft is attempting to defend this boundary with mechanisms
such as Driver Signing Enforcement, Secure Boot, and the Vulnerable Driver
Blocklist. Because the defense is incomplete, MSRC instead calls them
“defense-in-depth security features.”

MSRC similarly does not consider admin-to-PPL a security boundary, instead
classifying it as a defense-in-depth security feature. More on this in the next
section.

The rest of this article will refer to MSRC and Microsoft separately. While MSRC
is part of Microsoft, Microsoft is a much larger entity than MSRC; they
shouldn't be equated.


EXPLOITING VULNERABILITIES

In September 2022, I filed VULN-074311 with MSRC, notifying them of two zero-day
vulnerabilities in Windows: one admin-to-PPL and one PPL-to-kernel. I provided
source code for both exploits. The response concisely indicated that they
understood the vulnerabilities and declined to take any further action, as
stated below:

> The research describes a multi-step attack that leverages a PPL bypass to gain
> kernel code execution. Note that all of the proposed attacks do require
> administrative privileges to perform and thus the reported issue does not meet
> our bar for immediate servicing. We do not expect any further action and will
> proceed with closing out the case.

In this parlance, “servicing” means “patching.” Their response is consistent
with the aforementioned policy and their historical treatment of the
admin-to-kernel boundary. Their behavior is consistent too - it's been over 11
months and they still haven't patched either vulnerability. I find it
fascinating that Microsoft is willing to block drivers that can modify kernel
memory but MSRC is unwilling to service vulnerabilities that can do the same.

When I announced my Black Hat Asia 2023 talk, PPLdump Is Dead. Long Live
PPLdump, on Twitter five months after the MSRC report, the Windows Defender team
quickly reached out to learn more. It seems that MSRC closed the case without
telling the Defender team, whose products rely on PPL to protect hundreds of
millions of Windows machines, about a PPL bypass. This type of miscommunication
mustn't be allowed to continue.


TURNKEY TOOLING

EDRSandBlast is a tool that weaponizes vulnerable drivers to bypass AV & EDR
software. It can modify kernel memory to remove hooks installed by AV & EDR,
temporarily or permanently blinding them to malicious activity on the system.

As I discussed in my Black Hat Asia talk, MSRC has de-facto shown that they are
unwilling to service admin-to-PPL and admin-to-kernel vulnerabilities and that
it requires the existence of turnkey tooling on GitHub to motivate Microsoft to
action. This led me to release the admin-to-PPL exploit PPLFault and
admin-to-kernel exploit chain GodFault as easy-to-use tools on GitHub. For
brevity, below we'll call them “PPL vulnerability” and “kernel vulnerability”,
respectively.

In this same “turnkey tooling” spirit, to highlight the inconsistency of
blocking known-vulnerable drivers while simultaneously refusing to patch
admin-to-kernel exploit chains, I am releasing a version of EDRSandBlast that
integrates PPLFault to demonstrate the same result, sans vulnerable drivers. You
can see it here disabling the Windows Defender driver. My goal in releasing this
is to motivate MSRC to treat both PPL and kernel vulnerabilities with greater
urgency.


MITIGATION

I released a small kernel driver alongside PPLFault and GodFault called NoFault
which breaks the PPL exploit. Until Windows is fixed, anti-malware vendors can
employ this code to mitigate the PPL vulnerability. We've incorporated NoFault's
protection into the latest version of Elastic Endpoint/Defend - please update to
8.9.0+ if you haven't already. One comprehensive fix could be to have the memory
manager enforce page hashes for all executable images loaded into PPL, a feature
already employed for full Protected Processes.

GodFault is not the first tool to exploit the kernel vulnerability. ANGRYORCHARD
first used it with the now-patched KnownDLLs PPL vulnerability. The PPL
vulnerability has since been fixed, but the kernel one was not. I was able to
easily reuse the kernel vulnerability in GodFault - it's only a few lines of
code. If this is not patched, then any future PPL exploits will immediately be
chainable to the kernel. Note that NoFault breaks the kernel exploit chain by
preventing its requisite PPL code execution, but does not fix the kernel
vulnerability itself.


DISCUSSION

Making EDRSandBlast driverless is just one example of the things you can do with
such exploits. Admin-to-kernel exploits enable a whole menu of malware
capabilities that are normally impossible from user mode, including:

 * Disable kernel mode telemetry including process, thread, object manager,
   filesystem, and registry callbacks. EDRSandBlast does some of these.
 * Disable kernel ETW loggers
 * Terminate and/or inject malware into PPL anti-malware processes
 * Bypass LSA RunAsPPL to dump credentials or tamper with Credential Guard
 * Read/write the memory of shielded VM worker processes, which run as PPL
 * Run malware with greater privilege than anti-malware, such that it can't be
   scanned or terminated from user mode
 * Implement rootkit behavior such as hiding processes, files, and registry keys
 * Gain full read-write access to physical memory

Such kernel-driven capabilities, often enabled by BYOVD, are regularly used by
criminals to defeat and degrade security products, empowering them to hurt
people and businesses. PPL and kernel vulnerabilities enable these same
capabilities, so MSRC needs to service them proactively before threat actors
abuse them, not after.

I don't want to understate the difficulty of the problem - defending the kernel
against admins is hard and will require continual effort as new bypasses are
found. It will not be solved, but rather a difficult and ongoing arms race.
Fortunately, Microsoft recently adopted a new philosophy of “no longer avoiding
the hard things” (timestamped link). Addressing these types of vulnerabilities
is a “hard thing” affecting Windows security today that Microsoft can do
something about while simultaneously moving towards their vision of an Adminless
future. They're a large well-funded company filled with smart people, capable of
addressing multiple issues at once.


CONCLUSION

Microsoft created the Vulnerable Driver Blocklist to stop admins from tampering
with the kernel, but they've done nothing about an admin-to-kernel exploit chain
that was reported over 11 months ago. By removing the vulnerable driver
requirement from EDRSandBlast via GodFault, I hope to prove that admin-to-kernel
exploits can be just as dangerous as vulnerable drivers and that MSRC needs to
take them seriously. Given Windows 11's goal of default security and the fact
that the Vulnerable Driver Blocklist is now enabled by default, MSRC needs to
reconsider its policy of indifference towards PPL and kernel exploits.

JUMP TO SECTION

 * Introduction
 * Security boundaries
 * Exploiting vulnerabilities
 * Turnkey tooling
 * Mitigation
 * Discussion
 * Conclusion

ELASTIC SECURITY LABS NEWSLETTER

Sign Up

SHARE THIS ARTICLE

TwitterFacebookLinkedInReddit
 * Sitemap
 * Elastic.co
 * @elasticseclabs

© 2024. Elasticsearch B.V. All Rights Reserved.