Responding to a Microsoft 365 Security Incident: Step-by-Step

A Microsoft 365 security incident—whether a compromised admin account, data exfiltration, or ransomware attack—demands immediate, structured response. For MSPs and MSSPs, the difference between chaos and controlled incident response often determines whether you contain the breach in hours or lose critical data in days.

This guide provides a step-by-step incident response playbook for Microsoft 365 environments.

Phase 1: Detection and Initial Response (0-30 minutes)

Step 1: Declare an Incident

The moment you detect suspicious activity, declare an incident. Assign an incident commander who will coordinate response activities and communication.

Create an incident ticket documenting:

• Detection time: When was the activity first detected?
• Alert source: Microsoft Defender alert? User report? Audit log review?
• Initial indicators: Specific activity observed (unauthorized login, data export, permission changes)
• Affected systems: Which Exchange, SharePoint, Teams, or OneDrive workloads are involved?
• Initial severity: Critical (active data theft), High (compromised account), or Medium (suspicious activity)

Step 2: Preserve Forensic Evidence

Immediately preserve evidence before it’s lost:

1. Screenshot alerts and logs showing the suspicious activity
2. Document the timeline of detected indicators
3. Export audit logs relevant to the incident (see Step 6 below)
4. Do not modify any objects related to the incident yet

Modifying, deleting, or resetting accounts before forensics destroys evidence. Forensics comes before containment.

Step 3: Assess Impact Scope

Determine the scope of compromise:

• Single user account compromised? Isolated impact
• Admin account compromised? Potentially tenant-wide impact
• Service principal or app compromised? May have broad API permissions
• Mail forwarding rule deployed? Ongoing data exfiltration

Document the scope in your incident ticket.

Phase 2: Forensics and Investigation (30 minutes - 2 hours)

Step 4: Review Sign-in Logs

Navigate to the Microsoft Entra ID admin center -> Manage -> Sign-in logs and filter for the compromised user:

• Location: Where are sign-ins originating from? Suspicious geographies?
• IP Address: Use WHOIS/IP lookup tools to identify ISP (residential vs. datacenter)
• Device Info: What operating system and browser? Does it match expected devices?
• Success/Failure: Were there brute-force attempts (many failed logins)?
• Conditional Access: Did suspicious logins trigger MFA challenges?

Document:

• First suspicious sign-in timestamp
• Number of suspicious sign-ins
• Time gaps between sign-ins (suggests automated activity)
• Last legitimate sign-in timestamp

Step 5: Review Mailbox Activity

For compromised email accounts, review mailbox operations in the Exchange Admin Center:

1. Navigate to Recipients -> Mailboxes and select the affected mailbox
2. Click Edit -> More options -> Mailbox Delegation to check for unauthorized delegates
3. Review Mail flow -> Rules for suspicious forwarding rules created by the attacker
4. Check Sharing policies for unexpected external sharing

In the Microsoft Purview Compliance Portal, navigate to Audit -> Audit search and search for mailbox-specific operations:

• MailItemsAccessed: Email was read by the attacker
• Move: Messages moved to Deleted Items or other folders
• Create: New forwarding rules or delegates created
• New-InboxRule: Email rules created (common persistence mechanism)
• Remove-InboxRule: Suspicious rules deleted by attacker to hide activity

Export the audit log in CSV format for forensic analysis.

Step 6: Check for Persistence Mechanisms

Attackers often create backdoors to maintain access:

1. Hidden Rules: In Exchange, create a test email to yourself. Does it arrive? Attackers often hide certain emails from inbox view
2. OAuth Consents: Navigate to Microsoft Entra ID admin center -> Applications -> Consents and permissions -> Admin consents. Look for unexpected application consents (e.g., random “Document Editor” apps with full mailbox access)
3. Application Permissions: In Enterprise applications, review permissions granted to third-party apps, especially those with Mail.Read, Mail.ReadWrite, or Directory.Read.All permissions
4. Delegate Access: Check for hidden delegates (see Step 5 above)

Document all persistence mechanisms found.

Step 7: Search for Data Exfiltration

Attackers typically exfiltrate data before attempting persistence. Look for:

1. Large Downloads: In the Microsoft 365 Defender portal, navigate to Cloud apps -> Activity logs and filter for large file downloads
2. Unusual Share Access: Check SharePoint -> Site sharing reports for external sharing by the compromised user during the incident window
3. Forwarding Rules: Any email forwarding to external accounts? (See Step 5)
4. Teams Activity: Did the attacker access Teams channels or chats from the compromised account?

Document all data exfiltration indicators.

Phase 3: Containment (1-2 hours)

Step 8: Revoke Active Sessions

Immediately revoke all active sessions for the compromised account to force re-authentication:

1. Navigate to the Microsoft Entra ID admin center -> Users -> All users
2. Select the compromised user
3. Click Sign-out sessions to revoke all active sessions
4. The attacker loses access immediately

Step 9: Reset the Account Password

