2026-07-10 · view entry permalink →
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.
Infrastructure reputation is holding too much weight in many defense stacks. When a login originates from a provider or autonomous system that is generally trusted across commercial controls, attackers get a window to operate. That window may be short, but in token abuse operations, short is often long enough.
Between July 3 and July 27, we saw 26 critical-severity incidents linked to BL Networks spanning 23 identities.
Assume MFA alone is not enough when the attacker is abusing a legitimate Microsoft flow rather than stealing a password.
The device-code phishing wave covered earlier as a Railway-hosted campaign is not a single episode that tapered off. Huntress reports a second, parallel 2026 wave on entirely different infrastructure, and the delta that matters is what kind of infrastructure it is.
Huntress states it "started seeing suspicious Microsoft 365 authentication activity linked to BL Networks on April 13, 2026, which continues as of this writing", initially from a single address, spreading across several subnets in May, and continuing into July: "between July 3 and July 27, we saw 26 critical-severity incidents linked to BL Networks spanning 23 identities" (Huntress, 2026-07-31). For the April window it records 533 events tied to one address, including 113 successful logins in a 48-hour span between 20 and 21 April (Huntress, 2026-07-31). Huntress describes BL Networks as a VPS reseller "active since at least 2017, operating under ASN AS399629, according to Bushido Token Threat Intel" (Huntress, 2026-07-31).
The distinction from the earlier wave is the delta. The Railway campaign, which Huntress attributes to the EvilTokens phishing-as-a-service platform, ran on a platform-as-a-service product; BL Networks "is a bit different because it also provides standard hosting", with legitimate small-hosting customers alongside the abuse (Huntress, 2026-07-31). Huntress is careful not to overstate the blind spot; it notes that "cybersecurity researchers have frequently flagged its IP addresses because bad actors have used its servers for malicious campaigns as well", and closes that "the bigger lesson here is not that one provider is bad forever" (Huntress, 2026-07-31). The narrower and more useful claim is about weighting: "infrastructure reputation is holding too much weight in many defense stacks. When a login originates from a provider or autonomous system that is generally trusted across commercial controls, attackers get a window to operate. That window may be short, but in token abuse operations, short is often long enough" (Huntress, 2026-07-31). Huntress's broader argument is that defenders should stop tracking these as branded campaigns at all; "whether a campaign is discussed internally as Railway, EvilTokens, or potentially Kali365-aligned, the more durable lesson is that this is now an attack pattern" (Huntress, 2026-07-31).
Triage: a successful sign-in from a commodity hosting provider is not by itself an incident, remote workers use VPNs, and small suppliers legitimately host services there. The discriminating combination Huntress sets out is three-part and needs all three: the sign-in succeeded, it is tied to the device-code flow rather than an ordinary interactive or browser-based authentication, and the hosting provider makes no business sense for that particular user's normal working pattern. The strongest variant is cross-tenant, the same autonomous system appearing behind successful sign-ins for multiple unrelated identities or organisations in a short window, which reads as operational rather than coincidental. Because the flow itself is a genuine Microsoft authentication path and MFA may legitimately have been satisfied, neither the presence of MFA nor a clean risk score is evidence against the finding.