Agent Foskett Academy • SOC Analyst Academy • Module 6 • Lesson 52 • Cloud & SaaS Incidents

Lesson 52 — The Same Account Accessed SharePoint from Two Countries

The alert looked obvious.

At 09:12, the user's account accessed SharePoint from Australia.

At 09:26, the same account appeared to access SharePoint from Singapore.

Fourteen minutes.
Two countries.
One identity.

The first conclusion practically wrote itself:

“Impossible travel. Compromised account.”

Agent Foskett looked at the timestamps, then at the IP addresses.

“Before we accuse anyone of teleportation... what actually created those locations?”

Location is context. It is not identity, intent or proof of compromise.

Investigate the Location Anomaly Back to SOC Analyst Academy

Agent Foskett investigating SharePoint access from two countries

Two countries do not automatically mean two people

Validate IP ownership, sign-in context, sessions, devices and cloud activity before turning a geographic anomaly into a compromise verdict.

✓ Compare timestamps

✓ Validate IP context

✓ Correlate sign-ins

✓ Test competing explanations

Case briefing

09:12 SharePoint access Account: mia@contoso.com Location: Melbourne, Australia IP: 198.51.100.24 ↓ 14 MINUTES ↓ 09:26 SharePoint access Account: mia@contoso.com Location: Singapore IP: 203.0.113.82 INITIAL ALERT STORY: ONE USER TWO COUNTRIES 14 MINUTES BUT THE SOC STILL NEEDS TO ANSWER: What generated each location? Were these the same session? Were both activities interactive? Was a VPN, proxy or cloud service involved? What did the account actually do?

Investigation objective

Determine whether geographically inconsistent SharePoint activity represents legitimate access, VPN or proxy routing, session behaviour, automation or unauthorised use of the account.

Investigator's rule

Geolocation is an investigative clue, not a verdict. IP-derived location can be useful, but it must be interpreted alongside identity, session, device and workload evidence.

Stage 1 — put both events on the timeline

Evidence	Event A	Event B
Time	09:12	09:26
Account	mia@contoso.com	mia@contoso.com
Workload	SharePoint	SharePoint
Observed country	Australia	Singapore
IP	198.51.100.24	203.0.113.82
Initial meaning	Known location?	Requires investigation

The timestamps create the question

Fourteen minutes is not enough time for physical travel between Melbourne and Singapore. But the evidence does not yet prove that either event represents the user's physical location.

Start with what you know

The account generated cloud activity associated with two IP addresses. Everything beyond that — physical location, human operator and intent — still requires evidence.

Stage 2 — inspect SharePoint cloud activity

123456789

CloudAppEvents
| where Timestamp > ago(1d)
| where AccountId =~ "mia@contoso.com"
| where Application has "SharePoint"
| project Timestamp,
          AccountId,
          Application,
          ActionType,
          IPAddress,
          UserAgent,
          RawEventData
| order by Timestamp asc

Do not investigate only the two alert events

Look before, between and after them. A wider sequence may show one isolated foreign event, repeated activity from both IPs or a clear transition between access paths.

Actions matter

Opening a file, downloading hundreds of documents, changing sharing permissions and modifying site settings have very different security significance even if they come from the same location.

Stage 3 — compare the IP addresses

IP A — AUSTRALIA Known corporate egress? Known home ISP? Previously seen for user? Known VPN exit? Expected device/session? VS IP B — SINGAPORE Corporate security proxy? Cloud-hosted address? VPN exit node? Previously seen for user? Previously seen across organisation? New / unexplained infrastructure? DO NOT STOP AT: "IP GEOLOCATES TO SINGAPORE."

Ask who owns the network path

Traffic may appear to originate from a security service, VPN concentrator, corporate proxy or cloud infrastructure rather than the user's physical device location.

Historical use is valuable

If the Singapore IP has appeared repeatedly for many legitimate users, that context is very different from an IP never previously observed in the organisation.

