Jak budować modele klasyfikacji phishingu na bazie realnych kampanii mailowych

Dlaczego klasyfikacja phishingu wymaga realnych kampanii, a nie sztucznych danych

Różnica między „ładnymi” zbiorami benchmarkowymi a brudnymi danymi z produkcji

Model klasyfikacji phishingu zbudowany na sztucznym lub zbyt „wypolerowanym” zbiorze danych zachowuje się jak junior po jednym szkoleniu: na slajdach wszystko rozumie, ale w prawdziwym SOC-u gubi się po pierwszej godzinie. Publiczne zestawy maili są zazwyczaj zanonimizowane, zbalansowane, pozbawione duplikatów i skrajnych przypadków. To świetne środowisko do badań akademickich, ale w produkcji sytuacja wygląda zupełnie inaczej.

Realne skrzynki pocztowe są pełne szumu: automatyczne raporty, powiadomienia z systemów, newslettery o wątpliwej jakości, maile od partnerów pisane w pośpiechu, a do tego masa forwardów i odpowiedzi z cytowanymi wątkami. Jeśli model nigdy nie widział takiego „bałaganu”, będzie miał duży problem z uogólnieniem wiedzy z ładnych przykładów na prawdziwy ruch.

Druga sprawa: w zestawach benchmarkowych często brakuje kluczowego kontekstu – nagłówków technicznych, informacji o przekierowaniach czy metadanych z bramki pocztowej. Tymczasem w klasyfikacji phishingu to właśnie te „nudne” pola często rozstrzygają, czy mail jest niebezpieczny. Sam tekst wiadomości bywa podobny do legalnych kampanii marketingowych, więc model musi nauczyć się korzystać z wielu sygnałów jednocześnie.

Dynamika ataków i kreatywność napastników

Kampanie phishingowe zmieniają się jak moda w social mediach – coś, co było skuteczne miesiąc temu, dziś już nie działa, więc atakujący kombinują dalej. Powstają nowe szablony, nowe domeny, nowe sztuczki z linkami i załącznikami. Model wytrenowany na danych sprzed roku zaczyna „nie rozumieć” najnowszych wzorców, jeśli nie widzi świeżych przykładów.

Przestępcy obserwują działania producentów rozwiązań antyspamowych i bardzo świadomie je omijają. Jeśli filtr zaczyna blokować konkretne słowa kluczowe, phishing przesuwa się w stronę subtelnego socjotechnicznego języka: więcej aluzji, mniej oczywistych fraz typu „Twoje konto zostanie zablokowane”. Utrzymanie skutecznej klasyfikacji phishingu wymaga więc ciągłego dokarmiania modelu realnymi kampaniami, a nie jednorazowego treningu na „martwym” zbiorze.

Dochodzi do tego sezonowość. W okresie rozliczeń podatkowych rośnie liczba kampanii „na urząd skarbowy”, przed świętami – fałszywe przesyłki kurierskie i promocje, w okolicach dużych wycieków danych – podszywanie się pod znane serwisy. Model, który nie widzi tej sezonowości w danych treningowych, gorzej radzi sobie w newralgicznych okresach.

Przykład kampanii „aktualizacja hasła do Microsoft 365” w teorii i w praktyce

Teoretyczny przykład z prezentacji: mail z tytułem „Pilna aktualizacja hasła do Microsoft 365”, link prowadzi na oczywisty phishingowy landing z dziwną domeną, treść pełna błędów stylistycznych. Każdy filtr sobie z tym poradzi – także prosty, oparty na słowach kluczowych.

Praktyka z produkcji jest mniej wygodna. W prawdziwej skrzynce kampania może mieć temat „Zmiana zasad bezpieczeństwa konta służbowego”, nadawcę ustawionego na „Dział IT” z adresem w domenie bardzo podobnej do firmowej (typu it‑security‑nazwa‑firmy.com), a treść dopracowaną językowo. Linki mogą prowadzić przez kilka warstw przekierowań, z których pierwsze wyglądają zupełnie niewinnie – na przykład przez legalny serwis do skracania URL-i.

Dopiero nagłówki SMTP zdradzają, że mail nie wyszedł z serwerów Microsoft ani z serwerów firmowych: dziwne rekordy SPF, brak DKIM, podejrzany łańcuch Received z egzotycznymi adresami IP. To właśnie na takich niuansach musi uczyć się model klasyfikacji phishingu – i to dają tylko dane z realnych kampanii, nie podręcznikowe przykłady.

Dlaczego same słowa kluczowe nie wystarczają

Klasyczne filtry antyphishingowe wycinały wiadomości zawierające słowa typu „pilne”, „zresetuj hasło”, „Twoje konto zostanie zablokowane”. Dziś atakujący bez problemu obchodzą takie reguły. Piszą spokojnym, „urzędowym” językiem, unikają jasnych wezwań do natychmiastowej akcji lub przerzucają je do obrazków zamiast tekstu.

Model oparty wyłącznie na słowach kluczowych ma też inny problem: masę fałszywych alarmów. Legalne komunikaty z systemów bezpieczeństwa, ostrzeżenia z banków, wiadomości z działu HR – wszystkie używają podobnego słownictwa. Bez uwzględnienia kontekstu nadawcy, infrastruktury nadawania i nietypowych cech strukturalnych treści nie da się sensownie oddzielić phishingu od „prawdziwych” ostrzeżeń.

Przechodząc od słów kluczowych do pełnoprawnych modeli klasyfikacji phishingu, wykorzystuje się zatem kombinację: sygnały techniczne z nagłówków, cechy URL-i, cechy stylometryczne i modele NLP. Dopiero połączenie tych źródeł pozwala wyjść poza płytką analizę słownikową.

Kontekst organizacji a obraz „normalnego” ruchu mailowego

