Agent Foskett Academy • KQL Academy • Module 11 • Lesson 133

Lesson 133 — Detecting Newly Registered MFA Methods

An attacker who gains access to an account does not always stop at signing in.

If they can register or change an authentication method, they may create a new way back into the identity. The dangerous part is that the change itself can look like ordinary account maintenance unless somebody asks who made it, when it happened, and what authentication activity surrounded it.

In this lesson we move from SigninLogs into AuditLogs, hunt authentication-method changes, identify the initiating identity or application, inspect modified properties and correlate the change with the user's sign-in timeline.

A new authentication method is not just a configuration change. During an investigation, it can be a persistence clue.

Start Lesson 133 Back to KQL Academy

Agent Foskett KQL Academy authentication method investigation

What you will investigate

A new authentication method appears on a user's identity after unusual sign-in activity.

✓ Hunt authentication-method changes

✓ Identify who initiated the change

✓ Inspect modified properties

✓ Correlate AuditLogs with SigninLogs

The investigation begins

02:51 UTC ↓ Unusual sign-in activity ↓ 03:06 Successful authentication ↓ 03:14 Authentication method changes ↓ The account now has a method the analyst did not expect ↓ QUESTION Did the user legitimately update their security information... or did someone create a new route back into the account?

Learning objectives

Use Microsoft Entra audit telemetry to hunt authentication-method changes, identify the actor and target, inspect the recorded changes and correlate those events with surrounding sign-in activity.

Why AuditLogs?

SigninLogs tells us about authentication attempts. AuditLogs records changes made in the tenant. When the investigation question becomes “what changed on this identity?”, audit telemetry is the natural place to pivot.

Step 1 — discover authentication-method activity

Do not assume the exact operation wording before looking at your own tenant. Start by finding relevant UserManagement activity and inspect the operation names your environment records.

123456789101112131415

AuditLogs
| where TimeGenerated > ago(7d)
| where Category =~ "UserManagement"
| where OperationName has_any (
    "authentication method",
    "security info",
    "MFA"
)
| project TimeGenerated,
          OperationName,
          Result,
          ResultReason,
          InitiatedBy,
          TargetResources
| order by TimeGenerated desc

Why start broad?

Audit activity names and details can differ depending on the authentication method and workflow. Discovery first prevents a hunting query from silently missing events because it was written around one expected string.

Registration is not automatically suspicious

Users legitimately replace phones, add passkeys, configure Authenticator, register security keys and update recovery information. The investigation begins when the timing or surrounding evidence makes the change unusual.

Step 2 — focus on the target identity

Expand TargetResources so the investigation can isolate changes associated with the user under review.

1234567891011121314151617

let TargetUser = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(30d)
| where Category =~ "UserManagement"
| mv-expand Target = TargetResources
| where tostring(Target.userPrincipalName) =~ TargetUser
| where OperationName has_any (
    "authentication method",
    "security info",
    "MFA"
)
| project TimeGenerated,
          OperationName,
          Result,
          InitiatedBy,
          Target
| order by TimeGenerated desc

TargetResources matters

Audit records can contain structured target information. Expanding the field makes it easier to identify the affected user and later inspect the properties that changed.

Ask the obvious question

Was the user expecting to register a new method? If the answer is yes, verify the timing and method. If the answer is no, the event immediately deserves deeper investigation.

Step 3 — identify who initiated the change

InitiatedBy can identify a user or application associated with the audit event. Extract both possibilities rather than assuming every change was user-driven.

12345678910111213141516171819

let TargetUser = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(30d)
| mv-expand Target = TargetResources
| where tostring(Target.userPrincipalName) =~ TargetUser
| where OperationName has_any (
    "authentication method",
    "security info",
    "MFA"
)
| extend ActorUPN = tostring(InitiatedBy.user.userPrincipalName),
         ActorApp = tostring(InitiatedBy.app.displayName)
| project TimeGenerated,
          OperationName,
          Result,
          ActorUPN,
          ActorApp,
          TargetResources
| order by TimeGenerated desc

User initiated?

If the user initiated the change, compare that identity activity with their sign-in history. A self-service change performed during an unfamiliar session may still be suspicious.

Application initiated?

Automation and administrative workflows can legitimately perform directory changes. An application actor changes the investigation question: is this expected automation, an administrative action or something requiring escalation?

Step 4 — inspect what changed

Expand the target's modifiedProperties collection. This can reveal useful old/new values or property names recorded with the event.

123456789101112131415161718192021

let TargetUser = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(30d)
| mv-expand Target = TargetResources
| where tostring(Target.userPrincipalName) =~ TargetUser
| where OperationName has_any (
    "authentication method",
    "security info",
    "MFA"
)
| mv-expand Property = Target.modifiedProperties
| extend PropertyName = tostring(Property.displayName),
         OldValue = tostring(Property.oldValue),
         NewValue = tostring(Property.newValue)
| project TimeGenerated,
          OperationName,
          Result,
          PropertyName,
          OldValue,
          NewValue
| order by TimeGenerated desc

Do not rely on one property

Different authentication-method operations can expose different audit details. Treat the raw audit record as evidence and inspect what your tenant actually provides before turning an exploratory query into a detection rule.

Preserve the raw event

During a real incident, keep the original audit event as well as the parsed fields. Parsing makes investigation easier, but the unmodified record is valuable when you need to validate exactly what Microsoft Entra logged.

Step 5 — correlate the change with sign-ins

The method change becomes much more meaningful when placed beside authentication activity. Here we build a small ±2 hour window around each relevant audit event and bring nearby sign-ins into the same timeline.

12345678910111213141516171819202122232425262728293031323334353637

