01 Log Sources & Ingestion Foundation What flows into a SIEM — and why each source matters to an analyst
A SIEM ingests logs from across your environment. Click each source to explore its events from Ficsit Inc. — and understand what analysts look for in each one.
Key Concept
Log normalization is the process of converting logs from different vendors and formats into a consistent schema. Without it, you'd need a different query for every data source.
AUTH Authentication
Windows Event Logs, Active Directory — logons, failures, privilege use
userlogon_typeresultsrc_ipevent_id
DNS DNS Queries
DNS server logs — every domain resolution the network makes
queryanswerttlqtypethreat_intel
ENDPOINT Endpoint / EDR
Process starts, file writes, network connections, registry changes
processparentcmdlinehashsigned
FIREWALL Network / Firewall
FICSIT-FW-EDGE-01 — allowed/blocked connections at the perimeter
src_ipdst_ipdst_portrulebytes
Email Gateway
Inbound/outbound email — sender, attachments, SPF/DKIM, verdicts
fromsubjectattachmentspfverdict
← Select a log source
Click a source card to view its events from Ficsit Inc.
Log Sources — Instructor Notes
Start by asking the class: "If you had to pick one log source to detect a compromised account, which would you choose?" Walk through each source clicking on it. Emphasize that no single source tells the full story — detections become powerful when you correlate across sources. The email source in this dataset shows how the attack started: a phishing email with a macro attachment opened by FICSIT\\pioneer.
Class Exercise
Discussion: Looking at the endpoint and DNS logs, what's the sequence of events? Can you put them in order without seeing a timeline? Expected order: Email opened → macro → PowerShell → DNS query to pioneer-updates.svc.net → network connection to 185.220.101.47:4444.
02 Writing SIEM Queries Foyl SIEM · Log Search Query the Ficsit Inc. event log — hit Enter or Run to execute
All 29 events · Ficsit Inc. Pioneer Division · Last 4 hours
SEVTIMESTAMPSOURCEHOSTTYPEMESSAGE
Event Detail
Query Syntax Reference
src:authFilter by source type (auth, dns, endpoint, firewall, email)
sev:criticalFilter by severity (critical, high, medium, info)
host:WS-01Match hostname (partial match supported)
type:logonFilter by event type
powershellFree text search across all fields
Tip: Combine terms with spaces (implicit AND). Use the preset buttons above to start with common analyst workflows.
SIEM Queries — Instructor Notes
Start with the "Critical / High" preset to show the full picture. Then click "PowerShell" — ask the class what they notice about the parent process (outlook.exe spawning powershell is always suspicious). Walk through the "C2 Indicators" filter to show everything touching 185.220.101.47. Emphasize the committed query pattern — analysts write a full query before running it, not character by character.
Class Exercise — Try These Queries
1. Find all events on RESEARCH-STATION-01 → type: host:RESEARCH-STATION-01
2. Find failed authentications → type: src:auth type:logon_failed
3. Find the email that started the attack → type: src:email
03 Alert Triage Workflow Foyl SIEM · Alert Queue Work the queue — Escalate, Acknowledge, or Suppress each alert
Triage Decision Guide
CRITImmediate escalation. Open investigation. Do not wait for more data.
HIGHEscalate if corroborated by ≥2 sources. Investigate within the hour.
MEDInvestigate during shift. May be tuned away if low confidence.
LOWAcknowledge or suppress if known noise. Log the reason.
Alert fatigue is the #1 reason SOC analysts miss real incidents. High-volume, low-fidelity alerts train analysts to ignore the queue. Good triage hygiene — suppressing known noise with documented reasons — is what separates mature SOC programs.
Class Exercise
Work through the queue. For each alert decide: Escalate (open investigation), Acknowledge (noted, watch), or Suppress (known noise). Compare with the person next to you — did you agree?
Alert Triage — Instructor Notes
Open ALT-0885 first (email macro execution) — this is the root cause. Then open ALT-0892 (C2 attempt) — these two together form the attack chain. Ask: "Which alert would you have seen first if you were working the queue in real time?" Point out that the email alert (08:22) precedes the C2 alert (10:14) by nearly 2 hours. That's the detection gap. Use the confidence ratings to discuss why some high-severity alerts are medium confidence.
Discussion Point
ALT-0887 (Port Scan) is medium confidence. Question: Is PIONEER-LAPTOP-03 running a legitimate scan or is it compromised? What additional context would you need? Hint: check who's logged in (j.tech), what their role is, and whether a scan was authorized.
04 Detection Engineering Rule Anatomy · Live Testing Understand an existing detection, then tune it — test against the Ficsit log dataset
Key Concept
A detection rule defines what to fire on, not just what to look for. It has a condition, a threshold, a time window, a severity, and a MITRE mapping. Tuning rules is an ongoing process — not a one-time setup.
HIGH PowerShell with Encoded Command ● Active
Log Source
source = "endpoint" AND event_type = "process_start"
Condition — edit to tune
Parent Process Filter (optional)
Threshold
Fire when ≥ occurrence(s) within minutes
Severity
MITRE ATT&CK
T1059.001 — Command and Scripting Interpreter: PowerShell
Analyst Tip
The parent process filter is what separates a high-fidelity rule from a noisy one. PowerShell spawned by explorer.exe is common. PowerShell spawned by outlook.exe is almost always malicious.
Class Exercise
Challenge 1: Remove the parent process filter — how many more events fire? Is that acceptable?
Challenge 2: Change the condition to also catch cmd.exe launching scripts. What do you add?
Challenge 3: What threshold would you set to suppress a known backup script that runs PowerShell every 5 minutes?
Why -enc matters
The -enc / -EncodedCommand flag tells PowerShell to accept a Base64-encoded payload. Attackers use this to obfuscate malicious commands from text-based detections. In this dataset, the encoded command decoded to a stager that downloaded svc32.exe and established persistence via a registry run key.
Matching Events
—
Click "Test Rule" to see matching events
Detection Engineering — Instructor Notes
Click "Test Rule" with the default settings — it should match 1 event (EVT-3002, PowerShell from Outlook). Then demonstrate: remove the parent process filter — show how the match count doesn't change in this dataset but would in production. Ask: "If this environment has 500 endpoints and 20 legitimate PowerShell scripts, how many false positives would a day look like without the parent filter?"
Wrap-Up Discussion
Every detection in the Foyl SIEM started as a hypothesis: "What would this attack look like in logs?" Detection engineers work backwards from TTPs (Tactics, Techniques, Procedures) using MITRE ATT&CK. The best detections are behavioural, not signature-based — they catch novel malware that no AV has seen before.
05 Hypothesis-Based Threat Hunting Active Defense Start with a TTP hypothesis — build a query — find the evidence
Key Concept
Threat hunting is proactive — you write hypotheses based on known attacker TTPs and go looking for evidence, rather than waiting for an alert to fire.
Hunt Hypotheses — click to run
Class Exercise
Instructor demo: Click each hypothesis. Ask the class: "Is this finding expected or unexpected in this environment?" After all 5, ask: "Which hypothesis gives you the most urgent lead?"
← Select a hypothesis
🔎
Click a hypothesis to run it against the Ficsit log dataset
Hypothesis Hunting — Instructor Notes
Walk through all 5 hypotheses in order — this recreates the thought process an analyst would use even without a prior alert. Key teaching moment: Hypothesis 1 (Office→PowerShell) and Hypothesis 3 (Execution from %TEMP%) together tell the complete execution story before the C2 alert ever fired. This shows students that good hunts find incidents that alerts miss.
Discussion
If the C2 firewall rule had not fired (i.e., the port 4444 block didn't trigger an alert), which hypothesis would have caught this incident? How many hours earlier?
06 IOC Pivoting & Enrichment Threat Intelligence Start from one known bad indicator and expand the picture
Investigation trail
Pivot to related indicator
Events matching indicator
IOC Pivoting — Instructor Notes
Start at the IP 185.220.101.47. Show the threat intel panel — discuss what "bulletproof VPS" means and why attackers use them. Then pivot to the domain — note the 13-day registration age. Pivot to PIONEER-WS-01 — this shows the full scope of activity on the compromised host. Finally pivot to the hash f7a3bc91 — discuss why 31/72 AV detection is significant (custom compilation to evade signatures).
Discussion Point
Question: After pivoting through all indicators, which one gives you the best starting point for containment? The IP? The domain? The endpoint? The hash? Expected answer: The endpoint (PIONEER-WS-01) because that's where you can take direct action — isolate, image, remediate.
07 Attack Timeline Reconstruction Forensic Analysis The full Ficsit incident in chronological order — click any event to expand
Initial Access
Execution
Persistence
Credential Access
Lateral Movement
C2 / Exfil
Reconnaissance
⏱ Dwell: 2h 8m initial access → C2 detection
Attack Timeline — Instructor Notes
Scroll through the timeline from top to bottom — this is how a DFIR analyst reconstructs an incident. Key points: note the 102-minute gap between email execution (08:22) and PowerShell execution (10:04) — what was the attacker waiting for? The persistence was set up within 30 seconds of initial C2 (10:04→10:05) — attackers move fast once they have execution. The credential dump on RESEARCH-STATION-01 came just 5 minutes after lateral movement.
Class Exercise
Without looking at the timestamps: what's the minimum number of alerting events needed to detect this attack? Which single event would you most want to fire an alert on, and why? Hint: the email alert fired 8 min after delivery — but the PowerShell alert fired 2h later. What does that tell you about your detection coverage?
08 Evidence Collection & Preservation DFIR Check off evidence in order of priority — volatile evidence first
Critical — Collect in This Order
Volatile evidence (RAM, active connections) disappears the moment you reboot or remediate. Always image memory before touching the disk. Evidence collected in the wrong order is inadmissible in legal proceedings and useless for forensic analysis.
Evidence Log
Check items off to log them
0 / 10 items collected
Evidence Collection — Instructor Notes
Walk through the checklist from top to bottom — the priority ordering is intentional. Emphasize that memory images must happen before any remediation action. Discuss chain of custody: every piece of evidence needs a hash (MD5/SHA256), a timestamp, and the name of who collected it. In regulated industries (finance, healthcare), evidence handling mistakes can make a breach response worthless in court.
Discussion Point
Question: You're on the phone with a nervous manager who wants to just "wipe and re-image" the compromised laptop immediately. What do you tell them? Expected: Wiping before evidence collection destroys your ability to understand the full scope of the breach and any legal/regulatory obligations.
09 Root Cause Analysis 5 Whys Framework Work backwards from the symptom to find the root cause — click to reveal each step
Tracing back from symptom → root cause
5 Whys Framework
The 5 Whys is a root cause analysis method: for each symptom, ask "why did this happen?" until you reach a cause you can actually fix.

Important: Root cause ≠ the attacker. The attacker exploited a gap — the root cause is what gap existed that allowed it.

In this incident:
• Why could the user open quarantined email?
• Why was macro execution not blocked by policy?
• Why did PowerShell have outbound access?
• Why was port 4444 not blocked outbound?

Each "why" is a security control failure that needs to be closed.
After the Chain is Revealed
List 3 security controls that, if properly implemented, would have stopped this attack at different stages. Example: email sandbox detonation, PowerShell constrained language mode, egress filtering on non-standard ports.
Root Cause Analysis — Instructor Notes
Click "Trace Back" once to reveal the C2 stage. Ask the class what they think caused it before revealing the next step. Build the suspense — each reveal should prompt a discussion. The root cause is the phishing email bypassing enforcement, but the deeper root cause is that users could access their quarantine folder and override verdicts. The technical controls (SPF enforcement, attachment sandboxing) are the actual fixes.
Key Insight to Communicate
Root cause analysis is about systemic fixes, not blame. The user made a mistake, but blaming them doesn't prevent the next attack. Enforcing SPF rejection and disabling user quarantine access does.
10 Incident Reporting Communication Draft the report — toggle between Technical and Executive views
Report Fields — edit and preview updates live
Incident Severity
Classification
Affected Systems
Affected User(s)
Initial Access Vector
Business Impact
Immediate Recommendations
Incident Reporting — Instructor Notes
Toggle between Technical and Executive views to show the same information at different levels of abstraction. Executives care about business impact and what decisions need to be made — not event IDs. SOC analysts need the technical details for remediation. A good incident report serves both audiences. Ask: "What would you say to the CISO in 30 seconds if they called right now?"
Class Exercise
Edit the "Business Impact" field to include a worst-case data exposure estimate. What data might the attacker have accessed if the LSASS dump was exfiltrated? All domain credentials, potentially all data accessible by the 'pioneer' account.
11 Correlation Rules & Enrichment SIEM Engineering How the SIEM combines events from multiple sources into a single high-confidence alert
Key Concept
A single event (PowerShell executing) might be normal. The same event correlated with an email opening + an outbound C2 connection on the same host within 2 hours is an incident. Correlation is what separates a SIEM from a log aggregator.
Three source events — individually ambiguous
correlates on: host = "PIONEER-WS-01" + time_window = 4h →
Resulting Correlation Alert — CRITICAL
RULE: "Multi-Source Attack Chain — Email → Execution → C2" IF email_macro_execution AND powershell_encoded_cmd AND c2_outbound_attempt WHERE all events.host = same_host WITHIN time_window(4h) THEN fire(severity=CRITICAL, confidence=HIGH, mitre="T1566.001+T1059.001+T1571")
This single correlated alert replaces 3 individual medium/high alerts and fires with CRITICAL severity because all three stages are confirmed on the same host.
Threat intelligence enrichment added automatically
Analyst Tip
Enrichment happens at alert time, not query time. The SIEM calls out to threat intel feeds (VirusTotal, Shodan, internal threat intel) when the alert fires and adds context automatically. This saves 5-10 minutes per alert — multiplied by hundreds of alerts per day, that's significant.
Correlation — Instructor Notes
Walk through the three source events — each one in isolation would be medium severity at best. The correlation is what elevates this to critical. Discuss time windows: too short (5 min) misses slow attacks; too long (24h) creates false positives from unrelated events on busy hosts. 4 hours is the "Goldilocks" window for this type of attack chain. Point out how enrichment adds threat intelligence context without the analyst having to look anything up.
Engineering Question
What would break this correlation rule? If the attacker used different hosts for each stage. Or waited more than 4 hours between stages. This is why defenders need multiple overlapping rules, not just one.
12 Noise Reduction & SIEM Tuning SIEM Operations Apply suppression rules to reduce noise — watch the queue shrink
Alert queue: 12  alerts  ·  8 signal  ·  4 noise
Suppression Rules
Apply each suppression rule by checking it on. Watch how the alert queue changes — signal stays, noise disappears.
Queue Stats
Total alerts12
Suppressed0
Remaining12
False positive rate33%
Class Exercise
Apply all 4 suppression rules. Then: did you suppress any true positives? If so, which ones and why is that dangerous?
Noise Reduction — Instructor Notes
Start with all rules off — 12 alerts, 33% FPR. As you apply each rule, the queue clears. The key teaching moment: suppression rule 3 (service account auth) is slightly risky — service account logons can indicate lateral movement. Always suppress with a narrow scope (specific account + specific host) rather than broadly. After all rules: 8 alerts, 0% FPR in this dataset. Ask the class: is 0% FPR sustainable, or are we over-suppressing?
13 SOC Metrics & Performance Operations Measure the Ficsit Inc. SOC performance against this incident
Detection coverage by MITRE ATT&CK phase
Incident timeline — key time markers
Key Insight
The MTTD for initial access was 8 minutes (excellent). The MTTD for the full attack chain was 120 minutes (concerning). This gap — fast email detection, slow execution detection — is where attackers live. Improving detection at the execution phase would cut dwell time by 100 minutes.
Class Discussion — Wrap-Up
Looking at the coverage gaps: Data Exfiltration was not detected. If the attacker had successfully exfiltrated the LSASS dump, how would you have found out? What detection would you build to catch it? Answer: monitor for large outbound data transfers to new destinations, or TLS inspection to detect C2 over port 443.
SOC Metrics — Instructor Notes
Use this section as the capstone discussion. Point to the MTTD gap between initial access (8 min) and full chain (120 min) — this is the "detection gap" that all mature SOCs try to close. Industry benchmarks: median MTTD is 207 days for breaches discovered internally (IBM 2024). The Ficsit SOC found this in 2 hours — excellent. But MTTR is still open because they haven't contained it. The goal of this entire lab has been to build the skills to close that gap.