Wykrywanie ataków phishingowych z pomocą AI: narzędzia, modele i integracja z istniejącymi systemami

Cel czytelnika: szybciej wyłapać phishing, nie przepłacając

Intencja jest prosta: ograniczyć liczbę skutecznych ataków phishingowych przy minimalnym naruszeniu istniejącej infrastruktury i budżetu. Klucz to takie dobranie narzędzi AI i modeli, aby sensownie podnieść jakość detekcji, nie budując od zera całego SOC ani nie przepalając pieniędzy na zbędne licencje.

Frazy pomocnicze: wykrywanie phishingu AI, klasyfikacja wiadomości e‑mail, modele NLP bezpieczeństwo, integracja AI z SIEM, tanie narzędzia antyphishing, automatyzacja SOC z AI, LLM w cyberbezpieczeństwie, filtry antyspam a phishing, analiza URL z wykorzystaniem AI, detekcja BEC i spear‑phishingu, open‑source do wykrywania phishingu, pipeline ML do maili.

Dlaczego phishing to dziś problem „AI vs AI”

Od masowego spamu do precyzyjnych, dopracowanych kampanii

Phishing przeszedł drogę od topornych, masowych kampanii do bardzo dopracowanych wiadomości szytych pod konkretnych odbiorców. Kiedyś wystarczało wychwycić literówki, egzotyczną domenę nadawcy i kilka podejrzanych linków. Dziś wiadomości potrafią idealnie naśladować komunikację działu finansów, szefa czy banku, a błędów językowych praktycznie nie ma.

Atakujący korzystają z tych samych technik, które stosują firmy marketingowe: segmentują użytkowników, przygotowują różne warianty wiadomości, testują je i mierzą skuteczność. W efekcie klasyczne reguły typu „słowo pilne + link + załącznik = phishing” przestają wystarczać, bo zbyt wiele legalnych wiadomości biznesowych spełnia takie kryteria.

Dodatkowo phishing coraz częściej nie polega na jednym, oczywistym mailu. To całe kampanie: kilka niewinnych wiadomości, potem subtelne zebranie informacji, a dopiero na końcu próba wyłudzenia pieniędzy lub danych. Detekcja pojedynczej wiadomości w oderwaniu od kontekstu relacji z nadawcą to za mało.

Jak generatywne modele językowe zwiększają jakość phishingu

Generatywne modele językowe (LLM) umożliwiają tworzenie perfekcyjnych stylistycznie i językowo treści w dowolnym języku, w tym po polsku. Przestępcy używają ich do:

• generowania wielu wariantów tej samej kampanii phishingowej, co utrudnia tworzenie stabilnych reguł i sygnatur,
• imitowania stylu komunikacji konkretnej osoby (na podstawie wcześniejszej korespondencji),
• tłumaczenia treści na wiele języków z zachowaniem naturalnego brzmienia,
• automatycznego odpowiadania ofierze w dalszym ciągu rozmowy.

To oznacza, że po drugiej stronie jest „AI copywriter” piszący lepsze maile phishingowe niż większość ludzi. Bez zastosowania własnych modeli AI pojawia się asymetria – ręcznie ustawiane filtry lub proste skanery treści nie mają szans nadążyć za taką skalą i zmiennością.

Dlaczego klasyczne filtry antyspamowe zaczynają przegrywać

Filtry antyspamowe są bardzo skuteczne w blokowaniu masowych kampanii reklamowych i prostych phishingów, ale gorzej radzą sobie z:

• spear‑phishingiem – pojedyncze, dopracowane wiadomości do kluczowych osób,
• BEC (Business Email Compromise) – przejęcie skrzynki i prowadzenie rozmowy z wewnętrznego adresu,
• szarym obszarem – wiadomości wyglądają na biznesowe, ale zawierają subtelne manipulacje.

Stare podejścia opierają się głównie na reputacji IP, prostych cechach wiadomości i statystyce słów. Generatywne treści wyglądają jak typowe maile biznesowe, więc statystycznie „pasują” do normy. To powoduje wzrost fałszywych negatywów – wiadomości phishingowe, które przechodzą przez filtr, bo nie wyglądają jak spam.

Drugim problemem jest brak kontekstu organizacyjnego: klasyczny filtr nie wie, że księgowość nigdy nie wysyła linków do zewnętrznych serwisów płatności, a dział IT nie prosi o podanie hasła w mailu. AI może uwzględnić takie reguły probabilistycznie, łącząc analizę treści z profilem zachowań w organizacji.

Co realnie daje dołożenie AI do istniejącej ochrony

Dodanie warstwy AI nie musi oznaczać wymiany całej infrastruktury. Często wystarczy „dokleić” moduł analityczny do obecnych filtrów, aby osiągnąć kilka praktycznych efektów:

• Redukcja fałszywych pozytywów – wiadomości oznaczone jako podejrzane przez klasyczny filtr mogą być ponownie ocenione przez model NLP. Dzięki temu mniej legalnych maili trafia do spamu lub kwarantanny.
• Priorytetyzacja alertów – zamiast setek równorzędnych zgłoszeń, SOC dostaje listę ułożoną według szacowanego ryzyka. To bezpośrednio oszczędza czas analityków.
• Automatyzacja reakcji – wiadomości z bardzo wysokim wynikiem ryzyka mogą być automatycznie kierowane do kwarantanny, a użytkownik dostaje prostą informację z możliwością zgłoszenia, jeśli to błąd.
• Lepszy kontekst dla analityków – model może generować krótkie streszczenie ryzyka: „prośba o zmianę numeru konta bankowego, ton pilny, nadawca spoza domeny, domena świeża – wysokie ryzyko BEC”.

W praktyce najtańszy i najszybszy zwrot daje podejście hybrydowe: zostawić klasyczne filtry tam, gdzie działają dobrze, a AI wdrożyć jako warstwę „drugiej opinii” i narzędzie priorytetyzacji w SOC.

