Hackers Abuse AntiFox AI Pentesting Tool to Deploy Webshells and Access AWS Production Secrets

Attackers are abusing AntiFox, an open-source AI penetration-testing platform, to compromise web applications, deploy webshells, and access Amazon Web Services production secrets.

Arctic Wolf linked the activity to Alibaba Cloud infrastructure hosting AntiFox interfaces, connecting those systems to malicious actions against internet-facing applications and associated AWS environments.

In one intrusion, attackers moved through multiple AWS identities and issued hundreds of API requests in approximately 30 minutes. Most requests failed, but successful operations exposed sensitive production secrets.

A separate incident involved unauthorized access to S3 objects, including reading, copying, and deleting stored data.

Researchers from GitGuardian noted the AntiFox activity in their analysis of AWS credential abuse, drawing on Arctic Wolf’s investigation.

Their findings place the attacks within a wider shift toward AI-assisted credential theft. AntiFox is a legitimate dual-use framework being misused, rather than a newly identified malware family.

Hackers Abuse AntiFox AI Pentesting Tool

AntiFox began as a fork of ARTEX 0.1.1 and provides a Chinese-language interface for deploying AI agents that automate security-testing tasks. Operators can direct agents to map exposed services and probe endpoints.

Earlier reporting on ARTEX enterprise attack automation explains how these systems interpret results and choose subsequent actions instead of requiring constant manual input.

In an observed intrusion, attackers deployed an ASPX webshell on an internet-exposed Microsoft Internet Information Services server. The IIS worker process created the shell, enabling operating-system command execution.

Attackers searched for application configuration files and backups, read database connection strings, inspected error logs, and copied configuration material into a web-accessible upload directory.

These actions created opportunities to obtain credentials and sensitive application information. Investigators also observed an attempt to connect to an internal production database using a credential extracted from application configuration.

However, the available reporting does not establish that every AWS intrusion began through an IIS webshell or explain how every credential was obtained.

For cloud access, attackers used valid AWS identities, including IAM users and assumed EC2 roles. They tested permissions across services such as S3, EC2, Lambda, Secrets Manager, and Amazon Bedrock.

This credential-driven approach echoes AI agent credential exposure risks, where configuration files and ordinary tool activity can expose secrets without exploiting a flaw in the cloud platform itself.

Most requests returned access-denied errors, but the activity continued toward accessible resources. Some sequences progressed to successful retrieval of production secrets.

AWS told BleepingComputer that its services were not compromised and operated as designed; attackers used credentials taken from customers’ compromised applications to access their accounts.

Detecting Credential Abuse and Containing Exposure

The main defensive lesson is that failed requests do not make an activity sequence harmless. Teams should review successful operations within bursts of denied calls and connect unusual cloud access with preceding web-server activity.

A single identity’s permissions can determine whether reconnaissance stops at discovery or reaches production data. GitGuardian’s separate testing helps explain the speed advantage.

An ARTEX build without a dedicated secrets scanner found eight of nine planted credentials using ordinary commands. It began searching within six to thirteen seconds.

Related coverage of exposed ARTEX testing servers highlights why defenders should investigate deployed tooling alongside the credentials it can reach.

Response should prioritize revoking affected AWS sessions and access keys, rotating exposed application credentials, and reviewing downstream access.

Removing a leaked secret from a repository or configuration file does not invalidate it. Teams must identify dependent production services before rotation to reduce disruption while closing unauthorized access.

Longer-term controls include narrowly scoped permissions, short-lived credentials, stronger secret scanning, and keeping long-term keys out of application configurations.

Reporting on GitHub cloud credential theft reinforces that exposed secrets remain valuable across different attack methods. AWS also recommends requiring IMDSv2 and enabling GuardDuty to strengthen protection and detection.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally Qdefanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Give your SOC the alert context on the latest threats to stop incidents quickly -> Integrate Threat Intel from 16K SOCs

The post Hackers Abuse AntiFox AI Pentesting Tool to Deploy Webshells and Access AWS Production Secrets appeared first on Cyber Security News.