What Is C2?

What Is C2 (C&C, Command and Control)?

C2 (Command and Control) refers to the channels, and supporting infrastructure that attackers use to communicate and send commands to compromised systems and receive the results. Attackers use the C2 infrastructure to send malware instructions, assess an infected environment, explore the internal network, and send collected information

MITRE ATT&CK classifies Command and Control as a tactic that attackers use to communicate with compromised systems. C2 communications use a wide range of techniques, including application layer protocols, proxies, dynamic address resolution, encrypted channels, and web services. C2 therefore does not refer to a single server or piece of malware. It covers the channels and methods attackers use to communicate with and control compromised systems.

C2 Functions and Roles

After gaining access, attackers use C2 to carry out malicious activity. They collect system information, execute commands, download additional ransomware, and steal data. They can also disable security tools, attempt lateral movement, or deploy ransomware.

As C2 also sends the status of the compromised systems, with the information collected attackers can adjust their instructions as the attack develops. This means that even if systems are infected with the same malware, they can show different activity and levels of damage depending on whether they maintain a C2 connection and which commands they receive.

Attackers can also add or change C2 channels when needed. They can establish communication channels after the initial infection or switch to backup servers and different protocols if the existing connection is blocked.

How C2 Communication Works

There are several tools attackers use to establish C2 communications, but the overall process shares the same flow. Attackers gain initial access through phishing, exploited vulnerabilities, compromised accounts, or supply chain attacks. Then they deploy malware or remote access tools to communicate with external C2 infrastructure. During the connection, the malware can send details such as the hostname, operating system, user account, IP address, installed security products, and current privileges. This information helps the attacker assess the environment and status of the infected system. Once registered, the malware contacts the C2 infrastructure at set intervals to check for new commands that are known as beaconing or a callback.

Depending on the command, the malware checks running processes and files, captures screenshots, executes shell commands, collects account information, or downloads additional files and sends the results over the C2 channel. Because attackers use collected information to issue new commands, the capabilities identified in a malware sample do not reveal the full scope of an actual attack.

C2 communications may continue after the attack has ended. Even if the malware is removed, if scheduled tasks, services, startup programs, web shells, or additional accounts remain, attackers can use them to reconnect to C2 infrastructures.

C2 Infrastructure Architectures

C2 infrastructure can be grouped into centralized, multilayer and proxy-based, peer-to-peer (P2P), web service-based, and hybrid according to how commands are delivered. Real-world operations often separate primary and backup channels or combine multiple architectures.

Architecture	How It Works	Security Considerations
Centralized	Infected systems connect to one or a small number of C2 servers.	Communications can be blocked relatively quickly once they identify the servers and domains. However, attackers may change addresses or replace servers to restore C2 communications.
Multilayer and proxy-based	Redirectors, proxies, or relay servers are placed between infected systems and the actual control server.	Blocking an exposed server does not necessarily remove the operational infrastructure, which makes attribution and tracking more complex.
P2P	Infected devices pass commands or connection information to one another.	The network does not depend on a single server, which makes complete disruption difficult.
Web service-based	Commands or addresses are delivered through legitimate services such as cloud storage, code repositories, or social media.	The traffic blends with legitimate business activity, making it difficult to block.
Hybrid	The operation uses several C2 infrastructure models together.	Attackers restore control through another route when the primary channel is blocked.

Centralized architecture is relatively easy to operate as Infected systems connect to a predefined domain or IP address. However, once C2 servers and domains are identified and blocked, communication is disrupted. To prevent this, attackers prepare multiple domains, rotate server addresses, or place the actual C2 server behind relay servers to make disruption more difficult.

The P2P architecture uses infected devices as both servers and clients, forwarding commands. As the system is distributed across multiple infected devices, the network can continue operating even if several devices are removed. Managing this type of network is more complex than a centralized architecture because attackers need to coordinate commands across multiple infected devices and keep track of their communication status.

Web service-based C2 exploits legitimate services for malicious communications. Attackers store encrypted commands or C2 server addresses in public posts, files, or APIs. Because the traffic uses the same infrastructure as legitimate services, it cannot be identified based on domain or IP address alone. Blocking an entire service, however, can disrupt legitimate business operations. Determining whether the traffic is malicious requires analyzing the broader context, including the process and account involved, request content, and communication timing.

C2 Communication Methods

To maintain C2 communications while avoiding detection, attackers generally abuse everyday protocols and permits used for external connections. HTTP and HTTPS are the most commonly used methods. As both protocols support ordinary web access, commands and execution results exchanged using web requests are difficult to distinguish from normal internet traffic. HTTPS can make C2 traffic harder to identify due to encryption. Since HTTPS is widely used for legitimate web traffic, the use of encryption, a valid certificate, or port 443 cannot determine whether a connection is malicious.

DNS are also used as C2 channels. Attackers encode data in DNS queries or send commands through responses. Because DNS traffic is essential for network operations, malicious C2 activity can blend in with legitimate queries making it difficult to detect.

Attackers also use email, file transfer protocols, messaging services, remote management software, and custom TCP or UDP protocols. After assessing the organization’s network policies and detection environment, they select protocols or services that appear frequently in normal business.

Communication Method	How It Is Used	Detection Signals
HTTP and HTTPS	Commands are delivered through web requests and responses, which also carry execution results back to the attacker.	Proxy logs, URLs, headers, certificates, connecting processes, and recurring intervals
DNS	Commands or data are embedded in domain queries and responses.	Long subdomains, high character randomness, excessive TXT queries, and abnormal query volume
Cloud and web services	Posts, files, and APIs serve as command delivery mechanisms.	API calls from unauthorized applications and connections to services unrelated to business activity
Custom protocols	Communications use designated ports and proprietary message formats.	Nonstandard ports, protocol mismatches, and unknown external destinations
Remote management tools	Attackers abuse legitimate remote support capabilities.	Unauthorized installations, unusual accounts, and connections at unexpected times or to unusual targets

Detection Evasion Techniques

Attackers vary data formats, communication intervals, and addresses to make C2 traffic difficult to detect. They encode commands or execution results with formats such as Base64, add irrelevant data, or disguise traffic as legitimate protocols. They also hide information inside images or documents through steganography.

Attackers adjust timing to obscure recurring connection patterns. As beaconing with a C2 server is easier to identify, jitter is used to insert random variation between connection intervals. They also delay communications, restrict connections to a specific time or day, or reduce the amount of data sent in each transmission and spread the transfer over a longer period.

Another technique is rotating C2 server addresses. A domain generation algorithm (DGA) produces large numbers of domains which are used for C2 communications. Fast Flux rapidly rotates the IP address making C2 infrastructure more difficult to trace and block.

Attackers also abuse legitimate cloud services, content delivery networks, and web services. C2 traffic uses the same domains or infrastructure making it difficult to detect malicious communications with IP and domain reputation. Blocking an entire service disrupts legitimate work, which makes context such as the connecting process, account, and communication method essential.

Key Detection Points for C2 Activity

In order to detect C2 activities, destination reputation data should be analyzed along with network and endpoint activity.

Recurring External Communications

Repeating outbound connections can indicate C2 beaconing, especially when the same process regularly exchanges small amounts of data with the same external server. However, legitimate services such as software updates and system checks can also show similar behavior, so recurring connections does not always indicate C2 activity.

Unusual DNS Requests

DNS activity such as requests to previously unused domains, long subdomains, random-looking domain names, or an unusual volume of specific record types can indicate C2 communications. Repeated queries to large numbers of nonexistent domains within a short period may also indicate DGA activity. The process generating the DNS requests, recently installed software, and related user activity should be reviewed to determine whether the behavior is malicious.

Unusual Endpoint Activity

Suspicious endpoint behavior may include unexpected external connections from document applications and script interpreters, or network communication from files executed from temporary directories. Other indicators include recently added services, scheduled tasks, and unusual PowerShell execution. Reviewing process relationships can also help trace activity from an initial document or script execution to an C2 connection.

Proxy and Firewall Logs

Proxy and firewall logs can help identify unusual outbound communications, such as connections to destinations unrelated to business operations, recently registered domains, long-running sessions with low data volumes, and protocol and port mismatches. TLS connections should be reviewed based on certificate details, server names, client characteristics, connection frequency, and timing.

Correlating Logs

Correlating endpoint, DNS, proxy, firewall, and other logs is required to accurately detect C2. A single alert rarely reveals the full attack. Analysts need to connect the process and account involved with the destination and communication method to reconstruct the actual sequence of events.

