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.
A China state-backed threat group is using ARTEX, the automated agentic AI penetration testing framework, to achieve remarkable speed, scale and success in a campaign that already compromised about 140 sensitive targets in 11 days, according to CrowdStrike.
The threat group, which CrowdStrike tracks as Vapor Panda, targeted more than 200 organizations in at least 14 countries since Oct. 17, the security company said in a threat report Thursday. Targets and confirmed victims include foreign ministries, a European country’s presidency and prime minister’s office, defense and intelligence agencies; 19 U.S.-based organizations in the pharmaceutical, semiconductor, defense, nuclear and financial sectors; and telecom providers in the United States, Belgium and the Philippines.
CrowdStrike told CyberScoop about 70% of Vapor Panda’s targets were confirmed compromised or had evidence indicating moderate confidence of a successful intrusion.
Vapor Panda’s use of ARTEX, paired with DeepSeek, allowed it to accomplish more tasks with shocking speed — requests occurring as often as every 10 seconds — and pursue multiple attack paths concurrently.
“This is the first time that we’re seeing an agentic adversary nation-state threat actor at this scale, and I think that this is probably, unfortunately, something we’ll see more of,” Adam Meyers, senior vice president of counter adversary operations at CrowdStrike, told CyberScoop.
Hands-on-keyboard activity tracked by CrowdStrike for the past 15 years typically involved up to 40 commands per hour. “Now, with ARTEX, we could see it exceed 1,500 commands an hour,” Meyers said.
“If you diversify that across 200 targets, it costs them very little to run a mass-exploitation campaign and drop a websell,” he added. “They can hit more targets in a faster period of time.”
Vapor Panda’s broad-access campaign, which remains active, has targeted think tanks and government agencies spanning defense, justice, finance and diplomacy.
“I would characterize it as a diverse operational mission that tends to focus on sectors and geographies that Beijing considers economically or politically important,” Meyers said.
Adversarial use of AI is relatively new, yet also quickly becoming the new normal, Meyers said. “We’re scrambling because we’re seeing so many of these agentic adversaries.”
Agentic AI use for malicious purposes is growing month-over-month at a rate of almost threefold. CrowdStrike observed roughly 45 agentic adversary attacks in September and it’s already at 126 for October, and climbing.
Adversarial use of agentic AI isn’t an intractable problem, but rather another reminder that organizations need visibility into their endpoints, identities and cross-domain capabilities, Meyers said.
These attacks aren’t showcasing anything new, “it’s just doing it at a speed and scale that we’re unaccustomed to,” he said. “It’s not hopeless, but you’ve got to take action. You can’t put your head in the sand.”
One Civic owner purchased a cheap aftermarket head unit off Amazon, and decided to have Claude work its magic on it, like it would a smart TV. What was reportedly discovered isn’t surprising, but is worth knowing about.
Among the pre-installed bloatware—or spyware, if you’re being less charitable—was a voice assistant equipped with WebView, an Android system component that lets apps display content off the web. This apparently always used about a third of processing power, even while idle, which isn’t great. There were also Baidu location services, a call recorder (!), a DAB radio client that is pretty much useless in the U.S., and Adobe Acrobat, presumably so your passenger can entertain themselves with PDFs on the go.
It’s interesting because it exposes all the insecurities in this piece of IoT software. But I think the real story is that a random person was able to do this reverse-engineering with the help of AI. Expect a lot more stories like this in the future.
A tampered build of Anthropic’s Claude Code extension for VS Code-compatible editors planted an SSH backdoor on developers’ machines, researchers at macOS security firm Phorion have found. The company spotted the malicious package, version 2.1.313, on Open VSX, an open-source marketplace for VS Code extensions run by the Eclipse Foundation. VS Code’s default extension store is Microsoft’s Visual Studio Marketplace, where no malicious version has been reported. Its terms of use limit it to Microsoft’s … More →
Irregular evaluated Zhipu AI’s open-weight model GLM-5.3 across 13 offensive cyber scenarios using CyScenarioBench, the company’s framework for measuring an LLM’s ability to plan and execute multistage attacks under realistic constraints. The model refused none of the tasks and completed three scenarios at least once each, carrying attacks through dependent stages to reach objectives in simulated networks. Irregular said this was the strongest result it had recorded for an open-weight model. Offensive cyber capabilities Researchers … More →
Gartner recently released a new category of assessing security tools: the Integrated Security Operations Center (ISOC). Even though SIEM isn’t going anywhere, a rapidly evolving threat landscape is forcing a shift in industry logic that is reflected in the emergence of this new category. For years, SIEM has dominated as an all-encompassing category. But SIEMs are no longer sufficient to collect data, support investigations, and manage incidents; instead, the SIEM has separated into distinct architectural … More →
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.
This week, Axios reported that major US banks were detecting third-party AI agents operating inside customer accounts. In many cases, customers have given the agents their usernames and passwords so they could act on their behalf. This kind of access can violate a bank’s rules.
“Are you protecting me, or are you protecting your own profits?”
Bianco described traditional finance’s business model as “based on laziness.” Customers may leave idle cash in low- or no-interest bank accounts rather than move it into a money market fund. An AI agent could make that move for them. “Now that you’re able to do it, the banks are afraid they’re gonna lose that revenue stream,” he said.
The banks offer a different explanation. JPMorgan Chase CEO Jamie Dimon said the bank wouldn’t allow just any outside agent into its systems because doing so was “too risky for clients and for JPMorgan.”
Both explanations can be true: banks can want to retain deposits while also facing real security problems when software acts through customers’ accounts.
Handing over your banking login introduces another service into the security chain. A vulnerability in that service could expose your credentials or allow your account to be misused. And as Bank of America reportedly pointed out:
“If you do share your credentials, keep in mind that you’re responsible for activity resulting from that access.”
That’s the bank’s stated position, not a universal ruling on consumers’ legal rights. Still, it’s a warning worth taking seriously.
Pros and cons
An AI agent with permission to make purchases might find and buy an item at a lower price. But giving an agent access to your bank account also means sharing sensitive banking information with a third party. We’ve seen shared AI chats become searchable online too.
Axios reported that many banks allow, or are moving toward allowing, read-only access. This can let a tool analyze transactions without giving it permission to move money.
That’s an important boundary, but it doesn’t make the information harmless. An agent that can read bank statements may still disclose them if it’s compromised or manipulated. Preventing transactions and protecting confidentiality are separate security goals.
How to keep control of your money
For consumers, the practical question is not whether banks have perfectly selfless motives. It’s what access you’re giving away, and what could happen if the agent makes a mistake.
Don’t paste banking passwords or security codes into a general-purpose AI assistant. Major banks have explicitly warned customers against sharing their credentials.
Use your bank’s approved connection methods rather than giving an agent your login. Where supported, choose read-only access if all you need is analysis or budgeting help.
Give agents access to as little sensitive information as possible. An assistant comparing publicly advertised savings rates doesn’t need your bank statements. OpenAI recommends limiting agents to the data and credentials they need for the task.
Review consequential actions yourself. If an agent asks for confirmation, check exactly what it intends to do and what information it will share. Don’t treat a confirmation prompt as a formality.
AI can make it easier to compare financial products and spot opportunities you might otherwise miss. But an assistant that finds a better rate and an agent that can act inside your account are different propositions.
Let it help with the homework, but be cautious about handing it the keys.
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
On October 27, Google issued a new Stable channel update for Chrome.
Most users are on Chrome’s Stable channel. The desktop update brings Chrome to versions 156.0.8078.73/.74 for Windows and Mac and 156.0.8078.73 for Linux. The update includes 52 security fixes, including four rated Critical.
On the same day, Mozilla issued Security Advisory 2026-118, which fixes 167 vulnerabilities. Firefox 159 also introduces several new features.
Both updates will roll out over the coming days and weeks.
How to update Chrome
The easiest option is to allow Chrome to update automatically. But you can end up lagging behind on updates if you never close your browser or if something goes wrong, such as an extension preventing the update.
If you don’t want to wait for the rollout to reach you, manually updating is easy. Open About Google Chrome from Chrome’s settings or Help menu. Chrome will check for updates. If one is available, click Relaunch to apply it.
To update Firefox, open the browser and click the menu button at the right side of the Firefox toolbar, then go to Help and select About Firefox. The About Mozilla Firefox window will open.
Firefox will automatically check for updates. If one is available, it will be downloaded. Once done, you’ll be prompted to click Relaunch. After Firefox restarts, it will be up to date.
After the update, the version should be 159.0 or later
Technical details
These Chrome and Firefox updates address a familiar problem: browser code mishandling memory while processing web content. Both releases fix use-after-free vulnerabilities, including flaws in page layout, JavaScript processing, and SVG graphics.
A use-after-free vulnerability occurs when a program attempts to access a memory location after it has been freed. That can cause crashes or, in some cases, allow an attacker to run their own code.
There’s another connection between these updates: both Google and Mozilla credit OpenAI Codex Security with finding bugs fixed in these releases. AI can help security teams examine browser code for weaknesses, alongside human code reviews and automated tests that check how software handles unexpected inputs.
Mozilla’s collaboration with Anthropic shows how AI-discovered findings can lead to fixes: researchers validated vulnerabilities before reporting them, giving Mozilla’s team reproducible bugs to investigate, repair, and deliver to users.
Browse like no one’s watching.
Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal. Try it free →
