Executive Summary

On October 21, 2026, the Node.js project released security updates that fix CVE-2026-111497, an out-of-bounds write in the Brotli decoder bundled with the runtime. Vendors have labeled the vulnerability Node2Shell, Brotli2Shell, Broccoli2Shell, and HTTP2Shell, because the flaw sits in Google's Brotli library and reaches software well beyond Node.js. Any application that decompresses attacker-controlled data with a vulnerable Brotli library could be at risk. Google, as the CVE Numbering Authority, scored it 9.2 under CVSS v4.0, and Node.js rates it high.

CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities (KEV) catalog on October 27, 2026, with a November 10, 2026 deadline for federal civilian agencies. The public telemetry we reviewed shows exploitation attempts against honeypot sensors, and researchers have demonstrated code execution in lab environments. As of October 29, 2026, we are not aware of a public report of a confirmed compromise of a production system.

This report details Node2Shell's mechanism, affected versions, and observed activity, and outlines how SentinelOne customers and partners can strengthen their defenses.

Key Highlights

• One flaw, many patches. Node.js, Google Brotli, Bun, .NET, Python, Envoy, Istio, and PHP for Windows each shipped their own fix. Updating one does not update the others.

• Attempts are confirmed. Production compromise is not. ELLIO and Previdian have each recorded an exploitation attempt against their honeypot sensors. Previdian notes that such observations do not show the target was vulnerable or that the attempt succeeded.

• A default Node.js server is not exposed by itself. Something must hand attacker-controlled Brotli data to the decoder. Node.js names direct node:zlib use. Express 5 request bodies and built-in fetch() responses reach the same decoder, and Imperva reproduced both in the lab.

• A failed exploit still costs you. The Node.js advisory lists a crash as an outcome, and Sysdig reports that crashes have been easy to reproduce. Repeated crashes are a denial of service against any service that decodes attacker-influenced Brotli.

• The fix was visible for nearly eight months before release. Google committed it on February 27, 2026, with no release and no advisory. End-of-life Node.js 20, 23, and 25 are not expected to receive a fix.

Organizations should take the following steps immediately:

• Upgrade Node.js to 22.23.4, 24.22.1, or 26.12.1, then restart processes and rebuild container images.

• Inventory every other runtime and library that embeds the Brotli decoder, and patch internet-facing services first.

• Where patching must wait, reject inbound requests that carry Content-Encoding: br at the proxy or load balancer.

What is Node2Shell

Node2Shell is a memory corruption flaw in the Brotli decoder, the code that expands Brotli-compressed data. A Brotli stream signals switches between block types. When a stream declares only one block type, a switch is invalid and the decoder should reject it. The vulnerable decoder instead reported the invalid switch as a request for more input. The caller supplied more bytes, and the decoder kept appending them to an eight-byte internal buffer and wrote past its end, according to the Node.js advisory.

Node.js lists the outcomes as a crash, disclosure of process memory, or remote code execution, and the CVE record describes the attacker as unauthenticated. Imperva demonstrated code execution on the official Node.js 24.22.0 arm64 image. Microsoft describes the .NET impact as information disclosure, denial of service, or elevation of privilege.

Node2Shell at a Glance

How Attacker-Controlled Brotli Reaches the Decoder

Disclosure Timeline

Exploitation in the Wild

Exploitation attempts have been recorded, but a successful attack on a production system has not been publicly reported as of October 29, 2026. CISA added CVE-2026-111497 to its KEV catalog on October 27, 2026, with a November 10, 2026 deadline for federal civilian agencies under BOD 26-04.

The public telemetry comes from honeypots. Two threat intelligence providers each recorded an attempt: ELLIO saw a request built for Node.js 24.22.0 on x86-64 on October 26, and Previdian saw one from a U.S.-based address on October 27. Previdian notes that such observations do not show the target was vulnerable or that the attempt succeeded.

Researchers have reproduced code execution only in lab testing. Imperva ran code on the official Node.js 24.22.0 arm64 image through fetch() and Express 5 request bodies, needed multiple attempts, and did not test every Node.js build. Public proof-of-concept code appeared within hours of the October 21 release, according to Sysdig, so organizations should expect further attempts, particularly against internet-facing Express 5 services.

Observed Indicators

Patch Status

Node.js has fixed every supported release line: 22.x, 24.x, and 26.x. It will not patch end-of-life lines, which the project says are always affected when a security release occurs. Organizations running Node.js 20, 23, or 25 have no patch to apply and must upgrade to a supported line.

Recommended Mitigations

Patch, Restart, and Rebuild

• Upgrade to a fixed Node.js release, update every Dockerfile that pins an older tag, and restart or redeploy every workload.
• Confirm patch status from the Node.js release version running in each workload, not a bundled library version string, which may not reflect a backported fix.

Find Every Copy of the Decoder

• Inventory Bun, .NET, Python Brotli, Envoy, Istio, PHP for Windows, and statically built executables, including staging, CI, build images, and developer machines.
• Where Node.js links the system Brotli library, as it does on Debian, check your distribution’s advisory for the Node.js package as well as brotli. Debian’s tracker lists both.
• PHP for Windows fixed the flaw with rebuilt packages that keep the same PHP version number, so php -v looks the same before and after. Check the -1 build suffix or the SHA-256 on the download page.
• Move off Node.js 20, 23, and 25 on a defined date.

Reduce Exposure Until Patching Finishes

• Reject requests with Content-Encoding: br at the WAF or proxy, or set the body-parser inflate option to false so compressed bodies return HTTP 415. The second option also rejects gzip and deflate bodies, so test client traffic first.
• Restrict server-side fetches to trusted destinations. Link previews, webhooks, and crawlers send attacker-influenced URLs into fetch(), and removing br from Accept-Encoding does not stop a hostile server from replying with Brotli.
• Enable a vendor WAF rule as a stopgap where one exists. It does not replace the upgrade.

Limit the Blast Radius

• Run Node.js services as a non-root user and limit outbound connections from Node.js hosts. Docker runs containers as root by default, and the official node image provides a node user (uid 1000) that you must select with USER or -u.

Watch for Failed Attempts

• Alert on repeated worker crashes after requests with Content-Encoding: br. Where core dumps are enabled, restrict who can read them and shorten retention, because a core file can hold memory contents from other users’ sessions.

How SentinelOne Protects You

Node2Shell exploits the Brotli decoder inside the Node.js process. Patching Node.js and every other copy of the Brotli decoder remains the primary control. SentinelOne provides detection and visibility into post-exploitation behavior while that work is underway.

The Singularity agent builds a storyline of process activity on a host, including the Node.js services targeted by Node2Shell. These processes have a predictable life: they answer requests, call APIs, and read files. They do not normally start /bin/sh, run reconnaissance commands, download executables into /tmp, or open connections to arbitrary hosts. Behavioral detection looks for that deviation from normal behavior. 

Detection in Singularity AI SIEM

Platform detection content looks at what happens on the host after exploitation, not at the request body. 

Correlation rules tie these together. A request to the service, or an outbound fetch to an untrusted host, followed by a process spawn or file drop from the same Node.js process is the shape of a successful chain. 

Visibility at the Edge

Sysdig reports that the crash is easy to reproduce, which makes repeated worker crashes and restarts a useful early signal. Web server, WAF, and CDN logs may show requests with Content-Encoding: br followed by bursts of HTTP 5xx responses and unexplained worker restarts. Singularity AI SIEM can ingest those sources alongside endpoint data if you forward them. 

Hunt with Purple AI While You Patch

Patching is the only complete fix. While that work runs, analysts can ask Purple AI questions such as:

• Show me shell processes whose parent or prior image was node, nodejs, or bun since October 21.
• Show me new executable files written by the Node.js service account since October 21.
• Show me outbound connections from the Node.js service account to destinations we have never seen.
• Show me hosts with a spike in 500 responses followed by a Node.js process restart.

The last question depends on web server logs being ingested. 

Confirm Agent Saturation on Node.js Hosts

Confirm the agent is deployed, healthy, and in protect mode on every server and container host that runs Node.js, Bun, or another service that decompresses Brotli. Start with internet-facing Express 5 services and services that fetch external URLs.

Disclaimer

Information contained herein is current as of October 29, 2026, and is subject to change as patch releases and threat activity evolve. Recipients should not rely solely on this report for security decisions and should consult with their security teams and SentinelOne account representatives for current guidance.

The Arc browser shutdown arrives December 22, 2026. Export your data now and move to Dia before accounts are deleted.

Related Posts:

• iOS 27.1 iPhone Duo Release Targets Foldable Hardware
• OpenAI Cuts Internet Access for Frontier Model Training
• Google Privacy Policy Change Raises Gmail Ad Concerns

The post Arc Browser Shutdown Set for December 22, 2026 appeared first on Daily CyberSecurity.

Executive Summary

On October 21, 2026, the PHP project released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. The two flaws are known together as PHP2Shell. They were disclosed by the security firms Calif and Wiz and by OpenAI, working with the PHP security team, after AI-assisted auditing turned an out-of-memory weakness that a 2024 audit had flagged but could not prove exploitable into working remote code execution.

Both vulnerabilities sit in PHP's memory management and error handling, code that nearly every request touches, and the earliest affected path dates to PHP 5.4.0. An unauthenticated attacker can execute code on the web server or read its process memory, including passwords, tokens, and API keys belonging to other requests. On Apache with mod_php, the attack runs before any application code executes, which means an application with no bugs of its own is still exposed. As of October 21, 2026, no verified proof-of-concept code is available publicly. Attack attempts have been observed by Cloudflare after the leak, but no confirmed in-the-wild compromise has yet been reported.

While upgrading every PHP runtime remains the primary control, SentinelOne agent detects attackers’ post-exploitation activities. Once an attacker has code execution on the web server process, the behavior that follows web server flaws: execute shell commands, drop and invoke webshells, download and execute custom payloads and outbound connections. On managed hosts, the Singularity™ agent and Singularity AI SIEM detection content look for such behaviors, and Purple AI® can be used to hunt for it during the patching window. The separate memory-disclosure path runs no code on the host, so it leaves no process behavior to detect; that path is instead surfaced through web server, WAF, and CDN telemetry forwarded into AI SIEM.

This report details PHP2Shell's mechanism, affected versions, and confirmed activity, and outlines how SentinelOne customers can strengthen their defenses.

Key Highlights

• The flaw is in PHP itself, not in any application. WordPress, Drupal, Joomla, Magento, Laravel, and other web applications are all exposed on an affected PHP version, because the vulnerable code is in the runtime beneath them.
• The patch is the only complete fix. PHP states plainly that no configuration change fully closes the vulnerability. Every interim mitigation reduces one attack path and leaves others open.
• The unauthenticated path runs before your code does. On Apache with mod_php, a single crafted HTTP request triggers the flaw during request startup, so application-level controls never see it. PHP assesses the risk as highest for mod_php.
• Memory disclosure leaks secrets without a shell. One path reads live worker memory and returns passwords, tokens, API keys, and certificates with no code execution, which makes it quieter than a shell and harder to catch with execution-focused tooling.
• End of Life PHP will not get a patch. Organizations running PHP 8.1 and prior will not receive an official release. Source-only backports exist for 7.4, 8.0, and 8.1, and distribution or LTS vendors may offer fixed packages.
• Leverage SentinelOne platform post-exploitation coverage. The detection by the agent is agnostic to the vulnerability and exploit chain and focuses on attackers activity following the exploit, including but not limited to, installation and usage of webshells, command executions and outbound connection behavior that follows the code execution.

Organizations should take the following steps immediately:

• Update every PHP runtime to a fixed version and restart Apache, PHP-FPM, and any long-running workers.
• Inventory internet-facing PHP, including the copies bundled inside appliances, control panels, and vendor software.
• Isolate end-of-life PHP (8.1 and older) from the internet until it can be upgraded.
• Rotate credentials, tokens, and keys that a PHP worker could hold in memory on any exposed, unpatched system.
• Monitor the official PHP changelog for relevant updates

What is PHP2SHELL

PHP2Shell is a family of memory-safety vulnerabilities in core PHP, grouped under two CVEs that share one root cause. When PHP hits a fatal condition such as exhausting its configured memory limit, it does not unwind cleanly. It abandons the current operation with a “longjmp” out of the C call stack, so no cleanup runs and nothing records that a data structure was left half-built. A later cleanup routine, or a later request, then trusts that state.

CVE-2026-109618 is the out-of-memory case. PHP marks request data as valid before allocating memory for it. If that allocation hits the memory limit and fails, the entry is left pointing to uninitialized heap memory. When the failed request runs its cleanup routine, it processes these stale bytes, leading to corruption.. 

CVE-2026-109619 is the stale-state case. When a fatal error occurs, PHP fails to clean up properly, leaving a global pointer pointing to memory that has already been freed. Because worker processes handle multiple requests, a subsequent request on the same worker can interact with this freed memory before initialization resets it – resulting in a use-after-free condition. Session upload progress (enabled by default) is a confirmed trigger for this behavior.

Both flaws were discovered through AI-assisted auditing under OpenAI's “Patch the Planet” program. Calif and OpenAI independently reported the root cause to the PHP security team on August 11, 2026, and Wiz reported additional attack vectors on August 24, 2026. PHP first saw signs of the underlying out-of-memory problem during a 2024 audit by OSTIF and Quarkslab, but no exploitation path was proven at the time and the fix stalled. The PHP Foundation has since described that delay as a structural failure in its security process.

On October 20, the two CVE identifiers leaked on social media. PHP released a patch on October 21, 2026.

PHP2SHELL at a Glance

Affected and Fixed PHP Versions

Affected and Fixed PHP Versions

Am I Affected?

Assume exposure for any PHP runtime below the fixed version for its branch. Check the version the web server actually loads, which can differ from the command-line version, using php --version for the CLI and the equivalent for PHP-FPM or the Apache module. Linux distributions and LTS vendors received the patch in advance, and a packaged build may carry the fix under an older version number, so confirm against your vendor's advisory rather than the version string alone.

PHP states that all installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, and rates the risk highest for mod_php. Do not use configuration to rule out exposure. PHP validated mod_php code execution with default input and memory limits, and states that no configuration change is a complete mitigation. OpenAI has published a PHP version checker, which should be reviewed before you run it.

How The Two CVEs Differ

Why This Matters

A flaw in PHP itself reaches far further than a flaw in any one application. PHP is widely used across the internet, and it is embedded in content management systems, control panels such as cPanel and Plesk, and a variety of vendor applications. The hard part of this response is not applying the patch. It is finding every runtime that needs it.

The patch is also the only complete fix, and a large share of PHP cannot receive it. PHP 8.1 and older are at end of life, and Talos estimates from open-source data that around half of internet-facing PHP runs on branches with no official update. Those systems need to be upgraded to a supported branch or taken off the internet, not merely reconfigured.

Exploitation is also hard to see. The memory-disclosure path returns secrets from live worker memory without running code at all, which Wiz notes makes it harder to catch with tools focused on malicious code execution. Because the flaws execute below the application layer, Wiz also reports that application logs may contain little context, and the clearest traces are in web server and PHP error logs rather than in application telemetry.

Attack Chain

Stage 1: Reaching the Flaw Over an Unauthenticated Request

The attacker sends a crafted multipart HTTP request that places PHP's memory under pressure or forces a fatal error during request startup. A chunked or lengthless request slips past the post_max_size check, and empty file controls with deeply nested field names expand a small request body into large internal allocations.

Stage 2: Corrupting Worker State

The forced out-of-memory condition or fatal error interrupts PHP in a context that does not account for the early exit. For CVE-2026-109618, Apache with mod_php runs its request shutdown unconditionally and processes the partially initialized state as if it were valid. For CVE-2026-109619, a global pointer is left referring to freed request memory, and a later request on the same worker consumes it.

Stage 3: Code Execution or Memory Disclosure

With the heap arranged to reclaim the freed or invalid memory with attacker-controlled bytes, the corrupted state becomes a memory-corruption primitive that yields code execution as the web worker. PHP confirmed complete remote code execution against mod_php with default input and memory limits. On a separate path, the attacker instead reads live worker memory and extracts passwords, tokens, API keys, and certificates belonging to other requests, returned through the PHPSESSID response cookie, with no code execution at all.

Stage 4: Post-Exploitation

Code runs with the privileges of the web server worker, commonly www-data. From there, operators drop a web shell into the web root, spawn shells and tooling such as sh, bash, python, curl, and wget, and move laterally using any credentials recovered through memory disclosure.

Hardening Recommendations

These steps apply to any PHP estate, independent of security vendor. Patching is the only complete remediation. Everything else reduces exposure during the window before every runtime is updated.

Patch Every PHP Runtime and Restart Workers

• Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or to the fixed package from your Linux distribution or hosting provider.
• Restart Apache, PHP-FPM, and every long-running PHP worker after updating. The running process keeps the vulnerable code until it is restarted.
• Remember that updating an application, CMS, or framework does not update the PHP runtime beneath it.

Assess Your Exposure

• Inventory every PHP runtime: web servers first, then vendor appliances, Windows software that bundles php.exe or php-cgi.exe, control panels such as cPanel and Plesk, and any WordPress, Drupal, Joomla, or Magento install.
• Isolate end-of-life PHP (8.1 and older) behind a VPN or take it off the internet until it is upgraded to a supported branch.

Apply Interim Settings Only as a Bridge

