Browser-in-the-Middle BitM: jak działa taki atak

TL;DR

Browser-in-the-Middle, czyli BitM, to rodzaj ataku, w którym użytkownik myśli, że korzysta z normalnej strony albo aplikacji, ale jego działania są wykonywane w środowisku kontrolowanym przez atakującego. W praktyce może to oznaczać logowanie do prawdziwej usługi przez zdalną sesję, fałszywe okno przeglądarki albo proces, który wygląda wiarygodnie, bo prowadzi użytkownika przez znane elementy logowania.

Największy problem nie polega tylko na kradzieży hasła. Atakujący może przejąć uwierzytelnioną sesję, token albo cookie, czyli element, który po udanym logowaniu potwierdza, że użytkownik jest już zalogowany. Dlatego klasyczne MFA nadal pomaga, ale nie zawsze zatrzyma scenariusz, w którym pracownik sam przechodzi przez proces logowania w kontrolowanym środowisku.

BitM jest blisko spokrewniony z phishingiem omijającym MFA typu AiTM, ale zasługuje na osobne wyjaśnienie. Dla firm to ważny mechanizm, bo pojawia się przy Microsoft 365, Google Workspace, systemach SSO, portalach HR, narzędziach finansowych, panelach SaaS i innych usługach, w których przejęcie sesji może wystarczyć do dalszego ataku.

Czym jest Browser-in-the-Middle BitM

Browser-in-the-Middle oznacza dosłownie „przeglądarkę pośrodku”. W klasycznym phishingu użytkownik zwykle trafia na stronę, która udaje prawdziwy ekran logowania. W BitM problem jest inny: użytkownik może widzieć coś, co wygląda jak realna usługa, ponieważ interakcja odbywa się przez przeglądarkę lub sesję kontrolowaną przez napastnika.

MITRE opisuje BitM jako sytuację, w której atakujący wykorzystuje funkcje przeglądarki do ustanowienia niezauważonej zdalnej sesji dostępnej w przeglądarce ofiary. Użytkownik wykonuje swoje działania w oknie, które wydaje się normalne, ale faktycznie działa na maszynie lub w środowisku atakującego. To odróżnia BitM od prostego klona strony, gdzie głównym celem jest tylko zebranie loginu i hasła.

W praktyce BitM można rozumieć jako phishing skierowany nie tylko w dane logowania, ale w cały proces uwierzytelnienia. Użytkownik wpisuje dane, potwierdza kod, akceptuje powiadomienie albo przechodzi kolejne kroki. Jeżeli po drugiej stronie znajduje się środowisko kontrolowane przez napastnika, skutkiem może być przejęcie aktywnej sesji.

To ważne rozróżnienie dla osób odpowiedzialnych za phishing w firmie. Jeżeli organizacja skupia się wyłącznie na haśle, może przeoczyć sytuację, w której hasło nie jest główną zdobyczą. Celem staje się dostęp po uwierzytelnieniu.

Jak działa atak BitM krok po kroku

Typowy scenariusz zaczyna się od przynęty. Może to być e-mail z informacją o dokumencie, fałszywy komunikat z działu IT, wiadomość z komunikatora, zaproszenie do portalu kontrahenta albo alert o rzekomym problemie z kontem. Treść nie musi być krzykliwa. Często im bardziej przypomina zwykły proces firmowy, tym lepiej działa.

Po kliknięciu użytkownik trafia do środowiska, które wygląda jak przeglądarka, okno logowania albo normalna aplikacja. Kluczowe jest to, że pośrednik kontroluje przepływ. Użytkownik może być przekonany, że loguje się do znanej usługi, ale jego działania są przekazywane przez warstwę atakującego.

Następnie użytkownik wykonuje logowanie. Wpisuje login, hasło, kod jednorazowy, potwierdza powiadomienie MFA albo wybiera konto SSO. W tym samym czasie atakujący może uzyskać dane potrzebne do przejęcia sesji. Jeżeli usługa wyda token albo cookie po udanym uwierzytelnieniu, ten element może stać się właściwym celem ataku.

