Insights

Two trends have converged this year to produce the most effective route into a Microsoft 365 tenant that we currently see. The first is device code phishing, an attack that takes a live session without ever touching a password. The second is the industrialisation of residential proxy networks, which allows an attacker sitting anywhere in the world to appear in your sign-in logs as an ordinary home broadband user in your own country.

Neither technique is new in isolation. What has changed is how quickly the tooling is being built and how cheaply it can be rented.

What we are seeing

Between November 2025 and July 2026 our CSOC raised 54 cases involving device code authentication activity across our customer base. The monthly figures tell the story better than the total. One case in November. One in December. Three in January. Fifteen in July alone.

Within that broader set, a smaller group of incidents involved residential, ISP or mobile proxies in the initial access. Those are the ones worth examining closely, because they are the cases where the usual signals go quiet.

The attack that does not need a password

Device code sign-in is a genuine Microsoft feature. It exists for devices with no practical way to type a password, such as smart TVs, meeting room displays and command line tools. The device shows a short code, the user enters that code on a normal computer, signs in, and the device is granted access.

Attackers have simply turned the flow around. The victim receives something that looks like a shared document. They click through, are given a code, and land on a real Microsoft sign-in page at microsoft.com/devicelogin. This is made more convincing by the fact that you can append anything you like to that URL, without changing the functionality such as microsoft.com/devicelogin?Thisisthelinkyouarelookingfor. They sign in with their real password, complete MFA properly, and enter the code. The page then tells them the document has expired.

From the user’s point of view, nothing went wrong. No password was typed into a fake page and MFA was satisfied genuinely. But the code they approved authorised the attacker’s session rather than their own. Huntress documented a case where the entire sequence took 42 seconds.

This is the part that catches organisations out. Because no credential was stolen, a password reset achieves nothing. The attacker holds a refresh token, and that has to be revoked explicitly. In some campaigns the stolen session is used within minutes to register a new device and mint a Primary Refresh Token, turning one careless click into weeks of durable access.

Vibe-coded kits and a crowded market

The reason this technique has moved from a niche red team trick to something we now see weekly is that it has been packaged and sold.

Kali365 is the clearest example. First observed in April 2026 and the subject of an FBI IC3 advisory in May, it is a subscription phishing-as-a-service platform sold through Telegram, with dozens of built-in lures, token management, AI-generated business email compromise content and a companion desktop application that turns a stolen token into a live browser session inside the victim’s mailbox. Huntress, who reverse engineered it, describe the panel as vibe-coded. It has also appeared under the names Octopi365 and Freedom365, and has since expanded beyond Microsoft 365 to target AWS, Okta and other identity platforms.

Kali365 is not an outlier, it is a template. Forg365 surfaced in July, sold via Telegram with a five day free trial and then $400 a month or $3,800 a year, offering AI-assisted lure generation, adversary-in-the-middle routing, bot evasion, token vaulting and a browser extension for persistent single sign-on access. Researchers have documented Jalisco, OmegaLord, EvilTokens, Venom and CYB3R appearing over the same period, and long-established kits including Sneaky 2FA and Greatness have bolted device code support onto their existing panels.

The common factor is that AI-assisted development has collapsed the cost of entering this market. Building a credible phishing platform used to require a developer. It now requires a prompt and a Telegram channel. That is why the names keep changing, why the panels look increasingly alike, and why the volume keeps climbing. It also lowers the skill floor for the buyer, because the operator workflow is now a dashboard rather than a toolchain.

Where the traffic comes from

Stealing the session is only half of it. The attacker still has to use it, and that is where residential proxies come in.

A residential proxy service rents out access to real consumer internet connections. Instead of connecting from a datacentre or a commercial VPN, which any competent detection stack will flag, the attacker routes their traffic through somebody’s home broadband line or mobile connection. A sign-in from another continent then arrives in your logs looking like a domestic connection from a normal consumer ISP. The better services match the exit node to the victim’s own country in real time, which is enough to keep impossible travel, atypical travel and country-based Conditional Access policies quiet.

Our own cases show exactly that, and the geography is the point. UK customers were attacked through major UK consumer broadband providers, including one network that serves student and residential accommodation. An Australian customer was attacked through an Australian ISP. A US organisation was attacked through a US business ISP. In every case the sign-in arrived from the same country as the victim, on the kind of connection nobody blocks and no risk engine flags.

