Investigating suspicious sign-ins in Microsoft Entra

Sign-in logs are in the Microsoft Entra admin centre under Entra ID > Monitoring & health > Sign-in logs. You need at least the Reports Reader role. There are four kinds, and attackers often show up in the ones people don't open:

• Interactive user sign-ins: a person entering credentials or completing MFA.
• Non-interactive user sign-ins: a client using a token on the user's behalf (mail apps refreshing, Teams in the background). Stolen tokens are replayed here.
• Service principal sign-ins: apps signing in as themselves.
• Managed identity sign-ins: Azure resources signing in.

• Impossible or atypical travel. Sign-ins from two distant places closer together in time than travel allows. Microsoft's ID Protection computes 'Atypical travel' in real time and 'Impossible travel' (from Defender for Cloud Apps) offline. VPNs and mobile carriers cause false positives, so verify with the user.
• Adversary-in-the-middle (AiTM). The user enters credentials and approves MFA on a phishing proxy. In the logs you often see a successful interactive sign-in with MFA from an IP that isn't the user's, seconds after a sign-in from the user's real location, followed by activity from that new IP. ID Protection has an 'Attacker in the Middle' detection for sessions linked to a malicious reverse proxy.
• Token replay. After the theft, the attacker uses the stolen session or refresh token. Look for non-interactive sign-ins from a new IP and user agent, with MFA 'satisfied by claim in the token', and no matching interactive sign-in. ID Protection's 'Anomalous token' detection flags tokens with unusual lifetimes or used from unfamiliar locations, though Microsoft notes it can be noisy at low and medium risk.
• Password spray. Many accounts, one or two attempts each, from a small set of IPs, often over legacy protocols.

Microsoft Entra ID Protection rolls detections into risk levels on sign-ins and users, visible in the Risky users and Risky sign-ins reports. Some detections are available to all tenants (for example Anonymous IP address and Leaked credentials); most of the stronger ones are premium and need Entra ID P2. Treat risk as a lead, not a verdict: confirm with the user, compare with their normal pattern and look at what happened after the sign-in.

1. 01

   Revoke sessions

   Revoke the user's refresh tokens (Revoke-MgUserSignInSession in Microsoft Graph PowerShell, or Revoke sessions in the portal). A password change alone may not end an attacker's existing sessions.

2. 02

   Reset the password

   For hybrid accounts synced from on-premises Active Directory, Microsoft's token theft playbook says to reset the password twice.

3. 03

   Review MFA methods

   Remove any phone or authenticator the user didn't register.

4. 04

   Block the attacker's infrastructure

   Microsoft suggests blocking attacker IPs, while noting VPN-based attackers change addresses. A Conditional Access block for unexpected countries helps more.

5. 05

   Check persistence

   Inbox rules, forwarding, app consents, new devices registered, and any admin role changes.

6. 06

   Harden

   Require phishing-resistant MFA for the affected user group and consider token protection where supported.

Write down what you knew and when. A defensible investigation records: the trigger (alert, user report), each search and its criteria, exported sign-in records with correlation IDs, the timeline in UTC and local time, attacker IPs and user agents, what was accessed, containment steps with timestamps, and open questions. Export raw logs before retention removes them, and keep originals unchanged.

If personal information may have been accessed, you may have obligations under PIPEDA or provincial privacy law. Talk to your counsel early. Sources: Microsoft Learn: 'Sign-in logs in Microsoft Entra ID', 'Microsoft Entra data retention', 'What are risk detections?' (ID Protection), the 'Token theft playbook' and 'Block legacy authentication with Conditional Access'.