C2 in the Cyber Kill Chain
Understand "command and control" and how the CKC cuts it off
To understand the role of command and control in a cyber attack, it's helpful to start with the step that immediately precedes it—installation (handily, that’s exactly what we discussed last week). When someone talks about a cyber attack moving beyond just probing or scanning, they’re often referring to the attacker getting something persistent inside the target’s system.
Installation isn’t the flashiest part of a cyber attack. It doesn’t always get the headlines, and you rarely hear about it outside of technical postmortems. But it’s one of the most important stages in the Cyber Kill Chain, and for defenders, it’s a window of opportunity.
Understanding how attackers approach installation gives you a chance to detect and disrupt them before they do serious damage. It’s where malware stops being hypothetical and starts becoming a resident in your network. Whether it’s a nation-state slipping in a silent backdoor or a low-level criminal group pushing commodity malware, the goal is the same: get in, stay in, and go unnoticed.
If you’re building a defensive strategy, pay attention to installation. It’s one of the points where you still have a decent shot at stopping an intrusion before it turns into a full-blown breach. You might not stop the email from landing in the inbox, and you might not prevent the exploit from firing, but if you catch the installation and kill the process before it establishes persistence, you can break the chain—and that makes all the difference.1
That’s what installation is all about. At this point, the attacker already has access. They’ve exploited a vulnerability, gotten past defences, and now they want to make sure they can stay in the environment. They might install malware, a remote access trojan, or something custom-built. This stage is crucial because it gives them a foothold—a reliable way back in, without having to start the process all over again.
Installation doesn’t need to be flashy. It can be as quiet as dropping a single binary or tweaking a registry key. Whatever the method, the idea is to make the access stick. And once that’s in place, the attacker can move into what many would call the real core of the operation: command and control.
Command and Control (C2) in the CKC Framework
In the Cyber Kill Chain, command and control (C2) follows installation and plays a key role in how the attacker interacts with the compromised system. The CKC breaks an attack into a series of stages—each one giving defenders a chance to detect, disrupt, or respond. C2 marks the point where the attacker starts operating inside the environment with some level of stability and consistency.
At its core, C2 is about communication. The attacker needs to send instructions to their malware or implant and get data or feedback in return. That might mean using a server on the internet to issue commands. It might mean using email, cloud services, DNS, or even social media. The attacker sets up a channel that lets them talk to the compromised system, and ideally, do so without raising alarms.
Setting up the C2
From the CKC’s perspective, this is a big moment. Up until this point, the attacker might be working through fairly standard tools and infrastructure—scanning IPs, sending phishing emails, exploiting vulnerabilities. But once they’ve installed something and it starts calling back to them, that’s when they have real operational capability.
This is also where things get a bit tricky for defenders. C2 traffic doesn’t always look malicious. It can be buried in HTTPS, hidden in encrypted DNS queries, or tunneled through everyday services. Attackers know that defenders often have good visibility at the perimeter but less clarity on what’s normal and what’s not in outbound traffic. That’s what makes this stage both dangerous and revealing—it opens the door to activity, but also provides an opportunity for detection.
Understanding different modes of C2
C2 can be centralised or decentralised. In a centralised setup, compromised systems phone home to a single command server. It’s easier to manage but more vulnerable—take down the server, and the whole operation could fall apart. Decentralised C2, on the other hand, uses peer-to-peer networks or multiple redundant channels, making it harder to shut down. There are even cases where attackers don’t maintain active control, but pre-program tasks to execute without needing real-time communication—though that’s more the exception than the rule.
The takeaway from the CKC’s model is that C2 isn’t just another step. It’s the attacker establishing presence. It’s also a turning point. After this, they can begin their real goals—data theft, lateral movement, and sabotage. And from a defence standpoint, it’s a critical moment to intervene before those objectives are met.
Real-World Examples of C2 in Action
To see how this plays out in real attacks, it helps to look at some well-known cases. Not all of them follow the same pattern, but most involve some form of C2 that ties back to the ideas laid out in the CKC.
Playing out in real life
Consider the 2015 attack on the Ukrainian power grid. The attackers, widely attributed to a state-backed group, didn’t just get into the network. They installed malware that allowed them to maintain access and control the environment remotely. Their C2 infrastructure included VPNs and remote desktop tools, giving them hands-on-keyboard access to systems that controlled critical infrastructure. Installation let them in; C2 let them operate—and ultimately, shut the lights off for thousands of people.
Or take the case of the SolarWinds breach. Here, the attackers compromised a software update mechanism and installed a backdoor into thousands of organisations’ environments. The malware they deployed had built-in C2 capabilities, reaching out to attacker-controlled servers and awaiting instructions. It blended in well with legitimate traffic and used domain generation algorithms to avoid easy blacklisting. This allowed the attackers to quietly assess and exploit multiple victims, some of them high-value targets, for months before discovery.
Another example is the use of C2 in ransomware attacks. In many high-profile ransomware campaigns, the initial infection happens through phishing or vulnerable RDP services. But the real impact doesn’t come until the malware has called home, fetched encryption keys, or received instructions on how to spread. Some ransomware variants even wait for a specific C2 signal before executing, allowing attackers to time their campaigns for maximum disruption.
What these examples show is that C2 isn’t just a background process. It’s the operational heartbeat of the attack. Without it, many campaigns would fall apart or be limited in scope. It’s also a stage where the attacker often becomes visible, especially if they make mistakes or if the defenders are monitoring outbound traffic effectively.
Dealing with the C2 Problem
So how do defenders handle this? The challenge is that C2 traffic is designed to be stealthy. Attackers spend a lot of time making sure their communication blends in. But there are ways to spot and disrupt it.
Taking the Six-Step Plan
The first is visibility. If defenders can’t see what’s leaving their environment, they’re in the dark. Having good telemetry—on DNS, HTTP, SSL traffic, and more—goes a long way. It’s not about blocking everything, but about understanding what’s normal. When something unusual starts phoning home to a server in a country you’ve never done business with, that’s a signal worth looking into.
Behavioural analytics help too. Attackers often rely on specific patterns—regular beaconing, odd user-agent strings, or timing that doesn’t match regular business hours. Tools that can flag these behaviours make it easier to separate benign traffic from potential C2 activity.
Another approach is deception. Things like honeypots or sinkholes can attract and trap C2 traffic. If malware tries to connect to a domain that’s been redirected to a controlled server, defenders can gather intel and potentially identify compromised machines.
Network segmentation and least privilege access also play a role. If an attacker gets a foothold but can’t move laterally or reach out to the internet freely, their options are limited. Even if they establish C2, it might not give them much control.
Finally, there’s threat intelligence. Knowing how certain groups operate—what domains they use, what IPs they favour, what tools they rely on—can help block or detect C2 before it becomes a bigger issue. This isn’t a silver bullet, but it adds another layer to the defence strategy.
Of course, attackers adapt. When one method of C2 gets blocked or burned, forcing them to switch. That’s why the focus shouldn’t just be on blocking known threats, but on building resilience and monitoring for signs of compromise. The CKC gives defenders a mental model to work from, and the C2 stage is a key piece of that.
Thinking Forward
Command and control is where the attacker stops knocking and starts acting. It’s the point in the Cyber Kill Chain where access turns into operation. For defenders, understanding how C2 works—how it’s built, hidden, and used—is essential to spotting and stopping attacks before real damage happens.
The installation phase gives the attacker the door, but C2 gives them the key. By focusing attention on this part of the chain—watching outbound connections, understanding behaviour, and limiting what internal systems can do—defenders stand a much better chance of disrupting the adversary before they achieve their goals.
Cyber defence isn’t about stopping every attack at the perimeter. Sometimes the first few stages slip through. But if you can catch them at C2, you still have time to contain and respond. The earlier in the chain, the better—but every stage is a chance to detect and defend. In a way, C2 is both a risk and an opportunity. It's the moment the attacker opens a line of communication—and it might be the best moment to catch them in the act.