Według Cisco Talos atakujący wykorzystywali webhooki platformy automatyzacji n8n do dostarczania szkodliwych treści i rozpoznawania urządzeń. Analiza opublikowana 15 kwietnia daje powód do przeglądu wyjątków w poczcie, integracjach i na liście dozwolonych narzędzi zdalnego zarządzania. Dopuszczenie domeny narzędzia automatyzacji nie oznacza zaufania do każdego przepływu, który ktoś w nim zbudował.

Jedna z kampanii opisanych w analizie Talos zaczynała się od wiadomości udającej folder OneDrive. Program pobrany przez odbiorcę instalował zmodyfikowane narzędzie RMM, czyli oprogramowanie do zdalnego zarządzania komputerami. Oba elementy wyglądają w biurze znajomo. Udostępniony folder to codzienna praca, a narzędzie RMM może być w firmie zwykłym narzędziem pracy działu IT. Dodajmy do tego platformę n8n, wokół której zbudowano całą analizę, i postawmy pytanie, na które łatwo udzielić złej odpowiedzi: który z tych elementów nasza organizacja przepuściłaby na podstawie samej nazwy usługi lub domeny? Jeśli uczciwa odpowiedź brzmi „prawdopodobnie każdy”, przegląd wyjątków powinien trafić do kalendarza przed kolejną zmianą reguł.

Webhooki n8n dostarczały treść i rozpoznawały urządzenia

Jak podaje Cisco Talos, webhooki n8n posłużyły atakującym do dwóch zadań: dostarczania szkodliwych treści oraz rozpoznawania urządzeń. Webhook to adres, który przyjmuje zapytanie z zewnątrz i uruchamia przepływ zbudowany w narzędziu automatyzacji. W legalnym zastosowaniu łączy firmowe aplikacje. W opisanym nadużyciu ten sam mechanizm odpowiadał na połączenie szkodliwą treścią albo służył do rozpoznania urządzenia, które się z nim łączyło.

Dla reguł bezpieczeństwa opartych na domenach ma to konkretną konsekwencję. Jeśli reguła dopuszcza domenę narzędzia automatyzacji, widzi tylko znaną usługę. Nie widzi, kto zbudował przepływ ani co ten przepływ zwraca. Filtr poczty nie czyta intencji autora przepływu, czyta adres.

Z przytoczonych ustaleń nie wynika, jakie dane o urządzeniach zbierano ani jak dokładnie wyglądał każdy etap. Nie dopowiadajmy tych szczegółów. Do decyzji wystarczy sam podział ról: jedna platforma, dwa zastosowania po stronie atakującego, oba w usłudze, którą firma mogła wcześniej uznać za zaufaną.

Wyjątek dla domeny n8n mówi, że ufamy dostawcy narzędzia. O autorze konkretnego przepływu nie mówi nic.

Folder OneDrive i narzędzie RMM sprawdzają firmowe procedury

Fakty, na których opieramy ten tekst, nie mówią nic o procedurach zaatakowanych organizacji ani o tym, czy ktoś je naruszył. Nikomu więc nie przypisujemy błędu. Zderzenie procedury z praktyką przeprowadźmy u siebie, na przykładzie kampanii z fałszywym folderem OneDrive.

W opisanym łańcuchu widać trzy miejsca, w których firmowa kontrola może zadziałać: wiadomość, pobranie programu i instalacja narzędzia. Przy wiadomości zapytajmy, czy filtr poczty ma wyjątki dla domen usług chmurowych lub narzędzi automatyzacji i czy ktoś pamięta, po co je dodano. Przy pobraniu sprawdźmy, co instrukcja każe zrobić pracownikowi, który zamiast dokumentów z udostępnionego folderu dostaje program do uruchomienia. Przy instalacji liczy się to, jak firma dopuszcza narzędzia RMM.

Zmodyfikowane narzędzie RMM wymaga tu najwięcej uwagi. Jeśli lista dozwolonego oprogramowania dopuszcza program po nazwie, zmodyfikowana kopia może wyglądać dla niej tak samo jak wersja wdrożona przez dział IT. Przytoczone fakty nie mówią, czy w tej kampanii jakakolwiek lista wyjątków zadziałała na korzyść atakującego, i nie ma potrzeby tego zakładać. Wystarczy sprawdzić, czy nasza lista potrafiłaby odróżnić jedną kopię od drugiej.

