How to Investigate a Compromised Entra ID Account: Sign-Ins, Tokens, Mailbox and App Scoping

When an Entra ID account is suspected of compromise, resetting the password answers nothing about what the attacker already did: which sessions they hold, which mail and files they read, and what they planted that will outlive the reset. The evidence is spread across the interactive and non-interactive sign-in logs, the Entra audit log, the Microsoft 365 audit log and, if enabled, the Microsoft Graph activity log. This guide gives SOC analysts and incident responders an ordered investigation: anchor on the attacker's sessions, follow their tokens, scope mailbox and file access, and find persistence. It is the Entra counterpart to the How to Investigate CloudTrail for a Compromised Access Key guide and assumes the response process in the Identity Incident Response Playbook.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public incident response and Entra documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Anchor on the attacker's session, not the user. Find the first suspicious sign-in, then pivot on its SessionId, IP address, ASN and user agent; the legitimate user's activity on the same account is noise to separate out.
• Most attacker activity is non-interactive. A stolen refresh token or session cookie produces token redemptions in AADNonInteractiveUserSignInLogs, not new interactive sign-ins, so an investigation that reads only SigninLogs undercounts.
• A password reset does not end a token. Revoking sessions stops new tokens being issued, but an access token already issued stays valid until it expires, one hour by default, unless the app supports Continuous Access Evaluation.
• Scope means data plus persistence. The deliverable is two lists: what the attacker read or changed (mail, files, directory objects) and what they left behind (methods, devices, inbox rules, app consents, credentials, roles).
• Logs you did not enable cannot help. Entra keeps sign-in and audit logs for 30 days on P1 or P2, and Graph activity logs are not retained at all unless exported, so check what exists before planning the timeline.

When you need this

• Identity Protection risk: a user flagged at high risk, or detections such as anomalous token, unfamiliar sign-in properties or attempted access of a Primary Refresh Token. See the Microsoft Entra ID Protection guide.
• User report: unexpected MFA prompts, a new authentication method the user did not add, or sent mail they did not write.
• Mail signals: new forwarding or inbox rules, partners reporting invoice fraud from the account, or bulk mail from it.
• Phishing confirmed: the user entered credentials on an adversary-in-the-middle page, approved a device code prompt or consented to an unknown app. See the AiTM Phishing Guide.

If the account holds a privileged directory role, treat the tenant as potentially compromised and widen scope from the start.

Before you start

1. Preserve first: export the relevant sign-in, audit and Microsoft 365 audit records for the account to a case store before anything ages out. Retention changes are not retroactive.
2. Agree containment timing: decide with the incident lead whether to contain immediately or observe briefly. For an active attacker with mailbox access, contain first.
3. Use a clean admin path: investigate from a privileged access workstation and an account that is not the suspected one.

Step-by-step investigation

1. Find the first suspicious sign-in

Query both sign-in tables for the user over the full available window. Summarise by IPAddress, AutonomousSystemNumber, LocationDetails, DeviceDetail.deviceId, UserAgent and AppDisplayName. Attacker sessions typically show an IP or ASN the user has never used, no device ID or an unregistered device, and a user agent that differs from the user's managed devices. Check ResultType (0 is success), AuthenticationRequirement and ConditionalAccessStatus to see whether MFA was satisfied and how. Read the Entra ID Sign-In and Audit Log Detection Guide for the error codes and field meanings.

2. Follow the session and its tokens

Take the SessionId of the first attacker sign-in and pull every interactive and non-interactive record with that session ID. Each token redemption has a UniqueTokenIdentifier; IncomingTokenType shows what was presented (for example a primary refresh token). A session that continues from new IPs after the user's own sign-in, or non-interactive redemptions from a different ASN than the original sign-in, points to token replay rather than a password-only compromise. See the Session Token Theft Response Playbook and the Entra ID Primary Refresh Token (PRT) Security Guide.

3. Trace what the tokens were used for

If Graph activity logs are enabled, join MicrosoftGraphActivityLogs.SignInActivityId to UniqueTokenIdentifier in the sign-in tables, as Microsoft's own example query does. This gives each API call the attacker made: RequestUri, RequestMethod, ResponseStatusCode and the AppId used. Look for mail and file enumeration, directory reads of users and groups, and failed calls (401 and 403) that show what the attacker tried. Microsoft notes most Graph events arrive within 30 minutes and some take up to two hours.

4. Scope mailbox access

Search the Microsoft 365 audit log for MailItemsAccessed on the account's mailbox over the attack window. Microsoft documents two access types:

• Sync: written when a desktop Outlook client syncs a folder. If a sync record shares the attacker's ClientIPAddress, ClientInfoString or SessionId, Microsoft's guidance is to assume the whole folder, and likely the mailbox, was taken.
• Bind: individual message access, carrying InternetMessageId. Binds within a two-minute interval are aggregated, with OperationCount giving the number.

Then check inbox and forwarding rules created or changed in the window, delegate permissions added to the mailbox, and mail sent from the attacker's session. See the How to Audit Mailbox Forwarding and Inbox Rules guide and, where payments are involved, the Business Email Compromise Response Playbook.

5. Scope files and other apps

In OfficeActivity or Purview Audit, filter SharePoint and OneDrive operations by the attacker's IP and session: file access, downloads, sharing links created and external sharing. In the sign-in logs, list every AppDisplayName and ResourceDisplayName the attacker session reached; each SaaS app federated to Entra is a separate place to look, with its own logs.

