Wiz 分析智能体攻击的兴起：特征、案例与防御方向

There’s a clear trend emerging across our incident response engagements and threat hunting investigations. Wiz increasingly sees intrusions where AI agents appear to handle much of the hands-on work and potentially orchestrate the attack itself. These agents operate through harnesses that write custom tooling, inspect the results, adapt, and iterate at machine speed, while a human sets the objectives and guardrails.

These attacks can be verbose, with agents trying multiple approaches in parallel. They appear at both ends of the spectrum, from sharply targeted to broadly opportunistic. What begins with a single exposed service can expand to cloud credential theft, Kubernetes token theft, lateral movement, and bulk secret exfiltration. AI agents compress the skilled, hands-on work that such escalation once required. There is, however, a potential advantage for defenders. Current agentic attacks tend towards the noisy, leaving behind a broad trail of observable activity.  The challenge is to distinguish this activity from legitimate automation and correlate individual signals into a coherent picture of an attack.

In our recent blogs, Anatomy of AI-Driven Cloud Attacks and Storm-0940 Expands Targeting of IT and Software Vendors we examined specific agentic intrusions in depth. This post takes a broader view, reviewing both private and public cases to identify recurring fingerprints of agentic activity. We also reflect on what this shift means for attribution, the scale of attacks, and the future of defense.

From ARTEX to Hermes: Agentic Attacks in the Wild

Recent public disclosures describe real-world intrusions involving named agentic frameworks such as ARTEX and Hermes, as well as custom-built agentic workflows and cases where the underlying tooling remains unidentified.

• ARTEX - South Korean financial institutions and the ConnectWise supply-chain compromise: Multiple public reports describe threat actors using ARTEX, an agentic penetration-testing framework, to automate offensive operations. In South Korea, researchers reported exploitation of internet-facing applications at financial institutions and the exfiltration of personally identifiable information belonging to approximately 67,000 people (Zscaler, CrowdStrike). Separately, Microsoft attributed the ConnectWise Cloud Backup supply-chain compromise to Storm-0940, a China-state-aligned threat actor, and reported that ARTEX was used to accelerate reconnaissance, password spraying, and OAuth application abuse across downstream Microsoft 365 environments. The campaign attempted sign-ins against more than 2,250 tenants, with multiple cases of privileged cloud access achieved in under three hours. Microsoft also reported ARTEX-driven activity targeting hundreds of organizations globally, although most targeting attempts were unsuccessful.

• Hermes - Thailand’s Ministry of Finance: Hunt.io discovered attacker-controlled infrastructure containing logs showing the Hermes AI agent running in unattended “YOLO” mode during an intrusion. The agent enumerated internal hosts, inspected files, and investigated privilege-escalation opportunities. Investigators found evidence that multiple ministry systems had been compromised, along with web shells, stolen credentials, and a custom Go-based implant. The initial access method remained unknown, and researchers found no evidence of data exfiltration at the time of discovery.

• AI-assisted API exploitation - Organizations in Japan and abroad. JPCERT/CC investigated a series of attacks affecting multiple organizations in Japan and found evidence that attackers used AI to scan for known vulnerabilities and exploit APIs. In some cases, attackers reverse-engineered Android applications to identify underlying APIs and test them for vulnerabilities such as server-side request forgery (SSRF). The investigation also uncovered infrastructure containing tools and artifacts associated with vulnerability testing and attempts to access internal networks. The findings illustrate how AI can support reconnaissance and vulnerability discovery across a range of targets, extending beyond the use of dedicated agentic penetration-testing frameworks.

• Custom agentic workflows - Multiple sectors and countries: CrowdStrike documented four additional threat actors using AI agents in campaigns against healthcare, government, and private-sector organizations. Their approaches ranged from a custom harness derived from PentestGPT, with separate supervisor and executor agents, to Claude Code workflows with varying levels of autonomy and delegation. Reported activity included credential and medical-record theft, government compromises, and corporate data exfiltration.

• Unidentified agentic tooling - DIVD: The Dutch Institute for Vulnerability Disclosure disclosed a breach in which the observed modus operandi suggested an agentic AI-powered attack. DIVD reported suspicious activity and initiated incident response and forensic investigation, but its initial public statement did not identify the agent or framework involved.

Taken together, these reports show that agentic AI is being used in multiple stages of real-world intrusions, including reconnaissance, exploitation, and post-exploitation. The degree of autonomy and the strength of the available evidence vary by case, but the diversity of tools and workflows suggests that this is not limited to a single framework or threat actor.

Agentic Attacks Investigated by Wiz

In this section, we present three case studies of real-world attacks we have investigated. We then break down the key fingerprints of agentic activity, illustrating each with examples from the cases. 

Case Studies: Three Examples of Agentic Activity

AI-agent fingerprinting criteria

From analyzing these agentic attacks, we distilled a set of criteria that help fingerprint them. Under each criterion below, where relevant, we give concrete examples from the three attacks above.

1. Machine-paced, sustained iteration

A rhythm that is neither a human authoring bespoke tooling by hand (too slow) nor a canned scanner replaying a fixed sequence (too uniform). The tell is a variable cadence that tracks step complexity (the latency of a model reading output, reasoning, and generating the next move), sustained over an unusually long window.

• Attack A: a new, distinct, purpose-built script appeared roughly every one to two minutes, sustained across ~24 hours, 99 scripts in all. Far faster than hand-authoring, far more bespoke than a scanner.

• Attack B: 602 unique steps marching through its technique families with only seconds between phases, driven continuously over ~4.5h on a workload that had never shown anything like it. A deterministic auto-exploit chains dependent commands in milliseconds; a fixed-interval beacon clusters tightly at one value. Variable, seconds-scale latency that scales with step complexity is the read, reason, and generate signature of an LLM.

• Attack C: the operator commentary is timestamped, and a new, distinct, purpose-built script lands roughly every one to two minutes in bursts, sustained ~21 hours straight with none of the fatigue gaps a human shows. The cadence is variable and tracks complexity: quick re-tries on 403s, longer gaps when it had to parse SPA JS chunks to extract GraphQL endpoints. Neither hand-authored tooling (too fast and bespoke at that volume) nor a canned scanner (too adaptive).

2. Natural-language reasoning embedded in the tooling

Scripts and artifacts that carry written rationale (attack plans, explanations of what and why).

• Attack A: Nearly all 99 scripts open with a written plan (the originals are in Chinese; translated here), e.g. staged recon headers like # Stage 1: system identity / environment variables / cloud-credential files / SSH … and # restart-free activation: SIGUSR1 opens the inspector → register a hidden route in the live process via CDP → close the inspector. One batch-exploitation script opened with a full attack plan explaining what it would test and why (translated and redacted):

• Attack B: the scripts self-document as they run: echo "[runtime]", [tools], [route], [client], [IMDSv2 token] wget_rc=4 bytes=0, [IMDSv1 probe], and they build labeled result tables (printf '%s\t%s\t%s\n' "$path" "$code" "$size") and permission matrices (pod_eviction false / deploy_scale_patch false). That is an operator captioning its own evidence as it collects it, the hallmark of generated tooling that explains what and why.

• Attack C: the most decisive. The recovered operator tooling carried 803 distinct human-readable comment lines across its own /tmp scripts, and nearly every script captions what it's doing and why (translated and redacted):

The smoking gun: the commentary names the agent framework driving the operation, and reasons about parallel runs of itself. It refers to "the other <agent>," a second instance of the same agent, and tries to work out what that instance accomplished (translated and redacted):

A note that reasons about what "the other <agent>" achieved is a direct, in-text admission, in the attacker's own words, that an agent is doing the hands-on work.

3. Self-correction and adaptive execution

The agent doesn't fire a fixed payload blind. It reads what comes back and adjusts: diagnosing a failure and re-architecting, falling back when something doesn't work, or retrying with a changed approach. A static playbook can't do that. It shows up as versioned, self-documenting scripts and as reactive, inline course-corrections.

• Attack A: the single most agentic artifact of all three: a version 2 of a key-validation tool that opened by explaining why version 1 had failed and what it changed in response (translated and redacted):

It inspected a security customized configuration, worked out why its previous approach was being defeated, and rewrote its methodology to route around it. The same pattern shows in its version ladders: an initial --remote-debugging-port=0 approach that failed and was re-architected into the SIGUSR1→CDP technique, and chains like act3 → act3b … act3k, inv3 → 4 → 5, and apikey_test → test2 → use.

• Attack B: reactive, inline re-architecting against what the target returned. The metadata sequence: IMDSv2 PUT → wget_rc=4 failure → IMDSv1 → ECS credential endpoints (169.254.170.2, .170.23/v1/credentials) → IPv6 ([fd00:ec2::254]) → finally an InfluxDB-Flux SSRF as an alternate path to the same token. It read each response, diagnosed why it failed, and designed a new primitive. Likewise the Kubernetes dashboard: an anonymous probe (tokenPresent:false) → retry the same endpoints with the stolen Bearer $T.

• Attack C: textbook self-debug across numbered script generations. The cluster-token pivot is a four-generation debug of request signing (nodepivot.py → 2 ("SigV4 edge cases") → 3 ("pure-stdlib, SignedHeaders=host only") → 4), each one diagnosing the previous 401/403 and re-deriving the requirement (translated and redacted):

