Two 2026 M365 account-takeover campaigns (Railway device-code phishing, LSHIY ROPC spray) beat Conditional Access without breaking MFA
Huntress compared two structurally different but strategically identical 2026 Microsoft 365 account-takeover campaigns, both of which got through tenants whose Conditional Access (CA) policies required MFA — because each used an authentication path CA typically does not inspect (Huntress, 2026-07-09). The "Railway" campaign (March 2026) abused Microsoft's OAuth device-code flow: attackers generate a legitimate device-authorization code, embed it in a lure, and collect the resulting OAuth token (valid up to 90 days) when the victim enters the code at the real Microsoft endpoint — the victim may complete MFA, but the token is already gone, so the flow sidesteps MFA rather than defeating it (T1528). The operation ran from clean Railway.com PaaS IP ranges with trusted reputation (three IPs accounted for ~84% of traffic), used construction-RFP lure themes and in some chains triple-wrapped URLs through Cisco, Trend Micro and Microsoft SafeLinks in sequence, and reached 344 organisations across the US, Canada, Australia, New Zealand and Germany before Huntress published; it was attributed to a commercial phishing-as-a-service operation Huntress tracks as EvilTokens — a subscription platform with a storefront, a support team and AI-assisted lure generation (Huntress, 2026-07-09).
The "LSHIY" campaign (active mid-June 2026) took the opposite approach: no phishing, just 81M+ login attempts from an IPv6 range against Azure CLI using the deprecated Resource Owner Password Credentials (ROPC) OAuth flow, which posts credentials straight to the /token endpoint and never touches the authorization endpoint where most CA policies are enforced (T1110.003, T1078.004, The Hacker News, 2026-07-01). It compromised at least 78 accounts across 64 organisations; the finding that matters for defenders is that 55 of those had active CA policies requiring MFA that failed for predictable scoping reasons (T1556.006): MFA scoped to specific apps such as Admin Portals but not "All Cloud Apps", so Azure CLI slipped through; MFA scoped to specific user groups that omitted the compromised accounts; MFA required only from "untrusted" locations, bypassed by an attacker IP that geolocated inconsistently to the US; and two policies left in report-only mode. Huntress notes one tenant had a CA policy explicitly named "Block Azure CLI" that did not, in fact, block Azure CLI.
Device code phishing is effective because it doesn't try to beat MFA. It sidesteps it.
Of the 78 compromised accounts, 55 had active Conditional Access policies requiring MFA.
One glaring error here is that legacy protocols like ROPC can bypass some poorly-configured CAPs entirely since they don't go through the authorization endpoint where policies are enforced.
Defender actions
- Block the OAuth device-authorization (device-code) flow tenant-wide via Conditional Access, or restrict it to the named accounts that genuinely need it — this neutralises device-code phishing regardless of lure quality, because the token is never minted.
- Re-scope every MFA-requiring CA policy to 'All cloud apps' and 'All client app types' (including legacy/other clients), not a per-app or per-group allow-list — an omitted app such as Azure CLI is exactly what ROPC spray rides through.
- Enable client-level strong-auth enforcement (userStrongAuthClientAuthNRequired) to block ROPC flows from succeeding even with valid credentials, and audit for CA policies set to report-only that were never enforced.
- Hunt sign-in logs for successful ROPC/legacy-auth authentications to Azure resource apps with no corresponding interactive MFA challenge, and for device-code completion events not tied to a genuine input-constrained device.
ATT&CK mapping
4 techniques mapped from the cited reporting · MITRE ATT&CK v19.2
Initial Access TA0001
T1078.004Valid Accounts: Cloud Accounts
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Persistence TA0003
T1078.004Valid Accounts: Cloud Accounts
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
T1556.006Modify Authentication Process: Multi-Factor Authentication
Adversaries may disable or modify multi-factor authentication (MFA) mechanisms to enable persistent access to compromised accounts.
Privilege Escalation TA0004
T1078.004Valid Accounts: Cloud Accounts
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Stealth TA0005
T1078.004Valid Accounts: Cloud Accounts
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Defense Impairment TA0112
T1556.006Modify Authentication Process: Multi-Factor Authentication
Adversaries may disable or modify multi-factor authentication (MFA) mechanisms to enable persistent access to compromised accounts.
Credential Access TA0006
T1110.003Brute Force: Password Spraying
Adversaries may use a single or small list of commonly used passwords against many different accounts to attempt to acquire valid account credentials. Password spraying uses one password (e.g. 'Password01'), or a small list of commonly used passwords, that may match the complexity policy of the domain. Logins are attempted with that password against many different accounts on a network to avoid account lockouts that would normally occur when brute forcing a single account with many passwords.
T1528Steal Application Access Token
Adversaries can steal application access tokens as a means of acquiring credentials to access remote systems and resources.
T1556.006Modify Authentication Process: Multi-Factor Authentication
Adversaries may disable or modify multi-factor authentication (MFA) mechanisms to enable persistent access to compromised accounts.
Update chain
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.