Agent Foskett • MFA • Session Hijacking • Microsoft 365 Security
The MFA was enabled…
but the attacker still got in.
That is when things stop making sense.
MFA was on. No brute force. No password spray. No obvious compromise.
Just a normal day… until the activity did not match the user.
What we found
A legitimate user account. Successful MFA authentication. But access appeared from unfamiliar locations and the session behaviour did not line up with the user.
Successful MFA sign-in
Unfamiliar IP and location activity
Session reuse indicators
What actually happened?
This was not a classic password breach. The attacker did not need to brute force the account. They did not need to bypass MFA in the way most people imagine.
Instead, the attacker reused an already authenticated session. Once MFA has been completed, a session token can allow continued access. If that token is stolen, exposed or reused, the attacker may be able to walk straight in as the user.
Instead, the attacker reused an already authenticated session. Once MFA has been completed, a session token can allow continued access. If that token is stolen, exposed or reused, the attacker may be able to walk straight in as the user.
MFA was completed
The original authentication may have looked legitimate because MFA was successfully satisfied.
The session continued
Access persisted through a session token, not repeated password attempts.
The attacker blended in
Because the session looked valid, the activity may not trigger obvious alerts.
Why MFA is not the finish line
MFA is essential. It should be enabled. It should be enforced. But MFA protects authentication. It does not automatically protect every session after authentication has occurred.
This is where many Microsoft 365 environments fall short. They enable MFA and assume the job is done. But if sessions are not controlled, devices are not validated and token activity is not monitored, risk can still exist.
This is where many Microsoft 365 environments fall short. They enable MFA and assume the job is done. But if sessions are not controlled, devices are not validated and token activity is not monitored, risk can still exist.
MFA protects authentication
It helps prove the user during sign-in, but it is not the whole identity security strategy.
Sessions need control
Sign-in frequency, device compliance and session restrictions matter.
Behaviour needs monitoring
Security teams should hunt for abnormal activity, not just failed logins.
What we hunted
We did not start by looking for failed logins. That would have missed the point. The sign-in may have been successful. The real question was whether the behaviour made sense.
- 1
- 2
- 3
- 4
- 5
SigninLogs | where ResultType == 0 | summarize count(), Locations = make_set(Location) by UserPrincipalName, bin(TimeGenerated, 1h) | where array_length(Locations) > 1
What this finds
Successful sign-ins where the same user appears across multiple locations in a short period.
Why it matters
The user may have passed MFA, but the session behaviour may still be suspicious.
Best pivot
Review device compliance, IP reputation, user agent, application accessed and activity after sign-in.
How to read this query
The query is only the starting point. The real value comes from understanding whether the activity matches the user, device, location and business context.
What to look for
Same user across different locations
Successful sign-ins without obvious failure patterns
Access that does not match normal working behaviour
What normal can look like
VPN use
Mobile network changes
Travelling users
Remote access from known locations
What to do next
Check device compliance
Review Conditional Access decisions
Inspect mailbox, SharePoint and app activity after sign-in
What this kind of activity can indicate
Suspicious session behaviour does not always prove compromise by itself, but it should trigger deeper investigation.
Token theft
A stolen session token may allow access without repeated authentication prompts.
Proxy-based activity
Attackers may route activity through infrastructure that makes access look unusual or inconsistent.
Alerting gaps
The activity may not trigger high-severity alerts because the access appears authenticated.
What should be in place?
This is where Microsoft 365 security needs to move beyond simply enabling MFA. Identity protection needs layers.
Conditional Access
Require compliant devices, trusted locations and risk-based controls where appropriate.
Sign-in frequency
Force re-authentication where long-lived sessions create unnecessary exposure.
Defender and Sentinel visibility
Monitor identity, endpoint, email and cloud signals together rather than treating them separately.
Agent Foskett’s takeaway
If your security strategy stops at MFA, you are already behind.
MFA is essential, but it is not the finish line. It is the starting point. Real Microsoft 365 security means validating the user, the device, the session and the behaviour after sign-in.
MFA is essential, but it is not the finish line. It is the starting point. Real Microsoft 365 security means validating the user, the device, the session and the behaviour after sign-in.
Where this becomes real
We see this pattern more often than people think. Environments look secure because MFA is enabled, but nobody is checking whether sessions are being reused, whether Conditional Access is enforcing the right controls, or whether Defender and Sentinel are telling the full story.
That is the difference between having security features turned on and knowing they are actually protecting the business.
That is the difference between having security features turned on and knowing they are actually protecting the business.
Identity review
Assess MFA, Conditional Access, risky users, risky sign-ins and admin access.
Threat hunting
Use KQL and Microsoft security signals to hunt behaviour, not just alerts.
Security uplift
Improve configuration, visibility and response so controls actually protect the business.
