ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Microsoft Entra ID • MFA • Session Investigation

The Attacker Logged In After MFA

The sign-in looked clean.

The password was correct.

MFA was satisfied.

Conditional Access did not block the session.

But the attacker did not appear before MFA.

They appeared afterwards.

Discuss your environment Back to briefings
Agent Foskett investigation into post MFA attacker activity in Microsoft Entra ID and Defender XDR
Briefing summary

A user completed MFA successfully, but later activity came from a location, device and session pattern that did not fit the user. Agent Foskett investigated whether this was a normal sign-in, token theft, session hijacking or attacker activity after authentication had already succeeded.

MFA succeeded
The session continued afterwards
Post-authentication activity became the clue

What happened

The login was not suspicious because MFA failed. It was suspicious because MFA succeeded and the activity after MFA did not match the user.
MFA was satisfied The sign-in record showed a successful authentication event. At first glance, the identity controls appeared to have worked.
The behaviour changed afterwards After MFA, the session showed access patterns that did not fit the user's normal device, location, application or working pattern.
The investigation shifted The question was no longer whether MFA was enabled. The question became who controlled the session after MFA completed.

The query that changed the investigation

In Microsoft Defender XDR, IdentityLogonEvents can help defenders review successful logons and compare device, location, application and risk context.
post-mfa-logon-review.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
IdentityLogonEvents
| where Timestamp > ago(7d)
| where ActionType has "LogonSuccess"
| project Timestamp, AccountUpn, IPAddress,
          DeviceName, Application, LogonType,
          CountryCode, RiskLevel, FailureReason
| order by Timestamp desc
IPAddress and location Unexpected countries, hosting providers, VPN exit nodes or fast location changes can expose activity that does not fit the user.
Device and application A session that moves from a normal device to unfamiliar browser, app or unmanaged endpoint should be reviewed carefully.
Timeline sequence The order matters. Identify what happened before MFA, what happened at MFA and what happened after the session was established.

Hunting for post-MFA activity

A successful MFA event should not end the investigation. It should anchor the timeline.
activity-after-successful-login.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
CloudAppEvents
| where Timestamp > ago(7d)
| where AccountUpn == "user@contoso.com"
| project Timestamp, AccountUpn, Application,
          ActionType, IPAddress, DeviceType,
          UserAgent, ObjectName, ActivityType
| order by Timestamp asc

Agent Foskett moment

The evidence did not say MFA was missing. It said the session after MFA could no longer be trusted.
MFA was not the finish line Successful MFA only proves that a requirement was satisfied. It does not prove that every action after that moment was performed by the intended user.
The attacker used the after Many identity attacks become visible after authentication, when mailbox access, file access, OAuth consent or session reuse begins.
The timeline told the story Agent Foskett followed the session forward, not just backward. The compromise was not obvious at sign-in. It was obvious in the behaviour that followed.

What most environments miss

Post-MFA compromise is easy to miss when teams treat successful authentication as proof of safety.
Successful MFA can create false confidence Investigators may close the case too early because the log says MFA succeeded and Conditional Access was satisfied.
Tokens outlive the prompt Attackers do not always need to defeat MFA repeatedly if they can steal, reuse or inherit a valid authenticated session.
Risk may appear late The sign-in can look acceptable first, while the suspicious behaviour appears later in mailbox, SharePoint, Teams, OAuth or cloud application activity.

How defenders can investigate it

Treat a successful MFA event as the start of a session investigation, not the end of the incident.
Build the timeline Review what happened before the MFA event, during the MFA event and in the minutes or hours after the session was established.
Compare device and session context Look for unfamiliar user agents, unmanaged devices, new IP ranges, impossible travel, unexpected apps and sudden changes in access pattern.
Invalidate the session If the session looks suspicious, reset credentials, revoke refresh tokens, review MFA methods and check inbox rules, OAuth grants and file sharing activity.

Related investigations

The User Passed MFA But It Wasn't Really Them Understand how a successful MFA event can still sit inside a suspicious identity compromise investigation. Read more →
The Session Token Never Expired See how long-lived sessions can allow access to continue after the original sign-in looks normal. Read more →
The Login Came Through A Trusted Device Trusted device context can reduce friction, but it still needs to be reviewed when behaviour changes. Read more →
The Login Was Successful But The Risk Was High A successful sign-in can still carry risk signals that deserve investigation. Read more →
The MFA Prompt Looked Normal MFA prompts can look routine to users while the surrounding context tells a different story. Read more →
The MFA Method Was Added At 3:14AM New authentication methods can indicate account takeover or persistence after identity compromise. Read more →
MFA passed. That did not make the session safe.
The real question was who controlled the session after authentication completed.
Contact GEMXIT

Final thought

MFA is essential, but it is not the end of the investigation. The session after MFA still needs to be proven.
At GEMXIT We help organisations investigate Microsoft Defender XDR telemetry, Entra ID sign-ins, MFA events, session abuse, token theft, risky users and Microsoft 365 identity compromise. If you want to understand how this applies to your environment, see our Cyber Security services.
Agent Foskett mindset Do not stop when MFA succeeds. Follow the session, compare the behaviour and prove whether the activity after authentication still belongs to the user.

The login passed MFA, but the activity afterwards did not fit the user. Explore related investigations including The User Passed MFA But It Wasn't Really Them, The Session Token Never Expired, and The Login Was Successful But The Risk Was High.

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

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

The Attacker Logged In After MFA

This Agent Foskett briefing explains how to investigate Microsoft Entra ID and Microsoft Defender XDR evidence when MFA succeeded but suspicious activity appeared afterwards.

Post MFA Compromise Investigation In Microsoft Defender XDR

Successful MFA does not always prove that every action after authentication was performed by the intended user. Defenders should review sign-in logs, CloudAppEvents, session activity, user agents, IP addresses, device context, Conditional Access outcomes and token activity.

MFA Session Hijacking Token Theft And Identity Compromise

Some identity attacks happen after the authentication requirement has been satisfied. Session hijacking, token theft, trusted device abuse and persistent browser sessions can allow attacker activity to appear after a legitimate MFA event.