·12 min read

How to investigate a compromised Entra ID account: a step-by-step IR workflow

A practical incident response workflow for investigating a suspected compromised Microsoft Entra ID user — from initial triage to containment, evidence collection, and report generation.

Entra IDMicrosoft 365Incident ResponseDFIR

A user reports they received an MFA prompt they didn't initiate. Or you see a sign-in from an impossible location. Or a privileged admin account starts creating mailbox rules at 3 a.m. These are all signs of a compromised Entra ID (formerly Azure AD) account, and they're the single most common way attackers establish persistence in a Microsoft 365 tenant.

This guide walks through the full investigation workflow: what to check, in what order, and what evidence to preserve. It's based on NIST SP 800-61 and SANS IR process and covers the specific Microsoft telemetry you need to answer the questions a CEO will ask after a breach — what happened, how did they get in, what did they touch, was any data taken?

Before you start: triage in the first 15 minutes

The first 15 minutes determine how the rest of the investigation goes. Three decisions:

  1. Is this confirmed or suspected? A user clicking a phishing link without entering credentials is different from a sign-in from a new country. Triage before you containment-hammer the account.
  2. What's the blast radius? Is this a standard user, a privileged role, or a service account? A compromised Global Administrator needs different handling than a compromised contractor.
  3. Preserve evidence before you change anything. Password resets, revoking sessions, and blocking accounts overwrite timestamps and invalidate tokens. Snapshot the state first.

Step 1: Verify the sign-in is suspicious

Start in the Microsoft Entra admin centre (entra.microsoft.com) under Monitoring & health > Sign-in logs. Filter by the user principal name and look at the last 30 days. You're looking for:

  • Location anomalies — A user based in Sydney signing in from Lagos. Impossible travel (two sign-ins too close in time to be geographically possible) is a strong signal.
  • Device anomalies — A new, unmanaged device appearing in successful sign-ins. Especially one with no Conditional Access context.
  • User agent anomalies — Automated clients like BAV2ROPC or legacy protocols like POP/IMAP on accounts that should only use modern auth.
  • Risk state — Entra's built-in risk detection. Check the Risky users and Risky sign-ins reports. These aren't definitive but they're a useful starting point.
  • Token issuer type — Check for primary refresh token from a device you don't recognise. That's how modern attackers establish persistence.

Step 2: Preserve evidence

Before you do anything that changes state (password reset, session revoke, disable account), pull the evidence. Microsoft's default retention is 30 days for sign-in logs (longer with Entra ID P2 and Purview Audit), but the signals you need right now are in that window.

Collect:

  • Sign-in logs — All sign-ins for the user for the last 30 days, including interactive, non-interactive, service principal, and managed identity categories. Export as JSON or CSV, don't just screenshot.
  • Audit logs — What the user (or anything acting as them) did: group membership changes, app consents, password resets, MFA method additions. Filter by the target user and by initiator.
  • Unified Audit Log from Purview (compliance.microsoft.com) — captures actions across Exchange, SharePoint, Teams, OneDrive. Essential if the attacker touched mail or files.
  • Mailbox rules and forwarding — A classic attacker technique is adding an inbox rule that forwards or auto-deletes specific emails. Check via Get-InboxRule in Exchange Online PowerShell and compare against your baseline.
  • OAuth app consents — Illicit consent grants. Under Enterprise applications > User consent, look for apps the user consented to recently, especially ones requesting mailbox or file scopes.

Step 3: Map the blast radius

Once you've confirmed the compromise and preserved evidence, understand what the attacker had access to. This is the question your CEO will ask: which customers were affected, was PII compromised.

