As reported by The Hacker News, a fake LastPass Authenticator installer hosted on GitHub deploys a Microsoft-signed kernel driver — dubbed Alinubx.sys — that systematically terminates 145 antivirus and EDR processes before unleashing a password-stealing payload. The campaign, detailed by LastPass and Delphos Labs on September 17, 2026, is a textbook bring-your-own-vulnerable-driver (BYOVD) attack that exposes a persistent and uncomfortable truth: Microsoft's driver signing attestation pipeline validates provenance, not safety.
What makes this campaign particularly notable is not its sophistication — it's the convergence of several low-barrier techniques that together defeat modern endpoint defenses. The attackers combined DLL side-loading via a renamed copy of Microsoft's own vsdbg.exe, size-padded archives to exceed scanner limits, and a legitimately signed driver that scored zero detections on VirusTotal as recently as August 2026. The driver's kill list alone is sufficient to blind a target machine, and its additional capabilities — file hiding, process injection, traffic redirection — suggest the tool was built for broader operations than this single campaign.
Why This Matters Beyond LastPass
LastPass is clear that its systems and vaults were not compromised — the attackers merely borrowed brand trust. But the real story is the driver supply chain. A kernel driver signed through Microsoft's Hardware Compatibility Publisher chain in March 2023 remained trusted and undetected years later. This is not an isolated incident. The BYOVD technique has been used by ransomware groups including AvosLocker, BlackCat, and Robinhood. Each time, defenders are reminded that kernel-mode code operates below EDR visibility, and a signed driver is essentially a skeleton key to that layer.
Microsoft attestation proves a driver passed through a trust pipeline. It does not prove the driver is safe.
This gap between signing and safety is structural. The driver in question can kill security processes, hide files, inject code, and redirect traffic — all from kernel space — yet it passed Microsoft's compatibility program. Until signing programs incorporate behavioral analysis or runtime attestation, defenders must assume that signed does not mean benign.
Who Is Most at Risk
Shield53 Recommendations
Immediate Actions
- Enable Microsoft's Vulnerable Driver Blocklist via Windows Defender Application Control (WDAC) or Group Policy. Verify it is active and receiving updates — this driver was not on the list, but the blocklist is updated as threats are identified and is your primary native defense against BYOVD
- Deploy application allowlisting to prevent unsigned or unapproved executables from running, especially from user-writable directories like Downloads
- Restrict kernel driver loading using WDAC policies that only permit drivers from your organization's approved vendor list, rather than trusting all Microsoft Hardware Compatibility Publisher signatures
- Block GitHub-hosted installers at the web filter or proxy for users who should only download software from official vendor domains or enterprise software distribution channels
- Monitor for driver service installation events — specifically Event ID 7045 (Service Install) where the service type is kernel mode driver, and alert on any unexpected driver service creation
Strategic Actions
- Audit your EDR's kernel-mode visibility — confirm whether your endpoint platform can detect driver-based process termination or only sees the aftermath (AV services stopping unexpectedly)
- Implement detection rules for DLL side-loading patterns — flag signed Microsoft binaries (like vsdbg.exe) executing from non-standard directories alongside unsigned or recently created DLLs
- Alert on bulk security process termination — multiple AV/EDR processes stopping within a short window is a high-fidelity indicator of BYOVD activity, even if the driver itself goes undetected
- Educate users that legitimate software is distributed through vendor websites and official app stores, not GitHub repositories — reinforce this with browser warnings or proxy blocks for software download attempts from code-hosting platforms
The fundamental issue is trust architecture. We have built endpoint security in user mode while granting kernel-mode access to any driver that passes a provenance check. Until that asymmetry is addressed — through behavioral driver signing, mandatory runtime attestation, or broader adoption of WDAC — BYOVD will remain one of the most reliable tools in an attacker's arsenal. This campaign is not novel in technique, but it is a clear signal that the gap between signing and safety has not closed.
