NIK C2 implant uses victim's OpenAI keys for AI-driven post-exploitation

1. Executive summary

Cisco Talos has documented NIK C2, a Go-based 64-bit Windows remote access tool with a dual-channel command-and-control architecture (TLS WebSocket on port 443 plus an HTTP polling loop every 250 milliseconds) and more than 52 operator commands covering credential theft, surveillance, lateral movement and a screen-locking extortion module. The architecturally distinct feature is an embedded OpenAI Chat Completions client: the ai_generate command sends actor prompts from the infected host to https://api.openai.com/v1/chat/completions, and when the actor supplies no key the implant reads the victim's OPENAI_API_KEY environment variable, so the victim's account funds the inference and OpenAI's access logs record the victim's key. No CVE has been assigned and the item carries no CVSS score, no EPSS estimate and no CISA KEV entry; this is a malware capability assessment, not a patchable vulnerability. For EMEA financial services the exposure is to estates where developer or data-science workstations hold OpenAI API keys and where egress to api.openai.com is permitted, because in those environments the AI channel blends into legitimate traffic. Talos assesses with moderate confidence that NIK C2 is a functional framework rather than a proof of concept, based on an active server observed in the wild; no threat actor is named and no attribution is made.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

3. Technical analysis & attack chain

Talos does not describe the initial access vector. The report covers the implant's behaviour after execution, the C2 architecture, and one server observed hosting the framework. The chain below is confirmed from the source; the entry point is not.

1. The implant starts and inspects its command-line arguments. watchdog activates supervisory monitoring that relaunches the core process if terminated; copywatchdog tracks file copy operations; with neither argument it runs in primary agent mode.
2. In primary mode it takes a named mutex to enforce single-instance execution, logs [NIK] Starting, generates a 32-byte session key if uninitialised, decodes its obfuscated C2 address, and sets its masquerade name to svchost.exe or simvol.exe.
3. It records its PID in the victim's temporary application folder, then runs persistence and evasion: copies itself to %appdata%/Roaming/Microsoft/Network with modified access controls, writes Windows autostart registry entries, and masquerades its process.
4. It starts a local proxy server, opens the WebSocket communication loop in a separate goroutine, and enters a continuous heartbeat polling loop on the main thread.
5. On WebSocket handshake, before receiving any command, it sends a registration message containing hostname, local LAN IP, Windows username, user SID, the local reverse-proxy port, and the upstream proxy configuration read from the Windows registry proxy settings.
6. The HTTP polling channel posts a fresh state snapshot (hostname, watchdog status, local IP, username, timestamp, uptime) to /api/c2/update roughly every 250 milliseconds.
7. The dispatcher maps incoming commands by byte-level string matching to modules launched as concurrent goroutines, so multiple operations run in parallel.

C2 architecture. Two channels operate independently. The primary is a persistent WebSocket over TLS: a TCP dial with an eight-second timeout, port 443 appended if the address carries no port, then a TLS session that pins to a specific certificate instead of validating against the system CA store. That pinning defeats standard TLS interception proxies. The fallback is the HTTP polling loop. Resilience comes from three prioritised C2 tiers: runtime-updated URLs, an embedded encrypted server list, and a hardcoded fallback address. If an HTTP POST fails, the agent rotates to the next server address before retrying.

Wire format. Every message in both directions uses AES-256-GCM with a static key derived from a hardcoded seed stored obfuscated in the binary data section. The routine serialises JSON, generates 12 random bytes as nonce, encrypts, concatenates nonce + ciphertext + 16-byte authentication tag, Base64-encodes the result, and places it in a wrapper object under the e key alongside the plaintext agent ID (format ag_<16 hex chars>). Results go over the live WebSocket if present, otherwise by HTTP POST to /api/c2/result.

The report publishes the decoded seed and key. The decoded AES seed is d791dd0ff3228ed29a8d7333d4567be829159c5632ea347780992006f91c5295 and the resulting 32-byte AES key is 4887AFC0A574E9419A9695EF083460F58E4EF9A1C40793523CE112251273BDF9. These are in §5 because they let a defender decrypt captured NIK C2 traffic offline.

