A Microsoft-signed driver in fake LastPass GitHub downloads kills 145 security tools

Your antivirus did not miss this one. It was terminated.

There is a difference, and almost every conversation about endpoint security in a small business skips over it. The assumption baked into buying a security product is that the product is a referee standing outside the game. It watches, it judges, and if something bad happens it says so. What a kernel driver does is walk onto the field and remove the referee, from a position of higher authority than the referee has, using a permission slip signed by the league.

On September 17, 2026, LastPass’s threat intelligence team and Delphos Labs published a joint report on a campaign that does exactly that. The delivery is unglamorous: fake GitHub organizations, search engine optimized so they rank for “LastPass Authenticator download,” serving an installer that is a genuine Microsoft binary with one malicious library beside it. The interesting part is what rides along. A kernel driver, renamed, carrying a real Microsoft signature, holding a hardcoded list of 145 antivirus and endpoint detection process names, which it kills from kernel mode before the stealer starts work.

Everything below was checked against primary sources on September 21, 2026. Microsoft’s own documentation is quoted verbatim from Microsoft Learn and the Microsoft Download Center, both retrieved directly. Facts about the campaign come from the LastPass and Delphos report and are attributed as such. Where we could not confirm something, we say so, and there are two such places.

What happened, briefly

On August 13, 2026, the LastPass TIME team found a GitHub organization impersonating LastPass Authenticator. Pulling on that thread produced a distribution network impersonating at least 40 companies, which the report describes as a reusable malware-as-a-service kit rather than a one-off. The investigation state is given as of September 10, and the report was published September 17. LastPass tracks the stealer as Rapuncel and assesses with moderate confidence that it is a variant of BoryptGrab, a family Trend Micro documented in March 2026 using the same GitHub and oversized archive tradecraft.

The chain the report describes:

1. Somebody searches for a piece of software. A fraudulent GitHub organization ranks in the results, optimized for exactly that query.
2. The repository page carries fabricated trust badges. The report names “Authorized Access,” “VirusTotal Approved” and “Secure Archive.” None of these are things GitHub or VirusTotal issue.
3. The download button routes through a GitHub Pages portal, then through intermediate GitHub accounts used purely as waypoints, then through a Cloudflare-fronted redirector, before landing on a payload server.
4. The file is a ZIP, padded to between roughly 128 MB and 148 MB with two large junk DLLs. This is not incompetence. Many scanning products, including the free tier of several online scanners and some mail and proxy gateways, have a maximum file size they will inspect. Padding is a cheap way to fall off the end of that limit.
5. Inside is vsdbg.exe. That is the real Microsoft Visual Studio CoreCLR debugger, renamed to look like an installer, and it side-loads a malicious vsdbg.dll that sits next to it.
6. The malware makes three separate attempts at UAC bypass using built-in Windows features. With administrator rights it installs the driver and proceeds as SYSTEM.
7. The driver, Alinubx.sys, is written to disk as nvfsflt64.sys and registered as the service NvFsFilter, described as an NVIDIA file system filter driver.
8. The driver terminates the 145 processes on its list, from kernel mode, including ones running under Protected Process Light.
9. Rapuncel collects and exfiltrates.

Step 5 deserves a pause on its own. The executable that launches this is signed by Microsoft, because it is Microsoft’s. Any control that asks “is this binary signed by a reputable publisher” answers yes, correctly, and lets it run. The malicious code is in the DLL that the trusted executable loads. We wrote about the same structural problem from the other direction when npm packages started arriving with trustworthy provenance and untrustworthy contents. Publisher trust is a statement about who compiled a file, not about what happens when that file runs.

The driver, and what a Microsoft signature actually means

This is the part worth understanding properly, because it is the part that gets described wrong everywhere and because the correct version changes what you should do about it.

Since Windows 10 version 1607, a kernel mode driver will not load on a normal retail machine unless Microsoft has signed it. That is a real control and it genuinely raised the cost of kernel malware. The question is what Microsoft checks before it signs.

There are two routes. The thorough one is the Windows Hardware Compatibility Program, where the driver passes the Hardware Lab Kit test suite. Microsoft’s documentation describes HLK-tested drivers as demonstrating “that a manufacturer rigorously tests their hardware to meet all Microsoft requirements regarding reliability, security, power efficiency, serviceability, and performance.”

The other route is attestation signing. Here is what Microsoft’s own page says about it, quoted exactly:

