1. When Ordinary Network Traffic Raises an Alarm

Imagine a SOC analyst notices that a workstation is connecting to an unfamiliar external IP address every few minutes. Each connection is relatively small, and the traffic uses HTTPS, making it difficult to distinguish from normal internet activity through volume alone.

At first, the destination appears insignificant. However, the analyst notices that the connections began shortly after a suspicious executable was launched.

Further investigation reveals that the same workstation is making unusual DNS requests and communicating with infrastructure associated with suspicious activity.

The analyst now has a potential C2 investigation.

The challenge is that C2 traffic does not always look obviously malicious. Attackers may use common protocols such as HTTP, HTTPS, and DNS, while legitimate applications also generate recurring outbound connections.

The key to C2 investigation is identifying suspicious communication in context, rather than treating every unfamiliar connection as malicious.

2. What Is Command-and-Control Communication?

Command-and-Control, often abbreviated as C2 or C&C, describes the communication between an attacker and a compromised system that enables remote coordination or control.

After gaining access to a device, an attacker may use C2 communication to interact with the compromised environment.

Depending on the malware and attack, C2 activity may support:

• Receiving instructions from an attacker.

• Sending system information or collected data.

• Downloading additional tools or payloads.

• Maintaining communication with a compromised endpoint.

• Coordinating activity across multiple infected systems.

• Supporting further exploitation or lateral movement.

C2 is not a specific malware family or protocol. It is a functional part of many intrusions.

Some malware communicates with a central server, while other threats use peer-to-peer infrastructure, compromised legitimate services, or other communication mechanisms.

3. How Does a C2 Communication Chain Work?

A typical C2 sequence can involve several stages. The exact order depends on the threat and the attacker's objectives.

Stage 1: Initial compromise

A device becomes compromised through a mechanism such as phishing, exploitation of a vulnerable service, malicious software installation, or the abuse of valid credentials.

The initial compromise does not always produce immediate, obvious C2 traffic.

SOC focus: Review the first suspicious endpoint event, including process execution, downloaded files, authentication activity, and relevant security alerts.

Stage 2: Establishing communication

The compromised system attempts to contact external infrastructure controlled or used by the attacker.

This may involve DNS resolution, a direct IP connection, an HTTP request, an HTTPS session, or another protocol.

SOC focus: Identify the destination, protocol, initiating process, first-seen timestamp, and surrounding network activity.

Stage 3: Beaconing or recurring communication

Some malware periodically contacts its C2 infrastructure to check for instructions or report status.

This recurring behaviour is commonly called beaconing.

Connections may occur at regular intervals, but attackers can also introduce timing variation or other changes to make communication less predictable.

SOC focus: Examine connection frequency, duration, byte counts, timing patterns, and whether multiple endpoints exhibit similar behaviour.

Stage 4: Exchanging information or instructions

Depending on the threat, the compromised system may send information to the remote infrastructure or receive commands and additional payloads.

The content may be visible, partially observable, or encrypted.

SOC focus: Correlate network connections with endpoint process activity, file creation, DNS requests, and other evidence of commands or payload execution.

Stage 5: Expanding the intrusion

C2 communication may support further activity, such as credential theft, system discovery, lateral movement, or data collection.

Not every C2 connection leads to these actions, but identifying the communication early can provide an opportunity to interrupt the intrusion.

SOC focus: Search for additional affected hosts, suspicious authentication, unusual administrative activity, and evidence of data access or transfer.

4. Common Network Indicators of Potential C2

C2 communication can use legitimate protocols, which means no single network characteristic reliably identifies every attack.

1. Repeated outbound connections

A host repeatedly connects to the same unfamiliar destination at regular or near-regular intervals.

This can indicate beaconing, particularly when the pattern is associated with a suspicious process.

However, software update services, monitoring agents, and cloud applications also generate periodic traffic.

Investigation focus: Compare the connection pattern with known application behaviour and correlate it with endpoint telemetry.

2. Suspicious DNS activity

A device repeatedly queries an unusual domain or generates DNS requests with patterns that differ from normal activity.

Some threats use DNS to locate C2 servers, while others abuse DNS for tunnelling or other communication.

Investigation focus: Examine queried domains, query types, response patterns, NXDOMAIN rates, record lengths, and the process or host generating the requests.

Unusual DNS behaviour is a clue, not proof of malicious communication.

3. Unusual HTTPS connections

An endpoint may establish encrypted connections to a destination that has no clear business purpose.

Encryption protects legitimate users, but it can also prevent network monitoring tools from directly inspecting application content.

Investigation focus: Review destination reputation, certificate information where available, connection timing, SNI or other visible metadata where applicable, and the initiating process.

A valid TLS certificate does not guarantee that a destination is trustworthy.

4. Unexpected network destinations

A workstation or server communicates with an unfamiliar IP address, domain, hosting provider, or geographic region.

The destination may have little relationship to the host's normal business function.

Investigation focus: Validate the destination using approved threat-intelligence sources and examine whether other endpoints are communicating with it.

IP ownership, hosting location, and reputation should be treated as contextual evidence rather than definitive attribution.

5. Unusual data-transfer patterns

An endpoint sends or receives data in a way that differs from its normal baseline.

Examples include unexpected outbound transfers, repeated small exchanges, or communication occurring at unusual times.

Investigation focus: Compare the volume, direction, timing, and destination of traffic with normal host behaviour. Determine whether the activity could represent command exchanges, payload retrieval, or data exfiltration.

5. How SOC Analysts Investigate Potential C2 Communication

A structured investigation should establish which process generated the traffic, whether the destination is suspicious, and whether the activity is linked to a compromised host.

Step 1: Validate the alert

Review the original network or EDR alert and record:

• Source hostname and IP address.

• Destination IP address and domain.

• Protocol and destination port.

• First-seen and last-seen timestamps.

• Connection frequency and duration.

• Bytes sent and received.

• Initiating process and user, where available.

• Related threat-intelligence indicators.

Determine whether the alert is based on known malicious infrastructure, suspicious network behaviour, or an anomaly detected by a monitoring rule.

Step 2: Investigate the destination

Check the domain and IP address against trusted threat-intelligence sources.

Review historical observations, reputation, passive DNS information where available, and any related security reports.

Consider whether the destination belongs to a legitimate service used by the organisation.

Do not classify a connection as malicious solely because the destination is unfamiliar, hosted in a particular country, or has a low reputation score.

Step 3: Examine the connection pattern

Review network flow records, firewall logs, DNS telemetry, and proxy data.

Determine whether the host connects repeatedly to the same destination and whether the timing, session duration, and traffic volume differ from its normal baseline.

Look for related connections to other destinations that might indicate infrastructure changes or additional stages of the attack.

Step 4: Identify the initiating process

Use EDR or endpoint network telemetry to determine which process established the connection.

Investigate the process path, executable hash, parent process, user context, signing information, and start time.

For example, recurring connections from an unexpected script interpreter or unfamiliar executable may warrant closer examination than the same pattern from a known enterprise management agent.

The process name alone is not conclusive. Legitimate applications can be abused, and malicious software can use familiar process names.

Step 5: Correlate DNS and network evidence

Determine whether DNS queries immediately preceded the suspicious connections.

Review the queried domains, resolved IP addresses, query frequency, and response details.

Check whether the host communicates directly with an IP address or uses a domain that resolves to changing infrastructure.

If DNS tunnelling is suspected, examine query lengths, subdomain patterns, query volume, and response behaviour alongside other evidence.

Step 6: Investigate endpoint behaviour

Examine activity around the first suspicious connection.

Look for:

• Unusual process execution.

• Newly created files or scripts.

• Unexpected persistence mechanisms.

• Credential-access alerts.

• Security-control modifications.

• Suspicious file transfers.

• Connections to additional internal or external systems.

The objective is to connect the network activity to a possible initial compromise and identify any subsequent actions.

Step 7: Establish the scope

Search network and endpoint telemetry for other devices communicating with the same domain, IP address, certificate, or other relevant indicator.

Determine whether the event is isolated or part of a broader campaign.

Use shared indicators carefully. Common cloud hosting and content-delivery infrastructure may support both legitimate and malicious services.

Step 8: Contain and remediate

If the investigation confirms malicious C2 activity, follow the organisation's incident response procedures.

Actions may include isolating the affected endpoint, blocking confirmed malicious destinations, disabling compromised accounts, preserving forensic evidence, and identifying persistence mechanisms.

Blocking one IP address may be insufficient if the malware can switch destinations or use additional infrastructure.

Remove the root cause, recover the system through approved procedures, and monitor for renewed communication.

6. Example SIEM Queries for C2 Investigation

These examples provide starting points for identifying potentially suspicious communication. Adapt the field names and time windows to your data sources.

Splunk: Find repeated outbound connections

Assuming your network telemetry contains src_ip, dest_ip, and dest_port fields:

index=network earliest=-24h | stats count as Connections dc(dest_port) as UniquePorts sum(bytes_out) as BytesOut sum(bytes_in) as BytesIn min(_time) as FirstSeen max(_time) as LastSeen by src_ip dest_ip | where Connections > 20 | sort - Connections

This query highlights source-destination pairs with repeated connections. The threshold is illustrative and should be tuned to the environment.

Repeated connections alone do not establish C2 activity.

