Phishing po filtrze. Reakcja SOC

TL;DR

Phishing po filtrze poczty to sytuacja, w której wiadomość przeszła przez zabezpieczenia bramki e-mail i dotarła do użytkownika, mimo że zawierała złośliwy link, fałszywy formularz, podejrzany załącznik albo element socjotechniczny. Nie musi to oznaczać, że filtr zawiódł w prosty sposób. Często oznacza, że atak wykorzystał przejętą domenę, legalną usługę, poprawną reputację nadawcy, przekierowania, opóźnioną aktywację strony albo scenariusz, którego automatyczna analiza nie rozpoznała w chwili dostarczenia.

Po kliknięciu zaczyna się praca SOC, czyli security operations center, zespołu monitorowania i reagowania na incydenty. Najważniejsze nie jest szukanie winnego użytkownika, ale szybkie ustalenie, czy incydent zakończył się tylko wejściem na stronę, czy doprowadził do podania danych, wpisania kodu, przejęcia sesji, pobrania pliku, uruchomienia procesu albo instalacji narzędzia zdalnego dostępu.

Dobra reakcja na phishing po filtrze wymaga trzech elementów: użytkownika, który zgłasza zdarzenie bez zwłoki; zespołu SOC lub IT, który ma gotowy sposób triage; oraz organizacji, która mierzy nie tylko kliknięcia, ale też zgłoszenia, czas reakcji, podanie danych, działania po błędzie i skuteczność usunięcia zagrożenia z innych skrzynek.

Dlaczego filtr poczty nie zatrzymuje wszystkiego

Filtr poczty jest ważną warstwą ochrony, ale nie jest granicą, za którą phishing przestaje istnieć. Nowoczesne kampanie coraz częściej korzystają z elementów, które wyglądają dobrze z technicznego punktu widzenia: legalnych platform mailingowych, poprawnie skonfigurowanych domen, przejętych kont, zaufanych usług SaaS, linków pośrednich i stron, które w czasie skanowania nie pokazują jeszcze właściwej treści phishingowej.

Problem szczególnie dobrze widać przy wiadomościach wysyłanych z prawdziwej infrastruktury. Jeżeli atakujący przejmie konto firmowe, konto w narzędziu marketingowym albo usługę wykorzystywaną wcześniej do legalnej komunikacji, część sygnałów reputacyjnych będzie wyglądała poprawnie. Filtr może zobaczyć znaną domenę, poprawny nadawca techniczny, brak złośliwego załącznika i link prowadzący przez usługę, która sama w sobie nie jest jednoznacznie złośliwa.

Wiadomość może też zmieniać zachowanie w czasie. Strona phishingowa bywa neutralna podczas automatycznego skanowania, a właściwy formularz pojawia się później, tylko dla wybranych adresów IP, tylko dla konkretnej przeglądarki albo po przejściu przez kilka przekierowań. SANS Internet Storm Center opisywał w 2026 roku, że przekierowania były widoczne w znaczącej części analizowanych wiadomości phishingowych, a mechanizmy nie ograniczały się do klasycznych open redirectów. Dla SOC oznacza to, że samo sprawdzenie pierwszego adresu URL może nie wystarczyć.

To nie unieważnia filtrów poczty. Pokazuje raczej, że filtr jest pierwszą warstwą, a nie pełnym procesem obrony. Organizacja musi zakładać, że część wiadomości przejdzie dalej i dopiero wtedy zostanie oceniona przez użytkownika, helpdesk, SOC, EDR, proxy, DNS, SIEM i proces reagowania.

Co oznacza kliknięcie użytkownika

Kliknięcie nie jest jeszcze jedną kategorią ryzyka. Może oznaczać krótkie otwarcie strony, wejście na neutralny redirect, pobranie pliku, uruchomienie kodu w przeglądarce, przejście do fałszywego logowania albo początek przejęcia sesji. Dlatego pierwsza reakcja nie powinna sprowadzać się do pytania, czy użytkownik kliknął. Trzeba ustalić, co wydarzyło się po kliknięciu.

