AntiFox AI Pentesting Platform Linked to Attacks That Accessed AWS Production Secrets

Summary

Arctic Wolf Labs, as reported by The Hacker News on November 11, 2026, associated Alibaba Cloud systems hosting AntiFox interfaces with malicious intrusions against internet-facing web services and AWS environments. AntiFox is described as an agentic penetration-testing platform. The reported activity combined web compromise, configuration discovery, credential abuse, cloud enumeration, and access to sensitive cloud resources.^[0]

The web-side observations included a compromised IIS application, creation of an ASPX web shell by w3wp.exe, and subsequent command execution through that worker process. Commands searched application configuration and logs, extracted database connection information, attempted access to an internal production database, and staged configuration and log files in a web-accessible upload directory. The report establishes a database connection attempt and file staging, not successful database compromise or confirmed external retrieval of the staged files.^[0]

The cloud-side activity used valid IAM identities to validate credentials and enumerate numerous AWS services. Although most authenticated requests failed with AccessDenied, some operations succeeded, including GetSecretValue against a production secret. Separate activity involved S3 discovery and object operations. The precise IIS exploit and the acquisition method for AWS credentials in other attacks remained unknown, limiting reconstruction of a single end-to-end intrusion path.^[0]

The evidence supports malicious use associated with AntiFox-hosting infrastructure, but does not name the operators. AntiFox-specific operational details in the supplied material come from The Hacker News's account of Arctic Wolf's findings. The separate Check Point excerpt documents malicious use of ARTEX, a different platform, and provides context rather than independent confirmation of the AntiFox incidents.^[0][16]

Attack chain

1. 1. Web branch: compromise of an internet-facing IIS application: Some initial-access activity involved a compromised internet-facing IIS application. The precise vulnerability used to obtain code execution was not identified, so no particular exploit, CVE, or vulnerable version can be assigned to this phase.^[0]
2. 2. ASPX web-shell deployment and command execution: The IIS worker process w3wp.exe created an ASPX web shell, followed by command execution through the same process. Observed commands used whoami to identify execution context, enumerated the application directory, checked permissions with icacls, and tested the ability to write into the web root.^[0]
3. 3. Configuration discovery, credential use, and file staging: Post-compromise commands searched for web.config files and configuration backups, read application settings and database connection strings, and enumerated debug and error-log directories. The activity also attempted to connect to an internal production database with an extracted configuration credential and copied configuration and log files into a web-accessible upload directory. The report does not establish the relative ordering of every action within this phase.^[0]
4. 4. Cloud branch: access using valid AWS credentials: Other attacks began with a valid AWS credential obtained through an undetermined method. Valid IAM identities were then used to validate credentials and perform cloud discovery. This is a separately reported entry path; the evidence does not establish that all cloud access originated from credentials recovered on the IIS server.^[0]
5. 5. Broad authenticated AWS enumeration: The activity enumerated dozens of services, including IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Systems Manager, CloudWatch, and Amazon Bedrock. Most cross-service requests returned AccessDenied, while some discovery operations succeeded.^[0]
6. 6. Successful secret access and separate storage activity: In at least some instances, Secrets Manager enumeration was followed by a successful GetSecretValue request against a production secret. Elsewhere, a valid AWS identity performed S3 discovery and object operations. These are reported outcomes across the observed activity, not proof that every intrusion followed the same sequence.^[0]

Disclosure timeline

How it works

The concrete web-exploitation evidence concerns the execution context after application compromise rather than the underlying vulnerability. An ASPX web shell was created by w3wp.exe, and commands subsequently ran through that IIS worker process. Arctic Wolf interpreted this combination as suggesting compromise through the affected web application. The supplied reporting does not identify the request, payload, software defect, or CVE that first enabled code execution.^[0]

Application configuration provided material for further access attempts. Commands located web.config files and backups, read settings and database connection strings, and used an extracted credential in an attempted connection to an internal production database. Configuration and log files were also copied into a web-accessible upload directory. These observations support configuration harvesting and staging; they do not establish successful database access or completed exfiltration of the staged files.^[0]

The AWS activity relied on authenticated use of valid IAM identities rather than a disclosed AWS software vulnerability. Broad API enumeration encountered many authorization failures, but the identities retained sufficient access for some discovery and secret retrieval. A successful GetSecretValue request against a production secret is the clearest reported sensitive-data access outcome. S3 discovery and object operations were also observed, but the supplied account does not specify their complete operation set or data volume.^[0]

Key takeaways

• The decisive cloud finding is successful production-secret access, not merely broad AWS reconnaissance. Numerous AccessDenied responses coexisted with successful operations and should not be mistaken for an unsuccessful intrusion.^[0]
• Preserve the distinction between the IIS compromise path and attacks that began with already-valid AWS credentials. The supplied reporting does not establish a universal IIS-to-AWS credential chain.^[0]
• The underlying IIS vulnerability remains unidentified, and the supplied reporting provides no affected-version range or patch status. The empty affected-versions section reflects this evidence gap, not an assessment that the affected application was secure.^[0]
• AntiFox is the associated tool, not a named threat actor. Alibaba Cloud hosting identifies infrastructure context, not operator identity or nationality.^[0]
• The supplied AntiFox account does not provide actionable attacker IP addresses, domains, file hashes, or specific malicious file paths. Behavioral hunting is therefore better grounded here than an indicator blocklist.^[0]

Defensive actions

• Hunt for ASPX file creation by w3wp.exe and correlate it with command execution through the IIS worker process.: This process-and-file relationship is central to the reported IIS compromise. Prioritize accompanying PowerShell execution, whoami, icacls, application-directory enumeration, and web-root write tests rather than treating the presence of w3wp.exe alone as malicious.^[0]
• Investigate configuration harvesting and files copied into web-accessible upload directories on implicated IIS servers.: The observed commands searched web.config files, configuration backups, and debug or error logs, then staged configuration and log files in an upload directory. Identify the staged material and review whether it was subsequently requested; the source confirms staging but not external retrieval.^[0]
• Trace database credentials exposed through application configuration and review their use against internal production databases.: The activity attempted an internal production database connection using a credential extracted from configuration. Review the attempted authentication and any subsequent database activity, and replace implicated credentials as part of containment without assuming the reported attempt succeeded.^[0]
• Review AWS API activity by implicated IAM identities across both denied requests and successful operations.: Most observed requests returned AccessDenied, but some discovery and sensitive operations succeeded. Correlate broad service enumeration with successful Secrets Manager and S3 activity so that a large volume of authorization failures does not obscure the consequential requests.^[0]
• Contain implicated AWS credentials and investigate successful production-secret retrieval.: Valid AWS credentials enabled the reported activity, including successful GetSecretValue against a production secret. Revoke or replace credentials involved in unauthorized access, identify the retrieved secret, rotate its underlying credential where applicable, and investigate subsequent use of that credential.^[0]
• Review the effective Secrets Manager and S3 permissions of implicated IAM identities.: Authorization controls blocked many cross-service requests but still allowed some secret access and storage operations. Focus the permissions review on the resources and actions that actually succeeded, rather than interpreting widespread AccessDenied responses as complete containment.^[0]