Cisco Talos: NIK C2 implant calls OpenAI from the victim's PC and can spend the victim's own API key

One capability in sixteen is AI, and it can run on the victim's own key

Cisco Talos lists sixteen capabilities for the Windows implant of a framework it calls NIK C2. Fifteen are the familiar kit of a remote access tool: a credential and wallet stealer, a live keylogger, screen and camera capture, hidden desktop control, proxies for moving through the network, persistence, defence evasion and a screen locking ransomware module. One, the command ai_generate, is AI (the count of 1 in 16 is derived from the table in the Talos post, published on 29 October 2026 and read here from 11:18 UTC the same day).

That one capability is the reason for the headline, and its detail is more specific than "AI malware". Talos says the implant lets an operator "route arbitrary prompts to the OpenAI Chat Completions API directly through the infected host". The request leaves from the victim's own internet address. It needs an OpenAI API key, and when the operator sends none, Talos says the implant reads the victim's OPENAI_API_KEY environment variable and uses that. In Talos's words, "that account's API key will be used to fund the actor's AI inference", and "OpenAI's billing system will charge the victim's payment method". The environment variable is where OpenAI's own production guide tells developers to keep the key.

What that record does not establish matters as much. Talos prints no victim, no sector, no country and no count. It prints no real prompt sent through the implant and no reply, and it does not print the 68 byte instruction the implant gives the model. It does not say that any victim has been billed, that stolen keystrokes or passwords were ever pasted into a prompt, or that OpenAI has been told or has acted. It does not say who wrote NIK C2, whether it is sold, or how it reaches a PC. The billing and logging consequences are Talos's reading of the code, not a case it reports.

What Talos found: a Go implant, a panel, three versions in six days and one live server

Talos describes the implant as a "Go-based, 64-bit Windows remote access tool" with two command channels: a WebSocket over TLS on port 443 and an HTTP polling loop about every 250 milliseconds, both encrypted with AES-256-GCM under a key derived from a seed hardcoded in the binary. It says the dispatcher "facilitates over 52 commands", run as parallel goroutines. Samples carry a build path naming the project nik_panel, which Talos reads as cross compiled for Windows on a Linux machine. "All binaries observed in the wild were compiled with Go 1.23.4", and the authors zeroed the compile timestamps.

Zoom

"We developed a timeline based on the initial sighting dates of NIK C2 implant variants in OSINT." Its Figure 2 marks five first sighting dates in 2026, from 12 August to 18 August, and groups them into three versions. The OpenAI feature appears only in the third. That puts the whole visible development history inside six days (derived: 12 to 18 August), and Talos published 72 days after the last of those sightings (derived: 18 August to 29 October). Talos reads the pace as the work of "a technically proficient team with prior malware operations experience". That is an assessment, and it names no team.

Zoom

Talos also found the framework running. It says a threat actor hosted NIK C2 on 87.120.196[.]120, resolving total-sitevv[.]lol, behind a TLS certificate whose common name is nik-panel, the same string as in the implant. From that, Talos says it can "assess with moderate confidence that NIK C2 is not merely a proof of concept". Moderate confidence is the analyst's own grade; it is not a count of victims. The indicator file Talos published alongside the post adds a second address, 2.26.51.12, with an update URL on port 4443, which the post's text does not mention.

How the OpenAI call works, step by step

Talos takes the AI handler apart in more detail than anything else in the post. The panel sends three fields: prompt, api_key and model. An empty prompt returns an error with no network call. If api_key is missing, the implant reads OPENAI_API_KEY from the victim's environment. Talos calls this fallback deliberate: "It is a deliberate design with significant operational implications". If no model is named, the implant uses a five character default that Talos decoded as gpt-4; the operator can name any other model without rebuilding the binary.

Zoom

The request is an ordinary Chat Completions call. Its system message is a string "exactly 68 bytes long hardcoded in the binary", which Talos calls the implant's behavioural instruction to the model; Talos does not print it. The user message is the operator's prompt. Talos's Figure 5 shows the body with temperature 0.7 and max_tokens 2048, posted to https://api.openai.com/v1/chat/completions with a 60 second timeout. On a 200 reply the implant pulls out choices, message, content, and returns it to the panel under the key code, with the model name and the token counts so the operator can track consumption.

Zoom

Two consequences follow, and they are Talos's reading of the code, quoted as such. The call leaves from the victim's address, so to a firewall it looks like the victim using OpenAI. If the victim's key is used, "OpenAI's billing system will charge the victim's payment method" and OpenAI's logs show the victim's key, "allowing no trace attributable to the threat actor". A third follows by this site's inference: the operator need not hold an OpenAI account at all, provided the victim has one. Whether the operator's own key, when sent, leads back to the operator is not discussed.

What the AI step is for is the soft part of the post. Talos's conclusion says operators can "dynamically generate context-aware lure material", run local deception, summarise what they have stolen and write targeted payloads on the compromised host. Those are possibilities Talos lists, not uses it shows. The post gives no example of an output and no sign that a model's answer changed what an operator did next. On the record, the AI module is a remote prompt box that runs on someone else's machine and, where it can, someone else's account.

