• Cisco Talos observed a new AI-integrated command-and-control (C2) framework in the wild called “NIK C2.”
• NIK C2 contains a Windows implant, using which, an actor can dump credentials, stream the victim's keystrokes to collect the targeted victim’s sensitive data, and instruct an integrated AI model to analyze the harvested data, all within the compromised session.
• In this framework, the actor has abused the OpenAI Chat Completions application programming interface (API), which is a HTTP endpoint that enables ChatGPT-style conversations programmatically.
• In addition to the features that enable theft, an actor can also deploy desktop screen-locking ransomware via the NIK C2 implant onto the victim machine, leading to a ransom demand in Bitcoin or USDT cryptocurrencies.
• NIK C2 reshapes adversary tradecraft by collapsing collection and exploitation into a single continuous session, effectively erasing the offline processing delays that historically granted defenders critical detection windows. 
• Such AI-enabled adversarial frameworks require defenders to move beyond traditional detection and embrace continuous behavioral vigilance as the new baseline.

---

NIK C2 implant: AI-integrated remote access tool

The NIK C2 implant is a Go-based, 64-bit Windows remote access tool that grants persistent control over compromised hosts using a resilient dual-channel C2 architecture. It communicates over TLS-secured WebSockets on port 443 alongside an HTTP fallback polling loop every 250 milliseconds, protecting all traffic with AES-256-GCM encryption derived from a hardcoded seed. To survive takedowns, the implant routes traffic across three prioritized C2 tiers, which are runtime-updated URLs, an embedded encrypted server list, and a hardcoded fallback address. Beyond standard operations, the implant features surveillance, theft, lateral movement, and evasion capabilities, including credential dumping, RDP session hijacking, process hollowing, and a C2-driven screen lock ransomware module. 

Notably, the NIK C2 implant embeds a fully integrated OpenAI API client via its ai_generate command, allowing operators to route arbitrary prompts to the OpenAI Chat Completions API directly through the infected host. The NIK C2 implant manages API key resolution, request assembly, and response parsing locally, returning the encrypted generative AI results to the actor's C2.

The observed NIK C2 implant samples in the wild contains an embedded build path (/opt/nik_panel/data/build_52b79724a1fc4b8f/main.go), which identifies the project as "nik_panel" and indicates that the implant was cross compiled for Windows from a Linux development environment. Furthermore, the embedded eight-byte hex token matching the build identifier highlights that the threat actor's infrastructure actively tracking and versioning the implants. 

NIK C2 implant evolution timeline 

Talos observed that the NIK C2 implant development trajectory spans at least three distinct versions. All binaries observed in the wild were compiled with Go 1.23.4 (which was released in December 2024), placing the entire sample set compiled no earlier than late 2024. The actor has Zeroed PE TimeDateStamp fields and near-epoch filesystem timestamps (manifesting as Nov 29, 1979) are applied consistently across all samples.  

We developed a timeline based on the initial sighting dates of NIK C2 implant variants in OSINT. 

The pace of capability addition across the three versions indicates a technically proficient team with prior malware operations experience is actively expanding NIK C2 towards a full-service adversarial framework. 

Active NIK C2 server seen in the wild  

During our research, we observed that a threat actor hosted the NIK C2 framework on a server at IP address “87.120.196[.]120”, resolving the domain “total-sitevv[.]lol”. The C2 server hosted an SSL/TLS certificate (serial number 7d16381a9de823943b5a0987dbd0f26edf22052b and jarm:"28d28d28d00000000042d42d0000001f361a1bf80ed39a1e352adeb016a07b" ) with the Common Name (CN) set to nik-panel. This CN value matches strings embedded within the implant binary. Observing the NIK C2 infrastructure active in the wild allowed us to assess with moderate confidence that NIK C2 is not merely a proof of concept, but a fully functional, AI-integrated C2 framework. 

NIK C2 implant integrates OpenAI’s API 

AI integration is one of the most architecturally distinct features of NIK C2 implant. It constructs a fully formed HTTP request to OpenAI’s production inference endpoint, transmits it from the victim machine IP address, parses the JSON response, and returns the AI-generated text to the actor’s panel. The entire operation from receiving the actor prompt to returning the large language model (LLM) reply is executed synchronously with a 60-second timeout. 

The implant begins by extracting three fields from the command payload received from the C2. The first field, identified by the key prompt, is the text the actor wants to send to the AI model. If the prompt string has zero length, the handler immediately constructs an error response and returns without making any outbound network call. The second field, identified by the key api_key is the OpenAI API key to use for authentication. The third field, identified by the key model, specifies which OpenAI model to use.  

After extracting the three parameters, the implant checks whether the actor supplied an API key. If not, it calls the operating system's environment variable reader with the string OPENAI_API_KEY and uses the victim’s API key.  This fallback is not a backup mechanism for API key resolution. It is a deliberate design with significant operational implications. If the victim has configured an OpenAI account on their machine, that account's API key will be used to fund the actor's AI inference. OpenAI's billing system will charge the victim's payment method, and OpenAI's access logs will show the victim's API key as the one that made the requests, allowing no trace attributable to the threat actor.  

If the actor does not specify a model name, the implant falls back to a five-character default string stored in the binary data section. Decoding the five-character value showed gpt-4 confirming that GPT4 is the default when no model is specified. The actor can override this by passing any valid OpenAI model identifier in the command payload, allowing selection of newer models as they become available without requiring a binary update.  

The implant builds the OpenAI API request body by constructing a map with four fields. The first field uses the key model and contains the resolved model name. The second field uses key messages and contains a two-element array of message maps. The third field uses the key temperature and contains a floating-point value read from a constant in the binary data section. The fourth field uses the key max_tokens and contains an integer value also read from binary. 

The message array is constructed in the order that the OpenAI Chat Completions API expects. The system message is first followed by the user message. The system message map has the role system and a content string that is exactly 68 bytes long hardcoded in the binary. This 68-byte string is the implant's behavioral instruction to the AI. It defines the model's operational role and response style for the duration of the session. The user message map has the role user and contains the actor's prompt text verbiage. The complete map structure is then serialized to JSON. The JSON message is sent to the URL https:// api.openai.com/v1/chat/completions, the OpenAI Chat Completions endpoint, through an HTTP POST request. 

When the HTTP response arrives with a 200 status code, the handler uses Golang's JSON decoder to parse the response body directly into a generic map structure without defining a typed schema. It then navigates the decoded map by string key lookups in the sequence that the OpenAI Chat Completions API response structure defines. The outermost map is queried for the key choices which in a successful response contains an array. The implant checks that this array is non-empty, then accesses its element keys message and content. The string value at key content is the AI model-generated text response.  

After successfully extracting the AI-generated content, the handler assembles a result map with four entries. The key status is set to a constant string that reads as generated. The key code is set to the AI model's response text, so that the actor receives the full content of the model’s replies. The key model is set to the resolved model name that was used for the request, confirming which model produced the output. The key usage is set to the raw usage object from the OpenAI response, which contains the prompt token count, completion token count, and total token count. This usage data allows the actor to track how many tokens are consumed per request. The completed result map is ultimately transmitted to the C2 server over WebSocket or through the HTTP fallback C2 address. 

Dual execution modes of NIK C2 implant

Upon execution, the implant inspects its command-line arguments to determine its execution path. The argument watchdog activates supervisory monitoring to relaunch the core process if terminated, the copywatchdog tracks file copy operations, and the absence of either defaults execution to primary agent mode.  

In primary mode, it uses a named mutex to enforce single-instance execution, logs a message reading [NIK] Starting, generates a 32-byte cryptographic session key if uninitialized, decodes its obfuscated C2 address, and sets its masquerade name to “svchost.exe” or “simvol.exe”. 

After initial setup, the binary records its process ID (PID) in the victim's temporary application folder and executes its persistence and evasion routines. These routines include copying to %appdata%/Roaming/Microsoft/Network with modified access controls, configuring Windows autostart registry entries, and masquerading its process. Finally, it starts the local proxy server, initiates the WebSocket communication loop in a separate goroutine, and enters a continuous heartbeat polling loop on the main thread. 

Implant’s C2 command surface overview 

The implant command dispatcher module facilitates over 52 commands that are directed by the C2 panel. The dispatcher module uses byte-level string matching to map the associated modules that are launched as concurrent goroutines, allowing multiple operations to run in parallel.  

The following table shows the NIK C2 implant’s command categories: 

Category	Capability	Description
Stealer	Credential Stealer	Browser databases, saved passwords, cookies, autofill, crypto wallets, Discord  tokens, Firefox profiles.
Stealer	Wi-Fi harvesting	Extracts all saved WiFi SSIDs and plaintext passwords via Windows wireless  configuration tooling.
Surveillance	Keylogger	Real-time live stream per keystroke to actor panel, plus accumulated buffer  dump on demand.
Surveillance	Screen Capture	Full-screen screenshot and continuous screen stream.
Surveillance	Camera & Audio	Camera snapshot and stream, microphone recording, live audio feed.
Surveillance	Clipboard Monitor	Real-time clipboard content interception and replacement.
Remote Control	HVNC	Hidden Virtual Network Computing — full desktop control invisible to the victim.
Lateral Movement	SOCKS5/HTTP Proxy	Embedded proxy routing actor traffic through victim into internal network.
Lateral Movement	Reverse Proxy Tunnel	Bidirectional TCP relay tunneled over C2 WebSocket for LAN pivoting.
Lateral Movement	RDP Operations	RDP session interaction for lateral movement to other Windows hosts.
Persistence	Autostart &  Masquerade	Registry Run key persistence, process name masquerading, COM hijacking.
Persistence	Self-Heal Watchdog	External watchdog subprocess monitors and relaunches agent on termination.
Evasion	Defense Bypass	AMSI patch, debugger detection, stealth mode, UAC bypass, process hollowing.
AI	AI Generate	Live OpenAI API inference routed through victim machine with actor prompts.
Destructive	Boot Ransomware	Master Boot Record raw backup via PowerShell disk read and Screen-locking ransomware via LOLbin, registry persistence, crypto payment demand.
Destructive	Bootkit Preparation	UEFI vs. BIOS detection, Secure Boot query, bootkit binary staging.

Implant deploys screen-locking ransomware  

The ransomware module of the implant operates as a multi-stage attack controller that the actor runs in sequence to prepare, deploy, and retract a screen-locking ransomware payload.  

At first, it executes PowerShell to execute a raw disk copy command that reads directly from the physical drive device path (“\\.\PhysicalDrive0”) and writes the first sector, which is Master Boot Record (MBR), to a file named “mbr_backup.bin” in the Windows temporary directory.  

Next, the module constructs a complete self-contained HTML lock screen code entirely at runtime from a hardcoded format string, parameterized with actor supplied Bitcoin and USDT wallet addresses, prices, contact email, timer duration, and custom text from the C2 command message, allowing the actor to fully customize the ransom demands. 

After generating the HTML code, the binary writes it to the file “lock_screen.html” in the system temporary directory. It then generates a Windows batch script that calls mshta.exe with the path to the HTML file, followed by an infinite loop construct with a five-second timeout between iterations, ensuring that if the user somehow closes the window it reopens within five seconds. This batch file is written to the temp directory as “lock_start.bat”. 

The implant then runs a reg add command that writes a registry Run key named “SystemLock” under the current user's autostart path, pointing to a cmd /c invocation of the batch file, so the lock screen is executed on every user's logon. Additionally, a background goroutine is spawned that continuously monitors and relaunches the lock screen process. Finally, the module sends a confirmation response to C2 with the path of the deployed HTML file and the timer value. 

The design of this ransomware module is notable for several reasons. It does not encrypt any files, which means it leaves no forensic trail of file modification timestamps or encryption markers. It relies entirely on a screen lock, which is considerably faster to deploy than a file encryption ransomware. The persistence via registry Run key and a self-healing loop ensures the screen lock survives user attempts to dismiss it and survives a system restart.  

Implant’s bootkit preparation feature 

The bootkit preparation module of the implant is designed to survey the victim machine's boot firmware environment and then stage a bootkit payload file.  

It executes bcdedit /enum, the Windows Boot Configuration Data editor, with the output flag that enumerates all boot entries while hiding the console window. The implant reads the full output and searches for three specific substrings in sequence including EFI, Windows Boot Manager, and Windows Legacy OS Loader. If any of these are found, the boot type is classified as UEFI. The binary also searches for ntldr, the legacy Windows NT loader used by BIOS-mode systems as a fallback. Based on which string was matched, the boot type is recorded as either "UEFI" or "BIOS" as a string of the appropriate length. Separately, the binary runs a PowerShell command invoking Confirm-SecureBootUEFI, which is a built-in PowerShell command that returns to the current Secure Boot state. The output is searched for the string True to detect an enabled Secure Boot and for False to detect an explicitly disabled Secure Boot.  If neither is present, the value is recorded as unknown. The result is sent back to the C2, a map containing the boot type classification and the Secure Boot status string. 

Then the implant writes a 16-byte placeholder file named “bootkit.bin” to the system temporary directory. The bytes written spell out "NIK_BOOTKIT_PREP" in ASCII, which serves as a staging marker rather than an actual bootkit binary. This placeholder confirms that the target path is writable by the current process, establishes the file location that subsequent operations will reference, and can be overwritten by the actual bootkit binary delivered through the implant's file-upload or file-write command handlers. The path to the staged file is returned to the C2 in response.  

Implant’s theft functionality  

When the actor issues the theft category commands from the C2, the implant executes the associated goroutines to collect the targeted data into a result map space in the victim machine memory: 

WiFi password theft (wifi_steal) 

The implant executes netsh commands directly via Go’s exec.Command function by passing arguments as discrete tokens rather than through a shell string. Harvested results are formatted under specific labels: plaintext Wi-Fi passwords appear under Key Content:, saved network names are cataloged under WiFi Profiles: (with missing entries flagged using the per-entry format [%s] not found), and execution failures or absent interfaces return standardized error strings such as [WiFi] no wireless adapter or access denied and No WiFi profiles found. 

netsh wlan show profiles 
netsh wlan show profile name="" key=clear  

Browser credential extraction (passwords, quick_steal) 

The implant stages targeted browser database files into an archive alongside the Local State file, which contains the AES master key protected by Data Protection Application Programming Interface (DPAPI). The implant imports and executes the CryptUnprotectData Windows API to unwrap the AES key and decrypt the databases locally. Otherwise, it exfiltrates the raw encrypted databases to the C2 server for offline extraction. 

Targeted browser database files are shown in the table: 

Browsers	Targeted files
Chrome	Login Data, Cookies, Web Data, Local State, Bookmarks
Edge	Login Data, Cookies, Web Data, Local State
Brave	Login Data, Cookies, leveldb file
Opera	Login Data from folder Opera Software\Opera Stable\
Firefox	key4.db, logins.json, places.sqlite, formhistory.sqlite, Secure Preferences

Token and cookie theft (token_grab, quick_steal) 

The implant extracts Discord tokens and session cookies from the levelDB store on the victim machine. The extracted outputs are labelled as === Discord Tokens === and DISCORD TOKENS. The browser session cookies (Discord_Cookies) are extracted from the copied Cookies database.  

Cryptocurrency wallet theft (crypto_steal, wallet_export) 

