4.4 Reading a Sign-In Event
Reading a Sign-In Event: A Worked Example
Every investigation starts by reading individual sign-in events. This subsection walks through a single suspicious sign-in record field by field, showing you exactly how an analyst reads it and what conclusions to draw.
This is the skill that separates competent analysts from everyone else
Anyone can run a KQL query. The skill is in reading the result — knowing which fields matter, what the values mean, and what your next query should be based on what you see. This worked example teaches that reading skill.
The scenario
Your SIEM fires an alert: “Sign-in from unfamiliar location for j.morrison@northgateeng.com.” You open the sign-in log and find this event. Here is how you read it.
Field-by-field analysis
Step through the sign-in event
ResultType: 0 — the sign-in succeeded. This means the attacker (or user) provided valid credentials and satisfied any MFA requirements. A failed sign-in (ResultType != 0) is less urgent — the attacker tried but did not get in. A successful sign-in from an unfamiliar location is the priority.
IPAddress and Location — the sign-in came from Lagos, Nigeria. Your organisation is based in London with no Nigerian operations. This IP has never been associated with this user before. Check: is there a VPN that exits through Nigeria? Is the user travelling? If neither, this is a strong compromise indicator.
Application and client — the sign-in accessed Office 365 via a standard Chrome browser. Nothing anomalous about the application. But check: if this were IMAP or POP3 in ClientAppUsed, it would indicate legacy authentication bypassing MFA — a much more serious indicator. Browser-based access with a valid session means the attacker likely has a stolen token or phished the credentials.
Conditional access and MFA — conditional access allowed the sign-in and MFA was satisfied via authenticator app OTP. But wait: the user says they did not sign in. If MFA was satisfied and the user was not involved, this is the signature of an AiTM attack — the attacker captured the session token after the user completed MFA on a proxy page. The token already contains the MFA claim. This is exactly the scenario you will investigate in Module 13.
Next steps: Query AADNonInteractiveUserSignInLogs for the Lagos IP to check for token refresh activity (confirming token replay). Then check CloudAppEvents for inbox rule creation and EmailEvents for lateral phishing sent from this account. Revoke the user's sessions immediately and force re-authentication. This is the beginning of a full AiTM investigation — Module 13 takes you through the complete process.
Step 1 of 5
The eight-step reading checklist
Every time you read a sign-in event, run through these checks in order:
- ResultType — did it succeed or fail? Success from an unfamiliar location is more urgent than failure.
- IPAddress and Location — where did it come from? Is this a known corporate IP, VPN exit, or completely unfamiliar?
- TimeGenerated — when did it happen? A 2am sign-in for a 9-to-5 employee is suspicious.
- AppDisplayName — what application was accessed? Exchange Online and SharePoint are high-value targets.
- ClientAppUsed — which authentication protocol? Legacy protocols (IMAP, POP3) bypass MFA.
- ConditionalAccessStatus — what did conditional access decide? If it allowed the sign-in, which policies evaluated?
- MfaDetail — was MFA satisfied, and which method? If the user says they were not involved but MFA passed, suspect AiTM.
- DeviceDetail — is this a known, compliant device? An unregistered device from a foreign IP is a strong indicator.
Key takeaways
- Reading sign-in events is a skill you build through repetition — practice with the demo environment
- A successful sign-in from an unfamiliar location with satisfied MFA may indicate AiTM token theft
- Always check both SigninLogs and AADNonInteractiveUserSignInLogs for the same user and IP
- The eight-step checklist gives you a repeatable process for every suspicious sign-in
- Your next query should always be informed by what the current sign-in event tells you