Back to Intelligence

x47.c Windows Botnet Weaponizes xAI Grok API for AI-Driven Persistence — Detection and Response Guide

SA
Security Arsenal Team
September 27, 2026
11 min read

SecurityWeek recently reported on a new Windows botnet tracked as x47.c that represents a meaningful evolution in how commodity malware operates: instead of relying on a static command-and-control (C2) server to issue instructions, the botnet offloads its decision-making to xAI's Grok large language model. Infected hosts query the Grok API to select from a set of predefined actions, giving the operators an adaptive, resilient persistence layer — and simultaneously abusing (and draining) victims' AI API keys and credits.

For defenders, this is a watershed moment worth paying attention to. We've spent years building detections around beaconing to known-bad infrastructure, DGA domains, and hardcoded C2 IPs. x47.c renders much of that playbook obsolete by riding on legitimate, TLS-encrypted traffic to api.x.ai — a domain your proxy logs probably whitelist or ignore. If your organization has developers using xAI, Grok, or other LLM APIs, you now have a detection blind spot that an active botnet is exploiting.

This post breaks down how x47.c operates from a defender's perspective, provides production-ready Sigma, KQL, and Velociraptor detections, and gives you a concrete eradication and hardening plan.

Technical Analysis

What x47.c Does

Based on the reporting, x47.c exhibits two primary behaviors that distinguish it from traditional Windows botnets:

1. LLM-Driven Decision Loop for Persistence

Rather than receiving explicit commands from an operator-controlled C2, the malware maintains a predefined menu of actions — persistence establishment, payload staging, lateral movement prep, data staging, and similar operator tasks — and queries the Grok API to decide which action to execute and when. The LLM effectively becomes the botnet's brain.

This has serious defensive implications:

  • No static C2 to block. The botnet's "command channel" is api.x.ai, a legitimate SaaS endpoint operated by xAI. Domain and IP blocklists are useless without collateral damage.
  • Non-deterministic behavior. Traditional botnets replay predictable tasking patterns. An LLM choosing actions introduces timing and sequencing variance that defeats naive behavioral baselines keyed on fixed intervals or fixed action order.
  • Rapid operator iteration. The operators can change the bot's behavior by changing the prompt, not the binary. That means signatures built on today's payload may miss tomorrow's variant.

2. AI API Draining

x47.c doesn't just use its own operator-controlled API key — it harvests AI API credentials from compromised hosts and drains them. On a typical developer workstation or build server, that means hunting for:

  • Environment variables such as XAI_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY, AZURE_OPENAI_API_KEY, GOOGLE_API_KEY
  • Configuration files: ~/.config, %APPDATA% credential stores, .env files, appsettings.json, IDE and SDK config files
  • Cloud instance metadata and secrets stores reachable from the host

The financial impact is direct: stolen LLM API keys get burned at scale, racking up usage charges against the victim's xAI/OpenAI/Anthropic accounts. The strategic impact is worse — a valid API key on an infected host is the malware's own authentication material, meaning credential rotation is a prerequisite for eviction, not an afterthought.

Affected Platforms

  • Windows endpoints and servers — the botnet specifically targets Windows. Developer workstations, build agents, and servers with AI SDKs installed are the highest-value targets because they're most likely to hold LLM API credentials.
  • Organizations with xAI/Grok, OpenAI, Anthropic, or Azure OpenAI usage — both as infection targets (API keys present on hosts) and as unwitting C2 providers (traffic to api.x.ai blends into legitimate use).

Exploitation Status

x47.c is confirmed active in the wild as a functioning botnet. This is not a proof-of-concept or a research demo — it is an operational compromised-device network using a production LLM API for tasking. There is no CVE associated with this campaign; the abuse is of legitimate API functionality (valid credentials + legitimate endpoint), which is precisely what makes it hard to kill with traditional controls. It maps to MITRE ATT&CK techniques including T1102 (Web Service), T1071.001 (Application Layer Protocol: Web), T1552.001 (Unsecured Credentials: Credentials In Files), and T1059 (Command and Scripting Interpreter).

