ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Case File • Identity Security • Token Theft • Microsoft Entra ID • Defender XDR • KQL

The User Was in Melbourne — So Why Was Their Token Used in Singapore?

The sign-in looked normal.

The user was in Melbourne. The password was correct. MFA succeeded. The authentication came from the expected device.

Then the same identity began accessing Microsoft 365 from Singapore.

The password had not necessarily been stolen.

Agent Foskett had a different question: what if the attacker didn't need the password anymore?

Discuss Identity SecurityBack to investigations
Agent Foskett investigating suspicious token activity between Melbourne and Singapore
The Sign-In Wasn't the Whole Story

A legitimate authentication event can be followed by malicious activity if an attacker obtains a usable session token. The investigation has to continue beyond the password and MFA result.

✓ Legitimate Melbourne sign-in
✓ MFA successfully completed
✓ Later activity from Singapore

Everything about the sign-in looked right

The investigation began with an identity that appeared to have authenticated normally. The user was expected to be in Melbourne. The sign-in was successful. MFA had been satisfied. Nothing in that single event immediately screamed compromise.

If the investigation stopped there, the conclusion would have been easy: the user signed in successfully, so everything is fine.

But successful authentication answers only one question: was access granted?

It does not automatically prove that every action performed later with that session was performed by the same person.
MelbourneThe original interactive authentication aligned with the user's expected location.
MFA succeededThe authentication requirements were satisfied, making the event appear reassuring.
SingaporeLater activity associated with the identity appeared from a location that required explanation.

Agent Foskett stopped looking only at the login

A stolen session token changes the investigation. An attacker may not need to repeat the original interactive authentication every time they access a resource. That means analysts should distinguish between interactive sign-ins, non-interactive sign-ins and the resource activity that follows them.

The important question became: what happened after the legitimate Melbourne authentication?
Interactive authenticationEstablish where and how the user originally authenticated.
Session activityLook for later access that may rely on an existing token rather than a fresh password prompt.
TimelineSequence the events. Geography is useful, but timing and session context make it evidence.

Start with the user's sign-in timeline

In Microsoft Sentinel or another workspace receiving Microsoft Entra sign-in logs, establish the authentication timeline first. Replace the example account below with the identity being investigated. Do not begin by assuming that every different location is malicious. VPNs, mobile networks, cloud proxies and corporate egress can all affect geolocation.
identity-signin-timeline.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
  15. 15
let User = "user@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ User
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          ResultType,
          ConditionalAccessStatus
| order by TimeGenerated asc

Now separate interactive from non-interactive activity

A normal interactive sign-in can be only the beginning of the story. Review non-interactive sign-ins for the same identity and compare their timing, IP addresses, applications and resource access. A different country by itself is not proof of token theft, but a new network appearing shortly after a legitimate authentication can justify a deeper pivot.
noninteractive-session-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
  14. 14
  15. 15
let User = "user@contoso.com";
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ User
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ResourceDisplayName,
          ResultType,
          ConditionalAccessStatus
| order by TimeGenerated asc

Which IP addresses were using the identity?

Summarising the identity by IP and location can expose a pattern that is difficult to see when reading individual events. The objective is not to declare the furthest-away IP malicious. It is to understand which networks were associated with the identity, when they first appeared and how much activity came from each one.
identity-location-summary.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
let User = "user@contoso.com";
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ User
| summarize Events=count(),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated),
            Apps=make_set(AppDisplayName, 10)
    by IPAddress, Location
| order by FirstSeen asc

Was the suspicious IP seen anywhere else?

Once an IP address becomes an investigative lead, pivot across the environment. If the same address appears against other identities, applications or failed sign-ins, the context changes. Equally, an IP that belongs to a known corporate proxy, security service or VPN may explain what initially looked suspicious.
suspicious-ip-pivot.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
let SuspiciousIP = "203.0.113.10";
union isfuzzy=true
    (SigninLogs
     | project TimeGenerated, UserPrincipalName,
               IPAddress, AppDisplayName, ResultType),
    (AADNonInteractiveUserSignInLogs
     | project TimeGenerated, UserPrincipalName,
               IPAddress, AppDisplayName, ResultType)
