Public Wi‑Fi DNS Poisoning: Hijacking Microsoft 365 Sessions of Business Travelers

1. Basic Information

• Article Title: Hacked Public Wi-Fi Gateways Used to Harvest Corporate Credentials
• Source: SecurityWeek
• Publication Date: 2026-07-27
• Original Article: https://www.securityweek.com/hacked-public-wi-fi-gateways-used-to-harvest-corporate-credentials/
• Primary Source: https://reliaquest.com/blog/threat-spotlight-dns-poisoning-tactics-expand-to-hospitality/
• Related Entities: Microsoft 365, Entra ID device-code flow, DNS poisoning, AiTM, WPAD, captive portal, FrostArmada, APT28 (attribution unconfirmed)
• Severity: High
• IOCs: 38.146.28.75, 31.57.243.154, 104.194.159.150, m365-owa.com, owa-ms365.com, ms365-device.com, ms365-live.com

2. Executive Summary

This attack compromises Wi-Fi gateways at locations like hotels to forge DNS responses. It does not send phishing emails. Instead, it tricks users into visiting fake Microsoft pages, using WPAD proxies, and entering device-code authentication. This allows attackers to steal MFA-authenticated Microsoft 365 sessions.

3. Attack Flow

Chain A: DNS Redirection and Credential Theft

• Attackers gain administrative access to captive portal gateways in hotels or conference centers.
• Hypothesis (Primary source confidence: Low to Medium): Public SSH/SNMP/Web management interfaces and weak, reused administrator credentials are used for initial access.
• The gateway returns fake responses for DHCP-assigned DNS or passing DNS, resolving normal domains to attacker IPs.
• Users are redirected to fake Microsoft pages to collect credentials and OAuth information.
• Attackers log into Microsoft 365 using the stolen credentials and tokens.

Chain B: WPAD

• The gateway controls wpad name resolution or DHCP option 252.
• The device downloads the attacker's PAC file.
• Windows app and browser traffic pass through the attacker's proxy.
• Investigations observed attempts, but successful execution is unconfirmed.

Chain C: Device-Code Flow

• The fake page shows a Microsoft-like sign-in and approval screen to the user.
• The user approves the code on the legitimate Microsoft side.
• An MFA-authenticated OAuth token is issued to the client started by the attacker.
• Attackers access Microsoft 365 without directly capturing the password.

4. Attacker Position and Execution Location

• Attackers control the public Wi-Fi gateway management interface and external redirection infrastructure.
• DNS forgery and WPAD happen at the gateway. User interaction happens in the terminal browser. Token issuance happens in Microsoft Entra ID. Subsequent access happens from the attacker's side.
• No malware is required on the user's device.

5. Visibility for Victims and Administrators

• Users see a Microsoft-like sign-in or approval screen right after connecting to Wi-Fi.
• Because there are no phishing emails or links to click, users may mistakenly think this is part of the Wi-Fi authentication process.
• SOCs can see DNS/HTTPS requests to IOCs, PAC downloads via WinHttpAutoProxySvc, device-code authentication, and subsequent logins or OAuth operations from unknown IPs.

6. Success and Failure Conditions

Success Conditions

• Attackers have gateway management privileges.
• Device DNS is unencrypted, or encrypted DNS allows fallback to plaintext.
• Always-on full-tunnel VPN does not block pre-establishment traffic.
• Users input credentials or approve the device-code.
• Conditional Access allows device-codes, unknown devices, or unfamiliar locations.

Failure Conditions

• Always-on full-tunnel VPN routes all traffic (including DNS) to the corporate network.
• Strict DoH/DoT prevents plaintext fallback.
• WPAD is disabled, and PAC file hosting is restricted.
• Entra ID blocks the device-code flow, requiring phishing-resistant MFA and device compliance.

7. What Happens Upon Success

Credentials, OAuth tokens, and MFA-authenticated Microsoft 365 sessions are stolen. Attackers may proceed to access email, OneDrive, SharePoint, Teams, request additional OAuth consents, or register devices. While primary sources confirm Microsoft 365 account compromise paths, data theft and follow-on breaches must be verified for each victim organization.

8. Observable Logs

