AntiFox sfrutta server IIS e credenziali AWS per rubare segreti nel cloud

🛡️ Executive Summary

• Arctic Wolf documenta intrusioni associate ad AntiFox, framework open source di pentesting agentico, attraverso infrastrutture ospitate su Alibaba Cloud.
• Gli attaccanti hanno utilizzato web shell IIS e credenziali AWS valide per effettuare ricognizione, interrogare servizi cloud e accedere a un segreto di produzione.
• La campagna combina strumenti offensivi e operazioni autenticate. Non sono stati identificati la vulnerabilità iniziale, gli autori delle intrusioni o il grado esatto di autonomia dell’intelligenza artificiale.

AntiFox, piattaforma open source cinese dedicata al penetration testing agentico, compare in una serie di intrusioni informatiche documentate da Arctic Wolf Labs, nelle quali infrastrutture ospitate su Alibaba Cloud sono state associate a compromissioni di applicazioni web e ambienti Amazon Web Services. Gli attaccanti hanno utilizzato web shell su server Microsoft IIS, credenziali IAM legittime e interrogazioni automatizzate alle API AWS, arrivando in almeno un caso a recuperare un segreto di produzione attraverso Secrets Manager. La ricerca, pubblicata il 10 novembre 2026, mostra come strumenti progettati per le verifiche di sicurezza possano essere impiegati in operazioni malevole. Non dimostra tuttavia che AntiFox abbia eseguito autonomamente ogni fase dell’attacco né che Alibaba Cloud abbia partecipato consapevolmente alle intrusioni.

AntiFox e Alibaba Cloud: il pentesting agentico entra nelle intrusioni reali

AntiFox è una piattaforma open source, sviluppata prevalentemente in lingua cinese, che permette di organizzare attività di penetration testing attraverso componenti assistiti dall’intelligenza artificiale. Nel rapporto tecnico di Arctic Wolf Labs, i ricercatori descrivono infrastrutture pubbliche che ospitavano interfacce AntiFox e dalle quali provenivano attività malevole confermate contro applicazioni esposte su Internet e ambienti AWS. La disponibilità di strumenti di questo tipo riduce la complessità operativa necessaria per concatenare ricognizione, esecuzione di comandi, verifica delle credenziali e interrogazione dei servizi cloud. Il precedente di CyberXero, con un’infrastruttura comprendente 51 profili di agenti Claude Code e PentAGI, mostra una dinamica affine, pur riguardando un attore e una campagna distinti. Nel caso AntiFox, l’associazione tecnica con un framework agentico non certifica il livello di autonomia effettivamente raggiunto durante le intrusioni. Analogamente, la presenza di server su Alibaba Cloud identifica l’infrastruttura utilizzata, non la nazionalità degli operatori né un coinvolgimento del provider. Arctic Wolf non fornisce elementi sufficienti per attribuire queste operazioni a un gruppo APT o a un apparato statale.

Leggi anche: Agenti AI accelerano gli exploit: Chrome full-chain in sei giorni e bypass OTP

Server IIS compromessi: web shell ASPX e ricerca delle configurazioni

Una parte delle attività osservate riguarda un’applicazione Microsoft Internet Information Services (IIS) esposta pubblicamente. La telemetria raccolta da Arctic Wolf mostra il processo w3wp.exe, responsabile dell’esecuzione delle applicazioni web IIS, creare una web shell ASPX e avviare successivamente comandi del sistema operativo. Gli attaccanti hanno utilizzato strumenti ordinari come whoami per identificare l’utente in esecuzione e icacls per controllare i permessi, verificando inoltre la possibilità di scrivere file nella directory dell’applicazione. Il passaggio successivo ha riguardato la ricerca dei file web.config, delle copie di configurazione e dei log, con comandi PowerShell basati sulle classi .NET per estrarre impostazioni applicative e stringhe di connessione ai database. I ricercatori hanno osservato anche un tentativo di collegamento a un database interno di produzione attraverso credenziali recuperate dalla configurazione. La vulnerabilità utilizzata per ottenere inizialmente l’esecuzione di codice non è stata identificata, quindi non esiste una CVE specifica che possa essere attribuita con certezza alla campagna. La tecnica ricorda, per il ruolo centrale dell’infrastruttura IIS, il differente ecosistema BadIIS utilizzato per compromettere server Microsoft, senza che ciò dimostri alcun rapporto operativo tra i due casi. Il rischio emerge soprattutto quando un’applicazione web conserva credenziali utilizzabili per raggiungere risorse interne o servizi cloud.

Credenziali AWS valide: centinaia di richieste in circa trenta minuti

