« Phase 10 README

WARMUP — Social Engineering & Initial Access

Operation Cedar Lattice, Phase 10.
Before touching the labs, read every chapter in sequence. This guide takes you from the statistical reality of why email is still the dominant initial-access vector through the full email authentication stack, OSINT methodology, pretext construction, blue-team detection engineering, and the ATT&CK technique map. The lab walkthrough at the end shows exactly what each lab tests and what the solution must implement.

Table of Contents

Chapter 1: Social Engineering as Initial Access

1.1 The Numbers

Every major incident-response retrospective for the last decade tells the same story. Mandiant M-Trends 2023 reports phishing as the initial infection vector in approximately 36 % of intrusions across all industries — the single largest category, ahead of exploitation of public-facing applications and stolen credentials. Verizon DBIR data shows consistent 25–30 % attribution to phishing across thousands of breach records annually. CISA advisories for nation-state actors (APT29, APT41, Lazarus Group) invariably lead with spearphishing as the entry mechanism.

Why? Because defenders have become extremely good at patching software vulnerabilities. Mean time to patch for critical CVEs has compressed from weeks to days at security-mature organizations. Email exploits trust, not software. There is no patch for a well-crafted pretext.

1.2 ATT&CK T1566 Family

MITRE ATT&CK categorizes phishing under Tactic: Initial Access, with three sub-techniques:

  • T1566.001 — Spearphishing Attachment: payload delivered as an attachment (macro-enabled Office document, PDF with embedded JS, ISO with LNK dropper, HTML smuggling).
  • T1566.002 — Spearphishing Link: payload delivered as a URL (credential harvesting page, drive-by download, OAuth phishing).
  • T1566.003 — Spearphishing via Service: payload delivered through a trusted third-party service (SharePoint link, OneDrive share, Dropbox, LinkedIn InMail, Teams message).

FIN-LATTICE primarily uses T1566.001 and T1566.002 in combination: the link leads to a landing page that serves either a credential harvester or an HTML-smuggled payload.

1.3 The Trust Model Attack

Modern email security stacks layer multiple controls:

  1. Email authentication: SPF, DKIM, DMARC — verify the sending domain's authorization.
  2. Gateway filtering: ML-based phishing scoring, URL rewriting, attachment sandboxing (Proofpoint TAP, Mimecast, Microsoft Defender for Office 365).
  3. User training: phishing simulation programs, user-report buttons.
  4. Endpoint controls: EDR monitoring child processes of mail clients, macro policy.

The fundamental attack surface is that all of these are probabilistic, not deterministic. An email that passes SPF, passes DKIM, and reaches the inbox is not safe. It means the sending domain is authorized by the domain owner — but the domain owner could be the attacker who registered meridian-freight-intl.com last Tuesday and added themselves to the SPF record.

The trust model attack exploits the gap between authentication and legitimacy: authentication proves the server was authorized to send; it says nothing about whether the pretext is truthful or the link is benign.

1.4 Why Email Persists as the Most Effective Vector

  • Universal reach: every employee has email; no other channel reaches 100 % of the org.
  • Context richness: email carries sender name, subject, body, attachments, links — enough surface to craft a highly convincing pretext.
  • Action-oriented: email is a task-execution medium. Humans are conditioned to do things when they receive email (click, download, approve, reply with credentials).
  • Asynchronous: the attacker does not need to be present at the moment of interaction. A single well-crafted message can sit in an inbox until the target is distracted or rushed.
  • Authentication complexity: SPF/DKIM/DMARC have lookup limits, alignment subtleties, and policy gaps that even experienced administrators misconfigure.

Chapter 2: Email Authentication Stack (SPF / DKIM / DMARC)

2.1 SPF — Sender Policy Framework (RFC 7208)

What it is. SPF is a DNS TXT record published by the domain owner that lists which IP addresses or mail servers are authorized to send email claiming to be from that domain. The receiving mail server looks up the record and checks whether the sending server's IP is listed.

Record syntax. SPF records are TXT records at the root of the domain:

v=spf1 include:mailgun.org include:_spf.google.com ip4:203.0.113.10 -all

Mechanisms:

  • include:domain — recursively include the SPF record of domain.
  • ip4:cidr / ip6:cidr — authorize specific IP ranges.
  • a — authorize the domain's own A/AAAA records.
  • mx — authorize the domain's MX servers.
  • all — catch-all, applied when no earlier mechanism matches.

Qualifiers:

  • +all (default) — pass (any server passes; this is a misconfiguration).
  • -all — hard fail (any unlisted server fails; email should be rejected).
  • ~all — soft fail (unlisted server gets a softfail; typically delivered with a warning header, not rejected).
  • ?all — neutral (no policy statement; pass through).

SPF result values (returned in the Authentication-Results header):

  • pass — sending IP is authorized.
  • fail — sending IP explicitly unauthorized (-all matched).
  • softfail — sending IP unauthorized under soft policy (~all matched).
  • neutral — domain owner makes no assertion.
  • none — no SPF record found.
  • permerror — permanent error (invalid record syntax, too many DNS lookups — the 10-lookup limit exists because SPF include: chains are recursive and could be used as a DNS amplification vector).
  • temperror — transient DNS failure.

What SPF checks and what it does not. SPF checks the MAIL FROM (envelope sender, also called the RFC5321.MailFrom or Return-Path). It does NOT check the From: header visible to the user (RFC5322.From). This distinction is critical: an attacker can pass SPF on the envelope sender (evil@attacker.com) while displaying From: boss@legitimate.com to the recipient. DMARC closes this gap through alignment.

SPF alignment is the requirement that the domain in the MAIL FROM matches the domain in the From: header. DMARC enforces alignment; SPF alone does not.

