Agent Foskett Case File • Microsoft Entra ID • AuditLogs • SigninLogs • Password Reset • Identity Investigation
The User Didn't Reset Their Password — Someone Else Did
The user called the service desk with a simple problem.
Their password no longer worked.
They had not changed it.
They had not requested a reset.
They had not spoken to the help desk earlier that day.
But Microsoft Entra ID showed that the credential had changed.
Agent Foskett had two questions.
Who changed the password?
And more importantly:
What happened to the account after they did?
The Password Changed. The User Didn't Change It.
A password reset is an identity event. The audit trail can show who initiated the operation, which account was targeted and when the change occurred. The sign-in timeline shows what happened next.
✓ Identify the password-reset event
✓ Determine the initiating identity
✓ Investigate post-reset sign-ins
The user denial mattered
Users forget passwords. Administrators reset passwords. Self-service password reset exists for exactly this kind of operational problem.
But when the user explicitly denies making or requesting the change, the reset becomes an investigation point.
Agent Foskett did not assume compromise from the denial alone.
He went to the audit evidence to establish what actually happened.
But when the user explicitly denies making or requesting the change, the reset becomes an investigation point.
Agent Foskett did not assume compromise from the denial alone.
He went to the audit evidence to establish what actually happened.
Start with Microsoft Entra AuditLogs
Password-management operations can be recorded in Microsoft Entra audit telemetry. Agent Foskett searched
Rather than relying on one exact activity-name string, he began broadly and reviewed the returned operations.
AuditLogs for password-related activity involving the affected user.Rather than relying on one exact activity-name string, he began broadly and reviewed the returned operations.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
let User = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(7d)
| where ActivityDisplayName has "password"
| where tostring(TargetResources) has User
| project TimeGenerated,
ActivityDisplayName,
Result,
InitiatedBy,
TargetResources,
CorrelationId
| order by TimeGenerated ascThe reset event was only the beginning
The audit record established that a password-related operation had occurred against the account.
But the activity name alone was not enough. Agent Foskett needed the initiating identity, target account, result and timestamp.
A password changed. The investigation had to determine who caused the change.
But the activity name alone was not enough. Agent Foskett needed the initiating identity, target account, result and timestamp.
A password changed. The investigation had to determine who caused the change.
Who initiated the operation?
The
InitiatedBy field can contain information about the user or application associated with an audit operation. Agent Foskett expanded the relevant values rather than treating the field as a simple username.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
let User = "alex.wilson@contoso.com";
AuditLogs
| where TimeGenerated > ago(7d)
| where ActivityDisplayName has "password"
| where tostring(TargetResources) has User
| extend InitiatingUser =
tostring(InitiatedBy.user.userPrincipalName),
InitiatingApp =
tostring(InitiatedBy.app.displayName)
| project TimeGenerated,
ActivityDisplayName,
Result,
InitiatingUser,
InitiatingApp,
TargetResources,
CorrelationId
| order by TimeGenerated ascThe initiator changed the case
If the event had been initiated through an expected self-service flow, that would lead the investigation in one direction.
If an administrator had reset the password, Agent Foskett would need to establish whether the administrator was authorised and whether the action matched a genuine support request.
If an unexpected identity or application appeared, the event required immediate additional scrutiny.
The target told him whose password changed. The initiator told him where to investigate next.
If an administrator had reset the password, Agent Foskett would need to establish whether the administrator was authorised and whether the action matched a genuine support request.
If an unexpected identity or application appeared, the event required immediate additional scrutiny.
The target told him whose password changed. The initiator told him where to investigate next.
Do not confuse reset with change
Password events can represent different workflows. A user changing their own known password is not the same investigative scenario as another identity resetting a password.
Agent Foskett preserved the exact
Terminology matters because the operation describes the path taken.
Agent Foskett preserved the exact
ActivityDisplayName returned by the tenant rather than collapsing every password-related audit event into the same category.Terminology matters because the operation describes the path taken.
Investigation principle: Record the exact audit operation before deciding what the event means.
What happened immediately after the reset?
Identifying the reset was not enough.
If an attacker had obtained control of the credential, the next evidence might appear in the account's sign-in activity.
Agent Foskett pivoted to
If an attacker had obtained control of the credential, the next evidence might appear in the account's sign-in activity.
Agent Foskett pivoted to
SigninLogs and built a timeline around the reset.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
let User = "alex.wilson@contoso.com";
let ResetTime = datetime(2026-09-30 08:42:00);
SigninLogs
| where TimeGenerated between
(ResetTime - 30m .. ResetTime + 4h)
| where UserPrincipalName =~ User
| project TimeGenerated,
AppDisplayName,
IPAddress,
Location,
ResultType,
ResultDescription,
ConditionalAccessStatus,
AuthenticationRequirement
| order by TimeGenerated ascThe first successful sign-in mattered
Agent Foskett paid particular attention to the first successful authentication after the password event.
Was it from the user's normal location and device context? Did it target an expected application? Was the IP address familiar? Did the authentication requirements match normal behaviour?
A successful sign-in after a password reset does not automatically prove malicious use.
But it can establish that the new credential was followed by account activity.
Was it from the user's normal location and device context? Did it target an expected application? Was the IP address familiar? Did the authentication requirements match normal behaviour?
A successful sign-in after a password reset does not automatically prove malicious use.
But it can establish that the new credential was followed by account activity.
Compare the account before and after the reset
A single sign-in is easier to interpret when compared with the user's recent baseline. Agent Foskett summarised sign-in activity around the account to identify changes in IP address, application and location.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let User = "alex.wilson@contoso.com";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ User
| summarize SignIns=count(),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated)
by IPAddress,
AppDisplayName,
tostring(Location)
| order by LastSeen descNew did not automatically mean malicious
A new IP address or location can be important, but it can also be explained by travel, mobile networks, VPNs, cloud egress or other legitimate changes.
Agent Foskett treated novelty as an investigative lead and correlated it with the reset initiator, authentication details, application access and the wider timeline.
Unfamiliar is a reason to investigate. It is not a verdict.
Agent Foskett treated novelty as an investigative lead and correlated it with the reset initiator, authentication details, application access and the wider timeline.
Unfamiliar is a reason to investigate. It is not a verdict.
Was the administrator account legitimate?
If the password was reset by an administrator, the investigation did not stop simply because the initiator had permission to perform the action.
Agent Foskett checked whether the administrator normally performed password resets, whether there was a corresponding support request, whether the administrator's own sign-ins were expected and whether other unusual administrative operations occurred nearby.
Authorisation tells you what an identity could do. Audit evidence helps establish what it actually did.
Agent Foskett checked whether the administrator normally performed password resets, whether there was a corresponding support request, whether the administrator's own sign-ins were expected and whether other unusual administrative operations occurred nearby.
Authorisation tells you what an identity could do. Audit evidence helps establish what it actually did.
Search for other password operations by the same initiator
One reset might be a support action. Multiple unexpected resets by the same identity could indicate a wider problem. Agent Foskett scoped password activity associated with the initiator.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
let Initiator = "helpdesk.admin@contoso.com";
AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName has "password"
| extend InitiatingUser =
tostring(InitiatedBy.user.userPrincipalName)
| where InitiatingUser =~ Initiator
| project TimeGenerated,
ActivityDisplayName,
Result,
TargetResources,
CorrelationId
| order by TimeGenerated descThe password reset could be the beginning — not the objective
Changing a credential can be a means of gaining or maintaining control of an identity rather than the final action.
Agent Foskett therefore looked beyond the reset for subsequent sign-ins, application access and other identity changes supported by the available telemetry.
If the investigation uncovered additional changes — such as authentication-method modifications or privileged operations — those events would become separate evidence points in the same timeline.
The credential event told him where to start. The activity afterward told him why it mattered.
Agent Foskett therefore looked beyond the reset for subsequent sign-ins, application access and other identity changes supported by the available telemetry.
If the investigation uncovered additional changes — such as authentication-method modifications or privileged operations — those events would become separate evidence points in the same timeline.
The credential event told him where to start. The activity afterward told him why it mattered.
Build the identity timeline
Agent Foskett organised the evidence chronologically.
User last signs in normallyEstablish the account's activity before the credential event.
Password operation occursRecord the exact audit activity, result, target and timestamp.
Initiator identifiedDetermine which user, application or workflow initiated the operation.
First post-reset sign-inIdentify the first account activity following the password event.
Behaviour scopedCompare IPs, locations, applications and other identity activity.
Reset explainedDetermine whether the evidence supports an authorised action, user workflow or suspicious identity takeover.
What Agent Foskett checked
Exact operationWas the event a password change, reset or another password-management action?
Initiating identityWho or what initiated the audit operation?
Target identityWhich user's credential was affected?
Post-reset sign-insWhere and how was the account used afterward?
Initiator activityDid the same identity perform similar operations elsewhere?
Support contextWas there a legitimate business reason or help-desk request explaining the reset?
What the evidence can and cannot prove
An Entra audit event can establish that a recorded password-management operation occurred and provide context about the target and initiator where that information is present.
It does not automatically establish malicious intent.
Likewise, a successful sign-in after the reset can show subsequent account use, but analysts still need to evaluate IP, application, authentication, device and business context before attributing that use to an attacker.
Prove the operation. Identify the initiator. Then investigate the consequences.
It does not automatically establish malicious intent.
Likewise, a successful sign-in after the reset can show subsequent account use, but analysts still need to evaluate IP, application, authentication, device and business context before attributing that use to an attacker.
Prove the operation. Identify the initiator. Then investigate the consequences.
The lesson
The user said they had not reset their password.
Agent Foskett did not choose between believing the user and believing the system.
He used the system to reconstruct the event.
A password reset is not just a credential event. It can be the pivot point for an identity investigation.
Agent Foskett did not choose between believing the user and believing the system.
He used the system to reconstruct the event.
AuditLogs established the password operation and its initiator. SigninLogs showed what happened to the account around and after the change. The wider audit trail helped determine whether the initiator's activity was expected.A password reset is not just a credential event. It can be the pivot point for an identity investigation.
Investigation principle: When a user denies changing a credential, identify who initiated the operation before deciding what happened.
Related investigations
Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingExplore practical investigation techniques across Microsoft Defender XDR and Microsoft Sentinel.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
Final thought
A user saying “I didn't do that” is not the conclusion.
It is the beginning of the investigation.
Find the credential event. Preserve the exact audit operation. Identify the initiating identity. Then follow the account activity that came afterward.
The password had changed.
The user hadn't changed it.
The audit trail knew who had.
Follow the evidence. Build the timeline.
The Logs Already Knew! 🔎
It is the beginning of the investigation.
Find the credential event. Preserve the exact audit operation. Identify the initiating identity. Then follow the account activity that came afterward.
The password had changed.
The user hadn't changed it.
The audit trail knew who had.
Follow the evidence. Build the timeline.
The Logs Already Knew! 🔎
