1. Introduction: When a Compromised System Calls Home

A workstation begins making outbound connections to an unfamiliar domain every few minutes. No user reports a problem, no suspicious window appears, and the endpoint continues to operate normally.

The network monitoring platform records repeated connections. Shortly afterward, an endpoint detection alert identifies an unusual script execution on the same workstation.

Individually, the network connections might resemble ordinary web traffic. When correlated with the suspicious process, however, they may indicate that malware is communicating with attacker-controlled infrastructure.

This is one of the challenges of detecting command-and-control traffic.

Attackers need a way to interact with compromised systems after initial access. They may use that communication channel to issue commands, obtain system information, deliver additional payloads, or coordinate further activity.

For defenders, the objective is to identify communications that are suspicious in context, determine whether a device is compromised, and prevent further attacker interaction without unnecessarily disrupting legitimate business traffic.

2. What Is Command-and-Control Traffic?

Command and Control (C2) is the communication infrastructure or activity through which an attacker directs compromised systems.

After a system is compromised, malware or an unauthorised implant may attempt to contact a remote server, domain, or other communication endpoint. The attacker may then use the channel to send instructions or receive information.

C2 communication can support several activities:

• Sending commands to compromised endpoints.

• Downloading additional malware or tools.

• Collecting system and environment information.

• Coordinating activity across multiple compromised devices.

• Preparing data for exfiltration.

• Maintaining remote access to a compromised environment.

C2 is associated with the Command and Control tactic in the MITRE ATT&CK framework, identified as TA0011.

Not every outbound connection from a suspicious endpoint is C2. Legitimate applications communicate with remote services continuously, and malware can use common protocols that are also used by normal business applications.

The investigation must establish whether the connection's destination, timing, process, behaviour, and surrounding activity support a malicious explanation.

3. How Attackers Communicate with Compromised Systems

Understanding common communication patterns helps defenders design effective detections.

3.1 HTTP and HTTPS

Malware may use HTTP or HTTPS to exchange data with remote infrastructure. These protocols are widely used by legitimate applications, which can make suspicious connections difficult to distinguish based on protocol alone.

HTTPS encrypts application traffic in transit, limiting what passive network sensors can inspect unless suitable visibility is available. However, defenders may still be able to examine DNS activity, connection metadata, destination information, certificate details, and endpoint process telemetry.

Encryption should not be treated as evidence of malicious activity.

3.2 DNS-based communication

DNS is necessary for resolving domain names, but attackers may also abuse DNS queries and responses to support C2 or conceal data exchanges.

Potential warning signs include unusual query patterns, suspicious domain characteristics, unexpectedly high query volumes, and DNS activity that correlates with a suspicious process.

DNS tunnelling is one possible technique, but unusual DNS traffic can also result from legitimate software, misconfiguration, or security testing.

3.3 Periodic beaconing

Some implants communicate at recurring intervals to check for instructions or report their status. This pattern is commonly called beaconing.

For example, an endpoint might contact the same unusual destination at regular intervals over an extended period.

A repeated interval can be a useful hunting clue, but it is not sufficient on its own. Monitoring agents, update services, cloud applications, and other legitimate software also generate periodic traffic.

Analysts should correlate connection timing with destination reputation, process identity, DNS activity, and the endpoint's other behaviour.

3.4 Other communication methods

Depending on the environment and threat, C2 may also involve custom protocols, remote-access services, or third-party platforms.

Attackers may abuse legitimate cloud services or commonly used web infrastructure, making destination-based blocking less reliable.

Defenders therefore need multiple detection methods rather than a single list of known malicious IP addresses.

4. Network Indicators That May Reveal C2 Activity

C2 detection often begins with identifying traffic patterns that differ from an endpoint's normal behaviour.

Potential indicators include:

• Repeated outbound connections to an unusual destination.

• Connections to domains with suspicious characteristics or known malicious history.

• Unusual DNS query patterns.

• Unexpected traffic from a process that normally has no network activity.

• Connections occurring shortly after suspicious script or executable execution.

• Unexplained communication with external infrastructure outside normal business patterns.

• Network activity that continues after a suspicious file is detected.

No single indicator confirms C2. Each must be evaluated in context.

Example: Suspicious periodic connections

A workstation generates repeated outbound connections to an unfamiliar host at similar intervals.

The analyst finds that:

1. The connections began shortly after a suspicious script ran.

2. The same process is associated with the network activity.

3. The destination has no clear business justification.

4. The endpoint also exhibits unusual file or process activity.

Together, these observations provide stronger evidence than the recurring connections alone.

The next step is to determine whether the activity matches a known threat, whether communication succeeded, and whether other endpoints show the same pattern.

5. How Organisations Detect C2 Traffic

Effective C2 detection combines multiple sources of evidence. Different controls provide different views of the same activity.

5.1 DNS monitoring

DNS logs can reveal which domains endpoints attempt to resolve and when those requests occur.

Security teams may investigate:

• Newly observed or suspicious domains.

• High volumes of unusual queries.

• Query patterns that differ significantly from an endpoint's baseline.

• Connections to known malicious domains.

• DNS activity associated with suspicious processes or malware alerts.

DNS security services can also block requests to domains classified as malicious or prohibited by policy.

However, attackers may use compromised legitimate domains, rapidly changing infrastructure, or direct IP connections. DNS monitoring should therefore be combined with other controls.

5.2 Firewall and network-flow analysis

Firewalls and network-flow monitoring can show which systems communicate, the destinations involved, the ports and protocols used, and connection timing or volume.

These records help analysts identify unusual outbound communication and determine whether a suspicious endpoint is contacting multiple external systems.

Network-flow records generally provide metadata rather than full application content. They are valuable for scoping and correlation, but may not reveal the exact commands or data exchanged.

5.3 Proxy and secure web gateway logs

Web proxies and secure web gateways can provide visibility into outbound web requests, depending on deployment and encryption-inspection configuration.

Useful evidence may include requested hostnames, URLs, timestamps, user or device identities, response codes, and policy actions.

Analysts can use this information to determine whether an endpoint accessed a suspicious destination, whether the request was blocked, and whether similar activity occurred elsewhere.

5.4 EDR telemetry

Endpoint Detection and Response platforms can associate network connections with the processes responsible for them.

This is especially valuable when a legitimate application or system utility is being abused.

For example, a network connection attributed to an unexpected script interpreter may deserve closer examination than the same destination accessed by a known business application.

EDR can also expose process trees, command lines, file changes, and other behaviours that help establish whether a network connection is part of a wider attack.

5.5 Network Detection and Response

Network Detection and Response (NDR) solutions analyse network activity to identify suspicious communication patterns and other behaviours associated with threats.

Depending on the product and telemetry available, NDR may use protocol analysis, behavioural analytics, statistical patterns, or threat intelligence.

NDR can complement EDR by providing network-level context, including communications involving devices that lack a fully deployed endpoint sensor.

5.6 Threat intelligence

Threat-intelligence sources can provide information about known malicious domains, IP addresses, URLs, certificates, and other indicators.

Security teams may enrich alerts using reputable feeds and investigation platforms to determine whether a destination has previously been associated with malware or C2 infrastructure.

Indicator matches should be interpreted carefully. Infrastructure can change ownership, be shared by legitimate and malicious services, or become stale.

Threat intelligence is most useful when combined with observed behaviour and reliable context.

6. Blocking C2 Traffic: Defensive Controls

Detecting suspicious traffic is only part of the process. Organisations also need controls that can prevent or interrupt malicious communication.

DNS filtering

DNS security controls can block queries to known malicious domains and domains prohibited by organisational policy.

This may prevent malware from resolving a C2 domain through the organisation's approved DNS infrastructure.

Limitations include direct-IP communication, use of unmonitored DNS resolvers, and the possibility that legitimate shared infrastructure is involved.

Firewall egress filtering

Outbound firewall rules can restrict which systems are allowed to communicate with external destinations and services.

For example, servers that do not require general internet access can be restricted to approved destinations.

A deny-by-default approach for suitable systems can reduce exposure, but policies must account for operational dependencies and necessary business traffic.

