A Microsoft-signed driver kills 145 security tools, and Microsoft's own blocklist did not stop it

Reported to Microsoft on 19 August, still loading on 17 September

On 19 August 2026 Delphos Labs reported a kernel driver called Alinubx.sys to Microsoft. The driver was the component that let a fake LastPass Authenticator installer switch off antivirus and endpoint detection before stealing passwords. When the joint LastPass and Delphos report was published on 17 September, 29 days later, the driver was still not on Microsoft's vulnerable driver blocklist. It had carried a Microsoft signature, applied through the Windows Hardware Compatibility Publisher chain, since March 2023: 1,244 days before Delphos reported it to Microsoft.

That is the fact worth holding on to. It is also narrower than it sounds, so here is what it does not establish:

• It does not mean every Windows estate would load the driver. An organisation's own App Control policy, or a hash block set in an EDR console, can stop it regardless of Microsoft's list.
• It does not tell you the driver is still unblocked today, 22 September. I did not download Microsoft's current blocklist file to re-check it, and I found no later statement from Microsoft in the sources I read.
• It does not tell you how many people ran the installer. No source gives a victim, download or infection count.
• It does not show that every one of the 145 targeted security processes actually dies. The LOLDrivers record for the driver says that successful termination of protected processes "is not established".

The source for all of this is the LastPass and Delphos Labs report, published on 17 September by the LastPass Threat Intelligence, Mitigation and Escalation (TIME) team. The Hacker News covered it on 21 September. I read the report itself, the two LOLDrivers records for the drivers, and the three earlier vendor analyses it builds on.

Yes, this is the same campaign we covered on 19 September

Plainly: this is the same campaign as our briefing of 19 September, GitHub removed the fake LastPass repositories. Four of the six Rapuncel domains still resolve. Both pieces rest on the same primary source, the LastPass and Delphos report of 17 September, and The Hacker News story of 21 September reports that same document. It is not a new wave, a new lure or a new driver.

That briefing covered how people got to the malware: the fake GitHub organisation, the redirect chain, the attacker domains and which of them still resolved, why stars and commit history mean nothing, and what to do if a member of staff ran the installer. I will not repeat any of that here. This piece is about the driver. It is the part of the story that says the most about Windows defences, and the part the headlines put most weight on: "Microsoft-signed".

What the primary sources establish, and what they leave open

The questions a security lead asks about a campaign like this are how people got to it, which driver it used, whether Windows would block that driver, which products it kills, what it steals and who is behind it. The table sets each answer against what the sources do not say.

Established and not established, from the LastPass and Delphos report (17 Sep 2026), LOLDrivers, eSentire TRU (19 Aug 2026) and Proofpoint (20 Jul 2026)

Question	Established	Not established
Distribution	An organic search result for a LastPass Authenticator download led to a fake GitHub organisation page, github[.]com/LastPass-Authenticator	No source mentions paid search ads or malvertising. No ranking position or search engine is given
Driver	Alinubx.sys, a CnCrypt driver from Henan Dafeng Software, dropped as nvfsflt64.sys and run as the service NvFsFilter	Who submitted this build to Microsoft for signing
Signature	Microsoft Windows Hardware Compatibility Publisher chain, signed March 2023	That the signature was obtained fraudulently. The sources do not allege it
Blocklist	Not in Microsoft's enforced blocklist file downloaded on 20 August, and not added by publication on 17 September	Its status on 22 September. Whether the check compared Authenticode hashes (see below)
Products killed	145 hardcoded process names. eSentire's analysis of Cruciferra's default list names Defender, Defender for Endpoint, CrowdStrike, SentinelOne, Sophos and more	LastPass publishes no names. That Rapuncel's list matches eSentire's is an inference from the shared count and the Cruciferra link
Payload	The Rapuncel infostealer: more than 25 browsers, more than 30 wallet apps, Credential Manager, Discord, Steam and Telegram sessions	Victim numbers, sectors or countries
Attribution	Loader built with the Cruciferra PUROSANGUE crypter (high confidence). Stealer related to BoryptGrab (moderate confidence)	Any named actor, group or country behind this operation

Two builds, two Microsoft signatures: "renamed" undersells it

