Przejęcie DNS w hotelowym Wi‑Fi umożliwia kradzież kont Microsoft 365

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Publiczne i półpubliczne sieci Wi‑Fi od dawna pozostają atrakcyjnym celem dla cyberprzestępców, jednak najnowszy scenariusz ataku pokazuje wyraźną zmianę taktyki. Zamiast tworzyć fałszywe punkty dostępowe lub prowadzić klasyczne ataki typu evil twin, napastnicy przejmują kontrolę nad urządzeniami brzegowymi obsługującymi sieci hotelowe i konferencyjne, a następnie modyfikują ustawienia DNS.

W praktyce oznacza to, że użytkownik próbujący zalogować się do Microsoft 365 może zostać przekierowany na fałszywą stronę logowania, mimo że korzysta z legalnej sieci obiektu. Taki model ataku uderza bezpośrednio w warstwę tożsamości i może prowadzić do przejęcia poczty, dokumentów, komunikacji oraz dostępu do firmowych usług chmurowych.

W skrócie

Badacze opisali kampanię wymierzoną w osoby korzystające z sieci Wi‑Fi w hotelach i centrach konferencyjnych. Po uzyskaniu uprawnień administracyjnych do bramy sieciowej atakujący zmieniają konfigurację DNS, aby przekierowywać ofiary na infrastrukturę phishingową podszywającą się pod logowanie Microsoft 365.

W części incydentów zaobserwowano także nadużycie mechanizmu Device Code Flow, który może pozwolić obejść ochronę MFA bez potrzeby przechwytywania klasycznych kodów jednorazowych. Dodatkowo w części przypadków pojawiały się próby wykorzystania WPAD do podstawienia złośliwej konfiguracji proxy i uzyskania większej kontroli nad ruchem ofiary.

Kontekst / historia

Kampania była obserwowana co najmniej od czerwca 2026 roku i objęła organizacje z wielu sektorów, w tym finansów, ochrony zdrowia, energetyki, handlu detalicznego, usług prawnych i profesjonalnych. Charakter ataku sugeruje model oportunistyczny, nastawiony nie na jedną branżę, lecz na użytkowników biznesowych podróżujących służbowo.

Wybór hoteli i obiektów konferencyjnych nie jest przypadkowy. To miejsca, w których regularnie pojawiają się pracownicy o wysokiej wartości dla atakujących: menedżerowie, konsultanci, handlowcy, prawnicy, partnerzy biznesowi i kontraktorzy. Z perspektywy napastnika przejęcie ich tożsamości może zapewnić dostęp do zasobów organizacji bez konieczności bezpośredniego włamania do środowiska firmowego.

Analiza techniczna

Dokładny punkt wejścia do urządzeń sieciowych nie został jednoznacznie potwierdzony, ale najbardziej prawdopodobne scenariusze obejmują słabo zabezpieczone interfejsy administracyjne, takie jak SSH, SNMP lub panele webowe, a także wykorzystanie luk w samych appliance’ach sieciowych. Po uzyskaniu uprawnień administracyjnych napastnik modyfikuje konfigurację DNS na bramie lub urządzeniu pośredniczącym.

Efektem jest zwracanie spreparowanych odpowiedzi DNS dla zapytań kierowanych do usług Microsoft 365. Użytkownik wpisuje prawidłowy adres, lecz zamiast na autentyczny portal trafia na stronę phishingową. Taki atak jest szczególnie skuteczny, ponieważ odbywa się w zaufanym środowisku, zwykle w trakcie podróży służbowej, gdy potrzeba szybkiego dostępu do poczty lub dokumentów obniża czujność.

Szczególnie groźny jest wariant wykorzystujący Device Code Flow. To legalny mechanizm OAuth przeznaczony dla urządzeń z ograniczonym interfejsem wejścia, gdzie użytkownik zatwierdza logowanie na innym urządzeniu. W opisywanym scenariuszu ofiara jest nakłaniana do autoryzacji działania, ale faktycznie potwierdza sesję zainicjowaną przez atakującego. W rezultacie wystawiany jest prawidłowy token OAuth dla klienta kontrolowanego przez napastnika, co pozwala ominąć MFA bez tradycyjnej kradzieży hasła.

Dodatkowym elementem kampanii było nadużycie WPAD, czyli mechanizmu automatycznego wykrywania serwera proxy. Jeśli system ofiary pobierze złośliwy plik PAC, atakujący może próbować przekierować część ruchu przez kontrolowaną przez siebie infrastrukturę. Choć nie potwierdzono pełnej skuteczności tego elementu we wszystkich przypadkach, samo jego użycie wskazuje na dążenie do pogłębienia kontroli nad komunikacją sieciową ofiary.

