Raport Microsoft o nadużyciach ARTEX śledzi nasilające się ataki na firmy finansowe

Microsoft twierdzi, że cyberprzestępcy zaczęli wykorzystywać ARTEX przeciwko organizacjom finansowym w październiku 2026 roku, rozszerzając udokumentowane użycie tego frameworka poza wcześniejsze kampanie szpiegowskie. Raport Microsoft o nadużyciach ARTEX wskazuje Storm-3358 — grupę działającą z pobudek finansowych, którą Microsoft opisuje jako mającą siedzibę w Kambodży. Jej aktywność wywiera nową presję na znany problem bezpieczeństwa: atakujący mogą automatyzować działania, podczas gdy obrońcy wciąż potrzebują czasu na ocenę i powstrzymanie zagrożenia.

ARTEX to oparty na AI framework testów penetracyjnych, oprogramowanie koordynujące testy bezpieczeństwa za pośrednictwem agentów zdolnych do dobierania narzędzi i działania na podstawie wyników. Jego legalne przeznaczenie nie wyklucza przestępczego użycia. Główny konflikt dotyczy zautomatyzowanego wykonywania ataków w zestawieniu z decyzjami podejmowanymi przez ludzi i organizacyjnym przekazywaniem spraw, niezbędnymi do zatrzymania włamania.

Wcześniejsze raporty Microsoft łączyły ARTEX ze Storm-0940, odrębnym podmiotem powiązanym z kompromitacją łańcucha dostaw ConnectWise. Ta historia zapewnia kontekst, a nie dowód, że grupy mają wspólnego operatora. Łącznie raporty stawiają przed firmami finansowymi praktyczne pytanie: czy istniejące mechanizmy bezpieczeństwa potrafią przerwać atak przed jego kolejnym istotnym krokiem.

Raportowanie nadużyć Microsoft ARTEX wskazuje kampanię motywowaną finansowo

Najnowszy raport dodaje konkretną operację przestępczą do dowodów na adopcję ARTEX.

Opublikowana 6 listopada analiza ataków na sektor finansowy Microsoft opisuje działania Storm-3358 wymierzone głównie w organizacje finansowe w Azji Południowo-Wschodniej. Microsoft wskazuje również mniejszą grupę celów obejmującą duże organizacje finansowe w innych regionach.

Według Microsoft grupa łączy ARTEX z konwencjonalną automatyzacją, aby skanować wystawione systemy i wykorzystywać słabości aplikacji. Obejmują one anonimowe przesyłanie plików oraz fałszowanie żądań po stronie serwera, które skłania serwer do wykonywania żądań wybranych przez atakującego. Microsoft informuje również o wdrażaniu trojanów zdalnego dostępu — złośliwego oprogramowania zapewniającego stały dostęp do przejętych systemów.

Rozróżnienie między obieraniem celów a potwierdzonymi szkodami ma znaczenie. Raport przedstawia zaobserwowaną aktywność i techniki, ale nie zapewnia pełnego zestawienia ofiar, strat ani udanych włamań. Czytelnicy powinni powstrzymać się od przekształcania opisu aktywnej kampanii w niepoparte szacunki jej wpływu finansowego.

Ustalenia Microsoft dotyczące nadużyć ARTEX podważają również prosty sposób kategoryzowania incydentów bezpieczeństwa AI. Ta historia dotyczy atakujących wykorzystujących AI przeciwko zwykłym systemom przedsiębiorstw. Instytucja finansowa nie musi sama wdrażać agenta AI, aby mierzyć się z tego rodzaju zagrożeniem.

Zmienia to, które zespoły wewnętrzne powinny zwrócić uwagę. Organizacja może powierzyć nadzór nad AI komitetowi technologicznemu, pozostawiając bezpieczeństwo aplikacji zespołom inżynieryjnym. W tym przypadku istotna ekspozycja występuje wszędzie tam, gdzie zewnętrznie dostępne oprogramowanie, poświadczenia i uprawnienia dostępu się łączą.

Rozważmy operacyjne konsekwencje słabości aplikacji odkrytej poza godzinami pracy. Pierwszy alert może trafić do zespołu monitorującego, podczas gdy powstrzymanie zagrożenia wymaga oceny właściciela aplikacji. Jeśli atakujący kontynuuje testowanie podczas tego przekazania sprawy, proces reakcji organizacji staje się częścią jej faktycznej granicy bezpieczeństwa.