let TargetUser = "alex.wilson@contoso.com";
let ChangeTimes =
    AuditLogs
    | where TimeGenerated > ago(7d)
    | mv-expand Target = TargetResources
    | where tostring(Target.userPrincipalName) =~ TargetUser
    | where OperationName has_any (
        "authentication method",
        "security info",
        "MFA"
    )
    | project AuditTime=TimeGenerated,
              OperationName,
              AuditResult=Result;
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ TargetUser
| project SignInTime=TimeGenerated,
          IPAddress,
          Location,
          AppDisplayName,
          ResultType,
          ConditionalAccessStatus,
          AuthenticationRequirement
| extend JoinKey = 1
| join kind=inner (ChangeTimes | extend JoinKey = 1) on JoinKey
| where SignInTime between (AuditTime - 2h .. AuditTime + 2h)
| project AuditTime,
          OperationName,
          AuditResult,
          SignInTime,
          IPAddress,
          Location,
          AppDisplayName,
          ResultType,
          ConditionalAccessStatus
| order by AuditTime asc, SignInTime asc

What are we looking for?

Look for an unfamiliar IP or location immediately before the change, a successful sign-in from a new device, repeated failures followed by success, or application access that does not fit the user's normal behaviour.

Timing can change the case

A method added during a normal help-desk session at 10:00 may be expected. The same change at 03:14, minutes after an anomalous sign-in, has a very different investigative context.

Microsoft Entra also provides registration reporting

The Authentication methods Activity experience can show registration and usage information, including recent registration events. That is useful operational context. In the KQL Academy, however, we are deliberately learning to work from exported activity logs so we can correlate the identity change with the rest of the investigation.

Evidence table

Observation	What it tells us	What it does not prove
Authentication method changed	A security-information-related change was recorded.	That the change was malicious.
User appears in TargetResources	The audit event affected the identity under investigation.	Who controlled the session at the time.
User appears in InitiatedBy	The event was associated with that initiating identity.	That the legitimate human user performed it.
New method after unusual sign-in	The change occurred near suspicious authentication activity.	That the two events share malicious intent without further evidence.
Unfamiliar IP before the change	The preceding session differs from observed history.	That the IP belongs to an attacker.
User denies making the change	The event conflicts with the user's account of activity.	Everything else that happened in the session.

Agent Foskett's investigation

02:51 Unusual sign-in attempts begin ↓ 03:06 A sign-in succeeds ↓ The source is unfamiliar ↓ 03:14 AuditLogs records an authentication-method change ↓ KQL identifies the target user ↓ InitiatedBy is inspected ↓ Modified properties are reviewed ↓ SigninLogs is brought into the timeline ↓ The change occurred minutes after the unusual session ↓ The user is asked whether the registration was expected ↓ The answer is no ↓ The authentication-method event is no longer routine administration ↓ It is evidence of possible identity persistence

The attacker did not merely get in. The investigation now asks whether they tried to make sure they could get back in.

Investigation questions to ask next

Exactly which authentication method was added, changed or removed?
Who or what initiated the audit event?
Was the user expecting to change their security information?
What sign-in occurred immediately before the change?
Did the source IP, location, application and device fit the user's baseline?
Were other authentication methods changed during the same session?
Were sessions revoked or credentials reset afterwards?
Did the account access email, cloud resources or privileged functions after the change?
Did similar authentication-method changes occur on other users?

Lesson 133 key takeaways

Authentication-method changes belong in identity investigations.
Use AuditLogs when the question is what changed in Microsoft Entra.
Discover the operation names present in your tenant before making narrow assumptions.
TargetResources helps identify the affected identity.
InitiatedBy helps identify the user or application associated with the change.
Modified properties can reveal useful before-and-after evidence.
A legitimate configuration action can become suspicious because of timing and context.
Correlate method changes with SigninLogs rather than investigating them in isolation.
Preserve raw audit evidence alongside parsed fields.
A newly registered method can represent persistence after identity compromise.

Continue your KQL investigation training

Lesson 133 continues Module 11: Identity Threat Hunting. Next we investigate why a Conditional Access result can be useful evidence without telling the whole story.

KQL Academy Lesson 132 — Hunting MFA Fatigue Microsoft Entra Security Academy Agent Foskett Academy

Related Agent Foskett Investigations

Continue the identity investigation beyond the lesson. These related cases reinforce the same principle: authentication evidence must be correlated with what changed and what happened next.

The MFA Prompt Looked Normal Impossible Travel Sign-In Investigation The OAuth App Asked For Permission Browse Agent Foskett Investigations

🔎 KQL Academy — Module 11: Identity Threat Hunting

Use KQL to investigate identity behaviour as evidence.

⬅ Previous lesson

Lesson 132 — Hunting MFA Fatigue and Repeated Authentication AttemptsFind authentication pressure and suspicious failure-to-success sequences.

✅ Current lesson

Lesson 133 — Detecting Newly Registered MFA MethodsInvestigate authentication-method changes as possible identity persistence.

Next lesson

Lesson 134 — The Conditional Access Result Didn't Tell the Whole StoryUse KQL to investigate what a Conditional Access outcome does — and does not — prove.

Detect newly registered MFA methods with KQL

Lesson 133 of the Agent Foskett KQL Academy teaches analysts how to investigate Microsoft Entra authentication-method changes using AuditLogs, TargetResources, InitiatedBy, modified properties and surrounding SigninLogs activity.

Microsoft Entra authentication method investigation

Authentication method registrations and changes can be legitimate user activity or evidence of persistence after account compromise. KQL helps analysts place the change into an identity timeline and test whether the surrounding evidence supports a benign or malicious explanation.