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.

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 (, ). Separately, 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.

Hermes - Thailand’s Ministry of Finance: 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.

AI-assisted API exploitation - Organizations in Japan and abroad. 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.

Custom agentic workflows - Multiple sectors and countries: 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 , 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.

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 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 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).

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 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 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):

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):

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 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):

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 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 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:

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 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 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.

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.

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