Victim’s desktop-based wallets are collected directly from the wallet storage paths. Browser extension wallets are extracted from chromium LevelDB stored by extension ID. 

Desktop based wallet storage paths targeted are listed below: 

• /AppData/Roaming/Exodus/exodus.wallet 
• /AppData/Roaming/Electrum/wallets 
• /AppData/Local/Electrum/data/wallets 
• /AppData/Roaming/Ethereum/keystore 
• /AppData/Local/LedgerLive 
• wallet.dat (Bitcoin Core) 
• /AppData/Roaming/atomic (Atomic Wallet) 
• Electrum\wallets 

Browser extension wallets targeted: 

Wallet	Extension ID
MetaMask (Chrome/Brave)	nkbihfbeogaeaoehlefnkodbefgpgknn
MetaMask (Edge)	nkbihfbeogaeaoehlefnkodbefgpgknn
Coinbase Wallet	hnbohgpbmfldddohgoiefkeifpjficbk
Phantom (Chrome)	lnbcamaoebkogjmdnaofbeemigaalhlp
Brave Wallet	odbfpeeihodbihlmhbnhakoadhilfibh

Seed phrase, private key file, and system reconnaissance 

The implant performs two regular expression patterns to search on the entire filesystem of the victim machine. These two regular expressions are designed to scan file names for sensitive cryptographic assets and credentials, functioning as case-insensitive patterns ?i. The first expression targets cryptocurrency recovery materials and wallet backups by matching keywords like "seed," "mnemonic," or "wallet" paired with common plain-text and data file extensions (.txt, .md, .csv, .dat), while the second seeks out asymmetric private keys and general secrets using terms like "private," "privkey," or "secret" paired with both text files and standard cryptographic key containers (.key, .pem). Because both patterns use unanchored, greedy matching (.*) without start (^) or end ($) boundary anchors, they capture any file where these sensitive terms precede the target extensions. Matched data are collected under the label of seed candidates and archived into “browserdata.zip”.   

(?i)(seed|phrase|mnemonic|recovery|backup|wallet).*(\.txt|\.md|\.csv|\.dat) 
(?i)(private|privkey|secret).*(\.txt|\.md|\.key|\.pem) 

The implant also performs victim machine reconnaissance by executing the following commands and uses chcp 65001 prefix to force the output in UTF-8 format.  

chcp 65001 >nul 2>&1 & systeminfo 
chcp 65001 >nul 2>&1 & wmic os get lastbootuptime /value 
chcp 65001 >nul 2>&1 & wmic /namespace:\\root\SecurityCenter2 path AntiVirusProduct get displayName 2>nul 
chcp 65001 >nul 2>&1 & Get-Process | Select-Object Id, ProcessName | ConvertTo-Json -Compress 

After all collection paths are complete, the implant assembles all collected data into a single document that looks like a formatted report with clearly labeled sections for each data category such as === CRYPTO ===, === WIFI ===, === BROWSER ===.  

Keylogger: Keystrokes livestreamed to C2 

The keylogger module of the implant uses a persistent background goroutine that polls all 256 Windows virtual key codes, detecting keypresses via dynamically resolved API calls, and transmits the captured input. When a compromised victim presses a valid key on the keyboard, it is simultaneously streamed live as an AES-256-GCM encrypted JSON payload over WebSocket to C2 and also appends to an in-memory buffer capped at 10,000 entries and halved when full to prevent memory leaks. On an actor's dump command, this buffer is concatenated into a single string and returned to C2 via WebSocket or HTTP fallback, ensuring complete data transfer even during network interruptions. 

Stolen data exfiltration to C2 

Once the archive is assembled, the entire result map is handed to the result transmission routine of the implant. That routine constructs a new JSON object containing five specific fields. It includes the command identifier echoed back from the original command. It also contains the agent's persistent identifier, formatted as ag_<16 hex chars>. The type field is set to the string quick_steal_response. Finally, the data field holds the complete result map. 

Once constructed, this object is forwarded to the encryption routine. The routine serializes the object into JSON. It then generates 12 fresh random bytes to serve as a nonce. Next, it encrypts the serialized JSON using AES-256-GCM with a static key derived from a hardcoded seed. It concatenates the nonce, the ciphertext, and the 16-byte authentication tag and Base64-encodes the entire payload. The encrypted payload is placed in a wrapper object under the "e" key alongside the plain-text agent ID, and the wrapper is JSON marshaled into the final payload. 

This encrypted payload is then delivered through an available transmission path. The sending routine first checks whether the WebSocket connection is live. If it is, the payload is written directly into a WebSocket text frame on the existing connection, reaching the actor's panel with minimal latency. If the WebSocket is not currently connected, the routine falls back to an HTTP POST request to the endpoint path /api/c2/result on the C2 server, using the same encrypted body format. This dual-path design ensures stolen data is delivered even during WebSocket interruptions, as the HTTP channel remains functional independently of the WebSocket state. 

Implant’s C2 protocol 

The implant C2 architecture is designed for two independent, simultaneously operating communication channels. The primary channel is a persistent WebSocket connection over TLS. The secondary channel is an HTTP polling loop that posts to a fixed API endpoint at regular intervals. 

With the primary channel, the connection begins with a TCP dial to the C2 server address with an eight-second timeout. If the port is not explicitly present in the configured address, port 443 is appended automatically. Once the TCP socket is established, it is wrapped in a TLS session using a custom certificate configuration that pins to a specific certificate rather than validating against the system's certificate authority store. This prevents standard TLS interception proxies from observing traffic. 

Immediately after a successful WebSocket handshake but before any command is received, the implant transmits a full system registration message. The implant collects victim data such as the machine hostname, the local LAN IP address, the Windows username from the environment, a user security identifier, the local reverse-proxy port number that was assigned when the embedded proxy server was started, and the detected upstream proxy configuration derived from the Windows registry proxy settings. All of this is assembled into a JSON object and encrypted and sent to the C2.  

The HTTP polling channel runs independently. Every approximately 250 milliseconds, the agent collects a fresh snapshot of victim state hostname, watchdog status, local IP, username, current timestamp, and system uptime encrypts it in the same wire format and posts it to the /api/c2/update endpoint on the C2 server.  

Below table shows the C2 endpoints that the implant communicates: 

Endpoint	Purpose
/api/c2/update	Reconnaissance beacon – victim system info
/api/c2/result	Command output exfiltration
/api/c2/screen	Screenshot upload
/api/c2/file_chunk	File exfiltration
/api/c2/rproxy_up	Reverse proxy upstream data
/api/c2/ws	Websocket – actor command channel

Every message on both channels, in both directions, uses the same symmetric encryption scheme. A hardcoded seed value stored in obfuscated form in the binary data section is decoded at startup and produces a 32-byte AES key. 

Decoded AES seed: d791dd0ff3228ed29a8d7333d4567be829159c5632ea347780992006f91c5295 
32-byte AES key: 4887AFC0A574E9419A9695EF083460F58E4EF9A1C40793523CE112251273BDF9 

The C2 server then responds with an encrypted payload, whose inner map contains a command array identical in structure to those delivered over WebSocket. Commands received through HTTP are dispatched through the same logic. If the HTTP POST fails, the agent rotates to the next server address before retrying. 

The result transmission to the C2 is performed by the implant when a command handler completes its operation, the result is packaged into a response envelope containing the original command's identifier, the implant's own identifier, a type string formed by appending _response to the command name, the result data payload, and a top-level type marker of "result". This object is encrypted and delivered through either directly over the WebSocket connection if it is active, or via an HTTP POST to /api/c2/result. 

Implant’s defense evasion and anti-analysis techniques 

The NIK C2 implant deploys a layered set of defense evasion measures that activate immediately at startup and operate across the full compromise session. On launch, It hides its console window via API ShowWindow, renames the binary to “csrss.exe” in the Windows temp directory to impersonate a legitimate system process, disables Windows Recent Documents telemetry through a registry write action, and applies a critical-process flag via API NtSetInformationProcess with the parameter value 0x1D for  ProcessBreakOnTermination that causes a Blue Screen of Death if any attempt is made to terminate the process through Task Manager or taskkill actions.  

Alongside these, two anti-debug checks IsDebuggerPresent and CheckRemoteDebuggerPresent run silently and call os.Exit(0) on detection, leaving no exception record or crash evidence. When directed by the C2, the implant can also escalate privileges without a UAC prompt using the fodhelper.exe COM hijack, which writes the implant path into HKCU\Software\Classes\ms-settings\Shell\Open\command, triggers elevation, and cleans the registry key within two seconds. 

The implant bypasses the Antimalware Scan Interface (AMSI) by executing a hardcoded, embedded PowerShell script that patches memory inside “System.Management.Automation.dll”. Specifically, it overwrites the AmsiInitFailed field with a six-byte stub (MOV EAX, E_INVALIDARG; RET), forcing initialization to report failure and disabling content inspection for the remaining of the PowerShell session. 

Conclusion 

The emergence of NIK C2, an AI-enabled command-and-control framework, underscores a critical shift in modern malware design: the transition from static intrusion toolsets to dynamic, modular implants that adapt on demand. By embedding a live AI pipeline directly into the C2 loop, the compromised host is no longer a passive foothold but an autonomous operational asset. Operators can dynamically generate context-aware lure material, execute localized deception, synthesize operational intelligence, and craft targeted payloads directly on the compromised hosts — all while lowering the technical barrier which was traditionally required for such sophisticated tradecraft. 

Coverage 

The following ClamAV signature detects and blocks this threat:  

 Win.Trojan.GoDiscorder-10060526-0 

Indicators of compromise (IOCs)

IOCs for this research can be found at our GitHub repository here.

This research was conducted jointly with Julian-Ferdinand Vögele of Recorded Future’s Insikt Group. Details of the joint research and presentation are available here.

• Cisco Talos identified UAT-6275 (TAG-193 by Recorded Future) activity targeting government organizations across the Commonwealth of Independent States (CIS). Recovered artifacts show additional interest in water resources and energy. This focus is consistent with intelligence collection and may reflect the regional effects of the Russia–Ukraine war. 
• In activity observed from June 2025 through August 2026, Talos identified four infection-chain types that use macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and a crafted WinRAR archive exploiting CVE-2025-8088. The recovered payloads include several custom reverse shells that provide interactive remote access. 
• Three publicly accessible staging directories and GitHub repository history exposed payload builds, tool inventories, and changes to command-and-control (C2) infrastructure. These operational security lapses gave us direct visibility into the group's recent activity. 
• The files recovered from the exposed infrastructure suggest preparation for post-compromise operations and potential activity against Linux hosts and internet-facing appliances.  
• Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus, based on infrastructure access, language artifacts, sample submissions, working hours analysis, and regional targeting interests.

---

Background 

Cisco Talos and Recorded Future Insikt Group jointly investigated UAT-6275 activity targeting government organizations across the Commonwealth of Independent States (CIS). The investigation uncovered three publicly accessible staging directories and a previously unreported GitHub repository used to host malicious scripts and payloads. These exposed assets provided visibility into the threat actor's malware development, infrastructure changes and preparations for additional intrusion activity. 

Talos tracks this activity as UAT-6275, while Recorded Future tracks it as TAG-193. It overlaps with Silent Lynx (first reported by Seqrite) and sits within a broader set of campaigns connected to YoroTrooper, which we first reported in 2023. Subsequent research on Tomiris (Kaspersky), ShadowSilk (Group-IB), Cavalry Werewolf (BI.ZONE), and Hydra Saiga (VMRay) identified overlapping indicators across these reported clusters. We assess that UAT-6275 and YoroTrooper likely belong to the same broader activity cluster. However, we continue to track them separately because we have not observed direct indicator or toolset overlap between the two.

This post summarizes our joint Virus Bulletin 2026 white paper, “Break the silence: tracking Silent Lynx through exposed infrastructure” which contains the full technical analysis and indicators of compromise (IOCs).

Victimology 

UAT-6275's targeting is concentrated in Central Asia and the wider CIS region. Across the reviewed campaigns, observed victims and lure themes span nine countries: Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Russia, and Belarus.

Government and diplomatic affairs 

UAT-6275 targets government institutions responsible for diplomacy, economic development, agriculture, and environmental management. These organizations hold information that can inform bilateral negotiations, economic planning, and regional security decisions.

Our network flow analysis identified activity involving a Tajik government entity shortly after treaty discussions with Kazakhstan in March 2026 and a Belarusian government entity ahead of a bilateral meeting in April. This timing may indicate an interest in regional diplomatic developments.

The decoy documents we recovered also suggest an interest in diplomatic relations, international trade, and aviation. Examples include a diplomatic letter addressed to Armenia’s Ministry of Foreign Affairs.

Water security and resource management 

The group’s interest in regional resources spans environmental management and energy. Talos observed activity involving an Armenian government entity responsible for environmental matters and Uzbekistan’s Smart Forestry initiative, consistent with earlier reporting on Silent Lynx targeting water resource organizations across Central Asia. 

Energy-themed decoys included a cooperation proposal between Turkmenistan’s state oil company, Turkmennebit, and Russia’s Orsk Oil Refinery, used in an August 2025 sample. The refinery supplies petroleum products to Kazakhstan and later shut down after a Ukrainian drone strike in August 2026, with repairs expected to take up to six months. These ties suggest a possible intelligence interest in regional fuel supplies and the war’s implications for Kazakhstan’s energy security.

Campaign timeline 

Since Seqrite first reported Silent Lynx in January 2025, we have identified at least eight campaigns across the region through May 2026. These include malware delivery targeting Russia, Turkmenistan, and Uzbekistan; a credential-harvesting site impersonating Azerbaijan’s State Agency for Public Service; and lures referencing the China–Central Asia Summit and Russian energy infrastructure. In 2026, we also observed activity involving government entities in Tajikistan, Armenia, and Belarus, as well as Uzbekistan’s Smart Forestry initiative in May. 

Infrastructure and malware delivery 

Talos identified three publicly accessible staging directories containing malware and tools of UAT-6275. One sample led to the previously unreported GitHub repository, where the group hosted PowerShell scripts and payloads. Its commit history allowed us to track infrastructure changes and malware development.

The group relies on lightweight reverse shells, including Chvost, Laplas, and PickleShell, to issue commands on compromised systems.

We also recovered Linux-compatible tooling and a publicly available proof-of-concept exploit for FortiWeb CVE-2025-25257 from UAT-6275 infrastructure. These findings suggest interest in expanding the group’s operational capabilities. 

Four infection chains 

UAT-6275 used malicious documents, executable downloaders, and shortcuts to deliver malware, and later incorporated a WinRAR exploit. Talos categorized the recovered samples into four infection chains, A – D, based on how they retrieve and execute their payloads.

The first Chain A samples, observed in June 2025, used macro-enabled Word documents to download and execute a second-stage binary. In July 2025, we observed Chain B downloaders built with PS2EXE, a tool that packages PowerShell scripts as standalone Windows executables. These downloaders retrieved reverse-shell payloads and created scheduled tasks for persistence. 

We first observed Chain C in October 2025. A malicious shortcut launches PowerShell to retrieve and execute a GitHub-hosted script that provides remote shell access. Later samples also downloaded PickleShell and placed it in the Windows Startup folder for persistence.

