ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett • Entra ID • MFA Session Investigation

The User Passed MFA... But It Wasn't Really Them

The sign-in looked legitimate.

Correct username. Correct password. MFA successful. Conditional Access allowed it.

Everything appeared to line up.

The problem was...

the attacker did not need to bypass MFA.

They inherited the authenticated session.

This Agent Foskett briefing looks at a modern Microsoft identity problem: attackers do not always break authentication. Sometimes they steal the trust that authentication already created.

The dashboard may show MFA success. The sign-in logs may show a successful authentication. But the real investigation begins when we ask what happened after MFA was satisfied.

Discuss your environment Back to briefings
Agent Foskett MFA session token investigation
Briefing summary

MFA success is not always the end of the story. GEMXIT looks at how Entra ID sign-ins, AuthenticationDetails, Conditional Access, Microsoft Defender XDR and KQL can reveal suspicious activity after an authenticated session has already been trusted.

Investigate MFA session abuse
Correlate sign-ins and behaviour
Validate trust after authentication
🚨 MFA worked. The session was the problem.
Modern attackers do not always trigger failed logins, password spray alerts or impossible travel. Sometimes they use a session that already passed the checks.
Book a security review →

What happened

A Microsoft 365 sign-in showed MFA success. Conditional Access allowed the session. Nothing obvious failed. But the behaviour after authentication did not match the real user.
The sign-in looked legitimateThe user authenticated successfully. MFA was marked as satisfied. The sign-in result was successful and did not immediately look like an attack.
The session was not trustworthyThe account may have passed MFA, but a stolen browser cookie, token replay or adversary-in-the-middle phishing flow may have handed the attacker a valid session.
The attacker inherited trustThe risk was not that MFA failed. The risk was that the attacker obtained access after MFA had already created a trusted authentication state.

Why MFA success still needs investigation

MFA is essential, but a successful MFA event does not prove the person behind the session is still the legitimate user.
Passed does not mean safeMFA can be satisfied legitimately while the session, device, browser or token is later abused by someone else.
Allowed does not mean understoodConditional Access can make the correct decision based on policy, while the surrounding behaviour still requires investigation.
Behaviour completes the pictureUnusual hours, unfamiliar apps, strange user agents, abnormal file access and new IP patterns can matter more than the MFA result alone.

First hunt: successful MFA sessions with unusual context

Start with successful sign-ins where MFA was satisfied, then review the application, IP address, user agent, device information and Conditional Access result.
successful-mfa-context-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where AuthenticationRequirement has "multiFactorAuthentication"
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          IPAddress,
          Location,
          UserAgent,
          DeviceDetail,
          ConditionalAccessStatus
What to reviewLook for successful MFA sessions from unexpected locations, unfamiliar browsers, new IP ranges, unusual applications or activity outside the user's normal pattern.
Why it mattersSession abuse often appears as successful authentication, not failed authentication.
Best next pivotPivot into AuthenticationDetails, device details, session activity, Defender endpoint signals and post-login cloud actions.

Second hunt: repeated access from changing session context

A stolen or replayed session may keep working while the surrounding context changes. Look for successful access where IP addresses, user agents, apps or locations drift across time.
mfa-session-context-drift.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType == 0
| summarize SignIns = count(),
            IPs = make_set(IPAddress),
            Apps = make_set(AppDisplayName),
            UserAgents = make_set(UserAgent),
            Locations = make_set(Location)
            by UserPrincipalName, bin(TimeGenerated, 1d)
| where array_length(IPs) > 3 or array_length(UserAgents) > 3
| order by SignIns desc
What to reviewLook for a user account moving across multiple IPs, applications or browser fingerprints while continuing to authenticate successfully.
Why it mattersToken replay and session misuse can hide behind success because the authentication state has already been established.
Best next pivotCompare the sign-in timeline with Defender alerts, device activity, browser processes, phishing emails and suspicious URL clicks.

Third hunt: suspicious activity after MFA success