To, co jest podejrzane w jednej firmie, w innej może być zupełnie standardowe. Software house otrzymuje mnóstwo maili z GitHuba, Jiry, narzędzi CI/CD, systemów monitoringu. Bank natomiast żyje komunikacją z klientami, dokumentami prawnymi i raportami. Model ignorujący specyfikę organizacji będzie bezradny wobec niuansów lokalnego „normalnego” ruchu.

Przykład: w jednej organizacji bardzo rzadko pojawiają się maile po francusku. Pojedyncza wiadomość w tym języku z prośbą o natychmiastowe przelanie środków jest dużo bardziej podejrzana niż w międzynarodowej korporacji, gdzie francuski to jeden z języków roboczych. Z tego powodu modele klasyfikacji phishingu oparte na realnych kampaniach zbierają dane z konkretnego środowiska i uczą się jego charakterystyki.

W dojrzałych zespołach bezpieczeństwa buduje się wręcz osobne modele dla różnych segmentów: inny model dla użytkowników biurowych, inny dla działów technicznych, jeszcze inny dla kadry zarządzającej. Wszystkie jednak bazują na tych samych fundamentach: realnych kampaniach, które naprawdę pojawiły się w skrzynkach konkretnej organizacji.

Jak pozyskiwać realne dane mailowe do treningu – źródła i ograniczenia

Główne źródła danych: bramki pocztowe, systemy antyspamowe i honeypoty

Pierwszym naturalnym źródłem danych do klasyfikacji phishingu są logi i archiwa z bramek pocztowych oraz systemów antyspamowych. Zazwyczaj przechowują one: surowe wiadomości lub ich części, wyniki skanowania antywirusowego, wstępne oceny ryzyka oraz metadane (czas, adresy IP, domeny). To baza, na której można zbudować pierwszy duży zbiór treningowy.

Drugim źródłem są systemy SIEM i SOC/CSIRT. Wiele incydentów klasyfikowanych jako phishing jest już oznaczonych w ticketach, raportach i dziennikach zdarzeń. Łącząc identyfikatory wiadomości (np. Message‑ID) z tymi incydentami, można uzupełnić zbiór maili o wiarygodne etykiety „phishing” bez nadmiernego ręcznego etykietowania.

Honeypoty mailowe to dodatkowe narzędzie, które pozwala zbierać kampanie wymierzone w ogół internetu, nie tylko w daną firmę. Tworzy się zestaw adresów, które nigdzie nie są używane produkcyjnie, a jedynie „wystawione” na spamery i phisherów. Wiadomości trafiające na takie skrzynki są z dużym prawdopodobieństwem złośliwe lub niechciane – świetny materiał na dodatkowy zbiór treningowy, zwłaszcza do wykrywania nowych trendów.

Raporty od użytkowników i dane z SOC jako złoto etykiet

Ogromną wartość mają maile zgłaszane przez użytkowników jako potencjalny phishing. Jeśli organizacja korzysta z wtyczek typu „Zgłoś phishing” w kliencie poczty, powstaje naturalny kanał pozyskiwania przykładów. Takie maile są często „świeże”, wyjęte prosto z realnych kampanii, które właśnie przechodzą przez firmę.

Należy jednak pamiętać, że nie wszystkie zgłoszenia użytkowników to faktyczny phishing – część okazuje się legalnymi newsletterami lub korespondencją biznesową. Dlatego idealnie jest połączyć zgłoszenia użytkowników z procesem weryfikacji przez SOC, a następnie przenosić sprawdzone przypadki do bazy treningowej jako wysokiej jakości etykiety.

W SOC/CSIRT można też znaleźć historyczne incydenty, w których dokładnie opisano wektor ataku. Taki opis (np. jakie domeny użyto, jaki był pretekst) pomaga potem przy projektowaniu cech modelu lub przy ręcznym tagowaniu kampanii w danych treningowych (np. kampanie „na kuriera”, „na Microsoft 365”, „na urząd skarbowy”).

Współpraca z działem bezpieczeństwa i administracją poczty

Bez porozumienia z zespołem odpowiedzialnym za infrastrukturę pocztową oraz bezpieczeństwo nie da się zbudować sensownego pipeline’u danych. Trzeba ustalić kilka kwestii: gdzie technicznie przechowywane są maile, jakie są obecne polityki retencji, kto ma dostęp do logów, kto odpowiada za anonimizację i kto decyduje, jakie dane można wynieść z systemów produkcyjnych do środowiska analitycznego.

Praktycznie sprawdza się prosta umowa: dział bezpieczeństwa dostarcza przepływ surowych maili lub ich wybranych części do dedykowanego data lake, a zespół ML odpowiada za ich przetwarzanie i anonimizację. Ważne, aby na wczesnym etapie spisać także zasady bezpieczeństwa danych: kto może je oglądać, w jakiej formie, z jakich środowisk (VPN, sieć wewnętrzna, brak możliwości kopiowania na nośniki zewnętrzne).

Warto zbudować zaufanie: jeśli zespół bezpieczeństwa widzi, że dane są traktowane rozsądnie (logowanie dostępu, minimalny zakres, szybka anonimizacja), chętniej pomoże rozszerzyć dostęp do dodatkowych źródeł (np. archiwum starych kampanii). Z drugiej strony, zespół ML zyska lepsze rozumienie kontekstu bezpieczeństwa i będzie w stanie projektować modele dopasowane do realnych potrzeb SOC.

Anonimizacja i tokenizacja danych mailowych

Maile to dane wyjątkowo wrażliwe: pełne adresów, nazwisk, numerów telefonów, danych biznesowych, czasem informacji finansowych lub medycznych. Zanim trafią do zespołu ML, muszą przejść proces anonimizacji. Prosty wariant to usunięcie lub zamiana:

• adresów e‑mail (np. na tokeny typu EMAIL_1, EMAIL_2),
• domen firmowych na placeholdery (np. firma.local),
• konkretnych nazwisk i imion, jeśli to możliwe, na ogólne tokeny PERSON,
• numerów telefonów na PHONE, identyfikatorów klienta na ID itp.

