Investigating a suspicious sign-in with Entra sign-in logs

An "unfamiliar sign-in properties" alert at 02:00 is either a sales director in a hotel or the start of a very bad week, and the sign-in log is where you find out which. This is the procedure for reading it quickly and reaching a decision, rather than staring at forty columns. If the answer turns out to be "attacker", hand off to the compromised account runbook and do not finish this one first.

Which log

Entra admin center → Monitoring & health → Sign-in logs has four tabs, and the alert usually points at only one:

User sign-ins (interactive) — a human typed credentials or approved a prompt. Start here.
User sign-ins (non-interactive) — token refreshes and silent sign-ins on the user's behalf. This is where an attacker replaying a stolen token lives, because there is no interactive event at all. Check it every time, not just when interactive looks clean.
Service principal sign-ins and Managed identity sign-ins — apps. Relevant if the alert is about an app, or if the user owns app registrations.

Retention is 30 days with a Premium licence (7 days without). If the question is older than that, you need the logs to have been streamed to Log Analytics or Sentinel, and if they were not, you are investigating blind. Set that up after this incident if it is not already done.

Filter to the question

Filter on the user, then on the time window around the alert plus 24 hours either side. Add the columns IP address, Location, Device, Client app, Conditional Access, Authentication requirement, Multifactor authentication result, and Risk detail. Hide the rest.

Then answer six questions in order.

Status and Failure reason. A block by Conditional Access or a failed MFA is an attempt, not a compromise. A flood of failures followed by one success is the shape of password spray followed by a win; a single success with no failures from a new location is the shape of a phished credential or a replayed token.

2. Where, and from what network?

IP address and Location. Look up the IP's ownership — a hosting provider or VPN exit is not where a human on a business trip is sitting; a residential or mobile carrier range in the country the user is actually in usually is. Anonymised IP addresses (Tor, commercial anonymisers) are flagged by ID Protection as a risk detection in their own right.

Then compare against the user's own baseline: filter their last 30 days and look at the IPs and locations they normally use. Two countries in one hour is impossible travel; two countries in one week with a calendar entry saying "customer visit" is Tuesday.

3. What device and client?

Device shows whether the device is Entra joined, registered, compliant, and its operating system and browser. Client app shows Browser, Mobile Apps and Desktop clients, or — the important one — a legacy protocol like IMAP, SMTP, or Exchange ActiveSync. A successful legacy-protocol sign-in from a new location is nearly always an attacker, because those clients cannot do MFA.

An attacker doing adversary-in-the-middle phishing shows up as a browser sign-in from an unmanaged device with the user's MFA satisfied. That last part fools people: the MFA column says success because the user really did approve — for the attacker's proxied session.

4. What did Conditional Access do?

Open the sign-in, Conditional Access tab. Every policy that applied is listed with its result. What you are looking for is Not applied against a policy that should have applied — because the user is in an exclusion group, or the location was trusted, or the app was out of scope. An attacker who found the gap in your CA is the reason this sign-in exists. The gap is a finding regardless of what you decide about the user.

5. Was the token or session odd?

Authentication details tab shows each step — password, MFA method, whether a previously satisfied claim was reused. A sign-in whose MFA was satisfied by "claim in token" from a session that began somewhere else is a token replay tell. The non-interactive log for the same user in the same window is the other half: a refresh token being used from a new IP with no interactive sign-in preceding it is exactly what stolen tokens look like. Token protection is the control that closes this.

6. What did ID Protection say?

Risk state, Risk level and Risk detail. Open Entra ID Protection → Risky sign-ins for the detections behind the score: unfamiliar sign-in properties, anomalous token, atypical travel, leaked credentials, and so on. Each detection page names the signal. Two independent detections on one sign-in are much stronger than one.

Reaching a decision

Call it compromise and escalate if any of these are true:

Legacy-protocol success from a new location.
Non-interactive token use from an IP the user has never used, with no matching interactive sign-in.
Impossible travel with no plausible explanation, or an anonymising IP.
A leaked-credential detection on the user, regardless of the sign-in.
The sign-in was followed within minutes by mailbox rule creation, MFA method registration, or OAuth consent (check the audit log for the user in the same window — this is the decisive evidence).

Call it benign if the location matches known travel, the device is the user's own managed device, and the audit log shows nothing after the sign-in. Confirm with the user by phone, not by email to the account in question, then Confirm sign-in safe in ID Protection so the model learns.

If it is genuinely ambiguous, treat it as compromise for the purposes of containment — revoke sessions and require re-registration — and downgrade later. The cost of a wrong "benign" is far higher than a wrong "compromise".

Beyond one user

Take the suspicious IP and search the whole sign-in log on it. Attackers reuse infrastructure, and finding four users on the same VPN exit changes the incident from one account to a campaign. In Defender XDR, AADSignInEventsBeta in advanced hunting does this across 30 days in a single query, and the KQL primer has the shape.

Make the next one faster

Three things turn a 40-minute investigation into ten: sign-in logs streamed to Log Analytics so you have more than 30 days; a saved workbook or hunting query per scenario; and a written baseline of where your users are supposed to sign in from, so "is this normal?" is a lookup rather than a guess.