M365 Device Code Phishing - One Click Chain

The content described in this article draws on our Github repository, which you can reach here: https://github.com/redinpulse/RinP-Kodes-M365-Stealer

A 3% Click Rate, a 100% Impact

Cybersecurity is one of the areas that attracts the heaviest technology investment. Yet however large the allocated budget and the scale of the solutions being developed, the weakest link does not change: the human factor.

However widely we roll out awareness work, and however closely we track annual “clicked the link” and “filled in the form” rates through charts built on routine social engineering tests, the same problem persists: we cannot close the gap between the improvement in those percentages and the security risk a single employee’s mistake can create.

Setting up the arithmetic plainly does not change the picture either:

The real question these curves, encouraging as they look in annual reports, do not answer is this: what happens after that click - or, in the case this article focuses on, after the code has been entered?

Which doors can a single mistake by a single employee open for the entire organization? This is exactly where the real risk equation is set up. Traditional simulation metrics, meanwhile, were not designed to measure the size of that impact.

For precisely this reason, the attack surface employees create on internet-facing third-party services needs to be monitored and mapped continuously. When such a map is drawn, serious risks do not merely become visible; they can be prioritized and managed in an integrated way alongside existing security solutions.

In this article we describe how the user-centered attack surface in the Microsoft 365 ecosystem is mapped, and how the Kodes M365 Red Team platform we have developed at Red in Pulse manages this scenario end to end.

Because today every user in your organization is an attack surface in their own right.

In the M365 World There Is No “Link” - There Is “Code”

Most corporate awareness training is built on a single reflex: “do not click a link you do not recognize.”

In a Microsoft 365-focused attack scenario, however, the attacker does not need that reflex. OAuth 2.0 Device Authorization Grant, otherwise known as the device code flow (RFC 8628), is a legitimate authentication standard developed for printers, smart televisions and CLI tools where keyboard or browser interaction is limited. In a social engineering scenario, this legitimate flow can turn into the attacker’s most significant advantage:

1. The message sent to the victim contains no attacker-owned link. Instead it carries a prompt along the lines of “enter the value [code] at microsoft.com/devicelogin to pair your device.”
2. The user opens the browser themselves and goes to the genuine Microsoft address themselves. There is no attacker-owned URL for traditional email security controls to rewrite, analyze or detonate in an isolated environment. URL rewriting, lookalike domain detection and brand protection therefore produce limited signal.
3. Authentication takes place on the genuine Microsoft page. The TLS certificate, the domain name and every brand element are original.
4. The most critical point is that the user completes their own MFA verification themselves. No MFA fatigue attack, no MFA bypass technique and no fake phishing page is needed. Within a flow that looks legitimate, the user correctly enters both factors.

In this scenario MFA alone does not provide sufficient protection, because MFA verifies the identity of the user, not the intent behind the transaction.

The “click rate” metric used in simulation reports therefore leaves the behavior that actually needs measuring in this scenario out of scope. The user did not click an attacker-owned link; but by completing the device code flow they may have handed the attacker a session authorization that, depending on organizational policy, can be used or renewed for a long time.

The Chain: From Device Code to Enterprise Access

So what happens in the 72 hours that follow, once the user has entered that code? The simulation chain Kodes manages proceeds in four stages.

Stage 1 - Token Capture

When the device code flow completes, Microsoft issues a short-lived access token for the requested scopes. If the request also carries the offline_access scope, a long-lived refresh token may accompany it. The refresh token is the real strategic asset in the chain, because it allows new access tokens to be produced without the user authenticating again. Microsoft’s device code flow documentation likewise states that the refresh token is issued subject to the offline_access scope.

How long a refresh token stays valid varies with the token type, tenant policies, Conditional Access controls and any revocation applied. Signing out or changing a password may therefore not produce an immediate result in every scenario; the token can keep producing new access tokens until it is explicitly revoked or expires. Microsoft’s token lifetime documentation shows that events such as a password change or a sign-out can have different consequences depending on the token type.

On the Kodes side, this stage happens automatically once the user completes the device code flow. The tokens obtained are stored encrypted; identity and session data such as the user’s name, UPN, IP address and authorization scopes are parsed out.

Stage 2 - Lateral Expansion: One Key for 14 Services

Some of Microsoft’s first-party applications operate as part of the same client family in order to provide an uninterrupted session experience across applications. A family refresh token issued for one family member can, within the bounds of existing user consents and authorization scopes, allow tokens to be obtained for the other clients in the same family. In the research community this behavior is known as FOCI (Family of Client IDs). That this mechanism was designed by Microsoft as a deliberate SSO feature is covered in detail in the Secureworks FOCI research.

Drawing on this mechanism, Kodes performs token issuance and authorization analysis for 14 different Microsoft services from a single refresh token, in one operation:

Teams · MS Graph · Outlook · SharePoint Online · Azure Management · Azure Core Management · AAD Graph · Substrate · Yammer · Office Apps · Office Management · MAM (Intune) · MS Manage · DOD MS Graph

The critical point here is not that a new privilege is gained; it is that privileges the user has already consented to, or already holds, become usable across different Microsoft services. If the existing permissions are sufficient, no new consent screen may be displayed and no additional notification may reach the user.

Even an ordinary employee account can, depending on organizational policy, hold broad access across directory information, calendar, email, OneDrive and other business resources. The impact of a single authentication event can therefore extend well beyond the service it initially appeared to concern.

Stage 3 - Access to Enterprise Data

Once the tokens are ready, the data reachable within the user’s existing privileges is gathered into a single panel. The Kodes data viewer integrates directly with Microsoft APIs and analyzes the following sources:

• Mailbox - incoming and outgoing messages, and message content
• Corporate directory - employees’ names, titles, email addresses and phone numbers
• Calendar and Teams - meetings, conversations, decisions and daily workflows
• OneDrive and SharePoint - files, share points and department sites
• Azure subscriptions - the cloud resources the user is authorized over

The impact assessed at this stage is no longer limited to “access to one user’s email.” The resulting data can make the organization’s structure, its ongoing projects, its critical business processes and its communication with external stakeholders visible. The later steps of the chain are assessed against this organizational context.

Stage 4 - Pivot into the Corporate Network

In the final stage, the access the compromised endpoint can provide into the corporate network is verified. Within the approved test scope, Kodes runs an authenticated SOCKS5 proxy on the target device and reaches that service over a controlled tunnel.

Operator traffic can then be routed from the network context of the target device; the visibility of resources reachable only from inside the organization, such as intranet applications, internal DNS services and file servers, can be tested in a controlled way.

In our laboratory work and authorized customer tests, this entire chain - from the entry of the device code to traffic being routed through the corporate network - has been verified end to end within minutes.

Two-Sided View: What Does the Attacker Gain, and Where Can the Defense See It?

A red team engagement is incomplete without blue team visibility and detection design. Let us therefore assess each step of the chain side by side, in terms of the attacker’s gain and the signals the defense can see:

Microsoft states that device code usage can be tracked in Entra sign-in logs through the Authentication Protocol filter, and that subsequent token renewals can be correlated with the initial device code session through the Original Transfer Method field. Similarly, MailItemsAccessed can be used to investigate email access that takes place over supported mail protocols and clients. (Entra Authentication Flows, MailItemsAccessed)

The message of the table is clear: no step in the chain is inherently invisible. But each step, examined on its own, can look ordinary or low-priority. Real visibility comes from the ability to correlate Entra sign-in records, Microsoft Graph activity, workload audit logs and endpoint telemetry within the same session context. Microsoft’s approach to correlating session and token identifiers across different log sources makes this need explicit as well. (Microsoft Entra linkable identifiers)

This is where the real value of continuous red team work emerges: running realistic attack chains at regular intervals to measure not only whether the SOC sees the individual events, but how quickly it can establish the connection between them.

The Answer: Measuring and Managing Human Risk Continuously

The cycle of an annual simulation and quarterly awareness training is no longer sufficient to manage the dynamic human risk the Microsoft 365 ecosystem creates. The model we propose rests on three core elements:

1. Running scenarios continuously - controlled red team scenarios based on current attacker tactics, techniques and procedures (TTPs), including the device code flow, are run regularly. Each engagement measures at which stage the chain was detected, how far it was able to progress and at which point it was stopped.

2. Purple team integration - each scenario is monitored in real time together with the defense team and the existing security telemetry. The visibility table in the previous section is filled in with the organization’s own logs; detection, correlation and response times are turned into reportable KPIs.

3. Constraining it with technical controls - the device code flow is opened, through Conditional Access policies, only to the users, groups and use cases that need it. Microsoft Graph activity records and workload-specific audit logs are monitored centrally; anomaly thresholds for session and token usage are calibrated against this attack chain.

This threefold approach takes the human factor beyond being merely “the weak link that needs training” and turns it into a risk component that is measured, monitored and constrained by technical controls.

Red in Pulse sits at the very center of this continuous red team and purple team model, which measures human risk not through click rates alone but through the progress of the attack chain, the visibility of the defense and the time to respond.

Kodes M365 Red Team

To manage the attack chain described in this article from a single operational surface, we have developed a small platform called Kodes M365 Red Team. Kodes is an operations panel that manages, end to end, the authorized red team activities carried out after the social engineering scenario - from campaign management to token analysis, and from data visibility to verification of internal access:

• Campaign management - building target lists and centrally managing scenario-specific domain and delivery configurations
• Token operations - issuing tokens for 14 different Microsoft services in one operation from the tokens obtained, and presenting next-step recommendations based on the existing authorization scopes
• Data viewer - reviewing email, directory, calendar, chat, file and site data within the user’s privileges through the panel, with quick preview and comprehensive collection modes
• Controlled pivot - providing controlled access to the corporate network over an authenticated SOCKS5 tunnel and verifying internal resource visibility. Each endpoint reached can represent a different network context and, for the organization, a separate incident scenario.

The research foundation of Kodes draws on the technical body of work established by the AADInternals and TokenTacticsV2 projects in the open source security ecosystem. For readers who want to examine the technical background of device code-based phishing and the attack methodology in more detail, we particularly recommend the relevant AADInternals research article.

Responsible Use

Kodes M365 Red Team is designed for use only in penetration testing, red team and purple team engagements conducted under written authorization. The techniques named in this article are shared on the basis of publicly available research in the field, with the aim of improving the visibility of defense teams.