ReliaQuest виявила масштабну кампанію, у якій зловмисники компрометують Wi-Fi-шлюзи готелів, конференц-центрів та інших мереж із captive portal, а потім підміняють DNS-відповіді й ведуть мандрівників на фальшиві сторінки входу Microsoft 365. Активність триває щонайменше з червня 2026 року; скомпрометовані шлюзи знайшли в кількох містах США, Індії та Саудівській Аравії.
Це не загальне попередження про «небезпечний public Wi-Fi». Людина може під’єднатися до справжньої мережі закладу, але все одно потрапити під атаку, бо змінено сам шлюз. За даними ReliaQuest, основний шлях блокує always-on VPN із повним тунелем; значок замка в браузері або вручну заданий public DNS сам по собі не доводить безпечний маршрут.
Як працює перенаправлення в готельній мережі
ReliaQuest із низькою або середньою впевненістю припускає, що початковий доступ отримали через відкриті management-інтерфейси, слабкі чи повторно використані паролі або невиправлене ПЗ шлюзу. Після цього зловмисник змінює DNS і routing для всіх гостей.
- Шлюз компрометують. Зловмисник контролює captive-portal пристрій, який керує DNS і маршрутизацією гостей.
- DNS-відповіді підробляють. Запити до легітимних сервісів можуть отримати адресу attacker-controlled інфраструктури.
- З’являється схожа сторінка входу. ReliaQuest бачила Microsoft-themed домени, а не компрометацію хмари Microsoft.
- Викрадають пароль або авторизацію. Частина випадків використовувала фальшиву форму; у кількох атаках додали device-code flow.
- Ціллю стає акаунт. Схвалення ініційованого зловмисником device-code запиту може видати йому token навіть після звичайної MFA.
Домени та артефакти для перевірки
| Індикатор | Чому важливо |
|---|---|
m365-owa[.]com | Attacker-controlled домен, який імітує Microsoft. |
owa-ms365[.]com | Схожий на Outlook/Microsoft 365 домен із тієї самої кампанії. |
ms365-device[.]com | Домен, пов’язаний із device-code приманкою. |
ms365-live[.]com | Ще один Microsoft-themed домен на пов’язаній інфраструктурі. |
38.146.28[.]75 | IP у підроблених DNS-відповідях і proxy-активності. |
Неочікуваний wpad.dat або PAC-файл | Приблизно у третині випадків намагалися зловживати WPAD; успіх не підтверджено. |
Збіг індикатора — причина для перевірки, а не доказ втрати акаунта кожним гостем. Зіставте його із закладом, часом підключення, станом VPN, browser history, Microsoft Entra sign-ins, device-code events, proxy-активністю та новими сесіями.
Чому 8.8.8.8 і MFA можуть не врятувати
Незашифрований DNS-запит до 8.8.8.8 все одно проходить через скомпрометований шлюз. Той може підробити відповідь раніше, ніж запит дійде до Google. Strict encrypted DNS без plaintext fallback зупиняє таку підміну; opportunistic режим може повернутися до відкритого каналу.
MFA залишається необхідною, але не виправляє authorization, яку користувач сам схвалив після обману. У device-code сценарії людина може входити на справжній сторінці Microsoft, але несвідомо дозволяти сесію зловмисника. Наш матеріал про фішинг кодом пристрою пояснює, чому потрібно перевіряти ініціатора запиту.
Що робити після підозрілого входу в готелі
- Вийдіть із підозрілої мережі. Вимкніть Wi-Fi та перейдіть на довірений mobile hotspot, домашнє або корпоративне з’єднання.
- Повідомте security team заклад і час. Шлюз може загрожувати багатьом гостям; потрібно зіставити VPN, DNS, proxy та identity logs.
- Скасуйте сесії й підозрілі токени. Змініть пароль із довіреного пристрою, завершіть активні сесії та перевірте device-code authentication і OAuth grants.
- Перевірте пошту й cloud account. Перегляньте forwarding та inbox rules, delegates, recovery methods, OneDrive/SharePoint access, downloads і нові пристрої.
- Перевірте proxy у Windows. Шукайте невідомий PAC-файл, proxy server, DNS setting, network profile або certificate. ReliaQuest бачила WPAD-спроби, але не підтвердила їхній успіх.
- Надалі використовуйте full-tunnel VPN. Він має запускатися автоматично та передавати DNS разом із browser і application traffic. Split tunneling може залишити local DNS відкритим.
FAQ
Чи HTTPS зупиняє DNS-підміну в готелі?
HTTPS не дозволяє шлюзу непомітно видати себе за справжній Microsoft hostname без valid certificate. Кампанія натомість використовувала lookalike domains, звичні captive-portal redirects, proxy та device-code authorization. Не ігноруйте certificate warnings.
Чи VPN захищає від цієї кампанії?
Always-on full-tunnel VPN, який передає DNS через довірені корпоративні resolvers, закриває основний шлях. VPN, який запускають лише після входу, допускає DNS leak або split tunneling, може залишити частину traffic відкритою.
Чи потрібно сканувати ноутбук на malware?
Це передусім мережева та identity attack, а не доказ установлення malware на кожен пристрій. Локальна перевірка потрібна, якщо встановлювали файл, extension, certificate, proxy tool чи configuration profile або якщо симптоми тривають в іншій мережі.
Джерела
- ReliaQuest Threat Research. «DNS Poisoning Tactics Expand to Hospitality Wi-Fi». ReliaQuest Threat Spotlight, опубліковано 23 липня 2026 року, дата доступу 24 липня 2026 року. первинний звіт ReliaQuest.
