ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Entra ID • MFA • KQL Investigation

The MFA Method Was Added At 3:14AM

The account had MFA enabled. The password had been changed. Everything looked secure on the surface.

Then the audit logs showed something that should not have happened: a new authentication method was registered at 3:14AM.

The user was asleep. The attacker was not trying to bypass MFA. They were trying to become part of it.

Discuss your environment Back to briefings
Agent Foskett investigation into suspicious MFA method registration in Microsoft Entra ID
Briefing summary

A compromised account appeared protected because MFA was enabled, but Entra ID audit evidence showed a new authentication method had been added while the user was offline.

New MFA method registered after hours
Password reset did not remove access
Audit logs revealed the persistence path

What happened

The alert was not dramatic. The account simply looked protected.
MFA was enabled The account appeared stronger than a password-only account. That is why nobody looked too closely at first.
The timestamp did not fit A new authentication method appeared at 3:14AM. The timing was the clue. The user was not registering anything at that hour.
The attacker became trusted This was not an MFA bypass. It was MFA enrolment abuse. The attacker added a method they could use again later.

The KQL that changed everything

The evidence lived in Entra ID audit activity. The question was simple: who added, changed or registered an authentication method?
mfa-method-registration-investigation.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has_any (
                            "authentication method",
                            "security info",
                            "strong authentication")
| extend
                            Actor = tostring(InitiatedBy.user.userPrincipalName),
                            TargetUser = tostring(TargetResources[0].userPrincipalName),
                            TargetName = tostring(TargetResources[0].displayName)
| project TimeGenerated, OperationName, Result, Actor, TargetUser, TargetName, IPAddress, CorrelationId
| order by TimeGenerated desc
What it revealed A new authentication method was added outside normal working hours, against an account that had already shown suspicious sign-in activity.
No malware required The attacker did not need to deploy a payload. Identity control was the persistence mechanism.
The pattern was there The method registration, sign-in timing and account behaviour formed a timeline that explained the compromise.

Agent Foskett moment

Everyone focused on the password. Nobody looked at the authentication methods.
The password was changed That was the obvious response. But changing the password did not answer the bigger question: what else had changed on the account?
The method stayed trusted If an attacker registers their own authentication method, a simple password reset may not be enough.

This is where strong identity and access governance matters.
The audit trail told the story The logs showed the operation, the target account, the timing and the correlation evidence needed to confirm what happened.
What it was not It was not just a failed login. It was not just a risky sign-in. It was not just a user forgetting their password.
What it actually was Account persistence through security information manipulation. The attacker added a trusted method and kept a door open.
Why it matters MFA only helps when the registered methods are legitimate. A trusted method controlled by an attacker changes the entire investigation.

What most environments miss

MFA registration activity should be treated as security-sensitive evidence, not routine account noise.
Password resets are not enough When an account is suspected of compromise, review authentication methods, sessions, tokens, app consents and mailbox rules.
Security info changes need monitoring New phone numbers, authenticator apps, FIDO keys and alternate methods should be visible to security operations.
The missing skill The investigation is not just whether MFA exists. It is whether MFA still belongs to the user.

Related investigations

The MFA Prompt Looked Normal MFA prompts can look legitimate while hiding risky user behaviour or attacker pressure. Read more →
The User Passed MFA But It Wasn't Really Them Valid authentication does not always mean legitimate access when tokens, sessions and devices are abused. Read more →
The OAuth App Asked For Permission Consent abuse can create long-lived access even after the original sign-in looks resolved. Read more →
The Inbox Rule Hid The Evidence Mailbox rules are another common persistence and concealment technique after account compromise. Read more →
KQL Threat Hunting Guide Build practical Microsoft Defender XDR and Sentinel investigations across identity, endpoint and cloud signals. Read more →
The attacker did not bypass MFA.
They registered themselves into it.
Contact GEMXIT

Final thought

MFA is not just a setting. It is an identity trust relationship.
At GEMXIT We help organisations investigate identity compromise, validate MFA controls and understand what their Microsoft security telemetry is already trying to show them. If you want to understand how this applies to your environment, see our Cyber Security services.
Agent Foskett mindset Do not just ask whether MFA is enabled. Ask who owns the method, when it was added, where it was added from and whether the user actually did it.

If your audit logs are already telling the story, the next step is making sure your Microsoft 365 environment is tuned to surface it. 👉 Strengthen identity and access visibility

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Microsoft 365 MFA Method Registration Investigation

This Agent Foskett briefing explains how suspicious MFA method registration can indicate Microsoft 365 account compromise. Attackers may add their own authentication method after gaining access, allowing continued access even after a password reset.

Detect Suspicious Authentication Method Changes in Entra ID

Microsoft Entra ID audit logs can help defenders investigate security information changes, authentication method registration, MFA updates and suspicious after-hours account activity using KQL and Microsoft Sentinel.

Why Password Resets Are Not Enough After Account Compromise

When a Microsoft 365 account is suspected of compromise, defenders should review MFA methods, authentication registrations, sessions, tokens, mailbox rules and OAuth app consent rather than relying on password resets alone.