Huntress exposes device code phishing hidden in fake Teams meeting scheduler

Huntress said that in mid-October, attackers sent a spear-phishing email from a typosquatted domain to an employee at a construction industry company, pretending the sender was a senior vice president at another construction company. Huntress redacted the names of the impersonated employee and company because they are legitimate and notified the company of the fake domain, reaching out to the impersonated company to inform them about the typosquatted domain used in the attack.

Huntress said the message carried a link wrapped by Microsoft safe links that passed through a Google short link before reaching an initial lure page hosted on the typosquatted domain. The lure domain used Zoho Mail, as shown by its SPF record and Zoho verification TXT records, and displayed a Microsoft Teams calendar meeting setup with the executive’s headshot, name, and fake email address. The page showed the impersonated executive’s headshot and name beside a fake email address inside a Teams calendar meeting layout.

The lure page pitched an introductory call with the executive about a long-term product supply partnership and asked targets to select a date, time, and duration for the call. Huntress said the left panel framed the interaction as a business opportunity to lower the victim’s guard before the device code flow began. Huntress also said the page sent none of the booking information entered by the victim anywhere and made no network calls until the victim clicked Continue.

After the visitor entered booking details and clicked Continue, the page resolved the visitor’s country through /cdn-cgi/trace or /api/visitor/country, with the cloudflare.com/cdn-cgi/trace fallback, before contacting the attacker backend. Huntress said this geolocation step happens before the attacker initiates any device code request and lets the attacker tailor the chain to the visitor’s location using several fallback methods. The backend started a Microsoft device code sign-in and returned a user code, which served as the device code, carrying headers including X-Antibot-Token, X-Auth-Mode, X-WinHello, X-Automatic-Target-Country, X-Visitor-Country, and Idempotency-Key.

The confirmation page displayed the device code as a Booking Reference and included a session expiry countdown. When the visitor clicked Copy or Confirm Meeting, the code went to the clipboard and a popup opened showing Microsoft’s real device sign-in page. Huntress said this step quietly copied the device code, so the victim could paste it into Microsoft’s legitimate login page without realizing they were authorizing the attacker’s session.

Entering the code on Microsoft’s legitimate device login page at microsoft.com/devicelogin authorized the attacker’s pending session and let the attacker get access tokens for that account. From the victim’s perspective the process appeared routine: enter the code, complete multifactor authentication if prompted, and approve the request. In doing so, they authorized the attacker’s session without knowing it.

When the backend reported success, the page shut the popup, displayed a Verification complete note, and redirected the victim to a Calendly booking page to hide the compromise. Huntress said the redirect to Calendly made the interaction look like a normal meeting booking, so the victim had no reason to think anything suspicious had happened.

The phishing kit used AES-256-GCM ciphertext with the decryption key and IV beside it in the page, and the browser decrypted it using the WebCrypto API. To an email scanner or crawler that does not run JavaScript, the lure page appeared as an encrypted blob because attackers hid the kit in ciphertext. Huntress said attackers designed the JavaScript-dependent decryption to defeat automated scanning that does not execute page scripts.

The kit set up a window.open hook plus two fetch hooks that sent API calls to the attacker backend at gpimmlgration.com. Huntress said the phishing domain acted as a small loader, while attackers stored the real kit as ciphertext and the browser decrypted it.

If Microsoft returned an error such as AADSTS50076 or interaction_required, which can occur when multifactor authentication is required, the page said the backend was preparing a new code, launched another device code session, and tried again. Huntress said the token-mode fallback restarted the MFA flow and gave the victim another chance to authenticate by showing a new code on the page.

Huntress said the kit then displayed a second code reading “Verification code ready. Please complete verification using the new code shown on this page.” The second screen told the victim to use the newly generated code, completing the retry loop without alerting the victim that the first attempt failed.

