Home/ATT&CK Technique/Device Registration
ATT&CK Technique

Device Registration

T1098.005 · persistence, privilege-escalation

Adversaries may register a device to an adversary-controlled account. Devices may be registered in a multifactor authentication (MFA) system, which handles authentication to the network, or in a device management system, which handles device access and compliance. MFA systems, such as Duo or Okta, allow users to associate devices with their accounts in order to complete MFA requirements.

An adversary that compromises a user’s credentials may enroll a new device in order to bypass initial MFA requirements and gain persistent access to a network. In some cases, the MFA self-enrollment process may require only a username and password to enroll the account's first device or to enroll a device to an inactive account. Similarly, an adversary with existing access to a network may register a device or a virtual machine to Entra ID and/or its device management system, Microsoft Intune, in order to access sensitive data or resources while bypassing conditional access policies.

Devices registered in Entra ID may be able to conduct Internal Spearphishing campaigns via intra-organizational emails, which are less likely to be treated as suspicious by the email client. Additionally, an adversary may be able to perform a Service Exhaustion Flood on an Entra ID tenant by registering a large number of devices.

WindowsIdentity Provider

Actors Using This

12
russiaAPT29
iranOilRig
iranAPT35
north_koreaKimsuky
predominantly_english_speaking_youth_organized_crimeLAPSUS$
predominantly_westernScattered Spider

Likely Attack Path

Techniques the same actors pair with this one distinctively - those showing up among actors who use this technique noticeably more than across all actors (lift > 1.15), grouped by kill-chain phase. The × is that lift multiplier; the shared-actor count is in the tooltip. A near-universal technique pairs with everything at baseline, so its list is short by design.

Mitigations

1
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1032Multi-factor Authentication

Multi-Factor Authentication (MFA) enhances security by requiring users to provide at least two forms of verification to prove their identity before granting access. These factors typically include: - Something you know: Passwords, PINs. - Something you have: Physical tokens, smartphone authenticator apps. - Something you are: Biometric data such as fingerprints, facial recognition, or retinal scans. Implementing MFA across all critical systems and services ensures robust protection against account takeover and unauthorized access.

Identity and Access Management (IAM)
  • Use IAM solutions like Azure Active Directory, Okta, or AWS IAM to enforce MFA policies for all user logins, especially for privileged roles.
  • Enable conditional access policies to enforce MFA for risky sign-ins (e.g., unfamiliar devices, geolocations).
  • Enable Conditional Access policies to only allow logins from trusted devices, such as those enrolled in Intune or joined via Hybrid/Entra.
Authentication Tools and Methods
  • Use authenticator applications such as Google Authenticator, Microsoft Authenticator, or Authy for time-based one-time passwords (TOTP).
  • Deploy hardware-based tokens like YubiKey, RSA SecurID, or smart cards for additional security.
  • Enforce biometric authentication for compatible devices and applications.
Secure Legacy Systems
  • Integrate MFA solutions with older systems using third-party tools like Duo Security or Thales SafeNet.
  • Enable RADIUS/NPS servers to facilitate MFA for VPNs, RDP, and other network logins.
Monitoring and Alerting
  • Use SIEM tools to monitor failed MFA attempts, login anomalies, or brute-force attempts against MFA systems.
  • Implement alerts for suspicious MFA activities, such as repeated failed codes or new device registrations.
Training and Policy Enforcement
  • Educate employees on the importance of MFA and secure authenticator usage.
  • Enforce policies that require MFA on all critical systems, especially for remote access, privileged accounts, and cloud applications.

Detection Coverage

1/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) 1
Analytics (MITRE CAR) none
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none

Comply & Defend

Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin