Detecting Help Desk MFA Reset Abuse: Entra Sign-In Logs and Sentinel KQL

Retrospective: this article looks back at events from April 2025, written in 2026 with the benefit of hindsight.

After help desk social engineering, attackers typically reset MFA, register their own method and sign in. These detections connect those events.

Signals worth watching

• MFA methods deleted and new ones registered for a user within a short window.
• New MFA method registration from an IP, country or device not associated with the user.
• Registration of authenticator apps on new device types.
• Sign-ins with newly registered methods followed by access to admin portals, file shares or identity infrastructure.
• Help desk resets of privileged accounts.

Where the data lives

• Entra ID audit logs: "User registered security info," "Admin deleted security info," "User deleted security info," "User changed default security info."
• Entra ID sign-in logs.
• Ticketing system records for reset requests.

A starting query

New security info registration followed by risky sign-in:

let reg = AuditLogs
| where OperationName in ("User registered security info", "User registered all required security info")
| extend UPN = tostring(TargetResources[0].userPrincipalName), RegIP = tostring(InitiatedBy.user.ipAddress)
| project RegTime = TimeGenerated, UPN, RegIP;
SigninLogs
| where ResultType == "0"
| join kind=inner reg on $left.UserPrincipalName == $right.UPN
| where TimeGenerated between (RegTime .. RegTime + 4h)
| where IPAddress != RegIP or RiskLevelDuringSignIn in ("medium", "high")
| project RegTime, TimeGenerated, UserPrincipalName, RegIP, IPAddress, Location, AppDisplayName

Response

1. Contact the user via a separate, known channel.
2. Remove attacker-registered methods and revoke sessions.
3. Review help desk records for the request.
4. Check for privilege escalation and lateral movement.