📄 Reading this online? Get this brief as a formatted Word document — delivered to your inbox, free.

Hotel Wi-Fi, Device Codes and a Valid Token: How Attackers Are Passing Your MFA Check

Week of 3 August 2026 | Compiled by Team Paringa


Three incidents in ten days show the same pattern from different angles: the authentication succeeded, the second factor was satisfied, and the attacker walked away with a valid session anyway.


SECTION 1 - What Happened This Week

🔴 DNS hijacking on hotel Wi-Fi turns the device-code flow into an MFA bypass

ReliaQuest disclosed on 24 July that attackers have been altering DNS settings on Wi-Fi gateway devices at hotels and conference centres, redirecting users to fake Microsoft 365 login portals. The campaign has been running since at least June. Compromised gateways were identified across multiple US cities as well as India and Saudi Arabia, and observed traffic came from financial services, professional services, legal, healthcare, energy and retail organisations. This is not sector targeting. It is targeting travelling employees wherever they connect, which for most UK and EU enterprises means their executive population and their deal teams.

The attackers registered at least four domains for the fake portals: m365-owa.com, owa-ms365.com, ms365-device.com and ms365-live.com. In some cases the victim was pushed into a device-code authentication flow, shown a legitimate-looking Microsoft prompt, and asked to approve it. ReliaQuest's description of what happens next deserves repeating precisely: "What the user can't see is that approving the prompt authorizes a session initiated by the attacker." A legitimate OAuth token is then issued to the attacker's client.

Read that mechanism carefully, because it defeats the usual reassurance. There is no credential to intercept. There is no token to steal in transit. Microsoft issues a valid token to the attacker because the user approved a genuine Microsoft flow. ReliaQuest states plainly that this "bypasses the multi-factor authentication (MFA) protection without stealing any credentials or intercepting access tokens." The researchers also note that pointing your device at a public resolver such as 8.8.8.8 does not help, because the gateway forges the plain-text request before it ever reaches the intended resolver. In roughly a third of cases the attackers also abused Web Proxy Auto-Discovery to serve a malicious proxy configuration file.

ReliaQuest assesses this activity as similar to the FrostArmada router-based campaigns attributed to the Russian espionage group APT28. Their recommended mitigations are always-on full-tunnel VPN, encrypted DNS in strict mode, disabling WPAD, and disabling the device-code authentication flow in Microsoft Entra ID where it is not needed.

Sources: BleepingComputer

Disable the device-code flow in Entra Conditional Access this week unless you have a documented business case for it. That is a same-day change with a real risk reduction, and most enterprises we assess have it enabled purely because it is on by default. Then look at the structural point underneath. Every control in this chain assumes a credential or a token exists somewhere that can be issued, approved or replayed. The attacker did not break the cryptography, they got the legitimate system to hand them a valid artefact. An authentication model that issues no reusable credential at all removes the object being stolen, which is a different class of answer from making the credential harder to phish. Worth putting on the agenda for your next identity roadmap review, because the current direction of travel is producing better credentials, not fewer.


🟡 An Exchange zero-day that steals OAuth tokens and survives your password reset

On 29 July, Proofpoint published research on the Russian state group Laundry Bear, also tracked as Void Blizzard, exploiting CVE-2026-42897 in Microsoft Exchange Outlook Web Access. The flaw is a cross-site scripting issue in message body sanitisation, triggered simply by opening the email. Proofpoint calls it a "half-click exploit." Targets included government bodies in the US and Europe plus telecommunications, financial services, hospitality and aerospace organisations.

The identity implications are the story. The OWAReaper payload searches for Outlook add-ins holding ReadWriteMailbox permissions and uses them to steal OAuth tokens through the GetClientAccessToken operation. It then calls UpdateFolder to grant Owner-level permissions on every mail folder to the "Default" alias, a low-permission preset that exists in every Microsoft Exchange tenant. Any authenticated account in the organisation can then read that mailbox.

Because mailbox permissions are configured server side, Proofpoint confirms that changing the compromised user's credentials or reinstalling their machine does not revoke the attacker's access. The malware also creates invisible DOM elements and waits for the browser to autofill credentials into them.

Sources: BleepingComputer

Identity teams measure themselves on time-to-revoke. This intrusion makes that metric meaningless, because the thing granting access is no longer the credential. Two actions. First, add OAuth token revocation at tenant scope and mailbox permission enumeration to your account-compromise playbook, alongside the password reset that is currently the whole playbook in most organisations. Second, get an inventory of Outlook add-ins with ReadWriteMailbox scope across your estate. In our experience nobody owns that list, and it is a standing grant of mailbox access sitting outside every identity governance review you run.