Bardziej zaawansowane podejścia używają narzędzi typu NER (Named Entity Recognition), aby automatycznie wykrywać i maskować wrażliwe fragmenty w treści wiadomości. Istotne jest zachowanie struktury tekstu (rozmieszczenie tokenów, długość zdań, formatowanie), bo to właśnie ten kontekst wykorzystują modele NLP.

W przypadku nagłówków technicznych zwykle wystarcza maskowanie adresów IP, pełnych domen i identyfikatorów sesji. Zostawia się natomiast informacje o typie rekordu (SPF, DKIM), wyniku walidacji (pass/fail), długości domeny, liczbie przekierowań – to dane, które nie zawierają danych osobowych, a są niezwykle cenne dla modelu.

Ograniczenia prawne i techniczne przy gromadzeniu danych

Zbieranie danych mailowych do klasyfikacji phishingu trzeba prowadzić w zgodzie z regulacjami, przede wszystkim RODO oraz wewnętrznymi politykami ochrony danych. Należy jasno określić cel przetwarzania (podniesienie bezpieczeństwa, rozwój systemów antyphishingowych), zakres danych, czas ich przechowywania oraz podmioty zaangażowane w przetwarzanie.

Często pojawia się ograniczenie retencji: bramki pocztowe przechowują tylko ostatnie X dni ruchu mailowego, logi są rotowane co kilka tygodni. To wymusza szybkie zbudowanie pipeline’u, który na bieżąco pobiera i przetwarza nowe wiadomości. Jeżeli ten etap zostanie odłożony, cenne kampanie znikną z logów, zanim trafią do zespołu ML.

Od strony technicznej barierą może być rozmiar danych. Kilka milionów maili to setki gigabajtów surowego tekstu i załączników. Rozsądnym krokiem jest ograniczenie zakresu: zaciąganie tylko nagłówków i części tekstowej, pomijanie dużych załączników binarnych na pierwszym etapie, a dopiero później – dla wybranych przypadków – analizowanie pełnej zawartości.

Prosty pipeline: od maila produkcyjnego do rekordu w data lake

Dobrym punktem startu jest ułożenie prostego, powtarzalnego przepływu danych. Przykładowy pipeline może wyglądać tak:

• Przechwycenie maila na bramce pocztowej lub przez system DLP (kopie wędrują do kolejki danych).
• Wstępna filtracja techniczna: odrzucenie wiadomości czysto systemowych, zdrowotnych raportów serwerów itp., które nie są interesujące dla klasyfikacji phishingu.
• Anonimizacja i tokenizacja pól wrażliwych (adresy, domeny wewnętrzne, imiona, ID klientów).
• Parsowanie do spójnego formatu (np. JSON z polami: nagłówki, body_text, body_html, lista URL-i, wyniki SPF/DKIM).
• Zapis do data lake z metadanymi: czas wpływu, źródło, wstępna etykieta (np. spam, clean, suspected phishing).

Etykietowanie maili jako phishing / nie‑phishing – jak zorganizować ten proces

Dlaczego jakość etykiet jest ważniejsza niż rozmiar zbioru

Model klasyfikacji phishingu uczy się tego, co damy mu w etykietach. Jeżeli połowa „phishingów” to w rzeczywistości marketing lub zwykły spam, model będzie gubił się na granicy między prawdziwym atakiem a uciążliwym, ale legalnym mailiem. Lepiej mieć mniejszy, ale dobrze opisany zbiór, niż miliony wiadomości z przypadkowymi oznaczeniami.

W praktyce źródła etykiet są niejednorodne: część pochodzi z systemu antyspamowego, część z ręcznych zgłoszeń, część z incydentów obsłużonych przez SOC. Jeśli potraktuje się je wszystkie jako jednakowo pewne, model zacznie powielać błędy nawarstwione przez lata. Zamiast tego sensownie jest przypisać różnym źródłom różny poziom zaufania i budować z nich spójny obraz.

Źródła etykiet i ich „wiarygodność”

Da się wyróżnić kilka typowych źródeł informacji o tym, czy mail jest phishingiem:

• reguły antyspamowe i silniki AV – wysoka czułość, ale sporo fałszywych alarmów; dobre jako wstępna podpowiedź, nie jako ostateczna prawda,
• incydenty potwierdzone przez SOC/CSIRT – zwykle najwyższej jakości etykiety (ktoś ręcznie potwierdził phishing, czasem z pomocą analizy sandboxowej),
• zgłoszenia użytkowników – świetne źródło, jeśli są weryfikowane, ale „na surowo” bywają chaotyczne,
• kampanie z honeypotów – w przeważającej mierze złośliwe lub niechciane, ale mniej reprezentatywne dla ruchu do realnych skrzynek użytkowników,
• symulowane kampanie szkoleniowe – dają czysty, kontrolowany phishing, ale czasem zbyt „książkowy” jak na prawdziwy świat.

Dobry kompromis to zbudowanie warstwy „agregatora etykiet”, który łączy te źródła w jedną decyzję. Przykładowo, jeśli mail został jednocześnie zatrzymany przez bramkę, zgłoszony przez użytkownika i potwierdzony przez SOC, trafia do zbioru „złotych etykiet”. Jeśli tylko przeszedł przez filtr spamowy – ląduje w zbiorze mniej zaufanym, wykorzystywanym np. do pre‑treningu lub jako dane pomocnicze.

Proces ręcznego etykietowania z udziałem analityków

Przy kluczowych projektach nie uciekniemy od ręcznego oznaczania części danych. Warto przygotować to tak, by analitycy SOC nie znienawidzili projektu po tygodniu. Zamiast rzucać im setki przypadkowych maili, lepiej zbudować prosty interfejs (nawet w formie wewnętrznej aplikacji webowej), który prezentuje:

• nagłówki i treść maila w czytelnej formie,
• wyciąg najważniejszych pól technicznych (SPF/DKIM, domeny, adresy IP, wyniki sandboxa),
• dotychczasowe „typy” – np. ocena bramki, oznaczenie użytkownika, informacje z SIEM.

Analityk wybiera etykietę (np. phishing, nie‑phishing, potencjalnie złośliwy, niejednoznaczny) i ewentualnie dodaje tag kampanii („kurier”, „reset hasła do M365”, „faktura”). Takie tagi kampanii później procentują przy analizie, które typy ataków wymykają się modelowi.

Dobrą praktyką jest losowanie maili do ręcznego etykietowania w sposób kontrolowany: np. skupiać się na przypadkach, w których obecny system ma wątpliwości lub się myli. Dzięki temu czas analityków zużywa się tam, gdzie przynosi największą poprawę jakości modelu.

Radzenie sobie z niejednoznacznością i „szarą strefą”

Mail z prośbą o dane karty lojalnościowej? Dla jednego analityka to zwykły marketing, dla innego – granica phishingu, bo użytkownik może poczuć się zmanipulowany. W takich przypadkach etykieta binarna („phishing / nie‑phishing”) bywa za ciasna.

W realnych projektach często stosuje się dodatkowe kategorie:

• spam marketingowy – legalny, ale niechciany, bez zamiaru kradzieży danych czy pieniędzy,
• podejrzany / wymagający dalszej analizy – wiadomość na tyle dziwna, że model powinien ją raczej odrzucić do ręcznej weryfikacji,
• testy wewnętrzne / kampanie szkoleniowe – „phishing” kontrolowany, który nie zawsze chcemy, by model blokował.

Takie wzbogacone etykiety pozwalają później zbudować np. model wieloklasowy albo sieć dwóch modeli: pierwszy odróżnia ataki od reszty, drugi – filtruje zwykły spam od legalnej poczty. Dzięki temu system nie musi zgadywać, czy newsletter z natrętną promocją to już zagrożenie, czy tylko irytacja.

Kontrola jakości etykiet i spójność między osobami

Jeżeli w etykietowanie zaangażowanych jest kilku analityków, szybko pojawia się problem spójności. Jedna osoba ma podejście „blokować wszystko, co pachnie podejrzanie”, inna – „dawać szansę”. Po kilku tysiącach przykładów widać to w danych.

Pomagają proste mechanizmy:

• podwójne etykietowanie części próbek – dwie osoby niezależnie oceniają ten sam mail, różnice są omawiane i korygowane,
• krótkie „guideline’y” z przykładami granicznymi (zrzuty ekranu, fragmenty treści), do których można się odwołać przy wątpliwościach,
• regularne przeglądy losowej próbki już oznaczonych maili – ktoś z doświadczeniem sprawdza, czy standardy są utrzymane.

Taki proces przypomina kalibrację zespołu. Zamiast liczyć, że wszyscy „czują” phishing tak samo, lepiej step by step ujednolicać kryteria. Po kilku iteracjach liczba sporów przy nowych mailach wyraźnie spada.

Aktualizacja etykiet w czasie – kampanie, które „dojrzewają”

Czasem dopiero po kilku dniach okazuje się, że niewinny mail z ofertą współpracy był początkiem łańcucha ataku. SOC łączy kropki, uznaje, że to część większej kampanii i zmienia klasyfikację z „podejrzany” na „phishing”. Jeśli model dalej trenuje się na starej etykiecie, uczy się na błędnych przykładach.

Dlatego przy projektowaniu bazy treningowej opłaca się przewidzieć możliwość aktualizacji etykiet. Każda wiadomość powinna mieć:

• pole z aktualną etykietą,
• historię zmian (kto i kiedy zmienił klasyfikację, z jakiego powodu),
• ewentualnie powiązanie z identyfikatorem kampanii lub incydentu w systemie ticketowym.

Pozwala to w kolejnych iteracjach treningu łatwo odświeżać etykiety i włączać w model nowe ustalenia zespołu bezpieczeństwa, zamiast „zamrażać” raz ustalony stan na zawsze.

Przygotowanie danych mailowych – czyszczenie, strukturyzacja i reprezentacja

Parsowanie maili do spójnej struktury

Surowa wiadomość w formacie MIME jest dla modelu mało strawna. Zanim jakikolwiek algorytm dostanie tę treść, trzeba ją rozebrać na części pierwsze: nagłówki, wersje tekstowe, HTML, załączniki. W idealnym świecie kończymy ze spójnym rekordem, np. w JSON, gdzie każda istotna informacja ma swoje pole.

Przy parsowaniu pojawiają się typowe problemy:

• różne kodowania znaków (wielojęzyczne kampanie, stare systemy pocztowe),
• niestandardowe lub uszkodzone nagłówki,
• treść pocięta na wiele części MIME, czasem mieszająca HTML, tekst i obrzydliwy quoted‑printable.

Na tym etapie przydają się biblioteki pocztowe, ale warto mieć też własne „łatki” na często spotykane błędy formatowania. Modelowi jest obojętne, czy nagłówek został poprawiony ręcznie czy przez bibliotekę – ważne, by informacje takie jak From, Reply‑To, łańcuch Received czy temat były dostępne w przewidywalnym miejscu.

Czyszczenie treści: co usuwać, a co zostawić

Przy czyszczeniu treści łatwo przesadzić. Ktoś wymyśla regułę „usuń wszystko, co wygląda na stopkę” albo „wywal linki, zostaw sam tekst” i nagle połowa sygnałów phishingowych znika. Ścieżka środkowa to zachowanie wszystkiego, co niesie semantykę lub strukturę, a usunięcie jedynie śmieci technicznych.

W praktyce często usuwa się lub normalizuje:

• tagi HTML niezwiązane z treścią (np. style, skrypty, trackery pikselowe),
• ciągi przypadkowych znaków dodane przez spamerów dla oszukania filtrów (np. długie sekwencje losowych liter),
• zbyt długie cytowane wątki poniżej właściwej wiadomości (ale najlepiej z jakimś limitem, by nie gubić kontekstu).

