Home Blog Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure Last Updated: March 23, 2026 Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure By: Dave Kleinatland Jamie Levy Rich Mozeleski Erin Meyers Acknowledgments: Special thanks to Casey Smith, Tanner Filip, Matt Kiely, and Aaron Deal for their contributions to this investigation and write-up. UPDATE: March 23, 2026 In partnership with our friends at Flare.io and other contacts across the community, Huntress has attributed the Railway attack to the EvilTokens Phishing as a Service (PhaaS) platform. First advertised on the NOIRLEGACY GROUP telegram channel, EvilTokens spun up its own Telegram channels and made a first public post on February 16th, 2026. This activity corresponds with the first handful of compromises Huntress saw from Railway infrastructure on February 19th and 24th, 2026. Figure 1a: First public EvilTokens messages EvilTokens provides three “products” for its users: a “B2B Sender”, an “Office 365 Capture Link”, and a “SMTP Sender”. Both the B2B Sender and Capture Link boast powerful features including AI workflows that help in bypassing email filtering, tailoring phishing lures, and finding sensitive emails for wire fraud or data exfiltration activities. The EvilTokens dashboard also provides customers with Open Redirect links to vulnerable domains, through which CloudFlare workers from the “Office 365 Capture Link” and “Sender” products can steal additional credentials from new victims. Figure 2a shows the EvilTokens product store, along with their pricing. Figure 2a: EvilTokens product store Figures 3a and 4a show more details about the Capture Link and B2B sender, respectively: Figure 3a: EvilTokens Capture Link Functionality Figure 4a: EvilTokens BSB Sender Functionality Figure 5a: EvilTokens dashboard with custom branding options for phishing lures The EvilTokens dashboard also allows for easy branding and customization options, as seen in figures 5a and 6a. Figure 6a: EvilTokens dashboard with available vulnerable URLs for initial phishing link obfuscation Figure 7a: EvilTokens product update with announcement of integrated AI tooling In addition to rapid growth in tool functionality, the EvilToken team has spun up a full 24/7 support team and a support feedback channel, as seen in Figure 8a. They also have customer feedback, as seen in Figure 9a. Figure 8a: EvilTokens support team announcement Figure 9a: Positive community feedback for the EvilTokens platform Huntress continues to block authentication from Railway infrastructure to Huntress-protected identities and as of 1200 PM EST on Monday, March 23rd, 2026 had blocked 113 attempted compromises in addition to the ~350 compromises reported over the past two weeks. ------------------- Original post: March 20 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. IP Address Event Count Primary Use 162.220.234[.]41 254 Dominant token attack engine 162.220.234[.]66 132 Secondary token attack engine 162.220.232[.]57 97 Third-highest volume 162.220.232[.]99 38 Source of SAML authentication 162.220.232[.]235 15 SAML + OAuth token activity 162.220.232[.]55 162.220.232[.]223 162.220.232[.]230 ~8 Persistent OAuth (one organization) Active as of Mar 19 162.220.234[.]32 162.220.234[.].34 162.220.234[.].161 ~7 Persistent OAuth (one organization) Active Mar 6–11 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: