Detecting command-and-control traffic at the network layer: a practical guide for UK SMEs

Command-and-control traffic, often shortened to C2, is the communication channel an attacker uses after gaining a foothold. It is how compromised hosts receive instructions, exfiltrate data, or check in for updates. For many SMEs, the challenge is not whether this traffic exists, but whether the organisation can see it quickly enough to act on it.

Network-layer detection is valuable because it can expose activity that endpoint tools miss, especially when malware is fileless, living off the land, or running under legitimate processes. It also gives defenders a view across unmanaged or partially managed devices, guest networks, and cloud egress paths. The aim is not to inspect every packet in detail. It is to collect enough telemetry to identify suspicious patterns, reduce dwell time, and support triage.

What command-and-control traffic looks like in practice

In real environments, C2 traffic rarely looks dramatic. It often blends into normal business traffic by using HTTPS, common ports, or public cloud infrastructure. The useful indicators are usually behavioural rather than signature-based.

Common network-layer indicators: beaconing, unusual DNS, periodic HTTPS, and rare destinations

Beaconing is one of the most common patterns. A host connects out at regular intervals, often with small and consistent payload sizes. The timing may be every 30 seconds, every five minutes, or another repeatable pattern. The destination may be a domain that has little or no business justification.

DNS can also reveal suspicious behaviour. Examples include:

• High volumes of queries for newly registered or low-reputation domains
• Long or unusual subdomains that may indicate encoded data
• Frequent lookups for domains that resolve to changing IP addresses
• Repeated NXDOMAIN responses, which can suggest algorithmically generated domains or failed lookups

Periodic HTTPS traffic is another clue. A workstation that makes small, regular HTTPS requests to a rare destination, especially outside expected business applications, deserves attention. The same applies to outbound connections to infrastructure that is unusual for the device role, such as a finance laptop talking to a hosting provider with no obvious business reason.

How command-and-control differs from normal remote access and SaaS traffic

Not all regular outbound traffic is suspicious. Remote management tools, collaboration platforms, software update services, and SaaS applications also generate periodic connections. The difference is context. Legitimate services usually have known destinations, stable certificate chains, predictable user-agent patterns, and clear business ownership.

By contrast, C2 often shows one or more of the following:

• Rare or newly observed destinations
• Connections from endpoints that do not normally talk externally at that cadence
• Traffic that continues outside business hours without a clear reason
• Multiple hosts contacting the same low-reputation infrastructure
• Inconsistent or oddly small request and response sizes

Where network-layer detection fits in a layered defence model

Network detection should not be treated as a standalone control. It works best when combined with endpoint telemetry, identity logs, and asset context. A suspicious connection is much easier to assess when you know which user was logged in, whether the endpoint is managed, and what software is installed.

Relationship to endpoint telemetry, identity logs, and NDR

Endpoint telemetry can show the process that created the connection, the parent process chain, and whether a script or binary was involved. Identity logs can show whether the user account was recently used from another location, whether MFA prompts were triggered, or whether there was unusual sign-in behaviour. Network Detection and Response, or NDR, adds flow analysis, protocol metadata, and behavioural analytics across the wire.

For a small team, the practical model is simple: use network telemetry to spot the pattern, endpoint telemetry to identify the process, and identity data to understand who or what initiated the activity. That combination is often enough to decide whether an alert is benign, suspicious, or high priority.

Mapping the problem to MITRE ATT&CK techniques and detection coverage

MITRE ATT&CK is useful here because it gives a common language for adversary behaviour. C2 activity maps to techniques such as Application Layer Protocol, Proxy, Domain Generation Algorithms, and Encrypted Channel. You do not need to map every alert to ATT&CK in detail, but it helps to understand which techniques your detections cover and where the blind spots are.

For example, if your controls only look for known bad IP addresses, you may miss encrypted C2 over trusted cloud services. If you only inspect endpoints, you may miss unmanaged devices or traffic that never reaches the endpoint agent. A layered view improves coverage and makes gaps easier to explain to stakeholders.

Telemetry sources that matter most

SMEs rarely have the luxury of collecting everything. The best approach is to prioritise telemetry that is easy to obtain, useful for triage, and low enough in volume to manage.

DNS logs, proxy logs, firewall logs, NetFlow, and TLS metadata

DNS logs are often the highest-value starting point. They show what names endpoints are trying to resolve, how often they are queried, and whether the responses look unusual. Proxy logs add URL and user context where web traffic is forced through a gateway. Firewall logs provide source, destination, port, and allow or deny decisions. NetFlow or similar flow records are useful for spotting timing, volume, and destination rarity across the network. TLS metadata, including server name indication and certificate details, helps when content is encrypted.