Reset the password for the compromised account. In the Microsoft Entra ID admin center:

1. Select the user and click Reset password
2. Assign a temporary password
3. Require password change on next sign-in
4. If MFA is not enabled, enable it now

For a Global Admin or highly sensitive account, consider deactivating the account entirely and creating a new admin account instead.

Step 10: Remove Unauthorized Access Grants

Delete any persistence mechanisms discovered in Phase 2:

1. Remove OAuth consents: In Admin consents, click on suspicious applications and revoke consent
2. Delete unauthorized rules: In Exchange Admin Center, delete any forwarding rules or inbox rules created during the incident window
3. Remove delegates: Remove any mailbox delegates added by the attacker
4. Revoke application permissions: Remove permissions granted to suspicious applications

Step 11: Force MFA Re-Registration

If the account used to be unprotected by MFA, force MFA re-registration:

1. Navigate to Microsoft Entra ID admin center -> Security -> Multifactor authentication
2. Select the user and click Require to re-register multifactor authentication
3. The next time the user logs in, they must re-register with MFA

Step 12: Isolate Infected Devices (if applicable)

If the compromise originated from a user device:

1. Use Microsoft Intune to isolate the device (navigate to Devices -> All devices and isolate)
2. Require antivirus scan and remediation before reconnection
3. Review device compliance policies to prevent re-infection

Phase 4: Eradication and Recovery (2-6 hours)

Step 13: Identify Additional Compromised Accounts

One compromised account often indicates a broader compromise. Search for:

1. Similar sign-in patterns: In Sign-in logs, look for other accounts with suspicious activity from the same IP address or location
2. Bulk rule creation: In Audit logs, search for multiple users having inbox rules created at the same time
3. OAuth spree: Did an attacker consent to multiple malicious apps? Search for all consents from the incident timestamp
4. Service principal abuse: Did a service principal create multiple new accounts or mailboxes?

Document and quarantine all additional compromised accounts.

Step 14: Investigate the Attack Vector

How did the attacker gain initial access?

• Phishing: Compromised user clicked malicious link in email
• Credential stuffing: Attacker used leaked username/password from another breach
• Unpatched vulnerability: Your on-premises server was exploited
• Insider threat: Malicious employee
• Supply chain: Compromise originated from connected SaaS app

Understanding the attack vector prevents re-compromise.

Step 15: Recover from Backup

If data was deleted or corrupted:

1. Restore mailboxes, SharePoint sites, or Teams channels from backup (see our backup article)
2. Perform point-in-time recovery to before the attack
3. Verify restored data completeness and integrity

Without backup, you cannot recover data lost more than 30 days ago.

Step 16: Strengthen Authentication

Post-incident, implement stronger authentication:

1. Passwordless authentication: Deploy Windows Hello for Business or FIDO2 security keys for high-risk accounts
2. Conditional Access policies: Require MFA for sensitive operations, block legacy authentication
3. Risk-based authentication: Enable Azure AD Identity Protection to detect anomalous sign-ins automatically

Phase 5: Post-Incident (6+ hours)

Step 17: Document the Incident

Create a comprehensive incident report including:

• Timeline: Minute-by-minute sequence of events from initial compromise to containment
• Scope: Which systems were affected and how many users were impacted
• Root cause: How did the attacker gain initial access?
• Actions taken: What containment and eradication steps were executed
• Recommendations: What changes will prevent future similar incidents?
• Lessons learned: What did your team learn from this incident?

Share the report with IT leadership, security teams, and (if required by law) external parties.

Step 18: Implement Preventive Controls

Based on the incident, implement controls to prevent recurrence:

• Phishing incident? Deploy advanced email threat protection and user training
• Weak password compromise? Implement passwordless authentication
• Privilege abuse? Enable Privileged Identity Management (PIM) for sensitive roles
• Data exfiltration? Implement Data Loss Prevention (DLP) policies

Step 19: Communicate with Affected Users

If user data was compromised, inform the affected users:

• What happened: Be clear about the scope of compromise
• What we did: Explain your response and containment actions
• What they should do: Password reset, credential monitoring, etc.
• Support resources: Provide contact info for questions

For regulatory incidents, follow legal/compliance guidance on breach notification.

Step 20: Tabletop Exercise

Schedule a post-incident tabletop exercise with your incident response team:

• Review the incident: Walk through your response
• Identify improvements: What went well? What could be better?
• Update runbooks: Refine your incident response procedures based on lessons learned
• Train the team: Ensure all team members understand updated procedures

Conclusion

Microsoft 365 security incidents are not a question of if, but when. Organizations with documented, practiced incident response procedures minimize blast radius and recover faster. The 20 steps in this guide provide a structured response framework for containment, forensics, and recovery.

For MSPs and MSSPs, incident readiness is a competitive differentiator. Organizations choose managed service providers who respond rapidly and effectively to incidents.

Is your incident response playbook up to date? Assess your Microsoft 365 incident readiness at https://365securityassessment.com.