Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Automated Device Code Sign-In [RULE-1166]

This rule detects successful device code sign-ins that were completed by an automated HTTP client instead of a browser. Device code flow is an authentication method designed for devices that cannot easily show a sign-in page, such as a smart TV, a conference room system or a command-line tool. The device shows a short code, the user enters that code on a second device, and the first device receives a token.

The rule looks at the client that completed the sign-in. Browsers, Office applications and mobile apps identify themselves in a recognisable way. Scripting libraries and HTTP toolkits identify themselves differently, and Attic flags device code sign-ins that were finished by that kind of client. The sign-in IP addresses are also compared against the account's own recent sign-in history, so the alert can indicate whether the session also came from infrastructure that account has not used before.

Rationale

Device code phishing has become one of the most effective attacks against Entra ID, because it never asks the victim for a password. The attacker starts a device code flow themselves, then sends the victim the resulting code with a plausible reason to enter it: a Teams meeting that will not join, a new device that needs activating, an IT support request. The victim signs in on the real Microsoft page, approves the real prompt, and completes MFA. Everything the victim sees is genuine. The token, however, goes to the attacker.

Because the resulting session is fully authenticated and MFA-satisfied, it looks legitimate almost everywhere downstream. This is what makes the client itself worth watching. A person completing a device code sign-in is doing it in a browser. When the flow is instead driven by tooling, that is a strong indication the sign-in is being automated rather than performed by the account owner, whether by an attacker running a phishing kit or by a script nobody documented.

A sign-in from an IP address the account has not used recently strengthens the case considerably. That combination is why this detection is worth acting on quickly: it typically catches an attacker in the first minutes of holding a valid token, before they establish persistence.

Follow-up

Follow these steps to adequately address this detection:

  1. Validate whether the sign-in is legitimate: Contact the owner of the account. Ask whether they entered a device code around the time of the alert, whether someone asked them to do so, and whether they recognise the application named in the alert. A user who was phished will often remember entering a code they were sent by email, Teams or telephone.
    • If no (not legitimate): Treat the account as compromised. The attacker holds a valid token, so a password reset alone is not enough:
      1. Revoke all active sessions via Entra admin center → Users → [user] → Revoke sessions. This invalidates the stolen refresh token and is the single most important step.
      2. Block sign-in via Entra admin center → Users → [user] → Block sign-in
      3. Reset the password via an out-of-band method (not by email to the compromised account)
      4. Check for persistence: Verify whether the attacker has:
        • Registered a new device (see also RULE-1167)
        • Added or changed MFA methods
        • Granted OAuth consent to applications
        • Created inbox rules (forwarding, auto-delete)
        • Added application credentials (secrets, certificates)
      5. Investigate the timeline: Review the Entra ID sign-in logs and the unified audit log for all activity by this account since the sign-in. Pay attention to mailbox access, file downloads from SharePoint or OneDrive, and access to admin portals.
      6. Escalate to IR: If this is a privileged account, or if the attacker had time to act, contact Attic for incident response support via our IR service.
    • If yes (legitimate): The sign-in belongs to automation or to a device that genuinely uses this flow:
      1. Validate the use case: Establish which tool or script is involved, what it is for, and who owns it. Interactive user accounts should not normally be used for automation.
      2. Best practice: Use a service principal, a managed identity or a workload identity for automation rather than a user account. This limits the blast radius and makes auditing far simpler.
      3. Suppress future alerts: If the combination is approved, add it to the "Approved device code applications" setting in Attic. The alert contains the exact entry to add. Approve the specific combination of user and application rather than the user as a whole, so the account is still monitored for other activity.
  2. Consider restricting device code flow entirely: Most organisations need this authentication method for only a small number of accounts or devices. A Conditional Access policy targeting authentication flows can block device code flow for everyone else, which removes this attack path rather than only detecting it. This is the single most effective mitigation against device code phishing.Attic checks for this policy with Block Device Code Flow Authentication (CHK-1172), and offers an automated fix that creates the Conditional Access policy for you.
More information