The report calls Alinubx.sys "a renamed, identity-swapped version of CcProtect.sys". CcProtect.sys is the protection driver from CnCrypt, a Chinese disk encryption and host defence product made by Henan Dafeng Software Co., Ltd. The report says the operators changed the original file name, and that "that single change was enough to slip past detections keyed to the known name".

The two public LOLDrivers records (CcProtect.sys, Alinubx.sys) show something more interesting than a rename. You cannot rename a file's internal identity and keep the old signature: change the version resource and the Authenticode signature no longer matches. What the records show instead is two separate builds, each with its own Microsoft signature.

The two driver builds compared, from the LOLDrivers records for CcProtect.sys and Alinubx.sys (accessed 22 Sep 2026)

Attribute	CcProtect.sys	Alinubx.sys
OriginalFilename	CcProtect.sys	Alinubx.sys
Description	CnCrypt Protect Driver	Alinubx Driver
Product and version	CnCrypt 1.32	CnCrypt 1.32
PE timestamp	4 March 2022	24 March 2023
Microsoft leaf certificate valid	9 Sep 2021 to 1 Sep 2022	7 Jun 2022 to 1 Jun 2023
Code section size	0x318b3 bytes	0x3837d bytes
SHA256 (flat file)	5f0cfe83...cfb1c	611b3ba6...b5b61
Authenticode SHA256	61b268c3...f9a7	c202e7bb...e887

The compile timestamps are 385 days apart. The code sections differ by 27,338 bytes. Each file carries a Microsoft Windows Hardware Compatibility Publisher leaf certificate that was valid when that build was made. My inference, which no source states, is that Alinubx.sys was compiled under its new name and put through Microsoft's signing pipeline in March 2023 as a build in its own right. PE timestamps can be forged, but the signing certificates' validity windows point the same way.

Who submitted it is not stated anywhere. Microsoft's hardware signing needs a registered partner account, so the possibilities range from a legitimate customised build that was later stolen to deliberate abuse of a developer account. The sources do not choose between them, and neither will I. What matters for defenders is simpler: the file the malware drops is not a copy of a known-bad file with a new name. It is a different file, with its own hashes and its own valid signature.

Bring your own vulnerable driver, in the terms a defender needs

Bring your own vulnerable driver (BYOVD) works like this. The attacker does not need a Windows kernel vulnerability. They bring a legitimate driver that Windows will load because it is properly signed, and that driver does something dangerous on request. Once it is loaded, the attacker's ordinary program sends it instructions and the driver carries them out with kernel authority.

Alinubx.sys offers exactly that. According to the report and the LOLDrivers record, it creates a device called \\.\Alinubx. A program sends that device a process ID, and the driver looks up the process, opens it with kernel-mode access and terminates it. Security products guard their own processes against user-mode attempts to kill them. A request made from kernel mode sidesteps those handle checks. That is how the loader works through its list of 145 names.

Three facts limit the damage and are worth stating clearly:

1. Loading a driver needs administrator rights. The report says the malware "attempts three different methods to obtain administrator-level access" but does not name them. The Cruciferra toolkit it matched includes a COM Elevation Moniker bypass of User Account Control (UAC). Bypasses of that kind raise a user who is already a local administrator without showing a prompt. They do not turn a standard user into an administrator. The report does not say whether the other two methods need an existing admin account.
2. In this deployment the driver's other features were switched off. The report lists capabilities that were unconfigured: hiding files and registry keys, intercepting processes and DLLs, redirecting network traffic, and injecting DLLs. Its assessment is that Alinubx "acted as an AV killer and its broader functionality remained unconfigured".
3. The same driver family was already public. LOLDrivers added CcProtect.sys on 16 June 2026 as a BYOVD process killer, with a public proof of concept. That is 72 days before it added Alinubx.sys on 27 August. I am not linking the proof of concept.

Which security products are on the list

The LastPass report gives the count and no names. It says the loader allocates 0x91 entries, which is 145, and fills them with decrypted AV and EDR process names. For names you have to go one step out, to eSentire's analysis of the Cruciferra crypter, published by its Threat Response Unit on 19 August 2026. That analysis says Cruciferra's builder comes with "a total of 145 process names" configured by default for termination. eSentire's hash table lists Alinubx.sys as one of the vulnerable drivers.

