Skip to content
Security & Trust

Windows malware can run its AI requests on a victim's OpenAI key

Cisco Talos says NIK C2 falls back on a key set on the infected machine when the operator supplies none

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
Windows malware can run its AI requests on a victim's OpenAI key
In brief
  • Cisco Talos describes NIK C2, Windows malware that uses the OpenAI key set on an infected machine when the attacker supplies none.
  • In that case, Talos says, OpenAI bills the victim's payment method and its logs show the victim's key, with no trace of the attacker.
  • Teams should check where AI keys are stored on Windows machines, consider spending alerts, and rotate keys after a compromise.

When a key is set, the attacker's AI bill goes to you

Criminals have long borrowed their victims' computers, for example to mine cryptocurrency. Cisco Talos has now described malware that can borrow something else: the victim's account with an AI provider. It happens when the attacker supplies no key and the infected machine has one configured. The attacker gets the answers. The victim may get the invoice.

Talos published its research on October 29. It calls the malware NIK C2 and says it found the tool running in the wild. The implant is written in Go and targets 64-bit Windows. It gives an attacker lasting remote control of the machine.

How the billing fallback works

The implant has a built-in OpenAI client, reached through a command called ai_generate. An operator sends it a prompt. The operator can also send an OpenAI key and a model name. Talos says those two items are optional.

When the operator gives no key, the implant looks up OPENAI_API_KEY on the infected computer. It uses whatever value it finds there. Talos calls this "a deliberate design," not a backup.

The consequence follows from how billing works. Talos says OpenAI would charge the victim's payment method. It also says OpenAI's logs would show the victim's key as the requester. In Talos's words, that leaves no trace attributable to the actor.

The request itself is plain. The implant sends it to OpenAI's chat completions endpoint from the victim's machine. It waits up to 60 seconds for a reply. It returns the text to the attacker's panel, with the token counts for each request.

If no model is named, Talos found the default is gpt-4. The operator can name any valid model. Newer models therefore work without a new build of the malware.

More than an AI add-on

The AI feature sits inside a wider toolkit. Talos says the implant accepts more than 52 commands. They cover credential dumping, browser data, cryptocurrency wallets, Wi-Fi passwords, keylogging, screen and camera capture, and movement to other Windows machines. Its evasion features include process hollowing and a UAC bypass.

It also contains a screen-locking ransom module. Talos says the module encrypts no files. It shows a customised demand for Bitcoin or USDT and reopens the lock screen if the user closes it.

With no files encrypted, Talos says, there are no file-change timestamps for investigators to examine. It adds that locking a screen takes an attacker far less effort than encrypting files.

For communication, Talos says the implant uses a TLS-secured WebSocket on port 443. It also runs an HTTP fallback that polls roughly every 250 milliseconds. Traffic is encrypted with AES-256-GCM.

The idea: an AI key is spending authority

The lesson here is that an AI key is more than a login. It is permission to spend. On a machine where OPENAI_API_KEY is set, this implant can spend that key.

Think of a company card in a stranger's hands. The statement still carries your name. Talos describes a similar effect in OpenAI's logs, which would name the victim's key.

Infosecurity Magazine reports a second effect Talos points to. The malware joins data collection and use of that data in one session. Talos is quoted as saying this erases "offline processing delays that historically granted defenders critical detection windows." Infosecurity says operators can send stolen data for AI analysis inside the compromised session.

What the evidence does and does not show

Talos describes the code and the infrastructure it found. It does not report any victim's actual bill. It does not say how many machines are infected. It does not say how the implant first reaches them.

Talos is moderately confident that NIK C2 is a working framework, not a proof of concept. It saw at least three versions of the implant. It also saw a server that was active during its research.

That is one framework from one research team. It is not evidence of a wider trend.

Questions to put to your team

Ask where OpenAI and other AI keys live on Windows machines. Ask whether any sit in environment variables, since that is the variable this implant checks. Ask who can see them, and whether developer laptops hold production keys.

Ask whether each key has a spending cap. Spending alerts may surface unexpected usage, though Talos does not report any victim bills. Separate keys for each application would also help. An odd pattern could then point to one machine.

Finally, ask whether your incident playbook treats AI keys like passwords. After a Windows compromise, rotate them, then review the usage history. On a machine running this implant, a configured key could cost money as well as data.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cisco Talos.