Na końcu użytkownik może zobaczyć błąd, przekierowanie, komunikat o zakończeniu procesu albo prawdziwą stronę usługi. Dla niego całość wygląda jak drobna niedogodność techniczna. Dla organizacji może to być początek przejęcia skrzynki, dostępu do plików, panelu SaaS, komunikatora albo systemu finansowego.

Dlaczego prawdziwy ekran logowania nie zawsze oznacza bezpieczeństwo

Wiele poradników uczy, że trzeba sprawdzać wygląd strony, kłódkę, certyfikat i poprawność formularza. Te elementy nadal mają znaczenie, ale przy BitM nie wystarczają. Użytkownik może zobaczyć interfejs bardzo podobny do prawdziwego, a czasem faktycznie przechodzić przez elementy prawdziwej usługi, tylko nie w taki sposób, jaki zakłada organizacja.

Problem polega na zaufaniu do kontekstu. Jeżeli pracownik otrzyma link z przejętej skrzynki kontrahenta, zobaczy dokument w znanym narzędziu i zostanie poproszony o logowanie, może uznać proces za naturalny. Atak nie musi wyglądać jak fałszywa loteria ani rażąco podejrzany formularz. Może przypominać codzienną pracę.

To szczególnie istotne w środowiskach Microsoft 365, Google Workspace i innych systemach opartych o SSO. SSO, czyli single sign-on, pozwala logować się jednym mechanizmem do wielu aplikacji. Gdy taki proces zostanie przejęty lub przekierowany przez pośrednika, skutki mogą wyjść daleko poza jedną stronę.

Dlatego przy BitM trzeba myśleć o całym ciągu zdarzeń: skąd przyszedł link, czy użytkownik sam zainicjował logowanie, czy adres i kontekst są zgodne z normalną ścieżką pracy, czy menedżer haseł rozpoznaje domenę, czy system prosi o MFA w spodziewanym momencie i czy po logowaniu nie pojawia się nietypowe przekierowanie.

BitM, AiTM, MitM i zwykły phishing — gdzie jest różnica

Pojęcia łatwo się mieszają, bo wszystkie dotyczą pośredniczenia albo podszycia. W praktyce warto rozdzielić je po tym, gdzie znajduje się „środek” ataku i co jest głównym celem.

Klasyczny phishing zwykle próbuje skłonić użytkownika do podania danych na fałszywej stronie, w formularzu, wiadomości albo rozmowie. Celem może być hasło, numer karty, kod BLIK, dane osobowe albo decyzja płatnicza.

MitM, czyli Man-in-the-Middle, to szersze pojęcie techniczne. Oznacza sytuację, w której atakujący znajduje się pomiędzy dwiema stronami komunikacji i może ją obserwować, modyfikować albo przekazywać. W kontekście nowoczesnych usług webowych najczęściej mówimy jednak o wariantach aplikacyjnych i tożsamościowych, a nie o prostym podsłuchu sieciowym.

AiTM, czyli Adversary-in-the-Middle, opisuje phishing, w którym przeciwnik pośredniczy między użytkownikiem a prawdziwą usługą, aby przechwycić dane uwierzytelnienia, kody, cookies albo tokeny. To ważny temat dla kont firmowych, bo może prowadzić do przejęcia skrzynki i dalszego Business Email Compromise.

BitM jest konkretnym wariantem tego podejścia. Zamiast myśleć tylko o stronie pośredniczącej, patrzymy na przeglądarkę lub zdalną sesję jako element ataku. Użytkownik może mieć poczucie, że korzysta ze swojej przeglądarki, ale w rzeczywistości wykonuje działania w środowisku kontrolowanym przez kogoś innego.

Dlaczego MFA nadal jest potrzebne, ale nie każde MFA zatrzyma BitM

MFA, czyli uwierzytelnianie wieloskładnikowe, pozostaje jednym z najważniejszych zabezpieczeń kont. Nie należy z niego rezygnować tylko dlatego, że istnieją ataki pośredniczące. Bez MFA wiele przejęć byłoby łatwiejszych, szybszych i bardziej masowych.

