Microsoft 365 / Investigate security alerts and respond to incidents
When you receive a Microsoft 365 security alert, do not immediately close it just by looking at the severity. You should check the occurrence time, detection source, affected users/devices/emails, and related alerts. Multiple alerts for the same incident can be grouped into a single incident, so review both individual alerts and the entire incident together.
Difference between alerts and incidents
An alert is a record of specific suspicious activity detected. An incident is a unit that combines related alerts and evidence to help understand the attack flow. Microsoft's Defender incident investigation guide explains to review alerts, activities, assets, and evidence together. Available screens and automated investigation features vary depending on your organization's products and licenses.
Prepare access and choose the investigation screen
Open Incidents & alerts → Alerts in the Microsoft Defender portal. Even if you can view them with security reader permissions, it does not mean you can perform response actions like account blocking or device isolation. First, check your organization's Defender permission model, the scope of responsibilities, and product licenses, and designate investigation and response personnel.
The incident-cases experience is in preview, and the legacy incident experience remains available. If your organization uses incident cases, open Cases → Incident, select the case, and review its alerts, assets, evidence and activities. Different navigation does not by itself mean logs are missing. Use Microsoft’s incident case investigation guide to match the instructions to your available screen and permissions. In the unified role-based access control (RBAC) model, Security Data Read permits viewing and investigation, while Security Data Manage also permits case management; specific response actions have their own permission and workload requirements.
Initial response checklist
- Open the incident or alert list in the Microsoft Defender portal. Designate responsible personnel within the team and record the incident number to avoid duplicate handling of the same case.
- Check the severity, detection time, and affected accounts, emails, and devices. Do not confirm an actual breach based solely on the alert title.
- In the incident details, review related alerts, chronological activity records, evidence, and the results of automated actions. Check the meaning of the status and classification in the alert investigation document.
- If there is a high likelihood of a real threat and damage is ongoing, immediately notify the responsible personnel according to the organization's incident response procedures, and determine the scope of impact and approved isolation/blocking measures. Preserve the evidence needed for investigation while containing the threat; do not unnecessarily delay urgent containment.
- Record the cause and actions taken, and check whether the same activity exists for other users or devices. Monitor to ensure alerts do not recur after measures have been taken.
Record evidence and build an investigation timeline
Record not only the alert name but also the alert/incident ID, detection product, initial and most recent activity times and time zones, and identifying information of the target user, device, or email. Check the actual entities to avoid confusing files with the same name or similar accounts. Do not open malicious URLs or attachments directly on everyday work PCs.
Chronologically link confirmed events such as 'mail received → link-related alert → login → access to data'. Do not assume that all events occurred; distinguish between existing evidence and unknown facts. For example, even if a user denies clicking, relevant logs should be checked, and a password leak should not be confirmed solely based on click records.
Investigate whether there are alerts affecting other users related to the same sender, file, or URL. This is because even if an alert affecting one account is closed, the same activity may continue on another account. Store materials in an approved incident management location and do not post the original email, user information, or access logs on public channels.
How to assess a phishing alert
| Confirmed situation | What to check or do first |
|---|---|
| Message is quarantined and not delivered to the user | Check the quarantine result and whether it was delivered to other recipients. Determine if it is a detected/blocked attack |
| Arrived in the inbox, but user action is unconfirmed | Investigate message identifier and delivery scope, and let security personnel determine the need for message removal or blocking |
| Confirmed that the user entered a password on the link | Prioritize response due to potential account compromise. Proceed with blocking access, checking sessions, and authentication methods according to approved procedures |
| Confirmed malicious execution or ongoing damage on the device | Immediately transfer to the person responsible for preventing ongoing damage and verify the completion status of approved isolation and actions. |
Actions across multiple services may be necessary. For email delivery, check message trace, and for login and authentication, proceed to Microsoft Entra sign-in logs. Only changing the user's password is not enough; the relevant personnel must define the investigation scope to ensure suspicious authentication methods, forwarding rules, and app permissions are not left intact.
Even when automatic actions appear, distinguish between requested, pending, failed, and completed statuses. Depending on the product, automatic investigation or response features may not be available, and just seeing a response button on the portal does not mean the task has been performed. Preserve evidence and execute urgent blocking simultaneously, without unnecessarily delaying the prevention of ongoing damage.
Can we ignore it immediately if it seems like a false positive?
No. Compare the evidence with the responsible person’s explanation to establish whether a policy change or normal operational task caused the alert. If you classify an alert as a false positive, record the supporting evidence and scope. Do not disable broad alert rules and risk missing real attacks. When the same false positive recurs, consider a narrowly scoped adjustment supported by the investigation.
Distinguish an alert that correctly detected and blocked a real threat from an alert that incorrectly identified normal activity as malicious. The absence of damage does not by itself make an alert a false positive. For an approved test or operational task, compare the work request, execution time, target and evidence, then record the appropriate classification and determination. In the alert view, True positive, Informational, expected activity and False positive represent different conclusions. If tuning or suppression is justified, limit the affected targets and set an expiration or review date.
Verify recovery before closing the incident
- Current status of affected accounts/devices and presence of additional alerts
- Automated/manual actions taken and any actions that need to be reversed
- Completion of user notifications and internal incident records
- Persons responsible for recurrence prevention tasks such as policies, training, and authentication methods
The incident closure record should include the initial symptoms, impact scope, supporting evidence, actual results of automated and manual actions, and remaining follow-up work. Changing an alert to Resolved does not itself remove a threat. Close the incident after verifying that affected accounts and devices are protected and business operations have recovered. Separately review any temporary blocks or policy changes; the responsible person should reverse only the measures justified by the evidence and approved scope.