Z drugiej strony zwykle opłaca się zachować:

• informację o tym, czy mail zaczyna się szybką prośbą typu „Pilne!”,
• pierwsze kilka zdań głównej treści – tam najczęściej znajduje się pretekst socjotechniczny,
• linki i ich otoczenie tekstowe („kliknij tutaj, aby zaktualizować hasło”).

Niektóre zespoły decydują się na stworzenie dwóch wersji treści: „light” (po silnym czyszczeniu) do prostszych modeli i „full” (z minimalną ingerencją) dla modeli NLP, które same decydują, co jest istotne.

Normalizacja nagłówków i metadanych

W nagłówkach technicznych kryje się mnóstwo sygnałów, ale w surowej formie są bardzo niejednorodne. Jedna kampania ma pięć nagłówków Received, inna – trzydzieści. Domeny pojawiają się w różnych formach, czasem z subdomenami, czasem nie.

Przed zasileniem modelu warto nagłówki „spłaszczyć” do sensownych pól, np.:

• liczba serwerów na ścieżce Received,
• informacja, czy domena nadawcy i domena serwera źródłowego są powiązane,
• wynik SPF/DKIM/DMARC oraz obecność nagłówków Authentication‑Results,
• typ klienta pocztowego (o ile da się wydobyć) – podejrzane jest np. „Microsoft Outlook” wysyłany z nietypowego hosta.

Tak przetworzone metadane mogą posłużyć zarówno jako wejście do klasycznego modelu (zestaw cech numerycznych i kategorycznych), jak i jako dodatkowe tokeny w wejściu tekstowym (np. specjalne pola dodane na początku treści, typu [SPF_FAIL] [DKIM_NONE]).

Ekstrakcja i reprezentacja URL‑i

Linki są jednym z kluczowych elementów phishingu. Samo „występowanie linku” to za mało – liczy się jego domena, struktura, czasem długość ścieżki. Przy ekstrakcji URL‑i dobrze jest:

• wydzielić domenę główną (np. example.com) i ewentualnie znormalizować subdomeny,
• zapisać liczbę parametrów i długość URL‑a,
• sprawdzić obecność technik maskowania (np. domeny w ścieżce, skracacze linków).

Same domeny często anonimizuje się (np. corp.com → INTERNAL_DOMAIN), ale zachowuje się informację, czy domena jest wewnętrzna, czy zewnętrzna, nowa czy znana (na podstawie wewnętrznych list reputacyjnych). Dzięki temu model nie musi znać konkretnych nazw, by uczyć się, że „nagły link do nowej zewnętrznej domeny w mailu z działu finansowego” to podejrzany wzorzec.

Balans klas i strategie próbkowania

W rzeczywistych danych phishing to niewielki promil ruchu mailowego. Gdyby trenować model „jak leci”, nauczy się on genialnej strategii: zawsze mówić „nie‑phishing”. Dokładność będzie wysoka, ale z punktu widzenia bezpieczeństwa – bezużyteczna.

Trzeba więc świadomie podejść do proporcji klas:

• nadpróbkowanie phishingu (np. przez powielanie rzadkich przykładów lub techniki typu SMOTE, choć w tekstach z tym ostrożnie),
• podpróbkowanie klasy „nie‑phishing” – wybór reprezentatywnej, ale nieprzytłaczającej liczby legalnych maili,
• ważenie klas w funkcji straty modelu, tak by błąd na phishingu „bolał” bardziej niż błąd na legalnym mailu.

Często stosuje się mieszaninę tych podejść: początkowo buduje się zbiór w miarę zbalansowany do szybkich iteracji, potem dokłada się więcej przykładów „nie‑phishing”, by model nauczył się różnorodności normalnej korespondencji.

Reprezentacja tekstu: od bag‑of‑words do wektorów z modeli językowych

Od prostych reprezentacji do nowoczesnych embeddingów

Najprostsza reprezentacja tekstu to klasyczne bag‑of‑words lub bag‑of‑n‑grams. Każde słowo (lub fraza) dostaje swoje miejsce w wektorze, a wartości to liczniki lub wagi TF‑IDF. Dla maili technicznych, logów czy bardzo schematycznych kampanii to wciąż działa zaskakująco dobrze: phishing często używa powtarzalnych formuł typu „verify your account”, „urgent action required”, „aktualizacja hasła”.

Z czasem taki prosty model zaczyna jednak gubić niuanse. Nie odróżni „Twoje konto zostanie zawieszone” od „Twoje konto nie zostanie zawieszone, to tylko test phishingu”, jeśli w obu przypadkach dominuje słowo „konto” i „zawieszone”. Tu pojawiają się gęste reprezentacje, czyli embeddingi – wektory opisujące znaczenie słów lub całych zdań.

W praktyce widać często hybrydę:

• bazowy model oparty o TF‑IDF lub n‑gramy,
• dodatkowo kilka cech z prostych embeddingów (fastText, word2vec) – np. uśredniony wektor całej wiadomości,
• oraz kilkanaście „twardych” cech z nagłówków i URL‑i.

Takie połączenie bywa w zupełności wystarczające, zwłaszcza gdy zespół nie ma jeszcze doświadczenia z modelami transformatorowymi. Na etapie eksperymentów prostszy stos technologiczny ułatwia diagnozowanie błędów – jeśli coś działa źle, łatwiej dojść, czy winny jest preprocessing, dobór cech czy sam algorytm.

Reprezentacja wielomodalna: tekst + struktura + kontekst

Mail nie jest zwykłym dokumentem tekstowym. To mieszanka treści, metadanych, linków, a czasem też załączników. Model, który widzi wyłącznie „body”, traci dużą część obrazu. Dlatego dobrze jest zbudować reprezentację wielomodalną, gdzie różne źródła informacji dostają swoje „kanały”.

W prostym wariancie można po prostu skleić:

• wektor tekstowy (np. embedding całej wiadomości),
• wektor cech nagłówkowych (liczby, flagi logiczne),
• wektor cech URL‑owych i domenowych,
• kilka cech kontekstowych (np. czy nadawca był widziany w ostatnim tygodniu).

W bardziej zaawansowanym ujęciu da się potraktować każdą część jako osobny „widok” na maila: jeden model przetwarza treść, drugi – sekwencję URL‑i, trzeci – nagłówki, a na końcu ich reprezentacje są łączone w warstwie klasyfikacyjnej. To zbliża nas do architektur, które w praktyce działają najlepiej przy większych, różnorodnych zbiorach.

Inżynieria cech dla klasyfikacji phishingu – od prostych heurystyk do NLP

Heurystyki, które wciąż robią robotę

Stare, dobre reguły nie zniknęły tylko dlatego, że pojawiły się transformatory. Prosta cecha typu „liczba znaków wykrzyknika w temacie” bywa bardziej informatywna niż najbardziej wyrafinowany embedding. W realnych projektach często zaczyna się od kilkudziesięciu prostych wskaźników, które odzwierciedlają zdrowy rozsądek analityka SOC.

Klasyczny zestaw obejmuje m.in.:

• stosunek liczby linków do długości treści,
• obecność słów kluczowych w temacie i pierwszym akapicie („pilne”, „potwierdź”, „aktualizacja konta”, „faktura”),
• obecność słów typowych dla ataków finansowych („przelew”, „rachunek”, „contract”, „invoice”),
• prostą ocenę „krzyku” w temacie: wielkie litery, wykrzykniki, CAPSLOCK w słowach typu „WAŻNE”,
• nietypową godzinę wysyłki względem strefy czasowej organizacji.

Te cechy są nie tylko użyteczne dla modelu, ale też świetnie sprawdzają się przy tłumaczeniu decyzji interesariuszom. Łatwiej pokazać na zrzucie ekranu: „temat z trzema wykrzyknikami, nowa domena i prośba o pilny przelew” niż odwoływać się do abstrakcyjnego „wektora w przestrzeni 768‑wymiarowej”.

Cechy semantyczne: rozpoznawanie intencji maila

Phishing to nie tylko słowa, ale intencja. Ktoś chce, żeby odbiorca kliknął, podał dane, zainstalował coś lub przelał pieniądze. Dlatego przydają się cechy, które próbują uchwycić zamiar nadawcy, nawet jeśli używa on innych słów niż w poprzednich kampaniach.

Można to zrobić na kilka sposobów:

• proste klasyfikatory intencji zbudowane na osobnym zbiorze (np. „prośba o działanie”, „informacja jednostronna”, „newsletter”),
• reguły wykrywające pewne wzorce zdań („kliknij, aby…”, „zaloguj się, żeby…”, „podaj swoje dane…”),
• embeddingi zdaniowe (np. z modeli typu SBERT), porównywane z „wzorcami phishingu” – jeśli nowy mail jest semantycznie podobny do znanych przykładów, traktujemy to jako dodatkowy sygnał.

W jednej z organizacji zbudowano prosty klasyfikator intencji, który rozpoznawał cztery typy maili: marketing, operacyjny, wewnętrzny, „call‑to‑action z linkiem”. Ten ostatni, mimo że rzadki w normalnej korespondencji, był nadreprezentowany w phishingu. Dodanie samej tej jednej cechy poprawiło czułość modelu na nowe kampanie, których słownictwo nie pojawiało się wcześniej w zbiorze.

Cechy oparte na anomaliach względem profilu nadawcy

Ten sam tekst ma inne znaczenie, gdy wysyła go księgowa znana od lat, a inne, gdy przychodzi z przypadkowej domeny. Modele, które biorą pod uwagę „normalne” zachowanie nadawcy, mają wyraźną przewagę w detekcji ukrytych przejęć kont (ang. business email compromise).

Budując cechy „anomalii”, można wykorzystać m.in.:

• średnią długość maili wysyłanych przez danego użytkownika i odchylenie dla konkretnej wiadomości,
• typowy język i słownictwo nadawcy (np. język polski vs. nagły mail po angielsku),
• typowe grupy odbiorców (czy nadawca zwykle pisze do działu finansów, czy to nowy kierunek),
• częstotliwość wysyłki – nagły „wystrzał” maili do wielu odbiorców naraz.

To już zahacza o modele behawioralne, często utrzymywane poza głównym klasyfikatorem phishingu. Jednak nawet proste liczby – jak „czy nadawca pisał już kiedyś do tego odbiorcy” – potrafią mocno podbić skuteczność klasyfikacji.

Cechy z analizy struktury HTML i ukrytych elementów

Phishing coraz częściej przypomina piksel‑perfect kopię witryny banku czy serwisu SaaS. Analiza gołego tekstu nie odda różnic w layoutcie, ukrytych formularzach czy technikach maskowania elementów. Przydaje się więc warstwa cech wyciągniętych z HTML‑a.

Na radarze powinny znaleźć się m.in.:

• obecność <form> w treści maila lub osadzonych ramkach,
• ukryte elementy (style typu display:none, czcionki w kolorze tła),
• nietypowe kombinacje atrybutów w linkach (np. onclick z JS‑em maskującym URL),
• silnie zagnieżdżona struktura tabelkowa używana do udawania znanych szablonów.

Część z tych cech może mieć postać prostych flag logicznych („czy występuje ukryty formularz”), część – bardziej złożonych opisów, np. zhashowanych „sygnatur” struktury HTML, które pozwalają grupować podobne kampanie bez znajomości ich treści.

Cechy z reputacji domen i adresów IP

Nawet najlepsze NLP nie zastąpi informacji o tym, że domena z linku została zarejestrowana dwa dni temu na drugim końcu świata. Dane reputacyjne są często trzymane w dedykowanych bazach (wewnętrznych lub zewnętrznych), ale ich wyciągi można włączyć jako cechy do modelu.