Podstawy techniczne: jak AI „czyta” i ocenia wiadomości phishingowe

Mapa pojęć: NLP, embeddings, klasyfikacja i modele generatywne

Żeby sensownie rozmawiać o wdrożeniu, wystarczy kilka kluczowych pojęć:

• NLP (Natural Language Processing) – techniki pozwalające maszynom analizować i rozumieć tekst. Tu: treść maili, czaty, SMS‑y.
• Embeddings – numeryczne reprezentacje tekstu. Fragment tekstu zamienia się na wektor liczb, który można podać do klasyfikatora lub porównywać między sobą.
• Klasyfikacja binarna – podział na dwie klasy, np. phishing vs legit. Prostsze, często tańsze obliczeniowo.
• Klasyfikacja wieloklasowa – np. phishing, spam marketingowy, komunikacja wewnętrzna, transakcje finansowe. Przydaje się do dokładniejszego routingu maili w organizacji.
• Modele generatywne (LLM) – potrafią nie tylko klasyfikować, ale też tworzyć tekst i uzasadnienia oceny. Można je wykorzystać jako „inteligentny filtr” drugiego poziomu.

W praktycznych wdrożeniach często łączy się kilka poziomów: proste modele do wstępnej filtracji i tanie scoringi oraz bardziej zaawansowany model (np. LLM w chmurze) tylko dla najtrudniejszych przypadków.

Zakres analizy: nie tylko treść wiadomości

Model do wykrywania phishingu analizuje więcej niż sam tekst maila. Najważniejsze źródła sygnałów:

• Treść e‑maila – tematyka, ton wypowiedzi, obecność próśb o dane, linków, instrukcji płatności, elementów socjotechnicznych.
• Nagłówki – adres From, Reply‑To, Received, ścieżka przekazywania, nietypowe pola X‑, czas wysłania, strefa czasowa.
• Adresy nadawcy i odbiorcy – domeny, podobieństwo liter (typo‑squatting), różnice między adresem wyświetlanym a faktycznym.
• Linki (URL) – domena docelowa, ścieżka, słowa kluczowe, przekierowania, długość, ukryte parametry.
• Załączniki – typ pliku, nazwa, obecność makr, niespójność rozszerzenia i deklarowanego typu MIME.
• Kontekst użytkownika – historia kontaktu z nadawcą, typowe godziny korespondencji, język, w jakim zwykle się komunikują.

Najtańsze wdrożenia skupiają się na treści, domenie nadawcy i linkach. Z czasem można dorzucać kolejne sygnały, np. historię komunikacji i dane z SIEM.

Modele regułowe, klasyczny ML i nowoczesne modele językowe

Istnieją trzy główne podejścia do budowania detekcji phishingu:

• Reguły i sygnatury – np. SpamAssassin. Zbiór ręcznie pisanych zasad: słowa kluczowe, heurystyki, reputacja IP, DMARC/SPF/DKIM. Bardzo tanie w utrzymaniu, ale słabo skalują się na nowe, kreatywne ataki.
• Klasyczny ML – np. TF‑IDF + regresja logistyczna, SVM, XGBoost. Tekst zamieniany jest na cechy, a model wypluwa prawdopodobieństwo phishingu. Trenowanie jest stosunkowo tanie, a działanie szybkie – idealne dla mniejszych firm.
• Nowoczesne modele językowe (BERT, RoBERTa, LLM) – lepiej rozumieją kontekst, ironię, złożone instrukcje. Wymagają więcej mocy obliczeniowej, ale można korzystać z wersji pre‑trenowanych i tylko je dostroić lub używać via API.

Praktyczny model kosztowy: reguły robią wstępną filtrację, klasyczny ML poprawia jakość na poziomie masowych maili, a LLM jest odpalany tylko na małym procencie trudnych przypadków, gdzie stawka jest najwyższa (np. korespondencja działu finansów).

Łączenie sygnałów: scoring ryzyka zamiast prostego „spam/nie spam”

Skuteczna ochrona phishingowa rzadko opiera się na twardej, binarnej decyzji. Bardziej opłaca się zbudować scoring ryzyka, który łączy wiele sygnałów:

• prawdopodobieństwo phishingu z modelu NLP,
• reputację domeny nadawcy,
• wynik DMARC/SPF/DKIM,
• typ i zawartość załączników,
• historię relacji z nadawcą,
• dane z SIEM (np. czy użytkownik miał już podejrzane logowania).

Na tej podstawie można zdefiniować progi:

• niski wynik – mail przechodzi normalnie, może dostaje niewidoczny tag,
• średni wynik – mail trafia do skrzynki, ale z ostrzeżeniem w nagłówku lub banerem,
• wysoki wynik – kwarantanna, powiadomienie do SOC, ewentualnie prosty formularz dla użytkownika, aby zgłosił, że to jednak błąd.

Takie podejście minimalizuje fałszywe alarmy dla zwykłych pracowników i skupia uwagę SOC na naprawdę krytycznych przypadkach. To z kolei pozwala działowi bezpieczeństwa funkcjonować z mniejszym zespołem lub bez nocnych dyżurów „pod każdy bzdurny alert”.

Typy ataków phishingowych a podejście AI do ich wykrywania

Phishing masowy, spear‑phishing i BEC – różne sygnały, różna trudność

Różne typy phishingu wymagają innych strategii detekcji:

• Phishing masowy – prosty, często do szerokiej grupy, wciąż w miarę skuteczny na mniej świadomych użytkowników. Tu dobrze działają klasyczne filtry antyspamowe i proste modele ML.
• Spear‑phishing – wiadomości do konkretnych osób, często bogate w szczegóły z LinkedIn, strony firmowej, social mediów. Tekst wygląda jak normalna korespondencja biznesowa; kluczem są niewielkie anomalie (nowa domena, nietypowa prośba, niespodziewane załączniki).
• BEC (Business Email Compromise) – przejęcie legalnej skrzynki i wysyłanie wiadomości z prawidłowej domeny. Sama reputacja domeny nie pomaga; trzeba analizować zachowanie i treść.

Dla phishingu masowego AI jest „przyspieszaczem”, który filtruje więcej błędów niż człowiek. Natomiast w spear‑phishingu i BEC AI pełni rolę analityka, który zauważa drobne odchylenia: nagły, agresywny ton u „spokojnego” wcześniej nadawcy, eksperymenty z nowymi kontami bankowymi, presję czasu.

W praktyce warto zbudować osobne ścieżki scoringu dla różnych ról. Maile do CFO lub działu płatności mogą mieć dużo niższy próg reakcji, a każdy sygnał związany z przelewami lub zmianą numeru konta powinien znacznie podnosić ryzyko.

Ataki z fałszywymi stronami logowania i rola analizy URL

Duża część phishingu polega na przekierowaniu użytkownika na fałszywą stronę logowania. AI może tu działać na kilku poziomach:

• Analiza samego URL – długość, dziwne parametry, znak podobne (homoglyphs), świeżo zarejestrowane domeny, domeny w egzotycznych TLD, domeny przypominające markę (np. paypa1.com).
• Renderowanie strony i analiza treści – porównanie layoutu strony z oryginalną (np. znany bank), wykrywanie formularzy logowania, analiza logotypów i tekstów.
• Porównanie z bazą znanych marek – embedding tekstu i struktury strony, porównanie „podobieństwa semantycznego” do legalnych stron.

Phishing z załącznikami i „living off the land”

Coraz więcej kampanii phishingowych nie opiera się na linku, tylko na załączniku: fakturze, CV, potwierdzeniu przelewu, a nawet udawanych dokumentach z chmury (np. „SharePoint_document.pdf.html”). Atakujący często używają legalnych narzędzi (makra Office, skrypty PowerShell), więc klasyczne antywirusy mają ograniczone pole manewru.

AI może tu pomóc na kilku warstwach, zaczynając od najtańszych:

• Analiza nazwy i typu pliku – kombinacja słów „invoice”, „payment”, „urgent” w połączeniu z nietypowym rozszerzeniem (.html, .hta, .lnk) powinna podnosić scoring.
• Statisczna analiza treści – wyciągnięcie metadanych z dokumentu (autor, narzędzia, język), sprawdzenie, czy nie ma ukrytych arkuszy, podejrzanych formuł, zakodowanych fragmentów base64.
• Model ML dla makr i skryptów – klasyfikator trenuje się na kodzie VBA, PowerShell, JS osadzonym w dokumentach. Wektor cech może obejmować użycie konkretnych funkcji (np. Shell, CreateObject, DownloadFile), zagnieżdżenia, zaciemnianie.
• Korelacja treści maila z załącznikiem – LLM może sprawdzić, czy opis w treści pasuje do pliku. Jeżeli mail mówi o „krótkim zestawieniu sprzedaży”, a w załączniku jest plik instalatora .msi o losowej nazwie, to sygnał ostrzegawczy.

W trybie „budżetowym” warto zacząć od prostych reguł (rozszerzenia, rozmiar, metadane) oraz klasyfikatora dla kodu makr. Pełne sandboxy detekcyjne są drogie i wymagają utrzymania, ale mogą być zlecane selektywnie: tylko dla załączników z wysokim scoringiem ryzyka.

Phishing wielokanałowy: e‑mail, SMS, komunikatory

Kampanie phishingowe coraz częściej nie kończą się na skrzynce pocztowej. Użytkownik dostaje mail, potem SMS „przypominający”, a na koniec wiadomość na Teamsach czy WhatsAppie. Bez centralnej analizy trudno zorientować się, że to jedna kampania.

Modele AI mogą łączyć kropki, jeżeli przekaże się im dane z różnych kanałów:

• Normalizacja treści – sprowadzenie do wspólnego formatu: tekst maila, treść SMS, zrzut z komunikatora. Tu przydają się embeddings, które zamieniają treści na wektory porównywalne między sobą.
• Wykrywanie podobnych komunikatów – porównanie „semantyczne” wiadomości. Nawet jeśli treści nie są identyczne, model może wyłapać, że wszystkie mówią o „pilnej dopłacie do przesyłki” lub „weryfikacji konta bankowego”.
• Identyfikacja kampanii – clustering wiadomości na podstawie podobieństwa embeddingów + metadane (domena, kraj nadawcy, godziny wysyłki). W SOC zamiast setek pojedynczych alertów dostajemy kilka „kampanii”.

Na start nie trzeba integrować wszystkich kanałów. Praktyczny kompromis: e‑mail + oficjalne komunikatory firmowe (Teams, Slack). SMS i prywatne komunikatory można dołączyć później, zwykle w formie dobrowolnych zgłoszeń użytkowników lub danych od operatorów.

Przegląd narzędzi: od gotowych usług po rozwiązania open‑source

Gotowe usługi chmurowe i dodatki do skrzynek

Dla wielu firm najsensowniejszym pierwszym krokiem jest wykorzystanie gotowych usług wbudowanych w platformę pocztową lub jako dodatek SaaS. Koszty są przewidywalne (abonament), a wdrożenie szybkie.

Typowe kategorie rozwiązań:

