Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Platformy automatyzacji workflow, takie jak n8n, zostały zaprojektowane do integracji aplikacji, obsługi zdarzeń i automatyzacji procesów biznesowych. Jednak ta sama elastyczność może zostać wykorzystana przez cyberprzestępców jako element infrastruktury ataku.
W najnowszych obserwacjach webhooki n8n były nadużywane w kampaniach phishingowych, do dostarczania złośliwego oprogramowania oraz do fingerprintingu ofiar. Problem polega na tym, że publiczne endpointy webhooków mogą wyglądać wiarygodnie zarówno dla użytkowników, jak i części systemów bezpieczeństwa, ponieważ opierają się na legalnej usłudze chmurowej.
W skrócie
Atakujący wykorzystują publicznie dostępne webhooki n8n jako pośredni etap łańcucha infekcji. Linki do takich endpointów trafiają do wiadomości e-mail podszywających się pod współdzielone dokumenty, powiadomienia lub inne zaufane zasoby.
Po kliknięciu ofiara może zostać przekierowana na stronę z elementami socjotechnicznymi, takimi jak fałszywa CAPTCHA, a następnie uruchamiany jest mechanizm pobierania złośliwego pliku z zewnętrznej infrastruktury. Równolegle webhooki mogą działać jako piksele śledzące, pozwalające potwierdzić otwarcie wiadomości i profilować odbiorców.
- Nadużycia obserwowano co najmniej od października 2025 roku.
- Skala kampanii wzrosła do marca 2026 roku.
- W atakach wykorzystywano legalną infrastrukturę SaaS.
- Końcowym etapem bywało dostarczenie plików EXE lub MSI oraz uruchamianie narzędzi RMM.
Kontekst / historia
n8n to platforma low-code służąca do budowy automatyzacji i łączenia usług przez API. Jednym z jej podstawowych komponentów jest węzeł Webhook, który umożliwia uruchomienie workflow po otrzymaniu żądania HTTP. W typowym zastosowaniu to wygodny mechanizm integracyjny, wykorzystywany przez zespoły IT, DevOps i biznes.
Z perspektywy bezpieczeństwa istotne jest jednak to, że webhook może być publicznie osiągalnym adresem URL, zwracającym odpowiedzi HTTP i inicjującym dalszą logikę workflow. To sprawia, że legalna funkcja platformy może zostać przekształcona w narzędzie do serwowania treści phishingowych, przekierowań, kodu JavaScript lub śledzenia aktywności odbiorców.
Opisane kampanie wpisują się w szerszy trend, w którym napastnicy coraz częściej wykorzystują zaufane usługi chmurowe i narzędzia automatyzacji do ukrywania swoich działań. Zamiast budować własną, łatwą do zablokowania infrastrukturę, korzystają z gotowych platform o dobrej reputacji.
Analiza techniczna
Techniczny mechanizm nadużycia opiera się na tym, że publiczny webhook n8n może przyjmować żądania HTTP i zwracać odpowiedź bezpośrednio do przeglądarki użytkownika. Jeśli link do takiego webhooka zostanie osadzony w wiadomości e-mail, przeglądarka ofiary staje się odbiorcą treści wygenerowanej przez workflow.
W praktyce pozwala to atakującemu dostarczyć stronę HTML lub osadzić logikę JavaScript za pośrednictwem zaufanego hosta. Ofiara może zobaczyć ekran przypominający proces weryfikacji, na przykład CAPTCHA, choć w rzeczywistości jest to etap przygotowujący kolejną fazę ataku.
Po wykonaniu przez użytkownika określonej akcji uruchamiany jest skrypt inicjujący pobranie ładunku z zewnętrznego serwera. W badanych przypadkach końcowym payloadem były pliki wykonywalne albo instalatory MSI, po których uruchamiano zmodyfikowane wersje legalnych narzędzi do zdalnego zarządzania.
Szczególnie niebezpieczne jest wykorzystanie rozwiązań RMM, ponieważ takie aplikacje zapewniają atakującemu funkcje zdalnej administracji, wykonywania poleceń, utrzymania dostępu i komunikacji z infrastrukturą sterującą. Dodatkowo mogą one wyglądać mniej podejrzanie niż klasyczny malware, zwłaszcza w środowiskach firmowych.
Drugi scenariusz dotyczy fingerprintingu. W tym wariancie w wiadomości e-mail umieszczany jest niewidoczny obraz lub piksel śledzący kierujący do webhooka n8n. Samo otwarcie wiadomości może wywołać żądanie HTTP GET, które dostarcza operatorowi kampanii informacji o aktywności odbiorcy, a czasem także dodatkowych metadanych.
Konsekwencje / ryzyko
Najpoważniejsze ryzyko wynika z nadużycia reputacji legalnej platformy. Wiele organizacji koncentruje ochronę na blokowaniu domen jednoznacznie złośliwych, natomiast ruch do znanych usług chmurowych może nie zostać uznany za podejrzany na wczesnym etapie.
To zwiększa skuteczność phishingu i utrudnia filtrację na poziomie poczty, proxy oraz systemów reputacyjnych. Użytkownik widzi link prowadzący do wiarygodnie wyglądającej usługi, a część zabezpieczeń może dopuścić takie połączenie bez dodatkowej analizy.
Dodatkowe zagrożenie stanowi wykorzystanie legalnych narzędzi administracyjnych jako końcowego elementu infekcji. Jeśli nieautoryzowane oprogramowanie RMM zostanie uruchomione w środowisku przedsiębiorstwa, może zapewnić intruzowi trwałość, ruch boczny, możliwość kradzieży danych lub przygotowanie gruntu pod ransomware.
Ryzyko dotyczy również samej skuteczności kampanii. Webhooki używane jako piksele śledzące dają napastnikom szybki feedback na temat tego, kto otworzył wiadomość, kiedy to nastąpiło i które cele warto zaatakować ponownie. Takie dane pozwalają dynamicznie optymalizować kolejne fale phishingu.
Rekomendacje
Organizacje powinny rozszerzyć model oceny ryzyka o platformy automatyzacji i narzędzia low-code. Sam fakt, że usługa jest legalna, nie oznacza, że każdy publiczny endpoint działający w jej ramach jest bezpieczny.
Na poziomie ochrony poczty i ruchu web warto wdrożyć następujące działania:
- wykrywanie wiadomości zawierających linki do publicznych webhooków,
- analizę dynamicznie generowanych stron otwieranych z wiadomości e-mail,
- monitorowanie łańcuchów przekierowań oraz aktywności JavaScript po kliknięciu,
- blokowanie lub oznaczanie wiadomości z zewnętrznymi pikselami śledzącymi.
Na poziomie endpointów i systemów EDR szczególną uwagę należy zwrócić na:
- pobieranie plików EXE i MSI po otwarciu linków z poczty,
- uruchamianie narzędzi RMM poza zatwierdzonym procesem IT,
- nietypowe połączenia wychodzące po instalacji oprogramowania administracyjnego,
- próby tworzenia mechanizmów trwałości przez aplikacje zdalnego zarządzania.
Dla zespołów SOC i threat huntingu zasadne są także:
- korelacja danych z poczty, proxy, DNS i EDR,
- wyszukiwanie zdarzeń otwarcia wiadomości kończących się żądaniami HTTP do webhooków,
- utrzymywanie listy dozwolonych narzędzi RMM i alertowanie na każde nieautoryzowane wdrożenie,
- monitorowanie anomalii w ruchu do usług automatyzacji workflow.
Po stronie administratorów i dostawców workflow automation ważne jest ograniczanie ekspozycji publicznych endpointów, stosowanie uwierzytelniania tam, gdzie to możliwe, oraz analiza nietypowych wzorców wykorzystania webhooków do generowania treści HTML.
Podsumowanie
Nadużycie webhooków n8n pokazuje, że nowoczesne kampanie phishingowe coraz częściej opierają się nie na klasycznych, łatwo wykrywalnych domenach, lecz na zaufanych usługach SaaS. W takim modelu kluczową rolę odgrywa elastyczność legalnej platformy, która może zostać wykorzystana do hostowania etapów pośrednich ataku.
Dla obrońców oznacza to konieczność odejścia od prostego zaufania do reputacji domeny i klasyfikacji aplikacji jako legalnej. Skuteczna detekcja wymaga analizy całego łańcucha zdarzeń — od wiadomości e-mail, przez publiczny webhook, po uruchomienie skryptu i instalację narzędzia zapewniającego zdalny dostęp.
Źródła
- The Hacker News — https://thehackernews.com/2026/04/n8n-webhooks-abused-since-october-2025.html
- Cisco Talos Blog — https://blog.talosintelligence.com/
- n8n Docs: Webhook node documentation — https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/
- n8n Docs: Workflow development for Webhook node — https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/workflow-development/
- n8n Docs: Configure n8n webhooks with reverse proxy — https://docs.n8n.io/hosting/configuration/configuration-examples/webhook-url/