In April 2026, we identified a RAR archive that exploited CVE-2025-8088 in WinRAR to place PickleShell in the Windows Startup folder (Chain D). The payload runs at the next user sign-in. This was the first vulnerability exploit we observed in UAT-6275’s malware delivery.

Kazakhstan nexus assessment 

Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus. Supporting evidence includes Russian-language artifacts, apparent malware-testing submissions from Kazakhstan shortly after compilation, and operator activity consistent with UTC+5 working hours.

Looking ahead 

UAT-6275’s sustained activity and adoption of new delivery techniques suggest the group will continue pursuing access to government organizations across Central Asia and the CIS. Its interest in environmental agencies, economic ministries, and energy infrastructure reflects the intelligence value of regional diplomacy and resource management. 

Defenders in these sectors should monitor unexpected PowerShell activity and payload downloads from public services such as GitHub, alongside scheduled tasks and Startup-folder changes. Keeping archive utilities patched can help reduce exposure to the exploit-assisted delivery observed in this campaign. 

For further details on this research and our accompanying presentation, see “Break the Silence: Tracking Silent Lynx Through Exposed Infrastructure” on Virus Bulletin’s website, as well as Recorded Future’s related blog post.

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Backdoor.PickleShell-10060602-0 
• Win.Backdoor.Chvost-10060603-0 
• Win.Malware.Generic-10060604-0 
• Win.Malware.LAPLAS-10060605-0 
• Win.Malware.LAPLAS-10060606-0 
• Win.Proxy.Generic-10060628-0 

The following Snort rules cover this threat: 

• Snort 2: 1:11192, 1:15306, 1:46983, 1:47398 
• Snort 3: 1:46983, 4:16 

IOCs

IOCs for this research can be found at our GitHub repository here. 

• Cisco Talos uncovered a cluster of activity we track as UAT-11587 targeting government and policy organizations across Asia, including in Taiwan, India, the Philippines, and Cambodia, to deliver a previously undocumented backdoor referred to as “Antino” in developer artifacts. 
• Talos first observed UAT-11587 activity in September 2025. By July 2026, Talos had identified at least 16 affected or targeted institutional environments across eight Asian countries. 
• Antino is a Rust-compiled Windows backdoor that supports host reconnaissance, shell and PowerShell execution, file transfer, in-memory shellcode loading and persistence. Its native command-and-control channel operates exclusively through Microsoft 365, using Microsoft Graph to interact with Outlook and OneDrive. 
• Talos identified a recurring delivery branch that began with spear-phishing emails and tailored decoy documents, followed by a five-stage infection chain. The actor relied heavily on Cloudflare infrastructure for delivery, execution tracking, and payload staging. 
• Based on the development, preparation-environment, and targeting indicators detailed in this report, Talos assesses with high confidence that UAT-11587 is China-nexus.

---

Overview 

Talos first identified UAT-11587’s campaign while investigating a spear-phishing campaign directed at Taiwan's academic, think tank, and civil society policy community in March 2026. The message recreated Gmail's attachment interface and directed the target into a cloud-hosted, multi-stage infection chain. 

Across this activity, our researchers assessed that the actor used several delivery methods, loader families, and post-compromise tools. One recurring final-stage payload was a custom Rust backdoor that Talos tracks as Antino. Antino communicates with Microsoft 365 applications and uses Outlook and OneDrive objects as dead drops, rather than depending on a conspicuous dedicated command server. 

Further investigation showed that the activity extended beyond the initial Taiwan operation. Talos subsequently identified confirmed or probable affected government and security environments across multiple Asian countries, alongside additional regional targeting supported by lure content.  

While this report was being prepared, Symantec published research on an activity set it tracks as Jewelbug. Talos identified overlaps between UAT-11587 and the Antino-related espionage activity attributed to Jewelbug. Although Symantec reported that Jewelbug conducted both espionage and cryptocurrency fraud, it assessed that “the SEO business supplied access, delivery and infrastructure into the espionage operation, rather than that one person performed both roles.” Talos could not independently verify a connection between the espionage campaign and Jewelbug’s financially motivated activity. We therefore track UAT-11587 as a separate activity set. 

Who is UAT-11587? 

Talos assesses with high confidence that UAT-11587 is a China-nexus actor, based on the totality of corroborating technical and operational evidence, rather than any single indicator. The indicators discussed below are selected examples of the broader evidence supporting this assessment. 

Evidence supporting the attribution assessment 

Decoy document metadata provides several preparation-environment clues. A Taiwan-focused decoy contains the zh-CN language tag, the Simplified Chinese author value 未定义 (“undefined”), and an explicit +08:00 creation timestamp. Both recovered spear-phishing messages also contain +08:00 date headers. UTC+8 alone is not geographically distinctive because it is used across mainland China, Taiwan, Hong Kong, Singapore, and other locations. However, the combination of the +08:00 offset, the zh-CN language tag and Simplified Chinese metadata is more consistent with a mainland Chinese environment than with Taiwan or Hong Kong, where Traditional Chinese predominates. 

The campaign’s lure theme and targeting provide additional contextual support. Its lures and observed targets include Taiwanese political, legislative, civil defense, and policy research subjects, together with regional government, maritime, diplomatic, and security themes. This collection focus is consistent with China-nexus actor interests.  

Another supporting indicator appears in Antino’s development artifacts. Ten distinct Antino build outputs contain Cargo registry paths referencing rsproxy.cn, a Rust package mirror intended to improve dependency downloads within mainland China. The service’s public accessibility does not reveal the developer’s location, but its repeated use suggests reliance on a China-focused Rust mirror. 

During our investigation, Talos also identified a JavaScript downloader associated with UAT-11587 that referenced “d32tpl7xt7175h[.]cloudfront[.]net”, the same CloudFront distribution previously reported by Arctic Wolf in China-nexus UNC6384 delivery activity. This shared infrastructure suggests possible delivery-layer overlap. However, because cloud infrastructure can be reused and the campaigns employed different core malware and command-and-control (C2) architectures, Talos assesses this relationship with low confidence and continues to track UAT-11587 as a separate activity cluster.  

Victimology 

UAT-11587 primarily targeted public-sector and national-security-adjacent organizations across Asia. By July 2026, Talos had identified at least 10 confirmed and five probable affected institutional environments, plus one additional intended target. Our investigation reveals approximately 350 compromised endpoints across eight countries. 

 The affected or targeted sectors included: 

• Defense, military, and national security 
• Executive government and central public administration 
• Foreign affairs and diplomatic services 
• Justice, law enforcement, border security, and interior security 
• Legislative and parliamentary institutions 
• Government IT and shared e-government services 
• Think tanks, universities, and research institutions 
• Civil society, human rights, and public policy organizations 

 Based on the available evidence, Talos assesses with moderate-to-high confidence that the campaign targeted organizations in Taiwan, India, the Philippines, Cambodia, Pakistan, Thailand, Myanmar, and Syria. 

Based on its sustained targeting of government and national security-adjacent organizations, tailored political and diplomatic lures, and capabilities supporting persistent access and information collection, Talos assesses with moderate confidence that UAT-11587 is conducting intelligence gathering operation.  

Campaign timeline 

Talos observed UAT-11587 activity from September 2025 through July 2026. The earliest reviewed activity, from September through November 2025, used Philippines-themed lures and direct email attachment delivery. In January 2026, the actor conducted two additional Philippines-focused HTML application (HTA) campaigns and began using a broader set of policy and geopolitical lures alongside a standalone fake installer delivery branch. Activity accelerated between March and early June, with closely timed operations involving the Philippines and Taiwan, followed by activity affecting or targeting environments in Cambodia, Myanmar, Syria, Pakistan, and Thailand. The largest concentrated wave occurred on June 8 and 9, when Talos identified around 57 newly observed endpoints associated with India. 

Spear-phishing delivery and sender spoofing 

UAT-11587, like many targeted intrusion sets, relies on spear-phishing emails to deliver its infection chain. The social engineering themes used in these emails suggest the threat actor possessed detailed prior knowledge of their target organizations. This targeting precision is particularly apparent in the Taiwan campaigns, where lure content was carefully aligned with the operational and institutional context of each target. 

Abusing sender-domain misalignment to spoof trusted senders 

To make its spear-phishing emails appear more credible, UAT-11587 spoofed sender identities trusted by the intended recipients. The actor exploited the distinction between the SMTP envelope sender and the visible From header. Messages were sent through Migadu using the attacker-controlled “osc-cdn[.]com” domain as the RFC5321 envelope sender, while the RFC5322 From header displayed the identity of the organization being impersonated. 

 SPF passed because Migadu’s sending infrastructure was authorized to send email on behalf of “osc-cdn[.]com”. However, this result authenticated only the envelope-sender domain, not the sender displayed to the recipient. DMARC detected that the envelope and visible sender domains were not aligned and returned a failure. In the reviewed message, the displayed domain used a non-enforcing p=none policy, which requested monitoring rather than quarantine or rejection. The receiving provider therefore accepted the message, allowing the spoofed email to be successfully delivered to the recipient’s inbox despite the DMARC failure.  

Gmail attachment widget cloning 

Another social engineering technique used for initial access in this campaign was the closely replicated reconstruction of Gmail’s native attachment preview widget inside the email HTML body. The actor replicated the styling of Gmail’s attachment card using four inline PNG images embedded as Base64-encoded MIME parts. The entire attachment card was wrapped in an anchor tag pointing to an attacker-controlled URL. These links use Cloudflare Pages URLs with the pattern shown below. The ?m= parameter carries a target identifier and therefore permits per-recipient logging at the delivery service //my-<project>.pages.dev/File_download?m=<target-identifier>. The actor used a protocol-relative URL beginning with //, which may be overlooked by security tools that extract only fully qualified HTTP or HTTPS URLs. 

When a Gmail user opens the email in a browser, Gmail’s renderer faithfully displays the attacker-controlled HTML, producing a fake attachment widget that is visually indistinguishable from a legitimate Gmail attachment preview. 

Tailored lures and decoy documents 

Our analysis recovered three decoy documents during separate UAT-11587 operations. The first decoy described a workshop focused on the “Taiwan Information Warfare.” The document referenced a 2025 TikTok study and discussed perceived public knowledge gaps concerning cross-strait issues and information manipulation.  

The second decoy, titled “立法委員行使職務支領之各項費用徵免稅原則” (“Principles governing the taxation of expenses received by legislators in performing their duties”), used a narrower administrative pretext. It describes the income tax treatment of legislators’ remuneration, overseas travel, and expenses incurred while performing legislative duties. The document exactly reproduces a public Taiwan Ministry of Finance ruling to make the decoy appear credible. Its subject strongly suggests that it was prepared for members of Taiwan's public sector. 

Outside Taiwan, Talos recovered a two-page decoy titled “CSIS Indo-Pacific Forecast 2026 (Event Details).” The document borrowed the framing of a legitimate event and referenced real experts, presenting an agenda focused on regional alliances, gray-zone security, demographic trends, and human security. The subject matter would plausibly appeal to government, diplomatic, think tank, academic, and security policy audiences across the Indo-Pacific, including readers focused on India. 

Beyond the recovered decoys, file names of malicious executables, HTA files, and WSF stagers revealed additional themes spanning maritime policy, foreign affairs, diplomatic events, human rights, government administration, and technology research. 

One lure shows how the actor exploited current geopolitical developments. “Trump’s Former Russia Adviser Claims Moscow Offered US Free Rein in Venezuela in Exchange for Ukraine” closely paraphrased an Associated Press report, with two related samples appearing on VirusTotal two days later.  

Together, these examples show the actor using both news-style headlines and official-sounding documents to target audiences interested in foreign affairs, international security, and government policy. 

The table below lists the likely audience for each lure. Where recipient details or decoy content were unavailable, assessments are based solely on file names and subject matter and do not confirm delivery or compromise. 

Lure or decoy title	Potential target or audience
115年度薪資所得扣繳稅額表說明 (Instructions for the 2026 Salary Income Tax Withholding Table)	Taiwanese think tank
Resolution on the Updated Chart of Bajo de Masinloc	Likely Philippine public sector
Trump's Former Russia Adviser Claims Moscow Offered US Free Rein in Venezuela in Exchange for Ukraine	Foreign-policy, government, research, or media audiences interested in the topic.
CrossBorder_Repression_Seminar_Agenda	Likely human-rights, civil-society, diaspora, academic, or policy communities.
the May 27 inauguration of the TPiE	Regional political and civil-society audiences
Tehran_Bilateral_Summit_Proceedings_May2026	Likely diplomatic, foreign-affairs, or policy audiences following a Tehran-based bilateral meeting.
Items likely to be considered in the next Cabinet meeting.T11065885611.doc.exe	Indian government audiences
UO -C-DAC (1)	Indian government technology and research audiences

The infection chain 

In the reviewed spear-phishing operations, the actor uses a five-stage infection chain that begins with an HTA stager. Later stages abuse unsafe BinaryFormatter deserialization and gadget chains in standard .NET assemblies to load and execute the final payload. 

Stage 1: HTA and WSF Stager 

The “my-<project>.page[.]dev” Cloudflare URL in the spear-phishing emails leads to the download of an HTA file that was executed by mshta.exe. It hides and resizes its window, emits a tracking request to an invariant Cloudflare Pages beacon, and imports the next JavaScript stage from a cloud-hosted location. The same general template appears across multiple campaign variants: 

The actor uses two cloud services to deliver the second-stage JavaScript: 

• Cloudflare R2: “pub-<32-character hexadecimal identifier>[.]r2[.]dev” 
• Amazon CloudFront: “d2nq35tel3ucuo[.]cloudfront[.]net” 

The fixed Cloudflare Pages hostname “oisadjfoinsiduhfnoisdnfosdnoifnsoid[.]pages[.]dev” appears across multiple reviewed HTA variants. A hidden image causes mshta.exe to send a request containing the lure title in the URL path and ?track in the query string. This could allow the operator to correlate HTA execution with a particular lure for campaign tracking.  

Talos also observed WSF stagers that perform the same role through Windows Script Host. They send an HTTP HEAD request to the tracking host name with the lure title in the URL path, then load the next JavaScript stage from Cloudflare R2. Although paired HTA and WSF samples use different R2 objects and obfuscated loaders, both lead to the same infection chain.  

Stage 2: HTA-hosted JScript downloader and decryptor 

The Stage 2 component is HTA-hosted Microsoft JScript, delivered from Cloudflare R2 and loaded in-process by mshta.exe through the HTA stager. It acts as a downloader and decryptor that prepares the next stage in-memory .NET deserialization chain. The script retrieves three encrypted resources from the cloud-hosted delivery infrastructure: 

1. Encrypted JavaScript orchestrator (.js file) 
2. Encrypted .NET serialized gadget resource 1 (.txt file) 
3. Encrypted .NET serialized gadget resource 2 (.txt file) 

After downloading the files, the script applies custom Base64 decoding and decrypts each response with RC4 using an embedded key. It then executes the decrypted JScript orchestrator in memory to initiate the .NET 4.x deserialization chain. 

Stage 3: .NET BinaryFormatter deserialization chain 

