DNS Poisoning Tactics Expand to Hospitality Wi-Fi

Editor’s note: This report was authored by Alexander Capraro, Jalen Vaughn, Daxton Wirth, Austin Ritchie, and Connor Short

This is external threat intelligence from the ReliaQuest Threat Research team. The findings describe threats, vulnerabilities, and attacker activity affecting third parties and the broader threat landscape—not ReliaQuest's own environment. Nothing in this report should be interpreted as a vulnerability in ReliaQuest's systems or data.

Key Points

• Adversaries have been compromising public Wi-Fi gateways at hotels, conference centers, and other shared venues to hijack the accounts of traveling corporate employees. Once they control the Wi-Fi gateway, they quietly redirect users to attacker-controlled infrastructure to steal credentials, in activity ongoing since at least June 2026.

• ReliaQuest assesses this tradecraft is similar to that of “APT28” (also known as “Fancy Bear” and “Forest Blizzard”), a Russian military intelligence group that was previously linked to similar router-based campaigns compromising Microsoft 365 accounts.

• Organizations can close the primary exposure with one control: enforce always-on, full-tunnel VPN on corporate devices. This routes all traffic—including DNS—through the corporate network before it ever reaches the hotel gateway, effectively stopping the attack.

ReliaQuest has identified a widespread campaign in which threat actors expanded DNS poisoning credential-harvesting techniques—previously observed on small office/home office (SOHO) routers in activity attributed to "APT28"—to hotel and conference center captive portal appliances. The attacks aim to quietly compromise the Microsoft 365 accounts of corporate employees without touching their devices or sending a single phishing email.

Compromised Wi-Fi gateways were identified across multiple US cities and internationally in India and Saudi Arabia, primarily in hotel and hospitality organizations, with activity ongoing since at least June 2026. We observed traffic to these compromised gateways from organizations in a range of industries, including financial services, professional services, legal, health care, energy, and retail—confirming this isn't sector-specific targeting, but a campaign that highly likely goes after traveling employees wherever they connect.

ReliaQuest assesses that this tradecraft is similar to that of APT28 (also known as “Fancy Bear” and “Forest Blizzard”), a Russian military intelligence group previously linked to an analogous campaign.

Organizations that enforce always-on, full-tunnel VPN on corporate devices are effectively protected from this technique. Full-tunnel VPN routes all traffic, including DNS, through the corporate network before it ever reaches the hotel or public gateway, stopping the attack at its source. This report details how the attack works and what else you can do to defend against it.

One Compromised Gateway, Every Guest at Risk

Compromised Devices: Hospitality Wi-Fi Gateways

The compromised devices we investigated were appliances primarily used at hotels and other organizations running captive Wi-Fi services. However, any operator of a captive portal network—such as airports, conference centers, co-working spaces, universities, health care facilities, and event venues—faces a structurally similar attack surface.

ReliaQuest assesses with low-to-medium confidence that initial access into these devices exploited exposed management interfaces (including internet-facing SSH, SNMP, and web administration consoles) in combination with weak or reused administrative credentials. We encountered visibility constraints into the individual devices that prevented confirmation of this hypothesis, but this methodology would be consistent with the gateway targeting and DNS poisoning patterns documented in recent reporting on an APT28-linked campaign known as “FrostArmada.”

The attacker modified these compromised devices' configurations and used DNS poisoning to redirect regular web traffic, funneling connections for legitimate domains through attacker-controlled infrastructure.

Four attacker-registered domains—m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com, and ms365-live[.]com—were hosted at the IP addresses 31.57.243[.]154 and 104.194.159[.]150 and used for Microsoft-impersonation lures. We assess with high confidence that these domains are operated by the same actor, based on shared registration details and their appearance within a single browsing session seconds apart in multiple instances.

What Does This Mean for My Organization?

The significance of this device class is the environment it controls. Captive portal appliances sit at the network perimeter for every guest on that network. A single device compromise gives the attacker control to redirect traffic from every guest logging into the network that day, without touching a single endpoint. Requiring all corporate devices to use an always-on VPN with full-tunnel configuration ensures all DNS requests route through trusted corporate resolvers, mitigating the attack vector.

Possible Connection to Prior APT28 Activity

The observed campaign targeting routers primarily found in hotels exhibits overlapping tradecraft with FrostArmada, a campaign disrupted in April 2026 that aimed to compromise SOHO routers by altering their DNS settings to redirect traffic to attacker-controlled servers. These servers acted as DNS resolvers, enabling the interception of authentication traffic and the theft of Microsoft logins and OAuth tokens. The activity was attributed to APT28, a group assessed to operate on behalf of Russian military intelligence. This campaign isn't currently assessed to be FrostArmada itself, but it shares enough tactics, techniques, and procedures (TTPs) to suggest tradecraft reuse at a minimum.

Overlapping Tradecraft

Overlapping tradecraft includes gateway-level DNS poisoning targeting Microsoft authentication domains; SOHO routers being compromised as an initial access vector; and adversary-in-the-middle (AiTM) Microsoft 365 account compromise. All appear in prior reporting on the FrostArmada campaign. Not directly attributing this campaign to APT28 reflects that the assessment rests on TTP overlap rather than direct technical linkage such as shared infrastructure, code reuse, or operator OPSEC failure.

Where This Campaign Diverges

Where ReliaQuest's observations differ: the targeting of captive portal appliances—especially those used in hotels and conference centers—wasn't previously documented in FrostArmada reporting. Attacker infrastructure also differed from prior FrostArmada activity. The domain registrations and IP addresses used don't align with infrastructure previously seen in APT28 campaigns. In the campaign we observed, the attackers didn't selectively redirect traffic using keywords, as seen in FrostArmada; instead, all DNS requests resolved to the malicious infrastructure—potentially an indicator of a less sophisticated or less careful actor than APT28.

Observed Attack Chain

Gateway Compromise

Administrative access to the shared gateway is all the threat actor needs. From that position, they can perform DNS poisoning on every device on the network without touching a single endpoint.

The attack begins with the threat actor gaining administrative access to an internet-facing gateway (captive portal) managed by a hotel or conference center—systems frequently used by corporate employees. Because these devices manage DNS and routing for all connected clients, admin access alone is sufficient to redirect traffic at scale.

Once that foothold is established, the attacker controls DNS resolution for every client that connects. No further action on individual devices is needed.

DNS Poisoning

A single compromised gateway lets the threat actor silently redirect users' traffic without touching their devices. Every employee who connects to that network is exposed—no phishing link, no malicious attachment, no endpoint compromise required.

This works because of a fundamental trust built into how networks function: when a device joins a network, it trusts that network's DNS resolver to give it accurate answers. DNS translates domain names like login.microsoftonline[.]com into IP addresses, and whoever controls DNS controls where traffic goes.

With administrative control of the gateway, the threat actor configures DNS response forgery. Because the gateway serves as the DHCP-assigned DNS resolver for every connecting client, queries for any domain can be silently answered with attacker-controlled IP addresses and pages. In cases ReliaQuest investigated, forged responses redirected clients to hosts serving what we assess with medium confidence to be Microsoft-impersonating pages, including owa-ms365[.]com and ms365-live[.]com.

Why Common DNS Protections Don't Stop This

This technique bypasses common DNS security controls at the endpoint level. Devices with hard-coded resolvers such as 8.8.8[.]8 (Google's public DNS server) aren't inherently protected: the request still leaves the device as unencrypted traffic that the gateway can read, forge, and redirect. Endpoint DNS-encryption tools that don't cover system services leave gaps too, since core Windows services still make ordinary, unencrypted DNS requests.

Two configurations do stop it. A full-tunnel VPN routes all DNS through the corporate tunnel before the gateway can touch the request. Encrypted DNS in strict mode (DNS over HTTPS or DNS over TLS with plaintext fallback disabled) ensures the gateway can't forge a response. Most DNS encryption tools default to opportunistic mode, which permits plaintext fallback when encrypted resolution fails. That fallback is what the gateway redirects, making opportunistic mode insufficient; only strict mode closes the gap.

Secondary Activity Observed During Investigation

WPAD: A Secondary Redirection Channel

In roughly one-third of observed cases—Windows devices that didn't have Web Proxy Auto-Discovery (WPAD) disabled, or Mac devices—the attacker also attempted WPAD abuse. If successful, it routes all Windows application traffic through the attacker's proxy, broadening the redirection surface well beyond authentication traffic. This technique wasn't documented in prior FrostArmada-linked reporting, making it one of the clearest distinctions between this campaign and previously observed APT28 activity.

WPAD is a Windows feature that automatically retrieves proxy settings when a device joins a network. Windows checks two places: first a DHCP option (option 252), then a DNS lookup for a host named "wpad." A gateway attacker controls both. In this campaign, the DNS-based WPAD lookup was observed shortly after devices connected. The technique couldn't be confirmed as successful in these cases, suggesting it's opportunistic rather than a primary redirection channel.

If WPAD succeeds, Windows retrieves a malicious proxy auto-configuration (PAC) file that routes most application traffic through the attacker's proxy: Chrome, core authentication components, and most enterprise apps that rely on Windows networking. For affected organizations, this may create exposure across any application that transits through the compromised proxy. WPAD-based proxying is easy to miss because the logs generated by the traffic can look like routine network connections over HTTPS.

Device-Code Flow Abuse: An Account-Compromise Path

In a limited number of cases, the attacker paired the DNS-poisoning redirect with abuse of Microsoft’s device-code authentication flow, creating a path to Microsoft 365 account compromise that didn't require intercepting credentials or decrypting authentication traffic. This activity was not documented in prior FrostArmada-linked reporting either.

On ms365-live[.]com, ReliaQuest directly observed this flow. From the user’s perspective, the experience may not appear overtly suspicious: they are redirected to what appears to be a Microsoft 365-related sign-in or authorization prompt without having clicked a phishing email or link. What the user can't see is that approving the prompt authorizes a session initiated by the attacker. Once approved, Microsoft issues valid OAuth tokens to the attacker-controlled client that initiated the device-code flow. As a result, the attacker can obtain MFA-satisfied access to Microsoft 365 without collecting credentials on a fake page or intercepting authentication traffic in transit.

Additionally, on July 23, 2026, ReliaQuest observed DOM content hosted under ms365-device[.]com, a domain registered by the same operator based on shared registration details. The content didn't expose the final user-facing device-code page; instead, it appeared to be an operator-facing web server administration panel used to upload and serve HTML pages, rotate pages in fixed or random modes, manage downloadable files, track visitor telemetry, and restrict page and file access through an IP allowlist. These features are consistent with lure-serving and cloaking infrastructure designed to control which visitors receive hosted content and which are filtered out.

Although ReliaQuest didn't observe the final device-code page in this DOM content, the domain’s naming convention, shared registration details, and operator-panel functionality align closely with the device-code flow abuse observed on ms365-live[.]com. ReliaQuest assesses with medium confidence that ms365-device[.]com was intended to support additional Microsoft 365 account-compromise activity using the device-code authentication flow. Its registration and active panel content suggest continued operator activity and indicate the campaign may remain active.

Step Up Your Defenses Against Gateway DNS Poisoning

ReliaQuest's Approach

ReliaQuest GreyMatter helps security teams detect and contain gateway-level DNS poisoning and credential-harvesting activity before it leads to account compromise or follow-on intrusion. Effective detection for this campaign requires coverage across multiple layers: DNS traffic, authentication traffic routing, and endpoint-level behavioral anomalies.

GreyMatter Transit: GreyMatter Transit collects, normalizes, and detects on telemetry in motion before the data is stored in downstream platforms, enabling comparison against current threat intelligence in real time. In activity like this, that means anomalous DNS responses, connections to attacker-registered domains, and authentication traffic routed to unknown hosts can be matched against known-bad infrastructure and flagged as they occur, rather than surfacing later during a retrospective SIEM query.

GreyMatter Agentic AI: Gateway DNS poisoning chains generate signals that each appear benign on their own. A DNS response returning an unexpected IP address may not stand out in isolation, and a proxied authentication prompt is routine on corporate networks. Correlated together, especially when the DNS response IP address is outside known corporate address space and the proxy host is unrecognized, they may indicate an active credential-harvesting campaign. GreyMatter Agentic AI connects these behaviors so analysts can prioritize investigation before credentials are exfiltrated or session tokens are replayed.

ReliaQuest Detection Rules: ReliaQuest detection content is continuously updated based on the latest intelligence and research. For this activity, detection coverage focuses on the anomalous domain and IP resolutions.

Organizations can reduce their mean time to contain (MTTC) threats from hours to minutes by deploying these detections alongside GreyMatter Automated Response Playbooks:

Isolate Host: Removes the affected endpoint from the network, cutting off any active WPAD-proxied sessions and preventing further credential exposure while analysts review PAC file artifacts and proxy authentication logs.

Disable User: Disables the potentially compromised account to prevent credential replay or further authenticated activity while session exposure, group membership, and authentication history are reviewed.

Terminate User Session: Terminates the session of the potentially compromised user to stop any attackers in their tracks while further investigation can be performed.

Delete Device: Removes attacker-enrolled devices from the victim's Microsoft Entra ID tenant, closing the persistent access channel that survives password resets and session terminations.

Your Action Plan

The following recommendations address the main exposure chain: preventing DNS poisoning from reaching endpoints, eliminating the attack surface, and detecting credential-harvesting activity if it occurs.

• Enforce always-on VPN with full-tunnel configuration: Require all corporate devices to use a VPN with full-tunnel configuration, ensuring all DNS requests route through trusted corporate resolvers. Audit and eliminate split-tunneling exceptions that would allow DNS or authentication traffic to bypass the VPN. Effective implementation requires the VPN to establish automatically on network connection, with controls that prevent internet access until the tunnel is active.

• Audit proxy authentication logs for authentications from unknown hosts: Look for suspicious logs from known abused infrastructure. These are high-value signals for credential-harvesting attempts via a rogue proxy.

• Disable Web Proxy Auto-Discovery (WPAD) where not required: WPAD is enabled by default on Windows. In environments that don't require automatic proxy discovery, disable WPAD via Group Policy (WinHttpAutoProxySvc) to eliminate this attack surface entirely. Where WPAD is required, restrict proxy auto-configuration (PAC) file retrieval to approved internal hosts only.

• Validate the site before entering credentials: Train employees to verify the URL and certificate of any page requesting credentials before entering them, particularly when connected to hotel, conference center, airport, or other public Wi-Fi networks.

• Disable the device code authentication flow at the identity provider: In Microsoft Entra ID, configure a Conditional Access policy that blocks the device-code flow. The device-code flow has few legitimate use cases for most users in most environments, so blocking it by default removes the authentication path these campaigns depend on.

IOCs