Threat Intel | One Kit, Forty Companies: How a Malware-as-a-Service Platform Used GitHub as a Distribution Network for its Campaign

The hidden redirect chain

Behind the scenes, the page silently routes the victim through two additional observed GitHub Pages accounts (i.e., edgarcostartqd[.]github[.]io and dallikilic54[.]github[.]io) that act as hidden waypoints. These pages don't display anything visible to the user and exist to obscure the trail between the lure page and the actual malware server, making the infrastructure harder to trace and take down. Each one uses a custom 404.html file containing JavaScript that captures the URL path and silently forwards the victim to the next stage. This technique exploits standard GitHub Pages error-handling behavior to function as a covert redirector while appearing to be a broken or nonexistent page.

A separate Cloudflare-fronted server (istatlmenus[.]com) acts as the dynamic traffic director for the chain. Rather than hardcoding the payload server address into the lure pages directly, the chain fetches the destination from istatlmenus[.]com/mandua[.]wonted at runtime. This means the operator can redirect victims to a different payload server at any time simply by updating that single endpoint without touching any of the GitHub lure infrastructure. The endpoint was confirmed live and serving a JavaScript redirect on September 10, 2026, and its content had changed between August 27 and September 10, confirming active ongoing maintenance.

The terminal destinations

macperformancetools[.]com and zaffersnouty[.]com are the terminal destinations of the redirect chain. Both are currently parked, consistent with the operator standing down visible malicious activity following researcher detection while keeping the infrastructure registered and ready to reactivate. macperformancetools[.]com is 302-redirecting to awwwards.com and zaffersnouty[.]com is 302-redirecting to threads.com.

Both domains are confirmed Cloudflare-fronted. Sandbox analysis of both independently produced an identical behavioral finding: deletion of the Windows registry key HKEY_CURRENT_USER\Software\Google\Chrome\PreferenceMACs\Default\extensions.settings, which controls Chrome's extension integrity verification. The consistent pattern across two separate domains suggests this is a deliberate capability of the campaign, not a sandbox artifact. Its purpose and whether it was activated against real victims remains unclear.

The download

The victim is ultimately sent to the attacker's payload server (albinofennel[.]com or hanselarinmusky[.]com) with multiple user codes observed (unique tracking identifiers embedded in the download URL that indicate the infrastructure is managing multiple simultaneous lure campaigns or distribution channels) and a ZIP file downloads automatically.

During LastPass’ investigation, the TIME team identified albinofennel[.]com was serving at least 40 other branded impersonation lure pages, indicating LastPass was likely just one of the many targets using this same kit.

In the cases we observed, the zip file names and sizes differed slightly but contained identical malware components (i.e., LastPass-Authenticator-download-1.66.2.zip (148MB) and lastpass-authenticator-2.78.7.zip (127.9MB)). The large file size is intentional: most automated security scanning tools have size limits and will skip files this large, allowing the malware to arrive undetected.

The archive contains what appears to be a LastPass installer alongside a collection of supporting files with plausible-sounding names. Two large files (TitanStorage.dll and ProManager.dll) are pure junk and are included only to inflate the archive size further. The actual malicious files are small and hidden among the legitimate-looking ones.

*The size-padding angle is familiar: Delphos previously documented a 55MB libpsl-5.dll stealer where most of the file was junk padding used to slip past scanners.

What Happens After the File Is Opened?

Step 1: The fake installer runs

The victim runs what looks like a LastPass installer; however, it is actually Microsoft's own debugging tool (vsdbg.exe) renamed. When Windows loads this program, it automatically loads a companion file (vsdbg.dll) from the same folder. This is a standard Windows behavior the attacker deliberately exploits. The companion file is the attacker's code, not Microsoft's.

Step 2: The malware takes full control

The malware attempts three different methods to obtain administrator-level access, exploiting built-in Windows features that allow programs to request elevated permissions. Once it succeeds, it runs as SYSTEM, which is the highest privilege level available on a Windows machine, above even a standard administrator account.

