AD1.8 Monitoring Sign-In Activity

Navigating the sign-in log

Navigate to entra.microsoft.com → Monitoring → Sign-in logs. The default view shows the interactive sign-in log — every user-interactive authentication. The columns default to: Date, User, Application, Status, IP address, and Location. Customise this view by clicking “Columns” and adding “Device,” “Client app,” and “Conditional access” — these three additional columns give you the context you need without clicking into individual entries.

The log retains 30 days of data (E3) or 90 days (with an Azure AD P2 or E5 license). For investigations that need older data, you’ll need to have been exporting logs to Azure Monitor, a storage account, or a SIEM. For this course, 30 days is sufficient — most identity compromises are detected within days.

Set the time range to “Last 7 days” for your Monday morning review. For incident investigation, narrow to the specific date and time window of the suspected compromise.

The investigation workflow

When you investigate a specific account — because of a reported phishing email, a Defender alert, or a risky sign-in detection — follow this workflow.

Step 1: Filter to the user. Click “Add filter” → User → enter the username or UPN. This reduces the log to only that user’s sign-ins.

Step 2: Scan for unusual IPs. Look at the IP address column. Your office IP addresses should be familiar — they’re the same IPs you see every day. Any IP that isn’t your office, your VPN, or a known Microsoft service IP is worth checking. Click on an unfamiliar IP to see the geolocation.

Step 3: Check for sign-ins from unexpected locations. If the user works in London and you see a sign-in from Lagos, that’s either the user travelling (verify) or an attacker (investigate). Cross-reference with the time — a sign-in from Lagos at 03:00 UK time when the user was at home is suspicious. A sign-in from Lagos when the user is on a business trip is normal.

Step 4: Check the MFA details. Click on a suspicious sign-in and go to the “Authentication details” tab. Look for “MFA requirement: Satisfied by claim” versus “Satisfied by MFA.” “Satisfied by claim” on a first sign-in from a new IP means the session token already had MFA baked in — the AiTM signature. “Satisfied by MFA” means the user completed MFA interactively during this sign-in — which is expected.

Step 5: Check the conditional access tab. Click the “Conditional access” tab. It shows every CA policy that was evaluated for this sign-in and the result: Success (policy satisfied, access granted), Failure (policy not satisfied, access blocked), or Not applied (policy conditions didn’t match). If you see “Not applied” for your MFA policy, there’s a gap — the sign-in wasn’t covered by your conditional access. Investigate why.

Step 6: Check for post-sign-in activity. After confirming a suspicious sign-in, check the audit log (entra.microsoft.com → Monitoring → Audit logs) filtered to the same user and time window. Look for: new MFA method registered, inbox rule created, application consent granted, mailbox delegate added. Any of these within minutes of a suspicious sign-in confirms compromise.

Patterns that indicate compromise

After reviewing hundreds of sign-in investigations, certain patterns reliably indicate a compromised account:

Pattern 1 — The geographically impossible session: A successful sign-in from the user’s normal IP at 09:00, then another successful sign-in from a different country at 09:15. If MFA shows “Satisfied by claim” on the second sign-in, this is almost certainly AiTM token replay.

Pattern 2 — The configuration change cascade: A sign-in from an unusual IP followed within minutes by: a new MFA method registered (attacker adding their phone), an inbox rule created (forwarding financial emails), or a mailbox delegate added (attacker granting themselves persistent access). This is the classic BEC setup pattern.

Pattern 3 — The after-hours service account: A service account (svc-, app-, or named “service”) authenticating interactively (not via client credential flow) at 02:00 from an IP that isn’t your application server. Service accounts don’t take breaks. Interactive sign-ins from service accounts at any time are suspicious, and after-hours authentication from an unknown IP is a strong compromise indicator.

Pattern 4 — The failed-then-succeeded cluster: Multiple failed sign-ins (4625 or “Failure” in the sign-in log) from one IP targeting one account, followed by a successful sign-in from the same IP. This is brute force that succeeded. If MFA blocked the successful attempt, you’re safe — but the user’s password is confirmed compromised and needs resetting.

Building your weekly sign-in review

Your Monday morning sign-in log review takes 10 minutes and covers four checks.

Common false positives you’ll learn to recognise

After a few weeks of Monday morning reviews, you’ll start recognising patterns that look suspicious but are normal for your environment. Document these so you don’t re-investigate the same patterns every week.

VPN exit nodes cause the most frequent false positives. If your organisation uses a VPN that exits in another country, sign-ins through that VPN show a foreign location. Record your VPN provider’s exit IPs and filter them mentally during reviews. With P2 and named locations, you can add these IPs as a trusted location so they stop triggering alerts.

Microsoft background service authentication generates sign-ins that look unusual but are legitimate. Services like Azure Portal, Microsoft Office, and My Apps authenticate automatically when users have browser sessions open. These appear as sign-ins from the user’s IP with unfamiliar user agents. They’re normal.

Shared device sign-ins in hot-desking environments generate patterns that resemble credential sharing — the same IP shows different users within minutes. Expected on shared workstations, suspicious from a single-user laptop.

Mobile network sign-ins show different IP addresses for the same user within short periods because mobile carriers assign IPs dynamically. A user’s phone might show three different IPs across a morning as the carrier rotates addresses. This looks like impossible travel but it’s standard mobile networking.

Document your environment’s normal patterns in a “known false positive” list. Patterns that match the list get skipped. Patterns that don’t match get investigated. The list grows over the first month and stabilises — after that, anything new that doesn’t match is genuinely worth your attention.

Check 1 — Failed sign-ins from external IPs (2 minutes): Filter by Status: Failure, then scan the IP addresses. Clusters of failures from a single IP targeting multiple accounts indicate a password spray. Clusters from a single IP targeting one account indicate brute force. Record the source IPs for threat intelligence correlation if needed.

Check 2 — Successful sign-ins from unexpected locations (3 minutes): Remove the failure filter. Add a filter for “Location” and deselect your country. Any successful sign-ins from unexpected countries require investigation — even if MFA was completed (AiTM passes MFA).

Check 3 — Legacy auth sign-ins (2 minutes): Filter by Client app → select legacy protocols. After deploying CA002 (block legacy auth), this should return zero results. If you see results, your policy has a gap or an exception is being exploited.

Check 4 — Sign-ins to admin accounts (3 minutes): Filter by User → enter each admin account UPN. Every admin sign-in should be from a known IP and known device. Any admin sign-in from an unfamiliar IP is a critical investigation.