CREDENTIAL SECURITY

Fake LastPass Authenticator Installs a Microsoft-Signed Driver That Kills 145 Security Tools

A fake LastPass Authenticator installer hosted on GitHub drops a Microsoft-signed Windows kernel driver that terminates 145 antivirus and EDR processes before a credential stealer runs.

Matt Lucas  |  September 22, 2026  |  5 min
Editorial hero illustration
145
security processes on the kill list
0 of ~70
VirusTotal engines flagged the renamed driver
148 MB
padded archive to skip scanner size limits
March 2023
Microsoft signing date on the driver
Detected by CaverLive detection for CVE-2013-4786 in the RedEye Intel Feed →
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

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:

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 NvFsFilter

Scans 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, Status

Confirms Microsoft's vulnerable driver blocklist is actually enabled (1 means on)

reg query "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v VulnerableDriverBlocklistEnable

Close it

Disables and stops the malicious driver service (admin shell, takes effect fully after reboot)

sc.exe config NvFsFilter start= disabled
sc.exe stop NvFsFilter

Quarantines 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.bak

No 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 /f

Prompts for the agent you already run

Paste this when you need to know whether a specific Windows host ran the fake installer

Check this Windows host for the LastPass Authenticator fake installer campaign. Run these read-only checks and print the raw output of each before you interpret it: 1) sc.exe query NvFsFilter, 2) Test-Path C:\Windows\System32\drivers\nvfsflt64.sys, 3) Get-ChildItem C:\Windows\System32\drivers\*.sys | Get-AuthenticodeSignature | Where-Object { $_.SignerCertificate.Subject -match 'CnCrypt|Henan Dafeng' }, 4) Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} filtered for NvFsFilter or nvfsflt64, 5) reg query "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v VulnerableDriverBlocklistEnable. Then tell me which indicators hit and which did not. Do not stop any service, move any file or change any registry value. Stop and wait for my approval before any remediation step.

Paste this after an indicator hits and you need containment written up before anyone touches the box

Indicators for the Alinubx.sys kernel driver campaign matched on this host. Draft a containment plan for me and show every command you would run with its expected output, but execute nothing yet. Cover: disabling the NvFsFilter service, moving C:\Windows\System32\drivers\nvfsflt64.sys to C:\Quarantine instead of deleting it, capturing the file hash first with Get-FileHash, listing which credentials on this host must be rotated from a different clean device (browser-saved passwords, Windows Credential Manager, cryptocurrency wallet files, Discord, Steam and Telegram sessions), and why an in-place cleanup is not sufficient for a kernel-level compromise. Stop before executing and wait for my go-ahead on each step.

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