AntiFox: agentowy framework AI do testów penetracyjnych powiązany z kradzieżą sekretów AWS

Wprowadzenie do problemu / definicja

AntiFox to oparty na sztucznej inteligencji framework do automatyzacji testów penetracyjnych, zaprojektowany jako system agentowy zdolny do prowadzenia rekonesansu, identyfikacji powierzchni ataku, prób eksploatacji oraz generowania wyników w sposób zbliżony do pracy zespołu red team. Najnowsze ustalenia badaczy pokazują jednak, że narzędzia tego typu coraz częściej przekraczają granicę między legalną automatyzacją bezpieczeństwa a praktycznym wsparciem działań cyberprzestępczych.

W skrócie

Badacze bezpieczeństwa powiązali platformę AntiFox z incydentami, w których dochodziło do kompromitacji publicznie dostępnych usług webowych oraz dalszego ruchu bocznego do środowisk AWS. W obserwowanych atakach wykorzystywano przejęcie serwera IIS, wdrożenie powłoki webowej ASPX, odczyt plików konfiguracyjnych, ekstrakcję poświadczeń oraz enumerację usług chmurowych. W części przypadków aktywność doprowadziła do uzyskania dostępu do sekretów produkcyjnych w AWS Secrets Manager, co znacząco podnosi poziom ryzyka dla organizacji utrzymujących aplikacje hybrydowe i cloud-native.

Kontekst / historia

Nadużywanie ofensywnych narzędzi wspieranych przez AI rozwija się od kilku lat, ale dopiero niedawno zaczęło przyjmować wymiar operacyjny. Współczesne frameworki nie ograniczają się już do prostego skanowania czy korelacji wyników. Coraz częściej wykorzystują architekturę wieloagentową, w której poszczególne komponenty odpowiadają za planowanie, eksplorację, wykonanie kolejnych kroków ataku i dokumentowanie rezultatów.

AntiFox wpisuje się właśnie w tę kategorię. Narzędzie zostało opisane jako autonomiczna platforma pentesterska, zdolna do realizacji pełnego łańcucha działań ofensywnych. Problem polega na tym, że mechanizmy przydatne w autoryzowanych testach bezpieczeństwa są równie użyteczne dla operatorów prowadzących nieuprawnione włamania. W praktyce oznacza to obniżenie progu wejścia dla napastników oraz zwiększenie tempa działań po uzyskaniu pierwszego punktu zaczepienia.

Analiza techniczna

Z dostępnych informacji wynika, że część incydentów rozpoczynała się od kompromitacji internetowo dostępnej aplikacji działającej na Microsoft IIS. Po uzyskaniu wykonania kodu atakujący uruchamiali działania za pośrednictwem procesu w3wp.exe, czyli standardowego procesu roboczego IIS. Następnie tworzono web shell w technologii ASPX, co umożliwiało zdalne wykonywanie poleceń systemowych.

Po ustanowieniu trwałego dostępu realizowano etap rozpoznania lokalnego. Obejmował on identyfikację kontekstu wykonania, enumerację katalogów aplikacji, weryfikację uprawnień do zapisu oraz wyszukiwanie plików web.config i ich kopii zapasowych. To szczególnie istotny etap, ponieważ właśnie w takich plikach często przechowywane są connection stringi, dane logowania do baz danych, parametry środowiskowe oraz odwołania do usług zewnętrznych.

Kolejnym krokiem było odczytywanie ustawień aplikacji i łańcuchów połączeń do baz danych, a także przegląd katalogów debug i logów błędów. W części przypadków napastnicy podejmowali próby połączenia z wewnętrzną bazą produkcyjną przy użyciu poświadczeń wyekstrahowanych z konfiguracji aplikacji. Zaobserwowano również kopiowanie plików konfiguracyjnych i logów do katalogów dostępnych przez interfejs webowy, co mogło uprościć eksfiltrację danych bez konieczności stosowania bardziej zaawansowanych kanałów dowodzenia.

Równolegle lub w dalszej fazie incydentu wykorzystywano ważne tożsamości IAM w AWS. Dzięki nim prowadzono walidację poświadczeń oraz szeroką enumerację usług chmurowych, obejmującą między innymi IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation oraz DynamoDB. Choć wiele żądań kończyło się odmową dostępu, część operacji zakończyła się powodzeniem.

