News AI Security
Arctic Wolf links AntiFox agentic pentest platform to intrusions that reached AWS production secrets
Arctic Wolf Labs tied Alibaba Cloud-hosted AntiFox consoles to confirmed intrusions that began at an IIS application or an AWS credential obtained by unknown means and ended with a successful read of a production secret. The report's AWS call sequences are ready-made detections.
Key takeaways
- Arctic Wolf links AntiFox to intrusions through shared Alibaba Cloud infrastructure, not proof that an AI agent issued each command.
- The chain started at an IIS application or an AWS credential obtained by unknown means, then pivoted through web.config to database and cloud credentials.
- The actor enumerated 18 AWS services and eventually read a production secret with GetSecretValue.
- Most requests in the burst were denied, so least privilege worked until it did not; alert on the successful call.
- Revoke sessions before rotating credentials, and enforce IMDSv2 on application hosts.
Arctic Wolf Labs published a report this week linking AntiFox, which it describes as "an open source, Chinese language agentic pentesting platform", to real intrusions. The link is infrastructural: Arctic Wolf states that "Alibaba Cloud systems hosting AntiFox interfaces were associated with confirmed malicious actions". The report does not prove an AI agent issued each command, and Arctic Wolf itself notes that public-cloud infrastructure "may be reassigned or shared with unrelated tenants". AntiFox is built on the ARTEX framework and is freely forkable; The Hacker News counted more than 250 forks and more than 450 stars on GitHub at the time of its writing.
The chain: web app to cloud secrets #
Initial access took one of two forms. In the first, an internet-facing IIS application was compromised and the w3wp.exe worker process spawned an ASPX web shell. The exploited IIS vulnerability was not identified. In the second, the actor arrived with a valid AWS credential obtained "through unknown means".
From the IIS foothold, the actor used PowerShell and .NET configuration classes to parse web.config, pulled the database credential out of it, and tried to connect to an internal production database. That is the appsec lesson in one step: a connection string in a config file is a credential, and a web shell can read it.
On the AWS side, the actor enumerated 18 services, from IAM, EC2 and S3 through Secrets Manager, KMS, EKS, Systems Manager and Amazon Bedrock, and attempted an ECR GetAuthorizationToken call. In one intrusion the source cycled through multiple identities and fired hundreds of cross-service requests in about 30 minutes. Most were denied. The activity "eventually progressed to a successful GetSecretValue request against a production secret". A separate identity ran S3 discovery and object operations including GetObject, CopyObject and DeleteObject.
No victim was named, and the report does not claim AWS itself was compromised. The chain starts from a customer application or a valid AWS credential obtained by unknown means, which is where application teams come in.
Detection and response #
Arctic Wolf published source IP addresses, the AntiFox console's page title and common listening port, and the boto3 and botocore user agent strings it observed. Pull them from the report. Its recommendations map cleanly onto application and cloud teams:
- Isolate an IIS server the moment w3wp.exe spawns a shell, and treat everything in web.config as burned.
- Revoke active sessions before rotating database and AWS credentials, or the rotation changes nothing for a session already in hand.
- Alert on successful GetSecretValue calls from unfamiliar infrastructure, and on wide service enumeration from a single identity.
- Enforce IMDSv2 and apply least privilege to application identities so a stolen application credential cannot enumerate the whole account.
Sources
Questions this raises
- Did an AI agent carry out these attacks?
- Arctic Wolf ties the activity to Alibaba Cloud hosts running AntiFox interfaces. It does not demonstrate that an agent issued each command, and it cautions that cloud infrastructure can be reassigned or shared.
- Was AWS compromised?
- No. The intrusions began with a compromised customer IIS application or a valid AWS credential obtained by unknown means, then used normal AWS APIs with that access.
- What should application teams change?
- Treat config files such as web.config as credential stores, give application identities only the AWS permissions they need, enforce IMDSv2, and alert when w3wp.exe spawns a shell.