An AI Pentest Platform in Real Intrusions: AntiFox Linked to IIS Web Shells and Stolen AWS Production Secrets

Autonomous ‘AI pentesting’ frameworks promise to run a penetration test from reconnaissance to report with little human effort. Arctic Wolf now reports that the same convenience is being used against real victims. Alibaba Cloud servers hosting AntiFox, an open-source, Chinese-language agentic pentesting platform, were tied to confirmed intrusions that began with a web shell on an internet-facing IIS server and ended with a production secret read from AWS Secrets Manager.
| Researcher | Arctic Wolf Labs, Adversary Research |
| Tool | AntiFox: open-source, Chinese-language agentic pentesting |
| Hosting | Alibaba Cloud hosts serving AntiFox interfaces |
| Impact | ≥1 successful GetSecretValue on a production secret |
What happened
[Confirmed] Arctic Wolf says it is tracking attackers running self-hosted agentic pentesting frameworks, including AntiFox, from public cloud. In several recent intrusions, Alibaba Cloud systems hosting AntiFox interfaces were tied to confirmed malicious actions against internet-facing web services and the AWS environments behind them, chaining web exploitation, web shells, config discovery, credential checks, cloud enumeration, secret access and storage operations. (Arctic Wolf) [Reported] The attackers used valid IAM users and, in some cases, an assumed EC2 role. In one intrusion they cycled through several identities and made hundreds of API calls in about 30 minutes. AntiFox began as a fork of ARTEX 0.1.1, the framework Datadog reported in AWS attacks in October. (BleepingComputer) (GBHackers) (Datadog) [MAG212 analysis] “Linked to” means the tool was used; no threat actor is named and the maintainers aren’t accused. Public-cloud addresses can be reassigned, as Arctic Wolf warns.

Who is affected and how it works
[Reported] Web: on a compromised IIS application (entry flaw unknown), w3wp.exe wrote an ASPX web shell and ran commands through it, hunted for web.config files and backups, read connection strings and logs, tried an internal production database, and copied files into a web-accessible upload folder. AWS: starting from a valid credential (origin not stated), the actor enumerated IAM, S3, Secrets Manager, KMS, RDS, Lambda and Bedrock. Most calls returned AccessDenied, but some succeeded, including at least one GetSecretValue on a production secret. (The Hacker News) [Confirmed] Arctic Wolf’s alert lists file patterns in the web-accessible upload folder: *.aspx, pwn*.aspx, cfg*.txt, wc*.txt, el*.txt, and the AntiFox console title “AntiFox — 自主渗透测试控制台”. (Arctic Wolf)
Cloud and IIS hunt
OS: any (AWS CLI v2) · Windows for IIS · Shell: bash · PowerShell · Privileges: cloudtrail:LookupEvents · local admin · READ-ONLY
# Who read secrets since 1 Oct (management events, per region, last 90 days)
aws cloudtrail lookup-events --region us-east-1 \
--lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
--start-time 2026-10-01T00:00:00Z \
--query 'Events[].[EventTime,Username,CloudTrailEvent]' --output text | head -n 200
# PowerShell on the IIS server: .aspx files written in the last 30 days
Get-ChildItem C:\inetpub -Recurse -Include *.aspx,*.ashx,cfg*.txt,wc*.txt,el*.txt -File -ErrorAction SilentlyContinue |
Where-Object LastWriteTime -gt (Get-Date).AddDays(-30) | Select-Object FullName, LastWriteTime
Look for principals or source IPs you don’t recognise, especially Alibaba Cloud ranges. Repeat per region. Any new .aspx you didn’t deploy, or pwn*.aspx, cfg*.txt, wc*.txt or el*.txt in an upload folder, is a lead (Arctic Wolf patterns). Commands not tested by MAG212 CYBER.
Contain and remediate (in order)
- [MAG212 analysis] Alert on w3wp.exe creating .aspx files or spawning cmd/PowerShell, and on one identity making a burst of List/Describe calls across many services with a high AccessDenied rate.
- Revoke affected sessions and access keys, and rotate any secret read by an unexpected principal and every credential in a harvested
web.config; this is Arctic Wolf’s advice. In CloudTrail, look for the few successful calls inside bursts of denials. (GBHackers) (BleepingComputer) - Remove long-lived access keys and cut IAM permissions to what each workload uses; restrict
secretsmanager:GetSecretValueby resource.
Verify recovery: rotated secrets in use and old values revoked; no unknown principals in CloudTrail for 7 days; web roots match deployed builds. Prevention [MAG212 analysis]: AI agents make noisy, broad enumeration cheap. That noise is your detection opportunity, if CloudTrail goes somewhere someone watches.
Why it matters
Agentic tools make broad, fast enumeration cheap: in one intrusion the attackers cycled through several identities and made hundreds of AWS API calls in about 30 minutes. Most were denied, but a burst of denials is not a failed attack; the few that succeed are the breach. The chain also shows how a forgotten web.config with cloud credentials turns a web-server foothold into a cloud incident.
The bottom line
Alert on IIS writing new .aspx files, hunt for Arctic Wolf’s file patterns in upload folders, review who called GetSecretValue since 1 October, and replace long-lived access keys and any credential stored in web configuration files.
How we label evidence: [Confirmed] comes from a primary source such as a vendor or CISA; [Reported] from a secondary outlet; [Claimed] from an attacker or an unverified party; [MAG212 analysis] is our judgement; [Unknown] means not established at press time. Commands and indicators are copied from the cited sources and were not tested by MAG212 CYBER.
This story is part of MAG212 CYBER Daily, 12 November 2026, with the day’s other verified stories, the Defender’s Action Desk and a full source register. Get the daily briefing free: subscribe to MAG212 CYBER. By El Mostafa Ouchen.