SOC powinien szybko zebrać kilka informacji: kto otrzymał wiadomość, kiedy ją otworzył, z jakiego urządzenia kliknął, jaki adres URL został odwiedzony, czy strona poprosiła o login, hasło, kod jednorazowy lub potwierdzenie logowania, czy pobrał się plik, czy użytkownik uruchomił cokolwiek ręcznie i czy po kliknięciu pojawił się telefon lub kolejny kontakt od rzekomego wsparcia.

To etap, w którym użytkownik jest źródłem danych, nie problemem do ukarania. Jeżeli pracownik obawia się konsekwencji i ukryje kliknięcie, SOC traci najcenniejszy zasób: czas. W dobrze ustawionej kulturze bezpieczeństwa zgłoszenie po błędzie jest traktowane jako pomoc w zatrzymaniu incydentu, a nie jako przyznanie się do winy.

W testach phishingowych dla firm warto mierzyć właśnie ten moment. Sama liczba kliknięć mówi niewiele. Dużo ważniejsze jest to, ilu użytkowników zgłosiło podejrzaną wiadomość, jak szybko to zrobili, ilu zatrzymało się przed formularzem, ilu podało dane i czy organizacja potrafiła przejść od zgłoszenia do działania technicznego.

Pierwsze minuty pracy SOC

Pierwsze minuty po zgłoszeniu są najważniejsze, bo wtedy można jeszcze ograniczyć skutki incydentu. SOC powinien mieć gotowy playbook, który prowadzi analityka przez najważniejsze pytania bez blokowania decyzji. Chodzi o szybkie rozróżnienie, czy mamy do czynienia z fałszywym alarmem, kliknięciem bez dalszego działania, próbą wyłudzenia danych, podejrzeniem przejęcia konta, pobraniem pliku, aktywną komunikacją z infrastrukturą atakującego albo zainstalowanym narzędziem zdalnego dostępu.

Pierwszy obszar to wiadomość. Trzeba zebrać oryginalny e-mail, najlepiej wraz z nagłówkami. Nagłówki wiadomości pokazują trasę dostarczenia, serwery pośredniczące, wyniki SPF, DKIM i DMARC, adres zwrotny, identyfikatory wiadomości, czas dostarczenia i elementy, które pomagają ocenić, czy nadawca był podszyty, przejęty czy tylko podobny wizualnie. SPF, DKIM i DMARC to mechanizmy uwierzytelniania i polityki poczty, które pomagają ograniczać podszywanie się pod domeny, ale same nie rozwiązują problemu phishingu z legalnych lub przejętych kont.

Drugi obszar to użytkownik i endpoint. Endpoint detection and response, czyli EDR, powinien pokazać, czy po kliknięciu uruchomiła się przeglądarka, został zapisany plik, pojawiły się nowe procesy, zmieniły się klucze rejestru, uruchomiono skrypt, archiwum, dokument lub instalator. Jeżeli organizacja nie ma EDR, nadal może szukać śladów w historii przeglądarki, logach systemowych, logach proxy, DNS i w telemetrii narzędzi ochrony stacji roboczych.

Trzeci obszar to konto. Jeżeli użytkownik wpisał hasło, kod OTP albo zatwierdził powiadomienie MFA, czyli wieloskładnikowego uwierzytelniania, analiza musi objąć logowania, aktywne sesje, tokeny, urządzenia zaufane, reguły pocztowe, przekierowania, aplikacje OAuth i nietypowe działania w usługach chmurowych. W takim scenariuszu samo wymuszenie zmiany hasła może być niewystarczające, jeśli aktywna sesja lub token nadal pozostają ważne.

Analiza linku, domeny i przekierowań

Każdy link z podejrzanej wiadomości należy analizować bez klikania go z normalnej stacji użytkownika. SOC powinien sprawdzić pełny łańcuch adresów, domenę, datę rejestracji, certyfikat TLS, reputację, historię w narzędziach threat intelligence, użycie skracaczy, parametry śledzące i ewentualne przekierowania przez legalne usługi.