Ten scenariusz jest ilustracją analityczną, a nie ujawnionym incydentem Storm-3358. Wyjaśnia, dlaczego zgłoszone połączenie automatyzacji i znanych słabości zasługuje na uwagę, bez konieczności twierdzenia, że chodzi o całkowicie nową technikę ataku.

Wartość informacyjna tej wiadomości wynika z adopcji przez grupę motywowaną finansowo, a nie z dowodu, że ARTEX pokonuje każdą obronę. Firmy finansowe mają teraz kolejny udokumentowany powód, by sprawdzić, jak szybko potrafią przekształcić podejrzaną aktywność w autoryzowaną reakcję. Istotne jest to, czy atak zostaje zatrzymany, a nie czy odnotowuje go panel.

Firmy finansowe odczuwają presję na styku zespołów

Alert ma ograniczoną wartość ochronną, gdy organizacja nie może zadziałać, zanim dostęp się rozszerzy.

Presja rozkłada się między operacje bezpieczeństwa, inżynierię aplikacji, administrację tożsamościami i właścicieli biznesowych. Każda z tych grup kontroluje inną część incydentu. Ich koordynacja decyduje o tym, czy wykrycie prowadzi do powstrzymania zagrożenia, czy jedynie tworzy zapis tego, co się wydarzyło.

Dla organizacji finansowych decyzje o powstrzymaniu zagrożenia mogą obejmować zarówno dostępność usług, jak i bezpieczeństwo. Wyłączenie aplikacji może zakłócić legalną pracę. Ograniczenie konta może wpłynąć na proces biznesowy. Te kompromisy nie znikają tylko dlatego, że atakujący korzysta z AI.

Wniosek ma charakter organizacyjny, a nie wyłącznie techniczny. Zespół potrzebuje jasnych podstaw do decydowania, kiedy podejrzane zachowanie uzasadnia interwencję. Bez takich podstaw automatyzacja może generować alerty szybciej, pozostawiając podstawową kolejkę decyzji bez zmian.

Oddzielne dochodzenie Microsoft dostarcza konkretnego przykładu presji czasu. Badanie z 5 listopada dotyczące ujawnionych sekretów aplikacji opisuje agenta przechodzącego od odkrycia na GitHub do kradzieży danych z Azure Key Vault w pięć minut. Key Vault to usługa chmurowa do zarządzania sekretami, kluczami i certyfikatami.

Ta obserwacja należy do badań nad nadużyciem poświadczeń, a nie do opublikowanej osi czasu Storm-3358. Nie powinna stać się uniwersalnym punktem odniesienia dla ataków ARTEX. Jej znaczenie jest węższe: użyteczne odkrycie i istotne działanie następcze mogą nastąpić w tym samym krótkim oknie dochodzeniowym.

Dla deweloperów oznacza to, że ujawnienie poświadczeń jest incydentem związanym z uprawnieniami, a nie tylko kłopotliwą zmianą w kodzie. Sekret to materiał uwierzytelniający, który pozwala oprogramowaniu uzyskać dostęp do usługi. Usunięcie jego widocznej lokalizacji nie odpowiada na pytanie, do czego dawał dostęp ani czy ktoś już go wykorzystał.

Microsoft twierdzi, że ujawnione poświadczenia pozostają użyteczne, dopóki nie zostaną unieważnione lub zrotowane. Konsekwencja operacyjna wykracza poza porządkowanie repozytorium. Badacze muszą zrozumieć zakres uprawnień poświadczenia i zbadać związaną z nim aktywność, zamiast traktować usunięcie jako dowód zakończenia dostępu.

Nabywcy z sektora finansowego powinni stosować to samo rozumowanie przy ocenie produktów bezpieczeństwa. Demonstracja identyfikująca podejrzane żądania odpowiada jedynie na część pytania. Nabywcy muszą też rozumieć, jak ustalenia trafiają do osób uprawnionych do ograniczenia dostępu.

Użyteczne jest rozróżnienie między informacją a interwencją. Informacja pomaga zespołowi zrozumieć atak. Interwencja zmienia to, co atakujący może zrobić dalej. Program bezpieczeństwa potrzebuje obu tych elementów, ale nie powinien przedstawiać ich jako wymiennych rezultatów.