Stage 4 — check whether the IP is common across accounts

12345678

let InvestigatedIP = "203.0.113.82";
CloudAppEvents
| where Timestamp > ago(30d)
| where IPAddress == InvestigatedIP
| summarize
    Accounts = dcount(AccountId),
    AccountList = make_set(AccountId, 50),
    Applications = make_set(Application, 20),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)

Shared infrastructure can explain geography

An address used by many employees across expected cloud applications may indicate a shared network service. That does not automatically make the event safe, but it changes the hypothesis.

A rare IP increases interest

If the address is new to the organisation, new to the user and associated with unusual actions, the location anomaly deserves greater scrutiny.

Stage 5 — correlate with sign-in evidence

SHAREPOINT EVENT 09:26 — Singapore IP ↓ CORRELATE ↓ IDENTITY EVIDENCE Was there a new interactive sign-in? Was MFA performed? Was Conditional Access evaluated? Was the device familiar? Was the application expected? Was the session already established? Were there failed attempts beforehand? IMPORTANT: CLOUD ACTIVITY DOES NOT REQUIRE A BRAND-NEW INTERACTIVE SIGN-IN FOR EVERY ACTION.

Session behaviour matters

A cloud action can occur using an existing authenticated session. Do not assume that every SharePoint event should have a matching fresh sign-in at the same timestamp.

A new suspicious sign-in changes the case

If the foreign activity follows unfamiliar authentication from the same IP or infrastructure, especially with other anomalies, the account-compromise hypothesis becomes stronger.

Stage 6 — compare user agent and device context

Observation	Possible meaning
Same familiar browser/device context	Could support routing or session explanation.
New browser and unfamiliar device context	Raises concern when combined with other anomalies.
Automated or service-like activity	May require investigation of application or non-interactive access.
Foreign IP plus new device plus unusual actions	Stronger compromise signal than location alone.
Foreign IP used by many corporate users	May indicate shared proxy, VPN or security infrastructure.

Correlation strengthens or weakens hypotheses

No single field needs to settle the case. IP, user agent, device, session timing, authentication and workload behaviour become useful when evaluated together.

Look for contradictions

If the user is actively working from a known managed device in Melbourne while another unfamiliar session is downloading SharePoint data from unrelated infrastructure, the two-country story becomes much more significant.

Stage 7 — inspect what happened from each IP

123456789

let IPs = dynamic(["198.51.100.24", "203.0.113.82"]);
CloudAppEvents
| where Timestamp > ago(1d)
| where AccountId =~ "mia@contoso.com"
| where IPAddress in (IPs)
| summarize
    Events = count(),
    Actions = make_set(ActionType, 50),
    Applications = make_set(Application, 20),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by IPAddress

Behaviour can be more revealing than geography

If the Australian IP shows normal document access while the Singapore IP performs bulk downloads or sharing changes, the difference in behaviour may be more important than the distance between them.

Scope beyond SharePoint if needed

If the suspicious IP also appears in Exchange, OneDrive or other cloud workloads, the investigation may be moving toward a wider cloud-compromise story.

Stage 8 — test competing explanations

Hypothesis	Evidence that may support it
Legitimate travel	Travel confirmed, expected device, expected authentication and plausible timing.
VPN / proxy / security service	IP belongs to known infrastructure and appears across legitimate users.
Existing session behaviour	No new suspicious authentication; activity aligns with established session context.
Automation / application activity	Service-like pattern and expected application context.
Account compromise	New IP, unfamiliar authentication, new device/session and suspicious cloud actions.

Do not force a binary answer too early

The correct intermediate verdict may be “location anomaly explained by corporate proxy” or “unexplained foreign cloud activity requiring further identity investigation.” Both are better than guessing.

Business context still matters

Known travel, remote-work arrangements and corporate network design can resolve apparent anomalies quickly. Validate that context rather than assuming it.

Stage 9 — build the evidence-weighted decision