Problem zaczyna się wtedy, gdy organizacja traktuje MFA jako jeden uniwersalny poziom ochrony. Kod SMS, kod z aplikacji, push, passkey i klucz FIDO2 nie działają tak samo. Część metod można przekazać pośrednikowi, wpisać na stronie albo zatwierdzić w nieoczekiwanym momencie. Inne metody są projektowane tak, aby uwierzytelnienie było powiązane z właściwą domeną i urządzeniem.

Przy BitM najbezpieczniejszy kierunek to phishing-resistant MFA, czyli metody odporniejsze na pośredniczenie, takie jak FIDO2, WebAuthn, passkeys lub rozwiązania oparte o certyfikaty i urządzenia zarządzane. Nie oznacza to, że każda firma może wdrożyć je wszędzie od razu. Oznacza to, że konta uprzywilejowane, finansowe, administracyjne, HR i dostęp do kluczowych systemów powinny dostać wyższy poziom ochrony niż zwykłe konto o niskim ryzyku.

Ważna jest też ochrona sesji. Microsoft w dokumentacji dotyczącej tokenów zwraca uwagę na ryzyko kradzieży tokenów i potrzebę ograniczania ich użycia przez kontrolę urządzenia, warunki dostępu, wykrywanie ryzykownych logowań, ponowne uwierzytelnianie dla wrażliwych działań oraz rozwiązania utrudniające odtworzenie tokenu poza zaufanym kontekstem.

Gdzie BitM może pojawić się w polskiej firmie

W polskiej organizacji BitM nie musi występować pod własną nazwą. Pracownik może zobaczyć zwykły komunikat: „nowy dokument do podpisu”, „aktualizacja konta”, „wniosek HR”, „nowe zasady bezpieczeństwa”, „potwierdź dostęp”, „sprawdź fakturę”, „zaakceptuj zaproszenie”. Mechanizm jest groźny właśnie dlatego, że ukrywa się w rutynowym procesie.

W finansach może dotyczyć kont księgowych, poczty osób zatwierdzających przelewy, narzędzi do wymiany dokumentów z bankiem albo portali kontrahentów. Dlatego scenariusze BitM warto łączyć z tematem testów phishingowych dla firm finansowych, procedurą weryfikacji płatności i analizą nietypowych logowań.

W software house i działach IT podobny schemat może dotyczyć GitHub, GitLab, Jira, Confluence, chmury, paneli klienta albo dostępu do środowisk produkcyjnych. Tu ryzyko nie kończy się na jednej skrzynce. Przejęta sesja może otworzyć drogę do kodu, dokumentacji, sekretów projektowych lub danych klienta. Dlatego w takich zespołach sens ma połączenie BitM z ćwiczeniami dla software house i IT.

W HR, administracji i biurach rachunkowych atak może przyjść jako zaproszenie do podpisania dokumentu, prośba o zmianę danych pracownika albo plik udostępniony przez znaną osobę. Jeżeli wiadomość pochodzi z przejętego konta, rozpoznanie zagrożenia jest trudniejsze, bo nadawca może być prawdziwy, a ryzyko kryje się w dalszym procesie.

Jak użytkownik może rozpoznać ryzyko

Nie ma jednej oznaki, która zawsze zdradzi BitM. Lepiej szukać niespójności w procesie. Jeżeli logowanie pojawia się po linku z wiadomości, której użytkownik się nie spodziewał, trzeba zatrzymać się przed wpisaniem danych. Jeżeli system prosi o MFA w sytuacji, której użytkownik sam nie rozpoczął, to również jest sygnał do przerwania działania.

Pomaga menedżer haseł. Jeżeli hasło nie podpowiada się tam, gdzie zwykle powinno, użytkownik dostaje praktyczny sygnał, że adres lub kontekst może być inny niż oczekiwany. Nie jest to ochrona pełna, ale w codziennej pracy bywa bardzo skuteczna.

