« Red Team Engineer

Phase 10 — Social Engineering & Initial Access

Operation Cedar Lattice, Phase 10. The prior nine phases built the full post-exploitation playbook: payload development, EDR evasion, C2 infrastructure, cloud lateral movement. Now the engagement plan asks the hardest question defenders face: how did the attacker get in at all? For Meridian Freight International, the answer — as it is in the majority of real-world breaches — is email. Phase 10 covers the adversary-emulation tradecraft behind FIN-LATTICE's initial-access campaigns, with a clinical focus on email authentication analysis and OSINT-to-pretext mapping, both from the attacker's planning perspective and from the defender's detection engineering perspective.

Safety (non-negotiable). This phase contains no working phishing tools, no credential harvesters, no email-sending infrastructure, and no weaponized attachments. Every offensive concept is paired with its detection. The labs are analyzers and detectors over synthetic metadata — they score email headers and map OSINT findings; they do not send email or perform live reconnaissance.

Why This Phase Exists

Social engineering — specifically spearphishing — is the number-one initial-access vector in enterprise breaches. Mandiant's M-Trends data consistently shows phishing driving 30–40 % of intrusions, and MITRE ATT&CK T1566 (Phishing) is the most-observed initial-access technique across threat-actor reporting. Despite decades of security awareness training, email remains effective because it targets the trust model, not a software vulnerability: a well-crafted pretext exploits organizational context, urgency, and authority rather than an unpatched CVE.

Understanding how SPF, DKIM, and DMARC work — and how each can be passed, bypassed, or misconfigured — is required knowledge for anyone doing detection engineering, red teaming, or incident response. Building the OSINT-to-pretext pipeline from structured data is what separates a principal-level engagement from a generic phishing run.

Learning Objectives

1. Explain how SPF, DKIM, and DMARC interact, and describe the precise conditions under which each authentication check passes, fails, or is bypassed.
2. Parse raw email header authentication results and compute a structured phishing-risk score based on SPF result, DKIM result, DMARC policy enforcement, domain alignment, and reply-to anomalies.
3. Describe the OSINT methodology for building a spearphishing pretext: org-chart discovery, tech-stack enumeration from job postings, email-pattern inference from public sources, and subdomain surface mapping.
4. Map ATT&CK T1566.001 (spearphishing attachment) and T1566.002 (spearphishing link) to concrete detection artifacts: email gateway logs, EDR process-tree telemetry (Sysmon EID 1, EID 11, EID 3), and user-report pipeline events.
5. Construct and interpret a DMARC aggregate report (rua) and explain how it helps defenders detect domain abuse at scale.
6. Articulate the detection engineering implications of DMARC p=none on a target domain.
7. Given a synthetic OSINT profile, identify vendor-impersonation pretext opportunities and enumerate the detection capabilities the target organization likely has based on its technology stack.

Cedar Lattice Artifact

Phase 10 Engagement Note — FIN-LATTICE TTPs

FIN-LATTICE's prior campaigns (INDUSTROYER2 reporting, Mandiant UNC4577 overlap) show a consistent initial-access pattern: OSINT-driven vendor impersonation pretext delivered via a domain that passes SPF but fails DMARC alignment, targeting finance and operations staff at freight and logistics companies. The pretext typically impersonates a Salesforce or SAP account team contact, references a real contract renewal date harvested from LinkedIn posts, and links to a credential-harvesting page on a lookalike domain.

Meridian Freight's DMARC record is p=none — aggregate reports enabled, but zero enforcement. This means any message that passes SPF (even from an attacker-controlled server on the SPF record's include: chain) will be delivered regardless of DKIM failure or domain mismatch. Detection is entirely dependent on the email gateway's ML scoring and the user-report pipeline.

Labs

How to Run

# Lab 01 — run tests against stubs (should fail with NotImplementedError)
cd lab-01-email-auth-analyzer
pytest -q

# Lab 01 — run tests against reference solution
LAB_MODULE=solution pytest -q

# Lab 02 — run tests against stubs
cd ../lab-02-osint-surface-mapper
pytest -q

# Lab 02 — run tests against reference solution
LAB_MODULE=solution pytest -q

« Phase 09 — Cloud & Container Red Team