Web proxy and secure web gateway policies

Proxies can restrict access to malicious or unauthorised web destinations and enforce outbound web-access policies.

Organisations can block known threats, restrict risky categories, and investigate suspicious requests. Where supported and appropriate, additional inspection may help identify malicious activity within web traffic.

EDR containment

If endpoint evidence indicates an active compromise, EDR may allow responders to isolate the affected device, terminate malicious processes, or quarantine files.

Isolation can interrupt the endpoint's communication with attacker infrastructure, although the exact behaviour depends on the product and isolation policy.

Responders should verify the isolation status and follow incident procedures to avoid disrupting essential services unnecessarily.

Network segmentation

Segmentation restricts communication between systems and network zones. While it does not automatically block every external C2 connection, it can limit an attacker's ability to reach additional internal systems after compromising one endpoint.

Centralised blocking and response

Where integrations permit, a SIEM or SOAR platform can coordinate enrichment, alerting, ticket creation, and approved response actions.

For example, a high-confidence detection might trigger a workflow that enriches the destination, searches for related activity, requests analyst approval, and then applies a block or endpoint isolation action.

Automation should account for confidence, false-positive risk, business impact, and rollback procedures.

7. Practical SOC Investigation: Suspected C2 Beaconing

Consider an endpoint that repeatedly contacts an unfamiliar external domain. The activity is detected by a network monitoring platform.

A structured investigation can help determine whether the traffic represents malicious C2.

Step 1: Validate the alert

Record the affected endpoint, destination, timestamp, protocol, connection frequency, and detection rationale.

Confirm whether the alert represents a successful connection, a blocked attempt, or a pattern inferred from network metadata.

Step 2: Examine the destination

Review domain and IP reputation, registration information where available, historical observations, certificate information, and known threat-intelligence associations.

Do not classify a destination as malicious based solely on its age, hosting provider, or unfamiliarity.

Step 3: Identify the responsible process

Use EDR telemetry to identify which process initiated the connection.

Examine the process path, command line, parent process, execution user, and any recent file or configuration changes.

Step 4: Analyse communication patterns

Review DNS queries, connection timing, byte counts, protocol information, and destination changes where available.

Determine whether the traffic is periodic, whether it began after suspicious execution, and whether it resembles the endpoint's normal activity.

Step 5: Correlate with other telemetry

Search the SIEM for related process activity, endpoint alerts, authentication events, proxy requests, and connections from other devices to the same destination.

Multiple affected endpoints may indicate a broader infection or shared software behaviour that requires further investigation.

Step 6: Assess the risk

Determine whether the communication is confirmed malicious, suspicious but unconfirmed, or consistent with legitimate activity.

Assess whether commands were received, additional payloads were downloaded, sensitive data may have been accessed, or other systems may be affected. Do not claim these outcomes without supporting evidence.

Step 7: Contain and block

For confirmed or sufficiently high-risk activity, follow the incident-response procedure. Depending on the evidence, actions may include blocking the destination, isolating the endpoint, terminating a malicious process, preserving evidence, and searching for additional affected systems.

Step 8: Verify the result

Confirm that the intended control took effect. Check for continued attempts, alternative destinations, other communication methods, or related activity on additional endpoints.

Blocking a single domain does not necessarily eradicate the malware or remove its persistence mechanism.

8. Useful Data Sources and SOC Queries

The exact query depends on the SIEM schema and data source. The following examples are illustrative and should be adapted to the fields available in the environment.

Example A: Splunk — identify repeated outbound connections

index=firewall | stats count dc(dest_port) as distinct_ports values(dest_port) as destination_ports by src_ip dest_ip | where count > 20 | sort - count

This query highlights source-destination pairs with a high number of recorded events. It does not prove beaconing or malicious C2; repeated legitimate traffic may also appear.

Example B: Splunk — correlate endpoint network activity

If the EDR data model records process and network information in a common event source, a starting point may be:

index=edr | stats count values(process_name) as processes values(command_line) as command_lines by host dest_ip | sort - count

This example assumes that the index contains fields named host, dest_ip, process_name, and command_line. Field names and available network telemetry vary by product.

