Recent sign-in evidence
Collect seven days of Microsoft Entra sign-in activity for the affected identity and preserve the result for review.
Microsoft 365 incident response
Use an ordered response to contain the identity, preserve evidence, find persistence, recover access safely, and leave a clear incident record across the customer workflow.
For administrators and MSP technicians responding to a suspected cloud identity or business email compromise. Follow your incident-response, legal, insurance, and customer-notification requirements.
First response
Speed matters, but sequence matters too. Record the initial facts before cleanup changes the evidence, then contain the identity while you determine how far the attacker reached.
Capture the user principal name, customer, reporter, first known symptom, time window, affected payments or conversations, and the technician who owns the response.
Block new sign-ins while the account is investigated. For synchronized or federated identities, coordinate the change with the authoritative on-premises identity source.
Revoke Microsoft Entra sessions, then remember that application-issued session tokens can follow their own expiry and revocation behavior.
Use a strong temporary credential and the correct cloud or hybrid reset process. Do not assume a password reset removes app consent, a rogue MFA method, or every existing session.
Preserve sign-in and audit activity, mailbox rules and forwarding, sent messages, permissions, authentication methods, applications, devices, and relevant security alerts.
If the attacker touched invoices, payroll, banking, customer communications, or privileged access, notify the appropriate internal owners through a trusted channel immediately.
Recognize the signal
A single risky sign-in or inbox rule does not prove compromise. Several signals in the same time window, a successful unfamiliar sign-in, unexplained persistence, or verified fraudulent mail raise the urgency.
MSPControl and VirtuBot
MSPControl’s established ticket-based response path can keep the affected customer and user visible while VirtuBot collects core evidence and executes the containment actions enabled in the security-ticket policy.
Collect seven days of Microsoft Entra sign-in activity for the affected identity and preserve the result for review.
Collect seven days of Microsoft 365 unified-audit records associated with the user and attach the workbook to the incident ticket.
Collect the user’s associated Exchange Online mailbox rules and attach them to the ticket so hidden forwarding or message handling can be reviewed.
After the configured gates are met, the policy can disable the Microsoft 365 user, revoke sign-in sessions, and reset the password. Each action also has a test mode.
Internal notes, discussion notes, remediation tasks, and Teams notifications can keep technicians and the security workflow aligned.
The technician validates data completeness, investigates additional persistence, decides what to remove, restores access, and confirms the customer follow-up.
Current boundary: this workflow does not claim automatic removal of attacker-added MFA methods, application consent, mailbox rules, delegated access, devices, or sharing links. Those checks and decisions remain part of the technician’s investigation. Policy settings, permissions, tenant state, Microsoft licensing, and the identity topology affect what can run.
Investigate persistence and scope
The attacker may have created another way back in or reached data outside the mailbox. Work through the full checklist before returning the account to normal use.
| Review | What to look for | Why it matters |
|---|---|---|
| Authentication methods | New authenticator registrations, phone numbers, FIDO keys, temporary access methods, or missing expected methods. | A rogue method can let the attacker authenticate after the password changes. |
| Applications and consent | Unknown enterprise applications, user consent, service principals, delegated permissions, and recently created registrations. | Consent-based access can survive credential resets. |
| Roles and policy changes | New Entra or Azure roles, Conditional Access exclusions, security-setting changes, and altered administrative relationships. | The compromised identity may have expanded access or weakened controls. |
| Mailbox persistence | Inbox rules, external forwarding, delegates, folder permissions, transport behavior, trusted senders, and suspicious signatures. | Attackers hide replies, redirect mail, and preserve access to conversations. |
| Message activity | Sent Items, Deleted Items, message trace, unusual recipient volume, reply-chain hijacking, and restricted-sender status. | This defines who received malicious mail and what business process was touched. |
| Sign-in and audit timeline | Successful and failed sign-ins, IPs, locations, applications, device details, audit operations, and the first suspicious timestamp. | A timeline separates attacker actions from legitimate activity and response changes. |
| Devices, files, and sharing | Unknown registered or managed devices, OneDrive and SharePoint activity, anonymous links, downloads, and unusual sharing changes. | The incident can extend beyond email into stored data and persistent device access. |
Recover and follow up
Recovery should leave the identity usable, the business informed, and the evidence intact enough for later review.
Delete or disable only what the investigation identifies: malicious rules, forwarding, methods, consent, roles, devices, links, delegates, or applications.
Re-enable access, register trusted MFA, remove sending restrictions after Exchange permits it, and verify the user from a trusted device and channel.
Watch for repeated sign-ins, new rules, further mail, risk changes, and related users. Record actions, owners, time stamps, limitations, and follow-up controls.
Common questions
Record the initial facts, disable the affected account, revoke sign-in sessions, reset credentials using the correct cloud or hybrid process, and preserve the evidence needed to investigate persistence and scope. If payment or customer communications are involved, alert the appropriate business owners through a trusted channel.
No. A password reset does not automatically remove attacker-added authentication methods, app consent, mailbox rules, forwarding, delegated permissions, devices, sharing links, or every application-issued session. Review each persistence path before restoring normal access.
Yes. Session theft, adversary-in-the-middle phishing, malicious consent, helpdesk abuse, compromised devices, legacy paths, and attacker-added authentication methods can all matter. Review the sign-in method, device, application, token behavior, and registered methods instead of treating the presence of MFA as an all-clear.
Not always. Microsoft Entra can revoke refresh tokens and block new sign-ins, but applications can issue their own session tokens. Effective access loss depends on the token and the application’s authorization and synchronization behavior.
For the affected Microsoft 365 identity, the current ticket-based path can collect seven days of Entra sign-in logs, seven days of Microsoft 365 unified-audit records, and associated Exchange Online mailbox rules. It can attach those evidence workbooks to the incident ticket for technician review.
When enabled and allowed by the configured security-ticket policy, MSPControl can disable the Microsoft 365 user, revoke sign-in sessions, and reset the password. Independent test modes and evidence and model-confidence thresholds support staged operation. The technician still owns data validation, persistence removal, recovery, and customer decisions.
Continue the workflow
Use the product and documentation links that match the next action. Microsoft 365 permissions, licensing, tenant state, and deployment configuration can affect availability.
Self-hosted. Free license available. No credit card required.