Security/Attack/Chain

• Attack Chain

  • An attack chain (also called an attack lifecycle or kill chain) is the ordered sequence of steps an adversary takes to compromise and operate inside an environment—from first reconnaissance through impact.
  • Security teams use this framing to decide where to detect, contain, or disrupt an attack, and to align controls and playbooks to observable behavior.
  • It is conceptually similar to the Lockheed Martin Cyber Kill Chain and overlaps with MITRE ATT&CK (ATT&CK organizes tactics and techniques; kill-chain models emphasize ordering and breakpoints).

  • Typical stages (generic pattern)

    • 1. Reconnaissance

      • The attacker gathers information about the target organization and its attack surface.
      • Examples:
        • Collecting employee or role emails from public sources
        • Scanning external IP ranges and exposed services
        • Reviewing leaked credentials, code, or metadata for foothold hints

    • 2. Initial Access

      • The attacker gains a foothold in the environment.
      • Examples:
        • Phishing or social engineering
        • Exploiting vulnerable internet-facing applications
        • Stolen or guessed credentials (including VPN or IdP abuse)

    • 3. Execution

      • Malicious code runs on a compromised system.
      • Examples:
        • Malicious attachments or documents
        • Scripting runtimes (e.g. PowerShell) used as loaders
        • Droppers that fetch second-stage payloads

    • 4. Persistence

      • The attacker keeps access across reboots, credential rotation, or short-term cleanup.
      • Examples:
        • New local or cloud accounts
        • Scheduled tasks, services, or cron jobs
        • SSH keys, WMI subscriptions, or agent implants

    • 5. Privilege Escalation

      • The attacker obtains higher privileges than the initial foothold.
      • Examples:
        • Local privilege-escalation exploits
        • Credential theft from memory or stores
        • Abuse of tokens, Kerberos, or cloud IAM bindings

    • 6. Lateral Movement

      • The attacker moves from system to system inside the estate.
      • Examples:
        • Authenticated access to servers or workstations via stolen creds
        • Remote admin tools and remote execution
        • Pivoting through jump hosts, VDI, or trust relationships

    • 7. Data access / exfiltration

      • The attacker reaches valuable data or prepares to remove it.
      • Examples:
        • Access to regulated or sensitive data (PII, PHI, financial records)
        • Intellectual property, source code, or model weights
        • Staging archives before exfiltration over allowed channels

    • 8. Impact

      • The adversary achieves their end goal or visible harm.
      • Examples:
        • Large-scale data theft
        • Ransomware or wiper deployment
        • Sabotage of backups or critical services

  • Why defenders use attack-chain thinking

    • Train analysts to recognize sequences of behavior, not isolated alerts.
    • Map detections and telemetry to stages so gaps are visible.
    • Design defense in depth so failure at one layer does not imply total loss.
    • Structure incident response: contain footholds, cut persistence, then scope blast radius.

  • Stage-to-detection mapping (examples)

    • Initial access: email security, phishing controls, secure remote access posture
    • Execution: EDR, script control, application control
    • Lateral movement: authentication anomalies, tiered-admin hygiene, network segmentation signals
    • Exfiltration: DLP, egress monitoring, SaaS audit logs, large transfer baselines

  • Why it matters in practice

    • Many organizations combine open collaboration (partners, contractors, BYOD), heterogeneous systems, and high-value data, which widens the attack surface and rewards patient adversaries.
    • Attack-chain framing helps defenders interrupt campaigns earlier—before impact—by prioritizing breakpoints that match their architecture and risk.

  • Related: shipped-software defensive tooling

    • For product security classes (composition vs static vs dynamic testing vs dependency bots), see Security/DevSecOps/Taxonomy—orthogonal to kill-chain SOC framing above, but useful when mapping CVE intake to engineering workflows.