TL;DR
- what: A fake LastPass Authenticator installer on GitHub side-loads a malicious DLL, escalates to SYSTEM, and installs a Microsoft-signed kernel driver named Alinubx.sys that terminates 145 antivirus and EDR processes before running a credential stealer.
A fake LastPass Authenticator installer distributed through GitHub installs a Microsoft-signed Windows kernel driver that terminates 145 named antivirus and EDR processes, then runs a credential stealer against browsers, cryptocurrency wallets and Windows Credential Manager. LastPass and Delphos Labs published the joint analysis on September 17. When researchers checked the driver in August it scored zero detections on VirusTotal, and it was not on Microsoft's vulnerable driver blocklist. As of the report, it still is not.
LastPass says none of its own systems, services or customer vaults were touched. The attackers borrowed the brand, not the infrastructure. That distinction matters for your incident scoping and for nothing else: a user who ran this file lost every credential stored on that machine, regardless of which password manager they use.
The lure ranks in search results
The entry point is a GitHub page at github.com/LastPass-Authenticator that looks like a real LastPass product page and ranks for search terms like "LastPass Authenticator download". Clicking the download button routes the visitor through several GitHub pages to an attacker-controlled server, which serves a large ZIP. The genuine LastPass Authenticator ships from lastpass.com and the official mobile app stores. It is not distributed on GitHub, and that single fact is the cheapest user-facing control you have here.
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. Inside sits a renamed copy of vsdbg.exe, a legitimate Microsoft debugging tool, placed next to a malicious file called vsdbg.dll. Running the fake installer makes Windows load the attacker's DLL from the same folder, the classic DLL side-loading pattern. The loader then attempts three separate routes to administrator rights, reaches SYSTEM, and registers the kernel driver as a service.
A signed driver that kills 145 processes
The driver, which the researchers named Alinubx.sys, carries a hardcoded list of 145 antivirus and security process names and terminates every one it finds running. It does this from the kernel, below the layer where user-mode security agents live, so those agents cannot block the kill or record it. This is bring your own vulnerable driver, BYOVD, with one twist: the driver is not exploited, it is simply used as designed.
It is signed through the Microsoft Windows Hardware Compatibility Publisher chain, with a signing date of March 2023, years ahead of this campaign. Windows trusts it on sight.
Attestation is not assurance — The researchers put it plainly: "Microsoft attestation proves a driver passed through a trust pipeline. It does not prove the driver is safe." Treat WHCP signing as provenance metadata, not as a verdict, and do not let driver allowlisting stop at "signed by a Microsoft chain".
The driver can do more than kill processes. Its 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. The kill list on its own was sufficient.
The rename that erased detection
Alinubx.sys is a renamed copy of CcProtect.sys, a driver from the Chinese disk encryption product CnCrypt. That original is already catalogued on LOLDrivers as a process killer, with public proof-of-concept code. The two files share the same product name, version and submitter. Only the file name and the description changed. In August the known original was flagged by 7 of roughly 70 antivirus engines. The renamed copy was flagged by none of them.
Microsoft's vulnerable driver blocklist, enabled by default since the Windows 11 2022 Update, is the control most teams assume covers this case. Delphos checked it on August 20 and found neither the renamed driver nor the known original listed. The rename did not defeat the blocklist, because the original was never on it. The blocklist matches known file hashes, so any rename or recompile produces a hash it does not carry.
Delphos reported the driver to Microsoft on August 19. Microsoft replied that the behavior does not meet its definition of a security vulnerability, because the driver is not a Microsoft component, and directed the researchers to the separate channel that evaluates drivers for the blocklist. Delphos resubmitted there the same day. At publication on September 17, the driver was still not blocked.
What the stealer collected
With security software terminated, the stealer pulled saved passwords from more than two dozen browsers, cryptocurrency wallet files, and active login sessions for Discord, Steam and Telegram. It also took the contents of Windows Credential Manager and any file with a name containing "password", "seed" or "recovery". For Chrome and Edge, which use Google's app-bound encryption specifically to stop this, the stealer injects code into the browser process and asks the browser's own service to perform the decryption. Everything is packed into a ZIP and shipped to an attacker server.
⚠️ It survives the reboot and re-arms itself — The driver stays loaded. On every restart it re-kills security tooling and re-runs the stealer, which means the tools you would normally use to clean the machine are dead before they start. A host that ran this payload is a kernel-level compromise: give it a kernel-level forensic examination or rebuild it.
If a machine ran the installer
- Treat every password saved in a browser on that host as stolen, along with wallet files, Discord, Steam and Telegram sessions, and everything in Windows Credential Manager.
- Rotate those credentials from a separate clean device, never from the affected machine, since the stealer is still running there.
- Review account activity on the affected services for logins, transfers or session grants you did not perform.
- Rebuild the host, or at minimum image it and examine it offline. Kernel persistence means in-place cleanup by a user-mode agent is not reliable.
What to hunt for
The researchers stress hunting on lineage and behavior rather than a single file name, since the operators already demonstrated that a rename costs them nothing. Known artifacts from this campaign:
- Service: a service created with the name NvFsFilter
- File: a driver written to C:\Windows\System32\drivers\nvfsflt64.sys
- Signer: driver signing details naming Henan Dafeng Software or containing "CnCrypt"
- Device: the device path \.\Alinubx
- Behavior: any kernel driver load followed closely by security processes terminating
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} | Where-Object { $.Message -match 'NvFsFilter|nvfsflt64' }
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=6} | Where-Object { $.Message -match 'CnCrypt|Henan Dafeng' }
LOLDrivers publishes a community detection for this exact driver. It matches by hash, so it inherits the same weakness the blocklist has: it stops working the moment the operators change the file again. Build the behavioral rule as well, and treat any newly registered kernel service followed by EDR agent silence as an incident until proven otherwise.
Originally published on RedEye Threat Intelligence.
Top comments (0)