Delphos assesses "with high confidence" that the loader in this campaign was produced by Cruciferra's PUROSANGUE package or a close derivative. It lists the 145 default AV and EDR targets as one of the overlaps. So it is a reasonable inference, though not a stated fact, that Rapuncel's list is Cruciferra's default list. eSentire's table of the product families on that list includes:

Security products named on Cruciferra's default termination list, from eSentire TRU (19 Aug 2026). The LastPass report publishes only the count of 145

Product family	Example process names on the list
Microsoft Defender Antivirus	MsMpEng.exe, SecurityHealthService.exe, smartscreen.exe
Microsoft Defender for Endpoint	MsSense.exe, MsSenseS.exe
CrowdStrike Falcon	CSFalconService.exe
SentinelOne	SentinelAgent.exe, SentinelCtl.exe
Sophos, including HitmanPro.Alert	SavService.exe, SophosAgent.exe, hmpalert.exe
Palo Alto Cortex XDR, Fortinet FortiEDR, Elastic	CyveraService.exe, FortiEDRCollectorService.exe, elastic-endpoint.exe
ESET, Kaspersky, Bitdefender, McAfee, Symantec, Trend Micro	ekrn.exe, avp.exe, vsserv.exe, McShield.exe, ccSvcHst.exe, NTRtScan.exe
Also listed	Avast, AVG, Avira, Carbon Black, Cybereason, Cylance, Malwarebytes, Qihoo 360, Huorong, K7 and others

Two cautions go with that table. First, a list of process names shows what the loader tries to kill, not what it succeeds in killing. Vendors with kernel-side tamper protection may react differently, and no source tested each product. Second, being on the list is not a verdict on any vendor. It is a list of what is commonly installed. The practical point is that your EDR is a target at this stage, not a control. Anything you want to stop the driver has to act before the driver loads, or not depend on the agent that is about to be killed.

A Microsoft signature is a label, not a control

"Microsoft-signed" is the phrase in every headline, and it is a textbook friendly-name fallacy. The words sound like an assurance, but they describe a process. The Windows Hardware Compatibility Publisher signature tells Windows that the driver went through Microsoft's partner signing pipeline, so the kernel should accept it. It says nothing about whether the driver will kill processes for whoever asks. The Delphos wording is exact: "Microsoft attestation proves a driver passed through a trust pipeline. It does not prove the driver is safe."

Microsoft's own handling of the report makes the same point from the other side. According to the report, the Microsoft Security Response Center (MSRC) replied that the behaviour "does not meet its definition of a security vulnerability, since the driver is not a Microsoft-owned component". It redirected the report to the Windows Defender Security Intelligence driver submission portal. Delphos resubmitted there the same day, 19 August, and the case was closed. So the company whose signature made the driver loadable does not treat that driver as a security vulnerability in its own products. Blocking it goes into a separate queue, with no published deadline.

This is not a charge of bad faith. Microsoft's blocklist page is candid about the trade-off. It says the list "isn't guaranteed to block every driver found to have vulnerabilities", and that Microsoft sometimes has to "hold back some blocks to avoid breaking existing functionality". It also recommends "an explicit allowlist approach to security wherever possible". That is Microsoft telling you the blocklist is the backstop, not the control.

The campaign uses a second friendly name too. The driver is installed as a service whose display name poses as an NVIDIA File System Filter Driver, under the file name nvfsflt64.sys. A service list that reads as a graphics component tells you nothing about who wrote the file behind it.

Would the blocklist, memory integrity or the ASR rule have stopped it?

These are the four controls the question is usually about, each tested against what the sources establish for this driver.

Controls tested against Alinubx.sys, from Microsoft Learn (blocklist page dated 1 May 2026, ASR reference dated 9 Sep 2026, memory integrity page dated 14 Aug 2026) and the LastPass and Delphos report

