Playbook: Microsoft 365 account compromise
A role-based cloud identity response checklist from declaration through session revocation, evidence, persistence review, lockout recovery, and monitoring.
Scope
For help desk, identity, security, legal, and business owners responding to a suspected Microsoft 365 account takeover, including cases where the affected administrator cannot sign in.
Start with the situation, not the slogan
A playbook is a decision aid for tired people working with incomplete information. Playbook: Microsoft 365 account compromise therefore names owners, evidence, containment and exit criteria instead of pretending every incident follows a flowchart. Read it before the incident, tailor the contacts and systems, and exercise the awkward branches.
The first objective is shared situational awareness: what is known, who owns the incident, what business process is at risk, and which decision is due next. A chat channel full of competent people is not the same as command. Assign a coordinator and a note taker, even when the organisation is small enough for both to use the same kettle.
Under pressure, teams often reset the password and stop. The playbook keeps evidence, token revocation, mailbox changes, application consent, related users, access recovery, and communication in scope.
Composite scenario
How this usually reaches the desk
The playbook should activate when the team can establish its entry conditions, including: A named incident commander and trusted administrator are assigned. If the report remains ambiguous, open a low-severity record and time-box validation rather than ignoring it or declaring the end of civilisation. Escalate as evidence, privilege, spread or business impact increases.
This scenario combines common operational patterns; it is not presented as a report of one named incident.
What to look for
Begin with preserved, comparable evidence. One signal is rarely proof; use independent observations and a reliable timeline before declaring scope or intent.
A named incident commander and trusted administrator are assigned.
Confirm this condition from an authoritative source and note who supplied it. Mark assumptions as assumptions; they have an unfortunate habit of becoming facts in copied status updates.
The affected account, privilege, devices, applications, mailboxes, and business processes are identified.
Identify the decision that depends on the information and the deadline for obtaining it. Evidence is most useful when it changes action rather than merely decorating the timeline.
Evidence retention windows and export owners are known before containment.
Check coverage and retention before containment. If a source is unavailable, record the gap and use independent evidence rather than silently treating absence as innocence.
Access recovery
You cannot sign in. Choose the correct route.
First identify the account type. A personal Microsoft account used for Outlook.com, Xbox or Microsoft 365 Family is not the same identity system as a work or school account managed in a Microsoft 365 tenant. The sign-in screen may look familiar, which is a splendid piece of visual consistency and a poor incident classifier. Use the recovery path for the account you actually have.
Employee or ordinary work account
Try the organisation’s self-service password-reset route if it was configured before the incident. If that fails, contact the internal administrator or service desk through a trusted channel. Ask them to verify the request, inspect recent sign-ins and authentication methods, reset the password where appropriate, require MFA re-registration, and revoke active sessions. Do not use the consumer recovery form for a work or school identity.
Administrator, with another privileged administrator available
Use the second trusted administrator or an approved partner with sufficient delegated rights. In Microsoft Entra, an appropriately privileged administrator can review the affected user’s authentication methods, reset credentials, require MFA re-registration and revoke sessions. Preserve the unfamiliar methods and audit events before removing them. Restoring the login is only the beginning; continue the compromise investigation after access returns.
Sole Global Administrator, no emergency account
This is a tenant lockout, not an invitation to improvise around authentication. Check for a documented emergency-access account and for a Microsoft partner that genuinely retains suitable delegated administration. If neither exists, contact Microsoft 365 business support using Microsoft’s current global support page and state plainly: “Microsoft 365 business tenant lockout; the only Global Administrator cannot authenticate.” Be ready to complete Microsoft’s ownership and identity checks. Use an external email address and telephone number that you can actually access for case communication.
Personal Microsoft account
Use Microsoft’s Sign-in Helper first. If directed to the personal account recovery form, complete it from a familiar device and location and provide accurate historic details. Microsoft states that support agents cannot bypass two-step verification or manually send a reset link when none of the registered verification methods is available. Anyone selling a secret back door is offering, at best, an expensive lesson in optimism.
While access is being recovered
Open an internal incident record outside the affected tenant. Preserve the original alert, suspicious messages, account name, tenant domain, approximate compromise time, known-good contact details, invoices or subscription identifiers, and the support case number. Ask colleagues not to approve new MFA prompts or trust payment requests from the affected mailbox. If mail fraud is plausible, warn finance and counterparties through previously verified telephone numbers.
Do not delete the domain, create look-alike replacement tenants, or pay a stranger who promises to “unlock” Microsoft identity. Those actions do not revoke the attacker’s sessions and can complicate ownership verification. Once administrative access is restored, follow the same containment and evidence steps as any other compromise: revoke sessions, rotate credentials, review authentication methods, mailbox rules, forwarding, delegates, application consent, privileged roles, devices and audit logs.
Working examples
Run it, read it, decide what changes
These examples use documentation addresses, test identities and bounded targets. Replace placeholders only inside systems you own or are explicitly authorised to operate. Read the expected result and next action before running the command; a successful command is evidence, not yet a conclusion.
Revoke Microsoft 365 sign-in sessions
- Prerequisites
- A clean administrator workstation, Graph PowerShell installed, and delegated permission `User.RevokeSessions.All`.
Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId "alex@example.com"The command returns `True` when the revocation request is accepted.
Revocation is not instantaneous for every application and does not replace disabling a compromised account or rotating credentials.
Record the time, reset the password from a clean device, remove hostile authentication methods, and inspect sign-in logs for activity after revocation.
Review recent Entra sign-ins
- Prerequisites
- Permission to read audit logs, an appropriate Entra licence, and the affected user principal name.
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'alex@example.com'" -Top 50 |
Select-Object CreatedDateTime,IpAddress,AppDisplayName,ClientAppUsed,ConditionalAccessStatusThe newest sign-ins are listed with source IP, application, client and Conditional Access result.
An unfamiliar country is not proof by itself; VPNs and mobile networks move addresses. Correlate time, device, client, application and user activity.
Export the raw records, identify the first suspicious sign-in, and widen the time window around credential, MFA and application-consent changes.
Find suspicious Exchange inbox rules
- Prerequisites
- The Exchange Online module and permission to inspect the affected mailbox.
Connect-ExchangeOnline
Get-InboxRule -Mailbox "alex@example.com" |
Select-Object Name,Enabled,Priority,ForwardTo,RedirectTo,DeleteMessage,MoveToFolderEvery server-side rule is listed, including forwarding, redirect, deletion and folder actions.
A rule with an innocent name can still hide replies or invoices. Confirm each rule with the mailbox owner and audit data before removal.
Export the list, disable confirmed hostile rules, inspect forwarding and delegates, and search for messages affected by the rule.
Response sequence
Read the whole sequence before starting. Several workstreams may run in parallel, but their evidence, authority and expected outcomes still need to be explicit. Every step below points back to a concrete example; use the example as implementation evidence, not as permission to operate outside the stated scope.
Operational judgement
Run the playbook as a checklist with judgement, not as a spell. For Microsoft 365, Playbook and Identity, localise tenant names, log locations, provider contacts, legal thresholds, emergency credentials and business priorities. A generic document becomes operational only when the people on duty can find the required access without consulting the person currently on holiday.
Use a decision log separate from the task list. For each consequential action, note time, owner, evidence, choice, expected effect and observed result. This gives later reviewers something better than a reconstructed story and helps the next shift understand why a seemingly obvious action was delayed or rejected.
Handover
Make the result useful to the next person
Prepare the playbook package before an incident: primary and deputy owners, current contact routes, system inventory, evidence locations, delegated authority, provider escalation, legal and privacy triggers, secure communication, and emergency credentials. Keep a printable or otherwise independent copy where an identity or collaboration outage cannot hide it. Review contact details during exercises; telephone numbers appear to age faster than almost any cryptographic primitive.
For this playbook, the incident record should open with “Declare severity, time, user, role, business impact, and communication channel.” and drive deliberately towards “Restore access deliberately, monitor for recurrence, communicate impact, and assign control improvements.” A shift handover must state confirmed facts, open hypotheses, business impact, containment already applied, evidence at risk, approvals pending and the next scheduled update. After closure, turn lessons into owned changes to controls, documentation and exercises. A lesson without an owner and a date is simply a well-written regret.
Validate before you close
Exit when identity and mailbox integrity are accepted, related scope is handled, old access is invalid, monitoring is active, and decisions and owners are recorded.
Capture the test, the expected result and the observed result. Where a person or business owner must accept restored service, name them in the record. A green dashboard can confirm that a component is answering; it cannot confirm that invoices, identities or restored data are trustworthy.
Finish with a compact closure note: the original trigger, confirmed scope, evidence retained, controls changed, tests passed, known gaps, residual risk, and the people responsible for the remaining work. Schedule a review while the timeline is still fresh enough to challenge. The purpose is not to find a person to blame; computers already perform blame with admirable efficiency. The purpose is to make the next response faster, safer and less dependent on one person remembering where the useful log was hidden.
Common mistakes
- Running the playbook without assigning a decision owner and note taker.
- Containing too early or too late because evidence and business impact were not compared.
- Closing the incident without documenting recovery checks and follow-up owners.
These errors usually come from haste, unclear ownership or misplaced confidence. Build the safeguard into the runbook: a required evidence field, a second-person review, a rollback test or a specific exit criterion.
Questions people ask when the clock is running
Who may activate the playbook?
Define that locally before an incident. Help desk or monitoring staff should be able to open a record and escalate; containment authority may sit with incident command, service ownership or an executive depending on impact.
Must every step be completed in order?
No. Evidence, containment, communication and recovery often run in parallel. Keep dependencies explicit and do not let a later checkbox imply that an earlier decision was actually verified.
What is the exit condition?
Exit when identity and mailbox integrity are accepted, related scope is handled, old access is invalid, monitoring is active, and decisions and owners are recorded. Residual risk, communication and improvement actions still need named owners even after service is restored.
Safety boundary
Use these steps only on systems you own or are explicitly authorised to assess. Preserve evidence, follow your organisation’s legal and regulatory obligations, and prefer reversible actions when the situation is not yet understood.
Primary references
- Responding to a Compromised Email AccountMicrosoft Learn
- Revoke User Access in an EmergencyMicrosoft Learn
- Manage authentication methods for Microsoft Entra multifactor authenticationMicrosoft Learn
- Manage emergency access accounts in Microsoft Entra IDMicrosoft Learn
- Get support for Microsoft 365 for businessMicrosoft Learn
- SP 800-61 Rev. 3: Incident Response Recommendations and ConsiderationsNIST
- Microsoft Graph PowerShell OverviewMicrosoft Learn
Editorial status: first edition. Review the linked vendor documentation for product- and version-specific changes before acting.