Agent Foskett Case File • Microsoft Entra ID • Password Authentication • Sign-in Logs • KQL

The Password Was Correct — But Nobody Had Typed It

The sign-in was successful.

The password was accepted.
The application opened.
The account belonged to a real employee.

There was just one problem.

The employee had been asleep when it happened.

Someone had authenticated as them — and the logs were about to tell Agent Foskett how.

Discuss Microsoft Security Back to investigations

Agent Foskett investigating a suspicious successful Microsoft Entra ID password sign-in

A Successful Sign-in Is Not Proof of the Right Person.

The identity platform records authentication evidence. The investigator must establish who controlled the credentials and session.

✓ Examine authentication steps

✓ Correlate interactive and non-interactive sign-ins

✓ Follow the evidence before declaring compromise

The sign-in that did not belong

At 02:14, Microsoft Entra ID recorded a successful sign-in to a business application.

The account was familiar. The password-based authentication step had succeeded. The IP address and device context, however, did not match the employee’s normal pattern.

When contacted, the employee said they had not used the application that night.

“Interesting,” Agent Foskett muttered. “The password worked. That doesn’t tell us who used it.”

The case began with an inconsistency, not a verdict.

What the sign-in record actually said

Agent Foskett separated three questions:

Was a sign-in successful? The status and result code could answer that.

What authentication steps were recorded? The authentication details could help establish whether a password, passwordless method or another step was involved.

Was the person using the account its legitimate owner? That required corroboration beyond a successful sign-in.

A password step marked successful does not prove that the owner typed the password. A passwordless sign-in or an existing token should not be described as a fresh password entry without evidence.

Start with successful interactive sign-ins

In a Microsoft Sentinel workspace receiving Microsoft Entra ID sign-in logs, Agent Foskett filtered the interactive sign-in table for the account and projected the fields needed for triage. Replace the example account and adjust the investigation period.

let TargetUser = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ TargetUser
| where ResultType == "0"
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          IPAddress,
          Location,
          ClientAppUsed,
          AuthenticationRequirement,
          AuthenticationDetails,
          ConditionalAccessStatus,
          DeviceDetail,
          CorrelationId
| order by TimeGenerated asc

The authentication detail mattered

The AuthenticationDetails field can contain multiple steps with different methods, outcomes and processing details. Agent Foskett examined the original record rather than assuming every successful sign-in meant a newly typed password.

For this fictional case, the relevant step was reported as a successful password authentication. That narrowed the possibilities, but did not establish how the credentials had been obtained.

Some authentication details can be incomplete or updated after initial log processing. They should be interpreted alongside the overall result and other evidence.

Expand the recorded authentication steps

The next query expands the dynamic authentication-step array, making it easier to compare methods and outcomes across sign-ins.

let TargetUser = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ TargetUser
| mv-expand Step = AuthenticationDetails
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          IPAddress,
          ResultType,
          Method = tostring(Step.authenticationMethod),
          StepSucceeded = tostring(Step.succeeded),
          StepDetail = tostring(Step.authenticationStepResultDetail),
          CorrelationId
| order by TimeGenerated asc

The IP address was unfamiliar — not automatically malicious

The suspicious sign-in came from an address the employee did not recognise. Agent Foskett compared its geography, network ownership and historical use with the employee’s normal sign-in pattern.

VPNs, proxies, travel and cloud-hosted egress can produce unexpected locations. A different country or ASN is a reason to investigate, not standalone proof of account takeover.

In this case, the unfamiliar network became more significant when combined with the employee’s statement and the subsequent activity.

Check what happened after authentication

The attacker might have used the successful interactive session to obtain tokens and continue accessing resources without typing the password again. Agent Foskett therefore checked non-interactive sign-ins, which may record token-based background access.

Important: Non-interactive sign-in activity is not, by itself, evidence of stolen tokens. Legitimate applications also refresh and use tokens.

let TargetUser = "alex@contoso.com";
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          ResourceDisplayName,
          IPAddress,
          ResultType,
          ClientAppUsed,
          CorrelationId
| order by TimeGenerated asc

The second clue was the application activity

After the suspicious sign-in, application audit records showed access to information the employee normally used only during working hours.