Drugim dobrym nawykiem jest ręczne otwieranie usług krytycznych. Dokument z wiadomości może być prawdziwy albo może prowadzić do fałszywego procesu. Jeżeli logowanie dotyczy poczty, bankowości, systemu HR, VPN, panelu administratora albo narzędzia finansowego, bezpieczniej wejść do usługi przez zapisaną zakładkę, aplikację lub firmowy portal.

Trzeci element to zgłoszenie. Użytkownik nie musi rozstrzygać, czy to był BitM, AiTM, fałszywy formularz czy inny wariant. Ma przekazać wiadomość, link, zrzut ekranu i informację, czy wpisał dane lub zatwierdził MFA. Organizacja powinna mieć prosty kanał zgłaszania, a nie oczekiwać, że pracownik sam wykona analizę techniczną.

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

Jeżeli użytkownik zalogował się przez podejrzany link, wpisał hasło, podał kod MFA albo zatwierdził powiadomienie, trzeba działać tak, jak przy możliwym przejęciu sesji. Sama zmiana hasła nie jest wystarczającą reakcją.

Najpierw należy zgłosić zdarzenie do IT, Security lub SOC i nie kasować wiadomości. Potrzebne są nagłówki e-maila, adres linku, czas kliknięcia, nazwa użytej usługi, informacja o MFA i opis tego, co użytkownik zobaczył po logowaniu.

Następnie trzeba zmienić hasło z zaufanego urządzenia i unieważnić aktywne sesje. W systemach tożsamościowych należy sprawdzić ostatnie logowania, nowe urządzenia, metody MFA, zgody aplikacji, tokeny, lokalizacje, reguły pocztowe, przekierowania i nietypowe działania po zalogowaniu.

Jeżeli konto ma dostęp do finansów, HR, dokumentów klientów, repozytoriów kodu albo paneli administracyjnych, reakcja powinna objąć również aplikacje zależne od SSO. Przejęcie sesji w jednym miejscu może dać dostęp do kolejnych usług, nawet jeśli użytkownik pamięta tylko jedno okno logowania.

W przypadku poczty firmowej trzeba sprawdzić reguły ukrywające wiadomości, automatyczne przekierowania, wysyłkę do kontrahentów i próby zmiany numerów rachunków. To częsty dalszy etap po przejęciu konta, bo atakujący może użyć realnej skrzynki do kolejnych oszustw.

Co powinny zrobić IT, Security i SOC

Zespół techniczny powinien traktować BitM jako problem tożsamości, sesji i procesu, a nie tylko problem poczty. Filtrowanie wiadomości jest potrzebne, ale nie wyłapie wszystkiego, zwłaszcza gdy link prowadzi przez zaufaną usługę udostępniania plików albo wiadomość przychodzi z przejętego konta.

W praktyce potrzebne są cztery warstwy. Pierwsza to ograniczanie wejścia: ochrona poczty, blokowanie złośliwych adresów, analiza linków, izolacja przeglądania dla ryzykownych stron i edukacja użytkowników. Druga to odporne uwierzytelnianie: phishing-resistant MFA dla kont o wysokim ryzyku, ograniczanie słabszych metod zastępczych i wymuszanie urządzeń zgodnych z polityką.

Trzecia warstwa to kontrola sesji. Organizacja powinna umieć szybko unieważnić sesje, wymusić ponowne uwierzytelnienie, wykrywać logowania z nietypowych lokalizacji, zmiany metod MFA, użycie nowych urządzeń i anomalie po zalogowaniu. Czwarta warstwa to reakcja po incydencie: gotowa procedura, lista logów, odpowiedzialności i komunikacja do użytkowników.

Ważne jest też rozdzielenie kont według ryzyka. Administrator, księgowość, HR, zarząd, deweloper z dostępem do repozytoriów i osoba obsługująca płatności nie powinni mieć takiej samej ochrony jak konto bez dostępu do wrażliwych procesów. BitM pokazuje, że warto inwestować w ochronę tam, gdzie przejęta sesja może szybko zamienić się w incydent biznesowy.

