Hackers use AntiFox AI agents in AWS credential-theft attacks

Summary

Arctic Wolf observed malicious activity associated with Alibaba Cloud systems hosting self-managed AntiFox interfaces. AntiFox is an open-source agentic penetration-testing platform, and the associated infrastructure was used for vulnerability exploitation, webshell deployment, credential validation, configuration discovery, and AWS secret harvesting. The reporting establishes a connection between AntiFox-hosting infrastructure and malicious operations, but does not identify the operators behind these incidents.^[0]

The reported activity crossed web-server and cloud boundaries. One case involved an ASPX webshell on an internet-exposed IIS server, operating-system command execution, access to application settings and database connection strings, and copying configuration and log files into a web-accessible directory. AWS activity involved valid IAM identities and, in some cases, assumed EC2 roles. In one intrusion, the attacker cycled through identities and made hundreds of API requests in about 30 minutes; most attempts were blocked, but some succeeded and exposed production secrets. A separate incident included reading, copying, and deleting S3 objects.^[0]

The immediate defensive priorities are to correlate IIS compromise evidence with unusual AWS access, inspect successful API operations hidden within denial-heavy bursts, revoke affected sessions and keys, and rotate credentials exposed in application files. The supplied evidence does not identify a specific vulnerability, affected version range, patch, or actionable attacker indicator. Consequently, the findings support behavior-based investigation and credential containment rather than a product-specific patch directive or an infrastructure blocklist.^[0]

Attack chain

1. Webshell deployment: In the highlighted IIS intrusion, the attacker deployed an ASPX webshell on an internet-exposed server. The reporting does not identify the vulnerability or access mechanism that enabled deployment.^[0]
2. Operating-system command execution: Following webshell deployment, the reported activity included execution of operating-system commands on the IIS server.^[0]
3. Application configuration access: The same case included access to application settings and database connection strings. These accesses are reported as part of the server compromise; the article does not establish that every AWS identity used elsewhere originated from these files.^[0]
4. Web-accessible file staging: The attacker copied configuration and log files into a web-accessible directory. This establishes staging in an exposed location, but the supplied account does not separately document retrieval of those staged files.^[0]

Disclosure timeline

How it works

The concrete web-server exploitation mechanism described is an ASPX webshell on IIS, accompanied by operating-system command execution and access to application configuration material. Copying configuration and log files to a web-accessible directory created an exposed staging location. The reporting does not identify the initial software flaw, exploit request, or authentication condition that allowed the webshell to be placed.^[0]

The cloud-side mechanism was authenticated identity abuse: infrastructure associated with AntiFox used valid IAM users and, in some cases, assumed EC2 roles to call AWS APIs. One intrusion involved cycling through multiple identities during hundreds of requests in roughly 30 minutes. Most attempts were blocked, but successful operations obtained production secrets. The described mechanism is misuse of valid AWS identities, not a demonstrated bypass of AWS authentication.^[0]

In a separate incident, a valid AWS identity was used for S3 object reads, copies, and deletions. This observation establishes object-level access and modification activity, but the supplied reporting does not specify the affected buckets, object names, data volume, or how that identity was initially obtained.^[0]

Key takeaways

• AntiFox is a tooling and infrastructure association in this reporting, not a named threat actor. References to other ARTEX-related attacks do not establish attribution for these AntiFox-linked incidents.^[0]
• A high proportion of blocked AWS requests did not prevent compromise: successful calls within the same activity obtained production secrets. Investigators should assess successful operations rather than treating a denial-heavy burst as evidence of containment.^[0]
• The evidence supports a combined web-server and cloud-identity investigation, but not a fully reconstructed chain connecting every webshell action, credential source, secret retrieval, and S3 operation. The S3 activity was explicitly described as a separate incident.^[0]
• No specific vulnerable version, patch, or actionable attacker indicator is supplied. AntiFox's availability and version history describe the tool, not an affected-product version range for defenders to patch.^[0]

Defensive actions

• Correlate IIS webshell findings with unusual AWS activity associated with the affected environment.: The reported intrusions combined internet-facing web-service compromise with authenticated AWS access, and Arctic Wolf specifically recommended correlating IIS webshell activity with unusual cloud access.^[0]
• Review successful AWS API calls within bursts dominated by denied requests.: One intrusion generated hundreds of requests across multiple identities in about 30 minutes. Although most attempts failed, some succeeded and obtained production secrets, making denial counts alone an incomplete measure of impact.^[0]
• Revoke affected AWS sessions and access keys.: The activity relied on valid AWS identities, including IAM users and assumed EC2 roles. Revoking affected sessions and keys is an explicit containment recommendation in the reporting.^[0]
• Rotate credentials exposed through application files and assess the configuration material accessed on compromised IIS servers.: The attacker accessed application settings and database connection strings and staged configuration files in a web-accessible directory. The reporting explicitly recommends rotating credentials exposed through application files.^[0]
• During IIS investigation, examine the web-accessible directory used to stage configuration and log files.: File staging in such a directory was a concrete behavior in the highlighted intrusion. Examining those files can help establish which configuration and operational material was placed in an exposed location.^[0]
• Review S3 read, copy, and delete operations performed by identities implicated in the suspicious activity.: A separate reported incident used a valid AWS identity for all three operations. Investigation should therefore account for object copying and deletion as well as access to secrets.^[0]