« 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.