CaptiveCrunch: jak hotelowe Wi‑Fi może zagrozić firmowemu laptopowi i Microsoft 365

Pracownik melduje się w hotelu, otwiera firmowy laptop i łączy się z Wi‑Fi. Zamiast zwykłej strony akceptacji regulaminu widzi komunikat: „Aby uzyskać dostęp do internetu, zainstaluj aktualizację przeglądarki”. Chwilę później może pojawić się instrukcja uruchomienia polecenia albo ekran logowania do Microsoft 365.

Wszystko pasuje do sytuacji: nowa sieć, portal dostępowy, problemy z połączeniem. Właśnie dlatego taki scenariusz jest skuteczny.

31 lipca 2026 r. Microsoft opisał kampanię CaptiveCrunch. Według analityków grupa Storm-2945, oceniana jako podklaster Midnight Blizzard, od początku maja manipulowała ruchem DNS i HTTP związanym z sieciami wykorzystującymi captive portale. Aktywność obserwowano m.in. w hotelach, centrach konferencyjnych i innych obiektach ze współdzieloną infrastrukturą dostępu do internetu. Celem byli przede wszystkim użytkownicy podróżujący służbowo (Microsoft Threat Intelligence).

Czym jest captive portal i gdzie pojawia się ryzyko?

Captive portal to strona otwierana przed przyznaniem pełnego dostępu do publicznej sieci. Może wymagać zaakceptowania regulaminu, podania numeru pokoju, adresu e-mail albo kodu z recepcji. Sam mechanizm jest powszechny i legalny.

Problem zaczyna się wtedy, gdy napastnik potrafi manipulować ruchem prowadzącym do portalu lub z niego wychodzącym. Microsoft nie przesądza w raporcie, w jaki sposób uzyskano dostęp do poszczególnych elementów infrastruktury, dlatego nie należy automatycznie przypisywać winy konkretnemu hotelowi. Z perspektywy pracownika najważniejszy jest skutek: ekran wyświetlony w spodziewanym momencie może kierować do treści kontrolowanej przez przestępcę.

Portal gościnny może poprosić o akceptację zasad lub kod dostępu. Nie powinien jednak wymagać:

• instalowania aktualizacji systemu, przeglądarki, VPN lub certyfikatu;
• pobrania „narzędzia naprawczego”;
• wklejenia polecenia do PowerShella, cmd.exe, Terminala lub okna „Uruchom”;
• podania firmowego hasła do Microsoft 365 w celu „aktywacji internetu”;
• zatwierdzenia logowania na urządzeniu, którego użytkownik właśnie nie konfiguruje.

Dwie ścieżki ataku, a nie jeden łańcuch

Najważniejsze doprecyzowanie brzmi: Microsoft opisał dwa równoległe warianty, które mogły zaczynać się od podobnego kontaktu z niezaufaną siecią. Zainstalowanie malware nie było warunkiem przeprowadzenia device code phishingu, a zatwierdzenie kodu urządzenia nie musiało prowadzić do instalacji złośliwego programu.

Ścieżka	Co widzi użytkownik	Cel napastnika	Możliwy skutek
A. Malware	Fałszywa aktualizacja, test przeglądarki albo instrukcja „naprawy”	Nakłonić ofiarę do pobrania pliku lub wykonania polecenia	Zdalny dostęp do laptopa, kradzież plików, haseł, cookies i tokenów
B. Tożsamość i chmura	Podobna do prawdziwej strona logowania, pośrednik AiTM albo prawdziwy ekran Microsoftu z kodem urządzenia	Przejąć dane logowania lub skłonić ofiarę do autoryzowania obcej sesji	Dostęp do poczty i zasobów Microsoft 365, nawet bez infekowania laptopa

Ścieżka A: fałszywa aktualizacja i ClickFix

W wariancie malware użytkownik widział treści podszywające się pod aktualizacje przeglądarki lub systemu. Kampania wykorzystywała także technikę ClickFix: fałszywy błąd albo test instruuje ofiarę, by skopiowała polecenie i uruchomiła je lokalnie. To użytkownik wykonuje wtedy kod, często omijając naturalną ostrożność wobec pobranego pliku.

Microsoft opisał m.in. malware CornFlake Go, umożliwiające zdalne wykonywanie poleceń i utrzymanie dostępu do systemu, oraz ChocoShell, działający w pamięci infostealer PowerShell. Obserwowane możliwości obejmowały kradzież plików, zapisanych haseł, cookies, tokenów SSO Microsoft 365 i danych zapisanych sieci Wi‑Fi. Raport wskazuje również na oznaki prób kierowania użytkowników Androida do plików APK.