• Wbudowane filtry dostawców poczty – Microsoft Defender for Office 365, Google Workspace Security. Oferują podstawowe modele ML, sandboxy, reputację domen. Dla większości MŚP to „must have” i często wystarczający poziom ochrony, jeśli dobrze skonfiguruje się polityki.
• Secure Email Gateway (SEG) nowej generacji – produkty firm specjalizujących się w ochronie poczty, które deklarują użycie AI/ML. Zwykle pracują jako brama przed serwerem pocztowym i dodają warstwę detekcji URL, załączników, BEC.
• Plug‑iny / add‑iny do klienta poczty – lekkie rozszerzenia do Outlook/GSuite, które wyświetlają banery ostrzegawcze, umożliwiają zgłaszanie podejrzanych maili jednym kliknięciem i wysyłają dane do centralnego modelu.

Z punktu widzenia kosztów i wysiłku wdrożeniowego najrozsądniej najpierw „wycisnąć” maksimum z rozwiązań natywnych (Microsoft/Google), dopiero potem myśleć o dodatkowym SEG czy budowaniu własnych modeli.

Platformy klasy SOC z modułami AI

W większych organizacjach, które mają SOC, pojawia się inny segment narzędzi: SIEM, SOAR, XDR z funkcjami AI. Tu phishing jest tylko jednym z typów incydentów, ale dobrze wykorzystane moduły AI mogą znacząco odciążyć analityków.

Typowe funkcje, które warto wykorzystać:

• Automatyczne grupowanie alertów – zamiast 100 osobnych zgłoszeń o podobnym phishingu system tworzy jedno „zdarzenie zbiorcze”. Zwykle wykorzystuje do tego embeddings i klasyfikatory anomalii.
• Skrypty SOAR z LLM – playbook może wysłać najtrudniejsze przypadki do modelu generatywnego, który przygotuje streszczenie, ocenę ryzyka i propozycję działania (np. „zablokować domenę, powiadomić użytkowników z grupy finanse”).
• Modele UEBA (User and Entity Behavior Analytics) – analiza, czy dany użytkownik zachowuje się typowo: otwiera maile z nietypowych krajów, klika w linki, na które wcześniej nie reagował, czy nagle masowo odpowiada na podejrzane wiadomości.

Wdrożenie pełnego SOC z SIEM/SOAR to duży wydatek, ale nie trzeba robić tego na raz. Możliwy jest etap „SOC‑light” u dostawcy MSSP, który ma już gotowe integracje AI, a wewnątrz firmy utrzymuje się tylko minimalny zespół kontaktowy.

Open‑source dla detekcji phishingu

Dla zespołów z minimalnym budżetem, ale z kompetencjami technicznymi, kuszące są projekty open‑source. Dają dużą elastyczność i kontrolę nad danymi, kosztem samodzielnego utrzymania.

Elementy składanki, które można złożyć w działający system:

• Silniki bazowe – SpamAssassin, Rspamd, OpenDKIM, OpenDMARC. To fundament do obsługi reguł, SPF/DMARC i klasycznego antyspamu.
• Biblioteki NLP – Hugging Face Transformers, spaCy, fastText. Pozwalają zbudować embeddings i proste klasyfikatory phishingu we własnym zakresie.
• Modele pretrenowane – BERT‑y i RoBERTy trenowane na zadaniach klasyfikacji tekstu. Wystarczy je dostroić na swoich danych „phishing vs legit”, bez trenowania od zera.
• Narzędzia do analizy URL i HTML – open‑source’owe crawlery, detektory phishingu URL, biblioteki do renderowania stron w trybie headless (np. Playwright, Puppeteer).

Wariant oszczędny: nie tworzyć od razu rozbudowanego systemu, tylko dopisać moduł ML do istniejącego filtra (np. Rspamd) i używać go początkowo jedynie jako dodatkowego „scorera”, bez automatycznego blokowania.

API LLM jako „zewnętrzny analityk”

Dla firm, które nie chcą (lub nie mogą) utrzymywać własnej infrastruktury ML, praktyczną opcją są API modelów językowych. Model działa jak zewnętrzny konsultant: dostaje uproszczony kontekst maila i zwraca ocenę ryzyka oraz krótkie uzasadnienie.

Podstawowe wzorce użycia:

• Asystent analityka – SOC otwiera zgłoszenie, a system automatycznie dopytuje LLM o podsumowanie i rekomendację. Oszczędza to wiele minut czytania przy każdym incydencie.
• Druga opinia dla wysokiego scoringu – jeżeli klasyczne modele ML ocenią mail jako ryzykowny, LLM może potwierdzić, czy rzeczywiście chodzi o phishing, a nie o nietypowy, ale legalny przypadek.
• Generowanie treści szkoleniowych – z realnych, zanonimizowanych kampanii phishingowych można automatycznie tworzyć przykłady do ćwiczeń dla pracowników.

Ważna kwestia to prywatność: przy korzystaniu z chmurowego LLM trzeba zadbać o anonimizację treści maili i odpowiednie zapisy w umowach (DPA, lokalizacja danych). Często korzystniejszy jest model hostowany w ramach chmury dostawcy poczty, który i tak przetwarza te dane.

Projekt prostego pipeline’u AI do wykrywania phishingu (wariant „MVP na start”)

Założenia minimalnego, ale użytecznego systemu

MVP nie musi obejmować wszystkich kanałów i scenariuszy. Sensowny wariant „na początek” dla średniej firmy może wyglądać tak:

• działanie tylko na poczcie przychodzącej,
• analiza treści + nagłówków + linków,
• brak automatycznej blokady – jedynie banery i priorytetyzacja alertów,
• wykorzystanie uproszczonego modelu ML + kilku reguł,
• opcjonalnie – integracja z LLM tylko dla wąskiej grupy użytkowników wysokiego ryzyka (finanse, zarząd).

Celem MVP nie jest „złapanie wszystkiego”, tylko ograniczenie liczby niebezpiecznych kliknięć i odciążenie zespołu bezpieczeństwa przy sensownym koszcie infrastruktury.

Etap 1: zbieranie danych mailowych