Pivot from the user to:

  • Mailbox contents — What mail folders were accessed? Purview audit records MailItemsAccessed events when Advanced Audit is licensed (E5 or Advanced Compliance add-on). Without it, you're flying blind on read access.
  • SharePoint and OneDrive activity — File access, downloads, sharing links created. Anomalous bulk downloads are the key signal for data exfil.
  • Teams activity — Messages sent, chats joined, files shared. An attacker often pivots via Teams to target colleagues.
  • Devices enrolled — Did the attacker register a new device in the user's name? Check Devices in Entra and compare against known corporate devices.
  • Group membership changes — Did the user get added to any privileged groups? Did they add anyone else? This is how attackers escalate.
  • MFA methods — A newly-added authenticator or phone number is a persistence mechanism. If the attacker added their own MFA method, resetting the password alone won't lock them out.

Step 4: Contain

Only now, with evidence preserved and scope understood, do you contain. In order:

  1. Revoke all refresh tokens for the user. In PowerShell: Revoke-MgUserSignInSession -UserId <upn>. This invalidates active sessions across all devices and apps, forcing re-authentication.
  2. Reset the password and require MFA on the next sign-in. If the user had SSPR, check that the attacker didn't add alternative methods to it.
  3. Remove attacker-added MFA methods. Check under Authentication methods and remove anything the user doesn't recognise.
  4. Disable illicit OAuth consents. Under the affected app, choose Review permissions and revoke anything the user didn't legitimately authorise.
  5. Remove malicious inbox rules. Remove-InboxRule in EXO PowerShell.
  6. For high-risk accounts (Global Admin, service account), consider blocking sign-in entirely until you've fully investigated.

Step 5: Expand the investigation

One compromised account is rarely the whole story. Check whether the same IP, user agent, or autonomous system appears in sign-in logs for other users in the tenant. The attacker's infrastructure is often reused across multiple victims in the same organisation.

Look for:

  • Sign-ins from the same IP or ASN across multiple users
  • The same user agent or token issuer type pattern
  • Similar timing patterns — attackers often hit multiple accounts in a short window
  • Shared OAuth apps across users

If you find more than one compromised account, you're dealing with a broader incident. Escalate accordingly.

Step 6: Report

A good IR report answers five questions clearly:

  1. What happened? A timeline of events from initial access to containment. Timestamps in UTC. Sources cited.
  2. How did they get in? The initial access vector. Phishing? Password spray? Token theft? Third-party app consent?
  3. What did they touch? Every resource the attacker accessed, with confidence level. "Accessed mailbox folder X on 2026-04-15T10:23Z per MailItemsAccessed event ID ..." beats "may have read email".
  4. What was taken? Exfiltration evidence. Download sizes, file counts, forwarded messages. If you can't prove exfil, say so; don't speculate.
  5. Was PII compromised? This is the breach notification question. Depending on jurisdiction (Australian NDB scheme, EU GDPR, US state laws), you may have mandatory reporting obligations with tight deadlines.

Generate the report from the evidence, not from memory. Every claim should trace back to a specific log entry.

Post-incident: harden

Lessons-learned actions worth considering:

  • Block legacy authentication at the tenant level via Conditional Access. BAV2ROPC and basic auth account for a huge proportion of Entra ID compromises.
  • Require phishing-resistant MFA (FIDO2 or certificate-based) for privileged roles.
  • Restrict user consent to verified publishers or require admin consent for scopes that access mail/files.
  • Enable Advanced Audit if you don't have E5. Without MailItemsAccessed you can't prove what wasn't read.
  • Implement Conditional Access policies for risky sign-ins and compliant-device requirements.
  • Baseline your audit log retention. The default is 90 days — for regulated industries you often need longer.

A note on doing this manually vs. with tooling

Everything above can be done by hand in the Entra admin centre, Purview, and PowerShell. It takes hours. For a single compromised user, that's manageable. For an incident that spans multiple accounts or integrates with endpoint telemetry from Defender or CrowdStrike, manual correlation becomes the bottleneck.

That's the problem CICADA IR solves: it pulls sign-in logs, audit logs, mailbox events, and endpoint telemetry into a single investigation workspace, builds the entity graph and timeline automatically, and generates the five-question report for you. See Getting Started if you want to try it.

Want to run this workflow with a tool that does the heavy lifting?

CICADA IR automates evidence collection, entity mapping, and report generation for incidents like this.