When the MFA event looks normal, the strongest evidence may be what the session does next: files downloaded, mailbox changes, permission changes or unusual consent activity.
post-mfa-cloud-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("FileDownloaded", "Add member", "Update user", "Consent", "Mailbox")
| extend Hour = datetime_part("hour", TimeGenerated)
| where Hour < 6 or Hour > 20
| project TimeGenerated,
          OperationName,
          InitiatedBy,
          TargetResources
| order by TimeGenerated desc
What to reviewLook for data downloads, mailbox rules, consent grants, privilege changes or file access shortly after MFA was satisfied.
Why it mattersAttackers who inherit trust often move quickly into data access, persistence or mailbox manipulation.
Best next pivotPivot into Microsoft Defender for Cloud Apps, Microsoft Purview audit, SharePoint activity, mailbox audit and Entra ID sign-in context.

What this kind of activity can indicate

The point is not to assume every MFA success is malicious. The point is to recognise when a successful MFA result becomes a hiding place.
Adversary-in-the-middle phishingA phishing proxy may capture the session after the real user completes MFA, allowing the attacker to reuse trusted access.
Session token theftBrowser cookies and session tokens can be stolen from an endpoint, allowing access without repeatedly challenging the attacker for MFA.
MFA fatigue or social approvalThe user may approve a prompt they did not initiate, especially when alerts, prompts or pressure make the activity seem routine.
Data access without malware alertsThe most important evidence may be file access, downloads, mailbox changes or application access rather than a malware detection.
Inherited identity trustThe attacker is not always breaking in. Sometimes they are using the trusted authentication state that already exists.
Misplaced confidenceThe environment may have strong MFA, but still need better visibility into behaviour after authentication succeeds.

How GEMXIT approaches MFA session investigations

At GEMXIT, we do not stop at the successful MFA result. We look at identity, endpoint, cloud and behavioural evidence together.
We investigate the authenticationSigninLogs, AuthenticationDetails, Conditional Access results, device details and MFA claims help explain why access was granted.
We correlate the behaviourDefender XDR, Sentinel, endpoint telemetry, cloud activity and audit logs help determine whether the session behaved like the real user.
We validate trust continuouslyThe goal is practical visibility: understanding what happened before, during and after MFA was satisfied.
MFA proves a challenge was satisfied. It does not prove the session stayed safe.
GEMXIT helps organisations review Microsoft Entra ID, Microsoft Defender XDR, Microsoft Sentinel, Conditional Access and audit telemetry to identify identity risks hiding behind successful authentication.
Contact GEMXIT

Final thought

The user passed MFA. That was exactly why the session was trusted.
At GEMXITWe help organisations use Microsoft Defender XDR, Microsoft Sentinel, Entra ID and KQL to investigate MFA session abuse, validate identity assumptions and improve security visibility.
Agent Foskett mindsetThe important question is not only: “Did MFA pass?”

It is: “What happened after trust was granted?”

Continue the investigation with MFA Session Hijacking, The Session Token Never Expired, The Login Came Through A Trusted Device, When Nothing Looks Wrong, The Dashboard Was Green and Microsoft Security Operations.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

MFA Success and Microsoft Entra ID Session Security Investigation

This Agent Foskett briefing explains why successful MFA events still need investigation. Microsoft Entra ID, Conditional Access, Microsoft Defender XDR, Microsoft Sentinel and KQL telemetry can reveal suspicious behaviour after authentication has already succeeded.

Session Token Theft, AiTM Phishing and MFA Abuse

GEMXIT helps organisations investigate session token theft, adversary-in-the-middle phishing, MFA fatigue, suspicious session reuse, identity compromise and cloud activity that may not appear as a failed login or obvious high-severity alert.

Microsoft Defender XDR, Entra ID and KQL Threat Hunting

Example investigation areas include successful MFA sign-ins, AuthenticationDetails, Conditional Access results, device details, UserAgent context, AuditLogs, file downloads, mailbox activity, application consent and suspicious cloud activity after authentication.