Device Code Phishing Keeps Evolving. Here’s What to Watch For

What it is

A Huntress threat report on a 2026 device code phishing campaign against Microsoft 365 abusing VPS reseller BL Networks (BitLaunch/BLNWX, AS399629, active since ~2017). It follows an earlier Railway-hosted wave attributed to the EvilTokens phishing-as-a-service kit, and is possibly Kali365-aligned. The report's real contribution beyond a list of IOCs is a detection philosophy and a concrete internal threshold for classifying infrastructure as hostile.

How it works

Device code phishing evades classic detection because the victim authenticates through Microsoft's own legitimate sign-in flow — MFA can still complete, and no password is directly phished. The attacker then operates or replays the resulting Microsoft 365 tokens. Because logins arrive from a provider (BL Networks) that also sells legitimate hosting, downstream commercial controls that lean on infrastructure/ASN reputation don't flag the traffic, giving attackers a window to extract value.

What to do

The page's actionable core is a set of behavioral questions to ask instead of waiting for a named-campaign or "pristine attribution" match:

• 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?

The report also gives a usable internal threshold: Huntress classified BL Networks as adversary infrastructure on the basis that the disproportionate volume of device code logins alone was sufficient — not prior threat-report coverage. Beyond the IOCs already in the summary, the scale figures anchor what "disproportionate" looked like: 533 events tied to 216.203.20[.]95 between April 13–30, including 113 successful logins in a 48-hour window (April 20–21), and 26 critical-severity incidents across 23 identities between July 3–27.

flowchart TD
    A[M365 sign-in from unexpected infra] --> B{Device code flow?}
    B -- no --> Z[Lower priority]
    B -- yes --> C{Repeated / across many identities?}
    C -- no --> Z
    C -- yes --> D{Infra makes business sense for user?}
    D -- yes --> Z
    D -- no --> E[Treat as adversary infra<br/>don't wait for attribution]

Caveats

• The page states activity had "started to decrease" as of July but was ongoing — the specific IPs are point-in-time and BL Networks also hosts legitimate customers, so ASN/IP blocking risks false positives.
• The Kali365 link is hedged ("potentially"); attribution is explicitly the thing the report argues not to wait on.
• The fetched text is truncated mid-sentence at the final recommendation, so any concluding guidance after "waiting for pristine attribution can be" is not captured.