Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ujawniony w lipcu 2026 roku incydent związany z infrastrukturą tajlandzkiego Ministerstwa Finansów pokazuje nowy etap wykorzystania sztucznej inteligencji w operacjach ofensywnych. W centrum zdarzenia znalazł się otwartoźródłowy agent Hermes AI, którego nie użyto do uzyskania pierwszego dostępu do środowiska, lecz do automatyzacji działań prowadzonych już po kompromitacji systemu.
To istotna zmiana perspektywy. Zamiast traktować AI wyłącznie jako narzędzie pomocnicze do pisania skryptów czy analizy danych, należy coraz częściej postrzegać agentów zdolnych do wykonywania poleceń systemowych jako półautonomicznych operatorów, którzy przejmują żmudne zadania rozpoznawcze i administracyjne wykonywane dotąd ręcznie przez intruza.
W skrócie
- Atakujący uruchomił Hermes AI na serwerze pośredniczącym w trybie pozwalającym na samodzielne wykonywanie komend.
- Agent realizował typowe działania post-exploitation, w tym enumerację hosta, analizę systemu plików i wyszukiwanie ścieżek eskalacji uprawnień.
- Materiały wskazują na wcześniejsze osadzenie web shella oraz przygotowanie skryptów ukierunkowanych na środowisko Hadoop i HiveServer2.
- Nie potwierdzono publicznie eksfiltracji danych, ale incydent pokazuje praktyczne użycie AI do przyspieszania działań po włamaniu.
Kontekst / historia
Sprawa wyszła na jaw po odkryciu niechronionego serwera z włączonym listingiem katalogów. Na zasobie pozostawiono logi agenta, zestaw narzędzi ofensywnych oraz inne artefakty operacyjne, które umożliwiły badaczom odtworzenie części aktywności napastnika. Z dostępnych materiałów wynika, że operator dysponował już wcześniej dostępem do środowiska ofiary, a Hermes służył do automatyzowania kolejnych etapów działań.
W szerszym ujęciu incydent wpisuje się w rosnący trend praktycznego zastosowania modeli i agentów AI w cyberatakach. Wcześniej najczęściej mówiono o wykorzystaniu modeli językowych do przygotowywania treści socjotechnicznych, analizowania danych lub wspierania tworzenia skryptów. Tym razem kluczowe było przejście od wsparcia analitycznego do operacyjnego wykonawstwa, czyli realizacji sekwencji działań na zainfekowanym systemie bez ciągłej interwencji człowieka.
Analiza techniczna
Z ujawnionych informacji wynika, że Hermes został uruchomiony w trybie pracy umożliwiającym wykonywanie ryzykownych poleceń bez każdorazowego zatwierdzania. W praktyce oznacza to możliwość odbierania instrukcji, uruchamiania komend powłoki, analizowania rezultatów i kontynuowania działań na podstawie uzyskanych wyników.
Logi wskazują na klasyczny łańcuch aktywności post-exploitation. Agent miał wykonywać skrypty służące do wykrywania ścieżek eskalacji uprawnień w systemach Linux, wyszukiwać pliki oraz binaria z podwyższonymi uprawnieniami, listować zasoby i rekurencyjnie przeszukiwać katalogi dostępne z poziomu zainfekowanego hosta. W artefaktach pojawiały się także narzędzia enumeracyjne oraz elementy związane z lokalnymi scenariuszami podnoszenia uprawnień.
Szczególnie istotny był wątek środowiska Hadoop i usługi HiveServer2. Jeden z przygotowanych skryptów miał wykorzystywać konfigurację uwierzytelniania ustawioną w sposób niedający realnej weryfikacji hasła. W takim scenariuszu możliwe staje się dostarczenie złośliwego komponentu w formie biblioteki JAR implementującej funkcję użytkownika, a następnie wykonywanie poleceń systemowych za pośrednictwem zapytań do warstwy SQL. To nie tyle klasyczne włamanie do bazy, ile przekształcenie zaplecza analitycznego w punkt wykonania kodu na poziomie konta usługi.
Odzyskane materiały sugerowały również obecność web shella ukrytego w strukturze katalogów serwera WWW, testowanie domyślnych poświadczeń oraz składowanie dodatkowych implantów dla systemów Linux i Windows. Najważniejsze pozostaje jednak to, że Hermes pełnił głównie rolę automatycznego wykonawcy: odczytywał wyniki, ponawiał enumerację, przechodził przez kolejne katalogi i dokumentował stan środowiska w sposób przypominający nieprzerwaną pracę operatora terminala.
Konsekwencje / ryzyko
Największe znaczenie incydentu polega na obniżeniu kosztu operacyjnego działań po uzyskaniu dostępu do systemu. W tradycyjnym modelu intruz musi aktywnie sterować sesją, interpretować wyniki i ręcznie podejmować kolejne decyzje. W modelu wspieranym przez agenta AI duża część tych czynności może zostać zautomatyzowana, co skraca czas rozpoznania środowiska i zwiększa skalowalność kampanii.
Dla zespołów bezpieczeństwa oznacza to bardziej intensywne, ale pozornie znajome wzorce aktywności. Agent nie musi korzystać z egzotycznych technik. Wystarczy, że będzie wykonywać standardowe komendy administracyjne, uruchamiać popularne narzędzia audytowe i poruszać się po systemie w logicznej sekwencji. To utrudnia odróżnienie ręcznie sterowanego ataku od półautonomicznej aktywności wspieranej przez AI.
Dodatkowe ryzyko wynika z błędów konfiguracyjnych oraz nadmiernych uprawnień usług. Jeżeli komponenty takie jak HiveServer2 są wdrożone bez właściwego uwierzytelniania albo pozwalają na zbyt szerokie ładowanie dodatkowych bibliotek, mogą stać się dogodnym punktem do ruchu bocznego, wykonywania kodu i dostępu do dużych wolumenów danych. W sektorze publicznym konsekwencje mogą obejmować narażenie dokumentów wewnętrznych, danych kadrowych oraz informacji wspierających dalsze etapy operacji.
Rekomendacje
Organizacje powinny traktować agentów AI posiadających dostęp do powłoki, systemu plików i sieci jako nową klasę ryzyka operacyjnego. Takie narzędzia należy monitorować równie rygorystycznie jak frameworki zdalnej administracji, komponenty C2 czy zestawy używane przez zespoły red team.
- Zweryfikować konfigurację HiveServer2 oraz innych elementów ekosystemu Hadoop, zwłaszcza ustawienia uwierzytelniania i możliwość ładowania bibliotek JAR.
- Monitorować połączenia między warstwą serwerów WWW a usługami zaplecza analitycznego, w tym nietypowy ruch do portów administracyjnych i danych.
- Wzmocnić detekcję działań post-exploitation, takich jak seryjna enumeracja, przeszukiwanie web rootów, masowe listowanie katalogów oraz gwałtowny wzrost liczby poleceń wykonywanych przez pojedynczy proces lub konto.
- Aktualizować systemy Linux, ograniczać uprawnienia kont usługowych i regularnie przeglądać zasoby WWW pod kątem ukrytych skryptów i web shelli.
- Rozszerzyć threat hunting o artefakty charakterystyczne dla agentów AI, w tym katalogi wyników, przewidywalne nazwy logów, wzorce sesji terminalowych i iteracyjny sposób wykonywania poleceń.
Podsumowanie
Incydent z użyciem Hermes AI pokazuje, że skuteczne wykorzystanie sztucznej inteligencji w cyberatakach nie wymaga jeszcze w pełni autonomicznych systemów. Wystarczy agent, który po uzyskaniu przez intruza dostępu do środowiska potrafi konsekwentnie realizować długą serię znanych czynności technicznych bez ciągłego nadzoru człowieka.
Dla obrońców to wyraźny sygnał, że faza post-exploitation może stać się szybsza, tańsza i łatwiejsza do skalowania. Odpowiedzią powinno być połączenie bezpiecznej konfiguracji usług, twardego ograniczania uprawnień, monitoringu ruchu wewnętrznego oraz detekcji wzorców przypominających zautomatyzowaną aktywność operatora na powłoce.