Phishing, który przeszedł przez filtr. Jak SOC analizuje wiadomości po kliknięciu

2026-05-14

TL;DR

Filtr poczty to pierwsza linia, nie ostatnia. Wiadomości phishingowe wysłane z przejętych prawdziwych domen, z legalnych platform marketingowych i hostingowych albo z nowych rejestracji bez historii często nie uruchamiają żadnego alarmu. Użytkownik kliknie, bo wiadomość wygląda wiarygodnie i przeszła przez filtr.

W tym momencie zaczyna się praca SOC. Nie chodzi o karanie użytkownika. Chodzi o jak najszybsze zrozumienie, co się stało, czy nastąpiła kompromitacja i jak ograniczyć konsekwencje. Ten artykuł opisuje, jak wygląda taka analiza w praktyce i co robić, żeby rozwiązać problem, zanim eskaluje.

Dlaczego filtr przepuszcza tę wiadomość

Nowoczesne filtry poczty są dobre, ale mają granice. Reputacyjna ocena domeny nie zadziała na przejętej, prawdziwej domenie z historią. Analiza zawartości nie znajdzie złośliwego linku, jeżeli strona phishingowa jest pusta w momencie skanowania i aktywuje się dopiero po określonym czasie albo dla konkretnych użytkowników. Sandbox nie otworzy załącznika, który wymaga hasła podanego w treści maila.

Phishing z prawdziwej infrastruktury to rosnący problem. Gdy atakujący wysyłają wiadomości z kont marketingowych na legalnych platformach, z przejętych subskrypcji SaaS albo z serwerów firm, które wcześniej zaatakowali, filtry widzą dobrą reputację i nie flagują komunikacji.

To nie jest błąd filtra. To jego ograniczenie, które trzeba zaakceptować i uzupełnić innymi warstwami.

Pierwsze trzy minuty po zgłoszeniu

Kiedy użytkownik zgłasza kliknięcie podejrzanego linku, SOC powinien mieć gotowy checklist pierwszych kroków. Nie po to, żeby spowolnić reakcję, ale żeby żadne ważne pytanie nie umknęło w pośpiechu.

Pierwsze pytania dotyczą stanu: czy strona nadal działa, czy plik został pobrany, czy coś zostało uruchomione, czy użytkownik wpisał dane, czy w tle zaczęły się procesy, których nie było wcześniej. Odpowiedzi na te pytania decydują, czy incydent to kliknięcie bez konsekwencji, czy już eskalacja do potencjalnej kompromitacji.

Równolegle SOC analizuje nagłówki wiadomości. Nagłówki e-mail to techniczna część wiadomości zawierająca informacje o trasie, serwerze wysyłającym i mechanizmach autoryzacji. Zawierają dane o routingu wiadomości, serwerze nadawczym, wynikach SPF, DKIM i DMARC, czasie dostarczenia i adresie zwrotnym. Nawet jeśli filtr nie zareagował, nagłówki mogą pokazać anomalie, które wyjaśniają, jak ta wiadomość dotarła do skrzynki.

Analiza linku i domeny

Każdy link w podejrzanej wiadomości powinien zostać przeanalizowany bez jego klikania. SOC używa narzędzi do sprawdzenia reputacji domeny, daty rejestracji, certyfikatu TLS, historii i kategorii. VirusTotal, URLscan, Shodan, WHOIS i dane threat intelligence to standardowe elementy tego etapu.

Interesujące sygnały to: domena zarejestrowana kilka dni albo godzin przed incydentem, certyfikat wystawiony w ten sam dzień, adres IP hostujący wiele podobnych domen, przekierowania przez kilka intermediary, brak historii albo historyczne fałszywe wyniki dla tej domeny.

Jeżeli link już nie odpowiada, nie znaczy to, że sprawa jest zamknięta. Atakujący często wyłączają infrastrukturę phishingową po skompromitowaniu interesujących ich celów. Brak odpowiedzi strony może być sygnałem, że phishing był ukierunkowany i cel już reaguje.

Warto też sprawdzić URL w kontekście geofencingu. Jeśli strona pokazuje neutralną zawartość z lokalizacji SOC, a użytkownik klikał z innego adresu IP, phishing mógł dostarczyć inny content realnej ofierze. Analiza powinna uwzględniać takie selektywne zachowanie.

Endpoint i logi po kliknięciu

Nawet jeśli link wyglądał neutralnie, warto sprawdzić endpoint. EDR, czyli endpoint detection and response, to narzędzie do monitorowania i analizy zachowania komputera. Powinien pokazać, czy po kliknięciu otworzyła się przeglądarka, zostały pobrane pliki, uruchomione procesy, zmodyfikowane klucze rejestru albo nawiązane nowe połączenia sieciowe.

Phishing może prowadzić do drive-by download, czyli pobrania malware bez jawnej zgody użytkownika. Może też wymagać działania, jak otwarcie archiwum, uruchomienie skryptu albo kliknięcie przycisku na stronie. SOC powinien prześledzić całą ścieżkę.