For testing purposes only, you can submit your drivers for attestation signing, which doesn’t require HLK testing.

And, further down the same page:

When a driver receives attestation signing, it’s not Windows Certified. An attestation signature from Microsoft indicates that Windows trusts the driver. But because the driver isn’t tested in HLK Studio, there are no assurances about compatibility or functionality.

Read that second sentence again slowly. An attestation signature from Microsoft indicates that Windows trusts the driver. The requirements to obtain one are a Hardware Developer Program registration and an extended validation code signing certificate. You submit a CAB file. Microsoft strips your signature, applies its own, and returns the file. The gate is an identity check on the submitter, not a review of the code.

So here is the honest summary of what a Microsoft driver signature certifies: a company that passed extended validation identity checks put this file through Microsoft’s signing pipeline. That is all. It is a passport, not a background check, and the rest of Windows treats it as if it were a background check because there is no practical alternative.

Our first honest uncertainty. The report states that Alinubx.sys “is signed through the Microsoft Windows Hardware Compatibility Publisher chain, with a signing timestamp of March 2023.” That chain name appears on both attestation-signed and dashboard-signed drivers, so from the outside we cannot tell which route this particular file took, and we are not going to assert one. What matters either way is that the signature is genuine rather than forged, and that Windows honours it.

The driver itself is not new code. According to the report it is a renamed, identity-adjusted copy of CcProtect.sys, a process protection driver from Henan Dafeng Software Co., Ltd., a Chinese firm that makes disk encryption products under the CnCrypt brand. Product strings, version number 1.32, and submitter identity match. The process-kill capability is not a bug the attackers found. It is the driver’s job. A process protection driver is supposed to be able to stop processes, and the interface it exposes to do so does not care who is asking.

That original driver is catalogued on LOLDrivers, the community registry of signed drivers with abusable primitives, and proof-of-concept kill code for it is public on GitHub. The operators’ contribution was renaming the file. That was sufficient, because detection keyed to a filename does not survive a rename, and detection keyed to a signature does not fire on a valid one.

Result: 0 detections out of 72 engines on VirusTotal, recorded as of August 20, 2026.

The blocklist, and why it did not help

Windows has an answer to abusable signed drivers. It is called the Microsoft vulnerable driver blocklist, and since the Windows 11 2022 update it is enabled by default on all devices. It is also enforced whenever memory integrity, Smart App Control, or S mode is active. If you have a reasonably current Windows 11 machine, you have it on.

It did not stop this. To understand why, read Microsoft’s description of the list’s own limits, quoted from the documentation page:

Blocking drivers can cause devices or software to malfunction, and in rare cases, lead to blue screen. The vulnerable driver blocklist isn’t guaranteed to block every driver found to have vulnerabilities. When we produce the blocklist, Microsoft attempts to balance the security risks from vulnerable drivers with the potential effect on compatibility and reliability. The blocklist included in this article and in the associated downloadable files usually contains a more complete set of known vulnerable drivers than the version in the OS and delivered by Windows Update. It’s often necessary for us to hold back some blocks to avoid breaking existing functionality while we work with our partners who are engaging their users to update to patched versions.

And the cadence, from the same page: “The blocklist is updated quarterly. In addition, blocklist updates are delivered through the monthly Windows updates as part of the standard servicing process.”

Three things follow, and all three are visible in this incident.

The list is a list of known files. Alinubx.sys was not on it. The report states it “was not present in the Microsoft vulnerable driver blocklist” as of publication. A fresh rename of a known-bad driver is, to a blocklist, a file nobody has ever seen.

The shipped list lags the published list. Microsoft says so directly above: the downloadable version “usually contains a more complete set” than what is in the OS. We checked the Microsoft Download Center ourselves on September 21. The most recent published Microsoft Vulnerable Driver Blocklist is version 10.0.29545.0, dated May 14, 2026. That is the copy an administrator can apply by hand.

Quarterly is a very long time when the countermeasure is a rename. The list’s update rhythm and the attacker’s build rhythm are not in the same order of magnitude.

Microsoft’s own recommendation on that same page is the one worth taking seriously, and it is not “use the blocklist”:

As always, Microsoft recommends using an explicit allowlist approach to security wherever possible, but when that isn’t feasible, the use of this blocklist is a critical tool to disrupt malicious actors.