Typowe sygnały reputacyjne to:

• wiek domeny i czas od pierwszego zaobserwowania jej w ruchu organizacji,
• mapowanie domen na kategorie (bankowość, social media, hosting, „świeża, nieskategoryzowana”),
• historia incydentów związanych z domeną lub adresem IP,
• informacje z czarnych list i zewnętrznych feedów threat intelligence.

Modele uczące się z takich cech stają się wrażliwe na „świeże” domeny w połączeniu z mocną presją socjotechniczną. Gdy użytkownik nagle dostaje maila „potwierdź swój przelew” z linkiem do ledwo co zarejestrowanej domeny, ryzyko rośnie dramatycznie – i model może to jasno odzwierciedlić w swoim wyniku.

Wykorzystanie embeddingów z dużych modeli językowych

Na pewnym etapie proste cechy i klasyczne reprezentacje zaczynają mieć swoje ograniczenia. Gdy phishing staje się bardziej konwersacyjny („Cześć, masz chwilę? Potrzebuję, żebyś pilnie kupił karty podarunkowe…”), liczniki słów i TF‑IDF nie łapią już kontekstu relacji i tonu wypowiedzi. Tu wchodzą duże modele językowe.

Najczęstszy wzorzec wygląda mniej więcej tak:

• tekst maila (np. temat + pierwsze N znaków treści) trafia do modelu językowego,
• z jednej z ostatnich warstw modelu wyciągany jest gęsty wektor (embedding) o stałej długości,
• ten wektor, połączony z cechami nagłówkowymi i URL‑owymi, stanowi wejście do „klasycznego” klasyfikatora (np. XGBoost, sieć MLP, logistic regression).

Takie podejście daje sporą elastyczność: można korzystać z gotowych, pretrenowanych modeli (np. wielojęzycznych BERT‑ów) i niekoniecznie trzeba je od razu fine‑tunować. Często wystarczy zamrozić ich wagi i uczyć tylko klasyfikator na górze. Gdy zbiór danych urośnie, nic nie stoi na przeszkodzie, by spróbować pełnego dostrajania.

Wyzwania z modelami językowymi w środowiskach korporacyjnych

W teorii wszystko brzmi pięknie. W praktyce pojawia się kilka bardzo przyziemnych problemów: limity długości sekwencji, koszty obliczeniowe, prywatność danych. Pełny mail potrafi mieć kilkadziesiąt tysięcy znaków, załączony disclaimer zajmuje pół ekranu, a model BERT nie przyjmuje więcej niż 512 czy 1024 tokeny. Co wtedy?

Najczęściej stosuje się kombinację strategii:

• cięcie treści do najważniejszych fragmentów (temat, pierwsze akapity, otoczenie linków),
• dzielenie dłuższej treści na segmenty i łączenie embeddingów (np. uśrednianie, max‑pooling),
• oddzielne traktowanie załączników (np. osobny pipeline dla PDF‑ów czy dokumentów Office).

Do tego dochodzi kwestia inferencji w czasie rzeczywistym. Jeśli system ma klasyfikować każdy przychodzący mail w sekundę lub dwie, duży model językowy trzeba zoptymalizować: quantization, distillation, czasem kompilacja do wyspecjalizowanych runtime’ów. Bez tego chęć użycia „największego możliwego” modelu szybko zderza się ze ścianą budżetu sprzętowego.

Wybór architektury modelu – klasyczne algorytmy vs. głębokie modele tekstowe

Klasyczne algorytmy: kiedy prostota wygrywa

Wiele skutecznych systemów filtrowania phishingu w produkcji nadal opiera się na „nudnych” algorytmach: regresji logistycznej, random forest, gradient boosting. Przy dobrze zaprojektowanych cechach potrafią bić na głowę źle skonfigurowane sieci neuronowe.

Te algorytmy mają kilka praktycznych zalet:

• szybko się trenują i łatwo je stroić,
• dobrze radzą sobie z mieszanką cech numerycznych i kategorycznych,
• są stosunkowo odporne na umiarkowane szumy w danych,
• łatwo z nich wyciągnąć ranking istotności cech, co pomaga w audycie modelu.

Dla zespołów, które dopiero zaczynają z automatyzacją detekcji phishingu, często rozsądnym ruchem jest zbudowanie pierwszej wersji rozwiązania właśnie na takiej architekturze. Pozwala to lepiej zrozumieć, co faktycznie działa na danych organizacji, a później – jeśli pojawi się taka potrzeba – stopniowo włączać bardziej złożone modele.

Głębokie modele tekstowe: gdzie naprawdę robią różnicę

Transformery i inne modele głębokie stają się szczególnie przydatne w dwóch sytuacjach: gdy treść maili jest mocno zróżnicowana językowo (wiele języków, dużo swobodnej konwersacji) oraz gdy atakujący intensywnie modyfikują kampanie, unikając stałych fraz. Modele oparte na kontekście zdaniowym i dokumentowym lepiej wychwytują „styl” ataku niż same słowa kluczowe.

Przykładem są ataki podszywające się pod przełożonego („Hej, jesteś na spotkaniu? Potrzebuję szybko jedną przysługę…”). Nie zawierają one od razu słów „przelew” czy „hasło”, ale budują presję i relację. Głębokie modele potrafią wyłapać podobieństwo takiej wiadomości do setek innych, które w przeszłości zakończyły się próbą wyłudzenia.

Najczęściej zadawane pytania (FAQ)

Dlaczego modele wykrywania phishingu nie powinny być trenowane tylko na publicznych datasetach?

Publiczne zbiory maili są zwykle mocno „wypolerowane”: zanonimizowane, zbalansowane, bez duplikatów i skrajnych przypadków. Taki zbiór świetnie nadaje się do porównywania algorytmów, ale nie odzwierciedla bałaganu z realnej skrzynki – forwardów, długich wątków, raportów systemowych czy newsletterów o dziwnej jakości.

