# You Connect to Hotel Wi-Fi, Attacker Logs into Microsoft 365 Account — Without You Clicking Anything

## Overview

Imagine this scenario: you just checked in to your hotel after a long flight, opened your laptop, turned on Wi-Fi, opened Chrome, and Chrome automatically opened the Microsoft 365 sign-in page. It looks familiar. Enter your password, click "Next", the MFA popup appears, you approve. Done - and you think you just logged into your company email.

You are not logged in to your email. You just gave access to your company account to an attacker sitting somewhere, watching your operator panel screen light up.

There are no suspicious links to avoid. There are no attachments to refuse to open. There's not a single step you did wrong - because the only wrong step was connecting to that Wi-Fi network.

This is not a hypothetical scenario. Since June 2026, an attack campaign is exploiting captive portals - the network portal system that coordinates all hotel guest Wi-Fi - in many cities in the US, India and Saudi Arabia. The attacker compromises the gateway device, rewrites the DNS configuration, and then waits. A single controlled gateway is enough to expose all guests of that hotel - regardless of device, regardless of operating system.

The part that makes this campaign different from regular phishing lies in the MFA bypass technique: the attacker does not need to steal the password. They abuse the Microsoft Device Code Authentication flow so that the victim accidentally issues a valid OAuth token - MFA has been satisfied, no credential has actually changed hands, and password reset is not enough to revoke access.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/3df89880-6475-4cbd-9d15-e33d9d04ed14.png align="center")

## Event Timeline

| **Date** | **Key Event** |
| --- | --- |
| **Apr 2026** | FrostArmada disrupted; APT28 abused compromised SOHO routers to manipulate DNS and steal Microsoft credentials and OAuth tokens. |
| **Jun 2026** | Early evidence of a DNS poisoning campaign targeting hotel captive portals emerged. |
| **23 Jul 2026** | ReliaQuest published *Threat Spotlight: DNS Poisoning Tactics Expand to Hospitality Wi-Fi*. |
| **26 Jul 2026** | SecurityAffairs and BleepingComputer reported extensively on the campaign. |
| **30 Jul 2026** | SafeState released follow-up technical analysis. |
| **31 Jul 2026** | Campaign remained active; attacker infrastructure continued operating with page rotation and visitor tracking capabilities. |

## The Hacker Group Behind

### APT28 — Group Suspected of Being Behind the Campaign

Although the attribution has not been officially confirmed, all technical evidence points towards APT28 — or at least an actor who directly copied the group's TTP.

### Who Is APT28?

APT28 (Advanced Persistent Threat 28) is the identifier given by FireEye/Mandiant. This group is also known by many different names depending on the vendor:

| **Alias** | **Assigned By** |
| --- | --- |
| Fancy Bear | CrowdStrike |
| Forest Blizzard (formerly STRONTIUM) | Microsoft |
| Sofacy | Kaspersky |
| Pawn Storm | Trend Micro |
| Sednit | ESET |
| GRU Unit 26165 | Official designation — Russian Main Intelligence Directorate (GRU) |

APT28 is believed to operate under the direction of GRU (Главное разведывательное управление) — the military intelligence agency of the Russian Federation. The group has been active since at least 2004 and is one of the most thoroughly researched threat actors in the history of cybersecurity.

### Outstanding Operational History

APT28 is not a strange name — this group has left its mark on many major geopolitical events:

*   2016 US election campaign Hacked into the email system of the Democratic National Committee (DNC) and Hillary Clinton's election campaign. Stolen documents leaked via WikiLeaks.
    
*   WADA Attack (2016) Stolen medical records of Olympic athletes from the World Anti-Doping Agency, announced to pressure counterattack after Russia was banned from participating.
    
*   French Election 2017 (Macron Leaks) Leaked internal documents of Emmanuel Macron's election campaign 48 hours before the election.
    
*   NotPetya (2017) Together with Sandworm (APT44 — another GRU unit), contributed to a chain of attacks that damaged Ukrainian infrastructure, causing an estimated $10 billion in damage globally.
    
*   Attack on TV5Monde (2015) Take down the entire broadcasting system of a French TV channel, pretending to be "CyberCaliphate" to hide attribution.
    
*   DarkHotel / Operation Evil Twins (precursor) APT28 has a history of targeting hotels and travel environments. The campaign targeting executive travelers at Asian hotels from 2007-2014 was attributed to many stakeholder groups.
    

## Attack Chain

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/e6e77205-36ec-4390-89b9-5813e8b9cd5f.png align="center")

### Phase 1: Gateway Infiltration (T1078 / T1190)

First we will need to understand what a captive portal is and why controlling it means controlling the entire hotel network.

What is Captive Portal?

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/10afb762-6440-404c-b4f3-e69b7dc2fbde.png align="center")

