AntiFox AWS Credential Theft: Arctic Wolf Tracks ARTEX Fork in Live IIS Intrusions

On November 10, 2026, Arctic Wolf Labs published an open threat alert pack tying self-hosted AntiFox consoles on Alibaba Cloud to confirmed malicious activity against internet-facing Microsoft IIS applications and linked Amazon Web Services accounts. AntiFox is a Chinese-language, AGPL-3.0 agentic penetration-testing platform forked from ARTEX v0.1.1—the same lineage GitGuardian cataloged among roughly 45 open-source LLM attack loops on November 9. Arctic Wolf's cases are not a benchmark paper; they are field intrusions where agent-speed enumeration moved from ASPX webshells and web.config parsing to GetSecretValue against a production secret and S3 CopyObject/DeleteObject within bursts that lasted on the order of half an hour. If you run coding agents against repos that still embed cloud keys in application config, treat this as another data point that offensive agent harnesses and your benign agent share the same secret surfaces.

TL;DR

What Arctic Wolf documented

Arctic Wolf states it is tracking emerging use of self-hosted agentic penetration-testing frameworks, including AntiFox, from public cloud infrastructure. In several recently observed intrusions, Alibaba Cloud systems hosting AntiFox interfaces were associated with confirmed malicious actions against internet-facing web services and associated AWS environments.

The researchers emphasize a pattern that should sound familiar after Railway's ARTEX-class incident and Wiz's machine-speed cloud case studies: most individual API calls failed, but successful discovery and secret-access operations were embedded in the same burst. Arctic Wolf's guidance is blunt: do not assume an attack failed because most requests returned AccessDenied.

AntiFox background (mechanism, not marketing)

Per the AntiFox README, the platform is an AI-driven autonomous penetration-testing stack: a planner / worker / main-agent loop over a dual-graph architecture (global asset graph plus per-task exploration graph) that runs recon → attack-surface discovery → exploitation → finding capture → report delivery. Docker quick start exposes the operator UI on http://localhost:8787 with first-run setup at /setup.

AntiFox's publishers position delivery-quality .docx reports and evidence-linked traffic captures as differentiators versus discovery-only tools. Arctic Wolf's assessment is the defensive mirror image: frameworks like AntiFox make penetration-testing techniques more accessible to threat actors and increase the speed and consistency with which those techniques run in live attacks.

BleepingComputer's November 11 coverage adds that AntiFox remains on GitHub at v2.0 with improved reporting, while policy text forbids live use without technical enforcement—consistent with self-hosted consoles Arctic Wolf saw on commodity cloud hosts.

Attack chain step by step

Stage 1: Foothold on IIS or stolen AWS identity

Arctic Wolf describes two entry patterns:

1. Compromised internet-facing IIS application — endpoint telemetry showed w3wp.exe creating an ASPX web shell and running operating-system commands. The exact RCE vulnerability was not identified in the pack.
2. Valid AWS credential from unknown means — in other activity, the actor started with an already-valid cloud identity without a documented web exploit.

This split matters for developers: you may patch the web tier while keys leaked earlier still fuel AntiFox-linked bursts from Alibaba-hosted infrastructure.

Stage 2: Local discovery on the web server

On the IIS path, commands launched through w3wp.exe included:

• whoami for execution context
• Directory enumeration and icacls permission checks
• Writes into the web root to validate deployable shells

PowerShell then used .NET configuration classes to parse web.config connection strings and application settings. Arctic Wolf saw enumeration of debug and error-log directories and, in one case, an attempt to connect to an internal production database using a credential extracted from application configuration.

Defenders should treat System.Web.Configuration.WebConfigurationManager, ConnectionStrings.ConnectionStrings, and AppSettings.Settings references in PowerShell as high-signal hunts when spawned from w3wp.exe.

Stage 3: Staging secrets where the application can read them

Attackers copied configuration and log files into web-accessible upload directories, sometimes under .txt or image extensions. Arctic Wolf lists file patterns such as pwn*.aspx, cfg*.txt, wc*.txt, and el*.txt under user-writable paths—common in upload, image-conversion, or document-processing features.

That staging step is the bridge to AWS: many .NET deployments still keep SDK settings, access keys, or Secrets Manager references beside the code your coding agent edits daily.

Stage 4: AWS identity validation and cross-service spray

Once valid identities were available—IAM users and, in some cases, an assumed EC2 role—AntiFox-linked infrastructure issued authenticated API traffic including:

• Identity and permission discovery: GetCallerIdentity, GetUser, ListUsers, ListRoles, ListPolicies, ListKeys
• Service credential probes: including an attempted GetAuthorizationToken on Amazon ECR

Arctic Wolf ties the automation to scripting SDKs, publishing user-agent strings Boto3/1.43.125 and Botocore/1.43.125 as examples.

Stage 5: High-velocity enumeration across services

