AntiFox AWS attacks reached production secrets

In the AntiFox AWS attacks, attackers retrieved a production AWS secret even as most of their hundreds of API requests were denied. Arctic Wolf linked the activity to infrastructure hosting AntiFox, tracing intrusions through compromised applications or already-valid credentials into cloud discovery, secret retrieval and S3 operations. Here’s how to investigate the application and AWS activity together, identify successful operations and contain exposed credentials.

For teams running internet-facing applications connected to AWS, the reporting gives a concrete reason to review the application and cloud account together. MLQ.ai’s account of Arctic Wolf’s November 10 report describes configuration discovery, credential validation, production-secret access and S3 copy and delete operations associated with Alibaba Cloud systems hosting AntiFox. The concern is not confined to the compromised application. It is also what that application’s credentials allow the attacker to do in AWS afterward.

How the AntiFox AWS attacks moved from IIS to secrets

In some of the observed intrusions, application configuration provided a route into cloud accounts. Arctic Wolf associated initial access with a compromised, internet-facing Microsoft Internet Information Services (IIS) application. The researchers did not identify the vulnerability used to obtain code execution, so the reported sequence starts with a compromised application rather than an identified exploit.

The Hacker News’ report on the findings describes the IIS worker process, w3wp.exe, creating an ASPX web shell and then executing operating-system commands. Digital Today’s explanation of the intrusion describes the shell as a control file through which an attacker can issue commands to the server.

The attacker searched for web.config files, configuration backups and logs. Commands located web.config files and configuration backups, read application settings and database connection strings, and inspected debug and error-log directories. The activity also included copying configuration and log files into a web-accessible upload directory. The searches were not limited to the application’s active configuration file.

In one case, the attacker extracted a credential from application configuration and attempted to use it to connect to an internal production database. The distinction between an attempt and a successful connection matters here: the reporting does not establish that the database connection succeeded. Other intrusions began with a valid AWS credential, and its original source was unknown.

I’d put configuration backups and logs inside the credential investigation, rather than leave them for later housekeeping. Arctic Wolf’s observations place those files directly in the collection path. A review limited to the active application configuration would miss material the attacker was also searching for and, in the case of copied files, collecting into a web-accessible location.

Repeated AccessDenied errors did not stop secret retrieval

Denied requests and successful operations appeared in the same activity. The denials did not establish that the intrusion had failed. Arctic Wolf observed AntiFox-linked infrastructure using IAM users and, in some cases, an assumed EC2 role to validate credentials and test access across AWS services.

According to Arctic Wolf’s findings, reported by SecurityBrief, one intrusion cycled through multiple AWS identities and generated hundreds of cross-service API requests in about half an hour. Most of those requests were denied. Successful discovery and secret-access operations still appeared among them, which is the part of the sequence that a failure-heavy view of the activity can obscure.

The requests covered IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, EKS, Amazon Bedrock and other services. Repeated AccessDenied responses did not end the testing: the actor continued checking available permissions through List, Get and Describe operations.

A successful GetSecretValue request against a production secret was the consequential result. Researchers also observed S3 discovery and object operations, including GetObject, followed by CopyObject and DeleteObject activity. Some sequences therefore went beyond discovering what was present to retrieving a secret or acting on objects.

For the AntiFox AWS attacks, I would start triage with the requests that succeeded and what each identity could access. Successful secret retrieval and object operations deserve priority, with the denied requests retained as context for the wider sequence. The large volume of denied requests simply must not hide the smaller number of actions that worked.

Hunt for the IIS-to-AWS sequence

Arctic Wolf recommends examining endpoint behaviour and cloud activity together. The reported signals below give that review specific starting points, from the IIS worker process to the AWS operations that succeeded.

On the AWS side, Arctic Wolf specifically recommends looking for hosting providers or autonomous systems not previously associated with an identity. Scripting-oriented software development kits such as Boto3 or Botocore provide additional context. That context is particularly relevant when the SDK use appears alongside rapid requests across unrelated services, rather than as an isolated label in the activity.

