Huntress says a fake Teams page showed the device code as a booking reference; its figure shows 8 steps
Huntress says a fake Microsoft Teams scheduler showed an employee of a construction sector company the device code as a Booking Reference. Its own figure draws 8 steps (derived count); the post gives no time between approval and catch.
By Parminder Kumar Sharma · LinkedIn · · 21 min read
Eight steps, four obstacles and no clock: what Huntress's figure and text give
Huntress's own figure of the attack draws 8 steps between the victim opening the lure page and the attacker receiving tokens (derived: a count of the boxes in Figure 1 of its post). The text puts an email and three server side redirects in front of those 8, and names four obstacles the chain was built to get past (derived count): URL reputation checks, scanners that do not run JavaScript, an MFA error, and a look of ordinary consumer traffic. What the post does not give is a clock. It says the Huntress SOC "quickly" identified and contained the incident, and offers no minutes, no hours and no day beyond "mid-October". The page data date of the post is 12 November 2026, 14:00 UTC, so the incident was about four weeks before publication (derived, taking 15 October as the middle of the month: 28 days).
The incident, as Huntress describes it: an employee at a company in the construction sector received a spear phishing email that impersonated a senior vice president of another construction company, from a typosquatted domain. A fake Microsoft Teams meeting scheduler walked the employee through choosing a duration, date and time, and then showed a Booking Reference. Huntress says that reference was the device code. Copying it opened Microsoft's real device sign in page, and entering it approved the attacker's pending sign in.
What this does not establish. It is one incident at one customer. The post does not say who the attacker is, how many people received the email, how many organisations or users were hit, what the attacker did with the session beyond replaying it from other infrastructure, whether the kit is sold or shared, whether it matches a known framework, or whether Microsoft, Google or Calendly responded. It prints no CVE, which fits its own account: the attack abuses a legitimate sign in flow, not a software flaw. Huntress sells managed detection and response, including identity threat detection for Microsoft 365, and wrote the post about its own SOC's catch, so its account of the catch is its own. Microsoft, Google and Calendly are platforms the attacker used, not parties at fault. This briefing rests on Huntress's post, read on 13 November 2026, from a copy saved between about 07:05 and 07:30 UTC from a copy saved by the lead, and on two Microsoft documentation pages. A summary by Help Net Security was not read.
What is new here, set against two earlier device code briefings
This site has covered device code phishing twice before: the ANY.RUN briefing on the SkyW4lker kit and the Push Security briefing on fake event pages. Nothing from their counts carries over to this one. The comparison below is about method only, and each earlier cell is what those briefings say their sources reported. Huntress says its own SOC "observed an attack that was unique in the lengths it went to disguise this device code flow". That is Huntress's view of its own caseload, and the post does not claim the technique is new.
Method compared. Earlier columns are this site's earlier briefings on ANY.RUN's and Push's reports; the last column is Huntress's post of 12 November 2026.
| Element | Earlier briefings | This Huntress post |
|---|---|---|
| Where the code appears | A page that tells the victim to enter a device code on Microsoft's page; a Confirm access box with a one time access code | A Booking Reference on a Confirm Your Booking page inside a Teams scheduler flow, with a Copy button and a countdown |
| How the link reaches the victim | An email with a password protected attachment; invitation links through Google short links or another shortener | A spear phishing email posing as a senior vice president, a Microsoft Safe Links wrapper, then a share.google link |
| What hides the page from a scanner | A CAPTCHA page; a Cloudflare managed challenge | The kit is AES-256-GCM ciphertext that the browser decrypts, with the key beside it |
| If the code step fails | A proxy page as a second stage, in the Push chain (this site's reading of Push) | A new device code session, started when Microsoft returns an MFA error |
| Huntress's own earlier lure | Not applicable | Huntress says many earlier cases sent a PDF, such as an Agreement Review, and asked the target to copy a verification code |
Two of these are not new in kind. A shortener on a trusted Google domain also appears in the Push chain, and Huntress itself describes a lure that asked for a verification code. What Huntress adds is the context around the code: the page makes the code look like part of a booking. The code is not a login step, so the victim has nothing to compare it with.
What happened, in the order Huntress gives it
The email and the redirects. The message came from an account on a typosquatted domain and purported to come from the real senior vice president of another construction company. Huntress redacted the names of both the impersonated person and the company, and says it contacted the company about the fake domain. The email contained a link wrapped by Microsoft Safe Links that pointed to a Google short link. The post says that link redirected to a google.com address and then to the lure page, and that "these three redirects happened server-side at the same instant". Because the email body held the share.google link and not the typosquatted domain, Huntress says the message sidestepped URL reputation checks for email security.
The lure page. The lure domain was set up with Zoho Mail, according to its SPF and Zoho verification TXT records. The page showed a Teams calendar meeting setup with a headshot of the impersonated executive and an Introductory call about a long term partnership for the supply of the target's products. The decrypted kit shows that the choices a victim makes, duration, time, date and name, are not sent anywhere, and that the page makes no network calls until the victim clicks Continue.
Continue starts the attack. On Continue the page works out the visitor's country and sends it to the backend in a request with no body. The backend, which the victim cannot see, starts a Microsoft device code sign in and returns a user code. The victim lands on a Confirm Your Booking page. The Booking Reference on it is the device code, beside a session expiration countdown. Clicking Copy or Confirm Meeting puts the code on the clipboard and opens a popup showing Microsoft's real device sign in page. When the victim submits the code there, the attacker's pending sign in is approved.
The cover. When the backend reports success, the page closes the Microsoft popup, shows "Verification complete" and sends the victim to a Calendly booking URL, which Huntress redacted. Huntress says that looks like a real booking page, so the victim has no reason to suspect anything. After the attacker obtained the session token, it started the Cmsi:Cmsi login to Microsoft Authentication Broker, which Huntress reads as successful device code authentication. At that point Huntress says it quickly identified and contained the incident, barring the attack from escalating.
Friendly labels doing the work of a control
Every label on the page is chosen to make the code look like paperwork. Booking Reference names a code the victim is told to copy. Confirm Meeting is the button that puts it on the clipboard and opens Microsoft. Session expires in is a countdown that adds pressure. Verification complete is the line the page shows after the attacker has the tokens. None of these is a control, and a trained employee has nothing on the page to check them against: Huntress notes that device code phishing is hard to spot because it uses the legitimate flow and the real Microsoft sign in domain.
One detail in Huntress's screenshot is worth reading carefully. The countdown reads 26:51, which is 1,611 seconds. Microsoft's documentation says that from the moment a device code request is sent, the user has 15 minutes to sign in, the default value for expires_in. That is 900 seconds, so the page's countdown is 711 seconds (11 minutes 51 seconds) longer than Microsoft's default code life, about 1.79 times as long (derived). The post does not say what the countdown measures, and the screenshot also shows a New ref link that the post does not discuss. A reasonable reading, labelled as this site's inference, is that the countdown belongs to the lure's own session and not to the device code, and that a new reference means a new device code. Neither is stated. The screenshot's name field reads test and its meeting slot is Tuesday, 13 October 2026, so it looks like a capture of the kit and not of the victim's session; the post does not say which, and does not give 13 October as the date of the incident.
The countdown also shows why the code is the lure. Microsoft describes the device authorization grant as a flow for input constrained devices such as a smart TV or a printer, where the device shows a code and the user finishes the sign in on another device. Nothing in a meeting scheduler is a device. A reader who knows that rule can reject the page at the Confirm step. A reader who does not has no signal at all.
The four obstacles the post says the chain gets past
Huntress names a check, or a reason a check would miss, at six points in its account. Four are technical obstacles (the derived count above). Two are about the victim. The table says what the post states at each, and what it leaves out.
Obstacles and the steps that get past them, from Huntress's post of 12 November 2026. The right column is what the post does not say.
| Step | What Huntress says it gets past | What the post does not say |
|---|---|---|
| Email link is a share.google URL, not the lure domain | URL reputation checks for email security | Whether the Microsoft Safe Links wrapper scanned or rated the link; what any email gateway did |
| Kit ships as AES-256-GCM ciphertext, key and IV beside it | Scanners and crawlers that do not run JavaScript, which see an encrypted blob | Whether any sandbox that runs JavaScript saw the decrypted kit before Huntress |
| Token mode fallback on AADSTS50076 or interaction_required | An MFA error: the page starts a new device code session and gives the victim another try. The post calls this a fallback | How often the fallback fired in this incident, or whether it did |
| Device code login routed through a residential callback proxy | A check for unusual traffic: it looked like regular consumer traffic | Which address range or geography the victim's own sign ins came from |
| Real Microsoft device sign in page in a popup (victim side) | A victim's check of the address, because the flow and the login domain are legitimate | Whether Microsoft's own sign in page showed any warning |
| Redirect to a Calendly booking URL after success (victim side) | The victim's suspicion: it looks like a real booking page | Whose Calendly page it was; Huntress redacted the URL |
What the table does not say matters for a defender. The post does not state which signal alerted the Huntress SOC, so a reader cannot tell which of the four obstacles failed first or whether the catch came from the sign in logs, the proxy address or something else. It also does not give the gap between approval and identification, so a reader cannot compare their own mean time to detect against it.
What a defender could see, and what the post does not say
Huntress describes four kinds of evidence about the victim's account and its sign ins. First, the Cmsi:Cmsi login to Microsoft Authentication Broker. Second, programmatic user agents, python-requests and node, appearing in the sign in logs: Huntress says they show in both interactive and non-interactive logs, and often only in non-interactive ones. Third, the replay of the captured session from attacker infrastructure, with the ASN and region changing inside the same session ID. Fourth, the account state: no MFA enrolled, from a non-compliant, unmanaged device. It adds a residential proxy address, which it says is a home internet address in New Orleans with no other malicious activity beyond being abused as a proxy.
On the attacker's side, found by analysis, Huntress says the lure domain was registered eight days before the incident and was set up with Zoho Mail, and it reports the decrypted kit's behaviour. The post does not say which of these the SOC acted on first, which log table or field holds the Cmsi:Cmsi value, whether any detection rule fired, or whether Safe Links scanned the redirect. The last row of the diagram is this site's summary of where the post's evidence sits: at the identity layer, not in mail or on the web page.
Where the post differs from itself
MFA. The general account says a victim enters the code, completes multifactor authentication if prompted, and approves the request, and the kit has a fallback for the case where Microsoft returns an MFA error. But the ATT&CK table says the compromised account "had no MFA enrolled", and another row refers to the "post-MFA" Cmsi:Cmsi cookie handoff. The post does not reconcile these, so a reader cannot tell whether this victim saw an MFA prompt at all. The practical point stays the same either way: the approval was a human act.
The figure and the text. The figure's eight boxes start at the lure page and end with the victim selecting Continue, after which the attacker receives access and refresh tokens. The text starts with an email and three redirects, adds a fallback and ends with the Calendly redirect. The text names a session token and the Cmsi:Cmsi login; the figure names access and refresh tokens; one ATT&CK row says tokens for the Microsoft Authentication Broker client. The post does not say which token types were issued, or which were used. The figure's Continue button on Microsoft's page is not described in the text.
A string printed two ways. The share.google link appears with a stray space inside the code in one paragraph and without it in the indicator and ATT&CK tables. This briefing prints the version from the tables.
The domains. The email domain and the lure domain are both called typosquatted, but Huntress redacts the names, so the lure domain is not in the indicator list. The only attacker domain the post prints is the backend, and the post does not say whether the lure and the backend share an owner. A reader cannot block the lure domain from the post alone.
What Huntress states, and what it does not
Stated and not stated in Huntress's post of 12 November 2026. Read on 13 November 2026.
| Question | Stated | Not stated |
|---|---|---|
| When | Mid-October; the lure domain was registered eight days before the incident; post dated 12 November 2026 | The day; the time of approval; the time of identification; how long containment took |
| Who | A construction sector company was targeted; another construction company's senior vice president was impersonated | The attacker; any link to a named group, kit seller or framework |
| How many | One incident described | Recipients of the email; other victims; other campaigns using the same kit |
| After the token | The captured session was replayed from attacker infrastructure, with the ASN and region changing inside one session ID; Huntress contained it and barred escalation | What the attacker did with the session; whether mail or files were read; whether any persistence was set |
| The flaw | None: it abuses the legitimate device code flow | Any CVE; any Microsoft change or statement |
| Controls | Restrict or monitor device code authentication where not required via conditional access; phishing resistant MFA; investigate unfamiliar sign ins | Whether any control would have blocked this attack; the policy state of the victim's tenant |
| Detection | The sign in markers listed under Technical details | A detection query or rule; the first alert; the log field of Cmsi:Cmsi |
What to do, in order
Huntress's recommendations come first and are labelled. This site's suggestions follow and say so. Where Microsoft documentation is cited it is Microsoft's page, last updated 7 April 2026 according to the page. The post does not say any of these would have stopped this attack.
Take this with you
In order
- Huntress: restrict or monitor device code authentication where it is not required, via conditional access. Microsoft's guide says to get as close as possible to a unilateral block, to audit existing use first, to start the policy in Report only and to exclude emergency access accounts.
- Huntress: enforce phishing resistant MFA and enable additional conditional access policies. The post does not say they would have stopped this attack, and its table says the account had no MFA enrolled.
- Huntress: train staff to stop and verify the request through known contacts before entering any code on a Microsoft sign in page. This site's suggestion: add the plain rule that a code shown by a web page is not a booking reference.
- Huntress: investigate unfamiliar OAuth and device sign ins, especially from unmanaged devices, new regions or residential proxy infrastructure.
- Huntress: after a confirmed compromise, check for rogue MFA methods, unrecognised registered devices, unauthorised app consents, suspicious mailbox rules and suspicious outbound mail.
- This site's suggestion: hunt the last 30 days of sign in logs for device code sign ins, the Cmsi:Cmsi value and python-requests or node user agents, and revoke the refresh tokens of any user who approved a code they cannot explain. The post does not say how Huntress contained the incident.
- This site's suggestion: treat share.google and similar short links as redirectors in mail filtering, so the final destination is judged and not only the first hop. The post says the share.google link sidestepped reputation checks; it does not say what a destination check would have done.
Technical details
Everything below is Huntress's, copied from its post as read on 13 November 2026, from a copy saved between about 07:05 and 07:30 UTC, and defanged as Huntress defanged it. Do not visit, resolve or probe any address. The post prints no file hashes, no email headers, no full lure URL (the lure domain is redacted), no detection query or rule, and no log schema. This briefing does not invent them. Nothing here is a credential, a token or working code.
The request and the headers. After Continue, the page sends one request with no body to the backend's device start path. A defender can search proxy and DNS logs for the backend domain and this path. The post prints the headers on one line; they are shown one per line here, and the token value is redacted by Huntress.
POST hxxps[:]//gpimmlgration[.]com/static-export/api/device/start
X-Antibot-Token: REDACTED
X-Auth-Mode: cookie
X-WinHello: 1
X-Automatic-Target-Country: 1
X-Visitor-Country: XX
Idempotency-Key: web-<uuid>
Country lookup paths. Before that request the page resolves the visitor's country from three places. The paths are what a defender looks for in browser or proxy telemetry from a visit to the lure.
/cdn-cgi/trace
/api/visitor/country
cloudflare[.]com/cdn-cgi/trace
Lure directories. Huntress says the attacker staged several Teams themed lure directories on the typosquatted domain. A defender searches web proxy logs for these path names on any host, since the domain itself is redacted.
/%20Book%20a%20Microsoft%20Teams%20Meeting/
/Teams%20Microsoft%20Meeting/
Messages in the decrypted kit. The two fallback modes show the victim these texts. A user report or a screenshot that holds one of these sentences points to this kit's family of pages. Huntress says it cannot see where the mirror_url in the first mode points.
WinHello stage (if the backend provides a mirror_url):
Your sign-in was successful. To continue, we need to complete an additional verification on this device.
Token mode fallback (if Microsoft returns AADSTS50076 or interaction_required):
For your security, please verify your account again. A new verification code is being prepared.
Verification code ready. Please complete verification using the new code shown on this page.
Redirect chain and indicators. The email link was wrapped by Microsoft Safe Links, pointed to a Google short link, then redirected to a google.com address and the lure page. The two Google strings and the backend domain are Huntress's indicator rows. The Safe Links host is the wrapper Microsoft adds, so it is not an indicator on its own; the share.google value is a Google address, so this site's suggestion is to alert on the exact string and the pattern, not on the domain.
gpimmlgration[.]com Attacker-controlled backend / phishing infrastructure
share[.]google/?q=UltJkMsVWI5V9GJM1 Google short-link redirect used in the phishing chain
www[.]google[.]com/share[.]google?q=UltJkMsVWI5V9GJM1 Subsequent redirect before the lure page
nam12.safelinks.protection.outlook[.]com Microsoft Safe Links wrapper on the email link (named in the text, not in the indicator table)
hxxps[:]//calendly[.]com/[REDACTED]/30min Final redirect shape; Huntress redacted the account
Sign in log markers. What Huntress says to look for in Microsoft 365 sign in data. A defender searches interactive and non-interactive sign in logs for each. The post does not say which log table or field holds the Cmsi:Cmsi value, so confirm that in the tenant's own data before building a rule on it.
Cmsi:Cmsi Indicates the successful device-code authentication observed in the incident
Subsequent Programmatic User Agents such as python-requests and node in the sign in logs Indicates automated infrastructure. Appears both in interactive and non-interactive sign-in logs. Often times programmatic user agents only appear in non-interactive sign-in logs.
AADSTS50076, interaction_required Microsoft responses that trigger the kit's token mode fallback
CALLBACK_PROXY, MASSIVE_PROXY Labels Huntress gives the residential proxy routing of the captured session
The ATT&CK rows. Huntress's table has 12 technique rows (derived count). Each context cell below is this site's short summary of the post's own row, not a quotation.
ATT&CK techniques in Huntress's post of 12 November 2026, with this site's short summary of each row's context. Read 13 November 2026.
| Technique | ID | What the post's row says |
|---|---|---|
| Acquire Infrastructure: Domains | T1583.001 | The typosquatted domain was registered eight days before the incident |
| Stage Capabilities: Link Target | T1608.005 | Teams themed lure directories staged on that domain |
| Phishing: Spearphishing Link | T1566.002 | Email with a multi stage redirect chain through a Google short link |
| User Execution: Malicious Link | T1204.001 | The victim completed the booking flow and entered the Booking Reference code |
| Obfuscated Files or Information: Encrypted/Encoded File | T1027.013 | Kit shipped as AES-256-GCM ciphertext, decrypted in the browser |
| Valid Accounts: Cloud Accounts | T1078.004 | The account had no MFA enrolled and was used from a non-compliant, unmanaged device |
| Social Engineering: Impersonation | T1684.001 | A real executive's name, middle initial, title and headshot, plus Teams and Microsoft branding |
| Steal Application Access Token | T1528 | Tokens for the Microsoft Authentication Broker client once the code is entered |
| Steal Web Session Cookie | T1539 | The session token was captured through the relayed Cmsi:Cmsi flow |
| Adversary-in-the-Middle | T1557 | A callback proxy relayed the authentication and the post-MFA cookie handoff |
| Use Alternate Authentication Material: Web Session Cookie | T1550.004 | Captured session replayed from attacker infrastructure; ASN and region changed in one session ID |
| Proxy | T1090 | Captured session routed through a residential callback proxy |
The block, from Microsoft. This is the defender's setting, from Microsoft's page on blocking authentication flows, last updated 7 April 2026 by the page's own date. It is Microsoft's text, not Huntress's. Run it in Report only mode first, as the page says.
Under Conditions > Authentication Flows, set Configure to Yes.
Select Device code flow.
Under Access controls > Grant, select Block access.
Confirm your settings and set Enable policy to Report-only.
After confirming your settings using policy impact or report-only mode, move the Enable policy toggle from Report-only to On.
What was read, and what was not
Read in full: Huntress's post, page data date 12 November 2026 14:00 UTC, from a copy the lead saved on the morning of 13 November, and its Figures 1 to 4, fetched from the post's image host at about 07:22 UTC (that host's robots.txt answered 404, so no rules apply). Two Microsoft pages were fetched at about 07:23 UTC on 13 November: the Conditional Access guide to blocking authentication flows and the device authorization grant page. Help Net Security's summary was not read, so nothing here relies on it. Huntress's earlier post on a Railway based token replay campaign, which it mentions, was not fetched. No lure, backend or indicator address was visited, resolved or probed.
The question the post leaves open
Huntress gives a chain with 8 steps in its own figure, four evasions in its text and no clock, so the reader cannot measure the one number that decides the outcome: the gap between an employee approving a code and someone noticing. If a user in your tenant entered a device code today because a web page called it a booking reference, which log would show it, who reads that log, and how many minutes would pass before anyone revoked the session?
Key facts
Sources
- PrimaryCrafty Microsoft Teams Booking Flow Disguises Device Code Phishing, 12 November 2026: the attack chain, kit behaviour, indicators, ATT&CK table and figures. Read in fullHuntressaccessed 2026-11-13
- PrimaryBlock authentication flows with Conditional Access policy, page dated 7 April 2026: the device code flow block and report only guidanceMicrosoftaccessed 2026-11-13
- PrimaryMicrosoft identity platform and the OAuth 2.0 device authorization grant flow, page dated 4 January 2025: the 15 minute default code lifeMicrosoftaccessed 2026-11-13
