# Microsoft Teams Booking-Flow Device Code Phishing Campaign Targeting Microsoft 365 Accounts

> In mid-October 2026 Huntress observed a spear-phishing attack on a construction-sector company. It used a fake 'Microsoft Teams Meeting Scheduler' booking flow to get the victim to enter an attacker-generated Microsoft device code, shown as a 'Booking Reference', on Microsoft's real device-login page. A successful Cmsi:Cmsi (Microsoft Authentication Broker) sign-in followed through a residential callback proxy.

- **Published:** 2026-11-13T07:59:49Z
- **Last reviewed:** 2026-11-13T07:59:49Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-5941
- **ID:** TL-2026-5941
- **Severity:** HIGH
- **Category:** PHISHING
- **Status:** ACTIVE
- **Detections:** 9 (1 shown free below) · **IOCs:** 9 (3 shown free below)

## Description

Huntress SOC analysts investigated a spear-phishing intrusion against a construction-sector organization in mid-October 2026 (report published 2026-11-12). The lure email came from a typosquatted domain, registered about eight days before the incident, and impersonated a real senior vice president at another construction company. It proposed an 'introductory call' about a long-term supply partnership. The link in the email was wrapped by Microsoft Safe Links and pointed to a share.google short link, which redirected through a Google redirect to the lure page. The email body never contained the typosquatted domain, which sidestepped URL-reputation checks.

The lure page imitated a 'Microsoft Teams Meeting Scheduler' that asked for meeting duration, date, time and name. The page made no network calls until 'Continue' was clicked; it then sent the visitor's country to the backend (gpimmlgration[.]com, /static-export/api/device/start). The backend started a genuine Microsoft device-code authorization and returned a user_code, which the page displayed as a 'Booking Reference'. On the 'Confirm Your Booking' page, a Copy / Confirm Meeting click placed the code on the clipboard, and a session countdown added time pressure. A popup then opened Microsoft's real device-login page, where the victim pasted the code and completed authentication, including MFA if prompted. On success the popup closed, the page showed 'Verification complete', and the top window redirected to a Calendly booking page as cover.

The phishing kit was delivered as a small loader holding the real kit as AES-256-GCM ciphertext, with the key and IV in the page. The browser decrypted it with WebCrypto, so scanners that do not execute JavaScript saw only an encrypted blob. The decrypted kit installed a window.open hook and two fetch hooks that routed API calls to the backend. Request headers included X-Auth-Mode: cookie, X-WinHello: 1 and X-Automatic-Target-Country: 1. If the backend supplied a mirror_url, a fake Microsoft 'WinHello' popup claimed sign-in had succeeded and required an additional verification on the device. A token-mode fallback handled AADSTS50076 / interaction_required errors (typically MFA): the page told the victim to re-verify, restarted the flow with a new POST /api/device/start, and displayed a new code.

The successful sign-in was a Cmsi:Cmsi (Microsoft Authentication Broker) device-code authentication. It was relayed through a residential callback proxy in New Orleans so it would resemble consumer traffic. Sign-in logs also showed python-requests and node user agents from automated infrastructure, often visible only in non-interactive sign-in logs. The compromised account had no MFA enrolled and was accessed from a non-compliant, unmanaged device. Huntress contained the incident before escalation. The source gives no CVE, CVSS score or actor attribution, so severity is an analyst assessment based on confirmed account compromise. A separate Huntress report (Railway PaaS, March 2026) attributed a large device-code campaign to the EvilTokens phishing-as-a-service platform, but Huntress does not tie the Teams booking-flow incident to EvilTokens or any named actor.

## MITRE ATT&CK

- T1583.001 Domains
- T1608.005 Link Target
- T1566.002 Spearphishing Link
- T1204.001 Malicious Link
- T1027.013 Encrypted/Encoded File
- T1078.004 Cloud Accounts
- T1684.001 Impersonation
- T1528 Steal Application Access Token
- T1539 Steal Web Session Cookie
- T1557 Adversary-in-the-Middle
- T1550.004 Web Session Cookie
- T1090 Proxy

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**Cmsi:Cmsi Device-Code Sign-In to Microsoft Authentication Broker from Unmanaged Device** (`TL-2026-5941-SPL-001`)

Detects a successful Entra ID sign-in using the OAuth device authorization grant (device code) to the Microsoft Authentication Broker (Cmsi:Cmsi, app id 29d9ed98-a469-4536-ade2-f981bc1d605e) from a device that is neither compliant nor managed. This is the exact account-compromise step of the Teams booking-flow device-code phishing campaign (TL-2026-5941), where the victim pastes an attacker-generated 'Booking Reference' code into Microsoft's real device-login page and the attacker's relayed sign-in succeeds from an unmanaged device via a residential callback proxy. Behaviour-first: it needs no IOC feed and covers interactive and non-interactive sign-in logs.

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1078.004, T1528, T1557
- **Data sources:** azure:monitor:aad SignInLogs, azure:monitor:aad NonInteractiveUserSignInLogs, entra_id_signin_logs
- **Severity:** high
- **Confidence:** high

### Splunk SPL