Samo połączenie z obcą siecią nie oznacza więc automatycznej infekcji. Krytycznym momentem jest pobranie programu, zaakceptowanie nietypowego profilu lub certyfikatu albo wykonanie instrukcji, która przenosi działanie z przeglądarki do systemu operacyjnego.

Ścieżka B: AiTM i device code phishing

Drugi wariant uderzał w tożsamość użytkownika. W phishingu adversary-in-the-middle (AiTM) kontrolowana przez napastnika warstwa pośredniczy między ofiarą a prawdziwą usługą logowania. Może w ten sposób przechwycić dane lub token sesji.

Jeszcze bardziej mylący jest device code flow. To legalny mechanizm używany m.in. przez urządzenia z ograniczoną klawiaturą. Użytkownik otwiera prawdziwą stronę Microsoftu i wpisuje kod. W ataku kod został jednak wcześniej wygenerowany przez napastnika. Ofiara nie loguje własnego urządzenia — zatwierdza sesję rozpoczętą gdzie indziej (Microsoft Learn: przepływy uwierzytelniania).

Dlatego sama kontrola adresu strony nie zawsze wystarczy. Jeżeli użytkownik nie rozpoczął logowania nowego urządzenia lub aplikacji, nie powinien wpisywać otrzymanego kodu. MFA również nie gwarantuje ochrony, jeśli człowiek świadomie zatwierdzi uwierzytelnienie dla niewłaściwej sesji.

Czy VPN rozwiązuje problem?

VPN jest ważną warstwą ochrony, ale nie jest samodzielną odpowiedzią na CaptiveCrunch. W wielu sieciach portal trzeba otworzyć przed zestawieniem tunelu. To właśnie w tym krótkim oknie użytkownik może otrzymać złośliwy komunikat. Nawet aktywny VPN nie cofnie też uruchomienia polecenia ani autoryzacji obcej sesji na prawdziwej stronie logowania.

Najbezpieczniejszą praktyką w podróży jest preferowanie własnego hotspotu, eSIM lub zarządzanego routera podróżnego. Gdy użycie sieci gościnnej jest konieczne, urządzenie powinno być zarządzane, aktualne i skonfigurowane tak, by ograniczać instalację aplikacji oraz uruchamiać zatwierdzony tunel najszybciej, jak pozwala na to dana sieć.

Co firma powinna przygotować przed podróżą?

Urządzenie i łączność

• Wydawaj pracownikom zarządzane laptopy z MDM i EDR oraz bez stałych uprawnień lokalnego administratora.
• Aktualizuj system, przeglądarkę i klienta VPN przed wyjazdem, wyłącznie przez ich zaufane mechanizmy.
• Zapewnij służbowy hotspot, pakiet roamingowy, eSIM albo zarządzany router podróżny.
• Włącz szyfrowanie dysku, automatyczną blokadę ekranu i możliwość zdalnego odcięcia urządzenia.
• Ogranicz automatyczne łączenie ze znanymi sieciami i usuń niepotrzebnie zapisane profile Wi‑Fi.

Microsoft 365 i Entra ID

• Sprawdź w dziennikach, czy organizacja rzeczywiście używa device code flow. Najpierw zastosuj politykę Conditional Access w trybie report-only, zinwentaryzuj uzasadnione wyjątki, a potem blokuj przepływ tam, gdzie nie jest potrzebny (Microsoft Learn: blokowanie przepływów).
• Wymagaj MFA, a dla administratorów, finansów i osób z dostępem do wielu klientów stosuj metody odporne na phishing, np. klucze FIDO2 lub passkeys.
• Ogranicz rejestrowanie nowych metod MFA i urządzeń do zaufanych lokalizacji, zgodnych urządzeń lub kontrolowanego procesu wsparcia.
• Wykorzystaj polityki ryzyka logowania i urządzenia zgodne z wymaganiami tam, gdzie pozwalają na to licencje oraz model pracy firmy.
• Przygotuj możliwość szybkiego unieważnienia sesji użytkownika i izolacji urządzenia bez szukania procedury w trakcie incydentu.

Krótka instrukcja dla pracownika

Pracownik nie musi analizować DNS ani rozpoznawać nazwy kampanii. Powinien znać prostą regułę:

Portal Wi‑Fi może poprosić o kod dostępu lub akceptację regulaminu. Jeżeli żąda instalacji, certyfikatu, polecenia systemowego albo firmowego logowania, przerywam i przełączam się na własny internet.

Dodatkowo warto potwierdzić nazwę sieci z personelem obiektu, nie używać firmowego hasła jako hasła do portalu i nie zatwierdzać nieoczekiwanych powiadomień MFA. Firma powinna podać jeden łatwo dostępny numer lub kanał, na który można od razu wysłać zdjęcie podejrzanego komunikatu.

Co zrobić po kliknięciu, wykonaniu polecenia lub podejrzanym logowaniu?