Detection & Response

The detection thesis is simple: LLM API traffic is only legitimate from a small, known set of processes and hosts. Grok API calls from powershell.exe, rundll32.exe, an unsigned binary in %TEMP%, or a server with no AI workload are high-fidelity signals. Credential access to API-key-bearing files and environment variables is the second pillar.

Sigma Rules

YAML
---
title: Suspicious Process Network Connection to xAI Grok API
id: 3f8a1c94-7b2e-4d5a-9c61-8e4f2a0b7d33
status: experimental
description: Detects non-browser, non-approved processes establishing network connections to the xAI Grok API endpoint (api.x.ai), consistent with x47.c botnet LLM-driven C2 tasking. Baseline legitimate AI SDK processes in your environment before enabling at high level.
references:
  - https://www.securityweek.com/new-x47-c-windows-botnet-weaponizes-xai-grok-ai-api-draining/
  - https://attack.mitre.org/techniques/T1102/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1102
  - attack.t1071.001
logsource:
  category: network_connection
  product: windows
detection:
  selection_destination:
    DestinationHostname|contains:
      - 'api.x.ai'
      - 'api.grok.x.ai'
  filter_approved:
    Image|endswith:
      - '\Code.exe'
      - '\python.exe'
      - '\python3.exe'
      - '\node.exe'
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
  condition: selection_destination and not filter_approved
falsepositives:
  - Legitimate Grok SDK integrations running from custom paths
  - Electron-based AI clients
level: high
---
title: API Key Environment Variable Access via Command Line
id: 8c2d4e61-3a9f-4b7c-b512-6d8e0f1a9c44
status: experimental
description: Detects command-line access to AI provider API key environment variables, consistent with x47.c credential harvesting and API draining behavior. Administrators legitimately echo these keys rarely; treat hits as suspicious by default.
references:
  - https://www.securityweek.com/new-x47-c-windows-botnet-weaponizes-xai-grok-ai-api-draining/
  - https://attack.mitre.org/techniques/T1552/001/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_keys:
    CommandLine|contains:
      - 'XAI_API_KEY'
      - 'GROK_API_KEY'
      - 'OPENAI_API_KEY'
      - 'ANTHROPIC_API_KEY'
  selection_method:
    CommandLine|contains:
      - 'echo'
      - 'set '
      - 'Get-ChildItem Env:'
      - 'gci env:'
      - '$env:'
      - '[Environment]::GetEnvironmentVariable'
      - 'printenv'
  filter_setup:
    CommandLine|contains:
      - 'setx'
  condition: selection_keys and selection_method and not filter_setup
falsepositives:
  - Developers validating local configuration
  - CI/CD pipeline diagnostics
level: medium
---
title: Bulk Read of AI Credential and Environment Configuration Files
id: b71e9f02-4c5d-4a8e-9237-1f6c8d3e5a21
status: experimental
description: Detects suspicious processes reading .env files and AI SDK configuration files where LLM API keys are commonly stored, consistent with x47.c API key harvesting prior to API draining.
references:
  - https://www.securityweek.com/new-x47-c-windows-botnet-weaponizes-xai-grok-ai-api-draining/
  - https://attack.mitre.org/techniques/T1552/001/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|endswith:
      - '\.env'
      - '\.env.local'
      - '\.env.production'
      - '\openai\config.json'
      - '\anthropic\config.json'
      - '\xai\config.json'
  filter_dev:
    Image|endswith:
      - '\Code.exe'
      - '\devenv.exe'
      - '\idea64.exe'
      - '\node.exe'
      - '\python.exe'
      - '\git.exe'
  condition: selection and not filter_dev
falsepositives:
  - Backup agents and indexing services
  - DLP scanners
level: medium

KQL — Microsoft Sentinel / Defender

The following hunt query correlates outbound connections to xAI API endpoints with the initiating process, flagging anything outside an approved process list. Run it over 7 days first to build your baseline, then convert the residual to an analytics rule.

