Microsoft Signed the Driver That Killed EDR Across My Fleet Last Week

The uncomfortable part isn’t that malware disabled EDR. Malware has been trying to do that for years. The uncomfortable part is how: a kernel driver that Windows loaded without complaint, because it carried a valid Microsoft signature, and then reached down into ring 0 to terminate the security agent that was supposed to catch it. By the time a password stealer touched disk, the thing watching for password stealers was already dead.

This is the maturation of a technique the industry has been nervous about for a while. Bring Your Own Vulnerable Driver — BYOVD — meant smuggling in a legitimately signed but buggy driver and exploiting the bug to run in the kernel. The evolution on display here is blunter: don’t bother with the bug. Bring your own legitimately signed driver whose entire job is to kill security tooling, and let Microsoft’s trust chain wave it through the door.

September 17, 2026 — the disclosure

LastPass, working with Delphos Labs, published details of a campaign hosting a fake LastPass Authenticator installer on GitHub. The Hacker News picked it up the same week. The lure is exactly the kind of thing that works: a repository dressed up to look like an official project, a download that promises the real product, an MSI that installs something — just not what the user wanted.

What that MSI actually does, in order:

1. Impersonates the LastPass Authenticator on a GitHub-hosted page convincing enough to survive a glance.
2. Delivers an MSI the user runs voluntarily, with the privileges they hand it.
3. Drops a signed kernel-mode driver and loads it as a service.
4. Uses that driver, from the kernel, to disable or terminate AV/EDR processes running in userland.
5. Runs an infostealer against the now-undefended host — browser vaults, credentials, tokens.

Read that chain again and notice where the leverage sits. Step 3 is the whole game. Everything before it is social engineering you’ve seen a hundred times. Everything after it is trivial once the referee has left the field.

Why Windows let the driver load

Since Windows 10, 64-bit kernel-mode drivers must be signed through Microsoft’s process. In practice that means either full WHQL certification or the lighter attestation-signing path, where a developer with an EV certificate submits a driver and Microsoft counter-signs it. The signing establishes provenance — this came from an enrolled partner — not virtue. Microsoft is not auditing what the driver does at runtime, and it never claimed to.

So a driver whose sole purpose is to enumerate and kill security processes can carry a chain that terminates at a Microsoft signature. Defender’s reputation checks and SmartScreen lean on exactly that kind of trust signal. A file signed through the hardware program looks, to a lot of controls, like it belongs.

Do not turn this into a “Microsoft signed malware” morality tale. The attestation process trusts the submitter’s claims, and abuse of it means someone burned an enrolled identity or a stolen certificate — a problem of revocation speed, not signing philosophy. The correct question for a defender isn’t why did they sign it. It’s why does my fleet load kernel drivers it has never seen before without anyone noticing.

What actually got bypassed

Here’s where I’ll disappoint anyone hoping for a scoreboard. “EDR was bypassed” is not the same as “all EDR is defeated.” The technique works against agents whose protection lives in userland processes that a kernel driver can terminate. Products that run their own kernel component as a Protected Process Light (PPL), or that are hardened against kernel-issued termination, raise the cost considerably — a userland-only stealer can’t casually reach in and kill a PPL-protected service.

If your vendor has confirmed exposure in their own advisory, believe that over any list floating around. Treat unverified “EDR X is dead” claims as marketing from whichever competitor is loudest this week. The specific driver filename, SHA-256, and certificate subject are the IOCs that matter — pull them from the LastPass and Delphos Labs write-ups directly rather than from a secondhand summary, and feed those exact values into your hunts. Where the driver was attestation-signed, expect a signer chain rolling up to Microsoft Windows Hardware Compatibility Publisher; that publisher on a driver you don’t recognise is a strong prompt to investigate, not proof of malice on its own.

September 22, 2026 — what I did about it

