Railway. LSHIY. Different Auth Flows, but the Same Lesson We Keep Skipping

What Happened

Attackers found two ways to break into Microsoft 365 accounts without needing to steal passwords or defeat multi-factor authentication (MFA) directly. In the first campaign, they tricked users into entering a code on Microsoft's real login page, which gave the attackers a valid login token lasting up to 90 days. In the second, they used an older, rarely-blocked login method that let them submit usernames and passwords directly, bypassing MFA prompts entirely. Over 400 organizations were affected across multiple countries. Many victims believed they were protected because they had MFA turned on, but their security settings had gaps the attackers found and exploited. Organizations should review their Microsoft 365 security policies to ensure all login methods—including older ones—are covered by MFA, and that policies apply to all users and all applications, not just a subset.

Key Takeaways

• Device code phishing sidesteps MFA entirely by abusing Microsoft's OAuth device authorization grant flow, yielding tokens valid up to 90 days regardless of MFA completion
• ROPC (Resource Owner Password Credentials) flow bypasses most Conditional Access MFA policies because it targets the /token endpoint directly and is often excluded from Azure CLI coverage
• 55 of 78 LSHIY-compromised accounts had active MFA Conditional Access policies that failed to protect them due to scoping gaps, report-only mode, or mislabeled trusted locations
• EvilTokens operates as a commercial Phishing-as-a-Service platform with AI-assisted lure generation, storefront, and 24/7 support, industrializing device code phishing
• Over 50% of Huntress-recommended identity controls were missing in 60% of 12,000+ tenants reviewed during Managed ISPM early access

Affected Systems

• Microsoft 365 / Entra ID tenants
• Azure CLI (used as ROPC authentication client)
• Microsoft OAuth 2.0 Device Authorization Grant flow
• Organizations with Conditional Access policies scoped to specific apps, user groups, or locations rather than All Cloud Apps / All Users

Vulnerabilities (CVEs)

None identified.

Attack Chain

1. Initial Access (Railway): Phishing emails with construction RFP themes delivered triple-wrapped URLs through Cisco, Trend Micro, and Microsoft SafeLinks to evade email filtering
2. Authentication Abuse (Railway): Victims directed to Microsoft's legitimate deviceauth endpoint and tricked into entering a device code (e.g., EZ84KREMH), completing MFA which validates the attacker's OAuth token request
3. Token Harvesting (Railway): Attackers collect valid OAuth tokens lasting up to 90 days via Railway.com PaaS infrastructure with clean IP reputation, evading Microsoft Identity Protection risk scoring
4. Initial Access (LSHIY): Attackers obtain validated credentials and replay them at massive scale (81 million attempts) using ROPC flow against Azure CLI /token endpoint
5. Token Minting (LSHIY): ROPC flow mints fresh user tokens without triggering MFA prompts because Conditional Access policies omit Azure CLI or legacy auth client types
6. Persistence/Access: Both campaigns yield valid OAuth tokens granting full account access without passwords or malware, exploitable for up to 90 days

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No

The article does not provide specific detection rules or queries. It references Huntress Managed ITDR for detection of active compromises and Managed ISPM for posture management, but no rule content is included.

Detection Engineering Assessment

Required Log Sources

• Azure AD / Entra ID sign-in logs (interactive and non-interactive)
• Conditional Access policy evaluation logs
• Microsoft 365 audit logs
• Azure AD Identity Protection risk logs
• Exchange Online mail flow logs (for phishing email detection)

Hunting Hypotheses

Control Gaps

• Conditional Access policies scoped to specific apps (e.g., Admin Portals) rather than 'All Cloud Apps' allow ROPC and Azure CLI traffic to bypass MFA
• Conditional Access policies scoped to specific user groups leave accounts outside those groups unprotected
• MFA policies conditioned on trusted locations can be bypassed when attacker IPs are mislabeled or geographically close
• Conditional Access policies in report-only mode provide zero enforcement despite appearing configured
• Microsoft Identity Protection does not inherently flag logins from legitimate PaaS platforms like Railway.com as risky
• Email filtering stacks may pass triple-wrapped URLs that chain through trusted domains (Cisco, Trend Micro, Microsoft SafeLinks)

Key Behavioral Indicators

• Successful sign-ins using device code flow from cloud hosting/PaaS IP ranges
• Non-interactive sign-ins via Azure CLI using ROPC grant type
• High-volume authentication attempts from single IPv6 ranges (e.g., 81 million attempts indicating credential spray)
• Conditional Access policies named to block specific clients (e.g., 'Block Azure CLI') that do not actually match the intended client app
• OAuth tokens with 90-day refresh token lifetimes originating from device code flow authentication
• Phishing emails with construction RFP themes containing triple-wrapped redirect URLs

False Positive Assessment

Recommendations

Immediate Mitigation

Infrastructure Hardening

• Consider deploying Conditional Access policies with All Users / All Cloud Apps / All Client App Types scope to eliminate scoping gaps that attackers can predict and exploit.
• If supported by your licensing tier, consider enabling Microsoft Identity Protection risk policies to flag anomalous sign-in locations and impossible travel events.
• Consider implementing a periodic Conditional Access policy drift review process to detect when policies have been modified or excluded from their intended scope.
• Evaluate whether your email filtering stack can detect and block triple-wrapped URLs that chain through trusted redirector domains (Cisco, Trend Micro, Microsoft SafeLinks).
• Consider reviewing and restricting which users or groups are permitted to use the device code authentication flow if a full block is not feasible.

User Protection

• Consider deploying Microsoft Authenticator with number-matching or passwordless authentication to reduce the effectiveness of device code phishing lures.
• If applicable, consider enabling system-preferred MFA to ensure users authenticate through the strongest available method.
• Consider educating users on the device code phishing technique, specifically warning them not to enter authentication codes received via email or chat into Microsoft's deviceauth page unless they initiated the request from a known device.
• Consider restricting non-admin users from consenting to third-party applications in the tenant to reduce the OAuth token attack surface.

Security Awareness

• Consider incorporating device code phishing awareness into existing security training programs, emphasizing that legitimate Microsoft login pages can be abused if the user did not initiate the authentication request.
• Consider training IT staff on the distinction between MFA being 'enabled' versus 'enforced for all authentication paths,' as this was the core gap exploited in the LSHIY campaign.
• Consider adding construction RFP-themed phishing lures to existing phishing simulation campaigns, as this theme was specifically observed at scale in the Railway campaign.
• If your organization has a change management process for identity policies, consider documenting the risk of report-only mode policies being mistaken for enforced controls.

MITRE ATT&CK Mapping