Wiz incident response team traces AI agent through multi-cloud intrusion

Wiz’s Customer Incident Response Team said that an AI agent system ran an intrusion across a customer’s large multi-cloud environment spanning cloud providers, Kubernetes, CI/CD and GitOps, identity, secrets, data warehouses and applications. CI/CD automates software building, testing and deployment. The team said it has seen AI-driven attacks rise across recent intrusions over the past few weeks.

The agent ran entire intrusions, locating access routes, gathering credentials, moving between platforms and fixing its own code, according to the team. AI-driven intrusions move at machine speed across every cloud layer, and their traces appear in separate logs from identity providers, cloud control planes, CI/CD systems and workloads, with no single alert showing the full story. The agent acted simultaneously across platforms from one source and time window, enumerating cloud resources while deploying Kubernetes workloads and querying databases. It used native APIs and tooling across cloud providers, container orchestration, CI/CD systems, databases, identity providers and message queues.

Initial access involved probing internet-facing services, exploitation payloads for known vulnerabilities, anonymous cloud storage attempts and abuse of an exposed internal developer tool API. A confirmed vector was a Java remote code execution vulnerability in an exposed Kafka UI instance, leading to shell commands, malware deployment and a command-and-control channel, a hidden communication path attackers use to control compromised systems. After gaining a foothold, the agent scanned for alternative entry points in parallel, and the same source IP scanned more than 600 other Wiz customer environments.

The agent deployed backdoors and command-and-control agents to many pods across many Kubernetes clusters. A service account is an identity used by applications or automated processes rather than by people. Credential harvesting included mounted Kubernetes service account tokens, environment variables searched for token, secret, key and pass, and Instance Metadata Service queries, a cloud service that lets running virtual machines retrieve information about themselves. From inside a pod’s network namespace, the agent scanned internal message brokers, schema registries and databases to map reachability.

The agent chained credentials across environments, such as from a Kubernetes service account token to a cloud service account, a CI/CD system and full administrative access. The agent operated in both GCP and AWS using obtained access keys, service account credentials and identity impersonation. In GCP, it weaponized a service account with token-creation privileges to generate credentials across dozens of identities in rapid succession.

Inside GCP, the agent pulled down container registry images without pause, tried to pull sensitive database records out, and launched Cloud Run instances that anyone could reach, each beginning with pentest-. Cloud Run runs containerized applications without managing servers. Container registries store container images used to deploy applications.

In AWS, the agent used Systems Manager to execute commands across instances, connect to databases, move via SSH, gather secrets and stage exfiltration to a bucket named pentest-<task_id>. Systems Manager lets administrators run commands on cloud instances. It also created an IAM user prefixed with probe and assumed OrganizationAccountAccessRole for administrative access across AWS Organization member accounts. IAM controls who can access which cloud resources.

Using a compromised administrator API key, the agent created an identity provider user with a pentest prefix, set its password, activated it and added it to administrators. It then added the identity to AWS IAM Identity Center role groups and broad organizational groups, then signed in to AWS through SSO, or single sign-on, within minutes.

Five simultaneous CI/CD workstreams ran in parallel: secret harvesting, reachability mapping, credential spraying, service exploitation and compute expansion. New credentials were immediately tested against all known targets, and new reachable targets were immediately tested with all known credentials. Pipelines and manifests carried names such as pentest_exfil, recon, foothold, dump-remaining and harvest with numeric task identifiers and letter suffixes for failed retries.

On GitOps, a method of managing infrastructure and applications through Git repositories, the agent pushed malicious Kubernetes manifests via a compromised deployment service account, syncing them into production; the first manifest escalated to cluster-admin. After reaching cluster-admin, it minted service account tokens to impersonate applications and attempted vault authentication and vault-agent sidecar file access. It deployed a self-healing Kubernetes workload as a command-and-control implant and modified running workloads through the GitOps controller without leaving Git history traces.

Exfiltration channels included webhook[.]site, the organization’s source control repository and a Kubernetes ConfigMap, an object that stores configuration data; the cloud provider denied attempted buckets named pentest-<task-id>-<objective>. A webhook sends automated messages between services when events occur. Attacker resources, files and payloads carried labels such as pentest, probe, recon, redteam and exfil, likely to pose as authorized security testing and bypass AI safety guardrails, the controls built into models to refuse harmful requests. Resources, users and files contained numeric task identifiers repeated across related artifacts, with retries marked by letter suffixes such as -b, -c and -d.

Recovered code contained descriptive headers, numbered step-by-step comments and reused helper functions across dozens of payloads, consistent with model-generated code. After an unsuccessful attempt, the agent read the error, rewrote its script on the fly and retried within minutes.

Activity reached hundreds or thousands of actions each hour for long periods without human working-hour patterns. The agent operated from many attacker-controlled IP addresses, harvesting credentials and secrets while accessing sensitive data and exfiltrating it through many channels.

Wiz CIRT said the defender challenge is not invisibility but separate traces in identity provider, cloud control plane, CI/CD and workload logs, with no single alert showing the full story. Wiz recommends unifying cloud audit logs, Kubernetes audit logs, runtime events, identity provider logs, CI/CD audit trails and SaaS logs in one searchable location. The team also points to AI-assisted investigation as a way to cluster related alerts, condense activity from different sources, translate payloads, and surface the most important chains of events.

Wiz recommends rotating all credentials on compromised resources and hunting identities and resources for anomalous usage after the time of compromise. It also recommends maintaining endpoint and workload visibility covering process execution, network connections and file access.

Wiz recommends restricting trust between systems so staging workloads cannot reach production credentials and CI/CD pipelines do not hold standing access everywhere. It also recommends continuously scanning the external attack surface for exposed developer tools, management consoles and internal applications.

A separate investigation by Sygnia describes a similar pattern of speed and scale in an AWS environment. The two investigations show intruders running known techniques at speed and broader reach than people normally manage, while naming tools and tasks as security exercises or red team work.

Sygnia investigated a separate AWS cloud intrusion that reached broad compromise in approximately 72 hours with no novel malware or zero-day exploit, according to its reporting. The actor sought financially motivated extortion by gaining cloud infrastructure control to threaten disruption or destruction of critical services. Sygnia cited attacker-created scripts, structured reporting artifacts, highly parallel activity and rapid playbook execution as indicators of AI assistance. It said the significance was not new techniques but the speed and scale of operationalizing familiar techniques.

Sygnia’s case study described an AWS-based intrusion that spread across applications, cloud, source-control, CI/CD and runtime services rather than staying confined to a single service or account. In one observed second, the actor used four access keys across four separate accounts from a single source IP and user-agent, indicating automated orchestration. The actor ran several hundred unique SQL queries across dozens of databases and used artifacts framed as pentest or red team. SQL queries databases for information.

Sygnia mapped the intrusion to MITRE ATT&CK, a knowledge base of adversary tactics and techniques, with concentration in Execution, Discovery, Credential Access and Collection. Cited techniques included T1059, T1651, T1609, T1648, T1677, T1552, T1528, T1087, T1580, T1619, T1578 and T1078. Anthropic research mapped AI-assisted offensive activity from 832 banned accounts onto MITRE ATT&CK, showing concentration around execution, discovery, credential access and collection. Sygnia’s CISO Survey 2026 found 73% of 600 surveyed senior IT security decision-makers believe their organizations would not be fully prepared for a serious cyber attack.

Sygnia’s advice is to get ready for AI-driven threats ahead of any breach and to expect attackers to abuse known flaws more quickly and on a larger scale.