That is Microsoft telling you, in its own security documentation, that the deny list is the fallback.

What Microsoft said when it was told

Delphos reported the driver to the Microsoft Security Response Center on August 19, 2026, and resubmitted through the driver submission portal the same day. Per the report, MSRC replied that the behaviour does not meet its definition of a security vulnerability, on the grounds that the driver is not a Microsoft-owned component. The case was redirected to the Defender submission path and closed. At the time of publication on September 17, the driver was still not in the blocklist.

We want to be fair about this, because the reflex reading is not quite right.

MSRC is technically correct on its own terms. A third-party driver behaving as designed is not a vulnerability in Windows. There is no Microsoft code to fix, no patch to ship, no CVE that would make sense. MSRC’s scope is defects in Microsoft products, and this is not one.

The problem is the gap that correctness leaves open. Microsoft is the only party that can make a signed driver stop loading on a retail Windows machine. The vendor whose certificate is involved can revoke, but revocation is inconsistently honoured for kernel drivers and, as researchers documented in February 2026 with a revoked EnCase forensic driver used in a live intrusion, attackers keep using revoked drivers because they keep working. So the routing is: the only entity with the lever says the issue is out of scope for the team that was asked, and the process that does own the lever runs on a quarterly cycle.

That is not a conspiracy. It is an org chart meeting an attacker. But if you are the person running eleven laptops for a business in Etobicoke, the org chart is not your problem to solve, and the practical consequence is what you need to plan around: a signed driver that has not yet been individually catalogued will load on your machines, and there is no setting that changes that.

This is a category, not an incident

It would be easy to read this as one clever campaign. The numbers say otherwise.

ESET published research in March 2026 counting roughly 90 distinct EDR killer tools in circulation, of which 54 use the bring-your-own-vulnerable-driver technique, collectively abusing 35 signed drivers. ESET’s Jakub Souček summarized the economics in one line: EDR killers “endure because they’re cheap, consistent, and decoupled from the encryptor.”

Decoupled is the operative word. The same kill component gets bolted onto ransomware, onto stealers, onto whatever is next, by whoever rents the kit this month. Sophos has documented EDR killers shared across RansomHub, Blacksuit, Medusa, Qilin, DragonForce, Crytox, Lynx and INC. This is a commodity component in a supply chain, and it is being sold to people who did not write it and do not need to understand it.

What is new in this September campaign is not the driver trick. It is the pairing of a commodity kernel killer with a mass-market delivery channel that looks like the most trustworthy place on the internet to get software.

GitHub is the delivery channel, and that is the part small businesses feel

Here is the shape of the problem for an ordinary business.

Your bookkeeper needs a PDF tool. Your designer needs a file converter. Somebody needs the desktop app for the authenticator your bank told them to install. They search. A GitHub organization comes up, with a plausible name, a README that reads correctly, and a download button. GitHub is where software genuinely lives. There is no training slide anywhere that says “do not trust GitHub,” because for twenty years the advice has been the opposite.

The campaign did not defeat a control. It occupied a trust signal, the same way ClickFix occupied the visual language of a Cloudflare verification screen to get people to paste commands into the Run box. In both cases the user is doing something that looks entirely normal, and in both cases the security stack has no grounds to object.

We checked the named accounts on September 21. github.com/LastPass-Authenticator now returns 404, so that specific organization is gone, which is what you would expect after a public report naming it. Our network egress in this environment is restricted enough that we could not enumerate the rest of the accounts, so treat the takedown as confirmed for one account and unknown for the others. This is our second honest uncertainty, and it matters less than it sounds, because the report describes a reusable kit. Removing forty organizations removes forty organizations. It does not remove the tooling that made them.

What actually gets stolen

Per the report, Rapuncel collects credentials from more than 25 browsers, data from roughly 30 cryptocurrency wallets, Discord, Steam and Telegram session tokens, the contents of Windows Credential Manager, screenshots, a system profile, and documents whose filenames contain password, seed, wallet or recovery.

Strip out the consumer items and look at what is left for a business.

Browser-stored passwords. Not just the ones staff remember saving. Every one Chrome or Edge ever offered to save and they clicked yes: the hosting control panel, the payroll portal, the domain registrar, the business banking login, the client’s WordPress admin.

Windows Credential Manager. Mapped network drives, saved RDP connections, some VPN credentials, and whatever line-of-business applications have stashed there.

