Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure

Acknowledgments: Special thanks to Casey Smith, Tanner Filip, Matt Kiely, and Aaron Deal for their contributions to this investigation and write-up.

TL;DR: Huntress is monitoring an active device code phishing campaign targeting Microsoft 365 identities across more than 340 organizations in the US, Canada, Australia, New Zealand, and Germany. The first case appeared on February 19, followed by two more on February 24. Then, on March 2, it exploded, and over the past few weeks, it has continued to accelerate with no signs of slowing down, impacting organizations of all types and sizes, from law firms to construction companies.

In our initial analysis of this campaign, we've seen no identical phishing lures or initial domains. While there was some thematic reuse, the variance in lures is unprecedented. Each message was tailored enough to avoid exact duplication. Given this, we believe the campaign is leveraging automation or AI to operate at scale. Because each lure is personalized to its victim while avoiding exact replication, the phishing emails evade email filtering solutions with alarming efficacy. 

We also believe attackers are weaponizing Railway, a Platform-as-a-Service (PaaS) built for vibe coding, to spin up on-demand credential-harvesting infrastructure at machine speed. Railway's prompt-based deployment and troubleshooting features make it trivial to stand up and tear down internet-facing services with minimal friction. While we didn't directly observe threat actors using Railway's AI features in this campaign, we built a prototype to confirm how easily that workflow could accelerate phishing infrastructure deployment and turnover, even at the free tier. Railway effectively hands adversaries a cloud-hosted token harvesting engine that is clean to Microsoft's risk scoring, and whoever is behind this campaign is weaponizing it to full effect.

What also makes this campaign unusual is not just the device code phishing techniques involved, but the variety of techniques observed. Construction bid lures, landing page code generation, DocuSign impersonation, voicemail notifications, and abuse of Microsoft Forms pages are all hitting the same victim pool through the same Railway.com IP infrastructure. The diversity of techniques and lure types raises a question that doesn't have a clean answer: is this one threat actor with an unusually broad toolset, or multiple actors sharing the same backend?

Introduction

On March 2, 2026, the Huntress Security Operations Center (SOC)  surfaced a concerning pattern: a wave of anomalous authentication events across dozens of organizations simultaneously. The pattern was unmistakable: Device code phishing. This technique exploits the OAuth device authorization flow to grant the attacker persistent access tokens, which remain valid even after a password reset. These attempts originated from a narrow block of IP addresses belonging to Railway.com, a PaaS cloud hosting provider most security teams have never had a reason to block.

What followed was a multi-day investigation that revealed a technically sophisticated, operationally mature campaign targeting victims from various business sectors.

This post documents parts of the attack chain, the technical mechanisms behind the credential and token theft, how Railway is being abused as a token replay engine, and what Huntress has done and what companies and their clients can do right now.

Background

What is device code phishing?

OAuth device code phishing exploits a legitimate Microsoft authentication flow designed for input-constrained devices such as smart TVs, printers, and terminals. In normal use, a user visits microsoft.com/devicelogin, enters an 8-character code, and authorizes a device. Attackers weaponize this by generating device codes themselves, then tricking users into entering those codes via phishing lures. When the victim enters the code and approves the authentication prompt, the attacker's backend immediately receives a set of valid OAuth tokens—no password required, no MFA to defeat. The set of tokens includes an access token, which is good for immediate resource access, and a refresh token, which is valid for up to 90 days.

This technique is documented in Huntress' own research on OAuth device code phishing in Azure and Google Cloud, and covered extensively by threat analysts at ANY.RUN.

What is Railway.com?

Railway is a developer-friendly PaaS provider similar to Heroku or Render. Push a container or a GitHub repository, get a public HTTPS endpoint with automatic TLS, scaling, and outbound internet access. Sign-up requires only an email address. Railway's egress IP ranges—162.220.232.0/22 and 162.220.234.0/22—are clean, legitimate cloud provider space. Microsoft Identity Protection has no reason to score logins from these IPs as risky. That is the point.

Railway also reflects a broader shift towards modern cloud platforms, increasingly reducing infrastructure work from simple vibe coding, allowing adversaries to create infrastructure in a fraction of the time with prompts, templates, and a few clicks. In Railway’s case, prompt-based deployment and troubleshooting make it easy to build, test, and expose services quickly. We want to be precise here: Huntress did not directly observe the threat actor using AI-assisted deployment inside Railway during this campaign. What we did observe was abuse of Railway-hosted infrastructure. Separately, when we logged into the platform and built a test deployment to better understand how these authentication attempts may have been exiting Railway, it became clear how little effort would be required to spin infrastructure up or down at scale. That matters because even when AI isn’t visible in the telemetry, platforms that compress setup and operational overhead still help adversaries move faster.

