Threat Intel: Alinubx.sys. A Renamed CnCrypt Driver Became a Zero-Detection AV Killer

A fake LastPass Authenticator installer carried a Microsoft-attested kernel driver. Because Authenticode covers the version resources, the Alinubx identity had to exist before Microsoft signed it. The known build of the same driver ships as CcProtect.sys.

VirusTotal's last analysis for Alinubx.sys showed 0 malicious detections and 72 undetected engines, on July 21, 2025 at 20:53:49 UTC. As of August 20, 2026 that remained unchanged.

We recovered the embedded payloads through static analysis, custom decryption, NativeAOT data reconstruction, and emulator-assisted inspection. No sandbox detonation, prior signature, or threat feed was required to identify the driver, the stealer, or the signing chain.

What did the fake LastPass sample actually contain?

The file was named LastPass-Authenticator-download-1.66.2.exe, but the executable was a renamed Microsoft vsdbg.exe. That host side-loaded a malicious vsdbg.dll from the same directory. The DLL was a .NET NativeAOT loader with encrypted operational strings and two encrypted PE payloads hidden inside the .reloc section.

The first payload was a credential stealer internally named Rapuncel. It stole browser credentials, cryptocurrency wallet files, Discord tokens, Steam sessions, Telegram data, local documents, screenshots, and Windows Credential Manager entries. It compressed the stolen data into a ZIP archive and uploaded it to 2.26.126[.]50 using a raw TCP connection that framed the data as POST /upload HTTP/1.1.

The second payload was Alinubx.sys, a kernel driver dropped as C:\Windows\System32\drivers\nvfsflt64.sys and registered under NvFsFilter, with the description NVIDIA File System Filter Driver. The loader used it to terminate 145 antivirus and EDR processes from kernel mode.

The LastPass name prompted the user to click it, but the signed driver passed the trust controls.

Two large files in the archive were ballast. TitanStorage.dll was a damaged EA/Respawn crash-reporting binary, and ProManager.dll was high-entropy junk. Neither was loaded by the malware. They inflated the archive and created analysis noise. The size-padding angle is familiar: we previously documented a 55MB libpsl-5.dll stealer where most of the file was junk padding used to slip past scanners.

Component	Role	SHA256
`vsdbg.dll`	NativeAOT loader	`ea8c31a86fa785ab514022c278a2f6e571c86aac9283745a96605c44d88382d6`
Rapuncel stealer	Credential theft and exfiltration	`aefbc6e04320e9a0e80f2323f8a897c4fdb222a37b0b87d76e850109decbfadd`
`Alinubx.sys`	Kernel AV killer	`611b3ba687b7f46319a19609605ddfe5225e6d85277d8e923eea3fdb6f7b5b61`
Browser injection DLL	Chrome and Edge app-bound key decryption	`75018b06c7105a1dca391805d17b402aed35ebd515b92d461236eafbd606cb40`
`ProtectR3.dll` x64, unpacked	Usermode rootkit helper present inside driver	`26db14b956e33f69b3397a36387d32e01eb63613acff91069dc76b6ed7de45a8`

Is this connected to Cruciferra?

Proofpoint recently documented Cruciferra, a crypter service that uses DLL side-loading, .reloc payload storage, a custom Base16 alphabet (PQRSTUVWXYZ[\]^_), BYOVD-based EDR tampering, UAC bypass, persistence, and a large set of custom cryptographic routines. Proofpoint says Cruciferra often abuses GoFlyDrv.sys and lists additional helper drivers including Core64.sys, HwOs2Ec.sys, LnvMSRIO.sys, MemoryInformer.sys, NTIOLib_X64.sys, ProcessMonitorDriver.sys, and selfprot.sys.

The strongest overlap is the payload container: this sample also stores payloads in .reloc and uses the same custom Base16 style, with bytes in the 0x50 to 0x5F range corresponding to PQRSTUVWXYZ[\]^_. That is the discriminating evidence. The other overlaps are contextual: DLL side-loading, UAC bypass, persistence, generated internal record names, and BYOVD-style EDR tampering all fit the Cruciferra pattern, but none is decisive alone.

The main implementation change is the runtime. This sample uses .NET NativeAOT instead of Mono. That is a practical hardening step for a .NET crypter, not evidence against lineage. It preserves much of the developer workflow while removing the easy IL-decompilation path that defenders expect from Mono and .NET samples. It uses a different driver, a renamed Microsoft-attested CnCrypt/CcProtect, that Proofpoint did not list among the observed helper drivers.