DNS record example — Meridian Freight SPF:

meridianfreight.com. 300 IN TXT "v=spf1 include:_spf.google.com include:mailgun.org ~all"

This is a soft-fail policy. Unlisted senders get softfail, which most gateways deliver (not reject). A red team that controls a server within mailgun.org's ranges passes SPF completely — no anomaly, no alert from SPF alone.

2.2 DKIM — DomainKeys Identified Mail (RFC 6376)

What it is. DKIM adds a cryptographic signature to email. The sending mail server signs selected headers and the body using a private key; the receiving server retrieves the public key from DNS and verifies the signature. A valid DKIM signature proves that the email headers and body were not altered in transit and that the signer controlled the DNS record at signing time.

How it works technically. The signing algorithm (typically rsa-sha256) computes a hash over the canonicalized selected headers (defined by the h= tag) plus the body. The signature is placed in the DKIM-Signature header.

DNS key record — published at selector._domainkey.domain:

mail._domainkey.meridianfreight.com. 300 IN TXT (
  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
  "KBgQC2...rest-of-base64-public-key...AQAB"
)

DKIM-Signature header fields:

  • v=1 — DKIM version.
  • a=rsa-sha256 — algorithm.
  • d=meridianfreight.com — signing domain (the d= tag is what DMARC checks for alignment).
  • s=mail — selector (maps to mail._domainkey.meridianfreight.com).
  • h=From:To:Subject:Date:Message-ID — headers included in the signature.
  • bh= — base64 hash of the canonicalized body.
  • b= — base64 signature over the selected headers and body hash.

Why signing only From + Subject is weak. If the h= tag only covers From and Subject, an attacker can inject additional headers (e.g., a forged Reply-To) that are visible to the user without invalidating the signature. Best practice is to include all security-relevant headers: From, To, Subject, Date, Message-ID, Reply-To, Content-Type.

DKIM result values:

  • pass — signature verified.
  • fail — signature invalid (content modified or wrong key).
  • neutral — no signature.
  • none — no signature found.
  • policy — signature present but violates domain policy.
  • temperror / permerror — transient or permanent errors.

DKIM domain alignment. The d= tag in the DKIM-Signature must match (or be an organizational domain match of) the From: header domain. This is what DMARC checks. An attacker who signs email with d=attacker.com passes DKIM but fails DMARC alignment against From: finance@meridianfreight.com.

2.3 DMARC — Domain-based Message Authentication, Reporting and Conformance (RFC 7489)

What it is. DMARC builds on SPF and DKIM by adding:

  1. Policy: what should receivers do with messages that fail authentication?
  2. Alignment: should the authenticated domain match the From: header exactly?
  3. Reporting: send aggregate (rua) and forensic (ruf) reports back to the domain owner.

DNS record example:

_dmarc.meridianfreight.com. 300 IN TXT (
  "v=DMARC1; p=none; rua=mailto:dmarc-reports@meridianfreight.com;"
  "ruf=mailto:forensics@meridianfreight.com; fo=1; adkim=r; aspf=r"
)

Policy values (p=):

  • none — monitor only. No action taken on failing messages. Reports still sent. This is where most organizations start during DMARC rollout. It means an attacker can send email that fails DMARC and it will be delivered normally. Zero enforcement.
  • quarantine — messages that fail DMARC are moved to the spam/junk folder.
  • reject — messages that fail DMARC are rejected at the SMTP level (never delivered).

Subdomain policy (sp=): separate policy for subdomains. If omitted, subdomains inherit p=. An attacker who registers billing.meridianfreight.com as a lookalike... wait, that requires DNS control. More relevant: a legitimate subdomain with no SPF coverage can be used to send email that inherits the parent's p=none and gets delivered.

Aggregate reports (rua). The receiving mail server sends XML reports to the address in rua=. Each report covers a 24-hour window and contains: source IP, count of messages, SPF result, DKIM result, DMARC disposition. This is the most underutilized detection artifact in enterprise email security. A DMARC aggregate report tells you exactly who is sending email claiming to be your domain, which passes and which fails, at scale.

Forensic reports (ruf). Full message metadata (headers, sometimes body) for individual failed messages. Often disabled due to privacy concerns.

DMARC alignment modes:

  • Relaxed alignment (adkim=r, aspf=r, default): the organizational domain must match. mail.meridianfreight.com aligns with meridianfreight.com because they share the same registered domain. This is the most common configuration.
  • Strict alignment (adkim=s, aspf=s): the domain must match exactly. mail.meridianfreight.com does NOT align with meridianfreight.com under strict.

DMARC pass logic. DMARC passes if at least one of the following is true:

  1. SPF passes AND SPF alignment passes (MAIL FROM domain aligns with From: domain).
  2. DKIM passes AND DKIM alignment passes (d= tag aligns with From: domain).

An attacker who controls a server on the SPF include: chain can pass SPF, pass SPF alignment, and therefore pass DMARC — even without a valid DKIM signature. This is why p=none with a permissive SPF record is a high-risk configuration.

DNS record examples for a well-configured domain:

# Tight SPF — only authorized senders, hard fail
meridianfreight.com. IN TXT "v=spf1 include:_spf.google.com -all"

# DKIM key
mail._domainkey.meridianfreight.com. IN TXT "v=DKIM1; k=rsa; p=<pubkey>"

# DMARC at quarantine — enforce!
_dmarc.meridianfreight.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@meridianfreight.com; adkim=r; aspf=r"

Chapter 3: OSINT Methodology

3.1 The OSINT Pipeline

Effective spearphishing is not random. It is built from a structured reconnaissance pipeline:

Passive OSINT → Org Model → Email Pattern → Tech Stack → Pretext Construction

