Co piąty atak phishingowy w przeglądarce omija zabezpieczenia firmowe

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Phishing oparty na przeglądarce stał się jednym z najtrudniejszych do wykrycia wektorów ataku w nowoczesnych środowiskach IT. Nie chodzi już wyłącznie o wiadomość e-mail z podejrzanym odnośnikiem, ale o cały łańcuch działań realizowanych w warstwie sesji WWW — od otwarcia strony logowania, przez uwierzytelnienie, aż po przejęcie tokenów, ciasteczek sesyjnych i danych dostępowych.

To właśnie na poziomie przeglądarki atakujący coraz częściej omijają tradycyjne mechanizmy ochrony. W efekcie organizacje mogą posiadać rozbudowany stos bezpieczeństwa, a mimo to nie zauważyć incydentu na etapie, w którym dochodzi do realnego przejęcia tożsamości użytkownika.

W skrócie

Najnowsze obserwacje rynkowe pokazują, że około 20% phishingowych ataków wymierzonych w środowiska korporacyjne pozostaje niewidocznych dla narzędzi bezpieczeństwa zaprojektowanych do ich blokowania. Problem dotyczy szczególnie kampanii działających bez klasycznego malware, za to z wykorzystaniem legalnych usług, szyfrowanego ruchu i dynamicznie generowanych stron.

około co piąty atak phishingowy w przeglądarce nie jest wykrywany przez istniejące zabezpieczenia,
atakujący coraz częściej przechwytują sesję, a nie samo hasło,
tradycyjna ochrona skupiona na poczcie, sieci i endpointach nie zapewnia pełnej widoczności działań w browser layer,
największe ryzyko dotyczy środowisk intensywnie korzystających z aplikacji SaaS i pracy zdalnej.

Kontekst / historia

Przez lata strategie obrony budowano wokół klasycznych punktów kontrolnych, takich jak bramy pocztowe, filtry URL, systemy proxy, EDR, NGAV, sandboxy czy platformy SIEM. Model ten dobrze sprawdzał się w czasach, gdy dominowały ataki bazujące na znanych artefaktach, sygnaturach i złośliwych plikach wykonywalnych.

W ostatnich latach phishing wyraźnie ewoluował. Fałszywe strony logowania są dziś generowane dynamicznie, złośliwa logika uruchamia się dopiero po interakcji użytkownika, a infrastruktura przestępcza coraz częściej korzysta z legalnych usług chmurowych, przekierowań i domen o wysokiej reputacji. Atak nie musi więc dostarczać złośliwego pliku na stację roboczą, aby doprowadzić do przejęcia konta.

To przesunięcie z poziomu pliku i systemu operacyjnego do poziomu sesji przeglądarki sprawia, że wiele tradycyjnych narzędzi ma ograniczoną zdolność detekcji. Problem nie polega wyłącznie na skali kampanii, ale na zmianie miejsca, w którym rozgrywa się kluczowy etap kompromitacji.

Analiza techniczna

Najważniejszym wyzwaniem jest asymetria widoczności. Narzędzia bezpieczeństwa bardzo dobrze analizują pocztę, ruch sieciowy i aktywność endpointu, ale znacznie gorzej radzą sobie z tym, co dzieje się po otwarciu strony przez użytkownika. Tymczasem to właśnie wtedy atakujący uzyskują przewagę.

Współczesne kampanie browser-based phishing wykorzystują techniki utrudniające detekcję i analizę. Część z nich aktywuje się dopiero po spełnieniu określonych warunków, część ogranicza dostęp do strony wyłącznie dla wybranych ofiar, a część ukrywa złośliwe zachowanie przed sandboxami i systemami antybotowymi.

dynamiczne generowanie treści po załadowaniu strony,
fingerprinting środowiska ofiary i ukrywanie logiki przed analizą automatyczną,
warunkowe przekierowania oraz kontrola dostępu do strony phishingowej,
stosowanie CAPTCHA i mechanizmów anti-bot,
wykorzystywanie legalnych usług chmurowych i zaufanych domen pośredniczących,
przechwytywanie sesji po poprawnym logowaniu zamiast samej kradzieży hasła.

