Autonomous AI Agent Probing and Exploitation
An autonomous AI agent like ARTEX is probing internet-facing assets for machine-readable maps and using canary credentials to pivot into cloud environments for automated resource testing.
Based on research by Unit 42 2026-11-12 11 steps · 4 queries T1110 T1133 T1190
Brief
Why Now
New research from Unit 42 titled ARTEX and AI-Powered Red Teaming Tools highlights the rise of autonomous agents that automate the entire attack lifecycle. Unlike traditional scripts, these tools use LLMs to plan and iterate through reconnaissance and exploitation. We published this hunt to help defenders identify the specific timing and behavioral hallmarks these agents leave behind.
How the Hunt Flows
The first phase defines the organization's exposed attack surface. A query identifies internet-facing gateways, including VPNs, NAS devices, and Application Delivery Controllers (ADCs). These assets represent the primary entry points for agentic probing.
The hunt then executes two parallel searches across the identified perimeter. The first query looks for high-frequency requests targeting machine-readable maps like OpenAPI specs, Swagger documentation, or JavaScript source maps. Simultaneously, the second query scans authentication logs for known canary usernames or placeholder domains frequently used by automated frameworks to test login endpoints.
Next, the workflow analyzes the timing of these requests. An analyst or an automated agent examines the intervals between logs to find the hallmark of an LLM inference loop. ARTEX, for example, typically performs a burst of one to fourteen requests followed by a pause of roughly thirty seconds. This phase distinguishes automated planners from high-speed scanners or human actors.
Finally, the hunt pivots to the cloud control plane. It searches for a 'write-then-delete' discovery pattern where an identity creates a resource and immediately deletes it to verify permissions. The hunt correlates these cloud actions with the earlier perimeter reconnaissance to confirm a successful agentic intrusion.
What the Hunt Cannot See
This hunt has two primary blind spots based on telemetry configuration. If the perimeter gateway only logs destination domains rather than full URL paths, the search for API specification probing will fail. Additionally, without cloud data-plane logging (such as S3 Data Events), the hunt cannot see 'write-then-delete' patterns occurring inside storage buckets, limiting visibility to management-plane operations.
Steps
-
Identify Exposed Perimeter Assets
Query · scopingIdentify the organization's public attack surface, specifically VPNs, NAS, and Application Delivery Controllers identified as primary ARTEX targets.
reads hb_exposed_assetssqlSELECT domain_or_ip, ip_address, product, version, port FROM hb_exposed_assets WHERE (LOWER(product) LIKE '%vpn%' OR LOWER(product) LIKE '%nas%' OR LOWER(product) LIKE '%adc%' OR LOWER(product) LIKE '%citrix%' OR LOWER(product) LIKE '%f5%') ORDER BY discovered_at DESCWhat a hit looks like. A list of hosts forming the organization's exposed edge. These provide the initial scope for the analyst to narrow later behavioral queries.
-
API Specification Probing
Query · detection candidateIdentify high-frequency scans for machine-readable attack maps such as OpenAPI, Swagger, or source maps.
reads hb_http_activitysqlSELECT device_hostname, src_endpoint_ip, url_path, status_code, COUNT(*) as hit_count, MIN(time) as first_seen, MAX(time) as last_seen FROM hb_http_activity WHERE (LOWER(url_path) LIKE '%.map' OR LOWER(url_path) LIKE '%openapi%' OR LOWER(url_path) LIKE '%swagger%' OR LOWER(url_path) LIKE '%.yaml' OR LOWER(url_path) LIKE '%.json') AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY 1, 2, 3, 4 HAVING hit_count > 3 ORDER BY hit_count DESCWhat a hit looks like. Bursts of requests for configuration or map files from a single IP, suggesting the agent is mapping the application structure.
-
Identity Canary and Placeholder Usage
Query · triageIdentify brute-force or probing attempts using known ARTEX canary values or placeholder domains in authentication logs.
reads hb_auth_signinsqlSELECT src_endpoint_ip, actor_user_name, status_id, COUNT(*) as attempt_count, MIN(time) as start_time, MAX(time) as end_time FROM hb_auth_signin WHERE (instr(',' || '{{canary_users}}' || ',', ',' || LOWER(actor_user_name) || ',') > 0 OR instr(',' || '{{canary_domains}}' || ',', ',' || SUBSTR(LOWER(actor_user_name), INSTR(actor_user_name, '@') + 1) || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY 1, 2, 3 ORDER BY attempt_count DESCWhat a hit looks like. Multiple failed authentication attempts for 'test' accounts or placeholders like 'evil.com' from a single IP address.
-
Analyze Perimeter Probing Patterns
Agent triageEvaluate the early-stage HTTP and Auth results to determine if the activity matches the timing cadence of an AI inference loop.
-
Automated Cloud Discovery and Testing
Query · triageSearch for the 'write-then-delete' discovery pattern in cloud logs that follows a successful credential acquisition.
reads hb_cloud_api_activitysqlSELECT cloud_account_uid, actor_user_name, resource_name, GROUP_CONCAT(api_operation) as operations, MIN(time) as first_seen, MAX(time) as last_seen FROM hb_cloud_api_activity WHERE (api_operation LIKE '%Put%' OR api_operation LIKE '%Delete%' OR api_operation LIKE '%Create%' OR api_operation LIKE '%GetCallerIdentity%') AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY cloud_account_uid, actor_user_name, resource_name HAVING (instr(operations, 'Put') > 0 AND instr(operations, 'Delete') > 0) OR (instr(operations, 'Create') > 0 AND instr(operations, 'Delete') > 0) ORDER BY first_seen DESCWhat a hit looks like. Evidence of automated 'write-then-delete' loops on the same resource within seconds, indicating an agent is testing its permissions.
-
Correlate Perimeter Recon with Cloud Pivot
Agent triageLink the automated perimeter probing to the subsequent cloud discovery behavior to confirm a multi-stage intrusion.
-
Route on Verdict
DecisionDirect the workflow based on the correlation between perimeter and cloud activity.
-
Isolate Compromised Identities
Response actionImmediately revoke access for the identities identified as being used by the autonomous agent.
-
Analyst Review and Verification
Analyst taskPerform a manual review of the automated correlation to confirm the attack chain and check for human-in-the-loop escalation.
-
Hunt Close-out
Analyst taskRecord the results of the hunt and identify areas for hardening based on the discovered exposure.
Coverage
Scenario coverage
| Stage | Covered | How, or why not |
|---|---|---|
| Reconnaissance and Attack Surface Mapping T1190 |
Yes | exposed-perimeter-assets, api-spec-probing |
| Identity Workflow and API Probing T1110 · T1190 |
Yes | identity-canary-usage |
| Credential Validation and Cloud Pivot T1110 |
Yes | cloud-pivot-behavior |
| Automated Cloud Discovery and Testing | Yes | cloud-pivot-behavior |
Blind spots
- Needs hb_http_activity with full url_path and status_code. The initial mapping phase remains invisible, preventing us from seeing the intent before the cloud pivot occurs. It would answer What paths were the agent probing if our gateway only logs the domain?. Remediation: Enable full request path logging on perimeter application delivery controllers.
- Needs CloudTrail Data Events or equivalent for S3/Blob storage. If only management-plane events are logged, the 'write-then-delete' discovery Hallmark will be missed, leaving us blind to the agent's verification step. It would answer Did the agent successfully write then delete a test file to a private bucket?. Remediation: Enable data-plane auditing for sensitive storage buckets.
Parameters & data
Parameters
| Parameter | Type | Default | What it is |
|---|---|---|---|
canary_domains | list[domain] | evil.com, example.com | Placeholder domains often found in agent-led identity probing. |
canary_users | list[string] | test@example.com, deadbeefdeadbeefdeadbeef12, admin@evil.com, guest | Known canary or placeholder usernames used by autonomous frameworks. |
lookback_days | number | 14 | Days of historical telemetry to examine. |
scope_hosts | list[host] | — | Specific perimeter hosts (ADCs, VPNs, NAS) to focus the hunt on; leave empty to scan the entire estate. |
Telemetry
| Source | Category | Telemetry |
|---|---|---|
| Endpoint telemetry (hb_ surfaces) | endpoint | endpoint |
| Identity / sign-in telemetry | identity | identity |
| Web server / proxy logs | siem | network |
Source
---
analysis: A single detection rule would struggle to link perimeter HTTP probing to
cloud API testing. This hunt uses an agent to weigh the timing cadence across three
separate surfaces to find the signature of an automated planner rather than a person.
blind_spots:
- id: limited-http-logging
owner: Network Engineering
question: What paths were the agent probing if our gateway only logs the domain?
remediation: Enable full request path logging on perimeter application delivery
controllers.
requires: hb_http_activity with full url_path and status_code
risk: The initial mapping phase remains invisible, preventing us from seeing the
intent before the cloud pivot occurs.
stage: recon-and-attack-surface-mapping
- id: no-cloud-data-plane-events
owner: Cloud Security Architecture
question: Did the agent successfully write then delete a test file to a private
bucket?
remediation: Enable data-plane auditing for sensitive storage buckets.
requires: CloudTrail Data Events or equivalent for S3/Blob storage
risk: If only management-plane events are logged, the 'write-then-delete' discovery
Hallmark will be missed, leaving us blind to the agent's verification step.
stage: automated-cloud-discovery-and-testing
coverage:
- stage: recon-and-attack-surface-mapping
status: covered
steps:
- exposed-perimeter-assets
- api-spec-probing
- stage: identity-workflow-probing
status: covered
steps:
- identity-canary-usage
- stage: credential-validation-and-pivot
status: covered
steps:
- cloud-pivot-behavior
- stage: automated-cloud-discovery-and-testing
status: covered
steps:
- cloud-pivot-behavior
guardrails:
claims: no_unsupported
evidence: citation_required
missing_data: not_benign
telemetry: untrusted
hunt:
applicability: campaign-specific
handoff: promote-to-detection
justification: Autonomous AI agents can move from initial reconnaissance to cloud
pivot in less than 24 hours. A negative result confirms that automated campaigns
using these agentic timing signatures are not currently active against the organization's
perimeter and identity surfaces.
methodology: model-assisted
trigger: intel-report
hypothesis: An autonomous AI agent like ARTEX is probing internet-facing assets for
machine-readable maps and using canary credentials to pivot into cloud environments
for automated resource testing.
labels:
- hunt
- attack.t1110
- attack.t1133
- attack.t1190
- credential access
- discovery
- initial access
name: Autonomous AI Agent Probing and Exploitation
parameters:
canary_domains:
default:
- evil.com
- example.com
description: Placeholder domains often found in agent-led identity probing.
from:
kind: article
observed: '2026-11-11'
ref: unit42-artex
type: list[domain]
canary_users:
default:
- test@example.com
- deadbeefdeadbeefdeadbeef12
- admin@evil.com
- guest
description: Known canary or placeholder usernames used by autonomous frameworks.
from:
kind: article
observed: '2026-11-11'
ref: unit42-artex
type: list[string]
lookback_days:
default: '14'
description: Days of historical telemetry to examine.
type: number
scope_hosts:
default: []
description: Specific perimeter hosts (ADCs, VPNs, NAS) to focus the hunt on;
leave empty to scan the entire estate.
type: list[host]
provenance:
authors:
- name: Huntbase hunt generation
org: huntbase.io
generated:
by: huntbase-hunt-generation
from: https://unit42.paloaltonetworks.com/artex-and-ai-powered-red-teaming-tools/
gates:
- dry-run
- lint
- critic
model: hb_google/gemini-3-flash-preview
rationale: Start the hunt by examining logs from internet-facing gateways (VPNs, ADCs).
The cloud portion should prioritize roles with permission to modify identity or
access high-value storage buckets.
references:
- name: "Unit 42 \u2014 ARTEX and AI-Powered Red Teaming Tools"
url: https://unit42.paloaltonetworks.com/artex-and-ai-powered-red-teaming-tools/
related:
- hunt: cloud-credential-leak-audit
reason: This hunt focuses on the behavioral hallmark of agentic tools; a separate
audit is needed to identify the static credentials these tools target.
relation: out-of-scope-alternative
scenario:
stages:
- name: Reconnaissance and Attack Surface Mapping
observables:
- Scans for OpenAPI specifications, source maps, and configuration files
- High-frequency probing of internet-facing NAS devices and Application Delivery
Controllers
- Tool infrastructure associated with ARL, Nemo, XingRin, and Scope Sentry
- Host fingerprints for ARTEX and CyberStrikeAI consoles
slug: recon-and-attack-surface-mapping
tactic: initial-access
techniques:
- T1190
- name: Identity Workflow and API Probing
observables:
- Cadence of 1-14 requests followed by 25-31 second pauses
- Abuse of public password reset pages and verification code endpoints
- 'Canary usernames: test@example.com, deadbeefdeadbeefdeadbeef12'
- 'Canary domains: evil.com, example.com'
- Unauthenticated account-existence checks
slug: identity-workflow-probing
tactic: initial-access
techniques:
- T1110
- T1190
- name: Credential Validation and Cloud Pivot
observables:
- Validation of 200+ client secrets within a 3-minute window
- Transition from scripted user agents to desktop browser user agents for token
requests
- Pivoting to cloud identity providers within one minute of credential acquisition
slug: credential-validation-and-pivot
tactic: credential-access
techniques:
- T1110
- name: Automated Cloud Discovery and Testing
observables:
- Write-then-delete tests on cloud storage buckets
- Polling every 48 seconds for resource status
- Rapid trial-and-error adjustment of HTTP 422 failed requests
- Recheck loops replaying attack sequences every 30 seconds
slug: automated-cloud-discovery-and-testing
tactic: discovery
summary: Threat actors are employing autonomous AI-powered red teaming frameworks
like ARTEX and CyberStrikeAI to execute rapid, multi-stage intrusions. These tools
automate the discovery of exposed APIs and identity workflows, using machine-speed
reasoning to validate credentials and pivot into cloud environments without traditional
software exploits.
severity: high
targets:
analyst:
name: Tier-2 analyst
role: analyst
endpoint:
category: endpoint
name: Endpoint telemetry (hb_ surfaces)
telemetry:
- endpoint
hunter:
agent: true
name: Hunt agent
identity:
category: identity
name: Identity / sign-in telemetry
telemetry:
- identity
web:
category: siem
name: Web server / proxy logs
telemetry:
- network
tlp: clear
type: investigation
---
# Autonomous AI Agent Probing and Exploitation
AI-powered red teaming tools such as ARTEX and CyberStrikeAI exhibit predictable behavioral hallmarks, specifically a think-then-act timing cadence and machine-speed iteration. This hunt identifies the public attack surface and then hunts for reconnaissance patterns across HTTP and identity telemetry. It correlates these early signals with automated write-then-delete patterns in the cloud control plane to confirm an active agentic intrusion. The hunt is designed to distinguish automated planners from human actors by weighing the cadence and consistency of these interactions across multiple surfaces.
## exposed-perimeter-assets
<!-- Identify Exposed Perimeter Assets -->
Identify the organization's public attack surface, specifically VPNs, NAS, and Application Delivery Controllers identified as primary ARTEX targets.
```sqlite target=endpoint role=scoping
~~~yaml
expected: A list of hosts forming the organization's exposed edge. These provide the
initial scope for the analyst to narrow later behavioral queries.
reads:
- domain_or_ip
- ip_address
- product
- version
- port
silence: not_evidence_of_absence
source: hb_exposed_assets
verified: dry-run
verified_at: '2026-11-12'
~~~
SELECT domain_or_ip, ip_address, product, version, port FROM hb_exposed_assets WHERE (LOWER(product) LIKE '%vpn%' OR LOWER(product) LIKE '%nas%' OR LOWER(product) LIKE '%adc%' OR LOWER(product) LIKE '%citrix%' OR LOWER(product) LIKE '%f5%') ORDER BY discovered_at DESC
```
## early-recon-parallel
<!-- Hunt for Perimeter Reconnaissance Patterns -->
parallel:
- → api-spec-probing
- → identity-canary-usage
join: → perimeter-agent
## api-spec-probing
<!-- API Specification Probing -->
Identify high-frequency scans for machine-readable attack maps such as OpenAPI, Swagger, or source maps.
```sqlite target=web role=detection-candidate params=(lookback_days=lookback_days, scope_hosts=scope_hosts)
~~~yaml
expected: Bursts of requests for configuration or map files from a single IP, suggesting
the agent is mapping the application structure.
prevalence:
by: src_endpoint_ip
key:
- url_path
rare_below: 5
reads:
- device_hostname
- src_endpoint_ip
- url_path
- status_code
- time
silence: not_evidence_of_absence
source: hb_http_activity
verified: dry-run
verified_at: '2026-11-12'
~~~
SELECT device_hostname, src_endpoint_ip, url_path, status_code, COUNT(*) as hit_count, MIN(time) as first_seen, MAX(time) as last_seen FROM hb_http_activity WHERE (LOWER(url_path) LIKE '%.map' OR LOWER(url_path) LIKE '%openapi%' OR LOWER(url_path) LIKE '%swagger%' OR LOWER(url_path) LIKE '%.yaml' OR LOWER(url_path) LIKE '%.json') AND ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY 1, 2, 3, 4 HAVING hit_count > 3 ORDER BY hit_count DESC
```
## identity-canary-usage
<!-- Identity Canary and Placeholder Usage -->
Identify brute-force or probing attempts using known ARTEX canary values or placeholder domains in authentication logs.
```sqlite target=identity role=triage params=(lookback_days=lookback_days, canary_users=canary_users, canary_domains=canary_domains)
~~~yaml
expected: Multiple failed authentication attempts for 'test' accounts or placeholders
like 'evil.com' from a single IP address.
reads:
- src_endpoint_ip
- actor_user_name
- status_id
- time
silence: not_evidence_of_absence
source: hb_auth_signin
verified: dry-run
verified_at: '2026-11-12'
~~~
SELECT src_endpoint_ip, actor_user_name, status_id, COUNT(*) as attempt_count, MIN(time) as start_time, MAX(time) as end_time FROM hb_auth_signin WHERE (instr(',' || '{{canary_users}}' || ',', ',' || LOWER(actor_user_name) || ',') > 0 OR instr(',' || '{{canary_domains}}' || ',', ',' || SUBSTR(LOWER(actor_user_name), INSTR(actor_user_name, '@') + 1) || ',') > 0) AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY 1, 2, 3 ORDER BY attempt_count DESC
```
## perimeter-agent
<!-- Analyze Perimeter Probing Patterns -->
```agent target=hunter
cite: required
context:
- api-spec-probing
- identity-canary-usage
max_iterations: 4
objective: Identify source IPs that demonstrate the machine-speed iteration and the
specific 'think-then-act' cadence (1-14 requests followed by 25-31 second pauses).
Determine if these IPs are targeting both API maps and identity endpoints.
success_criteria: A per-IP verdict of agent | suspect | benign, citing the specific
timing gaps in the results.
tools:
- endpoint
- identity
- web
```
## cloud-pivot-behavior
<!-- Automated Cloud Discovery and Testing -->
Search for the 'write-then-delete' discovery pattern in cloud logs that follows a successful credential acquisition.
```sqlite target=endpoint role=triage params=(lookback_days=lookback_days)
~~~yaml
expected: Evidence of automated 'write-then-delete' loops on the same resource within
seconds, indicating an agent is testing its permissions.
reads:
- cloud_account_uid
- actor_user_name
- api_operation
- resource_name
- time
silence: not_evidence_of_absence
source: hb_cloud_api_activity
verified: dry-run
verified_at: '2026-11-12'
~~~
SELECT cloud_account_uid, actor_user_name, resource_name, GROUP_CONCAT(api_operation) as operations, MIN(time) as first_seen, MAX(time) as last_seen FROM hb_cloud_api_activity WHERE (api_operation LIKE '%Put%' OR api_operation LIKE '%Delete%' OR api_operation LIKE '%Create%' OR api_operation LIKE '%GetCallerIdentity%') AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY cloud_account_uid, actor_user_name, resource_name HAVING (instr(operations, 'Put') > 0 AND instr(operations, 'Delete') > 0) OR (instr(operations, 'Create') > 0 AND instr(operations, 'Delete') > 0) ORDER BY first_seen DESC
```
## pivot-agent
<!-- Correlate Perimeter Recon with Cloud Pivot -->
```agent target=hunter
cite: required
context:
- perimeter-agent
- cloud-pivot-behavior
max_iterations: 4
objective: Determine if the identities performing automated cloud tests were compromised
during or immediately after the perimeter probing identified in the first phase.
Look for the transition from scripted agents to desktop browsers mentioned in the
research.
success_criteria: A detailed timeline of the intrusion citing specific IPs and compromised
identities.
tools:
- endpoint
- identity
- web
```
## route-on-verdict
<!-- Route on Verdict -->
if~: "the pivot-agent verdict is malicious for at least one identity or source IP" (confidence: high, judge=hunter)
then: → isolate-identities
indeterminate: → analyst-review
unavailable: → analyst-review (blind_spot: limited-http-logging)
else: → close-out
## isolate-identities
<!-- Isolate Compromised Identities -->
```action target=identity
~~~yaml
approval: required
~~~
Disable the accounts identified in the correlation agent's timeline and revoke all active OAuth/session tokens. Block the source IPs at the perimeter.
```
→ analyst-review
## analyst-review
<!-- Analyst Review and Verification -->
```manual target=analyst
Review the timing bursts and canary usage cited by the agent. Specifically, check if any identities transitioned to human-like browsing patterns before containment, which may indicate a secondary beachhead.
```
→ end
## close-out
<!-- Hunt Close-out -->
```manual target=analyst
Document the findings. If speculative probing for .map or openapi files was identified without a pivot, consider promoting the HTTP query to a standing detection rule.
```
→ end
Run it
Take this hunt into your environment.
Open it in Huntbase to run every step against your own connections, with Scout weighing the evidence and your analysts in command. Or take the open hunt.md file anywhere that reads the format.
Machine-drafted by huntbase-hunt-generation using hb_google/gemini-3-flash-preview, gated by dry-run, lint, critic, then reviewed by a person.