A Microsoft 365 account compromise often starts with a simple support ticket.
The ticket comes in, the password is reset and the user gets back to work. At that point, it is easy to treat the incident as resolved because the immediate problem appears to be gone.
In reality, resetting the password only gets you back in control of the account. You still need to understand what led to the compromise and what impact it may have had.
The investigation should also help identify what allowed the incident to happen and what should change afterwards.
With those goals in mind, the rest of this article covers the areas I focus on when investigating a compromised Microsoft 365 account.
Confirm What Actually Happened
In my experience, many account compromise tickets start the same way: someone notices a suspicious or spam message using the user’s address.
That is a useful lead, but not proof that the account itself was involved. The sender address may have been spoofed, so first confirm whether the message actually passed through your tenant.
Check Exchange Online message trace for the message. If you have the original copy, review its headers as well to see where the message came from and whether its path matches what you would expect from a legitimate message sent through the tenant.
If the message is absent from your mail-flow records, spoofing becomes more likely. Before ruling out an account compromise, review the user’s sign-in activity for unfamiliar locations, devices, IP addresses and authentication events.
Limit Further Access
If the evidence points to an actual account compromise rather than spoofing, contain the account first and continue the investigation from there.
Containment usually requires more than one action:
- Block the account to prevent new sign-ins.
- Reset the password to ensure the current password can no longer be used.
- Revoke active sessions to invalidate refresh tokens and force reauthentication. Revocation does not guarantee that every existing session ends immediately.
- Review authentication methods and remove anything unfamiliar.
Do not forget the user’s device. If malware cannot be ruled out, isolate and investigate it before allowing the user to sign in again.
Otherwise, you may hand the attacker the new credentials yourself.
Build the Incident Timeline
By the time someone notices the first suspicious activity, the compromise may already be days or weeks old.
Work backwards across the available evidence, including sign-in logs, Entra audit logs, Purview Audit and endpoint alerts, to find the earliest suspicious event you can.
Then follow the timeline forward, documenting what happened until the account was contained.
Understand Your Log Retention
Before drawing conclusions from the timeline, make sure you know how far back the available logs actually go.
Retention varies by log source and licensing. Once the data has expired, that part of the history is no longer available for review.
This means even a thorough review of the remaining logs can leave gaps in the incident timeline.
If those gaps make it impossible to determine when the compromise began, document that limitation clearly.
Look for Persistence
Containment does not remove every access path an attacker may have created. Persistent access may remain in several places, and some of those changes may already have been reverted or removed before the investigation begins.
Review both what exists now and what changed during the period under investigation. For anything suspicious, determine whether it was used and remove the access it provides.
Authentication Methods
An unfamiliar authentication method can allow the attacker to authenticate again without knowing the new password.
Review the user’s registered methods and use the Entra audit logs to identify changes made during the period under investigation.
Mailbox Rules and Forwarding
Inbox rules and forwarding can silently move messages outside the organization or hide replies and other evidence from the user.
Check the current mailbox configuration and Purview Audit for suspicious rules or forwarding changes, including ones that no longer exist.
Application Consent
A malicious OAuth grant can give an application continued access to Microsoft 365 data without relying on the user’s password.
Review unfamiliar or recently approved applications and check for activity during the period under investigation.
If you find a suspicious grant, remove it and investigate the application itself. A malicious application may have access through other users or tenant-wide consent as well.
Delegated Access
Mailbox permissions can give another account independent access to the user’s mailbox.
Review Full Access, Send As and Send on Behalf permissions for suspicious changes, then investigate any account that received unexpected access.
Assess the Impact
Start with the activity already identified in the timeline and look at what else the compromised identity could have reached.
| Area | What to check |
|---|---|
| Messages | What was sent, to whom, and whether recipients interacted with it |
| Mailbox access | Shared mailboxes and other mailbox permissions |
| Files and collaboration | OneDrive, SharePoint, Teams, and other resources available to the identity |
| Applications and SSO | Enterprise applications, OAuth permissions and third-party services available through the identity |
| Privileged access | Administrative actions, role assignments, and access to other identities or tenant resources |
Map the resources and permissions available to the compromised identity, including access that may never appear as activity in the logs. Users rarely have a complete view of permissions accumulated over time through group memberships, shared resources or delegated access.
Document the Known and Unknown
Your incident report should separate confirmed activity from potential exposure and anything the current evidence cannot determine.
Record the evidence reviewed, the period it covers, and any gaps that limit your conclusions. Make it clear where the timeline is based on confirmed events and where uncertainty remains.
The report may later be needed by the customer, management, an insurer, or a regulatory authority. For that reason, its conclusions should make sense to someone who was not involved in the investigation.
If you write, “This did not happen,” be prepared to explain how the available evidence supports that conclusion.
Do not make the report more certain than the evidence allows.
Conclusion
An account compromise should result in more than a password reset and a closed ticket.
By the end of the investigation, you should have a clear enough picture of what happened to explain the response and any uncertainty that remains.
Use what you learned to improve the environment and refine the response process, then close the incident with a record you would be comfortable defending later.