A separate eSentire analysis strengthens the match further. eSentire describes a Cruciferra package called PUROSANGUE that produces a NativeAOT side-loaded DLL with EDR/AV killing, COM Elevation Moniker UAC bypass, process hollowing into ServiceModelReg.exe, and 145 default AV/EDR process targets. Our loader contains the decrypted string C:\ExploitTests\purosangue.tx and matches every one of those features. Recorded Future lists the same PUROSANGUE tier in a broader Cruciferra pricing summary. The only operational difference is the driver: where eSentire observed DCRCVDrv.sys, this sample uses a renamed Microsoft-attested CnCrypt/CcProtect driver.

We assess with high confidence that this sample was produced by the Cruciferra PUROSANGUE package or a close derivative.

Why was the signed driver the important payload?

The stealer did the visible criminal work. The driver made that work possible by disabling defenses at a level where the user-mode components of security software have no direct recourse. At the level kernel components are reduced to racing or observing the attacker's driver.

Alinubx.sys exposes an IOCTL interface through \\.\Alinubx. The loader sends IOCTL 0x222024 with target process IDs. The driver resolves each target process with PsLookupProcessByProcessId, opens it with ObOpenObjectByPointer, and terminates it with ZwTerminateProcess. The loader's target set is fixed in code: sub_1800eae00 allocates 0x91 entries, which is 145, and fills them with decrypted EDR/AV process-name strings.

The access mode is the critical detail. The driver calls ObOpenObjectByPointer with AccessMode=KernelMode, which bypasses the normal user-mode SeAccessCheck path at handle-open time. That is why it can defeat Protected Process Light (PPL), the protection many security products rely on to survive an administrator. It does not need to patch EPROCESS protection bits. It asks the kernel to open the process as kernel code, then kills it.

A user-mode stealer steals credentials. A trusted kernel driver clears the runway.

This reads as an abuse-by-design driver than a memory-corruption exploit. The process-kill interface appears to be product functionality exposed by a host-defense driver. The control is policy enforcement: block the driver, deny the signer or lineage, or prevent the drop. If the driver is trusted and not blocklisted, administrator rights are enough to install and use it.

What made Alinubx different from CcProtect?

Alinubx.sys is not an unrelated driver. The version resources and VirusTotal pivots tie it to the CnCrypt/CcProtect driver line from Henan Dafeng Software Co., Ltd. (河南大风软件有限公司). CnCrypt is a public Chinese disk encryption and host-defense product. Its protection driver, CcProtect.sys, is catalogued by LOLDrivers as a BYOVD process-killer provider, with public proof-of-concept code in BlackSnufkin’s CcProtect-Killer repository.

BlackSnufkin's PoC uses \\.\CcProtect, IOCTL 0x222024, and a PID input to kill an arbitrary process. A Chinese incident-response writeup also describes CnCrypt Protect being used after IIS compromise to create rules, install the CcProtect driver, redirect an IIS-loaded DLL to a malicious replacement, and hide a malicious service. Those are different uses of the same protection framework: process killing in one case, file/service hiding and redirection rules in another.

Our sample kept the CnCrypt product identity and version but changed the driver identity that most defenders would see first.

Field	Known `CcProtect.sys` v1.32	`Alinubx.sys` from this sample
Product	`CnCrypt`	`CnCrypt`
Version	`1.32`	`1.32`
Description	`CnCrypt Protect Driver`	`Alinubx Driver`
Original filename	`CcProtect.sys`	`Alinubx.sys`
Submitter programName	`河南大风软件有限公司`	`河南大风软件有限公司`
VirusTotal detections (checked 2026-08-20)	7 malicious / 70 undetected / 1 failure (last analysis 2026-08-13T04:54:45Z)	0 malicious / 72 undetected (last analysis 2025-07-21T20:53:49Z)
Microsoft blocklist status	Not found in Microsoft's DriverPolicy_Enforced.xml downloaded from https://aka.ms/VulnerableDriverBlockList on 2026-08-20 (XML SHA256: b772c4aacffac4130c36fc71c13f3b18b442a827887815417d211579e02f32e3)	Not found in Microsoft's DriverPolicy_Enforced.xml downloaded from https://aka.ms/VulnerableDriverBlockList on 2026-08-20 (XML SHA256: b772c4aacffac4130c36fc71c13f3b18b442a827887815417d211579e02f32e3)

The functionality stayed recognizable. The identity changed enough for detection to miss it.

Why did public BYOVD coverage not stop it?