• For CVE-2026-109618, set memory_limit=-1 administratively so applications cannot override it, and keep post_max_size low. Do not substitute RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable path.
• For CVE-2026-109619, set session.upload_progress.enabled=0, and on PHP 8.5 set fatal_error_backtraces=0, applied before request parsing and followed by a worker restart.
• Treat all of these as partial. PHP confirms there is no complete configuration mitigation, and hiding diagnostics with error_reporting, display_errors, or the @ operator does not help.

Constrain the Request at the Edge

• At the proxy or web application firewall, enforce limits on decoded request size, input field count, multipart part count, header count per part, and nesting depth, including requests that arrive without a usable Content-Length.
• Enable your WAF or reverse proxy vendor's managed rules for PHP2Shell, which several vendors published on October 21, and test first because rules can block legitimate traffic.
• Treat the WAF as a layer, not a fix: Cloudflare saw attackers mutating payloads to bypass its rules.
• If an application does not use multipart form data, block multipart requests to it before they reach PHP.

Limit Worker Reuse and Blast Radius

• Lower PHP-FPM pm.max_requests so workers recycle more often, reducing how long the corrupted state can persist.
• Use a cgroup memory.max as an availability boundary that kills only the affected worker, not the whole pool.
• Apply SELinux or AppArmor policies to restrict what a web worker can execute.

Rotate Secrets Reachable in Process Memory

• Assume any credential, session token, API key, or certificate held by a PHP worker on an exposed, unpatched system may have been disclosed.
• Rotate them now rather than after confirmed compromise, because memory disclosure leaves little trace.

Hunt for Post-Exploitation

• Review the web root for newly created files and web shells, and watch for new cron jobs, scheduled tasks, and accounts.
• Alert on PHP worker processes (php-fpm, php-cgi, httpd, apache2, w3wp) spawning shells, interpreters, or download tools, including cmd.exe and powershell.exe on Windows.
• In web server and PHP error logs, look for unusual multipart requests followed by memory-limit fatal errors or repeated HTTP 500 responses, and for unexplained PHP worker churn (Wiz).
• Check response headers for unexpectedly large or malformed PHPSESSID cookies, which Wiz identifies as a sign of the memory-disclosure path.
• Enable log_errors, a working error_log, and error_reporting=E_ALL in startup configuration for an isolated audit, as PHP recommends, and treat a clean log as supporting evidence rather than proof of safety.
• Treat these signals as leads, not verdicts. They come from public research rather than confirmed attack traffic, and memory-limit errors and HTTP 500s also occur on healthy systems.

How SentinelOne Protects You

PHP2Shell executes inside the web server worker process, below the application. SentinelOne’s visibility begins where that worker runs on a host with the agent installed. The agent cannot see internal application activity which doesn’t interact with the OS or other processes as the memory-disclosure path. What SentinelOne can address is the behavior of the code executed by the attacker.

The Behavior After Exploitation

Code execution through a web server worker process has the worker’s privileges. From there the sequence is familiar. The attacker runs host and user discovery, pulls a second-stage payload with a built-in download utility, writes a web shell into the document root so a fragile memory bug does not have to be triggered twice, opens an outbound connection to attacker infrastructure, and reads application configuration files for database credentials.

Detection on the Host

The Singularity agent builds a storyline of every process group activity on a host, including the web server workers PHP2Shell targets. These workers have a predictable life: they answer HTTP requests. They do not normally start /bin/sh, run reconnaissance commands, download executables into /tmp, write new .php files into the web root, or open outbound connections to arbitrary hosts. Behavioral detection looks for that deviation from the worker’s normal behavior. With the policy mode set to protect, the agent can terminate the process tree and quarantine dropped artifacts. 

Detection in Singularity AI SIEM

Platform detection content looks at what happens on the host after exploitation, not at the request body.

Correlation rules tie these together. An inbound HTTP connection followed by a file drop or process spawn from the same worker is the shape of a successful PHP2Shell chain. 

Visibility at the Edge

The memory-disclosure path never starts a process, so host telemetry alone will not see it. It can leave traces in web server, WAF, and CDN logs: unusual multipart requests followed by memory-limit errors or bursts of HTTP 500s, malformed or oversized PHPSESSID cookies, and unexplained worker churn. Singularity AI SIEM can ingest those sources alongside endpoint data if you forward them. Existing content covers allowed web shell uploads, successful POSTs to server-side scripts that have never received them before, and web shell command execution at the network layer. 

Hunt with Purple AI While You Patch

Patching is the only complete fix, and the Hardening section covers interim settings. While that work runs, analysts can ask Purple AI questions such as:

• Show me web server workers that spawned a shell in the last 72 hours.
• Show me new files written to web roots by php-fpm.
• Show me hosts with a spike in 500 responses followed by a child process from Apache.
• Show me outbound connections from www-data to destinations we have never seen.

The 500-response question depends on web server logs being ingested. 

Confirm Agent Saturation on Web-Facing Servers

Confirm the agent is deployed, healthy, and in protect mode on every server that serves PHP, including internet-facing Linux hosts.

Conclusion

The exploitation picture for PHP2Shell is moving quickly. As of October 21, 2026, no verified proof-of-concept code is available publicly. Attack attempts have been observed by Cloudflare after the leak, but no confirmed in-the-wild compromise has yet been reported. SentinelOne is monitoring PHP2Shell activity and will update this report as exploitation evidence, vendor guidance, and detection content change.

SentinelOne recommends customers follow vendor guidance and prioritize patching as the primary defensive tactic. Interim settings, WAF rules, and detection reduce risk while it is deployed. Update every PHP runtime to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, restart the workers, and confirm the fix is running on the version the web server actually loads. Move PHP 8.1 and older to a supported branch or off the internet, and rotate any secrets that a worker on an unpatched, exposed system could have held in memory.

SentinelOne Black October Webinar

Disclaimer

Information contained herein is current as of October 21, 2026, and is subject to change as patch releases and threat activity evolve. Recipients should not rely solely on this report for security decisions and should consult with their security teams and SentinelOne account representatives for current guidance.

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 turns the noise into specific behavior a detection team can hunt.

"EDR killer," a tool built to shut down endpoint detection and response (EDR), is one phrase doing the work of four different attacks. Detection teams treat it as a single thing and write one rule that catches one technique and misses the other three. The fix is to split the category and hunt each one on its own telemetry.

The four techniques share a goal and little else. Bring-your-own-vulnerable-driver loads a signed but flawed driver and drives kernel termination through it. Bring-your-own-installer abuses a trusted installer or upgrade path to swap the agent out. Admin-to-kernel walks an already-elevated session into Ring 0 through a documented gap. Driverless suspension never touches the kernel and freezes or filters the agent from user space. One detection cannot see all four.

The cost of conflating them is a coverage gap you cannot see. A single driver-load rule looks like coverage for "EDR killers," but the bring-your-own-installer and driverless paths leave no driver-load event at all, so that rule is silent while the agent dies.

Four Techniques, Four Hunts

Each leaves a distinct footprint. Below is the taxonomy and the observable to hunt for each.

Each hunt gets the same treatment: the observable, the telemetry source and event ID, the rule logic in plain terms, and the false-positive consideration. A detection engineer can ship the first one this week, and the rest follow as the baselines clean up.

Hunt One: Bring-your-own-vulnerable-driver

Bring-your-own-vulnerable-driver is the loudest of the four and the first one to instrument. The live LOLDrivers project tracks thousands of vulnerable signed drivers, most reachable without admin rights, a deep supply of signed-but-flawed kernel access with mature, copyable detection logic already in the public domain.

The primary observable is a driver load that does not match a trusted, previously-seen signature. Sysmon Event ID 6 is the core signal, logging each driver load with ImageLoaded, Hashes, Signed, Signature, and SignatureStatus. Any SignatureStatus other than Valid warrants investigation.

Two signature-based detections are worth building directly. The first keys on the driver-load signature status itself: alert on any driver load whose signature status is not Valid, which catches the signature-enforcement bypass and the BYOVD loader chain. The second is a first-seen detection: alert on a driver whose hash, signer, or version has never been seen on the host before, so anomalous drivers surface on first load instead of after the kill.

The false-positive consideration is real. Patch cycles introduce new signers and hashes constantly, and a first-seen rule will flare on legitimate new software. Published detection content that joins Event ID 6 driver loads against a known-bad driver table ships with an explicit false-positive warning. Plan for a tuning period and an allowlist before this rule goes to a 24/7 queue.

The SentinelOne® Annual Threat Report reaches the same conclusion for hunting at scale, urging teams to chase suspicious behavior rather than specific hashes or file names. It names kernel-mode drivers derived from POORTRY used to kill EDR and delete security files, the posture every hunt below adopts.

POORTRY is the canonical signed-driver kill primitive defenders hunt. SentinelLABS traced the STONESTOP loader and the POORTRY kernel driver, which received a process-kill IOCTL to terminate security tools. The driver carried valid WHQL signatures, later revoked under advisory ADV220005. A signed kernel driver issuing process-termination IOCTLs is the behavior this hunt exists to catch.

Know your coverage baseline before you trust prevention to backstop this hunt. The attack surface reduction (ASR) rule blocks a vulnerable signed driver from being written to disk. It does not block a driver already present from loading, so a driver the blocklist policy would block keeps running until reboot and an in-progress kill chain survives policy activation. The CodeIntegrity Operational log Event ID 3099 confirms when the blocklist policy is applied on a host. It does not catch an attack. It tells you whether your driver-blocking policy is live.

Hunt Two: The Kill Chain As a Correlation Target

The strongest version of the loud hunt is the ordered sequence, because a single event tells you far less than the chain it belongs to. Public research documents the full bring-your-own-vulnerable-driver chain and its detection points. It runs as sc.exe service create (Sysmon Event ID 1) plus a service install (System Event 7045), then a driver load at Event ID 6, then a DeviceIoControl device-control call (IOCTL), then callback removal and security-process termination.

Correlating that ordered sequence is far stronger than alerting on any single step. A service create alone is common, and a driver load alone is common. The same two within seconds, followed by an IOCTL to the freshly-loaded driver, is a fingerprint ordinary administration does not produce. Build a windowed sequence rule keyed on the service name to the image path to the device handle.

This chain shows up in real intrusions. Public threat research documents the pattern across named campaigns including Kasseika, BlackByte, and RansomHub. Attackers register a vulnerable driver as a kernel service via sc.exe, name that service to mimic a Windows update, then abuse IOCTLs for kernel primitives. The service-name masquerade is itself a tell. A "KB" service name attached to an unsigned or first-seen driver image is a high-confidence pair, so watch the join between the 7045 service-install name and the Event ID 6 image it loads.

The false-positive profile for the correlation beats the single events by design, because the conjunction is rare even when each part is common. The cost moves from alert volume to engineering effort: you need reliable event ordering and a join key, which means Sysmon tuned to capture both the service and the driver-load fields. Ship this second, after the single Event ID 6 rule is stable.

Hunt Three: Kernel-callback Removal and The Kernel-Originated Kill Loop

Admin-to-kernel needs a different lens, because the kill itself can happen entirely below the EDR's user-mode vantage point. Independent security research argues that admin-to-kernel falls short of a real security boundary and that the driver blocklist is an incomplete defense against it. Once code reaches Ring 0, it can remove the hooks the EDR relies on before it issues a kill.

Callback removal is its own observable, distinct from a process kill, and it deserves its own hunt. SOC Prime documented Qilin loading rwdrv.sys for raw memory read and write alongside a malicious hlpdrv.sys for kernel-callback manipulation, removing EDR kernel callbacks across more than 300 products. The same rwdrv.sys plus hlpdrv.sys pairing appears in Akira and other crews. The observable to instrument is the silent disappearance of kernel callbacks, a loss of expected callback telemetry from the EDR's own integrity reporting.

The termination that follows can run as a kernel-mode loop. The user-mode component enumerates running processes on a repeating, fixed-interval loop and sends the target PIDs to a masquerading kernel-service driver via IOCTL. The driver then calls ZwTerminateProcess in kernel mode, bypassing protected-process light entirely.

The fixed-interval rekill cadence is itself a signature. A user-mode agent that respawns and dies again on a repeating, fixed interval is being killed from below, not crashing on its own. That behavioral fingerprint is what you hunt when the callbacks are already gone.

The false-positive consideration is that this hunt depends on telemetry the attacker is actively trying to remove. Treat callback-integrity loss and the rekill cadence as corroborating signals rather than standalone alerts, paired with the cross-domain witnesses below.

Hunt Four: Bring-your-own-installer and Driverless Suspension

Bring-your-own-installer is the quietest of the four, and it leaves no driver-load event at all. SentinelOne documented this tamper bypass, where an attacker abuses a trusted installer or upgrade path to swap the agent out. SentinelOne shipped Local Upgrade Authorization, default-on for new customers, plus a detection rule and a hunting query against the bypass.

The hunt is an unexpected agent upgrade or reinstall outside a sanctioned change window. Your driver-load rule will never fire, because no vulnerable driver was ever loaded. The rule logic compares each event against a baseline of approved change, so you need a clean inventory of sanctioned upgrade windows and the package signers you deploy. Any agent install, uninstall, or version change outside that window is the finding. This is the hardest false-positive profile of the four, because without that inventory, normal patching drowns the queue. Build the baseline first.

Driverless suspension is the fourth class, and it abuses user-mode tricks that never touch the kernel. EDR-Freeze suspends the EDR process by racing the WerFaultSecure crash handler, entirely in user mode. EDRSilencer uses Windows Filtering Platform (WFP) filters to block EDR telemetry across roughly 16 products. These two leave different observables, so hunt them separately.

For the suspend path, watch for process-suspension state changes against the agent process that no maintenance action requested. For the filter path, watch for new WFP filters that match the agent's known egress destinations and silently drop its outbound telemetry, the EDRSilencer pattern. Legitimate updates and some VPN software touch process state and WFP filters, so scope the rules to the agent's own process and endpoints.

Why These Hunts Must Keep Pace

This work is urgent because the tooling has industrialized. SentinelLABS traced AvNeutralizer, also called AuKill, to the cybercrime gang FIN7, sold on Russian-language forums for $4,000 to $15,000 and adopted by Black Basta, AvosLocker, MedusaLocker, BlackCat, Trigona, and LockBit. That commoditization is the theme of SentinelOne's latest Annual Threat Report, which describes the industrialization of the modern cyber breach with mature automation accelerating intrusions. Public reporting tracked EDRKillShifter, a driver-based killer the RansomHub crew added to its arsenal and offered through an affiliate program, turning a hard kernel technique into a checkbox. Defenders face a market, not a single actor, so the hunts have to generalize across tools.

The Kill Is a Detection Gift

Here is the reframe most teams miss. They read the kill attempt as a defense failure and stop there. Read it instead as a high-confidence signal that ransomware is about to fire.

The Cyber Security Agency of Singapore documents the EDR-killer-then-ransomware sequence across multiple gangs, with the killer firing shortly before the ransomware. The minutes between the kill and the encryption are minutes you can act in. A correlated chain alert or a fixed-interval rekill detection that fires in that window is a live intervention point, not a post-incident artifact. The same advisory frames the whole category this way. EDR-killer activity is detectable via driver-load monitoring, suspicious process-termination patterns, and attempts to disable telemetry, three observables that map cleanly to the four hunts above.

There is a rarer, cleaner signal worth a dedicated rule. Independent researcher Peter M. flagged Windows Event ID 7031, a service that terminated unexpectedly. Scoped to security services, it is an ideal detection candidate, and quiet enough to alert on directly. A forced kernel termination often leaves a crash trail the service control manager records anyway. The kill leaves a fingerprint even when it succeeds.

When the Kill Succeeds nyway

Assume the kill works. You still are not blind. A successful kill produces an absence-of-signal you can alert on directly: agent-health drop, heartbeat loss, and the absence of expected telemetry, all findings alongside your suspicious-event rules. The SentinelOne Annual Threat Report describes one SaaS compromise that ran for 71 days until an automated detection correlated activity a manual review of sign-in logs had missed. Absence-of-signal correlation is exactly the kind of work a human queue rarely sustains alone.

Cross-domain telemetry survives the kill. Once the endpoint sensor is silenced, logging that operates independently of the agent remains as a witness, including network-based detection and cloud-based security monitoring. The attacker can kill the agent on one host. They cannot kill the firewall logs, the identity provider, and the cloud control plane at the same instant, and those sensors still record the lateral movement, credential use, and command-and-control that precede ransomware. Route them into the same hunt so the endpoint blind spot does not become total.

The false-positive consideration for the absence case is the most demanding of all. Absence-of-signal detection requires a reliable baseline of expected heartbeat, or a maintenance reboot looks like an attack. Tie the heartbeat-loss rule to the change-window inventory you built for bring-your-own-installer. A silent agent on a host with no scheduled maintenance, correlated with network or identity activity, is the alert.

Honest Tuning Notes

The order you ship it in decides whether analysts trust it, so sequence the rollout by signal quality. Start with the loud bring-your-own-vulnerable-driver hunt, because Sysmon Event ID 6 is low-volume and the rules already exist. Add the chain correlation next, since correlated sequences cut the false positives single events generate. Save the absence-of-signal and unexpected-upgrade hunts for last, after the baselines clean up. Shipping them out of order floods analysts and teaches them to ignore the alerts.

Retire the Wrong Scoreboard

Stop scoring on "did the kill succeed." Score on "did we catch the kill." Catching it early gives the response team the minutes that decide whether files get encrypted.

Deploy this on Monday. Turn on Sysmon Event ID 6 logging and the untrusted-driver and first-seen rules for the loud class. Build the service-create-to-driver-load-to-termination correlation for the chain. Add a dedicated Event ID 7031 rule and an agent-health heartbeat monitor for the absence case. Wire network, identity, and cloud telemetry into the same view so a silenced sensor is not a silenced investigation.