Each stage feeds the next. The output of passive OSINT is an organizational model (who works there, what they use, what they're working on). The email pattern turns names into targetable addresses. The tech stack shapes the pretext (you impersonate the vendor they use).

3.2 LinkedIn for Organizational Structure

LinkedIn is the primary source for:

  • Employee names and roles: building a realistic org chart (who reports to whom, who is in Finance, who is an IT admin).
  • Tenure data: long-tenure employees are higher-trust targets; new employees are easier to social-engineer because they don't yet know "how things work here."
  • Job postings: tech-stack signals. A posting for "Salesforce Administrator" tells you the org runs Salesforce CRM. A "CrowdStrike Engineer" posting tells you the org has deployed a specific EDR — and what detection capabilities you are operating against.

3.3 GitHub for Email Leaks

Git commits embed the author's email address in metadata. The command:

git log --format='%ae' | sort -u

extracts all unique committer email addresses from a repository. For a public GitHub organization, this is a goldmine: real employee email addresses, including the format (first.last, flast, firstlast), and sometimes personal Gmail addresses mixed with corporate addresses (correlation target).

The key insight is email format inference: if you see j.smith@meridianfreight.com and a.jones@meridianfreight.com, the pattern is initial.last@domain. You now have a templated attack surface for every name on the LinkedIn org chart.

3.4 Infrastructure Enumeration

Subdomain enumeration (via certificate transparency logs, passive DNS, DNS brute force) reveals the attack surface of the organization's infrastructure:

  • vpn.meridianfreight.com → VPN endpoint (credential stuffing, password spray target).
  • admin.meridianfreight.com → Admin panel (potentially unauthenticated or weak auth).
  • staging.meridianfreight.com → Staging environment (often weaker controls, real data).
  • gitlab.meridianfreight.com → Source code (may expose internal tools, secrets in commits).
  • jenkins.meridianfreight.com → CI/CD (pipeline poisoning target).
  • confluence.meridianfreight.com → Wiki (may expose architecture diagrams, runbooks).

This surface map informs both the initial-access pretext (link the target to portal. or remote.) and the post-exploitation roadmap.

3.5 Breach Data (Concept Only)

Historical breach databases (Have I Been Pwned, private collections) may contain credentials for employees' personal accounts that have been reused on corporate VPN or SSO. This is credential stuffing territory — out of scope for Phase 10 (that is Phase 05's domain) but relevant to understanding why OSINT-driven initial access is so effective in combination with other techniques.

3.6 The OSINT → Pretext Pipeline

1. LinkedIn: 20 employee names, their roles, their manager chain
2. GitHub: email pattern = first.last@meridianfreight.com
3. LinkedIn job posting: "Seeking Salesforce Administrator for CRM renewal project"
4. Pretext: "Hi [Name], I'm Alex Chen from the Salesforce renewal team.
             Your contract #MF-2024-0891 comes up for renewal next Friday.
             Please review the updated pricing at [link]."
5. Lookalike domain: salesforce-renewal-portal.com (registered last week, passes SPF)

The power of context-rich pretexts is that they defeat the user's primary heuristic: "Does this make sense for me to receive?" Yes, they do use Salesforce. Yes, there is a renewal cycle. Yes, the sender looks like an account manager.

Chapter 4: Pretexting and Pretext Construction

4.1 What Is a Pretext?

A pretext is a fabricated narrative that establishes a plausible reason for the target to take the desired action (click a link, open an attachment, provide credentials, wire money). A good pretext answers three questions before the target's skepticism can ask them:

  1. Who are you? — a plausible, verifiable-sounding identity.
  2. Why are you contacting me? — a reason the target can connect to their real work.
  3. Why now? — urgency that short-circuits deliberation.

4.2 High-Yield Pretext Categories

Vendor impersonation. The most effective category because it leverages an existing trust relationship. If the target organization uses Salesforce, an email from "Salesforce account team" impersonating a renewal manager is almost impossible for a non-technical employee to validate without making a phone call (which they almost never do).

Common vendor impersonation targets:

  • Salesforce → account team / renewal manager (CRM is universally used).
  • AWS → solutions architect / migration specialist (cloud bills arrive regularly).
  • Microsoft / Azure → M365 licensing (everyone has Microsoft licenses).
  • ServiceNow → professional services (IT orgs run ITSM).
  • Okta → identity team (high-value because they control SSO).
  • CrowdStrike → SE / renewal (EDR renewal gives urgency + IT-team targeting).

IT helpdesk impersonation. "Your account will be locked in 24 hours unless you verify your credentials." Targets non-technical employees who have no reason to question IT communications. Effective against large orgs where the IT helpdesk is faceless.

Executive assistant pretext. "I'm emailing on behalf of [CFO name from LinkedIn]. She needs the attached invoice approved today before she leaves for the conference." This combines authority (the CFO) with urgency (today) and a plausible context (conference = time pressure).

4.3 Pretext Construction Framework

A well-constructed pretext has five components:

  1. Identity anchor: a named individual (not a generic "support team") with a believable title, ideally one that exists in the vendor's real org structure.
  2. Organizational context: a reference to something the target's organization actually does (the Salesforce instance, the AWS migration, the ITSM project).
  3. Temporal urgency: a deadline, an expiring offer, a compliance requirement, a conference departure. Urgency prevents the target from pausing to verify.
  4. Low-friction action: the requested action must be small and plausible. "Click to review your invoice" is easier than "log into this system and fill out a form."
  5. Plausible follow-up path: the pretext should anticipate questions. If the target replies asking for more information, the attacker must have a response that doesn't break the narrative.

4.4 Why Context-Rich Beats Generic

