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

Device Registered After Device Code Sign-In [RULE-1167]

This rule detects a new device being registered in Entra ID shortly after the same account completed a device code sign-in. Attic correlates the two events: a successful device code authentication, followed within a short window by a device registration or device add performed by that same account. 

Device code flow is an authentication method for devices that cannot easily show a sign-in page. Registering a device adds a new identity to your tenant that is associated with the user. Each event on its own is routine. The sequence is what makes this detection meaningful.

Meeting room systems and conference hardware legitimately combine these two actions, so Attic filters known conference equipment out automatically. Approved combinations of user and application can additionally be whitelisted in the "Approved device code applications" setting, which this rule shares with RULE-1166.

Rationale

Device code phishing gives an attacker a valid, MFA-satisfied token without ever learning the victim's password. What that token cannot do by itself is survive: revoke the session or reset the password and the access is gone. So an attacker who wants to keep their foothold has to convert that temporary token into something durable, and registering their own device is the most reliable way to do it.

A device registered by the attacker becomes a lasting identity in your tenant. It can be used to satisfy Conditional Access policies that require a known or compliant device, it can request fresh tokens on its own, and, most importantly, it keeps working after the victim's password has been reset. Incident response teams regularly find that an account was properly cleaned up while an attacker-registered device quietly retained access. This is why MITRE tracks device registration as its own persistence technique (T1098.005).

The value of this rule lies in the correlation rather than in either event. Device registrations happen constantly in a healthy tenant and are far too noisy to alert on individually. Device code sign-ins have legitimate uses too. But a device code sign-in followed closely by that same account enrolling a new device matches the standard device code phishing playbook, and warrants immediate investigation. Because this detection fires at the persistence stage rather than the initial access stage, treat it as more urgent than a device code alert on its own.

Follow-up

Follow these steps to adequately address this detection:

  1. Validate whether the registration is legitimate: Contact the owner of the account. Ask whether they set up a new device around the time of the alert, and whether they entered a device code to do so. Check whether the device name in the alert matches something the user or your IT department recognises. Be alert to device names that imitate a naming convention but do not appear in your asset administration.
    • If no (not legitimate): Treat the account as compromised and the registered device as attacker-controlled. Order matters here:
      1. Remove the registered device first via Entra admin center → Devices → All devices → [device] → Delete. Do this before the password reset. A device that remains registered can keep obtaining access after the account has otherwise been cleaned up.
      2. Revoke all active sessions via Entra admin center → Users → [user] → Revoke sessions
      3. Block sign-in via Entra admin center → Users → [user] → Block sign-in
      4. Reset the password via an out-of-band method (not by email to the compromised account)
      5. Check for other persistence: Verify whether the attacker has also added or changed MFA methods, granted OAuth consent to applications, created inbox rules, or added application credentials. An attacker who registered a device has usually attempted more than one persistence mechanism.
      6. Investigate the timeline: Review the Entra ID sign-in logs and audit logs for all activity by this account and by the registered device since the sign-in. Check what the device accessed after it was enrolled.
      7. Escalate to IR: Because this detection indicates established persistence rather than only a suspicious sign-in, we recommend contacting Attic for incident response support via our IR service, particularly for privileged accounts.
    • If yes (legitimate): The user genuinely enrolled a device:
      1. Validate the device: Confirm the device belongs in your environment and is recorded in your asset administration. Verify that it meets your compliance requirements.
      2. Validate the flow: Establish why a device code was needed. If a normal browser-based sign-in would have worked, that is worth correcting, as it reduces how often users are conditioned to enter codes they were sent.
      3. Suppress future alerts: If this is recurring approved automation or hardware, add the combination to the "Approved device code applications" setting in Attic. The alert contains the exact entry to add. Note that this setting is shared with RULE-1166.
  2. Consider restricting device code flow and device registration: A Conditional Access policy targeting authentication flows can block device code flow for everyone who does not need it. Separately, review who is permitted to register devices and require MFA for device registration under Entra admin center → Devices → Device settings. Together these two measures remove most of this attack path rather than only detecting it.Attic checks for the first of these with Block Device Code Flow Authentication (CHK-1172), and offers an automated fix that creates the Conditional Access policy for you.

More information