Geolocation

Three detections depend on location: impossible travel, new geography and the map view. How the country is derived matters enough to document, because the obvious source is wrong.

Purview’s GeoLocation field is not a country

For SharePoint and OneDrive, AuditData.GeoLocation carries the multi-geo datacenter region — EUR, NAM, APC — not the country the user was in. For Exchange, Azure AD sign-ins and Teams it is absent entirely.

Measured on a real 178,653-event tenant export: the field was present on 50,143 events (28%), and every single value was EUR. Read naively as a country code, EUR truncates to EU, which is not an ISO-3166-1 country, so every event would be discarded — and impossible travel, which compares consecutive countries, could never fire.

Corelog therefore uses GeoLocation only when it genuinely contains a two-letter country code, and otherwise ignores it.

Country comes from the client IP

The country is resolved from ClientIP, ClientIPAddress or ActorIpAddress — whichever the record carries — against an IP-to-country database bundled with the application. On that same export, the IP fields cover 94.8% of events, and country resolution succeeds for 91.0%.

ActorIpAddress matters in particular: it is the field Azure AD sign-in records use, which is precisely where location is most relevant.

Private and reserved address space (RFC 1918, loopback, link-local) resolves to nothing. Corporate NAT tells you where the gateway is, not where the person is.

Note

The lookup is a binary search over an array in your browser tab. No address is ever sent to a geolocation service — that would defeat the point of a tool that does not transmit your data. See Privacy.

Data: DB-IP IP to Country Lite, used under CC-BY-4.0 — IP Geolocation by DB-IP.

Not every event places a person somewhere

This is the subtlety that matters most when reading a travel-related finding.

Most M365 events carry an IP, but that IP frequently belongs to Microsoft infrastructure acting on the user’s behalf rather than the user’s own client: background mailbox sync, indexing, mobile push, eDiscovery, service-to-service calls. MailItemsAccessed alone was 41% of the reference export and appeared from 94 distinct countries.

Treating those as user locations makes every mailbox look like it is teleporting between datacenters. Measured over the 161,811 geo-resolved events of that export:

Evidence rule	Flagged pairs	Users
Every event carrying an IP	47,739	997 of 1,698
Excluding MailItemsAccessed	18,896	348
Excluding background Exchange too	16,359	307
Interactive sign-ins only	992	67

So impossible travel and new geography count only interactive authentication as evidence of where a person was:

UserLoggedIn
UserLoginFailed
SignInEvent
PasswordLogonInitialAuthUsingPassword
TeamsSessionStarted
EmailAuthOTPAuthenticationSucceeded

A sign-in is the one event type that means “this person presented credentials from this address at this time”. Everything else can be, and routinely is, a service acting for them.

This is an operation allowlist rather than a filter on RecordType, so it holds across workloads and tenants — and so the criterion stays something an analyst can state plainly when asked to justify a finding.