Cyber Kill Chain

// SCENARIO — using the kill chain to plan a defensive program AND to structure
// engagement reports during an authorised penetration test. We focus on detection,
// prevention, and reporting — no operational tradecraft.

// ─── STAGE 1 — RECONNAISSANCE ──────────────────────────────────
//
// What attackers do:
//   • Open-source intelligence (whois, leaked breaches, LinkedIn, Shodan)
//   • Subdomain enumeration, port scanning, banner grabbing
//   • Identify exposed admin panels, public S3 buckets, dev environments
//
// Defensive controls:
//   • Inventory exposed services — Attack Surface Management (ASM) tooling
//   • Domain monitoring — alert on new lookalike domains
//   • Reduce surface: take down stale subdomains, retire unused services
//   • Cloud configuration scanning (Prowler, ScoutSuite) for public buckets / wide-open SGs
//
// What to alert on:
//   • Unusual user-agent fingerprints scanning the network
//   • SSL handshake anomalies (Shodan, Censys)
//   • Subdomain enumeration patterns in DNS query logs
//
// What an authorised tester reports:
//   • Every exposed asset found within scope
//   • Stale records, dangling subdomains
//   • Public information that reveals architecture (e.g. job ads naming internal tools)

// ─── STAGE 2 — WEAPONIZATION ───────────────────────────────────
//
// What attackers do:
//   • Craft a malicious payload — phish, malicious document, weaponised exploit
//   • Tailor lure to gathered intel (a target's role, recent project, vendor)
//
// Defensive controls:
//   • Email gateway with content sandboxing
//   • Endpoint protection signatures + behavioural detection
//   • Office macro disable by default, AppLocker policies, ASR rules
//
// What an authorised tester reports:
//   • Phishing simulation results (with consent + clear scope)
//   • Vulnerable software discovered (CVE links + reproduction)
//   • NEVER share the actual weaponised artifact in a report; describe the class

// ─── STAGE 3 — DELIVERY ────────────────────────────────────────
//
// What attackers do:
//   • Send phishing email, drop USB, exploit a perimeter vulnerability
//   • Sometimes legitimate path (compromised vendor login, exposed SaaS)
//
// Defensive controls:
//   • Mail filtering (SPF, DKIM, DMARC enforcement)
//   • Web application firewall + DDoS protections
//   • Phishing-resistant MFA (FIDO2 / WebAuthn) — the single biggest defensive win
//   • Web isolation for risky links / attachments
//
// What to alert on:
//   • Authentication from unusual geographies / impossible travel
//   • Surge of failed logins or password spray
//   • Spike in newly-registered lookalike-domain emails delivered
//
// What an authorised tester reports:
//   • Which delivery channels were attempted (web, email, USB drop test)
//   • Click rates and reporting rates from phishing simulations
//   • Effectiveness of the email gateway (block rate per category)

// ─── STAGE 4 — EXPLOITATION ────────────────────────────────────
//
// What attackers do:
//   • Trigger the vulnerability (open the doc, run the binary, exploit the auth flaw)
//
// Defensive controls:
//   • Patch management with documented SLAs (see owasp/a06)
//   • Endpoint Detection and Response (EDR) for behavioural detection
//   • Application allowlisting (no, the user really doesn't need to run powershell from Outlook)
//   • Browser hardening + memory safety mitigations
//
// What to alert on:
//   • Process tree anomalies (Word spawning cmd.exe)
//   • Unusual library loads / DLL side-loading
//   • Memory protection failures (DEP, ASLR, CFI bypass attempts)
//
// What an authorised tester reports:
//   • Each vulnerability successfully exploited (with proof of access scope)
//   • Reproducible steps an engineer can verify
//   • DO NOT leave persistent footholds after the engagement

// ─── STAGE 5 — INSTALLATION ────────────────────────────────────
//
// What attackers do:
//   • Install backdoor / persistence mechanism — registry run keys, scheduled tasks, systemd units, cron, autostart
//
// Defensive controls:
//   • EDR persistence-mechanism detection
//   • Sysmon + log forwarding for startup item changes
//   • Hardened images that reject unexpected service installs
//   • Cloud workload protection (CWPP) for ephemeral workloads
//
// What to alert on:
//   • New scheduled tasks / cron entries on critical hosts
//   • New services or startup items in golden-image-based deployments
//   • Sudden creation of admin accounts
//
// What an authorised tester reports:
//   • Persistence techniques EVALUATED (e.g. 'would we detect a scheduled task?')
//   • Whether existing EDR rules covered the technique
//   • Always clean up after the engagement — remove anything installed

