The attacker's C2 is no longer an HTTP panel. It is a pub/sub message broker with authentication, ACLs, and durable queues. At Tech86, we have been tracking the evolution of command-and-control tactics, and the NATS-as-C2 technique published by Sysdig represents a paradigm shift that most security teams have not yet grasped.
The attack that rewrote the C2 playbook
In March 2026, CISA added CVE-2026-33017 to the Known Exploited Vulnerabilities catalog. The vulnerability: unauthenticated remote code execution in Langflow, an AI orchestration platform. What happened next reveals the speed and sophistication of modern attacks.
Within 30 minutes, the attacker exploited the vulnerability, extracted AWS credentials from process memory, and validated access via sts:GetCallerIdentity. Full reconnaissance: Bedrock, S3, EC2, Lambda, IAM. Attempted container escape via DirtyPipe and DirtyCreds. Then installed what nobody expected: a NATS server as command-and-control infrastructure.
The server was configured at 45.192.109.25:14222 — with authentication and per-subject ACLs. The attacker did not improvise. They built production-grade infrastructure to control compromised machines.
Why NATS is the perfect C2
Traditional C2 uses HTTP panels, webhooks, Discord, Telegram. These are channels security teams have monitored for years. NATS is different.
NATS provides pub/sub with native authentication, per-subject ACLs, durable queues, and fan-out. These are the same properties engineers choose for production microservices. When an attacker uses these properties for C2, the traffic is indistinguishable from legitimate traffic.
If your infrastructure uses NATS, outbound NATS traffic is allowed by default. A malicious worker connected to the attacker's broker goes unnoticed because the protocol, port, and communication pattern are identical to your microservices. Your SIEM does not alert. Your firewall does not block. Your IDS does not detect.
The KeyHunter worker: one scanner, two revenue streams
The attacker did not stop at a command channel. They implemented a worker called KeyHunter with four capabilities mapped as NATS subjects:
task.scan_cde— scans cloud development environments for exposed credentialstask.scan_web— scans CodePen, JSFiddle, StackBlitz, CodeSandbox for leaked API keystask.validate_aws— validates AWS credentials in real time before reportingtask.validate_ai— validates OpenAI, Anthropic, HuggingFace keys in real time
One worker. Two revenue streams: cloud credentials and AI keys. From the same scan. Validated before reporting to the operator. This is enterprise-grade operational efficiency — applied to credential theft.
The subject architecture allows the operator to publish tasks to one subject and receive results on another, with fan-out to multiple workers. Horizontal scaling without effort. The C2 is not a centralized panel — it is a distributed system.
Persistence and scale over stealth
The attacker configured persistence via systemd with Restart=always and FD limits of 65,535. Workers written in Python and Go, compiled for multiple architectures. Hosted on cheap DigitalOcean VPS instances.
The strategy is clear: scale over stealth. No need to hide an HTTP panel or a Discord channel anymore. Just use infrastructure that looks legitimate. Cost is low, resilience is high, and detection is hard because nobody is looking for malicious NATS traffic.
This persistence approach is particularly dangerous because it survives reboots and leaves no obvious artifacts in traditional security logs. A generically named systemd service raises no suspicion. A Go process consuming minimal resources draws no attention.
The exposure window of AI platforms
Langflow, n8n, and AI orchestration platforms need outbound access to LLM endpoints. This requirement creates a broad exposure window. Permissive outbound access is exactly the channel the worker needs to reach the C2 broker.
At Tech86, we repeatedly see teams configuring wide-open outbound access for AI workloads because "it needs to work." It works — for the attacker too. The absence of egress restrictions is what turns an RCE vulnerability into a persistent compromise with an invisible C2 channel.
The mistake is not using Langflow or n8n. The mistake is allowing these workloads to reach any outbound destination without restriction. CVE-2026-33017 was patched. The next vulnerability in an AI platform will not be. But with egress allowlists, the attacker cannot reach the C2 broker even with RCE.
The defense that works: egress allowlists
The defense against NATS-as-C2 is not detecting the protocol — it is restricting the destination. Egress allowlists are the most effective measure: restrict outbound traffic from AI and automation workloads to specific endpoints. NATS outbound traffic to unauthorized IPs must be blocked and alerted on.
At Tech86, we implement outbound traffic monitoring and egress allowlisting for AI workloads because the next C2 may be hiding in the same infrastructure your microservices use. Our Perimeter WAF Shielding includes egress traffic inspection and allowlist rules that prevent a compromised worker from reaching unauthorized brokers.
The attacker evolved. Your defense needs to evolve with them. When C2 disguises itself as legitimate infrastructure, the only defense is ensuring illegitimate traffic never leaves your network.