Microsoft Defender for Endpoint alert triage: a first-hour runbook for Australian IT teams

Deploying endpoint detection and response is the easy half. The hard half is the Tuesday afternoon a high-severity alert lands and three people are looking at the same screen with different ideas about what to press. This is the runbook for that hour.

It assumes Microsoft Defender for Endpoint is deployed and someone holds the console. It is deliberately narrow: what to do between the alert arriving and the point at which you either close it or escalate it into a full incident response. The broader response plan — legal, insurer, communications, the notification decision — sits outside this and needs to exist separately.

Minutes 0 to 5 — the five questions to answer before touching anything

The instinct is to isolate immediately. Sometimes that is right. But five minutes establishing what you are looking at prevents both of the common failures: containing nothing while the attacker moves, and containing a finance director's laptop over a false positive at end of month.

1. 1What is the severity, and what did Defender actually detect? Read the alert title and the detection source rather than the colour of the badge. A high-severity alert from an attack surface reduction rule and a high-severity alert for credential theft from LSASS require different urgency.
2. 2Is this one alert or part of an incident? The Defender portal correlates related alerts into a single incident across endpoints, email, identity and cloud apps. If there is an incident, the incident is the unit of work and the individual alert is a symptom.
3. 3Which device, and whose? A server, a domain controller, a shared kiosk and a graduate's laptop are four different risk levels for identical detections.
4. 4Which account was involved, and is it privileged? A detection on a device where a privileged account was signed in is a materially worse event than the same detection under a standard user.
5. 5Has automated investigation already acted? Check the action centre. If automated remediation has quarantined the file and the verdict is malicious, you may be triaging something already contained, and knowing that changes what you do next.

The triage sequence, in order

Nine steps. Work them in sequence rather than jumping to the interesting one, because the order is what keeps the evidence intact.

1. 1Open the incident rather than the alert, and read the attack story. It gives you the process tree, the timeline and the related entities in one view. Most triage decisions are visible here without any further tooling.
2. 2Identify the initial access point. Was it an email attachment, a download, a removable device, a remote session, or a process on a server with no user? That answer determines whether this is one device or the first device.
3. 3Check the device timeline for what happened either side of the detection. The events before it tell you how the payload arrived; the events after tell you whether anything succeeded.
4. 4Check the account. Look at the sign-ins for the user involved, and whether the same account authenticated anywhere unusual in the same window. Endpoint alerts with an identity dimension are the ones that turn into tenant-wide problems.
5. 5Decide containment now, using the ranked list below. Do not wait until the investigation is complete: containment and investigation run in parallel, and the whole point of endpoint detection and response is that you can do both.
6. 6Collect the investigation package from the device before doing anything destructive to it. It gathers the forensic artefacts Defender can retrieve and takes one click. It is also the thing everybody forgets and nobody can recreate afterwards.
7. 7Hunt for the same indicators across the estate. Take the file hash, the IP address, the domain and the parent process, and query the rest of the fleet through advanced hunting. One infected device is a ticket. The same indicator on six devices is an incident with a different escalation path.
8. 8Block the indicators where the finding is genuine. Custom indicators let you block a hash, an IP address, a URL or a domain across onboarded devices, which stops the next twenty attempts while you deal with this one.
9. 9Escalate or close, deliberately, and record which one you did and why. An alert that is neither escalated nor closed is the most common state in an unmanaged console, and it is indistinguishable from nobody having looked.

Containment actions, ranked by how reversible they are

Reach for the least disruptive action that actually contains the threat, and understand what each one costs the person using the device. Ranked from most reversible to least.

