AntiFox tool drives IIS & AWS attacks, Arctic Wolf warns

Arctic Wolf Labs has published research on the use of the AntiFox penetration-testing platform in attacks on IIS web services and AWS environments. The researchers linked the activity to infrastructure hosted on Alibaba Cloud.

They found attackers used the open-source, Chinese-language framework to automate a chain of actions spanning web exploitation and cloud-account access. In the observed cases, the activity included deploying web shells on compromised Microsoft IIS servers, extracting application and database settings, and quickly using valid AWS identities to probe services and seek access to secrets and stored data.

One notable feature was the pace of the activity. In one intrusion, infrastructure linked to AntiFox cycled through multiple AWS identities and generated hundreds of cross-service API requests in about half an hour, combining denied requests with successful discovery and secret-access operations.

On compromised IIS systems, endpoint telemetry showed the w3wp.exe process creating an ASPX web shell and then launching operating-system commands. Those commands identified the execution context, inspected application directories, tested write permissions and located web.config files and configuration backups.

PowerShell commands then parsed web.config connection strings and application settings through .NET configuration classes. The activity also reviewed debug and error-log directories and, in one case, attempted to connect to an internal production database with a credential taken from the application configuration.

The exact vulnerability used to gain code execution on the exposed web server was not identified. In some incidents, the starting point appeared to be the IIS application. In others, the actor began with a valid AWS credential obtained through unknown means.

AWS activity

Once valid cloud identities were available, the intrusions moved into AWS discovery. Arctic Wolf said AntiFox-linked infrastructure used authenticated requests with IAM users and, in some cases, an assumed EC2 role to validate credentials and test permissions across a wide range of services.

The observed API activity included GetCallerIdentity, GetUser, ListUsers, ListRoles, ListPolicies and ListKeys, alongside an attempted Amazon ECR GetAuthorizationToken request. The request patterns suggest automated testing of collected credentials, with the actor continuing across services even after repeated AccessDenied responses.

Service enumeration extended across IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB and Amazon Bedrock. The activity relied on List, Get and Describe operations to identify what remained available to each identity.

In some cases, that process led to successful access to production data. In one intrusion, the activity progressed from Secrets Manager enumeration to a successful GetSecretValue request against a production secret.

Researchers also observed sustained S3 activity using valid identities. That included discovery and object operations through API calls such as ListBuckets, ListObjects, ListObjectVersions, HeadObject and GetObject, followed by CopyObject and DeleteObject operations.

Defensive steps

The findings are likely to draw attention from organisations running internet-facing applications tied to cloud workloads, particularly where application configuration files may hold AWS credentials, SDK settings or references to Secrets Manager. The research suggests that once an exposed web application is compromised, cloud activity can begin soon after configuration discovery.

Arctic Wolf advised security teams to look for AWS API activity from hosting providers or autonomous systems not previously associated with a given identity. Teams should also review cases where a single source IP uses multiple AWS access keys, IAM users or assumed roles in a short period.

The research also highlighted the value of investigating rapid bursts of List, Get and Describe operations across unrelated AWS services, especially when they originate from unfamiliar hosting infrastructure and use scripting-oriented AWS software development kits such as Boto3 or Botocore.

For web servers, the group recommended hunting for IIS worker processes spawning tools such as cmd.exe, powershell.exe, whoami.exe and icacls.exe. Defenders should also monitor user-writable web directories for newly created ASPX files and suspicious copies of configuration or log files placed in web-accessible locations under altered extensions.

Other steps highlighted in the research included enabling CloudTrail management events and S3 data events for sensitive buckets, turning on S3 versioning and, where appropriate, Object Lock, and alerting on successful GetSecretValue activity from unfamiliar infrastructure. The report also recommended quickly isolating affected web servers, revoking exposed AWS sessions and access keys, and rotating credentials found in web.config files, deployment artefacts, logs and environment variables.

Arctic Wolf said organisations should not assume an attack has failed simply because many API calls were denied, as successful discovery and secret-access operations can appear within the same burst of automated requests.