TWO-COUNTRY ALERT ↓ LOCATION ONLY ↓ Weak evidence by itself + NEW / RARE IP ↓ More interesting + UNFAMILIAR AUTHENTICATION ↓ Higher concern + NEW DEVICE / SESSION ↓ Higher concern + UNUSUAL SHAREPOINT ACTIONS ↓ Strong compromise hypothesis OR... KNOWN CORPORATE PROXY + expected device + normal actions + established history ↓ LIKELY EXPLAINED ANOMALY

Evidence should change confidence

Each corroborating observation should increase or reduce confidence in a hypothesis. That is more defensible than treating the alert name as the conclusion.

Escalate when the unexplained risk remains

If the foreign access cannot be explained and is associated with sensitive or destructive actions, escalate according to organisational procedures while continuing to preserve evidence.

Stage 10 — write the SOC finding

SOC FINDING — EXAMPLE SharePoint activity for mia@contoso.com was observed from IP addresses geolocated to Australia and Singapore within a fourteen-minute period. Review of the Singapore address showed that it was historically associated with the organisation's approved cloud security proxy and had been used by multiple legitimate accounts. The user's activity was associated with expected browser and account context, and no corresponding unfamiliar authentication or unusual SharePoint actions were identified during the reviewed period. The geographic difference is therefore assessed as an explained network-routing anomaly rather than evidence of impossible physical travel or account compromise. No malicious activity was identified from the location difference alone.

What if the evidence went the other way?

ALTERNATIVE FINDING If the Singapore IP were: New to the organisation + New to the user + Associated with unfamiliar authentication + Using a new device/session + Performing unusual SharePoint downloads THEN: The location anomaly would become one part of a much stronger account-compromise case. SAME ALERT. DIFFERENT EVIDENCE. DIFFERENT VERDICT.

Lesson 52 key takeaways

Two countries in a short period do not automatically prove account compromise.
IP geolocation describes network infrastructure, not necessarily a user's physical location.
Place both events on a timeline before interpreting them.
Review surrounding cloud activity rather than investigating only the alert records.
Check whether an IP is known to the user or common across the organisation.
VPNs, proxies and cloud security services can create misleading geographic signals.
Cloud actions may use an existing session without a fresh interactive sign-in.
Correlate location with authentication, device, session and user-agent evidence.
Compare what the account actually did from each IP.
Test legitimate travel, network routing, session behaviour, automation and compromise hypotheses.
Location becomes stronger evidence when corroborated by other anomalies.
The final SOC finding should explain why the geographic anomaly was or was not security-significant.

Module 6 — Cloud & SaaS Incidents

Lesson 52 showed why location anomalies require correlation rather than assumption. Lesson 53 increases the scale: hundreds of files are downloaded in only a few minutes.

Next: Lesson 53 — Hundreds of Files Were Downloaded in Minutes

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 6: Cloud & SaaS Incidents

Investigate cloud activity by correlating identities, applications, permissions, sessions and Microsoft 365 workload evidence.

← Previous lesson

Lesson 51 — The User Downloaded Gigabytes Before Leaving Investigate unusual cloud data access with business context.

✅ Current lesson

Lesson 52 — The Same Account Accessed SharePoint from Two Countries Evaluate location anomalies carefully.

Next lesson →

Lesson 53 — Hundreds of Files Were Downloaded in Minutes Measure bulk data access and compare it with normal behaviour.

Investigate SharePoint access from two countries with Microsoft Defender XDR

Lesson 52 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate geographic anomalies in Microsoft 365 and SharePoint by correlating cloud activity, IP addresses, authentication, sessions, devices and network context.

Evaluate impossible travel and cloud location anomalies with KQL

Use CloudAppEvents and Microsoft security telemetry to test legitimate travel, VPN or proxy routing, established sessions, automation and account-compromise hypotheses without treating IP geolocation as proof of a user's physical location.