Most of the phishing campaigns we cover here start with an email. This one does not, and that is exactly why it belongs in this newsletter. Threat intelligence firm ReliaQuest published a Threat Spotlight this month tracing a campaign that compromises the Wi-Fi gateways used by hotels and conference centers, then poisons DNS responses so guests trying to reach Microsoft 365 land on a fake login page instead. No inbox is ever touched.
How the Gateway Gets Turned Against Its Own Guests
The campaign has been running since at least June 2026, and ReliaQuest has identified compromised gateways in multiple US cities as well as in India and Saudi Arabia. The attackers get in through internet-facing management interfaces, SSH, SNMP, or a web admin panel, protected by nothing stronger than a weak or reused password. Once inside, they do not need to touch a single guest device. They just change the DNS settings on the gateway itself.
From that point on, every device that joins the network and asks “where is Microsoft 365” gets a forged answer. Instead of the real Microsoft IP, the poisoned gateway hands back an attacker-controlled address, one of at least four lookalike domains ReliaQuest identified: m365-owa.com, owa-ms365.com, ms365-device.com, and ms365-live.com, hosted on infrastructure at 31.57.243.154 and 104.194.159.150. A traveling employee opens their laptop, connects to what looks like the hotel’s normal Wi-Fi, and types their Microsoft 365 credentials into a page that looks completely legitimate because, as far as their browser’s address resolution is concerned, it is the address they asked for.
A Second Variant Skips the Password Entirely
In some observed cases, the fake page does not even bother asking for a password. It instead kicks off a device-code authentication flow, showing the target a prompt to approve a sign-in that the attacker has already initiated. Approve it, and the attacker walks away with a fully authorized session, no credential theft required and no password to later reset. ReliaQuest assesses this tradecraft resembles router-based campaigns previously attributed to the Russian military intelligence group tracked as APT28, Fancy Bear, or Forest Blizzard, though attribution for this specific campaign remains an assessment rather than a confirmed link.
Traffic to the malicious infrastructure has come from organizations across finance, healthcare, legal services, energy, retail, and professional services, which tells you this is not an industry-specific operation. It is an opportunistic one, aimed at whoever happens to be traveling and connects to the wrong hotel network that week.
Why DMARC Never Gets a Vote
DMARC verifies that a message claiming to be from your domain actually came from a server you authorized. It is one of the best tools available for stopping domain spoofing in email. This campaign simply does not send email. There is no message to authenticate, no From header to check, no SPF or DKIM signature to validate, because the entire attack chain runs at the network layer before a victim ever opens a mail client. The phishing page a target lands on is served because their device asked a poisoned resolver where Microsoft 365 lives, not because someone tricked them into clicking a link in their inbox.
This is worth sitting with, because it is a clean illustration of a point we make often in this newsletter: DMARC protects the channel where your organization sends and receives mail. It has no jurisdiction over the DNS resolver a hotel Wi-Fi gateway hands your laptop, and no attacker running this style of campaign needs to spoof your domain, or anyone’s domain, to succeed.
What This Means for Your Program
Treat public Wi-Fi as hostile by default, including hotel and conference networks your team trusts out of habit. An always-on, full-tunnel VPN closes the primary path this campaign relies on, because it routes DNS resolution through infrastructure you control rather than whatever the local gateway hands back. A padlock icon in the browser bar or a manually configured public DNS server is not proof the route getting you there was safe.
Train employees to be suspicious of a Microsoft 365 sign-in prompt that appears unexpectedly on hotel or conference Wi-Fi, especially a device-code approval screen. A device-code flow that the user did not initiate themselves, on a device they were not expecting to authenticate, is a red flag regardless of how legitimate the surrounding page looks.
Push DNS-over-HTTPS or DNS-over-TLS on managed devices so DNS queries cannot be silently rewritten by whatever network the device happens to join, hotel gateway or otherwise.
Remember that this gap sits entirely outside what DMARC, SPF, and DKIM can see. Those protocols remain essential for locking down the mail channel that attackers can forge in your name. They were never designed to, and cannot, secure the network path between a traveling employee’s laptop and the internet.
The Takeaway
A phishing campaign that never sends a phishing email is still a phishing campaign, and this one shows how far attackers will go to avoid the parts of your defense that actually work. Keep DMARC enforced at reject on every domain you own. Just do not mistake that enforcement for coverage of every way an employee’s credentials can end up in someone else’s hands.
Excello Mail helps you lock down DMARC, SPF, and DKIM enforcement on the domains you control, so the mail channel attackers can actually forge is closed while your team stays alert to the threats that route around email entirely. Sign up for free to Excello Mail and get full visibility into who is sending as your domain.