Fake LastPass Installer Ships a Signed Driver That Kills 145 EDRs

A GitHub organization calling itself LastPass Authenticator has been pushing a new infostealer called Rapuncel, bundled with a kernel driver that kills 145 antivirus and EDR processes on command. Microsoft still hasn't blocklisted that driver, a month after being told what it does. LastPass's Threat Intelligence, Mitigation and Escalation team (TIME) and Delphos Labs published the findings on September 17, tracing a campaign LastPass first spotted on August 13.

The fake org, github.com/LastPass-Authenticator, was built to rank for searches like "LastPass Authenticator download." Clicking through routes victims past redirects to a ZIP, either 148MB or 127.9MB, padded with junk files to blow past scanner size limits. The same server hosted more than 40 brand-impersonation pages, LastPass plus at least 39 others: a malware-as-a-service operation using GitHub Pages as trusted-looking hosting, not a one-off phishing kit. A near-identical fake macOS page was pulled before Delphos could analyze it. The real LastPass client only comes from lastpass.com or the official app stores.

RelatedA Windows Socket Driver Bug Handed Lazarus SYSTEM Access

How does the installer get from a download button to SYSTEM?

The ZIP has no obviously malicious executable. It has a renamed copy of Microsoft's own Visual Studio CoreCLR debugger, vsdbg.exe, sitting next to a file called vsdbg.dll. Windows loads DLLs from an executable's own folder first, so vsdbg.exe happily loads the attacker's DLL instead of a real one. That's DLL side-loading: the executable is legitimate and signed, the DLL beside it isn't, and Windows never questions the pairing. From there the loader hits SYSTEM, drops Rapuncel, and installs the kernel driver.

Why can a driver kill antivirus software that's supposed to stop it?

Most coverage skips this part. Protected Process Light, the mechanism Windows Defender and some EDR agents lean on, stops ordinary processes from touching a protected one. It does nothing against a kernel driver, which runs at the kernel's own privilege level and calls process termination directly, no permission check, no hook to trip. Alinubx.sys works a kill list of 145 named AV and EDR processes from below the layer security tools can see.

The driver poses as an NVIDIA component, dropping as nvfsflt64.sys and registering the service NvFsFilter, device path \.Alinubx. It isn't new code: Delphos traced it to CcProtect.sys, from the Chinese product CnCrypt, signed through Microsoft's Windows Hardware Compatibility Publisher chain in March 2023, signer pointing to Henan Dafeng Software. Renamed, it scored zero of 72 on VirusTotal in August; the original still gets flagged by roughly 7 of 70. The rename alone erased it. It also carries dormant features unused here: hiding, DLL injection, process interception. Today it's only an AV killer; a sharper operator could ask for more.

Why is a driver Microsoft signed in 2023 still trusted in 2026?

This is the real story. A signature isn't a safety claim, it's a timestamp: the WHCP chain attests to a binary at signing, not that it's still fine three years and one identity swap later. Revoking trust isn't automatic. It needs the separate vulnerable driver blocklist, shipped through Windows Update and enforced by HVCI, Smart App Control, or WDAC, updated only once or twice a year.

Delphos reported Alinubx.sys on August 19. A day later they checked the blocklist: not on it, so they resubmitted through Microsoft's review channel. Microsoft's reply: the behavior "does not meet its definition of a security vulnerability, because the driver is not a Microsoft component." As of the September 17 publication it still isn't blocklisted, though a community detection now sits on LOLDrivers.

1. 2026-08-13LastPass finds the fake GitHub org TIME team
2. 2026-08-19Delphos reports Alinubx.sys to Microsoft MSRC channel
3. 2026-08-20Blocklist check comes up empty resubmitted for review
4. 2026-09-17Joint report published LastPass TIME, Delphos Labs
5. OngoingStill not on the blocklist "not our component," per Microsoft

What does Rapuncel actually take?

Once Alinubx.sys clears the security tools, Rapuncel harvests:

RelatedOpenAI, Anthropic, Google Rally 100+ Firms Against Rogue AI

• Saved credentials. Passwords from more than 20 browsers, plus Windows Credential Manager.
• Crypto and chat accounts. Wallet files, Discord, Steam, and Telegram sessions.
• Anything sensitive. Files matching "password," "seed," or "recovery," wherever they sit.
• Chrome and Edge. The stealer injects code into the browser process to request browser-based decryption, sidestepping app-bound encryption instead of trying to break it.

Delphos assesses with high confidence that the loader used the paid Cruciferra Crypter, whose default kill list is also 145 names, a hint this is a commercial toolkit, not a bespoke build. They tie Rapuncel to BoryptGrab with moderate confidence. Victim count isn't known, and that gap matters: a stealer this well packaged, behind a driver with unused hiding and injection features, isn't a campaign to assume stayed small.

How does this stack up against earlier kernel-killer campaigns?

AuKill rode a legitimate Process Explorer driver into BlackByte ransomware deployments in 2023. Terminator, sold as Spyboy, offered the same trick as a subscription tool. Both eventually got blocklisted. Alinubx.sys is the odd one out: still live a month after being reported.

Who's exposed, and what should you do today?

Anyone who installs software found through a search engine, rather than typing the vendor's URL, is exposed, which is most people. Small businesses without WDAC policies are worst off, relying entirely on a blocklist cadence Microsoft already said it won't fast-track. Code-signing status isn't a trust boundary on its own. WDAC, HVCI, and per-signer blocking rules are, and they work today.

Our take

The obvious write-up is "fake installer drops infostealer." The real one is that Microsoft's own signature is doing the attacker's work. A driver it approved in 2023 is still trusted by every machine that hasn't separately blocked it, a month after Microsoft was told what it does. "Not our component" is technically defensible, but it's also the kind of answer that turns a fast-moving criminal problem into a slow bureaucratic one. The GitHub angle deserves its own worry too: one kit stood up 40-plus brand-impersonation pages and let search ranking do the phishing, no email needed. That scales far past LastPass, and it keeps working until GitHub or search engines treat a freshly registered org squatting on a trusted brand as the red flag it is.

Original analysis by GenZTech. Source: LastPass: Rapuncel infostealer report