Ataki ARTEX na sektor finansowy wywierają zatem presję na procedury łączące zespoły, a nie tylko na narzędzia należące do poszczególnych zespołów. Szybkie dochodzenie nadal traci wartość, jeśli jego ustalenia czekają na niedostępnego zatwierdzającego. Z kolei jasne uprawnienia mogą zwiększyć użyteczność istniejących mechanizmów bez zakładania, że nowy produkt rozwiąże cały problem.

Mechanizmem jest zautomatyzowane kontynuowanie działań, a nie nieznane słabości

Istotna zmiana polega na zdolności łączenia odkryć z kolejnymi działaniami przy ograniczeniu powtarzalnego udziału człowieka.

Skaner może zidentyfikować potencjalny problem, nie decydując, jak go dalej wykorzystać. Agentowy przepływ pracy dodaje proces decyzyjny, który interpretuje wyniki i wybiera kolejne działanie. To rozróżnienie pomaga wyjaśnić, dlaczego konwencjonalne narzędzia mogą stworzyć inne wyzwanie operacyjne, gdy oprogramowanie koordynuje ich użycie.

Google Threat Intelligence Group i Mandiant opisali ten rozwój w badaniu z 30 października dotyczącym agentowych frameworków ofensywnych. Ich prace w zakresie reagowania na incydenty zidentyfikowały nadużywanie ARTEX i innych frameworków na wielu etapach ataku. Badacze opisują znane słabości połączone ze zmieniającą się szybkością i skalą wykonania.

Ich obserwacje komplikują również twierdzenia o bezproblemowej autonomii. W jednym przypadku aktywność ARTEX wygenerowała 240 zdarzeń w logach i napotkała błędy potencjalnie związane z wzajemnym zakłócaniem się agentów. Dowody te wspierają bardziej użyteczną interpretację niż zarówno lekceważenie, jak i alarmizm: zautomatyzowana wytrwałość może współistnieć z widocznymi błędami.

Dla obrońców błędy mają wartość tylko wtedy, gdy ktoś lub coś rozpoznaje ich znaczenie. Nieudane działanie może ujawnić wrogie zamiary, zanim atakujący osiągnie cel. Traktowanie każdej porażki jako nieszkodliwego szumu grozi przeoczeniem szerszej sekwencji, która ją otacza.

Obecność błędów nie dowodzi jednak, że atak jest nieszkodliwy. Przepływ pracy może wielokrotnie zawodzić, a mimo to znaleźć działającą ścieżkę. Pytanie analityczne brzmi, czy środowisko uniemożliwia postęp, a nie czy wykonanie atakującego wygląda profesjonalnie.

Dlatego też liczenie żądań daje niepełny obraz. Duża liczba żądań może zostać zablokowana bez konsekwencji. Mniejsza sekwencja może wykorzystać prawidłowe uprawnienia i dotrzeć do wrażliwych zasobów. Waga zagrożenia zależy od relacji między zachowaniem, autoryzacją i wpływem na działalność.

Kontekst konkurencyjny wykracza poza Microsoft. Google i Mandiant ujmują ten rozwój przez pryzmat obserwacji z reagowania na incydenty, podczas gdy Microsoft przedstawia śledzenie kampanii i wskazówki obronne. Te perspektywy pokrywają się w kwestii adopcji, lecz ich opublikowane badania nie stanowią kontrolowanego porównania produktów bezpieczeństwa.

Żaden cytowany raport nie dowodzi, że Microsoft, Google lub inny dostawca konsekwentnie powstrzymuje aktywność ARTEX szybciej niż konkurenci. Nabywcy korporacyjni powinni odróżniać użyteczne badania zagrożeń od dowodu wyższości produktu. Widoczność dostawcy w zakresie ataków nie ustanawia automatycznie porównywalnej skuteczności zapobiegania.

Mechanizm ten ogranicza również powszechne założenie polityczne. Ograniczenie korzystania z AI przez pracowników nie powstrzymuje bezpośrednio zewnętrznego podmiotu przed użyciem agenta przeciwko wystawionej aplikacji. Wewnętrzne zarządzanie AI i zapobieganie zewnętrznym atakom przecinają się, ale dotyczą różnych źródeł ryzyka.

Wniosek z tych zagrożeń bezpieczeństwa związanych z agentową AI jest zatem konkretny. Organizacje muszą zbadać ścieżki łączące zwykłe słabości z wartościowym dostępem. Jeśli te ścieżki pozostają otwarte, szybsze podejmowanie decyzji przez atakujących może mieć znaczenie, nawet gdy poszczególne techniki są znane.

