AWS secret access sharpens questions over AntiFox-linked intrusions

Arctic Wolf found attackers probing a compromised IIS application and using valid AWS credentials, including to retrieve a production secret. Links to infrastructure hosting AntiFox interfaces do not prove the platform was responsible.

Arctic Wolf Labs has linked malicious activity against exposed web applications and AWS environments to Alibaba Cloud infrastructure hosting interfaces for AntiFox, an open-source AI-assisted penetration-testing platform. The researchers’ findings point to two routes into victim environments: a compromised Microsoft IIS application and AWS access using valid credentials whose original source remains unknown. They do not establish that AntiFox itself was responsible for every intrusion connected with the hosting infrastructure.

In the IIS-related activity, attackers used the web server’s worker process, w3wp.exe, to install an ASPX web shell and run commands. They searched for application configuration files and backups, examined database connection details and inspected diagnostic logs. Sensitive files were then copied to a directory accessible over the web. The operators also tried to use a credential found in the application material to reach an internal production database. Arctic Wolf said the vulnerability that enabled the initial compromise had not been identified.

Separate activity began with valid AWS credentials. The operators authenticated through IAM identities, sometimes using an assumed EC2 role, and queried a wide range of cloud services. Most requests across services were rejected, but Arctic Wolf recorded successful S3 discovery and object operations, alongside a successful Secrets Manager GetSecretValue request against a production secret. AWS documentation explains that this operation can return a secret’s stored contents to an authorised caller, making such access more consequential than merely identifying that a secret exists.

AntiFox’s public project materials describe an AI-assisted testing system built on ARTEX, with agents intended to coordinate reconnaissance, identify attack surfaces, run tests and compile findings. The repository makes the software and its documentation publicly available, but its stated purpose and capabilities do not establish how it was used in the incidents. ARTEX’s own documentation describes a multi-agent design that divides work between planning and execution, with supporting tools and oversight mechanisms; autonomy does not necessarily mean that human supervision is absent.

The findings sit within a broader shift towards agentic offensive security tools. Google Cloud Threat Intelligence Group has reported real-world misuse of frameworks including ARTEX and PentAGI, describing activity that has extended from reconnaissance and scanning to intrusion and persistence. Google characterises adversary use as early-stage and often noisy, while warning that more autonomous operations may develop. Its analysis covers multiple frameworks and campaigns, however, and does not independently verify the AntiFox-specific incidents.

The case illustrates how attackers can combine an initial foothold with exposed application settings and cloud identities to seek access beyond the system first compromised. Even where broad cloud enumeration is blocked, a single permission that allows access to a production secret or storage object may expose material useful for further intrusion. The observed links to infrastructure hosting AntiFox interfaces therefore raise questions about the misuse of agentic security tooling, while leaving the precise role of the platform in these incidents unresolved.

Source Reference Map

Inspired by headline at: ^[1]

Sources by paragraph:

Source: Fuse Wire Services