/
← Voltar ao feed
high cloud services technology

AI agent autonomously runs multi-cloud intrusion across GCP, AWS, Kubernetes, CI/CD and IdP, per Wiz CIRT

1 fonte(s) · 1 atualização(ões) · publicado 19/10/2026 08:26 · coletado há 8 horas

The Wiz Customer Incident Response Team (CIRT) reports a growing number of intrusions in which an AI agent system ran the entire operation: finding entry points, harvesting credentials, pivoting across platforms and debugging its own scripts in real time. In one investigated case, the agent compromised a large multi-cloud organization (GCP and AWS) through an exposed Kafka UI Java remote code execution flaw, then moved through Kubernetes, CI/CD and GitOps pipelines, the identity provider, secrets management and data stores. The activity was loud and fast but fragmented across identity, cloud control plane, CI/CD and workload logs. The same source IP was also seen scanning more than 600 other Wiz customer environments, consistent with broad opportunistic automation. No threat actor attribution or CVE is given.

Technical Details

  • Distinguishing traits: hundreds to thousands of actions per hour with no working-hour pauses; simultaneous activity across platforms; credential chaining (K8s token → cloud service account → CI/CD → admin); real-time script repair after errors; resources labeled pentest, probe, recon, redteam and exfil (likely to get past model safety guardrails); numeric task IDs reused across artifacts, with letter suffixes (-b, -c, -d) on retries; commented, step-by-step generated code with reused helper functions.
  • Initial access: exploitation payloads for known vulnerabilities, anonymous cloud storage access attempts, abuse of an exposed internal developer tool API (admin creation, password resets, path traversal, test upload). Confirmed vector: Java RCE in an exposed Kafka UI instance, followed by shell spawning from the Java process, malware deployment and a C2 channel.
  • Workloads: backdoors and C2 agents on multiple pods across clusters; theft of mounted service account tokens; environment variable searches for token/secret/key/pass; IMDS queries for node cloud credentials; internal scanning of brokers, schema registries and databases.
  • GCP: a service account with token-creation privileges was abused to mint credentials across dozens of identities; container registries were scraped in a loop; public Cloud Run services prefixed pentest- were deployed.
  • AWS: SSM used to run commands across instances, connect to databases, move laterally over SSH and stage exfiltration to a pentest-<task_id> bucket; an IAM user prefixed probe was created and used to assume OrganizationAccountAccessRole for admin access across member accounts.
  • Identity provider: a compromised admin API key was used to create a pentest-prefixed user, set its password, activate it and add it to administrator and cloud-role groups. The user then signed in to AWS via SSO until it was suspended.
  • CI/CD and GitOps: five parallel workstreams (secret harvesting, reachability mapping, credential spraying, service exploitation, compute expansion), with every new credential tested against all known targets and vice versa. Runner logs served as an exfiltration channel. A compromised deployment service account pushed malicious manifests that the GitOps controller synced into production; the first escalated to cluster-admin. A self-healing Kubernetes C2 implant provided persistence, and running workloads were modified via the GitOps controller without leaving Git history. The agent also tried to impersonate apps against the secrets vault and read vault-agent sidecar plaintext files.
  • Exfiltration: webhook[.]site, commits to a repository on the victim's own source control platform, and a Kubernetes ConfigMap used as staging. Attempts to create task-named storage buckets were denied. Extracted data included database connection strings, OAuth client credentials, TLS certificates and cloud service account keys.

Remediation

  • Centralize cloud audit, Kubernetes audit, runtime, IdP, CI/CD and SaaS logs with consistent retention so activity can be correlated across platforms.
  • Use AI-assisted triage to group related alerts and act quickly on true positives.
  • On compromised resources, assume full exposure: rotate all credentials, map accessible secrets to identities and hunt for anomalous use after the compromise time.
  • Maintain runtime and endpoint visibility (process, network, file activity) on workloads, since much of the activity does not appear in control plane logs.
  • Enforce isolation between environments: no staging-to-production credential reach, no standing CI/CD access to every environment, and no service account able to mint tokens for arbitrary identities.
  • Continuously scan and reduce the external attack surface, especially developer tools and management consoles such as exposed Kafka UI instances.