Oddzielne kampanie wskazują na adopcję, nie dowodząc wspólnego operatora

Pojawienie się tego samego frameworka w kilku dochodzeniach wskazuje na szerszą adopcję, a nie automatyczne przypisanie działań tej samej grupie.

Badanie Microsoft z 21 października opisuje Storm-0940, które według jego oceny jest powiązane z chińskim państwem, wykorzystujące ARTEX w atakach na różne branże. Analiza kompromitacji łańcucha dostaw łączy ten podmiot z przejętym dostępem do aplikacji, wpływającym na środowiska dalszych odbiorców. Microsoft informuje, że niektóre ataki osiągały uprzywilejowany dostęp do chmury w mniej niż trzy godziny.

Raport zawiera również konieczne zastrzeżenie: pomyślne uwierzytelnienie samo w sobie nie dowodzi, że uzyskano dostęp do danych klientów ani że zostały one skradzione. To rozróżnienie powinno znaleźć odzwierciedlenie w relacjach dotyczących sektora finansowego. Atakujący może dotrzeć do usługi, nie realizując wszystkich zamierzonych działań.

Storm-3358 i Storm-0940 stanowią zatem odmienne przykłady w ramach tego samego szerszego zjawiska. Ich zgłaszane motywacje i aktywność różnią się. Wspólne narzędzia same w sobie nie niwelują tych różnic ani nie dowodzą koordynacji.

CrowdStrike dodaje inną perspektywę poprzez swoje dochodzenie z 7 października dotyczące południowokoreańskiego sektora finansowego. Badacze znaleźli materiały konfiguracyjne ARTEX oraz historie sesji AI w infrastrukturze kontrolowanej przez atakujących, powiązanej z działaniami w sektorze finansowym. CrowdStrike nie przypisał kampanii konkretnemu przeciwnikowi i określił swoją ocenę operatora jako dokonaną z umiarkowaną pewnością.

Artefakty te są istotne, ponieważ pokazują coś więcej niż ogólne twierdzenie, że AI pojawiła się gdzieś w ramach włamania. Łączą narzędzia ze środowiskiem operacyjnym. Mimo to nie rozstrzygają tożsamości każdego podmiotu korzystającego z tych narzędzi.

To rozróżnienie wpływa na sposób, w jaki organizacje interpretują nowe raporty o incydentach. Dopasowanie nazwy frameworka może pomóc śledczym sformułować pytania. Nie powinno jednak zastępować badania infrastruktury, poświadczeń, wzorców aktywności i dowodów wspierających konkretne przypisanie.

Wzorzec dotyczący sektora finansowego również wymaga ostrożnego ujęcia. Liczne raporty dotyczące organizacji finansowych sprawiają, że sektor ten jest istotny dla tej historii. Nie dowodzą jednak, że finanse są najbardziej narażone na ARTEX, ponoszą największe straty ani dysponują wyjątkowo podatnym stosem technologicznym.

Różni badacze widzą także różne fragmenty krajobrazu zagrożeń. Działania zespołu reagowania na incydenty zaczynają się od organizacji szukającej pomocy. Telemetria chmurowa pokazuje aktywność w zakresie widoczności danego dostawcy. Żadne z tych źródeł nie reprezentuje automatycznie wszystkich ataków ani wszystkich organizacji.

Ten problem doboru próby jest ważny przy ocenie pozornego wzrostu. Dodatkowe raportowanie może odzwierciedlać więcej ataków, lepsze wykrywanie, szerszą widoczność lub kombinację tych czynników. Dostępne dowody potwierdzają szersze udokumentowane wykorzystanie, pozostawiając nierozstrzygniętą kwestię ogólnego wskaźnika adopcji.

Dla czytelników najsilniejszy wniosek pozostaje praktyczny. Ataki ARTEX na sektor finansowy nie są już hipotetycznym scenariuszem nadużycia ograniczonym do demonstracji. Opublikowane materiały opisują zastosowanie operacyjne, pozostawiając jednocześnie znaczną niepewność co do skali występowania, relacji między operatorami i łącznych konsekwencji.

Dowody nie potwierdzają uniwersalnej autonomii ani porażki obrony

Zaobserwowane włamania uzasadniają działanie, ale wybrane przykłady nie mogą określić typowego wskaźnika powodzenia ani dowieść, że istniejące zabezpieczenia są przestarzałe.