| where IPAddress == SuspiciousIP
| order by TimeGenerated desc

Build the timeline before making the verdict

Suppose the evidence shows a successful interactive sign-in from Melbourne at 09:02, followed minutes later by non-interactive activity from an unfamiliar Singapore IP against Microsoft 365 resources. That sequence deserves investigation, but the location labels alone still do not prove token theft.

Check whether the IP belongs to expected infrastructure. Review the application and resource. Examine device and session context where available. Look for unusual mailbox, SharePoint, Graph or other cloud activity after the change.

The timeline turns an odd location into an investigation.
09:02 — MelbourneSuccessful interactive authentication from the user's expected environment.
09:08 — New networkNon-interactive activity appears from an IP and geography not yet explained.
After 09:08Resource access determines whether the session simply looks unusual or begins behaving unusually too.

What Agent Foskett checked

Authentication typeWas the event interactive, non-interactive or resource activity using an existing session?
IP addressDid a new network appear, and is it expected corporate, VPN, proxy or cloud infrastructure?
LocationDoes the geography make sense when considered with the IP owner and network path?
ApplicationWhich Microsoft 365 or Entra application was accessed by the session?
TimingHow quickly did the unexplained activity follow the legitimate authentication?
Post-authentication activityWhat did the identity actually do after the suspicious session appeared?

What the evidence can and cannot prove

Geolocation is context, not a verdict. IP-based location can be affected by VPNs, proxies, mobile carriers, cloud infrastructure and security services. Likewise, a successful MFA result proves that an authentication requirement was satisfied; it does not by itself prove that every later action associated with the resulting session was performed by the legitimate user.

Token theft should be concluded only when the wider evidence supports it. Correlate sign-in type, IP ownership, device and session details, application activity, timing and the user's known behaviour.
One foreign IPA lead worth explaining — not automatic proof of compromise.
Successful MFAImportant authentication evidence, but not a permanent guarantee about the session.
Correlated activityThe strongest conclusion comes from multiple independent pieces of telemetry telling the same story.

The lesson

The user really was in Melbourne.

The successful sign-in really could have been theirs.

And MFA really could have worked exactly as designed.

That still doesn't mean the investigation ends at the authentication event.

Passwords prove less once a valid session exists.

Follow the identity beyond the login. Separate interactive authentication from non-interactive activity. Explain the IP addresses. Examine what the session accessed. And build the timeline before deciding what happened.
Investigation principle: A legitimate sign-in does not automatically make every later session action legitimate.

Related investigations

Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.Who is Agent Foskett?Meet the investigator behind the case files and the principle: follow the evidence.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
Melbourne authentication. Singapore activity. One identity.
Don't stop at the successful sign-in. Follow what the session did next.
Continue the Investigation

Final thought

Security investigations become dangerous when one reassuring event is allowed to explain everything that follows.

A correct password is evidence. Successful MFA is evidence. A known device is evidence.

But none of them should prevent an analyst from asking the next question when the timeline stops making sense.

Follow the evidence. Build the timeline.

The Logs Already Knew! 🔎
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The User Was in Melbourne — So Why Was Their Token Used in Singapore?

This Agent Foskett case file examines a Microsoft identity investigation where a legitimate Melbourne authentication is followed by unexplained non-interactive session activity from Singapore.

Microsoft Entra ID Token Theft Investigation With KQL

Use SigninLogs and AADNonInteractiveUserSignInLogs to compare interactive and non-interactive authentication, IP addresses, locations, applications, resources and timing when investigating suspected session or token compromise.

Successful MFA Does Not End the Investigation

A successful password and MFA event establishes authentication evidence, but analysts should continue following the session when subsequent network, location or resource activity no longer fits the expected user behaviour.