Agent Foskett aligned the application events with the sign-in time, IP address, user identity and available session identifiers. The sequence supported unauthorised use of the account, although the sign-in record alone could not prove the original theft mechanism.

“The door opened with a valid key,” he said. “Now we need to know who had the key.”

Do not confuse passwordless access with password theft

An important alternative was a legitimate passwordless method, such as a passkey or Windows Hello for Business. Another was continued access using an existing session or refresh token.

Agent Foskett checked the authentication method actually recorded for the event and did not label token refreshes as new password submissions.

If the logs showed passwordless authentication, the investigation would need to examine registered methods, devices and authentication-method changes instead. The technique must follow the evidence, not the headline.

Review Conditional Access in context

The successful sign-in also had a Conditional Access outcome. Agent Foskett checked which policies applied, whether controls were satisfied and whether any policy was excluded or not enforced.

ConditionalAccessStatus provides a useful starting point, but policy details and the sign-in record must be reviewed together. A success result does not mean every possible security control was required or that the session was trustworthy.

02:14 — Successful sign-inA password authentication step is recorded for the employee account.

Unfamiliar networkThe IP and device context differ from the employee’s normal activity.

Employee denies activityThe account owner confirms they were not using the application.

Follow-on accessApplication activity occurs after the suspicious sign-in.

Authentication evidence reviewedPassword, passwordless and token-based explanations are assessed separately.

Incident escalatedThe combined evidence supports suspected account compromise and a response.

What Agent Foskett checked

Result and statusDid Entra ID record a successful or failed authentication?

Authentication stepsWhich method was recorded, and did that step succeed?

IP and device contextWas the network or device consistent with known use?

Interactive versus non-interactiveWas this a new sign-in or background token activity?

Application audit trailWhat actions followed the suspicious authentication?

Policy and responseWhich controls applied, and what sessions or credentials require containment?

What the evidence can and cannot prove

A successful password authentication step supports the conclusion that password-based authentication succeeded for that event. It does not reveal whether the user typed the password, a password manager supplied it, or someone else used a stolen or otherwise obtained secret.

Sign-in records can establish the observed authentication flow, network context and application access. They do not independently prove the person behind the keyboard.

For this illustrative case, the combination of the employee’s denial, anomalous sign-in context and corroborating application activity justified treating the account as potentially compromised. The precise credential acquisition method remained unconfirmed.

Contain the account — and preserve the evidence

Once the incident met the organisation’s response threshold, the security team preserved relevant sign-in and application evidence, revoked active sessions where appropriate, reset compromised credentials, reviewed authentication methods and checked for persistence or additional affected accounts.

They also investigated how the password may have been exposed rather than assuming a reset alone resolved the root cause.

Response actions should be coordinated with the organisation’s incident-response procedures and the potential impact on legitimate access.

The lesson

The password was correct.

The identity was recognised.

The authentication service had done what it was asked to do.

But authentication success is not the same as identity assurance.

A valid credential can be used by the wrong person — and a good investigation proves the distinction with correlated evidence.

Investigation principle: Never infer who entered a credential merely because a password authentication step succeeded.

Related investigations

Agent Foskett InvestigationsExplore more identity, endpoint and cloud-security cases.AuthenticationDetails ExplainedUnderstand the authentication steps behind Microsoft Entra ID sign-ins.KQL Threat HuntingBuild evidence-led investigations with KQL.

Final thought

A successful login can be the beginning of an investigation, not the end of one.

The system recognised the secret.

Agent Foskett wanted to know who controlled it.

The password was correct. The person behind it was the question.

The Logs Already Knew! 🔎

The Password Was Correct — But Nobody Had Typed It

A Successful Sign-in Is Not Proof of the Right Person.

The sign-in that did not belong

What the sign-in record actually said

Start with successful interactive sign-ins

The authentication detail mattered

Expand the recorded authentication steps

The IP address was unfamiliar — not automatically malicious

Check what happened after authentication

The second clue was the application activity

Do not confuse passwordless access with password theft

Review Conditional Access in context

What Agent Foskett checked

What the evidence can and cannot prove

Contain the account — and preserve the evidence

The lesson

Related investigations

Final thought

The Password Was Correct — But Nobody Had Typed It

Investigate AuthenticationDetails with KQL

Investigate Account Compromise