A generic phishing email ("Your account has been suspended. Click here.") fails because:

  • It applies to everyone, so it applies to no one specifically.
  • It has no organizational context the target can connect to their work.
  • Modern gateways score generic templates as high-risk.

A context-rich pretext passes gateway ML scoring because:

  • It references specific internal tooling (Salesforce, AWS).
  • It has realistic sender names and titles.
  • The body text is low-entropy and conversational, not template-like.
  • The domain passed SPF and (in p=none environments) DMARC does not reject.

Chapter 5: Detection from the Blue Team Side

5.1 Email Gateway Controls

The email gateway (Proofpoint, Mimecast, Microsoft Defender for Office 365) is the first detection layer. Key detection signals:

  • SPF/DKIM/DMARC results: authentication headers are logged for every message. A message arriving with spf=fail and dmarc=fail on a domain with p=none is delivered but should generate an alert. Detection rule: SPF result = fail AND DMARC policy = none → HIGH RISK.
  • Lookalike domain detection: edit-distance algorithms (Levenshtein), homoglyph substitution (rn vs m), and IDN (internationalized domain name) detection catch most typosquat domains.
  • ML-based phishing scoring: modern gateways run large-scale ML models trained on billions of messages. They score semantic content, link reputation, attachment properties, and header anomalies. The score is usually exposed as a header (X-Phishing-Score, X-MS-Exchange-Organization-SCL, etc.).
  • URL rewriting: gateway rewrites all links through a click-time reputation check. Even if a link is clean at delivery time, reputation at click time (after the attacker activates the payload) will block it.
  • Attachment sandboxing: macro-enabled documents, executables, and archives are detonated in a sandbox environment. Detection: macro execution, network callbacks, file-system writes.

5.2 DMARC Aggregate Report Analysis

DMARC rua= reports arrive as XML files, typically compressed with gzip. A minimal aggregate report entry looks like this (conceptual structure):

<record>
  <row>
    <source_ip>203.0.113.50</source_ip>
    <count>47</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>meridianfreight.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>spf-domain.attacker.com</domain>
      <result>pass</result>
    </spf>
    <dkim>
      <domain>attacker.com</domain>
      <result>fail</result>
    </dkim>
  </auth_results>
</record>

This record tells a defender: 47 messages from IP 203.0.113.50 claimed to be from meridianfreight.com. SPF passed (but on a different domain — spf-domain.attacker.com). DKIM failed. DMARC policy is none so the messages were delivered. This is a phishing campaign in progress. The domain owner can only see it because they set up rua=.

Detection engineering: parse DMARC aggregate reports daily. Alert on:

  • New source IPs claiming your domain with dkim=fail.
  • SPF pass on a non-owned domain (alignment failure with pass).
  • Volume spikes from new source IPs.

5.3 Endpoint Detection — Process Tree Analysis

When a user opens a phishing attachment (macro-enabled Word document), the EDR records the process tree. Key Sysmon events to monitor:

Sysmon EID 1 — Process Create:

winword.exe → cmd.exe
winword.exe → powershell.exe
winword.exe → wscript.exe
excel.exe   → mshta.exe

Any child process spawned by an Office application that is a scripting engine or shell is a high-confidence macro execution indicator.

Sysmon EID 11 — File Created:

winword.exe creates: %TEMP%\*.exe
winword.exe creates: %APPDATA%\*.dll

File creation from an Office process in temp or appdata directories indicates a dropper.

Sysmon EID 3 — Network Connection:

winword.exe connects to: 203.0.113.50:443
powershell.exe connects to: attacker-c2.com:80

Network callbacks from Office processes or newly-spawned child processes indicate payload staging or C2 check-in.

5.4 User-Report Pipeline

The highest-signal detection for phishing is a user report. Every phishing simulation study shows that even in the worst organizations, at least 5–10 % of recipients report rather than click. In security-mature orgs this can be 60–80 %. A user-report pipeline should:

  1. Provide a one-click report button (Outlook add-in, Gmail extension).
  2. Automatically extract headers from reported messages and cross-correlate against other inboxes (did anyone else get this sender?).
  3. Auto-pull similar messages from all inboxes when a report is confirmed malicious.
  4. Feed confirmed phish back into gateway ML training data.

5.5 Detection Engineering: SPF Fail + DMARC Unenforced

The highest-value detection rule for initial-access phishing is:

IF spf_result IN ('fail', 'softfail', 'none') 
AND dmarc_policy == 'none'
AND dkim_result != 'pass'
THEN alert(CRITICAL, "Unauthenticated message on unenforced domain")

This covers the scenario where an attacker has no legitimate access to the domain's email infrastructure but can still deliver messages because the domain owner has not progressed their DMARC to quarantine or reject.

Chapter 6: Initial Access Techniques (ATT&CK)

6.1 T1566.001 — Spearphishing Attachment

How it works. The attacker delivers a malicious file as an email attachment. Common formats: macro-enabled .docm/.xlsm, .pdf with embedded JavaScript, .iso containing a .lnk (LNK dropper), .html with Base64-encoded JavaScript (HTML smuggling), or a .zip with a .js or .vbs dropper.

Why ISO/LNK became popular (2022-2023). Microsoft disabled Office macros from internet- sourced files by default in 2022. Attackers pivoted to ISO archives (which bypass Mark of the Web on Windows) containing LNK files that spawn a scripting engine directly.

Detection artifacts:

  • Email gateway: attachment file type, MIME type, sandbox verdict.
  • EDR: Office application spawning a child shell/scripting process.
  • Sysmon EID 1: winword.exe → cmd.exe or excel.exe → powershell.exe.
  • Sysmon EID 11: Office writing executable to %TEMP%.
  • Sysmon EID 3: Office process or child making external network connection.

Sigma rule stub:

title: Office Application Spawning Scripting Engine
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: Detects a Microsoft Office process spawning a command shell or scripting engine
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage|endswith:
            - '\winword.exe'
            - '\excel.exe'
            - '\powerpnt.exe'
            - '\outlook.exe'
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
            - '\wscript.exe'
            - '\cscript.exe'
            - '\mshta.exe'
    condition: selection
level: high
tags:
    - attack.initial_access
    - attack.t1566.001

6.2 T1566.002 — Spearphishing Link

How it works. The attachment is replaced with a URL. The link leads to:

  • A credential harvesting page that mimics the target org's SSO (Microsoft login, Okta, custom portal).
  • A drive-by download that serves a payload based on user-agent fingerprinting.
  • An OAuth phishing page that requests consent to a malicious application.
  • A WebDAV share containing a malicious file that Windows Explorer can auto-open.

Detection artifacts:

  • Email gateway URL reputation check (at delivery AND at click time).
  • Web proxy: category block on newly-registered domains, reputation block.
  • EDR: browser spawning a file download, browser spawning a script process.
  • Sysmon EID 3: browser connecting to uncategorized/new domain.
  • DNS: query for newly-registered domain from a workstation.

Sigma rule stub:

title: Browser Connection to Newly Registered Domain
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: Detects browser process making DNS query or TCP connection to domain registered
  within the last 30 days (requires threat-intel enrichment)
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        Image|endswith:
            - '\chrome.exe'
            - '\msedge.exe'
            - '\firefox.exe'
        Initiated: 'true'
    filter_known:
        DestinationHostname|contains:
            - '.microsoft.com'
            - '.google.com'
            - '.amazon.com'
    condition: selection and not filter_known
level: medium
tags:
    - attack.initial_access
    - attack.t1566.002

6.3 T1195 — Supply Chain Compromise

How it works. Rather than phishing a direct employee, the attacker compromises a trusted third party (software vendor, managed service provider) and uses that trust relationship as initial access. This is how SolarWinds (SUNBURST) worked: the trojanized Orion update was delivered to customers who had explicitly trusted the SolarWinds update mechanism.

Detection artifacts:

  • Software integrity monitoring (hash of installed binaries vs. vendor-published hashes).
  • Certificate pinning on software updates.
  • EDR: new unsigned binary from a software update process with unusual network behavior.
  • SIEM: alert on new network connections from software that historically had none.

Sigma rule stub:

title: Unexpected Network Connection from Update Process
id: c3d4e5f6-a7b8-9012-cdef-012345678902
status: experimental
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        Image|contains: 'Update'
        Initiated: 'true'
    filter_expected:
        DestinationHostname|endswith:
            - 'windowsupdate.com'
            - 'adobe.com'
    condition: selection and not filter_expected
level: medium
tags:
    - attack.initial_access
    - attack.t1195

6.4 T1189 — Drive-by Compromise

How it works. The target visits a compromised or attacker-controlled website. The page serves a browser exploit or uses a social engineering prompt to get the user to execute something (fake CAPTCHA that copies clipboard and prompts PowerShell paste — the "ClickFix" technique observed in 2024-2025 campaigns).

Detection artifacts:

  • Web proxy: visit to compromised category or newly-registered domain.
  • EDR: browser spawning PowerShell or cmd.
  • Sysmon EID 1: chrome.exe → powershell.exe.

6.5 T1078 — Valid Accounts

How it works. Attacker obtains valid credentials through phishing (credential harvest), password spraying, breach data, or OSINT inference, then authenticates using those credentials. No exploit required — the attacker looks like a legitimate user.

Detection artifacts:

  • Identity provider: login from new geographic location or new ASN.
  • IdP: login outside business hours for a user with no travel record.
  • IdP: MFA fatigue attack (repeated push notifications, user eventually approves).
  • SIEM: impossible travel detection (two logins from geographically distant locations within a time window that makes travel impossible).

Chapter 7: Misconceptions

Misconception 1: "If SPF passes, the email is safe."

False. SPF only confirms the sending server was authorized by the envelope sender domain — it says nothing about the From: header domain visible to the user, nothing about message content, and nothing about the sending domain's legitimacy. An attacker who registers meridian-freight-intl.com and publishes an SPF record passes SPF completely. DMARC with enforcement is needed to close the alignment gap.

Misconception 2: "DMARC rejects phishing email."

False for the majority of domains. DMARC only rejects when p=reject. Most domains remain at p=none indefinitely because moving to enforcement can break legitimate email flows (mailing lists, forwarding, on-behalf-of sending). According to industry surveys, fewer than 25 % of domains at DMARC p=reject. For a defender, discovering p=none means the domain is essentially unenforced regardless of DMARC being deployed.

Misconception 3: "DKIM proves the email is from the claimed domain."

Partially true, frequently misunderstood. DKIM proves the email was signed by someone who controls the private key for the d= tag's domain. It does NOT prove that d= domain is the same as the From: header domain — that is DMARC alignment's job. An attacker can produce a valid DKIM signature for d=attacker.com on an email with From: ceo@legit.com, and DKIM alone will report pass.

Misconception 4: "User training eliminates phishing risk."

Demonstrably false. Phishing simulation programs consistently show that even after repeated training, some percentage of users will click on sufficiently convincing pretexts. The click rate reduces but never reaches zero. Security architecture must assume some users will be phished and focus on post-click controls (EDR, web proxy, MFA on all internal resources) rather than relying solely on user training.

Misconception 5: "A long DMARC aggregate report means I'm under attack."

