Railway device-code phishing

M365 device-code phishing runs a second 2026 wave from a general-purpose VPS reseller — the same playbook on infrastructure that carries enough commercial trust to buy a window

UPDATE · originally covered Two 2026 M365 account-takeover campaigns (Railway device-code phishing, LSHIY ROPC spray) beat Conditional Access without breaking MFA (2026-07-10)

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.

Microsoft 365 account-takeover tradecraft converged this week on auth flows Conditional Access rarely covers — device-code, AiTM, ROPC and manager-impersonation vishing all beat MFA without breaking it

Four separate 2026-W28 disclosures describe one problem: Microsoft 365 account takeover is increasingly achieved not by defeating multi-factor authentication but by choosing an authentication path that Conditional Access commonly fails to gate. Huntress' comparative root-cause analysis of two campaigns made the mechanism explicit — "device code phishing is effective because it doesn't try to beat MFA. It sidesteps it," and in the ROPC-based LSHIY campaign "of the 78 compromised accounts, 55 had active Conditional Access policies requiring MFA" that still failed, because legacy/ROPC authentication through the /token endpoint never reaches the authorization endpoint where CA is enforced (Huntress, 2026-07-10). The same week, ZeroBEC documented Forg365, a Telegram-distributed adversary-in-the-middle phishing-as-a-service kit purpose-built to relay M365 auth and steal session cookies (ZeroBEC, 2026-07-10), and ReliaQuest profiled the Helix data-extortion cluster pairing manager-impersonation vishing with device-code phishing before SharePoint exfiltration (ReliaQuest, 2026-07-10). Read together with the week's ShinyHunters/Odido vishing attribution, the through-line is a maturing, commoditised identity-attack economy targeting the same tenant surface.

Why this is a cross-day pattern, not four items: device-code phishing, AiTM cookie theft, ROPC spraying and impersonation vishing are distinct techniques, but they exploit the same structural gap — a Conditional Access posture that assumes MFA coverage it does not actually enforce across every flow, client-app type and cloud app. A tenant that hardened against one of these this week is not hardened against the others.

Builds on: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · 2026-07-10/forg365-m365-phaas-aitm-devicecode-forgcookie · 2026-07-10/helix-data-extortion-devicecode-vishing-sharepoint-exfil

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.