AntiFox wykorzystywany do kradzieży poświadczeń AWS i ataków na serwery IIS - Security Bez Tabu

AntiFox wykorzystywany do kradzieży poświadczeń AWS i ataków na serwery IIS

Cybersecurity news

Wprowadzenie do problemu / definicja

AntiFox to otwartoźródłowa, chińskojęzyczna platforma do zautomatyzowanych testów penetracyjnych, określana jako narzędzie agentowe. Tego typu rozwiązania potrafią łączyć wiele etapów ataku w jeden półautomatyczny lub w pełni zautomatyzowany łańcuch działań. Problem pojawia się wtedy, gdy narzędzia projektowane do legalnych testów bezpieczeństwa zostają zaadaptowane przez cyberprzestępców do rzeczywistych włamań, rozpoznania środowisk chmurowych oraz eksfiltracji danych.

W skrócie

W ostatnich incydentach AntiFox był wykorzystywany do ataków na publicznie dostępne aplikacje IIS oraz środowiska AWS. Napastnicy używali infrastruktury chmurowej do hostowania interfejsów narzędzia, a następnie prowadzili rekonesans, uzyskiwali dostęp do plików konfiguracyjnych, wyszukiwali danych uwierzytelniających i wykonywali szeroką enumerację usług AWS.

W części przypadków skutkiem było pozyskanie sekretów produkcyjnych oraz operacje na zasobach S3, obejmujące odczyt, kopiowanie i usuwanie obiektów. To pokazuje, że AntiFox może wspierać zarówno etap wejścia do środowiska, jak i dalszą eskalację działań po uzyskaniu dostępu.

Kontekst / historia

Automatyzacja ofensywnych działań w cyberbezpieczeństwie nie jest nowym zjawiskiem, ale rozwój narzędzi agentowych wyraźnie obniża próg wejścia dla atakujących. Zamiast ręcznie wykonywać każdy krok po kompromitacji hosta lub konta, operator może uruchomić gotowy zestaw procedur obejmujących rozpoznanie, walidację uprawnień, identyfikację poufnych plików, analizę konfiguracji i eksplorację usług chmurowych.

W analizowanych przypadkach widoczne były dwa główne scenariusze wejścia. W pierwszym atak rozpoczynał się od kompromitacji publicznej aplikacji IIS. W drugim napastnicy dysponowali już ważnymi poświadczeniami AWS, choć źródło ich pozyskania nie zostało jednoznacznie ustalone. To istotne, ponieważ wskazuje, że AntiFox nie musi służyć wyłącznie do uzyskania dostępu początkowego, ale także do szybkiego rozwijania ataku po przejęciu tożsamości lub serwera.

Analiza techniczna

W środowiskach IIS zaobserwowano powtarzalny łańcuch aktywności. Proces roboczy IIS, czyli w3wp.exe, tworzył powłokę webową ASPX, a następnie uruchamiał polecenia systemowe służące do rozpoznania hosta. Obejmowało to identyfikację użytkownika, przeglądanie zawartości katalogów aplikacji, sprawdzanie uprawnień plików przy użyciu icacls oraz testowanie możliwości zapisu do głównych katalogów serwisu.

Kolejnym etapem było użycie PowerShell do odczytu pliku web.config, który często zawiera krytyczne informacje operacyjne, takie jak connection stringi, ustawienia aplikacji i dane dostępu do zaplecza. Napastnicy analizowali również katalogi z logami błędów i debugowania, ponieważ mogą one ujawniać strukturę aplikacji, dane uwierzytelniające, ścieżki systemowe lub szczegóły integracji z usługami zewnętrznymi.

Po pozyskaniu danych z konfiguracji podejmowano próby połączenia z wewnętrzną bazą produkcyjną, a wybrane pliki konfiguracyjne i logi były kopiowane do katalogów dostępnych z poziomu witryny. Taki sposób działania zwiększał szansę na dalszą eksfiltrację danych oraz uproszczenie kolejnych etapów ataku.

W warstwie chmurowej działania były jeszcze bardziej agresywne. Po użyciu prawidłowych tożsamości IAM, a w niektórych przypadkach również po przejęciu roli EC2, wykonywano szybkie sprawdzenie kontekstu bezpieczeństwa i uprawnień.

  • Weryfikowano tożsamość i aktywne uprawnienia.
  • Enumerowano użytkowników, role, polityki i klucze.
  • Sprawdzano dostępność usług i zasobów w wielu obszarach AWS.
  • Testowano ścieżki dostępu do sekretów oraz magazynów obiektowych.

Aktywność obejmowała między innymi IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB oraz Amazon Bedrock. W praktyce oznacza to zautomatyzowane sprawdzanie, które zasoby da się odczytać, opisać lub wykorzystać. Nawet jeśli wiele żądań kończyło się błędem odmowy dostępu, narzędzie kontynuowało pracę tam, gdzie napotykało skuteczne ścieżki.