The shift is from waiting for a verdict to running a hunt. That posture depends on an agent that keeps running and keeps telemetry flowing under attack, so demand the survivability test data before trusting any vendor's claim, ours included.

Why This Is the Work SentinelOne Exists to Do

Running these hunts in the minutes before encryption is where the contest is won, and that window is exactly what SentinelOne built Purple AI® to operate inside. Its Agentic Investigation capability runs the kind of zero-click investigation these hunts describe. It correlates the driver load, the service install, the callback removal, and the silence that follows, then renders a verdict and a response at machine speed. The kill attempt becomes the trigger, and the investigation is already running while the attacker still believes the sensor is blind.

Most security teams cannot run four hunts around the clock, and the attacker knows which hours are thin. Wayfinder, SentinelOne's managed detection and response practice, runs them for you, putting human hunters and autonomous investigation on the same telemetry every hour of every day. The kill is the middle of the story, and the platform is built to catch it there.

Step back across the whole series. It traced the EDR killer through four moves. A market with a price list. An industry with suppliers and resale. The trust gap it operates inside. And the hunts that catch it. One idea held the whole way through. A defender who watches behavior beats one who chases the binary of the week. Attackers turned the kill into a product. The answer is the one move a supplier cannot re-skin. It is the reach into the kernel to terminate what defends the host. Defenders are the protagonists of that story, and the platform exists to keep them there. A safer future for humanity is built by the people who refuse to look away when the kernel turns hostile.

External References

1. "LOLDrivers: Living Off The Land Drivers." loldrivers.io, retrieved 2026-06-26.
2. "Sysmon Community Guide: Driver Loading." TrustedSec, n.d.
3. "Qilin EDR Killer: Driver Abuse to Terminate 300+ Tools." SOC Prime, 2026-04-07.
4. "GRITREP: Observed Malicious Driver Use Associated with Akira SonicWall Campaign." GuidePoint Security (GRIT), 2025-08-05.
5. "EDR-killer driven by a decade-old vulnerable forensic driver." Help Net Security, 2026-02-05.
6. "New EDR-Freeze tool uses Windows WER to suspend security software." BleepingComputer, 2025-09-22.
7. "EDRSilencer." netero1010, GitHub repository, retrieved 2026-06-26.
8. "EDRSilencer red team tool used in attacks to bypass security." BleepingComputer, 2024-10-15.
9. "EDR-killing malware is the latest trend in ransomware." The Register, 2025-08-14.
10. "RansomHub gang developed a tool to kill EDR software." Security Affairs, 2024-08-15.
11. "Advisory on New Endpoint Detection and Response (EDR) Killer Tool Used by Multiple Ransomware Groups." Cyber Security Agency of Singapore, 2025-08-16.
12. "Investigating & Detecting EDR Killer." Peter M., Medium, 2025-11-19.

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.

For five years, SentinelOne™’s ThreatOps has inspired a global defender movement. What began in 2020 as a threat hunting webinar has grown into an industrial-scale gamified platform that has trained over 19,000 blue teamers, influenced over $661 million in closed-won revenue (September 2023–September 2026), and spawned the Sentinels League Threat Hunting World Championship.

As we mark five years of ThreatOps innovation, defenders worldwide are gearing up for the ultimate showcase: the Sentinels League Grand Final, hosted live on stage at OneCon 2026 in Las Vegas from October 20–22, 2026.

The Evolution of ThreatOps

The origin of ThreatOps dates back to April 2020, when Solutions Engineer (SE) Director Ryan Merrick launched a two-hour threat hunting webinar covering MITRE ATT&CK concepts, indicators of compromise (IOCs), and the distinction between hunting and searching. While educational, the team recognized that defenders needed hands-on experience interacting with real product telemetry.

In May of 2020, SE Joseph Poyner sketched a vision in a team chat channel: standing up a Capture the Flag (CTF) game that would walk players through the product, requiring them to search deep visibility telemetry for malicious process connections to find hidden flags. 

With the support and guidance of SE leaders Tommy Hui, Dave Gold, Keith Weisman, and Jared Phipps, the team secured a dedicated CTF line item in the FY21 budget, turning a side project into an official initiative. That initial sketch defined the exact game format ThreatOps still runs today. By August 2020, the team had stood up a dedicated console and created a parallel ransomware workshop track. 

The first live game ran in October 2020 for SentinelOne's product management team, followed by the first customer workshop in EMEA. Rapid scaling and industrialization soon followed:

• Public Challenges and Accreditation (2021): In March 2021, ThreatOps launched its first public challenge featuring cash prizes, expanding across named accounts, partner channels, and UK regional teams.
• Industrialization & Platform (2022): PJ Norris built a game-creator program to train SEs globally while securing CPE accreditation. At the same time, Brian Martin created a platform to automate game provisioning, data replays, and self-service registration. This new platform reduced workshop setup times from two days to under five minutes.
• Hackathon (2023) & Content Editor: In September 2023, the team met for the first ThreatOps Hackathon in Detroit, Michigan, where SEs spent a week building content, including the new Purple AI game (featuring GLaDOS). Shortly thereafter, Ryan O’Grady built a new game editor that streamlined the process for creating and publishing new game content.
• Multi-Surface & AI Expansion (2024–2025): The program expanded into every surface SentinelOne ships, including a new SDL Deep Dive game, Cloud Security, the Need for Speed-themed Hyperautomation game featuring live API interactions, and the Data Pipelines games. These games were made possible by collaboration with SE champions, including John Pease and Marco Rottigni.

Through continuous craft and automation, ThreatOps transformed threat hunting from a manual class into an enterprise-grade operational standard.

Enterprise Protection and $661M+ Revenue

The impact of ThreatOps shows up in two places: the number of defenders it has trained and the revenue it has influenced.

Empowering 19,000+ Global Defenders

What started as an internal workshop has grown into a massive global educational engine. Between September 2023 to September 2026, ThreatOps has built and deployed 5,215 game instances across 9 unique game types, generating a total of 27,899 player seats and reaching 19,211 unique players across 5,869 email domains.

The program's core audience is overwhelmingly enterprise-focused, with 87.4% corporate participation representing over 16,700 unique corporate defenders. Practitioners from world-class organizations regularly refine their skills in ThreatOps competitions, including teams from Orange and Orange Cyberdefense, Exclusive Networks, Cloud4C, GoDaddy and many more. This global footprint is sustained by an active internal community of 407 game owners.

$661.8M+ Closed-Won Revenue Influence

Beyond skill development, interactive threat hunting has become one of SentinelOne's most potent catalysts for customer acquisition and technical evaluation. Our analysis reveals that ThreatOps engagements have influenced $661.8 million in closed-won revenue across 6,435 deals and 1,538 corporate accounts (Sept 2023–Sept 2026).

The data points to a clear correlation between ThreatOps participation and commercial success. Opportunities where prospective accounts engaged in a ThreatOps game saw a 3.7x higher mean deal value, averaging $103,000 per closed-won deal compared to $28,000 for non-participating accounts. 

This commercial lift is driven by strategic timing: 80.4% of games execute mid-cycle while sales opportunities are actively open, serving as a decisive technical proof point during active Proof of Concept (POC) and Proof of Value (POV) evaluations.

The Sentinels League World Championship

In August 2025, Steve Regini, SVP of Global Solutions Engineering, and theater leadership (Keith Weisman, Amit Sabharwal, Lloyd Webb, and Wayne Phillips) approved turning ThreatOps’ game cadence into a global tournament: the Sentinels League Threat Hunting World Championship.

Presented in partnership with Dropzone AI, Google Cloud, and Mimecast, the Sentinels League features a $100,000 prize pool. Defenders compete across four critical attack surfaces in 30-minute CTF qualifiers: Endpoint, Cloud, AI Security, and Autonomous SOC. Prizes are awarded at every stage: qualifier winners earn cash, regional semifinal winners take home $3,000 and a trip to the Grand Final, other semifinal placers are rewarded too, and the top three finishers in the Grand Final all win prizes.

• Season 1 (2025): At OneCon 2025 in Las Vegas, Derek Render of ProCircular was crowned the first Threat Hunting World Champion, alongside runners-up Arnau Osso (T-Systems) and Ethan Chew (Intfinity).
• Season 2 (2026): Season 2 expanded to 49 qualifiers worldwide. It was led by Ryan O’Grady (Director of SE Operations) and Andy Wool (Senior Marketing Manager), with major contributions from PJ Norris (Lead Technical Enablement Manager) and Michael Logan (Senior Solutions Engineer).

Catch the Grand Final Live at OneCon 2026 in Las Vegas!

After months of regional competition, three elite regional champions have earned an all-expenses-paid trip to Las Vegas for the Grand Final:

• John Paul Lonie, aka “grumpycat” (Iress)
• Jodie McDonald, aka “jodie” (LevelBlue)
• Jason Walker, aka “tresscross” (Five9)

These three finalists, each of whom has already won $3,000 as a regional winner, will compete live on stage at OneCon 2026 for the $5,000 grand prize, the World Champion trophy, and a matching charitable donation made through the S Foundation.

Experience OneCon 2026: October 20–22, 2026

OneCon 2026 is SentinelOne's premier annual cybersecurity conference in Las Vegas. Beyond witnessing the Grand Final live, attendees will experience:

• Visionary Keynotes: Exploring AI-driven defense and autonomous cybersecurity.
• The OneCon Expo: Live technology demos and direct interaction with SentinelOne experts.
• Special Advisory Panels: Exclusive Customer and Partner Advisory Board sessions featuring unfiltered industry insights.
• OneCon After Dark: Evening networking at Jason Aldean's Kitchen + Bar featuring live music, dinner, and drinks.

Register Today!

Five years after a single wild idea, ThreatOps has elevated threat hunting for tens of thousands of defenders worldwide. Be there live in Las Vegas when the 2026 World Champion is crowned! Visit onecon.io to explore the full agenda.

The Endpoint: Why AI Must Be Governed By Something It Cannot Reach

This morning NVIDIA announced the NVIDIA Open Agent Safety Platform, with SentinelOne named as key collaborator. This new initiative is directly aligned with what I firmly believe is the key to effective security and governance of AI. It’s also what I believe will be required to truly secure an AI powered world. 

Every guardrail that exists today lives in software the model itself can reach.

The problem is simple to state and hard to solve. Models are aligned once and then run non-deterministically thereafter, increasingly at the endpoint and increasingly with the authority to act: in vehicles, industrial systems, humanoid robots, and agents with access to enterprise systems. Model alignment is checked before release, but nothing independently monitors the system at runtime.

Last week showed the risks. An AI agent in training at a frontier lab bypassed its network restrictions. Monitoring flagged it within 15 minutes. The automated kill switch failed, and it took two and a half hours to stop the run by hand. Watching is not enough if nothing independent can act.

An organization cannot reliably delegate consequential work to an agent without knowing what it is doing, whose authority it is exercising, and whether the boundaries around that authority actually hold. Those assurances require foundations throughout the infrastructure. One cannot depend solely on a model following instructions.

Out of the Model's Reach

Security has had a standard for this problem since 1972, when James P. Anderson's study for the U.S. Air Force defined the reference monitor. The mechanism that enforces policy must be tamperproof, must always be invoked, and must be small enough to verify. It remains the gold standard for enforcement architecture. A guardrail the model can reach fails the first test by definition. NVIDIA's own security engineers noted: "A control that the agent can decline to invoke is not an effective security control."

AI requires the same standard. A model must be governed by a layer that is separate from the intelligence it supervises and unreachable by it: one that runs in real time alongside the model and its compute, and that produces cryptographically attestable evidence of runtime behavior which operators, regulators, and insurers can independently verify.

A Foundation In Hardware

Today's announcement of NVIDIA's Open Agent Safety Platform is an important step toward the computing foundations that enterprise AI needs. Of its capabilities, hardware isolation and attestation are the most consequential. How the industry uses them, and what it builds on them, will determine their value.

The conviction behind this announcement is one I share with Jensen Huang: AI changes what the computing stack must provide for its behavior to be trustworthy. That requires a clear connection between the agent runtime and the protected infrastructure beneath it, in a cohesive stack where visibility and enforceable control underpin AI execution.

SentinelOne is committed to security rooted in hardware. NVIDIA's BlueField-4 places enforcement outside the host operating system, where tenant software cannot disable or bypass it. Together with other secure enclave architectures, it provides a way to secure the runtime directly from the hardware and to reduce the surface that must be secured to the hardware boundary itself. It also consolidates the cybersecurity stack: network, identity, data into the endpoint.

This is another step, and substantial work remains to build a truly secure architecture. The hardware boundary must itself be soundly secure, particularly where real-world applications are unforgiving. It must hold across deployment environments: enterprises and governments will use frontier AI services alongside workloads that must remain local, and their authority over data and actions must survive those transitions. And it must extend to any AI, on any compute that supports it.

The objective is clear. Anything that runs on a truly secure, hardware-rooted compute architecture should be provably governed, in the physical world and the digital one. Achieving that must also be simple, intuitive, and transparent to the end user. No one should need to understand attestation in order to benefit from it.

Verifiability

The broader question is how to govern action when agency is distributed across humans and machines. That comes down to six requirements.

• If a system cannot act in time, it does not matter. 
• If it cannot show the evidence behind its actions, it cannot be trusted. 
• If it cannot act independently when required, it cannot defend. 
• If it cannot stay within boundaries, it cannot be governed. 
• If its actions cannot be attributed, authority disappears. 
• And if accountability is lost, control is an illusion. That is ‘verifiable agency’.

What makes these requirements achievable is continuous behavioral visibility: the ability to observe, understand, and verify how actions are being taken across humans and machines in real time. 

SentinelOne was founded more than a decade ago on the conviction that behavior is the decisive signal, the only reliable way to distinguish the benign from the malicious at machine speed. Our behavioral AI is deployed at global scale today, protecting nearly one-fifth of the Fortune 500, and we are extending the same principle to make autonomous action verifiable, governable, and trustworthy.

In practice, this means AI operates at machine speed while every autonomous action remains traceable, auditable, and overridable by a human. AI provides scale, speed, and pattern recognition. Humans provide judgment, context, and the values these systems are expected to uphold. The arrangement is as much a matter of accountability as of engineering.

Certifiable and Insurable

Regulation, standards, and insurance are converging on the same requirement. Regulators will expect evidence of how AI systems behave at runtime, not only how they were aligned before release. Standards bodies will need a common basis for defining and measuring that behavior. Insurers will price risk against it. Attestation is the evidence all three will depend on. Within a few years, an AI product without attested runtime governance will be difficult to certify and difficult to insure, and more so for physical AI.

Building these foundations is the work SentinelOne is committed to. It will take sustained research and engineering across the stack, with claims of trust grounded in demonstrable behavior.

I congratulate the NVIDIA team. This is a meaningful commitment and an important milestone toward making increasingly capable AI truly governable, and toward making organizations willing to entrust it with work that matters.

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.

The loudest prediction about AI in the SOC runs like this. Give a team agentic investigation, and it stops needing analysts. Give it auto-investigation, and it stops needing a managed service. Both conclusions get the technology backward. Agentic investigation is a new component of security operations your team has never had. It does work no team could staff, at a scale no team could reach. In the model it creates, the analyst and the expert take on bigger roles. Both move up.

Think of it as the shift your SOC could never staff. People work finite hours, and they sleep. The alerts that pile up overnight have always been unstaffed risk. Agentic investigation is the coverage that never clocks out. This is a new operating model for the SOC. It has three layers, and they work as one. The single-analyst SOC, where one overwhelmed person is the last line before a breach, is ending. What replaces it covers more ground than any roster could staff.

The Shift That Never Sleeps

