AntiFox Proves Banning One AI Attack Framework Won't Work: The Signal Defenders Need Is in Their Own Cloud Logs

2026-11-13 · By H.A

AntiFox Proves Banning One AI Attack Framework Won't Work: The Signal Defenders Need Is in Their Own Cloud Logs

AntiFox Proves Banning One AI Attack Framework Won't Work: The Signal Defenders Need Is in Their Own Cloud Logs

An open-source AI pentesting platform built on ARTEX has turned up in intrusions that read AWS production secrets, which shows that tracking individual agentic tools is a losing game and that defenders should focus on what every one of them has to do.

What is new

Defenders have spent the past month learning the name ARTEX. The agentic attack framework has been linked to campaigns against Microsoft 365 tenants, banks and fintechs, and SaaS providers. This week researchers added another name: AntiFox, an AI-driven autonomous penetration testing platform published on GitHub and built on ARTEX. Researchers saw attacker-run AntiFox consoles hosted on Alibaba Cloud tied to malicious activity against internet-facing web services and the AWS environments behind them. When the research was published, the project had about 474 stars and 251 forks.

The new part is not that an AI pentest tool was misused. That is old news. The new part is that the ecosystem has started to branch. ARTEX is no longer one tool to track. It is a foundation that other projects build on, fork and rename.

What the intrusions looked like

Researchers describe two patterns.

In the first, the entry point was a compromised internet-facing IIS application. The attacker planted an ASPX web shell, spawned by the IIS worker process w3wp.exe, and used it to:

The vulnerability that gave code execution has not been identified.

In the second pattern, the attacker started with a valid AWS credential of unknown origin and probed a long list of services: IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, EKS, CloudFormation, DynamoDB and Amazon Bedrock. Most calls returned AccessDenied. A few did not. In at least some cases a GetSecretValue call against a production secret succeeded, and elsewhere S3 objects were listed and accessed.

Why chasing tool names is a dead end

The AntiFox README describes a planner, worker and main-agent design with a global asset graph and a per-task exploration graph. It covers reconnaissance, attack-surface discovery, exploitation, recording findings and producing a report a client can reproduce. That is a sensible design for an authorised red team. It is equally useful to someone without authorisation, and nothing in the code can tell the two apart.

The numbers show why blocking by name fails. Researchers counted about 1,465 hosts with an exposed ARTEX console as of 4 November, and another team found 2,557 systems that had hosted ARTEX, ten with exposed databases. Researchers also estimate there are now about 45 open-source agentic attack frameworks. Signatures for one console page or one GitHub repository will age in days, and a fork with a new name and favicon gets past them.

There is a better way to look at it. Whatever the framework, an agent attacking your environment still has to do the same physical things: run code on a web server, read files that hold secrets, call cloud APIs with a stolen identity, and move data somewhere it can collect it. The AI speeds up the loop and makes it tireless. It does not change the loop.

The tell: machine-speed enumeration

The AWS pattern is the clearest example. A human operator with a stolen key usually tries a few services they care about. An agent working through a plan tries everything, and it does not mind failing. What CloudTrail shows is a burst of calls across a dozen services in a short window from one identity, most of them failing with AccessDenied, followed by a few successful reads of secrets or objects.

That shape is unusual for a legitimate workload, which almost always calls the same small set of APIs. It is a high-quality detection that is cheap to build and that no amount of renaming will defeat.

The IIS side is just as consistent. w3wp.exe should almost never start a command shell, list web.config backups or write files into an upload folder. Those are classic web-shell detections, and they work whether the shell was typed by a person or chosen by a planner agent.

The real lesson is about where secrets live

Look again at what the attacker went after: connection strings in web.config, a production database credential reused from application config, and a long-lived AWS key from an unknown source. Each one was a secret sitting in a place an attacker could read once they had a foothold. Agentic tools did not create that problem. They just find it faster and more reliably than a tired human at 3 a.m.

Practical takeaways

REEF SENTINEL