CaptiveCrunch: hotelowe Wi-Fi prowadziło do CornFlake i kradzieży tokenów

Microsoft opisał kampanię CaptiveCrunch, która zamieniała rutynowe połączenie z hotelowym Wi-Fi w wieloetapowy atak. Ofiara była przekierowywana przez manipulację DNS i HTTP do fałszywych aktualizacji lub logowania kodem urządzenia. Dalsze etapy instalowały backdoor CornFlake i moduły kradnące dane przeglądarek, sesje Microsoft 365 oraz tokeny chmurowe.

Najważniejsza lekcja nie brzmi „nie korzystaj nigdy z hotelowego internetu”. Atak wykorzystuje moment, w którym użytkownik spodziewa się przekierowania do captive portalu, ostrzeżenia sieciowego i dodatkowego kroku logowania. Nietypowe zachowanie przeglądarki wygląda wtedy wiarygodnie.

Co ustalił Microsoft

W analizie opublikowanej 31 lipca Microsoft przypisuje aktywność grupie śledzonej jako Storm-2945, będącej podzbiorem Midnight Blizzard. Firma łączy szerszą aktywność Midnight Blizzard z rosyjską Służbą Wywiadu Zagranicznego i nazwami APT29 oraz Cozy Bear używanymi przez innych badaczy.

Kampania działa co najmniej od początku maja 2026 roku i obejmowała systemy captive portal w branży hotelarskiej na świecie. Microsoft obserwował dwa główne warianty:

• fałszywe aktualizacje przeglądarki lub systemu dostarczające malware;
• phishing kodem urządzenia, którego celem były konta Microsoft.

Od 16 lipca operatorzy częściej korzystali ze ścieżki device code. To pokazuje adaptację po stronie napastnika: gdy organizacje blokują pliki albo poprawiają detekcję endpointu, atak może przenieść ciężar na legalny przepływ tożsamości.

Dlaczego captive portal tworzy idealny kamuflaż

Hotelowe i konferencyjne sieci często przechwytują pierwsze zapytanie HTTP, aby wyświetlić warunki korzystania, numer pokoju albo formularz logowania. Użytkownik widzi domenę inną niż wpisana, certyfikat lub komunikat systemu o wymaganym zalogowaniu. W normalnych warunkach to część działania sieci.

CaptiveCrunch wykorzystywał tę tolerancję. Manipulacja DNS i ruchem HTTP mogła kierować podróżnego do treści przygotowanej przez napastnika. Fałszywa aktualizacja pasowała do kontekstu: „sieć wymaga nowszej przeglądarki” wydaje się mniej podejrzane, gdy dostęp do internetu właśnie nie działa.

VPN nie zawsze rozwiązuje etap początkowy, ponieważ tunel może jeszcze nie być zestawiony przed zaakceptowaniem captive portalu. Dlatego polityka musi obejmować czas przed uruchomieniem VPN.

Łańcuch malware: CornFlake i ChocoShell

Według Microsoftu główny implant, nazwany CornFlake, jest backdoorem napisanym w Go. Kopiował się do ścieżki %APPDATA%\svchost32\svchost32.exe i tworzył usługę o nazwie „Cloud Sync Service”. Nazwa oraz katalog mają naśladować legalny komponent, ale obecność svchost32.exe w profilu użytkownika jest sygnałem odmiennym od systemowego svchost.exe.

Operatorzy stosowali kilka sposobów trwałości i proces nadzorujący, który ponownie uruchamiał składniki. CornFlake umożliwiał pobieranie dalszych poleceń oraz modułów, w tym funkcji związanych z danymi przeglądarki.

Drugim elementem był ChocoShell, wykonywany w pamięci komponent PowerShell. Microsoft opisuje go jako narzędzie kradnące:

• zapisane dane logowania i cookies przeglądarek;
• dane sesyjne Microsoft 365;
• tokeny Azure;
• tokeny Web Account Manager.

Kradzież cookies i tokenów zmienia priorytety reakcji. Reset hasła może nie unieważnić każdej aktywnej sesji. Organizacja musi cofnąć sesje i tokeny, sprawdzić rejestracje aplikacji oraz przejrzeć aktywność w chmurze.

Device-code phishing bez fałszywego formularza hasła

W legalnym przepływie urządzenie wyświetla krótki kod, a użytkownik wpisuje go na stronie dostawcy tożsamości. Napastnik może zainicjować logowanie po swojej stronie i przekazać ofierze kod. Ofiara otwiera prawdziwą witrynę Microsoft, uwierzytelnia się i zatwierdza proces, lecz token trafia do sesji kontrolowanej przez napastnika.

