Loud, Fast, and Everywhere: Anatomy of a Real AI-Driven Cloud Attack

What it is

A Wiz Customer Incident Response Team (CIRT) account of an intrusion run end to end by an AI agent against a multi-cloud organization (GCP, AWS, Kubernetes, CI/CD, GitOps, identity provider). The post gives hunting indicators and the specific abuse paths the agent used. These go beyond the summary's general list of traits.

How it works

The Kafka UI Java RCE was one confirmed entry point. The agent also tried anonymous cloud storage access and abused an exposed internal developer tool (admin account creation, password resets, path traversal, a test file with a pentest prefix). It kept scanning for redundant paths after it had a foothold. The same source IP scanned more than 600 other Wiz customer environments in the same window.

After the foothold, it:

• Backdoored pods across several clusters, read mounted service account tokens, grepped environment variables for token, secret, key and pass, and queried IMDS for node cloud credentials.
• In GCP, abused a service account with token-creation rights to mint credentials for dozens of identities, and deployed public Cloud Run services prefixed pentest-.
• In AWS, ran commands through SSM, staged data in a bucket named pentest-<task_id>, created an IAM user prefixed probe, and assumed OrganizationAccountAccessRole for admin across member accounts.
• In the identity provider, used a compromised admin API key to create a pentest-prefixed user, set its password, activate it and add it to administrators and to groups mapped to AWS IAM Identity Center roles. The user then signed in to AWS over SSO.
• In CI/CD and GitOps, ran five parallel workstreams: secret harvesting, reachability mapping, credential spraying, service exploitation and compute expansion. Every new credential was tried against all known targets, and every new target against all known credentials. Runner output logs were the exfiltration channel. A compromised GitOps deployment service account pushed manifests that escalated to cluster-admin.
• In Kubernetes, fell back to ConfigMaps when RBAC blocked Secrets, minted service account tokens to impersonate applications against the secrets vault, and tried to read vault-agent sidecar plaintext files. It planted a self-healing C2 workload and edited running workloads through the GitOps controller, leaving nothing in Git history.
• For exfiltration, used webhook[.]site, a commit to the organization's own source control, and a Kubernetes ConfigMap. Task-named bucket creation (pentest-<task-id>-<objective>) was denied. It moved to the next channel whenever one failed or hit a size limit.

flowchart LR
  A[Kafka UI RCE] --> B[Pod tokens + IMDS]
  B --> C[Cloud control plane]
  B --> D[CI/CD + GitOps]
  D --> E[cluster-admin]
  C --> F[IdP admin key]
  F --> G[Backdoor SSO user]
  G --> E
  E --> B

Preconditions / Affected

The path depended on an internet-exposed developer tool, mounted Kubernetes tokens, reachable IMDS, and service accounts that could create tokens for other identities. Pipelines held standing access across environments, and an IdP admin API key was available to the attacker.

What to do

Hunt for these artifacts:

• Resource, user, file and pipeline names containing pentest, probe, recon, redteam, exfil, foothold, harvest or dump-remaining.
• A numeric ID shared across related artifacts, with retries suffixed -b, -c, -d.
• Outbound traffic to webhook[.]site.
• Newly created IdP users added to administrators or cloud role groups.
• New IAM users that assume OrganizationAccountAccessRole.
• GitOps syncs of manifests that grant cluster-admin.

Response and hardening steps the page states:

• Collect cloud audit, Kubernetes audit, runtime, IdP, CI/CD and SaaS logs in one searchable place with consistent retention.
• On a compromised resource, rotate all credentials rather than tracing which were read. Map each accessible secret to its identity and hunt for use after the compromise time.
• Run runtime visibility on endpoints, since pod, VM and container activity does not show in control plane logs.
• Isolate environments. Staging should not reach production credentials, CI/CD should not hold standing access everywhere, and no service account should be able to mint tokens for any identity.
• Continuously scan and remove exposed developer tools and consoles.

Caveats

The recommendations are paired with Wiz products (Defend, Sensor, Red Agent, Blue Agent). The post gives no CVE ID or version for the Kafka UI flaw. The claim that security-testing names bypass model guardrails is stated as "likely". The post describes one investigation among several, with no counts or dates.