The other fifteen: theft, surveillance and a lock screen that encrypts nothing

Most of the implant is conventional, and most of the defensive work is too. Talos's own category table, shortened here:

The ransomware module is a lock screen, not encryption. Talos says it copies the first disk sector to mbr_backup.bin, builds an HTML page at run time with the operator's Bitcoin and USDT addresses, prices, contact email and timer, shows it through mshta.exe from a batch file that reopens it every five seconds, and adds a Run key named SystemLock. "It does not encrypt any files", Talos notes, which makes it fast to deploy and leaves no trail of modified files. The bootkit step writes a 16 byte placeholder spelling NIK_BOOTKIT_PREP; Talos calls it a staging marker, not a bootkit.

Zoom

One evasion detail changes incident response. Talos says the implant marks itself as a critical process, which "causes a Blue Screen of Death if any attempt is made to terminate the process through Task Manager or taskkill actions". Killing it by hand crashes the machine. Isolating the host on the network first, then imaging it, is the safer order (this site's inference from Talos's description).

Not the first malware to call OpenAI, and the difference matters

In November 2025 Microsoft's incident response team described SesameOp, a backdoor that "uses the OpenAI Assistants API as a storage or relay mechanism to fetch commands". It used the API as a mailbox for commands and results, not for model output, and it used the actor's own key. Microsoft said "This threat does not represent a vulnerability or misconfiguration", and that OpenAI, after a joint investigation, "identified and disabled an API key and associated account believed to have been used by the actor". This site has also covered malware that tries to talk its way past AI analysis tools, a different trick again. These are separate families from separate vendors; nothing links them to NIK C2.

The difference is about whose account carries the abuse. When the actor's key is used, the provider can find and cut one account, as happened with SesameOp. When the victim's key is used, the account belongs to an innocent customer, the traffic comes from that customer's address, and cutting it punishes the victim. Talos does not say whether OpenAI has been told about NIK C2. OpenAI's developer pages describe warning and deactivation notices sent to an organisation, with event names such as safety.deactivation_issued; whether a victim whose key NIK C2 used would receive one is not stated anywhere this site read.

Stated and not stated: the record, line by line

Labels doing the work of a control

"AI enabled". The label sells the story, and Talos uses it in its title. On the record it describes one command out of sixteen capabilities, with no output shown. A defender who files NIK C2 under AI threats and waits for an AI specific control will miss the fifteen capabilities that steal, watch and lock, which is the ground ordinary endpoint detection is designed to cover.

svchost.exe, simvol.exe, csrss.exe. Talos says the implant takes these names, and copies itself into a folder called Microsoft\Network under the roaming profile. A familiar process name is not evidence of a system process. The test is the path and the parent, not the name.

GoDiscorder. The one detection Talos names is the ClamAV signature Win.Trojan.GoDiscorder-10060526-0. A search of antivirus logs for "NIK" would find nothing; the detection name points at Discord theft, not at the framework.

"Environment variable". OpenAI's production guide says "You should expose your keys to your application using environment variables or secret management service". That keeps keys out of source code, which is its purpose. It is not a control against malware running as the same user, which can read the variable as easily as the developer's own scripts. The same guide offers the controls that do limit the damage: "We strongly recommend setting an expiration date when you create a project API key", and "Set spend alerts on the limits page".

Who is speaking, and their interest

Cisco Talos is Cisco's threat intelligence group, and the post ends by pointing readers to Cisco's security products that carry its coverage. OpenAI sells access to the API that NIK C2 calls; its production guide says "OpenAI offers a pay-as-you-go pricing model", so every call made on a victim's key is billed to someone. Microsoft, the source for the SesameOp comparison, sells the Defender products whose detections and query it published. None of that makes the technical findings wrong; it is why each claim here is attributed. OpenAI's usage policies page and its help article on key safety answered this site's requests with HTTP 403 and were not read.

Technical details

The artifacts below are copied from the Cisco Talos post and its indicator file, both of 29 October 2026, and from Microsoft's post of 3 November 2025, all read on 29 October 2026. Live infrastructure is defanged by this site ([.] and hxxps). Talos also prints the decoded AES seed and key the implant uses for its C2 traffic; they are left out here because they are keys, and defenders who need them to decrypt captured traffic can take them from the Talos post itself. No exploit or proof of concept code is reproduced.

File hashes. The eight SHA256 values Talos lists as NIK C2 implants. Search endpoint and mail telemetry and block them.