W analizie nie chodzi tylko o odpowiedź, czy link jest złośliwy. Ważne jest też ustalenie, co próbował zrobić: przekierować do fałszywego logowania, zidentyfikować ofiarę, pobrać plik, ominąć skaner, dostarczyć inny content zależnie od lokalizacji albo zebrać informacje do kolejnego etapu ataku. Czasem link z perspektywy SOC pokazuje neutralną stronę, a z perspektywy użytkownika, który kliknął z firmowego adresu IP, prowadził do właściwej przynęty.

Trzeba też uważać na sytuację, w której strona już nie działa. Brak odpowiedzi nie zamyka sprawy. Infrastruktura phishingowa może być jednorazowa, wyłączana po kilku godzinach albo aktywowana tylko dla wybranych ofiar. Jeżeli użytkownik zdążył wpisać dane, zespół reagowania powinien traktować zdarzenie jako potencjalne przejęcie konta, a nie jako niegroźny link, który przestał działać.

Przy phishingu wykorzystującym przekierowania ważne jest odtworzenie ścieżki, ale bez narażania środowiska produkcyjnego. Narzędzia typu URLscan, VirusTotal, izolowane przeglądarki, sandboxy URL, proxy analityczne i dane DNS mogą pomóc w analizie, ale wyniki trzeba interpretować ostrożnie. Publiczne skanowanie adresu może czasem ujawnić zainteresowanie obrońców albo uruchomić zachowanie zależne od reputacji skanera.

Endpoint, DNS i logi po kliknięciu

Po kliknięciu trzeba odtworzyć zdarzenie w osi czasu. Godzina dostarczenia wiadomości, moment otwarcia, czas kliknięcia, zapytania DNS, połączenia HTTP, pobrania plików, uruchomione procesy i logowania użytkownika powinny tworzyć jeden obraz. Gdy każdy zespół patrzy tylko na własny fragment, incydent może wyglądać niegroźnie. Dopiero korelacja pokazuje, czy kliknięcie było początkiem łańcucha ataku.

Logi DNS mówią, jakie domeny były rozwiązywane przez urządzenie użytkownika. Logi proxy lub secure web gateway pokazują adresy URL, statusy odpowiedzi, kategorie stron, pobrane obiekty i czas komunikacji. EDR pokazuje procesy, pliki, komendy, połączenia sieciowe i działania lokalne. SIEM, czyli security information and event management, może połączyć te sygnały i wskazać, czy podobne zdarzenia wystąpiły u innych użytkowników.

W praktyce warto sprawdzić, czy po kliknięciu pojawiły się nietypowe procesy potomne przeglądarki, na przykład uruchomienie PowerShell, cmd, mshta, wscript, cscript, rundll32 lub instalatora. Warto też sprawdzić katalog pobrań, cache przeglądarki, historię uruchomień, nowe rozszerzenia, zapisane poświadczenia i zmiany w profilu użytkownika.

Jeżeli phishing dotyczył konta Microsoft 365, Google Workspace albo innej usługi SaaS, analiza endpointa nie wystarczy. Trzeba przejrzeć logi logowania, lokalizacje, urządzenia, user agent, reguły pocztowe, przekierowania, dostęp aplikacji, zgody OAuth i operacje na plikach. Coraz więcej ataków kończy się nie na komputerze użytkownika, lecz w tożsamości i usługach chmurowych.

Kiedy pojawiają się OTP, MFA i AiTM

Szczególnej uwagi wymagają scenariusze, w których strona prosi o kod OTP, czyli one-time password, albo o zatwierdzenie powiadomienia MFA. Użytkownik często myśli, że drugi składnik oznacza bezpieczeństwo. W ataku typu AiTM, czyli adversary-in-the-middle, fałszywa strona działa jednak jak pośrednik między ofiarą a prawdziwą usługą i może próbować przechwycić nie tylko hasło, ale także sesję lub token.

Jeżeli użytkownik wpisał kod albo zatwierdził logowanie, SOC powinien założyć, że mogło dojść do realnego dostępu. Reakcja musi obejmować nie tylko zmianę hasła, ale też unieważnienie sesji, sprawdzenie logowań, usunięcie podejrzanych urządzeń, cofnięcie zgód aplikacji, kontrolę reguł skrzynki i sprawdzenie, czy konto nie zostało wykorzystane do dalszego rozsyłania wiadomości.