Raport Microsoft dotyczący nadużyć ARTEX dostarcza dowodów na kampanie, a nie reprezentatywnego badania skuteczności. Nie przedstawia punktu odniesienia pokazującego, jak ci sami operatorzy radziliby sobie bez ARTEX. Ogranicza to twierdzenia dotyczące tego, jak dużą poprawę zapewnił framework.

Użyteczne porównanie powinno uwzględniać początkowy dostęp, warunki po stronie celu, umiejętności operatora oraz mierzony cel. Znalezienie wystawionej usługi różni się od uzyskania dostępu administracyjnego. Uzyskanie dostępu różni się od wyprowadzenia danych. Łączenie tych wyników pod jedną etykietą sukcesu zaciera istotne różnice.

Autonomia również wymaga jasnej definicji. Agent wybierający kolejne polecenie to coś innego niż operacja niewymagająca żadnego przygotowania, nadzoru ani korekty ze strony człowieka. Raporty pokazują znaczną aktywność zautomatyzowaną, lecz nie dokumentują każdego ludzkiego wkładu we wszystkich kampaniach.

Ta niepewność nie osłabia dowodów na to, że atakujący używają tych frameworków. Ogranicza wnioski, jakie czytelnicy powinni wyciągać na temat niezależności i niezawodności. Częściowo zautomatyzowana operacja może nadal wywierać poważną presję, nawet jeśli nie spełnia najsilniejszej interpretacji autonomicznego hakowania.

Ocena zagrożenia ARTEX opublikowana przez CERT-EU 5 listopada ARTEX threat assessment wzmacnia obawy dotyczące adopcji, dodając jednocześnie zastrzeżenie dotyczące wdrożeń. Organizacja podaje, że oryginalne repozytorium stało się niedostępne w październiku, podczas gdy niezależne forki nadal krążą. Fork to osobno utrzymywana kopia projektu oprogramowania.

Według CERT-EU możliwości i integracje mogą różnić się między tymi kopiami. Oznacza to, że nazwa frameworka nie wskazuje na jedną stałą implementację. Wnioski dotyczące jednego wdrożenia nie powinny automatycznie stawać się twierdzeniami o każdej wersji dostępnej gdzie indziej.

Ta sama ostrożność dotyczy twierdzeń o produktach obronnych. Opis funkcji nie dowodzi, że klient ją włączył, odpowiednio skonfigurował ani połączył z działającym procesem reagowania. Dostępność produktu i ochrona operacyjna to odrębne kwestie.

Microsoft omawia techniki oszustwa, które oferują atakującym mylące lub bezwartościowe cele. Testy wykazały korzyści, lecz publiczny raport nie potwierdza uniwersalnego ograniczenia strat. Takie ustalenia uzasadniają dalszą ocenę, a nie gwarancję, że agent zatrzyma się za każdym razem, gdy napotka wabik.

Sceptyczne stanowisko jest zatem zgodne z poważnym traktowaniem zagrożenia. Organizacje powinny kwestionować szerokie twierdzenia o niepowstrzymanych agentach, jednocześnie badając konkretne ścieżki dostępu opisane w badaniach. Niepewność co do skali występowania nie czyni znanej ekspozycji bezpieczną.

Te ryzyka bezpieczeństwa związane z agentową AI również zasługują na relacjonowanie, które rozróżnia to, co badacze zaobserwowali, od tego, czego oczekują w dalszej kolejności. Prognozy mogą wspierać przygotowania, ale pozostają prognozami. Dowody stają się bardziej użyteczne, gdy ich granice pozostają widoczne.

Obserwuj mierzalne rezultaty, szerszą adopcję i wyniki obrony

Kolejne użyteczne dowody pokażą, co osiągają atakujący i co niezawodnie im przeszkadza, zamiast jedynie wymieniać dodatkowe narzędzia AI.

Pierwszym sygnałem wartym obserwacji jest lepszy pomiar ukończonych etapów ataku. Przyszłe ujawnienia powinny rozróżniać próbę uzyskania dostępu, pomyślne uwierzytelnienie, rozszerzone uprawnienia i potwierdzoną kradzież danych. Te rozróżnienia sprawiłyby, że porównania między kampaniami byłyby bardziej miarodajne.

Raport wskazujący krótsze odstępy między tymi etapami w porównywalnych incydentach wzmocniłby argument, że automatyzacja skraca czas reakcji. Dowody, że aktywność wielokrotnie zatrzymuje się na egzekwowanych granicach, ograniczyłyby ten wniosek. Każdy z tych wyników byłby bardziej informacyjny niż kolejne odosobnione twierdzenie o szybkości.