KQL — Microsoft Sentinel / Defender
// Hunt: Non-standard processes communicating with xAI Grok API (x47.c LLM-C2 indicator)
let ApprovedAIClients = dynamic([
    "code.exe", "python.exe", "python3.exe", "node.exe",
    "chrome.exe", "msedge.exe", "firefox.exe"
]);
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemoteUrl has_any ("api.x.ai", "api.grok.x.ai")
   or RemoteIP in ("104.18.0.0/16") // replace with resolved api.x.ai ranges from your DNS telemetry
| extend ProcessName = tolower(split(InitiatingProcessFileName, "\"")[-1])
| where ProcessName !in~ (ApprovedAIClients)
| summarize
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    ConnectionCount = count(),
    RemoteIPs = make_set(RemoteIP, 10),
    CommandLines = make_set(InitiatingProcessCommandLine, 5)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessAccountName
| project FirstSeen, LastSeen, DeviceName, InitiatingProcessFileName,
          InitiatingProcessFolderPath, InitiatingProcessAccountName,
          ConnectionCount, RemoteIPs, CommandLines
| order by ConnectionCount desc;
// Companion hunt: processes reading AI API key material from environment or config files
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where ProcessCommandLine has_any (
    "XAI_API_KEY", "GROK_API_KEY", "OPENAI_API_KEY", "ANTHROPIC_API_KEY")
   and ProcessCommandLine has_any (
    "echo", "$env:", "Get-ChildItem Env:", "GetEnvironmentVariable", "printenv")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine,
          AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by TimeGenerated desc;

Note the operator comment in the first query: do not blindly trust a static IP range for api.x.ai. Resolve the domain from your own DNS telemetry (DeviceNetworkEvents where RemoteUrl == "api.x.ai") and hunt on the resolved addresses, since Cloudflare-fronted SaaS rotates IPs.

Velociraptor VQL

Use this hunt artifact across your fleet to identify hosts with live connections to xAI infrastructure from non-standard processes, combined with a check for API key material in process environments.

VQL — Velociraptor
-- Hunt: x47.c LLM-C2 indicator — active connections to api.x.ai from suspicious processes
SELECT Pid, Name, Exe, CommandLine, Username,
       netstat.RemoteAddr AS RemoteAddr,
       netstat.RemotePort AS RemotePort,
       netstat.Status AS ConnStatus,
       CreateTime
FROM pslist()
JOIN (
    SELECT Pid AS NetPid, RemoteAddr, RemotePort, Status
    FROM netstat()
    WHERE RemotePort = 443
      AND Status = 'ESTABLISHED'
) AS netstat
ON pslist.Pid = netstat.NetPid
WHERE Name =~ '(?i)(powershell|pwsh|cmd|rundll32|regsvr32|mshta|wscript|cscript)'
   OR Exe =~ '(?i)(\\temp\\|\\appdata\\local\\temp\\|\\programdata\\|\\users\\public\\)'
-- Second artifact: enumerate processes holding AI API keys in their environment block
SELECT Pid, Name, Exe, Username,
       environ() AS EnvVars
FROM pslist()
WHERE EnvVars =~ '(?i)(XAI_API_KEY|GROK_API_KEY|OPENAI_API_KEY|ANTHROPIC_API_KEY)'

