In September, a new breed of malware distributed via compromised Node Package Manager (npm) packages made headlines. It was dubbed “Shai-Hulud”, and we published an in-depth analysis of it in another post. Recently, a new version was discovered.
Shai Hulud 2.0 is a type of two-stage worm-like malware that spreads by compromising npm tokens to republish trusted packages with a malicious payload. More than 800 npm packages have been infected by this version of the worm.
According to our telemetry, the victims of this campaign include individuals and organizations worldwide, with most infections observed in Russia, India, Vietnam, Brazil, China, Türkiye, and France.
Technical analysis
When a developer installs an infected npm package, the setup_bun.js script runs during the preinstall stage, as specified in the modified package.json file.
Bootstrap script
The initial-stage script setup_bun.js is left intentionally unobfuscated and well documented to masquerade as a harmless tool for installing the legitimate Bun JavaScript runtime. It checks common installation paths for Bun and, if the runtime is missing, installs it from an official source in a platform-specific manner. This seemingly routine behavior conceals its true purpose: preparing the execution environment for later stages of the malware.
The installed Bun runtime then executes the second-stage payload, bun_environment.js, a 10MB malware script obfuscated with an obfuscate.io-like tool. This script is responsible for the main malicious activity.
Stealing credentials
Shai Hulud 2.0 is built to harvest secrets from various environments. Upon execution, it immediately searches several sources for sensitive data, such as:
GitHub secrets: the malware searches environment variables and the GitHub CLI configuration for values starting with ghp_ or gho_. It also creates a malicious workflow yml in victim repositories, which is then used to obtain GitHub Actions secrets.
Cloud credentials: the malware searches for cloud credentials across AWS, Azure, and Google Cloud by querying cloud instance metadata services and using official SDKs to enumerate credentials from environment variables and local configuration files.
Local files: it downloads and runs the TruffleHog tool to aggressively scan the entire filesystem for credentials.
Then all the exfiltrated data is sent through the established communication channel, which we describe in more detail in the next section.
Data exfiltration through GitHub
To exfiltrate the stolen data, the malware sets up a communication channel via a public GitHub repository. For this purpose, it uses the victim’s GitHub access token if found in environment variables and the GitHub CLI configuration.
After that, the malware creates a repository with a randomly generated 18-character name and a marker in its description. This repository then serves as a data storage to which all stolen credentials and system information are uploaded.
If the token is not found, the script attempts to obtain a previously stolen token from another victim by searching through GitHub repositories for those containing the text, “Sha1-Hulud: The Second Coming.” in the description.
Worm spreading across packages
For subsequent self-replication via embedding into npm packages, the script scans .npmrc configuration files in the home directory and the current directory in an attempt to find an npm registry authorization token.
If this is successful, it validates the token by sending a probe request to the npm /-/whoami API endpoint, after which the script retrieves a list of up to 100 packages maintained by the victim.
For each package, it injects the malicious files setup_bun.js and bun_environment.js via bundleAssets and updates the package configuration by setting setup_bun.js as a pre-installation script and incrementing the package version. The modified package is then published to the npm registry.
Destructive responses to failure
If the malware fails to obtain a valid npm token and is also unable to get a valid GitHub token, making data exfiltration impossible, it triggers a destructive payload that wipes user files, primarily those in the home directory.
Our solutions detect the family described here as HEUR:Worm.Script.Shulud.gen.
Since September of this year, Kaspersky has blocked over 1700 Shai Hulud 2.0 attacks on user machines. Of these, 18.5% affected users in Russia, 10.7% occurred in India, and 9.7% in Brazil.
TOP 10 countries and territories affected by Shai Hulud 2.0 attacks (download)
We continue tracking this malicious activity and provide up-to-date information to our customers via the Kaspersky Open Source Software Threats Data Feed. The feed includes all packages affected by Shai-Hulud, as well as information on other open-source components that exhibit malicious behaviour, contain backdoors, or include undeclared capabilities.
Huntress threat researchers are tracking a ClickFix campaign that includes a variant of the scheme in which the malicious code is hidden in the fake image of a Windows Update and, if inadvertently downloaded by victims, will deploy the info-stealing malware LummaC2 and Rhadamanthys.
Tsundere is a new botnet, discovered by our Kaspersky GReAT around mid-2025. We have correlated this threat with previous reports from October 2024 that reveal code similarities, as well as the use of the same C2 retrieval method and wallet. In that instance, the threat actor created malicious Node.js packages and used the Node Package Manager (npm) to deliver the payload. The packages were named similarly to popular packages, employing a technique known as typosquatting. The threat actor targeted libraries such as Puppeteer, Bignum.js, and various cryptocurrency packages, resulting in 287 identified malware packages. This supply chain attack affected Windows, Linux, and macOS users, but it was short-lived, as the packages were removed and the threat actor abandoned this infection method after being detected.
The threat actor resurfaced around July 2025 with a new threat. We have dubbed it the Tsundere bot after its C2 panel. This botnet is currently expanding and poses an active threat to Windows users.
Initial infection
Currently, there is no conclusive evidence on how the Tsundere bot implants are being spread. However, in one documented case, the implant was installed via a Remote Monitoring and Management (RMM) tool, which downloaded a file named pdf.msi from a compromised website. In other instances, the sample names suggest that the implants are being disseminated using the lure of popular Windows games, particularly first-person shooters. The samples found in the wild have names such as “valorant”, “cs2”, or “r6x”, which appear to be attempts to capitalize on the popularity of these games among piracy communities.
Malware implants
According to the C2 panel, there are two distinct formats for spreading the implant: via an MSI installer and via a PowerShell script. Implants are automatically generated by the C2 panel (as described in the Infrastructure section).
MSI installer
The MSI installer was often disguised as a fake installer for popular games and other software to lure new victims. Notably, at the time of our research, it had a very low detection rate.
The installer contains a list of data and JavaScript files that are updated with each new build, as well as the necessary Node.js executables to run these scripts. The following is a list of files included in the sample:
The last three files in the list are legitimate Node.js files. They are installed alongside the malicious artifacts in the user’s AppData\Local\nodejs directory.
An examination of the CustomAction table reveals the process by which Windows Installer executes the malware and installs the Tsundere bot:
This will execute Node.js code that spawns a new Node.js process, which runs the loader JavaScript code (in this case, B4jHWzJnlABB2B7). The resulting child process runs in the background, remaining hidden from the user.
Loader script
The loader script is responsible for ensuring the correct decryption and execution of the main bot script, which handles npm unpackaging and configuration. Although the loader code, similar to the code for the other JavaScript files, is obfuscated, it can be deobfuscated using open-source tools. Once executed, the loader attempts to locate the unpackaging script and configuration for the Tsundere bot, decrypts them using the AES-256 CBC cryptographic algorithm with a build-specific key and IV, and saves the decrypted files under different filenames.
The configuration file is a JSON that defines a directory and file structure, as well as file contents, which the malware will recreate. The malware author refers to this file as “config”, but its primary purpose is to package and deploy the Node.js package manager (npm) without requiring manual installation or downloading. The unpackaging script is responsible for recreating this structure, including the node_modules directory with all its libraries, which contains packages necessary for the malware to run.
With the environment now set up, the malware proceeds to install three packages to the node_modules directory using npm:
ws: a WebSocket networking library
ethers: a library for communicating with Ethereum
pm2: a Node.js process management tool
Loader script installing the necessary toolset for Tsundere persistence and execution
The pm2 package is installed to ensure the Tsundere bot remains active and used to launch the bot. Additionally, pm2 helps achieve persistence on the system by writing to the registry and configuring itself to restart the process upon login.
PowerShell infector
The PowerShell version of the infector operates in a more compact and simplified manner. Instead of utilizing a configuration file and an unpacker — as done with the MSI installer — it downloads the ZIP file node-v18.17.0-win-x64.zip from the official Node.js website nodejs[.]org and extracts it to the AppData\Local\NodeJS directory, ultimately deploying Node.js on the targeted device. The infector then uses the AES-256-CBC algorithm to decrypt two large hexadecimal-encoded variables, which correspond to the bot script and a persistence script. These decrypted files, along with a package.json file are written to the disk. The package.json file contains information about the malicious Node.js package, as well as the necessary libraries to be installed, including the ws and ethers packages. Finally, the infector runs both scripts, starting with the persistence script that is followed by the bot script.
The PowerShell infector creates a package file with the implant dependencies
Persistence is achieved through the same mechanism observed in the MSI installer: the script creates a value in the HKCU:\Software\Microsoft\Windows\CurrentVersion\Run registry key that points to itself. It then overwrites itself with a new script that is Base64 decoded. This new script is responsible for ensuring the bot is executed on each login by spawning a new instance of the bot.
Tsundere bot
We will now delve into the Tsundere bot, examining its communication with the command-and-control (C2) server and its primary functionality.
C2 address retrieval
Web3 contracts, also known as smart contracts, are deployed on a blockchain via transactions from a wallet. These contracts can store data in variables, which can be modified by functions defined within the contract. In this case, the Tsundere botnet utilizes the Ethereum blockchain, where a method named setString(string _str) is defined to modify the state variable param1, allowing it to store a string. The string stored in param1 is used by the Tsundere botnet administrators to store new WebSocket C2 servers, which can be rotated at will and are immutable once written to the Ethereum blockchain.
The Tsundere botnet relies on two constant points of reference on the Ethereum blockchain:
In order to change the C2 server, the Tsundere botnet makes a transaction to update the state variable with a new address. Below is a transaction made on August 19, 2025, with a value of 0 ETH, which updates the address.
Smart contract containing the Tsundere botnet WebSocket C2
The state variable has a fixed length of 32 bytes, and a string of 24 bytes (see item [2] in the previous image) is stored within it. When this string is converted from hexadecimal to ASCII, it reveals the new WebSocket C2 server address: ws[:]//185.28.119[.]179:1234.
To obtain the C2 address, the bot contacts various public endpoints that provide remote procedure call (RPC) APIs, allowing them to interact with Ethereum blockchain nodes. At the start of the script, the bot calls a function named fetchAndUpdateIP, which iterates through a list of RPC providers. For each provider, it checks the transactions associated with the contract address and wallet owner, and then retrieves the string from the state variable containing the WebSocket address, as previously observed.
Malware code for retrieval of C2 from the smart contract
The Tsundere bot verifies that the C2 address starts with either ws:// or wss:// to ensure it is a valid WebSocket URL, and then sets the obtained string as the server URL. But before using this new URL, the bot first checks the system locale by retrieving the culture name of the machine to avoid infecting systems in the CIS region. If the system is not in the CIS region, the bot establishes a connection to the server via a WebSocket, setting up the necessary handlers for receiving, sending, and managing connection states, such as errors and closed sockets.
Bot handlers for communication
Communication
The communication flow between the client (Tsundere bot) and the server (WebSocket C2) is as follows:
The Tsundere bot establishes a WebSocket connection with the retrieved C2 address.
An AES key is transmitted immediately after the connection is established.
The bot sends an empty string to confirm receipt of the key.
The server then sends an IV, enabling the use of encrypted communication from that point on.
Encryption is required for all subsequent communication.
The bot transmits the OS information of the infected machine, including the MAC address, total memory, GPU information, and other details. This information is also used to generate a unique identifier (UUID).
The C2 server responds with a JSON object, acknowledging the connection and confirming the bot’s presence.
With the connection established, the client and server can exchange information freely.
To maintain the connection, keep-alive messages are sent every minute using ping/pong messages.
The bot sends encrypted responses as part of the ping/pong messages, ensuring continuous communication.
Tsundere communication process with the C2 via WebSockets
The connections are not authenticated through any additional means, making it possible for a fake client to establish a connection.
As previously mentioned, the client sends an encrypted ping message to the C2 server every minute, which returns a pong message. This ping-pong exchange serves as a mechanism for the C2 panel to maintain a list of currently active bots.
Functionality
The Tsundere bot is designed to allow the C2 server to send dynamic JavaScript code. When the C2 server sends a message with ID=1 to the bot, the message is evaluated as a new function and then executed. The result of this operation is sent back to the server via a custom function named serverSend, which is responsible for transmitting the result as a JSON object, encrypted for secure communication.
Tsundere bot evaluation code once functions are received from the C2
The ability to evaluate code makes the Tsundere bot relatively simple, but it also provides flexibility and dynamism, allowing the botnet administrators to adapt it to a wide range of actions.
However, during our observation period, we did not receive any commands or functions from the C2 server, possibly because the newly connected bot needed to be requested by other threat actors through the botnet panel before it could be utilized.
Infrastructure
The Tsundere bot utilizes WebSocket as its primary protocol for establishing connections with the C2 server. As mentioned earlier, at the time of writing, the malware was communicating with the WebSocket server located at 185.28.119[.]179, and our tests indicated that it was responding positively to bot connections.
The following table lists the IP addresses and ports extracted from the provided list of URLs:
IP
Port
First seen (contract update)
ASN
185.28.119[.]179
1234
2025-08-19
AS62005
196.251.72[.]192
1234
2025-08-03
AS401120
103.246.145[.]201
1234
2025-07-14
AS211381
193.24.123[.]68
3011
2025-06-21
AS200593
62.60.226[.]179
3001
2025-05-04
AS214351
Marketplace and control panel
No business is complete without a marketplace, and similarly, no botnet is complete without a control panel. The Tsundere botnet has both a marketplace and a control panel, which are integrated into the same frontend.
Tsundere botnet panel login
The notable aspect of Tsundere’s control panel, dubbed “Tsundere Netto” (version 2.4.4), is that it has an open registration system. Any user who accesses the login form can register and gain access to the panel, which features various tabs:
Bots: a dashboard displaying the number of bots under the user’s control
Settings: user settings and administrative functions
Build: if the user has an active license, they can create new bots using the two previously mentioned methodologies (MSI or PowerShell)
Market: this is the most interesting aspect of the panel, as it allows users to promote their individual bots and offer various services and functionalities to other threat actors. Each build can create a bot that performs a specific set of actions, which can then be offered to others
Monero wallet: a wallet service that enables users to make deposits or withdrawals
Socks proxy: a feature that allows users to utilize their bots as proxies for their traffic
Tsundere botnet control panel, building system and market
Each build generates a unique build ID, which is embedded in the implant and sent to the C2 server upon infection. This build ID can be linked to the user who created it. According to our research and analysis of other URLs found in the wild, builds are created through the panel and can be downloaded via the URL:
At the time of writing this, the panel typically has between 90 and 115 bots connected to the C2 server at any given time.
Attribution
Based on the text found in the implants, we can conclude with high confidence that the threat actor behind the Tsundere botnet is likely Russian-speaking. The use of the Russian language in the implants is consistent with previous attacks attributed to the same threat actor.
Russian being used throughout the code
Furthermore, our analysis suggests a connection between the Tsundere botnet and the 123 Stealer, a C++-based stealer available on the shadow market for $120 per month. This connection is based on the fact that both panels share the same server. Notably, the main domain serves as the frontend for the 123 Stealer panel, while the subdomain “idk.” is used for the Tsundere botnet panel.
123 Stealer C2 panel sharing Tsundere’s infrastructure and showcasing its author
By examining the available evidence, we can link both threats to a Russian-speaking threat actor known as “koneko”. Koneko was previously active on a dark web forum, where they promoted the 123 Stealer, as well as other malware, including a backdoor. Although our analysis of the backdoor revealed that it was not directly related to Tsundere, it shared similarities with the Tsundere botnet in that it was written in Node.js and used PowerShell or MSI as infectors. Before the dark web forum was seized and shut down, koneko’s profile featured the title “node malware senior”, further suggesting their expertise in Node.js-based malware.
Conclusion
The Tsundere botnet represents a renewed effort by a presumably identified threat actor to revamp their toolset. The Node.js-based bot is an evolution of an attack discovered in October of last year, and it now features a new strategy and even a new business model. Infections can occur through MSI and PowerShell files, which provides flexibility in terms of disguising installers, using phishing as a point of entry, or integrating with other attack mechanisms, making it an even more formidable threat.
Additionally, the botnet leverages a technique that is gaining popularity: utilizing web3 contracts, also known as “smart contracts”, to host command-and-control (C2) addresses, which enhances the resilience of the botnet infrastructure. The botnet’s possible author, koneko, is also involved in peddling other threats, such as the 123 Stealer, which suggests that the threat is likely to escalate rather than diminish in the coming months. As a result, it is essential to closely monitor this threat and be vigilant for related threats that may emerge in the near future.
Cryptocurrency wallets Note: These are wallets that have changed the C2 address in the smart contract since it was created.
0x73625B6cdFECC81A4899D221C732E1f73e504a32
0x10ca9bE67D03917e9938a7c28601663B191E4413
0xEc99D2C797Db6E0eBD664128EfED9265fBE54579
0xf11Cb0578EA61e2EDB8a4a12c02E3eF26E80fc36
0xdb8e8B0ef3ea1105A6D84b27Fc0bAA9845C66FD7
0x10ca9bE67D03917e9938a7c28601663B191E4413
0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84
0x46b0f9bA6F1fb89eb80347c92c9e91BDF1b9E8CC
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.
GhostCall campaign attack flow
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.
GhostHire campaign attack flow
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.
Overall behavior of the phishing site
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.
Initial page mimicking Zoom call joining behavior
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.
Fake Zoom meeting
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.
Clicking the link on macOS (left) and on Windows (right)
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.
Malicious code upon ClickFix
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.
General fake prompt to update the SDK file (left) and Windows-specific (right)
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.
Snippets of the AppleScript disguised as a Zoom SDK update
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.
Initial infection flow
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 prompting the victim to enter their password
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.
ZoomClutch success window displayed after password validation
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.
TeamsClutch authentication and success windows
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
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.
Base application and payload decryption
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.
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:
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>.
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)
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.
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:
Generate a random 10-character file name in the temp directory: /private/tmp/[random-chars]{10}.zip.
Save the downloaded data to that file path.
Extract the ZIP file using ditto -xk /private/tmp/[random-chars]{10}.zip /private/tmp/[random-chars]{10}.
Make the file executable using chmod +x /private/tmp/[random-chars]{10}/install.
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.
Check the .result file for the string “success”.
Send result to /report endpoint.
Increment the cid field and save the configuration.
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:
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.
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.
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.
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:
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.
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.
EXIF metadata of images generated by GPT-4o
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.
Victim’s profile image enhanced using GPT-4o
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.
Comments that appear to be AI-generated in the secrets stealer module
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.
Fake LinkedIn profile
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.
Fake Telegram account
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.
The same Telegram account changed to impersonate a Web3 company founder
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.
Uniroute malicious package is referenced via go.mod in the DeFi-related project
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.
The main malicious logic is implemented in the following files:
uniroute.go: the main entry point
win.go: Windows-specific malicious code
lin.go: Linux-specific malicious code
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.
Base64-encoded C2 URL in the malicious package
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.
Malicious TypeScript-based project
The malicious behavior is implemented in pages/api/hello.ts, and the hello API is fetched by NavBar.tsx with fetch('/api/hello').
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.
DownTroy delivery process
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.
Overall Windows infection chain
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.
Binary blob structure
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:
In September 2024, we detected malicious activity targeting financial (trading and brokerage) firms through the distribution of malicious .scr (screen saver) files disguised as financial documents via Skype messenger. The threat actor deployed a newly identified Remote Access Trojan (RAT) named GodRAT, which is based on the Gh0st RAT codebase. To evade detection, the attackers used steganography to embed shellcode within image files. This shellcode downloads GodRAT from a Command-and-Control (C2) server.
GodRAT supports additional plugins. Once installed, attackers utilized the FileManager plugin to explore the victim’s systems and deployed browser password stealers to extract credentials. In addition to GodRAT, they also used AsyncRAT as a secondary implant to maintain extended access.
GodRAT is very similar to the AwesomePuppet, another Gh0st RAT-based backdoor, which we reported in 2023, both in its code and distribution method. This suggests that it is probably an evolution of AwesomePuppet, which is in turn likely connected to the Winnti APT.
As of this blog’s publication, the attack remains active, with the most recent detection observed on August 12, 2025. Below is a timeline of attacks based on detections of GodRAT shellcode injector executables. In addition to malicious .scr (screen saver) files, attackers also used .pif (Program Information File) files masquerading as financial documents.
GodRAT shellcode injector executable MD5
File name
Detection date
Country/territory
Distribution
cf7100bbb5ceb587f04a1f42939e24ab
2023-2024ClientList&.scr
2024.09.09
Hong Kong
via Skype
e723258b75fee6fbd8095f0a2ae7e53c
2024-11-15_23.45.45 .scr
2024.11.28
Hong Kong
via Skype
d09fd377d8566b9d7a5880649a0192b4
2024-08-01_2024-12-31Data.scr
2025.01.09
United Arab Emirates
via Skype
a6352b2c4a3e00de9e84295c8d505dad
2025TopDataTransaction&.scr
2025.02.28
United Arab Emirates
NA
6c12ec3795b082ec8d5e294e6a5d6d01
2024-2025Top&Data.scr
2025-03-17
United Arab Emirates
via Skype
bb23d0e061a8535f4cb8c6d724839883
Corporate customer transaction &volume.pif
corporate customer transaction &volume.zip
company self-media account application qualifications&.zip
2025-05-26
United Arab Emirates
Lebanon
Malaysia
NA
160a80a754fd14679e5a7b5fc4aed672
个人信息资料&.pdf.pif
informasi pribadi &pelanggan global.pdf.pif
global customers preferential deposit steps&.pif
2025-07-17
Hong Kong
NA
2750d4d40902d123a80d24f0d0acc454
2025TopClineData&1.scr
2025-08-12
United Arab Emirates
NA
441b35ee7c366d4644dca741f51eb729
2025TopClineData&.scr
2025-08-12
Jordan
NA
Technical details
Malware implants
Shellcode loaders
We identified the use of two types of shellcode loaders, both of which execute the shellcode by injecting it into their own process. The first embeds the shellcode bytes directly into the loader binary, and the second reads the shellcode from an image file.
A GodRAT shellcode injector file named “2024-08-01_2024-12-31Data.scr” (MD5 d09fd377d8566b9d7a5880649a0192b4) is an executable that XOR-decodes embedded shellcode using the following hardcoded key: “OSEDBIU#IUSBDGKJS@SIHUDVNSO*SKJBKSDS#SFDBNXFCB”. A new section is then created in the memory of an executable process, where the decoded shellcode is copied. Then the new section is mapped into the process memory and a thread is spawned to execute the shellcode.
Another file, “2024-11-15_23.45.45 .scr” (MD5 e723258b75fee6fbd8095f0a2ae7e53c), serves as a self-extracting executable containing several embedded files as shown in the image below.
Content of self-extracting executable
Among these is “SDL2.dll” (MD5 512778f0de31fcce281d87f00affa4a8), which is a loader. The loader “SDL2.dll” is loaded by the legitimate executable Valve.exe (MD5 d6d6ddf71c2a46b4735c20ec16270ab6). Both the loader and Valve.exe are signed with an expired digital certificate. The certificate details are as follows:
Serial Number: 084caf4df499141d404b7199aa2c2131
Issuer Common Name: DigiCert SHA2 Assured ID Code Signing CA
Validity: Not Before: Friday, September 25, 2015 at 5:30:00 AM; Not After: Wednesday, October 3, 2018 at 5:30:00 PM
Subject: Valve
The loader “SDL2.dll” extracts shellcode bytes hidden within an image file “2024-11-15_23.45.45.jpg”. The image file represents some sort of financial details as shown below.
The loader allocates memory, copies the extracted shellcode bytes, and spawns a thread to execute it. We’ve also identified similar loaders that extracted shellcode from an image file named “2024-12-10_05.59.18.18.jpg”. One such loader (MD5 58f54b88f2009864db7e7a5d1610d27d) creates a registry load point entry at “HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MyStartupApp” that points to the legitimate executable Valve.exe.
Shellcode functionality
The shellcode begins by searching for the string “godinfo,” which is immediately followed by configuration data that is decoded using the single-byte XOR key 0x63. The decoded configuration contains the following details: C2 IP address, port, and module command line string. The shellcode connects to the C2 server and transmits the string “GETGOD.” The C2 server responds with data representing the next (second) stage of the shellcode. This second-stage shellcode includes bootstrap code, a UPX-packed GodRAT DLL and configuration data. However, after downloading the second-stage shellcode, the first stage shellcode overwrites the configuration data in the second stage with its own configuration data. A new thread is then created to execute the second-stage shellcode. The bootstrap code injects the GodRAT DLL into memory and subsequently invokes the DLL’s entry point and its exported function “run.” The entire next-stage shellcode is passed as an argument to the “run” function.
GodRAT
The GodRAT DLL has the internal name ONLINE.dll and exports only one method: “run”. It checks the command line parameters and performs the following operations:
If the number of command line arguments is one, it copies the command line from the configuration data, which was “C:\Windows\System32\curl.exe” in the analyzed sample. Then it appends the argument “-Puppet” to the command line and creates a new process with the command line “C:\Windows\System32\curl.exe -Puppet”. The parameter “-Puppet” was used in AwesomePuppet RAT in a similar way. If this fails, GodRAT tries to create a process with the hardcoded command “%systemroot%\system2\cmd.exe -Puppet”. If successful, it suspends the process, allocates memory, and writes the shellcode buffer (passed as a parameter to the exported function “run”) to the allocated memory. A thread is then created to execute the shellcode, and the current process exits. This is done to execute GodRAT inside the curl.exe or cmd.exe process.
If the number of command line arguments is greater than one, it checks if the second argument is “-Puppet.” If true, it proceeds with the RAT’s functionality; otherwise, it acts as if the number of command line arguments is one, as described in the previous case.
The RAT establishes a TCP connection to the C2 server on the port from the configuration blob. It collects the following victim information: OS information, local hostname, malware process name and process ID, user account name associated with malware process, installed antivirus software and whether a capture driver is present. A capture driver is probably needed for capturing pictures, but we haven’t observed such behavior in the analyzed sample.
The collected data is zlib (deflate) compressed and then appended with a 15-byte header. Afterward, it is XOR-encoded three times per byte. The final data sent to the C2 server includes a 15-byte header followed by the compressed data blob. The header consists of the following fields: magic bytes
(\x74\x78\x20) , total size (compressed data size + header size), decompressed data size, and a fixed DWORD (1 for incoming data and 2 for outgoing data). The data received from the C2 is only XOR-decoded, again three times per byte. This received data includes a 15-byte header followed by the command data. The RAT can perform the following operations based on the received command data:
Inject a received plugin DLL into memory and call its exported method “PluginMe”, passing the C2 hostname and port as arguments. It supports different plugins, but we only saw deployment of the FileManager plugin
Close the socket and terminate the RAT process
Download a file from a provided URL and launch it using the CreateProcessA API, using the default desktop (WinSta0\Default)
Open a given URL using the shell command for opening Internet Explorer (e.g. “C:\Program Files\Internet Explorer\iexplore.exe” %1)
Same as above but specify the default desktop (WinSta0\Default)
Create the file “%AppData%\config.ini”, create a section named “config” inside this file, and, create in that section a key called “NoteName” with the string provided from the C2 as its value
GodRAT FileManager plugin
The FileManager plugin DLL has the internal name FILE.dll and exports a single method called PluginMe. This plugin gathers the following victim information: details about logical drives (including drive letter, drive type, total bytes, available free bytes, file system name, and volume name), the desktop path of the currently logged-on user, and whether the user is operating under the SYSTEM account. The plugin can perform the following operations based on the commands it receives:
List files and folders at a specified location, collecting details like type (file or folder), name, size, and last write time
Write data to an existing file at a specified offset
Read data from a file at a specified offset
Delete a file at a specified path
Recursively delete files at a specified path
Check for the existence of a specified file. If the file exists, send its size; otherwise, create a file for writing.
Create a directory at a specified path
Move an existing file or directory, including its children
Open a specified application with its window visible using the ShellExecuteA API
Open a specified application with its window hidden using the ShellExecuteA API
Execute a specified command line with a hidden window using cmd.exe
Search for files at a specified location, collecting absolute file paths, sizes, and last write times
Stop a file search operation
Execute 7zip by writing hard-coded 7zip executable bytes to “%AppData%\7z.exe” (MD5 eb8d53f9276d67afafb393a5b16e7c61) and “%AppData%\7z.dll” (MD5 e055aa2b77890647bdf5878b534fba2c), and then runs “%AppData%\7z.exe” with parameters provided by the C2. The utility is used to unzip dropped files.
Second-stage payload
The attackers deployed the following second-stage implants using GodRAT’s FileManager plugin:
Chrome password stealer
The stealer is placed at “%ALLUSERSPROFILE%\google\chrome.exe” (MD5 31385291c01bb25d635d098f91708905). It looks for Chrome database files with login data for accessed websites, including URLs and usernames used for authentication, as well as user passwords. The collected data is saved in the file “google.txt” within the module’s directory. The stealer searches for the following files:
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data – an SQLite database with login and stats tables. This can be used to extract URLs and usernames used for authentication. Passwords are encrypted and not visible.
%LOCALAPPDATA%\Google\Chrome\User Data\Local State – a file that contains the encryption key needed to decrypt stored passwords.
MS Edge password stealer
The stealer is placed at “%ALLUSERSPROFILE%\google\msedge.exe” (MD5 cdd5c08b43238c47087a5d914d61c943). The collected data is stored in the file “edge.txt” in the module’s directory. The module attempts to extract passwords using the following database and file:
%LOCALAPPDATA%\Microsoft\Edge\User Data\Default\Login Data – the “Login Data” SQLite database stores Edge logins in the “logins” table.
%LOCALAPPDATA%\Microsoft\Edge\User Data\Local State – this file contains the encryption key used to decrypt saved passwords.
AsyncRAT
The DLL file (MD5 605f25606bb925d61ccc47f0150db674) is an injector and is placed at “%LOCALAPPDATA%\bugreport\LoggerCollector.dll” or “%ALLUSERSPROFILE%\bugreport\LoggerCollector.dll”. It verifies that the module name matches “bugreport_.exe”. The loader then XOR-decodes embedded shellcode using the key “EG9RUOFIBVODSLFJBXLSVWKJENQWBIVUKDSZADVXBWEADSXZCXBVADZXVZXZXCBWES”. After decoding, it subtracts the second key “IUDSY86BVUIQNOEWSUFHGV87QCI3WEVBRSFUKIHVJQW7E8RBUYCBQO3WEIQWEXCSSA” from each shellcode byte.
A new memory section is created, the XOR-decoded shellcode is copied into it, and then the section is mapped into the current process memory. A thread is started to execute the code in this section. The shellcode is used to reflectively inject the C# AsyncRAT binary. Before injection, it patches the AMSI scanning functions (AmsiScanBuffer, AmsiScanString) and the EtwEventWrite function to bypass security checks.
AsyncRAT includes an embedded certificate with the following properties:
Serial Number: df:2d:51:bf:e8:ec:0c:dc:d9:9a:3e:e8:57:1b:d9
Issuer: CN = marke
Validity: Not Before: Sep 4 18:59:09 2024 GMT; Not After: Dec 31 23:59:59 9999 GMT
Subject: CN = marke
GodRAT client source and builder
We discovered the source code for the GodRAT client on a popular online malware scanner. It had been uploaded in July 2024. The file is named “GodRAT V3.5_______dll.rar” (MD5 04bf56c6491c5a455efea7dbf94145f1). This archive also includes the GodRAT builder (MD5 5f7087039cb42090003cc9dbb493215e), which allows users to generate either an executable file or a DLL. If an executable is chosen, users can pick a legitimate executable name from a list (svchost.exe, cmd.exe, cscript.exe, curl.exe, wscript.exe, QQMusic.exe and QQScLauncher.exe) to inject the code into. When saving the final payload, the user can choose the file type (.exe, .com, .bat, .scr and .pif). The source code is based on Gh0st RAT, as indicated by the fact that the auto-generated UID in “GodRAT.h” file matches that of “gh0st.h”, which suggests that GodRAT was originally just a renamed version of Gh0st RAT.
GodRAT.h
gh0st.h
Conclusions
The rare command line parameter “puppet,” along with code similarities to Gh0st RAT and shared artifacts such as the fingerprint header, indicate that GodRAT shares a common origin with AwesomePuppet RAT, which we described in a private report in 2023. This RAT is also based on the Gh0st RAT source code and is likely connected with Winnty APT activities. Based on these findings, we are highly confident that GodRAT is an evolution of AwesomePuppet. There are some differences, however. For example, the C2 packet of GodRAT uses the “direction” field, which was not utilized in AwesomePuppet.
Old implant codebases, such as Gh0st RAT, which are nearly two decades old, continue to be used today. These are often customized and rebuilt to target a wide range of victims. These old implants are known to have been used by various threat actors for a long time, and the GodRAT discovery demonstrates that legacy codebases like Gh0st RAT can still maintain a long lifespan in the cybersecurity landscape.
In June, we encountered a mass mailing campaign impersonating lawyers from a major company. These emails falsely claimed the recipient’s domain name infringed on the sender’s rights. The messages contained the Efimer malicious script, designed to steal cryptocurrency. This script also includes additional functionality that helps attackers spread it further by compromising WordPress sites and hosting malicious files there, among other techniques.
Report summary:
Efimer is spreading through compromised WordPress sites, malicious torrents, and email.
It communicates with its command-and-control server via the Tor network.
Efimer expands its capabilities through additional scripts. These scripts enable attackers to brute-force passwords for WordPress sites and harvest email addresses for future malicious email campaigns.
Kaspersky products classify this threat with the following detection verdicts:
HEUR:Trojan-Dropper.Script.Efimer
HEUR:Trojan-Banker.Script.Efimer
HEUR:Trojan.Script.Efimer
HEUR:Trojan-Spy.Script.Efimer.gen
Technical details
Background
In June, we detected a mass mailing campaign that was distributing identical messages with a malicious archive attached. The archive contained the Efimer stealer, designed to pilfer cryptocurrency. This malware was dubbed “Efimer” because the word appeared in a comment at the beginning of its decrypted script. Early versions of this Trojan likely emerged around October 2024, initially spreading via compromised WordPress websites. While attackers continue to use this method, they expanded their distribution in June to include email campaigns.
Part of the script with comments
Email distribution
The emails that users received claimed that lawyers from a large company had reviewed the recipient’s domain and found words or phrases in its name that infringed upon their registered trademarks. The emails threatened legal action but offered to drop the lawsuit if the domain owner changed the domain name. Furthermore, they even expressed willingness to purchase the domain. The specific domain was never mentioned in the email. Instead, the attachment supposedly contained “details” about the alleged infringement and the proposed buyout amount.
Sample email
In a recent phishing attempt, targets received an email with a ZIP attachment named “Demand_984175” (MD5: e337c507a4866169a7394d718bc19df9). Inside, recipients found a nested, password-protected archive and an empty file named “PASSWORD – 47692”. It’s worth noting the clever obfuscation used for the password file: instead of a standard uppercase “S”, the attackers used the Unicode character U+1D5E6. This subtle change was likely implemented to prevent automated tools from easily extracting the password from the filename.
Archive contents
If the user unzips the password-protected archive, they’ll find a malicious file named “Requirement.wsf”. Running this file infects their computer with the Efimer Trojan, and they’ll likely see an error message.
Error message
Here’s how this infection chain typically plays out. When the Requirement.wsf script first runs, it checks for administrator privileges. It does this by attempting to create and write data to a temporary file at C:\\Windows\\System32\\wsf_admin_test.tmp. If the write is successful, the file is then deleted. What happens next depends on the user’s access level:
If the script is executed on behalf of a privileged user, it adds the C:\\Users\\Public\\controller folder to the Windows Defender antivirus exclusions. This folder will then be used to store various files. It also adds to exclusions the full path to the currently running WSF script and the system processes C:\\Windows\\System32\\exe and C:\\Windows\\System32\\cmd.exe. Following this, the script saves two files to the aforementioned path: “controller.js” (containing the Efimer Trojan) and “controller.xml”. Finally, it creates a scheduler task in Windows, using the configuration from controller.xml.
If the script is run with limited user privileges, it saves only the controller.js file to the same path. It adds a parameter for automatic controller startup to the HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\controller registry key. The controller is then launched via the WScript utility.
Afterward, the script uses WScript methods to display an error message dialog box and then exits. This is designed to mislead the user, who might be expecting an application or document to open, when in reality, nothing useful occurs.
Efimer Trojan
The controller.js script is a ClipBanker-type Trojan. It’s designed to replace cryptocurrency wallet addresses the user copies to their clipboard with the attacker’s own. On top of that, it can also run external code received directly from its command-and-control server.
The Trojan starts by using WMI to check if Task Manager is running.
If it is, the script exits immediately to avoid detection. However, if Task Manager isn’t running, the script proceeds to install a Tor proxy client on the victim’s computer. The client is used for communication with the C2 server.
The script has several hardcoded URLs to download Tor from. This ensures that even if one URL is blocked, the malware can still retrieve the Tor software from the others. The sample we analyzed contained the following URLs:
The file it downloads from one of the URLs (A46913AB31875CF8152C96BD25027B4D) is the Tor proxy service. The Trojan saves it to C:\\Users\\Public\\controller\\ntdlg.exe. If the download fails, the script terminates.
Assuming a successful download, the script launches the file with the help of WScript and then goes dormant for 10 seconds. This pause likely allows the Tor service to establish a connection with the Onion network and initialize itself. Next, the script attempts to read a GUID from C:\\Users\\Public\\controller\\GUID. If the file cannot be found, it generates a new GUID via createGUID() and saves it to the specified path.
The GUID format is always vs1a-<4 random hex characters>, for example, vs1a-1a2b.
The script then tries to load a file named “SEED” from C:\\Users\\Public\\controller\\SEED. This file contains mnemonic phrases for cryptocurrency wallets that the script has collected. We’ll delve into how it finds and saves these phrases later in this post. If the SEED file is found, the script sends it to the server and then deletes it. These actions assume that the script might have previously terminated improperly, which would have prevented the mnemonic phrases from being sent to the server. To avoid losing collected data in case of an error, the malware saves them to a file before attempting to transmit them.
At this point, the controller concludes its initialization process and enters its main operation cycle.
The main loop
In each cycle of operation, the controller checks every 500 milliseconds whether Task Manager is running. As before, if it is, the process exits.
If the script doesn’t terminate, it begins to ping the C2 server over the Tor network. To do this, the script sends a request containing a GUID (Globally Unique Identifier) to the server. The server’s response will be a command. To avoid raising suspicion with overly frequent requests while maintaining constant communication, the script uses a timer (the p_timer variable).
As we can see, every 500 milliseconds (half a second), immediately after checking if Task Manager is running, p_timer decrements by 1. When the variable reaches 0 (it’s also zero on the initial run), the timer is reset using the following formula: the PING_INT variable, which is set to 1800, is multiplied by two, and the result is stored in p_timer. This leaves 1800 seconds, or 30 minutes, until the next update. After the timer updates, the PingToOnion function is called, which we discuss next. Many similar malware strains constantly spam the network, hitting their C2 server for commands. The behavior quickly gives them away. A timer allows the script to stay under the radar while maintaining its connection to the server. Making requests only once every half an hour makes them much harder to spot in the overall traffic flow.
The PingToOnion function works hand-in-hand with CheckOnionCMD. In the first one, the script sends a POST request to the C2 using the curl utility, routing the request through a Tor proxy located at localhost:9050 at the address:
After a request is sent to the server, CheckOnionCMD immediately kicks in. Its job is to look for a server response in a file named “cfile” located in the %TEMP% directory. If the response contains a GUID command, the malware does nothing. This is likely a PONG response from the server, confirming that the connection to the C2 server is still alive and well. However, if the first line of the response contains an EVAL command, it means all subsequent lines are JavaScript code. This code will then be executed using the eval function.
Regardless of the server’s response, the Trojan then targets the victim’s clipboard data. Its primary goal is to sniff out mnemonic phrases and swap copied cryptocurrency wallet addresses with the attacker’s own wallet addresses.
First, it scans the clipboard for strings that look like mnemonic (seed) phrases.
If it finds any, these phrases are saved to a file named “SEED” (similar to the one the Trojan reads at startup). This file is then exfiltrated to the server using the PingToOnion function described above with the action SEED parameter. Once sent, the SEED file is deleted. The script then takes five screenshots (likely to capture the use of mnemonic phrases) and sends them to the server as well.
They are captured with the help of the following PowerShell command:
The FileToOnion function handles sending files to the server. It takes two arguments: the file itself (in this case, a screenshot) and the path where it needs to be uploaded.
Screenshots are sent to the following path on the server:
After sending the file, the script goes idle for 50 seconds. Then, it starts replacing cryptocurrency wallet addresses. If the clipboard content is only numbers, uppercase and lowercase English letters, and includes at least one letter and one number, the script performs additional checks to determine if it’s a Bitcoin, Ethereum, or Monero wallet. If a matching wallet is found in the clipboard, the script replaces it according to the following logic:
Short Bitcoin wallet addresses (starting with “1” or “3” and 32–36 characters long) are replaced with a wallet whose first two characters match those in the original address.
For long wallet addresses that start with “bc1q” or “bc1p” and are between 40 and 64 characters long, the malware finds a substitute address where the last character matches the original.
If a wallet address begins with “0x” and is between 40 and 44 characters long, the script replaces it with one of several Ethereum wallets hardcoded into the malware. The goal here is to ensure the first three characters match the original address.
For Monero addresses that start with “4” or “8” and are 95 characters long, attackers use a single, predefined address. Similar to other wallet types, the script checks for matching characters between the original and the swapped address. In the case of Monero, only the first character needs to match. This means the malware will only replace Monero wallets that start with “4”.
This clipboard swap is typically executed with the help of the following command:
After each swap, the script sends data to the server about both the original wallet and the replacement.
Distribution via compromised WordPress sites
As mentioned above, in addition to email, the Trojan spreads through compromised WordPress sites. Attackers search for poorly secured websites, brute-force their passwords, and then post messages offering to download recently released movies. These posts include a link to a password-protected archive containing a torrent file.
Here’s an example of such a post on https://lovetahq[.]com/sinners-2025-torent-file/
The torrent file downloads a folder to the device. This folder contains something that looks like a movie in XMPEG format, a “readme !!!.txt” text file, and an executable that masquerades as a media player.
Downloaded files
To watch a movie in the XMPEG format, the user would seemingly need to launch xmpeg_player.exe. However, this executable is actually another version of the Efimer Trojan installer. Similar to the WSF variant, this EXE installer extracts the Trojan’s main component into the C:\\Users\\Public\\Controller folder, but it’s named “ntdlg.js”. Along with the Trojan, the installer also extracts the Tor proxy client, named “ntdlg.exe”. The installer then uses PowerShell to add the script to startup programs and the “Controller” folder to Windows Defender exclusions.
The extracted Trojan is almost identical to the one spread via email. However, this version’s code includes spoofed wallets for Tron and Solana, in addition to the Bitcoin, Ethereum, and Monero wallets. Also, the GUID for this version starts with “vt05”.
Additional scripts
On some compromised machines, we uncovered several other intriguing scripts communicating with the same .onion domain as the previously mentioned ones. We believe the attackers installed these via an eval command to execute payloads from their C2 server.
WordPress site compromise
Among these additional scripts, we found a file named “btdlg.js” (MD5: 0f5404aa252f28c61b08390d52b7a054). This script is designed to brute-force passwords for WordPress sites.
Once executed, it generates a unique user ID, such as fb01-<4 random hex characters>, and saves it to C:\\Users\\Public\\Controller\\.
The script then initiates multiple processes to launch brute-force attacks against web pages. The code responsible for these attacks is embedded within the same script, prior to the main loop. To trigger this functionality, the script must be executed with the “B” parameter. Within its main loop, the script initiates itself by calling the _runBruteProc function with the parameter “B”.
After a brute-force attack is completed, the script returns to the main loop. Here, it will continue to spawn new processes until it reaches a hardcoded maximum of 20.
Thus, the script supports two modes – brute-force and the main one, responsible for the initial launch. If the script is launched without any parameters, it immediately enters the main loop. From there, it launches a new instance of itself with the “B” parameter, kicking off a brute-force attack.
The script’s operation cycle involves both the brute-force code and the handler for its core logic
The brute-force process starts via the GetWikiWords function: the script retrieves a list of words from Wikipedia. This list is then used to identify new target websites for the brute-force attack. If the script fails to obtain the word list, it waits 30 minutes before retrying.
The script then enters its main operation loop. Every 30 minutes, it initiates a request to the C2 server. This is done with the help of the PingToOnion method, which is consistent with the similarly named methods found in other scripts. It sends a BUID command, transmitting a unique user ID along with brute-force statistics. This includes the total number of domains attacked, and the count of successful and failed attacks.
After this, the script utilizes the GetRandWords function to generate a list of random words sourced from Wikipedia.
Finally, using these Wikipedia-derived random words as search parameters, the script employs the getSeDomains function to search Google and Bing for domains to target with brute-force attacks.
Part of the getSeDomains function
The ObjID function calculates an eight-digit hexadecimal hash, which acts as a unique identifier for a special object (obj_id). In this case, the special object is a file containing brute-force information. This includes a list of users for password guessing, success/failure flags for brute-force attempts, and other script-relevant data. For each distinct domain, this data is saved to a separate file. The script then checks if this identifier has been encountered before. All unique identifiers are stored in a file named “UDBXX.dat”. The script searches the file for a new identifier, and if one isn’t found, it’s added. This identifier tracking helps save time by avoiding reprocessing of already known domains.
For every new domain, the script makes a request using the WPTryPost function. This is an XML-RPC function that attempts to create a test post using a potential username and password. The command to create the post looks like this:
When the XML-RPC request is answered, whether successfully or not, the WPGetUsers function kicks in to grab users from the domain. This function hits the domain at /wp-json/wp/v2/users, expecting a list of WordPress site users in return.
This list of users, along with the domain and counters tracking the number of users and passwords brute-forced, gets written to the special object file described above. The ID for this file is calculated with the help of ObjID. After processing a page, the script lies dormant for five seconds before moving on to the next one.
Meanwhile, multiple processes are running concurrently on the victim’s computer, all performing brute-force operations. As mentioned before, when the script is launched with the “B” argument, it enters an infinite brute-forcing loop, with each process independently handling its targets. At the start of each iteration, there’s a randomly chosen 1–2 second pause. This delay helps stagger the start times of requests, making the activity harder to detect. Following this, the process retrieves a random object file ID for processing from C:\\Users\\Public\\Controller\\objects by calling ObjGetW.
The ObjGetW function snags a random domain object that’s not currently tied up by a brute-force process. Locked files are marked with the LOCK extension. Once a free, random domain is picked for brute-forcing, the lockObj function is called. This changes the file’s extension to LOCK so other processes don’t try to work on it. If all objects are locked, or if the chosen object can’t be locked, the script moves to the next loop iteration and tries again until it finds an available file. If a file is successfully acquired for processing, the script extracts data from it, including the domain, password brute-force counters, and a list of users.
Based on these counter values, the script checks if all combinations have been exhausted or if the maximum number of failed attempts has been exceeded. If the attempts are exhausted, the object is deleted, and the process moves on to a new iteration. If attempts remain, the script tries to authenticate with the help of hardcoded passwords.
When attempting to guess a password for each user, a web page post request is sent via the WPTryPost function. Depending on the outcome of the brute-force attempt, ObjUpd is called to update the status for the current domain and the specific username-password combination.
After the status is updated, the object is unlocked, and the process pauses randomly before continuing the cycle with a new target. This ensures continuous, multi-threaded credential brute-forcing, which is also regulated by the script and logged in a special file. This logging prevents the script from starting over from scratch if it crashes.
Successfully guessed passwords are sent to the C2 with the GOOD command.
Alternative Efimer version
We also discovered another script named “assembly.js” (MD5: 100620a913f0e0a538b115dbace78589). While similar in functionality to controller.js and ntdlg.js, it has several significant differences.
Similarly to the first script, this one belongs to the ClipBanker type. Just like its predecessors, this malware variant reads a unique user ID. This time it looks for the ID at C:\\Users\\Public\\assembly\\GUID. If it can’t find or read that ID, it generates a new one. This new ID follows the format M11-XXXX-YYYY, where XXXX and YYYY are random four-digit hexadecimal numbers. Next up, the script checks if it’s running inside a virtual machine environment.
If it detects a VM, it prefixes the GUID string with a “V”; otherwise, it uses an “R”. Following this, the directory where the GUID is stored (which appears to be the script’s main working directory) is hidden.
After that, a file named “lptime” is saved to the same directory. This file stores the current time, minus 21,000 seconds. Once these initial setup steps are complete, the malware enters its main operation loop. The first thing it does is check the time stored in the “lptime” file. If the difference between the current time and the time in the file is greater than 21,600 seconds, it starts preparing data to send to the server.
After that, the script attempts to read data from a file named “geip”, which it expects to find at C:\\Users\\Public\\assembly\\geip. This file contains information about the infected device’s country and IP address. If it’s missing, the script retrieves information from https://ipinfo.io/json and saves it. Next, it activates the Tor service, located at C:\\Users\\Public\\assembly\\upsvc.exe.
Afterwards, the script uses the function GetWalletsList to locate cryptocurrency wallets and compile a list of its findings.
It prioritizes scanning of browser extension directories for Google Chrome and Brave, as well as folders for specific cryptocurrency wallet applications whose paths are hardcoded within the script.
The script then reads a file named “data” from C:\\Users\\Public\\assembly. This file typically contains the results of previous searches for mnemonic phrases in the clipboard. Finally, the script sends the data from this file, along with the cryptocurrency wallets it discovered from application folders, to a C2 server at:
After the script sends the data, it verifies the server’s response with the help of the CheckOnionCMD function, which is similar to the functions found in the other scripts. The server’s response can contain one of the following commands:
RPLY returns “OK”. This response is only received after cryptocurrency wallets are sent, and indicates that the server has successfully received the data. If the server returns “OK”, the old data file is deleted. However, if the transmission fails (no response is received), the file isn’t deleted. This ensures that if the C2 server is temporarily unavailable, the accumulated wallets can still be sent once communication is re-established.
EVAL executes a JavaScript script provided in the response.
KILL completely removes all of the malware’s components and terminates its operation.
Next, the script scans the clipboard for strings that resemble mnemonic phrases and cryptocurrency wallet addresses.
Any discovered data is then XOR-encrypted using the key $@#LcWQX3$ and saved to a file named “data”. After these steps, the entire cycle repeats.
“Liame” email address harvesting script
This script operates as another spy, much like the others we’ve discussed, and shares many similarities. However, its purpose is entirely different. Its primary goal is to collect email addresses from specified websites and send them to the C2 server. The script receives the list of target websites as a command from the C2. Let’s break down its functionality in more detail.
At startup, the script first checks for the presence of the LUID (unique identifier for the current system) in the main working directory, located at C:\\Users\\Public\\Controller\\LUID. If the LUID cannot be found, it creates one via a function similar to those seen in other scripts. In this case, the unique identifier takes the format fl01-<4 random hex characters>.
Next, the checkUpdate() function runs. This function checks for a file at C:\\Users\\Public\\Controller\\update_l.flag. If the file exists, the script waits for 30 seconds, then deletes update_l.flag, and terminates its operation.
Afterwards, the script periodically (every 10 minutes) sends a request to the server to receive commands. It uses a function named PingToOnion, which is similar to the identically named functions in other scripts.
The request includes the following parameters:
LIAM: unique identifier
action: request type
data: data corresponding to the request type
In this section of the code, LIAM string is used as the action, and the data parameter contains the number of collected email addresses along with the script operation statistics.
If the script unexpectedly terminates due to an error, it can send a log in addition to the statistics, where the action parameter will contain LOGS string, and the data parameter will contain the error message.
The server returns a JSON-like structure, which the next function later parses.
The structure dictates the commands the script should execute.
This script supports two primary functions:
Get a list of email addresses from domains provided by the server
The script receives domains and iterates through each one to find hyperlinks and email addresses on the website pages.
The GetPageLinks function parses the HTML content of a webpage and extracts all links that reside on the same domain as the original page. This function then filters these links, retaining only those that point to HTML/PHP files or files without extensions.
The PageGetLiame function extracts email addresses from the page’s HTML content. It can process both openly displayed addresses and those encapsulated within mailto links .
Following this initial collection, the script revisits all previously gathered links on the C2-provided domains, continuing its hunt for additional email addresses. Finally, the script de-duplicates the entire list of harvested email addresses and saves them for future use.
Exfiltrate collected data to the server
In this scenario, the script anticipates two parameters from the C2 server’s response: pstack and buffer, where:
pstack is an array of domains to which subsequent POST requests will be sent;
buffer is an array of strings, each containing data in the format of address,subject,message.
The script randomly selects a domain from pstack and then uploads one of the strings from the buffer parameter to it. This part of the script likely functions as a spam module, designed to fill out forms on target websites. For each successful data submission via a POST request to a specific domain, the script updates its statistics (which we mentioned earlier) with the number of successful transmissions for that domain.
If an error occurs within this loop, the script catches it and reports it back to the C2 server with the LOGS command.
Throughout the code, you’ll frequently encounter the term “Liame”, which is simply “Email” spelled backwards. Similarly, variations like “Liama”, “Liam”, and “Liams” are also present, likely derived from “Liame”. This kind of “wordplay” in the code is almost certainly an attempt to obscure the malicious intent of its functions. For example, instead of a clearly named “PageGetEmail” function, you’d find “PageGetLiame”.
Victims
From October 2024 through July 2025, Kaspersky solutions detected the Efimer Trojan impacting 5015 Kaspersky users. The malware exhibited its highest level of activity in Brazil, where attacks affected 1476 users. Other significantly impacted countries include India, Spain, Russia, Italy, and Germany.
TOP 10 countries by the number of users who encountered Efimer (download)
Takeaways
The Efimer Trojan combines a number of serious threats. While its primary goal is to steal and swap cryptocurrency wallets, it can also leverage additional scripts to compromise WordPress sites and distribute spam. This allows it to establish a complete malicious infrastructure and spread to new devices.
Another interesting characteristic of this Trojan is its attempt to propagate among both individual users and corporate environments. In the first case, attackers use torrent files as bait, allegedly to download popular movies; in the other, they send claims about the alleged unauthorized use of words or phrases registered by another company.
It’s important to note that in both scenarios, infection is only possible if the user downloads and launches the malicious file themselves. To protect against these types of threats, we urge users to avoid downloading torrent files from unknown or questionable sources, always verify email senders, and consistently update their antivirus databases.
For website developers and administrators, it’s crucial to implement measures to secure their resources against compromise and malware distribution. This includes regularly updating software, using strong (non-default) passwords and two-factor authentication, and continuously monitoring their sites for signs of a breach.
Login
![Here's an example of such a post on https://lovetahq[.]com/sinners-2025-torent-file/](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2025/08/07001809/efimer-trojan15.png)