Control	What it does	Would it have stopped Alinubx?
Microsoft vulnerable driver blocklist	On by default since the Windows 11 2022 update. Blocks listed drivers from loading. Updated quarterly and through monthly updates	No, on the record. Not listed on 20 August or at publication on 17 September
Memory integrity (HVCI)	Runs kernel code integrity checks inside virtualisation-based security. Enforces the blocklist; incompatible drivers can fail	Not through the blocklist, for the same reason. Whether this driver is HVCI-compatible is not established (see below)
ASR rule: Block abuse of exploited vulnerable signed drivers	Stops apps saving vulnerable signed drivers to disk. Does not stop a driver already on disk from loading	Not stated. Its driver set is Microsoft's, and no source says Alinubx is in it
Your own App Control deny rule or allowlist	Denies by Authenticode hash, file name, publisher and version, or allows only what you have approved	Yes, once written: an Authenticode hash deny for both builds, or a driver allowlist that does not include CnCrypt

On memory integrity, there is one hint and it is not proof. The LOLDrivers record for the original CcProtect.sys quotes the public proof of concept's note that "HVCI must be disabled to avoid instability". That suggests the driver family may not work well under memory integrity. Microsoft's memory integrity page warns that incompatible drivers can malfunction or fail. But neither the report nor LOLDrivers tested Alinubx.sys on a machine with memory integrity turned on. I have not either. Treat memory integrity as worth having, and do not assume it stops this driver.

On the ASR rule, note two details from Microsoft's reference. Its dependencies are listed as "None". And it acts when the driver is written, which comes before the kill step, so the Defender processes the loader goes on to terminate are not needed for the rule to fire. Whether it fires depends on whether Microsoft's set of vulnerable drivers includes this build. No source says it does. Advanced hunting records its decisions as AsrVulnerableSignedDriverAudited and AsrVulnerableSignedDriverBlocked, so you can see what it catches.

The only control on this list that works for certain against a newly signed, not-yet-listed driver is one you write. That means a deny rule with the specific hashes, or an allowlist that never included the driver in the first place.

The "0 of 20" figure, and why a hash comparison is the wrong test

The report includes a striking statistic. Delphos checked 18 driver files from public BYOVD repositories, plus CcProtect.sys and Alinubx.sys, against Microsoft's DriverPolicy_Enforced.xml blocklist downloaded on 20 August 2026. It found "0 of 20 SHA256 matches because the blocklist is a list of known bad hashes". The Hacker News repeated the conclusion that renamed or recompiled drivers get past hash-based matching.

The figure establishes less than it appears to. Microsoft's App Control documentation says App Control uses the "Authenticode/PE image hash algorithm" when it calculates a file's hash. That is not the flat file SHA256 you get from Get-FileHash or from VirusTotal. The Authenticode hash leaves out the signature and checksum, so a correct match needs the Authenticode value. The same documentation lists rule levels by file name, publisher, version and signing certificate, as well as by hash. And the blocklist page says the list covers "certificates used to sign malware" as well as individual drivers.

So a comparison of flat SHA256 values would find no match even for a driver that is blocked, if the block is written as an Authenticode hash or as a file name, signer or version rule. The report does not say which hash type Delphos compared, or whether it checked the other rule types. My inference is that the "0 of 20" result, and the wider claim that the original CcProtect.sys was never blocklisted, need re-checking against Authenticode hashes and attribute rules before anyone relies on them. The separate statement that Alinubx.sys was not blocked at publication stands on the MSRC exchange and the closed case, not on the hash comparison alone.

This does not rescue the blocklist as a control. A deny rule keyed to the file name CcProtect.sys, if there were one, would miss a build whose OriginalFilename is Alinubx.sys. A deny rule keyed to one build's hash would miss the other. That is the point of an allowlist.

Attribution: a rented kit, not a named actor

Nobody names who ran this campaign, and the evidence explains why that is hard. Delphos places the pieces in two commercial ecosystems:

• Cruciferra, a crypter sold as a service. eSentire says it "first appeared in November 2025" and sells the PUROSANGUE package with EDR killing for $1,200 a month. Proofpoint's analysis of 20 July 2026 found eight different vulnerable drivers across Cruciferra samples, and names some as alternatives that "may be dropped and used" in place of another. Proofpoint links one Chinese-speaking cybercrime actor, TA4922, to the service and says multiple unrelated actors use it.
• BoryptGrab, a stealer family spread through search-optimised fake GitHub repositories. Trend Micro first described it on 5 March 2026 across more than 100 repositories, noting Russian-language comments and Russian IP addresses. Arctic Wolf described at least 292 brand impersonation repositories on 13 July 2026 and assessed the operator as "likely Russian-speaking". Delphos places Rapuncel in the BoryptGrab ecosystem with moderate confidence. The strongest shared marker is the lure name passathook-cs2, and the stealer files are "not byte-identical" to Trend Micro's.