// ─── STAGE 6 — COMMAND & CONTROL (C2) ──────────────────────────
//
// What attackers do:
//   • Establish an outbound channel for instructions (HTTPS, DNS tunnelling, legitimate cloud services)
//
// Defensive controls:
//   • Egress filtering — block direct outbound from servers; route via a proxy that logs everything
//   • DNS sinkholing of known C2 domains
//   • TLS inspection on critical segments (consent + privacy review)
//   • Anomaly detection on beaconing patterns (jittered intervals, low-bandwidth connections)
//
// What to alert on:
//   • Persistent low-volume connections to unfamiliar IPs
//   • Domain generation algorithm (DGA) lookups in DNS
//   • Non-browser processes initiating HTTPS connections
//   • DNS over HTTPS (DoH) from a server that shouldn't browse the web
//
// What an authorised tester reports:
//   • Detectability of common C2 patterns within the environment
//   • Time-to-detect from first beacon to first SOC ticket
//   • Coverage gaps (e.g. EDR sees only Windows, but the Linux hosts have no telemetry)

// ─── STAGE 7 — ACTIONS ON OBJECTIVES ───────────────────────────
//
// What attackers do:
//   • Move laterally, escalate privileges, find target data, exfiltrate, encrypt / destroy / ransom
//
// Defensive controls:
//   • Network segmentation — flat networks help attackers more than they help operators
//   • Privileged Access Management (PAM) with session recording
//   • Just-in-time access for production
//   • Data Loss Prevention (DLP) on egress
//   • Backups: tested + offline + immutable
//
// What to alert on:
//   • Mass file accesses or unusual data egress sizes
//   • Privilege escalation (kerberoasting attempts, GPO changes, IAM policy attaches)
//   • Internal RDP / SSH between hosts that don't normally communicate
//   • New admin sessions outside business hours
//
// What an authorised tester reports:
//   • Each objective reached (in-scope only)
//   • Time-to-detect at each stage
//   • Recommendations mapped to MITRE ATT&CK techniques
//   • DO NOT exfiltrate real user data; use canary records or synthetic data

// ─── RoE NON-NEGOTIABLES (in every engagement) ─────────────────
//
//   1. Written scope, signed by a customer authority — endpoints, accounts, time windows
//   2. Clearly listed out-of-scope systems and data classes
//   3. Escalation path for: critical finding, accidental access, customer-impacting issue
//   4. Reporting checklist — what evidence you'll collect, how it's stored, when it's destroyed
//   5. Stop conditions — when you must pause and notify (e.g. service degradation)
//   6. Communication channels — daily checkin, ad-hoc escalation
//   7. Data handling — no real user data exfiltrated; canaries / synthetic data only
//   8. Post-engagement cleanup — every test artifact removed, accounts disabled, persistence undone

// ─── MAPPING TO DETECTION ──────────────────────────────────────
//
// Use the kill chain to organise a detection coverage matrix:
//   • Each stage × each MITRE ATT&CK technique
//   • Mark which logs / EDR rules / SIEM detections cover each cell
//   • Track time-to-detect for known scenarios
//   • Tabletop exercise: 'attacker reaches stage X — what fires?'
//
// Gaps highlight where to invest in tooling, rules, or training.

// ─── REPORT STRUCTURE FOR AN AUTHORISED ENGAGEMENT ─────────────
//
//   Executive summary
//       Scope, dates, accounts, stop conditions hit (or not)
//       Top 3 findings, top 3 recommendations
//   Methodology
//       What you tested, what was out of scope, what you intentionally avoided
//   Detection coverage by kill chain stage
//       What the SOC saw vs what slipped through
//   Findings
//       Per finding: severity, location, reproduction, remediation, ATT&CK mapping
//   Evidence
//       Screenshots / log excerpts, REDACTED where they include PII
//   Cleanup
//       List of every artifact created / disabled / removed at engagement close
//
// Goal: hand the customer a document they can hand to engineering on Monday morning.

// ─── COMMON BUGS / MISTAKES ────────────────────────────────────
//
// • Testing outside the RoE — even one out-of-scope action voids the engagement
// • Sharing weaponised artifacts in the report — refer to CVE / class instead
// • Leaving accounts, scheduled tasks, or shells behind
// • Reading real user data 'out of curiosity' — instant trust failure with the customer
// • Mapping every finding to the kill chain without ATT&CK technique IDs — defenders need both
// • Stopping at exploitation — defenders need to know detection coverage at LATER stages too
// • Treating the kill chain as the only model — pair with MITRE ATT&CK, Diamond Model, Unified Kill Chain

# Lockheed Martin's 7-step model:
#   Recon → Weaponise → Deliver → Exploit → Install → C2 → Actions on Objective
# Useful for tabletop exercises and detection coverage maps.