Build1 publisher3 min readPublished
A Microsoft-signed driver in a fake LastPass installer kills 145 security processes from the kernel
Alinubx.sys terminates security agents from kernel mode under a Microsoft Windows Hardware Compatibility Publisher signature dated March 2023, and nothing in the driver has to be exploited for that to work.
The Engineer · Build desk

What happened
- A fake LastPass Authenticator installer side-loads a malicious DLL, escalates to SYSTEM and installs a Microsoft-signed kernel driver that terminates 145 named antivirus and EDR processes before a credential stealer runs.
- The entry point is a GitHub page that imitates a LastPass product page and ranks for search terms like "LastPass Authenticator download", routing clicks through several GitHub pages to an attacker-controlled server serving a large ZIP.
- The driver is a renamed copy of CcProtect.sys from the Chinese disk encryption product CnCrypt, already catalogued on LOLDrivers as a process killer with public proof-of-concept code.
- Delphos Labs checked Microsoft's vulnerable driver blocklist on August 20 and found neither the renamed driver nor the original it was copied from listed, and as of the report the driver still is not.
- Microsoft told the researchers the behaviour does not meet its definition of a security vulnerability, because the driver is not a Microsoft component.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Neither default control narrows the set of drivers that can kill an agent: allowlisting on a Microsoft signing chain admits this file, and a hash-matched blocklist cannot cover the next rename or recompile of the same code.
- exposure The agent that dies is the thing that would have logged its own death, so the first signal available to an operator is a host that stopped reporting.
- decision Teams that enforce driver policy have to pick between waiting for Microsoft's blocklist to grow and maintaining their own deny list from catalogues like LOLDrivers, including renamed variants.
- precedent Microsoft's answer sets the expectation that a third-party driver abused exactly as written is not a Microsoft vulnerability, so removal depends on the pace of a separate evaluation queue.
The kill runs in kernel mode, below the layer where user-mode security agents live, so those agents cannot block it and cannot record it [7]. The signature is what makes that cheap. Alinubx.sys is signed through the Microsoft Windows Hardware Compatibility Publisher chain with a signing date of March 2023, years ahead of this campaign, and Windows trusts it on sight [8]. This is bring your own vulnerable driver with one change: the attackers run the driver exactly as designed [9].
Microsoft's vulnerable driver blocklist, which the source describes as the control most teams assume covers this case, has been enabled by default since the Windows 11 2022 Update [10]. It matches known file hashes, so any rename or recompile produces a hash the list does not carry [11]. In this case the original was never on the list in the first place [12].
The rename did change what scanners said. In August the known original was flagged by 7 of roughly 70 antivirus engines, and the renamed copy was flagged by none of them [13]. That is about one engine in ten on a file with public proof-of-concept code, and zero once the file name and description changed [1]. The two files share product name, version and submitter [14]. The renamed driver itself scored zero detections on VirusTotal when researchers checked it in August [3].
The joint LastPass and Delphos Labs analysis, published September 17, is direct about what the signature proves [2]. "Microsoft attestation proves a driver passed through a trust pipeline. It does not prove the driver is safe," the researchers wrote [15]. Their recommendation is to treat Windows Hardware Compatibility Publisher signing as provenance metadata, and not to let driver allowlisting stop at "signed by a Microsoft chain" [16].
Delphos reported the driver to Microsoft on August 19, one day before it checked the blocklist [17][2]. Microsoft directed the researchers to a separate channel that evaluates such submissions [18].
The delivery side is cheaper to stop than the driver. The archives observed were 148 MB and 127.9 MB, padded with junk files so that scanners enforcing a maximum file size skip them entirely [19]. Inside sits a renamed copy of vsdbg.exe, a legitimate Microsoft debugging tool, next to a malicious file called vsdbg.dll, so running the fake installer makes Windows load the attacker's DLL from the same folder [20]. The loader then tries three separate routes to administrator rights, reaches SYSTEM, and registers the kernel driver as a service [21]. The genuine LastPass Authenticator ships from lastpass.com and the official mobile app stores [22].
The driver's code also supports hiding files, injecting into other programs and rerouting web traffic, but those functions require a configuration file the operators did not include, so they stayed dormant [23]. LastPass says none of its own systems, services or customer vaults were touched [24]. A user who ran the file lost every credential stored on that machine, whichever password manager they use [25].
What to watch
- Whether Microsoft adds hashes for Alinubx.sys or CcProtect.sys to the vulnerable driver blocklist, and how long that takes after the September 17 analysis.
- Whether a later sample ships the configuration file that activates the driver's file-hiding, injection and traffic-rerouting functions.
- Whether the github.com/LastPass-Authenticator page stays up and keeps ranking for download searches.