Zespół polujący na luki sam został zhakowany. DIVD podejrzewa atak z użyciem agentowego AI
DIVD odizolowało infrastrukturę i prowadzi analizę śledczą. Wyjaśniamy, co jest faktem, co hipotezą i jak mówić o AI podczas trwającego incydentu.
- AUTOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLIKACJA
- 28 września 2026
- CZAS CZYTANIA
- 10 min czytania
- TEMAT
- Bezpieczeństwo AI
Holenderski Dutch Institute for Vulnerability Disclosure (DIVD), którego wolontariusze wyszukują podatne systemy i ostrzegają ich właścicieli, poinformował o włamaniu do własnej infrastruktury. Organizacja zablokowała dostęp, rozpoczęła analizę z zewnętrznym zespołem reagowania i przyjęła ostrożne założenie, że doszło do naruszenia, dopóki dochodzenie nie wykaże czegoś innego.
Najwięcej uwagi przyciąga zdanie DIVD, że sposób działania wskazuje na atak napędzany przez agentowe AI. To ocena organizacji na wczesnym etapie, a nie opublikowany raport techniczny dowodzący użycia konkretnego modelu lub autonomicznego systemu. Warto zachować oba elementy jednocześnie: nie ignorować obserwacji doświadczonego zespołu, ale nie zamieniać hipotezy w pewnik.
Co zostało potwierdzone
DIVD wykryło podejrzaną aktywność i po analizie uznało, że zostało zhakowane. Zablokowało dostęp do infrastruktury oraz rozpoczęło badanie śledcze przy wsparciu niezależnego zespołu reagowania na incydenty.
Organizacja poinformowała bezpośrednio zaangażowane strony, zgłosiła incydent holenderskiemu organowi ochrony danych i krajowemu centrum cyberbezpieczeństwa oraz omówiła dalsze działania z policją. Jako priorytety wskazała izolację i zabezpieczenie infrastruktury, analizę dowodów oraz wsparcie wolontariuszy.
Początkowy komunikat nie opisuje drogi wejścia, dotkniętych systemów, rodzaju dostępnych danych, czasu obecności napastnika ani potwierdzonej eksfiltracji. Nie identyfikuje też sprawcy ani użytego narzędzia AI.
„Wskazuje na agentowe AI” nie znaczy „AI zostało udowodnione”
Atak może wyglądać na zautomatyzowany z wielu powodów: szybka sekwencja działań, równoległe próby, adaptacja do odpowiedzi systemu, nietypowe polecenia albo łączenie wielu narzędzi. Takie cechy mogą wspierać hipotezę o agencie, ale nie wystarczają same do przypisania technologii.
Do mocniejszego wniosku potrzebne byłyby ślady pokazujące pętlę obserwacja–decyzja–działanie, charakterystyczne błędy lub artefakty narzędzia, korelacja czasowa, infrastruktura operatora, przechwycone prompty albo inne dowody. Nawet wtedy trzeba rozróżnić autonomicznego agenta od skryptu, orkiestratora i człowieka intensywnie korzystającego z asystenta AI.
To rozróżnienie ma znaczenie biznesowe. Firma reaguje przede wszystkim na uzyskany dostęp, dotknięte dane i trwałość napastnika, a nie na atrakcyjną etykietę. W pierwszych godzinach „czy to było AI?” jest zwykle pytaniem niższego priorytetu niż „co napastnik może zrobić teraz?”.
Dlaczego podejście „zakładamy naruszenie” może być rozsądne
Podczas trwającego dochodzenia brak pełnych dowodów nie powinien uspokajać, jeśli istnieją wiarygodne oznaki dostępu. Założenie naruszenia pozwala szybciej odizolować systemy, zabezpieczyć logi, zmienić klucze i powiadomić osoby, które mogą ograniczyć szkodę.
Nie oznacza to publicznego twierdzenia, że wykradziono wszystkie dane. Wewnętrzna hipoteza robocza może być konserwatywna, podczas gdy komunikacja zewnętrzna pozostaje precyzyjna: co wykryto, jakie działania wykonano i czego jeszcze nie ustalono.
Takie podejście jest szczególnie ważne dla organizacji posiadającej informacje o podatnych systemach innych podmiotów. Potencjalna wartość danych zależy nie tylko od ich poufności, ale również od czasu — luka, której właściciel jeszcze nie naprawił, może szybko zostać wykorzystana.
Jak przygotować firmę na szybszego i bardziej adaptacyjnego napastnika
Niezależnie od tego, czy w tej sprawie zostanie potwierdzone agentowe AI, zespoły powinny zakładać, że automatyzacja skraca czas między dostępem a kolejnym działaniem. Ręczne zgody i komunikacja nie mogą pozostawać jedynym mechanizmem zatrzymania ataku.
Organizacja potrzebuje:
- centralnych logów dostępnych po odizolowaniu systemu źródłowego;
- krótkotrwałych poświadczeń i możliwości szybkiego odwołania kluczy;
- segmentacji ograniczającej przejście między usługami;
- alarmów dla sekwencji działań, nie tylko pojedynczych wskaźników;
- przygotowanej listy systemów do odłączenia i właścicieli decyzji;
- bezpiecznego kanału komunikacji poza potencjalnie naruszonym środowiskiem;
- aktualnego spisu danych, partnerów i osób wymagających zawiadomienia.
Szybkość nie powinna usuwać kontroli nad skutkami. Automatyczne blokady muszą mieć zakres, warunki cofnięcia i nadzór, aby reakcja nie zatrzymała usług bardziej niż sam napastnik.
Transparentność nie oznacza publikowania każdego szczegółu
DIVD zdecydowało się wcześnie potwierdzić włamanie i wskazać, że dochodzenie trwa. Taka komunikacja może pomóc partnerom przygotować się na ryzyko, ale wymaga dyscypliny językowej. Hipotezy powinny być nazwane hipotezami, a terminy kolejnych aktualizacji nie mogą zastępować treści.
Organizacja nie powinna publikować informacji, które ułatwią napastnikowi utrzymanie dostępu lub usunięcie śladów. Może jednak podać status usług, rodzaj działań ochronnych, potencjalnie zainteresowane grupy, kanał kontaktu oraz datę aktualizacji.
Ważnym elementem komunikatu DIVD jest również troska o wolontariuszy. Incydent to nie tylko problem techniczny. Długotrwała praca pod presją zwiększa ryzyko błędów, dlatego harmonogram zmian, odpoczynek i wsparcie decyzyjne są częścią bezpieczeństwa operacyjnego.
Co firma powinna dokumentować w sprawie możliwego użycia AI
Jeśli zespół podejrzewa udział systemu agentowego, powinien zachować surowe zdarzenia, znaczniki czasu, pełne polecenia, odpowiedzi usług, nietypowe warianty błędów i kolejność użycia narzędzi. Późniejsza ocena bez pierwotnych danych łatwo zamienia się w narrację opartą na wrażeniu.
W raporcie końcowym warto oddzielić obserwacje od interpretacji i wskazać poziom pewności. „Działania następowały co kilka sekund w wielu usługach” jest obserwacją. „Napastnik używał autonomicznego agenta” jest wnioskiem wymagającym dodatkowego uzasadnienia.
Fakty źródłowe i wnioski Breachroad
DIVD CSIRT potwierdza włamanie, izolację infrastruktury, zewnętrzne wsparcie śledcze, powiadomienie zainteresowanych stron i organów oraz własną ocenę, że modus operandi wskazuje na atak napędzany agentowym AI. Komunikat nie przedstawia technicznego dowodu tej hipotezy ani pełnego zakresu incydentu.
Standard dowodowy dla przypisania AI, priorytety reakcji, lista kontroli oraz zalecenia dotyczące komunikacji są wnioskami Breachroad. Więcej kontekstu zawiera analiza ofensywnego użycia AI przez przestępców i plan reagowania na incydenty. Firmy wdrażające agentów mogą uporządkować granice działania w ramach bezpiecznego wdrożenia AI.