```spl
index=azure sourcetype="azure:monitor:aad" earliest=-24h category IN ("SignInLogs","NonInteractiveUserSignInLogs") properties.status.errorCode=0 (properties.authenticationProtocol=deviceCode OR properties.originalTransferMethod=deviceCodeFlow)
| eval upn=lower('properties.userPrincipalName'), app_id=lower('properties.appId'), app_name='properties.appDisplayName', src_ip='properties.ipAddress', ua='properties.userAgent', country='properties.location.countryOrRegion'
| eval compliant=lower(coalesce('properties.deviceDetail.isCompliant',"false")), managed=lower(coalesce('properties.deviceDetail.isManaged',"false"))
| where (app_id="29d9ed98-a469-4536-ade2-f981bc1d605e" OR like(lower(app_name),"%authentication broker%")) AND compliant!="true" AND managed!="true"
| stats count min(_time) as first_seen max(_time) as last_seen values(src_ip) as src_ip values(country) as country values(ua) as user_agent by upn app_name
| eval detection="TL-2026-5941 Cmsi:Cmsi device-code sign-in from unmanaged device", first_seen=strftime(first_seen,"%F %T"), last_seen=strftime(last_seen,"%F %T")
```

### Microsoft KQL

```kql
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0"
| where AuthenticationProtocol =~ "deviceCode" or OriginalTransferMethod =~ "deviceCodeFlow"
| where AppId =~ "29d9ed98-a469-4536-ade2-f981bc1d605e" or AppDisplayName has "Authentication Broker"
| extend IsCompliant = tostring(DeviceDetail.isCompliant), IsManaged = tostring(DeviceDetail.isManaged)
| where IsCompliant !~ "true" and IsManaged !~ "true"
| project TimeGenerated, UserPrincipalName, AppDisplayName, AppId, IPAddress, Location, UserAgent, IsCompliant, IsManaged, CorrelationId
| order by TimeGenerated desc
```

### Sigma

```yaml
title: Device Code Sign-In to Microsoft Authentication Broker from Unmanaged Device
id: 6f1c2a54-3b7e-4d1a-9c52-8e5a1f0b7d11
status: experimental
description: Detects a successful Entra ID device-code (OAuth device authorization grant) sign-in to the Microsoft Authentication Broker (Cmsi:Cmsi) from a device that is neither compliant nor managed, as seen in the TL-2026-5941 Teams booking-flow device-code phishing campaign.
references:
    - https://www.huntress.com/blog/crafty-microsoft-teams-booking-flow-disguises-device-code-phishing
    - https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/
author: Threadlinqs Team
date: 2026-11-13
tags:
    - attack.credential-access
    - attack.defense-evasion
    - attack.t1528
    - attack.t1557
    - attack.t1078.004
logsource:
    product: azure
    service: signinlogs
detection:
    selection_flow:
        AuthenticationProtocol: 'deviceCode'
    selection_status:
        ResultType: '0'
    selection_app_id:
        AppId: '29d9ed98-a469-4536-ade2-f981bc1d605e'
    selection_app_name:
        AppDisplayName|contains: 'Authentication Broker'
    filter_managed:
        DeviceDetail.isCompliant: 'true'
    filter_managed_2:
        DeviceDetail.isManaged: 'true'
    condition: selection_flow and selection_status and 1 of selection_app_* and not 1 of filter_*
falsepositives:
    - Legitimate device-code sign-ins by users of shared or kiosk devices, Teams Rooms, or CLI tooling that are not enrolled in Intune
    - Newly provisioned devices not yet compliant
level: high
```

**Known false positives:**

- Legitimate device-code sign-ins from shared, kiosk or Teams Rooms devices not enrolled in Intune
- Newly provisioned or BYOD devices that are not yet marked compliant or managed

**Tuning notes:** Adjust the index/sourcetype to your Microsoft Cloud Services add-on ingestion. Allowlist known device-code applications and kiosk/Teams Room accounts, and consider raising severity when the user has no MFA method registered or the IP is not in a named location. Combine with Conditional Access report-only results for device-code flow to find the exposed population.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- Teams Booking Lure URL Delivery or Click ([indicator] / share.google Redirect) (locked: unlock with TL Creds)
- Post Device-Code Compromise: New MFA Method, Device Registration or App Consent (locked: unlock with TL Creds)
- Device-Code Sign-In from a Country Not in the User's 14-Day Baseline (locked: unlock with TL Creds)
- Device-Code Start API Call to [indicator] Phishing Backend (locked: unlock with TL Creds)
- Repeated Device-Code MFA-Required Results (AADSTS50076 Token-Mode Fallback) (locked: unlock with TL Creds)
- DNS Resolution of [indicator] Phishing Backend (locked: unlock with TL Creds)
- Device-Code Sign-In Followed by python-requests/node Token Use (Session Replay) (locked: unlock with TL Creds)
- Session Reuse from New Country or IP After Device-Code Sign-In (Residential Proxy Relay) (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sample indicators (3 of 9)

Defanged, TLP:CLEAR.

- Domain: `gpimmlgration[.]com`
- URL: `hxxps://share[.]google/?q=UltJkMsVWI5V9GJM1`
- URL: `hxxps://www[.]google[.]com/share.google?q=UltJkMsVWI5V9GJM1`

Full set of 9 indicators unlocks with TL Creds: https://threadlinqs.com/tl-creds

## Sources

- [Crafty Microsoft Teams Booking Flow Disguises Device Code Phishing](https://www.huntress.com/blog/crafty-microsoft-teams-booking-flow-disguises-device-code-phishing)
- [Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure](https://www.huntress.com/blog/railway-paas-m365-token-replay-campaign)
- [Storm-2372 conducts device code phishing campaign](https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/)
- [Securelist: Microsoft device code phishing attack](https://securelist.com/microsoft-device-code-phishing-attack/120350/)
- [Huntress: What is Device Code Phishing?](https://www.huntress.com/cybersecurity-101/topic/device-code-phishing)
- [How to protect against Device Code Flow abuse (Storm-2372 attacks) and block the authentication flow](https://jeffreyappel.nl/how-to-protect-against-device-code-flow-abuse-storm-2372-attacks-and-block-the-authentication-flow/)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-5941