I turned on the vulnerable-driver blocklist across the fleet for a week and watched what tried to load. The honest result: almost nothing legitimate broke, and I got a clean baseline of every driver our estate actually depends on — which turned out to be the more valuable artifact. You cannot spot the anomalous driver until you know what normal looks like.

Start by checking whether the Microsoft Vulnerable Driver Blocklist and memory integrity are even on. On a lot of estates, they quietly aren’t:

1
2
3
4
5
6
7
8
9
10
11
12

# Report-only: is the vulnerable driver blocklist enabled?
$ci = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config' -ErrorAction SilentlyContinue
[pscustomobject]@{
    VulnerableDriverBlocklistEnable = $ci.VulnerableDriverBlocklistEnable  # 1 = on
    HVCI_MemoryIntegrity            = (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning -contains 2
}
​
# Enumerate loaded kernel drivers as a baseline
Get-CimInstance Win32_SystemDriver |
    Where-Object State -eq 'Running' |
    Select-Object Name, DisplayName, PathName, StartMode |
    Sort-Object Name | Format-Table -AutoSize

Then confirm the ASR rule that targets this exact behaviour. Block abuse of exploited vulnerable signed drivers carries GUID 56a863a9-875e-4185-98a7-b882c64b5ce5. Audit its state before you enforce it:

1
2
3
4
5
6
7
8
9
10

# Report current ASR state (1 = Block, 2 = Audit, 0 = off/not set)
$rule = '56a863a9-875e-4185-98a7-b882c64b5ce5'
$pref = Get-MpPreference
$ids  = $pref.AttackSurfaceReductionRules_Ids
$acts = $pref.AttackSurfaceReductionRules_Actions
$idx  = $ids.IndexOf($rule)
if ($idx -ge 0) { "Rule state: $($acts[$idx])" } else { "Rule not configured" }
​
# When ready, run in AUDIT first, review telemetry, THEN switch to Block (1)
# Set-MpPreference -AttackSurfaceReductionRules_Ids $rule -AttackSurfaceReductionRules_Actions 2

If you run Defender for Endpoint, hunt for recent kernel driver loads across the estate and surface the ones you can’t account for:

1
2
3
4
5
6
7
8
9

// Advanced hunting: newly loaded kernel drivers, last 14 days
DeviceEvents
| where Timestamp > ago(14d)
| where ActionType == "DriverLoad"
| summarize Hosts = dcount(DeviceId), FirstSeen = min(Timestamp)
    by FileName = tostring(AdditionalFields.FileName),
       SHA256   = tostring(AdditionalFields.SHA256)
| where Hosts < 5   // rare drivers are the interesting ones
| order by FirstSeen desc

Prioritise like this. This week: enable the vulnerable driver blocklist and memory integrity (HVCI) where hardware allows, and move that ASR rule from audit to block once you’ve confirmed nothing legitimate trips it. HVCI matters because it blocks unsigned and revoked drivers at load time regardless of what the MSI wants. Next cycle: stand up Windows Defender Application Control (WDAC) with the Microsoft-recommended driver blocklist, deployed in audit mode first — WDAC is the control that lets you say “only drivers I’ve approved load here,” which is the actual answer to bring-your-own-signed-driver. Immediately, and free: tell people that security tools do not ship from random GitHub repos, and pull IOCs from the vendor advisories into your blocklists today.

GitHub stays the delivery vector because it launders reputation. A domain typosquat looks like a domain typosquat; a repository under a plausible name, with stars and a README, borrows the platform’s credibility for free. That’s not a bug GitHub can fully patch — it’s the cost of an open platform, and attackers have read the pricing.

The next dated beat worth watching is the driver blocklist itself. Microsoft ships updates to it, and revocation of the abused signing identity is what actually closes this instance. Until that revocation lands and propagates, a valid signature is doing exactly what it was designed to do — vouching for a stranger. Watch your Patch Tuesday notes and your blocklist version, and in the meantime, assume any kernel driver your fleet hasn’t seen before is guilty until your baseline says otherwise.