Entra ID Sign-in Logs Analysis: Risky Sign-ins and Travel

TL;DR. In the sign-in logs, read seven things per row: time, user, IP + ASN + location, application, client app / authentication protocol, status + error code, Session ID. Then look for patterns rather than single rows: a successful sign-in from a hosting network, one Session ID used from two networks, many 50126 failures from one IP (spray), repeated MFA failures then a success (fatigue), a deviceCode protocol, a legacy client, a Conditional Access block followed by success. Impossible travel is a lead, not a verdict: VPNs and mobile networks generate plenty of it.

Sign-in logs are where a BEC starts. They are also where most false alarms come from, because a travelling sales team on hotel Wi-Fi and a mobile carrier's exit nodes look a lot like an attacker. The skill is combining signals.

The fields worth reading

From the portal CSV/JSON or the Graph signIn resource:

Error codes you will meet

From Microsoft's AADSTS error code reference:

A 50074 or 500121 on an account the user did not try to access at that time means someone else has the password.

Pattern 1: successful sign-in from a hosting or VPN network

Phishing proxies and attackers' machines mostly run on cloud and VPS providers. A successful sign-in whose ASN belongs to a hosting provider, for a user who normally signs in from a corporate or residential ISP, is one of the most useful single signals. Two caveats: your own VPN or secure web gateway may also sit on a cloud ASN (whitelist it), and attackers increasingly use residential proxies to avoid exactly this check.

Pattern 2: one session, two networks

The Session ID is created at the interactive sign-in and inherited by every token derived from it. If the interactive sign-in happened from IP A and non-interactive sign-ins of the same Session ID appear from IP B in another country or ASN, the session was very likely stolen and replayed. That is covered in depth in AiTM phishing and token replay detection.

Pattern 3: impossible travel, and why it lies

Impossible travel compares consecutive successful sign-ins of a user: if the distance divided by the elapsed time exceeds what an airliner can do, something is off. It catches replay from another continent. It also catches:

Microsoft's own Atypical travel detection ignores obvious false positives such as VPNs and locations regularly used by others in the organisation, and needs a learning period (the earliest of 14 days or 10 sign-ins). A log-only analysis has no such history, so treat raw impossible travel as a lead and require a second indicator.

The M365 Forensics rule is transparent about its parameters: two consecutive successful sign-ins of the same account, at least 500 km apart, implying more than 900 km/h; it uses the sign-in's coordinates when present and falls back to a country centroid otherwise. It is rated high, not critical, precisely because of the false positives above.

Pattern 4: password spray and MFA fatigue

• Password spray: one IP, many different accounts, 50126 failures within an hour. The tool raises it when one IP fails against five or more distinct accounts in 60 minutes. If one of those accounts then succeeds from anywhere unusual, prioritise it.
• MFA fatigue: several MFA-step failures (500121, 50074, 50076…) for one user in a short time, possibly followed by a success. The tool flags five failures in an hour (medium) and three failures followed by an interactive success within the hour (high). Number matching in Microsoft Authenticator reduces the risk but does not remove social engineering.

Entra ID Protection has its own Password spray detection; per Microsoft Learn it only fires when a spray actually validated a user's password.

Pattern 5: device code and legacy authentication

• Device code flow (authenticationProtocol = deviceCode, or originalTransferMethod = deviceCodeFlow): the user types a code on Microsoft's device login page and the attacker's session receives the tokens. Microsoft documented a large device code phishing campaign in February 2025 and recommends blocking the flow wherever possible. See device code phishing.
• Legacy authentication (IMAP, POP, SMTP AUTH, Exchange ActiveSync with basic auth…): cannot enforce MFA. A successful legacy sign-in on a mailbox that should not use it deserves a look.

Pattern 6: Conditional Access block, then success

A 53003 block followed within the hour by a success for the same user can be a user fixing their device, or an attacker switching client or network until a policy no longer applies. Compare the two rows: same device and IP, or not?

Entra ID Protection signals

If the tenant has P2, riskEventTypes_v2 and riskLevelDuringSignIn carry Microsoft's own detections (unfamiliarFeatures, anonymizedIPAddress, unlikelyTravel…). Without P2 you see hidden or a generic "additional risk detected". Use them as corroboration; their absence proves nothing.

Reading them together

A single high-signal row is rare. What convinces is a cluster: spray from a VPS at 22:10, a hosting-network success for the same user at 08:12, the same Session ID from another country seven minutes later, then a new MFA method. M365 Forensics scores each pattern, then correlates: any UAL or audit action carrying the IP, Session ID or token of a suspicious sign-in becomes a critical finding. The fictional walkthrough shows such a cluster, including an impossible-travel finding whose evidence mixes the user's own legitimate sign-ins with the attacker's.

Frequently asked questions

Is an impossible travel alert proof that an account was hacked?

No. VPNs, cloud proxies, mobile networks and IP geolocation errors all produce impossible travel between legitimate sign-ins. Treat it as a lead and look for a second, independent indicator such as a hosting network, a replayed session or a new inbox rule.

What does error 50126 mean in the Entra sign-in logs?

InvalidUserNameOrPassword: the credentials were wrong. A few are normal; many 50126 failures from one IP across many accounts in a short time is the pattern of password spraying.

Why are the non-interactive sign-ins important?

They record token use without user input, which is how a stolen session cookie or refresh token is replayed. Token replay and many attacker actions only appear there.

Further reading

• Microsoft Learn: What are risk detections?, Non-interactive sign-in logs
• MITRE ATT&CK: Password Spraying (T1110.003), MFA Request Generation (T1621)
• How to export the sign-in logs
• Okta has the same questions with different fields: oktaforensics.com.