In one intrusion, the AntiFox-linked source cycled multiple AWS identities and generated hundreds of cross-service API requests within approximately 30 minutes. Enumerated services included IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB, and Amazon Bedrock, predominantly via List, Get, and Describe calls.

The sequencing matches what CrowdStrike described for ARTEX lineage operators: continue after denial, concentrate on resources that remain accessible, and treat the cloud control plane like a searchable graph.

Stage 6: Secret and object impact

Arctic Wolf confirms impact beyond noise:

• Progression from Secrets Manager enumeration to a successful GetSecretValue request against a production secret
• Sustained S3 activity: ListBuckets → ListObjects → HeadObject → GetObject, followed by CopyObject and DeleteObject

Those outcomes are why the pack recommends S3 versioning, Object Lock where appropriate, data events on sensitive buckets, and alerts on GetSecretValue from novel infrastructure.

Infrastructure indicators Arctic Wolf shared

The GitHub pack includes infrastructure and behavioral IoCs (not exhaustive—AntiFox is public and cloud IPs churn):

Port 8787 also appears in Censys reporting on exposed ARTEX-family consoles. AntiFox is another operator UI on the same port convention, which makes internet exposure of pentest dashboards a recurring pattern—not a one-off misconfiguration.

Hunting and response (from the primary pack)

Arctic Wolf's defensive guidance clusters into cloud, endpoint, and correlation work:

Cloud hunting

• API traffic from hosting providers or autonomous systems not previously associated with the identity
• One source IP using multiple access keys, IAM users, or assumed roles in a short window
• Rapid List/Get/Describe ladders across unrelated services, especially from a novel ASN, with Boto3/Botocore user agents
• GuardDuty categories: anomalous IAM user, credential access, discovery, compromised EC2 credentials, unusual API calls from hosting infrastructure

IIS and endpoint hunting

• w3wp.exe spawning cmd.exe, powershell.exe, whoami.exe, icacls.exe, or archive utilities
• New .aspx files in user-writable directories (upload, temp, image conversion)
• Config or log files copied into web roots under benign extensions

Correlation rule Arctic Wolf stresses

If a compromised web application stored AWS credentials, SDK configuration, deployment settings, or Secrets Manager references, malicious AWS use may begin shortly after configuration discovery.

Immediate actions

• Isolate web servers showing unexpected worker-process shells; preserve web roots, IIS logs, and endpoint telemetry before reimage where feasible
• Remove unauthorized ASPX artifacts; review all user-writable directories
• Revoke active AWS sessions and access keys for affected identities; read CloudTrail before reissuing credentials
• Rotate anything recovered from web.config, deployment artifacts, debug logs, environment variables, and backups—including database passwords and application secrets
• Enforce IMDSv2 with restrictive hop limits where instance roles are required; apply least privilege so workloads cannot list broadly across the account

Update (November 12, 2026): GitGuardian ties lab speed to live AntiFox cases

On November 11, 2026, GitGuardian published a dedicated AntiFox write-up that cross-references Arctic Wolf's pack and explains why machine-speed credential discovery is the recurring risk—not a missing CVE. GitGuardian reiterates that only four of roughly 45 cataloged agentic attack frameworks ship a named secrets scanner, yet offensive loops still reach keys because the model improvises with ordinary shell tools.

That post cites Guillaume Valadon's November 10, 2026 ARTEX lab experiment: a stock ARTEX build with no dedicated secret-scanning code recovered eight of nine planted credentials using git and grep, including an AWS key pair removed after one commit and a token on a side branch. Under a neutral “assess the security posture” prompt—with no explicit secrets instruction—the first hunting command landed six to thirteen seconds into the run. GitGuardian frames the same behavior Arctic Wolf saw in production: hundreds of AWS API calls in ~30 minutes, mostly denied, with GetSecretValue successes embedded in the burst.

If you rely on “we deleted the key from main” as remediation, this lab result is the counterexample: history and CI workflows remain in scope for agent loops whether the attacker runs AntiFox in Alibaba Cloud or your intern runs Claude Code on Friday's branch.

How this fits the ARTEX fork landscape

AntiFox is not the first ARTEX derivative to show up in incident reporting. Check Point's November reporting on ARTEX consoles, WorkOS's confirmed ARTEX breach narrative, and GitGuardian's Shodan counts for ARTEX-family fingerprints already established that open-source agent loops + exposed operator UIs scale abuse.

Arctic Wolf's November pack is the first vendor breakdown naming AntiFox specifically with IIS → AWS telemetry, GetSecretValue success, and S3 destructive object APIs in the same campaign style. It validates the catalog's warning: forks do not wait for permission refactors on the original repo.

For a wider ARTEX defensive stack, see Google and Mandiant's five-layer framing and Wiz's seven fingerprints of agentic attacks.

What this means if you run AI coding agents

Coding agents do not deploy AntiFox for you, but they accelerate the same mistakes Arctic Wolf exploited:

1. Secrets beside application code — when Copilot, Claude Code, or Codex refactors web.config, .env, or appsettings.json, keys often stay in place because the model optimizes for build green, not vault migration.
2. Symmetric loop architecture — your agent's tool loop (read file → run command → call API) is structurally similar to AntiFox's worker agents. Attackers simply aim the loop at your endpoints.
3. Shared cloud identities — if agents help debug AWS SDK errors, developers paste temporary keys into chat context or commit example configs that never get scrubbed—exactly the material IIS staging copied to readable paths.

Concrete checks today

• Search repos and deployment templates for AKIA, aws_secret_access_key, ConnectionStrings, and SecretsManager references agents recently touched
• Run aws sts get-caller-identity with application roles and confirm list permissions are not broader than the workload needs
• Enable CloudTrail and S3 data events on buckets holding build artifacts or agent-exported logs
• Review whether any internal pentest console (ARTEX, AntiFox, PentAGI, HexStrike MCP) is reachable from the internet on 8787 or neighboring ports—GitGuardian counted exposed consoles in November

If you host apps on platforms like Railway or other PaaS layers, pair this with Railway's October forensic report: agent-speed attackers chase the same environment-variable shapes whether entry is IIS or a build escape.

What Beam can and cannot do here

Beam runs on your developer machine and watches local coding-agent actions: heuristic skill and MCP config scans, optional PreToolUse deny on Claude Code and Codex, and redaction before persistence when events are stored locally. It does not ingest CloudTrail, monitor IIS w3wp.exe, or block Alibaba-hosted AntiFox consoles attacking your production tenant.

Where Beam still helps is upstream of Arctic Wolf's IIS staging step: flagging when your agent reads a config file containing AKIA patterns, attempts curl-to-bash from a new skill, or exfiltrates a .env after a prompt injection—patterns that overlap secret-hunting grades in GitGuardian's Provisioned frameworks. That is heuristic, hook-based coverage, not a replacement for cloud IAM guardrails or WAF coverage on upload endpoints.

Frequently asked questions

What did Arctic Wolf publish about AntiFox on November 10, 2026?

Arctic Wolf Labs released pack_alerts/202611-antifox-alibaba-hosted-platforms-facilitate-web-cloud-intrusions on GitHub, documenting intrusions where Alibaba Cloud systems hosting AntiFox interfaces were tied to malicious IIS and AWS activity, including successful GetSecretValue and S3 object operations.

What is AntiFox relative to ARTEX?

AntiFox is an AGPL-3.0 fork that began from ARTEX v0.1.1, per the AntiFox-AI/antifox README. It runs multi-agent recon-through-report workflows on TCP/8787 by default and requires PostgreSQL plus an Anthropic or OpenAI API key for the agent loop.

How fast did the AWS enumeration move?

In one intrusion Arctic Wolf describes, AntiFox-linked infrastructure cycled multiple AWS identities and issued hundreds of cross-service API requests within approximately 30 minutes, mixing AccessDenied responses with successful discovery and secret access in the same burst.

Did every AWS API call fail?

No. Arctic Wolf explicitly warns defenders not to assume failure when most calls are denied. Successful List, Get, and Describe operations—including GetSecretValue against a production secret—appeared within the same automated sequences.

Am I affected if I only run Claude Code or Codex locally?

Not because AntiFox targets your laptop IDE directly. You are in scope if your deployed apps store AWS keys in web.config, .env files, or CI artifacts that a compromised web tier or an attacker agent could read—the same material legitimate coding agents copy during refactors.

Is AntiFox still on GitHub?

Yes. BleepingComputer reported November 11, 2026 that AntiFox remains public at AntiFox-AI/antifox with v2.0 improvements to reporting. The README disclaims live use but does not describe technical enforcement, matching what Arctic Wolf observed from self-hosted consoles.

Related (November 12, 2026): Datadog's AWS field report documents the same credential class AntiFox hunts—long-term keys and public Cognito pools—via CloudTrail FilterLogEvents and artex-* user agents after web-tier compromise.

Related reading

• Datadog ARTEX AWS hunting: CloudWatch and Cognito abuse
• GitGuardian: ~45 agentic pentest frameworks and Shodan counts
• Railway October report: ARTEX-class agent speed
• Censys: exposed ARTEX consoles on port 8787
• Vapor Panda and ARTEX at scale
• Anatomy of an AI-driven cloud attack (Wiz CIRT)
• November 2026 attacks timeline
• Beam landing: what Beam watches on-device

Primary sources: Arctic Wolf Labs GitHub alert pack (2026-11-10) · AntiFox-AI/antifox README · BleepingComputer (2026-11-11)

IoCs, API names, and timing reflect Arctic Wolf's November 10, 2026 pack unless a linked vendor updates them later. AntiFox repository metadata may change with new releases on GitHub.