AntiFox AI pentest tool used in AWS attacks: Arctic Wolf lists 2 IPs, 18 services

Security firm Arctic Wolf Labs says attackers are running AntiFox, an open-source, Chinese-language AI penetration-testing platform, from Alibaba Cloud servers to break into web servers and then work through victims' AWS accounts. In its report dated 10 November 2026, Arctic Wolf describes a chain that starts with a compromised IIS web application or a stolen AWS key and ends with production secrets read and storage objects copied or deleted. Amazon says AWS itself was not compromised and that the attackers used credentials taken from customers' own applications.

Key points

• Arctic Wolf Labs ties two Alibaba Cloud IP addresses running AntiFox's web console (TCP port 8787) to confirmed intrusions against internet-facing web services and the AWS environments behind them.
• In one intrusion the attacker sent "hundreds" of AWS API requests across 18 services in about 30 minutes; most were denied, but a GetSecretValue call on a production secret succeeded.
• AntiFox is a fork of the ARTEX AI agent framework (version 0.1.1), according to BleepingComputer, and its GitHub repository showed 474 stars and 251 forks when The Hacker News wrote about it.
• Amazon says "AWS services were not compromised and operated as designed", and points to least-privilege permissions, IMDSv2 and GuardDuty as defences.
• Arctic Wolf could not identify the web flaw that gave the attackers code execution, or how the AWS credential in the second pattern was obtained.

What to do

You are most at risk if you run a public IIS application that holds AWS access keys or database credentials in web.config, or if long-term IAM access keys sit in application files. Based on Arctic Wolf's recommendations:

1. Hunt in CloudTrail. Look for API calls from hosting-provider address ranges that the identity has not used before, for one source IP using several keys or roles in a short window, and for fast sequences of List, Get and Describe calls across many services made with Boto3 or Botocore. Arctic Wolf's own indicators are the Alibaba Cloud addresses 47[.]79[.]4[.]33 and 8[.]208[.]101[.]210 and the user agents Boto3/1.43.125 and Botocore/1.43.125.
2. Alert on successful secret reads. Arctic Wolf recommends alerting on successful GetSecretValue calls from new infrastructure, especially after broad enumeration. Enable CloudTrail management events and S3 data events, and use S3 versioning and Object Lock on critical data, since the attacker used CopyObject and DeleteObject.
3. Check your IIS servers. Isolate a server if w3wp.exe spawns cmd.exe, powershell.exe, whoami.exe or icacls.exe. Look for new .aspx files, files named like pwn*.aspx, cfg*.txt, wc*.txt and el*.txt in upload directories, and preserve evidence before reimaging.
4. Rotate what the web server could read. Credentials found in configuration files, logs, backups and environment variables should be treated as exposed. After reviewing CloudTrail, revoke sessions and access keys for affected identities.
5. Harden the cloud side. Arctic Wolf and Amazon both recommend IMDSv2 with a restrictive hop limit and least-privilege permissions for application identities; Amazon adds enabling GuardDuty and keeping long-term access keys out of application configuration.

What happened

Arctic Wolf Labs, in a report published in its public wolf-tools repository with a date of 10 November 2026, says self-hosted agentic pentest tools, specifically AntiFox, were operated from Alibaba Cloud infrastructure that it linked to confirmed malicious activity. It describes the activity as a chain: web exploitation, web-shell deployment, configuration discovery, credential validation, cloud enumeration, secret access and storage operations. BleepingComputer and The Hacker News both reported on it on 11 November, and BleepingComputer later added Amazon's statement.

Arctic Wolf describes two intrusion patterns.

Pattern one: IIS web shell, then AWS. The attacker compromised an internet-facing IIS application. Arctic Wolf saw the IIS worker process w3wp.exe create an ASPX web shell and spawn cmd.exe and powershell.exe. Commands such as whoami and icacls and write tests in the web root followed. PowerShell was then used to search for web.config files and backups, read application settings and connection strings, and read debug and error logs, and the attacker copied configuration and log files into a web-accessible upload directory. According to The Hacker News, the attacker also tried to connect to an internal production database with a credential taken from the configuration. The flaw used to get code execution on the web server was not identified.

