14 Tactics
Click a tactic to explore techniques and detection opportunities.
← Select a tactic to see techniques
MITRE ATT&CK — Instructor Notes
Emphasize that ATT&CK is not a compliance checkbox — it is a shared vocabulary for describing what attackers do. Analysts who can say "this alert maps to T1003.001 — LSASS dump, which is Credential Access" immediately know the next defensive action (isolate the host, reset credentials, check for lateral movement) rather than treating alerts in isolation. Use the Ficsit tactic mapping exercise to build this muscle memory. Common student mistake: confusing tactics with techniques. Drill: "The tactic is the WHY, the technique is the HOW."
Analyst Note
In practice, you rarely have time to look up ATT&CK IDs during an incident. The goal is to internalize the tactic flow — Recon → Initial Access → Execution → Persistence — so you can predict what an attacker will try next even before you have the evidence. When you see an encoded PowerShell execution (Execution), your next question should be "where's the persistence mechanism?" — not because the alert told you, but because you understand the adversary playbook.
Known Threat Actors
← Select an actor to view profile
Threat Actor Profiling — Instructor Notes
Stress that attribution in a SOC is a confidence assessment, not a verdict. Analysts who say "this is definitely APT28" are overstepping — that determination requires intelligence community resources, legal evidence chains, and geopolitical context beyond typical SOC scope. What analysts can and should do: profile TTPs, recognize actor clusters, and inform defenders about likely next moves based on known actor behavior. The "Ficsit Relevance" callout for each actor is the key learning moment — ask students to articulate WHY each actor does or does not match before revealing the answer.
Analyst Note
When I get a new alert, I spend 60 seconds checking whether the IOCs or TTPs match any known actor in our threat intel platform before I start investigating from scratch. If the C2 IP or malware hash appears in a known campaign, that context changes everything — I immediately know what lateral movement techniques to hunt for, what credentials to rotate, and who to escalate to. Threat actor profiling isn't academic — it directly accelerates triage.
Execution Chain
Sample: invoice_Q2.xlsm
Analyst Tip — Finding Each Stage
Dropper: Sysmon Event 1, Office parent spawning cmd/PowerShell. Loader: outbound HTTP GET + PE file creation in Sysmon Event 11. Payload: Sysmon Event 10, unexpected process accessing explorer.exe memory. C2 Beacon: NGFW NetFlow showing regular-interval HTTPS. Persistence: Sysmon Event 13, Run key pointing to %APPDATA%. Each stage leaves a different log footprint — knowing which event ID maps to which stage is half the battle.
← Select a stage to see details
Malware Lifecycle — Instructor Notes
Walk students through the 13-minute timeline from macro execution to persistence. The key insight: by the time most organizations notice an infection (hours or days later), all 5 stages have already completed. Detection at the Dropper stage (Office spawning PowerShell) is the highest-leverage intervention — if that alert had been auto-escalated, the analyst would have had svc32.exe, the C2 IP, and the staging domain in hand before any lateral movement. Discuss why "detection only" mode EDR is insufficient — prevention at the Installation stage would have blocked the payload even if the Delivery/Execution stages succeeded.
Analyst Note
The PDB string in svc32.exe — "D:\Projects\chimney\svc32\" — is the kind of OPSEC mistake that gets attackers caught. Attackers often compile with debug symbols enabled and forget to strip them. When you run strings or PEiD against a suspicious binary, always check for PDB paths — they often contain project names, usernames, or campaign codenames that link multiple pieces of malware together. The "chimney" string here is how the IRON CHIMNEY cluster was named.
Indicator Levels
Higher = harder for attacker to change when detected.
← Select an indicator level
Pyramid of Pain — Instructor Notes
The Pyramid of Pain (David Bianco, 2013) reframes IOC-based detection from "what do we block?" to "what costs the attacker the most?". Use the Ficsit incident to make it concrete: the C2 IP (185.220.101.42) was in two public threat intel feeds — but Ficsit had no automated ingestion, so blocking it cost zero effort. The VBA Chr() obfuscation technique (TTPs) is something the attacker would have to redesign their entire delivery mechanism to change. Ask: if Ficsit had TTP-based detections from day one, which alert would have fired first — and would it have mattered?
Analyst Note
When I get an IOC from a threat intel feed, the first thing I ask is: "where does this sit on the Pyramid of Pain?" A hash goes straight to a block list — but I don't write a detection rule around it because the attacker can evade it in 5 minutes. A TTP like "Office spawning PowerShell" goes into a Sigma rule that fires regardless of what malware they're using. The goal is building detection coverage that survives infrastructure rotation and tool changes — and that means working from the top of the pyramid down.
Sigma Rule Library — Ficsit Incident
| Rule ID | Name | Tactic | Severity | Status |
|---|
Event Tester
Process Name
Command Line
Parent Process
Destination IP
Select a rule to view Sigma definition
Key Concept
False positives vs. false negatives — a detection rule sits on a spectrum. A broad rule catches everything (low false negatives) but floods analysts with noise (high false positives). A narrow rule is quiet but misses variants. Tune toward behavioral specificity: "Office spawning PowerShell" has almost no legitimate use case — it can be broad on the condition and still produce zero false positives. Contrast with "any PowerShell execution" — that fires on every admin script and IT automation task.
Exercise
Use the Event Tester to test these 4 scenarios and record which rules fire: (1) process=powershell.exe, parent=winword.exe — (2) process=procdump.exe, parent=svc32.exe, cmd=-ma lsass.exe — (3) process=cmd.exe, parent=explorer.exe, ip=185.220.101.42 — (4) process=notepad.exe, parent=explorer.exe. Identify which scenario has a detection gap and write a rule to close it.
SIEM Rule Writing — Instructor Notes
Sigma is a vendor-agnostic detection rule format — a Sigma rule can be compiled to Splunk SPL, Microsoft Sentinel KQL, Elastic DSL, or Rapid7 IDR queries. Teach students to think in Sigma first, SIEM syntax second. Key exercise: have students test scenario 2 (procdump + lsass.exe) — this fires NO rules in the current library (FC-005 fires on LSASS access, not procdump by name). Ask: what Sigma rule would you write to catch this? The answer should be based on behavior (non-system process accessing lsass.exe) not the tool name (procdump.exe), because attackers can rename the binary.
Analyst Note
The most useful thing I did in my first detection engineering role was mapping all our existing Sigma rules to ATT&CK techniques and finding the gaps. We had excellent Initial Access and Execution coverage — but zero Lateral Movement rules. That gap analysis directly drove our next 3 months of detection work. The ATT&CK heatmap in Section 12 is exactly that kind of coverage audit — it makes the blind spots visible instead of letting them hide in a sea of active rules.
Login Anomalies
Process Anomalies
Network Anomalies
| Timestamp | User | Source IP | Location | Method | Result | Baseline Delta | Risk |
|---|
Behavioral Analytics — Instructor Notes
UEBA (User and Entity Behavior Analytics) detects anomalies relative to a baseline — not absolute rules. Impossible travel (Chicago → Frankfurt in 5 hours) is only detectable if the system knows the user's normal login location. This is why baseline period matters: UEBA deployed on day one has no baseline and generates constant false positives. Discuss the 3 behavioral categories here — login anomalies (identity-based), process anomalies (endpoint-based), and network anomalies (network-based) — and how combining all 3 for a single entity dramatically raises confidence. A login from Frankfurt AND a C2 beacon AND a new process in %TEMP% is near-certainty, even if each signal alone might be tuned away.
Analyst Note
The 02:17 brute-force pattern on sarah.okonkwo is a great example of a signal that needs context. Three failed logins at 2 AM could be a locked-out employee, a forgotten password, or lateral movement with stolen credentials being tested. The difference is in the surrounding signals: is there a matching process anomaly on that host? Is there SMB traffic from her IP to other hosts? Behavioral analytics is about correlation, not individual alerts in isolation.
Static
Dynamic
Network
YARA
Sample: svc32.exe · SHA256: a3f8c2...
[Static analysis output TBD — PE header, imports, strings, entropy]
Malware Triage — Instructor Notes
Malware triage follows a defined sequence: static first (no execution risk), then dynamic (controlled sandbox environment), then network (what does it phone home to?), then YARA (does it match known families?). Emphasize that the order matters — running an unknown binary without static analysis first can waste sandbox capacity on benign files. The anti-analysis behaviors in the dynamic tab (VM detection, 2-minute sleep, debugger check) are an excellent teaching moment: explain why sandbox reports sometimes come back clean even for confirmed malware — the sample detected it was in a VM and exited cleanly. Ask: how do you sandbox a VM-aware sample?
Analyst Note
The first thing I look at in any suspicious binary is the PE imports section. If I see OpenProcess + VirtualAllocEx + WriteProcessMemory in the same binary, that's the process injection triad — I know immediately this file is going to try to hide inside another process. I don't need to run it. I can build a YARA rule on those imports and start hunting for the same capability across all endpoints before the sandbox even finishes. Imports don't lie — they show you what the binary is capable of even before it executes.
Email Headers
Sample: phishing email to marcus.chen@ficsit-pioneer.corp
Red Flags — This Email Has 5
① From domain is invoices-ficsit.io, NOT @ficsit-pioneer.corp (2-day-old typosquat). ② Reply-To routes to Gmail — attacker reads all replies. ③ X-Originating-IP is 185.220.101.42, the same C2 server used in the breach. ④ SPF SOFTFAIL — attacker's own domain doesn't authorize the sending IP. ⑤ Attachment is macro-enabled .xlsm. Any one of these warrants investigation; all five together is unambiguous.
Email Authentication Results
← Click a header field for analysis
SPF · DKIM · DMARC — How They Interact
SPF (Sender Policy Framework): publishes which IPs are allowed to send email for your domain. Result: PASS, SOFTFAIL, or FAIL. DKIM (DomainKeys Identified Mail): cryptographically signs the message body and headers — proves the message wasn't altered in transit. DMARC (Domain-based Message Auth, Reporting & Conformance): ties SPF and DKIM together and tells receivers what to do when they fail (none / quarantine / reject). Critical insight: DMARC only protects the exact domain in the From header — lookalike domains (invoices-ficsit.io) are outside your DMARC policy. This is the gap attackers exploit.
Exercise — Header Forensics
Click every header field in the list. For each one: (1) classify it as OK / SUS / BAD, (2) explain why it is or isn't suspicious, (3) identify which headers directly prove attacker infrastructure involvement. Then answer: which single header provides the strongest forensic link between this phishing email and the C2 server identified in the breach? (Hint: check X-Originating-IP.)
Phishing Analysis — Instructor Notes
The X-Originating-IP header is the key "aha" moment in this section. The same IP (185.220.101.42) that sent the phishing email is the C2 server that svc32.exe beacons to — a clear infrastructure link. Attackers who reuse infrastructure across delivery and C2 make attribution much easier. The DMARC gap is also worth dwelling on: many organizations achieve DMARC p=reject on their own domain and consider the problem solved — but lookalike domains (which cost $10 to register) completely bypass your DMARC policy. Brand protection services monitor for these registrations proactively.
Analyst Note
When I analyze a suspected phishing email, I read headers bottom-to-top — the lowest Received header is where the email originated. The X-Originating-IP and the bottom-most Received header together tell me the real sending server. Everything above that in the chain is relay hops your infrastructure added. Once I have the originating IP, I pivot to threat intel: VirusTotal, Shodan, AbuseIPDB. In this case, 185.220.101.42 was listed in abuse.ch's threat feed — the email and the malware both link back to the same server.
Hunt Builder
Define Hypothesis
Threat
Scope
Time Window
Pivot Field
Hypothesis Framework — 3 Approaches
TTP-based: "We know attackers use T1021.002 (SMB lateral) — let's hunt for admin$ share access from workstations." Highest confidence, most durable. IOC-based: "A threat intel report named 185.220.101.42 — let's find any connections to that IP." Fast but only catches known infrastructure. Anomaly-based: "Which hosts have unusual outbound traffic volumes compared to their 30-day baseline?" Catches unknown threats but requires strong baseline and analyst judgment to reduce false leads. The best hunts combine all three.
Hunt Results
Define a hypothesis and click Run Hunt to begin.
Exercise — Run All 5 Hunt Types
Run each threat type (C2, Lateral Movement, Exfiltration, Persistence, Credential Access) against the workstation subnet. For each hunt: (1) record how many matching events were found, (2) identify which host first appears in the results, (3) determine the chronological order of the attack stages based on the timestamps. Then answer: if you had run the Persistence hunt 12 hours after the initial compromise, would you have detected the breach before lateral movement occurred?
Threat Hunting — Instructor Notes
Threat hunting is proactive — you are not responding to an alert, you are assuming the breach has already happened and working to find it. The Ficsit case is ideal for this: the attacker had 70 hours of dwell time with 847 documented C2 beacons. A hunter running the C2 beaconing hunt on day 1 would have found WIN-MCHEN-WS01 within 4 hours of the first beacon. The key learning: most compromises are not discovered through alerts — they are discovered through threat hunting or external notification. The Persistence hunt exercise forces students to think about whether proactive hunting could have shortened the dwell time from 70 hours to under 24.
Analyst Note
The Fourier analysis beaconing hunt is one of the highest-signal hunts you can run. Fixed-interval C2 traffic is statistically very different from human-generated or application-generated traffic. I use a Jupyter notebook that pulls NGFW NetFlow into a pandas DataFrame, groups by (src_ip, dst_ip) pairs, and runs FFT on the connection timestamps. Any pair with a dominant frequency below 600 seconds and σ below 90 seconds gets flagged automatically. It catches 95% of known C2 families and produces fewer than 5 false positives per week on a network of 2,000 hosts.
← Select a kill chain phase
← Select a phase to see defender controls
Kill Chain Disruption — Instructor Notes
The key insight of the Kill Chain model is that defenders only need to succeed once — attackers need to succeed at every phase. Walk through each Ficsit phase and ask: "At which phase was this the most disrupted? At which phase was the gap most costly?" The answer: Exploitation (the 6-hour alert delay) was the single biggest miss. If that EDR alert had auto-escalated in 5 minutes instead of 6 hours, analysts would have contained the breach before Installation, C2, and Actions on Objectives all completed. The Kill Chain is not a detection framework — it is a reasoning framework for understanding where in the attack lifecycle your controls sat and where they failed.
Analyst Note
When I'm doing post-incident review, I map every event to a Kill Chain phase and then ask: at which phase did we have the best chance to stop this, and why didn't we? At Ficsit, the answer is unambiguous — the Exploitation phase EDR alert was the kill shot opportunity. Everything after that was downstream of a 6-hour queue delay. That finding drove a direct SOC process change: P1 escalation for Office→shell process chains, no analyst triage required. That one change prevents this entire class of attack from completing in future.
Active Attribution Exercise — IRON CHIMNEY Campaign
You are analyzing artifacts from the Ficsit Inc. breach. Tag each piece of evidence with the threat actor it most closely matches. When enough evidence is tagged, the attribution panel will reveal the analysis.
0 / 10 tagged
| Artifact | Type | Value | Source | Matches | Tag |
|---|
Attribution Analysis
Campaign Attribution — Instructor Notes
Attribution is a confidence level, not a verdict — this is the core principle to drive home. Students often want binary answers: "Was it APT41 or not?" The real answer is "the IRON CHIMNEY cluster has high infrastructure overlap with APT41 tooling, but we cannot conclusively assign nation-state attribution without intelligence community resources." The campaign tagging exercise is designed to make students work through the evidence aggregation process themselves rather than receiving a conclusion. The "10 artifacts tagged" reveal is the payoff — at that point, the pattern is clear even if the actor name remains probabilistic. Also highlight the PDB string as the single most valuable artifact: leaked build paths are an OPSEC failure that directly enable attribution.
Analyst Note
I approach attribution the same way a detective approaches a case — circumstantial evidence that converges from multiple independent sources builds a compelling picture even when no single piece of evidence is definitive. The infrastructure overlap (Hetzner ASN, Google Storage exfil channel), the tooling patterns (VBA Chr() obfuscation matching IRONSHELL), and the PDB path ("chimney") all point to the same cluster independently. When 10 different artifacts all point to the same actor, that's the closest thing to attribution you get at the SOC level — and it's enough to brief leadership, engage law enforcement, and inform proactive threat hunting for this actor's other TTPs.
ATT&CK Coverage Heatmap
Detection Control Inventory
Detection Coverage — Instructor Notes
The coverage audit is the capstone of this lab — it ties every section together into a practical deliverable. A detection coverage audit answers the question: "Which ATT&CK tactics and techniques do we have detection for, and where are we blind?" The Ficsit audit shows 9/14 covered (partially) with 5 critical gaps. The most impactful gaps — TLS inspection, application control, and DLP auto-block — are not exotic; they are well-understood controls that were simply not deployed. Use the "gap" items to drive discussion: for each gap, ask students to estimate the cost of implementing the control vs. the cost of the breach it would have prevented. This is the language of risk-based security investment that practitioners need to speak to leadership.
Analyst Note
I run a coverage audit for every team I join within the first 30 days. The output is a heatmap — green for covered tactics, yellow for partial, red for gaps — and I present it to the CISO alongside a prioritized remediation list. The prioritization criteria: (1) which gaps appeared in a recent breach or threat report targeting our industry? (2) which controls have the highest ROI (TTP-level detection vs. hash-level detection)? (3) which are quickest to close with existing tools? At Ficsit, application control would have been the single highest-ROI control to add — it blocks entire classes of attacks, not just svc32.exe specifically.