The three files downloaded from Cloudflare R2 or Amazon CloudFront are the JScript orchestrator and two serialized .NET gadget resources. The threat actor leverages a scripted .NET deserialization technique in which JScript instantiates COM-visible .NET classes and passes attacker-controlled serialized data into BinaryFormatter. During deserialization, the embedded gadget chain drives execution, allowing the malware to load and execute an embedded .NET assembly, the next-stage “TestAssembly.dll”, inside the script host process, mshta.exe. 

The JScript orchestrator deserializes the two resources in sequence. It first attempts to deserialize stage_1, which appears designed to disable a .NET security check introduced to block ActivitySurrogateSelector-based deserialization gadget chains. The code wraps this operation in a try/catch block and proceeds to stage_2 when an exception occurs, suggesting the actor anticipated differences in .NET versions, patch levels, or assembly availability across target systems. The two-call behavior observed in stage_1 appears intended to improve compatibility across different .NET patch levels.  

The second serialized resource, stage_2, uses the System.Windows.Forms.AxHost+State deserialization gadget in combination with an ActivitySurrogateSelector gadget chain. This technique substitutes a surrogate object during deserialization to drive code execution. In this case, the gadget chain loads the embedded PE file, “TestAssembly.dll”, directly into memory and executes it inside mshta.exe. 

Stage 4: “TestAssembly.dll” downloader and launcher 

“TestAssembly.dll” is a small .NET downloader and launcher that Stage 3 loads directly into mshta.exe through the BinaryFormatter deserialization chain. It downloads a lure-specific decoy document and a three-file DLL-sideloading bundle from cloud-hosted infrastructure. It opens the decoy, writes the bundle to a writable staging directory, and launches the Microsoft-signed “GatherOsState.exe”, which sideloads “slc.dll”, the Antino backdoor. 

The table below shows the files retrieved during one Taiwan-targeting campaign. Note that the actor uses randomized nonstandard extensions (.luy, .pzs, .syk) that remove obvious executable/DLL filename signaling.  

CDN URL	Actual Content	Description
pub-abfa7742e315485a98a5fafd6dbfb68e.r2.dev/HeiqAW6Z[…].pdf	Lure-specific PDF	Decoy document opened for the victim
pub-abfa7742e315485a98a5fafd6dbfb68e.r2.dev/HeiqAW6ZGatherOsState.exe.luy	GatherOsState.exe (legitimate signed binary)	Legitimate signed binary that loads slc.dll
pub-abfa7742e315485a98a5fafd6dbfb68e.r2.dev/HeiqAW6Zslc.dll.pzs	slc.dll (Antino C2 implant)	Antino backdoor
pub-abfa7742e315485a98a5fafd6dbfb68e.r2.dev/HeiqAW6ZOsGather.dat.syk	OsGather.dat	Calculator decoy PE

All the “TestAssembly.dll” downloader builds recovered in this investigation share the AssemblyAttribute GUID b2b3adb0-1669-4b94-86cb-6dd682ddbea3. This is a useful tooling-level detection marker.   

Stage 5: Signed-host DLL sideloading Antino backdoor 

The downloaded “GatherOsState.exe” is a legitimate Microsoft-signed Windows Assessment and Deployment Kit (ADK) binary that was abused for DLL sideloading. When executed, it loads “slc.dll” from its local directory. The attacker placed the Antino backdoor file slc.dll alongside the signed executable, which then calls the DLL’s SLOpen export to start Antino. 

C2 infrastructure 

Beyond email delivery, UAT-11587 relied extensively on Cloudflare throughout the infection chain. Cloudflare Pages hosted malicious HTA and WSF files and a separate execution-tracking endpoint, while Cloudflare R2 stored encoded loader stages, decoy documents, and payload components. UAT-11587 also used Amazon CloudFront to deliver additional scripts and decoy content. This architecture placed much of the infection chain within widely used cloud services and ordinary HTTPS traffic. 

We also identified software-themed domains that directly hosted standalone Antino executables. The domain “microsoft-flash[.]com”, registered shortly before its use, served Antino samples from “https://microsoft-flash[.]com/download/flashcenter_pp_ax_install_en.exe”. Similarly, “wps-cn[.]com” delivered a related Antino build from “https://www.wps-cn[.]com/downloads/flashcenter_pp_ax_install_en.exe”. The choice of “wps-cn[.]com” may also indicate that the delivery site was designed to appeal to Chinese-speaking users, particularly those in mainland China. 

While the infection chain relied heavily on Cloudflare, Antino itself used Microsoft 365 for post-compromise C2. The “Dead-drop C2 communication” section explains this channel in more detail. 

The Antino backdoor 

Antino is a , Rust-compiled Windows backdoor observed in both 32-bit and 64-bit builds. Talos named the malware after identifying AntinoApp in its Windows application manifest and repeated antino directory names in PDB and Rust source paths across multiple variants. It supports host reconnaissance, command execution, persistence, and Microsoft Graph-based C2, using Outlook for command exchange and OneDrive for heartbeat and file transfer. 

D:\a\antino\antino\target\x86_64-pc-windows msvc\release\deps\slc_template.pdb 
D:\a\antino\antino\target\x86_64-pc-windows-msvc\release\deps\antino_client_template.pdb
D:\a\antino\antino\target\i686-pc-windows-msvc\release\deps\antino_client_template.pdb
D:\a\antino\antino\client\src\core.rs
D:\a\antino\antino\client\src\signaller\mod.rs
D:\a\antino\antino\client\src\artillery\run.rs
D:\a\antino\antino\client\src\config\mod.rs
D:\a\antino\antino\shared\src\command_client.rs
D:\a\antino\antino\shared\src\command\registry.rs
D:\a\antino\antino\shared\src\command\add_to_run.rs
D:\a\antino\antino\shared\src\command\cmd.rs
D:\a\antino\antino\shared\src\command\download_file.rs
D:\a\antino\antino\shared\src\command\execute_program.rs
D:\a\antino\antino\shared\src\command\exit.rs
D:\a\antino\antino\shared\src\command\list_files.rs
D:\a\antino\antino\shared\src\command\load.rs
D:\a\antino\antino\shared\src\command\ps.rs
D:\a\antino\antino\shared\src\command\system_info.rs
D:\a\antino\antino\shared\src\command\upload_file.rs

The “D:\a\antino\antino\...” paths follow the standard GitHub Actions Windows workspace structure, “D:\a\<repository>\<repository>\...”. This suggests that the reviewed CI variants were compiled on GitHub-hosted Windows runners. 

The backdoor was observed in both standalone executable and DLL forms. Our analysis observed two generations of Antino, distinguished by consistent differences in their underlying code and Rust build environment. The clearest implementation differences involve session-ID generation and registration and heartbeat behavior.   

Characteristic	Antino Gen1	Antino Gen2
Observed build period	October 2025	December 2025 to January 2026
Application identity	No AntinoApp manifest in the reviewed builds	Uses the AntinoApp application manifest
Session identifier	XOR- and Base64-encodes the process ID, computer name, username and platform.	Generates a random UUID v4 containing no host-derived information
Registration and heartbeat	Classic builds use sendsession and heartbeat email drafts; an early DLL already supports OneDrive heartbeats	Stores JSON heartbeat objects under “/antino/heartbeats/<session_id>.json”; the heartbeat also registers the implant

Dead-drop C2 communication 

Antino communicates exclusively through Microsoft 365, using the Microsoft Graph API to interact with Outlook and OneDrive as dead-drop C2 channels. Both Antino generations use broadly similar Microsoft 365-based C2 workflows. This design allows Antino’s C2 traffic to blend into legitimate Microsoft application synchronization at the network layer. Outbound connections terminate at “graph.microsoft.com” and “login.microsoftonline.com”, both of which are widely trusted and commonly allowed in enterprise environments.  

The Antino Gen2 implant authenticates to Microsoft Graph using the OAuth 2.0 client-credentials flow. This authentication method allows the registered Entra ID application to access the configured Outlook mailbox and OneDrive resources without requiring an interactive user sign-in. 

The Antino implant uses two distinct mechanisms for C2 communication, implemented in separate modules: 

Mechanism 1: OneDrive file-based communication 

The Antino backdoor uses the threat actor’s OneDrive for registration and file-based communication. The OneDrive folder used for communication includes three folder paths: 

Path	Direction	Purpose
/antino/heartbeats/{id}.json	Antino upload	Beacon / check-in; carries system state
/antino_downloads/{file}	Antino upload	Exfiltrated data from victims (files the operator downloads from victims)
/antino_uploads/{file}	Threat actor upload	Toolkit delivery staging (files the operator uploads to victims)

Antino uses the heartbeats folder to upload JSON-formatted heartbeat files containing host telemetry, including the session ID, timestamp, online/offline status, machine name, username, platform, and a campaign code defined in the backdoor configuration. Each implant session is assigned a randomly generated UUID, which is used as the heartbeat filename “{session_id}.json”. The implant uploads the heartbeat file to OneDrive during initial execution and resends every minute. 

The directory naming is from the threat actor’s perspective. “antino_uploads/” holds tools the operator pushes to victims, while “antino_downloads/” holds data the operator pulls from victims. The file-based polling model is characteristic of dead-drop C2 designs used to decouple operator activity from implant activity on the network. 

Mechanism 2: Outlook commands communication 

The Antino backdoor receives commands through email messages. The implant actively pulls commands from the threat actor’s Outlook mailbox folder every 10 seconds. The protocol uses two message types: command emails contain tasking from the controller, while response emails contain the implant’s results. 

Command messages are identified by the subject prefix command_req_[session_id] and responses by command_res_[session_id], as indicated in the HTTP GET request sent by Antino: 

 The body of each command message contains a JSON object with the information required for execution. It has three fields: command_type, the command to invoke; command_data, an object containing command-specific parameters; and request_id, a per-command identifier used to correlate the request with the corresponding response (the request_id is distinct from the implant session_id used in the message subject and heartbeat). For example, a cmd request has this body: 

 The response follows a similar structure. Its body contains a JSON object describing the outcome of command execution. The command_type field identifies the command that was executed, while request_id links the response to the corresponding request. The success field indicates whether the command succeeded, result contains the returned output, and error provides failure details or is null when execution succeeds. For example, a successful cmd response has the following body:  

Antino-supported commands 

Antino is a comprehensive backdoor that supports several commands for host reconnaissance and execution. Across the reviewed Antino builds, Talos identified the following command handlers. Command availability varies by generation and build.   

Command/handler	Capability
cmd	Runs cmd.exe /C and captures output
powershell	Runs powershell.exe -Command
system_info	Collects host and process context
execute_program	Executes an operator-supplied program
list_files	Enumerates a directory
upload_file	Transfers files from the threat actor’s OneDrive to the compromised host
download_file	Exfiltrates files from the compromised host to the threat actor’s OneDrive
load_shellcode	Runs operator-supplied shellcode in memory
add_to_run	Establishes Antino persistence by adding a Registry Run value
exit	Stops the Antino runtime

Antino-supported commands. Command availability varies slightly by generation and build. 

The cmd and powershell commands allow the operator to execute commands directly through the Windows command shell or PowerShell and collect their output.   

Filesystem operations are handled through list_files, upload_file, and download_file. Similar to the C2 communication protocol, these names are written from the operator’s perspective: upload_file transfers files from the threat actor’s OneDrive to the compromised endpoint, while download_file reads a file from the endpoint and uploads it to OneDrive for operator retrieval.  

Antino provides two options for running actor-supplied code: load_shellcode and execute_program. The load_shellcode command sends a Base64-encoded payload in the command-request email body in the following JSON format: 

Masking the loaded payload 

The use_sleep_mask parameter enables a defense evasion technique intended to reduce the secondary payload’s exposure to memory scanners. When enabled, Antino hooks Sleep and VirtualAlloc and registers a vectored exception handler (VEH). The VirtualAlloc hook records the tracked memory region. When the tracked payload thread calls Sleep, the Sleep hook changes that region to non-executable (PAGE_READWRITE), encrypts its contents in place, and then calls the real Sleep function. 

 After Sleep returns, an attempt to execute code from the encrypted, non-executable region triggers an access violation. The VEH confirms that the fault occurred within the tracked region, restores its previous memory protection, decrypts the content, and resumes execution. This technique is intended to reduce the time during which memory scanners can observe recognizable executable payload bytes. Although this technique does not mask the entire Antino process or guarantee evasion, it adds another layer of defense evasion by reducing the window in which memory scanners can identify the loaded payload. 

Abuse of the Windows Scripted Diagnostics framework workflow  

The Antino backdoor abuses the Windows Scripted Diagnostics framework to execute attacker-controlled PowerShell through legitimate Windows components. Both the execute_program and add_to_run commands use this technique. 

This workflow involves three components:  

• Scripted Diagnostics Execution Engine (“sdiageng.dll”) 
• Program Compatibility Wizard (PCW) troubleshooting package (“C:\Windows\diagnostics\system\PCW”)  
• Scripted Diagnostics Native Host process (“sdiagnhost.exe”) 

Windows normally uses “sdiageng.dll” to load troubleshooting packages such as PCW, while “sdiagnhost.exe” executes their PowerShell scripts in a separate process. 

Antino initializes COM and creates an instance of CLSID {1F3D8AA5-9EBF-4EE4-85C2-EA40379AEDE8}, the CScriptedDiag class implemented by “sdiageng.dll”. It then initializes the engine with the legitimate PCW package and a blank diagnostic Answers XML document. The engine creates a temporary working copy of the package and returns its directory, such as “C:\Windows\Temp\SDIAG_<GUID>”. 

Antino writes an attacker-controlled PowerShell script into this directory. For example, the add_to_run command generates a script that creates an HKCU Run key value: 

Antino then resumes the diagnostic workflow. The Scripted Diagnostics engine delegates execution to the native host, observed in runtime traces as %windir%\SysWOW64\sdiagnhost.exe -Embedding. The host subsequently executes result.ps1. The resulting Run key entry launches the selected Antino executable the next time the affected user signs in. 

 The technique allows Antino to proxy PowerShell execution and the persistence-related registry modification through a Microsoft-signed diagnostic workflow. This can complicate behavioral attribution to the original implant, although it does not eliminate observable PowerShell, file-creation or registry telemetry. 

Antino configuration  

Antino stores the configuration data in a custom PE section named .cfg. The on-disk structure begins with a four-byte little-endian JSON length followed by bytes XORed with the alternating key 0xAB 0xCD.  

In addition to its C2 configuration, Antino’s embedded configuration contains two deployment settings, run and launch_mode. The run field controls whether Antino automatically installs a persistent copy when it starts. When set to true, Antino launches its installation task, stages the required files under %LOCALAPPDATA%\Windows GatherOSStateKit\, and creates an HKCU Run value. launch_mode is evaluated only when run is set to true. It defines which files constitute the persistent payload: exe or raw for standalone PE or dll for sideloading. 

Coverage 

The following ClamAV signatures detect and blocks this threat:  

