CyberStrikeAI w akcji: orkiestrator LLM uzyskał uprawnienia administratora domeny w placówkach edukacyjnych w Ameryce Łacińskiej i Afryce

2 listopada 2026 r. Kaspersky opublikował raport Securelist i komunikat prasowy opisujące włamania do organizacji sektora edukacji w kilku krajach Ameryki Łacińskiej i Afryki, w których działania po eksploituacji były kierowane przez duży model językowy. Narzędziem był CyberStrikeAI, otwartoźródłowy framework do testów penetracyjnych napisany w Go, którego serwer dowodzenia i kontroli hostuje LLM, który wybiera narzędzia i pisze polecenia, podczas gdy zwykły implant wykonuje je na zaatakowanym hoście. W jednym przypadku, który Kaspersky rekonstruuje szczegółowo, ludzki operator dostał się przez przejęty Microsoft SQL Server, zrobił dwutygodniową przerwę, a następnie pozwolił agentowi działać: konta administratora domeny zostały przejęte w ciągu trzech–czterech dni, a ostatni etap — ruch boczny, masowe zrzucanie poświadczeń i eksport bazy danych — zakończył się w ciągu godziny. Kaspersky nie podaje nazwy żadnej instytucji ani kraju, nie podaje liczby ofiar i twierdzi, że zaobserwował tę aktywność między wrześniem a październikiem 2026 r. Pełny zapis tej kampanii, wraz z nadaną jej oceną ciężkości, oceną pewności i pełną listą źródeł, znajduje się w Orca AI Incident Archive, obok pozostałych wpisów dotyczących włamań wspomaganych przez AI.

Co Kaspersky faktycznie opublikował

Dokument podstawowy to „CyberStrikeAI w rzeczywistych warunkach: wykorzystanie AI w rzeczywistych atakach na organizacje”, opublikowany w Securelist 2 listopada 2026 r.; jego autorami są Kirill Antonov, Vladislav Vlasov i Dmitry Chizhmak z zespołu badawczego ds. zagrożeń firmy Kaspersky. Towarzyszy mu własny komunikat prasowy firmy Kaspersky wydany tego samego dnia, który podsumowuje te same ustalenia. Ocena wiarygodności A przyznana w archiwum opisuje, jak dobrze te dwa dokumenty są ze sobą zgodne i jak szczegółowe są dane techniczne; nie jest to stwierdzenie, że druga organizacja niezależnie zweryfikowała włamanie.

Relacje wtórne w tym raporcie nie wskazują tej drugiej organizacji. Cybersecuritynews.com, Cyberpress, SecurityOnline oraz mający siedzibę w Nairobi TechTrends Kenya opublikowały relacje między 2 a 3 listopada 2026 r., a każda z nich opiera się na komunikacie Kaspersky'ego, a nie na własnym śledztwie; artykuł kenijskiego medium zbudowano wokół tego samego cytatu z komunikatu prasowego Nikity Nazarowa, szefa Threat Exploration w Kaspersky. Na dzień 9 listopada 2026 r. żaden poszkodowany uniwersytet, ministerstwo edukacji ani krajowy zespół reagowania na incydenty komputerowe nie potwierdził publicznie tych wtargnięć, a Kaspersky nie ujawnił tożsamości ofiar. Ten brak sam w sobie jest częścią zapisu: szczegółowo udokumentowano techniki działania, a nie szkody wyrządzone jakiejkolwiek nazwanej instytucji.

Oświadczenie Kaspersky'ego o zakresie jest celowo wąskie. Potwierdzone ofiary to, jak to ujęto, „organizacje z sektora edukacji w kilku krajach Afryki i Ameryki Łacińskiej”. Nie podano, ile ich było, w których krajach ani jak w ogóle wykryto kampanię — jedynie, że zespół natrafił na nią „w ramach proaktywnego monitorowania zagrożeń”.

Jedno rozróżnienie ma tu znaczenie, ponieważ łatwo je zatrzeć. Niezależne organizacje poinformowały już o CyberStrikeAI w rzeczywistych włamaniach — ale nie w tych włamaniach. Team Cymru powiązało infrastrukturę obsługującą to narzędzie z kampanią ze stycznia–lutego 2026 r. wymierzoną w ponad 600 urządzeń FortiGate, zaobserwowawszy 21 unikalnych adresów IP obsługujących ją między 20 stycznia a 26 lutego 2026 r. Jednostka TrendAI firmy Trend Micro w badaniu opublikowanym 23 października 2026 r. opisała operatora uruchamiającego 44 skoordynowane agenty CyberStrikeAI, które w krótkim oknie tego października poddały co najmniej 19 możliwych do zidentyfikowania organizacji, w tym co najmniej 16 w Japonii, działaniom walidacyjnym. Nota badawcza Cloud Security Alliance z 28 października 2026 r. zestawia oba przypadki i stwierdza, że żadne opublikowane źródło nie powiązało jeszcze odrębnych kampanii CyberStrikeAI z jednym aktorem. Ten zbiór prac potwierdza przesłankę — że ten framework jest wykorzystywany do atakowania rzeczywistych sieci — i nie mówi nic o ofiarach wśród placówek edukacyjnych w Ameryce Łacińskiej i Afryce w raporcie Kaspersky’ego.

