The download button sits on a GitHub organisation page called LastPass-Authenticator. It ranks for the phrase "LastPass Authenticator download", it carries the right logo, and it leads through two hidden redirector pages to an attacker-controlled server. What comes back is a ZIP of 148 MB, padded with junk files so that scanners with size limits skip it.
Inside are a renamed copy of Microsoft's vsdbg.exe debugger, a malicious vsdbg.dll placed beside it, and a Windows kernel driver that Microsoft's hardware compatibility programme signed in March 2023. That driver, Alinubx.sys, carries a list of 145 named antivirus and endpoint security products and terminates every one it finds running. It does that from kernel mode, below the layer those products live in, and it does it before a credential stealer starts work. LastPass and Delphos Labs published the joint analysis on September 17.
Who owns this, and who can close the tab
You own this if somebody in your company can download an installer and end up with administrator rights on the machine. That is the entire prerequisite. The loader tries three routes to elevation, reaches SYSTEM, and registers the driver as a service. Everything after that point happens underneath the software you bought to notice it.
You own it twice if your endpoint plan is one agent and nothing behind it, because the agent is the thing being switched off.
You can close the tab if App Control for Business runs in enforced mode across your fleet, or if a standard user on your estate genuinely cannot reach local administrator by any route. Mac and Linux shops can close it too, with one caveat: the same operator ran a near-identical page for a "macOS LastPass" product, and it came down before the researchers could take it apart.
This story does not touch LastPass the product. The company states that no LastPass system, service, or customer vault was involved, and that the lure travelled entirely outside its channels. The name was borrowed, along with at least 40 other brands served from the same host. If you use the password manager, this campaign hands you nothing to rotate on that account.
The driver was catalogued in June
Alinubx.sys is a renamed copy of CcProtect.sys, a driver that ships with CnCrypt, a disk-encryption product from Henan Dafeng Software Co., Ltd. The rename changed the file name and the description. The product name, the version string 1.32, and the submitter stayed in the version resources, which turns out to be the useful part.
The original carries a LOLDrivers catalogue entry dated June 16, 2026, classified as a process-killer provider under ATT&CK T1562.001, with public proof-of-concept code attached. Three months of public notice, exploit included.
Two things follow from the rename, and the second one is worth your afternoon.
Detections collapsed. Delphos checked the renamed driver on August 20 and got zero hits from 72 engines.
Then the finding: Microsoft's vulnerable driver blocklist carried neither file. Not the renamed Alinubx.sys, and not the catalogued CcProtect.sys underneath it. The rename bought nothing against the blocklist. The original was never on the list to begin with.
Delphos reported the driver to MSRC on August 19. Microsoft replied that the behaviour does not meet its definition of a security vulnerability, since the driver belongs to a third party, and redirected the report to the separate driver submission portal that considers drivers for the blocklist. That case was closed. Delphos resubmitted the same day. At publication on September 17, the driver was still absent from the list.
Microsoft's own documentation is direct about the limits. The blocklist "isn't guaranteed to block every driver found to have vulnerabilities", and the page explains why: "It's often necessary for us to hold back some blocks to avoid breaking existing functionality while we work with our partners." It refreshes quarterly. Read it as what it is: a list of drivers somebody else judged safe enough to block, updated four times a year.
Three controls, and what each one stops here
Most teams have a version of this argument once a year and settle it with opinions. Here it is settled against one real chain.
The vulnerable driver blocklist
On by default since the Windows 11 2022 update, and additionally enforced whenever memory integrity (HVCI), Smart App Control, or S mode is active. It matches known file hashes. Against this chain it contributes nothing, because neither hash appears on it. Leave it enabled. Stop counting it as coverage.
The Defender ASR rule
"Block abuse of exploited vulnerable signed drivers", GUID 56a863a9-875e-4185-98a7-b882c64b5ce5. Read Microsoft's description of the rule closely before you rely on it: it "prevents apps from saving vulnerable signed drivers on the computer. It doesn't prevent loading existing drivers already on the computer." The documented alerting behaviour is a user notification pop-up, with no EDR alert raised. It also rests on the same judgement about which drivers are known-bad, so a file that nobody has flagged gets written to disk.
App Control for Business, matched on attributes
App Control policies can deny on the signer and on the version-resource attributes instead of the hash. A rule written against the publisher "Henan Dafeng Software Co., Ltd." or the product name "CnCrypt" survives a rename, survives a recompile, and catches whatever the operator calls the file next week. Microsoft says as much on the blocklist page itself: "Microsoft recommends using an explicit allowlist approach to security wherever possible."
A minimal deny fragment to fold into a policy you already maintain:
<FileRules>
<Deny ID="ID_DENY_CNCRYPT_PRODUCT" FriendlyName="CnCrypt product, any file name"
ProductName="CnCrypt" MinimumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_CCPROTECT_ORIGINAL" FriendlyName="CcProtect original filename"
InternalName="CcProtect.sys" MinimumFileVersion="65535.65535.65535.65535" />
</FileRules>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_DENY_CNCRYPT_PRODUCT" />
<FileRuleRef RuleID="ID_DENY_CCPROTECT_ORIGINAL" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>Ship it in audit mode first. Read Microsoft-Windows-CodeIntegrity/Operational for a week, where event 3076 records what an enforced policy would have blocked, then flip to enforce once the log is quiet. On a small estate that is an afternoon of work and a week of patience.
One honest caveat about memory integrity. The public proof-of-concept for CcProtect.sys notes that HVCI had to be off for stability, and LOLDrivers records this sample's load behaviour under HVCI as unknown. Turning memory integrity on remains the right call. Treating it as proof that this driver cannot load is a claim nothing published supports.
What to check on a machine you cannot rebuild tonight
Hunt the lineage rather than the file name, because the operator has already changed the file name once. Four artefacts hold across a rename, because they live in the driver's version resources and in its own service plumbing.
# Run elevated. Reads local state only: no network calls, no changes.
# 1. The service the loader registers.
Get-CimInstance Win32_SystemDriver |
Where-Object { $_.Name -eq 'NvFsFilter' -or $_.PathName -match 'nvfsflt64\.sys' } |
Select-Object Name, DisplayName, State, PathName
# 2. Any driver on disk whose signer or product resources trace back to CnCrypt,
# whatever the file happens to be called this week.
Get-ChildItem "$env:SystemRoot\System32\drivers\*.sys" -ErrorAction SilentlyContinue |
ForEach-Object {
$v = $_.VersionInfo
if ($v.CompanyName -match 'Henan Dafeng' -or
$v.ProductName -match 'CnCrypt' -or
$v.OriginalFilename -match 'CcProtect') {
[pscustomobject]@{
File = $_.FullName
Company = $v.CompanyName
Product = $v.ProductName
Origin = $v.OriginalFilename
Signer = (Get-AuthenticodeSignature $_.FullName).SignerCertificate.Subject
}
}
}
# 3. The rootkit configuration file. Present means the wider feature set was armed.
Test-Path "$env:SystemRoot\Alinubx.ccf"
# 4. Kernel driver service registrations in the last 30 days, for eyes-on review.
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=7045;
StartTime=(Get-Date).AddDays(-30) } -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match 'kernel mode driver' } |
Select-Object TimeCreated, @{ n='Detail'; e={ $_.Message -replace '\s+',' ' } }The device path \\.\Alinubx is the fourth artefact, and it is the one an EDR query can reach without touching every endpoint by hand. Behaviourally, the rule to write is a driver load followed by security processes terminating. A community detection for this exact driver is published on LOLDrivers, and it matches by hash, so it inherits the weakness this whole story is about.
If it ran, the credentials left before the driver loaded
The order of events decides the response. The stealer, which LastPass calls Rapuncel, collects first: saved passwords from 19 or more browsers, files for 34 or more cryptocurrency wallets, Discord and Steam and Telegram session data, the contents of Windows Credential Manager, and screenshots of every attached monitor. The archive leaves over a raw TCP connection.
App-bound encryption in Chrome and Edge does not hold against it. The stealer injects code into the browser process and asks the browser's own decryption service for the passwords, so the request arrives from a caller the browser already trusts. The protection works exactly as designed and answers anyway.
Three consequences for the first hour:
- Rotate from a different machine. The driver stays loaded, re-kills the security tools, and re-runs the stealer on every reboot. Credentials typed into the affected host during cleanup go out with the next upload.
- Revoke sessions, not only passwords. Stolen session tokens for mail, chat and single sign-on outlive a password change. In Entra ID that is a revoke-sessions action on the user, not a reset.
- Treat the host as a kernel-level compromise. A user-mode cleanup runs inside the layer the driver controls. Rebuild it, or get a kernel-level forensic look before you hand it back.
Write the deny rule for the signer, not the file name
The one change worth making this week is small and specific. Open the App Control policy you already have, add a deny on the CnCrypt product attributes, and run it in audit mode while you read the Code Integrity log. If you have no policy at all, that afternoon is the whole project: an audit-mode driver policy costs nothing to run and tells you exactly which third-party kernel drivers your estate already loads. Most owners are surprised by that list, and the list is the point. Every one of those drivers is trusted by your machines on the strength of a signature somebody obtained years ago.
We build and test the endpoint and incident-response side of this for organizations that have one agent and no kernel telemetry behind it, which describes most small teams. If you want a second set of eyes on your driver policy or on a host you suspect ran something like this, book a session and bring the log.
Need an incident response plan before the next attack?
We help organizations build and test incident response playbooks, including the endpoint and kernel-driver controls that decide whether the playbook ever gets a chance to run. Book a session with our team.