Attack chain overview 

The Railway infrastructure: A token harvesting factory

All authentication abuse observed in our telemetry originates from a narrow block of Railway.com IPs. Three IPs account for roughly 84% of observed events—consistent with a small number of deployed Railway applications, not a botnet.

The phishing infrastructure: A separate ecosystem

Upstream of the Railway token-harvesting engine sits a phishing delivery infrastructure that tells its own story. Based on shared intelligence and analyst observations, several technical signatures appear consistently across this campaign.

Abuse of email security vendor URL rewriters

The most significant delivery bypass: the attacker wraps malicious URLs inside legitimate security vendor redirect services. The email arrives with a Cisco, Trend Micro, or Mimecast URL in the body so that the visible link is a trusted vendor domain, not the malicious destination:

• Cisco Secure Email (secure-web.cisco.com): 5+ instances as first-hop wrapper

• Trend Micro URL Protection (cas5-0-urlprotect.trendmicro.com):  first hop in multiple chains

• Mimecast URL Protection (url.us.m.mimecastprotect.com): wraps an intermediate redirect

One observed chain was triple-wrapped: SafeLinks → Trend Micro → Cisco Secure Web → final phishing page. The victim's email security stack sees a Cisco or Trend Micro link and passes it. The attacker is not defeating email security; they're using competitors' deployed infrastructure to launder their links and bypass spam filters.

Multi-hop redirect chains (2–5 hops)

The "known-good platforms" in the middle of these chains are compromised websites. These are real businesses whose CMS was vulnerable and injected with redirect pages. These sites carry legitimate domain reputation, making URL inspection at any single hop uninformative. We will discuss the lure using customervoice.microsoft.com a bit later.

Observed tactic: Device code phishing with landing page codes

Most device code phishing we’ve observed in the past used email as a pretext. This campaign is notably different. The observed landing sites prompt the victim to proceed to the legitimate Microsoft device code authentication endpoint and input a provided code in order to read some files. The code is rendered directly on the page when the victim arrives. This is an interesting iteration of the tactic, as, normally, the adversary must produce and then provide the code to the victim. By rendering the code directly on the page, likely by some code generation automation, the victim is immediately provided with the code and pretext for the attack.

The page prompts the user with a “Continue to Microsoft” button, which spawns a pop-up window. In this case, the pop-up is rendering the legitimate Microsoft authentication endpoint. Pop-up windows in the context of phishing often can mean the adversary is using browser-in-the-browser to manipulate the pop-up window’s URL. In this case, the pop-up was confirmed to be the legitimate Microsoft endpoint, which rules out browser-in-the-browser.

Figure 1: Device Code Phishing used as a tactic

Device code phishing is notably different than an adversary-in-the-middle attack because the adversary is not truly “in the middle.” Rather, they are using the legitimate Microsoft device code authentication feature and prompting the user to authenticate under circumstances that the adversary controls. Multi-factor authentication is not an effective mitigation for this attack because the victim inputs the code, then their username and password, and then MFA code if applicable. The resulting authentication generates a token that the attacker can retrieve, thus negating the protection of MFA.

The lure diversity: One campaign or many?

The phishing lure topics observed represent a striking range. Construction RFP lures dominate and the victim list includes 24 construction and trades organizations, suggesting deliberate sector targeting or simple effectiveness in that audience.

Observed tactic: Effective phishing lures

Abuse of Microsoft Dynamics 365 “Customer Voice” feature

One of the phishing lures started with the use of a “Customer Voice” form, as mentioned earlier. These forms are a feature of Microsoft Dynamics 365 intended to collect customer feedback. These were identified by their URL beginning with customervoice.microsoft[.]com/Pages/ResponsePage.aspx?id= followed by the unique identifier of the form. The form presented a SharePoint branded landing page:

Figure 2: Example of a Microsoft Dynamics 365 phishing lure leading to SharePoint

Sophisticated “File Download” pages

From the above, the “Access SharePoint” link led to a convincing file download website hosted on vercel[.]app. Other examples of this were seen hosted on amplifyapp[.]com. This style lure requires the user to check at least one file and click “View Selected” to proceed. 

Figure 3: Example of a file download lure

