Wprowadzenie do problemu / definicja luki
Phishing-as-a-Service (PhaaS) Sneaky2FA dorzucił do swojego arsenału technikę Browser-in-the-Browser (BitB) – fałszywe „okno przeglądarki w przeglądarce”, które imituje pop-up logowania Microsoft i maskuje podejrzany URL. W efekcie ofiary podają hasła oraz potwierdzają MFA w kontrolowanym przez napastnika oknie, a zestaw przechwytuje zarówno poświadczenia, jak i aktywne ciasteczka sesyjne (AiTM). To znacznie podnosi skuteczność przejęć kont Microsoft 365.
Technika BitB została szczegółowo opisana przez badacza mr.d0x w 2022 r. – to sprytna kombinacja HTML/CSS/JS budująca wiarygodny, ruchomy pop-up z paskiem adresu udającym domenę docelową (np. login.live.com), choć strona ładuje się z innego źródła.
W skrócie
- Co nowego? Sneaky2FA renderuje fałszywe okno logowania (BitB) i w jego wnętrzu ładuje swoją stronę AiTM, co łączy „realistykę” z pełnym przechwytem sesji.
- Kogo celuje? Głównie Microsoft 365/Entra ID (OAuth/SSO).
- Jak zwodzi? Bot-check (Cloudflare Turnstile), warunkowe ładowanie/geofencing, ciężka obfuskacja HTML/JS, rotacja domen i ścieżek (często długie, losowe path).
- Skutki: kradzież ciasteczek sesyjnych → ominięcie 2FA → BEC/escalation.
Kontekst / historia / powiązania
Sneaky2FA został nagłośniony na początku 2025 r. przez Sekoia TDR jako świeży zestaw AiTM/PhaaS sprzedawany via bot Telegram, z charakterystycznymi wzorcami URL i nietypowym profilem User-Agent podczas negocjacji z API Microsoftu („niemożliwa zmiana urządzenia”). Sekoia wskazała też pokrewieństwa kodowe do W3LL OV6. W telemetrii z Q1 2025 Sneaky2FA był wśród najpopularniejszych AiTM-kitów obok Tycoon2FA i EvilProxy.
W listopadzie 2025 r. Push Security odnotowało nową odmianę Sneaky2FA z BitB, a media branżowe (m.in. BleepingComputer) potwierdziły obserwacje. Równolegle, inne PhaaS (np. Raccoon0365) też eksperymentują z BitB.
Analiza techniczna / szczegóły luki
Łańcuch ataku Sneaky2FA z BitB (obserwacje Push Security):
- Ofiara trafia na domenę przynęty (np. previewdoc[.]us) i przechodzi Cloudflare Turnstile.
- Strona stylizowana na podgląd PDF/Adobe zachęca do „Sign in with Microsoft”.
- Po kliknięciu renderowane jest okno BitB – pasek adresu i ramka imitują Edge/Windows lub Safari/macOS (dopasowanie do platformy ofiary).
- Wewnątrz okna ładuje się realny przepływ logowania Microsoft, ale przez reverse-proxy/Sneaky AiTM, który podkrada hasło + token sesyjny.
- Po sukcesie następuje redirect do prawdziwego zasobu, by ukryć ślady.
Techniki uniku i utrudniania analizy:
- Obfuskacja HTML/JS (dzielenie tekstu na fragmenty z niewidocznymi tagami, elementy interfejsu jako obrazy/BASE64, anty-fingerprinting kodu).
- Warunkowe ładowanie: niepożądany ruch (VPNy, adresy vendorów) → przekierowanie na nieszkodliwe strony (np. Wikibooks).
- Bot-protection przed crawlerami (Turnstile/CAPTCHA).
- Rotacja domen/ścieżek: krótkie życie kampanii, bardzo długie ścieżki (≈150 znaków).
Wskaźniki i heurystyki detekcji (Sekoia):
- „Impossible device shift” w logach Entra ID: kolejne kroki logowania z odmiennymi UA (np. iOS Safari → Windows Edge w jednej sesji).
- Wzorce URL generowane przez kit (/index, /verify, /validate po długiej ścieżce), autograb e-maila w parametrze URL.
- Infrastruktura i licencjonowanie via Telegram bot („Sneaky Log”).
Czym BitB różni się od typowego AiTM?
BitB to warstwa „kosmetyczna” – sprawia, iż phishing wygląda jak natywny pop-up SSO (z rzekomo „dobrym” adresem), przez co „sprawdź URL” traci sens. W Sneaky2FA BitB nakłada się na klasyczny przepływ AiTM odpowiedzialny za kradzież sesji.
Praktyczne konsekwencje / ryzyko
- Przejęcia kont M365 mimo włączonego 2FA (kradzież ciastek sesyjnych) → BEC, wycieki danych, ruch boczny w M365/SharePoint/Teams, utrata reputacji i realne straty finansowe.
- Podwyższona „skuteczność socjotechniczna”: pop-up wygląda jak natywny dla przeglądarki/OS ofiary.
- Utrudniona analiza i blokowanie domen przez rotację/warunkowe ładowanie.
Rekomendacje operacyjne / co zrobić teraz
Prewencja (to-do dla SecOps/IT):
- Wymuś phishing-resistant MFA (FIDO2/WebAuthn) dla kont uprzywilejowanych i wrażliwych ról; ogranicz SMS/OTP. (Kontekst: AiTM/BitB atakują sesję).
- SSO/MFA policy hardening: step-up dla ryzykownych sygnałów, blokada starszych metod (legacy), wymuszenie device compliance.
- Zasady przeglądarkowe: blokady iFrame’ów/okien z nieznanych domen w krytycznych aplikacjach (CSP, X-Frame-Options), izolacja przeglądarkowa dla dostępu do SaaS krytycznego.
- Edukacja, ale konkret: „przeciągnij pop-up” – prawdziwe okno da się wysunąć poza ramy głównej przeglądarki i pojawia się w pasku zadań; BitB – nie. (Uwaga: to tylko szybki test heurystyczny, nie gwarancja).
Detekcja i reagowanie (Blue Team):
- Korelacja anomalii UA/klientów w jednym przepływie logowania („impossible device shift”). Wdrożenie reguł Sigma/UEBA dla Entra ID (przykłady z publikacji Sekoia).
- Hunting domen kampanii: długie, losowe ścieżki, motywy lure (podgląd dokumentu/Adobe), CAPTCH-e przed adekwatną stroną, domeny w stylu previewdoc[.]*.
- Telemetria przeglądarkowa/EDR: wykrywanie osadzonych „okien” z atrybutami nietypowymi dla natywnego pop-upa; alerty na Cloudflare Turnstile → Microsoft login w krótkiej sekwencji.
- Playbook IR: natychmiastowe unieważnienie sesji (Revoke refresh tokens), wymuszenie key rotation, przegląd reguł skrzynek (forwardy, reguły ukrywania), MFA re-enrollment i risk-based sign-out.
Twardnienie M365/Entra:
- Włącz Continuous Access Evaluation, Sign-in risk policies, Token protection (jeśli dostępne), ogranicz Auth Session Lifetime; monitoruj Consent Grants i aplikacje typu OAuth z nadmiernymi uprawnieniami.
Różnice / porównania z innymi przypadkami
- Tycoon2FA/Mamba2FA – klasyczne AiTM (proxy/relay) bez akcentu na BitB; skuteczne, ale mniej „wizualnie” przekonujące niż BitB. Sneaky2FA łączy AiTM + „makijaż” BitB.
- Raccoon0365 – również eksperymentuje z BitB (zapowiedzi „BITB mini-panel”), co sugeruje trend w PhaaS.
Podsumowanie / najważniejsze wnioski
Sneaky2FA podniósł poprzeczkę: BitB zwiększa wiarygodność phishingu, a warstwa AiTM przez cały czas zapewnia kradzież sesji i ominięcie MFA. Organizacje muszą traktować „sprawdzaj URL” jako niewystarczające – potrzebne są phishing-resistant MFA, polityki kontekstowe, korelacja logów (UA/anomalia), szybszy IR po incydencie i ochrona tożsamości w przeglądarce.
Źródła / bibliografia
- BleepingComputer – Sneaky2FA PhaaS kit now uses redteamers’ Browser-in-the-Browser attack (19 listopada 2025). (BleepingComputer)
- Push Security – Analyzing the latest Sneaky2FA Browser-in-the-Browser phishing page (18 listopada 2025). (Push Security)
- Sekoia – Sneaky 2FA: exposing a new AiTM Phishing-as-a-Service (16 stycznia 2025). (Sekoia.io Blog)
- Sekoia – Global analysis of Adversary-in-the-Middle phishing threats (11 czerwca 2025). (Sekoia.io Blog)
- mr.d0x – Browser In The Browser (BITB) Attack (15 marca 2022). (mrd0x.com)