Model, który zna tylko takie „ładne” dane, radzi sobie na benchmarkach, a później gubi się w produkcji. Nie umie odróżnić normalnego szumu organizacji od faktycznie podejrzanych wiadomości, bo nigdy nie widział typowego, codziennego ruchu mailowego.

Skąd brać realne dane mailowe do trenowania klasyfikatora phishingu?

Najbardziej naturalnym źródłem są bramki pocztowe, systemy antyspamowe i archiwa poczty – tam zwykle znajdują się surowe wiadomości, nagłówki, wyniki skanów AV i metadane. Dobrze jest też spiąć to z systemami SIEM/SOC, gdzie incydenty phishingowe są już opisane i oznaczone, co daje gotowe etykiety „phishing” vs „nie‑phishing”.

Dodatkowo można wykorzystać honeypoty mailowe (adresy wystawione tylko na spam/phishing) oraz maile zgłaszane przez użytkowników przyciskiem „Zgłoś phishing”. Ten ostatni kanał często dostarcza świeże kampanie, które dopiero zaczynają się pojawiać w organizacji.

Jakie cechy maila są najważniejsze w modelach klasyfikacji phishingu?

Same słowa w treści to za mało. W praktyce duże znaczenie mają techniczne nagłówki SMTP (SPF, DKIM, łańcuch Received, domeny nadawcy), cechy URL-i (liczba przekierowań, podejrzane domeny, parametry) oraz struktura wiadomości (HTML vs tekst, osadzone obrazki, załączniki).

Dopiero połączenie tych sygnałów z analizą językową treści daje sensowny efekt. Przykładowo: legalny mail z banku też użyje słów „pilne” i „bezpieczeństwo konta”, ale przyjrzenie się infrastrukturze nadawczej i domenom linków jasno odróżni go od kampanii phishingowej.

Dlaczego filtry oparte na słowach kluczowych są dzisiaj mało skuteczne?

Atakujący doskonale wiedzą, że stare filtry łapią słowa typu „zresetuj hasło” czy „konto zostanie zablokowane”. Dlatego piszą spokojnym, urzędowym językiem, unikają oczywistych fraz, a wezwania do działania przenoszą np. do obrazków lub załączników. Dla prostego filtra taki mail wygląda niewinnie.

Do tego dochodzi problem fałszywych alarmów. Prawdziwe maile z banku, działu bezpieczeństwa czy HR korzystają z podobnego słownictwa jak phisherzy. Bez kontekstu technicznego i organizacyjnego system zaczyna masowo blokować normalne komunikaty, co szybko zniechęca użytkowników i zespół SOC.

Jak uwzględnić specyfikę organizacji przy budowie modelu phishingu?

Podstawą jest zbieranie danych z własnego środowiska – z bramek pocztowych, systemów bezpieczeństwa i zgłoszeń użytkowników. Dzięki temu model uczy się, jak wygląda „normalny” ruch w danej firmie: z jakich systemów przychodzą powiadomienia, w jakich językach piszą partnerzy, które domeny są typowe.

W dojrzałych organizacjach buduje się nawet osobne modele dla różnych segmentów użytkowników: inny dla działów technicznych, inny dla biura, a jeszcze inny dla zarządu. Każdy z nich widzi inny zestaw „typowych” maili, więc łatwiej wychwycić coś, co naprawdę odstaje od normy, np. nagły mail po francusku z prośbą o szybki przelew w firmie, gdzie francuski praktycznie nie występuje.

Jak radzić sobie ze zmiennością kampanii phishingowych w czasie?

Kluczowe jest ciągłe „dokarmianie” modelu świeżymi danymi. Phishing zmienia się sezonowo (podatki, święta, duże wycieki danych) i reaguje na działania dostawców zabezpieczeń. Model wytrenowany raz na danych sprzed roku po prostu nie zna nowych wzorców, domen i szablonów.

Dlatego warto wdrożyć cykliczny retraining: regularnie zbierać nowe kampanie z SOC, honeypotów i zgłoszeń użytkowników, aktualizować zbiór treningowy i odświeżać model. Dobrą praktyką jest też monitorowanie spadków skuteczności w określonych okresach (np. w czasie „sezonu na kurierów”) i wtedy przyspieszanie aktualizacji.

Najważniejsze wnioski

• Modele trenowane na „czystych” zbiorach benchmarkowych słabo radzą sobie w prawdziwym środowisku, bo nie znają produkcyjnego bałaganu: szumu, duplikatów, dziwnych wątków mailowych i brakującego kontekstu technicznego.
• Skuteczna klasyfikacja phishingu wymaga ciągłego „dokarmiania” modelu świeżymi kampaniami, bo atakujący zmieniają szablony, domeny i techniki tak szybko, jak zmieniają się trendy w social media.
• Kluczowe sygnały często kryją się w nagłówkach i metadanych (SPF, DKIM, łańcuch Received, przekierowania URL), a nie w samym tekście – to tam widać, że mail „od IT” wcale nie wyszedł z firmowych czy microsoftowych serwerów.
• Same słowa kluczowe prowadzą do masy fałszywych alarmów i łatwo je obejść „urzędowym” tonem wiadomości lub przeniesieniem wezwania do akcji do grafiki; konieczne jest łączenie NLP z sygnałami technicznymi, cechami URL-i i stylometrii.
• Normalny ruch mailowy wygląda inaczej w banku, inaczej w software house’ie, a jeszcze inaczej w małej firmie produkcyjnej – model musi znać lokalny kontekst organizacji, np. to, jakie języki, systemy i typy komunikatów są tam codziennością.
• Małe odchylenia od typowego wzorca w danej firmie (np. pojedynczy mail po rzadko używanym języku z prośbą o przelew) mogą być silniejszym sygnałem phishingu niż „klasyczne” słowa alarmowe, jeśli model jest wytrenowany na realnym ruchu z tego środowiska.