Szczególnie groźne są scenariusze typu adversary-in-the-middle, w których ofiara sama przekazuje dane logowania do podstawionej strony, a atakujący przechwytuje także wynik procesu MFA lub aktywną sesję. W takim modelu klasyczne zabezpieczenia reputacyjne i sygnaturowe często reagują zbyt późno albo nie widzą incydentu wcale.

Dodatkowym problemem jest to, że przeglądarka nadal bywa traktowana jako zaufany interfejs do aplikacji biznesowych. W praktyce jest jednak miejscem wykonywania aktywnej treści, renderowania skryptów i bezpośredniej interakcji z systemami SaaS, więc brak telemetrii z tego poziomu oznacza istotną lukę operacyjną dla SOC i zespołów reagowania.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem jest fałszywe poczucie bezpieczeństwa. Organizacja może zakładać, że skoro wdrożyła EDR, filtrację poczty, MFA, SASE czy CASB, to ryzyko phishingu pozostaje pod kontrolą. W rzeczywistości luka pojawia się między warstwami ochrony — dokładnie tam, gdzie użytkownik wykonuje codzienną pracę w przeglądarce.

Ryzyko biznesowe obejmuje zarówno przejęcie tożsamości, jak i dalsze skutki operacyjne. Po skutecznym phishingu atakujący może wykorzystać dostęp do aplikacji chmurowych, skrzynek pocztowych i danych firmowych, a następnie rozszerzyć skalę incydentu na kolejne obszary organizacji.

przejęcie kont użytkowników i administratorów,
kradzież tokenów sesyjnych oraz częściowe obejście MFA,
nieautoryzowany dostęp do danych w usługach SaaS,
eskalacja uprawnień i ruch boczny po przejęciu tożsamości,
wykorzystanie skompromitowanych kont do BEC, oszustw finansowych i dalszego phishingu,
straty finansowe, przestoje operacyjne i koszty obsługi incydentu.

Szczególnie narażone są organizacje silnie uzależnione od aplikacji webowych, pracy zdalnej i procesów realizowanych przez przeglądarkę. Im większa rola browser layer w codziennych operacjach, tym większa powierzchnia ataku i znaczenie ochrony sesji użytkownika.

Rekomendacje

Organizacje powinny zacząć traktować przeglądarkę jako osobną warstwę bezpieczeństwa, a nie jedynie interfejs do aplikacji. Oznacza to konieczność zwiększenia widoczności zdarzeń zachodzących podczas sesji WWW oraz wdrożenia mechanizmów, które potrafią reagować w czasie rzeczywistym.

rozszerzyć telemetrię o aktywność w browser layer, w tym domeny, przekierowania, formularze logowania i nietypowe zachowania sesyjne,
wdrożyć ochronę sesji przeglądarki, np. izolację zdalną, kontrolę aktywnej treści oraz polityki ograniczające wprowadzanie poświadczeń na nieautoryzowanych stronach,
rozwijać architekturę IAM pod kątem odporności na phishing, zwłaszcza z użyciem metod odpornych na przechwycenie,
uzupełnić playbooki SOC i IR o scenariusze browser-based phishing oraz analizę tokenów, czasu życia sesji i anomalii po uwierzytelnieniu,
utrzymać szkolenia użytkowników, ale nie traktować ich jako głównej linii obrony.

Kluczowe znaczenie ma także analiza zachowań po poprawnym logowaniu. W wielu przypadkach to nie moment wpisania hasła, lecz późniejsza aktywność sesyjna dostarcza pierwszych sygnałów, że konto zostało przejęte lub nadużyte.

Podsumowanie

Dane z 2026 roku potwierdzają, że phishing w przeglądarce coraz skuteczniej omija część klasycznych zabezpieczeń i pozostaje niewidoczny dla tradycyjnych systemów detekcji. Problem wynika nie tylko ze wzrostu liczby kampanii, ale przede wszystkim z przesunięcia ataku do warstwy sesji WWW, gdzie wiele organizacji ma ograniczoną telemetrię i słabsze mechanizmy kontroli.

Dla zespołów bezpieczeństwa oznacza to konieczność zmiany modelu obrony — od ochrony perymetru i endpointu w stronę ochrony tożsamości, sesji oraz samej przeglądarki jako krytycznego punktu egzekwowania polityk. Bez tego nawet rozbudowany stos zabezpieczeń może nie zauważyć incydentu aż do momentu przejęcia konta lub wycieku danych.