Not necessarily. Large organizations send millions of emails from many sources (marketing platforms, transactional email services, employee newsletters, partner systems). A DMARC aggregate report with many source IPs and a mix of SPF/DKIM results is often just the complexity of the organization's legitimate email ecosystem — not an attack. Defenders must baseline normal sending patterns before they can detect anomalous ones. This is why p=none is a useful starting point during DMARC adoption: it lets you see who is legitimately sending on your behalf before you enforce a policy that might block them.

Misconception 6: "The SPF 10-lookup limit is a minor edge case."

False for complex enterprises. The SPF specification (RFC 7208) caps the number of DNS lookups that a receiving server is required to perform during SPF evaluation at 10. Each include:, a, mx, and redirect= mechanism may trigger additional lookups. Large enterprises that include multiple cloud mail providers (mailgun.org, sendgrid.net, _spf.google.com, salesforce.com, amazonses.com) can easily exceed 10, causing permerror — which means SPF evaluation fails and the message may be treated as unauthenticated. This is a common misconfiguration that breaks DMARC enforcement for legitimate mail.

Misconception 7: "Phishing only targets employees without technical knowledge."

False. Some of the most successful spearphishing campaigns have targeted security engineers, executives, and incident responders. The OAuth phishing technique (sending a "Grant access to your account" prompt through a legitimate OAuth flow) is specifically designed to bypass technical users who know not to enter credentials on fake pages — the OAuth consent page IS on a legitimate provider's domain. Technical sophistication changes the attack method, not whether the attack succeeds.

Lab Walkthrough

Lab 01 — Email Auth Analyzer

What it builds. A function library that takes a dictionary of email header authentication fields and returns structured analysis with a weighted risk score.

Core functions to implement:

  1. spf_analysis(header) — Returns {pass: bool, finding: str}. pass=True only if spf_result == 'pass'. The finding string explains the result.

  2. dkim_analysis(header) — Returns {pass: bool, finding: str, domain_match: bool}. domain_match compares the last two dot-separated parts of dkim_domain and from_domain. Example: mail.example.com → base = example.com. Empty dkim_domain → domain_match=False.

  3. dmarc_analysis(header) — Returns {enforced: bool, policy: str, finding: str}. enforced=True only if dmarc_policy is quarantine or reject.

  4. phish_risk_score(header) — Weighted integer score:

    • +3 if SPF result is fail, softfail, none, permerror, or temperror.
    • +3 if DKIM result is not pass.
    • +2 if DMARC policy is none or missing.
    • +4 if DKIM passes but dkim_domain base domain differs from from_domain base domain (subdomain spoof with cross-org DKIM).
    • +3 if reply_to_domain is non-empty and its base domain differs from from_domain base domain.

  5. analyze(header) — Runs all four analyses and returns {risk_score: int, risk_level: str, findings: list[str]}. Risk levels: LOW (0-3), MEDIUM (4-6), HIGH (7-10), CRITICAL (11+).

Test data walkthrough:

  • LEGIT: SPF pass, DKIM pass + domain match, DMARC reject, reply-to matches → score 0, LOW.
  • PHISH: SPF fail (+3), DKIM fail (+3), DMARC none (+2), reply-to mismatch (+3) → 11, CRITICAL.
  • SUBDOMAIN_SPOOF: SPF pass (0), DKIM pass but domain mismatch (+4), DMARC none (+2), reply-to mismatch (+3) → 9, HIGH.
  • SOFTFAIL: SPF softfail (+3), DKIM pass (0), DMARC quarantine (0), no reply-to (0) → 3, LOW.

Lab 02 — OSINT Surface Mapper

What it builds. A function library that takes synthetic OSINT data about an organization and maps it to vendor-impersonation pretext opportunities, sensitive infrastructure, and expected detection capabilities.

Core functions to implement:

  1. email_patterns(github_emails) — Infers email format patterns from a list of real email addresses. Returns sorted list of pattern strings like first.last@domain.com. Pattern inference:

    • If local part contains . and has 2 segments of length > 1 each → first.last@base_domain.
    • If local part contains . and first segment is length 1 → f.last@base_domain.
    • If local part has no . and length > 1 → flast@base_domain.

  2. pretext_angles(job_postings, technologies) — Matches posting text and technology names against VENDOR_MAP keys (case-insensitive). Returns sorted unique list of vendor impersonation descriptions.

  3. exposed_infrastructure(subdomains) — Matches each subdomain against SENSITIVE_SUBDOMAIN_KEYWORDS (keyword must appear anywhere in the subdomain string, case-insensitive). Returns sorted list of {subdomain, service_type, risk_note}.

  4. detection_evasion_notes(target) — Matches target['technologies'] and target['job_postings'] against TECH_DETECTION_MAP keys. Returns sorted list of detection-capability descriptions.

  5. osint_summary(target) — Calls all four functions and assembles the result dict.

Success Criteria

After completing both labs, you should be able to:

  • Parse an email header dict and produce a structured risk score with findings in under 20 lines of Python.
  • Explain to a SOC analyst exactly why SPF softfail + DMARC p=none is a high-risk configuration even if no attack is in progress.
  • Given a list of GitHub emails, infer the organization's email format pattern and articulate why this matters for a spearphishing campaign.
  • Map a job posting to a specific vendor-impersonation pretext and explain the attack narrative.
  • List the five Sysmon event IDs most relevant to detecting phishing attachment execution and explain what each one records.
  • Run both lab test suites with LAB_MODULE=solution pytest -q and see all tests pass.