ae38f1181c9dd0db7224d6023e335eb2cdabb0f441906d14ffba8602b7abca3c
6583eb22ca554e749b647d68ae76f7279a8dc538196ebde1412669357a027de5
30817712277bba54e4cb8640f4005aad35f5172f88cf046aea545d029e12ccba
1fee4cd8d3560e6c60ba50451860adf6e705f26fd3fe1c1ccc058f4e8b13073a
bf83345ca66bdc4bd45ade608a06361d18927dd80351e9a1d8cbe8eda5d78402
99573a79f393299049216237d0d23761d67f6a8507a7a0cfe17cb30837f68f00
5d25efba2119f52d08214a590fedb45a5c9fe5e2850fd87e7bca24c92745e6d1
2a01056369cc691f5bed6bd2654930a81d1bc240a568a0d5b209aceef3b5c9c9

Network indicators. The domain, the two addresses and the C2 paths. The second address and the port 4443 URL appear in the indicator file, not in the post text. The paths are useful in proxy logs even when the server changes.

total-sitevv[.]lol
87.120.196[.]120
2.26.51[.]12
hxxps://2.26.51[.]12:4443/api/c2/update
/api/c2/update
/api/c2/result
/api/c2/screen
/api/c2/file_chunk
/api/c2/rproxy_up
/api/c2/ws

Build path and server certificate. The build path is embedded in the samples; the certificate serial, JARM fingerprint and common name are from the live server. The JARM and certificate are what a scan of internet facing hosts would match.

/opt/nik_panel/data/build_52b79724a1fc4b8f/main.go
serial number 7d16381a9de823943b5a0987dbd0f26edf22052b
jarm:"28d28d28d00000000042d42d0000001f361a1bf80ed39a1e352adeb016a07b"
Common Name (CN) set to nik-panel

The OpenAI request and the result returned to the panel. Transcribed by this site from Talos's Figures 5 and 6, which are images; the JSON braces are omitted and the angle bracket entries are Talos's own placeholders. The token counts in the second block are Talos's example values, not a measured call.

POST https://api.openai.com/v1/chat/completions
"model": "gpt-4",
"temperature": 0.7,
"max_tokens": 2048,
"messages": [
  "role": "system", "content": "<68-byte hardcoded instruction string>"
  "role": "user",   "content": "<actor's prompt text>"
]

"status": "generated",
"code": "<AI model response text>",
"model": "gpt-4",
"usage": "prompt_tokens": 142, "completion_tokens": 318, "total_tokens": 460

Host artifacts. Process names the implant takes, files it writes to the temp folder, the Run key name used by the lock screen, the registry path written for the fodhelper.exe UAC bypass, and the log string it writes at start. Hunt for these by path and parent, not by name alone.

svchost.exe
simvol.exe
csrss.exe
mbr_backup.bin
lock_screen.html
lock_start.bat
bootkit.bin
browserdata.zip
SystemLock
HKCU\Software\Classes\ms-settings\Shell\Open\command
[NIK] Starting

Commands the implant runs. WiFi password collection and system reconnaissance. Command line logging that shows these from an unexpected parent is a useful alert.

netsh wlan show profiles
netsh wlan show profile name="" key=clear
chcp 65001 >nul 2>&1 & systeminfo
chcp 65001 >nul 2>&1 & wmic os get lastbootuptime /value
chcp 65001 >nul 2>&1 & wmic /namespace:\\root\SecurityCenter2 path AntiVirusProduct get displayName 2>nul
chcp 65001 >nul 2>&1 & Get-Process | Select-Object Id, ProcessName | ConvertTo-Json -Compress

File name patterns the stealer searches for. Talos prints two case insensitive regular expressions used to find seed phrases and private keys on disk. Files that match them are what the implant collects into browserdata.zip.

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

Detection Talos names. The only signature in the post.

Win.Trojan.GoDiscorder-10060526-0

A starting query for calls to OpenAI. Microsoft published this Defender XDR hunting query for SesameOp. It counts devices and processes that connect to api.openai.com. Against NIK C2 the question is the same: which processes on which hosts call OpenAI, and should they.

//show number of devices connecting to https://api.openai.com per InitiatingProcessFileName, and number of days in the period where the connection was observed
DeviceNetworkEvents
| where RemoteUrl endswith "api.openai.com"
| summarize Connections = count() by DayOfConnection = bin(TimeGenerated, 1d), DeviceName, InitiatingProcessFileName, RemoteUrl
| summarize TotalConnections = sum(Connections), DaysWithConnections = dcount(DayOfConnection), DistinctDevices = dcount(DeviceName) by InitiatingProcessFileName, RemoteUrl

What to do, in the order worth doing it

The checks are this site's, built from what Talos and the vendors print. The first two need no new tooling.

Zoom

The question that exposes the gap

Talos ends by asking defenders to "embrace continuous behavioral vigilance as the new baseline". The narrower lesson is about one variable. NIK C2's AI feature is only as dangerous as the keys lying on the machines it lands on, and the record does not yet show anyone paying for it. So the question for any organisation that gives staff OpenAI keys is simple: if an implant spent one of those keys tonight, from a laptop on your network, would your monitoring flag the call to api.openai.com, or would the first sign be next month's OpenAI invoice?

Key facts