AntiFox Attacks Reached AWS Production Secrets. Recover the Credentials Behind Them Too

A cloud key can be the first stolen credential in an incident, rather than the last. Arctic Wolf Labs reports intrusions associated with infrastructure hosting AntiFox, an agentic penetration-testing platform, in which valid AWS identities were used to explore services and successfully retrieve a production secret. Its report is dated 10 November; BleepingComputer and The Hacker News covered the findings on 11 November.

For the person coordinating recovery, there are two jobs: stop the identity that read the secret, then replace what that secret unlocks. Closing the first route leaves the second credential usable until the service that accepts it rejects it.

What the researchers observed

Arctic Wolf describes valid IAM users and assumed EC2 roles making AWS requests. Many requests failed, but successful operations appeared among the denials, including a production GetSecretValue call. In an IIS intrusion, the researchers observed a web shell, access to application configuration and database connection strings, and copies of files placed in a web-accessible directory. Other activity involved S3 object operations.

These are the researchers' observations. The two newsrooms independently report and interpret that research; they do not provide a second set of victim telemetry. The initial IIS vulnerability and the origin of some AWS credentials remain unknown. The report does not establish a victim count, attribution or that an AI agent performed every step without human intervention.

Build the recovery list from access, not from the first alert

Start a restricted incident ledger with a row for each affected identity and a row for each secret it could read. Record the owner, receiving system, exposure window and replacement status. Use resource names and secret version identifiers; leave the values themselves out of the ledger. A responder needs to know which database password changed, not see the password in a shared spreadsheet.

Review successful operations alongside failures. A long list of denied requests is useful evidence about permissions, but one successful read can create a separate recovery task. Distinguish a secret that was retrieved, one that was reachable with the affected identity, and one for which there is no evidence of access. That distinction makes the investigation honest while letting the incident lead choose a cautious rotation scope.

Ask the application owner about additional copies: deployment configuration, old releases, diagnostic exports and backups. Replacing a value in the current deployment does not tell you whether an earlier copy was exposed or whether another service still accepts it.

Contain access, then replace the downstream credentials

Stop the source of access. Isolate compromised workloads and disable affected access keys. Preserve evidence through your incident process before rebuilding.
Handle role sessions explicitly. AWS documents a separate mechanism to deny permissions to role sessions issued before a cutoff. It affects legitimate sessions too. Contain the path that permits new role assumptions as well; the cutoff does not block later sessions.
Rotate at the accepting service. AWS defines Secrets Manager rotation as updating both the stored secret and the database or service credential. Changing only the stored string leaves the original password valid at its destination.
Reconnect the legitimate consumers. Identify every application, integration and scheduled job using the old value. Give each an owner and verify its replacement before retiring a controlled overlap, if your service supports one.
Test both outcomes. Confirm normal access works with the replacement and that the old credential is rejected. Record the result and time without recording either value.

Do not turn incident chat into the replacement secrets store

A busy response channel is a tempting place to paste a new connection string. It also gives every channel member, integration and retained export another copy. Keep coordination in the channel and send the value only to its intended recipient. Verify that person through an established contact route, especially when an urgent request arrives during the incident.

Use a trusted device for the handover. If the recipient is restoring a workload, install the replacement in its runtime secrets store and keep it out of shell history, screenshots and support tickets. A short-lived transfer link reduces the period in which someone can retrieve the handover; it does not shorten the credential's lifetime at the database. Choose that lifetime separately.

Where Secretus helps

Secretus can carry a replacement text secret between people with browser-side encryption and a link that becomes invalid after expiry or first successful access. That is useful for a verified administrator receiving a temporary recovery credential. Use your cloud controls and secrets manager to revoke access, rotate credentials and serve applications. A transfer tool cannot make a compromised recipient device safe or invalidate a value someone already copied.

The same distinction matters in our earlier coverage of Microsoft's GitHub-to-Azure secret theft research: recovering the first identity is only the start of tracing what it could unlock.