A fake LastPass Authenticator page on GitHub. A kernel driver signed by Microsoft’s own hardware programme. A stealer that kills 145 security processes, survives a reboot and keeps killing anything that restarts. LastPass’s threat team and Delphos Labs published the full technical write-up on 17 September 2026, five weeks after finding the lure on 13 August [1].
The interesting part is not that any single component is novel. It is that the campaign chained four assumptions that most organisations still depend on, and broke every one of them. This post walks the whole chain stage by stage, explains why each step works at the level of the operating system, and then sets out the defence strategy that follows from that detail.
The campaign in one table
| Field | Detail |
|---|---|
| First observed | 13 August 2026 by the LastPass Threat Intelligence, Mitigation and Escalation team; joint analysis with Delphos Labs; report published 17 September 2026 with the investigation state as of 10 September [1] |
| Brands impersonated | At least 40 companies, all served from one malware-as-a-service backend. LastPass was one lure among many [1] |
| Lure | SEO-optimised fake GitHub organisation (github.com/LastPass-Authenticator) plus a GitHub Pages portal, and a second page advertising a macOS LastPass product [1] |
| Payload archives | 127.9 MB and 148 MB ZIP files, padded with junk DLLs so scanners with size limits skip them [1] |
| Execution | vsdbg.exe, Microsoft’s Visual Studio CoreCLR debugger, renamed to look like an installer, side-loading the attacker’s vsdbg.dll (.NET NativeAOT loader, SHA-256 ea8c31a8…82d6) [1][2] |
| Privilege escalation | Three UAC elevation methods, ending in SYSTEM [1][3] |
| Kernel payload | Alinubx.sys (SHA-256 611b3ba6…5b61), dropped as C:\Windows\System32\drivers\nvfsflt64.sys, registered as the service NvFsFilter, described as an NVIDIA File System Filter Driver [1] |
| Signature | Microsoft Windows Hardware Compatibility Publisher chain, signing timestamp March 2023, 0 of 72 VirusTotal detections on 20 August 2026, and absent from Microsoft’s vulnerable driver blocklist at publication [1] |
| Capability | Terminates processes matching 145 hardcoded antivirus and EDR names, from kernel mode, through IOCTL 0x222024 on the device \\.\Alinubx [1] |
| Stealer | Tracked as Rapuncel (SHA-256 aefbc6e0…fadd): 25 or more browsers, 30 or more cryptocurrency wallet applications, Discord, Steam, Telegram, Windows Credential Manager, keyword-matched documents, screenshots, system profile [1][2] |
| Exfiltration | Compressed upload to 2.26.126[.]50 over raw TCP carrying an HTTP-formatted POST /upload, with three retries two seconds apart [1] |
| Persistence | Auto-starting Windows service that loops: check for security products, kill any that restarted, re-run the stealer [1] |
| Lineage | Loader built with the Cruciferra PUROSANGUE crypter package (high confidence); stealer assessed as a BoryptGrab-related variant or sibling build (moderate confidence) [1][5][6] |
Stage 1: being found is the attack
The victim does not get phished by email. They search for the software they want, and the attackers have bought their way into the top of those results with SEO-optimised GitHub organisations and Pages sites. The fake GitHub page uses LastPass branding, product copy and a prominent GET button, and it ranked near the top for queries such as LastPass Authenticator download [1]. A second fake account advertised a macOS LastPass build, which the LastPass team assesses was the same actor running parallel impersonation accounts [1].
The download portal then manufactures trust signals that do not exist: badges reading Authorized Access, VirusTotal Approved and Secure Archive, plus a spinner claiming it is validating a session and generating a secure token [1]. None of it is real. It exists to keep the visitor calm while the page silently prepares the download.
The scale is the point. The payload server albinofennel[.]com was serving at least 40 other branded impersonation pages from a JavaScript kit that generates lure pages from URL path parameters, and download URLs carried multiple user codes, which indicates several lure campaigns running in parallel through the same infrastructure [1]. This is a malware-as-a-service distribution business, not a single-brand phishing page. LastPass states plainly that none of its systems, services or customer vaults were involved: GitHub is not a LastPass distribution channel, and the brand was borrowed because it is recognisable [1].
Figure 1. Ten stages from search result to kernel. Stages 5 to 8 are where most existing controls are aimed, and where they failed.
Stage 2: a delivery chain built to survive takedown
Behind the visible page is a routing chain designed to make the infrastructure tedious to trace and cheap to replace. From the lure, the victim is silently passed through two more GitHub Pages accounts that display nothing, each using a custom 404.html file containing JavaScript that captures the requested URL path and forwards the visitor to the next stage [1]. That is a clever abuse of normal GitHub Pages behaviour: a broken link on a free, trusted, high-reputation host becomes a covert redirector.
The chain does not hardcode where the payload lives. A separate Cloudflare-fronted endpoint (istatlmenus[.]com) answers a request for the destination at runtime, so the operator can point every lure in the campaign at a new payload server by changing one response [1]. The endpoint was still serving a JavaScript redirect on 10 September 2026, and its content had changed between 27 August and 10 September, which confirms active maintenance after the researchers started watching [1].
The terminal domains observed were parked and 302-redirecting to legitimate sites at the time of publication, consistent with a temporary stand-down rather than a shutdown: the infrastructure stays registered and ready [1]. One detail deserves attention from browser teams: sandbox execution of both terminal domains independently deleted the Chrome registry key that controls extension integrity verification (HKCU\Software\Google\Chrome\PreferenceMACs\Default\extensions.settings). The LastPass team notes the behaviour was identical across two separate domains, so it appears deliberate rather than a sandbox artefact, and its purpose was not determined [1].
Stage 3: archives engineered to be too big to scan
The download in the observed cases was named like a real release (LastPass-Authenticator-download-1.66.2.zip at 148 MB, lastpass-authenticator-2.78.7.zip at 127.9 MB) [1]. Inside, alongside the fake installer, were files with plausible names, two of which, TitanStorage.dll and ProManager.dll, are pure padding included only to inflate the archive [1].
Why this works comes down to an operational reality: most automated analysis pipelines and many email or web security products impose file size limits, and files above the limit are skipped rather than queued. A 148 MB archive of mostly junk therefore does not need to evade detection, it needs to be ignored by tooling that stops looking at that size. The same team documented a 55 MB libpsl-5.dll sample previously padded for the same reason, so this is an established technique rather than an improvisation [1].
Stage 4: a Microsoft debugger loads the attacker’s DLL
The fake installer is Microsoft’s own Visual Studio CoreCLR debugger, vsdbg.exe, renamed [1][2]. When Windows starts that executable, it loads vsdbg.dll from the executable’s own directory, which is where the attacker put their code. That is DLL side-loading, mapped as T1574.002 in the report’s MITRE ATT&CK table [1].
The reason it works is about what security controls actually see. Policy, allowlisting and reputation checks evaluate the signed Microsoft binary, which is legitimate and expected. The adjacent DLL is loaded by that trusted process under its own trust, and nothing in the chain requires the attacker to break a signature. This is the same class of abuse as any LOLBin hijack, and it is why application control that permits a signed binary without constraining where it loads libraries from does not stop it.
The loader itself is .NET NativeAOT, compiled to native code instead of the readable intermediate language defenders expect from .NET or Mono samples [1]. Delphos describes that as a deliberate hardening step that keeps the developer workflow while removing the easy decompilation path [1]. Two artefacts tie it to a known toolkit: the loader stores payloads in the .reloc section and encodes them with the same custom Base16 alphabet as the Cruciferra crypter, with bytes in the 0x50 to 0x5F range corresponding to PQRSTUVWXYZ[\]^_, and a decrypted string in the binary reads C:\ExploitTests\purosangue.tx [1][5].
Stage 5: from user to SYSTEM in three attempts
Installing a kernel driver on Windows requires administrator rights, so privilege escalation is a prerequisite rather than a bonus. The loader attempts three different elevation methods using built-in Windows features, and once one succeeds it runs as SYSTEM [1][3]. The PUROSANGUE package that eSentire documented, and which the LastPass analysis matches feature for feature, uses COM Elevation Moniker abuse for the UAC bypass and process hollowing into ServiceModelReg.exe as part of the chain [1]. The report maps this to T1548.002 for the UAC bypass and T1055.012 for the hollowing [1].
The broader lesson is that UAC is a consent prompt, not a security boundary between administrative and non-administrative code. As long as a logged-in user is a local administrator, or a local administrator’s credentials are cached on the machine, the supply of elevation techniques is effectively unlimited because Windows ships many legitimate mechanisms that auto-elevate. A campaign that ships a crypter service gets working bypasses included, and it only has to work once.
Stage 6: the driver, and why it is the payload that matters
Why kernel mode wins
Antivirus and EDR products run mainly in user mode with supporting components in the kernel. A driver runs below the user-mode boundary entirely, so from its position the security software protecting the machine is just another set of processes with identifiers [1][4]. That is also why the kill cannot simply be blocked by the security product being killed: by the time it is a termination request at that level, the code issuing it is more privileged than the code receiving it.
The driver exists in this campaign specifically because administrators are not the top of the stack any more. Security products rely on Protected Process Light to survive an administrator, so the attacker goes under it.
What it does, mechanically
The report documents the exact sequence. The driver exposes an IOCTL interface through the device \\.\Alinubx, and the loader sends IOCTL 0x222024 with target process identifiers [1]. The driver resolves each identifier with PsLookupProcessByProcessId, opens the process with ObOpenObjectByPointer using AccessMode=KernelMode, and terminates it with ZwTerminateProcess [1]. The loader’s target list is fixed in code: one function allocates 0x91 entries, which is 145, and fills them with decrypted antivirus and EDR process-name strings [1].
The detail that makes Protected Process Light irrelevant is the KernelMode access mode. It means the process is opened as kernel code, so the normal user-mode access check at handle creation is not the deciding factor, and the driver does not need to patch protection bits in the kernel’s process structure to succeed [1]. This is not a memory-corruption exploit that a patch can fix. It is product functionality being pointed in the wrong direction: the report describes it as an abuse-by-design driver whose process-kill interface appears to be a legitimate host-defence feature [1].
The disguise, and the sibling behind it
On disk the driver is nvfsflt64.sys, registered as the service NvFsFilter and described as an NVIDIA File System Filter Driver [1][3]. Underneath, it is a renamed, identity-swapped copy of CcProtect.sys from CnCrypt, a Chinese disk-encryption and host-defence product published by Henan Dafeng Software: the product string, version 1.32 and submitter metadata are unchanged while the original filename and description were altered [1]. Because the version resources and Authenticode metadata keep the CnCrypt and Henan Dafeng identity, those fields are the durable hunt pivots rather than the filename [1].
CcProtect is already catalogued as a known-abused driver. LOLDrivers lists CcProtect.sys as a signed kernel driver used in BYOVD research as a process-killer provider, and a public proof of concept (BlackSnufkin’s CcProtect-Killer) opens \\.\CcProtect, sends IOCTL 0x222024 and passes a process identifier to kill an arbitrary process [7][8]. In other words, the dangerous capability was public before this campaign existed, and the only work required was to change the filename that defenders’ detections were keyed to [1].
Why the signature made it worse, not safer
The driver was signed through the Microsoft Windows Hardware Compatibility Publisher chain with a March 2023 timestamp, scored 0 of 72 on VirusTotal as of 20 August 2026 with no change since July 2025, and was not present in Microsoft’s vulnerable driver blocklist at publication [1]. The LastPass report is careful about what that means: attestation proves a driver passed through a trust pipeline, not that it is safe [1].
Delphos also tested the blocklist’s coverage directly, checking 18 raw driver files from public BYOVD repositories plus CcProtect.sys and Alinubx.sys against Microsoft’s DriverPolicy_Enforced.xml as downloaded on 20 August 2026, and finding 0 of 20 hash matches [1]. That is not a failure of the blocklist as designed. It is a hash list, and the moment an operator renames or recompiles the artefact, the hash changes while the capability does not.
The disclosure path also illustrates the gap. Delphos reported the driver to Microsoft’s Security Response Center on 19 August 2026; MSRC replied that the behaviour does not meet its definition of a security vulnerability because the driver is not a Microsoft-owned component, and directed the report to the driver submission portal for blocklist consideration. That case was closed, the driver was resubmitted the same day, and it was still not on the blocklist at publication [1]. Signature abuse has no clean vendor patch. The compensating controls are yours.
Capability that was present but dormant
The driver contains considerably more than this campaign used. The report lists file and registry hiding, process and driver interception, DLL interception, network control with port redirection over the Windows Filtering Platform, APC-based user-mode DLL injection, and a rule configuration system driven by a file at \SystemRoot\Alinubx.ccf [1]. The hidden helper, ProtectR3.dll, was extracted and analysed (SHA-256 26db14b9…45a8) [1].
None of it was active, because the operator never supplied the configuration file or sent the configuration IOCTL, and no heartbeat URL was configured [1]. So in this deployment Alinubx was a killer and nothing else. In a future deployment where Alinubx.ccf is present, the same driver could hide its files, inject into every process, and intercept web traffic to inject advertising, modify search results or replace downloads with malicious ones [1]. That is the difference between a stealer that gets caught and a persistent foothold that is invisible to user-mode tooling. The presence of that configuration file is one of the most valuable things to hunt for.
Stage 7: what the stealer takes, and how it defeats browser protection
With the endpoint defences killed, Rapuncel collects: saved passwords from 25 or more browsers; wallet files from 30 or more cryptocurrency applications; Discord login tokens; Steam session tokens, including silently launching Steam to scan its memory if it was not running; Telegram session data; the Windows credential store; any document whose name contains words such as password, seed, wallet or recovery; a screenshot of every connected monitor; and a detailed system profile [1][2].
Google’s app-bound encryption, introduced for Chrome in 2024, was designed to stop exactly this theft by binding the encryption key to the machine and to the application rather than leaving it where a file-copying stealer can use it [11]. Rapuncel’s approach is to stop copying and start impersonating: it injects a helper DLL into the browser process and calls the browser’s own decryption service from inside, so the request appears to originate from the application the protection was built for [1]. Delphos calls this a highly specific workflow rather than generic stealer boilerplate, which is what makes it a useful indicator of shared tooling with the BoryptGrab family [1].
The stealer also leaves footprints that are worth knowing about during an investigation: a browser_decryption.log and sends.log in the temporary output folder on the affected machine, and collection artefacts including UserInformation.txt with a BUILD NAME field, installed_applications.txt, and a directory named Filegraber, misspelled, which appears in both families [1].
Exfiltration is deliberately simple: everything is compressed into a ZIP and uploaded to 2.26.126[.]50 over a raw TCP connection carrying an HTTP-formatted POST to /upload, with three retries two seconds apart if the transfer fails [1]. The loader and the driver did not communicate with any external infrastructure in this deployment, which means network-level blocking of the loader or driver has nothing to bite on [1].
Stage 8: why the machine stays compromised
Rapuncel installs itself as a Windows service that starts on every boot, then loops: check for security products, kill anything that restarted, run the stealer again [1]. The practical consequence is that ordinary remediation does not work. The report states that the machine may remain under the attacker’s control until the kernel driver is physically removed, and that this requires Safe Mode or an external recovery environment because normal Windows tools cannot safely act on software running at that level while the system is booted [1]. Any machine that executed this payload deserves kernel-level forensic investigation rather than a cleanup script [1].
Why the chain worked: four assumptions
The campaign did not need a zero-day. It needed four reasonable beliefs to hold long enough for one download.
Figure 2. Each assumption is defensible on its own. Chained, they produced a fully trusted execution path into the kernel.
| Assumption | How it was broken here | What replaces it |
|---|---|---|
| A recognisable brand on GitHub means an official channel | Lookalike organisation and Pages site, SEO-stuffed copy, fabricated trust badges, and 40 or more brands served by one kit [1] | A published, enforced download path: block unapproved installers and unmanaged browser extensions, and make the approved source the only thing that actually works on the endpoint |
| A Microsoft signature means a vetted driver | A WHCP-chain signature from March 2023 on a driver whose capabilities were catalogued publicly in 2026 [1] | Treat attestation as provenance: keep an allowlist of drivers the fleet needs, inventory what loads, and alert on new Microsoft-attested drivers outside change control |
| A clean VirusTotal score means a safe file | 0 of 72 detections on the driver; the dangerous sibling was public with proof-of-concept code [1][7][8] | Decide on behaviour and lineage: signature family, service and device names, and IOCTL behaviour survive renaming better than hashes do |
| The vulnerable driver blocklist covers the drivers that matter | 0 of 20 hashes matched the list on 20 August 2026, and a filename change was enough to evade name-keyed detection [1] | Layered kernel controls: memory integrity, the blocklist as one input, plus your own hash and signer rules for the driver lineages you actually care about |
Attribution: a crypter service, a sibling stealer and a kit for hire
The loader is the strongest attribution signal. Delphos assesses with high confidence that vsdbg.dll came from the Cruciferra PUROSANGUE package or a close derivative [1]. Proofpoint documented Cruciferra in July 2026 as a sophisticated crypter service used by multiple unrelated criminal clusters to deliver remote access trojans and stealers, written in Mono, using indirect system calls and API and IAT unhooking, and built around a large collection of custom encryption routines that frustrate static analysis. It was advertised on Exploit[.]in as the underground’s most lethal crypter and first offered for sale in autumn 2025, with multiple tiers [5].
The matches here are specific rather than generic: the .reloc payload container, the custom Base16 alphabet with the 0x50 to 0x5F byte range, the decrypted purosangue.tx string, the DLL side-loading pattern, the UAC bypass behaviour, the persistence model and the BYOVD-style defensive tampering with the same 145-target default list [1]. The one operational difference from the eSentire observation of PUROSANGUE is the driver: where that analysis saw DCRCVDrv.sys, this sample used the renamed Microsoft-attested CnCrypt driver, which is a swap rather than a break in lineage [1].
The stealer links to a separate campaign. Trend Micro documented BoryptGrab in March 2026: the same SEO-optimised fake GitHub repositories and deceptive Pages portals, harvesting browser and wallet data, screenshots, Telegram data and files, with some variants downloading a PyInstaller backdoor called TunnesshClient that establishes a reverse SSH tunnel, and with build names such as Shrek [6]. The confirmed overlaps with Rapuncel, as set out in the LastPass report, include the passathook-cs2 brand appearing in both datasets, the delivery architecture with a dynamic payload-server lookup, the collection artefacts including the misspelled Filegraber directory, the highly specific app-bound encryption bypass workflow, and the archive size inflation [1][6].
The differences matter too, because they show how these families evolve: distinct hashes and build names, a 136 KB browser helper exporting Bootstrap in Rapuncel against a 1.35 MB helper exporting ReflectiveLoader in the documented BoryptGrab samples, separate command-and-control infrastructure, no kernel driver documented in the BoryptGrab reporting, and different secondary payloads, where BoryptGrab adds a reverse SSH backdoor and a Golang downloader while this campaign adds Alinubx.sys [1][6]. Delphos assesses Rapuncel as a BoryptGrab-related variant or sibling build with moderate confidence, and found no definitive evidence that it was AI-generated, though an AI-assisted rewrite could not be ruled out [1].
Put together with the forty-brand backend, the picture is a service: lure kits generated from URL parameters, unique campaign identifiers per victim path, payload servers that rotate behind a lookup endpoint, a crypter that changes encryption per build, and a driver lineage the operator swaps when a filename gets burned [1][5].
Detection: what to hunt, and where
The report is explicit that durable indicators here are behavioural, because hashes, filenames and server addresses rotate [1]. The table below lists what to look for and why it survives repackaging.
| Artifact or behaviour | Why it matters | Where to look |
|---|---|---|
| A write to C:\Windows\System32\drivers\nvfsflt64.sys | The drop path in this deployment; the operator may rename again, so pair it with the next two rows | File creation telemetry, Sysmon event 11, EDR file events [1] |
| Service creation named NvFsFilter, describing itself as an NVIDIA component | NVIDIA does not ship a filter driver by this name; a service describing itself as NVIDIA while the signer is a CnCrypt lineage driver is a strong signal | System log event 7045, Security event 4697, service creation telemetry [1] |
| The device \\.\Alinubx, or driver strings referencing Alinubx, CcProtect or ProtectR3.dll | The kernel interface and the user-mode helper are harder to rename convincingly than a file path | Image load and driver telemetry, string hunts in memory or on disk [1][7] |
| Presence of \SystemRoot\Alinubx.ccf | This file is the switch for the dormant rootkit capability, so its presence indicates the broader configuration, not kill-only use | File telemetry on system root, offline analysis [1] |
| vsdbg.exe loading a non-Microsoft vsdbg.dll, or spawning unexpected children | Legitimate debugging activity loads its own signed DLL from the Visual Studio installation, not from a download folder | Image load and process creation telemetry, parent-child anomalies [1] |
| A PE with a raw .reloc section far larger than its declared base-relocation size, dense with bytes in the 0x50 to 0x5F range | The encrypted payload container is a lineage indicator of the crypter, and it survives recompilation better than a hash | Static triage of downloaded archives and new binaries [1][5] |
| Linux-side nothing, Windows-side: mass process termination of security software | The kill is the loudest event in the chain, and it will appear as EDR services stopping across the fleet | EDR service stop events, process termination telemetry, agent health dashboards [1] |
| Newly installed Microsoft-attested drivers whose metadata carries the Henan Dafeng Software name or CnCrypt strings | The identity most defenders would see first was changed; the version resources were not | Driver inventory, Authenticode programName pivots [1] |
| Large ZIP downloads from github.io or parked domains, in the 100 MB range | Archive padding is a deliberate technique to slip past size limits | Proxy and web gateway logs, browser download telemetry [1][6] |
| DNS or proxy traffic to albinofennel[.]com, hanselarinmusky[.]com, icansamyope[.]com, istatlmenus[.]com, macperformancetools[.]com, zaffersnouty[.]com | Historical infrastructure, useful for retro-hunting and correlation rather than durable blocking | DNS and proxy logs, firewall logs [1] |
| ZIP upload to 2.26.126[.]50 using POST /upload over raw TCP | The exfiltration signature: a non-standard transport carrying HTTP-formatted content | Egress monitoring, network metadata, flow records [1] |
| browser_decryption.log or sends.log in the temporary output folder | Direct forensic evidence that the stealer ran, even if the archive was deleted | Endpoint triage, IR collection [1] |
| Deletion of the Chrome extensions.settings registry key | Observed on both terminal domains in sandbox; purpose undetermined but deliberate | Registry change telemetry, browser integrity checks [1] |
There is an architectural consequence in all of this. If the first thing a successful attacker does is terminate your endpoint agent, then any detection that lives only on the endpoint is a detection that can be switched off. Forward DNS, proxy, authentication and Windows event data to a collector the endpoint cannot reach, so that a killed agent still leaves a trail [1].
Defence strategy, layer by layer
| Layer where the chain can break | Control | Why it works against this campaign |
|---|---|---|
| Distribution | Publish and enforce a software catalogue: allow only approved sources, block unmanaged installer downloads, and give users a sanctioned way to request software | The chain starts with a user downloading an installer from an unofficial source. If the download cannot complete or cannot execute, nothing downstream matters [1] |
| Execution | Application control with rules that constrain signed binaries, including developer and debugging tools, to their installation directories, and block library loading from user-writable paths | Defeats the side-loading step specifically: the trusted vsdbg.exe stops being useful when it cannot load a DLL from the download folder [1] |
| Execution | Attack surface reduction and browser policy: block executable content unless it meets prevalence, age and trust criteria, use the rule that blocks abuse of exploited vulnerable signed drivers [10], and manage browser extensions centrally | Adds friction to the padded archive, the installer and the extension tampering seen at the terminal domains [1] |
| Privilege | Remove standing local administrator rights, use separate administrative accounts, and monitor elevation patterns | The driver install requires administrator rights, so removing routine local admin removes the easiest path to SYSTEM [1][3] |
| Kernel | Memory integrity (HVCI) and the Microsoft vulnerable driver blocklist, both of which are available by default on modern Windows and enforced together | Raises the cost of loading an arbitrary signed driver; the public proof of concept for this driver family explicitly notes that memory integrity must be disabled for it to load [1][7][8][9] |
| Kernel | An explicit allowlist of drivers your fleet needs, plus your own hash and signer rules for known-abuse lineages such as the CnCrypt and CcProtect family | Microsoft’s own guidance recommends an allowlist approach where feasible, because the shipped blocklist balances compatibility and is not exhaustive [9] |
| Telemetry | Collect driver loads, service creation, image loads, DNS, proxy and authentication events off the endpoint, and alert on security agent termination fleet-wide | The driver kill is the loudest event and it survives renaming, and off-host logging survives the agent being killed [1] |
| Response | Rehearse offline removal: Safe Mode or external recovery, credential reset from a clean device, session revocation for Discord, Steam, Telegram and browsers, wallet review, then reimage | The kernel driver cannot be safely removed from a running system, and credentials were already taken before the kill began [1] |
| Assurance | Keep a driver inventory, test your blocklist against renamed copies of known-abused drivers, and report abused drivers to Microsoft’s driver submission portal [12] | The campaign succeeded because a known-abused driver with a public proof of concept went undetected under a new name; testing with the rename is the whole lesson [1][7][8] |
If a machine ran the installer
- Treat every credential that was stored in a browser on that machine as exposed, along with wallet files, Discord, Steam and Telegram sessions, and anything in Windows Credential Manager. The stealer collected and exfiltrated these before the driver work began [1].
- Change those credentials from a separate, known-clean device rather than from the affected machine, and review vault and account activity for anything unexpected [1].
- Isolate the host and preserve it for kernel-level forensic investigation instead of running cleanup tools on it [1].
- Remove the driver offline, from Safe Mode or an external recovery environment, checking for the service, the drop path and the configuration file [1].
- Hunt the estate for the same artefacts and for the dormant-configuration indicator, because the driver may be present without its full capability enabled [1].
- Only then rebuild, and fix the path that allowed the download: the endpoint cannot be the only control that stood between a search result and the kernel [1].
What to take away
- The delivery problem and the defence problem are the same problem: a user downloading an installer from a source you do not control [1].
- DLL side-loading works because signature checks validate the host binary, not the adjacent library. Constrain where trusted binaries may load from [1].
- A kernel driver beats user-mode security products by design, and Protected Process Light does not help once the open happens in kernel mode [1].
- Attestation, reputation scores and hash blocklists are provenance and popularity signals, not safety signals. All three were on the attacker’s side here [1].
- The capability was public before the campaign: a catalogued driver with proof-of-concept killer code, renamed and re-signed with an existing signature. Assume the next one will be too [7][8].
Sources
- LastPass Threat Intelligence, Mitigation and Escalation team with Delphos Labs, “One Kit, Forty Companies: How a Malware-as-a-Service Platform Used GitHub as a Distribution Network for its Campaign” (17 September 2026), the primary technical report behind this post. The vendor blog returns 403 to automated readers; archived copy at web.archive.org · https://blog.lastpass.com/posts/lastpass-delphos-report-rapuncel-infostealer
- SecurityWeek, “Fake LastPass Installers Push Kernel-Level EDR Killer, Rapuncel Stealer” (21 September 2026) · https://www.securityweek.com/fake-lastpass-installers-push-kernel-level-edr-killer-rapuncel-stealer/
- BleepingComputer, “Fake LastPass Authenticator GitHub repos push new Rapuncel infostealer” (18 September 2026) · https://www.bleepingcomputer.com/news/security/fake-lastpass-authenticator-github-repos-push-new-rapuncel-infostealer/
- The Hacker News, “Fake LastPass Authenticator Installer Abuses Microsoft-Signed Driver to Kill Antivirus and EDR” (21 September 2026) · https://thehackernews.com/2026/09/fake-lastpass-authenticator-installer.html
- Proofpoint Threat Research, “Unpacking Cruciferra: An Analysis of a Sophisticated Crypter Service” (20 July 2026) · https://www.proofpoint.com/us/blog/threat-insight/unpacking-cruciferra-analysis-sophisticated-crypter-service
- Trend Micro, “New BoryptGrab Stealer Targets Windows Users via Deceptive GitHub Pages” (March 2026), including the published IOC file · https://www.trendmicro.com/en_us/research/26/c/boryptgrab-stealer-targets-users-via-deceptive-github-pages.html
- LOLDrivers entry for CnCrypt CcProtect.sys, catalogued as a BYOVD process-killer provider · https://www.loldrivers.io/drivers/3e3067b0-3d74-46fe-9f57-1ae3a0293958/
- BlackSnufkin, CcProtect-Killer proof of concept, which sends IOCTL 0x222024 to the CcProtect device to terminate an arbitrary process · https://github.com/BlackSnufkin/BYOVD/tree/main/CcProtect-Killer
- Microsoft Learn, Microsoft recommended driver block rules, including the note that the vulnerable driver blocklist is not guaranteed to block every vulnerable driver and that an allowlist approach is recommended where feasible · https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules
- Microsoft Learn, Attack surface reduction rules reference, including the rule that blocks abuse of exploited vulnerable signed drivers · https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference
- Google Online Security Blog, app-bound encryption for Chrome (July 2024), the protection the stealer bypasses by injecting into the browser process · https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html
- Microsoft Security Intelligence, driver submission portal used to nominate a driver for the vulnerable driver blocklist · https://www.microsoft.com/en-us/wdsi/driversubmission
The part worth remembering
Strip away the brand names and this campaign is a sequence of ordinary decisions. A user downloaded software from a source they had no reason to distrust. A signed binary loaded a library from the wrong place. A user account had enough privilege to install a driver. A known-abused driver was renamed. A blocklist keyed on hashes did not match. Each of those is fixable, and none of them is fixed by buying another detection signature. If you want to test how you would fare, two exercises map directly onto this chain: a controlled test of your application control and driver policy against a renamed known-abused driver, and an incident tabletop that starts with an endpoint agent going silent mid-incident and asks who notices and what evidence survives.
Published for defensive education. Technical detail is quoted from the LastPass and Delphos report and the supporting research listed above; indicators are reproduced with their source context so you can validate them against your own telemetry rather than treating any single artefact as a durable blocker.