Command & Control as the Key to Data Leak Investigation

In the overwhelming majority of cases, systemic breaches are an ongoing process, controlled from the outside. And the key to investigation, minimizing damage, and building defense lies in detecting the Command & Control (C2) infrastructure. Without understanding how C2 works, a Security Operations Center (SOC) becomes a firefighting team putting out sparks but unable to see the fire itself.

In this article, we will explore why C2 is not just a "virus," but an architectural principle of modern attacks, and how to build an investigation around this concept.

External Control

A one-time breach (such as an accidentally exposed S3 bucket or a database dump left publicly accessible) can be distinguished from a controlled one by a key feature: interactivity and adaptability.

In the case of a C2-controlled breach, the attacker doesn't just "take what's lying around." They first conduct reconnaissance, study the network structure, the location of valuable data, and backup systems. Then, they create multiple entry points and persistence mechanisms in case one of the vectors is detected.

Next, they exfiltrate data in small batches to avoid triggering DLP systems or network traffic analyzers.

Implementing this behavior in practice is impossible without a control channel. The attacker must receive commands (which folders to archive, where to send them) and see the results of their actions. This channel—Command & Control—becomes the "bridge" linking the attacker to the compromised infrastructure. Destroying it means not just stopping the current breach, but depriving the attacker of control over all infected nodes.

In the minds of many specialists, C2 is firmly associated with "malware" that communicates with the "command server." This is a dangerous simplification. Modern C2 is a management architecture, not a specific file.

Thus, C2 can exist without classic malware in various forms. For example, when using Living-off-the-land, the attacker can use legitimate system tools (PowerShell, WMI, SSH, PsExec) to receive commands. In this case, the "agent" is the administrative tool of the OS itself.

Additionally, the attacker can place command servers in public clouds (AWS, Azure, Google Cloud) or use legitimate cloud APIs. The victim sends requests to amazonaws.com, and within this traffic, commands and stolen data are hidden.

It is also possible to use legitimate messengers (Telegram, Discord, Slack) as a transport for commands and results.

Thus, detecting C2 only by signatures (file hashes or IP addresses) becomes impossible. The attacker does not inject "foreign code" in the classical sense — they manipulate the standard infrastructure tools.

How C2 disguises itself as legitimate traffic

Modern C2 frameworks (Cobalt Strike, Sliver, Mythic, Brute Ratel) have reached such a level of development that their traffic is almost indistinguishable from legitimate traffic if you don't know where to look.

They use permitted protocols for masking, and perhaps the most common is HTTPS. To complicate detection as much as possible, hackers use User-Agent spoofing: simulating browsers (Chrome, Edge) or API clients.

Also, when using HTTPS, they apply so-called JARM fingerprints, meaning that attackers configure TLS certificates and handshake parameters so that they match legitimate services (for example, cloning the JARM fingerprint of Cloudflare).

Finally, they may use ghost domains (Domain Fronting). In this case, requests go to a legitimate CDN (for example, CloudFront), and inside the HTTP Host header, a domain controlled by the attacker is specified. The CDN proxies the traffic, and at the network level, only communication with a trusted cloud provider is visible.

Another fairly common protocol for masking traffic is DNS. This protocol is rarely blocked completely, so C2 agents can encode commands and data in subdomains.

Here’s a small example: The agent sends a request like data_encrypted.attacker.com. The attacker’s DNS server returns a TXT record with a command. This is extremely difficult to detect without analyzing the volume and frequency of DNS requests to rare domains.

Agents can also use public APIs of legitimate services. For example, they may use the Microsoft Graph API. In such cases, they can read requests to graph.microsoft.com to read commands from the headers of Outlook emails or comments in SharePoint.

With Slack/Discord webhooks, agents can transmit stolen data to a private messenger channel through standard APIs.

So, we’ve covered the main methods of C2 interaction with victim nodes and the protocols and tools used for this. Now, let’s look at how we can detect C2.

Detecting C2: From Signatures to Correlation

The evolution of C2 detection methods directly reflects the evolution of the attacks themselves. Let’s look at three approaches, each representing the next level of maturity.

The old reliable signature-based approach. Searching for known Indicators of Compromise (IOC): IP addresses, domains, file hashes, strings in network packets. In today’s world, this method will clearly be insufficient. Signatures become outdated just hours after publication. C2 frameworks allow generating unique builds for each victim. For targeted attacks (APT), signatures are useless.