Narzędzie, a także to, gdzie tak naprawdę siedziała AI.

CyberStrikeAI, jak opisuje go Kaspersky, to „open-source’owa, modularna platforma napisana w Go do automatyzacji testów penetracyjnych”. Jego kluczowym wyborem projektowym jest to, że cała warstwa inteligentna znajduje się na serwerze kontrolnym atakującego, a nie na maszynie ofiary. Narzędzia do rozpoznania i eksploatacji, zarządzanie webshellami, przydzielanie zadań agentom oraz odczytywanie wyników są udostępniane modelowi jako narzędzia MCP w ramach jednego procesu serwera, a to model decyduje, które z nich wywołać jako następne.

Implant to druga połowa i jest celowo głupi. Kaspersky pisze, że jest to „klasyczny agent C2 bez funkcjonalności AI — bez kluczy API, bez wywołań API usług AI i bez autonomicznej logiki”. Odpytuje listener przez HTTP/S, TCP lub WebSocket, wykonuje polecenia powłoki i dotyka systemu plików. Nie jest modelem działającym w sieci ofiary i nigdy nie kontaktuje się z dostawcą AI. Podział pracy opisuje zdanie, którym Kaspersky wyjaśnia cały schemat: „Decyzje są rozdzielone na dwa poziomy: operator określa zadanie ogólnie, a model decyduje, jak je wykonać”.

Kontrola człowieka zostaje zachowana, a nie wyeliminowana. Kaspersky zwraca uwagę na mechanizm human-in-the-loop, w ramach którego „operator zachowuje pełną kontrolę nad procesem”, a polecenia generowane przez model „mogą wymagać ręcznej akceptacji lub korekty przed ich wykonaniem”. Kroki pisze AI; człowiek wciąż może je odrzucić.

Jedno zrekonstruowane wtargnięcie, w kolejności, w jakiej datuje je Kaspersky

Raport opisuje pojedynczy incydent w ramach kampanii, a jego pierwsza faza wygląda jak zwykła ręczna praca przy klawiaturze. Polecenia w systemach ofiary pochodziły z procesu sqlservr.exe, wskazując na „skompromitowany SQL Server (wersja 16.0.1000)” jako prawdopodobną drogę wejścia. Operator następnie zebrał podstawowe informacje o hoście, wdrożył narzędzia i ręcznie zmapował sieć. Zajęło to „prawie dzień”, po czym atakujący ucichli na około dwa tygodnie.

Druga faza to moment, w którym zmienia się tempo. Po wdrożeniu agenta CyberStrikeAI utrzymanie dostępu i rekonesans lokalny przeprowadzono „w ciągu 2 minut” — zadanie harmonogramu o nazwie SystemUpdate wskazujące na implant, z kluczem Run w rejestrze pod HKCU\Software\Microsoft\Windows\CurrentVersion\Run jako alternatywą frameworka w systemie Windows oraz wpisem crontab @reboot lub linią nohup w ~/.bashrc jako jego alternatywami w systemie Linux. Rekonesans domeny trwał „przez kolejne 5 godzin”, wykorzystując generowane przez model skrypty PowerShell i zapytania LDAP do Active Directory, w tym wyszukiwania potrzebne do przygotowania Kerberoastingu i AS-REP Roastingu oraz sprawdzenia LAPS, Azure i katalogów .azcopy. Po „krótkiej przerwie trwającej kilka dni” końcowy etap — ruch boczny przez SMB i WMI, masowy dumping poświadczeń oraz eksport bazy danych — zajął „nie więcej niż godzinę”.

Warto zapamiętać zdanie podsumowujące Kaspersky'ego: cały atak – „od wdrożenia agenta po przejęcie kontroli nad administratorami domeny” – został przeprowadzony w ciągu 3–4 dni.