Step 3: All security software is killed

The malware installs a kernel driver, which is software that runs at the deepest level of the operating system, below where antivirus and security tools operate. This driver is disguised as an NVIDIA graphics component (nvfsflt64.sys, registered under the name "NVIDIA File System Filter Driver"). It carries a list of 145 named antivirus and endpoint security products. It terminates every one of them that is running. Because the kill command comes from kernel level (below where security software operates) no antivirus can block or detect it. The driver was signed by Microsoft's own hardware compatibility program, giving it a level of trust that Windows does not question.

Step 4: Stealth features load (partially)

The driver contains code to hide its own files from Windows and inject a helper component (ProtectR3.dll) into every running program on the machine. In this specific deployment, the attacker did not provide the configuration file that the driver needs to activate these features, so they did not run. The driver was used solely to kill security software.

Step 5: Browser passwords are stolen

With security software gone, the stealer reads saved passwords from more than 25 web browsers. For Chrome, Edge, and other modern browsers that use Google’s 2024 “app-bound encryption” feature (a security improvement specifically designed to prevent this kind of theft) the malware uses a more sophisticated approach: it injects a small piece of code directly into the browser process. This code impersonates the browser itself and calls Chrome’s own password-decryption service from inside Chrome, bypassing the protection because the request appears to come from a legitimate source.

Step 6: Everything of value is collected

Beyond passwords, the malware collects the following:

• cryptocurrency wallet files from more than 30 wallet applications, 
• Discord login tokens, 
• Steam session tokens (the malware will launch Steam silently if it is not already running, then scan its memory for credentials), 
• Telegram session data, 
• Windows credential store (which holds saved network passwords, Windows Hello data, and other credentials), 
• any document whose name contains words like "password," "seed," "wallet," or "recovery",
• a screenshot of every monitor connected to the machine, and 
• a detailed profile of the system. 

Step 7: Everything is sent to the attacker

All collected data is compressed into a ZIP archive and uploaded to an attacker-controlled server at 2.26.126.50 over a raw internet connection formatted to look like ordinary web traffic. If the upload fails, the malware retries three times with two-second pauses between attempts. The Rapunzel Stealer uses a dedicated C2 at 2.26.126.50 for credential exfiltration. The delivery loader and Alinubx kernel driver do not communicate with external infrastructure in this deployment.

Step 8: Web traffic hijacking (present but not active)

The kernel driver also contains code to intercept all web traffic passing through the machine and redirect it through a local proxy, which would allow the attacker to inject advertisements, modify search results, or replace software downloads with malicious ones. This feature requires a configuration file that the attacker did not provide in this deployment, so it did not activate. Its presence in the driver suggests the operation has broader capabilities that could be enabled in future deployments.

Step 9: The machine stays compromised indefinitely

The malware installs itself as a Windows service that starts automatically every time the computer boots. It then loops continuously: checking for security products, killing any that have restarted, and re-running the stealer. The machine may remain fully under the attacker's control until the kernel driver is physically removed. This process requires booting the computer into Safe Mode or using an external recovery tool, because normal Windows tools cannot safely remove software operating at that level while the system is running.

• Malware Family: The stealer payloads are not byte-identical and do not share hashes with any of Trend Micro's published IOCs. Rapuncel's build name differs from documented BoryptGrab builds (CryptoByte, Shrek, Sonic, Yaropolk). The behavioral and artifact-level overlap points to the same ecosystem, not the same binary.
  
• Browser Helper DLL Implementation: Trend Micro's documented BoryptGrab samples embed a ChaCha20-encrypted PAYLOAD_DLL resource that decrypts to a 1.35 MB DLL exporting ReflectiveLoader. Rapuncel embeds a smaller 136 KB helper exporting Bootstrap. Same purpose, different packaging.
  
