A fake LastPass Authenticator installer kills antivirus and EDR with a Microsoft-signed driver
On September 17, 2026 LastPass and Delphos Labs revealed that a fake LastPass Authenticator installer deployed Alinubx.sys, a Microsoft-signed kernel driver that terminates 145 security processes before a password stealer runs. Add the driver’s hash to your blocklists and treat every password on an affected machine as compromised.
September 17, 2026. LastPass and Delphos Labs publish their analysis of Alinubx.sys. August 2026. the driver scores zero detections on VirusTotal. August 19, 2026. Delphos Labs reports it to Microsoft. Why it matters: a fake installer ships a Microsoft-signed kernel driver that kills 145 security processes, then lets a password stealer empty the machine.
LastPass says none of its systems, services, or customer vaults were touched — the attackers only borrowed its name. The lure is a fake GitHub page, github.com/LastPass-Authenticator, that ranks for “LastPass Authenticator download” and mimics a real product page. The genuine LastPass Authenticator ships from lastpass.com and the official app stores, never from GitHub.
How the payload reaches the kernel
The download button routes the visitor through several GitHub pages to an attacker-controlled server, which serves a large ZIP archive — 148 MB and 127.9 MB in the observed samples. The size is deliberate: the archive is padded with junk files so scanners with a size limit skip it.
Inside sits a renamed copy of vsdbg.exe, Microsoft’s real debugger, placed next to a malicious vsdbg.dll. When the fake installer runs, Windows loads the attacker’s DLL from the same folder — the DLL side-loading technique. The loader then tries three ways to gain administrator rights, reaches SYSTEM, the highest level on a Windows box, and installs the kernel driver as a service.
A signed driver that bypasses the defenses
The driver, which the researchers named Alinubx.sys, carries a list of 145 antivirus and EDR process names and terminates each one it finds running. It does so from the kernel, below the level where user-mode security tools operate, so those tools can neither block nor observe the kill. Loading a legitimately signed but abusable driver to gain that access is a known technique called BYOVD — bring your own vulnerable driver.
The driver is signed through the Microsoft Windows Hardware Compatibility Publisher chain, with a signing date of March 2023, years before this campaign. As the researchers put it: “Microsoft attestation proves a driver passed through a trust pipeline. It does not prove the driver is safe.” The kill list is the only part of the driver actually exercised here. Its code can also hide files, inject into other programs, and reroute web traffic, but those functions need a configuration file the attackers did not include.
What the stealer takes
The driver’s work is enough. With security software down, the stealer collects saved passwords from more than two dozen browsers, cryptocurrency wallet files, Discord, Steam, and Telegram sessions, the contents of Windows Credential Manager, and files named like “password”, “seed”, or “recovery”.
For Chrome and Edge, which use Google’s app-bound encryption specifically to block this kind of theft, the stealer injects into the browser and asks the browser’s own service to decrypt the passwords. The data is then packed into a ZIP and sent to an attacker server.
Why nothing caught it
The driver is a renamed copy of CcProtect.sys, a driver from the Chinese disk-encryption product CnCrypt, already listed in the LOLDrivers catalog as a process killer with public proof-of-concept code. The two share the same product name, version, and submitter; only the file name and description changed.
That rename collapsed the detections. The known original was flagged by 7 of about 70 engines in August, while the renamed driver showed zero. Microsoft’s vulnerable driver blocklist, on by default since the Windows 11 22H2 update, offers no extra protection either: Delphos Labs checked on August 20 and found neither the renamed driver nor the original on it. The blocklist matches file hashes, and a renamed or recompiled driver produces a hash the list does not carry. As of the September 17 report, Alinubx.sys was still not on it.
Delphos Labs reported the driver to Microsoft on August 19. Microsoft’s response: the behavior does not meet its definition of a security vulnerability because the driver is not a Microsoft component — and it pointed the researchers to the separate channel that reviews drivers for the blocklist.
The renaming trick exposes a deeper limit in hash-based defense. The blocklist that should have caught this driver compares cryptographic hashes, so a one-byte change to the file produces a different hash and a clean pass. The original CcProtect.sys was already a known process killer on LOLDrivers with public exploit code, yet that knowledge did not automatically propagate to the renamed copy. Defense that keys on hashes is only as good as its list; defense that keys on behavior — signing chain, product metadata, or the driver’s capabilities — would have flagged the rename as the same abusable driver in different clothing.
BYOVD is a family that keeps returning
Alinubx.sys is not an isolated case: it is the latest iteration of a family of attacks defenders have called BYOVD for years. The principle is always the same — load a legitimately signed but abusable driver to gain kernel privileges — and the LOLDrivers catalog lists dozens of these drivers, each with public proof-of-concept code.
What sets this campaign apart is the chain of trust. The driver is signed through Microsoft’s Windows Hardware Compatibility Publisher program in March 2023, a channel endpoint defenses treat as legitimate by default. Once loaded, it operates below the security tools, which makes EDR detection structurally hard: the EDR sees the driver load, but not what it does once installed.
That is exactly why the defense has to move upstream: monitor the driver-load event, log kernel-service installations, and apply WDAC or a driver blocklist rather than relying on the signature. Trust in a driver should never rest on the signer’s attestation alone.
What you should do
The first step is defensive and immediate. Check whether the driver is present on your fleet and add its hash to your blocklists while waiting for it to land on the official list:
# Find the renamed driver among running drivers
Get-CimInstance Win32_SystemDriver |
Where-Object { $_.PathName -match 'Alinubx' } |
Select-Object Name, State, PathName
# Hash a suspicious sample to add it to your blocklists
Get-FileHash -Algorithm SHA256 .\Alinubx.sysThe second step concerns victims. If someone ran the fake installer, treat every password saved in the browser as stolen, along with cryptocurrency wallets, Discord, Steam, and Telegram sessions, and the contents of Credential Manager. Change those passwords from a separate, clean device, not the affected one, and review account activity. The driver stays loaded, re-kills security tools, and re-runs the stealer until it is neutralized.
The deeper lesson applies to every SOC: a Microsoft signature does not vouch for a driver. The controls that matter are the vulnerable driver blocklist, monitoring newly loaded drivers, and limiting who can install a kernel service on an endpoint.
Verdict
Alinubx.sys is a demonstration that a cleanly executed BYOVD can neutralize an entire defensive chain without being detected. If you are not yet tracking drivers loaded on your endpoints, start by adding this hash to your blocklists and logging kernel-service installations. If a machine was affected, reimaging is the safe answer: changing passwords is not enough while a signed driver stays loaded and can re-kill your defenses on every reboot.