Acknowledgments: Special thanks to Rich Mozeleski for his contributions to this investigation and writeup.
Huntress has seen a notable influx in device code phishing attacks in 2026. Earlier this year, we reported a massive wave of device code phishing attacks that stemmed from Railway, a platform-as-a-service built for vibe coding. Starting in April, we also saw attacks from IP addresses linked to a virtual private server (VPS) reseller called BL Networks.
Huntress started seeing suspicious Microsoft 365 authentication activity linked to BL Networks on April 13, 2026, which continues as of this writing. At the beginning of April, we saw all incidents linking back to one offending IP address (216.203.20[.]95).
In May, the infrastructure utilized spread from one specific IP to several across a few different subnets: we saw device code phishing attacks originating from BL Networks and spanning several IPs, including 193.149.176[.]151, 193.149.176[.]238, and 45.61.136[.]129.
As of July, activity has started to decrease, but we still very much see BL Networks in use: between July 3 and July 27, we saw 26 critical-severity incidents linked to BL Networks spanning 23 identities.
This is similar to the wave of device code phishing attacks we observed earlier this year that were linked to Railway, which we attributed to the EvilTokens phishing-as-a-service (PhaaS) platform. While that activity has since tapered off, this second surge in activity linked to BL Networks later in the year shows that the story didn't end with the first wave of coverage around device code phishing infrastructure - and it won't end here either.
What is BL Networks?
BL Networks (also known as BitLaunch or BLNWX) has been active since at least 2017, operating under ASN AS399629, according to Bushido Token Threat Intel. VPS resellers offer Linux or Windows VPS for purchase. A VPS can be used for legitimate hosting use cases (such as by small hosting companies serving local businesses), but customers can also use it to host illegal activity, such as spam campaigns, botnets, phishing sites, or malware distribution.
We first came across malicious authentication activity from BL Networks in April. Between April 13 through April 30, Huntress identified 533 events tied back to BL Networks specifically from 216.203.20[.]95, with 113 successful logins originating from BL Networks in a 48-hour window between April 20 and April 21.
The EvilTokens-linked device code phishing surge that we saw earlier this year was spun out through the completely legitimate Railway infrastructure. BL Networks is a bit different because it also provides standard hosting. However, cybersecurity researchers have frequently flagged its IP addresses because bad actors have used its servers for malicious campaigns as well.
Why this looks familiar
BL Networks poses the same core defender problem seen in the earlier EvilTokens kit; attackers are abusing legitimate-looking infrastructure to replay or operate stolen Microsoft 365 tokens without tripping the kinds of controls many teams expect to save them.
Device code phishing is already difficult to detect because it doesn't look like old-school credential theft. The user is sent to a legitimate Microsoft sign-in flow. MFA may still happen. No password has to be phished directly. From the defender's perspective, what often stands out is not the phishing page itself but the surrounding context: where the sign-in comes from, what app or flow was used, whether the identity and infrastructure pairing makes sense, and whether the activity aligns with normal user behavior.
That is exactly why infrastructure like BL Networks deserves scrutiny. If the authentication succeeds and the infrastructure does not automatically look hostile to downstream controls, attackers can keep extracting value from the workflow even after public attention moves on.
The BL Networks Campaign tells us three things
First, threat actors aren't done iterating on device code phishing. The existence of earlier reporting and prior detections has not caused this activity class to disappear. If anything, the emergence of IP addresses from BL Networks suggests the ecosystem is adapting and reusing what works.
Second, 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.
Third, defenders need to stop thinking of these campaigns as isolated brand names. 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: legitimate cloud services, legitimate Microsoft authentication pages, disposable lure infrastructure, and token-centric post-compromise tradecraft.
Defenders should pay attention to the behavior, not just the logo on the infrastructure
If there is a silver lining here, it is that this kind of activity creates patterns. Huntress teams were able to identify BL Networks as sufficiently suspicious to discuss classification as adversary infrastructure, with the team explicitly stating that the disproportionate device code logins were enough to make that call. That is the kind of threshold defenders should think about internally as well.
The question should not be "Have we seen this exact provider in a threat report before?" Ask the following instead:
Are we seeing repeated successful sign-ins from infrastructure that makes no business sense for the user?
Are those sign-ins clustered around device code flows?
Are they appearing across multiple organizations, users, or identities in ways that look operational rather than accidental?
Are we seeing the same surrounding behaviors that appeared in earlier token replay campaigns?
If the answer is yes, waiting for pristine attribution can become a luxury. When the evidence is strong enough, defenders should bias toward containment and signal generation.
What you can do now
Organizations worried about this trend should focus on practical identity-layer defenses:
Review device code authentication use in your environment and restrict it where it is not required.
Monitor for successful sign-ins tied to unusual or newly suspicious infrastructure, especially when paired with device code activity.
Investigate clusters of successful
UserLoggedInevents from the same autonomous system or hosting provider, even when those logins do not initially look "high risk."Revoke sessions and tokens quickly when suspicious device code abuse is identified.
Assume MFA alone is not enough when the attacker is abusing a legitimate Microsoft flow rather than stealing a password.
The bigger lesson here is not that one provider is bad forever. Adversaries have learned how to turn trusted platforms into force multipliers. They can rotate lures, hosting, redirect chains, and post-compromise workflows faster than many security teams can update assumptions.
Final thoughts
Beyond blocking obviously malicious links or catching fake login pages, defenders can thwart phishing attacks by recognizing when real services, real authentication flows, and real cloud infrastructure are being stitched together into an attack chain that leads to compromise.
And that, more than any single campaign name, is why BL Networks is worth watching.
Want the bigger picture? Download the full report for a deeper breakdown of the Railway and BL Networks playbooks, how these device code phishing attacks unfold, and what defenders should do next.