Wyjątek w filtrze jest decyzją o przyjęciu ryzyka

Wniosek z analizy Talos dla zarządu obejmuje trzy rejestry oglądane razem: wyjątki w poczcie, zatwierdzone integracje i dozwolone narzędzia zdalnego zarządzania. Każdy wpis w nich powstał zapewne jako odpowiedź na konkretną potrzebę zespołu. Problem zaczyna się, gdy wyjątek przeżywa swój powód. Domena narzędzia automatyzacji dopuszczona dla jednej integracji obejmuje wtedy także przepływy, których nikt w firmie nie zbudował. Narzędzie RMM dopuszczone dla działu IT może przepuścić kopię, której dział IT nie instalował.

Z przytoczonych faktów nie wynikają koszty ani skala strat, więc nie wyceniajmy ryzyka na ich podstawie. Możemy natomiast wymagać porządku decyzyjnego. Wyjątek bez właściciela trudno obronić przed audytorem i trudno szybko wycofać podczas incydentu, bo nikt nie wie, kogo zapytać o skutki.

Wyjątek w filtrze to decyzja o przyjęciu ryzyka. Powinien mieć właściciela, uzasadnienie i termin ponownej oceny.

Odpowiedzialność proponujemy rozdzielić według rejestrów. Wyjątki w poczcie przypiszmy administratorowi poczty, integracje zespołom, które je zbudowały, a listę narzędzi RMM działowi IT. Zarząd nie musi znać szczegółów webhooków n8n. Powinien wiedzieć, kto potrafi powiedzieć, które z nich należą do firmy.

Polska firma zaczyna od własnej listy wyjątków

Z faktów, na których opiera się ten tekst, nie wynika nic o polskich ofiarach ani o skali takich nadużyć w Polsce. Nie ogłaszajmy więc trendu. Dla polskiej organizacji punktem odniesienia jest jej własne środowisko: czy ktoś korzysta z n8n albo podobnej platformy automatyzacji, czy filtr poczty ma dla takich usług wyjątki i jakie narzędzia RMM są dopuszczone.

Pytanie o n8n zadajmy szerzej niż w dziale IT. Narzędzia automatyzacji mogą trafić do firmy przez marketing, sprzedaż albo księgowość, razem z integracją, o którą poproszono administratora poczty. Jeśli firma nie korzysta z n8n, to również jest informacja, bo wyjątek dla takiej domeny nie ma wtedy uzasadnienia. Jeśli korzysta, potrzebna jest lista przepływów należących do firmy, bo bez niej trudno odróżnić własny ruch od cudzego.

Co z tym zrobić w poniedziałek

  1. Wypisz wyjątki poczty dla narzędzi automatyzacji. W 30 minut sprawdź z administratorem filtra poczty, czy lista dozwolonych nadawców i adresów obejmuje domenę n8n lub podobnych usług. Przy każdym wpisie zanotuj, kto go dodał, kiedy i w jakim celu. Wpis bez uzasadnienia oznacz do decyzji właściciela.
  2. Ustal, czyje są przepływy. W 30 minut poproś zespoły korzystające z n8n lub innego narzędzia automatyzacji o listę webhooków, które firma sama utworzyła, z osobą odpowiedzialną za każdy z nich. Jeśli takiej listy nie ma, zapisz to jako lukę i wskaż, kto ma ją uzupełnić.
  3. Sprawdź jedną regułę dla narzędzia RMM. W 30 minut wybierz jedno narzędzie RMM dopuszczone w firmie i ustal, na jakiej podstawie reguła je przepuszcza: po nazwie, po źródle instalacji czy po podpisie. Jeśli po nazwie, zapisz pytanie, jak firma odróżni zmodyfikowaną kopię od wersji wdrożonej przez dział IT.

Domena n8n na liście wyjątków wyraża zaufanie do dostawcy narzędzia. Przepływ zbudowany przez nieznanego autora tego zaufania nie dziedziczy, podobnie jak zmodyfikowana kopia dozwolonego narzędzia RMM. Przegląd wyjątków zacznijmy więc od pytania, czyje przepływy i czyje kopie programów faktycznie przepuszczamy.

Źródła

  1. Cisco Talos: The n8n n8mare: How threat actors are misusing AI workflow automation. Publikacja: 15 kwietnia 2026 r.; wersja odczytana 21 kwietnia 2026 r.

Redakcja cyberinsight.pl.