> AI Pentest Tool AntiFox Abused To Steal AWS Credentials
[AUTHOR: Pierluigi Paganini]
[DATE: 11/11/2026 21:31]
[LANGUAGE: EN]
Arctic Wolf saw attackers use the AntiFox pentest platform to hit IIS servers and AWS accounts.
Arctic Wolf Labs has published research on attackers using AntiFox, an open-source, Chinese-language agentic penetration testing platform. These frameworks chain attack steps together with little human effort. In several intrusions, Alibaba Cloud systems hosting AntiFox interfaces were tied to confirmed attacks on internet-facing web services and the AWS environments behind them.
Two entry points showed up. In some cases, the attackers got into a public IIS application, though Arctic Wolf couldn’t identify the vulnerability. In others, they started with a valid AWS credential obtained by means nobody knows.
“Arctic Wolf is tracking the emerging use of self-hosted agentic penetration testing frameworks, including AntiFox, from public cloud infrastructure.” states the report published by Arctic Wolf, “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 IIS attacks followed a similar pattern. The IIS worker process, w3wp.exe, created an ASPX web shell and then ran commands to gather information about the system. The attackers checked the user account, listed files in the application folder, reviewed file permissions using icacls and tested whether they could write files to the website’s main folder.
They then used PowerShell to read the web.config file, looking for database connection details and application settings. They also checked folders containing debug and error logs. Using credentials found in the configuration file, they tried to connect to an internal production database. Finally, they copied configuration files and logs into an upload folder that could be accessed through the website.
The AWS attacks moved quickly. AntiFox used valid IAM accounts and, in some cases, an assumed EC2 role. The attackers first checked their identity and permissions within AWS. They used commands such as GetCallerIdentity, GetUser, ListUsers, ListRoles, ListPolicies and ListKeys to discover available accounts, roles, policies and access keys. They also tried to obtain an authorization token for Amazon Elastic Container Registry (ECR).
In one intrusion, the source cycled through several AWS identities and sent hundreds of requests in about half an hour.
“The activity then rapidly enumerated services across the affected AWS environments, including IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB, and Amazon Bedrock, using List, Get, and Describe operations.” continues the report. “After authorization failures, the activity continued across other services and concentrated on resources that remained accessible.”
Most requests came back as AccessDenied, but a few worked, and the attackers kept going where the doors were open.
Some sequences ended with a successful GetSecretValue request against a production secret. Others focused on S3, listing buckets, objects and versions, reading objects, then copying and deleting them. Nobody has to stay awake for that kind of persistence, which is the whole point of the tool.
Arctic Wolf’s concern is simple. These frameworks make penetration testing techniques easier to reach for attackers, and they make those techniques faster and more consistent in live attacks.
For hunting, start with AWS activity coming from hosting providers the identity has never used. Look for one IP address using many access keys, users or roles in a short time, and for fast runs of List, Get and Describe calls across unrelated services, especially from Boto3 or Botocore. Check GuardDuty for odd IAM user behavior, credential access, discovery and unusual calls from hosting networks.
On the Windows side, watch for w3wp.exe starting cmd.exe, powershell.exe, whoami.exe, icacls.exe or archive tools. Look for new .aspx files in upload, temporary and image-conversion folders, and for config or log files saved there under .txt or image extensions. PowerShell commands that read WebConfigurationManager, ConnectionStrings or AppSettings deserve a close look, and so does any AWS activity that starts soon after.
Organizations should enable AWS CloudTrail logging and monitor access to sensitive S3 storage. They should also use S3 versioning and Object Lock to protect important data from deletion. Alerts should flag suspicious access to stored secrets, especially when it follows unusual account activity.
Companies should identify all internet-facing applications and prioritize patching and protecting file upload, conversion and document-processing services. If an IIS process launches an unexpected command shell, administrators should isolate the server, preserve logs and forensic evidence, remove malicious files and change all exposed credentials.
They should also revoke compromised AWS sessions and access keys, enforce IMDSv2 and apply least-privilege permissions to limit what applications can access. As Arctic Wolf warns, a series of mostly denied requests does not mean the attack was unsuccessful.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
Pierluigi Paganini
(SecurityAffairs – hacking, AI Pentest Tool AntiFox)