• Email: No initial access emails. Check for post-compromise inbox rules, external forwarding, and internal phishing.
• Proxy/SWG/DNS: Legitimate domains resolving to 38.146.28.75, IOC domains/IPs, PAC file downloads, and certificate/SNI mismatches.
• Endpoint/EDR: svchost.exe -k LocalServiceHttp -p -s WinHttpAutoProxySvc, unknown wpad.dat files, pre-VPN establishment traffic, and DNS settings.
• Identity/IdP: Device-code sign-ins, OAuth tokens, unknown IPs/countries/ASNs, access from different locations immediately following MFA, and device registrations or app consents.
• SaaS/Cloud: Email searches, bulk downloads, inbox rules, OneDrive/SharePoint access, and session reuse.
• Network: DHCP/DNS responses, gateway MAC/BSSIDs, VPN/DoH/DoT establishment, and WPAD proxies.

9. Attack Success Determination

10. Investigation Playbook

• Trigger: IOCs, device-code usage on public Wi-Fi, WPAD, or pre-VPN Microsoft fake pages.
• Initial Verification: Check location, SSID/BSSID, connection time, screen content, input/approval details, and VPN status.
• Endpoint: Preserve DNS cache, DHCP settings, Wi-Fi profile, PAC file, browser history, certificates, and VPN logs.
• Authentication & Cloud: Check sign-ins, device-codes, OAuth tokens, devices, app consents, and email/file audits.
• Follow-on Actions: Check inbox rules, forwarding, searches, bulk data downloads, internal sends, and additional account actions.
• Containment: Revoke sessions/refresh tokens, disable accounts, block IOCs, remove suspicious devices/consents, and change credentials.
• Classification: Wi-Fi Exposure / DNS Redirect / User Approval / Account Compromise / SaaS Data Access / Follow-on.

11. Defense and Detection Ideas

• Single Event: IOCs, device-code flow, unknown PAC files, abnormal resolution of Microsoft domains.
• Chronological Correlation: Public Wi-Fi connection -> VPN not established -> DNS anomaly/WPAD -> device-code -> successful authentication from a different IP -> SaaS operations.
• Hunting: Device-codes used during business trips, short-interval access from different countries/ASNs by the same user, device registrations, or OAuth consents.
• Log Gaps: Collect Wi-Fi/DHCP/DNS logs from endpoints early, and ensure adequate retention periods for Entra/SaaS audit logs.
• Priority Countermeasures: Always-on full-tunnel VPN with kill switch, strict encrypted DNS, disable WPAD, and block device-code flows.

12. Facts / Inference / Hypothesis

Facts

• Activity observed in hotels and other locations in the US, India, and Saudi Arabia since June 2026.
• Observed cases of returning malicious IPs for all DNS requests, WPAD attempts, and limited device-code abuse.
• No direct attribution to APT28; only TTP similarities.

Inference

• For companies with frequent travelers, email security measures alone cannot detect this initial contact.

Hypothesis

• Initial gateway access relies on a combination of public management interfaces and weak credentials. The primary source states this remains unconfirmed.

13. MITRE ATT&CK Mapping

14. Unknowns and Additional Investigation

Gateway products, initial access methods, successful WPAD examples, number of victim accounts, and stolen data. TLS handling methods, browser warnings per device, and relationship with APT28.

15. Impact on Global SOCs and Enterprises

This directly affects business travelers, conference attendees, and users of hotels, airports, and coworking spaces. Even in zero-trust environments, if pre-VPN traffic and device-code exceptions remain, defenses can be bypassed. Organizations need to enforce a policy of "do not trust public Wi-Fi" through configuration and establish a capability to correlate travel schedules with identity logs.

16. Summary by Target Audience

• For SOCs: Correlate DNS/WPAD, endpoint VPNs, Entra device-codes, and SaaS operations on a per-user basis.
• For Administrators: Prioritize always-on full-tunnel VPNs with kill switches, strict encrypted DNS, disabling WPAD, and blocking device-code flows.
• For Users: Be suspicious of Microsoft authentication or code approval screens immediately after connecting to public Wi-Fi. If the VPN is not connected, do not enter details and report the incident.