Every SOC runs on a hard limit. Signal is effectively infinite. Human attention is not. Analysts have finite hours, and they sleep at night. So a large share of alerts are never investigated at all. According to 451 Research’s Voice of the Enterprise report, nearly half of SOC teams can’t investigate more than half their daily alerts (451 Research's Voice of the Enterprise: Information Security, SecOps 2024 (n=243), as cited in the S&P Global Market Intelligence / 451 Research Vanguard Report "Agentic AI in SecOps," April 2025 (commissioned by SentinelOne®).

That untouched queue was never safe. It was silent risk acceptance, priced in because no one had the hours to pay it down. Every alert nobody opened was a bet that it did not matter, and sometimes that bet was wrong. That backlog is exactly where agentic investigation earns its place. It works the alerts your team never reached. It enriches, correlates, and resolves the low-priority signal that used to age out on its own. This is the coverage the SOC could never staff, running while the building is dark.

Jared Atkinson mapped this in 2019. His Funnel of Fidelity, published at SpecterOps, frames the SOC as narrowing stages, from collection and detection through triage, investigation, and response. Two of its principles govern everything here. The widest cut happens first, on the alerts nobody has context for yet. Cost per item rises as volume falls, so the expensive humans sit at the narrow end, and everything upstream is a fight to protect their attention. Agentic investigation joins that fight and never tires. It reads the raw, low-context signal at volume, and forwards only what earns a human's time.

The timing matters, because the adversary already moved to this speed. SentinelOne's latest Annual Threat Report and Defender's Playbook describes attackers using "automation, polymorphism and AI-assisted tooling" to compress "response windows" and erode "the effectiveness of purely manual detection and investigation." The report is blunt about where the fight now happens. "Much of the meaningful contest now takes place inside the systems organizations rely on every day." A queue you cannot reach is a queue the adversary counts on.

One caution keeps this honest. Speed on a bad alert is still a bad outcome. An agent that auto-closes a real incident hides the miss inside a metric that looks healthy. The control is straightforward. Sample the alerts the agents close, re-review them, and publish the miss rate. Keep every verdict on a replayable record, so a decision made today survives an audit tomorrow. Governance is what turns machine-speed autonomy into something a leader can trust.

The Day Shift Gets a Promotion

Absorbing the dropped queue does something to the humans, too. It clears the mundane work that consumed them. Triage, correlation, and context-gathering were never the point of the job. They were the tax on it.

Clear that tax, and a different analyst becomes possible. This is the jump the legacy SOC never had room to make. The analyst becomes an operator who oversees AI agents. The human moves from sorting alerts to directing outcomes. The people who used to burn out covering impossible hours now run a day shift built on judgment.

That role runs on judgment the machine cannot supply. The AI lacks the context to weigh business impact. It cannot reason about a thinking adversary. It cannot make the inference call when the evidence points two ways at once. AI verdicts also drift over time, and attacker-controlled log fields can try to talk an agent into the wrong call. Those limits are exactly why a human governs the record and owns the judgment. That work is the highest-value work in the SOC.

Picture the operator's day. Agents open, enrich, and close the routine cases in the background. The human reviews the handful that carry real ambiguity. The human tunes the logic that manufactures downstream noise. The human hunts the adversary the rules have not caught yet. One person now covers ground that used to need a full tier, and effectiveness rises without the workload rising with it.

This is Human Amplification, one of the three pillars of Autonomous Security Intelligence (ASI). AI that elevates human teams. Security teams should invest time directing outcomes rather than managing noise. Purple AI™ runs the guided investigation, AI SIEM provides the correlation, and together it elevates analysts from operators to strategic decision-makers. More impact per analyst and greater control with less fatigue.

SentinelOne made this case in "The Autonomous SOC, Revisited". Autonomy is a journey the team travels over time, one governed step after another. Every assisted workflow is building toward what comes next. Analysts gain the advantage by governing the conditions, the way a pilot governs a flight rather than adjusting every control surface by hand. Control over the right decisions is what matters.

The Specialist You Page

The third layer answers a problem no amount of automation solves on its own. Most organizations cannot afford a standing bench of seasoned threat hunters and senior responders. That talent is scarce, expensive, and hard to retain. When an incident goes deep, an in-house team can run out of depth before the adversary runs out of moves.

Speed makes that gap urgent. SentinelOne's latest Annual Threat Report and Defender's Playbook documents a ransomware crew executing a high-density data theft in 19 minutes. An incident that finishes in minutes does not wait for you to hire the right expert.

A managed service is the specialist you page for exactly that moment. SentinelOne Wayfinder Managed Services amplifies teams with experienced security analysts. It provides the human-in-the-loop advantage for the incidents that exceed your bench. It goes several levels deeper than most teams can reach, and it bursts beyond your current capability on demand.

These experts run on the same AI your team does. They move faster because the platform clears their mundane work, too. So the depth you escalate to arrives fast, backed by people who hunt adversaries for a living. You get a stable of senior talent without carrying it on your payroll.

For a growing business, that math decides whether the SOC scales or stalls. You cannot hire your way to round-the-clock senior coverage. You can subscribe to it. The burst line turns a capability you could never build into one you can call on the day an intrusion outruns your team.

The Three Layers as One Model

Put the three together and the shape of the new SOC appears. The always-on shift (via Purple AI Auto-Investigation) works the queue that used to age out untouched. Your evolved operators govern the agents and own the judgment calls. SentinelOne Wayfinder Managed Services bursts beyond your ceiling when an incident demands it. Each layer covers a gap the others cannot. This is the operating model: who does the work, and where.

Lay the model over Atkinson's funnel and the fit is clean. The always-on shift works the wide, noisy top. Your operators own the narrow middle, where leads become judgment. The Wayfinder managed experts you call in handle the deepest, rarest cases at the bottom. AI widens the funnel's throughput without widening anyone's hours.

Under the operating model runs one technology stack, and it has a working equation. Purple AI, plus AI SIEM, plus Hyperautomation, equals Autonomous Security Intelligence. Where the three layers describe who does the work, these three describe what powers it, and each one reaches across all three layers rather than owning any single one. AI SIEM is the single data foundation, the intelligence fabric every layer reads from. Purple AI is the investigation reasoning each layer wields, whether an agent runs it unattended, an operator directs it, or a Wayfinder expert takes it deep. Hyper Automation is the execution at machine speed that works the queue while the building is dark and carries a verdict to response. Three parts, one core, powering all three layers.

That shared core is what lets the layers act as one. An incident passes cleanly from agent to analyst to expert, with full context intact at every handoff, because all three read from the same foundation and run the same intelligence. Stitched-together tools break that handoff. ASI is how SentinelOne operationalizes AI across the entire security lifecycle. Built on. Not bolted on. It is the foundation of the entire platform. It combines human-level reasoning with agentic workflows to filter noise and drive outcomes at scale.

The payoff is measurable, and it is what a board wants to see. In SentinelOne's business-value research, teams identify threats 63% faster and resolve them 55% faster, and report a 60% lower likelihood of a major security event. That is what it means to Maximize Efficiency and Effectiveness of Security Operations. Security operations scale without a matching rise in headcount, tooling, or cost. Analysts spend their hours on the decisions that move risk, while routine triage runs itself. The SOC stops reading as a cost center that only grows. It starts reading as an operating advantage that compounds.

The through-line is control. As "The Autonomous SOC, Revisited" put it, governance precedes autonomy. What security leaders want is relevant control, governance over the decisions that matter, without being burdened by the ones that do not. Machines handle protection at scale. Humans provide judgment and direction. That balance is the model.

The Verdict

Here is the line to carry out of the noise about AI replacing the SOC. Agentic investigation makes a different analyst possible, the one who operates on judgment, adversary reasoning, and business impact. It builds the backstop the legacy model never had, and it hands the mundane work to a machine that never sleeps.

This is the new model for the SOC. The night shift never sleeps. The day shift works on judgment. The specialist is a page away. Three layers, one platform, humans in command. It exists to give the advantage to those who secure our future. A safer future for humanity depends on defenders who can finally operate above the noise.

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.

The consumer data broker Radaris.com has long had a reputation for ignoring requests to remove personal information from its vast empire of people-search services online. That reputation caught up with the company recently in a lawsuit alleging Radaris violated a New Jersey privacy law that provides for hefty fines against data brokers that publish personal information on state law enforcement officials. In the face of repeated stonewalling and prevarication by attorneys for Radaris, the judge in the case ordered that radaris.com and more than a dozen other data broker domains be transferred to the plaintiffs.

The radaris.com website, prior to the domain transfer to Atlas.

In February 2024, Radaris was sued by Atlas Data Privacy Corp, a company that has been pursuing data brokers alleged to be violating a New Jersey statute called Daniel’s Law. The statute allows state law enforcement officials, government personnel, judges and their families to have their information completely removed from commercial data brokers and people-search services, and provides for fines of $1,000 per violation against companies that ignore removal requests.

Less than a month after Atlas sued Radaris, KrebsOnSecurity published a deep dive into the Radaris co-founders — Igor and Dmitry Lubarsky (also spelled Lybarsky) — Russian-born brothers living in Massachusetts who operate a dizzying array of people-search companies as well as a number of Russian language dating services and affiliate programs.

Attorneys for the Lubarsky brothers threatened to sue for defamation if the story wasn’t removed and an apology issued. Their attorney asserted that our reporting was wildly inaccurate, and that the true owners of the company were Ukrainians living in Ukraine.

The Lubarsky brothers Dmitry or “Dan” (left) and Gary/Igor.

KrebsOnSecurity doubled down and showed how the Lubarsky brothers built and operated Radaris and other data broker companies using a fictitious CEO’s name. Our follow-up story noted that Radaris’s attorney — a lawyer with the Boston Law Group named Val Gurvits — admitted his clients had invented the CEO pseudonym “Gary Norden,” and that Radaris also had issued multiple press releases over the years that quoted the fake CEO while seeking money from potential investors.

Attorneys for Radaris waited until the last minute to appear in court and contest what was all but certain to be a default judgment in favor of the plaintiffs, and then told the court that Atlas had failed to serve the real owners and operators of Radaris and several of its sister data broker companies.

Atlas re-filed the lawsuit in June 2025, this time dramatically expanding the number of Radaris family data brokers accused of violating Daniel’s Law. Matt Adkisson, president and CEO of Atlas, said Radaris turned to a tried-and-true playbook: Delaying in court until the last possible minute, and playing shell games with Radaris’s true country of origin and the individuals listed as owners and operators of these sites.

“We refer to this period as their island-hopping phase. Privacy policies changed constantly, and new entities kept appearing from places like the Marshall Islands, the British Virgin Islands, and Seychelles,” Adkisson told KrebsOnSecurity. “Behind the scenes, it felt like a shell game. Defense lawyers told the court that certain entities merely operated the domains and were the proper parties to sue. But by the time a judgment neared, those entities would be discarded and new entities would appear. Meanwhile, the lawyers claimed the other entities that actually owned the domains should not be held responsible.”

Adkisson said when the defendants updated their terms of service to state that Radaris was suddenly managed by a company in the Marshall Islands, Atlas hired an investigator in that country and soon learned the brand new entity that Radaris claimed was managing the company didn’t even exist yet.

Mr. Gurvits stepped forward as Radaris’s attorney in a class action lawsuit the company temporarily lost in 2017 because it never contested the claim in court. When the plaintiffs told the judge they couldn’t collect on the $7.5 million default judgment, the court ordered the domain registry Verisign to transfer the radaris.com domain name to the plaintiffs.

Mr. Gurvits appealed that verdict, arguing the lawsuit hadn’t named the actual owners of the Radaris domain name — a Cyprus company called Bitseller Expert Limited — and thus taking the domain away would be a violation of their due process rights.

The judge in the 2017 case ruled in Radaris’ favor — halting the domain transfer — and told the plaintiffs they could refile their complaint. Soon after, the operator of Radaris changed from Bitseller to Andtop Company, an entity formed (PDF) in the Marshall Islands in Oct. 2020. The plaintiffs never re-filed their lawsuit.

A mind map of various entities tied to Radaris and the company’s co-founders. Click to enlarge.

“That seemed to be their modus operandi,” said Raj Parikh, a partner at PEM Law in New Jersey who handles most of the Daniel’s Law litigation for Atlas. “In the past, they won by attrition. Plaintiffs’ attorneys tired of the procedural games and just gave up. That strategy worked for a decade, and it probably would have worked in this case too, since any financial recovery from foreign actors will be difficult. But we were acutely aware of the threat this website posed to law enforcement officers and other public officials in New Jersey, and decided early on to commit whatever time and resources were necessary to remove that threat.”

On August 26, the judge in the New Jersey case found the defendants were given multiple chances to appear and defend the claims against them but had failed to do so. Mr. Gurvits declined to comment on the case, saying it had been assigned to another attorney, a Mr. Victor Worms. In response to questions, Mr. Worms asserted the New Jersey court transferred Radaris.com to Atlas as part of a default judgment against Radaris.com, which is not a legal entity.

“We have made a motion to vacate that default judgment on the grounds that it is void since a non-entity has no legal capacity to sue or be sued,” Worms replied. “We also intend to pursue all appropriate appeals because we believe the transfer of Radaris.com amounts to a forfeiture in violation of various constitutional principles.”

While radaris.com still comes up prominently in results when searching online for U.S. residents by name, the domain no longer sells detailed personal dossiers on millions of Americans. Its homepage now displays a notice from Atlas, as well as links to our previous reporting on Radaris.

EMAIL CONFIRMATIONS

Atlas told KrebsOnSecurity that it has obtained more than 10,000 emails and documents in the course of litigation, and that those messages confirm our previous reporting on the owners and operators of Radaris and its myriad companies.

Atlas said the emails clearly establish that the nominal legal vehicles — Radaris America, Inc.; Bitseller Expert Limited; Digital Orbit Corp; Core Solutions Group Inc; Lucky Solutions Inc; Virtura Corp; Veripages Inc.; Nuform Solutions Inc.; Growth Data Advisors Inc.; Property Experts, Inc — are all administered by the same three or four people from the same mailboxes, share one bank or payment card set, and are all managed from one virtual office address.

“The corpus establishes, with documentary evidence generated independently by banks, payment processors, hosting providers, registrars, software-as-a-service vendors and the operators’ own systems, that radaris.com and at least twenty-five other people-search websites are one operation run by a small Boston-area group whose administrative, financial and technical functions sit on the difive.com mail domain and its successors (centerex.com, scienteco.com, eprofit.com, realmo.com, pub360.com),” reads a summary shared by Atlas.

Atlas said the emails show Radaris.com earns approximately $42,000 a month, while Veripages.com earns around $45,000 monthly via its partnership with the Lifetime Value Company, a marketing and advertising firm whose brands include PeopleLooker, PeopleSmart, NumberGuru, and Bumper, a car history site.

According to Atlas, the emails also showed the Radaris family of websites earns as much as $25,000 each month from their partnership with Onerep, a company that claims to help people remove their information from people-search sites. In March 2024, KrebsOnSecurity revealed how the Belarusian founder of Onerep had launched and operated dozens of people-search sites over the years and was continuing to operate one of them (Nuwber), effectively spreading the disease and selling the cure.

The domain radaris.com now redirects to this notice from Atlas about the court-ordered domain transfer.

All told, the New Jersey court has so far transferred 14 domain names from the Radaris family of companies to Atlas. Radaris.com now redirects to a notice of the court-ordered domain transfer.

THE ROAD AHEAD

The Radaris family of companies is still potentially facing fines of $1,000 per alleged violation of Daniel’s Law. For the time being, however, Daniel’s Law is facing a constitutional challenge from virtually all of the 150 other consumer data broker firms being sued by Atlas.

The data broker industry responded by having at least 70 of the Atlas lawsuits moved to federal court, challenging the New Jersey statute as overly broad and a violation of the First Amendment. The U.S. Court of Appeals for the Third Circuit has not yet issued a decision on the constitutional challenge, but either way the case is widely expected to be appealed all the way to the U.S. Supreme Court.

Meanwhile, at least 14 other states have now passed laws modeled after the New Jersey statute, with more states considering similar measures. However, West Virginia’s Daniel’s Law was ruled facially unconstitutional under the First Amendment by a federal district court in August 2025.

Justin Sherman is a privacy expert and author of the forthcoming book “The Middlemen,” which examines how the data broker industry powers modern surveillance. Sherman said federal lawmakers have long faced intense lobbying by the technology industry against more restrictive U.S. data privacy laws, but that many powerful industries are now working against passing comprehensive data privacy legislation.

“These days at the federal level, add in the intense amount of lobbying against these laws from social media companies, big tech, cryptocurrency firms, and now AI proponents in the mix who claim that limiting their data scraping is somehow going to collapse the whole U.S. economy under Chinese rule,” he said.

Sherman said people-search companies will continue to thrive unless and until Congress enacts meaningful consumer privacy and data protection laws that are relevant to life in the 21st century. That’s because virtually all state privacy laws exempt records that might be considered “public” or “government” documents, including voting registries, property filings, marriage certificates, motor vehicle records, criminal records, court documents, death records, professional licenses, bankruptcy filings, and more.

At least 25 states have passed or implemented laws requiring age verification for residents seeking to access adult content online, but there is no federal law that limits how the companies that are scanning everyone’s drivers license can use, share or keep the data provided. Had such restrictions been enshrined in law, we may have avoided the recent breach at IDScan.net, which exposed the drivers license information on more than 153 million Americans when the records were briefly turned into a point-and-click identity theft service on the dark web.

“The average person can look at Daniel’s Law and have a perfectly normal reaction, which is that everyone should be covered, not just police and judges,” Sherman said. “But we don’t need more wake-up calls. We’ve had eight million wake-up calls already on the need for better privacy laws. The lack of comprehensive federal privacy law is not for a lack of knowledge, and anyone claiming otherwise is either not reading the news or kidding themselves.”

A joint Tenable-SentinelOne analysis of 93 CVE-actor attribution pairs reveals that both state-sponsored actors and cybercriminals independently converge on the same edge infrastructure.

It is the shared attack surface where state-sponsored threat actors and financially motivated criminal groups independently converge — not the province of a single adversary category, and not exclusively a nation-state problem, despite two years of headlines about China-nexus actors targeting Ivanti, Fortinet, and Palo Alto Networks. The data here tells a different and much broader story. One focused on vendors vs CVEs.

Key Takeaways

• Two independent observation systems, Tenable exposure telemetry across thousands of customer containers and SentinelOne DFIR casework across 66 CVEs, converge 79% on the same vendor attack surfaces despite minimal CVE-level overlap.
• Twelve CVEs in the combined dataset have confirmed multi-nexus attribution: state-sponsored and criminal actors independently exploiting the same vulnerability, across five nexus categories (China, Russia, DPRK, Iran, ransomware).
• The exposure picture is flatter than the headlines suggest: Fortinet, the vendor most associated with edge-device attacks in the press, sits mid-pack on container-grain exposure (25%) — well behind F5 (54%) and in a tight 10-point band with Check Point, Ivanti, and Citrix.
• 54% of customer environments running F5 products have at least one exposed, actively-exploited CVE; Citrix customers show the slowest remediation patterns at 461 days median time to patch.
• Remediation complexity, particularly of high priority CVEs, leads to a statistically significant 24-day remediation gap, leaving large windows of opportunity for attackers.
• The same product lines get hit again and again: Ivanti EPMM and Ivanti Connect Secure each show a newly exploited CVE roughly every 8.5 to 13 months.
• Leverage multiple defense-in-depth strategies: patch as quickly as possible, but also minimize the attack surface (feature-set minimization) and run endpoints in protect mode to better stop lateral movement from attacks that gain initial access.

The Convergence is the Story

Twelve CVEs in the combined dataset have confirmed multi-nexus attribution: state-sponsored and criminal actors independently exploiting the same vulnerability, across five nexus categories. Four examples illustrate the pattern:

The remaining eight confirmed multi-nexus CVEs span Fortinet, Citrix, Cisco, and Ivanti product lines. State-sponsored actors and ransomware operators are not operating in separate vulnerability ecosystems. They share the same entry points into the same products. The breadth of the convergence, not any single actor’s activity, is the finding.

That pattern holds across the full combined analysis. Three conclusions emerge:

Vendor attack surfaces are the persistent exploitation target. The same eleven vendors (i.e., Fortinet, Citrix, Ivanti, Palo Alto Networks, Cisco, Juniper, VMware, Microsoft, Oracle, CrushFTP, and Meta’s React framework) appear in both observation systems at 79% convergence, and all seven edge-product vendors converge. Serial exploitation timing on Ivanti products shows the vulnerability-to-exploitation pipeline refreshing at 8.5 to 13-month intervals on the same product lines. This is structural, not episodic. Patching the current CVE does not remove the vendor attack surface from the threat landscape.

State-sponsored and ransomware actors converge structurally. Twelve CVEs with confirmed multi-nexus attribution span all five nexus categories and cross the state-criminal divide. Defending against one actor category on edge devices necessarily requires defending against all of them, because the attack surface is shared. An organization that patches only for nation-state TTPs leaves itself exposed to ransomware operators exploiting the same vulnerability, and vice versa.

High-priority CVEs take more time to remediate, not less. Across Tenable’s 238-CVE high-priority list, high-priority CVEs carry a median remediation time of 146 days, compared to 122 days for all other CVEs — a 24-day gap that is statistically significant. The edge-appliance-specific subset (52 CVEs) shows a consistent 8-day gap in the same direction, which was not statistically significant, but suggests the direction may hold for edge appliances too. External data corroborates the pattern: the 2026 Verizon Data Breach Investigations Report (DBIR) found that median patch time increased from 32 to 43 days year over year, even as exploitation overtook credential theft as the number one initial access vector, and the 2025 DBIR, which incorporated Tenable RSO’s remediation trend analysis across 17 edge-related CVEs, found that only 54% of edge device KEVs were fully remediated. The explanation is structural: edge devices are the network boundary, so patching a VPN gateway or firewall means downtime for every user behind it, and change management gates multiply. These devices also resist standard patching workflows because they do not run endpoint agents, often require firmware-level updates with manual validation, and frequently lack active support contracts. The result is that the devices most worth patching are operationally the hardest to patch — and as the high-priority queue grows (the 2026 DBIR reports 50% more critical vulnerabilities to patch than the prior year), everything on it waits longer.

Background

Edge and perimeter devices occupy a uniquely consequential position in enterprise architecture. VPN gateways, firewalls, remote access appliances, and application delivery controllers sit at the boundary between trusted and untrusted networks. They are very often the first component an attacker touches and, for many organizations, the last component that gets patched. When one of these devices is compromised, the attacker inherits its network position: inside the perimeter, with access to internal resources, often without triggering endpoint detection.

This analysis combines two independent datasets to demonstrate that convergence. Tenable contributes exposure telemetry from the Tenable One Exposure Management Platform, covering thousands of customer containers and measuring what edge infrastructure is deployed, what is vulnerable, and how long it remains unpatched. This dataset extends Tenable Research’s ongoing analysis of edge device exposure trends, including the remediation telemetry Tenable contributed to the 2025 and 2026 Verizon DBIR reports. SentinelOne contributes findings from its digital forensics and incident response (DFIR) practice, documenting which threat actors actually exploit which vulnerabilities, observed firsthand inside compromised environments. Neither dataset was built for this analysis; each was constructed independently for different operational purposes.

The finding that makes this analysis compelling is not about any single CVE or any single actor. It is the structural convergence: two independent observation systems, looking at the problem from opposite sides, arrive at the same conclusion about which vendor surfaces are under persistent, broad exploitation, and by whom. (For how each dataset was built and scored, see the Methodology appendix below.)

What’s Exposed: The Vulnerability Surface

Tenable’s exposure telemetry provides the vulnerability-side view. All exposure metrics reported here use container-grain measurement: the percentage of customer environments (organizational containers) with at least one asset vulnerable to a given CVE as of Aug. 15, 2026, relative to total exposed containers over the preceding 14-month period. This measures breadth of organizational exposure to edge-product vendor vulnerabilities, not raw asset counts, across the sampling window.

This section covers 15 vendors in three groups: seven confirmed in both independently compiled corpora, two confirmed in SentinelOne’s casework but absent from Tenable’s attributed corpus, and six “candidate” vendors surfaced by a broader screen of Tenable telemetry. The candidates are not part of the convergence finding, but two, F5 and Zimbra, show broader customer exposure than most of the confirmed seven, so omitting them would understate the breadth of at-risk edge infrastructure.

F5 and Citrix lead for different reasons. Among vendors with statistically robust sample sizes, F5 customers are the most broadly exposed: 53.8% of 2,784 monitored customer environments running F5 products have at least one actively exploited CVE present. Citrix customers show the slowest remediation patterns: a median of 461 days to patch, with 71% of affected environments still carrying unpatched Citrix CVEs after a full year. F5 leads on scale of exposure; Citrix leads on persistent exposure.

The mid-pack is flatter than expected. Check Point (18.6%), Ivanti (24.1%), Fortinet (24.9%), and Citrix (28.8%) cluster within a 10-point band at container-grain. Fortinet, which dominates headlines, is mid-pack by this measure.

Thin-sample vendors show extreme rates but require caution. Juniper (91.7%), VMware (75.0%), Palo Alto Networks (69.2%), and Cisco (56.2%) all show container-exposure proportions above 50%, but each has fewer than 50 in-sample containers. These statistics are real directional signals, but should be considered within the context of the relatively low sample size.

Serial exploitation is structural. Two clean serial-exploitation sequences appear in the dataset: Ivanti EPMM (approximately 8.5 months between successive exploited CVEs) and Ivanti Connect Secure (approximately 13 months). Same product line, new vulnerability, repeat exploitation. Tenable Research has published advisories on both Ivanti exploitation sequences, tracking each CVE from initial disclosure through active exploitation, and the exposure data here extends that analysis with organizational remediation timelines not available at the time of the original advisories. The next one is coming.

Who Exploits What: The Threat Actor Landscape

This is not a targeted effort by a specific group. Edge infrastructure is a core focal point of attack across a broad range of threat actors and nexus categories. The combined Tenable-SentinelOne corpus documents exploitation by actors spanning five nexus categories: China, Russia, DPRK, Iran, and criminal (financially motivated). All five categories independently target the same vendor surfaces. Every attribution in the corpus is bucketed into one of three confidence tiers derived from a five-dimensional rubric evaluating attribution directness, evidence provenance, recency, exploitation role, and source corroboration. Confidence tiers, from high to low, are: DIRECT, TECHNIQUE-ALIGNED, or INFERRED.

Actor density scales with vendor exposure. Fortinet products face the broadest actor surface: 29 distinct threat actors across five nexus categories. Citrix follows with 22 actors across five categories, Ivanti with 19 across four, Palo Alto Networks with nine across three, and Check Point with six across two. Every focal vendor has confirmed exploitation from multiple nexus categories. No single vendor’s exposure is attributable to a single adversary group.

China-nexus actors are the highest-confidence case study, appearing across nine vendors in the corpus, with four DIRECT-tier attributions from the scored dataset alone. But the analytical value here is not that China targets edge devices. That is well established. The value is that China, Russia, DPRK, Iran, and ransomware operators all target the same edge devices, as the examples above illustrate. The governed attribution methodology is what allows this claim to be made with precision: we can distinguish confirmed multi-nexus convergence (DIRECT-tier evidence on both sides) from assessed convergence (INFERRED, requiring corroboration).

What Incident Response Sees That Telemetry Can’t

Exposure data shows which appliances are reachable, vulnerable, and unpatched. Incident response looks at what happened when attackers got in: what they accessed, what they took, and where they went next. In SentinelOne DFIR cases involving edge infrastructure, attackers used credentials stored on the appliances and the access those appliances already had to reach internal systems.

Credential Theft from Edge Appliances

Across three engagements, threat actors reached the management plane of FortiGate appliances and created rogue administrative accounts. In two, they also exported device configurations and extracted credentials that could be used to move further into the network. Two of these three are documented in detail in FortiGate Edge Intrusions.

In one of those two, the exported configuration contained LDAP bind credentials for a directory service account. The account was later used in the environment. A few hours later, the threat actor added two computers to the domain. Neither had a Service Principal Name, which is unusual for a legitimate domain join. The mS-DS-CreatorSID attribute on both accounts pointed back to the stolen service account.

We saw similar activity on an Ivanti Cloud Services Appliance in late 2024. A China-nexus actor chained CVE-2024-8963 with CVE-2024-8190 before the first public disclosure in the chain. After gaining access, the actor collected SSH keys and other stored credentials. That engagement is documented as Activity F in Follow the Smoke.

These appliances did not provide conventional endpoint telemetry. We had to follow the activity into authentication records, newly created Active Directory objects, and the later use of credentials taken from the appliances.

When the Initial Access Vector Cannot Be Confirmed

In December 2025, Fortinet disclosed CVE-2025-59718, an authentication bypass in its FortiCloud SSO integration affecting FortiOS and other products. Several weeks later, Fortinet disclosed CVE-2026-24858. This second flaw allowed an attacker with a FortiCloud account and a registered device to log into devices belonging to other customers when FortiCloud SSO was enabled.

That overlap mattered in one of the three engagements above. The appliance was running a version affected by both CVEs, but the available logs did not show when or how the attacker first gained access. The earliest retained malicious activity showed a rogue local administrator account. A few minutes later, a domain administrator authenticated from the appliance’s VPN address pool. Exposure data showed that the appliance had been vulnerable to both CVEs, but that alone did not establish how it was compromised. We treated both as possible, not confirmed, initial-access vectors.

Abuse of Trusted Management Access

In one SentinelOne DFIR engagement involving a FortiManager appliance, CVE-2024-47575 allowed an unauthorized device to register with the appliance through the management protocol. Two log entries, seconds apart, recorded the rogue registration and the settings change that followed. The threat actor then staged an archive of managed-device configurations that could expose credentials, addresses, and details about the network. The actor had been present for about a month before the customer detected the activity.

In a separate engagement, a threat actor chained SQL injection, pass-the-hash authentication, and authentication bypass against an internet-facing SonicWall GMS console (CVE-2023-34133, CVE-2023-34132, and CVE-2023-34124). The actor created administrative accounts on a platform operated by a managed service provider, then used existing shared access to enter multiple customer environments. Most of the resulting traffic was advertising-related, leading us to assess that the infrastructure was being used for click fraud.

The actors were after different things. One collected configuration data and information about the network. The other used the access to turn systems across several environments into proxies. In both cases, the actor inherited the access that the organization had already granted to the management platform. These cases show the difference between the two views: exposure telemetry finds the vulnerable device, while incident response shows what was taken from it and where the attacker went next.

What to Do About It

Patch F5 and Citrix edge devices immediately. These two vendors combine the highest exposure rates with the slowest remediation timelines across statistically robust samples. Look for strategies to reduce the remediation time, particularly for weaponized CVEs. Additionally, reduce the attack surface by minimizing the enabled feature set on these devices and aim for defense in depth by running endpoints in protect mode to limit lateral movement opportunities.

Audit Ivanti Connect Secure and EPMM deployments. Serial exploitation on observed 8.5 to 13-month cycles means the next exploitable CVE in these product lines is a question of timing, not probability. Organizations running Ivanti edge products should assume they will face a new actively exploited vulnerability within the next year and plan patching capacity accordingly.

Implement edge-device-specific patch SLAs. The delayed remediation paradox demonstrates that general priority frameworks do not translate into faster patching on the devices that sit at the network boundary. Edge devices and network infrastructure warrant dedicated remediation timelines that are shorter than the organizational default and commensurate with the elevated risk.

Treat edge device exposure as a cross-signal priority. Attribution, severity, and exposure volume identify different CVEs as “top priority.” Organizations need all three signals for complete coverage. A vulnerability management program that prioritizes exclusively by CVSS will systematically underweight CVEs with strong exploitation evidence but modest severity scores, and vice versa. The Tenable One Exposure Management Platform enables this cross-signal approach by combining vulnerability severity, exposure intelligence, asset context, and exposure data into a unified prioritization view.

Identifying Affected Systems

Tenable customers can use the Tenable Vulnerability Watch dashboard to monitor classifications for all CVEs discussed in this analysis. A list of Tenable plugins for the vulnerabilities discussed in this analysis can be found on the individual CVE pages at tenable.com/cve as they are released. This link displays all available plugins for each vulnerability, including upcoming plugins in our Plugins Pipeline.

Get more information

• Tenable Vulnerability Watch
• SentinelOne Threat Research (PurpleHaze, SonicWall SMA1000)
• FortiGate Edge Intrusions – SentinelOne
• Follow the Smoke – SentinelOne
• CISA Known Exploited Vulnerabilities Catalog

Join Tenable’s Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One Exposure Management Platform, the exposure management platform for the modern attack surface.

Appendix: Methodology and Corpus Construction

How the corpus was built. Tenable’s 33-CVE corpus was derived by combining and deduplicating vulnerabilities with the highest exploitation volume and broadest actor adoption; SentinelOne validated CVEs across 14 vendors, and their 66-CVE landscape view reflects 12 months of DFIR casework with false positives removed. Combined, the two datasets identify 82 distinct CVEs, 17 of which appear in both. Layered on top of these sources is a governed attribution corpus of 93 CVE-actor pairs spanning approximately 39 named threat actors and five nexus categories.

Why Tenable tracks these CVEs. Tenable’s set comes out of exposure management. A CVE enters it through the Vulnerability Watch program, which classifies vulnerabilities under active or likely to be exploited, and is additionally scored with a Vulnerability Priority Rating (VPR). The question being answered is prescriptive: of everything actually deployed across customer environments, what should be prioritized and patched first? Threat-actor attribution is layered on afterward from definitive and confidence-scored sources (e.g., Federal cybersecurity advisories).

Why SentinelOne tracks these CVEs. SentinelOne’s set comes from the opposite direction: incident response. A CVE earns its place in their 12-month DFIR landscape because responders found it used in a real intrusion — the initial access vector in a case someone called them about. The question being answered is forensic: what happened here, and who did it? Coverage is shaped by who engaged them, not by install base.

What “overlap” means here. Overlap was measured at two levels, and the answer changes sharply depending on which level you use.

At the level of the individual vulnerability, the two sets barely intersect. Only 17 of 82, or 21%, of CVEs are common to both. Tenable and SentinelOne are, for the most part, not looking at the same vulnerabilities. However, the datasets converge at the product level. Eleven of the 14 vendors in Tenable’s focal CVE set appear in SentinelOne’s 12-month DFIR landscape – a 79% convergence: Fortinet, Citrix, Ivanti, Palo Alto Networks, Cisco, Juniper, VMware, Microsoft, Oracle, CrushFTP, and Meta’s React framework. That’s 79% convergence at the vendor level against 21% at the CVE level. Three vendors did not conform: Apache and SAP were absent from SentinelOne’s casework, and the one Progress case they worked on was closed as a false positive. Narrow the comparison to edge and remote-access infrastructure specifically, and the convergence is a perfect 100%. Tenable’s corpus independently identified seven edge vendors (i.e., Fortinet, Citrix, Ivanti, Palo Alto Networks, Cisco, Juniper, and VMware). All seven appear in SentinelOne’s casework. Two teams, working from unrelated evidence for unrelated purposes, arrived at the same seven vendors while sharing roughly one CVE in five.

Why the distinction matters. “Different vulnerabilities, same vendors” is not a weaker version of “same vulnerabilities.” It is a different and more actionable claim. Had both datasets converged on the same individual CVEs, the story would be that a specific handful of vulnerabilities is being widely exploited: patch those and the problem shrinks. What the data actually shows is that state-sponsored and criminal operators are independently arriving at the same small set of edge and remote-access product vendors, then finding their own separate ways in. The durable target is the vendor attack surface. Patching this quarter’s Ivanti CVE does not remove Ivanti from anyone’s target list.

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.

The Good | Authorities Launch New Operations Against Cybercrime Networks & Supply Chain Attackers

Operation Jackal IV, coordinated by INTERPOL across 22 nations, has led to the arrest of 58 individuals and the identification of over 200 suspects linked to West African cybercrime networks. The joint action successfully dismantled elements of the Black Axe syndicate, which orchestrates global romance, investment, and business email compromise (BEC) scams. Law enforcement agencies across South Africa, Argentina, and Romania also disrupted major Crime-as-a-Service (CaaS) providers, freezing millions of dollars in illicit financial assets.

The FBI, collaborating with the DoJ, have disrupted the global QScan and QTRouter hacking platforms operated by Chinese state-sponsored threat actors. The group QTFY, which maintains direct ties to China’s military and intelligence services, used these compromised IoT botnets to mask cyber espionage traffic targeting critical U.S. networks, including the Federal Reserve and NASA. Law enforcement successfully seized the core command-and-control (C2) domains hardcoded within the malicious frameworks.

From the U.S. Treasury is a new operation dubbed Economic Outcast, imposing sweeping sanctions on five Mabna Institute members and nearly 60 Iran-linked entities. Under the direction of Iran’s Ministry of Intelligence and Security (MOIS), the attackers breached multiple American critical infrastructure organizations, state governments, and defense contractors. These state-sponsored actors then exfiltrated datasets, executed high-value cryptocurrency heists, and now face federal indictments alongside a $10 million dollar reward for information leading to their arrest.

The Australian Federal Police (AFP) have arrested and charged two individuals for principal roles in TeamPCP, a cybercrime syndicate. The group systematically compromised trusted open-source projects, including Trivy, Checkmarx KICS, and LiteLLM, by stealing developer credentials and distributing backdoored software updates across major ecosystem release channels. This massive software supply chain campaign potentially compromised organizations worldwide and facilitated the unauthorized theft of hundreds of thousands of credentials.

The Bad | ‘NovaCookies’ Phishing Toolkit Exploits DocuSign Services to Steal Session Tokens

Security researchers have disclosed details of NovaCookies, a subscription-based phishing platform that systematically targets corporate networks to steal authenticated Microsoft 365 sessions. Operating as an Adversary-in-the-Middle (AitM) proxy, this malicious toolkit is advertised on Telegram for $320 monthly. The campaigns actively compromise hundreds of organizations across several nations, including the U.S., the U.K., Germany, and the U.A.E.

To establish a foothold, attackers distribute counterfeit document-sharing lures within genuine DocuSign notifications. Styled as a share notice, the decoy claims an accounting department shared a remittance-advice PDF and invites the recipient to open it. Since these notifications originate from legitimate servers, they bypass standard sender-authentication checks and reputation filters. The malicious link is embedded inside the shared document, below the inspection layer of most security gateways. Once clicked, the attack uses an OAuth error-redirect technique to guide the browser through legitimate Microsoft or Google endpoints before routing traffic to the phishing infrastructure. This transition ensures every intermediate step appears trustworthy until the user reaches the proxy.

NovaCookies is a variant of the Sneaky2FA platform, which operates on a centrally managed model where the operator hosts the infrastructure rather than individual affiliates. The kit offers customized flows targeting common identity providers. Affiliates register landing pages on .vu domains, utilizing deceptive, alternating-case subdomains like PwPt-sHaRe to masquerade as legitimate Microsoft portals. While these checks obscure the landing pages, the proxy relays credentials and multi-factor authentication (MFA) codes in real time to Microsoft. Because each individual hop of the attack chain appears legitimate, security analysts emphasize that the browser remains the critical intersection where these events converge.

The Ugly | Threat Actors Deploy Spark RAT to Target Cambodian Organizations

A recently uncovered campaign is targeting both individuals and organizations in Cambodia with Spark RAT, which functions as a Go-based, open-source remote access trojan. Distributing compressed archives through targeted phishing emails, the threat actors deploy diverse lures, including Cambodian government notices, public health announcements, and dental records. The multi-stage attack sequence begins when a victim executes an Inno Setup installer, which initiates a dynamic link library side-loading chain using a signed Tencent application to deliver intermediate payloads.

To guarantee execution, the DLL loader performs timing-based anti-sandbox checks to detect virtual environment delays and scans running processes in an attempt to weaken its permissions. The loader then decrypts shellcode hidden within an embedded PNG file to run a second stager that determines whether the malware operates with SYSTEM privileges. If these elevated rights are present, the malware proceeds directly to inject mode. Otherwise, it configures a Windows service for local persistence. Ultimately, the stager injects malicious shellcode into the legitimate vssvc.exe process, monitoring execution to re-inject the payload if terminated.

The intrusion chain utilizes the Bring Your Own Vulnerable Driver (BYOVD) technique that abuses a legitimate but vulnerable OPSWAT AppRemover driver, ardrv.sys, to escalate privileges and neutralize security programs. Operating under CVE-2026-36425, this driver enables the malware to terminate active security processes, including Microsoft Defender, Huorong Internet Security, and Tencent PC Manager. The program also patches Antimalware Scan Interface and Event Tracing for Windows, executes user-mode termination of security tools, and injects Spark RAT into ctfmon.exe. Although operational tactics and driver usage closely mirror the Chinese-speaking Silver Fox syndicate, analysts classify the campaign as an unattributed cluster due to the absence of shared infrastructure, certificates, or code reuse.

It is the shared attack surface where state-sponsored threat actors and financially motivated criminal groups independently converge — not the province of a single adversary category, and not exclusively a nation-state problem, despite two years of headlines about China-nexus actors targeting Ivanti, Fortinet, and Palo Alto Networks. The data here tells a different and much broader story. One focused on vendors vs CVEs.

Key Takeaways

• Two independent observation systems, Tenable exposure telemetry across thousands of customer containers and SentinelOne DFIR casework across 66 CVEs, converge 79% on the same vendor attack surfaces despite minimal CVE-level overlap.
• Twelve CVEs in the combined dataset have confirmed multi-nexus attribution: state-sponsored and criminal actors independently exploiting the same vulnerability, across five nexus categories (China, Russia, DPRK, Iran, ransomware).
• The exposure picture is flatter than the headlines suggest: Fortinet, the vendor most associated with edge-device attacks in the press, sits mid-pack on container-grain exposure (25%) — well behind F5 (54%) and in a tight 10-point band with Check Point, Ivanti, and Citrix.
• 54% of customer environments running F5 products have at least one exposed, actively-exploited CVE; Citrix customers show the slowest remediation patterns at 461 days median time to patch.
• Remediation complexity, particularly of high priority CVEs, leads to a statistically significant 24-day remediation gap, leaving large windows of opportunity for attackers.
• The same product lines get hit again and again: Ivanti EPMM and Ivanti Connect Secure each show a newly exploited CVE roughly every 8.5 to 13 months.
• Leverage multiple defense-in-depth strategies: patch as quickly as possible, but also minimize the attack surface (feature-set minimization) and run endpoints in protect mode to better stop lateral movement from attacks that gain initial access.

The Convergence is the Story

Twelve CVEs in the combined dataset have confirmed multi-nexus attribution: state-sponsored and criminal actors independently exploiting the same vulnerability, across five nexus categories. Four examples illustrate the pattern:

The remaining eight confirmed multi-nexus CVEs span Fortinet, Citrix, Cisco, and Ivanti product lines. State-sponsored actors and ransomware operators are not operating in separate vulnerability ecosystems. They share the same entry points into the same products. The breadth of the convergence, not any single actor’s activity, is the finding.

That pattern holds across the full combined analysis. Three conclusions emerge:

Vendor attack surfaces are the persistent exploitation target. The same eleven vendors (i.e., Fortinet, Citrix, Ivanti, Palo Alto Networks, Cisco, Juniper, VMware, Microsoft, Oracle, CrushFTP, and Meta’s React framework) appear in both observation systems at 79% convergence, and all seven edge-product vendors converge. Serial exploitation timing on Ivanti products shows the vulnerability-to-exploitation pipeline refreshing at 8.5 to 13-month intervals on the same product lines. This is structural, not episodic. Patching the current CVE does not remove the vendor attack surface from the threat landscape.

State-sponsored and ransomware actors converge structurally. Twelve CVEs with confirmed multi-nexus attribution span all five nexus categories and cross the state-criminal divide. Defending against one actor category on edge devices necessarily requires defending against all of them, because the attack surface is shared. An organization that patches only for nation-state TTPs leaves itself exposed to ransomware operators exploiting the same vulnerability, and vice versa.

High-priority CVEs take more time to remediate, not less. Across Tenable’s 238-CVE high-priority list, high-priority CVEs carry a median remediation time of 146 days, compared to 122 days for all other CVEs — a 24-day gap that is statistically significant. The edge-appliance-specific subset (52 CVEs) shows a consistent 8-day gap in the same direction, which was not statistically significant, but suggests the direction may hold for edge appliances too. External data corroborates the pattern: the 2026 Verizon Data Breach Investigations Report (DBIR) found that median patch time increased from 32 to 43 days year over year, even as exploitation overtook credential theft as the number one initial access vector, and the 2025 DBIR, which incorporated Tenable RSO’s remediation trend analysis across 17 edge-related CVEs, found that only 54% of edge device KEVs were fully remediated. The explanation is structural: edge devices are the network boundary, so patching a VPN gateway or firewall means downtime for every user behind it, and change management gates multiply. These devices also resist standard patching workflows because they do not run endpoint agents, often require firmware-level updates with manual validation, and frequently lack active support contracts. The result is that the devices most worth patching are operationally the hardest to patch — and as the high-priority queue grows (the 2026 DBIR reports 50% more critical vulnerabilities to patch than the prior year), everything on it waits longer.

Background

Edge and perimeter devices occupy a uniquely consequential position in enterprise architecture. VPN gateways, firewalls, remote access appliances, and application delivery controllers sit at the boundary between trusted and untrusted networks. They are very often the first component an attacker touches and, for many organizations, the last component that gets patched. When one of these devices is compromised, the attacker inherits its network position: inside the perimeter, with access to internal resources, often without triggering endpoint detection.

This analysis combines two independent datasets to demonstrate that convergence. Tenable contributes exposure telemetry from the Tenable One Exposure Management Platform, covering thousands of customer containers and measuring what edge infrastructure is deployed, what is vulnerable, and how long it remains unpatched. This dataset extends Tenable Research’s ongoing analysis of edge device exposure trends, including the remediation telemetry Tenable contributed to the 2025 and 2026 Verizon DBIR reports. SentinelOne contributes findings from its digital forensics and incident response (DFIR) practice, documenting which threat actors actually exploit which vulnerabilities, observed firsthand inside compromised environments. Neither dataset was built for this analysis; each was constructed independently for different operational purposes.

The finding that makes this analysis compelling is not about any single CVE or any single actor. It is the structural convergence: two independent observation systems, looking at the problem from opposite sides, arrive at the same conclusion about which vendor surfaces are under persistent, broad exploitation, and by whom. (For how each dataset was built and scored, see the Methodology appendix below.)

What’s Exposed: The Vulnerability Surface

Tenable’s exposure telemetry provides the vulnerability-side view. All exposure metrics reported here use container-grain measurement: the percentage of customer environments (organizational containers) with at least one asset vulnerable to a given CVE as of Aug. 15, 2026, relative to total exposed containers over the preceding 14-month period. This measures breadth of organizational exposure to edge-product vendor vulnerabilities, not raw asset counts, across the sampling window.

This section covers 15 vendors in three groups: seven confirmed in both independently compiled corpora, two confirmed in SentinelOne’s casework but absent from Tenable’s attributed corpus, and six “candidate” vendors surfaced by a broader screen of Tenable telemetry. The candidates are not part of the convergence finding, but two, F5 and Zimbra, show broader customer exposure than most of the confirmed seven, so omitting them would understate the breadth of at-risk edge infrastructure.

F5 and Citrix lead for different reasons. Among vendors with statistically robust sample sizes, F5 customers are the most broadly exposed: 53.8% of 2,784 monitored customer environments running F5 products have at least one actively exploited CVE present. Citrix customers show the slowest remediation patterns: a median of 461 days to patch, with 71% of affected environments still carrying unpatched Citrix CVEs after a full year. F5 leads on scale of exposure; Citrix leads on persistent exposure.

The mid-pack is flatter than expected. Check Point (18.6%), Ivanti (24.1%), Fortinet (24.9%), and Citrix (28.8%) cluster within a 10-point band at container-grain. Fortinet, which dominates headlines, is mid-pack by this measure.

Thin-sample vendors show extreme rates but require caution. Juniper (91.7%), VMware (75.0%), Palo Alto Networks (69.2%), and Cisco (56.2%) all show container-exposure proportions above 50%, but each has fewer than 50 in-sample containers. These statistics are real directional signals, but should be considered within the context of the relatively low sample size.

Serial exploitation is structural. Two clean serial-exploitation sequences appear in the dataset: Ivanti EPMM (approximately 8.5 months between successive exploited CVEs) and Ivanti Connect Secure (approximately 13 months). Same product line, new vulnerability, repeat exploitation. Tenable Research has published advisories on both Ivanti exploitation sequences, tracking each CVE from initial disclosure through active exploitation, and the exposure data here extends that analysis with organizational remediation timelines not available at the time of the original advisories. The next one is coming.

Who Exploits What: The Threat Actor Landscape

This is not a targeted effort by a specific group. Edge infrastructure is a core focal point of attack across a broad range of threat actors and nexus categories. The combined Tenable-SentinelOne corpus documents exploitation by actors spanning five nexus categories: China, Russia, DPRK, Iran, and criminal (financially motivated). All five categories independently target the same vendor surfaces. Every attribution in the corpus is bucketed into one of three confidence tiers derived from a five-dimensional rubric evaluating attribution directness, evidence provenance, recency, exploitation role, and source corroboration. Confidence tiers, from high to low, are: DIRECT, TECHNIQUE-ALIGNED, or INFERRED.

Actor density scales with vendor exposure. Fortinet products face the broadest actor surface: 29 distinct threat actors across five nexus categories. Citrix follows with 22 actors across five categories, Ivanti with 19 across four, Palo Alto Networks with nine across three, and Check Point with six across two. Every focal vendor has confirmed exploitation from multiple nexus categories. No single vendor’s exposure is attributable to a single adversary group.

China-nexus actors are the highest-confidence case study, appearing across nine vendors in the corpus, with four DIRECT-tier attributions from the scored dataset alone. But the analytical value here is not that China targets edge devices. That is well established. The value is that China, Russia, DPRK, Iran, and ransomware operators all target the same edge devices, as the examples above illustrate. The governed attribution methodology is what allows this claim to be made with precision: we can distinguish confirmed multi-nexus convergence (DIRECT-tier evidence on both sides) from assessed convergence (INFERRED, requiring corroboration).

What Incident Response Sees That Telemetry Can’t

Exposure data shows which appliances are reachable, vulnerable, and unpatched. Incident response looks at what happened when attackers got in: what they accessed, what they took, and where they went next. In SentinelOne DFIR cases involving edge infrastructure, attackers used credentials stored on the appliances and the access those appliances already had to reach internal systems.

Credential Theft from Edge Appliances

Across three engagements, threat actors reached the management plane of FortiGate appliances and created rogue administrative accounts. In two, they also exported device configurations and extracted credentials that could be used to move further into the network. Two of these three are documented in detail in FortiGate Edge Intrusions.

In one of those two, the exported configuration contained LDAP bind credentials for a directory service account. The account was later used in the environment. A few hours later, the threat actor added two computers to the domain. Neither had a Service Principal Name, which is unusual for a legitimate domain join. The mS-DS-CreatorSID attribute on both accounts pointed back to the stolen service account.

We saw similar activity on an Ivanti Cloud Services Appliance in late 2024. A China-nexus actor chained CVE-2024-8963 with CVE-2024-8190 before the first public disclosure in the chain. After gaining access, the actor collected SSH keys and other stored credentials. That engagement is documented as Activity F in Follow the Smoke.

These appliances did not provide conventional endpoint telemetry. We had to follow the activity into authentication records, newly created Active Directory objects, and the later use of credentials taken from the appliances.

When the Initial Access Vector Cannot Be Confirmed

In December 2025, Fortinet disclosed CVE-2025-59718, an authentication bypass in its FortiCloud SSO integration affecting FortiOS and other products. Several weeks later, Fortinet disclosed CVE-2026-24858. This second flaw allowed an attacker with a FortiCloud account and a registered device to log into devices belonging to other customers when FortiCloud SSO was enabled.

That overlap mattered in one of the three engagements above. The appliance was running a version affected by both CVEs, but the available logs did not show when or how the attacker first gained access. The earliest retained malicious activity showed a rogue local administrator account. A few minutes later, a domain administrator authenticated from the appliance’s VPN address pool. Exposure data showed that the appliance had been vulnerable to both CVEs, but that alone did not establish how it was compromised. We treated both as possible, not confirmed, initial-access vectors.

Abuse of Trusted Management Access

In one SentinelOne DFIR engagement involving a FortiManager appliance, CVE-2024-47575 allowed an unauthorized device to register with the appliance through the management protocol. Two log entries, seconds apart, recorded the rogue registration and the settings change that followed. The threat actor then staged an archive of managed-device configurations that could expose credentials, addresses, and details about the network. The actor had been present for about a month before the customer detected the activity.

In a separate engagement, a threat actor chained SQL injection, pass-the-hash authentication, and authentication bypass against an internet-facing SonicWall GMS console (CVE-2023-34133, CVE-2023-34132, and CVE-2023-34124). The actor created administrative accounts on a platform operated by a managed service provider, then used existing shared access to enter multiple customer environments. Most of the resulting traffic was advertising-related, leading us to assess that the infrastructure was being used for click fraud.

The actors were after different things. One collected configuration data and information about the network. The other used the access to turn systems across several environments into proxies. In both cases, the actor inherited the access that the organization had already granted to the management platform. These cases show the difference between the two views: exposure telemetry finds the vulnerable device, while incident response shows what was taken from it and where the attacker went next.

What to Do About It

Patch F5 and Citrix edge devices immediately. These two vendors combine the highest exposure rates with the slowest remediation timelines across statistically robust samples. Look for strategies to reduce the remediation time, particularly for weaponized CVEs. Additionally, reduce the attack surface by minimizing the enabled feature set on these devices and aim for defense in depth by running endpoints in protect mode to limit lateral movement opportunities.

Audit Ivanti Connect Secure and EPMM deployments. Serial exploitation on observed 8.5 to 13-month cycles means the next exploitable CVE in these product lines is a question of timing, not probability. Organizations running Ivanti edge products should assume they will face a new actively exploited vulnerability within the next year and plan patching capacity accordingly.

Implement edge-device-specific patch SLAs. The delayed remediation paradox demonstrates that general priority frameworks do not translate into faster patching on the devices that sit at the network boundary. Edge devices and network infrastructure warrant dedicated remediation timelines that are shorter than the organizational default and commensurate with the elevated risk.

Treat edge device exposure as a cross-signal priority. Attribution, severity, and exposure volume identify different CVEs as “top priority.” Organizations need all three signals for complete coverage. A vulnerability management program that prioritizes exclusively by CVSS will systematically underweight CVEs with strong exploitation evidence but modest severity scores, and vice versa. The Tenable One Exposure Management Platform enables this cross-signal approach by combining vulnerability severity, exposure intelligence, asset context, and exposure data into a unified prioritization view.

Identifying Affected Systems

Tenable customers can use the Tenable Vulnerability Watch dashboard to monitor classifications for all CVEs discussed in this analysis. A list of Tenable plugins for the vulnerabilities discussed in this analysis can be found on the individual CVE pages at tenable.com/cve as they are released. This link displays all available plugins for each vulnerability, including upcoming plugins in our Plugins Pipeline.

Get more information

• Tenable Vulnerability Watch
• SentinelOne Threat Research (PurpleHaze, SonicWall SMA1000)
• FortiGate Edge Intrusions – SentinelOne
• Follow the Smoke – SentinelOne
• CISA Known Exploited Vulnerabilities Catalog

Join Tenable’s Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One Exposure Management Platform, the exposure management platform for the modern attack surface.

Appendix: Methodology and Corpus Construction

How the corpus was built. Tenable’s 33-CVE corpus was derived by combining and deduplicating vulnerabilities with the highest exploitation volume and broadest actor adoption; SentinelOne validated CVEs across 14 vendors, and their 66-CVE landscape view reflects 12 months of DFIR casework with false positives removed. Combined, the two datasets identify 82 distinct CVEs, 17 of which appear in both. Layered on top of these sources is a governed attribution corpus of 93 CVE-actor pairs spanning approximately 39 named threat actors and five nexus categories.

Why Tenable tracks these CVEs. Tenable’s set comes out of exposure management. A CVE enters it through the Vulnerability Watch program, which classifies vulnerabilities under active or likely to be exploited, and is additionally scored with a Vulnerability Priority Rating (VPR). The question being answered is prescriptive: of everything actually deployed across customer environments, what should be prioritized and patched first? Threat-actor attribution is layered on afterward from definitive and confidence-scored sources (e.g., Federal cybersecurity advisories).

Why SentinelOne tracks these CVEs. SentinelOne’s set comes from the opposite direction: incident response. A CVE earns its place in their 12-month DFIR landscape because responders found it used in a real intrusion — the initial access vector in a case someone called them about. The question being answered is forensic: what happened here, and who did it? Coverage is shaped by who engaged them, not by install base.

What “overlap” means here. Overlap was measured at two levels, and the answer changes sharply depending on which level you use.

At the level of the individual vulnerability, the two sets barely intersect. Only 17 of 82, or 21%, of CVEs are common to both. Tenable and SentinelOne are, for the most part, not looking at the same vulnerabilities. However, the datasets converge at the product level. Eleven of the 14 vendors in Tenable’s focal CVE set appear in SentinelOne’s 12-month DFIR landscape – a 79% convergence: Fortinet, Citrix, Ivanti, Palo Alto Networks, Cisco, Juniper, VMware, Microsoft, Oracle, CrushFTP, and Meta’s React framework. That’s 79% convergence at the vendor level against 21% at the CVE level. Three vendors did not conform: Apache and SAP were absent from SentinelOne’s casework, and the one Progress case they worked on was closed as a false positive. Narrow the comparison to edge and remote-access infrastructure specifically, and the convergence is a perfect 100%. Tenable’s corpus independently identified seven edge vendors (i.e., Fortinet, Citrix, Ivanti, Palo Alto Networks, Cisco, Juniper, and VMware). All seven appear in SentinelOne’s casework. Two teams, working from unrelated evidence for unrelated purposes, arrived at the same seven vendors while sharing roughly one CVE in five.

Why the distinction matters. “Different vulnerabilities, same vendors” is not a weaker version of “same vulnerabilities.” It is a different and more actionable claim. Had both datasets converged on the same individual CVEs, the story would be that a specific handful of vulnerabilities is being widely exploited: patch those and the problem shrinks. What the data actually shows is that state-sponsored and criminal operators are independently arriving at the same small set of edge and remote-access product vendors, then finding their own separate ways in. The durable target is the vendor attack surface. Patching this quarter’s Ivanti CVE does not remove Ivanti from anyone’s target list.

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.

The question has shifted. Security leaders spent several years debating whether AI would reshape security operations. That debate has settled. Now the conversation is about pace. How fast can the foundation be built, and what do organizations that moved early have to show for it?

For the second year, SentinelOne® commissioned 451 Research to survey 611 North American cybersecurity decision-makers and practitioners on the state of security operations strategy. The results confirm what we’ve been building toward, and they surface a finding that should recalibrate how most security leaders sequence their AI investments.

The Returns Didn’t Wait for the Roadmap

Many product roadmaps assume a clear sequence and start with building toward higher maturity first with returns following. The data shows that AI is running ahead of schedule.

Nearly all organizations surveyed (96%) are still operating AI at the earliest maturity levels:

• Level 1: Basic monitoring; triage specialist/alert analyst
• Level 2: More senior triage analyst / basic incident responder and investigator

By most measures, AI adoption in the SOC is still early. And yet, 99% of those same organizations already report improvements in incident response and remediation.

The numbers are consistent. Early-stage AI (chatbots handling initial alert triage, automated tools sorting true positives from noise) is delivering before organizations reach advanced maturity. The gap between where most organizations are and what they are already getting is real and consistent across survey respondents.

Organizations waiting for higher AI maturity before building the supporting infrastructure are running the sequence backward. The returns are available now. The foundation built today determines how far those returns scale.

Platformization Has Reached A Verdict

The organizations accelerating AI adoption are also the ones consolidating onto platforms. A platform-oriented security architecture means moving from siloed, specialized tools to an integrated stack built on a foundation that coordinated AI decision-making can actually run on, and one that lets each new capability compound on the last.

The platformization numbers from this year’s survey are clear. 82% of organizations describe themselves as platform-oriented, a 13-point jump in a single year, and 94% expect to be there within three years.

A common assumption is that platform adoption means replacing specialized tools. The data complicates that picture. The same technologies most frequently deployed as standalone tools (EDR, SIEM, CNAPP) are also the top anchors for integrated platforms. Organizations typically start with one of these and expand outward. What changes is the common data layer that enables coordinated AI decision-making, serving as the connective tissue underneath.

Platformization is not coincidental with AI’s emergence. Agentic AI needs connected, continuously updated data to accurately reason across signals and take autonomous action. Fragmented architectures, where telemetry is siloed and pipelines require manual effort, cannot support AI-driven SOC operations at scale. Platform adoption and AI adoption are converging because AI’s data requirements have made integration a structural necessity.

The survey makes the infrastructure connection an explicit one. The top-cited benefit of investing in a data lake for SecOps is supporting AI-driven SOC workloads and agents. Organizations that built the data foundation early have already cleared the barrier stalling others. Those who haven’t, face a prerequisite gap, and the distance is widening rapidly. Architectural readiness is the variable that determines how far AI investments can scale.

Job Satisfaction Is Rising

Every discussion of AI in the SOC centers on detection and response metrics. This report has those too, but there is a finding that security leaders managing attrition should weigh: analyst burnout is declining.

As AI handles repetitive, high-volume triage work, analysts report rising job satisfaction. The role is shifting away from processing an endless queue and toward investigation, threat hunting, and judgment-intensive work. In a market where SOC analyst turnover remains a persistent operational cost, that shift carries real dollar value.

The analyst role evolves, becoming more strategic and more consequential.

A New Attack Surface

The same AI systems changing how SOCs operate are also creating new targets. Adversaries are already probing AI infrastructure including agents, data pipelines, model endpoints, and the governance gaps that emerge when controls lag behind adoption. The report surfaces this tension clearly: Organizations are deploying AI faster than they are securing it.

An AI agent with misconfigured access or an unmonitored data pipeline is an exposure. Securing the AI infrastructure that powers the SOC is happening alongside deployment, whether organizations have planned for it or not. Those without a clear governance posture are accepting risk that may not be priced into their AI investment case.

The potential of GenAI and agentic AI in the SOC is already being realized. The organizations that capture it fully are those building governance alongside deployment. The platform that runs the Autonomous SOC and the platform that secures it are, increasingly, the same platform.

SentinelOne’s Vision: The Autonomous SOC

Everything the report surfaces, from AI returns arriving before maturity to platform consolidation to the improving analyst experience, points to how these are expressions of the same shift. The foundation that enables early AI returns is the same one that determines how far those returns scale, how capable analysts become, and how well the security of AI itself is governed.

The findings align with how SentinelOne has defined the path to autonomous security operations: A progression from AI-assisted triage at early maturity levels to increasingly autonomous investigation, threat hunting, and response, with humans in strategic and governing roles. The report validates that the market is moving through exactly that sequence. Organizations that understand the architecture behind it (the platform integration, the common data layer, the governance controls) are positioning themselves to capture returns at every stage rather than waiting for the destination.

The full 451 Research report goes further into detail, covering what progression looks like at each maturity level, the specific barriers organizations are encountering, and the data behind each finding in full.

Read the full 451 Research report to learn more about how AI is reshaping cybersecurity.

Third-Party & Intellectual Property Disclaimers

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.

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.

The Good | U.S. Charges Iranian Cyberattackers Over Mass Intellectual Property Theft

The U.S. Justice Department has indicted 17 Iranian nationals associated with the Mabna Institute, a state-sponsored hacking-for-hire firm, for executing a massive global cyber espionage campaign. Operating since 2013, the malicious network systematically targeted academic institutions, private corporations, and government agencies to harvest intellectual property. While nine defendants faced prior indictments in 2018 for targeting more than 300 universities and private firms, newly unsealed charges add eight individuals to the sweeping legal action. Investigators reveal that the hackers worked on behalf of Iran’s Islamic Revolutionary Guard Corps (IRGC), various government bodies, and commercial clients.

The campaign targeted the credentials of hundreds of thousands professors worldwide, compromising roughly 80,000 of them. By exploiting these accounts, the actors exfiltrated over 31 terabytes of sensitive academic data, including journals, dissertations, and ebooks valued at $3.4 billion. The intrusions affected 178 universities, including 144 in the United States, alongside 53 private firms, two non-governmental organizations, and 10 state agencies. Beyond academic espionage, the defendants targeted private entities, including an extortion scheme against entertainment network HBO for $6 million dollars in Bitcoin.

The State Department announced rewards of up to $10 million for information leading to the apprehension of five key defendants and established an anonymous Tor network link to receive tips. All defendants currently face multiple federal charges, including conspiracy to commit computer intrusions, wire fraud, and aggravated identity theft, which can incur maximum penalties of twenty years in prison. This prosecution reinforces the government’s long-term commitment to pursuing foreign threat actors who target domestic organizations, regardless of how much time passes.

The Bad | Medusa Ransomware Syndicate Compromises 500 Critical Infrastructure Organizations

A joint advisory issued by federal agencies warns that the Medusa ransomware syndicate has systematically breached over 500 critical infrastructure organizations in the United States since June 2021. Released in coordination with CISA, the FBI, and the Department of Health and Human Services (HHS), the alert covers Medusa’s rapid escalation across healthcare, manufacturing, defense, and financial sectors. This release is an update to a March 2025 assessment, which previously estimated the victim count at just over 300 entities. Other targeted areas include education, medical, legal, and insurance systems.

While the threat actors have been active since January 2021, they experienced a massive surge in their operations in 2023 following the launch of the “Medusa Blog” leak site. Operators leverage this portal to publish stolen files, applying double extortion tactics to coerce non-paying victims. Structurally, the syndicate operates under a Ransomware-as-a-Service (RaaS) model, employing an aggressive affiliate program. Developers actively recruit initial access brokers on dark web forums, offering payments ranging from $100 to $1 million dollars for exclusive access. Defenders should not confuse this threat with MedusaLocker, a separate ransomware family, or the Medusa and TangleBot mobile malware families, which also share similar naming.

As a defense against these intrusions, the agencies urge organizations to implement robust defenses. Security teams must secure and patch exposed systems to protect firmware, operating systems, and software from exploitation. Additionally, administrators should restrict access from untrusted origins to remote services and implement network segmentation to prevent lateral movement.

The Ugly | Hackers Exploit Critical Windows IKE Protocol Vulnerability

CISA has added a critical remote code execution (RCE) vulnerability in the Windows Internet Key Exchange Service Extensions component, known as MS-IKEE, to its catalog of actively exploited flaws. Tracked as CVE-2026-33824, this severe double-free vulnerability affects all supported versions of Windows 10, Windows 11, and Windows Server 2016, 2019, 2022, and 2025. The flaw enables unauthenticated, remote attackers to execute arbitrary code by simply transmitting maliciously crafted UDP packets over port 500 or port 4500 to Windows systems running IKE version 2. Because this protocol component handles crucial features like cryptographically generated address authentication, denial-of-service protection, and third-party interoperability, exposed systems remain highly vulnerable to complete network compromise.

Although Microsoft addressed the issue during April 2026 Patch Tuesday, the firm has not yet updated its official advisory to reflect the ongoing in-the-wild exploitation. Under the urgent mandate of Binding Operational Directive 26-04, CISA ordered all U.S. Federal Civilian Executive Branch (FCEB) agencies to secure their vulnerable systems within three days. While this binding directive specifically targets federal networks, cybersecurity officials strongly urge all enterprise network defenders to prioritize applying the security updates immediately to halt active intrusions.

For organizations unable to immediately deploy the patch, Microsoft recommends restricting inbound UDP ports 500 and 4500 on systems where IKE is not required, or configuring host firewalls to only accept traffic from verified peer IP addresses. The rapid exploitation of this protocol flaw joins a growing list of recently abused Microsoft vulnerabilities, including a high-severity Windows Task Host bug and a SharePoint RCE vulnerability now heavily leveraged in ransomware campaigns. Since late 2021, CISA has cataloged hundreds of actively exploited Microsoft vulnerabilities to help defenders aggressively prioritize patching.

The Good | Courts Sentence “The Com” Online Syndicate Member for Blackmail & Sextortion

A court in the UK has sentenced a member of the decentralized online cybercrime collective known as “The Com” to two years in prison following an investigation by the National Crime Agency (NCA). Justin Swaddle, who operated under the digital aliases ‘Epstein’, ‘Rugen’, and ‘Moscow’ across Discord, Snapchat, and Telegram, pleaded guilty to multiple criminal charges of blackmail and child abuse. In addition to his sentence, the court ordered Swaddle’s placement on the National Sex Offenders Register and imposed a ten-year Sexual Harm Prevention Order.

Investigators revealed that Swaddle systematically targeted and groomed young, vulnerable victims globally, using popular chat platforms to exploit his targets. The prosecution identified 117 female victims worldwide, aged thirteen to seventeen, whom Swaddle coerced into performing severe acts of self-harm and generating explicit material. Rather than seeking financial gain, Swaddle was reportedly motivated by the online status and notoriety he obtained by sharing the media within exclusive subgroups. When victims resisted his demands, he used video recordings, home addresses, and school details to blackmail them into compliance.

The investigation, which the NCA initiated in January 2024 following Swaddle’s initial arrest by West Yorkshire Police, required extensive cross-border coordination. British officers collaborated closely with law enforcement agencies in the United States, Australia, Canada, Norway, and New Zealand to identify and safeguard affected children worldwide.

Authorities emphasize that The Com functions as a highly dangerous, loose-knit global network subdivided into specialized factions, including groups dedicated to physical violence, sexual coercion, financial extortion, and high-profile corporate ransomware operations.

The Bad | Agencies Warn of Expanding Gunra Ransomware Operations Targeting Critical Infrastructure

U.S., U.K., and South Korean intelligence and law enforcement agencies have issued a joint cybersecurity advisory warning global critical infrastructure organizations about escalating threats by Gunra ransomware. First appearing in April 2025 as a variant specializing in double extortion, the group uses malware derived from leaked Conti source code. Gunra targets public health, financial, and government sectors worldwide, with a heavy concentration of victims in Australia, East Asia, and Europe.

To establish initial access, operators exploit critical authentication vulnerabilities, specifically CVE-2024-55591 and CVE-2025-24472, in FortiOS and FortiProxy software, alongside security flaws in VPN gateways. While campaigns initially focused on Windows environments, the threat actors expanded to cross-platform operations by introducing a Linux variant. In January 2026, the group launched a formal Ransomware-as-a-Service (RaaS) affiliate program under the brand “Golden Community”, actively recruiting penetration testers to serve as initial access brokers. Attackers deploy their payloads via phishing and conduct ransom negotiations via WhatsApp.

Once inside a network, the actors utilize Impacket tools for credential dumping and lateral movement. They execute malicious tasks during nighttime hours, exfiltrating stolen documents to cloud services and deleting critical backup and archived data across primary and recovery centers. The malware leverages advanced ciphers like Salsa20 or ChaCha20 to encrypt terabytes of data in a limited timeframe.

Strong links have been identified between Gunra and North Korean state-backed threat actors, observing overlapping infrastructure and techniques, such as the exploitation of zero-day flaws in certificate signing software. Despite its sophistication, a catastrophic cryptographic flaw in Gunra’s Linux variant allows victims to fully recover encrypted files.

The Ugly | New ‘ShieldBreak’ Zero-Day Exploit Bypasses Microsoft Defender Protections

A security researcher known as ‘Nightmare Eclipse’ has released a novel Microsoft Defender zero-day exploit dubbed ‘ShieldBreak’ shortly after this month’s Patch Tuesday update. The vulnerability operates as a direct patch bypass for RoguePlanet, a separate privilege escalation flaw in Microsoft’s malware protection engine that was patched in July.

Although both flaws lead to SYSTEM-level compromise, researchers confirm the underlying exploitation techniques differ significantly. While the original RoguePlanet bug exploits a filesystem race condition using virtual disks to overwrite system files, ShieldBreak hijacks cloud-hydration processes.

Specifically, the exploit leverages user-mode callback hooks to modify file contents during a cloud-hydration scan via the Cloud Filter API. To achieve privilege escalation, an attacker first places a standard test file and utilizes Object Manager symbolic links to redirect Defender’s path to the system32 directory. During scanning, the exploit uses the Common Log File System to swap the file identity and plant a malicious DLL, phoneinfo.dll, where a default system file does not exist. Triggering a scheduled Windows Error Reporting task subsequently forces the system to load this rogue library, spawning a shell with highest privileges.

The proof-of-concept operates with a 100% success rate on fully patched installations of Windows 11 25H2 and Windows Server 2025. Although Windows 10 remains vulnerable to the flaw, the current code does not natively support those legacy systems. Analysts note that Microsoft Defender must be actively enabled for the exploit chain to function.

The release intensifies an ongoing dispute between Microsoft and the researcher over bug bounty policies and recent threats of legal action.

The Good | Snowflake Hacker Pleads Guilty as Ransom Cartel Creator Draws 16 Years

Connor Riley Moucka pleaded guilty in Seattle federal court this week to computer fraud, wire fraud, aggravated identity theft and conspiracy over the 2024 breaches of Snowflake customer accounts.

The intrusions reached at least 165 organizations and exposed records tied to at least 100 million people. Prosecutors say Moucka collected at least $495,000 from ransoms and data sales. He is due to be sentenced on October 27, facing a two-year mandatory minimum on the identity theft count and up to 30 years on the rest.

Every Snowflake account the group reached had multi-factor authentication switched off, and the credentials, some harvested by infostealer malware as far back as November 2020, had never been rotated. The gang didn’t need to find a vulnerability in Snowflake’s platform to exploit; it turned out that more than three-quarters of the compromised accounts had prior credential exposure, and none had network allow lists in place.

In separate news, The Department of Justice announced that Maksim Silnikau, the Belarusian national who built and administered the Ransom Cartel ransomware operation, was sentenced to 16 years for conspiracy and aggravated identity theft.

Ransom Cartel creator sentenced 16 yrs for REvil-linked RaaS targeting 18 orgs, $6.7M losses. https://intel.threadlinqs.com/threat/TL-2026-1902 #ThreatIntel #CVE_2021_1675 #CVE_2021_34527 #Ransomcartel

[image or embed]

— Threadlinqs (@threadlinqs.bsky.social) August 6, 2026 at 3:51 AM

Between 2021 and 2023, Silnikau recruited affiliates through underground forums, supplying stolen credentials and encryption tools while running an affiliate site that handled negotiations and revenue splits.

The Ranson Cartel attempted to extort at least $5.2 million from at least 18 companies, including a robotic-surgery startup disrupted for two months and law firms that paid $125,000 and $300,000 after weeks of downtime.

Silnikau was arrested in Spain in 2023, fled while awaiting extradition, and was caught trying to cross into Belarus before consenting to face trial in the United States.

The Bad | Claude Mythos 5 Spends 34 Hours Trying to Backdoor Real Code

The UK AI Security Institute (AISI) reported Tuesday that an agent running Claude Mythos 5 spent 34 hours trying to merge a malware dropper into a real open-source project during a security evaluation, after searching the open internet and landing on a real, unconnected repository whose name happened to share a keyword with the test’s fictional scenario.

The agent researched the maintainers, opened a pull request pairing a hidden dropper with a working bug fix, and cycled through three payload versions as each was caught. When a human reviewer flagged the code as malicious, the agent’s account denied it, force-pushed a rewritten branch history, and used a second account to vouch for the code. It also hid a prompt injection inside a GitHub issue aimed at AI coding assistants. The maintainer closed the pull request despite the cover-up.

Across 122 evaluation runs, AISI logged 19 unsanctioned actions in 10 runs, 17 involving Mythos 5 and two involving GPT-5.6 Sol, though AISI notes that figure is a count, not a rate. Both models had cyber safeguards off and open internet access by design, a setup meant to measure raw capability rather than mirror production use.

Nothing escaped AISI’s sandbox, and AISI found no evidence of real-world harm. The reviewer had the chance to catch it only because GitHub holds checks on a first-time contributor’s pull request until a maintainer approves them.

Anthropic’s own July 30 review of 141,006 evaluation runs found a separate Mythos 5 run that published malware to PyPI, downloaded and ran on 15 real systems within an hour. OpenAI reported a similar incident days earlier, exploiting a zero-day to reach Hugging Face’s production database. In each case, a test environment meant to stay sealed did not, and a model reached through it before anyone caught it.

Not to be outdone, Meta became the third lab in recent weeks to disclose an AI agent reaching into systems outside a security test. The exposure traced to Irregular, the same firm behind OpenAI’s second incident, whose misconfiguration gave a Meta model internet access it used to exploit a real company’s system.

The Ugly | ChainDrop Worm Compromises Over 1,300 npm Packages With Two Billion Monthly Downloads

A self-propagating worm known as ChainDrop compromised at least 868 npm packages across 1,381 versions, part of a broader campaign researchers put at more than 1,300 packages with a combined two billion monthly downloads.

The mass compromise began Tuesday when an attacker breached the GitHub account of a maintainer who controlled several widely used caching libraries, including Keyv, Cacheable, flat-cache and file-entry-cache. The worm then self-propagated to other maintainers’ packages, including ones tied to Deliveroo, Ornikar, OneReach, Picsart, Qlik and ServiceTitan.

The worm pushed malicious commits directly to each project’s main branch and triggered a new release through a GitHub Actions workflow, giving the poisoned npm packages valid provenance signatures.

A preinstall script added to package.json ran automatically on npm install, pulling down the Bun JavaScript runtime and using it to execute an obfuscated infostealer that harvested GitHub tokens, npm tokens, AWS and Kubernetes credentials, HashiCorp Vault secrets, database credentials and a run of other cloud and developer logins.

Every stolen token was checked against npm’s own whoami endpoint before the haul was encrypted and sent to a public GitHub repository, with any credentials belonging to other maintainers repeating the process on their packages.

ChainDrop is built on Shai-Hulud, the same self-propagating technique that has hit npm before. Each GitHub repo storing the stolen credentials is auto-named with random terms from Dune and carryies the description, “Shai-Hulud: Here We Go Again.”

While many of the auto-generated dead drop repos have since been taken down, the scale of the outbreak demonstrates how rapidly self-propagating worms can weaponize trusted credentials and automated pipelines. For a deeper breakdown and defensive strategies on this attack vector and other emerging supply chain risks, read the SentinelOne Annual Threat Report.

AI agents have made their way into virtually every layer of your environment. They run in the apps your employees adopt, on the endpoints where agents execute code, as users with access privileges those agents borrow, and in the cloud workloads that scale them. The platform that you trust to secure your endpoints is already already covering where AI operates today.

Here is the through-line that makes this one problem instead of four. Every AI attack starts as an interaction and ends as an action. A prompt gets manipulated, an agent gets tricked, and the damage lands on a host, reaches into an identity, or moves through the cloud. The tools that treat each surface as a separate product hand you fragments. SentinelOne treats them as one chain.

How SentinelOne Defends the Agentic Stack Today

Employee AI use is where the risk quietly enters. Your people are already using AI tools you never sanctioned, through browser, IDE, and API-connected apps and agentic AI tools. SentinelOne discovers that shadow AI use across browsers, IDEs, and copilots, highlights which tools and models are in play and governs it with policy. It keeps confidential data, PII, and secrets from reaching untrusted models, and it stops prompt injection and jailbreaks aimed at the tools you build. Legacy DLP reads patterns; this reads context, which is the only way to catch an attack aimed at AI systems that behave in a non-deterministic way.

The agent layer is where AI stops advising and starts acting. An employee’s prompt sends text. An agent sends commands, holds credentials, calls APIs, and chain actions without a human approving each step. That makes them non-human identities with standing access. SentinelOne governs that access. It inventories the agents and MCP servers already operating and scores what each one can reach and holds every agent to the privileges its task requires. Then it inspects the tool calls themselves, so an injected instruction gets blocked at the moment it would execute. What gets executed lands in a searchable record, and the same enforcement doubles as a kill switch.

While governance decides what an agent is allowed to do, the endpoint is where you find out what it actually did.

The endpoint is where agents execute. This is the frontier, and where SentinelOne has protected customers for over a decade. Our behavioral engine judges what a process does, not what it claims to be. That is how we caught QUIETVAULT – malware that spins up AI agents in “yolo” mode to exfiltrate secrets to GitHub. It is how we autonomously stopped the LiteLLM supply chain attack, where adversaries weaponized the Claude CLI to install a malicious payload. It is how we surfaced a DLL side-loading attack hidden inside an AI tool installer. Real detections, on the endpoint, today. Agents run on the host, and so do we.

The identity is where a hijacked agent runs next. Picture an employee’s AI coding agent that gets hijacked mid-task. It spawns a shell and reaches for cached credentials and cloud session tokens, trying to stop being a process and start being the user. That pivot to identity is what unlocks lateral movement, and it is where most AI attacks are headed. SentinelOne meets the move. It secures human and non-human identities alike, and seeds the environment with decoy credentials and honeytokens no legitimate user ever touches. The instant the hijacked agent grabs one, the trap trips, and Identity responds by forcing an MFA re-challenge, disabling the account, or isolating the host. Authorization at login is not enough. Access gets validated against behavior and pulled at runtime.

The cloud is where AI workloads scale. Consider an internal AI agent running in a Kubernetes cluster with standing access to a customer database. Security teams keep asking the same question about deployments like this. Where is the model connecting, and who is it talking to? SentinelOne answers with eBPF-native runtime protection that judges how the workload actually behaves, and flags the moment that inference service reaches an endpoint it has never touched before. It covers the control plane the deployment depends on, the secrets it reads, the pipelines it runs through, and the data it can access. Defending the AI you build takes more than watching it, it takes action on the workload in real time.

SentinelOne’s Singularity Platform Advantage

Each of these surfaces matters on its own. What closes the kill chain is following an attack across them without losing it at the handoff. This is where a single platform earns its keep. AI telemetry already streams into the Singularity Data Lake, alongside the endpoint data the platform has correlated for years. As identity and cloud signals join that same view, an analyst follows one attack from first prompt to final action, without stitching logs across six tools at two in the morning. A manipulated prompt, the process it spawns, the credential it reaches for, and the cloud resource it targets read as one story rather than six disconnected alerts.

Detection that only watches is observation. Runtime action is protection. When the Singularity Platform acts, autonomous response blocks the execution, rolls back the change, and revokes the access at the point of impact, without a human relaying orders between consoles. This is the difference between whether an attack is stopped or just gets logged.

That is the case for securing AI inside a platform built for autonomous runtime response. We are not adding a console to chase AI, we are extending the one already deployed where your agents run.

Questions to Ask When Assessing Your AI Security Options

When evaluating AI security, ask yourself three things.

• Does the solution protect the endpoint where agents actually execute, or is it a roadmap item?
• When a hijacked agent pivots to credentials and the cloud, does that telemetry land in the same platform, or are you manually connecting dots across three dashboards?
• Can the solution act at the moment of execution, or only tell me what already happened?

SentinelOne protects the surfaces where AI runs today. This includes the apps your employees use, the agents they deploy, the endpoints where agents execute, the identities they borrow, and the cloud where they scale. One platform, built for autonomous response. While AI has changed the attack, it does not have to change your architecture.

See it for yourself. Talk to our team about securing AI across your endpoints, identities, cloud, and the AI apps your employees already use, all from the platform you run today. Contact SentinelOne today.

Third-Party Trademark 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.

The Good | Authorities Disrupt “The Com”, Release Security Guidelines & Charge Telegram CEO

Europol and law enforcement partners from nine countries have flagged over 4000 URLs for removal to disrupt the online ecosystem of The Com. Operating as a decentralized network, The Com targets and recruits vulnerable youth across social media and gaming platforms.

Investigators report the syndicate’s content actively promotes self-harm, child exploitation, and physical attacks, while providing instructional manuals for swatting and arson. This multi-week joint operation builds upon Project Compass, a year-long international initiative that previously resulted in 30 arrests and identified 179 suspects linked to the criminal network.

From U.S. and Australian governments, a new joint cybersecurity guidance urges critical infrastructure organizations to proactively prepare isolation plans for operational technology systems. The advisory provides recommendations for physically and logically disconnecting vital infrastructure from corporate networks during severe cyberattacks.

Since state-sponsored threat actors and cybercriminals continuously target these essential sectors to facilitate espionage, data extortion, and disruptive operations, such resources help businesses shore up their operational resilience, documentation, and testing procedures.

The Russian Federal Security Service (FSB) has formally charged Telegram founder Pavel Durov with aiding terrorist activities and violating federal laws regarding prohibited information. Authorities accuse the messaging platform of failing to remove channels and automated bots allegedly operated by Ukrainian special services.

According to Russian intelligence, Ukrainian operatives leveraged a Telegram dating chatbot to psychologically manipulate and recruit young Russian men into sharing physical geolocations before coercing them into executing armed attacks and arson against domestic critical infrastructure.

This charge is the latest action against Telegram preceded by Durov’s arrest in 2024, restrictions placed on the platform, and a near-blockade from earlier this year.

The Bad | Theft Victims Sue Apple Over Fraudulent Cryptocurrency Wallet Application

Three individuals have filed a lawsuit against Apple after losing approximately $1.8 million in Bitcoin to a fraudulent cryptocurrency application housed on the official App Store. Between May and August 2025, the plaintiffs downloaded a malicious app impersonating “Sparrow Wallet”, a legitimate platform exclusively available on desktop operating systems.

The fraudulent app instructed users to input their secret recovery seed phrases during the initial setup process. Once victims entered these credentials, scammers immediately transferred the cryptocurrency to unauthorized external addresses.

The legal complaint alleges that Apple failed to adequately monitor its software marketplace while falsely promoting the App Store as a secure environment. Despite warnings from the real developer behind Sparrow Wallet who called out impersonator applications more than a year before these specific incidents occurred, Apple had taken no action.

Now, the plaintiffs claim the marketplace even featured the fraudulent software within curated cryptocurrency collections, effectively recommending the malicious tool to unsuspecting victims.

There is still a scam ‘Sparrow Wallet’ app on the @Apple App Store, despite myself and others having reported it weeks ago.

Worse, you have to install it to report it.

Always go to the wallet’s website to find the link to download it. App stores will not protect you.

— Craig Raw (@craigraw) January 6, 2024

Financial theft within mobile ecosystems continues to grow as researchers recently identified dozens of similar wallet impersonators actively targeting user recovery phrases and keys across the Apple App Store. In response to the allegations, Apple’s filing stated that it takes swift action to remove infringing content and provides dedicated reporting mechanisms for suspected fraud.

The plaintiffs currently seek full financial reimbursement, compensatory damages, and a formal court mandate requiring the tech giant to publicly disclose and systematically improve its internal procedures for detecting and removing fraudulent software submissions.

The Ugly | Anthropic Joins OpenAI in Finding Its Models Reached Real Companies During Cyber Evals

Anthropic disclosed this week that three of its models reached real production systems during cybersecurity testing. After reviewing 141,006 evaluation runs, it identified three incidents in which a Claude model reached the open internet from inside the environment of one of its third-party evaluation partners, and then accessed the systems of three organizations.

Unlike OpenAI’s recent breach of Hugging Face, no zero-day was involved, according to Anthropic. A misconfiguration had left machines in the evaluation with live internet access.

In one incident, a model built a malicious Python package and published it to PyPI, the public registry for Python software. The package was live for about an hour, during which time it was downloaded and run on 15 real systems. The downloaders included a security vendor’s scanner that installs packages automatically to check them for malware, leading to the model’s code exfiltrating that company’s credentials.

Anthropic said it found no evidence of a model pursuing a goal of its own, characterizing the incidents as a harness and operational failure rather than a model alignment failure, and noted that the safeguards it ships on released models would have blocked the behavior.

OpenAI also updated its account of the Hugging Face breach this week, revealing the same models had also used publicly exposed credentials to compromise accounts at four other services.

OpenAI said the models configured one compromised account as an outbound relay and staging server and used a second for data storage. The remaining two accounts were accessed in read-only mode.

Although OpenAI’s models extracted partial datasets containing CyberGym solutions and operated multiple concurrent workloads, the activity ultimately left critical encryption keys behind, exposing the operation. OpenAI said it continues to review the incident alongside external auditors and has restricted its pre-release model from further internal research access.