Have you ever connected to a hotel Wi-Fi and seen a web page appear asking you to enter your room name, full name or click "Accept Terms"? It is a captive portal. This is a device or software that sits between your device and the internet, acting as the "gateway" to the entire guest network:

*   Allocate IP addresses to all connected devices (DHCP)
    
*   Answers every domain name question - "where is login.microsoft.com?" - before the device asks for the internet (DNS resolver)
    
*   Route all traffic out
    
*   Control who can access the network and who is blocked
    

If an attacker controls a captive portal, they control all three — and every device connecting to that network is within reach.

How do attackers get into the captive portal?

The Captive portal appliance - like any other network device - requires an administrative interface for hotel IT to configure. The problem is that the majority of these devices are installed once and then forgotten, with default credentials or weak passwords that are never changed.

Attackers exploit three common weaknesses:

1.  SSH exposed to the internet - SSH (Secure Shell) is a protocol that allows remote device administration via the command line. In a standard corporate environment, SSH is only opened on the internal network. But many hotel captive portals have SSH that opens directly to the internet - anyone can try to log in from anywhere. Combined with the admin password admin123 or the factory default password that has not been changed, an attacker can gain access using brute-force or credential stuffing in minutes.
    
2.  Unprotected web admin console - The browser management interface (usually on port 8080 or 443) of the device sometimes does not require strong enough authentication, does not have rate limiting against brute-force, or is running old firmware with known vulnerabilities. Some devices even have a backdoor account from the manufacturer.
    
3.  Misconfigured SNMP - SNMP (Simple Network Management Protocol) is a network device monitoring protocol. With the default community string being public or private, an attacker can read - and in some versions - write configuration to the device without needing the admin password.
    

### Phase 2: Rewrite Gateway Config

After gaining access to the gateway, the next thing the attacker does takes only a few minutes: rewrite the DNS table inside the device.

How does DNS work - and why is it the most important control point?

Think of DNS as the phone book of the internet. When you type login.microsoftonline.com into the browser, the computer doesn't know what the IP address of that server is and it needs to ask DNS: "What is the phone number (IP) of login.microsoftonline.com?"

In a normal environment, that process looks like this:

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/99941a51-a903-40b8-8fc5-a6956d7fb497.png align="center")

After the attacker rewrites the DNS configuration on the gateway, the same process occurs as follows:

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/f4820028-737f-4d56-8fd8-807787a9692d.png align="center")

Bottom line: An attacker doesn't need to touch your device. They do not need to send phishing emails. They don't require you to download anything. They just need to change a number in the directory table — from Microsoft's real IP address to the IP address of a fake server they control.

In fact, some DNS poisoning IPs of attackers have been recorded such as: 31.57.243\[.\]154, 38.146.28\[.\]75

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/327393b5-15d9-4059-84a6-0ce8d34772c8.png align="center")

### Phase 3: Expanding Scope (~1/3 of Cases)

In about a third of observed cases, attackers further leveraged the Web Proxy Auto-Discovery (WPAD) mechanism — a protocol that allows Windows devices to automatically load proxy configurations when joining new networks. WPAD checks both DHCP and DNS — and the gateway is controlling both.

A successful WPAD hijack will push a malicious proxy configuration file to the victim device. Chrome, Windows authentication components, and most enterprise applications then route traffic through the attacker's proxy. The traffic log appears like a normal HTTPS connection — it's easy to miss during an investigation.

### Stage 4: Fake login page

Victim opens a browser and is redirected to a fake Microsoft 365 sign-in page. This page is designed to look legit. The entered credentials are collected and sent to the attacker's infrastructure.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/8a77caf0-2167-4d54-bc05-e3ace8469d2c.png align="center")

### Stage 5: MFA Bypass

This is the most dangerous technique in the campaign. Instead of just collecting passwords, the attacker paired redirects with the abuse Microsoft Device Code Authentication flow:

1.  The attacker initiates a device-code authentication session from his side
    
2.  Victim sees a Microsoft login screen that looks completely legitimate
    
3.  Victim approve — accidentally authorized the session initiated by the attacker
    
4.  Microsoft grants valid OAuth access tokens and refresh tokens to software controlled by attackers
    
5.  The attacker has full access to the account — MFA has been satisfied
    

No credential changes hands. Password reset is not enough to terminate access if the attacker-enrolled device is still active in the tenant.

## Detailed Technical Analysis

### Why Hard-Coded DNS Doesn't Help

A common misconception: "I have fixed DNS set to 8.8.8.8 or 1.1.1.1, so I'm safe."

Wrong. A DNS query sent to 8.8.8.8 still leaves the device as a plaintext UDP packet on port 53. The gateway sits between the device and the internet — it can read the query, forge a valid reply, and return it before the packet actually reaches Google DNS. From the device's perspective, everything looks completely normal.