Clicking “View Selected” brings the user to the device code phishing page, as shown in Figure 3. 

Abuse of Cloudflare’s workers.dev platform

Nearly every device code phishing site was observed to be hosted on a Cloudflare workers.dev instance. This platform allows developers to run serverless apps on the Cloudflare platform. This allows the threat actors to bypass DNS and web content filtering as Cloudflare is a trusted platform globally. The workers.dev domains are ephemeral and systematically generated based on the user creating the instance. They appear in this format:

[lure-type]-[3char-id].[username]-[domain]-s-account.workers.dev/[tracking-hash]

• [lure-type] typically contained the values “adobe”, “docusign”, “index”, “onedrive”, “page”, or “voicemail”

• [3char-id] is a seemingly random alphanumeric value

• [username]-[domain] represents a normalized e-mail address where user@domain.com would become user-domain-com

• [tracking-hash] varied in format between [16 character hex] value, a 32 character hex].[64 character hex]&ab=1, and ?email=(value)

Huntress has reported all of the currently observed workers.dev instances to Cloudflare, and most, if not all, have already been taken down. 

Abuse of third-party services and compromised websites

In an effort to evade e-mail security tools that may rely on URL or domain reputation, the threat actors utilized a variety of third-party services and compromised websites of various organizations. In many cases, the victims were clicking through two or three layers to get to the final stage of the attack. Examples of services seen used in the attacks:

• wixsite[.].com - web hosting and creation platform for phishing lure site

• www.taskade[.]com - AI app building platform for phishing lure site

• app.usewhale[.]io - AI capable document creation platform for phishing lure site

• r.brandreward[.]com - link tracking/redirection used to hide true link destination

