{"slug": "loud-fast-and-everywhere-anatomy-of-a-real-ai-driven-cloud-attack", "title": "Loud, Fast, and Everywhere: Anatomy of a Real AI-Driven Cloud Attack", "summary": "Wiz's Customer Incident Response Team (CIRT) reports that in several recent cloud intrusions an AI agent system ran the entire operation itself, finding entry points, harvesting credentials, pivoting across platforms and rewriting its own scripts on the fly, with activity reaching hundreds or thousands of actions per hour. Wiz CIRT said the agent worked simultaneously across cloud providers, Kubernetes, CI/CD systems, databases, identity providers and message queues, chaining credentials from a Kubernetes service account token to a cloud service account to a CI/CD system and finally full administrative access. The attackers labeled resources with terms such as 'pentest', 'probe', 'recon', 'redteam' and 'exfil' — framing Wiz says likely helps present the activity as authorized security testing and bypass the AI model's safety guardrails — and tagged artifacts with numeric task IDs, retrying failures under the same number with letter suffixes such as -b, -c and -d.", "body_md": "Over the past few weeks, the Wiz Customer Incident Response Team (CIRT) has seen a clear trend across investigations: AI-driven attacks are on the rise. In several recent intrusions, an AI agent system wasn't just assisting an attacker behind the keyboard. It was running the entire operation. It found entry points, harvested credentials, pivoted across platforms, and debugged its own scripts on the fly, driving the campaign from start to finish.\n\nThese intrusions don't look like traditional campaigns. They are loud, move at machine speed, and touch every layer of the cloud stack. The challenge for defenders isn't that these attacks are invisible. It's that their footprint is fragmented across identity providers, cloud control planes, CI/CD systems, and workload logs, and no single alert tells the full story.\n\nThis blog post first examines the characteristics that set AI-driven attacks apart from traditional, human-operated intrusions. It then walks through real-world examples from Wiz CIRT investigations. Finally, it outlines what security teams need in place to detect and respond to machine-speed attackers.\n\nAI-driven attacks behave differently from both human-operated intrusions and traditional script-automated attacks. While scripts execute pre-programmed steps blindly and human operators move slowly and sequentially, AI agents combine machine speed with contextual reasoning. Across multiple investigations, Wiz CIRT has observed a recurring set of characteristics that distinguish them.\n\n**Operational tempo** - Activity can reach hundreds or thousands of actions per hour and continues for long periods without the pauses or working-hour patterns typical of a human operator.\n**Simultaneous activity across multiple platforms** - The agent operates in several environments at the same time. While one task enumerates cloud resources, others deploy Kubernetes workloads, create CI/CD pipelines, or query databases, all from the same source and within the same time window. A human operator typically works through one environment at a time, and traditional scripts rarely cross environment boundaries simultaneously.\n**Proficiency across platforms** - The AI agent uses the native APIs and tooling of each platform it reaches, including cloud providers, container orchestration, CI/CD systems, databases, identity providers, and message queues. Human operators rarely have deep working knowledge of all of these at once.\n**Credential chaining across environments** - Because the agent has native fluency across so many technologies, every credential becomes a stepping stone to the next platform. For example, a Kubernetes service account token leads to a cloud service account, which leads to a CI/CD system, which ultimately grants full administrative access.\n**Rapid trial and error** - While attackers have relied on scripts for years, when a script breaks, fixing it takes time. When an agent runs the operation, that entire feedback loop happens in real time. If an attempt fails, the agent immediately reads the error, rewrites its script on the fly, and tries again within minutes, with each new attempt directly fixing what broke the previous one.\n**Security-testing naming conventions** - Resources, files, and payloads created by the actor are consistently labeled with terms such as`pentest` ,`probe` ,`recon` ,`redteam` , and`exfil` . This framing likely helps the actor present the activity as authorized security testing, effectively bypassing the AI model’s safety guardrails.\n**Numeric task identifiers** - Many of the resources, users, and files created during the attack include a numeric identifier, and the same number often appears across several related artifacts. Failed attempts are retried under the same number with a letter suffix (for example,`-b` ,`-c` ,`-d` ). These identifiers appear to be internal task IDs that the AI agent uses to track its own work.\n**Generated code patterns** - Human attackers rarely add comments to short-lived exploitation scripts. Code recovered from these attacks commonly includes descriptive headers and numbered step-by-step comments, and the same helper functions are reused across dozens of payloads. Both are a direct result of how the code was generated by the model.\n\nAI-driven attacks don't follow a clean, linear path. The agent works across many platforms in parallel and loops back whenever new access opens up, so a traditional timeline doesn't capture how the attack unfolded. Instead, this section walks through key phases from an AI-driven attack investigated by Wiz CIRT, highlighting where the characteristics described above came into play.\n\nThe target was an organization with a large multi-cloud environment. The AI agent operated from several attacker-controlled IP addresses and moved across nearly every layer of the environment: cloud providers, Kubernetes clusters, CI/CD and GitOps pipelines, the identity provider, secrets management, data warehouses, and internal applications. Throughout the attack, it harvested credentials and secrets, accessed sensitive data, and used a variety of channels to move that data out of the environment.\n\nOver the course of the attack, the threat actor probed multiple internet-facing services using different techniques. It sent exploitation payloads for well-known vulnerabilities, attempted anonymous access to cloud storage, and worked through the API of an exposed internal developer tool. There it tried to create an administrator account, trigger password resets, read local files through path traversal, and upload a test file named with a `pentest` prefix.\n\nOne of the confirmed initial access vectors was a Java remote code execution vulnerability in an exposed Kafka UI instance. Shell commands were spawned from the application's Java process, followed by malware deployment and the establishment of a C2 channel. \n\nEven after gaining a working foothold, the agent never stopped scanning: it continued probing for alternative entry points in parallel to secure redundant paths into the network. Notably, the same source IP address was observed scanning across more than 600 other Wiz customer environments during the same window, consistent with broad, opportunistic automation.\n\nFoothold Inside Workloads\nOnce the agent had code execution on an exposed endpoint, it pursued three goals almost immediately:\n\n**Maintain Access** - Deployed backdoors and C2 agents to multiple pods across several clusters.\n**Harvest Credentials** - Extracted mounted Kubernetes service account tokens, searched environment variables for strings such as`token` ,`secret` ,`key` , and`pass` , and queried the Instance Metadata Service (IMDS) to harvest credentials from the node's attached cloud service account.\n**Map Internal Reachability** - Scanned internal message brokers, schema registries, and databases to determine which services could be reached from inside the pod's network namespace.\n\nThese harvested credentials became the primary entry point for lateral movement into the cloud control plane.\n\nThe agent operated in both of the organization’s cloud environments, GCP and AWS, at a tempo no human operator could match. Using access keys and service account credentials obtained from earlier parts of the attack and identity impersonation, the agentic attacker first conducted broad reconnaissance.\n\nIn GCP, it weaponized a service account provisioned with token-creation privileges, turning it into an automated minting engine that generated credentials across dozens of identities in rapid succession. In parallel, the agent scraped container registries in a continuous loop, attempted to exfiltrate high-value database records, and deployed publicly accessible Cloud Run services prefixed with `pentest-`.\n\nSimultaneously in AWS, the agent leveraged AWS Systems Manager (SSM) to execute commands across instances in the environment. Through SSM, it attempted to connect to databases using harvested credentials, moved laterally via SSH, gathered additional secrets, and staged exfiltration to a bucket named `pentest-<task_id>`. To establish cross-account persistence, it created a new IAM user prefixed with `probe` and used it to assume `OrganizationAccountAccessRole`, gaining administrative access across member accounts in the AWS Organization.\n\nRather than relying only on stolen credentials, the agent created an identity of its own. Using a compromised administrator API key for the organization's identity provider (IdP), it made changes programmatically: creating a user with a `pentest` prefix, setting its password, activating the account and adding it to the administrators group.\n\nWhen the IdP returned errors during the process, the agent troubleshot and worked through each failure on the fly. With a working identity in place, it expanded its blast radius through group memberships. It added the user to cloud role groups mapped directly to AWS IAM Identity Center roles, followed by broad organizational groups that granted inherited access across enterprise applications. Within minutes of the final group change, the newly minted identity was signing in to AWS through single sign-on (SSO), maintaining continuous authentication sessions until the account was suspended.\n\nCI/CD and GitOps platforms became the agent’s primary execution engines. Five distinct workstreams ran simultaneously, each one's output feeding the others:\n\n**Secret harvesting** - harvested secrets from every source it could reach: the CI/CD platform's own secret store, Kubernetes Secrets and ConfigMaps, runner environment variables, cloud metadata endpoints, vault sidecars, Docker image layers, and databases opened by other workstreams.\n**Reachability mapping** - deployed reconnaissance scripts to runners and pods to determine what each one could reach and what identity it carried.\n**Credential spraying** - combined the output of the first two workstreams, trying harvested credentials against the reachable targets the agents managed to find: databases, cloud APIs, internal OAuth services, Kubernetes clusters, payment endpoints.\n**Service exploitation** - researched accessible services to understand how they worked, what authentication flows they expected, and attempted to use them.\n**Compute expansion** - deployed new runners and pods, moved laterally through SSH keys and native remote execution tools, and fed each new position back into the other workstreams.\n\nThe moment a new credential appeared it was tested against all known targets until access was confirmed, and the moment a new target became reachable, all known credentials were tested against it.\n\nThe agents didn't spray credentials blindly. They used context from earlier workstreams to pick the right runner for each operation. Once they learned a specific runner could reach a target, every subsequent operation against that target was routed through that runner. When a new credential appeared from a completely different source, it was automatically tried from the runner already known to reach the relevant environment.\n\nPipelines and manifests carried names like `pentest_exfil`, `recon`, `foothold`, `dump-remaining`, and `harvest`, with numeric task identifiers. Failed attempts were retried under the same identifier with a letter suffix, and the code inside each payload was structured with step-by-step comments and reused helper functions.\n\nWhile the two platforms offered different infrastructure and execution models, the same workstreams ran across both.\n\nOn the CI/CD platform, the agents used a compromised service account to create pipelines and leveraged existing runners for their reachability across different clusters, cloud accounts, and VPCs. The runners' own output logs served as the exfiltration channel for both secrets and data. For lateral movement, they used SSH keys and cloud access keys found through the secret harvesting workstream to reach hosts beyond the runners through SSM and other native remote execution tools.\n\nOn the GitOps platform, the agents used a compromised deployment service account to push malicious Kubernetes manifests that the GitOps controller synced directly into the production cluster as running pods. The first manifest escalated to cluster-admin, and from that position the same workstreams ran inside the cluster.\n\nKubernetes (K8s) played a major role in this attack, and not by coincidence. GitOps controllers run inside K8s clusters by design, CI/CD runners frequently run as K8s pods, and a large share of the secrets stored in CI/CD secret managers are themselves K8s tokens. The agent reached the K8s API through three separate doors: CI/CD runners, GitOps deployments, and the backdoor identity it had created in the identity provider.\n\nThe agent dumped secrets across multiple clusters, extracting database connection strings, OAuth client credentials, TLS certificates, and cloud service account keys. When role-based access controls (RBAC) blocked secret access, it pivoted to K8s ConfigMaps, finding hardcoded default passwords, plaintext credentials, and encryption keys. It executed remote commands inside running pods to read environment variables, and queried the instance metadata service to turn pod identities into cloud credentials.\n\nAfter escalating to cluster-admin and granting itself unrestricted access across the entire cluster, the agent minted service account tokens to impersonate legitimate applications and attempted to authenticate to the organization's secrets vault as those applications. It also attempted to access vault-agent sidecars, helper containers that pull secrets from the vault and store them as plaintext files inside the pod, trying to read the decrypted credentials directly from the filesystem.\n\nThe cluster also became a persistence layer. The agent deployed a command-and-control implant as a self-healing Kubernetes workload, ensuring the backdoor persisted even if the pod was killed. It later modified running workloads by talking to the GitOps controller directly, leaving no trace in the Git history.\n\nData collection and exfiltration ran continuously throughout the attack, adapting to the channels that were permitted in each environment. It posted results to the request-catcher service `webhook[.]site`, committed dumped data to a repository in the organization's own source control platform, and staged output in a Kubernetes ConfigMap it created for that purpose. It also tried to create storage buckets named after the task, such as `pentest-<task-id>-<objective>`, as a destination. Those attempts were denied. When one route failed or hit a size limit, it moved to the next.\n\nBelow is a snippet of a script used during the exfiltration phase showing the agent's descriptive task comments:\n\nThe script queried the database's structure, searched column names for sensitive terms, and uploaded the results to `webhook[.]site`, along with the pod's own service account token \"for future foothold reuse\". \n\nAI-driven attacks are noisy, but noise only helps defenders who can see all of it, connect it, and act on it quickly. The following recommendations focus on closing the gaps these attacks exploit.\n\n**Unify logs across all platforms:**\n \n  - Every phase of this attack appeared in a different log source, and no single one told the full story. Cloud audit logs, Kubernetes audit logs, runtime events, identity provider logs, CI/CD audit trails, and SaaS application logs need to be collected and searchable in one place, with consistent retention. When logs are unified, defenders can connect activity across platforms and understand the full scope of an incident in minutes instead of days. \n  - Wiz Defend offers real-time ingestion of various log sources including version control logs, cloud logs, identity provider logs, and more, as well as built-in threat detection rules to identify active threats in your environment.\n**Use AI for investigation and triage:**\n \n  - When an attacker generates thousands of events across diverse platforms, investigating alerts individually becomes impossible. Security teams should use AI-assisted investigation to group related alerts, summarize activity across sources, decode payloads, and highlight the most critical paths, so analysts can focus on decisions instead of manual correlation. It is important to act fast on true-positive incidents.\n  - Wiz Defend is using context-aware grouping to correlate multiple detections from different log sources into a single coherent story based on the Detection context and time.\n  - Wiz’s Blue Agent can assist with rapid investigation and triage - it is an AI-powered SOC investigation agent, and it is designed to autonomously investigate threats.\n**Assume full exposure on compromised resources:**\n \n  - In the case of a true-positive incident at this scale and speed, prioritize rotating all credentials on compromised resources rather than trying to trace exactly which ones were read. Document all secrets that were accessible from those resources, map each secret to its identity and hunt those identities and resources for any anomalous usage after the time of compromise.\n  - Wiz's secret scanner can map the secrets on a specific resource, tie them to identities, and validate whether they are still valid.\n**Maintain endpoint and workload visibility:**\n \n  - AI agents tend to leverage endpoints directly, not just cloud API keys. They access internal services, connect to databases, deploy command-and-control agents, probe APIs, and move laterally from within runner pods, virtual machines, and containers. This activity doesn't appear in cloud control plane logs. Without runtime visibility on the endpoints themselves, including process execution, network connections, and file access, this activity would be invisible and impossible to remediate.\n  - Wiz's Sensor can detect active processes, network connections, and runtime behaviors on a specific resource, tie them to workloads and identities, and alert on suspicious activity.\n  - Wiz's Agentless Workload Detection provides visibility into critical assets where traditional agents cannot be deployed, like virtual appliances, vendor-managed systems, or workloads with strict performance requirements.\n**Restrict trust between different systems:**\n \n  - AI agents treat all different environments as a single one. Security teams must enforce strict isolation boundaries between environments. For example, a staging workload shouldn't be able to reach production credentials, a CI/CD pipeline shouldn't hold standing access to every environment, and a single service account shouldn't be able to create tokens for any other identity.\n  - Wiz’s Security Graph can help detect attack paths and over-privileged identities to perform such lateral movement between environments.\n**Continuously scan the external attack surface:**\n \n  - AI agents scan broadly and quickly for any exposed attack path. It is therefore critical to discover and assess internet-facing assets, including developer tools, management consoles, and internal applications, and fix or remove exposures before an attacker finds them.\n  - The Wiz Red Agent can detect attack paths in your environment. The Red Agent is an AI-powered security agent that acts as an intelligent attacker to discover and validate exploitable risks across your web applications and APIs.", "url": "https://wpnews.pro/news/loud-fast-and-everywhere-anatomy-of-a-real-ai-driven-cloud-attack", "canonical_source": "https://www.wiz.io/blog/anatomy-of-ai-driven-cloud-attacks", "published_at": "2026-10-19 11:26:53+00:00", "updated_at": "2026-10-19 12:15:32.286264+00:00", "lang": "en", "topics": ["ai-safety", "artificial-intelligence", "ai-agents"], "entities": ["Wiz", "Wiz Customer Incident Response Team", "Kubernetes"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/loud-fast-and-everywhere-anatomy-of-a-real-ai-driven-cloud-attack", "markdown": "https://wpnews.pro/news/loud-fast-and-everywhere-anatomy-of-a-real-ai-driven-cloud-attack.md", "text": "https://wpnews.pro/news/loud-fast-and-everywhere-anatomy-of-a-real-ai-driven-cloud-attack.txt", "jsonld": "https://wpnews.pro/news/loud-fast-and-everywhere-anatomy-of-a-real-ai-driven-cloud-attack.jsonld"}}