Pattern two: a valid AWS credential. In other intrusions the attacker began with a valid AWS credential whose origin Arctic Wolf could not determine. It cycled through several IAM identities (and in some cases an assumed EC2 role) from the same source, first checking who it was and what it could do, then listing and describing resources. Arctic Wolf counts 18 enumerated services: IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB and Bedrock. Most calls returned AccessDenied. Some succeeded, including at least one GetSecretValue on a production secret and S3 ListObjects, GetObject and HeadObject calls, followed by CopyObject and DeleteObject.

Background

AntiFox belongs to a family of tools that put a large language model in charge of a penetration test. An operator gives the agent a goal in plain language; the agent plans, picks tools, runs commands, reads the output and retries when something fails. According to BleepingComputer it is a fork of ARTEX 0.1.1 with a Chinese-language interface, and an AntiFox 2.0 is on GitHub. Its publishers prohibit use against live systems, in real pentests or exercises, or for illegal or destructive activity, but BleepingComputer notes that no technical control enforces this.

ARTEX itself was in the news the week before. Microsoft Threat Intelligence reported on 5 November that attackers were using it to search public GitHub repositories for exposed secrets and abuse them, with activity dating back to August 2026 (that account reaches us through secondary coverage, GitGuardian and others, and we have not read the Microsoft post itself). We covered another ARTEX case in CrowdStrike's report that the Vapor Panda group used ARTEX agents on more than 200 organisations in 11 days, and the WorkOS breach notice that mentioned the same framework.

How it works

Nothing in Arctic Wolf's chain is new. Web shells, configuration files that hold connection strings, and long-lived cloud keys are old problems. What the agent changes is speed and patience: GitGuardian reports that in a controlled ARTEX lab test the agent started searching within 6 to 13 seconds and found 8 of 9 planted credentials, and CERT-EU, quoted by The Hacker News, notes that agentic tools can test large numbers of low-complexity misconfigurations and work through long attack chains without fatigue. In Arctic Wolf's case, the telltale is behavioural: dozens of services probed from one address in minutes, almost all refused, a few permitted.

Two sets of numbers circulate about how widespread ARTEX-family tooling is, and they measure different things. Check Point identified 2,557 systems that hosted ARTEX, and Censys counted 1,465 hosts with exposed ARTEX consoles as of 4 November, according to The Hacker News, which adds that not every instance is malicious. A third figure, "five minutes" from GitHub leak to cloud-secret theft, comes from the Microsoft ARTEX research on Azure Key Vault and does not describe the AntiFox intrusions.

What it means

For defenders the useful change is where detection sits. Signature-based detection of a specific tool is brittle, since forks appear within days. The behaviours Arctic Wolf lists, such as a burst of denied API calls followed by a successful secret read from an unfamiliar hosting network, survive a rename. Teams that already ship CloudTrail to a log platform can write that rule today.

For cloud customers it is another reminder of the shared-responsibility line Amazon drew in its statement: the attackers used customers' credentials, not an AWS flaw. The credentials that mattered were the ones a compromised web server could read, so the leverage is in keeping long-term keys out of application configuration and using short-lived role credentials.

For the people who publish open-source offensive tooling, this is another case of a licence restriction that only works if the user chooses to follow it. Whether that changes how such tools are released is not something the sources address.

What we don't know yet

• Who operates the AntiFox instances in Arctic Wolf's report; the report ties them to Alibaba Cloud hosting, not to a named actor. Hosting on a cloud provider does not by itself show the provider was involved.
• Which web vulnerability opened the IIS servers, and how the AWS credentials in pattern two leaked.
• How many organisations were affected. Arctic Wolf gives no victim count and no exact API request total, only "hundreds" in about 30 minutes for one intrusion.
• Whether the S3 deletions destroyed data that could not be recovered; the report lists DeleteObject calls but we have no figures on what was deleted.
• Whether AntiFox 2.0 changes behaviour in ways that make these indicators stale.

What to watch next

• Further Arctic Wolf or AWS guidance, and any update to the IP and user-agent indicators.
• Whether other vendors publish their own AntiFox or ARTEX detections.
• Changes to AntiFox's GitHub repository, including its licence terms and its fork count.

Sources

• Arctic Wolf Labs: AntiFox, Alibaba-hosted platforms facilitate web and cloud intrusions (primary)
• BleepingComputer: Hackers use AntiFox AI agents in AWS credential-theft attacks
• The Hacker News: AntiFox AI pentesting platform linked to attacks that accessed AWS production secrets
• GitGuardian: AntiFox, ARTEX AI fork targets AWS credentials