Designing a C2 Detection System

Effective C2 detection starts with visibility into outbound communications. Firewall allow and block logs cannot reveal detailed HTTPS behavior or identify the process that generates a DNS request. Effective detection requires endpoint telemetry analysis with network logs.

Normal communication patterns should be defined according to the role of the system. A connection to a code repository may be normal for a development server but unusual for a financial system. Understanding which external services, communication times, data volumes, and applications are normal for each system helps distinguish unusual C2 communications more accurately.

Threat intelligence helps identify and block known C2 servers and domains. When blocking the IP address or domain based on the information, security teams should review when the intelligence was collected, its confidence level, and whether the address is shared by multiple services. An IP address that was used for malicious activity might later be assigned to a legitimate service. Additionally, several services often share a single cloud address.

New C2 infrastructure requires behavior-based detection. Combining recurring callbacks, unusual DNS requests, rarely used external destinations, and network connections from processes unrelated to business activity produces more accurate results than evaluating each signal separately. Even with jitter, C2 traffic can reveal recurring characteristics when analysts compare connection times, destinations, and transfer volumes over a longer period.

Detection rules should support investigation along with alerts. Analysts need access to raw logs, system and user information, and process relationships to analyze an attack. Once the incident is confirmed, they should be able to search other systems for the same destinations, file hashes, certificates, processes, and accounts.

What to Do First When C2 Traffic is Suspected

When C2 traffic is suspected, first identify the affected systems and accounts, communication destinations, and the connections. Do not estimate the scope from a single alert. Search for the same destinations and similar communication behavior on other systems. If several systems connected to the same C2 infrastructure, investigate whether the compromise spread beyond the initially identified hosts.

Once C2 communications are confirmed, isolate systems with a high likelihood of compromise from the network to prevent new commands and lateral movement. Immediately powering off a system can destroy volatile evidence, including memory-resident malware and current network connection data. Determine the order of network isolation, evidence collection, and shutdown according to the system’s importance and the current stage of the attack.

Add confirmed C2 domains, IP addresses, URLs, certificates, and related indicators to DNS security controls, firewalls, proxies, and endpoint security policies to stop additional communications. When attackers abuse legitimate cloud or web services, assess the business impact before blocking the entire service. Where necessary, narrow the control by URL, application, account, or process.

Preserve evidence needed to reconstruct the attack path and determine the scope of damage. Relevant evidence includes running processes, active network connections, DNS, proxy and firewall logs, malicious files, scheduled tasks and services, and user login records. Blocking the C2 address and deleting related files or execution records too early can make it harder to determine the initial access path and the actions taken by the attacker.

Remediation should include a review of scheduled tasks, services, registry settings, web shells, newly created accounts, and other mechanisms that could re-establish attacker access. If credentials were exposed, change the passwords and revoke active sessions and tokens. Remediate the vulnerability or configuration error used in the attack to reduce the risk of reinfection.

Continue monitoring for renewed contact with known C2 servers after recovery. Attackers also resume C2 activity through different external servers or protocols, so closely monitor the network activity of affected systems for an appropriate period. Incorporate the IP addresses, domains, files, processes, and communication patterns identified during the incident into detection rules, threat hunting queries, and incident response procedures.

Operating Principles for Reducing C2 Risk

Limit outbound communications to what each system actually needs. Servers and critical business systems should connect only to approved destinations over authorized protocols. For systems with no operational need for internet access, blocking outbound traffic reduces the paths malware can use to contact C2 infrastructure.

DNS traffic requires similar oversight. Route queries through approved DNS servers and centralize log collection so analysts can investigate unusual domain activity. Endpoints that use arbitrary external resolvers or separate encrypted DNS services can obscure DNS-based C2 traffic. Apply controls that align with the organization’s security policies and operational requirements.

Segment networks according to business function and asset criticality to contain intrusions. Permit only necessary traffic between user, server, critical information system, and management networks. Access to remote management tools and script execution environments should also be limited to authorized administrators and approved systems.

Security updates, phishing protections, multifactor authentication, least-privilege access, and application control help prevent attacks from reaching the C2 channel. Network intrusion detection and prevention systems can identify known communication patterns and suspicious protocol behavior. Since attackers frequently change infrastructure and traffic formats, detection should combine known indicators of compromise with behavioral analysis.

FAQ