Common Mistakes

  1. Treating SPF softfail as a pass. In spf_analysis, pass=True only when spf_result == 'pass'. Softfail is not a pass — it is a deliberately weakened policy that the receiving server can honor or ignore. In the risk scorer, softfail adds +3 to the risk score.

  2. Not extracting the base domain for alignment checks. DMARC alignment operates on the organizational domain (last two dot-separated parts), not the full FQDN. mail.example.com aligns with example.com under relaxed alignment. If you compare full strings, you will get false mismatch findings on legitimate mail from subdomains.

  3. Forgetting that DMARC p=none means zero enforcement. Many students see dmarc_result=fail and assume the message was blocked. No. With p=none, DMARC records the failure in the aggregate report and delivers the message. Only quarantine or reject causes action.

  4. Treating DKIM domain mismatch as always malicious. Large organizations often sign email with a shared ESP's DKIM key (e.g., d=sendgrid.net for transactional email). This is a DMARC alignment failure for DKIM, but SPF alignment may still pass. Context matters — domain mismatch is a risk indicator, not a definitive indicator of attack.

  5. Forgetting the reply-to mismatch as a signal. Attackers frequently set a different Reply-To: domain to capture replies without controlling the From: domain. This is one of the most reliable phishing signals and is missing from many scoring systems.

  6. Conflating the OSINT surface mapper's outputs with actual attack capability. The mapper identifies potential pretext angles and expected detection capabilities — it does not verify them. A job posting for "CrowdStrike Engineer" does not guarantee that the org has deployed CrowdStrike in production; it signals that the org is evaluating or building toward it. Assume the detection capability exists and plan accordingly.

Interview Q&A

Q1: What is DMARC and what does "p=none" mean from a security standpoint?

A: DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is a policy layer that sits on top of SPF and DKIM and answers two questions: (1) Should receivers enforce authentication results? (2) Send me reports about what you see. It is published as a DNS TXT record at _dmarc.domain.com.

p=none means the domain owner is in monitoring mode: authentication results are evaluated, aggregate reports are sent to the rua= address, but no enforcement action is taken. Messages that fail SPF, fail DKIM, or fail alignment are delivered normally as if DMARC did not exist. From a security standpoint, p=none is equivalent to no enforcement — it tells receivers "collect the data, don't block anything." For defenders, a target with p=none means the email authentication stack provides logging but zero protection against domain spoofing. An attacker can send email claiming to be from the target's domain from any infrastructure, and it will be delivered as long as the gateway's ML scoring doesn't catch it. This is one of the most common high-risk email authentication misconfigurations in enterprise environments.

Q2: Explain DKIM alignment and why it matters for phishing detection.

A: DKIM alignment is the requirement — enforced by DMARC — that the domain in the DKIM signature's d= tag matches the domain in the email's From: header (the one visible to the user). Without alignment, DKIM pass alone is misleading: an attacker can sign an email with a valid DKIM key for d=attacker.com while the From: header reads ceo@legit.com, and DKIM will report pass. The email is cryptographically signed — just not by the domain the user sees.