The results should be enriched with timestamps, destination reputation, process ancestry, and other evidence before drawing conclusions.

Example C: Microsoft Sentinel — review unusual outbound traffic

CommonSecurityLog | summarize ConnectionCount = count(), Ports = make_set(DestinationPort) by SourceIP, DestinationIP | where ConnectionCount > 20 | order by ConnectionCount desc

This query assumes that firewall or network-security events are being ingested into CommonSecurityLog. The threshold is illustrative and should be tuned to the organisation's traffic baseline.

For actual beaconing detection, include timestamps and analyse the intervals between connections rather than relying only on event counts.

9. Common Challenges in C2 Detection

Encrypted communications

Encryption protects legitimate users but can also conceal malicious content from passive network inspection.

Organisations can combine available connection metadata, DNS information, endpoint telemetry, and approved inspection methods where appropriate. Inspection must account for privacy, legal requirements, application compatibility, and operational impact.

Legitimate cloud services

Attackers may abuse trusted hosting providers or collaboration platforms to communicate with compromised systems.

Blocking an entire provider may disrupt legitimate business operations. Destination-level evidence, endpoint context, and behaviour-based detection are often necessary.

Changing infrastructure

C2 infrastructure may rotate domains or IP addresses, and threat actors may use multiple destinations.

Static indicator lists can therefore become outdated. Behavioural detection, timely intelligence updates, and endpoint correlation help address this limitation.

False positives

Monitoring systems may flag legitimate update services, monitoring agents, or applications that communicate at regular intervals.

Detection rules should be tested against normal traffic and tuned using approved baselines without suppressing genuinely suspicious behaviour.

Limited visibility

Devices may be unmanaged, logs may be incomplete, or network traffic may bypass monitoring controls.

Organisations should identify blind spots, improve telemetry collection, and ensure that critical systems are covered by appropriate endpoint and network monitoring.

10. Prevention and Long-Term Defensive Strategy

A mature C2 defence strategy combines preventive controls with detection, investigation, and recovery.

1. Centralise DNS: Use approved resolvers and monitor attempts to bypass organisational DNS controls.

2. Restrict outbound traffic: Limit unnecessary internet access from servers and sensitive systems.

3. Deploy EDR: Maintain endpoint visibility and response capability across critical devices.

4. Use network monitoring: Collect firewall, proxy, DNS, and network-flow telemetry.

5. Protect endpoints: Patch operating systems and applications, restrict unnecessary privileges, and control unauthorised execution.

6. Integrate threat intelligence: Enrich alerts with current, reputable intelligence and account for indicator quality.

7. Hunt proactively: Search for unusual periodic connections, suspicious process-linked network activity, and related behaviours across endpoints.

8. Automate carefully: Use confidence-based workflows and approval gates for disruptive response actions.

9. Test detections: Validate controls through authorised simulations and controlled exercises.

10. Plan for eradication: Investigate persistence and initial access so that blocking communication is not mistaken for complete remediation.

Conclusion

Command-and-control traffic provides attackers with a communication path to compromised systems. Detecting it requires more than searching for known malicious IP addresses or unusual domains.

Organisations improve detection by correlating DNS queries, network flows, proxy logs, EDR telemetry, threat intelligence, and behavioural patterns. Defensive controls can then block known malicious destinations, restrict unnecessary outbound communication, and contain affected endpoints.

For SOC analysts, the most important task is to establish the relationship between a suspicious connection and the process or activity that generated it. Confirming the destination, understanding the timeline, assessing the impact, and verifying containment are essential to a reliable investigation.

Blocking C2 traffic can interrupt an attack, but effective incident response must also address the compromised endpoint, persistence mechanisms, and any additional systems or accounts affected.

Further Reading

• MITRE ATT&CK: Command and Control

• MITRE ATT&CK: Application Layer Protocol

• MITRE ATT&CK: Encrypted Channel

• CISA — Cybersecurity advisories and defensive guidance.

• Microsoft Sentinel documentation — SIEM analytics and investigation.

• Microsoft Defender for Endpoint — Endpoint detection and response.