Jak ćwiczyć scenariusz BitM w firmie

BitM nie powinien być ćwiczony jako techniczna ciekawostka. Najbardziej wartościowe jest sprawdzenie, czy pracownicy zatrzymują się w odpowiednich momentach procesu. Czy rozpoznają nieoczekiwane logowanie? Czy zgłaszają wiadomość od znanego nadawcy, gdy kontekst jest nietypowy? Czy wiedzą, że MFA nie powinno być zatwierdzane automatycznie?

W testach phishingowych dla firm taki scenariusz pozwala mierzyć nie tylko kliknięcie. Ważniejsze są kolejne decyzje: wejście w link, reakcja na logowanie, próba użycia zapisanej zakładki, zgłoszenie wiadomości, opisanie sytuacji i zachowanie po ewentualnym podaniu danych.

Dobry program security awareness powinien tłumaczyć, że nowoczesny phishing coraz częściej atakuje proces, a nie pojedynczy formularz. Użytkownik ma rozumieć, że podejrzane może być nie tylko to, jak wygląda strona, ale też to, dlaczego w ogóle został poproszony o logowanie i kto zainicjował ten proces.

Ćwiczenia warto łączyć z krótkimi mikrolekcjami, quizami i prostą procedurą zgłaszania. Można też wykorzystać quiz rozpoznawania phishingu jako lekki element utrwalający, ale przy BitM kluczowe będzie ćwiczenie reakcji na podejrzany proces logowania, a nie tylko ocena wyglądu wiadomości.

Dlaczego BitM jest evergreenem, a nie tylko chwilowym trendem

Nazwa BitM może pojawiać się falami w raportach, ale mechanizm pozostanie aktualny tak długo, jak firmy będą używać przeglądarki jako głównego miejsca pracy. Poczta, dokumenty, CRM, HR, finanse, komunikatory, repozytoria kodu i panele administracyjne coraz częściej działają przez web i SSO. To wygodne dla użytkownika, ale atrakcyjne dla atakujących.

Rozwój phishing-as-a-service dodatkowo obniża próg wejścia. Atakujący nie muszą za każdym razem budować całej infrastruktury samodzielnie. Mogą korzystać z gotowych zestawów, przekierowań, automatyzacji i przejętych kont do dystrybucji. Dla organizacji oznacza to, że obrona nie może opierać się na jednej radzie typu „sprawdź, czy strona wygląda prawdziwie”.

BitM jest dobrym tematem evergreen, bo porządkuje myślenie o phishingu po erze prostych fałszywych formularzy. Pracownik nadal jest ważnym elementem obrony, ale nie może być jedyną barierą. Potrzebuje czytelnych zasad, łatwego zgłaszania i technicznych kontroli, które ograniczą skutki błędu.

Co zapamiętać

Przy BitM pytanie nie brzmi tylko: „czy ta strona wygląda prawdziwie?”. Lepsze pytanie brzmi: „czy to ja świadomie rozpocząłem ten proces logowania i czy odbywa się on w normalnej ścieżce pracy?”.

Jeżeli odpowiedź jest niejasna, użytkownik powinien przerwać działanie i zgłosić sytuację. Organizacja powinna natomiast umieć szybko sprawdzić sesje, tokeny, logowania i zmiany na koncie. Właśnie połączenie zachowania użytkownika, odpornego MFA, kontroli sesji i reakcji operacyjnej zmniejsza ryzyko, że jedno kliknięcie zamieni się w przejęcie dostępu.

Jeżeli chcesz przećwiczyć podobne scenariusze w organizacji albo sprawdzić, czy pracownicy rozpoznają nietypowe procesy logowania, przejdź do kontaktu z PHISHLY. Taki test ma sens wtedy, gdy mierzy nie tylko kliknięcie, lecz także zatrzymanie procesu, zgłoszenie i reakcję po możliwym przejęciu sesji.