Run the netstat artifact alongside a DNS resolution of api.x.ai (via Velociraptor's query against your DNS logs or a simple resolve enrichment) to confirm the remote addresses. The environment-block sweep is equally valuable: any process holding these keys that isn't your known AI tooling is both a potential x47.c node and a credential exposure.

Remediation / Hunt Script (PowerShell)

PowerShell
# x47.c Botnet Triage & Hardening Script — run elevated on suspect endpoints
# 1. Identify live connections to xAI API infrastructure from non-approved processes
$approved = @('code.exe','python.exe','python3.exe','node.exe','chrome.exe','msedge.exe')
$xaiIPs = (Resolve-DnsName api.x.ai -Type A -ErrorAction SilentlyContinue).IPAddress
Get-NetTCPConnection -State Established -RemotePort 443 -ErrorAction SilentlyContinue |
  Where-Object { $xaiIPs -contains $_.RemoteAddress } |
  ForEach-Object {
    $p = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
    if ($p -and $approved -notcontains $p.ProcessName.ToLower()) {
      [PSCustomObject]@{
        Alert      = 'SUSPICIOUS_XAI_CONNECTION'
        PID        = $p.Id
        Process    = $p.ProcessName
        Path       = $p.Path
        RemoteIP   = $_.RemoteAddress
        StartTime  = $p.StartTime
      }
    }
  }

# 2. Sweep common credential locations for AI API keys (exposure check, rotate if found)
$keyPaths = @(
  "$env:USERPROFILE\.env",
  "$env:APPDATA\xai",
  "$env:APPDATA\openai",
  "$env:USERPROFILE\.config"
)
foreach ($path in $keyPaths) {
  if (Test-Path $path) {
    Get-ChildItem $path -Recurse -ErrorAction SilentlyContinue |
      Select-String -Pattern 'XAI_API_KEY|GROK_API_KEY|OPENAI_API_KEY|ANTHROPIC_API_KEY' -List |
      ForEach-Object { Write-Warning "API key material found: $($_.Path) — ROTATE IMMEDIATELY" }
  }
}

# 3. Check persistence locations for recently created entries (x47.c persistence footholds)
Get-CimInstance Win32_StartupCommand |
  Where-Object { $_.Command -match 'temp|appdata|programdata|powershell' } |
  Select-Object Name, Command, Location, User
Get-ScheduledTask | Where-Object {
  $_.Actions.Execute -match 'powershell|wscript|mshta' -and
  $_.Date -gt (Get-Date).AddDays(-30)
} | Select-Object TaskName, TaskPath, @{n='Action';e={$_.Actions.Execute}}

# 4. Optional containment: block api.x.ai at the endpoint firewall on hosts with NO legitimate Grok use
# Comment out until you have inventoried legitimate usage — this WILL break sanctioned AI tooling
# New-NetFirewallRule -DisplayName 'Block xAI API (x47.c containment)' -Direction Outbound `
#   -RemoteAddress $xaiIPs -Protocol TCP -RemotePort 443 -Action Block

Remediation

1. Rotate every AI API key immediately — fleet-wide assumption of compromise. Any host that communicated with api.x.ai outside your approved process inventory must have all LLM provider keys rotated: xAI console, OpenAI, Anthropic, Azure OpenAI. Do this before malware removal, not after — a live implant will simply re-harvest the old keys or exfiltrate new ones during your cleanup window.

2. Establish an approved-process and approved-host inventory for LLM API traffic. The durable fix for this threat class is egress policy: only specific hosts (build servers, developer machines with registered AI projects) and specific process hashes should be permitted to reach api.x.ai, api.openai.com, and api.anthropic.com. Enforce this at the proxy or egress firewall, not the endpoint.

3. Eradicate and reimage confirmed infections. For hosts flagged by the hunts above: isolate from the network, capture memory and triage images for IR, audit scheduled tasks / Run keys / services / WMI subscriptions created in the last 60 days, then reimage. Botnets with LLM-driven tasking can receive novel instructions mid-response — do not assume a static payload.

4. Move API keys out of files and environment variables. Migrate to a secrets manager (Azure Key Vault, HashiCorp Vault, AWS Secrets Manager) with just-in-time retrieval. Keys sitting in .env files and persistent environment variables are exactly what x47.c's draining module is built to find. Set spend alerts and rate limits on all LLM API accounts so draining is caught financially even if it's missed technically.

5. Add LLM API endpoints to your threat model and detection content permanently. Deploy the Sigma rules above, convert the KQL hunt to a scheduled analytics rule after baselining, and add api.x.ai connection telemetry to your SOC's standard triage checklist. x47.c is the first botnet of this kind to get press — it will not be the last.

6. Monitor for abnormal API consumption. Pull usage reports from your xAI/OpenAI/Anthropic dashboards. Spikes in token consumption, requests from unfamiliar ASN/geography, or keys used outside business hours are leading indicators of draining that no endpoint tool will catch.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.