- 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.
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.
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.
Fix It Yourself
Everything above is what happened. This is what to run. The check commands change nothing.
Check whether you are exposed
Checks whether the campaign's service name is registered on this host
sc.exe query NvFsFilterScans installed drivers for the CnCrypt or Henan Dafeng signer used by this driver family
Get-ChildItem C:\Windows\System32\drivers\*.sys | Get-AuthenticodeSignature | Where-Object { $_.SignerCertificate.Subject -match 'CnCrypt|Henan Dafeng' } | Select-Object Path, StatusConfirms Microsoft's vulnerable driver blocklist is actually enabled (1 means on)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v VulnerableDriverBlocklistEnableClose it
Disables and stops the malicious driver service (admin shell, takes effect fully after reboot)
sc.exe config NvFsFilter start= disabled
sc.exe stop NvFsFilterQuarantines the driver file rather than deleting it, so forensics still has the sample
mkdir C:\Quarantine
move C:\Windows\System32\drivers\nvfsflt64.sys C:\Quarantine\nvfsflt64.sys.bakNo blocklist entry exists for this driver yet, so this only hardens coverage for drivers Microsoft has listed; reboot required
reg add "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v VulnerableDriverBlocklistEnable /t REG_DWORD /d 1 /fPrompts for the agent you already run
Paste this when you need to know whether a specific Windows host ran the fake installer
Paste this after an indicator hits and you need containment written up before anyone touches the box
What to alert on
The highest-value observable is a kernel driver load immediately followed by security tooling going quiet. In Sysmon, alert on Event ID 6 (DriverLoad) where the ImageLoaded path is C:\Windows\System32\drivers\nvfsflt64.sys or where the Signature or signer fields contain "CnCrypt" or "Henan Dafeng Software", and pair it with Windows System log Event ID 7045 (Service Control Manager, service installed) where ServiceName is NvFsFilter or ImagePath references nvfsflt64.sys. Because a rename produces a new hash and a new file name, make the behavioral correlation the primary rule: any Event ID 6 driver load from a non-baselined path, followed within 60 seconds by two or more Sysmon Event ID 5 (process terminated) events for your EDR or AV agent binaries, or by your EDR management console reporting agent heartbeat loss on that asset. Add a secondary rule on Sysmon Event ID 1 for a process named vsdbg.exe executing from a user-writable path such as Downloads, Temp or Desktop, since the legitimate Microsoft debugger does not normally run from there, and on Event ID 7 loading vsdbg.dll from that same directory. Endpoints that report a driver load and then stop reporting at all should be treated as the alert, not as a gap in telemetry.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us