Najpierw trzeba ustalić, skąd pipeline ma brać wiadomości. Typowe podejścia:

• Journaling / kopia ruchu – serwer poczty (Exchange, M365, Google) wysyła kopie wszystkich maili do dedykowanej skrzynki lub kolejki (np. Kafka, SQS). Moduł AI czyta tylko kopię, nie ingeruje w główny tor dostarczania.
• Webhook / API – w chmurze można zarejestrować „connector”, który wywołuje naszą usługę przy każdym nowym mailu. To wygodne do integracji z aplikacją serwerową.
• Okresowe skanowanie skrzynek – dla MVP w bardzo małej skali, skrypt działa co kilka minut, pobiera nowe wiadomości przez IMAP/Graph API i analizuje je z opóźnieniem.

Wariant bezpieczny na początek to journaling: nawet jeśli system AI przestanie działać, poczta nadal dochodzi, a my utrzymujemy pełny materiał do późniejszej analizy i trenowania modeli.

Etap 2: wstępne przetwarzanie i ekstrakcja cech

Każda wiadomość powinna zostać „rozebrana” na elementy, które wykorzysta model:

• Tekst – oczyszczenie z HTML (pozostawienie znaczenia linków), wyciągnięcie tematu i treści, normalizacja znaków.
• Nagłówki – From, Reply‑To, Received, SPF/DKIM/DMARC, identyfikacja domen i IP.
• Lista URL – domeny, ścieżki, parametry, informacja, czy link jest skracany (bit.ly itp.).
• Informacje o załącznikach – lista nazw, rozszerzeń, rozmiar, rodzaj MIME.

Na tym etapie dobrze jest wprowadzić prosty mechanizm redakcji/anonimizacji, jeżeli planuje się wysyłać cokolwiek do chmurowego LLM – np. zamiana nazw firm i numerów rachunków na placeholdery.

Etap 3: wielowarstwowy scoring ryzyka

Sercem pipeline’u jest obliczenie łącznego wyniku ryzyka. Sensownie jest to zorganizować warstwowo:

1. Warstwa regułowa – kilka jasnych zasad „hard‑fail”, np. domena w czarnej liście, ewidentnie fałszywy SPF/DMARC, znane złośliwe URL. Można od razu podnieść scoring powyżej ustalonego progu.
2. Klasyczny model ML – wykorzystujący cechy tekstowe (np. TF‑IDF) oraz techniczne (długość tematu, obecność faktury, liczba linków itp.). Zwraca prawdopodobieństwo phishingu.
3. Moduł URL – osobny scoring dla linków (reputacja, świeżość domeny, podejrzane TLD), który można znormalizować do wspólnej skali.

W pierwszej wersji łączny wynik może być zwykłą średnią ważoną, bez skomplikowanego ensemble learning. Ważniejsze jest, żeby progi decyzyjne były sensownie dobrane i łatwe do regulacji w konfiguracji.

Etap 4: decyzja i akcje po stronie poczty

Na bazie wyniku ryzyka ustala się akcje. Dla MVP wystarczą trzy poziomy:

• Niski poziom – brak akcji, ewentualnie tag w nagłówkach (X‑Phishing‑Score), który można wykorzystać w późniejszej analizie.
• Średni poziom – dodanie banera ostrzegawczego w treści maila („Ta wiadomość wygląda podejrzanie – sprawdź nadawcę i adresy URL przed kliknięciem”).
• Wysoki poziom – umieszczenie w kwarantannie lub w dedykowanym folderze „Podejrzane” + automatyczne zgłoszenie do zespołu bezpieczeństwa.

Etap 5: pętla feedbacku od użytkowników i analityków

Nawet najlepszy model bez informacji zwrotnej szybko przestaje być użyteczny. Minimalna pętla feedbacku nie musi być skomplikowana ani droga, wystarczą proste mechanizmy osadzone w poczcie i ticketingu.

• Przycisk „Zgłoś phishing” – dodatek do klienta poczty (Outlook, Gmail) przekierowujący podejrzane maile do dedykowanej skrzynki „phishing@…”. To najtańszy wariant – bez automatycznej integracji.
• Automatyczne etykietowanie zgłoszeń – każde zgłoszenie wzbogacone jest o aktualny scoring AI. Analityk widzi od razu, czy model uznał wiadomość za ryzykowną czy nie.
• Prosty workflow „prawdziwy / fałszywy alarm” – analityk jednym kliknięciem oznacza wynik (TP/FP/FN). Taka informacja trafia do bazy, z której raz na jakiś czas generuje się zestaw do ponownego trenowania modeli.

Na początek wystarczy, że dane z pętli feedbacku są gromadzone w jednym miejscu (np. prosty CSV lub tabela w bazie). Automatyzację trenowania można dołożyć później, gdy będzie już co trenować.

Etap 6: stopniowe zwiększanie automatyzacji

MVP powinien startować konserwatywnie, ale wraz z rosnącą pewnością do wyników można odblokowywać bardziej odważne działania. Najrozsądniejsza jest ewolucja w kilku krokach:

1. Tylko tagowanie i banery – system niczego nie blokuje, zbiera dane o skuteczności i buduje zaufanie użytkowników.
2. Kwarantanna dla najwyższego ryzyka – automatyczne zatrzymywanie jedynie wiadomości z bardzo wysokim scoringiem (np. > 0.95), z możliwością szybkiego „uwolnienia” przez analityka lub właściciela skrzynki.
3. Reguły automatycznej reakcji – po potwierdzeniu phishingu system może samodzielnie usuwać kopie z innych skrzynek, tworzyć zgłoszenia do IT o blokadę domeny, a w skrajnych przypadkach wymuszać reset haseł.

Dobrym kompromisem budżetowym jest zastosowanie pełnej automatyki tylko dla kont wysokiego ryzyka (finanse, HR, kadra kierownicza), a dla reszty – ograniczenie się do banerów i lekkiej kwarantanny.

