Lab Walkthrough 1 – Failed Logons Followed by Success
08:11:01 EventID=4625 user=jsmith src_ip=203.0.113.44
08:11:04 EventID=4625 user=jsmith src_ip=203.0.113.44
08:11:06 EventID=4625 user=jsmith src_ip=203.0.113.44
08:11:09 EventID=4625 user=jsmith src_ip=203.0.113.44
08:11:12 EventID=4625 user=jsmith src_ip=203.0.113.44
08:11:21 EventID=4624 user=jsmith src_ip=203.0.113.44 logon_type=10🔮 Predict first
What happened? Which account and IP were involved? How many failures, and did authentication eventually succeed? What does Logon Type 10 indicate? Would you escalate, and what additional logs would you request?
Reveal the expected direction
Five failures against jsmith from 203.0.113.44, followed by a success — Logon Type 10 is RemoteInteractive, commonly RDP, so this pattern could represent password guessing followed by successful Remote Desktop authentication. Next, pull EDR events, VPN records, asset ownership, the user's normal working location, and any threat intelligence on that IP, then check what authentication activity followed. This is exactly Lab 1 in the downloadable pack below, with the full raw log file to work through yourself.
Lab Walkthrough 2 – Suspicious PowerShell
Timestamp: 2026-08-30T10:14:32Z
Host: LON-LT-0442
User: CORP\jdoe
ParentImage: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine: powershell.exe -WindowStyle Hidden -EncodedCommand <redacted>🔮 Predict first
Name at least three individually interesting indicators in this one log line. Then decide: is this "malware confirmed," or does it need more investigation first — and if so, what would you check next?
Reveal the expected direction
Microsoft Word spawning PowerShell, a hidden window, and an encoded command are all individually suspicious (Lesson 2's behaviour-based detection in action) — but the correct next step is never "malware confirmed," it's investigation. Was a document actually opened? Where did it come from — an email? What does the encoded command actually do once decoded? Did PowerShell reach out to the internet? Were files created, or another process started? This maps to Lab 3 in the pack, which supplies the fuller process-tree telemetry to answer exactly those questions.
1 Writing a Real Escalation
An analyst should never escalate with only "suspicious login detected." A useful escalation reads more like:
High-confidence account compromise suspected.
User: jsmith
Initial activity: 27 failed Microsoft 365 authentication attempts from
203.0.113.18 between 09:14 and 09:18 UTC.
Successful authentication: 09:19 UTC from same address.
Subsequent activity: Mailbox forwarding rule created at 09:23 UTC.
User normally authenticates from UK corporate addresses. No approved travel identified.
Recommended actions: Revoke active sessions. Disable account pending validation.
Reset authentication credentials. Review MFA methods. Review mailbox activity.Notice the shape: what happened, with exact timestamps and sources; why it's suspicious, with the baseline it deviates from; and specific, actionable recommendations — not just a severity label. Good security operations depends heavily on communication, not just correct technical analysis that never gets acted on.
2 Evidence Preservation
Analysts should avoid destroying evidence unnecessarily — immediately reimaging a compromised laptop, for instance, can remove information Incident Response still needs. Depending on your organisation's procedure, the right move may instead be isolating the device, preserving logs, collecting memory, collecting forensic artefacts, recording timestamps, and safely preserving malicious files rather than deleting them outright. Always follow your organisation's actual incident response procedure rather than improvising in the moment.
3 UTC & Time Synchronisation
Time is critical during investigations. Global organisations correlate events in UTC — a London log at 10:00 BST, a New York log at 05:00 EDT, and a SIEM timestamp of 09:00 UTC can all represent the exact same moment. Systems need reliable time sync (NTP) to make this work; a drifted clock can make an incident timeline genuinely impossible to reconstruct accurately, which is also why Module 9's Kerberos lesson flagged time sync as a Kerberos-breaking issue — the same underlying fragility shows up here from the investigation side.
4 Log Retention & Cost
Companies can't store every event forever — security logs consume enormous storage, so organisations decide what to collect, how long to keep it, whether to keep raw data, when to archive, and what needs to stay immediately searchable. A common tiering: hot searchable data for 30 days, warm data for 90 days, archive for a year or more — the exact policy depends on security requirements, industry regulation, legal requirements, cost, privacy, and investigation needs.
Cost matters more than it sounds like it should. If DNS logging alone generates 4 billion events a day, routing everything into an expensive SIEM can become enormously costly very quickly. Security architects have to decide what genuinely needs real-time analysis, what can sit in cheaper storage, and what can be filtered before it's even collected — a real, recurring architectural trade-off in large SOC environments, not a one-time decision.
The Full 12-Lab Investigation Pack
The two walkthroughs above are Labs 1 and 3 from the full pack — here's the complete set, in increasing difficulty:
Every lab ships with raw .log/.json/.csv telemetry, a reusable SOC Investigation Worksheet, a KQL/SPL practice cheat sheet, and MITRE ATT&CK mapping exercises. Work through Labs 1–3 closely (they're guided), 4–7 with the hints provided, and 8–11 independently — then use Lab 12 as your capstone. Answer the questions yourself before checking the instructor pack's answer key.
⬇️ Download the Student Lab Pack (.zip)
⬇️ Download the Instructor Lab Pack (.zip, includes answer key)
Lesson Outcome
You should now be able to work through a failed-logon and a suspicious-PowerShell investigation using the eight-step method from Lesson 3, write an escalation that a Tier 2 analyst could act on immediately, explain why evidence preservation matters before containment, explain why UTC and time sync matter for timelines, and describe the retention/cost trade-offs behind real SOC log architecture. From here, work through the 12-lab pack at your own pace. Lesson 6 closes the module with SOAR, AI in the SOC, metrics, threat hunting, and where this all leads next.