• 2nco[.[com - URL shortening service used to hide true link destination

• track.tec35[.]com - link tracking/redirection used to hide true link destination

• www.hits2babi[.]com - link tracking/redirection used to hide true link destination

• appspot[.]com - Google’s App Engine for phishing lure site

• amplifyapp[.]com - AWS Amplify for phishing lure site

• vercel[.]app - Vercel for phishing lure site

• amazonaws[.]com - AWS S3 for phishing lure site

In addition to the abuse of known commercially available tools there was a high amount of compromised organization’s websites that were hosting one of the hops in the attack chain. The malicious page was typically hosted off of the main website in a folder with a very generic name like /project/ or /voip/. Others were hosted from a .html file out of the root of the domain.

User agent analysis: The attacker's digital wardrobe

The user agent (UA) strings presented during Railway-sourced authentication events reveal a deliberately curated set of UAs that mimic realistic enterprise browser populations. The replay engine rotates through them to avoid uniform UA detection rules.

• The attacker researched their target demographic. The OS build strings (OS/10.0.26200 = Win11 24H2, OS/10.0.26100 = Win11 23H2, OS/10.0.22631 = Win11 22H2) reflect actual current Windows versioning, not outdated or synthetic values. This is deliberate research, not default tooling behavior.

• The iPhone UA is a detection opportunity. iPhone OS 18_7 paired with Version/26.3 Note Version/26. iOS 26 is a future version that does not exist in early 2026. A detection rule keying on iPhone OS 18 + Version/26 from cloud provider IP ranges would have high fidelity with very low false positives.

• BAV2ROPC is programmatic and scheduled, not human. The twice-daily scheduling visible in events (11:00 AM and 8:00 PM) confirms this is an automated script, not a human operator. This is the "set it and forget it" persistence mechanism for high-value targets.

• Linux Chrome may be indicative of server OS leaking. X11; Linux x86_64 in 15 events may represent API-level token exchanges where the Railway container did not bother to set a spoofed UA and the actual runtime environment is visible.

Scale and victim profile

Sectors targeted

The Huntress response

When Huntress sees threat actors using new tradecraft that is working at scale, we move. To mitigate the threat for our partners, Huntress pushed out a Conditional Access Policy (CAP) to all eligible tenants (i.e., tenants with Microsoft Entra ID P1 and Security Defaults disabled) to prevent logins from all Railway-owned infrastructure, as well as to disrupt the adversary’s access path at the source. This was accomplished by creating a Named Location containing the IPs associated with Railway. We validated that no legitimate activity had been seen from Railway-owned infrastructure in the prior 14 days across our customer base and did our best to ensure negative impact would effectively be zero. This wasn’t a casual call, and it wasn’t made in a vacuum. It went through internal review across our SOC, product, leadership, and customer-facing teams, with careful consideration for both security and operational impact. 

What’s interesting is not that we caught an attacker typing prompts into Railway in real time—we didn’t. It’s that the same product features designed to help legitimate builders move faster can also help adversaries industrialize phishing infrastructure. When a platform makes deployment, troubleshooting, and teardown fast and low-friction, it shrinks the gap between an idea and a live attack service. That’s the real concern: AI-assisted and prompt-driven workflows don’t need to appear explicitly in the logs to still change the speed, scale, and economics of abuse.

When attackers are actively exploiting a fast-moving campaign like this, it stops being a normal change-management discussion and becomes an emergency response decision. Our duty is to protect customers, even when that means acting quickly and decisively against novel tradecraft. When customer environments are at risk, we will continue to take the necessary action to stop active threats. 

What we’re hearing (thoughts from the community)

Before publishing this blog, we shared high-level details about the campaign and protective measures on Reddit. The conversation that followed provided some great feedback, and we want to address two key concerns directly.

Some customers noted they would have appreciated notification or the option to opt-in before this change. That's fair feedback, and it's something we're taking seriously. During an active campaign with credentials being harvested in real time, waiting means leaving customers exposed. In this case, we prioritized stopping the threat immediately. Going forward, we're working on ways to give customers more visibility into these decisions while maintaining our ability to act quickly when threats are actively targeting our customer base.

Customers adhering to CMMC also raised important questions about how this action aligns with compliance requirements. Huntress conducts ongoing consultations with CMMC experts, who've verified that this action is covered under incident response as an SPA.

Response recommendations

Immediate actions

• Hunt for Railway IP logins. Run the Sentinel queries above against your sign-in logs. Any successful authentication is a confirmed compromise.

• Revoke all refresh tokens for affected users. Revoke-AzureADUserAllRefreshTokens or Entra ID portal. This, however, does NOT immediately revoke in-flight OAuth access tokens as those expire in ~1 hour unless CAE is enabled.

• Block Railway CIDR blocks via Conditional Access Named Locations. If no legitimate Railway-deployed applications exist in your environment.

Medium-term hardening

• Block Device Code Authentication Flows in your Microsoft 365 environment using Conditional Access. Restrict Device Code flow to only the specific identities that need this method.

• Require a compliant device for Exchange Online / SharePoint. Device code authentication cannot proceed if the device is not compliant when compliant devices are required.

• Enable Continuous Access Evaluation (CAE). Reduces token revocation latency from ~1 hour to minutes.

• Train end users on device code lures specifically. Educate users that inputting device codes, even into the legitimate Microsoft authentication endpoint, is not necessarily safe.

Conclusion

Railway.com has lowered the infrastructure cost and operational complexity of device code phishing campaigns at scale. A service that lets an attacker deploy a containerized identity attack framework in minutes- with clean IP reputation, automatic TLS, and no identity verification-  is a material force multiplier for any threat actor interested in scoring a business email compromise payday.

The diversity of techniques and lure types in this campaign, whether one actor with a broad toolkit or multiple actors sharing common infrastructure, points to the same practical challenge for defenders. You cannot block this campaign by domain. You cannot block it by lure type. You can block it by IP range, and you can detect it in authentication telemetry. The attack is visible at the identity layer even when it is invisible at every other layer.

If your Microsoft 365 tenants are not covered by an identity detection and response platform with cross-tenant visibility, this campaign illustrates exactly what you're missing.

Detection queries

Microsoft Sentinel — Railway login hunt (interactive):

SigninLogs

| where IPAddress startswith "162.220.234." or IPAddress startswith "162.220.232."

| where ResultType == 0

| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress,

          AuthenticationRequirement, ConditionalAccessStatus

| order by TimeGenerated desc

Hunt for BAV2ROPC programmatic token access from Railway:

AADNonInteractiveUserSignInLogs

| where IPAddress startswith "162.220.232." or IPAddress startswith "162.220.234."

| where UserAgent contains "BAV2ROPC"

| project TimeGenerated, UserPrincipalName, ResourceDisplayName, IPAddress

Indicators of Compromise (IOCs)

All IOCs are defanged. Remove brackets before use in blocking rules.

CIDR blocks for perimeter blocking:

• 162.220.232[.]0/22

• 162.220.234[.]0/22

• 152.55.176.0/20

• 208.77.244.0/22

• 66.33.22.0/23

• 69.46.46.0/24

• 69.9.164.0/22

• 2607:99c0::/32

Behavioral authentication IOCs