Attackers routed the device code login through a residential callback proxy based in New Orleans to appear as ordinary consumer traffic. Huntress said the New Orleans residential proxy carrying the device code login was a random home internet address with no other malicious activity besides attackers abusing it as a proxy. Huntress characterized the proxy as an innocent consumer connection repurposed by the attacker to make the malicious sign-in look like ordinary home internet traffic.

After the attacker obtained the session token, a Cmsi:Cmsi login to Microsoft Authentication Broker began, indicating successful device code authentication. Huntress identified and contained the incident quickly, stopping the attack from escalating. The Huntress SOC observed the attack in mid-October and moved to contain it once the device code authentication succeeded.

In device code phishing, attackers abuse the legitimate Microsoft authorization flow by starting a device-code sign-in request and convincing a victim to type the code at Microsoft’s real device login page. The legitimate authorization flow and login domain make the attack difficult for victims to detect because it uses Microsoft’s genuine domain, microsoft.com/devicelogin. To the victim, entering the code, completing multifactor authentication if prompted, and approving the request seems routine, but it actually authorizes the attacker’s session.

This is how the OAuth device-code flow can bypass multifactor authentication: the victim completes multifactor authentication on their own device while approving the attacker’s session, handing over access tokens. Huntress said this attack differed from conventional credential phishing because it did not immediately show a Microsoft sign-in page, instead using a Teams Meeting Scheduler workflow to build context. By delaying the real Microsoft sign-in and wrapping it in a familiar booking workflow, the attacker made the device code authorization appear to be a normal part of scheduling a meeting.

Huntress has tracked multiple significant device code phishing campaigns over the past year, including a Railway-based Microsoft 365 token replay campaign reported in March. Earlier campaigns used PDF lures such as an “Agreement Review” and asked targets to copy a verification code into Microsoft’s device login page, making the meeting scheduler a more elaborate evolution of the same technique. Huntress said the mid-October attack was unique in the lengths it went to disguise the device code flow, a notable example of threat actors investing more effort into disguising device code authorization as everyday business activity.

Huntress said the kit included a WinHello stage where, if the backend supplied a mirror_url, the victim saw a pop-up claiming the sign-in succeeded and requesting extra verification. This additional stage tries to convince the victim that authentication already succeeded and that another step is needed, keeping the target engaged after the initial code entry.

Huntress said any device code prompt arriving after a link or booking request counts as suspicious. Device code phishing works because it relies on Microsoft’s genuine authentication process. Attackers are reframing device code phishing as a credible social-engineering ploy that wraps authorization in everyday tasks.

Huntress recommends restricting or monitoring device-code authentication through conditional access where it is not required, enforcing phishing-resistant multifactor authentication, and investigating unfamiliar OAuth and device sign-ins from unmanaged devices, new regions, or residential proxy infrastructure. Defenders should enable additional complex conditional access policies alongside restricting device-code authentication.

The appearance of programmatic user agents like python-requests or node in interactive sign-in logs indicates automated attacker infrastructure. Programmatic user agents in interactive sign-in logs point to attacker tooling rather than normal human sign-ins.

After a breach is confirmed, defenders should check for rogue multifactor authentication methods, devices never recognized before, app consents not authorized, mailbox rules that look suspicious, and outbound mail that looks suspicious. These post-compromise checks help identify persistence mechanisms the attacker may have established after obtaining the session token.

Huntress says users should pause and confirm a request using known contacts before typing any code into a Microsoft sign-in page. Huntress said defenders should make sure users understand exactly whose session they are authorizing whenever a routine task asks them to copy, enter, or approve a code. Huntress said this advice targets the core social engineering of device code phishing, where victims believe they are approving their own routine action rather than an attacker’s session.

Huntress said the incident shows threat actors are reshaping device code phishing into convincing social-engineering ploys that hide authorization behind an everyday task, and that this technique succeeds because it relies on a legitimate Microsoft authentication process wrapped in a credible meeting-booking experience.