Badacze wykryli kampanię, w której napastnicy przejmują bramy publicznych sieci Wi‑Fi i zmieniają ich konfigurację DNS. Pracownik próbujący skorzystać z Microsoft 365 może zostać przekierowany na fałszywy panel logowania albo nakłoniony do zatwierdzenia sesji rozpoczętej przez atakującego. Najskuteczniejszą ochroną firmowego urządzenia jest automatycznie uruchamiany VPN typu full tunnel, obejmujący również zapytania DNS.
Atak rozpoczyna się w hotelowej sieci, a nie na komputerze pracownika
23 lipca 2026 roku ReliaQuest opublikowało analizę kampanii wymierzonej w osoby korzystające z Wi‑Fi w hotelach, centrach konferencyjnych i innych współdzielonych obiektach.
Napastnicy nie muszą wcześniej:
- wysyłać wiadomości phishingowej,
- infekować komputera,
- przekonywać użytkownika do pobrania pliku,
- przejmować służbowego telefonu,
- znać adresu e-mail konkretnej ofiary.
Najpierw uzyskują kontrolę nad bramą sieciową obsługującą publiczne Wi‑Fi. Takie urządzenie może odpowiadać za przekierowanie użytkownika do strony powitalnej, przydzielenie dostępu oraz rozwiązywanie nazw DNS.
Po zmianie konfiguracji jedna przejęta brama może wpływać na ruch wielu gości jednocześnie.
Według raportu ReliaQuest z 23 lipca 2026 r. kampania jest aktywna co najmniej od czerwca. Zaatakowane urządzenia wykryto w wielu miastach Stanów Zjednoczonych, a także w Indiach i Arabii Saudyjskiej.
Czym jest captive portal?
Captive portal to strona wyświetlana podczas łączenia się z publiczną siecią. Może wymagać:
- zaakceptowania regulaminu,
- podania numeru pokoju,
- wpisania kodu z recepcji,
- podania adresu e-mail,
- zalogowania się kontem uczestnika konferencji.
Aby wyświetlić portal, infrastruktura Wi‑Fi przechwytuje pierwsze połączenia urządzenia i kieruje je do lokalnego systemu uwierzytelniania.
Brama znajduje się więc w uprzywilejowanym miejscu — pomiędzy urządzeniem gościa a internetem. Jeżeli zostanie przejęta, napastnik może próbować manipulować rozwiązywaniem domen i kierowaniem ruchu.
Podobna konstrukcja występuje również w:
- portach lotniczych,
- centrach handlowych,
- pociągach,
- przestrzeniach coworkingowych,
- uczelniach,
- placówkach medycznych,
- obiektach targowych,
- sieciach udostępnianych podczas wydarzeń.
Jak działa zatruwanie DNS?
DNS tłumaczy nazwę domeny, na przykład adres usługi internetowej, na adres IP serwera.
W normalnej sytuacji urządzenie wysyła pytanie do zaufanego resolvera i otrzymuje prawidłową odpowiedź. W zaatakowanej sieci brama może odpowiedzieć inaczej albo skierować zapytanie do serwera kontrolowanego przez napastnika.
W opisywanej kampanii zmieniona konfiguracja DNS prowadziła użytkowników do infrastruktury przygotowanej do podszywania się pod Microsoft 365.
Zaobserwowane domeny obejmowały:
m365-owa[.]comowa-ms365[.]comms365-device[.]comms365-live[.]com
Nazwy zostały zapisane w formie nieaktywnej.
Domeny mogą na pierwszy rzut oka wyglądać wiarygodnie, zwłaszcza na małym ekranie telefonu albo wtedy, gdy pracownik spodziewa się dodatkowego logowania po połączeniu z nową siecią.
Dlaczego ustawienie publicznego DNS może nie wystarczyć?
Użytkownik może zakładać, że ręczne ustawienie serwera 8.8.8.8 albo 1.1.1.1 całkowicie rozwiązuje problem.
Jeżeli zapytania DNS są przesyłane w sposób nieszyfrowany, przejęta brama może je przechwycić lub sfałszować przed dotarciem do wybranego resolvera. Samo wpisanie adresu publicznego serwera DNS nie gwarantuje więc ochrony.
Szyfrowany DNS może ograniczyć ryzyko, ale tylko wtedy, gdy:
- działa w trybie wymuszonym,
- korzysta z zaufanego dostawcy,
- nie przechodzi automatycznie na nieszyfrowany DNS po wystąpieniu błędu,
- jego konfiguracja nie może zostać zmieniona przez lokalną sieć.
Czy HTTPS chroni przed takim przekierowaniem?
HTTPS utrudnia napastnikowi przejrzyste podszycie się pod prawdziwą domenę Microsoftu. Przeglądarka powinna odrzucić certyfikat niepasujący do legalnego adresu.
Atakujący mogą jednak skierować użytkownika do osobnej, podobnie nazwanej domeny posiadającej własny prawidłowy certyfikat. Kłódka w przeglądarce potwierdza wtedy szyfrowane połączenie z domeną napastnika — nie potwierdza, że witryna należy do Microsoftu.
Dlatego trzeba sprawdzać pełny adres, a nie wyłącznie obecność HTTPS.
Atak może ominąć MFA przez device code flow
W części przypadków napastnicy nie ograniczali się do klasycznego wyłudzenia hasła. Wykorzystywali mechanizm logowania określany jako device code flow.
Funkcja została zaprojektowana dla urządzeń, na których trudno używać pełnego formularza logowania, na przykład:
- telewizorów,
- konsol,
- urządzeń konferencyjnych,
- drukarek,
- aplikacji terminalowych.
Jak wygląda legalny proces?
Urządzenie wyświetla kod. Użytkownik otwiera stronę Microsoftu na innym komputerze lub telefonie, wpisuje kod, loguje się i zatwierdza dostęp.
Po poprawnym uwierzytelnieniu token trafia do urządzenia, które rozpoczęło procedurę.
Jak wykorzystuje to napastnik?
Atakujący sam inicjuje logowanie na kontrolowanym urządzeniu. Następnie przekonuje ofiarę, że wyświetlony kod jest potrzebny do:
- uruchomienia hotelowego internetu,
- dokończenia logowania,
- potwierdzenia konta Microsoft 365,
- odblokowania dostępu do dokumentu,
- przeprowadzenia dodatkowej weryfikacji.
Ofiara loguje się na prawdziwej stronie Microsoftu i może poprawnie przejść MFA. Problem polega na tym, że zatwierdza sesję rozpoczętą przez napastnika.
Microsoft wydaje wówczas ważny token OAuth klientowi atakującego. Z punktu widzenia systemu MFA zostało wykonane prawidłowo.
Nie jest to techniczne złamanie kryptografii MFA. Użytkownik zostaje nakłoniony do autoryzowania niewłaściwej sesji.
Microsoft udostępnia możliwość blokowania device code flow przy użyciu Conditional Access. Firma podkreśla również, że mechanizm jest rzadko używany przez klientów, ale często wykorzystywany przez napastników.
WPAD może skierować więcej ruchu przez serwer napastnika
W około jednej trzeciej analizowanych przypadków zaobserwowano również próbę wykorzystania Web Proxy Auto-Discovery, czyli WPAD.
WPAD pozwala systemowi Windows automatycznie odnaleźć konfigurację serwera proxy. Urządzenie może wyszukiwać plik wpad.dat zaraz po połączeniu z nową siecią.
Przejęta brama może odpowiedzieć na takie wyszukiwanie i dostarczyć złośliwy plik PAC. Plik określa, które połączenia mają być kierowane przez wskazany serwer proxy.
Potencjalnie może to objąć ruch:
- przeglądarki,
- aplikacji korzystających z ustawień Windows,
- składników uwierzytelniania,
- programów biznesowych,
- usług działających w tle.
ReliaQuest nie potwierdziło skutecznego przejęcia ruchu przez WPAD w analizowanych przypadkach. Zaobserwowano próby jego wykorzystania, dlatego technikę należy traktować jako możliwy dodatkowy kanał ataku, a nie potwierdzony element każdego włamania.
Kto był narażony?
Ruch do przejętych bram pochodził z organizacji reprezentujących między innymi:
- finanse,
- usługi profesjonalne,
- kancelarie prawne,
- ochronę zdrowia,
- energetykę,
- handel detaliczny.
Nie wskazuje to na kampanię ograniczoną do jednej branży. Celem są prawdopodobnie pracownicy posiadający wartościowe konta firmowe i korzystający ze współdzielonych sieci podczas podróży.
Szczególnie atrakcyjne mogą być konta:
- członków zarządu,
- administratorów IT,
- pracowników finansów,
- prawników,
- handlowców,
- konsultantów,
- osób uczestniczących w negocjacjach,
- zespołów pracujących nad fuzją albo ważnym kontraktem.
Czy za kampanią stoi APT28?
Zaobserwowane techniki przypominają wcześniejszą kampanię FrostArmada, wiązaną z rosyjską grupą APT28, znaną również jako Fancy Bear i Forest Blizzard.
Podobieństwa obejmują:
- przejmowanie urządzeń brzegowych,
- zmianę konfiguracji DNS,
- podszywanie się pod Microsoft,
- ataki adversary-in-the-middle,
- próbę uzyskania dostępu do Microsoft 365.
Nie ma jednak wystarczających dowodów, aby przypisać nową kampanię bezpośrednio APT28.
ReliaQuest wskazuje na istotne różnice:
- odmienną infrastrukturę,
- inne dane rejestracyjne domen,
- brak technicznego powiązania z serwerami FrostArmada,
- atakowanie hotelowych captive portali,
- przekierowywanie znacznie szerszego ruchu,
- dodatkowe próby wykorzystania WPAD i device code flow.
Podobieństwo sposobu działania może oznaczać wykorzystanie znanej techniki przez innego operatora.
Najlepsza ochrona: VPN uruchamiany automatycznie
ReliaQuest jako najważniejsze zabezpieczenie wskazuje firmowy VPN działający w trybie:
- always-on — uruchamiany automatycznie,
- full tunnel — kierujący cały ruch przez firmową infrastrukturę,
- obejmujący DNS,
- blokujący dostęp do internetu do czasu utworzenia tunelu.
W takim modelu hotelowa brama widzi przede wszystkim zaszyfrowane połączenie z firmowym serwerem VPN. Zapytania DNS są rozwiązywane przez zaufane serwery organizacji.
Dlaczego zwykły VPN może nie wystarczyć?
Ochrona może być niepełna, gdy:
- użytkownik musi uruchomić VPN ręcznie,
- przeglądarka zaczyna działać przed połączeniem tunelu,
- stosowany jest split tunneling,
- DNS pozostaje obsługiwany przez lokalną sieć,
- VPN rozłącza się bez zablokowania ruchu,
- captive portal jest otwierany poza tunelem.
Organizacja powinna przetestować zachowanie urządzenia na rzeczywistej sieci z portalem powitalnym, a nie opierać się wyłącznie na nazwie funkcji w panelu VPN.
Jak pracownik może bezpieczniej korzystać z hotelowego Wi‑Fi?
Preferuj własne połączenie komórkowe
Jeżeli zasięg na to pozwala, hotspot z telefonu lub firmowy modem komórkowy ogranicza kontakt z obcą infrastrukturą Wi‑Fi.
Nie jest to ochrona absolutna, ale usuwa z ataku przejętą hotelową bramę.
Nie loguj się do firmy podczas otwierania portalu hotelowego
Portal dostępu do Wi‑Fi nie powinien żądać:
- hasła Microsoft 365,
- zatwierdzenia logowania w Authenticatorze,
- kodu urządzenia Microsoft,
- hasła VPN,
- danych administratora,
- dostępu do firmowej skrzynki.
Jeżeli taki komunikat pojawi się podczas łączenia z Wi‑Fi, należy rozłączyć sieć i skontaktować się z firmowym IT.
Sprawdzaj pełny adres
Prawidłowa strona logowania Microsoftu korzysta z oficjalnych domen producenta. Obecność słów microsoft, office, m365, owa lub live w adresie nie wystarcza.
Nie zatwierdzaj nieoczekiwanych kodów
Jeżeli pracownik sam nie rozpoczął logowania na urządzeniu wymagającym device code flow, nie powinien wpisywać kodu ani zatwierdzać autoryzacji.
Wyłącz automatyczne łączenie z publicznymi sieciami
Urządzenie nie powinno automatycznie dołączać do otwartych sieci o znanych lub popularnych nazwach.
Co powinna wdrożyć firma?
1. Always-on VPN z pełnym tunelem
Polityka powinna obejmować służbowe laptopy i — jeżeli to możliwe — telefony. Należy sprawdzić, czy tunel obejmuje DNS oraz czy działa mechanizm kill switch.
2. Blokowanie device code flow
Jeśli organizacja nie korzysta z tej metody, należy ją zablokować w Microsoft Entra Conditional Access.
Przed włączeniem blokady warto:
- uruchomić politykę w trybie raportowania,
- sprawdzić logi logowania,
- zidentyfikować legalne urządzenia,
- przygotować ograniczone wyjątki,
- wyłączyć device code flow dla pozostałych użytkowników.
Od 1 lipca 2026 roku nowe tenanty Microsoft Entra domyślnie blokują device code flow w ramach Security Defaults. Dokumentacja Microsoft dotycząca ustawień domyślnych
3. Wyłączenie WPAD
Jeżeli firma nie wykorzystuje automatycznego odnajdywania proxy, WPAD powinien zostać wyłączony centralnie.
Jeżeli jest potrzebny, klient może pobierać plik PAC wyłącznie z zatwierdzonego hosta.
4. MFA odporne na phishing
Warto wdrażać:
- passkeys,
- klucze FIDO2,
- Windows Hello for Business,
- uwierzytelnianie powiązane z zarządzanym urządzeniem.
Należy jednak pamiętać, że device code flow może osłabić część kontroli opartych na stanie urządzenia. Dlatego nieużywany mechanizm najlepiej całkowicie zablokować.
5. Szkolenie osób podróżujących
Przed wyjazdem pracownik powinien wiedzieć:
- jak uruchamia się firmowy VPN,
- które komunikaty logowania są prawidłowe,
- jak zgłosić podejrzaną stronę,
- kiedy skorzystać z hotspota,
- jak rozpoznać nieoczekiwane żądanie kodu urządzenia,
- że hotelowe Wi‑Fi nie powinno wymagać danych służbowego konta.
Oznaki możliwego ataku
Administratorzy powinni sprawdzić:
- logowania device code flow,
- nowe urządzenia zarejestrowane w Entra ID,
- wydanie tokenu po zalogowaniu z hotelowej lub zagranicznej sieci,
- dostęp do Microsoft 365 z nietypowego adresu bezpośrednio po podróży pracownika,
- połączenia z domenami podobnymi do Microsoftu,
- zapytania WPAD po dołączeniu do publicznej sieci,
- pobranie nieznanego pliku
wpad.dat, - niespodziewane zmiany proxy,
- reguły przekazywania poczty,
- nowe aplikacje OAuth,
- masowe pobieranie wiadomości lub dokumentów.
Co zrobić po wpisaniu danych na podejrzanej stronie?
- Rozłącz urządzenie z publiczną siecią.
- Skontaktuj się z działem IT niezależnym kanałem.
- Zapisz nazwę sieci, hotel, czas i adres wyświetlonej strony.
- Z zaufanego urządzenia zmień hasło.
- Unieważnij wszystkie aktywne sesje i tokeny odświeżania.
- Sprawdź historię logowania oraz użyte protokoły.
- Usuń nieznane urządzenia z Entra ID.
- Cofnij podejrzane zgody OAuth.
- Sprawdź metody MFA i dane odzyskiwania konta.
- Usuń nieznane reguły pocztowe.
- Przeanalizuj pobrania plików oraz wysłane wiadomości.
- Sprawdź, czy to samo konto miało uprawnienia administracyjne.
- Zmień inne ujawnione dane uwierzytelniające.
- Obserwuj konto również po zmianie hasła.
Zmiana samego hasła może nie wystarczyć. Napastnik posiadający ważny token OAuth lub zarejestrowane urządzenie może zachować dostęp.
Wskaźniki kampanii
ReliaQuest opublikowało następujące wskaźniki:
m365-owa[.]comowa-ms365[.]comms365-device[.]comms365-live[.]com31.57.243[.]154104.194.159[.]15038.146.28[.]75
Znalezienie wskaźnika w logach wymaga analizy czasu, urządzenia, użytkownika i kolejnych operacji. Brak tych adresów nie wyklucza ataku, ponieważ infrastruktura może zostać zmieniona.
Fakty potwierdzone i informacje nieustalone
Potwierdzone:
- przejęte bramy Wi‑Fi wykryto w hotelach i innych współdzielonych obiektach;
- kampania jest aktywna co najmniej od czerwca 2026 roku;
- zmieniana konfiguracja DNS kierowała użytkowników do infrastruktury napastnika;
- celem były konta Microsoft 365 pracowników podróżujących służbowo;
- zaobserwowano domeny podszywające się nazwą pod usługi Microsoftu;
- w części przypadków wykorzystywano device code flow;
- poprawne zatwierdzenie device code flow może wydać napastnikowi token uwierzytelniony przez MFA;
- obserwowano próby wykorzystania WPAD;
- ruch do przejętych bram pochodził z organizacji należących do wielu branż;
- always-on full-tunnel VPN obejmujący DNS ogranicza podstawowy wektor ataku.
Nieustalone albo niepotwierdzone publicznie:
- dokładny sposób przejęcia każdego urządzenia Wi‑Fi;
- liczba skompromitowanych hoteli i użytkowników;
- pełna lista państw objętych kampanią;
- liczba skutecznie przejętych kont Microsoft 365;
- skuteczne wykorzystanie WPAD w analizowanych przypadkach;
- dane skradzione z poszczególnych organizacji;
- wykorzystanie kampanii przeciwko pracownikom z Polski;
- bezpośrednia odpowiedzialność APT28.
Ocena: podobieństwo do wcześniejszych operacji APT28 uzasadnia analizę możliwego związku, ale nie pozwala na pewne przypisanie kampanii. Różnice w infrastrukturze i sposobie prowadzenia ataków mogą wskazywać na innego operatora wykorzystującego opublikowaną lub skopiowaną technikę.
Podsumowanie
Publiczne Wi‑Fi może zostać wykorzystane nie tylko do podsłuchiwania ruchu. Przejęcie bramy pozwala napastnikowi aktywnie sterować tym, dokąd kierowane są urządzenia gości.
Firmy wysyłające pracowników w delegacje powinny wdrożyć automatyczny VPN z pełnym tunelem, zablokować niepotrzebny device code flow i wyłączyć WPAD. Pracownicy powinni preferować połączenie komórkowe oraz zgłaszać każdy przypadek, w którym portal hotelowego Wi‑Fi żąda danych Microsoft 365 albo zatwierdzenia kodu urządzenia.