Skip to main content
If you think a user may be compromised and Petra hasn’t alerted, this page walks through how to check. Petra ingests more M365 signal than most other tools and takes a holistic view of an account before deciding whether it’s compromised. Most other tools flag on individual events (a login from an unfamiliar location, a failed MFA prompt, a click on a link) even when those events are benign on their own. Before escalating, run through the checks below. In practice, the answer is usually travel, a mobile carrier quirk, a VPN, a Microsoft datacenter IP, or a password spray that was stopped at MFA.

​
Start with the innocent narrative

The default answer is that the user is not compromised. Before looking for red flags, try to construct a coherent benign explanation for what you’re seeing. If the data fits a simple story (the user traveled, the user is on a VPN, the IP is a Microsoft service), that story is almost certainly correct.

​
Where to look

Open the user in the Petra portal and scroll to the login logs. You’re looking at the last 14 days by default, extend the range if the flagged IP might be recurring. For each distinct IP, note:
  • The city, region, and country Microsoft reports.
  • The device name and type.
  • Whether the login was successful.
  • Whether the login was from a known user device.

​
Common benign explanations

​
The user was actually there

Before anything else, confirm with the user (or their manager) where they are right now. The most common false alarm is the MSP assuming a user is in one city when they’ve moved, are traveling, or are working remotely from somewhere else. If they’re traveling, look for the journey in the logs: home city, then an in-flight WiFi provider, then the destination country. Viasat IPs in the middle of a login trail almost always mean airplane WiFi. Reduced login frequency is a travel signal. Attackers increase login volume, they don’t reduce it.

​
Mobile carrier geolocation

Cellular carriers (T-Mobile, AT&T, Verizon) route traffic across adjacent states and often geolocate far from the user. T-Mobile is the worst offender, it’s common to see a Florida user geolocated to Chicago. The test: widen the date range to 30 to 60 days and look for the same IP appearing in earlier logs with a different city. The same IP geolocated to two different cities over time is consistent with mobile carrier routing, but residential proxy services (rented by attackers) produce the exact same pattern. Check the ASN before closing the case: a mobile carrier ASN (T-Mobile, AT&T, Verizon) confirms it. A hosting provider or known proxy ASN means you’re looking at a proxy service, not a carrier.

​
VPN use

Corporate VPNs (Tailscale, etc.) route through arbitrary exit nodes. A user on a VPN can appear to log in from many cities over a short window. Consumer VPNs like NordVPN, TunnelBear, and OpenVPN do the same thing. If you have access to an IP enrichment tool, check whether it identifies the IP as a known VPN operator. A named consumer or corporate VPN is almost always the full explanation.

​
Direct Send (email from themselves)

If a user received a phishing email that appears to come from their own address, that’s almost always a Direct Send attack, not a compromise. The attacker abused a Microsoft 365 feature to spoof the sender. They are not in the account.

​
Password spray and MFA challenge (no compromise)

If a user got an unexpected MFA prompt they didn’t initiate, there are two common explanations. Neither is a compromise. The tell in both cases is that there is no successful login tied to the MFA challenge. The attacker never got in. Case 1: The attacker had the password and got stopped at MFA. An attacker entered the correct password, hit MFA, and failed. The account is not compromised, but the password is known to attackers and should be reset. How to spot it in the logs:
  • The MFA challenge originates from an unfamiliar IP: a datacenter, hosting provider, or residential proxy.
  • There is no successful login after that MFA challenge from the same IP.
  • The user’s normal sessions and devices continue uninterrupted on their usual IPs.
Case 2: Microsoft proactively challenged the user. Microsoft detects a password spray targeting the account and issues a precautionary MFA challenge. The attacker did not have the password. Microsoft triggered the challenge on its own. How to spot it in the logs:
  • The MFA challenge originates from the user’s own legitimate IPs and devices.
  • The surrounding session activity is normal and continues uninterrupted.
See our research on password spray campaigns using residential proxies.

​
Microsoft datacenter IPs

Microsoft routes traffic through its own datacenters for Exchange, SharePoint, Teams, and many first-party service clients. SharePoint logs in particular are full of Microsoft datacenter IPs because Excel Online, Word Online, and similar apps proxy through Microsoft infrastructure. These show up with odd-looking geolocations but are almost always benign. See what’s up with all that “impossible travel”.

​
Tesla, IoT devices, and Microsoft service clients

Tesla vehicles route M365 requests through Azure backends, so you’ll sometimes see datacenter logins from odd regions on Linux user agents. IoT devices do the same. Microsoft’s M365 Chat Client can produce odd user agent strings (e.g. Android on a Windows device). This is a Microsoft quirk, not an attack. See when a Tesla looks like an attacker and that Android 6 login.

​
Endpoint compromise

If you’re confident a user was hacked but you can’t piece it together from the login patterns above, the attacker may be operating through the user’s own device rather than logging in from their own infrastructure. This is an endpoint compromise, usually malware on the laptop.
Petra monitors M365 identity activity, not endpoints. If an attacker never logs in from their own infrastructure and acts entirely through a malware-infected device, we may only see the downstream M365 behavior. EDR is the right tool for a confident verdict. Signature-based AV alone usually misses the active sessions and persistence involved. The checks below help you notice the pattern.
What the logs look like:
  • Suspicious actions (new inbox rule, OAuth app consent, outbound phish, unusual file access) coming from the user’s own registered device and the company IP or the user’s normal home IP.
  • No successful logins from unfamiliar IPs anywhere in the window.
  • No device that the user doesn’t already own. The session is just the user’s own session being driven by malware.
How to check:
  • Confirm the device name on the suspicious events matches a device the user actually uses.
  • Confirm the IP matches the user’s office network, home network, or VPN. If everything checks out and the actions are still suspicious, treat the endpoint as compromised.
  • Loop in your EDR or antivirus to scan the device and check for active malware or recent persistence installs.
If you confirm an endpoint compromise, rotating the M365 password alone is not enough. Isolate the device, scan it, and treat any tokens or saved sessions on it as compromised until the device is clean or rebuilt.

​
When it’s actually suspicious

Real compromises almost always show more than one of the signals below together, not just one in isolation. A single odd-looking login is usually one of the benign cases above. Before escalating, run through the checks one more time and confirm with the user where they actually are. If two or more of these line up and you still can’t explain them, that’s when it’s worth a closer look.
  • A successful login (not a failed attempt) from a location that isn’t explainable by travel, mobile carrier routing, or a VPN, and you’ve confirmed with the user they aren’t there.
  • A successful login from a hosting or datacenter IP that isn’t Microsoft-owned and isn’t a known Microsoft service client.
  • A login from a device the user doesn’t own and has never been seen on before.
  • A login pattern that doesn’t match the user’s normal behavior (frequency, timing, or geographic clustering all suddenly change) together with a visible attacker action, like a new inbox rule, a new OAuth app consent, outbound phish, or unusual file access.
Only successful logins matter. Failed attempts are noise, no matter how many of them there are or where they come from. If the pattern genuinely fits compromise and Petra hasn’t alerted, double-check that incident notification methods are configured, and re-read What Petra Alerts On to make sure what you’re seeing isn’t one of the cases we intentionally don’t alert on.