Modele i techniki: od klasycznego ML po LLM w SOC

Proste modele ML – szybki start przy małym budżecie

Na początku nie trzeba inwestować w duże modele. Klasyczne podejście z lekkimi algorytmami jest tanie, transparentne i wystarczające, by odsiać sporą część kampanii masowych.

• Logistic Regression / Linear SVM – działają dobrze na cechach TF‑IDF z tematu i treści wiadomości. Są szybkie w trenowaniu i łatwe do wdrożenia jako mikroserwis.
• Drzewa decyzyjne / Random Forest – dobrze łączą cechy tekstowe z technicznymi (SPF, liczba linków, domeny, rozmiar maila). Pozwalają łatwo zrozumieć, które cechy najmocniej wpływają na decyzję.
• Modele liniowe + cechy ręcznie projektowane – np. „czy domena From ma mniej niż 30 dni?”, „czy jest słowo <urgent> w temacie?”, „czy Reply‑To różni się od From?”. Tego typu cechy podnoszą skuteczność niewielkim kosztem.

Przy takim podejściu punkt ciężkości jest na inżynierii cech, a nie na mocy obliczeniowej. W praktyce jeden niewielki serwer lub nawet kontener na istniejącej infrastrukturze starczy dla kilku tysięcy użytkowników.

Modele oparte na embeddings – złoty środek

Kiedy klasyczne podejścia zaczynają się „dławić” na bardziej wyrafinowanych mailach, dobrym krokiem jest przejście na embeddings tekstowe.

• Sentence-BERT / inny encoder z Transformers – przekształca temat i treść maila w gęste wektory, które są znacznie bardziej semantyczne niż gołe TF‑IDF.
• Klasyfikator nad embeddings – nad wektorami można postawić prosty model (np. Logistic Regression, XGBoost). Trening jest szybki, bo liczba cech jest ograniczona, a jakość zwykle rośnie.
• Wykrywanie „rodzin” kampanii – podobne maile mają podobne embeddings, więc można wykrywać całe kampanie, nawet jeśli różnią się drobnymi detalami (np. inne kwoty, inne nazwy firm).

Technicznie najbardziej opłacalne jest korzystanie z gotowych, lekkich encoderów (miniLM, DistilBERT itp.), które można uruchomić na CPU. GPU przydaje się dopiero przy bardzo dużej skali lub przetwarzaniu wsadowym.

Dostrajanie modeli Transformer pod phishing

Kolejny poziom to fine‑tuning pretrenowanych modeli. Nie trzeba budować architektury od zera, wystarczy kilkanaście tysięcy przykładów „phishing vs legit”, dobrze zbalansowanych i zróżnicowanych językowo.

Praktyczne wskazówki:

• Krótki kontekst – większość decyzji można podjąć na podstawie tematu i pierwszych kilkuset znaków treści. Cięcie zbyt długich maili oszczędza pamięć i czas inferencji.
• Włączenie cech technicznych – oprócz samego tekstu warto dodać do modelu kilka prostych cech liczbowych (np. jako dodatkową warstwę). Podnosi to czułość na ataki z dobrze sklonowanym językiem, ale podejrzanym nadawcą.
• Fine‑tuning okresowy – zamiast jednego dużego procesu trenowania co rok, lepiej co kilka miesięcy dodać warstwę danych z najnowszych kampanii.

Najważniejszy koszt przy takim podejściu to nie sprzęt, ale przygotowanie i utrzymanie zbioru treningowego. Bez dobrego data pipeline’u nawet najlepsza architektura będzie „ślepa”.

LLM w SOC: gdzie faktycznie mają sens

Modele generatywne są drogie, ale potrafią odciążyć analityków przy zadaniach wymagających zrozumienia kontekstu biznesowego, a nie tylko cech technicznych.

Najbardziej opłacalne zastosowania:

• Triaging trudnych przypadków – LLM dostaje temat, zanonimizowaną treść, wyniki SPF/DMARC, reputację domen oraz listę linków. Na tej podstawie przygotowuje streszczenie i ocenę, np. „wysokie ryzyko BEC, podszywanie się pod dyrektora finansowego”.
• Analiza łańcucha korespondencji – ataki BEC często trwają tygodniami. LLM potrafi w jednym przebiegu przeanalizować długą wymianę wiadomości, wyłapując moment, w którym wkracza atakujący.
• Wsparcie podczas incydentu – analityk może „rozmawiać” z modelem o konkretnej kampanii: dopytywać o podobne przypadki, potencjalne skutki i działania naprawcze. Przy dobrze zbudowanym kontekście działa to jak konsultacja z doświadczonym kolegą.

Raczej nie ma sensu używać LLM jako pierwszej linii detekcji masowych maili – będzie to po prostu zbyt drogie. Sprawdza się raczej w roli filtra drugiego stopnia dla niewielkiego procenta najtrudniejszych zdarzeń.

Modele hybrydowe: reguły + ML + LLM

Najrozsądniejsze architektury dla średnich organizacji to hybrydy, w których różne typy modeli obsługują różne poziomy złożoności.

• Reguły filtrują oczywistą „sieczkę” – znane domeny, podpisane malware, prymitywne próby podszywania się.
• Klasyczny ML lub embeddings obejmuje szeroki środek – większość zwykłych kampanii phishingowych i spam.
• LLM angażowany jest tylko przy „szarej strefie” – mailach, co do których klasyczny system ma niską pewność, oraz przy kontach wrażliwych.

Takie podejście ogranicza koszty inferencji, bo najdroższe zasoby używane są tam, gdzie rzeczywiście robią różnicę – w rzadkich, ale potencjalnie bardzo kosztownych incydentach.

Integracja z istniejącymi systemami: serwer poczty, SIEM, SOAR, helpdesk

