The signal
Treat a new factor like a new credential
MFA registration events are often explained away as normal account hygiene: a new phone, a replacement device, or a second sign-in method. That assumption is exactly what makes the event useful to an attacker.
After gaining access to an account, an intruder may register an authenticator, phone number, passkey, or hardware key they control. The action is legitimate from the identity platform's point of view, leaves no malware on disk, and can preserve access after the victim changes a password.
Investigation principle
01 · Baseline
Define what normal enrollment looks like
An alert becomes useful only when the expected pattern is understood. In a typical environment, legitimate registration has several supporting signals.
- The device, IP address, location, and user agent are familiar for the user.
- The activity occurs during expected working hours or an onboarding or device-refresh window.
- A helpdesk ticket, approved self-service flow, or other identity-verification record explains the change.
- Only the expected method is added; there is no burst of recovery, consent, forwarding, or role changes.
- The session satisfies the organisation's current Conditional Access and authentication requirements.
Build the baseline around your own enrollment process. A registration from a personal phone may be ordinary in one organisation and a policy violation in another.
02 · Triage
Red flags that raise confidence
| Signal | Why it matters |
|---|---|
| Unfamiliar session | Registration follows a sign-in from a new IP, device, autonomous system, or region. |
| Suspicious timing | The method is added outside the user’s normal pattern or immediately after a risky sign-in. |
| No support record | There is no helpdesk, onboarding, or device-replacement event to explain the change. |
| Method mismatch | The new factor differs from the user’s established methods or organisational standard. |
| Multiple changes | Several factors or recovery channels are added or removed in one short window. |
| Adjacent account activity | The same session creates mailbox rules, grants OAuth consent, changes groups, or touches privileged resources. |
No single row proves compromise. Confidence comes from the sequence: how the session began, what authorised the registration, and what happened next.
03 · Investigation
Reconstruct the session, not just the event
- 1
Anchor the timeline. Record the registration time, method type, target account, initiating actor, result, and any available device or request details.
- 2
Review nearby sign-ins. Examine the hours before and after the event. Compare IP, location, device ID, user agent, authentication requirement, risk signals, and Conditional Access outcome.
- 3
Identify what authorised the change. Determine whether the session used a strong recent authentication, an existing factor, an administrator action, or a token that may have been stolen.
- 4
Correlate related activity. Look for password resets, phishing alerts, recovery-information changes, inbox rules, forwarding, OAuth grants, group membership, and role changes.
- 5
Validate out of band. Contact the user through a trusted channel that does not depend on the potentially compromised account. Confirm both the registration and the surrounding activity.
Evidence to preserve
04 · Response
Contain the account, not only the factor
If the registration cannot be confirmed as legitimate, deleting the new method is not enough. Treat the identity as compromised and remove every route the attacker may have created.
- Disable or restrict the account while preserving required evidence.
- Revoke active sessions and refresh tokens.
- Reset credentials through a verified recovery process.
- Remove unauthorised authentication and recovery methods.
- Review and reverse mailbox rules, forwarding, OAuth consent, group membership, roles, and application access.
- Re-verify the user's identity before enrolling replacement factors.
- Expand the investigation to other identities or devices touched by the same infrastructure.
ATT&CK context