CTIPilot
AI-generated · no human review · verify critical claims against the linked source. how it works →

Railway device-code phishing

campaign · campaign:railway-device-code-phishing-m365-2026

March 2026 device-code phishing campaign against 344 organisations that harvested Microsoft 365 OAuth tokens via the device-authorization flow, run from clean Railway.com PaaS IPs and attributed by Huntress to the EvilTokens phishing-as-a-service operation (Huntress, 2026-07-09).

Coverage
1
first 2026-07-10 → last 2026-08-01
Latest activity
2026-08-01
Huntress: device-code phishing and ROPC token-spray defeat M365 tenants by routing around the auth paths…
Peak priority
high
1 high
Targets
public-sector
sectors: public-sector, finance, healthcare
Sources cited
4
2 hosts

Action items (4)

Do-now tasks recorded on the entries about Railway device-code phishing, newest first. Check the date before acting on an older one.

Defender insights

What each entry about Railway device-code phishing tells a defender to do, newest first.

2026-07-10HIGHHuntress: device-code phishing and ROPC token-spray defeat M365 tenants by routing around the auth paths Conditional Access actually inspects

Latest update · triage

Story timeline

  1. 2026-07-10Two 2026 M365 account-takeover campaigns (Railway device-code phishing, LSHIY ROPC spray) beat Conditional Access without breaking MFA
    researchHuntress: device-code phishing and ROPC token-spray defeat M365 tenants by routing around the auth paths Conditional Access actually inspects

Hunting pivots

Affected products
Azure CLIMicrosoft 365Microsoft Entra ID
Tags
ai-abusecloudidentityphishing
ATT&CK techniques (6 across 7 tactics)

6 techniques observed across 1 entry about this entity, derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.2 · compare on the matrix · Navigator layer (JSON)

  • Initial AccessValid Accounts: Cloud Accounts · Phishing: Spearphishing Link
  • PersistenceValid Accounts: Cloud Accounts · Modify Authentication Process: Multi-Factor Authentication
  • Privilege EscalationValid Accounts: Cloud Accounts
  • StealthValid Accounts: Cloud Accounts
  • Defense ImpairmentModify Authentication Process: Multi-Factor Authentication
  • Credential AccessBrute Force: Password Spraying · Steal Application Access Token · Modify Authentication Process: Multi-Factor Authentication
  • Lateral MovementUse Alternate Authentication Material: Application Access Token

Initial Access TA0001

T1078.004Valid Accounts: Cloud Accounts×1

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.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

T1566.002Phishing: Spearphishing Link×1

Adversaries may send spearphishing emails with a malicious link in an attempt to gain access to victim systems. Spearphishing with a link is a specific variant of spearphishing. It is different from other forms of spearphishing in that it employs the use of links to download malware contained in email, instead of attaching malicious files to the email itself, to avoid defenses that may inspect email attachments. Spearphishing may also involve social engineering techniques, such as posing as a trusted source.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

Persistence TA0003

T1078.004Valid Accounts: Cloud Accounts×1

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.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

T1556.006Modify Authentication Process: Multi-Factor Authentication×1

Adversaries may disable or modify multi-factor authentication (MFA) mechanisms to enable persistent access to compromised accounts.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

Privilege Escalation TA0004

T1078.004Valid Accounts: Cloud Accounts×1

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.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

Stealth TA0005

T1078.004Valid Accounts: Cloud Accounts×1

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.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

Defense Impairment TA0112

T1556.006Modify Authentication Process: Multi-Factor Authentication×1

Adversaries may disable or modify multi-factor authentication (MFA) mechanisms to enable persistent access to compromised accounts.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

Credential Access TA0006

T1110.003Brute Force: Password Spraying×1

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.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

T1528Steal Application Access Token×1

Adversaries can steal application access tokens as a means of acquiring credentials to access remote systems and resources.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

T1556.006Modify Authentication Process: Multi-Factor Authentication×1

Adversaries may disable or modify multi-factor authentication (MFA) mechanisms to enable persistent access to compromised accounts.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

Lateral Movement TA0008

T1550.001Use Alternate Authentication Material: Application Access Token×1

Adversaries may use stolen application access tokens to bypass the typical authentication process and access restricted accounts, information, or services on remote systems. These tokens are typically stolen from users or services and used in lieu of login credentials.

Evidence: 2026-07-10/m365-conditional-access-gaps-railway-lshiy-campaigns · ATT&CK page ↗

Entries about Railway device-code phishing (1)

2026-07-10 · view entry permalink →

HIGHupdatedNATOB2

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.

Huntress 2026-07-09

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.

The Hacker News 2026-07-01

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.

Huntress 2026-07-09
Updaterun 2026-08-01T0409Z-intelevidencesourcestechniquesbody

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.

research10 Jul 04:36Zmulti-sourceOpen finding →
Sources: Huntress · The Hacker News

Co-occurring entities

Derived: referenced by the same focused operational entries (weekly summaries and report roundups don't count); ×N counts the shared entries.

Where this entity is cited

  • Research1

Source distribution

  • huntress.com3 (75%)
  • thehackernews.com1 (25%)
All cited sources (4)