Działania związane z poświadczeniami to katalog dobrze znanych technik Windows, a nie coś nowego: gałęzie rejestru kopiowane za pomocą reg.exe, zrzuty lsass.exe wykonywane przez funkcję MiniDump z comsvcs.dll z użyciem identyfikatora procesu, a nie jego nazwy, aby ominąć dopasowywanie w wierszu poleceń, oraz — po przejęciu wbudowanego konta administratora domeny — ataki DCSync i Golden Ticket uruchamiane przez plik binarny Mimikatz o zmienionej nazwie, wdiag2.exe. Do ruchu bocznego wykorzystano WMIExec z Impacket, udostępnione foldery administracyjne i WMI; skrypt reverse shell p1.ps1 był wypychany na zdalne hosty i łączył się zwrotnie z 185.186.245[.]144:5501. Ładunki dzielono na fragmenty, takie jak d3.b64, i składano ponownie za pomocą certutil, a jeden beacon podszywał się pod svchosts.exe.

Zbieranie danych nastąpiło na końcu. Agent generował zapytania SQL dostosowane do zadania, ale przed ich uruchomieniem sprawdzał uprawnienia konta bazy danych, rekurencyjnie skanował udziały sieciowe przed pobraniem plików i zwracał wszystko tym samym szyfrowanym kanałem C2, z danymi zakodowanymi w Base64 wewnątrz JSON. Zrzuty ekranu w systemach Windows i Linux były dostępne, ale według relacji Kaspersky’ego wykonywano je tylko wtedy, gdy orkiestrator wydał polecenie. W raporcie stwierdzono, że zbieranie danych „było ostatnim etapem ataku: łańcuch zakończył się tam i nie zaobserwowaliśmy dalszej aktywności”.

Co zabrano i czego nie mówi zapis

Kaspersky odnotowuje, że agent wyeksportował rekordy bazy danych z serwera SQL organizacji edukacyjnej i zebrał pliki z zasobów sieciowych, oraz szczegółowo opisuje ten mechanizm. Nie podaje jednak, ile rekordów lub plików opuściło system, czy eksport został ukończony ani czyje dane znajdowały się w tabelach. Wtórne podsumowania idą w tym punkcie dalej niż raport: w artykule SecurityOnline napisano, że agent „wygenerował ukierunkowane zapytania SQL, aby wykraść rekordy uczniów i pracowników z tabel bazy danych”, podczas gdy sam tekst Kaspersky'ego opisuje zapytania skierowane do serwera SQL organizacji edukacyjnej, nie precyzując, co zawierały tabele. Czytelnicy powinni traktować opis „rekordy uczniów i pracowników” jako wtórną charakterystykę, a nie ustalenie Kaspersky'ego.

W rejestrze brakuje również informacji, czy jakakolwiek ofiara wykryła samo włamanie, co każda instytucja zrobiła później, czy powiadomiono organy regulacyjne lub organy ochrony danych w krajach dotkniętych atakiem oraz czy kampania nadal trwa. Kaspersky podaje jedynie, że zbieranie danych było ostatnim zaobserwowanym etapem w badanych incydentach. Komunikat prasowy nie zawiera wskazówek naprawczych dla dotkniętych organizacji — jego rekomendacje są skierowane ogólnie do obrońców.

Atrybucja: co potwierdzają dowody, a czego nie potwierdzają

Kaspersky wyraźnie stwierdza, że nie może wskazać konkretnego aktora. „Dostępne dane nie pozwalają nam powiązać tej aktywności z żadną znaną grupą atakujących ani z pewnością stwierdzić, że za obiema kampaniami stoi ten sam operator”. Artefaktem, na którym się opiera, są metadane kompilacji Go wewnątrz implantów, zawierające hashe kontroli wersji, czasy commitów i flagę brudnej kopii roboczej — „unikalny odcisk palca konkretnej kompilacji”. Na tej podstawie próbki dzielą się na dwie grupy, a w każdej z grup ładunki Windows i Linux mają identyczne metadane, co oznacza, że pochodzą z tej samej kopii roboczej.

Grupy nie łączą się ze sobą. „Nie dzielą wspólnej infrastruktury C2”, a na dwóch zestawach serwerów kontrolnych działały różne wersje CyberStrikeAI. Kaspersky podaje dwa powody, dla których przypisanie jest tu trudne: framework jest publicznie dostępny, więc różni operatorzy mogli niezależnie zbudować payloady w podobnych warunkach, a same polecenia są generowane przez model, co zwiększa ich różnorodność, jednocześnie usuwając indywidualne nawyki, od których zależy przypisanie behawioralne.

To, co pozostaje, jest sugestywne, a nie rozstrzygające. Niektóre skrypty zawierały komentarze po chińsku, atakujący korzystali z chińskiej usługi dnslog[.]cn, aby potwierdzić dostęp do internetu z hostów ofiar, a większość restartów serwerów sterujących — możliwych do odtworzenia, ponieważ samopodpisany certyfikat TLS jest ponownie generowany w pamięci przy każdym uruchomieniu, więc jego pole not_before zapisuje czas restartu — przypadła na godziny pracy w UTC+8. Sam CyberStrikeAI powstał w chińskiej społeczności cyberbezpieczeństwa. W komunikacie prasowym Kaspersky'ego wyraźnie zaznaczono: te artefakty „nie ustalają tożsamości ani lokalizacji atakujących”, a firma „nie mogła przypisać tej aktywności do znanej grupy zagrożeń ani potwierdzić, że ta sama osoba zarządzała całą zidentyfikowaną infrastrukturą”. Operator mówiący po chińsku to przypuszczenie, a nie ustalenie.