C2 endpoints.

AI module (ai_generate). The implant extracts three fields from the C2 command payload: prompt (the actor's text), api_key (optional), and model (optional). A zero-length prompt returns an error without any outbound call. If no key is supplied, the implant calls the OS environment variable reader for OPENAI_API_KEY and uses the victim's key. If no model is supplied it falls back to a five-character default in the binary data section, which decodes to gpt-4; the actor can pass any valid OpenAI model identifier, so newer models can be selected without a binary update. The request body is a four-field map: model, messages (a two-element array, system message first then user message), temperature (a float constant from the binary), and max_tokens (an integer constant from the binary). The system message content is a hardcoded 68-byte string that sets the model's operational role and response style for the session. The JSON is POSTed to https://api.openai.com/v1/chat/completions from the victim's IP address, synchronously, with a 60-second timeout. On HTTP 200 the handler decodes the response into a generic map without a typed schema, walks choices then message then content, and returns a result map with status set to generated, code holding the model's reply text, model holding the resolved model name, and usage holding the raw token counts (prompt, completion, total). The result is encrypted and sent to C2 over WebSocket or the HTTP fallback.

The billing and logging consequence is the point: the victim's payment method is charged, and OpenAI's access logs show the victim's key as the requester, leaving no trace attributable to the actor.

Collection. The theft commands run as goroutines and assemble a labelled report with sections such as === CRYPTO ===, === WIFI === and === BROWSER ===.

Wi-Fi harvesting runs netsh wlan show profiles and netsh wlan show profile name="" key=clear through Go's exec.Command with discrete argument tokens rather than a shell string. Results are labelled Key Content: for plaintext passwords and WiFi Profiles: for saved network names, with per-entry misses flagged as [%s] not found and failures returning [WiFi] no wireless adapter or access denied or No WiFi profiles found.

Browser theft stages the databases below plus the Local State file, which holds the AES master key protected by DPAPI. The implant imports and calls CryptUnprotectData to unwrap the key and decrypt locally; otherwise it exfiltrates the raw encrypted databases for offline extraction.

Discord tokens and session cookies are pulled from the levelDB store and the copied Cookies database, labelled === Discord Tokens === and DISCORD TOKENS, with cookies as Discord_Cookies. Desktop wallets are collected from their storage paths; browser extension wallets are extracted from chromium LevelDB by extension ID.

Two case-insensitive regexes scan the entire filesystem for seed material and private keys, matched data is labelled seed candidates, and the archive is written as browserdata.zip:

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

Both are unanchored and greedy, so they capture any file where the sensitive term precedes the extension.

Reconnaissance runs with a chcp 65001 prefix to force UTF-8 output:

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

Surveillance. The keylogger polls all 256 Windows virtual key codes through dynamically resolved API calls. Each valid keypress is streamed live as an AES-256-GCM encrypted JSON payload over WebSocket and appended to an in-memory buffer capped at 10,000 entries, halved when full. An actor dump command concatenates the buffer and returns it over WebSocket or HTTP fallback. The command set also covers full-screen and continuous screen capture, camera snapshot and stream, microphone recording and live audio, clipboard interception and replacement, and HVNC for desktop control invisible to the victim.

Lateral movement. An embedded SOCKS5/HTTP proxy routes actor traffic through the victim into the internal network. A reverse proxy tunnel relays bidirectional TCP over the C2 WebSocket for LAN pivoting. RDP operations interact with sessions for movement to other Windows hosts.

Evasion. At launch the implant hides its console via ShowWindow, renames the binary to csrss.exe in the Windows temp directory, disables Windows Recent Documents telemetry by registry write, and sets the critical-process flag via NtSetInformationProcess with parameter 0x1D (ProcessBreakOnTermination), so terminating it through Task Manager or taskkill causes a blue screen. Two anti-debug checks, IsDebuggerPresent and CheckRemoteDebuggerPresent, call os.Exit(0) on detection, leaving no exception record or crash evidence. On C2 direction it escalates without a UAC prompt through the fodhelper.exe COM hijack: it writes the implant path into HKCU\Software\Classes\ms-settings\Shell\Open\command, triggers elevation, and cleans the key within two seconds. It bypasses AMSI by running an embedded PowerShell script that patches memory inside System.Management.Automation.dll, overwriting the AmsiInitFailed field with a six-byte stub (MOV EAX, E_INVALIDARG; RET) so initialisation reports failure and content inspection is disabled for the rest of the PowerShell session. The command set also lists process hollowing and a stealth mode.

Screen-locking extortion module. This is a multi-stage controller the actor runs in sequence. It uses PowerShell to read the first sector of \\.\PhysicalDrive0 (the MBR) and write it to mbr_backup.bin in the Windows temp directory. It builds a self-contained HTML lock screen at runtime from a hardcoded format string parameterised with actor-supplied Bitcoin and USDT wallet addresses, prices, contact email, timer duration and custom text from the C2 command, and writes it to lock_screen.html in the system temp directory. It generates lock_start.bat, which calls mshta.exe with the HTML path inside an infinite loop with a five-second timeout, so a closed window reopens within five seconds. It runs reg add to write a 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 runs at every logon, and spawns a goroutine that continuously monitors and relaunches the lock screen process. It then confirms to C2 with the deployed HTML path and timer value.

The module encrypts no files. It leaves no file-modification timestamps or encryption markers, deploys faster than file-encrypting ransomware, and survives both dismissal attempts and restart through the Run key and self-healing loop. The ransom demand is in Bitcoin or USDT. Talos does not describe data theft followed by extortion, so this is screen-lock extortion, not double extortion.

Bootkit preparation. The implant runs bcdedit /enum with the console window hidden and searches the output in sequence for EFI, Windows Boot Manager and Windows Legacy OS Loader; a match classifies the boot type as UEFI, and a fallback search for ntldr classifies BIOS. It runs PowerShell Confirm-SecureBootUEFI and searches for True or False, recording unknown if neither appears. It returns a map of boot type and Secure Boot status to C2. It then writes a 16-byte placeholder bootkit.bin to the system temp directory containing the ASCII string NIK_BOOTKIT_PREP. The placeholder is a staging marker: it confirms the target path is writable and establishes the location that a real bootkit delivered through the file-upload or file-write handlers can overwrite.

Build and versioning. Observed samples embed the build path /opt/nik_panel/data/build_52b79724a1fc4b8f/main.go, identifying the project as nik_panel and showing cross-compilation for Windows from Linux. An embedded eight-byte hex token matching the build identifier indicates the actor's infrastructure tracks and versions implants. All observed binaries were compiled with Go 1.23.4, released December 2024, so the sample set is no earlier than late 2024. PE TimeDateStamp fields are zeroed and filesystem timestamps are near-epoch (manifesting as 29 November 1979) across all samples. Talos tracks at least three versions.

Infrastructure. Talos observed the framework hosted at 87.120.196[.]120, resolving total-sitevv[.]lol, with a TLS certificate whose Common Name is nik-panel, matching strings embedded in the implant binary. The certificate serial number is 7d16381a9de823943b5a0987dbd0f26edf22052b and the JARM is 28d28d28d00000000042d42d0000001f361a1bf80ed39a1e352adeb016a07b.

Confidence and gaps. This section rests on a single source, the Talos report. The active-server observation and the moderate-confidence assessment that NIK C2 is functional rather than a proof of concept are Talos's, not corroborated here. No threat actor is named and no attribution is made; there is no MITRE ATT&CK profile for any actor in this item, so any actor attribution a client encounters elsewhere should be treated as unconfirmed. The initial access vector, the delivery mechanism, the identity of any victim and the volume of infections are not stated. The report gives no file hashes. The ClamAV signature Win.Trojan.GoDiscorder-10060526-0 is the only vendor detection named, and its GoDiscorder naming does not obviously match the nik_panel project name; treat the signature as the vendor's label and verify it detects the samples in your estate before relying on it.

4. Mitigation & containment

P1, within 24 hours.

• Hunt for the implant's persistence and staging artefacts across Windows endpoints: files under %appdata%/Roaming/Microsoft/Network, csrss.exe or simvol.exe running from a temp directory, mbr_backup.bin, lock_screen.html, lock_start.bat and bootkit.bin in temp directories, and a Run key named SystemLock under HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Any hit is a confirmed compromise, not a lead.
• Search endpoint and proxy logs for POSTs to /api/c2/update, /api/c2/result, /api/c2/screen, /api/c2/file_chunk, /api/c2/rproxy_up and /api/c2/ws. The 250-millisecond polling cadence to /api/c2/update is a strong signal on its own.
• Block the observed infrastructure at egress and DNS: 87.120.196[.]120 and total-sitevv[.]lol. This is one server from a single source; it will not cover other deployments, so pair it with the behavioural detections in §6.
• Inventory which endpoints hold an OPENAI_API_KEY environment variable, and check OpenAI usage and billing records for requests the account owner did not make, particularly requests originating from corporate egress IPs at times that do not match the key owner's activity. The victim's key appears as the requester in OpenAI's logs, so this is the only place the abuse surfaces on the provider side.
• If a host is confirmed infected, treat every credential and session on it as stolen: browser-stored passwords and cookies, Discord tokens, Wi-Fi PSKs, desktop and extension wallet seeds and keys, and anything typed during the keylogger session. Rotate them. Do not rely on terminating the implant process, because the ProcessBreakOnTermination flag will bugcheck the host; isolate at the network and hypervisor layer instead.

P2, within 72 hours.

• Restrict egress to api.openai.com to approved hosts and approved service accounts, and alert on requests to /v1/chat/completions from endpoints that are not sanctioned AI workstations. This directly removes the victim-funded inference path and gives you a detection surface.
• Because the implant pins to a specific TLS certificate rather than the system CA store, TLS interception proxies will not see its traffic. Do not treat "no proxy hit" as absence; rely on endpoint telemetry and the HTTP fallback endpoint paths.
• Add EDR detections for the AMSI patch (memory writes to System.Management.Automation.dll overwriting AmsiInitFailed), the fodhelper.exe COM hijack writing to HKCU\Software\Classes\ms-settings\Shell\Open\command, bcdedit /enum and Confirm-SecureBootUEFI invoked by a non-administrative, non-management process, and mshta.exe launched against an HTML file in a temp directory.
• Deploy the vendor signature Win.Trojan.GoDiscorder-10060526-0 where ClamAV is in use, and confirm your primary AV/EDR has equivalent coverage; the report names no other detection.

P3, within 7 days.

• Review DORA Art. 28 third-party arrangements for AI providers: an OpenAI account funded by a corporate payment method is an ICT third-party dependency, and the abuse path here runs through it. Confirm you can obtain usage logs from the provider on request.
• Add the filesystem regex patterns in §3 to DLP or file-scanning policy so seed phrases and private keys in .txt, .md, .csv, .dat, .key and .pem files on user endpoints are flagged before an implant finds them.
• Test the screen-lock scenario in tabletop form: the module leaves no encryption markers, so standard ransomware playbooks keyed on file entropy and extension changes will not fire. Detection has to come from the SystemLock Run key, mshta.exe behaviour and the MBR backup file.

5. Indicators of compromise

No file hashes are published in the source. The report references a Talos GitHub repository for IOCs but does not list hashes inline; retrieve them from that repository rather than treating the table above as complete.

ipv4  87.120.196[.]120
domain  total-sitevv[.]lol
jarm  28d28d28d00000000042d42d0000001f361a1bf80ed39a1e352adeb016a07b
x509_serial  7d16381a9de823943b5a0987dbd0f26edf22052b
x509_cn  nik-panel
aes_key  4887AFC0A574E9419A9695EF083460F58E4EF9A1C40793523CE112251273BDF9
aes_seed  d791dd0ff3228ed29a8d7333d4567be829159c5632ea347780992006f91c5295
file_path  %appdata%/Roaming/Microsoft/Network
file_path  /opt/nik_panel/data/build_52b79724a1fc4b8f/main.go
file_name  mbr_backup.bin
file_name  lock_screen.html
file_name  lock_start.bat
file_name  bootkit.bin
file_name  browserdata.zip
registry_key  HKCU\Software\Microsoft\Windows\CurrentVersion\Run\SystemLock
registry_key  HKCU\Software\Classes\ms-settings\Shell\Open\command
url_path  /api/c2/update
url_path  /api/c2/result
url_path  /api/c2/screen
url_path  /api/c2/file_chunk
url_path  /api/c2/rproxy_up
url_path  /api/c2/ws

Behavioural indicators

6. Detection

The YARA rule below keys on strings the implant carries in its binary: the startup log line, the build path, the bootkit staging marker, the C2 endpoint paths, the masquerade names and the default model string. It will not match samples where the actor has changed these, and it is written against a single source's description rather than a sample set, so validate it against known-good Go binaries before production use.

rule NIK_C2_Go_Implant_Strings
{
    meta:
        author = "Adverse Trace"
        date = "2026-10-29"
        reference = "https://blog.talosintelligence.com/nik-c2-new-ai-enabled-framework/"
        description = "String-based detection for the NIK C2 Go implant (nik_panel), covering startup log, build path, bootkit staging marker and C2 endpoint paths"
        confidence = "moderate, single source, validate before enforcement"

    strings:
        $startup   = "[NIK] Starting" ascii wide
        $buildpath = "/opt/nik_panel/data/build_" ascii
        $bootmark  = "NIK_BOOTKIT_PREP" ascii
        $ep_update = "/api/c2/update" ascii
        $ep_result = "/api/c2/result" ascii
        $ep_screen = "/api/c2/screen" ascii
        $ep_chunk  = "/api/c2/file_chunk" ascii
        $ep_rproxy = "/api/c2/rproxy_up" ascii
        $ep_ws     = "/api/c2/ws" ascii
        $masq1     = "simvol.exe" ascii wide
        $masq2     = "nik-panel" ascii wide
        $defmodel  = "gpt-4" ascii
        $openai    = "OPENAI_API_KEY" ascii
        $oaiurl    = "https://api.openai.com/v1/chat/completions" ascii
        $lockkey   = "SystemLock" ascii wide
        $mbrbackup = "mbr_backup.bin" ascii wide
        $lockscr   = "lock_screen.html" ascii wide
        $lockbat   = "lock_start.bat" ascii wide
        $bootfile  = "bootkit.bin" ascii wide
        $browzip   = "browserdata.zip" ascii wide

    condition:
        uint16(0) == 0x5A4D and filesize < 30MB and
        (
            $startup or
            $buildpath or
            $bootmark or
            (2 of ($ep_*)) or
            ($masq1 and $masq2) or
            ($oaiurl and $openai) or
            (2 of ($lockkey, $mbrbackup, $lockscr, $lockbat, $bootfile, $browzip))
        )
}

The Sigma rule targets the process and registry behaviour a defender can see without the binary. It assumes Sysmon with command-line and registry event logging.

title: NIK C2 Implant Behavioural Indicators
id: 8f3c2a71-4b6d-4e2a-9c1f-7d5e0a3b6c92
status: experimental
description: Detects process, registry and network behaviour attributed to the NIK C2 Go implant, including boot survey, Wi-Fi credential harvesting, screen-lock deployment and OpenAI API abuse from non-sanctioned hosts
author: Adverse Trace
date: 2026/10/29
references:

    - https://blog.talosintelligence.com/nik-c2-new-ai-enabled-framework/
logsource:
    product: windows
    category: process_creation
detection:
    selection_bootsurvey:
        CommandLine|contains:

            - 'bcdedit /enum'
            - 'Confirm-SecureBootUEFI'
    selection_wifi:
        CommandLine|contains|all:

            - 'netsh wlan show profile'
            - 'key=clear'
    selection_lockscreen:
        Image|endswith: '\mshta.exe'
        CommandLine|contains: 'lock_screen.html'
    selection_lockbat:
        CommandLine|contains|all:

            - 'lock_start.bat'
            - 'cmd /c'
    selection_fodhelper:
        Image|endswith: '\fodhelper.exe'
    selection_masquerade:
        Image|endswith:

            - '\csrss.exe'
            - '\simvol.exe'
        Image|startswith:

            - 'C:\Users\'
            - 'C:\Windows\Temp\'
    condition: 1 of selection_*
    falsepositives:

        - Legitimate boot configuration management tools invoking bcdedit or Confirm-SecureBootUEFI
        - Administrative Wi-Fi profile audits using netsh with key=clear
        - Software installers using mshta.exe
    level: high
---
title: NIK C2 Screen Lock Run Key Persistence
id: 2b7e9d14-6c3a-4f81-a5d2-0e8c4b1f7a63
status: experimental
description: Detects creation of the SystemLock Run key used by the NIK C2 screen-locking extortion module
author: Adverse Trace
date: 2026/10/29
references:

    - https://blog.talosintelligence.com/nik-c2-new-ai-enabled-framework/
logsource:
    product: windows
    category: registry_set
detection:
    selection:
        TargetObject|endswith: '\CurrentVersion\Run\SystemLock'
    condition: selection
    falsepositives:

        - Unlikely
    level: critical
---
title: NIK C2 Fodhelper UAC Bypass Registry Write
id: 5a1d8c36-9e4b-4a27-b3f0-6d2c8e5a1b47
status: experimental
description: Detects the fodhelper COM hijack registry path used by the NIK C2 implant for UAC bypass
author: Adverse Trace
date: 2026/10/29
references:

    - https://blog.talosintelligence.com/nik-c2-new-ai-enabled-framework/
logsource:
    product: windows
    category: registry_set
detection:
    selection:
        TargetObject|endswith: '\Software\Classes\ms-settings\Shell\Open\command'
    condition: selection
    falsepositives:

        - Legitimate ms-settings protocol handlers
    level: high

7. Sources

• Cisco Talos, "NIK C2: The new AI-enabled command-and-control framework", https://blog.talosintelligence.com/nik-c2-new-ai-enabled-framework/, 2026-10-29. Single source for all technical detail, infrastructure and the ClamAV signature in this advisory.

8. Adverse Trace position

No CVE, CVSS score, EPSS estimate or CISA KEV entry applies to this item; it is a malware capability assessment, and we have not assigned a severity score the data does not support. Our assessment is that NIK C2 is a functional, actively developed Windows RAT with an unusually broad command set and one feature that changes defender economics: the victim-funded OpenAI channel means AI-assisted post-exploitation leaves no attacker-attributable trace in provider logs and blends into egress that many financial services firms already permit for developer and data-science teams. The exposure is highest where OpenAI API keys sit in endpoint environment variables and egress to api.openai.com is unrestricted. Everything in §3 rests on a single Talos report; the active-server observation and the moderate-confidence "functional, not proof of concept" judgement are Talos's, and we have not independently corroborated them. No actor is named and no attribution is made; any actor attribution a client sees elsewhere should be treated as unconfirmed. We will monitor for additional reporting, for the IOC set in the Talos GitHub repository, and for any named actor or MITRE ATT&CK profile that would let us raise confidence, and we will issue an update if the initial access vector or victim profile becomes known. Clients with developer or AI workstations holding OpenAI keys should treat the P1 hunts in §4 as the priority this week.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.