🟡 Passkeys become the Entra default in September, and attackers are already enrolling their own

Microsoft confirmed on 13 July that passkeys become the default authentication method in Entra ID from September 2026. Users on SMS and voice will be auto-enabled for passkeys and prompted to register one at their next MFA challenge. Microsoft-provided telecom delivery for SMS and voice retires entirely on 1 February 2027. Microsoft's own justification is worth quoting: its Threat Intelligence team has observed AI-enabled phishing campaigns reaching click-through rates as high as 54%, against roughly 12% for traditional campaigns.

Moving enterprises off SMS is the right call and long overdue. The problem is what attackers are already doing to the enrolment step. Okta disclosed on 8 July that an actor it tracks as O-UNC-066, operating the extortion brand Pink, has been running a vishing campaign since April that calls employees and talks them through enrolling a "new Entra passkey for security reasons." Victims are directed to a phishing kit that mirrors the real Entra enrolment portal, complete with the victim organisation's branding. The passkey being registered belongs to the attacker.

Notably, this is not an adversary-in-the-middle proxy. Okta describes an operator-controlled PHP panel with one-second heartbeat polling, letting a human attacker adapt the flow in real time to whichever MFA method the victim uses, TOTP, push with number matching, or SMS OTP. Credentials and MFA responses are relayed to the operator, who authenticates to the real Microsoft account while the victim watches a fake enrolment screen and copies out a fake BIP-39 recovery phrase that has no role in genuine Entra passkey enrolment at all. Pink has been targeting food and beverage, technology, healthcare, automotive, construction and aviation, and moves quickly to exfiltrate from SharePoint and OneDrive. Its leak site launched on 31 May.

Sources: BleepingComputer - Entra passkey default | BleepingComputer - Pink vishing

A phishing-resistant credential is only as strong as the process that binds it to a human. Microsoft is about to prompt your entire user base to enrol a passkey, and an active extortion crew has spent four months practising exactly that conversation. Before September, do two things: publish an internal statement that IT will never phone a user to walk them through passkey enrolment, and put a verified-identity gate on enrolment itself rather than relying on the user's judgement mid-call. Longer term, note where the attacks have moved. Nobody is attacking FIDO2 cryptography. They are attacking enrolment, recovery, helpdesk and consent, because that is where a reusable credential gets created and re-created. Architectures that never issue a credential in the first place do not have an enrolment ceremony to hijack.


SECTION 2 - What Identity and IAM Leaders Are Dealing With

The uncomfortable pattern across all three stories is that the authentication event succeeded. Nothing failed. The hotel Wi-Fi victims completed a genuine Microsoft flow. The Pink victims satisfied their number-matching push. The OWA victims never saw a login page at all. In each case the attacker ended up holding something the platform considered valid: an OAuth token, a registered passkey, or a server-side permission grant. Detection built around failed logins and impossible travel does not fire on any of this.

The tooling is following the attackers, not leading them. ReliaQuest reported separately on 14 July on two new kits targeting Microsoft 365, Jalisco and OmegaLord. Jalisco generates fresh Microsoft OAuth device codes in real time when a victim opens the phishing page, specifically to defeat the 15-minute code validity window Microsoft introduced to fight device-code phishing. ReliaQuest has seen attackers register five rogue devices on a single compromised account, using names containing "Microsoft" or "Windows" to blend in, and observed exfiltration from SharePoint in as little as six minutes. Their mitigation advice includes cutting the Entra device-registration limit from its default of 50 down to one or two, and restricting the OAuth Device Authorization grant in Okta. That is a telling list: the recommended fixes are all about constraining how many credentials and tokens the platform is willing to mint, which is an admission of where the real exposure sits.


Three Things Worth Watching Next Week

1. September Entra passkey rollout preparation - Expect a wave of enrolment-themed phishing and vishing in the four to six weeks before the default switches on. Get user comms out ahead of the attackers, not after.

2. Device-code flow restrictions becoming standard baseline - Two separate ReliaQuest reports in July recommended disabling it. Expect this to appear in insurer questionnaires and audit checklists before the end of Q3.

3. Whether anyone attributes the hotel Wi-Fi campaign formally - ReliaQuest sees similarity to APT28's FrostArmada activity but has not confirmed initial access to the gateways. Formal attribution would change the risk calculus for executive travel policy considerably.


Questions? hello@paringa.ai


Paringa works with specialist partners on the parts of identity most enterprises have not solved: what happens after the login succeeds. We focus on infrastructure, AI security, cost and governance, and we bring the right partner to the problem rather than the same one every time. | 3 August 2026 | © Paringa Ltd