# Lab 1 — Microsoft Defender incident triage, response and closure

**Provider:** RCW IT Training
**Series:** Microsoft Defender security labs (Lab 1 of 5)
**Level:** Advanced practitioner
**Estimated time:** 70–90 minutes
**Delivery:** Offline, browser-local console replica. No tenant, no API, no credentials, no network calls.
**Lab URL:** [Open the lab](./)

> This lab reproduces the *shape and wording* of the Microsoft Defender portal for teaching purposes. It is not Microsoft software, is not affiliated with or endorsed by Microsoft, and uses no Microsoft logo. Every identifier in it is synthetic.

## Contents
1. Learning objectives · 2. Scenario · 3. Simulated boundary · 4. Data, privacy and audit · 5. Marking · 6. Procedure · 7. Expected results · 8. Traps · 9. Evidence · 10. Troubleshooting · 11. Control alignment · 12. References

## Learning objectives

- triage a correlated incident from the queue to the attack story without losing the evidence chain;
- apply queue discipline (severity, status, detection source) before touching an item, and claim it;
- assert only the techniques the alerts actually evidence, and say what an absence of data does not prove;
- bound a blast-radius hunt in KQL rather than asserting it from the incident title;
- request containment in a form an approver can sign: scope, expiry, rollback, blast radius, change reference;
- classify and resolve so the metrics stay honest, including the false-positive and empty-reason rules;
- make the regulatory escalation call on facts and timelines, not on the loudest field label.

## Scenario

Simulated clock **2026-08-20T12:00Z**. In the incidents queue, **INC-2291 — “Suspicious PowerShell activity and mailbox rule creation on FIN-WKS-0421”** is nine days from its SLA. The correlated alerts were raised on 2026-08-19: a PowerShell download of an executable (High · Execution), startup-folder persistence (Medium · Persistence) and a mailbox rule forwarding mail externally (High · Collection, from the email workload). The underlying telemetry spans `FIN-WKS-0421` (`fin.manager`), `HR-WKS-0110` (`hr.assistant`) and `OPS-SRV-0102` (`svc_backup`), with the campaign mail (`Invoice 88213` from `n1ghtbloom@relay-secure.example`) as the entry point. Four other incidents sit in the queue, including **INC-2288**, an in-scope red-team exercise.

Your role: **Mira Solanki, SOC L2** — a simulated account in a simulated tenant.

## Simulated boundary

| Real behaviour modelled | Simplified for the lab |
| --- | --- |
| Left navigation, breadcrumbs, queue → incident page → summary pane | Filters change the rendered rows; there is no backend query |
| Correlated attack story, technique mapping, recommended actions | Recommendations are static text, not generated by a service |
| Manage incident: assignee, status, classification, resolution, tags, comment | Resolution is validated against your own selections, and the linked alerts resolve with it |
| Device isolation offered from inside the incident, action record with approval | No device is touched; the action and its approval are recorded locally |
| Alert tuning, false-positive determination, escalation and notification clocks | Decisions are graded on their reasoning and stated limits |
| Audit trail with identity redaction and export | Stored in `localStorage` in your browser only |

## Data, privacy and audit

State lives in one `localStorage` key (`rcw.defender-lab.defender-incident-triage`) plus the learner-name key; nothing is transmitted, and there are no cookies, analytics, web fonts or third-party requests. Every graded action is written to a local audit trail; **Redact identities** masks anything shaped like a mailbox unless it is obvious documentation data, and the export defaults to redacted. Synthetic data rules: RFC 2606/6761 reserved domains, RFC 4193 unique-local addresses, `contoso-rcw.example` as the tenant. Accessibility: skip link, single tab stop with roving focus in grids, `aria-live` on every form message, `aria-current` navigation, visible focus at 3:1, reduced-motion and forced-colours support, print view that expands the tabs.

## Marking

| # | Objective | Pts | Core check |
| --- | --- | --- | --- |
| 1 | Intake and priority | 10 | Priority from SLA clock and asset context, on-call and SLA stated |
| 2 | Queue filtering, selection and ownership | 15 | Severity High + Status New + detection source, exactly INC-2291, claimed and set In progress, 80-character justification |
| 3 | Attack story, techniques and pivot evidence | 20 | Exactly the five evidenced techniques, initial access as spearphishing, the inbox rule as the pivot, and "unknown" for the silence |
| 4 | Bounded KQL blast-radius hunt | 15 | A time-bounded query with the right grouping, and the same scope in words |
| 5 | Contained, approved response actions | 15 | Approvable scope, evidence before mutation, change reference and approver, no destructive action without them |
| 6 | Classification, remediation state and closure note | 15 | True positive, Multi-staged activity, false-positive reason left empty, a tag, five remediation items |
| 7 | Regulatory and contractual escalation decision | 10 | Notification decided on facts and clocks, with the duty owner named |

Total 100 points.

## Procedure

1. **Intake (10).** Home → read the briefing cards, set the priority call for INC-2291, on-call owner and the SLA clock you are working to.
2. **Queue (15).** Incidents view → apply the three filters, select the one incident, claim it, set status, and write the justification the handover will quote.
3. **Story (20).** Incident page → assert the techniques the alerts support, name the initial access and the pivot, and answer what missing beacons prove (nothing, until sensor health is checked).
4. **Hunt (15).** Advanced hunting → run a bounded query over the simulated tables to size the exposure. The validator executes your query with the same engine the sample rows came from, so an unbounded or mis-grouped query returns a different row count and fails.
5. **Respond (15).** Response actions → sequence isolation and evidence collection, and complete the authorisation record: approver, change reference, expiry, rollback.
6. **Resolve (15).** Closure → classification, threat type, remediation state, tags, and a note that says what remains open.
7. **Escalate (10).** Escalation → decide notification on what the data shows, name the duty owner, and state the clock that applies to this tenant.

## Expected results

- Queue: Severity `High`, Status `New`, detection source `Microsoft Defender for Endpoint`, selection **exactly INC-2291**, assignee `Mira Solanki`, status `In progress`.
- Story: **T1566, T1059, T1547, T1114, T1021** and nothing else. `T1070.004` (no deletion events) and `T1190` (the device is not internet-facing) are over-claims and are rejected.
- Initial access = phish link; pivot = the mailbox rule (it proves attacker control of the mailbox, not just a bad laptop); missing beacons = *unknown* until sensor health is verified.
- Closure: classification true positive, threat type **Multi-staged activity**, false-positive reason **left empty**, at least one tag, and five of the six remediation items — the sixth says "nothing else needed", which is false here.
- Escalation is graded on the reasoning and the named owner, not on a checkbox.

## Traps the lab records

1. Selecting INC-2288 alongside INC-2291 because it looks alarming — it is an authorised, in-scope exercise.
2. Asserting techniques the telemetry does not support because they are typical of the family.
3. Downgrading "no beacons" to "no beaconing" without checking sensor health.
4. A destructive action with no approver, change reference or expiry.
5. Closing as false positive to satisfy a metric, or filling the false-positive reason on a true positive.
6. Copying another lab's regulator: this tenant is an **essential entity under NIS2**, not a financial entity under DORA.

## Evidence pack

`Lab guide` view → **Export evidence pack** downloads JSON with the learner name, timestamp, per-objective results, every field you entered and the audit trail — machine-verifiable against the same checks the page applies. `Reset lab state` clears only this lab.

| Symptom | Cause and fix |
| --- | --- |
| "No rows returned" in the query pane | Your time window excluded the events, or you filtered a field the table does not have. Read the schema card above the editor. |
| Right row count, objective still open | The validator compares the grouping, not only the total. Add the missing `summarize … by` dimension. |
| Form submits with no message | A required control sits in a hidden tab panel; the message inside the form is authoritative. |
| Selections lost on refresh | Only completed objectives persist; re-submit after a reset. |

## Control alignment

Process: **NIST SP 800-61r3** (detection and analysis; containment, eradication and recovery; post-incident). Management system: **ISO/IEC 27001:2022 A.5.24–A.5.28**, with **A.8.15–A.8.16** for logging and monitoring. Adversary model: **MITRE ATT&CK Enterprise**. Programmatic good practice: **CIS Controls v8.1** (Incident Response Management, Email & Web Browser Protections, Network Monitoring, Malware Defences). Notification reasoning: **NIS2 Art. 23(4)** (24 h early warning, 72 h notification, final report within one month) and **GDPR Art. 33/34** on risk. DORA is deliberately *not* applied to this tenant.

This mapping is educational guidance. It is not a compliance certification, an audit opinion, production authorisation, or legal advice; your organisation determines the applicable laws, contracts, standards and evidence.

## References

Text-form documentation paths only — the lab is offline and fetches nothing:
`learn.microsoft.com/defender-xdr/investigate-incidents` · `learn.microsoft.com/defender-endpoint/respond-machine-alerts` · `learn.microsoft.com/defender-endpoint/investigate-alerts` · `learn.microsoft.com/defender-xdr/advanced-hunting-cross-domain-queries` · `learn.microsoft.com/defender-office-365/mdo-sec-ops-guide` · NIST SP 800-61 Rev. 3 · ISO/IEC 27001:2022 Annex A · MITRE ATT&CK Enterprise · CIS Controls v8.1