1. 1Run an antivirus scan on the device. Non-disruptive, cheap, and useful for confirming whether anything else is present. It contains nothing on its own but it costs nothing to start while you keep working.
2. 2Stop and quarantine the file across the organisation. Targeted at the artefact rather than the machine. Reversible, and it prevents the same file executing on any other onboarded device.
3. 3Add custom indicators to block the hash, IP address, URL or domain. Broad protection, easily removed later, and the fastest way to stop a campaign that is hitting multiple users.
4. 4Restrict application execution, so only Microsoft-signed applications can run on the device. Disruptive to the user but leaves the machine online and reachable, which keeps the investigation going. Often the right middle setting for a device you suspect but have not confirmed.
5. 5Isolate the device selectively, which cuts network access while leaving specified collaboration applications working. Useful when the user needs to stay contactable and the device needs to stop talking to everything else.
6. 6Isolate the device fully. It disconnects from the network while retaining connectivity to the Defender service so you can keep investigating and can release it remotely. This is the correct action for confirmed compromise, hands-on-keyboard activity, or anything with ransomware characteristics. Tell the user; a laptop that silently loses the network produces a service desk ticket that wastes the next twenty minutes.

The six alerts never to auto-resolve

Plenty of alerts are genuinely benign and closing them quickly is correct. These six deserve a human conclusion every time, regardless of how busy the queue is, because each one is a marker for an attacker who is already past the perimeter.

1. 1Credential theft from LSASS, or any credential access detection. No legitimate business process reads credential memory. Treat every instance as real until proven otherwise, and assume the credentials on that device are compromised.
2. 2Suspicious PowerShell or obfuscated script execution on a server. On a workstation this is sometimes an administrator being clever. On a server it is rarely anything good.
3. 3Anything involving PsExec, WMI remote execution or remote service creation between workstations. Lateral movement looks exactly like systems administration, which is precisely why it works.
4. 4Shadow copy deletion, backup catalogue tampering or boot configuration changes. These are ransomware pre-staging and they are frequently the last quiet moment before encryption.
5. 5A detection on a domain controller, certificate authority or backup server. The device class alone justifies full investigation regardless of severity rating.
6. 6Persistence mechanisms — scheduled tasks, run keys, WMI event subscriptions, new services — created outside a change window. Persistence is the step attackers take once they have decided to stay.

What to preserve while you are containing

This is the part Australian organisations most often regret skipping, and it costs about three minutes during the incident.

Under the Notifiable Data Breaches scheme, where an entity suspects an eligible data breach it must carry out a reasonable and expeditious assessment, and take all reasonable steps to complete it within 30 days. The quality of the endpoint evidence is what decides whether the answer to "what did they reach?" is specific or unknowable. An organisation that can show an attacker was contained on one workstation eleven minutes after execution notifies differently to one that cannot rule anything out.

• Collect the investigation package from every affected device before rebuilding or reimaging anything. Rebuilding destroys the answer to the question you will be asked in a fortnight.
• Export the incident timeline and the alert detail while it is current, and store it outside the tenant that is under investigation.
• Record the human timeline separately: when the alert fired, when a person saw it, when containment happened, who authorised it. Times and names, written as they happen rather than reconstructed later.
• Capture the affected accounts and what data those accounts could reach. That mapping, not the malware analysis, is what determines the scope of a notification.
• Note whether the incident is reportable to ASD's Australian Cyber Security Centre through ReportCyber, and separately whether any regulatory or contractual reporting obligation applies. These are different questions with different clocks and the notification decision belongs to the response plan, not to the person triaging.

Closing the alert honestly

When you resolve an alert or an incident, classify it properly: a true positive, expected activity that was informational, or a false positive, with the determination that fits. This is not administrative hygiene. The classification feeds Microsoft's tuning, it is what your future self reads when a similar alert appears, and it is the record that shows a decision was made by a person.

Write one line of commentary in the incident describing what you concluded and why. In six months, when the same detection fires on a different device, that line is worth more than the entire alert payload.

The weekly discipline that makes the first hour shorter

1. 1Review the action centre for what automated investigation did without asking. Automation you never audit is automation you cannot defend to anyone.
2. 2Clear the queue to zero once a week. An unresolved alert older than seven days is either a decision nobody made or a detection nobody understood.
3. 3Re-check device onboarding coverage against the actual device count. Triage quality is capped by the number of devices reporting.
4. 4Review the exclusions and the custom indicators added during the previous week's incidents. Temporary exclusions become permanent silently.
5. 5Rehearse one containment action per quarter on a test device — isolation, release, live response — so the permissions and the muscle memory are current.