AntiFox-Linked AWS Attacks Access Secrets Despite Blocked API Calls

Attackers accessed an Amazon Web Services (AWS) production secret despite hundreds of denied API requests during activity linked to infrastructure hosting AntiFox, an AI-powered penetration-testing platform. Arctic Wolf Labs disclosed the findings on November 10, 2026, after investigating intrusions involving web applications and cloud environments.

In one intrusion, operators made hundreds of AWS API requests across multiple identities in approximately 30 minutes. Most failed, but a successful GetSecretValue request retrieved a production secret from AWS Secrets Manager. The findings highlight the risk of credential abuse and successful operations going unnoticed amid authorization failures.

AntiFox-linked intrusions expose AWS secrets

Arctic Wolf's investigation, reported by The Hacker News, connected Alibaba Cloud infrastructure hosting AntiFox interfaces to malicious activity involving Microsoft Internet Information Services (IIS) applications and AWS accounts.

AntiFox is an open-source framework derived from ARTEX 0.1.1, previously implicated in AI-assisted credential-theft campaigns. Researchers have not determined which AntiFox-linked actions were autonomous or identified a specific threat group.

In one incident, attackers exploited an unidentified IIS vulnerability. The w3wp.exe worker process created an ASPX web shell, enabling command execution. Attackers accessed application settings, database connection strings, and configuration files.

Separate AWS activity involved valid identities used to enumerate services, including IAM, S3, and Secrets Manager. Research identified thousands of exposed AWS access keys that remained active, illustrating the risks of compromised credentials. The precise methods used to obtain the AWS credentials in the AntiFox-linked attacks have not been established.

Another incident involved unauthorized S3 object reads, copies, and deletions. In a November 12 statement to BleepingComputer, AWS said its services were not compromised, attributing the activity to credentials obtained from compromised customer applications.

CloudTrail gaps complicate AWS investigations

AWS CloudTrail threat detection requires examining successful operations alongside denied requests. Correlating identities, assets, and related alerts helps security operations teams manage alert volume without overlooking sensitive activity.

AWS CloudTrail documentation confirms that Event History retains 90 days of management events per Region but excludes data events. Secrets Manager API calls generate CloudTrail records without exposing secret values.

S3 object operations, including GetObject and DeleteObject, require separately configured data-event logging. AWS's S3 logging guidance confirms these events are not recorded by default. Logging enabled after an intrusion cannot recover previously uncollected activity.

Detecting and containing AWS credential abuse

Security teams should prioritize evidence collection, credential containment, and controls that limit unauthorized access.

• Investigate AWS activity: Correlate successful GetSecretValue requests with denied operations, unfamiliar IP addresses, and rapid enumeration across identities.
• Inspect IIS applications: Hunt for unexpected ASPX files, suspicious w3wp.exe activity, and unauthorized configuration access. Restrict application-pool privileges.
• Contain compromised credentials: Disable exposed keys, revoke affected sessions where supported, rotate secrets, and investigate unauthorized IAM changes.
• Strengthen identity controls: Restrict Secrets Manager access, enforce least privilege, replace embedded credentials with temporary workload identities, and apply appropriate network restrictions.
• Improve logging and recovery: Verify CloudTrail coverage, enable S3 data-event logging, and monitor GuardDuty findings. Protect critical objects with S3 Versioning and appropriate Object Lock controls.
• Test incident response plans: Simulate credential theft and unauthorized secret access to validate detection, containment, evidence preservation, and recovery.

The Cloud Security Alliance's analysis supports correlating identity, API, and infrastructure evidence rather than relying on isolated indicators. Investigators should verify successful API operations before closing an incident based on predominantly denied requests.

Read more: The Zeabur breach involving exposed application credentials shows why credential rotation and recovery checks must extend to services connected to a compromised hosting platform.