Splunk: Investigate DNS query patterns

Assuming DNS records are indexed with query and src_ip fields:

index=dns earliest=-24h | stats count as QueryCount dc(query) as UniqueDomains values(query) as Domains by src_ip | sort - QueryCount

Use this as an initial overview, then filter for the host and suspicious domains identified in the alert. High DNS volume can also be caused by legitimate applications.

Microsoft Sentinel: Review network connections

For environments where network telemetry is available in the DeviceNetworkEvents table:

DeviceNetworkEvents | where Timestamp > ago(24h) | project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemotePort, RemoteUrl, ActionType | order by Timestamp desc

This query provides a starting point for examining device network activity and the process responsible for each connection, where those fields are populated.

Investigation tip: Begin with the source device and destination from the alert. Expand the search only after establishing the relevant timeline, process context, and baseline.

7. Indicators and Evidence to Look For

Potential C2 activity should be assessed using multiple evidence sources.

Evidence sourceWhat to investigateFirewall and NetFlow logsRepeated outbound connections, unusual destinations, and traffic volumesDNS logsSuspicious domains, unusual query patterns, and unexpected resolutionsProxy logsURL requests, redirects, and outbound web communicationTLS metadataAvailable certificate, SNI, and connection detailsEDR telemetryInitiating process, command line, parent process, and related file activityThreat intelligenceKnown malicious infrastructure and related indicatorsEndpoint and identity logsSuspicious execution, account activity, and post-compromise behaviour

No single indicator confirms C2. A strong conclusion connects network evidence with process behaviour and other signs of compromise.

8. MITRE ATT&CK Mapping

The following techniques may be relevant when supported by the evidence collected during the investigation.

TechniqueIDRelevanceApplication Layer ProtocolT1071C2 communication using application-layer protocolsWeb ProtocolsT1071.001C2 using HTTP or HTTPSDNST1071.004C2 communication using DNSEncrypted ChannelT1573Encrypted communication used to conceal C2 trafficIngress Tool TransferT1105Downloading tools or files into a compromised environmentProxyT1090Using proxy infrastructure to relay communicationNon-Standard PortT1571Using unexpected ports for communication

These mappings describe possible behaviours. They should not all be assigned to an incident unless the relevant activity is observed.

9. How Organisations Can Detect and Prevent C2 Activity

Centralise network and endpoint telemetry. Collect firewall, DNS, proxy, EDR, and relevant cloud network logs in a central monitoring platform.

Establish normal baselines. Understand which external services and communication patterns are expected for each type of endpoint.

Monitor recurring connections. Detect unusual beacon-like patterns, particularly when they originate from suspicious processes or newly observed destinations.

Use threat intelligence carefully. Enrich alerts with reliable indicators while accounting for shared hosting, changing infrastructure, and false positives.

Restrict unnecessary outbound access. Apply appropriate egress filtering and proxy controls to reduce the destinations systems can contact.

Protect endpoints. Use EDR, application controls, patching, and least-privilege access to reduce the likelihood and impact of initial compromise.

Investigate DNS anomalies. Monitor unusual query patterns, suspicious domains, and potential tunnelling behaviour.

Correlate multiple signals. Combine network anomalies with process execution, file changes, authentication events, and known malicious indicators.

Maintain an incident response plan. Define when to isolate a host, block a destination, preserve evidence, and escalate to incident response teams.

10. Lessons for Modern SOC Teams

C2 detection is a correlation problem. A suspicious destination, recurring connection, or unusual DNS query may be benign when examined independently.

The investigation becomes more meaningful when network behaviour can be connected to a process, a user, a suspicious file, or an earlier security event.

SOC teams should also distinguish between detecting possible C2 communication and confirming that a system is compromised. The former justifies investigation; the latter requires sufficient supporting evidence.

Finally, containment must account for the broader intrusion. Blocking a destination may interrupt communication, but it does not automatically remove malware, revoke compromised credentials, or eliminate persistence.

Conclusion

Potential C2 communication can provide an early warning that a compromised system is communicating with attacker-controlled infrastructure. However, because attackers and legitimate applications both use common network protocols, reliable detection requires more than identifying unusual traffic.

By correlating DNS activity, network connections, process telemetry, threat intelligence, and post-connection behaviour, SOC analysts can establish whether the activity is malicious, identify affected systems, and support effective containment.

The key lesson: Investigate the connection, the process that created it, and the activity that followed. Network anomalies become actionable when they are connected to evidence of an intrusion.

Further Reading

• MITRE ATT&CK — Command and Control tactics and techniques.

• CISA — Guidance on detecting and responding to network intrusions.

• Microsoft Learn — Defender endpoint network events and advanced hunting.