Each source has limitations. DNS logs may not show encrypted DNS or direct IP connections. Proxy logs may miss traffic that bypasses the proxy. Firewall logs can be noisy and often lack application context. NetFlow does not show content. TLS metadata is helpful, but only if it is collected consistently and enriched with asset and threat intelligence data.

What to collect first when resources are limited

If resources are tight, start with DNS, firewall, and proxy logs, then add NetFlow if your environment supports it. These sources provide a strong baseline for outbound detection without requiring full packet capture. Make sure timestamps are synchronised with NTP, because timing analysis depends on accurate clocks.

It is also worth collecting basic asset context: hostname, IP address, device owner, operating system, and whether the endpoint is managed. Without that, even good detections become harder to triage.

Detection approaches that work for small security teams

Small teams need detections that are explainable, maintainable, and low on false positives. Behavioural rules are usually more useful than static indicators alone.

Beaconing detection using timing, volume, and destination rarity

Beaconing detection can be built from flow records or proxy logs. Look for repeated connections from the same host to the same destination at regular intervals, especially when the payload sizes are small and consistent. A simple approach is to calculate inter-arrival times and flag destinations with low variance over a window such as one hour or one day.

Destination rarity matters as well. If only one or two hosts in the estate contact a domain, and there is no obvious business reason, that traffic is worth reviewing. Rarity is especially useful when combined with low volume and regular cadence.

In a SIEM, this might be implemented as a scheduled query that groups by source host and destination, calculates count, average interval, and standard deviation, then filters on low variance and low historical prevalence. In an NDR platform, the same logic may already exist as a behavioural model.

Domain age, reputation, and DNS anomaly checks

Domain age can be a useful enrichment field. Newly registered domains are not automatically malicious, but they are more suspicious when they appear in outbound traffic from endpoints that do not normally contact them. Reputation feeds can help, though they should not be the only decision point because attackers often use infrastructure that is not yet flagged.

DNS anomaly checks should look for:

• Unusually long query names
• High entropy subdomains
• Repeated TXT lookups where that record type is not normally used
• Frequent queries to domains with no prior history in the estate

These checks are best treated as triage signals rather than proof of compromise.

TLS and encrypted traffic analysis without breaking privacy or operations

Most C2 traffic is encrypted, so defenders need to extract value from metadata rather than content wherever possible. This is usually enough to identify suspicious patterns without decrypting everything.

Using SNI, certificate attributes, JA3 or JA4-style fingerprints, and flow metadata

Server Name Indication, or SNI, can reveal the hostname requested during TLS negotiation. Certificate attributes such as issuer, subject, validity period, and subject alternative names can help identify unusual or self-signed infrastructure. JA3 and JA4-style fingerprints summarise TLS client behaviour and can be useful for clustering similar traffic patterns across hosts.

Flow metadata remains important. Connection duration, bytes sent and received, session frequency, and destination port all help build a picture. A short-lived TLS session that repeats every few minutes and sends very little data may be more interesting than a long, user-driven web session.

Practical limits of inspection and how to avoid overreliance on decryption

Full TLS interception can create operational and privacy overhead, and it is not always appropriate. It can also break applications if certificates, pinning, or modern protocols are not handled correctly. For many SMEs, the better approach is selective inspection combined with strong metadata collection.

Do not assume that decryption is required for useful detection. In practice, many C2 detections are built from metadata, reputation, and behaviour. If you do deploy TLS inspection, apply it where the business case is strongest, document the scope carefully, and test application compatibility before broad rollout.

Building useful detections in a SIEM or NDR platform

Whether you use Microsoft Sentinel, another SIEM, or an NDR tool, the same design principles apply. Start with a small number of high-signal use cases and tune them against your own traffic patterns.

Example logic patterns for Sigma, KQL, or vendor analytics

A practical detection pattern might look like this:

• Identify outbound connections from endpoints to rare domains or IPs
• Group by source host and destination over a fixed time window
• Calculate connection frequency, average interval, and byte counts
• Enrich with DNS age, certificate details, and asset criticality
• Alert when the pattern is both periodic and uncommon for the environment

In KQL, you might query DNS or proxy logs for repeated lookups or connections, then join to asset tables and threat intelligence. In Sigma, you would usually express the underlying event pattern and let the SIEM backend handle the translation. In vendor analytics, look for rules that support behavioural thresholds rather than only IOC matching.

Tuning thresholds to reduce false positives from legitimate polling and updates

