NATS-as-C2: Harvesting AI API Keys via Cloud Messaging

Key Takeaways

• A threat actor exploited CVE-2026-33017, a critical unauthenticated remote code execution flaw in Langflow (CVSS 9.3), to deploy what Sysdig documented as the first confirmed use of NATS — a high-performance, cloud-native pub/sub messaging system — as attacker-controlled command-and-control (C2) infrastructure, enabling scalable, distributed harvesting of AI API keys and cloud credentials [1].
• The attacker’s toolset, internally named “KeyHunter,” scraped public code-sharing platforms for exposed API keys using a twelve-pattern regex set covering AWS, OpenAI, Anthropic, Google, GitHub, Stripe, Slack, database URLs, JWTs, and private keys, then validated and reported results back over the NATS C2 channel [1].
• Harvested AWS credentials were subsequently used in LLMjacking operations against AWS Bedrock foundation models — converting stolen compute access directly into AI inference without payment [1].
• Industry data confirms that 18.1 million API keys and tokens were recaptured from criminal underground markets in 2025 alone, with 6.2 million credentials tied specifically to AI tools [2].
• Organizations running AI development tooling, agentic frameworks, or LLM-integrated infrastructure in cloud environments should treat external API key exposure as a first-class credential risk and implement runtime egress controls, secret rotation, and runtime threat detection immediately.

Background

NATS: Cloud-Native Messaging Co-opted as Attack Infrastructure

NATS is an open-source, high-performance messaging system designed for cloud-native and edge computing workloads. Developed under the CNCF ecosystem, it supports publish/subscribe, request/reply, and durable message queue patterns through its JetStream persistence layer [3]. Organizations use NATS for microservice orchestration, real-time data pipelines, and distributed task queuing — exactly the workloads found in modern AI deployment architectures where multiple inference workers, orchestration agents, and data pipelines must coordinate at scale.

This design profile makes NATS an attractive abuse target. On May 14, 2026, the Sysdig Threat Research Team published findings documenting what appears to be the first confirmed use of NATS as attacker-controlled C2 infrastructure, dubbed “NATS-as-C2” [1]. The choice of NATS as C2 infrastructure suggests deliberate evasion of the signature-based detection tuned for HTTP-based control panels, IRC channels, and consumer chat platforms such as Telegram or Discord — infrastructure that blends architecturally with the legitimate cloud services already deployed in target environments. Port 4222 (NATS default) traversing corporate egress controls alongside Kubernetes service mesh traffic is less likely to trigger standard detection signatures than an outbound connection to a known malware domain.

The Langflow Entry Point

The campaign’s initial access vector was CVE-2026-33017, an unauthenticated remote code execution vulnerability in Langflow, an open-source visual framework for building agentic AI applications [4]. The flaw, carrying a CVSS base score of 9.3, stems from a combination of missing authentication on certain API build endpoints and insufficient input sanitization that permits code injection. By issuing a crafted request to the public /api/v1/build_public_tmp/<flow-id>/flow endpoint, an unauthenticated attacker can execute arbitrary commands within the Langflow container process and read its full environment, including any secrets injected as environment variables at startup [4].

The vulnerability was publicly disclosed on March 17, 2026. Within 20 hours, Sysdig observed active exploitation attempts in the wild [4]. CISA added CVE-2026-33017 to its Known Exploited Vulnerabilities catalog on March 25, 2026, mandating federal agency patching and signaling the community to treat this as an active threat [4]. Langflow’s integration model commonly requires API credentials to be injected at startup — AWS access keys, LLM provider API keys, and database connection strings are all typical inputs — making a successfully exploited instance a potential source of significant credential exposure.

Security Analysis

Attack Architecture: Distributed Credential Hunting over NATS JetStream

The attacker’s infrastructure represents a meaningful operational evolution beyond opportunistic credential scraping. Within a 30-minute window following initial exploitation of a Langflow instance, the threat actor — operating from a DigitalOcean host at 159.89.205.184 — downloaded both a Python worker script and a compiled Go binary to the compromised host [1]. Static analysis of these tools revealed a systematic, worker-pool architecture for credential discovery and validation, not a single-host operation.