DMARC enforces alignment by checking whether the d= domain matches (relaxed: same organizational domain, last two parts; strict: exact match) the From: header domain. If DKIM passes but alignment fails, DMARC falls through to check SPF alignment. DMARC only passes if at least one of SPF or DKIM passes WITH alignment. For phishing detection, DKIM domain mismatch (DKIM passes but d= doesn't align with From:) is a significant risk signal — it means someone signed the message on behalf of a different domain than the one displayed to the user.

Q3: How does SPF softfail (~all) differ from hard fail (-all) in practice?

A: Both ~all (softfail) and -all (fail) indicate that the sending server is not in the authorized list of senders for the domain. The difference is the recommended action communicated to the receiving server:

-all (hard fail) says: this server is definitively not authorized; you SHOULD reject this message. Most modern MTAs treat -all as a strong signal and may reject or quarantine.

~all (softfail) says: this server is probably not authorized, but I'm not fully confident; you MAY deliver this with a warning header. Most MTAs deliver softfail messages to the inbox with an X-Spam-Status: softfail or similar header. The practical effect is that softfail rarely stops delivery.

In practice, many organizations use ~all instead of -all because they are not fully confident their SPF record covers every legitimate sender (cloud apps, third-party services, mailing lists). This makes softfail the most common configuration, and it provides very little protection. For a red team, soft-failing an SPF check means the message still reaches the inbox. For detection engineering, softfail should be treated as a risk signal (it adds to the risk score) but not as a definitive block.

Q4: What OSINT sources are most useful for constructing a spearphishing pretext?

A: In priority order for pretext richness:

  1. LinkedIn — the most valuable source. Provides full name, title, manager chain, tenure, connections, and recent posts (which may mention travel, projects, vendors). The company page shows employee count, location, and hiring patterns.

  2. Job postings — the second most valuable. A job posting for "Salesforce Administrator" or "AWS Cloud Engineer" tells you exactly what technology the org uses and what the vendor relationships look like. This directly drives vendor-impersonation pretext selection.

  3. GitHub — provides email address format (from commit metadata: git log --format='%ae'), sometimes exposes internal tooling, configuration files, or API keys in commit history.

  4. Certificate transparency logs and passive DNS — subdomain enumeration reveals the infrastructure surface: VPN endpoints, admin panels, staging environments, internal tools (Jira, Confluence, GitLab) exposed externally.

  5. Conference talks, press releases, blog posts — executives frequently mention specific technology investments, partnerships, and initiatives in public talks. This provides high- quality pretext context.

The pipeline: LinkedIn → names/roles → GitHub → email pattern → job postings → vendor stack → combine into context-rich pretext targeting a specific person's role and responsibilities.

Q5: How would you detect a spearphishing attachment delivered as a macro-enabled Word document?

A: Detection is layered — you need controls at three points:

At the email gateway (before delivery):

  • Block macro-enabled Office file extensions (.docm, .xlsm, .pptm) from external senders.
  • Sandbox attachment detonation: if the sandbox observes macro execution, network callbacks, or child process spawning, quarantine the message.
  • File hash reputation against known-bad databases.

At the endpoint (post-delivery, on open):

  • EDR/Sysmon EID 1 (Process Create): alert on winword.exe spawning any child process that is a shell or scripting engine (cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe). This is a high-confidence IOC — there is almost no legitimate reason for Word to spawn PowerShell.
  • Sysmon EID 11 (File Create): alert on Office processes writing executables or DLLs to temp or appdata directories.
  • Sysmon EID 3 (Network Connect): alert on Office processes or their children making outbound network connections to external IPs or new domains.

Policy controls:

  • Group Policy: disable macros from internet-sourced files (Microsoft's 2022 default change).
  • Application allowlisting (AppLocker/WDAC): prevent execution of binaries dropped by Office to temp directories.

The highest-value single detection is Sysmon EID 1 on Office spawning a scripting child — it has extremely high precision and fires early in the kill chain.

Q6: What is the difference between T1566.001 and T1566.002?

A: Both are sub-techniques of T1566 (Phishing) under Initial Access.

T1566.001 — Spearphishing Attachment: the payload is embedded in or attached to the email itself. The attacker relies on the user opening the attachment and executing it (macro, exploit, dropper). The payload reaches the endpoint via the email client's file system. Key detection: email gateway sandbox + EDR process-tree monitoring.

T1566.002 — Spearphishing Link: the email contains a URL; the payload or credential harvest happens at the destination. The attacker relies on the user clicking the link and either submitting credentials or triggering a drive-by. The payload never enters the email system — it is served from web infrastructure. Key detection: URL reputation at the gateway (click-time scanning) + web proxy category filtering + DNS monitoring for new domains.

Operationally, T1566.002 is harder to defend because: (1) the payload is not in the email (no attachment sandbox), (2) the link may be clean at delivery and only become malicious later, and (3) URL rewriting by gateways can be bypassed by encoding, redirects, or phishing- as-a-service platforms that rotate infrastructure. Many modern campaigns combine both: the email has an HTML attachment (T1566.001) that opens a phishing page (T1566.002).

Q7: What does a DMARC aggregate report (rua) contain and how is it useful for defenders?

A: A DMARC aggregate report is an XML document sent daily (or per-reporting-period) from each major receiving mail server to the domain owner's rua= address. It contains, for each source IP and policy-result combination observed during the period:

  • Source IP: the sending server's IP address.
  • Message count: how many messages were seen from that IP claiming to be from your domain.
  • Policy evaluated: what DMARC disposition was applied (none/quarantine/reject) and the SPF and DKIM results.
  • Auth results: the SPF domain evaluated and its result; the DKIM domain evaluated and its result.
  • Header from: the From: header domain.

For defenders, the aggregate report answers: "Who is sending email on behalf of my domain?" This catches: (1) unauthorized senders (attackers who have not compromised your SPF record but are sending from other IPs), (2) forgotten legitimate senders (a third-party service you forgot to add to SPF), and (3) volume spikes that indicate active phishing campaigns. Parsing rua reports and alerting on new source IPs sending on your domain is one of the highest-value, lowest-cost detection investments for email security. Tools like parsedmarc, Google Postmaster Tools, and commercial DMARC management platforms automate this parsing.

Q8: How do you score phishing risk from email headers alone?

A: A weighted additive scoring model over the following signals provides a reliable risk stratification:

SignalWeightRationale
SPF fail / softfail / none / error+3Sending server not authorized by domain owner
DKIM fail+3Message not cryptographically authenticated by claimed domain
DMARC unenforced (p=none or missing)+2No enforcement even if auth fails
DKIM domain mismatch (passes but d= != From: domain)+4Signed by a different domain — high spoof signal
Reply-To domain differs from From: domain+3Classic phishing misdirection

Score interpretation:

  • 0–3: LOW — likely legitimate or minor misconfiguration.
  • 4–6: MEDIUM — investigate; may be misconfigured legitimate sender.
  • 7–10: HIGH — strong phishing indicators; quarantine recommended.
  • 11+: CRITICAL — multiple independent phishing signals; reject or isolate.

The DKIM domain mismatch carries the highest weight (+4) because it is the most specific indicator: it means someone produced a valid DKIM signature for a different domain than the one shown to the user. The only legitimate use case (shared ESP signing with their own d= domain) is becoming less common as organizations configure their own DKIM keys. In combination with DMARC unenforced, this pattern is near-definitive for a spoofing attempt.

References

  • RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email: https://tools.ietf.org/html/rfc7208
  • RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures: https://tools.ietf.org/html/rfc6376
  • RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC): https://tools.ietf.org/html/rfc7489
  • Mandiant M-Trends 2023 — Annual report on attacker initial-access vectors and dwell time: https://www.mandiant.com/m-trends (requires registration)
  • MITRE ATT&CK T1566 — Phishing (Initial Access): https://attack.mitre.org/techniques/T1566/
  • MITRE ATT&CK T1566.001 — Spearphishing Attachment: https://attack.mitre.org/techniques/T1566/001/
  • MITRE ATT&CK T1566.002 — Spearphishing Link: https://attack.mitre.org/techniques/T1566/002/
  • Google Admin Toolbox — Check MX — Public DNS record checker for SPF/DKIM/DMARC: https://toolbox.googleapps.com/apps/checkmx/
  • parsedmarc — Open-source DMARC aggregate report parser: https://github.com/domainaware/parsedmarc
  • Sysmon — Windows system monitoring tool (Sysmon EID reference): https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon