How NDR Detects Command-and-Control Traffic

How NDR Detects Command-and-Control Traffic 

C2 appears as outbound traffic to the internet, or may also be connected to internal scanning, lateral movement, credential abuse, staging, or peer-to-peer communication. Since NDR continuously monitors traffic across north-south and east-west paths, it can detect command-and-control traffic.  

A strong NDR approach usually combines several detection methods. 

1. Detecting Beaconing Patterns

Beaconing is one of the classic C2 behaviors. 

A compromised host may contact the attacker infrastructure every few seconds, minutes, or hours to check in for instructions. Sometimes the interval is very regular. Sometimes it includes jitter to make the timing less obvious. 

NDR can identify suspicious beaconing by looking for: 

• repeated outbound connections from the same host, 
• regular or semi-regular timing intervals, 
• small but persistent data transfers, 
• repeated contact with rare destinations, 
• unusual communication outside business hours, 
• similar session sizes over time, 
• low-volume traffic that persists for days, 
• connections that do not match the asset’s normal role. 

A single outbound connection may not look malicious. A workstation contacting an unknown external domain every 10 minutes for two days is different. That pattern gives analysts something worth investigating. 

This is where network security monitoring helps. It gives the SOC enough historical context to understand whether a connection is normal, rare, new, or suspicious for that host. 

2. Analyzing DNS for C2 Indicators

Attackers use DNS because it is widely allowed, easy to blend into, and often under-monitored compared with web traffic; therefore, it is one of the most useful places to hunt C2. Some C2 channels use DNS only to resolve attacker infrastructure. Others use DNS more aggressively for tunneling, staging, or command exchange. 

NDR can support DNS-based C2 traffic detection by identifying: 

• unusual DNS query volume, 
• long or encoded-looking subdomains, 
• repeated queries to rare domains, 
• high NXDOMAIN activity, 
• newly observed domains, 
• DNS requests to unauthorized resolvers, 
• domain generation algorithm patterns, 
• suspicious TTL behavior, 
• DNS tunneling indicators, 
• internal systems resolving domains they have never contacted before. 

For example, a server that rarely makes external DNS requests but suddenly starts resolving long, random-looking domains should get attention. The same applies to workstations that generate repeated failed lookups across many algorithmic-looking domains. 

DNS does not prove C2 by itself. But it often gives threat hunters an early thread to pull. 

3. Inspecting HTTP, HTTPS, and TLS Behavior

A lot of C2 traffic hides inside web traffic because web traffic is everywhere. 

An attacker does not need the connection to look perfect. It only needs to look boring enough to avoid immediate attention. That is why network threat detection has to inspect more than destination IPs. 

NDR can examine HTTP, HTTPS, and TLS metadata for signs such as: 

• rare or suspicious user agents, 
• unusual URI structures, 
• odd HTTP methods, 
• abnormal header combinations, 
• suspicious GET and POST patterns, 
• strange client-server byte ratios, 
• repeated connections to low-reputation infrastructure, 
• TLS certificate anomalies, 
• self-signed or newly issued certificates, 
• mismatched SNI and certificate details, 
• unusual JA3 or JA4 fingerprints, 
• protocol and port mismatches, 
• session duration anomalies. 

This is especially useful when payloads are encrypted. Even without decrypting the content, analysts can still evaluate how the session behaves. 

4. Building a Baseline of Normal Network Behavior

C2 detection improves when the SOC understands what “normal” looks like. 

Not every rare connection is malicious. Not every periodic connection is beaconing. Not every new domain is suspicious. Context matters. 

NDR solutions use behavioral analytics to compare current activity against normal network behavior for users, hosts, servers, applications, peer groups, and destinations. 

This helps flag activity such as: 

• a workstation communicating with infrastructure it has never contacted before, 
• a database server initiating unusual outbound web sessions, 
• a domain controller making unexpected external connections, 
• a user device contacting rare destinations after a suspicious login, 
• a server using protocols outside its normal role, 
• an internal asset suddenly behaving like a relay or proxy. 

This is where advanced threat detection becomes more practical. The SOC is not just asking, “Is this known bad?” It is asking, “Is this behavior normal for this asset, at this time, in this environment?” 

That distinction is important because unknown C2 infrastructure will not always appear in threat intelligence feeds immediately. 

5. Correlating Threat Intelligence With Network Evidence 

Threat intelligence still matters. Known malicious IPs, domains, URLs, certificates, malware infrastructure, C2 framework patterns, and reputation signals can help NDR solutions identify active threats faster. 

But threat intelligence should not be the only layer. Attackers rotate infrastructure quickly. They use compromised servers. They host C2 in cloud environments. They customize tooling. They use newly registered domains or blend into legitimate services. 

A stronger model is layered: 

• signatures help catch known tooling, 
• threat intelligence helps identify suspicious infrastructure, 
• behavioral analytics helps detect unknown or modified activity, 
• packet and metadata evidence helps analysts validate the alert. 

6. Using Packet and Metadata Evidence to Validate the Alert

Once an alert fires, the SOC needs to know what happened. Did the host really communicate with C2 infrastructure? Was data transferred? Did the session include file movement? Was the traffic connected to lateral movement? Was it part of a larger attack path? 

That is why packet evidence and enriched metadata are valuable. A mature NDR workflow should help analysts answer: 

• Which host initiated the connection? 
• What destination did it contact? 
• Which protocol and application were used? 
• When did the activity begin? 
• How often did the host communicate? 
• How much data moved? 
• Were DNS queries involved? 
• Was the session encrypted? 
• Were there related internal connections before or after? 
• Did the same host show signs of scanning, authentication attempts, or data staging? 
• Is the behavior isolated or part of a broader threat detection and response workflow? 

Packet-level evidence is especially useful when the SOC needs confidence. Metadata can show the shape of the activity. Full packet capture, where available, can help reconstruct the session and validate what took place.