[New Rule] Entra ID Admin Registered MFA Method for User

[descambiado]

Summary

Adds a detection for an administrator registering or updating an MFA method on behalf of another Entra ID user.

Existing MFA coverage in the ruleset keys on removal: Entra ID MFA Disabled for User matches Disable Strong Authentication and User deleted security info. The admin-initiated registration path is the inverse and is currently unobserved. An adversary with administrative access can attach a phone number they control to a victim account, obtaining a factor that satisfies MFA and Conditional Access without changing the password and without the account owner noticing.

Entra ID Temporary Access Pass Created for User already covers the TAP case with a different tactic mapping, so this rule explicitly excludes *TemporaryAccessPass* to keep the two complementary rather than overlapping.

Validation

Detection logic and the investigation guide are derived from audit events generated and captured in a live Entra ID tenant, not from documentation.

A single admin registration writes two audit records with the same timestamp and target:

1. Authentication Methods service — the record this rule matches

Activity type   : Admin registered security info
Category        : UserManagement
Correlation id  : 60d0e1b2-984b-463a-8a06-77f828a6bd44
Status          : success
Result reason   : Admin registered phone method for user
User agent      : Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Chrome/151.0.0.0
Initiated by    : User  (UPN, object id and IP address present)
Target          : User  testuser1@<tenant>.onmicrosoft.com

modifiedProperties:
  Phone.Phone.Id          -> "3179e48a-750b-4051-897c-87b9720928f7"
  Phone.Phone.PhoneType   -> "Mobile"
  Phone.Phone.PhoneNumber -> "+34 600000000"

2. Core Directory service — parallel record, not matched by this rule

Activity type   : Update user
Category        : UserManagement
Initiated by    : Application  "Azure Credential Configuration Endpoint Service"

modifiedProperties:
  StrongAuthenticationMethod      : []  ->  [{"MethodType":5,"Default":true},{"MethodType":0,"Default":false}]
  StrongAuthenticationUserDetails : []  ->  [{"PhoneNumber":"+34 600000000","AlternativePhoneNumber":null,...}]
  Included Updated Properties     : "StrongAuthenticationMethod, StrongAuthenticationUserDetails"

Two details worth carrying into the investigation guide came out of this and are documented in the rule's note:

• The actor is only attributable from the Authentication Methods record. The Update user twin is initiated by a Microsoft first-party service principal, so attributing from that record gives the wrong answer.
• result_reason distinguishes the method type in plain language, which is what makes the TAP exclusion clean. Registering a Temporary Access Pass on the same account produced Admin registered security info with result reason Admin registered temporary access pass method for user and TemporaryAccessPass.* modified properties, confirming the exclusion clause matches only the intended case.

Checks:

• TOML parses, two MITRE threat blocks (Persistence, Credential Access), T1556.006
• No non-ASCII characters
• rule_id verified unique against the repository
• No existing rule matches Admin registered security info outside the TAP rule, which this one excludes by design
• severity/risk_score set to medium/47, matching Entra ID MFA Disabled for User as the closest comparable rule

What I did not verify

Being explicit about the limits of the above:

• Only the phone registration path was reproduced end to end. Admin updated security info is included on the strength of it being a documented Entra operation name (it appears throughout Microsoft's own Azure-Sentinel content), but I did not trigger it in the tenant, so I have not seen its modifiedProperties shape first hand. Happy to drop it from the query if you would rather the rule only claim what was observed.
• I could not run detection_rules validate-rule locally (missing toolchain dependencies), so the rule has only been checked by hand and by parsing. CI will be the first real run.

Notes

Happy to adjust naming, severity, or the exclusion approach if you would rather see this folded into the existing MFA rule instead of standing alone.