### Limitations of Encrypted DNS

DNS over HTTPS (DoH) and DNS over TLS (DoT) can prevent this attack — but only when configured in strict mode. Most current tools run in opportunistic mode by default: when encrypted resolution fails (for example, the gateway blocks), the system automatically fallsback to plaintext DNS.

It is this fallback that the poison gateway exploits. Devices that users believe are being protected are actually communicating DNS completely unencrypted — and being redirected.

Two configurations prevent this attack:

*   Strict-mode DoH or DoT — completely eliminate plaintext fallback
    
*   Full-tunnel VPN — all traffic including DNS goes through the corporate network before the gateway has a chance to intervene
    

### Operator Panel Architecture

The analysis team discovered an attacker domain that has a host operator panel with the following features:

*   Page rotation (fake interface rotation)
    
*   Visitor tracking
    
*   IP allowlisting (cloaking — hidden from security researchers)
    

The existence of this operational infrastructure proves the operation is still being actively maintained — not a spray-and-pray campaign abandoned after deployment.

## **IOC & Artifacts**

### **Malicious IP**

*   **38.146.28\[.\]75**
    
*   **31.57.243\[.\]154**
    
*   **104.194.159\[.\]150**
    

### Malicious Domain

*   **m365-owa\[.\]com**
    
*   **owa-ms365\[.\]com**
    
*   **ms365-device\[.\]com**
    
*   **ms365-live\[.\]com**
    
*   **chikolimdrid\[at\]gmail\[.\]com**
    

## **MITRE ATT&CK Mapping**

| **Tactic** | **Technique ID** | **Technique Name** | **Description** |
| --- | --- | --- | --- |
| Initial Access | T1078 | Valid Accounts | Weak or reused administrative credentials on the hotel gateway enabled unauthorized access. |
| Initial Access | T1190 | Exploit Public-Facing Application | Exploitation of exposed management services such as SSH, SNMP, or the web administration interface. |
| Defense Evasion | T1557 | Adversary-in-the-Middle | DNS poisoning performed through the hotel's captive portal infrastructure. |
| Defense Evasion | T1562 | Impair Defenses | Circumvention of encrypted DNS protections by exploiting DNS fallback behavior. |
| Credential Access | T1556 | Modify Authentication Process | Abuse of the Microsoft Device Code authentication flow. |
| Credential Access | T1528 | Steal Application Access Token | Theft of OAuth access tokens obtained through the Device Code flow. |
| Collection | T1056.003 | Web Portal Capture | Credential harvesting using a counterfeit Microsoft 365 sign-in page. |
| Lateral Movement | T1185 | Browser Session Hijacking | Browser traffic redirected through a malicious WPAD-configured proxy. |
| Command and Control | T1071.001 | Web Protocols | Command-and-control communications conducted over HTTP/HTTPS via an attacker-controlled proxy. |
| Command and Control | T1090 | Proxy | Malicious proxy configuration distributed through WPAD to intercept user traffic. |

## Comments

This campaign marks a notable escalation in the TTP of DNS poisoning: the first time this technique has been systematically deployed on hospitality-grade captive portal infrastructure — not small-office SOHO routers like FrostArmada before it.

Regarding attribution: The technical overlap with APT28/FrostArmada is obvious — same DNS poisoning mechanism to steal Microsoft credential, same abuse device code authentication. However, the domain and IP infrastructure do not match what is known about APT28. The way the attacker redirected the entire DNS query instead of selectively filtering by keyword also suggests this was a less sophisticated operator — possibly a copycat financially-motivated, possibly another actor who learned the TTP from the FrostArmada report. Our analytics team does not have enough basis to assign attribution at this time.

What's really more worrying than attribution is the rate at which the attack surface is spreading. FrostArmada targets SOHO routers — devices with millions of units but scattered. Captive hotel portal is more focused: a single hotel gateway at an international conference can expose hundreds of corporate executives in 2-3 days.

Perspective from the Vietnamese market: Hanoi and Ho Chi Minh City are fast-growing MICE (Meetings, Incentives, Conferences, Exhibitions) destinations in Southeast Asia. 4-5 star hotels serve a large number of corporate travelers from financial, technology and energy corporations - exactly the profile of victims of this campaign. Large conferences (APEC, ASEAN-related events, industry summits) gather thousands of executives into the same guest network. This is a high-value goal.

According to our observations through SOC activity, outbound DNS anomalies from traveling endpoints are often not prioritized in triage — because DNS traffic from endpoints that are outside the office network is inherently "anomaly" by definition. This is exactly why this technique works so well: it exploits the blind spot in the monitoring logic of the majority of the SOC team.

Bigger pattern to watch: after hotels, the next natural attack surface is airport lounge Wi-Fi, conference center networks and co-working spaces — all of which use similar captive portal architecture, often with lower security standards.