6. Hunt for persistence in the audit log

Filter AuditLogs for the account as actor or target in the attack window. The persistence that matters most:

For consent abuse, see How to detect OAuth consent phishing in Entra ID. The full detection set for these events is in the Entra ID Audit Log Detection Guide.

7. Widen to related accounts

Pivot on the attacker's IPs, ASNs and user agents across all users' sign-ins. AiTM and password spray campaigns rarely hit one account. Check whether phishing mail was sent internally from the compromised mailbox and who opened it.

Containment and eradication

Microsoft's token theft playbook and its revoke access guidance give the order below. Run steps 1 to 3 together so the attacker cannot re-establish access between them.

1. Disable the account: clear Account enabled in the Entra admin centre or set AccountEnabled to false with Microsoft Graph. For synced accounts, disable in Active Directory as well.
2. Reset the password: for hybrid accounts, Microsoft advises resetting twice with random values.
3. Revoke sessions: "Revoke sessions" in the admin centre or Revoke-MgUserSignInSession. New tokens cannot be issued; access tokens already issued remain valid until expiry (one hour by default) except in apps that support Continuous Access Evaluation. Apps with their own session cookies keep them until the app ends the session.
4. Mark the user compromised in ID Protection and confirm risk-based Conditional Access policies apply.
5. Remove what was planted: delete unknown authentication methods and devices before re-enabling, remove attacker inbox rules and mailbox delegates, revoke unknown consent grants, and roll back any directory changes the account made.
6. Block attacker infrastructure: named locations or Conditional Access for attacker IP ranges, noting that attackers rotate IPs.
7. Re-enable with strong methods: re-register the user with phishing-resistant methods using a Temporary Access Pass issued after identity verification.

See the Global Token Revocation Guide for apps that need separate session termination.

Decision points

• Password-only or token theft: if attacker activity continues from the same session ID without new interactive sign-ins, treat it as token theft: revoke sessions and check the device for token theft malware, not just the password.
• Observe or contain: contain at once if mail is being read or payments are at stake. Short observation is defensible only when the account has no privilege and you need the attacker's infrastructure for wider scoping.
• Privileged account: if the account held a directory role during the window, every change it made is suspect. Escalate to a tenant compromise investigation and check federation, cross-tenant and Conditional Access settings.
• Notification: if MailItemsAccessed or file access shows personal data was read, involve privacy counsel. The Data Breach Notification Checklist sets out common triggers and deadlines.

Verify it worked

• No successful interactive or non-interactive sign-ins from attacker IPs, ASNs or session IDs after containment.
• The user's authentication methods and registered devices match what the user confirms owning.
• No inbox rules, forwarding or delegates that the user did not create.
• No app consents or credentials added during the window remain.
• Risk state in ID Protection is remediated, and the user signs in only from expected devices.

Common errors and how to avoid them

• Reading only interactive sign-ins: token replay appears in the non-interactive log; always union both tables.
• Resetting the password and closing the case: sessions, methods, devices, rules and consents survive a reset.
• Searching the Entra audit log for inbox rules: mailbox rules are in the Microsoft 365 audit log.
• Re-enabling before cleanup: an attacker-registered authenticator lets them sign straight back in.
• Treating Bind counts as a full list: aggregation and Sync records mean actual exposure is often larger than the visible messages; Microsoft advises assuming more was accessed.
• Waiting to export: 30-day retention means a slow start loses the first days of the attack.

Measuring readiness

• Log coverage: sign-in (both tables), audit, Microsoft 365 audit and Graph activity logs exported with at least 12 months of retention.
• Time to contain: median minutes from alert to disabled account and revoked sessions.
• Time to scope: hours from containment to a signed-off list of data accessed and persistence removed.
• Persistence found after closure: count of cases reopened because a method, rule or consent was missed. Target zero.
• Exercise frequency: tabletop or purple team runs of this procedure per year.

Framework mapping

Practitioner checklist

• Export sign-in, audit and Microsoft 365 audit records for the account before anything else.
• Identify the first attacker sign-in and its session ID, IP, ASN, device and user agent.
• Union interactive and non-interactive sign-ins and follow the session's tokens.
• Join Graph activity logs to sign-ins on the token identifier where available.
• Scope mailbox access with MailItemsAccessed Sync and Bind records.
• Scope SharePoint, OneDrive and every federated app the session reached.
• List and remove methods, devices, rules, delegates, consents, credentials and roles added in the window.
• Disable, reset, revoke sessions and mark compromised together, then re-enable with phishing-resistant methods.
• Pivot on attacker infrastructure across all users.
• Record data accessed for the notification decision.

Standards and references

• Microsoft Learn: Token theft playbook
• Microsoft Learn: Revoke user access in Microsoft Entra ID
• Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
• Microsoft Learn: Azure Monitor Logs reference, SigninLogs table
• Microsoft Learn: AADNonInteractiveUserSignInLogs table
• Microsoft Learn: Access Microsoft Graph activity logs
• Microsoft Learn: Microsoft Entra data retention
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management

Related NHI Mgmt Group resources: Identity Incident Response Playbook · Entra ID Sign-In and Audit Log Detection Guide · Session Token Theft Response Playbook · How to Investigate CloudTrail for a Compromised Access Key