Dlaczego Kaspersky twierdzi, że to nie jest kryzys związany z wykryciem

Konkluzja raportu sprzeciwia się poglądowi, że LLM w łańcuchu ataku wymaga nowej klasy obrony. Ponieważ model znajduje się na serwerze atakującego, „nie pozostawił żadnych śladów swojej obecności w infrastrukturze (takich jak konkretne żądania API do lokalnych modeli LLM lub anomalne wzorce zużycia zasobów przez hosty)”. To, co zamiast tego widzą obrońcy, to wtargnięcie przypominające działania człowieka: te same narzędzia, te same sekwencje, te same wpisy w dzienniku zdarzeń. Werdykt Kaspersky'ego jest taki, że „wprowadzenie AI do łańcucha ataku nie stanowi jeszcze fundamentalnie nowych wyzwań dla wykrywania”, że „klasyczne, dobrze dostrojone reguły korelacji i analizy behawioralnej są wystarczające” oraz że nowość „nie tkwi w samych metodach, lecz w szybkości i łatwości, z jaką je wykonano”.

Opublikowane wykrycia kierują się tą logiką, a nie wymyślaniem nowych. Kaspersky Anti Targeted Attack przypisuje ruchowi implantu werdykt sieciowy Backdoor.CyberStrikeAI.HTTP.C&C; reguła wykrywania anomalii sieciowych o nazwie „Scanning domain records via LDAP queries” wychwytuje rekonesans domeny; Kaspersky SIEM dostarcza ponad 100 reguł obejmujących techniki opisane w raporcie, w tym DCSync, Golden Ticket, Kerberoasting i Impacket WMIExec; a implanty są klasyfikowane jako HEUR:HackTool.Win64.CyberStrike.gen i HEUR:HackTool.Linux.CyberStrike.gen. Wskazówki firmy Kaspersky dla klientów są konwencjonalne — wykrywanie i reagowanie na punktach końcowych, wykrywanie sieciowe, analiza zagrożeń oraz monitorowanie poza godzinami pracy lub przez usługę zarządzaną.

Oświadczenie Nazarowa w komunikacie prasowym to ten sam argument w jednym zdaniu: napastnicy „użyli agenta AI opartego na CyberStrikeAI, aby przeprowadzić pełny łańcuch ataku i dostosowywać kolejne kroki w ramach przejętych sieci”, ale „framework nadal opierał się na znanych technikach i procedurach, w tym rozpoznaniu, zrzucaniu poświadczeń, ruchu bocznym oraz gromadzeniu i eksfiltracji danych”.

Co jest ustalone, a co nie

Ujmując to wprost: mechanizm jest udokumentowany w stopniu, który pozwoliłby obrońcy wytropić go już jutro — pochodzenie procesów od sqlservr.exe, zaplanowane zadanie o nazwie SystemUpdate, dostęp do LSASS przez comsvcs.dll, DCSync z komputera niebędącego kontrolerem domeny, nagłówek HTTP X-Implant-Token oraz adresy C2, które wymienia Kaspersky. Kampania wokół tego mechanizmu już nie. Kaspersky nie opublikował żadnej listy ofiar, podziału na kraje, szacunku wolumenu danych ani nazwy aktora. Wszystko, co czytelnik mógłby chcieć wiedzieć o tym, kto ucierpiał i jak poważnie, kończy się na sektorze i regionie.

Dwa szczegóły warto podkreślić każdemu, kto sięga po raport w oczekiwaniu na więcej. Po pierwsze, Kaspersky opisuje atak jako „jeden z pierwszych publicznych opisów przejęcia z udziałem LLM w warunkach rzeczywistych”, a nie jako pierwszy — ostrożne sformułowanie, które ogranicza twierdzenie do tego, co zespół mógł znaleźć w publicznych relacjach. Po drugie, raport zauważa, że wersja implantu nie jest powiązana z wersją serwera, że konfiguracje i klucze listenerów przetrwają aktualizacje operatora oraz że data kompilacji próbki wskazuje jedynie najwcześniejszą możliwą datę wdrożenia, a nie długość przejęcia. Liczba 3–4 dni jest pomiarem jednego zrekonstruowanego incydentu, a nie ograniczeniem tego, jak długo trwała którakolwiek z tych intruzji, zanim ktoś ją zauważył.