• Html.Trojan.UAT-11587-10060367-2 
• Txt.Trojan.UAT-11587-10060385-5 
• Txt.Trojan.UAT-11587-10060386-1 
• Win.Trojan.UAT-11587-10060365-1 
• Win.Trojan.UAT-11587-10060366-1 
• Win.Trojan.UAT-11587-10060369-1 
• Win.Trojan.UAT-11587-10060370-1 
• Win.Trojan.UAT-11587-10060371-1 
• Win.Trojan.UAT-11587-10060372-1 
• Win.Trojan.UAT-11587-10060373-1 
• Win.Trojan.UAT-11587-10060374-1 
• Win.Trojan.UAT-11587-10060375-1 
• Win.Trojan.UAT-11587-10060376-1 
• Win.Trojan.UAT-11587-10060377-1 
• Win.Trojan.UAT-11587-10060378-1 
• Win.Trojan.UAT-11587-10060379-1 
• Win.Trojan.UAT-11587-10060380-1 
• Win.Trojan.UAT-11587-10060381-1 
• Win.Trojan.UAT-11587-10060382-1 
• Win.Trojan.UAT-11587-10060383-1 
• Win.Trojan.UAT-11587-10060384-1 

The following Snort rules cover this threat:  

• Snort 2: 1:66880, 1:66881, 1:66882 
• Snort 3: 1:66880, 1:66881, 1:66882 

Indicators of compromise (IOCs)  

IOCs for this research can also be found at our GitHub repository here. 

e809da86bd81463347fa7f922d3e088755a94a331889d32acb55aa8f57778a34 (malicious HTA stager - CSIS Indo-Pacific lure) 

e6ff096a0562c0042b09d250bd60272ffcd8d72bd95c563842acf765a8dc8bcf (malicious HTA stager - Bajo de Masinloc lure) 

4d0fdce4c098635fe9b296c3a82c74645f9885eb5e383aa44a0fe7e50da3ca3f (malicious HTA stager - Taiwan information-warfare workshop lure) 

f1ef5fe4c0cdcff13cc750c867728b89719f81437bdc49041edd1ae1f3edb4e8 (malicious HTA stager - Taiwan legislative-tax lure) 

01b5c6acb20e41799a0e96d9d1d6e1c44791883706b6285e874fcb15cc93b31a (malicious HTA stager - Venezuela and Ukraine news lure) 

5a35fcd4458e808ab0fa52bb2a92923b60566ee4d7aaadaac7c95cad3d839562 (malicious HTA stager - Venezuela and Ukraine news lure) 

17b53ffa8e005f0e82491d3f9c0a4984c44da52e1668a855c11a137f627c5b4b (malicious HTA stager - institutional disciplinary-action lure) 

484ab497072ea09f12187b349f5b1c80754e4942408a009cccb20a2a3c8c6506 (malicious WSF stager - institutional disciplinary-action lure) 

3a94910eb8022592ce030e6861359f7e980fc1b5a6ccd290cbb071d3e95ed02a (malicious HTA stager - TPiE inauguration lure) 

6a1dbbfcfe6867ac83d35012b2717084388b4a34707efd0b725466dfd0e8fa56 (malicious WSF stager - TPiE inauguration lure) 

75c12795016ae48b1bddd34a9f5adea63a12f58701eae01e1b4ab3d9dfa1513c (malicious HTA stager - Tehran bilateral-summit lure) 

bd8ddc8f33e0fe43147ee6f1713654996420a27c5d2cd91751ad67124ebc6fe4 (malicious WSF stager - Tehran bilateral-summit lure) 

b75492466462141c56d97b705f0c606faf272577631dc2822aa8d6bda53633b6 (malicious HTA stager - cross-border repression seminar lure) 

23d5f1af8581ae200615d9a66d539f2043c3248b649e862557b379d7e8b7a3ac (malicious WSF stager - cross-border repression seminar lure) 

0b4e5e017c0f0ccac79e13ca5d580a75af67a24ca0763f9ebfdaaeb1ba4fc739 (malicious HTA stager - Latin carnival lure) 

ae1b45fb56b9f1b9cb3ee30d2bb1279c9b90b70bb62f8de305d198c6a4e0585e (malicious WSF stager - Latin carnival lure) 

cd3509fa82e506cc6f2eeafa0a45d4b8b76a07edadd29779daf00568febcaba7 (malicious HTA stager - C-DAC lure) 

b8e6e83a73e6e07f8873c364dd2a4b830bceb60758163e2efcd7e387cb604655 (malicious WSF stager - C-DAC lure) 

7969ae5f11fc163049c8eadba06f814f5edece13a707e6087c1c49011a45b838 (malicious HTA stager - Latin carnival lure variant) 

aea5e9029f9212d05bde10f7806d1f2819be45d167e6fd877b9fb1b11088ac90 (malicious WSF stager - Latin carnival lure variant) 

7fa98efba59614cec0b7291aedee98764f8dc037b6cc798c93951a31208e9e32 (malicious HTA stager - internal-review lure) 

65f4b9292e91abfa5adf42a03526932930c1c0a436bb186a7948fe6770295788 (malicious WSF stager - internal-review lure) 

61a8f5add6c35f99c389012dbb2343061fd0b54611b40490b9a7f0b49d707da0 (Antino-chain Stage 2 JScript downloader and decryptor) 

747b1d13bdf06956b5da5f47250fefd5284ebcf7961971732c3d348aa1a2d533 (Antino-chain Stage 2 JScript downloader and decryptor) 

a13182699a12a8dd9d07c336dbd8de5e9b086b9b09793b7de2e9761aa03ce1dc (Antino-chain Stage 2 JScript downloader and decryptor) 

2f1513c822af0c6635dd3c69dc38f0b2f6e02012ea36415fff111a5d4d5fae05 (Antino-chain Stage 2 JScript downloader and decryptor) 

a0e91085f08956a9a7034ace73cee60cb211f5d96f02bc91a026601bde8f2221 (Antino-chain Stage 2 JScript downloader and decryptor - HTA branch) 

47f98dfe01759a464e22d5ec55d012dccb38ce010dd73e3ba8d7ffefca12b4b2 (Antino-chain Stage 2 JScript downloader and decryptor - WSF branch) 

b3416726a064dd7f657bbb400adeb365eea7f8bb60783ad2d9da1a1d93768731 (Antino-chain Stage 2 JScript downloader and decryptor - HTA branch) 

0a6fb71ab1362d065c7ec2678c1e73d9a0721b0e7099d392ba7559bb2eec4970 (Antino-chain Stage 2 JScript downloader and decryptor - WSF branch) 

f0c1dc6d6daa4d010932c7818ed5f22929c182f58e5f495fabe2fb3cfc835b97 (Antino-chain encrypted JScript orchestrator) 

5555e904101689351a2a1359c9c06da0a57139a9470df7d26823c1b75db55041 (Antino-chain encrypted BinaryFormatter resource) 

5168a2696a0ed858f996f388bfe94f952d475158f4ee6206816608936db005ca (Antino-chain encrypted BinaryFormatter resource) 

7c2ac9c040b3300bffa7d2e435dbb1bc12e7efd644d2216d603c72121266395c (Antino-chain encrypted JScript orchestrator) 

d87201c1299a7f5854929645e6891c6c424d2a690031272bedacba7c5fe73a3e (Antino-chain encrypted BinaryFormatter resource) 

334f39279ff3aae40fe74340c887ae018c75bc42790586bdf9070adb5889100c (Antino-chain encrypted BinaryFormatter resource) 

077bd873217d8abfbb6482d11966ca34f3fef7ad5166f24fbc5dc3ddefe894a1 (Antino-chain encrypted JScript orchestrator) 

ad0bd2b45e2416fb1384bf30af068d857e7c06b4226615d66b55b610a34c5670 (Antino-chain encrypted BinaryFormatter resource) 

e2f59d8d5a81583ed482b6c7bf37699efdb2264e452cf7d8cfc0c54dfbd9ab3f (Antino-chain encrypted BinaryFormatter resource) 

3a4c9020eeb5ef22a1ff443e606ccb6705fe287c583121c713d2c9f9f1f2a2af (Antino-chain encrypted JScript orchestrator) 

4b614e5c37abaddca162119e42a969945caa681305e246e0ed0060ea9984008b (Antino-chain encrypted JScript orchestrator) 

c8e1239d7276178b6620f47ec4880494be1cb394477b223fc54bffb0947bff50 (Antino-chain encrypted BinaryFormatter resource) 

079acd58a74479ac8b108b618d2a4da8a8bd560a04459cd90e2fec9da5027513 (Antino-chain encrypted BinaryFormatter resource) 

8e1d68906d6de92f359945d3a95da1480e72773a3e8dea7682d6bf0f6699f75f (Antino-chain encrypted JScript orchestrator) 

170b0eee60a335f32c1d0c19a0bb8d8bbc0a5b298ea9486b546f58d25cc8a464 (Antino-chain encrypted BinaryFormatter resource) 

b31ca75f73a9363b0e35042a41216c3f581eaa0b9cd78cb58f089c2e40babd40 (Antino-chain encrypted BinaryFormatter resource) 

d753a615aedf8e58ffc75b2b7ebd320c0cbe6bcb5cbb885db749a2a85c55d3bf (Antino-chain TestAssembly.dll downloader) 

133a46ba41136ca21c93fb08c28446826d8c0d9b7923a16f2d152d595a710098 (Antino-chain TestAssembly.dll downloader) 

9fc50cf28f86201fda8306926817b1ede41fdd993202515905dd072f6803542f (Antino-chain TestAssembly.dll downloader) 

d4cb2f5df16ec9b9c5b796ae55848534e15d4f8b8806f0431108fc7a99a2548a (Antino-chain TestAssembly.dll downloader) 

131ac3e0df777910e0a32e43d5744bccb0490750d4c2adc359da41d76d383c46 (Antino-chain TestAssembly.dll downloader) 

09ef7c736bccfafefc44d9910d499173b88063b73b221fc0dc9e9105107e5cff (Antino Gen 2 slc.dll backdoor) 

0c39264337a1186b2e765e24073399cbdcba118306614eb411e315887af578bd (Antino Gen 2 standalone fake-installer backdoor) 

1fadc90b61ce536abda78eb387a7f3d745f00c16775d3f762845ccc0fde567da (Antino Gen 1 slc.dll backdoor) 

40e7e77aff603f4c2ef17b3bc8ea836e714d0734a1e5b946e52f95536ec5c91d (configured Antino Gen 1 standalone backdoor) 

5c5c060b272cd4a5c3767edc0e9478bd35b7e1756e183d0446a5491bd65519cb (configured Antino standalone backdoor) 

971cb2448b5d67dcc1f5eaa10d12e77f213035ad31230dc2ac7a510610a2059d (Antino Gen 2 standalone fake-installer backdoor) 

9b7df409c9a89f7536d3ba7b6d43fb6dbac618c8bb52615ba34cc971ad71bbf3 (Antino Gen 2 standalone fake-installer backdoor) 

b90a4e770869c28fd2140acb3ebdc50c113bb6f096b4bbdb9ac87c349c70e85e (Antino Gen 2 standalone fake-installer backdoor) 

ca14ad0344dc7216f6da29a5cbe4237d886cc5257e8c3a48fb4885a311c9b800 (post-unpack Antino standalone backdoor memory image) 

e2eb7703047b37b28dc34e6990205d758a2454b39bc655b460606745fadcb530 (Antino Gen 2 slc.dll backdoor) 

e7e3b0bcd6798634adf8b49d305f3a7b7682e4b76db549682a183c5a186df4bb (Antino Gen 2 slc.dll backdoor) 

fdbd047031c13a17c9f491c9355f44d587584ebe2b8927be8482e6c236c8e1c1 (Antino Gen 2 slc.dll backdoor) 

103[.]27[.]110[.]220 (historical serving IP for the Antino payload hosted on wps-cn[.]com) 

osc-cdn[.]com (actor-used spear-phishing sender domain) 

oisadjfoinsiduhfnoisdnfosdnoifnsoid[.]pages[.]dev (Cloudflare Pages execution-tracking domain) 

d2nq35tel3ucuo[.]cloudfront[.]net (Antino-chain CloudFront staging domain) 

pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev (Antino-chain Cloudflare R2 staging domain) 

pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev (Antino-chain Cloudflare R2 staging domain) 

my-3lyt6wcp[.]pages[.]dev (Cloudflare Pages delivery domain) 

my-qc39r814[.]pages[.]dev (Cloudflare Pages delivery domain) 

my-662ylt3w[.]pages[.]dev (Cloudflare Pages delivery domain) 

my-6g16qsfe[.]pages[.]dev (Cloudflare Pages delivery domain) 

my-goq6xmbm[.]pages[.]dev (Cloudflare Pages delivery domain) 

my-h3qli6kq[.]pages[.]dev (Cloudflare Pages delivery domain) 

my-sv7c1fzs[.]pages[.]dev (Cloudflare Pages delivery domain) 

my-u0up9qri[.]pages[.]dev (Cloudflare Pages delivery domain) 

my-vtsdod2n[.]pages[.]dev (Cloudflare Pages delivery domain) 

my-wgoxp32b[.]pages[.]dev (Cloudflare Pages delivery domain) 

microsoft-flash[.]com (standalone Antino fake-installer delivery domain) 

wps-cn[.]com (standalone Antino fake-installer delivery domain) 

hxxps://microsoft-flash[.]com/download/flashcenter_pp_ax_install_en.exe (standalone Antino fake-installer delivery URL) 

hxxps://www[.]wps-cn[.]com/downloads/flashcenter_pp_ax_install_en.exe (standalone Antino fake-installer delivery URL) 

hxxps://my-662ylt3w[.]pages[.]dev/Institutional_Disciplinary_Action_Report_May_2026.hta (malicious HTA delivery URL) 

hxxps://my-662ylt3w[.]pages[.]dev/Institutional_Disciplinary_Action_Report_May_2026.wsf (malicious WSF delivery URL) 

hxxps://my-6g16qsfe[.]pages[.]dev/the%20May%2027%20inauguration%20of%20the%20TPiE.hta (malicious HTA delivery URL) 

hxxps://my-6g16qsfe[.]pages[.]dev/the%20May%2027%20inauguration%20of%20the%20TPiE.wsf (malicious WSF delivery URL) 

hxxps://my-goq6xmbm[.]pages[.]dev/Tehran_Bilateral_Summit_Proceedings_May2026.hta (malicious HTA delivery URL) 

hxxps://my-goq6xmbm[.]pages[.]dev/Tehran_Bilateral_Summit_Proceedings_May2026.wsf (malicious WSF delivery URL) 

hxxps://my-h3qli6kq[.]pages[.]dev/CrossBorder_Repression_Seminar_Agenda.hta (malicious HTA delivery URL) 

hxxps://my-h3qli6kq[.]pages[.]dev/CrossBorder_Repression_Seminar_Agenda.wsf (malicious WSF delivery URL) 

hxxps://my-sv7c1fzs[.]pages[.]dev/Extravaganza%20Latin%20Carnival.hta (malicious HTA delivery URL) 

hxxps://my-sv7c1fzs[.]pages[.]dev/Extravaganza%20Latin%20Carnival.wsf (malicious WSF delivery URL) 

hxxps://my-u0up9qri[.]pages[.]dev/UO%20-C-DAC%20%281%29.hta (malicious HTA delivery URL) 

hxxps://my-u0up9qri[.]pages[.]dev/UO%20-C-DAC%20%281%29.wsf (malicious WSF delivery URL) 

hxxps://my-vtsdod2n[.]pages[.]dev/Extravaganza%20Latin%20Carnival%20post%20copy.hta (malicious HTA delivery URL) 