Szczególnie niebezpieczne były sytuacje, w których sekwencja kończyła się pobraniem sekretu produkcyjnego. W innych przypadkach nacisk kładziono na S3: listowanie bucketów, przegląd obiektów i wersji, odczyt danych, a następnie kopiowanie lub usuwanie plików. Tego rodzaju aktywność wskazuje na połączenie rekonesansu, eksfiltracji i potencjalnego sabotażu.

Konsekwencje / ryzyko

Największe zagrożenie wynika z szybkości i skali działania. Narzędzia agentowe potrafią w krótkim czasie wykonać setki żądań do wielu usług i automatycznie dostosowywać się do warunków środowiska. Dla organizacji oznacza to, że nawet częściowo skuteczny incydent może błyskawicznie przejść od kompromitacji pojedynczego serwera WWW do ekspozycji sekretów, danych aplikacyjnych, konfiguracji chmurowej i zasobów magazynowych.

Z perspektywy obrony szczególnie groźne są trzy elementy:

  • wykorzystanie legalnych poświadczeń, co utrudnia odróżnienie ataku od aktywności administracyjnej,
  • masowe wywołania typu list, get i describe, które mogą zostać błędnie uznane za niegroźny rekonesans,
  • dostęp do plików konfiguracyjnych, logów i sekretów produkcyjnych, umożliwiający ruch boczny, trwałą obecność i dalsze przejęcie środowiska.

Ryzyko biznesowe obejmuje utratę poufności danych, kradzież poświadczeń, nieautoryzowane użycie zasobów chmurowych, usuwanie danych z S3, zakłócenie działania aplikacji oraz wzrost kosztów reagowania na incydent i rotacji kluczy.

Rekomendacje

Organizacje powinny traktować publicznie dostępne aplikacje IIS i tożsamości AWS jako wspólną powierzchnię ataku. W praktyce oznacza to konieczność korelacji telemetrycznej między systemami Windows, warstwą aplikacyjną i logami chmurowymi.

W środowiskach Windows należy monitorować sytuacje, w których w3wp.exe uruchamia cmd.exe, powershell.exe, whoami.exe, icacls.exe lub narzędzia archiwizujące. Wysoki priorytet powinny mieć również nowe pliki .aspx tworzone w katalogach uploadu, folderach tymczasowych i lokalizacjach związanych z konwersją dokumentów lub obrazów.

W AWS kluczowe znaczenie ma pełne logowanie aktywności oraz wykrywanie nietypowych wzorców użycia tożsamości. Szczególną uwagę warto zwrócić na:

  • logowania i wywołania API z nietypowych sieci hostingowych,
  • użycie jednego adresu IP do obsługi wielu kluczy, użytkowników lub ról w krótkim czasie,
  • szybkie sekwencje wywołań w wielu niepowiązanych usługach,
  • próby dostępu do Secrets Manager po wcześniejszej enumeracji IAM i zasobów obliczeniowych,
  • nietypowe operacje na S3, zwłaszcza łączące odczyt, kopiowanie i usuwanie obiektów.

Od strony prewencyjnej należy stosować zasadę najmniejszych uprawnień, wymuszać rotację i natychmiastowe unieważnianie skompromitowanych kluczy, ograniczać uprawnienia ról instancji oraz wdrażać wersjonowanie i mechanizmy ochrony przed usuwaniem w S3. W środowiskach aplikacyjnych priorytetem powinno być łatanie usług uploadu plików, komponentów konwersji dokumentów oraz wszystkich publicznych punktów wejścia obsługujących dane użytkownika.

Jeżeli istnieje podejrzenie kompromitacji IIS, zalecane jest natychmiastowe odizolowanie serwera, zabezpieczenie artefaktów śledczych, usunięcie web shelli, przegląd plików konfiguracyjnych pod kątem ekspozycji sekretów oraz wymiana wszystkich danych uwierzytelniających, które mogły zostać ujawnione. W przypadku AWS niezbędne jest unieważnienie aktywnych sesji, przegląd polityk IAM i dokładna analiza dostępu do sekretów oraz bucketów S3.

Podsumowanie

Przypadek AntiFox pokazuje, że nowoczesne narzędzia do automatyzacji testów penetracyjnych mogą zostać bardzo skutecznie zaadaptowane do rzeczywistych włamań. Ich wartość ofensywna nie wynika z pojedynczej techniki, lecz z możliwości szybkiego łączenia rekonesansu, analizy uprawnień, ekstrakcji konfiguracji i eksploracji chmury w jeden zautomatyzowany proces.

Dla zespołów bezpieczeństwa kluczowy wniosek jest prosty: seria odrzuconych żądań nie oznacza nieudanego ataku. Wystarczy kilka skutecznych operacji na sekretach, konfiguracji lub zasobach S3, aby incydent przerodził się w poważne naruszenie bezpieczeństwa.

Źródła

  • https://securityaffairs.com/202880/hacking/ai-pentest-tool-antifox-abused-to-steal-aws-credentials.html
  • https://github.com/rtkwlf/wolf-tools/tree/main/pack_alerts/202611-antifox-alibaba-hosted-platforms-facilitate-web-cloud-intrusions
  • https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
  • https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
  • https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html