The NATS server, hosted at 45.192.109.25:14222, served as the coordination backbone. The server ran with authentication enabled and subject-level access control lists (ACLs) configured, indicating deliberate operational security on the attacker’s part. Compromised hosts joined the worker pool by connecting to this NATS endpoint and subscribing to structured task subjects: task.scan_cde, task.scan_web, task.validate_aws, and task.validate_ai. Using JetStream’s durable pull consumer model with explicit message acknowledgements, the operator could centrally queue scanning and validation tasks, distribute them across any number of compromised workers, and receive structured results back — a pattern architecturally difficult to distinguish from a legitimate distributed job queue without behavioral baselining [1].

This design provides the attacker with several operational advantages over traditional C2 approaches. Work can be redistributed automatically if a worker disappears. The operator never needs to maintain persistent connections to individual compromised hosts. NATS traffic on port 14222 does not match common C2 detection signatures tuned for HTTP beaconing, IRC, or DNS tunneling. And because NATS is a legitimate commercial technology used widely in the same cloud environments being targeted, defenders must reason about process behavior and egress destination rather than relying on protocol-level anomaly detection alone.

The KeyHunter Toolset: AI Credentials as Primary Targets

The attacker’s Python-based credential harvesting component, which internal artifacts identified as part of the “KeyHunter” project, embedded a twelve-pattern regular expression set covering the full range of credentials relevant to modern AI and cloud infrastructure: AWS access keys and secrets, GitHub personal access tokens, OpenAI API keys, Anthropic API keys, Google API keys, Slack tokens, Stripe secret keys, database connection URLs, JSON Web Tokens, and PEM-encoded private keys [1]. The inclusion of Anthropic API keys alongside OpenAI keys reflects the breadth of this credential-hunting operation, targeting the full range of platforms that confer access to premium AI inference capacity.

Scanning was directed at public code-sharing platforms — CodePen, JSFiddle, StackBlitz, and CodeSandbox — where developers frequently paste working code snippets containing live API keys, either inadvertently or for convenience during debugging [1]. This attack surface is well-documented: research by Cyble has identified public repositories containing hardcoded OpenAI API keys embedded in JavaScript applications, Python scripts, CI/CD configurations, and infrastructure-as-code files [5]. The KeyHunter operation represents the weaponization of this known exposure surface within an automated, distributed, cloud-native campaign architecture.

Validation of harvested credentials was performed before exfiltration, separating active keys from expired or revoked ones and increasing the operational value of each result returned to the operator. AWS keys that passed validation were subsequently tested against AWS Bedrock to confirm access to foundation model APIs, enabling LLMjacking — the consumption of AI compute capacity billed to the victim’s account [1]. At the per-token pricing of premium foundation models, systematic validation and monetization of stolen AWS credentials through Bedrock inference represents a meaningful and growing financial threat to organizations running AI workloads in AWS.

Credential Exposure at Scale: Industry Context

The KeyHunter campaign is not an isolated incident but rather a targeted expression of a broader, documented trend in credential exposure. SpyCloud’s 2026 Annual Identity Exposure Report found that 18.1 million API keys and tokens were recaptured from criminal underground sources in 2025, with the category spanning payment platforms, cloud providers, developer ecosystems, and AI services [2]. The same report identified 6.2 million credentials and authentication cookies specifically tied to AI tools — a category not previously tracked as a distinct segment in prior years’ reports — reflecting the rapid adoption of AI platforms and the corresponding growth in the attack surface they create [2].

Industry analysis consistently finds that non-human identities (NHIs) — the service accounts, API keys, OAuth tokens, and machine credentials that AI systems use to interact with infrastructure and external services — are structurally more exposed than human credentials in several respects [9]. They typically lack multi-factor authentication. They rotate infrequently or not at all, particularly in development environments. They are often granted broad permissions at creation and never scoped down as the application’s actual needs become clear. And they proliferate rapidly when agentic AI systems are deployed, since each agent, tool integration, and model connection may generate its own credential set. When an NHI is compromised, the attacker may maintain access for months before discovery [2].

MITRE ATT&CK Mapping