Microsoft w 2026 roku opisywał kampanie, które łączyły poprawnie wyglądającą komunikację, legalne usługi dystrybucji i wieloetapowy phishing prowadzący do kompromitacji tokenów. To dobry przykład zmiany, która powinna być widoczna w procedurach SOC: wykrywanie nie może kończyć się na haśle. W środowiskach chmurowych równie ważne są sesje, tokeny, zgody OAuth, urządzenia i późniejsze działania na koncie.

W programie awareness warto jasno tłumaczyć użytkownikom, że kod MFA nie jest informacją do wpisywania na stronie otwartej z maila. Jeżeli pojawia się prośba o kod, zatwierdzenie logowania albo ponowną autoryzację po kliknięciu w wiadomość, właściwą reakcją jest przerwanie procesu i zgłoszenie zdarzenia.

RMM i fałszywe wsparcie techniczne

Część ataków phishingowych nie kończy się formularzem. Po kliknięciu użytkownik może zobaczyć komunikat o błędzie, numer telefonu do wsparcia, instrukcję instalacji aplikacji albo prośbę o uruchomienie narzędzia zdalnej pomocy. RMM, czyli remote monitoring and management, to narzędzia zdalnego zarządzania, normalnie używane przez IT, ale nadużywane przez atakujących do uzyskania dostępu do urządzenia ofiary.

Jeżeli na endpoincie pojawił się AnyDesk, TeamViewer, ScreenConnect, RustDesk lub inne narzędzie instalowane poza procesem IT, należy traktować to jako zdarzenie wysokiego ryzyka. Atakujący mógł widzieć ekran, przejąć kontrolę nad urządzeniem, kopiować pliki, obserwować logowanie, prosić o zatwierdzenia albo uruchamiać polecenia w tle.

Reakcja powinna być szybka i techniczna: izolacja urządzenia, zebranie artefaktów, analiza procesu instalacji, sprawdzenie połączeń zewnętrznych, zmiana poświadczeń używanych na tym urządzeniu, kontrola sesji w usługach chmurowych i weryfikacja, czy podobny scenariusz nie dotknął innych użytkowników.

Dla polskich firm to szczególnie ważne w scenariuszach podszycia pod bank, operatora, dostawcę hostingu, system księgowy, helpdesk Microsoft 365 albo obsługę płatności. Atak może zaczynać się od maila, ale właściwa manipulacja odbywa się przez telefon i zdalny dostęp.

Sandbox i analiza pliku

Jeżeli użytkownik pobrał plik, nie powinien go ponownie otwierać, przesyłać przypadkowymi kanałami ani usuwać bez konsultacji z IT. Plik powinien zostać zabezpieczony do analizy. Sandbox to odizolowane środowisko, w którym można uruchomić podejrzany plik lub adres URL i obserwować zachowanie bez narażania sieci produkcyjnej.

Analiza sandboxowa może pokazać, czy plik próbuje uruchomić procesy potomne, pobrać kolejne komponenty, połączyć się z infrastrukturą C2, czyli command and control, zmienić ustawienia systemu, odczytać dane z przeglądarki, uzyskać trwałość albo ominąć zabezpieczenia. Wyniki nie zawsze są jednoznaczne, bo część malware wykrywa środowiska analityczne i zachowuje się neutralnie, ale sandbox nadal pomaga ustalić, czy plik wymaga eskalacji.

W mniejszych organizacjach własny sandbox nie jest standardem. Nie oznacza to jednak, że analiza jest niemożliwa. Można korzystać z usług chmurowych i narzędzi zewnętrznych, pamiętając o ostrożności przy wysyłaniu plików zawierających dane firmowe lub osobowe. Jeżeli plik może zawierać poufne informacje, decyzja o przekazaniu go do publicznej usługi musi uwzględniać ryzyko ujawnienia danych.