Session tokens. This is the one people underestimate. A stolen live session does not need the password and does not need to pass MFA, because the authentication already happened. We went through the mechanics of this in detail when attacker-in-the-middle kits started harvesting Microsoft 365 sessions, and the conclusion is the same here: resetting the password does not end a stolen session. You have to revoke the sessions explicitly.

Documents matching those four keywords. Every office has a passwords.xlsx somewhere. Usually more than one, usually out of date, usually still containing three things that work.

The realistic sequence after a hit on one laptop in a ten-person firm is not dramatic. It is: the stealer logs go to a broker, the broker sells the interesting-looking ones, and some weeks later somebody who bought your Microsoft 365 session reads a month of your mailbox, learns how your invoices are worded and who approves them, and sends one. That is where the money leaves. The driver, the kernel, the 145 processes, all of that is infrastructure for the boring outcome.

The three controls that would have stopped this

Take the chain and ask, at each step, what would have broken it. The answer is uncomfortable, because the effective controls are not the ones anybody sells you.

1. Standard user accounts. This is the whole ballgame.

The malware makes three attempts at UAC bypass. Every known UAC bypass technique works by abusing an auto-elevating Windows component, and every one of them requires that the account already be a member of the local Administrators group. UAC is a convenience boundary for an admin account, not a security boundary. Microsoft has said so for years.

A user who is not a local administrator cannot be bypassed into becoming one. The driver never installs. The service is never created. The 145 processes are never touched. Rapuncel might still run in that user’s context and take their browser passwords, which is bad, but it is a fraction of the incident and it happens with your endpoint software awake and watching.

This is free. It takes about ten minutes per machine. It is the single highest-value thing on this page and it is skipped in most small offices because somebody once needed to install a printer driver and it was easier to just leave the account as admin. Give people a separate admin account for the handful of times a year they genuinely need one.

2. Application allowlisting, which is Microsoft’s own top recommendation.

An allowlist does not need to have heard of Alinubx.sys, or of the renamed vsdbg.exe, or of anything the operators build next month. It permits what you approved and refuses everything else, which is the only posture that does not depend on the defender having seen the file before.

For a small business, in rough order of effort:

• Smart App Control, if the machine qualifies. It is free, built in, and blocks untrusted and unsigned applications. The catch is real: it can only be turned on during a clean install of Windows 11, and if it is off on an existing machine there is no supported way to switch it on without reinstalling.
• App Control for Business (formerly WDAC), which is the proper tool and also the one that needs a week of audit mode before you enforce anything.
• AppLocker, on older machines and older editions.

If none of those are realistic this quarter, at minimum enable the Defender ASR rule Block executable files from running unless they meet a prevalence, age, or trusted list criterion (GUID 01443614-cd74-433a-b99e-2ecdc07bfc25, requires cloud-delivered protection on). A freshly compiled installer from a two-week-old domain has no prevalence and no age. Run it in audit mode first and read the events, because it will also object to things your business legitimately uses.

3. Do not let the file arrive.

Software gets installed from the vendor’s own domain, from winget, or from the Microsoft Store. Not from search results. The rule for staff is a single sentence and it survives repetition: if you did not type the vendor’s domain yourself, you are not on the vendor’s site.

For a business with a couple of dozen machines, winget is worth twenty minutes of somebody’s attention. It resolves from a curated manifest repository rather than from whatever ranked first this morning, and it removes the entire class of “I searched for it and clicked download.”

The controls that would not have helped, and why

Worth stating plainly, so nobody buys the wrong thing in response to this article.

Control	Outcome here
Antivirus or EDR agent	Terminated from kernel mode before the stealer ran
Vulnerable driver blocklist	Driver was not on the list, and the list updates quarterly
ASR rule: block abuse of exploited vulnerable signed drivers	Depends on the same known-driver intelligence, and per Microsoft “doesn’t prevent loading existing drivers already on the computer”
Signature and publisher checks	Every signature in the chain was genuine
VirusTotal before running	0 of 72 engines, recorded August 20
Scanning the download	Archive padded to roughly 128 to 148 MB to exceed inspection limits
MFA on the accounts	Session tokens stolen after authentication already succeeded

None of that means endpoint security is pointless. It means it is the layer that tells you what happened, and it only gets to do that job if it is still running. In this chain it was not, and the only controls that survived contact are the ones that act before code runs at all.

Check your own machines

