AntiFox AI pentesting staat de laatste tijd in de schijnwerpers nadat onderzoekers een campagne hebben beschreven waarin de tool werd gebruikt om AWS-credencials te stelen en daarna door te bewegen in gecompromitteerde omgevingen. Daarbij gaat het niet alleen om eenmalige toegang, maar om een keten waarin web-exploitatie, web shelling en vervolgens cloud-ontdekking en secrets-diefstal samenkomen.
De bevindingen zijn afkomstig van Arctic Wolf Labs, die de koppeling tussen omgevingen met AntiFox-interfaces en bevestigde kwaadaardige acties beschrijft. De exacte softwarekwetsbaarheid voor initial access blijft daarbij vooralsnog onbekend, maar de aanvalspaden laten wel duidelijk zien hoe agentic tooling schaal en snelheid kan vergroten.
Wat is AntiFox AI pentesting?
AntiFox is een platform dat zichzelf positioneert als een autonome, AI-gedreven benadering van penetration testing. Het project is via GitHub te downloaden en wordt regelmatig geforkt en gestar’t, wat wijst op brede belangstelling. In de beschrijving van het platform wordt uitgelegd dat er een planner/worker-structuur werkt met meerdere agents die een opdracht uitvoeren van recon tot rapportage.
Waar veel automatisering vooral stopt na het “vinden”, legt AntiFox de nadruk op het omzetten van gevonden informatie in resultaten die reproduceerbaar zijn en met bewijs kunnen worden gedeeld. In praktijk kan dezelfde eigenschap bij misbruik juist helpen om sneller richting impact te gaan.
De waargenomen aanvalsketen: van web naar AWS
In meerdere waargenomen intrusies werd AntiFox gelinkt aan kwaadwillende activiteiten tegen internetgerichte webdiensten en de bijbehorende AWS-omgevingen. De onderzoekers beschrijven een aanpak waarin verschillende stappen na elkaar worden geschakeld: webexploits en het plaatsen van een web shell, gevolgd door configuratie-ontdekking, validatie van credencials, cloud-service enumeratie en uiteindelijk secret access en opslagoperaties.
Met andere woorden: de aanval lijkt ontworpen om zowel de route naar initial access als de route naar laterale beweging en gegevensroof te automatiseren.
Initial access via een IIS-context
Volgens Arctic Wolf is een deel van de initial access gekoppeld aan een gecompromitteerde, internetgerichte applicatie op Windows/IIS. Vanuit die positie wordt ingezet op het creëren van een ASPX web shell. Daarbij wordt verwezen naar het gebruik van w3wp.exe, het IIS-workerproces, om besturingssysteemcommando’s uit te voeren.
De commandoreeks die daarna wordt gezien, richt zich op het vinden van configuratiebestanden en back-ups (onder andere via het zoeken naar web.config), het uitlezen van applicatie-instellingen en database-connection strings, en het enumereren van log- en debuglocaties.
Secrets en verbindingen uit configuratiebestanden
Een opvallend onderdeel is dat geprobeerd wordt om verbinding te maken met een interne productie-database met een credenciaal dat uit de applicatieconfiguratie wordt gehaald. Vervolgens worden configuratie- en logbestanden gekopieerd naar een uploaddirectory die ook via het web bereikbaar is.
Op het gecompromitteerde IIS-systeem lijken commands via w3wp.exe ook het uitvoeringscontext en permissies te verifiëren. Zo wordt gekeken naar de huidige identiteit (whoami), wordt de applicatiemap geïnventariseerd, worden rechten gecontroleerd met icacls en wordt getest of schrijven naar de web root mogelijk is.
Doorstappen in AWS met misbruik van IAM-identiteiten
In andere gevallen begon de dreiging niet bij een webshell, maar met een geldig AWS-credential dat via een nog onbekende route werd verkregen. Vervolgens werden geldige IAM-identiteiten misbruikt om credencials te valideren en tientallen AWS-diensten te enumereren.
De onderzoekers noemen daarbij onder meer IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB en Amazon Bedrock.
In de meeste gevallen leidde een groot deel van de geauthenticeerde API-verzoeken tot AccessDenied. Toch vonden sommige discovery- en secret-accessactiviteiten wel succes, waaronder pogingen die verder gingen dan alleen enumeratie.
Van Secrets Manager naar GetSecretValue
In ten minste een deel van de aanvallen wordt beschreven dat de activiteit doorgroeide voorbij het opvragen van metadata uit Secrets Manager, tot een succesvolle GetSecretValue-actie tegen een productiegeheim. Daarnaast worden gevallen vermeld waarin een geldige AWS-identiteit werd ingezet voor S3-discovery en objectoperaties via API-aanroepen.
Dat maakt de dreiging extra ernstig: het gaat niet enkel om “kijken”, maar om het daadwerkelijk ophalen en mogelijk exfiltreren van gevoelige content.
Waarom agentic tooling de dreiging vergroot
De rode draad in deze rapportage is dat agentic frameworks penteststappen toegankelijker maken voor aanvallers. Door automatisering ontstaat consistentie: dezelfde technieken kunnen sneller worden herhaald en in live-intrusies kunnen meerdere stappen gelijktijdig of in een logische keten worden doorlopen.
Daarbij groeit ook de schaal. In plaats van één traject per persoon kan een aanvaller een doelwit- of doellijst opstellen en agenten het werk laten uitvoeren, inclusief het benutten van zwakheden en het navigeren door complexere aanvalspaden.
Vergelijkbare campagnes met AI-agenten
De disclosure plaatst AntiFox niet op zichzelf. Onderzoekers verwijzen naar een bredere trend waarbij aanvallers AI-aangedreven pentest- of agenttools gebruiken. Zo wordt de campagne Operation Ghost-Campus genoemd, waarin AI-agenten zouden worden gebruikt om langdurige toegang tot LLM-omgevingen te onderhouden en later geautomatiseerd frauduleuze activiteiten uit te voeren.
Ook wordt gewezen op platforms zoals ARTEX, dat door onderzoekers op meerdere locaties werd aangetroffen. Het is daarbij wel belangrijk om te benadrukken dat niet elke blootliggende console per definitie kwaadaardig is; misconfiguraties kunnen ook legitieme redenen hebben.
Wat kwaadwillenden meestal nastreven
De aanvallen waar de analyses zich op richten, lijken vaak op een beperkt aantal winstgerichte doelen. Denk aan het stelen van cryptovaluta, het compromitteren van accounts, het uitbuiten van zwakke authenticatie of ontbrekende beveiligingschecks, én het uitvoeren van denial-of-service-aanvallen tegen webdiensten.
In een specifiek voorbeeld met Apple code-signing certificaten wordt beschreven dat agenten op gecompromitteerde systemen zoeken naar certificaatdatabases, gestolen certificaten valideren en vervolgens gegevens gebruiken om applicaties te kunnen ondertekenen. In dat geval ging het zelfs om een klein aantal certificaten dat uiteindelijk volledig zou hebben gevalideerd.
Wat kun je vandaag doen tegen dit soort aanvallen?
Hoewel niet alle details over de gebruikte kwetsbaarheid bekend zijn, kun je wel gericht maatregelen nemen op de patronen die in de keten terugkomen: gecompromitteerde webapplicaties, web shelling, het uitlezen van configuratiebestanden en het misbruik van cloud-credentials voor service discovery en secret access.
1) Bescherm webapplicaties en detecteer web shell gedrag
Richt je op het verminderen van de kans op initial access: patch kwetsbaarheden, beperk internetexposure en zorg dat webapplicaties minimaal rechten hebben. Let daarnaast op tekenen van web shelling, zeker wanneer IIS-processen opvallend veel besturingscommando’s uitvoeren of bestanden in web-bereik plaatsen.
Meer context over aanvalspaden en software die doelen benadert via misbruik van beheer- en authenticatielagen vind je ook in deze analyse over een Xen Orchestra lek waarbij authenticatie werd omzeild.
2) Controleer toegang tot configuraties en credentials
De beschreven stappen draaien sterk om het verzamelen van configuration data. Zorg dat gevoelige configuraties niet onnodig leesbaar zijn en dat er strikte scheiding is tussen omgevingen en secretopslag. Overweeg daarnaast harde controles rond wie configuratie- en back-upbestanden kan raadplegen en uploaden.
3) Harden AWS: beperk, monitor en reduceer blast radius
Omdat de keten ook draait op het misbruiken van IAM-identiteiten, is principle of least privilege essentieel. Zet waar mogelijk policies die wild discovery beperken, en controleer of accounts en rollen alleen doen waarvoor ze bedoeld zijn.
Besteed extra aandacht aan diensten rond secrets: Secrets Manager en KMS. Log en alert op atypische aanvraagpatronen, vooral wanneer een rol eerst meerdere services enumereert en daarna direct naar secret value requests gaat.
4) Voer responsplannen door op “cloud pivot” scenario’s
De aanval is ontworpen om van web naar cloud te pivots. Dat betekent dat incident response niet stopt bij het webserver-alarm. Train teams op het snel onderzoeken van de cloud-kant: welke rollen werden gebruikt, welke API calls zijn gedaan en welke geheimen zijn benaderd.
Als je ook te maken hebt met geautomatiseerde recon- of exploitketens, is het leerzaam om te kijken naar eerdere analyses over exploit- en payloadpatronen, zoals reverse shells tegen Qlik Sense, waarin de nadruk ligt op wat aanvallers bereiken zodra ze code-executie hebben.
Conclusie
De koppeling tussen AntiFox AI pentesting en intrusies waarbij AWS-productiegeheimen worden benaderd, laat zien hoe agentic tooling de route naar impact kan versnellen. De beschreven keten combineert geautomatiseerde stappen: initial access via een internetgerichte webapplicatie, web shelling met IIS, het verzamelen van configuratiegegevens en vervolgens IAM-gebaseerde discovery en secret access.
Voor verdedigers is de kernboodschap helder: pak zowel de weblaag als de cloudlaag aan, beperk privilege en monitor op de combinatie van gedragspatronen. Alleen zo voorkom je dat “gevonden” informatie automatisch wordt omgezet in echte schade.
Bron: https://thehackernews.com/2026/11/antifox-ai-pentesting-platform-linked.html