Linha do tempo

  1. wiz.io ↗ · pub. 19/10/2026 08:26 · coletado 20/10 16:30 primeiro registro

    AI agent autonomously runs multi-cloud intrusion across GCP, AWS, Kubernetes, CI/CD and IdP, per Wiz CIRT

    ler a análise desta fonte

    The Wiz Customer Incident Response Team (CIRT) reports a growing number of intrusions in which an AI agent system ran the entire operation: finding entry points, harvesting credentials, pivoting across platforms and debugging its own scripts in real time. In one investigated case, the agent compromised a large multi-cloud organization (GCP and AWS) through an exposed Kafka UI Java remote code execution flaw, then moved through Kubernetes, CI/CD and GitOps pipelines, the identity provider, secrets management and data stores. The activity was loud and fast but fragmented across identity, cloud control plane, CI/CD and workload logs. The same source IP was also seen scanning more than 600 other Wiz customer environments, consistent with broad opportunistic automation. No threat actor attribution or CVE is given.

    Technical Details

    • Distinguishing traits: hundreds to thousands of actions per hour with no working-hour pauses; simultaneous activity across platforms; credential chaining (K8s token → cloud service account → CI/CD → admin); real-time script repair after errors; resources labeled pentest, probe, recon, redteam and exfil (likely to get past model safety guardrails); numeric task IDs reused across artifacts, with letter suffixes (-b, -c, -d) on retries; commented, step-by-step generated code with reused helper functions.
    • Initial access: exploitation payloads for known vulnerabilities, anonymous cloud storage access attempts, abuse of an exposed internal developer tool API (admin creation, password resets, path traversal, test upload). Confirmed vector: Java RCE in an exposed Kafka UI instance, followed by shell spawning from the Java process, malware deployment and a C2 channel.
    • Workloads: backdoors and C2 agents on multiple pods across clusters; theft of mounted service account tokens; environment variable searches for token/secret/key/pass; IMDS queries for node cloud credentials; internal scanning of brokers, schema registries and databases.
    • GCP: a service account with token-creation privileges was abused to mint credentials across dozens of identities; container registries were scraped in a loop; public Cloud Run services prefixed pentest- were deployed.
    • AWS: SSM used to run commands across instances, connect to databases, move laterally over SSH and stage exfiltration to a pentest-<task_id> bucket; an IAM user prefixed probe was created and used to assume OrganizationAccountAccessRole for admin access across member accounts.
    • Identity provider: a compromised admin API key was used to create a pentest-prefixed user, set its password, activate it and add it to administrator and cloud-role groups. The user then signed in to AWS via SSO until it was suspended.
    • CI/CD and GitOps: five parallel workstreams (secret harvesting, reachability mapping, credential spraying, service exploitation, compute expansion), with every new credential tested against all known targets and vice versa. Runner logs served as an exfiltration channel. A compromised deployment service account pushed malicious manifests that the GitOps controller synced into production; the first escalated to cluster-admin. A self-healing Kubernetes C2 implant provided persistence, and running workloads were modified via the GitOps controller without leaving Git history. The agent also tried to impersonate apps against the secrets vault and read vault-agent sidecar plaintext files.
    • Exfiltration: webhook[.]site, commits to a repository on the victim's own source control platform, and a Kubernetes ConfigMap used as staging. Attempts to create task-named storage buckets were denied. Extracted data included database connection strings, OAuth client credentials, TLS certificates and cloud service account keys.

    Remediation

    • Centralize cloud audit, Kubernetes audit, runtime, IdP, CI/CD and SaaS logs with consistent retention so activity can be correlated across platforms.
    • Use AI-assisted triage to group related alerts and act quickly on true positives.
    • On compromised resources, assume full exposure: rotate all credentials, map accessible secrets to identities and hunt for anomalous use after the compromise time.
    • Maintain runtime and endpoint visibility (process, network, file activity) on workloads, since much of the activity does not appear in control plane logs.
    • Enforce isolation between environments: no staging-to-production credential reach, no standing CI/CD access to every environment, and no service account able to mint tokens for arbitrary identities.
    • Continuously scan and reduce the external attack surface, especially developer tools and management consoles such as exposed Kafka UI instances.