These are read-only. Run them in PowerShell as an administrator on Windows 11 or Windows 10.

Look for the driver and its service:

Get-ChildItem "$env:SystemRoot\System32\drivers\nvfsflt64.sys" -ErrorAction SilentlyContinue
Get-CimInstance Win32_SystemDriver | Where-Object Name -eq 'NvFsFilter'

Anything returned by either command on a machine without NVIDIA storage software is worth investigating properly, and the correct next step is to disconnect that machine from the network before you keep typing on it.

Confirm the vulnerable driver blocklist is actually on:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" |
  Select-Object VulnerableDriverBlocklistEnable

Check memory integrity, which enforces the blocklist regardless of the setting above:

Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
  -ClassName Win32_DeviceGuard |
  Select-Object SecurityServicesRunning, VirtualizationBasedSecurityStatus

SecurityServicesRunning containing 2 means HVCI is active.

Now the question that matters most, which is how many of your users are local administrators:

Get-LocalGroupMember -Group "Administrators"

If the answer includes the account your staff log into every day, that is the finding. Everything else on this page is secondary to it.

And see what a compromise would have handed over, on each machine:

Get-ChildItem "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Login Data" -ErrorAction SilentlyContinue
Get-ChildItem "$env:LOCALAPPDATA\Microsoft\Edge\User Data\Default\Login Data" -ErrorAction SilentlyContinue
cmdkey /list

One more thing that is not a command. If any machine in your business is still on Windows 10, it no longer receives the monthly servicing that carries blocklist updates, which means the deny list on it is frozen at whatever it was when support ended. We covered what that actually costs a small business when the deadline arrived, and this is a concrete instance of it.

If you think you were hit

Order matters here, and the usual instinct gets it wrong.

1. Get the machine off the network. Do not shut it down if you may need forensics; pull the network. Do not keep using it.
2. Assume every credential on it is gone. Not the ones you remember. All of them.
3. Change passwords from a different, known-clean device. Changing them from the compromised machine hands the new ones to the same stealer. LastPass’s own advice in the report is exactly this.
4. Revoke sessions, do not just reset passwords. In Microsoft 365, sign the user out of all sessions in Entra ID. In Google Workspace, sign the user out from the admin console. Repeat for anything else that keeps a long-lived session: the CRM, the hosting panel, Slack.
5. Rotate the shared things. Hosting control panel, domain registrar, payment processor keys, anything in a spreadsheet that matched those four keywords.
6. Rebuild the machine. A driver that ran in kernel mode and holds the ability to terminate security processes is not something you clean off. Reinstall.
7. Read the mailbox rules. Business email compromise usually starts with a forwarding or auto-delete rule that hides the attacker’s replies. Check the mailbox rules on every account that touched that machine, including the ones that look fine.

The uncomfortable summary

The security model of Windows drivers rests on a signature, and a signature answers the question “who submitted this file,” not the question “what does this file do.” Microsoft’s documentation says so in plainer language than any vendor marketing will: attestation signing is “for testing purposes only,” an attestation signature “indicates that Windows trusts the driver,” and there “are no assurances.”

Bolted onto that is a deny list that ships quarterly, that Microsoft itself says is not guaranteed to be complete, that Microsoft itself describes as the fallback to allowlisting, and that in this case did not contain the file because the file had been renamed. And behind the deny list is a reporting process that correctly concluded a third-party driver behaving as designed is not a Microsoft vulnerability, and closed.

Every part of that is defensible. The sum is a Windows machine that will load a kernel driver, signed in 2023 by a company that makes disk encryption software in Henan, renamed to look like an NVIDIA component, which switches off 145 security products before anything else happens. And the way it got onto the laptop was a GitHub page that ranked well.

You cannot fix any of that. What you can do is make the chain fail at the one step that does not depend on anybody recognising a file: the step where the malware needs administrator rights and does not have them. Take local admin off the accounts your staff use daily. It costs nothing, it takes an afternoon, and in this incident it is the difference between a bad day and a rebuild.

---

If you run a business in Toronto and you are not certain who on your team has local administrator rights, or whether a machine has ever run something it should not have, get in touch. Checking is cheap and it is a short conversation. We write up the month’s security and patching stories in the same plain language.

Sources

Microsoft primary documentation, each page retrieved and read on September 21, 2026:

• Driver Signing Options, Microsoft Learn, page dated March 23, 2026, for the verbatim sentences “For testing purposes only, you can submit your drivers for attestation signing, which doesn’t require HLK testing” and “When a driver receives attestation signing, it’s not Windows Certified. An attestation signature from Microsoft indicates that Windows trusts the driver. But because the driver isn’t tested in HLK Studio, there are no assurances about compatibility or functionality,” for the extended validation certificate requirement, and for the quoted description of HLK-tested drivers
• Attestation Sign Windows Drivers, Microsoft Learn, for the submission mechanics: CAB file, EV signature by the submitter, Partner Center submission, and Microsoft replacing the submitted catalog and signature with its own
• Microsoft recommended driver block rules, Microsoft Learn, page dated May 1, 2026, for the verbatim caveat beginning “Blocking drivers can cause devices or software to malfunction,” for “The blocklist is updated quarterly,” for the statement that the blocklist has been enabled by default since the Windows 11 2022 update and is enforced under memory integrity, Smart App Control or S mode, and for the verbatim recommendation “Microsoft recommends using an explicit allowlist approach to security wherever possible, but when that isn’t feasible, the use of this blocklist is a critical tool to disrupt malicious actors”
• Microsoft Vulnerable Driver Blocklist download, Microsoft Download Center, for the most recent published blocklist being version 10.0.29545.0 dated May 14, 2026, as shown on the page on September 21, 2026
• Attack surface reduction rules reference, Microsoft Learn, page dated September 9, 2026, for the GUID 01443614-cd74-433a-b99e-2ecdc07bfc25 and its cloud-protection dependency, for the GUID 56a863a9-875e-4185-98a7-b882c64b5ce5, and for the verbatim statement that the vulnerable signed drivers rule “prevents apps from saving vulnerable signed drivers on the computer. It doesn’t prevent loading existing drivers already on the computer”

Campaign research. These findings are the researchers’ and are not vendor-confirmed:

• 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”, published September 17, 2026, investigation state as of September 10, 2026. Source for the August 13 discovery date, the impersonation of at least 40 companies, the fabricated “Authorized Access,” “VirusTotal Approved” and “Secure Archive” badges, the multi-hop redirect chain, the ZIP padding to roughly 128 to 148 MB, the vsdbg.exe and vsdbg.dll side-loading, the three UAC bypass attempts, the Alinubx.sys to nvfsflt64.sys rename and NvFsFilter service, the Microsoft Windows Hardware Compatibility Publisher chain signature with a March 2023 timestamp, the 145 hardcoded antivirus and EDR process names, the Protected Process Light bypass, the 0 of 72 VirusTotal result as of August 20, 2026, the CcProtect.sys and Henan Dafeng Software Co., Ltd. lineage with matching version 1.32 strings, the absence of the driver from the Microsoft vulnerable driver blocklist at publication, the August 19 MSRC report and its closure on the grounds that the driver is not a Microsoft-owned component, the exfiltration targets including 25-plus browsers, roughly 30 cryptocurrency wallets, Windows Credential Manager, session tokens and documents matching password, seed, wallet and recovery, the moderate-confidence assessment that Rapuncel is a BoryptGrab variant, and the advice to change credentials from a separate known-clean device
• “Fake LastPass Authenticator GitHub repos push new Rapuncel infostealer”, BleepingComputer, September 18, 2026, used as independent corroboration of the 40 companies, the 145 security products, the driver and loader filenames, and the exfiltration targets
• “LastPass discovers new infostealer variant disguised as GitHub repo”, heise online, September 19, 2026, used as a second independent corroboration of the same figures
• “54 EDR Killers Use BYOVD to Exploit 35 Signed Vulnerable Drivers and Disable Security”, The Hacker News, March 19, 2026, reporting ESET research, for the counts of roughly 90 EDR killer tools, 54 using BYOVD and 35 abused signed drivers, and for the quoted line from ESET researcher Jakub Souček
• “Ransomware attackers introduce new EDR killer to their arsenal”, Sophos, for EDR killer tooling shared across multiple ransomware operations
• LOLDrivers, the community registry of signed drivers with abusable primitives, for the catalogued entry covering CcProtect.sys

Checked by us directly on September 21, 2026:

• github.com/LastPass-Authenticator returns HTTP 404, indicating that named organization has been removed. Egress restrictions in our environment prevented us from checking the remaining named accounts, so the status of the rest of the network is unknown to us