1. Odłącz i odizoluj urządzenie. Wyłącz Wi‑Fi lub użyj funkcji izolacji w EDR. Nie instaluj przypadkowego „czyściciela” i nie usuwaj samodzielnie śladów.
2. Zgłoś zdarzenie natychmiast. Zanotuj godzinę, miejsce, nazwę sieci, adres strony, treść komunikatu, pobrane pliki i wykonane czynności. Szybkie zgłoszenie jest ważniejsze niż pewność, czy atak się udał.
3. Zabezpiecz konto z czystego urządzenia. Unieważnij aktywne sesje i tokeny, zmień hasło, sprawdź metody MFA, zarejestrowane urządzenia, zgody OAuth, delegacje oraz reguły przekierowania poczty.
4. Przejrzyj logi Microsoft 365 i Entra. Szukaj użycia device code flow, nowych rejestracji, nietypowych lokalizacji i adresów IP, dostępu do Exchange, SharePoint, OneDrive, Teams oraz Microsoft Graph.
5. Zbadaj endpoint. EDR i analiza powłamaniowa powinny ustalić, czy uruchomiono malware, jakie mechanizmy trwałości powstały i jakie dane mogły opuścić urządzenie. Przy potwierdzonej infekcji bezpieczniejsza może być odbudowa systemu niż samo „wyczyszczenie”.
6. Ogranicz skutki biznesowe. Sprawdź wysłane wiadomości, ukryte reguły skrzynki i zmiany danych płatniczych. Ostrzeż partnerów, jeśli z konta mogły wyjść fałszywe prośby.
7. Oceń obowiązki dotyczące danych osobowych. Jeżeli zdarzenie stanowi naruszenie ochrony danych, administrator powinien ocenić ryzyko z IOD lub prawnikiem. Gdy zgłoszenie jest wymagane, RODO przewiduje działanie bez zbędnej zwłoki — w miarę możliwości nie później niż 72 godziny od stwierdzenia naruszenia (UODO: zgłaszanie naruszeń).

Reset hasła jest tylko jednym krokiem. Nie zamyka aktywnych sesji w każdym scenariuszu, nie usuwa zgody udzielonej aplikacji i nie odpowiada na pytanie, czy zainfekowany laptop nadal przekazuje dane. Microsoft zaleca m.in. unieważnienie sesji i kontrolę reguł skrzynki podczas obsługi przejętego konta (Microsoft Learn: reakcja na przejęcie konta).

Dlaczego ten scenariusz jest szczególnie ważny dla biur rachunkowych?

Laptop księgowego lub doradcy może otwierać dostęp do wielu organizacji jednocześnie. W skrzynce znajdują się faktury, dane płacowe, deklaracje, dokumenty tożsamości i historia ustaleń z klientami. Przejęte konto pozwala też tworzyć bardzo wiarygodne prośby o zmianę rachunku bankowego, bo napastnik zna kontekst rozmowy i może użyć prawdziwego podpisu.

Dlatego biuro rachunkowe powinno wymagać dostępu do systemów klientów tylko z zarządzanych urządzeń i potwierdzania zmian finansowych drugim kanałem. Nietypowa dyspozycja płatnicza wymaga telefonu na znany wcześniej numer — nawet jeśli wiadomość pochodzi z właściwej skrzynki.

MŚP nie musi budować własnego SOC, aby ograniczyć to ryzyko. Potrzebuje jednak właściciela procesu, aktualnej listy urządzeń i kont, ochrony endpointów, odpornego MFA, kopii zapasowych oraz krótkiej procedury, którą da się uruchomić także wieczorem lub podczas wyjazdu.

Podsumowanie

CaptiveCrunch łączy kontekst podróży z dwoma różnymi celami: infekcją urządzenia oraz przejęciem tożsamości w chmurze. Dlatego skuteczna ochrona również musi działać dwutorowo.

Po stronie urządzenia oznacza to zarządzany laptop, brak instalacji z captive portalu, EDR i preferowanie własnego internetu. Po stronie Microsoft 365 — ograniczenie device code flow, MFA odporne na phishing, kontrolę ryzykownych logowań i gotowość do unieważnienia sesji. Najważniejszą kompetencją pracownika pozostaje przerwanie procesu, gdy „dostęp do Wi‑Fi” nagle wymaga instalacji, polecenia systemowego lub nietypowego logowania.

Wykorzystane źródła

• Microsoft Threat Intelligence: CaptiveCrunch
• Microsoft Learn: Authentication flows w Conditional Access
• Microsoft Learn: blokowanie przepływów uwierzytelniania
• Microsoft Learn: ograniczanie device code flow dla urządzeń Teams
• Microsoft Learn: reakcja na przejęte konto Microsoft 365
• UODO: zgłaszanie naruszeń ochrony danych