Your Microsoft 365 account was breached. What now?
A first-hour response that revokes access, preserves cloud evidence, checks the persistence paths attackers commonly leave behind, and explains the recovery route when you cannot sign in.
Scope
For Microsoft 365 and Entra ID administrators responding to a suspected user or administrator account takeover, including lockouts caused by changed passwords or MFA methods.
Start with the situation, not the slogan
An incident rarely arrives with a neat label. It arrives as a forwarded screenshot, a worried telephone call, or a monitoring alert written by a machine with no sense of occasion. In this case “Your Microsoft 365 account was breached. What now?” is the working heading, but the label is only a starting hypothesis. The useful work is to establish what happened, what can still happen, and which decision cannot safely wait.
Keep three clocks in view: the attacker’s opportunity, the business interruption, and the lifetime of the evidence. They do not run at the same speed. A hasty change may interrupt access but erase context; a perfect investigation conducted at geological pace may leave the organisation exposed. Good response is the slightly unglamorous art of making the next reversible decision with the best evidence currently available.
Cloud identities can be abused without malware on a laptop. Stolen sessions, changed authentication methods, mailbox rules, delegated permissions, and OAuth grants may keep access alive after a password change.
Composite scenario
How this usually reaches the desk
Imagine the report begins with this observation: “Sign-ins from unfamiliar locations, devices, autonomous systems, or impossible travel patterns.” A second check returns another clue: “New inbox rules, forwarding addresses, authentication methods, app consents, or role assignments.” Neither fact alone tells the whole story. Together they justify a documented incident, a defined owner, and a deliberate containment decision. This is where a timeline beats a collection of heroic memories; memory is an excellent storyteller and a dreadful audit log.
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.
Sign-ins from unfamiliar locations, devices, autonomous systems, or impossible travel patterns.
Record the exact time, source, identity, system and time zone. Compare it with a known-good baseline and with what the user or service owner expected. A surprising event is a lead, not a conviction.
New inbox rules, forwarding addresses, authentication methods, app consents, or role assignments.
Look for the control-plane event that made the visible activity possible: a changed credential, permission, rule, route, token or trusted device. Persistence often looks administrative because, technically, it is.
Unusual message sends, mailbox searches, file downloads, or repeated MFA prompts reported by the user.
Correlate the report with independent telemetry before deciding scope. User testimony, identity logs, endpoint evidence and service audit records are strongest when they agree on sequence rather than merely on mood.
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.
What to do
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
Containment and recovery are different verbs. Containment limits the next harmful action; recovery returns a service to trustworthy operation. Between them sits eradication: removing the access path and persistence that would make the freshly restored service merely a cleaner target. For Microsoft 365, Entra ID and Exchange, keep those decisions separate in the timeline even if a small team performs them minutes apart.
Communication is also a control. Tell affected people what is known, what remains uncertain, what they must do and when the next update will arrive. Avoid both melodrama and false reassurance. “We are investigating” is useful only when followed by an owner and a time. The goal is to reduce secondary harm without teaching a possible attacker exactly what the team has discovered.
Handover
Make the result useful to the next person
Maintain two views of the incident. The working timeline should contain detailed events, evidence locations, hypotheses and technical actions. The stakeholder update should contain confirmed impact, current containment, material uncertainty, decisions required and the next reporting time. Do not copy speculative indicators into executive statements. Equally, do not polish away uncertainty merely because it looks untidy. Both records should use absolute times with a declared time zone and should identify the source of each important fact.
At shift change, hand over the current scope, trusted administration path, preservation status, active controls, failed actions, business priorities and the next three decisions. Read back the most consequential assumptions. For this case, ensure the record begins with “Declare an incident, record the time, affected identity, reporter, and known business impact. Use a separate trusted administrator account for response.” and does not finish until the team has addressed “Search for related activity across recipients, shared mailboxes, and accounts that used the same device, IP, application, or phishing lure.” A concise, accurate handover prevents the incoming team from repeating disruptive work or mistaking a quiet telemetry gap for successful containment.
Validate before you close
Confirm that old sessions no longer work, unknown persistence is gone, expected email flow is restored, and monitoring covers the affected identity for renewed access attempts. Record what was checked, not just what was changed.
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
- Resetting systems before preserving volatile evidence and audit logs.
- Treating the first visible symptom as the complete scope of the incident.
- Restoring service without verifying that the attacker’s access path is closed.
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
Does one suspicious event prove compromise?
No. Treat “Sign-ins from unfamiliar locations, devices, autonomous systems, or impossible travel patterns.” as a reason to investigate and preserve evidence. Confidence should rise when independent identity, service, endpoint or network records support the same sequence.
Should we reset everything immediately?
Reset or revoke what the evidence and risk justify, but preserve the state you will need to understand the incident. Broad, undocumented resets can interrupt the attacker, the business and the investigation in one impressively efficient stroke.
When can the incident be closed?
Confirm that old sessions no longer work, unknown persistence is gone, expected email flow is restored, and monitoring covers the affected identity for renewed access attempts. Record what was checked, not just what was changed. Closure also requires named owners for residual risk and follow-up work; “it seems quiet now” is an observation, not an exit criterion.
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
- View Activity Logs of Application PermissionsMicrosoft Learn
- What’s the difference between a Microsoft account and a work or school account?Microsoft Support
- Help with the Microsoft account recovery formMicrosoft Support
- 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
- Contact Microsoft customer supportMicrosoft Support
- Microsoft Graph PowerShell OverviewMicrosoft Learn
Editorial status: first edition. Review the linked vendor documentation for product- and version-specific changes before acting.