Cyber Kill Chain Analysis: Evidence, Gaps, and Defensive Opportunities
Cyber Kill Chain analysis helps an investigator ask where an intrusion became visible and where a defender could have interrupted it. The useful result is a set of supported assessments and testable defensive actions. A fully colored chain can conceal more uncertainty than it explains.
This guide applies Lockheed Martin’s seven-stage model to the same fictional hybrid incident used in Intrusion Analysis: From Alert to Defensible Findings. Use that investigation method to establish evidence, scope, and competing explanations before drawing conclusions from stage labels.
Simulation notice: Case SIM-2026-001 concerns Example Services, a fictional company. Every person, system, log, contextual statement, and conclusion is invented. It describes neither a real engagement nor my employer. The analytical snapshot is October 14, 2026, 16:00 UTC. A populated example records open questions; it does not declare the incident closed.
Download the Cyber Kill Chain workbooks
- Download the blank Cyber Kill Chain analysis workbook (XLSX)
- Download the completed simulated Cyber Kill Chain analysis (XLSX)
Each file has 14 worksheets covering the framework, stage assessments, evidence, timeline, indicators and ATT&CK, hypotheses and gaps, defensive opportunities, validation, actions, and findings. The template includes seven stage prompts and all 42 stage/course combinations. It contains no simulated incident facts or implied test results.
Use the original framework precisely
The Cyber Kill Chain framework is attributed to Lockheed Martin. Its original intelligence-driven defense paper is the foundational reference. Direct retrieval of those Lockheed Martin materials was restricted during this review; the accessible AWS framework discussion and original courses-of-action matrix supports the seven-stage and six-course structure used here. The interpretations below are this guide’s analysis of synthetic records.
| Original stage | Analytical purpose |
|---|---|
| Reconnaissance | Understand target selection and preparatory research. |
| Weaponization | Examine preparation of the exploit/payload combination. |
| Delivery | Identify how the prepared mechanism reached the target. |
| Exploitation | Examine the trigger enabling execution through a vulnerability or interaction. |
| Installation | Identify establishment of a persistent foothold or implant. |
| Command and Control | Examine the adversary’s communication and control channel. |
| Actions on Objectives | Assess activity toward the intended effects. |
These are adversary stages. Incident response organizes the defender’s work, while ATT&CK describes adversary behavior at a different granularity. They are complementary views with no universal one-to-one mapping. A successful login is not automatically an observed exploit, and cloud access need not leave a delivered malware artifact.
AWS explicitly discusses modifications for cloud environments. Those modifications are adaptations, not additional original Lockheed Martin stages. This workbook retains the original seven labels and explains where the identity/cloud evidence does not fit them neatly.
Keep visibility, outcome, and confidence separate
Stage Overview records three independent assessments:
- Evidence state: Observed, Inferred, Unknown, Not applicable, or Not assessed.
- Assessed outcome: Attempted, Succeeded, Blocked, Unknown, or Not assessed, scoped to a stated behavior.
- Confidence: Low, Moderate, High, or Not assessed, with a rationale for the precise claim.
Observed means a relevant artifact or operation is present. It does not mean the adversary’s overall objective succeeded. Unknown means the evidence cannot answer the question. Not applicable needs a case-specific reason; it must not substitute for missing logs. An empty template begins Not assessed.
Keep supporting and contradictory records in Stage Evidence and Gaps and Hypotheses. The example’s first four stages remain unknown, Installation is observed, C2 is inferred, and Actions on Objectives is observed with an unresolved overall outcome. Two observed stages out of seven is a description of recorded evidence, not a coverage score or a probability of compromise.
Analyze the case stage by stage
Reconnaissance: unknown
The pack contains no adversary target-research records. Ordinary internal activity on October 12 supplies context, not proof of pre-intrusion reconnaissance. Neither later report listing nor a network connection establishes what the adversary knew before access.
Leave both evidence state and outcome Unknown, with confidence Not assessed. Request relevant external intelligence or earlier activity only when it can answer a defined question. Record the missing preparatory visibility; do not invent a research narrative to complete the chain.
Weaponization: unknown
No payload preparation, exploit assembly, or delivery artifact is provided. EVT-023 records PowerShell execution referencing ReportCache.ps1, but the script content and its preparation history are absent. The name of a script does not establish a malware family or a weaponization mechanism.
Keep this stage Unknown. A recovered script, build artifact, or reliably linked delivery package could change the assessment. Until then, unsupported assumptions about malware preparation would contaminate later conclusions.
Delivery: unknown
Identity acceptance at EVT-017, assertion issuance at EVT-018, and the VPN session at EVT-019 establish access-related observations. They do not show a phishing message, delivered exploit, stolen-cookie origin, or any other original delivery path.
The simulated owner denial in CTX-001 supports unauthorized identity use, but it does not resolve how access was obtained. Keep password compromise and existing-session reuse as alternatives in HYP-003; seek provider authentication context and WS-014 artifacts. Delivery remains Unknown.
Exploitation: unknown
The identity-to-VPN-to-RDP sequence links IC-77, ASSERT-77, V-77, assigned address 10.20.0.77, and destination logon L-712. That supports a reconstruction of access. It does not establish a software vulnerability, CVE, or MFA bypass.
Apply T1078, Valid Accounts and T1021.001, Remote Desktop Protocol with their documented procedure rationale in Indicators and ATT&CK. Retain the original-stage exploitation question as Unknown. This is a useful limit of a malware-oriented stage model when analyzing identity misuse.
Installation: observed; scoped outcome succeeded; high confidence
EVT-024 records registration of ReportCache, and EVT-025 records its execution. CTX-002 distinguishes it from the authorized PatchWindow maintenance change. The combination supports an unapproved user-logon persistence mechanism, also mapped to T1053.005, Scheduled Task.
The approved maintenance alternative was tested and refuted rather than discarded because its name looked harmless. Preserve EVT-011–EVT-015 and the change context alongside the suspicious records. Task registration at 05:12 with a −04:00 offset normalizes to 09:10 UTC after the documented −120-second correction in CTX-003.
Succeeded here means the scoped task registered and executed. It does not mean a complete implant inventory exists, that every persistence location was examined, or that the task reveals the original entry mechanism. Memory and workstation gaps remain relevant.
Command and Control: inferred; outcome unknown; low confidence
EVT-029 links a DNS lookup for sync.example.test to 192.0.2.88; EVT-030 records a TLS connection to that endpoint. This is a candidate control channel for investigation. Process attribution, payload content, and a demonstrated command/response relationship are absent.
Ordinary application traffic remains an alternative. Label C2 Inferred with Low confidence and outcome Unknown. Obtain process-to-connection context, available proxy/network records, and appropriate content evidence. Do not turn a destination address into a confirmed adversary-controlled service merely because it appears next to suspicious host activity.
Actions on Objectives: observed; overall outcome unknown; moderate confidence
Local access and staging appear in EVT-026–EVT-028; the archive procedure supports T1560.001, Archive via Utility. Cloud session C-88 links back to IC-77, and three distinct cloud object downloads at EVT-034–EVT-036 support T1530, Data from Cloud Storage.
The cloud operations total 4,407,296 service-recorded bytes. The local archive is 4,401,392 bytes. They are different measurements with no proved content equivalence. The 31-object listing, 86,000-byte TLS connection, and VPN aggregate counters do not establish 31 stolen files or a complete external transfer.
Collection-related activity is observed, while the final recipient, full receiving-device completion, total exposure, and ultimate adversary objective remain unknown. The egress gap from 09:30 to 10:15 UTC further limits the assessment. Preserve these limits in Findings Summary, not only in a footnote.
Reconstruct sequences rather than forcing a straight line
Chain Timeline keeps all 48 events, including ordinary activity, unmapped context, and containment. It uses sequence/pivot identifiers to let an investigator group a meaningful run while retaining event order and source pointers. Stage Evidence supports several records per stage and alternative interpretations.
In a larger case, create separate sequence identifiers when evidence supports a new host, identity pivot, or intrusion run. Record the join that relates them and any competing explanation. Do not draw a new seven-stage chain merely because activity spans a second system, and do not use stage order as proof that one event caused another. Keep temporal uncertainty and unassigned activity visible.
Turn stages into defensive opportunities
Defensive Opportunities contains the original six course categories across all seven stages: Detect, Deny, Disrupt, Degrade, Deceive, and Destroy. Review all 42 combinations; applicability and evidence matter more than filling every row with a product name. Each row records the proposed or existing control, prerequisites, expected effect, owner, validation reference, and state.
In this guide, detect means reveal activity; deny prevents the relevant access or action; disrupt interrupts an active path; degrade reduces its effectiveness; deceive introduces controlled misleading opportunities; destroy removes an adversary capability within authorized defensive scope. The last category does not imply authority to interfere with outside infrastructure.
For the unknown preparation stages, an intelligence or collection requirement may be the appropriate result. Insufficient visibility is different from a validated defense. Later observed behavior supports more concrete proposals:
| Observed concern | Defensive work and validation |
|---|---|
| Identity linked to VPN and RDP | Correlate session/assertion, assignment window, destination logon, and relevant policy context. Expected joins, telemetry completeness, timing tolerance, and approved benign access. |
| Unapproved task registration | Compare task action, principal, trigger, and authorization context with approved changes. A known unapproved task and a PatchWindow benign comparison. |
| Possible external communication | Improve process/network attribution and recover egress coverage. Known test traffic, sensor coverage checks, and content/byte semantics. |
| Continued cloud access after VPN ends | Restrict the relevant identity/grants and validate cloud session behavior. Scoped post-restriction requests, expected denial, and alternate-path review. |
| Collected report content | Review permissions and data-event visibility for the relevant population. Authorized test objects, least-privilege expectations, and observable access outcomes. |
These are candidate controls and investigation steps, not claims that deploying a named tool would have prevented this incident. ATT&CK mapping can guide a test hypothesis but does not establish that the test has run or that a control detects the whole technique.
Validate the effect, then record the residual risk
Control Validation separates method, expected result, actual result, evidence, verdict, date, and limitations. A planned test has verdict Not run. Passed and Failed require actual results and evidence for a stated scope.
VAL-001 inspects the sampled refresh and cloud denials at EVT-042 and EVT-043 after EVT-041. VAL-002 inspects the isolation/task state recorded at EVT-044. Their Passed verdicts describe synthetic, evidence-limited observations. They do not establish that every credential, session, or persistence mechanism was removed. VAL-003, the proposed egress-detection test, remains Not run.
Use Action Tracker for owners, priorities, due dates, dependencies, and completion criteria. At the fixed snapshot, four actions remain open and one is overdue. A service-health response at EVT-048 does not close the incident. Broader persistence review, acquisition questions, recipient context, recovery acceptance, and explicit closure authority still matter.
Work with the files
Start with the completed example to trace a finding to its stage evidence and then to the manifest’s source pointer. Use Framework Reference and References and Lists for definitions, confidence, and editable workflow lists. Use the separate blank template for a real incident and keep it in an approved private workspace.
Set the case ID and UTC analysis date on Case Overview. Add rows inside the native tables or press Tab at the final cell; confirm formulas, filters, validation, and formatting extend. If your application does not autofill them, copy the preceding table row and replace its inputs. Validate the summary after editing. Missing type/state counters identify incomplete action records; overdue work uses the explicit snapshot rather than today’s clock.
The files contain ordinary formulas and no macros or external workbook connections. Recalculation was checked on disposable edited copies in headless LibreOffice; Microsoft Excel native open/save remains unverified. Wide working records print in column groups with repeated IDs. Select useful sheets and preview the result after adding notes rather than shrinking the entire workbook onto one page.
Download the shared synthetic evidence
Download the shared synthetic evidence pack (ZIP)
Extract the ZIP beside the workbook. It creates an evidence folder containing eight files:
README.txt: instructions and the normalized schema.manifest.json: source hashes, event IDs and pointers, and the inventedCTX-records.- Six simulated JSON logs:
identity.json,vpn.json,windows-security.json,endpoint.json,network.json, andcloud-audit.json.
The manifest’s SHA-256 hashes check the six source files for fixture consistency, not real-world evidence authenticity. The manifest does not hash itself. These are the same shared evidence files used by the intrusion analysis workbook.
Return to the intrusion analysis guide and investigation workbook for evidence handling, hypothesis testing, scope, impact accounting, and a defensible findings narrative.