## Recommendation

### For employees on business trips

Turn on VPN BEFORE connecting to hotel Wi-Fi - not after

*   This is the most important habit. The correct order is: Connect to Wi-Fi → TURN ON VPN NOW → then use the internet
    
*   Why is this order important? Because DNS poisoning happens as soon as your device connects to the network and sends the first DNS query. If the VPN is not enabled, the DNS query will already pass through the poisoned gateway — even if you enable the VPN after a few seconds.
    

Do not approve any MFA prompts that you did not initiate yourself

*   If you're sitting at a hotel and suddenly there's a Microsoft screen asking you to confirm your login and you don't remember what you just logged in to — refuse immediately.
    
*   The Device Code abuse technique works by making you approve a session that the attacker initiated. If you don't actively open apps or log into anything, there's no reason to have an MFA popup.
    
*   Simple rule: Don't remember what you just did → Don't approve.
    

Kiểm tra URL và chứng chỉ trước khi nhập mật khẩu

*   Before typing any password, look at the address bar:
    
*   Valid:
    
    *   [https://login.microsoftonline.com](https://login.microsoftonline.com) (green key, exact URL)
        
*   Counterfeit:
    
    *   [https://login.microsoftonline.com.verify-now.net](https://login.microsoftonline.com.verify-now.net)
        
    *   [https://m1crosoft-login.com](https://m1crosoft-login.com)
        
    *   http:// (no "s" after http)
        

Prioritize using mobile data (4G/5G) instead of hotel Wi-Fi when doing sensitive work

*   When you need to access company email, internal systems or important documents - using a hotspot from your personal phone is much safer than hotel Wi-Fi. An attacker cannot poison DNS on your 4G connection.
    

### For IT / Security Team

High priority — Do this week

*   Enforce always-on VPN with full-tunnel for traveling devices: Full-tunnel ensures 100% of traffic - including DNS - passes through the corporate infrastructure before the device "sees" the outside network. Split-tunnel opening exceptions for some domains is enough for attackers to exploit.
    
*   Check if the current VPN is split-tunnel: Get-VpnConnection | Select-Object Name, SplitTunneling, Routes
    
*   If SplitTunneling = True → need to review and remove unnecessary exceptions
    
*   Block Device Code Authentication Flow in Microsoft Entra ID
    
*   Disable WPAD on all endpoints via Group Policy
    

Medium priority — Do it this month

*   Review Entra ID logs after each long business trip
    
    `// Microsoft Sentinel — Hunt for suspicious Device Code sign-ins`
    
    `SigninLogs`
    
    `| where AuthenticationProtocol == "deviceCode"`
    
    `| where ResultType == 0 // Thành công`
    
    `| extend Country = tostring(LocationDetails.countryOrRegion)`
    
    `| project TimeGenerated, UserPrincipalName, IPAddress, Country, AppDisplayName`
    
    `| where Country !in ("Vietnam") // Thay bằng danh sách quốc gia baseline của org`
    
    `| order by TimeGenerated desc`
    
*   Check the proxy artifact on the computer after the employee returns from work
    
*   Review Entra ID registered devices — recover strange devices
    

Long term — Improve architecture

*   Updated Travel Security Policy — Clear rules: Public Wi-Fi = untrusted by default. VPN must be enabled before connecting. Don't use hotel Wi-Fi for sensitive work without a VPN.
    
*   Strict-mode DNS over HTTPS (DoH) — Chromium-based browsers supported. Deploy policy to enforce strict mode, eliminating fallback to plaintext DNS when encrypted resolution fails.
    
*   Include this attack in Security Awareness Training — Instead of the general "be careful of public Wi-Fi," include this specific scenario: "You connect to hotel Wi-Fi, don't click anything, still lose your account. This is why you have to turn on the VPN first."
    

## References

[Hackers Hijack Hotel Wi-Fi to Steal Microsoft 365 Credentials](https://securityaffairs.com/196017/security/hackers-hijack-hotel-wi-fi-to-steal-microsoft-365-credentials.html)

[DNS Poisoning Tactics Expand to Hospitality Wi-Fi | ReliaQuest Threat Spotlight](https://reliaquest.com/blog/threat-spotlight-dns-poisoning-tactics-expand-to-hospitality/)

[Hotel Wi-Fi DNS Poisoning Attacks Hijack Microsoft 365 Accounts](https://www.safestate.com/post/hotel-wi-fi-dns-poisoning-attacks-hijack-microsoft-365-accounts)

[Hackers hijack hotel Wi-Fi DNS to steal Microsoft 365 accounts](https://www.bleepingcomputer.com/news/security/hackers-hijack-hotel-wi-fi-dns-to-steal-microsoft-365-accounts/)