Episode 43 — Analyze intrusions through the kill chain lens
In Episode 43 — Analyze intrusions through the kill chain lens, we are going to use a simple model to make complex intrusions easier to understand and easier to stop. When an investigation is busy, it is common to get stuck staring at the loudest alert, the most damaged system, or the final impact, and that habit can hide what truly mattered earlier in the timeline. A good model gives you a way to organize what you saw and what you did not see, without needing perfect data or perfect memory. The Lockheed Martin Cyber Kill Chain gives you that structure by describing attacker progression as a sequence of stages that depend on each other. When you learn to think in this sequence, you gain a practical advantage, because every stage is an opportunity to detect, disrupt, or reduce impact before the attacker reaches their objective.
The kill chain describes seven steps an attacker must take to be successful, and the reason it is so useful is that it treats an intrusion as a process rather than as a single event. Attackers do not magically arrive at data access or disruption. They work through a chain of actions where early decisions shape later options. In this model, an attacker begins by learning about the target, then preparing capabilities, delivering them, exploiting weaknesses, installing a foothold, establishing Command and Control (C 2), and finally acting on objectives. You do not have to memorize these stages as a chant to gain value. You have to understand that each stage creates artifacts, and those artifacts are what you can observe. The model also implies that if you interrupt one stage, later stages become harder or impossible, which is exactly how defenders create leverage.
To use the model during analysis, you map what you observed to stages such as reconnaissance, delivery, and exploitation, and you do that mapping with discipline rather than with guesswork. Reconnaissance might show up as scanning, enumeration, or unusual attention to public-facing services. Delivery might show up as a malicious attachment, a drive-by download, or a file arriving through a channel that does not match normal business flow. Exploitation might show up as process behaviors that indicate a vulnerability was triggered, or as unusual application crashes followed by spawned processes. This mapping is not about forcing every artifact into a bin, but about asking where it most plausibly fits in the progression. When you can place events into stages, you also start seeing gaps, such as why you see later stage behavior without clear evidence of earlier steps. Those gaps matter because they often point to logging blind spots or alternate access paths.
A common investigation failure is focusing only on the final stage of an attack and ignoring how it started, especially when the final stage is painful. When systems are encrypted, data is stolen, or core services are disrupted, the instinct is to concentrate on recovery and containment, and those are absolutely important. The problem is that if you do not also understand how the attacker entered and progressed, you are likely to leave the door open for re-entry or repeat the same detection failure again. The kill chain lens forces you to look backward, not as an academic exercise, but as a practical one. If you can identify the earliest observable stage, you can strengthen the part of your defenses that would have prevented the incident entirely. Over time, this is how organizations move from repeatedly cleaning up to actually reducing intrusion frequency.
One of the strongest values of the kill chain is that it helps you identify opportunities to break the chain as early as possible. Early interruption reduces both cost and uncertainty, because it is easier to stop delivery than to clean up after installation, and it is easier to stop exploitation than to unwind C 2 and lateral movement. Breaking the chain early does not always mean blocking everything. It can mean increasing friction, raising detection fidelity, or limiting privileges so exploitation does not lead to meaningful installation. When you use the kill chain, you naturally ask, where did we first have a chance to stop this, and what would have changed the outcome. That question turns post-incident analysis into a plan for improvement rather than a narrative of regret. It also aligns teams, because it gives everyone a shared way to discuss prevention without arguing about which single alert mattered most.
Imagine you spot an attacker at the delivery phase and stop them before they can exploit anything. In that moment, the incident looks small, maybe even boring, because the attacker never gets traction. But from a risk standpoint, that is a major win, and the kill chain helps you recognize why. Delivery controls and detections can include email filtering, web content controls, attachment detonation, and user behavior signals that surface suspicious interaction early. If you stop delivery reliably, you reduce the need to fight at later stages where evidence is noisier and the attacker has more options. This also improves confidence, because early stage artifacts are often clearer and less ambiguous than late stage effects, which can blend with legitimate activity. The model reminds you that stopping an intrusion early is not luck, it is a deliberate capability. It also reminds you to measure and strengthen that capability.
Another way to hold this concept in your head is to think of the kill chain as a series of connected links that can be broken. Each link is connected to the next, and each link depends on conditions that you can influence, such as visibility, access control, segmentation, and policy enforcement. A broken link does not always mean the attacker disappears instantly. It can mean the attacker must change tactics, spend more time, or take higher-risk actions that are easier to detect. This is a practical way to think about defensive advantage, because you do not need perfect prevention to create meaningful disruption. When you force the attacker to work harder, you create more opportunities to see them. The kill chain lens also helps you avoid the trap of believing the attacker is unstoppable, because it shows you specific places where you can interfere.
When you focus specifically on the C 2 phase, you can predict the types of technical indicators you would expect to see, and that makes detection and investigation more structured. C 2 often includes outbound connections to external infrastructure, sometimes with periodic beaconing, sometimes with interactive sessions, and often with encryption or protocol mimicry. You might expect unusual Domain Name System query patterns, repeated contact with rare domains, connections to unusual ports, or connections that occur with a regular cadence that does not match normal application behavior. You might also expect process-to-network relationships that are inconsistent with baseline, such as a document viewer or a scripting host initiating outbound sessions. In some cases, you see fallback behavior, where the malware cycles through multiple domains or IP addresses until it finds a reachable endpoint. When you treat these as expected C 2 signals rather than as random anomalies, you become faster at recognizing the stage and predicting what the attacker is trying to enable next.
Using this model consistently also helps you evaluate which parts of your defenses are strong or weak today, because you can compare what you observed to what you would have expected to observe. If you routinely detect in the later stages, such as installation and actions on objectives, but you rarely see evidence of reconnaissance and delivery, that suggests either those early stages are invisible or they are not being monitored well. Conversely, if you see reconnaissance frequently but stop delivery often, that suggests your early controls are effective, but you still need to watch for alternate delivery paths. The kill chain lets you frame this as coverage and capability across stages rather than as isolated tool performance. This is important because many organizations have strong coverage in a few phases and weak coverage in others, and attackers naturally exploit the weak spots. A stage-based review turns vague concerns into a clear set of defensive priorities.
Another practical benefit is that the kill chain can organize your final reports into a clear narrative that is easy to follow. Instead of writing a report that reads like a pile of timestamps, you can present events in a progression that mirrors attacker logic. That structure helps technical readers validate the story, because they can see whether the sequence makes sense, and it helps nontechnical readers understand why certain events mattered. A kill chain narrative also makes uncertainty easier to state, because you can say which phases are well supported by evidence and which phases are inferred due to gaps. This improves credibility because you are not pretending to know everything. You are showing what you know, where it fits, and what remains unclear. A clear structure also improves handoffs because other analysts can pick up the story and continue work without rebuilding it from scratch.
The model naturally pushes you to focus on early stages to achieve more proactive and effective defense, because early stages are where you can prevent rather than recover. Proactive defense does not mean predicting the future perfectly. It means recognizing patterns early, reducing exposure, and building detection that surfaces attacker preparation before impact occurs. When you concentrate on reconnaissance, weaponization, and delivery, you start to invest in controls like external attack surface monitoring, phishing resistance, vulnerability management, and safer default configurations. These investments often produce quiet wins, where intrusions never fully form, and those wins can be hard to appreciate without a model that explains what you prevented. The kill chain provides that explanation by making early disruption visible as success. Over time, focusing earlier also reduces the emotional intensity of response work, because fewer incidents reach the phases that cause severe operational pain.
To use the kill chain effectively, you also need to verify that your logging covers every stage from start to final actions, because a model is only as useful as your ability to observe reality. Logging coverage includes visibility into inbound scanning and enumeration, delivery vectors like email and web access, exploitation artifacts such as process creation and application telemetry, installation artifacts such as persistence mechanisms, and outbound communication for C 2. It also includes visibility into actions on objectives, such as unusual access to sensitive data stores, encryption activity, or destructive changes. If you cannot observe a stage, you should treat that as a known limitation, not as an absence of activity. Attackers do not skip stages because you do not log them. When you map coverage, you identify where evidence is missing and where additional telemetry would have changed the investigation. That is how you turn the model into a roadmap for improving visibility rather than a diagram you admire.
Now practice the mental act of placing separate technical alerts into their correct bins within the seven-stage model, because this is where the lens becomes operational. Suppose you see an alert about repeated inbound scanning against an exposed service, and you treat that as reconnaissance because it reflects target discovery and probing. Next, you see an alert that a user received a suspicious attachment that was blocked, and you map that to delivery because the payload attempted to reach the user. Then you see an endpoint alert where an application spawned an unexpected scripting process immediately after opening a document, and you map that to exploitation because it suggests a vulnerability or macro-driven execution chain. You also see a persistence-related alert where a new scheduled task was created shortly after the suspicious execution, and you place that in installation because it represents a foothold mechanism. Finally, you see outbound connections with a steady beacon pattern from the same host to a rare external domain, and you place that in C 2 because it suggests remote control enablement. Practicing this sort of mapping trains you to see progression rather than isolated flashes of activity.
Once you can map events this way, you can apply the same framework to a full incident and see the story with much less effort. A well-mapped incident tells you where the attacker entered, how they advanced, where they established durability, and where they attempted to achieve objectives. It also tells you which phase offered the earliest realistic interception point, which is often the most valuable lesson. This approach also improves team coordination because responders, threat intelligence analysts, and detection engineers can talk about the same incident using the same stage language. When a detection engineer hears that you lacked visibility in the delivery phase, they know what to improve. When a leader hears that you stopped activity before C 2 stabilized, they can understand that the response was timely. The model becomes a shared language for both technical and strategic learning.
Conclusion: The kill chain maps the path so place your last incident into this framework. When you take an investigation and organize it through the seven-stage progression, you get a clearer view of what happened, what you observed, and what you missed. Mapping events to stages helps you avoid the trap of focusing only on the final impact and instead pushes you to strengthen early interception points where damage is prevented rather than managed. It also gives you a clean narrative structure for reporting, and it turns logging gaps into specific improvement targets rather than vague concerns. Take your most recent incident, map the key artifacts into the kill chain stages, and note where the earliest break in the chain could have occurred, because that is where your next defensive gains are most likely to come from.