Warto zaznaczyć, że ręczne ustawienie publicznego resolvera DNS nie musi rozwiązać problemu. Jeśli lokalna brama przechwytuje lub fałszuje nieszyfrowane zapytania DNS jeszcze przed ich opuszczeniem sieci, użytkownik nadal może zostać przekierowany do infrastruktury napastnika.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takiego incydentu jest przejęcie tożsamości w ekosystemie Microsoft 365. Może to otworzyć dostęp do Exchange Online, SharePoint, OneDrive, Teams oraz innych zasobów zintegrowanych z Microsoft Entra ID. W środowisku korporacyjnym taki dostęp często staje się punktem wyjścia do dalszych działań ofensywnych.

Napastnicy mogą wykorzystać przejęte konto do ataków BEC, kradzieży danych, rozsyłania phishingu z legalnych skrzynek, eskalacji uprawnień lub utrzymania trwałej obecności w środowisku chmurowym. Ryzyko jest tym większe, że użytkownik działa pozornie zgodnie z procedurami bezpieczeństwa: korzysta z prawdziwej sieci obiektu i loguje się do znanej usługi.

Z punktu widzenia zespołów SOC i IAM zagrożenie jest trudne do wykrycia, ponieważ ślady kompromitacji bywają subtelne. W telemetrii mogą pojawiać się nietypowe przepływy uwierzytelniania, nowe aplikacje klienckie, podejrzane sesje OAuth, niestandardowe lokalizacje logowania lub rzadko spotykana aktywność związana z Device Code Flow.

Rekomendacje

Podstawowym środkiem ograniczającym skuteczność podobnych kampanii powinien być pełnotunelowy VPN typu always-on dla użytkowników mobilnych. Taki model utrudnia manipulowanie ruchem przez lokalną infrastrukturę i zmniejsza ryzyko przechwycenia lub modyfikacji zapytań.

Drugim ważnym elementem jest stosowanie szyfrowanego DNS w trybie restrykcyjnym oraz monitorowanie, czy urządzenia końcowe rzeczywiście korzystają z bezpiecznych mechanizmów rozwiązywania nazw. Sama zmiana resolvera na publiczny nie wystarczy, jeśli zapytania pozostają nieszyfrowane i mogą być przechwycone lokalnie.

W obszarze tożsamości organizacje powinny przeanalizować potrzebę korzystania z Device Code Flow. Jeśli ten mechanizm nie jest wymagany, warto go zablokować. Jeżeli jest potrzebny w wybranych scenariuszach, należy ograniczyć go politykami dostępu warunkowego do konkretnych kont, aplikacji lub urządzeń oraz regularnie analizować logi jego użycia.

Dobrym krokiem jest również wyłączenie WPAD tam, gdzie nie jest niezbędny. Mechanizm ten od lat wiąże się z ryzykiem nadużyć, a w wielu nowoczesnych środowiskach generuje więcej zagrożeń niż realnych korzyści operacyjnych.

przegląd logów Microsoft Entra ID pod kątem logowań wykorzystujących Device Code Flow,
analiza nowo autoryzowanych aplikacji i wystawionych tokenów OAuth,
monitorowanie nietypowych przekierowań logowania oraz anomalii geolokalizacyjnych,
wymuszenie aktualizacji systemów i klientów obsługujących konfigurację proxy,
audyt ekspozycji administracyjnej urządzeń sieciowych używanych przez partnerów i dostawców,
szkolenie pracowników mobilnych, aby nie zatwierdzali nieoczekiwanych żądań logowania.

Podsumowanie

Opisana kampania pokazuje, że bezpieczeństwo tożsamości nie zależy wyłącznie od hasła i MFA, ale także od integralności lokalnej infrastruktury sieciowej. Przejęcie DNS w hotelowym Wi‑Fi może skutecznie zamienić zwykłe logowanie do Microsoft 365 w atak phishingowy, a wykorzystanie Device Code Flow dodatkowo osłabia skuteczność tradycyjnych mechanizmów ochronnych.

Dla organizacji to wyraźny sygnał, że ochrona użytkowników mobilnych wymaga równoczesnego wzmacniania warstwy sieciowej, polityk IAM oraz zdolności detekcyjnych. Szczególnie istotne staje się monitorowanie nietypowych przepływów uwierzytelniania i ograniczanie zaufania do sieci dostępnych poza kontrolowanym środowiskiem firmy.