Integracja z serwerem poczty

Najpierw trzeba zdecydować, gdzie fizycznie wpiąć się w przepływ poczty. Opcji jest kilka i każda ma inny balans między kosztem a kontrolą.

• Transport agents / connectors – rozszerzenia w Exchange / M365 / Google Workspace, które modyfikują wiadomość w locie (dodają nagłówki, banery, przekierowują do kwarantanny). Zapewniają małe opóźnienia, ale wymagają lepszej znajomości platformy.
• Brama pocztowa „przed” serwerem – osobny serwer, który przyjmuje cały ruch SMTP, analizuje go i dopiero potem przekazuje do właściwego serwera poczty. Zapewnia pełną kontrolę, ale zwiększa złożoność i punkty awarii.
• Tryb „mirror only” – journaling lub kopia do analizy offline, bez ingerencji w dostarczanie. To najtańszy i najmniej ryzykowny wariant na start, choć bez natychmiastowego wpływu na użytkowników.

Na pierwszym etapie sensowny jest tryb mirror + banery dodawane za pomocą natywnych reguł serwera poczty, na podstawie nagłówków X‑Phishing‑Score ustawianych przez moduł AI.

Integracja z SIEM – minimalny zakres, który ma sens

Podpinanie wszystkiego pod SIEM jest kuszące, ale kosztuje. Na początek wystarczy kilka dobrze dobranych typów zdarzeń.

• Alerty wysokiego ryzyka – każdy mail, który trafił do kwarantanny lub został oznaczony jako „prawie pewny phishing”, powinien generować zdarzenie w SIEM.
• Zgłoszenia użytkowników – informacje o tym, że użytkownik kliknął „Zgłoś phishing”, przydają się do korelacji z innymi logami (np. logowania z nietypowych lokalizacji).
• Akcje automatyczne – wszelkie działania typu: usunięcie maila z wielu skrzynek, blokada domeny, zmiana reguł na firewallu – powinny być logowane jako zdarzenia audytowe.

Z perspektywy budżetu ważne jest ograniczenie „szumu” – wysyłanie do SIEM każdego maila i każdego scoringu szybko podniesie koszty licencji i składowania. Lepiej logować jedynie informacje istotne z punktu widzenia incydentów.

Integracja z SOAR – automatyzacja krok po kroku

Jeśli w organizacji jest już SOAR, moduł phishingowy może stać się jednym z najcenniejszych źródeł danych. Kluczowe jest jednak nie przesadzić z automatyzacją.

Przykładowe playbooki o wysokim stosunku efektu do wysiłku:

• Playbook „Potwierdzony phishing” – po oznaczeniu maila jako phishing przez analityka:
  • SOAR wyszukuje wszystkie kopie tej wiadomości w innych skrzynkach,
  • przenosi je do kwarantanny,
  • dodaje domenę/URL do listy blokad,
  • wysyła powiadomienie do użytkowników, że mogą zignorować tę wiadomość.
• Playbook „Podejrzany link kliknięty” – po zdarzeniu EDR lub proxy:
  • SOAR identyfikuje maila, z którego pochodził link,
  • sprawdza scoring AI i, jeśli potwierdza ryzyko, uruchamia działania jak wyżej + zleca skanowanie stacji użytkownika.

Na początek wystarczy kilka takich scenariuszy, dobrze przetestowanych. Rozbudowa automatyzacji ma sens dopiero, gdy zespół zobaczy, które czynności są naprawdę powtarzalne.

Połączenie z systemem helpdesk / ITSM

Bez integracji z ticketingiem phishing szybko zamienia się w chaos mailowy. W wielu firmach da się jednak zbudować prostą integrację, nie dotykając głównej platformy.

• Automatyczne tworzenie zgłoszeń – dla alertów wysokiego ryzyka system sam tworzy ticket w JIRA/ServiceNow/Freshservice, przypisując go do kolejki bezpieczeństwa.
• Powiązanie z użytkownikiem – zgłoszenie zawiera informację o koncie, z którego wysłano/odebrano podejrzaną wiadomość, co ułatwia komunikację i ewentualne działania typu reset hasła.
• Szablony odpowiedzi – dla typowych sytuacji (fałszywy alarm, potwierdzony phishing, potrzeba dodatkowych informacji) można przygotować gotowe komunikaty, które analityk tylko minimalnie dostosowuje.

Na poziomie MVP wystarczy, że każda automatyczna akcja ma swoje odzwierciedlenie w ticketingu. Dzięki temu zespół widzi pełną historię interwencji, a audyt ma gdzie zajrzeć.

Dane treningowe, etykietowanie i ciągłe doskonalenie

Źródła danych do trenowania modeli

Największym wyzwaniem nie jest sam model, lecz zdobycie dobrej jakości danych z odpowiednimi etykietami. W praktyce sensownie jest łączyć kilka źródeł.

• Własne archiwum maili – realne wiadomości z organizacji są najbardziej reprezentatywne. Można wykorzystać:
  • maile zgłoszone przez użytkowników jako phishing,
  • maile usunięte przez tradycyjny antyspam,
  • próbkę „zwykłej” korespondencji jako klasę „legit”.

Najczęściej zadawane pytania (FAQ)

Jakie są najtańsze sposoby wykorzystania AI do wykrywania phishingu w e‑mailach?

Najmniej inwazyjny i kosztowny wariant to dołożenie prostego modelu NLP jako dodatkowej warstwy do obecnego filtra antyspamowego. Model ocenia tylko te wiadomości, które są „na granicy” – np. nie trafiły od razu do spamu, ale wyglądają podejrzanie. Dzięki temu nie przepalasz mocy obliczeniowej na oczywisty spam.

