At a glance
- Unit 42 observed attackers using ARTEX and AI red teaming tools to automate scanning and attempt intrusions.
- Targets include internet-facing assets, password-reset pages, APIs, identity flows and cloud services.
- Obtained credentials or trust relationships can provide a path into cloud environments without exploiting a software vulnerability.
- Prioritize reviewing exposed assets, centralizing telemetry and logs, detecting automated behavior and blocking activity at the network edge.
Unit 42 reports ARTEX and AI red teaming tools used in intrusion activity
Unit 42 observed attackers using ARTEX and AI-powered red teaming tools to automate scanning, testing and intrusion attempts against internet-facing assets. Prioritize exposed password-reset pages, APIs, identity flows and cloud services; centralize logs, detect automated behavior and block…
In this article
Unit 42 observed attackers using ARTEX and other AI-powered red teaming tools to automate scanning, testing and targeting of internet-facing assets. The analysis describes observed behaviors and relevant review and mitigation measures.
Overview and technical details
ARTEX is an open-source, AI-powered, multi-agent penetration-testing framework designed to automate pentesting activities. Unit 42 observed this framework and other AI red teaming tools being used to scan, test and attempt to intrude on internet-facing assets.
| Field | Details |
|---|---|
| Product/tool | ARTEX and AI red teaming tools |
| Activity | Scanning, testing and attempted intrusion against internet-facing assets |
| Source | Palo Alto Unit 42 |
Affected systems
Unit 42 observed this activity at multiple organizations and across multiple sectors, sometimes in less than a day. Named targets include identity workflows, public password-reset pages, exposed APIs and other internet-facing assets; obtained credentials or trust relationships can provide a path into cloud environments.
Mechanism and impact
Attackers use ARTEX and LLMs to evaluate responses automatically, adapt when requests fail and continue targeting public-facing surfaces. According to the source, access to cloud environments may rely on obtained credentials and trust relationships and does not necessarily require exploiting a software vulnerability.
Behaviors observed by Unit 42 include bursts of 1–14 requests spaced about one second apart, followed by pauses of 25–31 seconds; redirects within about a minute after credential loading; and validation of more than 200 client secrets in about three minutes. Other signs include accessing routes found in an OpenAPI spec or source map, modifying and resubmitting HTTP 422 requests, and sending GET requests to check after write operations.
Activity may also include attempting to write to and then delete from a bucket, using fake usernames or placeholders such as evil[.]com, test@example[.]com and deadbeefdeadbeefdeadbeef12, targeting multiple device and service types in parallel, or polling on a sustained cycle. In the Cairn survey, one source IP generated hundreds of thousands of high-rate requests across multiple edge protocols.
Review and mitigation measures
- Prioritize reviewing internet-facing assets, especially public password-reset pages, APIs, identity flows and cloud services that could lead to cloud access.
- Centralize perimeter telemetry and logs to identify high-rate automated requests, and block campaigns at the network edge.
- Continuously discover and mitigate exposed edge assets; monitor infrastructure hosting the tools to update edge blocking.
- Consistent generic error responses or silent connection throttling may limit signals that help an agent adapt.
- Offensive open-source frameworks can be tested in a controlled environment to find, validate and remediate exposure.