This driver family was not hiding in a private corner of the internet. CcProtect.sys was already public enough to have a LOLDrivers entry, a documented process-killer use case, and a BlackSnufkin proof of concept that opens \\.\CcProtect, sends IOCTL 0x222024, and passes a PID to kill.

The broader problem is visible in UsingBYOVD, a public repository that packages reusable exploitation code for signed drivers. It includes a CLI and code paths for kernel-level process termination, PPL manipulation, SYSTEM token theft, LSASS dumping, and unsigned driver mapping. It also documents driver-specific IOCTLs for several kill-capable drivers, including BootRepair.sys, ProcessCtr.sys, GGProtect64.sys, and HWAuidoOs2Ec.sys.

The gap is between public knowledge and effective blocking. The LOLDrivers entry helps defenders who know to look for CcProtect.sys or its known hash. It does not automatically stop a renamed build. The Microsoft vulnerable driver blocklist we downloaded on 2026-08-20T00:32:59Z did not contain CcProtect.sys, Alinubx.sys, CnCrypt, 河南大风软件有限公司, or either driver SHA256. The downloaded DriverPolicy_Enforced.xml had SHA256 b772c4aacffac4130c36fc71c13f3b18b442a827887815417d211579e02f32e3.

During the same investigation, we checked 18 raw .sys drivers from UsingBYOVD, plus CcProtect.sys and Alinubx.sys, against that Microsoft enforced driver blocklist. Exact SHA256 hits: 0 of 20. Public tooling had already reduced signed-driver abuse to repeatable operations. The platform blocklist had not caught up.

Public BYOVD research is not the same as platform enforcement. Attackers can move through the gap between the two.

If a researcher can find working driver abuse primitives in minutes, and a malware operator can package one into a crypter, then a platform blocklist cannot lag too far behind public exploit repos and still be treated as a dependable control. A single loadable driver is enough.

Alinubx.sys was not just another copy of a known driver. Because Authenticode covers the version resources, the Alinubx identity had to exist before Microsoft signed it. Someone produced a CnCrypt v1.32 build with new metadata and got it Microsoft-attested in 2023. The signing timestamp is 2023-03-24 12:18 UTC, countersigned by Microsoft Time-Stamp Service. The programName proves which submission identity appears in the Authenticode metadata; it does not prove Henan Dafeng knowingly authorized malicious use. Compromised, resold, and rented signing or Partner Center access are documented patterns in this abuse class.

What does Microsoft's signature prove?

The driver is signed by Microsoft Windows Hardware Compatibility Publisher, issued by Microsoft Windows Third Party Component CA 2014. The signing chain means Windows trusts the driver as kernel code. It does not mean the driver passed a deep functional security review.

Microsoft's attestation signing process allows a vendor with the required Partner Center and certificate setup to submit driver packages for Microsoft signing. Microsoft's own documentation says attestation signing does not require the full Hardware Lab Kit path used for Windows certification. Mandiant documented this abuse pattern in 2022 and showed why the shared Microsoft leaf certificate is not a useful pivot by itself. The more useful field is Authenticode SpcSpOpusInfo, especially the programName value that identifies the submitter.

For Alinubx.sys, that value is 河南大风软件有限公司 (Henan Dafeng Software Co., Ltd.). VirusTotal pivots on signature:"大风" and signature:"CnCrypt" returned CnCrypt executables, CcProtect drivers, CcProtect DLLs, and the renamed Alinubx.sys sample.

The Microsoft signature proves the driver passed through a trust pipeline. It does not prove the driver is safe.

The exact leaf certificate serial and thumbprint are useful for validating this sample, but they are not safe hunting keys. Microsoft uses the same hardware compatibility publisher certificate across many legitimate drivers. Hunting on the certificate alone catches unrelated software. Hunting on the submitter programName, CnCrypt metadata, driver behavior, and lineage is more useful.

What was active and what was only present in code?

The driver carries far more than this deployment used: file and registry hiding, process and driver interception, DLL interception, network control, port redirection, WFP traffic handling, APC-based usermode DLL injection, and a rule configuration system based on \SystemRoot\Alinubx.ccf.

We found no evidence that the loader writes Alinubx.ccf, sends configuration IOCTL 0x222010, or activates the network redirect, orProtectR3.dll injection. The driver can also send a JSON rule and version heartbeat over an HTTP POST to a configured URL, but no URL is configured in this sample.

In this deployment, Alinubx acted as an AV killer. Its broader functionality remained unconfigured. in the sample we analyzed. A future deployment with Alinubx.ccfpresent could activate the rest.