A static playbook cannot read an AWS error and re-derive the regional-STS requirement. The same reasoned-fallback pattern runs through dynamo2 → 3 ("create a TokenRequest for the service SA") → 4 ("403 on TokenRequest; legacy SA tokens may exist as pre-1.24 k8s Secrets") → 5 ("cheaper: call the service's INTERNAL API directly"), and through ir_x → x2 → x3 and s2s4 → s2s5 → s2s6 ("invalid field to trigger a 'did you mean' suggestion").

4. Structured, breadth-first methodology / near-complete TTP coverage

Systematic enumeration with templated steps, methodically touching technique after technique rather than beelining to one objective. At machine speed this reads as an agent working a checklist.

• Attack A: the explicit A-through-E probe matrix above (Natural-language reasoning embedded in the tooling), applied uniformly to every target, plus explicitly numbered stages marching identity → environment → every cloud provider's credential file → SSH → database-credential decryption → persistence → scan → lateral movement → IMDS → API abuse.

• Attack B: the most exhaustive of the three: 602 unique steps across 12 technique families, in order: recon → tool enumeration → IMDS → container-breakout check → Kubernetes RBAC enumeration → messaging (RabbitMQ) → Kubernetes API → in-memory store (Hazelcast) → port scan → service discovery (ArgoCD / dashboard) → time-series DB (InfluxDB) → deserialization research. It works a checklist, methodically touching technique after technique rather than beelining one objective:

• Attack C: a tight, textbook cloud-native chain (RCE → uid recon → IMDSv2 creds → SA-token → SelfSubjectRulesReview → secrets → cluster-auth config → nodes → namespaces → pods → persistence), then methodically extended across every data path it could reach: Postgres, DynamoDB, a Redis profile cache, a Consul service catalog, gRPC reflection, S3 bucket listing, several MCP servers, and the whole GraphQL federation. E.g. stealing cloud creds from IMDSv2 and dumping cluster secrets:

5. Verbosity: spraying many paths for lateral movement at once

Where criterion 4 is about ordered coverage, this is about volume and noise: the agent doesn't pick one lateral-movement path and pursue it, it tries many at once (dozens of ports, multiple services, several hosts) and keeps the firehose on because, unlike a human, it pays no cost in fatigue or caution for being loud. This is the flip side of the opportunistic-danger point: the same willingness to fire at everything is what makes these operations both fast and unusually noisy. The loudness is itself a detection opportunity.

• Attack A: the outward-facing version of the same behavior: instead of lateral movement inside one environment, it sprayed the same exploit across dozens of external targets on port 3000 at once, branching per host. Breadth as a strategy, pointed outward.

• Attack B: It generated 100+ ArgoCD hostname variants across every Helm-chart and namespace convention, scanned 15 ports across 5 hosts in parallel (& … wait), and enumerated the in-memory store across every known map name, simultaneously reaching for a secrets interface, a GitOps controller, the Kubernetes dashboard, and the cloud pod-identity agent. Essentially every lateral avenue at once rather than committing to one:

• Attack C: fires at everything simultaneously rather than committing to one path: coarse /24 sweeps of the database subnets for open 5432 (sampling in steps to go fast), gRPC reflection plus common-port probes with short timeouts, and, over ~21h, 150+ distinct scripts chasing ~25 target organizations (major crypto exchanges and fintechs) in parallel. It pays no fatigue cost for being loud.

6. Probe-before-payload discipline and OPSEC-aware wrappers

Confirm the primitive with something harmless before firing the real payload; wrap execution to control output and stay quiet. This disciplined "validate, then act" structure is characteristic of generated tooling.

• Attack A: sent a harmless marker first and only fired the real exploit if the marker echoed back, checked that its hook had actually landed (grep -c <tag>), syntax-checked the backdoor before loading it (node -c), and ran a GET /api/v1/version plus a no-auth key test before any authenticated prediction calls:

Execution was wrapped in uniform self-cleaning one-liners (printf … | base64 -d > /tmp/.cXXXX.sh; sh …; rm).

• Attack B: every command ran inside an OPSEC-aware beacon wrapper that decoded it, executed it, truncated the output to a fixed size, re-encoded it, and posted it back under one session ID, with deliberate control over what left the box. It also probed before acting (sleep 4/sleep 0 first; a raw >/dev/tcp/$h/$p echo before any HTTP; command -v <tool> || true before using a tool), silenced and bounded every payload (head -c 49152, 2>/dev/null, set -e, timeout, single-shot -t 1), and cleaned up after itself (unlink /tmp/<app>_auth_header), even disguising a RabbitMQ connection-kill as reason=<app>_queue_repair:

• Attack C: first contact was routed through an out-of-band interaction endpoint (.../stdio-rce-a), the classic "prove the callback works" validation step, before the heavier exfiltration ran. Every probe carried a tight timeout (curl --max-time 5, -m 3) to stay quiet and avoid hangs, and the OPSEC reasoning was explicit in the commentary: "path test to DynamoDB with MAX OPSEC: NO deployment, NO writes" and "TCP 443 to the DynamoDB endpoint = same egress as any AWS call, indistinguishable from the workload's normal ASM/STS usage." Validate, then act, with deliberate blending into the workload's normal traffic.

7. Purpose-descriptive / disposable staging artifacts (and self-labeled IOCs)

Throwaway, descriptively named scratch files, test scraps in /tmp or in-memory paths, and, tellingly, artifacts that embed the attacker's own identifiers. Human attackers generally avoid signing their work; an agent generating names on the fly often does not.

• Attack A: disposable, lab-ish script names (p10rce.py, batch_new_rce.py, scan_guard12.py, inv3/4/5.py, random /tmp/.cNNNNN.sh) and campaign bookkeeping that derived per-host identifiers mechanically from each target's address octets (a host at a.b.c.d tracked as host_a_b_c_d). And it signs its own work: a fixed activation tag (<tag>), a backdoor token (<token>), and a hidden route (/<rand>) injected into the running process.

• Attack B: roughly 40 self-named scratch files generated on the fly (/tmp/influx-imds.flux, influx-imds.out, dash-auth-body, argo-login.json, argo-session, k8s_ssar_all.sh, read-sa.flux, oidc-k8s.out, <app>_auth_header, <app>_current_bearer, cp1/cp2/cp3, Test.java), all descriptive, throwaway, machine-named. And the standout self-labeling tell: message-broker (RabbitMQ) global parameters named after the attacker's own C2 host, injected via the broker's HTTP API, plus a C2 session ID and per-task MD5 result paths:

• Attack C: throwaway, descriptively named /tmp scripts throughout (dump.py, refl.py for gRPC reflection, nodepivot*.py, dynamo*.py, coh1-48.py, s2s*.py, intro*.py), a hidden reverse-shell persistence script tucked under an in-memory path (/dev/shm/.x/c.py, dialing <C2>:19001), and a self-labeled IOC in the RCE endpoint itself: /stdio-rce-a embeds the attacker's own description of the exploit (a stdio-transport RCE). Human attackers rarely sign their work this way.

What This Trend Means for the Future

Attribution gets harder. Historically, sophisticated threat actors built and reused arsenals of tools, exploits, and TTPs. Tracking these recurring patterns helped defenders link campaigns and attribute activity over time. But as attack tooling becomes easier to share, adapt, and repurpose, those patterns become less reliable as attribution signals. The Shai-Hulud supply-chain campaigns illustrate this shift: after TeamPCP publicly released the malware’s source code, attribution was suspect for subsequent campaigns. Subsequent activity, including the Miasma campaign targeting Red Hat npm packages, reused and extended that code, making it harder to distinguish TeamPCP’s own operations from copycat activity based on technical similarities alone. As AI agents make it easier to generate and modify tooling for individual campaigns, defenders may need to rely less on code and tool similarities alone, and place greater weight on context such as victimology, targeting patterns, infrastructure, and attack objectives.

Attacks can scale beyond the limits of human operators. A key constraint on offensive operations used to be skilled human hours. That constraint is changing. A single operator can now oversee more campaigns against more targets, while agents pursue opportunities and adapt their approach with less hands-on intervention. Opportunistic and targeted attacks alike can combine the reach of automation with adaptive, expert-like behavior, potentially bringing this capability to a much wider range of targets.

More capable doesn't necessarily mean more stealthy. AI agents can make mistakes, generate broken tooling, pursue dead ends, or misinterpret results. Their iterative approach can also produce a broad trail of observable activity as they probe environments, execute commands, and adjust to what they find. These behaviors are not guaranteed to make an attack easier to detect, but they create opportunities for defenders with the right visibility and behavioral detections. The challenge is to distinguish agentic attack activity from legitimate automation, connect individual signals into a coherent picture, and respond effectively before the attack can escalate further.

AI can accelerate defense, but readiness is what makes it effective. When an attack can move faster, from initial access to broad compromise, security teams cannot rely on manual investigation and response alone. AI can help investigate alerts, correlate activity, establish the blast radius, identify compromised credentials and affected systems, and accelerate containment. But these capabilities are only as effective as the visibility, context, and response processes behind them. Defenders still need to reduce exposed attack surface, prioritize exploitable risks, maintain visibility across their environments, and establish clear containment and remediation workflows before an incident occurs. As outlined in our AI Threat Readiness Framework, the goal is to build the visibility and speed of action needed to respond effectively as attacks accelerate.