False positives are common when you first deploy beaconing detections. Software updates, endpoint management tools, backup agents, and monitoring systems often poll on a schedule. The answer is not to suppress everything. It is to build allowlists carefully and based on evidence.

Use a staged tuning process:

1. Run detections in alert-only mode and review the top talkers
2. Tag known-good services with business owners and justification
3. Exclude stable, documented infrastructure where appropriate
4. Keep a short review cycle for new destinations and new device types

Be cautious with broad exclusions such as entire cloud providers or all HTTPS traffic. Those shortcuts usually hide more than they solve.

Validation and threat hunting workflow

Detections are only useful if they can be validated and investigated efficiently. The goal is to move from alert to decision with minimal guesswork.

How to test detections safely using benign simulations and lab traffic

You do not need exploit traffic to validate a C2 detection. Safe testing can be done with benign lab hosts, controlled scripts that generate periodic outbound connections, or test domains you own. The point is to confirm that the detection fires on the intended pattern and not on unrelated traffic.

When testing, vary the interval, destination, and protocol so you can see how the rule behaves. Record the expected outcome, the actual alert, and any tuning changes made afterwards. This creates a useful feedback loop for future detection work.

How to investigate alerts and confirm whether traffic is suspicious

A good investigation starts with context. Check the source host, logged-on user, process lineage if available, and whether the destination is known to the business. Review whether the traffic is new, rare, or inconsistent with the device role. Look for supporting evidence in endpoint and identity logs, such as unusual process execution, failed sign-ins, or lateral movement indicators.

If the traffic is suspicious, contain the host according to your incident response process, preserve relevant logs, and avoid making changes that destroy evidence unless there is an immediate operational need. If it is benign, document why and feed that knowledge back into the detection logic.

Operational pitfalls and blind spots

Several common issues reduce the value of network-layer detection.

CDNs, cloud services, split tunnelling, and remote work edge cases

Content delivery networks and cloud platforms can make destinations look less meaningful than they are. Many legitimate services share infrastructure, so a single IP address may host both benign and suspicious traffic. Split tunnelling can also bypass central monitoring when remote users connect directly to the internet. Remote work adds another layer of complexity because home networks and personal devices may introduce noise or hide traffic from corporate controls.

These are not reasons to abandon network detection. They are reasons to make sure your visibility model matches how people actually work.

Why network detections fail when asset inventory and baselines are weak

Without a reliable asset inventory, it is hard to know whether a connection is unusual. Without a baseline, it is hard to tell whether a pattern is rare. Network detections become much more effective when you know which devices are servers, laptops, kiosks, or specialist systems, and when you understand their normal outbound behaviour.

That is why network detection should be linked to configuration management, endpoint management, and identity governance rather than treated as a separate island.

A pragmatic implementation roadmap for UK SMEs

For most UK SMEs, the best route is incremental. Start with the telemetry you already have, then add use cases that improve visibility without overwhelming the team.

1. Confirm what DNS, proxy, firewall, and flow logs you can already collect
2. Normalise timestamps and enrich events with hostname, user, and asset data
3. Build one or two high-value detections, such as beaconing and rare destination alerts
4. Document expected benign patterns for update services, remote access, and backup tools
5. Review alerts weekly at first, then adjust thresholds and exclusions based on evidence
6. Track false positives, time to triage, and the number of alerts that led to useful action

Over time, you can expand into TLS fingerprinting, domain age enrichment, and ATT&CK mapping. The important thing is to keep the detections operationally manageable. A small number of well-tuned rules is usually better than a large library of noisy ones.

If you are building or improving this capability, it can help to review your logging architecture, endpoint telemetry, and response workflow together rather than in isolation. That is often where the biggest gains in detection quality come from.

Frequently asked questions

What network logs are most useful for detecting command-and-control traffic? DNS logs, proxy logs, firewall logs, NetFlow, and TLS metadata are the most useful starting points. DNS and proxy logs provide name and URL context, firewall and flow logs show connection patterns, and TLS metadata helps when traffic is encrypted.

How can encrypted traffic still be analysed for suspicious command-and-control behaviour? Even when content is encrypted, you can still analyse SNI, certificate attributes, connection timing, destination rarity, byte counts, and TLS fingerprints such as JA3 or JA4-style data. In many cases, those signals are enough to identify suspicious behaviour without decrypting the session.

For UK SMEs that want help shaping a practical detection strategy, a consultant can help prioritise telemetry, tune use cases, and align the work with wider security operations and ISMS objectives.

Further reading

MITRE ATT&CK, Enterprise matrix, techniques related to command and control: useful for mapping detections to adversary behaviour and identifying coverage gaps.