• C2 infrastructure: Rapuncel's confirmed C2 is 2.26.126[.]50. Trend Micro's documented samples use different infrastructure. No shared C2 has been identified. 
  Kernel Driver: This campaign deploys Alinubx.sys, a Microsoft-attested kernel driver with 0/72 VT detections terminating 145 AV/EDR processes. No kernel driver component is documented in Trend Micro's BoryptGrab reporting.
  
• Secondary Payloads: BoryptGrab delivers a reverse SSH backdoor (TunnesshClient) and a Golang downloader (HeaconLoad), providing persistent remote access. This campaign delivers Alinubx.sys as the secondary payload, focused on defeating endpoint security rather than persistent access.
  Payload Server Architecture: albinofennel.com uses a window.__PM__ JavaScript kit generating dynamic lure pages from URL path parameters, supporting 40+ simultaneous brand impersonations. BoryptGrab's documented infrastructure does not include this level of automation.

Assessment

The shared file names and similar behaviors used in both campaigns are the strongest observed connections between these two campaigns. The shared collection artifacts, the misspelled Filegraber directory, and the highly specific Chrome Elevation Service bypass workflow are not generic stealer boilerplate. They indicate a shared codebase, shared tooling, or a deliberate fork from within the BoryptGrab ecosystem.

The payload differences (distinct hashes, different build names, smaller and differently packaged browser helper DLL, separate C2 infrastructure) are consistent with how modern malware families evolve across builds. Builder automation, forks, and rewrite workflows can preserve the same theft model while changing packaging, helper modules, strings, and infrastructure.

Rapuncel is a BoryptGrab-related variant or sibling build. It is not a confirmed match to any of Trend Micro's published samples, but the behavioral and artifact-level overlap is sufficient to place it within the BoryptGrab ecosystem with moderate confidence. Delphos found no definitive evidence that Rapuncel was AI-generated, though an AI-assisted rewrite from the same specification cannot be ruled out; a human rewrite is equally plausible.

Why was the signed driver the important payload?

The stealer did the visible malicious work while the driver enabled it by disabling defenses where the user-mode components at the kernel level of the security software, where components are reduced to racing or observing the attacker's driver rather than remediating it.

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 driver calls ObOpenObjectByPointer with AccessMode=KernelMode, which bypasses the normal user-mode SeAccessCheck path at handle-open time. It asks the kernel to open the process as kernel code, then kills it. 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.

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

This is an abuse-by-design driver rather 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?

The version resources and VirusTotal pivots tie Alinubx.sys 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 available in BlackSnufkin’s CcProtect-Killer, a widely mirrored GitHub repository.

That proof of concept opens \\.\CcProtect, sends IOCTL 0x222024, and passes a PID 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 and 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.

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

How does a Microsoft-signed driver end up killing 145 security processes?

The observed ZIP delivered two payloads through DLL side-loading. The first, a credential stealer the LastPass TIME team tracks as Rapuncel, targets 19 or more browsers, 34 or more cryptocurrency wallets, Discord, Steam, Telegram, and Windows Credential Manager, and decrypts Chrome and Edge app-bound encryption keys with a dedicated injection DLL. The second payload is the one that matters for defenders.

Alinubx.sys is a kernel driver. It exposes an IOCTL interface, accepts a list of process IDs, and terminates each one from kernel mode using ZwTerminateProcess after opening the process with KernelMode access. That KernelMode flag bypasses the user-mode access check that normally protects security software, defeating Protected Process Light without touching EPROCESS protection bits. It carries 145 hardcoded AV and EDR process names, dropped to disk as nvfsflt64.sys under the service name NvFsFilter, disguised as an NVIDIA File System Filter Driver.

The driver is signed through the Microsoft Windows Hardware Compatibility Publisher chain, with a signing timestamp of March 2023, years before this campaign. It scored 0 out of 72 on VirusTotal as of August 20, 2026, unchanged since July 2025. It was not present in the Microsoft vulnerable driver blocklist at publication.

The driver is a renamed, identity-swapped version of CcProtect.sys, a driver already listed on LOLDrivers with public proof-of-concept killer code. Same product string, same version, same submitter, same process-kill primitive. The operators changed the original filename from CcProtect.sys to Alinubx.sys, and that single change was enough to slip past detections keyed to the known name.

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