Hash pliku, czyli skrót kryptograficzny pozwalający rozpoznać konkretną próbkę, może pomóc w wyszukaniu podobnych przypadków w threat intelligence. IoC, czyli indicators of compromise, mogą następnie trafić do EDR, SIEM, filtrów poczty, proxy lub list blokowania. Trzeba jednak pamiętać, że IoC są śladem po ataku, a nie pełną strategią obrony. Dobre reagowanie łączy wskaźniki techniczne z analizą zachowania użytkownika i procesu.

Co zrobić, jeśli to już się stało

Jeżeli użytkownik tylko kliknął link i natychmiast zgłosił zdarzenie, nie należy zaczynać od straszenia ani karania. Trzeba zebrać szczegóły: godzinę kliknięcia, urządzenie, przeglądarkę, wygląd strony i to, czy pojawił się formularz, plik, kod, telefon albo prośba o instalację aplikacji. Następnie SOC lub IT powinien sprawdzić logi endpointa, DNS, proxy i poczty.

Jeżeli użytkownik podał login lub hasło, trzeba zmienić hasło w oficjalnym systemie, unieważnić aktywne sesje i sprawdzić historię logowań. W środowiskach Microsoft 365, Google Workspace i innych usługach SaaS trzeba również sprawdzić reguły pocztowe, przekierowania, aplikacje z nadanymi zgodami, urządzenia zaufane, nowe metody MFA i nietypowe działania na plikach lub skrzynce.

Jeżeli użytkownik wpisał kod OTP albo zatwierdził MFA, zdarzenie należy traktować jako możliwe przejęcie sesji. Sama zmiana hasła może nie wystarczyć. Potrzebne jest unieważnienie sesji, analiza logów, sprawdzenie tokenów i ocena, co atakujący mógł zrobić w czasie dostępu.

Jeżeli pobrał lub uruchomił plik, urządzenie powinno zostać odłączone lub odizolowane zgodnie z procedurą firmy. Nie należy samodzielnie czyścić śladów, usuwać plików ani restartować komputera, jeśli organizacja wymaga zabezpieczenia artefaktów. Dla SOC ważne są procesy, pliki, logi, połączenia sieciowe i czas zdarzenia.

Jeżeli zainstalowano narzędzie zdalnego dostępu, reakcja powinna być natychmiastowa. Trzeba odciąć dostęp, zabezpieczyć endpoint, zmienić poświadczenia używane na urządzeniu, sprawdzić działania na kontach i ustalić, czy atakujący nie wykonał przelewów, zmian w systemach biznesowych, pobrania danych albo dalszego rozsyłania wiadomości.

Polski kontekst: użytkownik, SOC i zgłoszenia

W polskich organizacjach phishing po filtrze poczty często trafia nie tylko do dużych SOC, ale także do helpdesku, administratora Microsoft 365, działu IT, inspektora ochrony danych, compliance albo osoby odpowiedzialnej za bezpieczeństwo w mniejszej firmie. To oznacza, że procedura musi być zrozumiała także poza zespołem wyspecjalizowanych analityków.

Dobry proces powinien jasno mówić, gdzie zgłaszać podejrzane wiadomości, co załączyć, czego nie usuwać, kiedy dzwonić, kiedy izolować urządzenie i kto podejmuje decyzję o wymuszeniu zmiany hasła lub unieważnieniu sesji. Pracownik nie powinien zastanawiać się, czy pisać do przełożonego, helpdesku, administratora czy na ogólną skrzynkę. Im prostszy kanał zgłoszenia, tym większa szansa, że informacja dotrze na czas.

W przypadku podejrzanych SMS-ów w Polsce działa numer 8080 do zgłaszania wiadomości do CERT Polska. Podejrzane incydenty i wiadomości e-mail można zgłaszać przez kanały CERT Polska. Dla firmy nie zastępuje to własnego procesu reagowania, ale jest ważnym elementem szerszego ekosystemu obrony, szczególnie gdy phishing dotyczy wielu podmiotów albo używa domen, które mogą trafić na listy ostrzeżeń.

W organizacjach objętych wymaganiami regulacyjnymi, na przykład NIS2, DORA, ISO 27001 albo wewnętrznymi wymaganiami audytowymi, zgłoszenia użytkowników są także dowodem działania procesu. Pokazują, że firma nie ogranicza się do polityki bezpieczeństwa, ale potrafi wykrywać, eskalować i analizować zdarzenia w praktyce.