Disclosure status

We reported Alinubx.sys to Microsoft through the Microsoft Researcher Portal on August 19, 2026. At the time of publication, we had not received confirmation of a blocklist update.

What should defenders hunt for?

Hunt for lineage and behavior, not just the original name.

Microsoft-attested drivers whose Authenticode programName contains 河南大风软件有限公司 or whose version resources contain CnCrypt.

Drivers with OriginalFilename or strings matching CcProtect.sys, Alinubx.sys, Alinubx, ProtectR3.dll, or \\.\Alinubx.

Service creation for NvFsFilter or file writes to C:\Windows\System32\drivers\nvfsflt64.sys.

Driver load followed by termination of security processes through kernel activity.

Presence of \SystemRoot\Alinubx.ccf, which would indicate the broader rootkit configuration path rather than kill-only use.

PE files where the raw .reloc section is much larger than the size declared in IMAGE_DIRECTORY_ENTRY_BASERELOC. In this loader, the excess region is mostly bytes in the 0x50 to 0x5F range, which encoded encrypted payload data before recovery.

The Rapuncel stealer exfiltration pattern: ZIP upload to 2.26.126[.]50 using POST /upload HTTP/1.1 over raw TCP. Treat this IP as historical/shared-infrastructure context, not a standalone block rule without corroborating request framing.

Indicators of compromise

Indicator	Context
`611b3ba687b7f46319a19609605ddfe5225e6d85277d8e923eea3fdb6f7b5b61`	`Alinubx.sys`, renamed CnCrypt/CcProtect driver
`5f0cfe8357bb52b45068ddbac053e32bc38e6cb5e086746f5402657b0a5cfb1c`	Known `CcProtect.sys` v1.32 sample from LOLDrivers
`aefbc6e04320e9a0e80f2323f8a897c4fdb222a37b0b87d76e850109decbfadd`	Rapuncel stealer
`ea8c31a86fa785ab514022c278a2f6e571c86aac9283745a96605c44d88382d6`	NativeAOT loader `vsdbg.dll`
`2.26.126[.]50`	Stealer exfiltration IP observed in payload. Shared/reseller infrastructure; use with `POST /upload` framing, not alone.
`\\.\Alinubx`	Driver device name
`NvFsFilter`	Driver service name
`C:\Windows\System32\drivers\nvfsflt64.sys`	Dropped driver path
`\SystemRoot\Alinubx.ccf`	Driver config path, not present in this deployment
`河南大风软件有限公司`	Authenticode OpusInfo programName

MITRE ATT&CK

Observed in this deployment: T1574.002 Hijack Execution Flow: DLL Side-Loading; T1055.012 Process Injection: Process Hollowing; T1562.001 Impair Defenses: Disable or Modify Tools; T1555.003 Credentials from Web Browsers; T1539 Steal Web Session Cookie; T1113 Screen Capture; T1005 Data from Local System; T1041 Exfiltration Over C2 Channel; T1548.002 Abuse Elevation Control Mechanism: Bypass User Account Control; T1543.003 Create or Modify System Process: Windows Service; T1036.005 Masquerading: Match Legitimate Name or Location; T1553.002 Subvert Trust Controls: Code Signing.

Present in code but not confirmed active in this deployment: T1014 Rootkit; T1055.004 Process Injection: APC-style injection; T1557 Adversary-in-the-Middle.

What does this tell us about signed-driver trust?

Windows does not accept unsigned kernel code, but this trust was earned by a submission workflow and is ultimately enforced by blocklists and static detections. Attackers and toolmakers adapt faster than this type of process can respond.

CcProtect.sys already had public BYOVD coverage. A renamed CnCrypt v1.32 build, signed later as Alinubx.sys, had zero VirusTotal detections and was absent from the Microsoft blocklist we downloaded. That is enough to turn an already known driver family into a fresh AV killer.

Trust decisions based on signer and filename are brittle. The durable signal is what the driver can do.

A signed driver can look legitimate in metadata and still expose a kernel process-kill primitive. Defenders need lineage, behavior, and capability analysis across the compiled artifact itself.Delphos Labs works on this problem: understanding what software actually does when source code, signatures, names, and trust labels are not enough.

This sample was analyzed with static analysis, custom decryption, NativeAOT data reconstruction, and emulator-assisted inspection. No antivirus signatures or YARA rules were used to detect the the driver, the stealer, or the signing chain.

Request access to analyze your own files here.