Why did signature-based detection miss all of this?

The signature was ineffective at halting this campaign because a signature merely asks whether a file matches something already discovered to be malicious. This driver was signed, timestamped, and clean on VirusTotal, and its dangerous twin was hiding behind a different filename. Every signal a signature-based control reads came back green.

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

Delphos checked 18 raw driver files from public BYOVD repositories, plus CcProtect.sys and Alinubx.sys, against the Microsoft DriverPolicy_Enforced.xml blocklist downloaded on August 20, 2026. There were 0 of 20 SHA256 matches because the blocklist is a list of known bad hashes. New malware can avoid matching by creating a new hash with techniques such as a filename swap or a recompilation.

Delphos Labs analyzed the compiled artifact directly through static analysis, custom decryption, NativeAOT data reconstruction, and emulator-assisted inspection. This allowed them to inspect the binary directly, rather than weaker techniques like antivirus signatures and YARA rules. Thus, the findings that identified this kit, the .reloc payload container, the 0x50 to 0x5F byte range, the build-environment string, and the 145-target count, came from reading the binary rather than relying on information of whether it had been previously detected.

A signature only works when malware has been previously identified. Delphos Labs’ technique of reading the binary does not have this handicap.

What was active and what was only present in code?

The driver carries 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, activates the network redirect, or performs ProtectR3.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 and its broader functionality remained unconfigured. A future deployment with Alinubx.ccf present could activate the rest.

Disclosure status

Delphos reported Alinubx.sys to Microsoft through the MSRC Researcher Portal on August 19, 2026. MSRC responded that the behavior does not meet its definition of a security vulnerability, since the driver is not a Microsoft-owned component, and directed the report to the Windows Defender Security Intelligence driver submission portal, which is the channel for blocklist consideration. That case was closed. Delphos resubmitted through the driver submission portal on August, 19, 2026. At publication, Alinubx.sys was not present in the Microsoft vulnerable driver blocklist.

What should someone who ran the installer do?

Treat every credential stored in the browser on that machine as exposed, along with cryptocurrency wallet files, Discord and Steam and Telegram session tdata, and anything held in Windows Credential Manager. The stealer collected and exfiltrated these before the driver work began.

Change those credentials from a separate, known-clean device rather than the affected one, and review vault activity for anything unexpected.

What does this mean for defenders?

Most robust techniques of binary inspection are needed to find novel malware. Hashes and payload server addresses can easily be rotated. For example, in this campaign, one payload server dropped off DNS during the analysis window while two others stayed live. As signatures and IP addresses are discovered, operators will redeploy to fresh infrastructure, recompile with a new signature, and swap the driver filename again, the same way CcProtect.sys became Alinubx.sys. Even durable indicators are behavioral: a file written to C:\Windows\System32\drivers\nvfsflt64.sys, a service created as NvFsFilter describing itself as an NVIDIA component while unsigned, vsdbg.exe spawning non-Microsoft child processes, and a PE file whose raw .reloc section is far larger than its declared relocation size with a high concentration of bytes in the 0x50 to 0x5F range. Any machine that executed this payload should consider kernel-level forensic investigation, because Alinubx.sys defeats the user-mode tooling that would normally perform the cleanup.

The larger lesson is about trusting fragile, lookup-based detection techniques. This campaign chained together four separate trust assumptions and broke each one: that a recognizable brand on GitHub means an official channel, that a Microsoft signature means a vetted driver, that a clean VirusTotal score means a safe file, and that a blocklist covers the drivers that matter.

Delphos analyzes compiled code to reveal intent, without source and without prior knowledge of the sample. That is the analytical posture this class of threat requires.

What should defenders hunt for?

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

• Microsoft-attested drivers whose Authenticode programName contains the Henan Dafeng identity 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 and shared-infrastructure context, not a standalone block rule without corroborating request framing.