The uncomfortable part is where those connections come from. Many of the people whose lines are being used have no idea they are involved. On 2 July the FBI, Google’s Threat Intelligence Group, IRS Criminal Investigation, Lumen and Shadowserver disrupted NetNut, one of the largest such networks, seizing hundreds of domains. Google, which tracks the underlying botnet as Popa, links it to around two million consumer devices, largely Android-based smart TVs and streaming boxes infected through trojanised applications, and reported 316 distinct threat clusters using the network in a single week. NetNut’s operator, the publicly listed Israeli firm Alarum Technologies, disputes the allegations and has said it will cooperate fully with law enforcement to ensure any misuse of its infrastructure is investigated.

It is also worth being realistic about the effect of takedowns. NetNut followed the disruption of IPIDEA in January, and Google’s own assessment is that when one network degrades, operators buy capacity from competitors and become resellers. The pool shrinks, it does not disappear. This is displacement, not eradication, and defenders should plan accordingly.

Why this is hard to detect, and what we look at instead

Most identity detection rests on the source of a sign-in looking wrong. Remove that signal and a great deal of standard tooling goes quiet. Our approach is to stop asking where the sign-in came from and start asking what is unusual about everything around it.

Device context is the strongest single signal. A user who works exclusively from a managed, compliant laptop suddenly authenticating to Office 365 from an unmanaged Windows device is worth acting on regardless of how ordinary the IP address looks. Sequencing matters too. A connection to a suspicious domain followed shortly afterwards by a risky sign-in on the same account is a pattern that neither event produces on its own. We run custom detections that correlate business email compromise indicators, particularly mailbox rule creation, device registration and new MFA method registration, against anomalous sign-ins in the same window, because those changes immediately after an unusual authentication are the clearest tell that a session is in the wrong hands.

We also hunt the URL and domain patterns these kits use directly against email telemetry, which lets us find the lure rather than the consequence. That requires Microsoft Defender for Office 365 Plan 2, since the email log tables involved are only available at that licence level. It is one of the more concrete examples of licensing determining what a SOC can actually see for you.
There is often a second opportunity as well. In one of our cases the initial token theft came through a residential line, and the attacker then returned over a commercial VPN. The theft blended in. The return did not.

In two of the proxy-based incidents we handled, our custom detection content was the only thing that fired. No Microsoft detection surfaced the activity at all. In others our content fired alongside Microsoft’s, which is the outcome we want. The reason these detections can drive automated containment within minutes of a sign-in is confidence: when the indicators in the logs are strong enough on their own, the source IP stops mattering, and you can act rather than investigate.

Two things the data shows that are easy to miss

The first is that lures increasingly arrive from people you trust. In one incident the phishing email came from a genuinely compromised mailbox at a business partner. Sender reputation, domain authentication and user suspicion of unfamiliar senders were all irrelevant, because the message was real and the sender was known. These kits ship with lateral phishing tooling for exactly this reason, and it works.

The second is that targeting persists. One organisation accounted for six of our device code cases between April and July, three of them on the same day. Once a domain is on a list it stays on that list, and the lures keep arriving. Treating each of those as an isolated event, rather than as sustained pressure on one organisation, is how the seventh one gets through.

What to change now

Block device code authentication. Microsoft classifies it as a high-risk authentication method, and its own guidance is to get as close to a full block as your environment allows. Disable it in Conditional Access and add exclusions only where there is a documented need. For most organisations this removes the technique outright.

Require compliant or managed devices. A stolen session is far less useful if it can only be used from a device you control. Mobile Application Management covers phones and tablets where full device management is not practical.

Block unknown platforms. If your people only work from Windows, macOS, iOS and Android, restrict sign-ins to those platforms and close the gap.

Fix the response playbook. Make explicit token and session revocation the first step in account compromise response, not a password reset. Review who is able to register new MFA methods, and make sure mailbox rule changes are monitored and alerted on.

Sources

• Huntress, analysis of the Kali365 / Octopi365 device code phishing ecosystem, June 2026.
• FBI IC3 public service announcement naming Kali365, 21 May 2026.
• ZeroBEC research on Forg365, covered by The Hacker News, CSO Online and Computerworld, July 2026.
• Krebs on Security, SecurityWeek, Infosecurity Magazine and BankInfoSecurity coverage of the FBI, Google, IRS CI, Lumen and Shadowserver disruption of NetNut, 2 July 2026.
• Google Threat Intelligence Group statement on the NetNut and Popa disruption, July 2026.
• Microsoft Security Blog, AI-enabled device code phishing campaign analysis, April 2026.
• Microsoft Learn, Conditional Access guidance on blocking authentication flows.
• Chorus CSOC case data, November 2025 to July 2026.