Review the source infrastructure, identities used, requested operations and successful results as a sequence. Apply the same approach on the server: connect suspicious worker-process activity with newly created files and configuration discovery, instead of treating each event as a separate investigation.

The unknown IIS entry point limits patch advice

The reports do not establish which IIS vulnerability enabled the initial code execution. In some incidents, they also leave the origin of the valid AWS credentials unresolved. With those gaps, there is no defensible basis for recommending one specific IIS patch as the answer to this campaign. The reported activity supports investigating the application and credentials, but it does not identify that patch.

AWS separately rejected the interpretation that its services themselves had been compromised:

“AWS services were not compromised and operated as designed.”

— Adam Montgomery, AWS Senior PR Manager, quoted by SecurityBrief

Montgomery attributed the account access to credentials taken from customers’ compromised applications. That distinction has a practical consequence for the response. Closing the application entry point does not remove the need to review the exposed identities and their permissions; that work remains necessary even after the entry point is closed.

Arctic Wolf linked malicious activity to infrastructure hosting AntiFox interfaces. I would not take that link as proof that an artificial intelligence (AI) model independently chose every individual action. The reporting supports an automated attack chain. It does not supply a complete decision history showing how each operation was selected.

The infrastructure indicators come with a separate limit: Arctic Wolf warns that cloud IP addresses may be reassigned. An address match needs context, not a permanent verdict attached to that address. Organisations without IIS also have reason to review relevant AWS identity activity. Not every observed intrusion began with an identified IIS compromise, so the absence of IIS does not settle that part of the review.

Contain exposed AWS identities and harden the application path

Where the evidence indicates compromise, Arctic Wolf’s advice covers the affected server and the cloud credentials. The following response sequence keeps both in view.

1. Isolate affected web servers and revoke exposed AWS access. Arctic Wolf recommends quickly isolating compromised servers and revoking affected sessions and access keys. Keep the investigation broader than the identity that made the successful request. The researchers observed a single source cycling through multiple identities, so that successful request is not the only identity activity to review.

2. Rotate credentials exposed through application material. Arctic Wolf explicitly includes web.config, deployment artefacts, logs and environment variables in its rotation advice. Review those sources, and include configuration backups and copied files when determining what may have been exposed. Removing the web shell addresses the shell, but it does not address credentials the attacker has already obtained.

3. Establish which cloud operations succeeded. Review successful secret retrieval and S3 object activity alongside the denied discovery requests, rather than allowing the denied requests to dominate the review. Arctic Wolf recommends enabling CloudTrail management events and S3 data events for sensitive buckets, plus alerting on successful GetSecretValue calls from unfamiliar infrastructure. Keep that visibility work distinct from the immediate task of revoking exposed access.

4. Reduce the permissions and credential exposure available to applications. AWS recommends least-privilege permissions, requiring IMDSv2 on EC2 instances, keeping long-term access keys out of application configurations and enabling Amazon GuardDuty. These recommendations address the credential path described in the research. They do not depend on identifying AntiFox by name before taking action on that path.

5. Review S3 protection where object operations were observed. Arctic Wolf recommends enabling S3 versioning and, where appropriate, Object Lock. Assess that advice against the reported copy and delete operations. S3 protection complements the identity response; it does not replace revoking exposed access, nor does it replace investigating which objects were affected.

For a team without evidence of compromise, a targeted review of application credential storage, identity permissions and the detection signals above is the practical starting point. AWS also recommends that customers who suspect unauthorised account activity follow its compromised-credential remediation guidance or contact AWS Support.

I’d prioritise the credential path and successful cloud operations over building the response around the AI label. In the AntiFox AWS attacks, an application compromise or an already-valid credential was enough to begin testing permissions, and repeated denials did not prevent access to a production secret. A connected IIS-and-AWS investigation, followed by containment covering both systems and identities, addresses that sequence. Start by reviewing the successful secret and S3 operations alongside the identities that issued them, then revoke the exposed access.