hxxps://my-vtsdod2n[.]pages[.]dev/Extravaganza%20Latin%20Carnival%20post%20copy.wsf (malicious WSF delivery URL) 

hxxps://my-wgoxp32b[.]pages[.]dev/Internal_Review_Dossier_0520.hta (malicious HTA delivery URL) 

hxxps://my-wgoxp32b[.]pages[.]dev/Internal_Review_Dossier_0520.wsf (malicious WSF delivery URL) 

hxxp://d2nq35tel3ucuo[.]cloudfront[.]net/4oyE4n4ozLQ0.log (Antino-chain Stage 2 URL) 

hxxp://d2nq35tel3ucuo[.]cloudfront[.]net/LtVGUSsyUTDA.log (Antino-chain Stage 2 URL) 

hxxp://d2nq35tel3ucuo[.]cloudfront[.]net/TzzyYlYnJ40Z.log (Antino-chain Stage 2 URL) 

hxxp://d2nq35tel3ucuo[.]cloudfront[.]net/tdyvHHVcrci8.log (Antino-chain Stage 2 URL) 

hxxp://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/Qw7Womin4X6N (Antino-chain Stage 2 URL) 

hxxp://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/kVFPxm1uAjOY (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/5SVIdjpRQjkZ (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/PbyfSk69AwVf (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/qMD71Z95clTf (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/HenUWB51MwpG (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/q9LgxIaU1CJK (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/BKvYRxPiGpbM (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/nswz3cb9lhuC (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/6HJV5qV5BTLs (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/MKJacn3hFt3Y (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/cX8MChhuVvzz (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/byrdvvZEZZlk (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/5TGrbjCCLa8M (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/s0p18dgHR4PZ (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/zlKDeyO3HuUS (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/icWMOGLJcfQO (Antino-chain Stage 2 URL) 

hxxp://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/5U7kzhvlYlVF (Antino-chain Stage 2 URL) 

hxxps://d2nq35tel3ucuo[.]cloudfront[.]net/9q9OlLKCm0an2ct1.js (Antino-chain encrypted JScript orchestrator URL) 

hxxps://d2nq35tel3ucuo[.]cloudfront[.]net/LwqPW64Xl0ti3q7s.txt (Antino-chain encrypted BinaryFormatter resource URL) 

