Agent Foskett Investigation • Microsoft Entra ID • Passkeys • Authentication Methods • AuditLogs • SigninLogs • KQL
The User Changed Their Password — But the Attacker Added a Passkey
The user reported the suspicious sign-in.
Their password was changed immediately.
The team expected the stolen credential to be useless.
Then another authentication event appeared.
Agent Foskett went back through the Microsoft Entra audit trail.
Eleven minutes before the password reset, a new authentication method had been registered.
It wasn't another password.
It was a passkey.
A Password Reset Does Not Remove Every Authentication Method
When an account is compromised, investigate changes to the identity itself. A newly registered authentication method can change the containment story.
✓ Establish the suspicious sign-in
✓ Find authentication-method changes
✓ Correlate registration with later sign-ins
The password reset looked like containment
Changing the compromised password was sensible, but Agent Foskett treated it as one containment action rather than proof that every authentication path had been removed. The next question was whether anything about the user's authentication methods had changed during the compromise window.
Suspicious sign-inThe incident began with authentication activity the user did not recognise.
Password changedThe known credential was replaced as part of the response.
Identity changed tooThe audit trail showed that another authentication method had been registered before containment.
Start with the suspicious sign-in
Capture the authentication event that established the compromise window. Record the source IP, application, authentication details, device context and result so later identity changes can be placed against a reliable timeline.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ User
| project TimeGenerated,
AppDisplayName,
IPAddress,
ResultType,
AuthenticationDetails,
AuthenticationRequirement,
DeviceDetail
| order by TimeGenerated ascHunt for authentication-method changes
Microsoft Entra AuditLogs can record changes to a user's authentication methods. Search the compromise window for successful registration, addition or update operations involving the affected identity.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
let User = "alex@contoso.com";
AuditLogs
| where TimeGenerated > ago(7d)
| where tostring(TargetResources) has User
| where OperationName has_any
("authentication method", "passkey", "FIDO")
| project TimeGenerated,
OperationName,
InitiatedBy,
TargetResources,
AdditionalDetails,
Result
| order by TimeGenerated ascThe registration happened before the password reset
Timing changed the meaning of the event. The passkey registration occurred after the suspicious sign-in but before the response team changed the user's password. That sequence made the authentication-method change part of the compromise timeline rather than an unrelated configuration event.
03:11 — suspicious sign-inThe unfamiliar authentication established the start of the investigation window.
03:22 — passkey registeredA new authentication method appeared while the suspicious session was active.
03:37 — password resetThe known password changed after the new authentication method had already been added.
Who initiated the registration?
The operation name alone is not enough. Inspect the initiating identity and related audit fields. Depending on the registration flow and available telemetry, the event may identify the user, application or administrative context responsible for the change.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any
("passkey", "FIDO", "authentication method")
| extend InitiatingUser =
tostring(InitiatedBy.user.userPrincipalName),
InitiatingApp =
tostring(InitiatedBy.app.displayName)
| project TimeGenerated,
OperationName,
InitiatingUser,
InitiatingApp,
TargetResources,
ResultDid later sign-ins use a different authentication method?
Return to SigninLogs after the password reset and inspect AuthenticationDetails. The goal is not to infer passkey use from timing alone, but to determine whether the sign-in evidence identifies an authentication method consistent with the newly registered credential.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ User
| project TimeGenerated,
AppDisplayName,
IPAddress,
ResultType,
AuthenticationDetails,
AuthenticationRequirement
| order by TimeGenerated ascInventory the identity, not just the password
An account recovery investigation should review the authentication methods attached to the identity and compare them with what the user and organisation expect. Unexpected methods deserve validation and, where appropriate, removal through the organisation's approved response process.
Known methodsEstablish which authentication methods legitimately belonged to the user before the incident.
New methodsIdentify additions or changes during the compromise window.
Containment stateVerify that unauthorised methods and sessions have been addressed rather than relying on the password reset alone.
What the evidence can and cannot prove
A suspicious sign-in followed by an unexpected passkey registration is important correlation, but timing alone does not prove who physically registered the credential. The conclusion should reflect the audit fields, user validation, sign-in evidence and authentication-method details actually available.
ProvenThe audit trail can establish when an authentication method was registered and which identity was targeted.
Strong correlationA registration immediately after suspicious authentication can materially change the compromise assessment.
Do not overclaimAttribute the registration to an attacker only when the combined evidence supports that conclusion.
Build the identity-persistence timeline
Place authentication and identity changes into one chronological view. This prevents the password reset from becoming an artificial endpoint when the attacker may have changed the account before the response began.
Initial accessEstablish the suspicious authentication event and session context.
Identity changeRecord the passkey or authentication-method registration with its initiator and timestamp.
RecoveryTrack password changes, session revocation, method removal and the final verification that suspicious access stopped.
Agent Foskett's investigation mindset
A password is only one way an identity can authenticate. During account compromise, investigate the identity's authentication configuration as carefully as its sign-in history.
Ask what changedLook beyond the original credential and inspect authentication-method lifecycle events.
Use the timelineA method added during the compromise window carries different meaning from one registered months earlier.
Verify recoveryContainment should address unauthorised authentication paths, active sessions and the compromised credential.
Investigation findings
The password reset was not the complete containment story. Microsoft Entra audit telemetry showed that a new passkey authentication method had been registered after the suspicious sign-in and before the response began. By correlating AuditLogs with SigninLogs and authentication details, the analyst could determine whether later access was consistent with the newly added method and expand recovery beyond the password alone.
The identity had changedThe compromise window contained more than suspicious authentication; it contained an authentication-method change.
The password reset was only one controlChanging one credential did not answer whether other authorised authentication methods remained.
The audit trail exposed persistenceIdentity configuration events revealed the clue that sign-in review alone could have missed.
Related Agent Foskett investigations
Continue with authentication-method, OAuth and Microsoft Entra identity investigations.
The New MFA Method Was Registered 11 Minutes After the LoginInvestigate a suspicious authentication-method change immediately after a sign-in.The OAuth App Was Deleted — But the Permission Grant Was Still ThereReconstruct consent and permissions after an application identity disappears.Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
Final thought
Password resets matter, but modern identity investigations cannot stop at passwords. If an attacker gains sufficient access to alter authentication methods, the identity itself may have changed before anyone begins containment. Follow the audit trail, inventory the expected methods, correlate later sign-ins and verify recovery. The password may be new. The attacker's way back in may be newer.
What authentication changed?Search the compromise window for new or modified authentication methods.
What happened after the reset?Inspect later sign-ins and authentication details instead of assuming the new password ended access.
Is the identity actually recovered?Verify authentication methods and sessions as part of containment.
