Device Registration (T1098.005) is a sub-technique of Account Manipulation in MITRE ATT&CK. It sits under two tactics, persistence and privilege escalation, and MITRE lists Windows and identity providers as the affected platforms.
The idea is simple. If an attacker holds a stolen username and password, the next hurdle is usually MFA. If the MFA system lets that account enroll a new device, the attacker can register their own phone, token or virtual machine and walk through the door like any other user. Because the registered device is now trusted, it also keeps working after the first foothold is gone.
This post covers what MITRE documents about the technique, what to log, and which controls close the gap.
How attackers use it
MITRE describes two broad paths.
The first is the MFA system. Products such as Duo or Okta let users associate devices with their accounts to satisfy MFA requirements. An attacker who has compromised a user's credentials may enroll a new device to bypass the initial MFA requirement and gain persistent access to the network. MITRE notes that in some cases the self-enrollment process may need only a username and password to enroll the account's first device, or to enroll a device on an inactive account. That is the weak spot: a dormant account with no device yet is an open invitation.
The second path is device management. An adversary with existing access to a network may register a device or a virtual machine to Entra ID and its device management system, Microsoft Intune. The goal is to reach sensitive data or resources while bypassing conditional access policies, since a registered device can look like part of the fleet.
MITRE also points out two follow-on effects. Devices registered in Entra ID may be able to carry out internal spearphishing through intra-organizational email, which mail clients are less likely to treat as suspicious. And an adversary may be able to flood an Entra ID tenant by registering a large number of devices, which MITRE ties to service exhaustion.
None of this needs malware on a host. It abuses a feature that is working as designed, which is why it blends in.
How to detect it
The MITRE detection strategy for this technique is titled Suspicious Device Registration via Entra ID or MFA Platform. It has two analytics worth turning into rules:
- A new device registered to a compromised user account through Entra ID, Okta or Duo self-enrollment portals, used to bypass MFA or conditional access.
- A Windows device registered to Entra ID, or added through the Intune registration pipeline, using stolen credentials.
In practice that means you want these logs flowing to one place:
- Entra ID audit logs for device registration and device join events.
- Intune enrollment events.
- Okta and Duo admin and authentication logs, especially new factor or new device enrollment.
- Sign-in logs, so you can correlate a registration with the sign-in that preceded it.
Signals that deserve a look:
- A device enrolled shortly after a sign-in from an unusual location or network.
- Enrollment on an account that had no registered devices before, or on an account that had been inactive.
- A burst of registrations from one account or one source address.
- A registration followed soon after by access to mail, files or admin portals.
- Enrollment from outside your trusted locations or from an unmanaged device.
The most useful single question is: who approved this device? If the answer is "nobody, the user self-enrolled with only a password," you have found a gap even before an attack.
How to reduce the risk
MITRE lists one mitigation, multi-factor authentication, and it gives specific direction on how to apply it to registration itself:
- Require MFA to register devices in Entra ID. Registration should not be a step that a password alone can complete.
- Configure your MFA system to disallow enrolling new devices for inactive accounts.
- When users first enroll in MFA, use conditional access policies to restrict device enrollment to trusted locations or trusted devices.
- Consider a temporary access pass as the initial MFA method used to enroll a device, instead of leaving a window where a password is the only requirement.
Beyond what MITRE lists, the logic follows naturally: treat registration as a privileged event. Alert on it, review it, and make removing an unknown device a standard part of account recovery. When you reset a compromised password, also review and clear registered devices and MFA factors, or the attacker keeps the access you thought you removed.
Check your own environment
Work through this list with your identity team:
- Can a user with only a password register a device or add an MFA factor? Where, and from which networks?
- Are there inactive or never-enrolled accounts that could self-enroll their first device?
- Is device enrollment limited by conditional access to trusted locations or compliant devices?
- Do you have an alert on new device registration, and who receives it?
- Is there a periodic review of registered devices per user, with stale ones removed?
- When an account is compromised, does your runbook include removing registered devices and factors?
If you export Entra ID device records or your MFA vendor's device list, a quick sort by registration date and by owner will show clusters worth a second look.
Quick check
Why is an inactive account a risk for this technique?
MITRE notes that self-enrollment may require only a username and password to enroll a first device, or to enroll a device on an inactive account. An attacker with a stolen password can then add their own device and pass MFA.
What does MITRE recommend for the first MFA enrollment?
Use conditional access policies to restrict device enrollment to trusted locations or devices, and consider a temporary access pass as the initial MFA solution used to enroll a device.
After resetting a compromised password, what else should you clear?
Any devices or MFA factors registered to the account, since a device the attacker enrolled stays trusted until someone removes it.
Sources
- MITRE ATT&CK, Account Manipulation: Device Registration (T1098.005)
