What This Playbook Covers
A compromised device can give an attacker a path into Microsoft 365, email, files, Teams, SharePoint, and business systems. However, a device alert does not always prove compromise by itself. This playbook explains how security teams can confirm the event, isolate the device, preserve evidence, investigate root cause, review related identity activity, and return the device to a trusted state.
The goal is not simply to remove malware or close an alert. Instead, the team must understand what happened, what the attacker may have accessed, whether the user account also shows risk, and what control gaps allowed the event to occur. As a result, the organization can reduce damage, support leadership decisions, and improve security after the response ends.
When This Playbook Is Used
Use this playbook when a device shows signs of malware, unauthorized access, risky behavior, or suspicious Microsoft 365 activity. Some alerts may turn out to be false positives. However, every meaningful device event should follow a clear review path so the team can confirm risk before taking disruptive action.
Endpoint Or Malware Alerts
Defender, EDR, antivirus, or another security tool may report malware, exploit activity, suspicious PowerShell use, credential theft behavior, or unexpected process activity. In many cases, these alerts provide the first sign that the device needs isolation or deeper review.
Unusual Device Behavior
A user may report popups, slow performance, unexpected MFA prompts, unknown apps, browser redirects, or strange network activity. Because user reports often arrive before formal alerts, responders should compare the report against device and identity data.
Suspected Account Or Data Exposure
A compromised device may also place the user account, mailbox, SharePoint files, OneDrive data, or Teams access at risk. As a result, the team should review both endpoint evidence and Microsoft 365 activity before closing the case.
Signs A Device May Be Compromised
Device compromise rarely appears through one signal alone. Therefore, the team should look for supporting evidence across endpoint alerts, user activity, identity risk, and Microsoft 365 logs.
Endpoint Warning Signs
Look for malware alerts, suspicious scripts, unusual startup items, unknown remote access tools, disabled security controls, abnormal outbound traffic, or unexpected administrator activity. These signs may show that an attacker has gained a foothold on the device.
Identity Warning Signs
Compare device activity with risky sign-ins, user risk events, MFA changes, impossible travel, password spray activity, and new authentication methods. For more background, review the Microsoft Entra User Risk and Sign-In Risk guide.
Data Access Warning Signs
Check for large file downloads, unusual SharePoint access, new OneDrive sharing links, mailbox rule changes, external forwarding, or unexpected permission changes. If these events appear after device compromise, the team should review possible data exposure.
Execution Steps
A strong device response follows a clear order. First, confirm the alert and scope. Next, stop the device from creating more risk. After that, preserve evidence and review identity activity. Finally, restore the device only after the team confirms that the threat no longer remains.
Confirm The Device Event
Start by validating the alert or user report. For example, review Defender alerts, device timeline data, user reports, process activity, network activity, and recent system changes. Then identify the device, signed-in user, business role, location, and first known time of concern.
Limit Further Risk
Isolate the device when the evidence suggests active compromise, malware execution, command-and-control traffic, credential theft, or lateral movement. In addition, notify the user and confirm whether business-critical work depends on that device before making permanent changes.
Preserve Key Evidence
Save the information responders need before cleanup begins. Useful evidence may include Defender alerts, device timeline data, running processes, suspicious files, IP addresses, user reports, screenshots, sign-in logs, and audit events.
Investigate Root Cause
Determine how the event started. For example, review whether the issue came from phishing, a malicious attachment, unsafe browsing activity, stolen credentials, unpatched software, remote access tools, or a risky sign-in from the same user account.
Fix The Device And Account
Remove malicious files, reset credentials, revoke active sessions, remove unsafe persistence, and correct weak settings. If the team cannot trust the device, reimage it before returning the device to production use.
Restore And Watch Closely
Return the device to service only after the team confirms that the threat has ended. After that, monitor the device, user account, sign-ins, mailbox activity, and file access for signs that the attacker still has access.
Microsoft 365 Investigation Checklist
A device investigation should not stop at the endpoint. Because users access Microsoft 365 from the device, responders should also review identity, email, files, and audit activity tied to the same user.
Identity Review
Review Entra sign-in logs, user risk, sign-in risk, MFA changes, authentication methods, session activity, and Conditional Access results. If the device compromise aligns with risky identity activity, the account may require containment.
Email And Collaboration Review
Check Exchange mailbox rules, forwarding settings, message trace, Teams activity, suspicious links, phishing reports, and unusual communication patterns. In many cases, attackers use a compromised device to access email or impersonate the user.
File And Sharing Review
Inspect SharePoint and OneDrive activity for large downloads, new external sharing links, sensitive file access, permission changes, and unexpected deletion events. As a result, the team can determine whether the incident may involve data exposure.
Questions Every Responder Should Ask
Device investigations become more useful when responders ask the same core questions each time. Therefore, every review should connect endpoint activity, identity activity, and business impact.
How Did The Event Start?
Determine whether the event began with phishing, malware, unsafe browsing, a malicious attachment, a stolen password, an exposed service, or unauthorized remote access. This helps the team fix the root cause rather than only remove the symptom.
Which Account Was Used?
Identify the user account tied to the device. Then review sign-ins, user risk, MFA activity, mailbox changes, and file access. If identity activity looks unsafe, responders should treat the device event as a possible account compromise.
What Did The Attacker Access?
Review local files, browser activity, email, Teams, SharePoint, OneDrive, admin portals, and business apps. In other words, confirm whether the event affected only the device or also exposed Microsoft 365 data.
Did The Threat Spread?
Check whether the device contacted other systems, accessed shared resources, used remote tools, attempted credential theft, or triggered alerts on other devices. If the threat spread, expand the scope immediately.
Can The Device Be Trusted?
Decide whether cleanup gives the team enough confidence or whether the device needs a full rebuild. However, do not return the device to production use until security controls, updates, and user access have been verified.
Which Controls Failed?
Identify whether the event exposed gaps in patching, endpoint protection, Conditional Access, MFA, user training, browser controls, local admin rights, or device management. As a result, the team can reduce repeat risk after recovery.
Common Device Compromise Red Flags
Certain findings deserve fast review because attackers often use them during endpoint compromise. Because of this, responders should document why each red flag did or did not require escalation.
Endpoint Red Flags
Pay close attention to malware alerts, suspicious scripts, new startup items, unknown remote access tools, disabled protection, unusual outbound traffic, and unexpected administrator activity.
Identity Red Flags
Watch for risky sign-ins, impossible travel, new MFA methods, repeated failed sign-ins, password spray activity, or account activity the user does not recognize. These signals may show that the device event also affected the account.
Data Red Flags
Look for large file downloads, unexpected SharePoint access, OneDrive sharing, mailbox forwarding, sensitive file access, or deletion events. If these findings appear, legal, compliance, or leadership review may be needed.
Containment And Recovery Decisions
Device response often requires quick decisions that affect users and business operations. Therefore, responders should use clear criteria when deciding whether to isolate, rebuild, restore, or keep a device under watch.
Isolate When Risk Remains Active
Isolate the device when malware still runs, suspicious traffic continues, the user cannot explain the activity, or security tools show signs of active compromise. This step helps stop further damage while the team investigates.
Rebuild When Trust Is Low
Rebuild the device when responders cannot confirm full cleanup, when attackers gained persistence, or when the device handled sensitive work. Instead of relying on partial cleanup, a rebuild gives the team a cleaner recovery path.
Restore After Validation
Restore access only after the device passes security checks, receives required updates, and no longer shows suspicious behavior. In addition, confirm that the user account, sessions, and Microsoft 365 access appear safe.
Operational Requirements
A device compromise playbook works best when security teams can act quickly and collect reliable evidence. Therefore, organizations should confirm these requirements before an incident occurs.
Endpoint Detection And Response
Use endpoint protection that helps teams detect malware, isolate devices, review timelines, and respond to attacker activity. Microsoft Defender for Endpoint can support these tasks when the environment has the right licensing and setup.
Central Log Access
Give responders access to device alerts, sign-in logs, audit logs, mailbox activity, and file access records. In addition, confirm that retention settings support the time needed for investigation and reporting.
Device Management Controls
Ensure the team can isolate, wipe, rebuild, retire, or reconfigure devices through approved management tools. If those actions require separate approvals, document the approval path before an incident begins.
Escalation Criteria
Not every device alert requires full incident response. However, certain findings should trigger escalation because they may indicate active compromise, data exposure, or broader Microsoft 365 risk.
Escalate Identity Risk
Escalate when the user does not recognize sign-ins, risky sign-ins appear after the device event, MFA settings changed unexpectedly, or attackers may still have active sessions.
Raise Data Exposure Concerns
Raise the issue when logs show large downloads, external sharing, mailbox forwarding, sensitive file access, or activity involving regulated or client data.
Expand The Investigation
Expand the scope when the device contacted other systems, used remote tools, created new admin activity, or triggered alerts on other endpoints. As a result, the team can avoid treating a broader event as a single-device issue.
Expected Outcome
After completing this playbook, the organization should understand what happened, which accounts or systems faced risk, what evidence supports the conclusion, and what controls need improvement.
- Security teams confirm the affected device, user, event timeline, and scope.
- Responders isolate or control the device before the threat creates more damage.
- Investigators review related Microsoft 365 identity, email, file, and audit activity.
- The team removes risk, restores trusted access, and documents each response action.
- Leaders receive a clear summary of findings, business impact, and required follow-up work.