W takim wariancie domena logowania i certyfikat mogą być poprawne. Sygnałem jest kontekst: dlaczego hotel, dokument albo rozmówca prosi o wpisanie kodu urządzenia? Użytkownik powinien zatwierdzać kod tylko wtedy, gdy sam rozpoczął logowanie na konkretnym urządzeniu i rozumie, jaka aplikacja otrzyma dostęp.

Zasady dla osób podróżujących

Najbezpieczniejszym rozwiązaniem dla wrażliwej pracy jest prywatny hotspot komórkowy. Gdy użycie hotelowej sieci jest konieczne:

• przed połączeniem zaktualizuj system i przeglądarkę z zaufanej sieci;
• nie instaluj żadnej „aktualizacji wymaganej przez Wi-Fi”;
• użyj captive portalu tylko do uzyskania dostępu, bez logowania do kont firmowych;
• uruchom pełny tunel VPN natychmiast po przejściu portalu;
• nie ignoruj ostrzeżeń TLS;
• nie wpisuj kodu urządzenia, którego logowania sam nie rozpocząłeś;
• przy podejrzeniu przerwij połączenie i przejdź na hotspot;
• zgłoś zdarzenie, zanim zaczniesz samodzielnie czyścić urządzenie.

Pracownik nie powinien zostać zmuszony do wyboru między terminem biznesowym a bezpieczeństwem. Firma musi zapewnić roaming, hotspot lub inną realną alternatywę.

Kontrole tożsamości

Jeśli organizacja nie potrzebuje przepływu device code, powinna go zablokować. Gdy jest wymagany dla określonych urządzeń, należy ograniczyć go polityką dostępu warunkowego, grupą użytkowników i kontekstem zgodności.

Warto również:

• wymagać urządzenia zarządzanego dla dostępu do danych wrażliwych;
• stosować uwierzytelnianie odporne na phishing, np. passkeys lub klucze FIDO2;
• alarmować na logowania device code z nowych lokalizacji;
• korelować wydanie tokenu z aktywnością użytkownika i urządzenia;
• ograniczać czas sesji uprzywilejowanych;
• umożliwić SOC szybkie unieważnienie tokenów i sesji.

MFA nadal ma wartość, lecz samo potwierdzenie logowania nie chroni, jeżeli użytkownik świadomie autoryzuje przepływ napastnika. Potrzebne są metody związane z właściwą domeną i urządzeniem oraz polityki kontekstowe.

Detekcja na urządzeniu i w sieci

Na Windows sprawdź tworzenie plików i uruchomienia z %APPDATA%\svchost32\, usługę „Cloud Sync Service”, nietypowe procesy potomne PowerShell i mechanizmy watchdog. Ważne jest także połączenie procesu z późniejszym dostępem do magazynów cookies, tokenów i profili przeglądarek.

W DNS oraz proxy szukaj niespodziewanych odpowiedzi w czasie łączenia z captive portalem, przekierowań do fałszywych aktualizacji i ruchu z procesu podszywającego się pod systemowy. Jeżeli laptop był używany w hotelu w okresie kampanii, skoreluj endpoint z logami Entra ID i Microsoft 365.

Procedura po podejrzeniu

1. Odłącz urządzenie od niezaufanej sieci, ale nie usuwaj od razu artefaktów.
2. Skontaktuj się z SOC z innego, zaufanego urządzenia.
3. Unieważnij sesje i tokeny użytkownika; sam reset hasła nie wystarcza.
4. Zabezpiecz logi endpointu, Entra ID, Microsoft 365, DNS i VPN.
5. Sprawdź reguły skrzynki, zgody aplikacji, nowe urządzenia i aktywność chmurową.
6. Odbuduj system z zaufanego obrazu, jeśli potwierdzono malware lub nie można określić zakresu.
7. Rozszerz wyszukiwanie na innych podróżnych korzystających z tych samych obiektów.

Fakty a wnioski Breachroad

Microsoft potwierdza obserwowany łańcuch przekierowań, CornFlake, ChocoShell, przejście do device-code phishingu i techniczne wskaźniki. Atrybucja do Storm-2945 oraz relacja z Midnight Blizzard są oceną Microsoftu, a nie matematycznym dowodem tożsamości operatora.

Wniosek Breachroad jest organizacyjny: bezpieczna polityka podróży musi obejmować internet, tożsamość i endpoint jako jeden proces. Sam VPN nie wystarczy, jeżeli człowiek musi najpierw przejść przez niezaufaną stronę, a sam EDR nie wystarczy, gdy napastnik kradnie legalny token bez instalacji pliku.

Szkolenia cyberbezpieczeństwa i symulacje phishingu mogą przygotować pracowników na fałszywe aktualizacje i device code w kontekście podróży. Audyt bezpieczeństwa IT może sprawdzić polityki Entra, unieważnianie tokenów, VPN, EDR i gotowość SOC.