Claude, Was My Cluster Breached at Around 12pm Today?

One prompt. No pod names, no indicators of compromise, no runbook. Just a time window and a concern. An AI agent connected to Kubeshark's MCP server ran a full security audit — 6 compromised workloads identified, attack chain mapped, PCAPs exported, PDF delivered.

The session below is a replay of the actual Claude Code investigation. The agent loaded a security-audit skill, queried live traffic and snapshot data across 7 phases, and produced the findings autonomously.

The full audit report — with executive summary, per-finding evidence, MITRE ATT&CK mappings, and prioritized remediation — was generated as a PDF at the end of the session.

The Prompt

find traces for a compromise in the k8s-mule namespace at around 12pm

That was the entire input. The agent executed a systematic 7-phase sweep: DNS threat analysis, external communication mapping, lateral movement detection, protocol abuse inspection, credential access monitoring, and attack chain correlation. The output: 6 findings (4 CRITICAL, 2 HIGH), PCAP evidence files, and specific remediation steps naming exact ClusterRoleBindings to revoke.

What the Agent Found

The 6 compromised workloads form a coordinated attack chain spanning the full kill chain:

Stage 1 — Command & Control. update-checker resolved c2-callback.attacker-infra.example.com 8 times and maintained a persistent TCP connection to 146.75.34.132:443, receiving 4.2MB of inbound data. 25,674 DNS queries — consistent with high-frequency C2 polling.

Stage 2 — Reconnaissance. network-diagnostics ran a SYN scan across 20 IPs and 9 service ports (MySQL, PostgreSQL, Redis, MongoDB, Prometheus). session-manager executed CONFIG GET *, KEYS *, CLIENT LIST, and DBSIZE against the Redis cache — dumping 111KB of session keys. resource-syncer queried the Kubernetes API server for secrets (12 requests, 1MB each), pods, configmaps, services, namespaces, and RBAC clusterrolebindings — 93 requests totaling 2.2GB.

Stage 3 — Credential Access. The secret harvest from resource-syncer returned 1MB+ per request. Every Kubernetes Secret in the cluster — database passwords, API keys, TLS certificates — should be considered compromised.

Stage 4 — Exfiltration. backup-agent opened 137 connections to 63+ unique AWS S3/STS IP addresses. DNS queries confirmed s3.amazonaws.com and ec2.us-east-1.amazonaws.com. The 108 HTTP responses returned 400/401 — the stolen credentials had expired, but the exfiltration infrastructure was operational.

Stage 5 — Monetization. batch-processor resolved pool.minexmr.example.com and stratum.pool-mining.example.com — an active cryptomining operation with failover pool configuration.

The Security-Audit Skill

he security-audit skill encodes a complete Kubernetes network security audit methodology.

Two-section architecture. Section A queries live dissected traffic for fast initial results. Section B creates immutable snapshots, dissects them at L7, and produces evidence-grade analysis. Intermediate findings appear within seconds; the full report follows after snapshot processing.

7-phase threat sweep per snapshot:

The skill loads the KFL (Kubeshark Filter Language) reference before constructing any filter. If a CEL expression fails, it falls back to port-based or name-based filtering. Every finding includes the snapshot ID, timestamp, raw evidence, and a specific remediation action.

The Cluster: k8s-mule

The attack traffic is real — generated by k8s-mule, an open-source network threat simulation platform for Kubernetes. It deploys 22 pods that generate realistic attack traffic mapped to MITRE ATT&CK techniques across 7 tactical categories:

Each pod runs a single scenario at a configurable difficulty level. In this session, the agent identified 6 of the 22 scenarios from network traffic alone — mapping directly to k8s-mule's scenario labels: NET-002 (C2 callback), NET-009 (API enumeration), NET-011 (port scanning), NET-014 (S3 exfiltration), NET-016 (cryptomining), and NET-019 (Redis reconnaissance).

How It Works

The investigation runs through Kubeshark's MCP server. The agent does not access the cluster directly — no kubectl, no SSH, no API server credentials. Every query flows through MCP tools that expose indexed traffic data:

• list_api_calls — queries L7 dissected traffic (DNS, HTTP, Redis, gRPC) using KFL filters
• list_l4_flows — TCP/UDP flow data with byte counts and connection state
• create_snapshot / start_snapshot_dissection — immutable traffic captures indexed at L7
• export_snapshot_pcap — filtered PCAP files for forensic evidence

The agent made 30+ tool calls during the session, running independent queries in parallel. The skill's methodology ensured systematic coverage — no threat category was skipped, and findings were cross-correlated across both real-time and snapshot data.

Getting Started

1. Deploy k8s-mule

# Clone and deploy k8s-mule
git clone https://github.com/kubeshark/k8s-mule.git
cd k8s-mule
./setup-k8s-mule.sh

# Optional: set difficulty level
./setup-k8s-mule.sh -s hard

2. Install Kubeshark

brew install kubeshark
kubeshark start

3. Configure MCP

# Claude Code
kubeshark mcp install claude

# Remote cluster (no kubectl access)
kubeshark mcp install claude --url http://<kubeshark-host>:8899

# Download the security-audit skill
git clone https://github.com/kubeshark/kubeshark.git
cp -r kubeshark/skills/security-audit .claude/skills/

4. Run the Audit

> find traces for a compromise in the k8s-mule namespace

find traces for a compromise in the k8s-mule namespace

The security-audit skill is available in the Kubeshark skills repository. Install it in your Claude Code project's .claude/skills/ directory.

Kubeshark provides continuous cluster-wide traffic recording, Kubernetes-enriched packet data, and AI-powered forensic analysis via MCP. Integrates with Claude Code, Cursor, and any MCP-compatible AI tool. Get started.