Arctic Wolf says AntiFox hosts on Alibaba Cloud were linked to web shell and AWS intrusions; 18 services named
Arctic Wolf Labs says Alibaba Cloud systems hosting AntiFox interfaces were associated with web shell and AWS intrusions; its list names 18 AWS services, its summary says dozens, and it did not identify the exact flaw.
By Parminder Kumar Sharma · LinkedIn · · 14 min read
Eighteen services named, "dozens" claimed, and no count of intrusions
Arctic Wolf Labs' alert on AntiFox, read from 16:06 UTC on Wednesday 11 November 2026, names 18 AWS services in its enumeration list (derived by counting: IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB and Amazon Bedrock). Its own summary says the activity enumerated "dozens of services". It counts the intrusions as "several", prints one date (10 November 2026, in its heading) and gives no figure for victims.
That is the first thing the record does not establish: how big this is. It also does not establish who operates the Alibaba Cloud hosts, whether AntiFox itself carried out the actions or only shares infrastructure with whoever did, what weakness let the attacker run code on a web server, or what was taken. The alert's wording is "associated with", and this briefing keeps that wording.
What the alert does print is a sequence a defender can look for: a web shell created by an IIS worker process, configuration files read, valid AWS identities tested, a burst of denied calls with successes mixed in, a secret read, and storage operations. BleepingComputer reported it on 11 November 2026 (its page data gives 10:12 at UTC minus five hours, which is 15:12 UTC, derived). The alert is the primary; BleepingComputer is a secondary used to find it.
What the alert says it observed
The first key finding is the claim everything else hangs on: "In several recently observed intrusions, Alibaba Cloud systems hosting AntiFox interfaces were associated with confirmed malicious actions against internet-facing web services and associated AWS environments." The alert describes AntiFox as "an open source, Chinese language agentic pentesting platform" and says the activity associated with infrastructure hosting it chained web exploitation, web shell deployment, configuration discovery, credential validation, cloud service enumeration, secret access and storage operations.
It gives two starting points. In some activity the foothold was a compromised internet facing IIS application: endpoint telemetry showed the application's w3wp.exe process creating an ASPX web shell and then running operating system commands. In other activity the actor began with a valid AWS credential "obtained through unknown means". The exact vulnerability used for code execution "was not identified".
On the IIS server the alert lists, in order: commands that identified the execution context with whoami, listed the application directory, checked permissions with icacls and tested whether files could be written into the web root; PowerShell that parsed web.config connection strings and application settings; a look at debug and error log directories; and an attempt to connect to an internal production database with a credential taken from the application configuration. Its key findings add that configuration and log files were copied into a web accessible upload directory.
On the AWS side the source used valid IAM users and, in some instances, an assumed EC2 role. In one intrusion it "cycled through multiple AWS identities" and generated hundreds of cross service requests within approximately half an hour. Read as at least 200 requests in 1,800 seconds (derived from "hundreds" and "half an hour", so a floor, not a measurement), that is at least one request every nine seconds. Most were denied. Discovery and secret access operations that succeeded were mixed into the same burst.
The burst ended, in some instances, with a successful GetSecretValue request against a production secret. In other activity a valid AWS identity listed buckets and objects, then made GetObject, CopyObject and DeleteObject calls. The alert does not say which secret, which bucket, what the objects held or what was deleted.
What "associated with" carries, and what the headline claims
The body of the alert is careful. The infrastructure is "AntiFox-linked", the systems "hosting AntiFox interfaces" were "associated with" malicious actions, and the IIS compromise is something the process telemetry "suggests". The alert never says which actor ran the interface, and it says nothing about whether the tool, rather than a person using a tool like it, issued the calls.
The heading above the body is bolder: "Used to Steal AWS Credentials and Move Laterally in Compromised Environments". The body supports a successful read of one production secret and a credential taken from application configuration for a database login attempt. It does not say that AWS credentials were stolen from the web server, and in the AWS only activity the credential came from an unknown source. The two statements sit in one document; a reader should hold the body's wording.
BleepingComputer's wording is stronger again: "Attackers are using Alibaba Cloud to host self-managed instances of AntiFox", and the attacker "obtained production secrets" (plural). The alert says a production secret, once, in some instances.
"Pentesting platform" names a purpose, not a control
The alert's own background explains why the label matters: agentic frameworks make penetration testing techniques more accessible to threat actors, "increasing the speed and consistency with which these techniques can be applied in live attacks". A tool that is published as a testing aid is still a tool any buyer of a cloud server can run.
BleepingComputer adds that AntiFox's publishers prohibit use against live systems, in real world tests or for destructive or illegal activity, "but they do not describe any technical controls that enforce those restrictions". That is BleepingComputer's reading of the project's pages, which this site did not open, so it stays attributed. The same point stands without it: a prohibition in a project's terms is a statement, not a safeguard, and the alert's hunting advice is built on behaviour (process parents, API sequences, source networks) rather than on spotting the tool's name.
What the alert states, and what it does not
Statements in Arctic Wolf Labs' alert dated 10 November 2026 against what it leaves unsaid, read 11 November 2026. The right column is this site's list of gaps.
| Topic | Stated by Arctic Wolf | Not stated |
|---|---|---|
| How many intrusions | "Several recently observed intrusions"; one intrusion described with its timing | A count, dates, victims, a sector, a country |
| Who operates the hosts | Alibaba Cloud systems hosting AntiFox interfaces; AntiFox-linked infrastructure | Operator, actor name, whether AntiFox issued the calls, the AntiFox version |
| Initial access | A compromised internet facing IIS application in some activity; a valid AWS credential in other activity | The vulnerability; the credential's source; whether the IAM users' keys came from the web server |
| AWS activity | Valid IAM users, sometimes an assumed EC2 role; hundreds of calls in about half an hour in one intrusion; 18 services listed | How many identities, how many calls succeeded, which accounts |
| Secret access | A successful GetSecretValue against a production secret | Which secret, what it unlocked, whether it was used |
| Storage operations | ListBuckets, ListObjects, GetObject, CopyObject, DeleteObject on a valid identity | Buckets, data, what was deleted, impact |
| Confidence | "Confirmed malicious actions"; web application compromise "suggested" by telemetry | A confidence rating; any link to another named tool or family |
Where the sources differ
BleepingComputer's article is a secondary. These are the differences between it and the alert, kept as differences.
Arctic Wolf's alert (read 11 November 2026) against BleepingComputer's article (dated 11 November 2026, 10:12 US Eastern, from its page data).
| Point | Arctic Wolf's alert | BleepingComputer |
|---|---|---|
| Lineage of AntiFox | Does not mention ARTEX or any fork | "Initially created as a fork of ARTEX 0.1.1", with that sentence linked to the project's own page |
| Secrets obtained | A successful GetSecretValue against a production secret, in some instances | The attacker "obtained production secrets" |
| Hosting | Alibaba Cloud systems hosting AntiFox interfaces | Attackers using Alibaba Cloud to host self managed instances |
| The project today | Says nothing about its current state | Says it is on GitHub, updated to version 2.0, with a use prohibition |
| Related coverage | None | Links earlier ARTEX stories, including a CrowdStrike report and attacks on South Korean banks |
The fork claim is the one a reader is most likely to repeat. Only BleepingComputer makes it, and it attaches the claim to the AntiFox project's own page, which this site did not open under the rules for this brief. So the fork relationship is BleepingComputer's statement, resting on a page this site has not read.
Set beside this site's earlier ARTEX coverage
This site has covered the ARTEX family of agentic tools from several angles, for example Censys' count of exposed operator consoles and CrowdStrike's report of ARTEX use against more than 200 organisations. The alert does not mention ARTEX. BleepingComputer does, saying ARTEX went closed source after use in attacks on South Korean banks and that CrowdStrike linked it to a China based group that targeted more than 200 organisations across 14 countries; those are BleepingComputer's statements here and the earlier briefs hold the primary detail.
What they share is the category: agentic penetration testing frameworks that security vendors link to attacks on web services and cloud accounts. What differs on this record is the evidence. The earlier briefs each work from their own primary; the AntiFox record is one vendor alert with no count, no victim and no named actor, so no ranking of one against the other is possible, and none is attempted.
What API call patterns let a defender read
The alert's strongest practical point is about reading a denied burst. It says to hunt for rapid sequences of List, Get and Describe operations spanning unrelated services, and adds "Do not assume a sequence was unsuccessful because most requests were denied." A log review that only looks for successful calls from a new address will see the secret read; one that filters on failures will see noise and miss it. Both belong in the same query.
Arctic Wolf's hunting guidance, in its order: look for AWS API activity from hosting providers or autonomous systems not previously linked to the identity; one source address using several access keys, users or roles in a short period; rapid List, Get and Describe sequences across unrelated services, with confidence rising for a novel hosting network and a scripting oriented SDK such as Boto3 or Botocore; GuardDuty findings for anomalous IAM user behaviour, credential access, discovery and compromised EC2 credentials; IIS worker processes spawning command shells, PowerShell, whoami, icacls, archive utilities and similar tools; newly created .aspx files, above all by the worker process and in upload, temporary or image conversion directories; configuration or log files copied under .txt or image extensions; PowerShell referencing the .NET configuration classes; and a correlation of web shell activity with later AWS activity.
One caution from the alert applies to every indicator in it: the list is not exhaustive, AntiFox is publicly available, and public cloud addresses can be reassigned or shared with unrelated tenants. A match on an address is a lead, not a verdict.
What to do, in order
Take this with you
Arctic Wolf's defensive considerations, paraphrased, in its order
- Enable CloudTrail management events and S3 data events for sensitive buckets, plus S3 versioning and, where appropriate, Object Lock, to limit the impact of deletion.
- Alert on successful GetSecretValue activity from novel infrastructure, particularly after broad service enumeration or denied calls.
- Keep an inventory of internet facing applications and prioritise file conversion, upload and document processing services for patching, testing and web application firewall coverage.
- When an IIS worker process spawns unexpected shells or interpreters, isolate the server at once and preserve the web root, IIS logs, endpoint telemetry and memory before reimaging where feasible.
- Remove unauthorised ASPX files and review every user writable web directory, since other shells may exist or existing files may have been changed.
- Rotate credentials exposed through web.config, application settings, deployment artifacts, debug logs, environment variables and backup configuration files: database credentials, AWS access keys, API tokens, encryption keys and application secrets.
- Revoke active AWS sessions and access keys tied to affected users and roles, and review CloudTrail for each identity before issuing replacements.
- Enforce IMDSv2 with a restrictive metadata response hop limit where instance roles are needed, and apply least privilege so workloads do not hold broad listing permissions across the account.
Take this with you
This site's suggestions (not Arctic Wolf's advice)
- Write one alert for a principal that fails many calls across unrelated services and then succeeds at GetSecretValue on a production secret within the same burst.
- List every IAM user and role reachable from internet facing Windows web servers, and cut each to the calls the application needs; a web tier should not hold account wide listing rights.
- Treat any secret read from a web server's reach as exposed after a shell is found, and rotate it before the investigation ends.
- Turn on object level logging for sensitive buckets and alert on a burst of CopyObject or DeleteObject by one identity.
- Make upload directories non executable, so a file written there cannot run as a page.
- Alert on w3wp.exe starting cmd.exe, powershell.exe, whoami.exe or icacls.exe, and test the alert once on a non production host.
- Do not block by the listed addresses alone: they are source addresses seen calling in, the alert gives no outbound blocking advice, and shared cloud ranges change hands.
Technical details
Everything below is copied from the alert's indicators of compromise section and its hunting guidance. It is not a tool command and not a payload. The alert prints no query text and no payload, so there is none here. Addresses are shown exactly as the alert prints them, already defanged. This site did not visit, resolve or probe any of them.
Infrastructure and interface indicators. These identify the source addresses the alert links to AntiFox, the title of the tool's web interface, a banner hash, the port and the SDK user agent strings seen. The alert prints a long dash between the two parts of the interface title; this site's rules bar that character, so it is shown here as a plain hyphen. Match on the two parts, not on the dash. The Chinese text is the alert's; this site reads it as roughly autonomous penetration testing console (derived). A defender checks edge logs, network scans and CloudTrail source addresses and user agents against them, and treats a match as a lead.
# ANTIFOX-LINKED SOURCE INFRASTRUCTURE
47[.]79[.]4[.]33
8[.]208[.]101[.]210
# ANTIFOX WEB INTERFACE TITLE
AntiFox - 自主渗透测试控制台
# ANTIFOX BANNER HASH
c370d03542ed2ec696f7337940b14652e98e9bab
# ANTIFOX COMMON PORT
TCP/8787
# USER AGENT STRINGS
Boto3/1.43.125
Botocore/1.43.125
Endpoint behaviour and file patterns. The arrows are process parent to child. The file patterns sit in the web accessible upload directory the alert describes without naming. A defender hunts for these parent and child pairs in endpoint telemetry and for these file names in web directories.
# ENDPOINT BEHAVIOR
w3wp.exe → cmd.exe
w3wp.exe → powershell.exe
w3wp.exe → where.exe
cmd.exe → whoami.exe
cmd.exe → icacls.exe
# FILE PATTERNS
<web-accessible upload directory>*.aspx
<web-accessible upload directory>\pwn*.aspx
<web-accessible upload directory>\cfg*.txt
<web-accessible upload directory>\wc*.txt
<web-accessible upload directory>\el*.txt
AWS API sequences. Each pair is a call followed by a call from the same identity. A defender searches CloudTrail for these sequences by one principal in a short window, from a source not previously seen for that principal.
# AWS API SEQUENCES
ListSecrets → GetSecretValue
GetCallerIdentity → ListBuckets
ListBuckets → ListObjects
ListObjects → HeadObject
ListObjects → GetObject
The AWS calls named in the observed behaviour. This block gathers the API names the alert lists in prose, joined by this site; the alert prints them in sentences, not as a block, so the layout here is derived.
Identity and permission discovery: GetCallerIdentity, GetUser, ListUsers, ListRoles, ListPolicies, ListKeys
Attempted: Amazon ECR GetAuthorizationToken
Secrets and storage: ListSecrets, GetSecretValue, ListBuckets, ListObjects, ListObjectVersions, HeadObject, GetObject, CopyObject, DeleteObject
PowerShell terms to hunt. The alert says the actor used .NET configuration classes to read web.config. These are the strings it lists for a hunt in PowerShell logs and command lines. A defender searches script block and process command line logs for them on web servers.
System.Web.Configuration.WebConfigurationManager
WebConfigurationFileMap
VirtualDirectoryMapping
ConnectionStrings.ConnectionStrings
AppSettings.Settings
[IO.File]::ReadAllText
The question the alert leaves open
The alert tells defenders to hunt a burst of denials with a success inside it, and tells them not to read the denials as failure. It does not tell them how many of its own "several" intrusions ended in a read of data, or what the first secret opened. If a web server of yours were shelled tonight, and one of its roles then failed dozens of calls and succeeded at one, which alert would fire on the success, and who would be reading it before the secret was used?
Key facts
Sources
- PrimaryPack alert dated 2026-11-10, Antifox Agentic Pentesting Platform Used to Steal AWS Credentials and Move Laterally in Compromised Environments: key findings, observed behavior, hunting guidance, defensive considerations, indicators. Read in fullArctic Wolf Labsaccessed 2026-11-11
- Reported byHackers use AntiFox AI agents in AWS credential-theft attacks, 11 November 2026 10:12 US Eastern: the fork of ARTEX 0.1.1 claim and the ARTEX context. Secondary; read in fullBleepingComputeraccessed 2026-11-11
