Agent Foskett Investigation • Microsoft Entra ID • Session Theft • Defender XDR • KQL
The Password Was Never Stolen — The Browser Cookie Was
The user had MFA.
Their password had not been changed.
There was no obvious password spray.
Yet somebody was reading cloud data from a network the user had never used.
The first assumption was obvious.
“The attacker must have stolen the password.”
Agent Foskett looked at the evidence and asked a different question.
What if the attacker never needed the password at all?
Authentication Can Be Stolen After Authentication
A password and MFA establish a session. If an attacker steals a reusable session artifact, later access may not require the attacker to enter either one again.
✓ Separate credential theft from session theft
✓ Compare IP address, country and user agent
✓ Follow cloud activity after the original sign-in
The password evidence was strangely quiet
The account was clearly being used in a way the user could not explain, but the investigation did not show the pattern normally expected from a stolen password. There was no convincing run of failed attempts followed by success, no password change by the attacker and no reason to assume the password itself had ever left the user's control.
MFA had succeededThe legitimate user had authenticated earlier from their normal environment.
The password still workedThere was no evidence that the attacker had changed it to take ownership of the account.
Cloud activity still appearedMicrosoft 365 activity later came from network and client characteristics that did not fit the user's normal session.
Start with the activity the attacker actually performed
In Microsoft Defender XDR, CloudAppEvents can provide cloud application activity from connected services. Rather than beginning with the theory that a password was stolen, Agent Foskett starts with the affected account and looks for changes in IP address, country, user agent and other session context.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
let User = "alex@contoso.com";
CloudAppEvents
| where Timestamp > ago(7d)
| where AccountId =~ User
| project Timestamp, ActionType, Application,
IPAddress, CountryCode, City,
UserAgent, IsAnonymousProxy,
UncommonForUser, SessionData
| order by Timestamp asc
Investigation point: a cloud activity event associated with an account tells you which identity the service recorded. It does not automatically prove the account owner personally initiated that activity.
The timeline stopped looking like one continuous user session
The legitimate user was active from their normal Australian network and familiar browser. Minutes later, cloud activity appeared from a different source with client characteristics that did not match the expected pattern. That did not prove session-cookie theft by itself, but it was enough to stop treating the account history as one ordinary session.
08:42The user completes normal authentication and MFA from their expected device and network.
08:49The authenticated browser session is active.
09:03Cloud activity begins from a source IP and client context that do not fit the user.
09:05+The second activity stream continues without the investigation finding evidence that the attacker needed to enter the user's password again.
Group the account activity by IP address and user agent
A useful next step is to stop reading individual rows and identify distinct activity clusters. IP address and user-agent combinations can reveal that the same account is effectively operating from two different environments during the same investigation window.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
let User = "alex@contoso.com";
CloudAppEvents
| where Timestamp > ago(7d)
| where AccountId =~ User
| summarize FirstSeen=min(Timestamp),
LastSeen=max(Timestamp),
Events=count(),
Apps=make_set(Application, 20),
Countries=make_set(CountryCode, 10)
by IPAddress, UserAgent
| order by FirstSeen asc
MFA did not fail — it had already done its job
This is the part that can confuse an investigation. MFA can successfully protect the original authentication while an attacker later targets the authenticated session. A stolen browser session artifact can allow an attacker to replay an existing authenticated state rather than repeat the original password-and-MFA ceremony.
Password theftThe attacker obtains the user's secret and attempts to authenticate as the user.
Session theftThe attacker obtains a reusable session artifact after authentication has already occurred.
Different investigationThe second case requires investigators to follow session context and subsequent cloud actions, not only password events.
Important: successful MFA is not evidence that every later action associated with that account came from the person who completed MFA.
Did Defender already recognise the session behaviour?
Microsoft Defender XDR can surface detections related to stolen session cookies and attacker-in-the-middle activity when the required products, connectors and telemetry are available. Instead of hard-coding one exact alert title, hunt broadly for session-cookie and token-related alerts in the incident window.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
AlertInfo
| where Timestamp > ago(30d)
| where Title has_any
("session cookie", "AiTM", "anomalous token", "token")
| project Timestamp, Title, Severity,
Category, ServiceSource,
DetectionSource, AlertId
| order by Timestamp asc
Uncommon does not automatically mean malicious
An unusual IP address, country or user agent is a clue, not a verdict. VPNs, mobile networks, browser updates, travel, security proxies and cloud egress can all change session characteristics. The strength of the investigation comes from correlation: unusual session context, the timing after legitimate authentication, suspicious cloud activity and any Defender or Entra risk detections need to tell the same story.
One strange IP?Investigate it, but do not convict it.
One unfamiliar user agent?Compare it with the account's normal activity and device context.
Multiple aligned signals?That is where the session-theft hypothesis becomes substantially stronger.
What the evidence can and cannot prove
SupportedThe account generated cloud activity from session characteristics inconsistent with the user's expected environment.
Strongly supported with detectionA Defender session-cookie or AiTM detection, aligned with the same account and timeline, materially strengthens the token-replay conclusion.
Do not overclaimAn unfamiliar IP address alone does not prove a browser cookie was stolen, and the logs do not expose the stolen cookie value itself.
Contain the session — not just the password
If the evidence supports session theft, password remediation alone should not be treated as the entire response. Revoke active sign-in sessions where appropriate, investigate the endpoint and browser that originated the legitimate session, look for phishing or malware that could have captured session material, and review downstream cloud activity for persistence or data access.
Revoke sessionsForce the identity back through authentication rather than assuming a password change alone closes every active path.
Investigate the source deviceDetermine how the authenticated session artifact may have been obtained.
Scope the cloud activityFollow mail, files, applications and account changes performed during the suspicious session.
Agent Foskett's investigation mindset
The original question was, “How did they get the password?” That question quietly assumed the attacker needed it. The better question was, “What authentication material did the attacker actually use?”
Do not stop at MFAMFA explains how the legitimate session was established, not necessarily who controlled it later.
Follow the sessionIP address, user agent, application activity and timing can expose a split between legitimate and attacker behaviour.
Question the assumptionIf password-theft evidence is absent, investigate whether the authenticated session became the target instead.
Investigation findings
The password was not the evidenceThe investigation did not need to prove that the attacker knew or changed the user's password.
The session was the pivotCloud activity split into distinct network and client contexts after the legitimate authentication.
The lessonAuthentication can be attacked after authentication has already succeeded.
Related investigations
Continue following identity, MFA and session evidence across Microsoft security investigations.
The Account Had MFA — But the Legacy Authentication Attempt Told the StoryInvestigate authentication evidence without assuming MFA ends the analysis.The User Changed Their Password — But the Attacker Added a PasskeyFollow persistence that survives the obvious password response.The Sign-In Came From Australia — But the ASN Told a Different StoryUse network context to test whether a familiar geography is really familiar.
Final thought
The password was still the user's. MFA had succeeded. And yet somebody else was operating inside the cloud session. Once Agent Foskett stopped asking how the attacker stole the password, the evidence made far more sense. The attacker did not need to know the password. They needed the authenticated session that came after it. The Logs Already Knew! 🔎
Password looks untouched?Do not end the investigation there.
MFA succeeded?Ask what happened to the session afterwards.
The lesson?Credentials are not the only authentication material worth stealing.
