Cloud reconnaissance used to be slow, tedious work. Not anymore. In a set of recently disclosed intrusions, attackers used AntiFox, an open-source agentic penetration-testing platform, to automate everything from web exploitation to credential discovery, AWS identity validation, cross-service enumeration, and finally access to production secrets. Work that once took days was squeezed into about half an hour.
It’s worth being clear about what this story is not. AI did not “hack AWS.” AWS says its services weren’t compromised and worked as designed. The attackers got in with credentials stolen from customers’ compromised applications, then used them to reach customer AWS accounts. The real concern is what an AI agent can do once it holds valid credentials: test them across dozens of services, read the denials, swap identities, and keep pushing down whatever path stays open.
What Is AntiFox?
AntiFox is an open-source, Chinese-language agentic pentesting platform built on ARTEX version 0.1.1. Users can deploy AI agents to handle common offensive-security chores, like mapping internet-exposed services and probing endpoints for weaknesses.
The attackers ran it on self-managed Alibaba Cloud infrastructure. From there, it was tied to vulnerability exploitation, web-shell deployment, credential validation, configuration discovery, and the harvesting of AWS secrets.
AntiFox’s developers say it must not be used against live systems, in real-world penetration tests, or for destructive or illegal activity. But reporting on the incidents says no technical mechanism enforcing those rules has been disclosed. So the restriction is, in practice, a request.
The Autonomous Cloud Kill Chain
The attack followed a familiar cloud pattern. What changed was the speed: much of the reconnaissance and permission discovery could run automatically, at machine pace.
Internet-facing IIS server
↓
ASPX web shell / command execution
↓
Configuration and connection-string discovery
↓
AWS credential extraction
↓
IAM user / EC2 role validation
↓
Cross-service AWS API enumeration
↓
AccessDenied analysis and identity cycling
↓
Successful resource discovery / secret access
↓
Production secret retrievalInitial access
In one investigated incident, the attackers planted an ASPX web shell on an internet-facing IIS server. That gave them command execution on the host and a solid foothold.
From there they went looking through application settings, database connection strings, configuration files, and logs. Some of those files were copied into web-accessible directories, which only widened the exposure of credentials and sensitive data.
Credential validation
The attackers didn’t try to break AWS authentication. They used valid AWS identities, including IAM users and, in some cases, assumed EC2 roles, to send authenticated API requests.
That distinction matters. They never had to defeat AWS’s sign-in system. They just had to find an identity that a customer’s application had leaked or mishandled, and use it.
Cross-service enumeration
Once authenticated, the agents started mapping the environment. The reported activity touched a wide range of services: IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB, and Amazon Bedrock.
In one intrusion, the attackers cycled through several AWS identities and fired off hundreds of API requests in roughly 30 minutes. Most were denied. It didn’t matter. The volume and breadth were enough to chart which paths were actually open.
AccessDenied as a map
A pile of AccessDenied responses can look like a defense that worked. In this campaign, it was also a source of intelligence for the attacker.
Every denial told the agent a bit more about what a given identity could and couldn’t do. The occasional successful List, Get, or Describe call then revealed live resources, real permissions, and where to go next.
The agent didn’t need every call to succeed. It only needed enough of them to find a route to something valuable.
Reaching Secrets Manager
The campaign didn’t stop at discovery. In some cases the attackers got into secrets used in production, including through AWS Secrets Manager.
A single successful secret retrieval can hand over database credentials, API keys, tokens, or certificates, which can turn one compromised application into movement across the whole cloud environment.
In a separate incident, attackers used a valid AWS identity to read, copy, and delete objects in Amazon S3. Stolen credentials can be used for destruction, not just snooping.
Why “Brute-Forcing” Is Misleading
This wasn’t necessarily password brute-forcing against an AWS login page. A better description is machine-speed API permission brute-forcing: quickly testing valid credentials against many services and actions to find out what they can really do.
| Traditional manual recon | Autonomous agent-speed recon |
|---|---|
| A human tests services and permissions over hours or days. | An agent issues hundreds of API requests in roughly 30 minutes. |
| The attacker manually interprets errors and chooses next steps. | The agent can cycle identities, test services, and pursue successful calls systematically. |
| A denial may end a particular manual attempt. | Repeated denials can still reveal the identity’s effective permission boundary. |
| Detection often focuses on a single suspicious event. | The meaningful signal is a rapid cross-service burst combined with occasional successful sensitive operations. |
The goal was never to win every request. It was to find the few that worked.
The Detection Blind Spot
Plenty of security teams see a flood of denied API calls and conclude the attack was contained. That’s a risky assumption.
A burst of denials can mean an automated agent is methodically probing an identity’s permissions. If those denials are followed by successful discovery calls, or worse, a successful GetSecretValue, it deserves immediate investigation.
Signals worth correlating
- A compromised IIS server, web-shell activity, or unexpected command execution.
- Access to application configuration files, connection strings, logs, or configuration backups.
- Valid IAM-user or EC2-role activity from unfamiliar infrastructure or unusual network patterns.
- A rapid burst of cross-service AWS API calls.
- A high share of
AccessDeniedresponses mixed with successfulList,Get, orDescribecalls. - Successful access to Secrets Manager, S3, IAM, EC2, or other high-value services.
- S3 object reads, copies, or deletions right after credential validation.
What Defenders Should Do Now
Reduce credential exposure
Long-term AWS access keys don’t belong in application configs, source code, logs, or easily reachable backups. AWS itself recommends keeping them out of application configuration.
If credentials may have been exposed, rotate them, and revoke affected sessions and access keys right away.
Apply least privilege
The attackers got as far as they did because the identities they held could do more than their workloads needed. Tight, least-privilege IAM policies shrink the number of services and actions a compromised credential can reach.
Go through your IAM users, roles, inline and managed policies, and trust relationships. Look hardest at identities that can read secrets, enumerate resources broadly, assume other roles, or touch production data stores.
Harden EC2 metadata access
Where EC2 is involved, require IMDSv2. It cuts down on instance-metadata credential theft, a common way to grab temporary credentials from a compromised host.
Detect behavior, not just denials
Build detections around sequences rather than single events:
- High-volume authenticated AWS API activity from an unfamiliar source.
- Cross-service enumeration within a short window.
- A high denial ratio followed by successful discovery calls.
- A successful
GetSecretValueafter broad enumeration. - IAM, EC2, S3, or Secrets Manager activity that lines up with web-shell indicators.
AWS also recommends turning on Amazon GuardDuty as part of a wider detection and response approach.
The Bigger Shift
AntiFox shows that AI doesn’t have to invent a new kind of vulnerability to matter. It just has to automate the unglamorous work skilled attackers already do: find an exposed app, pull out a credential, check that it works, map its permissions, and follow the first successful path to sensitive data.
Also Read: Why United’s AI Ban Is Really About Who Owns the Customer
The result is a shorter attack window and far more reconnaissance activity. Defenders should assume an attacker may try many identities, services, and permissions in very little time, and that a wall of denials might be the lead-up to a successful secret read.
The cloud kill chain hasn’t gone anywhere. It just runs at machine speed now.