A crypter sold by the month to anyone, with drivers that can be swapped, tells you about the supplier, not the customer. The accurate description is: an unattributed operator using commercially available tooling.

A note on interests, without cynicism. LastPass had a direct reason to investigate a campaign that traded on its name. Delphos Labs sells binary analysis. eSentire ends its post by recommending its own managed detection service. None of that weakens the technical findings, which are specific and checkable. It is a reason to separate what each vendor measured from what each vendor recommends.

Driver-stage indicators, and what each one is worth

Domain and network indicators for this campaign are in our 19 September briefing. The ones below are specific to the driver stage and come from the report and the LOLDrivers records. Hashes are given in full because they are not clickable. The report's own advice is to "hunt for lineage and behavior, not just the original name".

Driver-stage indicators from the LastPass and Delphos report and LOLDrivers, with an assessment of how durable each is

Indicator	Value	Worth
Service name	NvFsFilter, display name posing as an NVIDIA File System Filter Driver	Medium: cheap to change, but fast to check
Driver path	C:\Windows\System32\drivers\nvfsflt64.sys	Medium: same caveat
Device name	\\.\Alinubx	Medium: fixed in this build
Alinubx.sys SHA256	611b3ba687b7f46319a19609605ddfe5225e6d85277d8e923eea3fdb6f7b5b61	High for this build only
Alinubx.sys Authenticode SHA256	c202e7bb00135434321dad49f6c746b1ea071f6e7400a598438868f660f0e887	High: the value App Control hash rules use
CcProtect.sys v1.32 SHA256	5f0cfe8357bb52b45068ddbac053e32bc38e6cb5e086746f5402657b0a5cfb1c	High for the original build
CcProtect.sys Authenticode SHA256	61b268c31404e7b77868f5efdc2f134fffcf3059680e1ac26d93ead48529f9a7	High: for App Control
Loader vsdbg.dll SHA256	ea8c31a86fa785ab514022c278a2f6e571c86aac9283745a96605c44d88382d6	Low: crypter output changes per build
Lineage	Product string CnCrypt; Henan Dafeng identity in the Authenticode programName	Highest: survives renaming and rebuilding
Behaviour	A driver load followed by security processes ending	Highest, if your telemetry outlives the kill

For Microsoft Defender for Endpoint customers, this advanced hunting query covers the service, file and driver-load indicators. It is a starting point, not a complete detection. Adjust the time window to your retention.

let names = dynamic(["alinubx.sys", "nvfsflt64.sys", "ccprotect.sys"]);
let hashes = dynamic(["611b3ba687b7f46319a19609605ddfe5225e6d85277d8e923eea3fdb6f7b5b61", "5f0cfe8357bb52b45068ddbac053e32bc38e6cb5e086746f5402657b0a5cfb1c"]);
union
 (DeviceEvents
  | where Timestamp > ago(90d)
  | where ActionType in ("DriverLoad", "ServiceInstalled", "AsrVulnerableSignedDriverAudited", "AsrVulnerableSignedDriverBlocked")
  | where tolower(FileName) in (names) or SHA256 in (hashes) or AdditionalFields has "NvFsFilter"),
 (DeviceFileEvents
  | where Timestamp > ago(90d)
  | where tolower(FileName) in (names) or SHA256 in (hashes))
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256, InitiatingProcessFileName, AdditionalFields
| order by Timestamp desc

What to do, in the order worth doing it

The question that exposes the gap

Every control in this story that depends on someone else's list failed for at least 29 days. Microsoft's blocklist did not include the driver. VirusTotal showed 0 detections out of 72 on 20 August, and that result had not changed since July 2025. The EDR on the endpoint was on the kill list. The controls that would have worked are local: an allowlist, a deny rule, and standard user rights.

So the question to take to your next security review is not "is the blocklist on?" It is this: if a validly signed driver that nobody has listed yet arrived on one of our laptops tomorrow, which control that we own, and not one maintained by a vendor, would refuse to load it? If the honest answer is "none of ours", the signature on the next driver will be doing the attacker's work.

Key facts