hxxps://d2nq35tel3ucuo[.]cloudfront[.]net/HsOw0YU9s11dxyr1.txt (Antino-chain encrypted BinaryFormatter resource URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/0u25lAqY58or53ra.js (Antino-chain encrypted JScript orchestrator URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/gpv0IRMtvto6e8t2.txt (Antino-chain encrypted BinaryFormatter resource URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/HzjNPgRE9ir92e38.txt (Antino-chain encrypted BinaryFormatter resource URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/2laZiB2zvnx04jze.js (Antino-chain encrypted JScript orchestrator URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/wyLwwCu43j1wf2pg.js (Antino-chain encrypted JScript orchestrator URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/ThyI9pwewrh_a1pr.txt (Antino-chain encrypted BinaryFormatter resource URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/8ypvQLxJvggmrz94.txt (Antino-chain encrypted BinaryFormatter resource URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/vD68BdmB2ky28gcc.js (Antino-chain encrypted JScript orchestrator URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/oaFE7PJHk0h_emqt.txt (Antino-chain encrypted BinaryFormatter resource URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/AcPP9fCvdjztmho8.txt (Antino-chain encrypted BinaryFormatter resource URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/7ChyKauxbnuftp68.js (Antino-chain encrypted JScript orchestrator URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/KOOOT4a76st012bx.txt (Antino-chain encrypted BinaryFormatter resource URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/Ub4RJzNIrfleri8t.txt (Antino-chain encrypted BinaryFormatter resource URL)  

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/HeiqAW6ZGatherOsState.exe.luy (Antino sideload-package URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/HeiqAW6Zslc.dll.pzs (Antino backdoor delivery URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/HeiqAW6ZOsGather.dat.syk (Antino sideload-package URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/hjgzBskgGatherOsState.exe.lzj (Antino sideload-package URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/hjgzBskgslc.dll.iwq (Antino backdoor delivery URL) 

hxxps://pub-abfa7742e315485a98a5fafd6dbfb68e[.]r2[.]dev/hjgzBskgOsGather.dat.ael (Antino sideload-package URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/bzP3NcRPGatherOsState.exe.thl (Antino sideload-package URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/bzP3NcRPslc.dll.czh (Antino backdoor delivery URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/bzP3NcRPOsState.dat.mxb (Antino sideload-package URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/VD7F3WxnGatherOsState.exe.mtm (Antino sideload-package URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/VD7F3Wxnslc.dll.fsc (Antino backdoor delivery URL) 

hxxps://pub-0173d1566dcd4fd49fa25f11f14bfe4c[.]r2[.]dev/VD7F3WxnOsState.dat.pgy (Antino sideload-package URL) 

• Cisco Talos recently identified an undocumented phishing framework, internally branded "JWR" by its developer, built to convincingly impersonate checkout and login pages across major payment and shopping platforms. 
• The client engine of the JWR phishing framework is a real-time, operator-driven system that, rather than merely logging form submissions like a static credential-stealing page, keeps an AES-CTR encrypted WebSocket open to the threat actor so they can steer each victim's session live. 
• The victim data targeted by the actor using JWR extends well beyond payment data, encompassing identity documents, Social Security numbers, passport and driver's license images, website and PayPal credentials, 2FA codes, and full device fingerprints, all committed to the actor's server once a session ends.  
• Talos assesses with medium confidence that the JWR phishing framework is a variant of "The Outsider," a phishing-as-a-service (PhaaS) platform, based on several similarities in the client engine scripts and functionalities of the two PhaaS platforms. 
• Talos observed a real-world campaign delivering the JWR client via SMS lures impersonating toll authorities, and postal and courier services of several countries in Southeast Asia and the Middle East.

---

JWR phishing framework, a likely variant of the Outsider 

JWR is a phishing framework capable of harvesting complete payment card data, login credentials, and personally identifiable information (PII) documents and images in real time. The client-side engine of the framework impersonates login, and checkout flows of several payment gateways, including Shopify, PayPal, Apple, Klarna, and banks, while allowing the operator to stealthily control the victim session through an AES-CTR encrypted WebSocket channel. The client engine architecture is divided into a Host Bridge module that relays commands into a phishing inline frame (iframe) and a Vue.js victim application that renders across 44 phishing pages, streams the victim's keystrokes to the actor as they are typed, and carries out more than 40 distinct instructions issued from the command-and-control (C2) console. The data exfiltration schema is a cvvform object that includes fields such as credit card number, CVV, PIN, expiry date, Social Security Number (SSN), passport or ID images, two-factor authentication (2FA) codes, website logins, PayPal credentials, and device fingerprint.  

Talos discovered that the JWR client engine shares significant code and functional similarities with the client of The Outsider PhaaS platform operated by the Chinese-speaking actor “Outsider Enterprise,” which was reported by external researchers. 

JWR client architecture and workflow

The execution starts when the parent phishing webpage loads and executes the client's engine. It checks a single global flag, window.__HOST_MODE, which is set by the parent phishing page, and selects one of two execution modes. If the flag is set, the script enters Host Mode, and control passes to the Host Bridge module, an immediately invoked function expression (IIFE) that operates within the parent page, typically a replica of a legitimate checkout or account login page, relaying received details into a child iframe that contains the actual phishing form. It establishes a persistent WebSocket connection to the actor’s C2 server. 

If the flag is not set, the page enters Content Mode, and control passes to the Vue.js Application, an interactive front end that renders the phishing pages, collects victim input, manages the flow across 44 HTML files, and handles the actor’s instructions from the C2 server, ultimately redirecting to a custom error page after sending the data to the C2. The Content Mode of execution has three communication modes: standalone, pluginIframe, and hostIframe. 

• In standalone mode, the application fully owns its WebSocket connection. 
• In pluginIframe mode, it has no direct link to the network at all and instead sends everything upward to an embedding plugin frame. 
• In hostIframe mode, it defers entirely to a parent page already running as the relay bridge. 

Regardless of which of these three modes or through the Host Bridge is used, the data is either sent to C2 as plain text in JSON format with the DEV_MODE flag set, or it is passed to the JwrCrypto module, which encrypts it with a newly generated key before sending it to the C2 server.  

The script engine includes a background worker module that maintains the connection with C2, keeping it alive independently of page navigation for the remainder of the session. In a live session activity, the script continuously streams the victim’s keystrokes to the actor's C2 server as captured data, while that the actor continuously sends the next instruction to be executed from the C2 server. Each incoming instruction is checked by the client engine against a brief history to ensure that nothing already executed runs twice, then routed by the Instruction Handling module to one of two outcomes including, redirecting the victim to a different phishing page or updating the current page's state and displayed status, awaiting the actor’s next instruction. This execution loop repeats until the actor decides to keep the session alive, and when the actor chooses to close the session, the accumulated data is transmitted to the C2 one last time, and the victim is redirected. 

JWR Client’s host bridge mode  

In host bridge mode, the IIFE establishes a persistent WebSocket connection to the actor's server, manages the victim's session identity, excludes repeating incoming instructions, and proxies all communication between the server and the phishing child iframe. 

Every victim is assigned a unique session token the moment the bridge initializes. It first checks persistent storage for an existing JWRCID value if the victim has visited the page before, and if true, the same token is reused, allowing the actor to correlate multiple visits from the same device. If none exists, a new token is generated in the format JWRCVV-{Date.now()}-{random1}-{random2}, with both random segments being 13-character base-36 strings, and this token becomes the victim's permanent identifier for the entire C2 communication. 

The module then spawns a Web Worker from a separate script located at static/js/ws-worker.js, which isolates the WebSocket from the main JavaScript context, allowing the connection to persist during navigation within the phishing flow. The WebSocket connection path is constructed as webSocket/QT/{sessionId}/khkjsahfjkwhakjlsdwdddddd88, where the alphanumeric suffix is likely a server-side authentication token that ensures the connection originates from a deployed kit instance. 

The host bridge incorporates an anti-analysis check, which serves as a one-time execution guard that performs a self-referential .toString().search() call against a backtracking regex. This check detects whether a debugger has attached the function to modify its apparent source. Additionally, a decoy variable is scattered throughout the code to mislead static-analysis tools. 

Moreover, it maintains a JSON array named JwrExecutedInstructions in sessionStorage to prevent the same operator instruction from executing more than once. Before relaying any instruction into the phishing iframe, it verifies the instruction ID against a list. If a match is found, it discards the repeating instructions. If it is a new instruction, it sends an acknowledgment back to the C2 server in the format {type:"instructionAck", instruction_id:, cvv_id:}. The list is limited to 50 entries and is trimmed to retain the most recent 30. 

Content Mode operation (Vue.js application), the real-time capture 

The Vue.js victim application developed by the JWR developer is a single Vue 2.X instance, window.vm = new Vue ({el: ‘#app’, ...}), mounted on a Document Object Model (DOM) element with the id “#app”. This application serves as the phishing page that the victim sees and interacts with. It is responsible for rendering the checkout forms, collecting and streaming input to the C2, executing the actor’s instructions, and performing the exfiltration function. 

When the Vue instance is constructed, the created function is executed, processing the data passed from the fake webpage the victim visited, but without attaching the page. It generates the session ID and clears any sensitive fields leftover from a prior page visit if the victim had previously accessed the same fake page. It also restores any previously saved session state from “sessionStorage” if it exists. Then, it redirects the victim from any page other than index/login/home that lacks a session ID to a_index.html, ensuring the victim enters the phishing flow. Finally, the Vue takes the rendered output and attaches it to the #app element in the page's DOM, making the interface visible and interactive to the victim. 

Once the DOM is ready, Vue executes the mounted function asynchronously, at which point the victim becomes visible to the actor. It determines the engine’s execution mode and then executes two functions: getIPInfo() to geolocate the victim’s IP address and getSyncSettings() to pull the actor’s configuration from the C2 server. Next, it initializes the communication channel, captures the victim's action, and creates a CVV form with the victim's device fingerprint data. This includes the victim's current form of state, such as device type, browser, language, time zone, and geolocation, which are encrypted and sent to the actor's C2 server. 

One of the key features of the JWR kit is its near-real-time input streaming. Each input element in the phishing form is transmitted to the actor’s console, allowing the actor to view partial card numbers, partial passwords, and partial verification codes as the victim types, without needing to wait for the victim to click any submit button. This mechanism enables the actor to see the victim's data and determine which instruction to send to the client's engine from the C2 before the victim even submits the form. 

Before the Vue instance is created, the client engine establishes an instruction mapping table that correlates over 40 actor command names with specific HTML page filenames, thereby granting the actor remote control over the victim browser session. 

The JWR client script includes a C2 command dispatcher. When the actor sends an instruction, the client receives, decrypts, and forwards it to the dispatcher function, which routes it to the appropriate handler based on the instruction type. The table below displays the actors' instructions from C2, facilitated by the JWR client kit. 

Instructions	Purpose
to_index	Send victim to the landing/entry page
to_login	Send victim to site-login page
to_password	Prompt for account password
to_info	Collect PII
to_card	Send victim to card-entry page
to_qr	Show QR code for scan-based verification
to_sms	Request SMS OTP
to_sms_login	Request SMS OTP for login step
to_sms_bank	Request SMS OTP for bank verification
to_2fa	Request 2FA code
to_text_verify	Request custom text/code verification
to_email	Request email OTP
to_pin	Request card PIN
to_app	Request bank-app push approval
to_login_app	Request app-based login approval
to_bank_login1	Step 1 of multi-stage bank login
to_bank_login2	Step 2 of multi-stage bank login
to_bank_login3	Step 3 of multi-stage bank login
to_custompage	Route to a custom/template-defined page
to_shop	Show fake storefront/shop page
to_paypal_login	Collect PayPal login credentials
to_paypal_card	Collect card data via PayPal-branded flow
to_paypal_card_verify	Request card verification text (PayPal flow)
to_paypal_sms	Request PayPal-linked phone OTP
to_paypal_email	Request PayPal-linked email OTP
to_paypal_pin	Request PayPal PIN
to_paypal_app	Request PayPal app-approval verification
to_apple_login	Collect Apple ID login
to_apple_sms	Request Apple-linked SMS OTP
to_apple_email	Request Apple-linked email OTP
to_apple_card	Collect card data via Apple-branded flow
to_apple_verify	Request generic Apple verification step
to_klarna_login	Collect Klarna login credentials
to_klarna_sms	Request Klarna-linked SMS OTP
to_klarna_email	Request Klarna-linked email OTP
to_klarna_pay	Collect Klarna payment details
to_klarna_pin	Request Klarna PIN
to_success	Sends full data to the C2 and redirect victim to a real site
to_redirect	Redirect victim out to an operator-supplied URL
tip_fail	Show generic declined/invalid error, force re-entry
tip_custom_fail	Show an operator-authored custom error message
to_page_custom_fail	Route to a custom failure page defined per template
tip_change_card	Fake card-declined prompt to extract a second/different card
updata_img	Push a new image likely a refreshed QR code without navigating
updata_2fa	Silently inject/display an OTP code supplied by the operator
text_updata_verify	Push custom verification text to display, without navigating
submitResult	Operator pushes a corrected or enriched copy of the victim's form data back into the session

The JWR client engine has a data exfiltration schema. Its scope extends well beyond payment data, and includes full identity information (name, gender, date of birth, Social Security Number, passport, driver's license, medical record number), address, email and email password, up to three sets of website credentials, PayPal login, complete card data (PAN, expiry, CVV, PIN, brand, issuer, issuing country), front and back card images, photos of identity documents, and an automatically captured browser fingerprint, including IP, device, language, time zone, user agent, cookies, and geolocation. 

Upon submission, the client normalizes the submission types, triggering a full-screen non-interactive overlay over the page. For credit card submissions, a Lottie animation is displayed that corresponds to the card brand detected from the first two BIN digits. After exfiltration, when the actor closes the WebSocket, terminate the worker and POST the entire cvvformobject to the C2 endpoint at api/open/the_final_interface. Once the actor confirms, the victim is redirected to the actual site. 

Talos discovered that the primary mode of C2 communication for the JWR kit is via a binary WebSocket connection. The WebSocket path follows the format shown below, where the JWRCID and JWRCVV segments encode the victim’s unique session token, and the trailing alphanumeric suffix is likely a server-side authentication token. 

Alongside the WebSocket, the JWR client registers five Representational State Transfer (REST) endpoints which are used as an alternate communication method, between the C2 and the victim browser. In this case, a session opens with api/open/addClick, executed once from within the mounted function after the phishing page becomes visible to the victim. It reports the victim's IP address, country, the specific phishing page they landed on, the referring or storefront URL, and a bundle of device and operating system (OS) metadata to the actor's console with a live "new visitor" entry before a single instruction has even been sent by the actor from the C2 server. Running alongside it is api/open/getSyncSettings, which pulls inbound configuration from the actor's server rather than exfiltrating anything, letting the actor change error messages, default contact placeholders, currency display, and other behavior on the fly without redeploying the client engine. For the victim’s environments where a persistent WebSocket connection is unavailable or blocked, api/open/pollInstruction provides an HTTP long poll fallback that delivers the same operator instruction objects the socket would otherwise push, keeping the actor's remote control functional even under restrictive network conditions. The session closes with api/open/the_final_interface, the client engine terminal exfiltration call. Once the actor issues a release instruction, the WebSocket connection and background worker are closed, and the entire accumulated cvvform object, every field collected across the full victim session — card data, identity documents, credentials, and fingerprint alike — is sent via HTTP POST to the C2 endpoint. 

The below table represents the endpoints and the purpose.  

Endpoint	Purpose
api/open/addclick	Victim arrival beacon with fingerprinting data sent to C2
api/open/getSyncSettings	Gets actor-controlled settings from the C2
api/open/the_final_interface	POSTs the entire cvvform – exfiltration endpoint
api/open/pollInstruction	Gets the actor’s instructions from the C2
api/open/addCvv	Exfiltration endpoint

The JWR client has purpose-built integrations for two major e-commerce platforms Shopify and WooCommerce. For Shopify deployments, the client reads the cart_data URL parameter which is a signed JSON blob that Shopify passes between checkout steps and extracts the checkout domain to use as the WebSocket base URL. This makes the WebSocket connection seem to originate from a legitimate Shopify domain. The initShopifyProductInfo() and initWordPressProductInfo() functions reconstruct the victim's shopping cart from the Shopify cart data, populating the phishing page with accurate product names, quantities, unit prices, and order totals making the fake checkout indistinguishable from the real one. 

The operator facing status messages of the JWR framework are entirely written in Simplified Chinese and read as a professional admin dashboard notification feed phrases like "正在填写PayPal登录账号" (filling in PayPal login account), "进入2FA验证页, 请发送验证, 等待用户提交" (entering 2FA verification page, please send verification, waiting for user submission), and "均失败" (all failed), indicating that a Chinese-speaking actor is operating this scam campaign. 

JWR phishing framework’s card stealing scenario 

When the victim lands on the fake page, their browser sends an arrival beacon, indicating to the actor that a new visitor is present. From there, the actor takes over, sending a to_info instruction that directs the victim to a personal details page. While the victim types, the actor sends no further instructions but monitors the data stream live. Once the actor has assessed the victim's personal information, they issue a to_card instruction, moving the victim to the card entry page, where the same stealth live streaming occurs as the card number is typed in digit by digit. 

If the actor isn't keen on the typed card details, tip_fail or tip_change_card instructions are sent, which deliver a fake "your card was declined" message to the victim and returns them to the card page to try a different one. This loop can repeat as many times as the actor wants, each attempt aimed at harvesting another card from the same victim. If the card is accepted instead, the operator sends one of the instructions: to_sms, to_2fa, to_pin, or to_app, directing the victim to a verification page to confirm their identity with a one-time code. For the rejected code, the actor sends the tip_fail instruction, which prompts the victim to re-enter it, while an accepted one leads to the final instruction, to_success, which redirects the victim to the real website, concluding the session with the actor now having the victim’s data that was typed.  

The ongoing scam campaign  

Cisco Talos observed an attacker utilizing an SMS phishing technique, sending SMS related to toll or road-pricing fees, postal or courier fees lures that contain a malicious URL targeting potential victims. When victims click on the URL, it opens a fake webpage that executes embedded JavaScript, which then renders and loads the client-side JavaScript engine of the JWR phishing framework. 

The victimology of this scam campaign illustrates a broad, multi-country SMS phishing (smishing) operation rather than a single targeted campaign. Most of the malicious URLs impersonate a national land transport authority and its vehicle services or road toll payment portal, consistent with an "unpaid toll or road pricing fine" lure in Singapore. A second set of malicious URLs impersonates a national postal service, aligned with a "parcel held pending a customs or delivery fee" lure, alongside a smaller cluster mimicking an electronic toll collection system in the UAE. The third set of URLs impersonates a regional courier brand utilized across several Southeast Asian countries, again centered around the undelivered parcel or cash on delivery fee theme. 

Talos discovery of the similarities in the client engine script of the JWR framework used in the current campaign with that of the Outsider PhaaS platform and additionally, we observed that in June 2026, the FBI had announced the technical takedown operation against Outsider platform (PhaaS) that has been in operation since 2023, through a joint operation “Ghost Hook.” However, the Outsider PhaaS was sold as a self-servicing product in the actor’s Telegram channels, according to the external researcher report, indicating the likely existence of variants of the Outsider PhaaS kit employed and operated by other Chinese-speaking threat actors.  

Comparing JWR with other Chinese PhaaS platforms 

Following the discovery of several similarities in the client-side scripts of the JWR and The Outsider kit, Talos conducted a comparative assessment of the JWR client script against other phishing kits operating within the Chinese-speaking criminal ecosystem. 

Talos found that JWR shares no code-level implementation with Lucid, Darcula, or Lighthouse. Its C2 communication protocol, encryption module, and message envelope are all independently engineered. At the behavioral level, JWR aligns closely with those kits. All four share the operational signature that defines this PhaaS lineage including live operator puppeteering, card capture paired with OTP/2FA interception, and multi-brand templating at scale. Several additional characteristics place JWR within the same family, highlighting a tradecraft consistency across the developers of the phishing kits embedded in the Chinese-speaking criminal ecosystem. 

Coverage 

The following ClamAV signature detects and blocks this threat:  

• Js.Phishing.JwrFramework-10060456-0 

The following Snort2 and Snort3 (SIDs) rules detect and block this threat: 

• 66924
• 66925
• 66926
• 66927
• 66928  

IOCs  

The IOCs for this threat are also available at our GitHub repository here. 

• Cisco Talos is disclosing UAT-11795, a sophisticated, Russian-speaking, financially motivated adversary that has been conducting a malicious campaign targeting users in the U.S. and Europe since at least June 2025.  
• Talos has discovered that the actor in this campaign delivers a Python-based remote access tool (RAT) that we track as “Starland RAT” and a command-and-control (C2) memory implant known as the “WLDR agent.” 
• The WLDR agent is a sophisticated PowerShell-based C2 memory implant that features encrypted beaconing, task queuing, and a Runspace execution engine for executing additional payloads.  
• UAT-11795 also has CastleStealer and Remcos RAT as alternative payload implants in their arsenal. 
• The actor targets victims' credentials and cryptocurrency wallet assets, establishing a persistent connection to the victims' machines from the C2 server, with the potential to deliver and execute further payloads. 

Victimology 

According to the telemetry data, the infection is predominantly observed in the United States. There are also fewer potential impacts observed in Germany, Romania, and Venezuela, based on the assessment of the passive DNS resolution data of the C2 domains associated with this campaign. 

Talos has observed that the threat actor in this campaign has utilized trojanized installer lures from software categories including: 

Trojanized installer	Software name	Software category
MobaXterm_v26.1.exe	MobaXterm	SSH, remote desktop, and network administration terminal
WebEx_Client.exe and Zoom installer	Cisco WebEx and Zoom	enterprise video conferencing and collaboration platforms
dbeaver-ce-windows-x86_64.exe	DBeaverCommunity Edition	open-source database management and SQL client
FaceitInstaller_x64.exe	FACEIT	online gaming platform

The breadth of trojanized software across developer tooling, IT administration utilities, enterprise collaboration platforms, and a consumer gaming application suggests the actor is operating an opportunistic, volume-driven distribution model targeting multiple victim profiles simultaneously, rather than a single vertical. 

Threat actor infrastructure 

The threat actor in this campaign operates a distributed infrastructure across two functional categories, payload staging and persistent C2, with domain naming conventions chosen to blend into legitimate traffic categories. The staging domains, including “eorthopaedics[.]com” (likely a hijacked domain), “web-devtools[.]com” (resembles a developer tooling portal), and “zynaris[.]io” (resembles a technology start-up), with each domain serving a narrow functional role:  

• “eorthopaedics[.]com” and “sastoro[.]com” hosts the PowerShell stage chain under “/feed/” and “/alpha/” paths indicating that the actor has added the malicious routing alongside the legitimate contents. 
• “web-devtools[.]com” serves raw shellcode payloads under the paths (“/starlandfox”, “/x32remka”, “/dopfile”) and a compressed archive. 
• “zynaris[.]io” hosts the potential ClickFix-delivered HTML application (HTA) stager and trojanised installer lures. 

The C2 infrastructure is similarly distributed, with “eorthopaedics[.]com” and “sastoro[.]com” both serving hardware-bound unique identifier (HWID) encrypted envelopes over HWID parameterized URL paths with “eorthopaedics[.]com” under “/feed/” and “sastoro[.]com” under “/alpha/”. This suggests that the two domains represent parallel C2 infrastructure used for the same campaign. 

The domains “windowscreenrepairnearme[.]com” (which is also likely to be a hijacked domain) and “aipythondevs[.]com” serve as the primary C2 for the Starland Python RAT. All C2 URLs incorporate a victim hardware identifier derived from the C: drive volume serial number of the victim machine as the final URL path component, enabling the distinct C2 communication for each of the compromised victims. The actor in this campaign has also implemented C2 infrastructure resilience by using a Polygon smart contract (“0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba”), which stores an XOR-encrypted fallback C2 domain that is retrievable via a public JSON-RPC call.  

Talos discovered that the actor controls two Telegram bots, “8384531459” (“skuefq_bot”) and “7993597060” (“komandastuk_bot”), used for receiving the implant’s execution notification beacons, including messages with victim’s machine fingerprints and cryptocurrency wallet inventories. 

Talos’ research uncovered a private live Telegram channel called “stuk komanda”, controlled by the same threat actor. The stuk komanda channel was created on June 5, 2025, and has three unknown subscribers. It does not contain any chat groups and appears to be structured like a C2. The channel lists messages in the name of file names that appear to be Windows-based binaries, highlighting that the threat actor has been active since at least June 2025. 

Multi-stage attack summary 

The threat actor executed a multistage campaign that involves deploying a weaponized HTA downloader via Microsoft HTML Application Host (“mshta.exe”) on the victim's machine, likely utilizing a ClickFix technique. The execution of the HTA file results in the downloading and execution of trojanized installers bundled with a malicious Python package, which sends the implant status of the installer to an attacker-controlled Telegram bot. The NSIS script associated with the trojanized installer is designed to execute the malicious byte-compiled Python code encapsulated within the installer file. 

This initial byte-compiled Python code acts as a loader that decodes and executes an embedded Python RAT, which we are calling Starland RAT, in the victim's machine memory. Starland RAT offers a wide range of functionalities and has been specifically engineered to operate within the Windows environment. Its capabilities include defense evasion techniques, system reconnaissance, stealing browser data and cryptocurrency wallets, and a fallback C2 connection mechanism that includes a hardcoded C2 URL, as well as a Polygon Ethereum smart contract that serves as a backup. This connection allows it to interact with the smart contract through Eth_call, dynamically resolving the C2 domains. The RAT sends the reconnaissance information to the C2 to register the victim's machine and is proficient in receiving and executing intermediate payloads in several formats, including shellcode for 64-bit and 32-bit Windows environments, directly executing Windows shell commands, and downloading and executing malicious EXE, MSI, and DLL files. 

Talos has observed that the threat actor has distinct infection chains for each type of intermediate payload that Starland RAT receives from the C2. In the case of an x64 shellcode intermediate payload, it implants CastleStealer as the final payload. CastleStealer is a .NET stealer that targets credentials, cryptocurrency wallets, Telegram data, and other browser data from the victim's machine. Similarly, the x32 shellcode implants a variant of the Remcos RAT. 

Furthermore, Talos has observed that the threat actor executed a Windows shell command through Starland RAT as an intermediate payload to download and execute a PowerShell stager. This stager is associated with an undocumented PowerShell C2 framework, which we track as “WLDR C2” in alignment with the internal project designation used by the threat actor in the PowerShell scripts. The PowerShell stager is heavily obfuscated and is designed to decrypt an embedded next-stage PowerShell loader. The second-stage PowerShell loader script has capabilities for defense evasion, connects to the C2, downloads a JSON response, and processes this response to execute another embedded PowerShell payload, the WLDR agent, in the victim's machine memory. The WLDR agent is a bespoke PowerShell script that receives its C2 address through the PowerShell loader injected global variable at the time of execution. The WLDR agent employs capabilities including encrypted HTTP beaconing, comprehensive host reconnaissance, a robust reconnection protocol, and a modular task execution engine to further execute the malicious PowerShell scripts as directed by the threat actor from the WLDR C2 server. 

Initial vector 

The threat actor gains initial access to the victim machine potentially through a ClickFix social engineering technique that entices the user to execute a command, which then stealthily downloads and executes a remotely hosted weaponized HTA file. The HTA file runs an embedded VBScript that drops a Windows batch file into the user profile’s application temporary folder, which contains instructions to first download and implant a trojanized installer from the attacker-controlled staging domain onto the victim machine. 

Once the trojanized installer is executed, the batch file sends a notification beacon to an attacker-controlled Telegram bot, “8384531459”, to confirm successful execution to the threat actor. At the same time, the VBScript establishes persistence under “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” with the generic value “MyApp”, pointing back to “mshta.exe” to execute the remotely hosted weaponized HTA file every time the victim logs in to the machine. Talos identified a Russian-language developer comment left in the VBScript (“Добавление команды в автозапуск для текущего пользователя”), indicating that a Russian-speaking actor is conducting this campaign. 

Python loader packaged into trojanized installers 

Talos has observed that the threat actor in this campaign has weaponized software installers by utilizing the Nullsoft Scriptable Install System (NSIS). They have packaged the Python runtime executable “pythonw.exe” along with a compiled Python loader, which is disguised as a license file named “LICENSE.txt”. The threat actor has modified the NSI script file of the installer to include instructions for executing the compiled Python loader using the Python runtime executable.  

The compiled Python loader is a relatively large file obfuscated with numerous junk functions that perform random arithmetic operations and print randomly generated strings to the standard output. The actual execution logic is confined to six lines in the loader program, implementing XOR decryption using the XOR key 198 (0xC6) to decrypt the encrypted embedded payload of Starland RAT and execute it in the victim machine's memory.

Starland RAT, a Python-based RAT 

Starland is a Python-based remote access tool (RAT) with the capability to steal cryptocurrency. During its initial execution phase, the RAT resolves and declares all required Windows API function signatures through Python’s ctypes interfaces. It directly loads “kernel32.dll” using WinDLL and explicitly defines the argument types and return types for every Win32 call used later in execution, including VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, VirtualProtectEx, CreateProcessA, QueueUserAPC, and ResumeThread. Custom ctypes Structure subclasses are declared for SECURITY_ATTRIBUTES, STARTUPINFO, and PROCESS_INFORMATION, mirroring the definitions in the Windows SDK. This API mapping mechanism ensures that all injection and process manipulation calls later in execution are ready without further need for Windows API imports or dynamic resolution. 

Before any malicious logic executes, the RAT conducts check for anti-analysis environments. First, it compares the logged-on username of the victim machine against a hardcoded list of usernames, which includes known sandbox service accounts and aliases, including WDAGUtilityAccount. Next, the RAT verifies the victim's computer name against a list of hostnames from recognized sandbox environments, such as Cuckoo, Any.Run, Joe Sandbox, and Hybrid Analysis. If either check matches, the RAT's execution terminates immediately. Additionally, the RAT examines the Downloads folder for a Zone.Identifier alternate data stream on the trojanized installer file, confirming that the file was obtained via a browser download rather than being uploaded or copied directly. 

The RAT establishes persistence before any network communication with the C2 takes place. The primary mechanism involves creating a scheduled task using the PowerShell New-ScheduledTask command, with a randomized name following the pattern PythonLauncher-{3 random characters}. When executed with administrator privileges, the trigger is set to AtLogOn with RunLevel Highest, ensuring the elevated re-execution of the RAT at every user logon. Additionally, a secondary Startup folder LNK shortcut is created via the WScript.Shell COM object, placed in the user's Startup directory, targeting “pythonw.exe” with LICENSE.txt as its argument. If the RAT is not already running with elevated privileges, it also attempts UAC elevation via ShellExecuteW with the runasverb, aiming to upgrade the scheduled task to the higher-privilege logon before proceeding. 

It performs system reconnaissance, assembling the victim profile that includes the system hardware-bound unique identifier (HWID), total RAM size of the victim machine, and installed antivirus by executing the following commands: 

Get-CimInstance -Class Win32_ComputerSystemProduct.UUID  
wmic memorychip get Capacity   
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct

The RAT also conducts Active Directory reconnaissance via the PowerShell command Get-WmiObject Win32_ComputerSystem.Domain. If the victim is identified as a member of Active Directory, the RAT executes the following commands to collect information about domain structure, domain controllers, and the victim’s domain privileges: 

whoami && systeminfo && net user {USERNAME} /dom && nltest /dclist

For workgroup-only hosts, it executes the whoami /all command. The reconnaissance data collected are staged by the RAT for inclusion during the victim machine registration to the primary C2 domain hardcoded in the RAT program. It also captures a screenshot of the victim machine's desktop, saves it as a PNG in the RAT’s working directory, generates a Base64-encoded string for the PNG file in memory, stages it alongside the reconnaissance data, and deletes the PNG file from the disk. 

Additionally, it gathers the victim’s cryptocurrency assets information by enumerating the desktop cryptocurrency wallets and browser extension wallets, checking for the presence of over 40 cryptocurrency wallets. The collected data is also staged alongside the reconnaissance data and the Base64-encoded screenshot (PNG) data. The RAT consolidates all collected data into a single JSON file, XOR encrypts it with the 5-byte key “helo1”, Base64-encodes it, and sends it to the primary C2 through an HTTP POST request using the HTTP user-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36.  

If the primary C2 registration fails, the RAT enables a blockchain-anchored fallback mechanism. An eth_call is triggered via JSON-RPC to the public Polygon RPC endpoint “polygon-rpc[.]com”, targeting the smart contract “0x6ae382ed2154cc84c6672e4e908cd2c69c1b35ba” and function selector “0xc659f3b8” for the latest block. The encrypted hexadecimal string that the RAT receives from the smart contract is XOR-decrypted with the key “$m7*rYpry3” to recover a fallback domain to which the RAT sends the victim machine registration request along with the reconnaissance and screenshot data. 

Before transmitting the reconnaissance information to the C2 for the victim's machine registration, the RAT sends a notification message to the attacker-controlled Telegram bot using hardcoded credentials. The message includes the victim's public IP address sourced from “api64.ipify[.]org”, the build name, region locale, computer name presented as a “Crew ID” field, OS platform and release, processor string, and the hardcoded label  
"Windows Defender” as the protection application indicator. If any Chrome cryptocurrency wallet extensions or desktop cold wallet applications were detected during the reconnaissance phase, they were also appended to the message of the Telegram bot, providing the threat actor with visibility into the victim profile and cryptocurrency assets before the actual registration of the victim machine to the C2. 

After the RAT registers the compromised machine with the C2, it sends a GET request to the C2 server every 50 – 60 seconds. It contains minimal JSON content with two randomly named junk fields and the bot's unique identifier, encoded using the same XOR key “helo1” and then Base64 encoded. The C2 server responds with one of the four commands supported by the RAT: 

Commands	Action
shellexecute	Runs an arbitrary shell string via “cmd /c” or PowerShell and returns the output to the C2 server through HTTP POST request.
x32	Receives a 32-bit shellcode URL and executes the shellcode that is staged using the asynchronous procedure call (APC), process injection technique.
x64	Receives a 64-bit shellcode URL and executes the shellcode that is staged using the asynchronous procedure call (APC), process injection technique.
download	Downloads the payload file to the “%TEMP%” folder and executes it by file extension, supporting EXE, MSI, DLL, and ZIP formats with appropriate execution methods.
HTTP 403 response	Triggers the self-deletion of the RAT file and exits its process, functioning as a kill switch.

Windows shell command deploys bespoke WLDR agent C2 implant 

In the current campaign investigation, Talos discovered that the threat actor executed a curl command to download and execute additional PowerShell script payloads of the WLDR C2 framework from another C2.  

WLDR stager 

The WLDR stager PowerShell script represents the initial stage, where it establishes a loop counter and two boolean flags for execution states. Each state creates a runtime alias for PowerShell command execution, resolving .NET Base64 and byte conversion types through an obfuscated string construction mechanism. It also defines an inline decryption routine that XOR decrypts the next stage, which is the embedded encrypted WLDR downloader PowerShell script, using a dynamically computed XOR key. 

WLDR downloader  

WLDR downloader is a compact HWID-bound loader script. Upon execution, it derives a hardware identifier from the victim’s C: drive volume serial number, converts it from hexadecimal to a decimal number, and appends it to two hardcoded C2 URLs for victim-specific payload delivery and a persistent agent task channel. It then issues an HTTP GET request to the C2, and the C2 server only responds to requests whose HWID matches a pre-registered value. The C2 server response is an encrypted JSON envelope containing fields with a Base64-encoded salt, initialization vector, encrypted data, and authentication tag. 

The WLDR loader processes the JSON response by decrypting the envelope through an inline decryption routine using a derived 64-byte key from a hardcoded plaintext password “odg5t8mvssvh” and the salt received from the C2 server in the JSON response. This is followed by the decryption of the encrypted data, which is the next stage of the WLDR agent PowerShell C2 memory implant. Before executing the WLDR agent, it writes the C2 URL and the plaintext password into the global PowerShell scope, making both available for the WLDR agent as its C2 address and session encryption key for all subsequent communication with the C2. 

Bespoke WLDR C2 agent implant 

The WLDR agent is a fully featured PowerShell remote access client that operates entirely in memory. It implements encrypted C2 communications, concurrent task execution through a managed Runspace engine, and a module delivery framework that provides the threat actor with interactive remote PowerShell execution capabilities on the victim's machine. 

Upon execution, the agent initializes the server's URL to a development placeholder and immediately checks for a globally scoped URL and session encryption password that were set by the WLDR loader script. If found, it overwrites the placeholder with the C2 URL and inherits the session encryption password, while also configuring other operational parameters, including polling interval, HTTP timeout, retry counts for the C2 reconnect cycle, and the number of threads for the Runspace pool. 

Before initiating the C2 connectivity, it implements a mutex “f2j398fj239d8j23dkkskskkkkkkkkk” to prevent duplicate instances and performs a dependency check on the inherited session encryption password. If the password is not found, the agent exits its execution. The network communication is encrypted using AES-256-CBC with HMAC-SHA256 in an encryption, then Message Authentication Code (MAC) construction, with session keys derived through PBKDF2-SHA256 over a randomly generated salt at 5,000 iterations. The protocol version tag WSv1 is bound to every MAC computation, with a new random initialization vector (IV) generated for each message. 

The agent performs reconnaissance via WMI queries, gathering information on antivirus products, network adapter configurations, OS version and build, domain membership, CPU, RAM, administrative privilege status, and UAC policy. A hardware identifier is primarily derived from the C: drive volume serial number; if that fails, it queries the machine's registry for the GUID or generates a checksum of the host name, which is appended to all C2 URLs. The initial connection to the C2 is established through an HTTP POST that includes the victim machine profile, the infection identifier, protocol version 2.0.0, and the cryptographic session parameters, with a connection retry timing set to 30 seconds. All subsequent traffic is sent to C2 over HTTPS, with headers designed to mimic a Chrome browser session in version 124. 

After establishing the initial connection with the C2, the agent polls the C2 server every 10 seconds. The response from the C2 server can include either commands or tasks, with the only hardcoded command in the agent being a kill instruction that triggers instance termination, while tasks are queued for execution. 

During our research, we observed that the initial response from the C2 was the idle polling interval response, which included empty fields in both the “commands” and “tasks” arrays. 

Further analysis of the agent program disclosed that the C2 responses to the polling will contain encrypted PowerShell commands or scripts, which are decrypted using the same hardcoded password and executed through one of the two runtime engines defined in the backdoor program.  

The primary agent execution engine is a PowerShell RunspacePool supporting up to 10 concurrent threads. Each PowerShell script payload delivered by the C2 is wrapped with details of execution context and parameters as in scope variables along with event handlers on the script’s execution result of output, error,and warnings. These event handlers registered on the output, error, and warning streams are triggered synchronously as the script execution output is produced, packaging results into stream messages and forwards them to the C2 in real time without waiting for the script execution completion.  

This message streaming capability makes the WLDR agent’s Runspace engine favorable for the interactive operations such as continuous monitoring where the command output reaches the threat actor incrementally, rather than after the completion of the script execution.  

If the Runspace engine fails to initialize the payload, PowerShell script execution defaults to standard PowerShell background jobs. It injects parameters and launches the script as a background job; however, unlike the Runspace path, it collects output only after the job completes, making it suitable only for short-lived batch tasks. 

Other payloads of Starland RAT campaign 

Talos has discovered that the threat actor possesses additional malware, including CastleStealer and Remcos RAT, which can be deployed as payloads to the victim's machine via the Starland RAT. To deliver these payloads, the threat actor utilizes a custom shellcode loader for both x64 and x32 machines, encapsulating the embedded encrypted binaries of the payloads. 

The shellcode loader resolves all required Windows APIs entirely at runtime by enumerating the list of loaded modules in the OS memory, iterating through each module's export directory, and comparing a hash of each function name against stored target values. The shellcode neutralizes both the Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW) through two sequential bypass mechanisms. The primary technique resolves the target functions AmsiScanBuffer in “amsi.dll” and EtwEventWrite in “ntdll.dll” using runtime hash-based API resolution, then overwrites their first bytes in memory with a patch that forces AMSI to always return a clean scan result and the ETW write function to return immediately without writing the output, effectively neutralizing both interfaces. If the primary patching technique fails, the shellcode executes a fallback mechanism where it calls VirtualProtect to temporarily change the target function's memory page protection value to read-write-execute and writes the same patch bytes directly, then restores the original page protection. 

Then, it decrypts the embedded encrypted payload blob and decompresses the decrypted data using LZX decompression into a newly allocated memory region. The payload is subsequently dispatched either by the reflective PE injection technique or by .NET CLR loading through the ICorRuntimeHost COM interface for .NET binaries, or through the PowerShell Runspace for PowerShell scripts. 

Talos discovered that the threat actor can deliver CastleStealer implant through the x64 shellcode and the Remcos RAT through the x32 shellcode variant.  

CastleStealer is a .NET-based infostealer and credential harvesting implant designed to systematically extract sensitive data from compromised Windows hosts. It incorporates several anti-analysis measures, including a Russian locale exclusion check and a hardcoded build expiry timestamp, ensuring it executes only against genuine targets within a defined operational window. Its credential theft surface is broad, targeting the full Chromium browser family and Firefox through direct SQLite database access, with decryption support for both legacy DPAPI-protected credentials and the AES-GCM application bound encryption scheme. Beyond browser data, it enumerates crypto wallet browser extensions, Discord and Telegram session files, Steam account credentials, and targeted filesystem paths, transmitting all collected material over a TCP socket to the attacker-controlled infrastructure. CastleStealer’s secondary payload delivery capability allows the actor to implant further payloads through process injection technique or PowerShell script execution.  

Remcos RAT (Remote Control and Surveillance) is a commercial remote access tool originally sold as a legitimate remote administration tool. However, it has been extensively abused by a wide range of threat actors since its emergence in 2016. It provides operators with comprehensive post-exploitation capabilitiesincluding real-time keylogging, screen and webcam capture, audio recording, file management, shell command execution, and clipboard monitoring all communicated over an encrypted channel to a configurable C2 server.  

Coverage 

The following ClamAV signature detects and blocks this threat: 

Txt.Downloader.Agent-10060312-0
Html.Downloader.Agent-10060313-0
Html.Downloader.Agent-10060314-0
Py.Loader.Agent-10060315-0
Py.Loader.Agent-10060316-0
Ps1.Trojan.Agent-10060317-0
Ps1.Trojan.Agent-10060318-0
Ps1.Trojan.WLDRAgent-10060319-0
Ps1.Downloader.Agent-10060320-0
Win.Trojan.CastleStealer-10060341-0
Win.Trojan.Starland_Installer-10060342-0
Win.Malware.Starland-10060343-0
Win.Malware.Remka-10060344-0

The following Snort Rules Snort 2 and Snort 3 (SIDs) to detect and block this threat: 66787 – 66790 and 301580  

IOCs

The IOCs for this threat are also available at our GitHub repository here.