Dla instytucji finansowych istotny pomiar powinien wiązać się z decyzją operacyjną. Ile czasu śledczy potrzebowali, aby zidentyfikować zasób objęty incydentem? Kiedy uprawniony właściciel podjął działanie? Czy powstrzymanie incydentu usunęło dostęp atakującego, czy jedynie rozwiązało widoczny objaw?

Pytania te nie wymagają założenia, że każdy atak przebiega według tej samej sekwencji. Wymagają przekazania wystarczającego kontekstu, aby zrozumieć, dlaczego wystąpił konkretny wynik. Bez tego kontekstu najszybciej ujawniony przykład może łatwo stać się mylącym branżowym punktem odniesienia.

Drugim sygnałem jest udokumentowana adopcja przez odrębnych aktorów i implementacje. Badacze powinni nadal oddzielać wspólne narzędzia od wspólnych operatorów. Dowody łączące kolejne grupy motywowane finansowo z wykorzystaniem operacyjnym wzmocniłyby ocenę szerszej adopcji.

Z kolei dowody, że aktywność koncentruje się wokół wąskiego zbioru operatorów, osłabiłyby twierdzenia o powszechnej dyfuzji. Obie możliwości pozostają zgodne z obecnym raportowaniem. Brakującym elementem jest wyraźniejszy mianownik opisujący, jak często te frameworki pojawiają się w określonym zbiorze incydentów.

Zmienność oprogramowania również zasługuje tu na uwagę. Jeśli różne kopie ARTEX działają odmiennie, badacze muszą wskazywać, którą implementację zbadali. W przeciwnym razie usprawnienia lub niepowodzenia związane z jedną wersją mogą zniekształcić publiczne rozumienie innej.

Trzecim sygnałem jest niezależnie ocenialna skuteczność obrony. Organizacje potrzebują dowodów, że mechanizmy kontroli przerywają istotne działania w realistycznych warunkach. Użyteczne wyniki wyjaśniałyby pozycję wyjściową atakującego, zastosowany mechanizm kontroli oraz punkt, w którym postęp został zatrzymany.

Ten standard dotyczy w równym stopniu konwencjonalnych produktów bezpieczeństwa i obronnych agentów AI. Szybsze podsumowania mogą pomagać analitykom, lecz same w sobie nie dowodzą szybszego powstrzymania incydentu. Przekonująca ocena łączy wsparcie z wynikiem, który zmienia dostępne atakującemu opcje.

Ustalenia Microsoft dotyczące nadużyć ARTEX sprawiają, że te pytania są aktualne, nie dostarczając jednak wszystkich odpowiedzi. Dokumentują one przestępczą adopcję i znane ścieżki wykorzystania, podczas gdy towarzyszące badania dostarczają dowodów automatyzacji w odrębnych kampaniach. Najlepszą odpowiedzią jest precyzyjne wykorzystanie tych dowodów.

Dla organizacji śledzących te wydarzenia ważne jest zachowanie rozróżnienia między faktami źródłowymi, ocenami wewnętrznymi i przypisanymi działaniami. Przeszukiwalna baza wiedzy zespołu może wspierać tę pracę, pod warunkiem że wrażliwe materiały dotyczące incydentów podlegają ustalonym zasadom dostępu. Dokumentacja powinna pomóc kolejnemu członkowi zespołu reagowania podjąć decyzję, a nie jedynie archiwizować kolejne ostrzeżenie.

Rozpocznij kolejną rozmowę o bezpieczeństwie od konkretnej ekspozycji, którą Twoja organizacja już rozumie. Zapytaj, kto może ją ograniczyć, jakich dowodów potrzebuje ta osoba i jak zespół weryfikuje, że dostęp rzeczywiście się zakończył. Następnie porównaj ten proces z etapami ataku opisanymi w pierwotnych badaniach. W całym przeglądzie zachowaj widoczne rozróżnienie między próbą działania a dokonaną szkodą. Celem jest wskazanie decyzji, którą można podjąć wcześniej, uprawnienia, które można zawęzić, lub nierozwiązanej zależności wymagającej właściciela. Która część obecnego procesu reagowania nadal czekałaby na przekazanie sprawy, podczas gdy zautomatyzowany atakujący kontynuowałby działanie?