The behavioral approach is much more effective. It involves analyzing anomalous behavior, regardless of specific indicators. During analysis, we look for periodic outgoing connections with a constant interval (e.g., every 60 seconds). Legitimate traffic usually does not have such perfect timing.

Also, the behavioral approach involves searching for DNS anomalies. This is usually a huge number of requests to a third-level domain with high entropy names (random characters).

At the node level, we can also look for process anomalies. The parent process (e.g., winword.exe or powershell.exe) establishes a network connection with an external IP, which is unusual for office applications.

The correlation approach involves combining data from multiple sources (network, endpoints, cloud) to identify a context that, when viewed separately, appears legitimate.

This approach is the most reliable. Let's consider a small example again. A standalone HTTP request to microsoft.com is legitimate, and a standalone process of powershell.exe is legitimate. But if powershell.exe, with arguments encoded in base64, establishes a TLS connection with an IP that was registered yesterday and has a self-signed TLS certificate, this correlation provides nearly 100% confidence in C2.

Let’s consider a hypothetical but typical scenario that an Incident Response team faces. We have the following initial data: a DLP system recorded the transfer of 2 GB of data to an external IP address over HTTPS. The “suspicious volume” rule was triggered, so the SOC opens an incident and sees not just one transfer, but a series of events over the last 7 days. The volume of data sent gradually increases (from 50 MB on the first day to 2 GB on the last day). This is a behavioral indicator of managed exfiltration — the attacker first checked the channels, then began the exfiltration.

Now let’s look at the network interaction analysis. By detailing the traffic for the month, it is found that two weeks before the exfiltration began, requests were sent from this host to the domain cdn-cloudflare-resolve.com (a domain impersonator) every 120 seconds. The responses came back with exactly 0 bytes (which is unusual for a real CDN). This is classic beaconing — waiting for a command.

EDR shows that the svchost.exe process (a legitimate system process) was injected at the moment before the beaconing began. In the process tree, a powershell.exe -WindowStyle Hidden -EncodedCommand was found.

Thus, the network anomaly (beaconing) + behavioral anomaly on the endpoint (powershell without a window with an encoded command) provide undeniable confirmation of C2 activity.

As a result, we can draw the following conclusion: this is not a one-time leak due to a configuration error. This is a targeted attack with the deployment of a C2 agent (likely Cobalt Strike or Sliver), which first established itself in the system, then received a command to search for data, and finally, a command to exfiltrate it.

We think at the level of management infrastructure, not individual alerts

Many cybersecurity professionals are used to thinking in terms of alerts when we receive notifications about an incident and need to react to it, but to effectively investigate leaks, we need to shift from “alert-driven” thinking to “campaign-driven” thinking.

That is, instead of asking: “Is this IP address on the blacklist?” we should ask: “Why is this server communicating with an external resource at a frequency characteristic of beaconing, and why does this traffic coincide with the start of unusual processes on this host?”

Security issues must be considered holistically. It is necessary to build NDR (Network Detection and Response) that allows for the analysis of network traffic. Without network analysis, you won’t see beaconing and ghost domains, as EDR alone does not detect C2 using legitimate cloud APIs.

Implementing DNS filtering with entropy analysis allows detecting C2 at the preparation stage. In particular, blocking by categories (newly observed domains, domain generation algorithms) will significantly complicate the attackers' efforts during the preparation phase.

Once a quarter, simulate C2 operations (e.g., using Cobalt Strike in a controlled environment) to check how well your detections correlate beaconing with endpoint activity.

It would be useful to analyze TLS/JARM, as even if the IP address is clean, the JARM fingerprint of a homemade server often differs from the fingerprints of legitimate services (Google, Microsoft, Cloudflare). Monitoring anomalous TLS handshakes is one of the most reliable ways to find C2 infrastructure.

Conclusion

Command & Control is not just a technical term from APT group reports. It is an architectural principle underlying most system data leaks. As long as there is a control channel between the attacker and the compromised environment, the leak can continue, evolve, and disguise itself.

Investigating such incidents becomes successful only when the security team stops hunting individual “malwares” and starts analyzing the control infrastructure — looking for beaconing patterns, correlating network anomalies with processes on hosts, and identifying anomalies in the use of legitimate protocols.

Cutting the C2 channel means not just fixing the incident, but regaining control over your own infrastructure, stopping data leaks at the root, rather than when the databases have already been stolen by the attacker. Remember: where there is managed activity, there is always C2. Find it — and you’ll find the key to the investigation.