The observed techniques map to several MITRE ATT&CK for Cloud and Enterprise tactics. Initial Access was achieved via Exploit Public-Facing Application (T1190) through the Langflow RCE. Credential Access involved Unsecured Credentials: Credentials in Environment Variables (T1552.001) to extract AWS and AI keys. Collection was performed via Automated Collection (T1119) using the KeyHunter regex scanning toolset. Command and Control was established through Application Layer Protocol (T1071) using NATS, a legitimate messaging protocol, to blend with normal traffic. The LLMjacking phase constitutes Resource Hijacking (T1496), consuming cloud compute billed to the victim [1].

Recommendations

Immediate Actions

Organizations running Langflow or any AI orchestration framework with public API endpoints should patch to a version addressing CVE-2026-33017 immediately, or disable public build endpoints if patching is not immediately feasible. Any Langflow instance that was publicly exposed prior to patching should be treated as potentially compromised: rotate all AWS, OpenAI, Anthropic, Google, and HuggingFace credentials that were accessible as environment variables to those containers. Do not wait for forensic confirmation of exploitation before rotating — the cost of rotation is far lower than the cost of sustained credential abuse.

Review egress firewall rules for all AI workload infrastructure. Legitimate AI inference containers should not need to establish outbound connections to arbitrary IP addresses on port 4222 (NATS default) or similar unconventional ports. Block outbound connections to 45.192.109.25 and 159.89.205.184, the infrastructure identified in this campaign, and investigate any existing connections from your environment to these hosts [1]. Tighten egress policies for AI tooling so that containers can communicate only with specific, explicitly approved LLM provider endpoints and required services — not the open internet.

Short-Term Mitigations

Runtime threat detection solutions can surface portions of this attack chain even when the C2 channel uses a legitimate messaging protocol. Per Sysdig’s own analysis [1], behavioral heuristics capable of detecting NATS-as-C2 activity include flagging unexpected process executions within containers, unusual outbound connection targets, and file download behavior inconsistent with normal application operation. These detection patterns are sound regardless of the specific tool employed: the attacker’s behavior — downloading new binaries, establishing unexpected network connections, scraping credential patterns — deviates from the expected runtime behavior of an AI inference container in ways that behavioral monitoring can surface.

Audit the credential hygiene of all AI-integrated systems. Conduct a systematic review of how API keys for LLM providers, cloud infrastructure, and data services are stored and injected into AI workloads. Secrets injected as environment variables in containerized deployments are accessible to any process running in the container and can be captured at the OS level by anyone who achieves code execution. Migrate toward secrets management solutions such as AWS Secrets Manager, HashiCorp Vault, or cloud-provider native secret stores with short-lived, automatically rotated credentials wherever feasible.

Establish monitoring for non-human identity usage anomalies. Configure alerting for API key usage that deviates from established baselines: unexpected geographic origin, unusual invocation volumes, calls to services the key has not previously accessed, or API calls made outside of normal business hours. AWS CloudTrail, combined with purpose-built NHI monitoring tooling, can surface LLMjacking attempts through Bedrock or other AI services before costs escalate significantly.

Strategic Considerations

The NATS-as-C2 campaign illustrates a pattern that will likely intensify: as AI workloads become standard cloud infrastructure, the credentials that power them — LLM API keys, model provider access tokens, vector database connection strings — will become primary targets for financially motivated threat actors. Stolen AWS credentials that permit Bedrock inference can be monetized immediately through LLMjacking, and stolen LLM provider API keys can be resold on underground markets or used directly for scraping and generation at scale.

Organizations should incorporate AI credential management into their broader secrets lifecycle governance. This means treating LLM API keys with the same security controls applied to database credentials and cloud provider keys: inventory all keys, establish rotation schedules, enforce least-privilege scope at issuance, and monitor for anomalous usage. The CSA and Oasis Security “State of Non-Human Identity and AI Security” survey (January 2026) found that 51 percent of IT and security professionals reported no clear ownership of AI identities within their organizations, and over 16 percent stated they do not track when new AI credentials are created [10]. Without ownership and inventory, rotation and monitoring are impossible.