Le intrusioni documentate comprendono anche l’utilizzo di utenti IAM legittimi e, in alcune circostanze, ruoli EC2 assunti. In una delle attività osservate, un’origine associata ad AntiFox ha utilizzato più identità AWS per generare centinaia di richieste verso servizi differenti nell’arco di circa mezz’ora. Le interrogazioni iniziavano con operazioni di identificazione come GetCallerIdentity, GetUser, ListUsers, ListRoles e ListPolicies, proseguendo con controlli sulle autorizzazioni e sui servizi disponibili. Gli operatori hanno esplorato IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB e Bedrock. Molte chiamate hanno restituito AccessDenied, ma altre sono riuscite, permettendo di proseguire la ricognizione. Il dato importante non è soltanto il volume delle richieste: un’identità compromessa conserva le autorizzazioni effettivamente assegnate dall’organizzazione, anche quando viene utilizzata da una macchina sconosciuta. Una dinamica già osservata nelle intrusioni ScarletEel contro gli ambienti AWS, dove credenziali valide e funzionalità native del cloud permettevano di estendere la compromissione. Arctic Wolf precisa inoltre che, in alcune intrusioni, gli operatori disponevano già delle credenziali prima dell’attività osservata: non è quindi corretto ricondurre ogni accesso AWS alla stessa compromissione IIS.

Secrets Manager e S3: quando la ricognizione raggiunge i dati di produzione

Il risultato più significativo è rappresentato da una chiamata GetSecretValue riuscita contro un segreto di produzione in AWS Secrets Manager. Dopo aver interrogato servizi differenti e verificato i privilegi disponibili, l’attività ha raggiunto una risorsa riservata. Il recupero di un segreto rappresenta un passaggio concreto oltre la semplice enumerazione: può rendere disponibili credenziali o altri valori sensibili, secondo il contenuto della risorsa interessata. In altre attività Arctic Wolf ha identificato operazioni su Amazon S3, comprendenti ListBuckets, ListObjects, GetObject, CopyObject e DeleteObject, eseguite attraverso identità AWS valide. Questi eventi documentano l’utilizzo di funzionalità che permettono di consultare, copiare o cancellare oggetti, ma il rapporto non quantifica un’eventuale esfiltrazione complessiva né dimostra la cancellazione sistematica dei dati. Il percorso ricorda altri scenari in cui una vulnerabilità applicativa può condurre al recupero di identità cloud, come illustrato nell’analisi sul passaggio da SSRF alle credenziali AWS. Nel caso AntiFox, tuttavia, non è stato dimostrato che un attacco SSRF abbia costituito il vettore iniziale. Il problema comune è il collegamento tra applicazioni esposte, configurazioni sensibili e privilegi cloud eccessivamente estesi.

Indicatori AntiFox: porte, processi e comportamenti da monitorare

Arctic Wolf identifica due indirizzi associati all’infrastruttura osservata, 47[.]79[.]4[.]33 e 8[.]208[.]101[.]210, oltre alla porta TCP 8787, utilizzata comunemente dalle interfacce AntiFox. Il titolo dell’interfaccia individuata è AntiFox — 自主渗透测试控制台, mentre il relativo banner presenta l’hash MD5 c370d03542ed2ec696f7337940b14652e98e9bab. Questi indicatori devono essere contestualizzati: gli indirizzi di infrastrutture cloud possono essere riassegnati e la presenza di AntiFox non dimostra automaticamente un impiego criminale. Sul versante Windows, i segnali più rilevanti comprendono w3wp.exe che genera cmd.exe o powershell.exe, file ASPX inattesi nelle directory scrivibili e copie di configurazioni collocate in percorsi accessibili dal web. Nei log AWS, invece, occorre correlare molteplici identità utilizzate dal medesimo IP, richieste rapide a servizi differenti e accessi riusciti a Secrets Manager dopo numerosi dinieghi. Le sequenze vanno analizzate attraverso CloudTrail e GuardDuty, evitando di considerare innocua un’attività soltanto perché la maggioranza delle chiamate restituisce errori di autorizzazione. L’obiettivo non è individuare semplicemente uno strumento, ma riconoscere l’intera progressione operativa.

Continua con:

GitLab e AWS, l’AI diventa un control plane: RCE e credenziali a rischio

Gheist ruba i segreti GitHub: 13.500 branch malevoli e 850 account violati

Le difese per le aziende italiane devono collegare server web e identità cloud

Le organizzazioni italiane che utilizzano IIS, applicazioni ASP.NET e servizi AWS dovrebbero verificare congiuntamente la sicurezza dei server esposti e le autorizzazioni delle identità cloud. Arctic Wolf raccomanda di abilitare CloudTrail, includendo gli eventi dati S3 sui bucket sensibili, utilizzare il versioning e valutare Object Lock per proteggere gli oggetti critici da cancellazioni non autorizzate. Suggerisce inoltre di applicare il principio del minimo privilegio agli account IAM, imporre IMDSv2 alle istanze EC2 e controllare le configurazioni che conservano chiavi API, password e segreti. Quando una compromissione viene accertata, occorre isolare i server coinvolti, preservare log e artefatti forensi, rimuovere le web shell non autorizzate e revocare le credenziali compromesse, verificandone l’utilizzo precedente. AntiFox non introduce una nuova vulnerabilità universale di AWS o IIS: dimostra piuttosto quanto rapidamente strumenti offensivi, identità legittime e risorse cloud possano essere concatenati durante un’intrusione. La difesa deve quindi seguire la stessa catena, dal primo processo sospetto sul server web fino all’ultima operazione autorizzata nel cloud.