Huntress Blocks Device Code Phishing from Railway

Your users’ MFA won’t help here. A phishing campaign running on Railway infrastructure is using device code phishing to bypass multi-factor authentication entirely, and this week Huntress pushed a conditional access policy to all ITDR-protected Microsoft 365 tenants to block it.

This post covers what was deployed, how the attack works, what we did at Salt Data when we got the notification, and what you should do beyond relying on the vendor-managed policy.

What Huntress deployed

Huntress created a conditional access policy named [HUNTRESS] Block - Confirmed Adversary Infrastructure with the following configuration:

Alongside the policy, Huntress created two supporting objects in Entra ID:

• [HUNTRESS] CAP - Emergency Access Exclusion: an empty security group. Microsoft requires “block everyone” policies to have at least one exclusion group so that emergency (break-glass) accounts can still authenticate if needed. It’s empty by default, and you should add your break-glass accounts to it.
• [HUNTRESS] Confirmed Adversary Infrastructure: a Named Location containing the IP ranges, in CIDR notation, associated with this campaign’s infrastructure.

The policy is straightforward: any authentication attempt originating from the listed IP ranges gets blocked, regardless of user or resource. This cuts off the phishing campaign’s ability to use stolen tokens from its known infrastructure.

What we did at Salt Data

We received the Huntress notification and completed the following the same day:

1. Confirmed the conditional access policy is active and set to enforce (not report-only) across all managed tenants
2. Added our break-glass accounts to the [HUNTRESS] CAP - Emergency Access Exclusion group
3. Reviewed Entra ID sign-in logs for any prior device code flow activity originating from the Railway IP ranges in the Named Location
4. Found no indicators of compromise across any of our managed environments

If you’re a Salt Data client, no action is needed on your end. The blocking policy is already enforcing, and we’ve verified your tenant is clean.

What is device code phishing?

Device code authentication is a legitimate OAuth 2.0 flow designed for devices that can’t easily handle interactive login, think smart TVs, IoT sensors, or CLI tools. The device displays a short code, the user enters it on a separate browser at microsoft.com/devicelogin, authenticates normally (including MFA), and the device receives an access token.

The problem: attackers can initiate this flow from their own infrastructure and trick users into entering the code for them.

graph TD
  A["Attacker generates<br/><small>device code request</small>"] --> B["Phishing email sent<br/><small>AI-generated, personalized lure</small>"]
  B --> C["User clicks link<br/><small>Directed to microsoft.com/devicelogin</small>"]
  C --> D["User enters code + MFA<br/><small>On Microsoft's legitimate portal</small>"]
  D --> E["Microsoft issues tokens<br/><small>Access + refresh tokens</small>"]
  E --> F["Attacker captures tokens<br/><small>Full account access granted</small>"]
  F --> G["Lateral movement<br/><small>Mailbox, SharePoint, OneDrive</small>"]
  F --> H["Device registration<br/><small>Attacker registers in Entra ID</small>"]
  H --> I["Primary Refresh Token<br/><small>Persistent access to org resources</small>"]
  style A fill:#991b1b,stroke:#7f1d1d,color:#fef2f2
  style B fill:#991b1b,stroke:#7f1d1d,color:#fef2f2
  style C fill:#92400e,stroke:#78350f,color:#fef3c7
  style D fill:#92400e,stroke:#78350f,color:#fef3c7
  style E fill:#991b1b,stroke:#7f1d1d,color:#fef2f2
  style F fill:#991b1b,stroke:#7f1d1d,color:#fef2f2
  style G fill:#5b21b6,stroke:#4c1d95,color:#ede9fe
  style H fill:#5b21b6,stroke:#4c1d95,color:#ede9fe
  style I fill:#5b21b6,stroke:#4c1d95,color:#ede9fe

This is why device code phishing is so effective: the user never enters their password on a fake site. They authenticate on Microsoft’s real portal, complete real MFA, and unknowingly hand the resulting tokens to the attacker. Traditional phishing defenses that look for fake login pages or credential harvesting sites don’t catch this because there are none.

Once the attacker has a valid refresh token, the damage compounds quickly. Microsoft’s analysis of Storm-2372, a threat actor using this exact technique since 2024, documented a clear post-compromise chain: the attacker uses the refresh token to register a new device in Entra ID, obtains a Primary Refresh Token (PRT), and gains persistent access to the organization’s resources. From there, they can access mailboxes, exfiltrate data from SharePoint and OneDrive, and send internal phishing emails from the compromised account to propagate further.

Why Railway?

Railway is a legitimate platform-as-a-service provider where developers deploy applications directly from GitHub with automatic scaling and infrastructure management. It’s a real product used by real teams.

That’s precisely why attackers choose it. PaaS platforms offer several advantages for phishing infrastructure:

• Disposable environments: spin up and tear down in minutes, making takedown efforts a constant game of whack-a-mole
• Shared IP pools: traffic comes from IP ranges belonging to a legitimate cloud provider, which makes reputation-based blocking unreliable
• Low cost and low friction: no need to provision servers, manage DNS, or deal with hosting providers that might respond to abuse reports quickly

