VOLTA is a mature stealer implant with an optional AI-integration layer. After stealing credentials, sessions, and cryptocurrency wallets, VOLTA sends a structured evidence bundle to an LLM to rank the victim’s assets by monetization value.
If a model refuses to perform the target assessment, VOLTA fails over to a three-model chain, implying a direct engineering effort and expectation of hitting model guardrails.
This stealer is self-deleting, and there is no attacker-owned infrastructure. The novelty in the AI-integration is that it is not supporting a traditional malware capability but working as an intelligence analyst on behalf of the operator.
There is a new idea in the cybercrime world — cast a wide net, steal everything, and let AI sort out the specifics. A new malware self-named “VOLTA-AUTODOXER,” surfaced through the CAIRN research effort, is a self-deleting Windows infostealer that augments its post-theft workflow with an LLM-powered victim-profiling stage.
After harvesting the standard stealer haul, including browser passwords; cookies; payment cards; cryptocurrency wallet seed phrases; Discord, Telegram, Steam, and Roblox sessions; Microsoft OAuth tokens; SSH and cloud-provider keys; Wi-Fi profiles; and screenshots, VOLTA builds a structured evidence bundle about the person behind the machine. This bundle contains geolocation and home address, employer and employer domain, inferred birth year, card last-4 digits, Slack workspaces, document authorship metadata, iPhone backup indicators, and a live Roblox account valuation. It then uses stolen session access to enrich that bundle further: searching the victim’s Gmail for purchase receipts to corroborate a home address, pulling UberEats and DoorDash order history, and enriching Discord accounts via the stolen token.
The bundle is serialized and POSTed to OpenRouter under a system prompt that instructs the model to act as “a forensic intelligence analyst drafting a target assessment.” The required output includes a section titled “WHAT THEY’RE WORTH” with valuables ranked by monetization with a low/medium/high tier, and a section on “THEIR OPSEC” containing an assessment of the victim’s security posture and password hygiene. The model is the operator’s triage analyst; it turns a raw credential log into a prioritized and citation-backed dossier of the victim and their monetizable assets.
Figure 1. The VOLTA-AUTODOXER workflow.
The AI configuration: “Go deep, not wide… Be blunt, specific, accurate.”
VOLTA uses a multi-model architecture to fall back resiliently if it hits a model’s refusal, checking each response for phrases like “I can’t” or “I’m not able,” before passing on to a chain of up to three models.
Endpoint
https[:]//openrouter[.]ai/api/v1/chat/completions
Default model
anthropic/claude-opus-4.6
Fallback chain
moonshotai/kimi-k2 → google/gemini-2.5-flash
Temperature
0.2 — deterministic, consistent output
Request format
Hand-assembled JSON; no SDK; User-Agent Mozilla/5.0
Figure 2. Hardcoded model selection.Figure 3. Failover model selection to kimi-k2, and then gemini-2.5-flash.
Model temperate controls the randomness and predictability of LLM-generated text. The low hardcoded temperature value (0.2) suggests the attacker is emphasizing accuracy and consistency. The malware also employs a chain of cascading models in the event of failures. This multi-model architecture suggests that the operator is anticipating encountering refusals, with the fallback pivoting to a few, smaller, and more permissive models.
The system prompt directly reveals the operator’s use case: Produce a concise analytical assessment of the victim’s suitability as a target, backed by an auditable trail of citations.
Figure 4. VOLTA’s raw system prompt.
The prompt also asks for something out of the ordinary, but that agents excel at: making connections between sparse and disparate data. For example, encouraging connections like the victim’s names, addresses, or universities to patterns in their passwords. In this case, the model isn’t being asked to find data; rather, it’s being asked to stretch the data and make useful inferences that extend the value of what has been scraped.
Stealer capabilities
VOLTA’s capabilities are directly aligned with the records produced in modern digital life, and well beyond basic credential theft. In a single pass, the stealer can extract browser credentials, cookies, and saved payment cards across Chromium-based browsers. It hits Firefox and Thunderbird, Outlook profiles, Slack workspaces, Steam and Battle.net sessions, Discord tokens, Telegram sessions, Roblox accounts, and SSH and cloud-provider config files (gcloud, OpenVPN, Hide.me). VOLTA doesn’t just copy cryptocurrency wallets, but runs an embedded cracker against the vault inline, writing the result to a WALLET VAULTS CRACKED line in its own report.
Every saved Wi-Fi password on the machine is pulled via a direct call to WlanGetProfileList and dumped to plaintext.
Figure 5. VOLTA dumps plaintext passwords for every saved Wi-Fi network on the host.Figure 6. The organized collection targets.
What really sets VOLTA apart from commodity stealers is what comes after the initial collection. There is a live enrichment pass that leverages stolen sessions to deep dive the victim’s data. For example, using the victim’s own authenticated Gmail tokens, it queries their inbox for receipts from Amazon, DoorDash, Uber Eats, Grubhub, Walmart, and PayPal, then review those receipts to establish a confirmed home address. Stolen Uber Eats and DoorDash sessions are called directly for order history. The Discord token is re-used to enrich the victim’s account profile. Roblox inventory is valued via a live “Rolimons[.]com” lookup.
Figure 7. That’s right: Your Uber Eats history is now a potential liability.
After the collection and enrichment stages are complete, the data is assembled and structured locally in a file called “Identity_Report.txt”. This file is serialized into a bundle as JSON and POSTed to OpenRouter along with the system prompt. The returned payload is received as “AI_Analysis.txt”. Both files exfil together in “volta_dox.zip”.
Figure 8. VOLTA’s exfil can happen in three stages: 1) after the stealer runs (“volta_log.zip”), 2) after the AI call (“volta_dox.zip”), (3) if the network enrichment produces anything (“volta_doxnet.zip”).
The inference round-trip happens entirely through the victim’s own network connection, on their own machine, before the result is exfiltrated.
Deployment model
Instead of hardcoding its Telegram channel, API keys, and settings directly into the code (which is likely what someone writing a tool for personal use would do) VOLTA uses a template with six swappable slots, filled in at build time.
This suggests it’s a builder model: The author sells access, the customer provides their values, and the builder compiles a custom binary for each order. The credentials in those slots are encrypted, but not in a meaningful way. The key is SHA-256 of two constants sitting in the same binary, but it’s presumably there because customers expect their API keys not to be sitting in plaintext, not because it provides real protection. Anyone who reverses the file can recover them.
If VOLTA is indeed a commoditized malware, then the AI dossier capability isn’t something the author invented for their own operations. It is a feature which enables a customer of any level of sophistication to point it at victims and start receiving ranked target assessments in their Telegram inbox.
All the observed endpoints for this malware are third-party controlled. There is no actor-owned infrastructure.
Countermeasures
Much of the token-stealing capability of VOLTA relies on techniques to bypass App-Bound Encryption (ABE) in Chrome. An application control policy that restricts which processes may launch Chrome with --headless would block the ABE decryption path entirely. At minimum, you can also alert when Chrome is launched with --headless from any process not in a known developer. Best practices for storing credentials in hardware backed stores also apply.
In the event of compromise, the main executable may have deleted itself, but users should attempt to preserve the “APPDATA%\volta_debug.txt” file. This is a timestamped harvest log and contains a record of exactly what was collected and whether the LLM call succeeded. Revoke any potentially compromised tokens and change passwords. For cryptocurrency wallets, if the seed phrase was in plaintext on disk, treat the wallet as fully compromised and migrate funds to a new wallet with a seed generated on an air-gapped device.
Conclusions
VOLTA is a mature stealer with a late-stage AI layer added for one purpose: relieving the operator of analytical work. The axis of AI improvement here is not speed or scale but effort displacement; the same logic visible in CLOSEDQUORUM, though applied to a different phase. These implants reflect the same underlying logic: Identify the step that requires the most sustained human attention and replace it with a model call. The question for defenders is not whether this pattern will appear elsewhere, but which phase it touches next.
Figure 9. End-to-end VOLTA workflow.
The second trend to watch is the anticipation of hitting model refusals, and the approaches to building in resiliency. In this case, it includes a fallback chain from Claude to Kimi to Gemini and the ability to run without the LLM stage altogether if no key is present. As AI integration in malware matures, refusal resilience may become a standard design requirement.
The open question underlying both trends is whether effort displacement in crimeware changes the landscape in a meaningful way: lowering the operational floor, raising the ceiling on scale, or both. Cybercrime operations have always been opportunistic, and the sophistication bar has always been lower than assumed, but there is a difference between a wide net and a wide net that sorts itself.
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.
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.
Figure 2. NIK C2 implant evolution timeline.
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.
Figure 3. NIK C2 was observed in the wild during the research period.
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.
Figure 4. Snippet of NIK C2 implant AI handler module.
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_tokensand 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 userand 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.
Figure 5. Snippet of NIK C2 implant AI handler module.
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 messageand content. The string value at key contentis 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 modelis set to the resolved model name that was used for the request, confirming which model produced the output. The key usageis 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.
Figure 6. AI model response is encapsulated in JSON message and will be sent to C2.
Dual execution modes of NIK C2 implant
Upon execution, the implant inspects its command-line arguments to determine its execution path. The argumentwatchdog 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 messagereading [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:
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.
Figure 8. Screenlocker HTML code is hardcoded in NIK C2 implant binary.
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.
Figure 9. Desktop lockscreen page of the ransomware deployed by the NIK C2 implant.
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 netshcommands 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 deniedand No WiFi profiles found.
netsh wlan show profiles
netsh wlan show profile name="" key=clear
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 CryptUnprotectDataWindows 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\
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.
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”.
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.
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.
Figure 10. Snippet of NIK C2 IMPLANT’s C2 communication handler function.
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.
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.
Figure 11. Snippet of NIK C2 implant’s C2 communication handler function.
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 NtSetInformationProcesswith the parameter value0x1Dfor ProcessBreakOnTermination that causes a Blue Screen of Death if any attempt is made to terminate the process through Task Manager or taskkill actions.
Figure 12. Snippet of NIK C2 implant’s evasion handler module.
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.
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.
Cisco Talos has identified UAT-11473, a highly sophisticated advanced persistent threat (APT) actor, who exploited CVE-2026-20127, an authentication bypass vulnerability in Cisco SD-WAN Catalyst Controller instances to bypass authentication and gain unauthorized access to affected systems.
UAT-11473 then installed a custom malware framework we track as “KeyDrift” consisting of multiple components geared towards collecting sensitive keying information, acting as backdoors and intermediate command-and-control (C2) hosts.
Observed targeting spans across space and satellite services, defense and aerospace technology, and policy research.
KeyDrift is a custom malware framework that is designed to operate in Cisco SD-WAN controller environments. Talos assesses with high confidence that the framework is designed to provide long-term persistent access and automated exfiltration of sensitive keying material. KeyDrift operates inside SD-WAN control-plane processes and is capable of intercepting decrypted control traffic, extracting control-session metadata and data-plane keying material, and staging or transmitting the collected material using encrypted records.
The framework’s primary component is PolyFlame, a memory-resident module deployed through modified runit service paths. PolyFlame is injected into legitimate running vdaemon processes, and it can also masquerade as a packed “aaamgrd” loader variant. Once resident, PolyFlame interposes socket, DTLS, and runtime-linker behavior through functions such as recvfrom, sendto, getpeername, dlopen, dlsym, mprotect, and “/proc/%d/maps” parsing. This gives KeyDrift access to SD-WAN control-plane traffic from inside legitimate controller daemon execution rather than through a conventional endpoint beacon.
LittleFilch, another component of the KeyDrift framework, provides the collection and exfiltration capability identified in the framework. The module hooks “SSL_read” inside vdaemon, inspects decrypted control-plane buffers, extracts keying material for a list of predefined edge nodes, and stages the data locally in encrypted format for exfiltration.
Talos assesses with high confidence that KeyDrift’s intended operational purpose is Cisco SD-WAN control-plane collection: persistent controller residence, in-band traffic access, key-material extraction from decrypted control messages, and encrypted staging or exfiltration of the recovered material. Observed variations of the KeyDrift modules and deployment mechanisms suggest active development of the framework’s capabilities.
KeyDrift analysis
KeyDrift uses Cisco SD-WAN runit service paths as its primary execution anchor. In the PolyFlame sshd deployment, the actor modifies the service run script, remounts /rootfs.rw executable, launches a malicious script “conf_sshd” in the background, and then starts the legitimate sshd service. The loader script enumerates running vdaemon PIDs, records them in “/tmp/system-vdaemon”, and invokes the injector component “rsshd” to inject PolyFlame (“libdssl.so”) into each process.
Recovered conf_sshd logic uses the same control flow across reviewed samples:
Figure 1. conf_sshd control flow logic.
Runit launchers
The observed sshd runit launcher preserves normal Cisco SD-WAN sshd startup logic while adding two malicious lines before service execution, which remount “/rootfs.rw” executable and background execution of conf_sshd, which then drives rsshd injection into vdaemon.
Figure 2. conf_sshd execution logic.
The recovered aaamgr runit launcher from an affected vBond appliance uses a parallel service-wrapper pattern, but it executes the packed aaamgrd PolyFlame loader directly. The deletion of the writable-overlay PAM configurations for sshd and login before remounting “/rootfs.rw” executable if part of the legitimate script, along with the invocation of the aaamgrd daemon via Python:
Figure 3. aamgrd daemon launch.
PolyFlame
PolyFlame is the primary operational module in the KeyDrift framework. PolyFlame operates at the socket and DTLS control-plane layer. PolyFlame serves two primary purposes:
Command execution via a TinyShell-styled backdoor
Intermediate C2 that can forward commands to and from the C2 to other peers
PolyFlame is primarily injected into the vdaemon process, providing operational obfuscation and access to all in-process state: DTLS session keys, vEdge topology, OMP routes, and policy tables. No hardcoded IPv4 addresses, binding ports, callback domains, URLs, host headers, or polling interval were recovered from the analyzed PolyFlame samples. PolyFlame is designed for in-band control or tasking over Cisco SD-WAN control-plane traffic rather than a conventional fixed external beacon.
This implant is meant to serve as a hook of the recvfrom() API call. The original recvfrom is replaced by a malicious subroutine in the vdaemon process. When recvfrom is called in the vdaemon process, the malicious subroutine will first execute the real/legitimate recvfrom() API to obtain the C2 IP address info for communicating with it in the future.
PolyFlame’s time check
The recvd data from the C2 consists of the MD5 value of a specific DATE. PolyFlame will calculate the local time on the device in format “%Y-%m-%d” and calculate its MD5 hash. If the MD5 calculated by the device does not match with the one sent by the C2, the implant will stop further execution. Otherwise, the implant then uses an “administrative code” from the C2 and performs an action.
PolyFlame’s tasking
PolyFlame contains an administrative mode that processes the admin code sent by the C2, that defines operations — it’s one of the first flags checked in the backdoor:
Code = 1: Generate random bytes and send to C2. This is likely a check-in beacon or heartbeat for the C2.
Code = 2: Set implant type to backdoor (TinyShell) or intermediate C2.
Code = 3: Set up the command handler for the intermediate C2.
Any other code value: Check the implant type flag currently set. Based on the implant type flag, either send the accompanying data to TinyShell or the intermediate C2 component for processing.
PolyFlame’s command execution
PolyFlame contains a backdoor that matches the capabilities of TinyShell: file read, file write, and arbitrary command execution, but not interactive shell. This backdoor component’s implementation is quite similar to TinyShell, but the command codes differ. PolyFlame handles the following command codes:
Code = 0x100: Execute command using “/bin/sh -c <command>”
Code = 0x200: Write file to disk.
Code = 0x300: Read file from disk and send to the C2.
PolyFlame as an intermediate C2 component
The intermediate C2 component is a one-to-many handler (somewhat like a one-to-many multiplexer) — meaning the implant can connect to only one C2 but can connect to many peers who can be served by the intermediate C2 component. Similar to the TinyShell-backdoor component, the intermediate C2 component also accepts and processes specific command codes from the C2:
Code = 0x403: Create a thread to connect to the specified peer IP. Make a new connection and keep socket alive until specified.
Code = 0x404: Send data recvd from the C2 to a connected peer.
Code = 0x405: Remove a peer from the list of active connections.
Code = 0x407: Send a response recvd from a peer, back to the C2.
Code = 0x408: Set a specific value in memory.
PolyFlame variant: aaamgrd
Talos has observed a distinct PolyFlame variant that masquerades as the aaamgr service. The legitimate Cisco aaamgr component is a Python package; it does not normally appear as a compiled ELF runit service. This PolyFlame variant is executed by a malicious runit service under “/etc/sv/aaamgr/” with aaamgrd and a modified run launcher.
aaamgrd is a statically linked ELF64 executable with no section headers, a single RWE loader segment, and an RC4-encrypted embedded ELF payload. The loader uses direct syscalls including ptrace, fork, wait4, kill, tgkill, mmap, and mprotect. It performs an anti-debug check by deobfuscating /proc/%d/status and TracerPid: and exits if a tracer is present.
The observed staging sequence was:
Figure 4. PolyFlame staging sequence.
Note that in addition to the implant execution staging, there are also indications of timestomping.
LittleFilch: libcommon.so TLS interception module
LittleFilch is a control-session interception module positioned to collect data-plane keying material from control sessions visible to the injected vSmart process.
LittleFilch installs an SSL_read hook inside vdaemon. The hook calls the original SSL_read, then processes returned buffers only when the returned size is greater than 0x18F, the first decrypted byte is 0x07, and three marker patterns are checked for presence. These marker bytes are followed by the actual artifacts that LittleFilch aims to record:
Marker bytes
Parsed field
Length
Notes
40 03 06
Public IP
4 bytes
vEdge
public / transport IP
40 0C 04
Peer
system-IP
4 bytes
vEdge OMP
system-IP
05 01 0C
06 40
Binary
key field
32 (0x20)
bytes
Assessed
OMP-distributed AES-256 IPsec data-plane key material
LittleFilch records the extracted keying material and RSA-encrypts it before writing the output to “/var/tmp/vdaemon.bin”. It can then send the encrypted content over UDP in a DTLS 1.2 application-data style record.
Figure 5. Keying material recording format used by LittleFilch.
LittleFilch expects its configuration file — located at “/var/tmp/vdaemon.conf” — to contain two host port lines: one local bind IP/port and one remote destination IP/port. It deletes “/var/tmp/vdaemon.conf” after reading it. Talos has not been able to recover the “vdaemon.conf” file.
Following the identification of UAT-11473 activity, Talos strongly recommends that organizations monitor their systems for indicators of post-compromise activity. Should any signs of unauthorized activity be detected, organizations should immediately activate their incident response frameworks. Contact the Cisco Technical Assistance Center (TAC) for support by initiating a TAC request.
Coverage
Snort SIDs are already available for CVE-2026-20127: 65938, 65958.
Snort SIDs for the malicious artifacts illustrated in this blog:
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.
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.
Figure 1. Regional targeting.
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.
Figure 2. Lure document masquerading as a Russian diplomatic congratulatory letter to the Armenian 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.
Figure 3. Decoy impersonating Turkmennebit and proposing cooperation with Orsk Oil Refinery management.
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.
Figure 4. Campaign timeline.
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.
Figure 5. First observations of four UAT-6275 infection chains, June 2025 – April 2026.
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.
Figure 6. Chain C retrieves a GitHub-hosted PowerShell script; later samples also deploy PickleShell to the Startup folder.
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.
Figure 7. Chain D exploits CVE-2025-8088 to place PickleShell in the Windows Startup folder for execution at the next sign-in.
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.
Figure 8. Timing of 77 GitHub commits in UTC+3 and UTC+5, with 09:00–18:00 local working hours shaded.
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.
