Sentinel • KQL • Session Hijacking
The Logs Already Knew
Nothing looked wrong. No high severity alerts. No incidents. Just another quiet day in Microsoft Sentinel… until one successful sign-in raised the real question: what doesn’t fit the pattern?
Briefing summary
The data was already there. Sentinel didn’t fail. The sign-in looked valid on paper, but deeper hunting across Microsoft security signals exposed impossible travel, token reuse and quiet session hijacking.
Successful sign-in with no alert
Impossible travel across regions
Stolen token moving quietly
What happened
No panic. No incident. Just one sign-in that did not feel right.
The KQL that changed everything
The evidence was already inside the logs. It just needed the right question.
SigninLogs
| where ResultType == 0
| extend
Country = tostring(LocationDetails.countryOrRegion),
City = tostring(LocationDetails.city),
AuthRequirement = tostring(AuthenticationRequirement),
MFA = tostring(MfaDetail.authMethod),
SessionId = tostring(CorrelationId)
| summarize
SignInCount = count(),
Countries = make_set(Country),
Cities = make_set(City),
IPAddresses = make_set(IPAddress),
AuthRequirements = make_set(AuthRequirement),
MFAMethods = make_set(MFA),
SessionIds = make_set(SessionId)
by UserPrincipalName, bin(TimeGenerated, 1d)
| where array_length(Countries) > 1
Agent Foskett moment
Once we pulled the thread, the story became obvious.
What most environments miss
Sentinel did not fail. The investigation question was missing.
Final thought
If you are relying on alerts alone, you are already late.

GEMXIT PTY LTD GEMXIT UK LTD © GEMXIT 2026