Railway is actively fighting this abuse. In February 2026, they rolled out new abuse detection heuristics across their fleet. The rollout even caused a brief incident where legitimate workloads were mistakenly flagged (affecting less than 3% of their fleet), which shows the scale of the problem they’re dealing with.

The broader pattern here is not unique to Railway. Attackers routinely abuse PaaS and serverless platforms (Heroku, Vercel, Cloudflare Workers, and others) because they inherit the trust and IP reputation of their hosting provider. Blocking by IP range, as Huntress has done here, is a valid short-term measure for confirmed adversary infrastructure, but it’s a reactive control by nature.

AI-generated phishing lures

What makes this campaign particularly effective is the use of personalized, AI-generated phishing lures. Huntress described them as designed to “evade email filtering solutions and to convince users to give up their credentials.”

This is the trend the Huntress 2026 Cyber Threat Report warned about: AI is now a productivity tool for attackers. Grammar mistakes, awkward phrasing, and generic templates used to be reliable indicators of phishing. That’s no longer the case.

In practice, these lures work because attackers feed AI models with publicly available context: employee names from LinkedIn, project details from company websites, branding from public-facing pages. The output looks like internal communication. Common formats documented by Proofpoint include:

• Shared document notifications (“Alex shared Q1-Revenue-Review.xlsx with you”)
• Meeting invitations from what appears to be a colleague or external partner
• IT helpdesk requests asking users to “re-authorize” their Microsoft account
• Salary or benefits notices referencing the target company by name

The device code itself is typically framed as a “verification code” or “one-time passcode,” often with urgency (“your session expires in 15 minutes”). Some campaigns direct users to an attacker-controlled landing page that displays the target company’s logo before redirecting to Microsoft’s legitimate devicelogin page. Combined with device code phishing (where the user ends up on Microsoft’s actual login portal), the entire attack chain looks legitimate from start to finish.

What device code phishing looks like to end users

If you’re forwarding this article to non-technical staff, this is the section that matters.

Red flags to watch for:

• An email asking you to visit microsoft.com/devicelogin and enter a code you didn’t request
• Any message framing a short alphanumeric code as a “verification code” or “security passcode”
• Urgency language like “expires in 15 minutes” or “immediate action required” around entering a code
• A request to “re-authorize” or “verify” your Microsoft 365 account that you didn’t initiate
• A login page that shows your company logo but asks you to enter a code before signing in

Why this matters for MSPs

This incident illustrates several things worth paying attention to if you manage Microsoft 365 environments for clients.

Managed ITDR earns its keep in moments like this. Huntress observed the campaign across hundreds of tenants, correlated the activity, identified the infrastructure, and pushed a blocking policy, all before most individual MSPs would have even noticed the pattern. That cross-tenant visibility and coordinated response is difficult to replicate with standalone tooling.

Understand what’s being deployed in your tenants. When your security vendor pushes policies proactively, you should review what was created and why. Check the Named Location to understand the scope of the block. Verify the exclusion group is configured correctly with your break-glass accounts. Document the policy in your tenant management records.

Device code phishing was already accelerating. The Huntress 2026 report showed OAuth abuse more than doubling year-over-year, from 4.8% to 10.1% of identity threats. Proofpoint’s research documented multiple threat actors (including state-aligned groups) adopting this technique throughout late 2025. This campaign is not an isolated event; it’s part of a clear trend.

What you should do beyond this policy

The Huntress conditional access policy blocks known adversary IPs. That’s valuable, but it only covers confirmed infrastructure for this specific campaign. Here’s what you should do to build deeper protection.

Key takeaways

• MFA alone does not stop this. If your identity security strategy assumes MFA prevents credential theft, device code phishing breaks that assumption. Users authenticate on Microsoft’s real portal, complete real MFA, and the attacker collects the resulting tokens without ever seeing a password.
• The root cause fix is blocking device code flow. IP blocking (what Huntress deployed) is a necessary stopgap for this campaign, but the real fix is disabling device code authentication entirely via conditional access. If no workload in your environment needs it, block it.
• AI-generated lures eliminate the last easy tell. Grammar and formatting are no longer useful phishing indicators. Detection must shift to behavioral signals: unexpected device code flow activity, anomalous token grants, and suspicious OAuth app registrations.
• Managed ITDR provides cross-tenant intelligence. Huntress identified this campaign across hundreds of tenants and deployed a coordinated block before most individual MSPs noticed. That cross-tenant visibility is difficult to replicate with standalone tooling.
• Share this with your users, not just your IT team. The technical controls matter, but end users are the ones entering the codes. Forward the “what to watch for” section above to anyone with a Microsoft 365 account.

What’s next

This campaign connects directly to the broader identity threat trends covered in our earlier analysis. If you haven’t reviewed those yet, they provide essential context: