Objective. Students independently configure a SIEM environment, detect a multi-stage simulated attack using correlation rules and manual investigation, and produce a complete analyst report documenting the incident.
This lesson, its worked examples and its practice questions has not yet been verified by an industry-certified professional or by a certification or approval body. It is a study draft and may contain errors. Do not use it as instructions for work on a job site or on live equipment. Always follow your instructor, your supervising professional, and current official references and regulations.
VoTechWorks program approval and accreditation are still in progress. Credentials are issued only by the certifying bodies named in each program, after their own exams.
This lab is the culminating assessment for the SIEM course. You will work alone to set up a live SIEM environment, detect a hidden multi-stage attack, and deliver a professional analyst report. Every skill you have practiced — log ingestion, correlation rules, search queries, timeline reconstruction, and ATT&CK mapping — comes together here.
The capstone has three timed phases. First, you configure the environment: connect log sources, verify data is flowing, and activate your correlation rules. Second, the instructor silently loads a pre-built attack dataset into your SIEM. You do not know which attack stages are present — you must find them. Third, you write a structured report and deliver a five-minute verbal debrief.
This mirrors real-world incident response. Analysts rarely receive a complete picture at the start. You must gather evidence, form hypotheses, and revise them as new data appears.
Deploy four log source types to your clean SIEM instance: Windows event logs, Linux authentication logs, firewall logs, and web server logs. After connecting each source, run a simple search to confirm events are arriving — for example, query for any event in the last five minutes and verify the count is nonzero. Activate at least three correlation rules you built earlier in the course. Common choices include failed-login threshold rules, port-scan detection rules, and rules that alert when a new account is used to access multiple hosts in a short window.
Document each log source and rule in your triage template before moving to Phase 2. If a log source is not ingesting, troubleshoot it immediately; missing data is a gap an attacker exploits, and it is a gap that will cost you points on the rubric.
The injected dataset represents a complete kill-chain with five stages.
Stage 1 — Reconnaissance scan. An external IP conducts a port scan against the network perimeter. Look for firewall logs showing a single source IP generating connection attempts across many destination ports in a compressed time window. Map this to ATT&CK technique T1595 (Active Scanning) or T1046 (Network Service Discovery) depending on evidence.
Stage 2 — Credential brute-force. The attacker targets a login service. Windows Security Event ID 4625 (failed logon) or Linux `/var/log/auth.log` entries showing repeated authentication failures from one source IP are your indicators. A correlation rule that fires after a threshold of failures in a rolling window should alert here.
Stage 3 — Successful login. Following the brute-force, a logon succeeds. Event ID 4624 on Windows or an `Accepted password` line in Linux auth logs, from the same source IP and around the same timestamp, confirms the breach. Note the account name — it becomes a pivot for the next stages.
Stage 4 — Lateral movement. The compromised account is used to access additional hosts. Look for Event ID 4648 (explicit credential logon) or SMB/RDP connections from the beachhead host to internal targets. ATT&CK technique T1021 (Remote Services) covers common lateral movement methods.
Stage 5 — Data staging. Large outbound transfers or archive-creation activity (e.g., `7z`, `zip` commands in process logs, or large POST requests in web logs) indicate the attacker is preparing to exfiltrate data. ATT&CK technique T1074 (Data Staged) applies here.
For each stage, record the exact SIEM query you used, the raw event that confirmed it, the timestamp, and the affected asset. Use ATT&CK Navigator to verify technique IDs before writing them into your report.
Your report must include six sections:
1. Executive summary — two to four sentences describing what happened, written for a non-technical manager.
2. Timeline of events — chronological list of each stage with UTC timestamps.
3. Affected assets — hostnames, IP addresses, and accounts involved.
4. Evidence citations — paste or screenshot the SIEM query and result that proves each stage.
5. ATT&CK technique IDs — one or more per stage, with the technique name spelled out.
6. Containment and remediation recommendations — specific, actionable steps such as isolating a host, resetting a credential, or blocking an IP at the firewall.
Vague recommendations such as "improve security" do not meet the rubric standard. Write steps a junior analyst or sysadmin can execute immediately.
Even in a lab environment, treat the simulated attack data with the same discipline you would apply to real incident data. Do not share findings with classmates during the assessment — this is an individual exercise. Protect any credentials or IP addresses in the dataset as if they were live production data. In workplace settings, incident data is often subject to legal hold and must be handled under your organization's evidence-preservation policy. Accurate, timestamped documentation is not optional; it is required if the incident ever goes to litigation or regulatory review.
You pass the capstone by identifying at least four of the five attack stages, supporting each identified stage with at least one cited SIEM query, using correct ATT&CK IDs, providing actionable recommendations, and submitting the report on time. A late report that would otherwise pass does not earn a passing grade — deadlines in incident response are real.
Answer each question, then check it. Nothing is recorded; this is your own practice.
A free tech program — complimentary, as our commitment to get America working. Help us build VoTechWorks. Tell us what works, what doesn’t, and what you want to learn.