At the architectural level, AI development platforms and agentic frameworks that require internet-exposed endpoints for core functionality — as Langflow’s public build endpoint represents — should be deployed with network access controls that prevent unauthenticated external access. If the application design requires a public endpoint, that endpoint should be isolated from the environment’s production credential store, so that exploitation yields no access to live API keys or cloud credentials. Defense-in-depth at the workload level, not just perimeter controls, is the appropriate model for AI infrastructure security.

CSA Resource Alignment

This incident maps directly to several active CSA research and framework initiatives addressing the convergence of cloud and AI security. The NATS-as-C2 campaign touches each layer of the agentic AI stack — from orchestration frameworks and credential management to network architecture and identity governance — making it a useful lens for evaluating how CSA’s existing guidance applies to AI workload security in practice.

MAESTRO (Multi-Agent Environment, Security, Threat, Risk and Outcome) is the CSA’s agentic AI threat modeling framework, introduced in 2025 [6]. MAESTRO’s seven-layer architecture — from Foundation Models through Ecosystem Integration — explicitly captures the attack surface exposed in this campaign: the orchestration layer (Langflow as an agentic workflow platform), the integration layer (environment-variable-injected AI API credentials), and the ecosystem layer (public code-sharing platforms as discovery surfaces for exposed secrets). The KeyHunter campaign can be systematically analyzed using MAESTRO’s threat categorization, and organizations building agentic AI systems should apply the framework to identify analogous credential exposure risks in their own architectures.

CSA Cloud Controls Matrix (CCM) v4.1 provides governance controls directly applicable to this threat. The Identity and Access Management (IAM) domain addresses the provisioning, rotation, and deprovisioning of credentials, including non-human identities. The Infrastructure and Virtualization Security (IVS) domain covers workload isolation and network segmentation controls that can prevent lateral movement from a compromised AI container to broader cloud infrastructure. The Security Incident Management (SEF) domain establishes expectations for detection and response capabilities that should be extended to AI workload environments [7].

CSA AI Controls Matrix (AICM) addresses AI-specific security controls across 18 domains, including dedicated guidance on model security, supply chain management, and AI-specific identity and access management [8]. The AICM provides a structured approach for organizations to assess and remediate the credential hygiene gaps this campaign exploited, including controls for API key lifecycle management and monitoring of AI service access patterns.

CSA Zero Trust guidance is directly applicable to the network architecture failures this campaign exploited. A zero trust model that enforces explicit verification and least-privilege access for all network connections — including those originating from AI workload containers — would have blocked the outbound NATS connection to attacker infrastructure before credential exfiltration could occur. Container workloads should be treated as untrusted by default and permitted only the specific egress required for their documented function.

The OWASP Non-Human Identities Top 10, which CSA has endorsed and documented [9], addresses the structural vulnerability class that makes AI API key harvesting operationally valuable. NHI:1 (Improper Offboarding), NHI:2 (Secret Leakage), and NHI:7 (Long-Lived Secrets) all describe conditions directly observable in the KeyHunter campaign’s discovery surface — public repositories and code-sharing platforms laden with exposed, active API keys.

References

[1] Sysdig Threat Research Team. “NATS-as-C2: Inside a new technique attackers are using to harvest cloud credentials and AI API keys.” Sysdig, May 14, 2026.

[2] SpyCloud. “SpyCloud Annual Identity Exposure Report 2026.” SpyCloud, March 2026.

[3] Synadia Communications. “NATS.io — Cloud Native, Open Source, High-Performance Messaging.” NATS.io, accessed May 2026.

[4] The Hacker News. “Critical Langflow Flaw CVE-2026-33017 Triggers Attacks within 20 Hours of Disclosure.” The Hacker News, March 2026.

[5] Cyble Research. “When AI Secrets Go Public: Exposed ChatGPT API Keys.” Cyble, 2025.

[6] Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” CSA, February 2025.

[7] Cloud Security Alliance. “Cloud Controls Matrix and CAIQ v4.1.” CSA, accessed May 2026.

[8] Cloud Security Alliance. “AI Controls Matrix.” CSA, accessed May 2026.

[9] Cloud Security Alliance. “Introducing the OWASP NHI Top 10: Standardizing Non-Human Identity Security.” CSA, June 2025.

[10] Cloud Security Alliance / Oasis Security. “State of Non-Human Identity and AI Security.” CSA, January 2026.