Co zmienić po incydencie

Po zakończeniu triage warto wrócić do pytania, dlaczego wiadomość przeszła przez filtr i co można poprawić. Czasem odpowiedzią będzie reguła blokowania domeny, korekta polityk DMARC, wzmocnienie detekcji linków, blokada typu załącznika, zmiana konfiguracji bezpiecznych linków albo lepsze logowanie zdarzeń. Czasem jednak problem będzie poza filtrem: brak kanału zgłoszeń, brak procedury unieważniania sesji, brak widoczności w logach SaaS albo zbyt wolna decyzja o izolacji endpointa.

Warto sprawdzić, czy podobna wiadomość dotarła do innych skrzynek i czy została usunięta centralnie. Trzeba też ocenić, czy użytkownicy widzieli podobne warianty w SMS-ach, komunikatorach, Teams, Slacku albo telefonach. Phishing rzadko ogranicza się do jednego kanału. Jeżeli kampania była dobrze przygotowana, e-mail mógł być tylko pierwszym dotknięciem.

Wnioski powinny trafić do trzech miejsc: kontroli technicznych, procedur SOC lub IT oraz programu awareness. Jeżeli użytkownicy klikali, bo wiadomość wyglądała jak realna komunikacja z systemu HR, finansów, Microsoft 365 albo dostawcy SaaS, następnym krokiem nie powinno być ogólne przypomnienie o ostrożności. Lepiej przygotować krótką lekcję pokazującą dokładnie ten mechanizm: link, formularz, kod, plik, telefon, zgłoszenie i reakcję.

Jak ćwiczyć reakcję na phishing po filtrze

Scenariusz phishingu po filtrze dobrze nadaje się do ćwiczeń, bo nie kończy się na użytkowniku. Testuje cały łańcuch: dostarczenie wiadomości, decyzję odbiorcy, zgłoszenie, triage, analizę, reakcję techniczną i komunikację wewnętrzną. To dużo bliższe realnemu incydentowi niż kampania, która sprawdza wyłącznie liczbę kliknięć.

W ćwiczeniu można mierzyć, czy użytkownik zgłosił wiadomość przed kliknięciem, po kliknięciu, po wpisaniu danych albo dopiero po rozmowie telefonicznej. Można też mierzyć, ile czasu minęło do pierwszego zgłoszenia, czy helpdesk wiedział, co zrobić, czy SOC znalazł wiadomość u innych użytkowników, czy udało się zablokować domenę, czy unieważniono sesję i czy przygotowano komunikat do zespołu.

Taki test pokazuje realną cyberodporność. Nie chodzi o perfekcyjne unikanie każdego błędu, bo to nierealne. Chodzi o to, czy organizacja potrafi skrócić czas od błędu do reakcji. Jeżeli użytkownik kliknął, ale zgłosił zdarzenie po minucie, a SOC usunął wiadomości z pozostałych skrzynek i zablokował link, firma jest w lepszej sytuacji niż organizacja, w której nikt nie kliknął w symulacji, ale nikt nie wie, jak zgłosić prawdziwy incydent.

Wniosek

Phishing, który przeszedł przez filtr poczty, nie jest anomalią. To normalny scenariusz, z którym organizacje muszą się liczyć. Filtr redukuje ryzyko, ale nie zastępuje użytkownika jako sensora, SOC jako procesu reagowania ani telemetrii z poczty, endpointa, DNS, proxy i usług chmurowych.

Najważniejsza zasada działania jest praktyczna: po kliknięciu liczy się czas, szczerość zgłoszenia i precyzyjna analiza tego, co wydarzyło się dalej. Dobra organizacja nie buduje obrony na założeniu, że nikt nigdy nie kliknie. Buduje ją tak, aby po kliknięciu szybko wiedzieć, czy doszło do podania danych, przejęcia sesji, pobrania pliku, zainstalowania narzędzia zdalnego dostępu albo dalszego rozlania ataku po firmie.