Logi proxy i DNS to kolejna warstwa. Proxy loguje adresy i czas, DNS loguje zapytania o domeny. Nawet jeśli endpoint nie pokazuje nic podejrzanego, logi sieciowe mogą ujawnić komunikację z zewnętrznymi serwerami, których normalnie nie powinno być.

Kiedy pojawiają się OTP i RMM

Szczególna eskalacja następuje, gdy phishing prowadzi do strony, która prosi o kod OTP, lub gdy ofiara zostaje nakłoniona do instalacji RMM. OTP, czyli one-time password, to jednorazowy kod potwierdzający tożsamość. RMM, czyli remote monitoring and management, to narzędzie do zdalnego zarządzania komputerem, normalnie używane przez IT, ale nadużywane przez atakujących do zdalnego dostępu bez uprawnień.

Wpisanie OTP na fałszywej stronie może oznaczać, że atakujący zrealizował logowanie AiTM, czyli adversary in the middle, w trybie real-time. To poważna sytuacja, która wymaga natychmiastowego zablokowania sesji, resetu poświadczeń i zbadania, co atakujący robił przez kilka minut dostępu.

Instalacja RMM to inna kategoria. Jeśli na endpoincie pojawił się AnyDesk, TeamViewer, ScreenConnect albo podobne narzędzie instalowane bez zgody IT, to jest to aktywny dostęp atakującego. Reakcja powinna być szybka: izolacja endpointa, zabranie go z sieci, analiza zakresu dostępu i zmiana poświadczeń.

Użytkownik jako sensor

Najszybsze wykrycia incydentów phishingowych w organizacjach często przychodzą od użytkowników, nie od narzędzi. Filtr, EDR i SIEM reagują post-factum albo nie reagują wcale na nowatorski scenariusz. Użytkownik, który natychmiast zgłasza kliknięcie, daje SOC szansę na reakcję w ciągu minut.

Dlatego szkolenia phishingowe i komunikacja awareness muszą tworzyć kulturę zgłaszania, a nie strach przed karą. Jeżeli pracownik wie, że po kliknięciu powie helpdesku i SOC zajmie się sprawą bez konsekwencji dla niego, prawdopodobieństwo szybkiego zgłoszenia rośnie.

To jest jeden z głównych celów regularnych testów phishingowych dla firm. Nie tylko pomiar kliknięć, ale też pomiar zgłoszeń i czas reakcji. Czy organizacja dowiedziała się o symulowanym phishingu od użytkowników, czy z analizy po czasie?

Sandbox i analiza pliku

Jeżeli użytkownik pobrał plik, powinien trafić do sandboxa. Sandbox to odizolowane środowisko do bezpiecznego uruchomienia podejrzanych plików lub adresów URL i obserwowania ich zachowania. Tam można uruchomić go bez ryzyka dla sieci produkcyjnej i zobaczyć, co robi: czy nawiązuje połączenia, modyfikuje system, zapisuje dane, kopiuje poświadczenia albo przygotowuje się do szyfrowania.

Wyniki sandboxa pozwalają ocenić, czy plik jest złośliwy, i przekazać hash do platform threat intelligence. Jeśli inni analitycy już widzieli ten sample, można szybko zidentyfikować rodzinę malware, infrastrukturę C2 i znane IoC, czyli indicators of compromise.

W polskich organizacjach sandbox jest nadal rzadkością poza dużymi SOC. Warto wiedzieć, że dostępne są darmowe i płatne usługi cloud-based, jak VirusTotal, ANY.RUN, Joe Sandbox albo Hybrid Analysis, które mogą obsłużyć analizę pliku bez własnej infrastruktury.

Co zmienić po incydencie

Każdy incydent phishingowy, nawet zakończony bez kompromitacji, jest źródłem wiedzy. Warto odpowiedzieć na pytania: jak ta wiadomość przeszła przez filtr, czy reguły i polityki trzeba dostosować, czy nagłówki wskazują na konkretny wektor, który można zablokować, czy użytkownicy wiedzą, jak zgłaszać phishing.

Jeżeli kampania była ukierunkowana, warto sprawdzić, co motywowało napastnika. Czasem phishing poprzedza bardziej zaawansowany atak. Jeżeli ofiara ma dostęp do czegoś wartościowego, a kampania wyglądała na spersonalizowaną, incydent warto połączyć z threat intelligence i historią wcześniejszych kontaktów.

Wniosek

Phishing po filtrze to normalność, nie wyjątek. Organizacje, które myślą o ochronie jako filtr poczty plus szkolenie raz do roku, będą miały coraz więcej incydentów bez odpowiedniej odpowiedzi.

Dobra odpowiedź wymaga: użytkownika, który zgłasza natychmiast; SOC, który ma gotowy proces; narzędzi do analizy linku, nagłówków, endpointa i pliku; oraz kultury organizacyjnej, która traktuje zgłoszenie kliknięcia jako pomoc, a nie winę.

To jest obrona phishingowa w praktyce. Nie tylko blokowanie, ale też wykrywanie, reagowanie i uczenie się na każdym incydencie.