Najbardziej niepokojący element stanowiły skuteczne wywołania umożliwiające dostęp do sekretów produkcyjnych. Oznacza to, że atak nie kończył się na rozpoznaniu konta czy mapowaniu uprawnień, lecz przechodził do fazy pozyskiwania danych o wysokiej wartości. W innych przypadkach obserwowano również działania na zasobach S3, w tym operacje rozpoznawcze i pracę na obiektach poprzez wywołania API.

Technicznie rzecz biorąc, AntiFox nie musi samodzielnie zawierać kompletnego exploita dla każdej fazy ataku. Jego przewaga wynika z możliwości łączenia kolejnych czynności w spójny łańcuch decyzyjny: od pozyskania dostępu, przez analizę środowiska, aż po wybór najbardziej obiecujących ścieżek eskalacji i eksfiltracji. To zmienia charakter zagrożenia z pojedynczych, ręcznie sterowanych incydentów na półautonomiczne kampanie prowadzone z dużą powtarzalnością.

Konsekwencje / ryzyko

Dla organizacji kluczowe ryzyko wynika z połączenia dwóch obszarów: podatnych aplikacji webowych i nadmiernie uprzywilejowanych środowisk chmurowych. Jeśli aplikacja internetowa ma dostęp do wrażliwych sekretów, baz danych lub zasobów AWS, kompromitacja warstwy webowej może stać się bezpośrednią drogą do przejęcia środowiska produkcyjnego.

Poświadczenia przechowywane w plikach konfiguracyjnych lub logach zwiększają ryzyko szybkiej eskalacji.
Rola aplikacyjna w AWS z nadmiernie szerokimi uprawnieniami ułatwia enumerację i dostęp do zasobów.
Brak ścisłego modelu least privilege dla Secrets Manager, S3 i baz danych rozszerza skutki incydentu.
Serwery IIS dopuszczające zapis do lokalizacji dostępnych z poziomu aplikacji sprzyjają wdrożeniu web shelli.
Monitoring ograniczony do warstwy hosta może nie wykryć korelacji działań lokalnych i chmurowych.

Dodatkowym zagrożeniem jest skala. Agentowe narzędzia ofensywne potrafią automatyzować nie tylko rozpoznanie, ale też selekcję celów, testowanie ścieżek ataku i priorytetyzację kolejnych ruchów. W efekcie atakujący może równolegle prowadzić działania przeciwko wielu organizacjom, przy mniejszym nakładzie pracy ręcznej i większej spójności operacyjnej.

Rekomendacje

Organizacje powinny traktować ten typ zagrożenia jako połączenie ryzyka aplikacyjnego, systemowego i chmurowego. Skuteczna obrona wymaga działań wielowarstwowych.

Przeprowadzić przegląd publicznie dostępnych aplikacji internetowych, zwłaszcza uruchomionych na IIS, pod kątem zdalnego wykonania kodu, nieautoryzowanego uploadu plików, błędów uwierzytelniania i nieprawidłowych uprawnień do katalogów.
Usunąć sekrety z plików konfiguracyjnych wszędzie tam, gdzie to możliwe, i przenieść je do dedykowanych systemów zarządzania sekretami.
Wymusić korzystanie z krótkotrwałych poświadczeń oraz minimalnych uprawnień dla aplikacji i ról IAM.
Objąć środowiska AWS ścisłym monitoringiem aktywności IAM i API, ze szczególnym uwzględnieniem nietypowej enumeracji usług oraz wywołań do Secrets Manager, KMS i S3.
Wdrożyć detekcję zachowań charakterystycznych dla kompromitacji IIS, takich jak uruchamianie poleceń przez w3wp.exe, tworzenie plików ASPX w nietypowych lokalizacjach czy odczyt web.config poza normalnym profilem aplikacji.
Ograniczać skutki potencjalnego włamania poprzez segmentację, separację środowisk i szybką rotację sekretów, kluczy, tokenów oraz connection stringów.

Podsumowanie

Przypadek AntiFox pokazuje, że agentowe platformy AI do testów penetracyjnych mogą stać się realnym narzędziem wspierającym włamania do środowisk produkcyjnych. Największym problemem nie jest sama automatyzacja, lecz zdolność takiego oprogramowania do szybkiego łączenia rozpoznania, eksploatacji, walidacji poświadczeń i dostępu do zasobów chmurowych. Dla obrońców oznacza to konieczność ściślejszego powiązania bezpieczeństwa aplikacji webowych z kontrolą tożsamości i sekretów w chmurze.