W praktyce sprawdza się podejście hybrydowe: zostawiasz DMARC/SPF/DKIM, klasyczne reguły i reputację IP, a AI traktujesz jako „drugą opinię” i narzędzie do priorytetyzacji alertów. Jeśli budżet jest bardzo ograniczony, zacznij od analizy samej treści, domen nadawców i linków, bez zaawansowanych korelacji w całej organizacji.

Czym różni się wykrywanie phishingu z użyciem AI od klasycznego filtra antyspamowego?

Klasyczne filtry antyspamowe opierają się głównie na prostych sygnałach: reputacji IP, słowach kluczowych, podstawowych cechach nagłówków i statystyce treści. Działają świetnie na masowy spam, ale gubią się przy pojedynczych, dopracowanych mailach typu BEC czy spear‑phishing, które wyglądają jak normalna komunikacja biznesowa.

AI (modele NLP, embeddings, klasyfikacja) analizuje treść w sposób zbliżony do człowieka: wyłapuje ton wypowiedzi, nietypowe prośby (np. zmianę numeru konta), strukturę rozmowy i łączy to z dodatkowymi sygnałami – domeną nadawcy, linkami, porą wysłania czy kontekstem relacji. Daje to wyższą skuteczność na trudnych przypadkach i mniejszą liczbę fałszywych alarmów.

Czy muszę wymieniać obecny system poczty lub SIEM, żeby dodać AI do wykrywania phishingu?

Nie. Najbardziej opłacalne jest „doklejenie” warstwy AI do tego, co już masz. W praktyce model działa jako osobny moduł analityczny, który dostaje kopię wiadomości (treść + nagłówki + podstawowe metadane) z istniejącego systemu i odsyła ocenę ryzyka lub kategorię (phishing, spam, komunikacja wewnętrzna itp.).

Integracja zwykle odbywa się przez:

• webhooki lub API po stronie bramki pocztowej (MTA) albo chmurowej poczty (Microsoft 365, Google Workspace),
• konektor do SIEM/SOAR, który wysyła podejrzane maile do analizy i odbiera scoring ryzyka,
• plugin do klienta pocztowego, jeśli zaczynasz bardzo budżetowo i nie chcesz ruszać infrastruktury serwerowej.

Wymiana całego systemu ma sens dopiero, gdy obecna platforma nie pozwala w ogóle na integracje.

Jakie modele AI najlepiej sprawdzają się do wykrywania phishingu w mailach?

Na poziomie „koszt vs efekt” najczęściej łączy się trzy warstwy:

• proste modele klasycznego ML (np. TF‑IDF + regresja logistyczna) do szybkiej, taniej filtracji masowych treści,
• model embeddings + klasyfikator (np. XGBoost) do dokładniejszego rozróżniania phishingu od normalnych maili biznesowych,
• LLM jako „ekspert drugiej linii” – wywoływany tylko dla najtrudniejszych, wysokowartościowych wiadomości (np. do zarządu, finansów).

Taki układ ogranicza koszty: najdroższy element (LLM) liczy tylko niewielki promil ruchu, a większość pracy wykonują lekkie, lokalne modele. Jeśli dopiero startujesz, sensownym krokiem jest model klasyfikacji binarnej phishing vs legit, a dopiero później rozbudowa o więcej klas (np. marketing, transakcje, komunikacja wewnętrzna).

Jak AI analizuje linki i załączniki w kontekście phishingu?

AI nie zatrzymuje się na samej treści maila. W praktyce analizowane są:

• linki (URL) – domena, długość, ścieżka, obecność podejrzanych słów, przekierowania, podobieństwo do znanych marek (typo‑squatting),
• załączniki – typ pliku, nazwa (np. „faktura_2024.pdf.exe”), niespójność rozszerzenia z typem MIME, obecność makr.

Model tekstowy może też ocenić opis załącznika w treści maila („musisz pilnie uruchomić załączony plik, aby odblokować konto”) i zestawić go z samym plikiem.

W wersji budżetowej często wystarczy analiza domeny i ścieżki URL oraz podstawowe reguły dla rozszerzeń załączników, a dopiero później dołożenie sandboxa czy głębszej analizy plików.

Czy LLM naprawdę pomagają w wykrywaniu phishingu, skoro przestępcy też z nich korzystają?

Tak, bo LLM po twojej stronie działają w innym trybie: nie generują treści phishingowych, tylko opisują i klasyfikują to, co przychodzi do organizacji. Potrafią np. streścić ryzyko: „prośba o zmianę numeru konta, ton pilny, nadawca spoza domeny, świeża domena – wysokie ryzyko BEC” i na tej podstawie podnieść priorytet alertu.

Żeby nie przepłacać, LLM warto używać selektywnie – tylko dla wiadomości z „szarej strefy”, które nie są oczywistym spamem ani jednoznacznie bezpieczne. Resztę ruchu lepiej obsłużyć tańszymi modelami wyspecjalizowanymi w klasyfikacji.

Od czego zacząć wdrażanie AI do ochrony przed phishingiem w małej lub średniej firmie?

Najbardziej rozsądny plan na start to:

• upewnić się, że podstawy są ustawione: DMARC, SPF, DKIM, sensowny filtr antyspamowy,
• wybrać prosty moduł AI do analizy treści + linków, najlepiej taki, który integruje się z twoją pocztą lub istniejącym SIEM,
• skonfigurować AI jako warstwę „drugiej opinii”, która:
  • zmniejsza liczbę fałszywych pozytywów (nie blokuje legalnych maili),
  • podnosi priorytet najgroźniejszych wiadomości (np. zmiana numeru konta, prośby o przelew).

Na koniec dorzuć prosty proces reagowania: automatyczna kwarantanna maili z najwyższym wynikiem ryzyka i możliwość łatwego zgłoszenia „to błąd” przez użytkownika. To daje szybry efekt przy małym naruszeniu infrastruktury i budżetu.