The Meeting Code That Was a Login: Hunting Device Code Phishing
The challenge
A fake Teams invite gave staff a code to enter. Hunt device code sign-ins and what came next. Name the account the attacker now controls.
What you'll learn
- Explain how the OAuth device code flow can be phished
- Read Entra ID sign-in fields: protocol, app, IP, device, error code
- Pivot from a deviceCode sign-in to what the same account did next
- Tell a legitimate meeting-room device sign-in from a phished one
- List the controls: Conditional Access, token revocation, alerting
Skills tested
Prerequisites
- What MFA is
- Reading tabular log events
How it works
The OAuth 2.0 device authorization grant (RFC 8628) lets a device with no keyboard, such as a smart TV or a meeting-room panel, sign in: the device shows a short code, you type it at microsoft.com/devicelogin on your own computer and sign in there, and the device, which has been polling Entra ID, receives the tokens.
Nothing ties the code to the person typing it. In device code phishing the attacker starts the flow themselves and sends the code as a meeting invite or chat message, while it is fresh (a code expires after about 15 minutes). The victim signs in on Microsoft's real page with her real password and MFA, and the tokens go to the attacker's script. Microsoft reported Storm-2372 doing this in 2025 with fake Teams invites, later through the Microsoft Authentication Broker so the stolen session could register a device.
In the sign-in log this splits into two rows. The deviceCode row is the victim's own browser approving the code, so it shows her usual IP and device. The token redemption comes seconds later from wherever the attacker runs, with a client that is not a browser. Pairing the two (same user, same app, same session) is the detection.
Common mistakes
- Answering [email protected]. That is the Harbour room's Teams panel. An admin typed its code on a laptop at 09:51 and the panel redeemed the token from the office IP four seconds later: the device code flow used exactly as designed.
- Stopping at the deviceCode row. Lena's approval comes from her own Edge on the office IP and passed MFA. The compromise only shows in the rows that follow it from Frankfurt.
- Answering a password-spray target. The ropc rows from São Paulo are a spray that failed: every one is error 50126, invalid username or password.
- Flagging sara.jansen. She is travelling: Lisbon, a normal browser, and a normal MFA prompt (50074) followed by success.
- Answering the attacker's IP. The question asks which account was taken over.
How to defend against it
- Block the device code flow with a Conditional Access policy (Conditions, Authentication flows), excluding only the meeting-room and shared devices that need it.
- Alert when a device code session is redeemed from a different IP, country or user agent than the approval, and on deviceCode sign-ins to the Microsoft Authentication Broker.
- On a hit, revoke the user's sessions and refresh tokens (
revokeSignInSessions), reset the password, delete any device the attacker registered, and review mailbox access. - Teach staff that no meeting invite ever asks you to type a code at a Microsoft sign-in page.