Endpoint detection has become so capable that network monitoring is sometimes treated as legacy. That is a mistake with a straightforward justification: endpoint telemetry only exists where an agent is installed, and a meaningful fraction of every real network cannot host one.
Printers, cameras, building management systems, network appliances, embedded medical and industrial devices, contractor laptops, personal phones — none run your EDR. Attackers know which devices are unmonitored, and those devices are frequently the initial foothold precisely because they are invisible to the control everyone relies on.
Network data has the opposite property. If it communicates, it is observable, regardless of what it is.
DNS: the highest value per byte
DNS query logs are the most useful network telemetry available relative to their volume and cost, because virtually every meaningful action begins with a name resolution.
Several detection patterns depend on it:
- Command-and-control beaconing. Implants resolve their controller on a schedule. The signature is not the domain but the regularity — queries at consistent intervals, often with small jitter, continuing outside working hours.
- Domain generation algorithms. Malware that computes candidate domains produces a characteristic pattern: many failed resolutions for high-entropy names, most returning NXDOMAIN, until one succeeds. The failures are the signal.
- DNS tunnelling. Data encoded into query names and answers, used to exfiltrate through a protocol nobody blocks. Indicators include abnormally long labels, very high query volume to a single domain, and unusual record types such as TXT or NULL in quantity.
- Newly registered and rare domains. A domain registered days ago and queried by exactly one host in the organisation is worth attention. Rarity is one of the strongest signals in security data.
Two practical cautions. Log at a point that preserves the originating client, not just the forwarder — a log showing every query came from the internal resolver is nearly useless for attribution. And account for encrypted DNS: DNS over HTTPS bypasses internal resolvers entirely, so policy should direct clients to approved resolvers and treat unexpected DoH endpoints as something to investigate.
Proxy and TLS metadata
Web traffic dominates outbound volume and therefore dominates exfiltration and C2. Even without decryption, the metadata is informative: destination, timing, request and response sizes, user agent, and the TLS handshake itself.
The Server Name Indication field in a TLS handshake reveals the intended hostname in clear text, which recovers much of what encryption otherwise hides. Certificate details — issuer, validity period, subject — add more, and self-signed or freshly issued certificates on unusual ports are worth noting.
Beaconing analysis works well here too. Human browsing is bursty and irregular; automation is not. Connections to one destination at near-constant intervals with similar payload sizes describe a machine, and if no legitimate agent explains it, that is the finding.
User-agent analysis retains value despite being trivially spoofable, mostly because attackers frequently do not bother. Default library user agents from scripting runtimes appearing in outbound web traffic are often the quickest way to spot tooling.
Flow data for the shape of the network
Flow records summarise conversations rather than contents: source, destination, ports, protocol, byte and packet counts, duration. They are cheap enough to retain for long periods, which makes them the practical basis for historical investigation.
Their strength is structural analysis. Internal reconnaissance appears as one host connecting to many on the same port in a short window. Lateral movement appears as new server-to-server relationships that never previously existed. Exfiltration appears as an outbound transfer whose size is wildly inconsistent with that host’s baseline.
East-west visibility is the part most often missing. Perimeter-focused monitoring sees traffic leaving the network but not traffic between internal hosts, which is exactly where lateral movement occurs. In segmented and cloud environments, flow logs at the segment or VPC boundary are frequently the only record that an internal connection happened at all.
Flow and firewall analysis means constant CIDR arithmetic, and investigating a callback domain starts with its structure.
Detecting beacons properly
Because beaconing appears repeatedly above, it is worth stating the method rather than the description. For each source-destination pair, take the timestamps of connections over a window and compute the intervals between them. Then examine the distribution.
Human-driven traffic yields a wide, irregular spread. Automated callbacks yield a tight cluster around a central value, and remain tight even when the implant adds jitter, because jitter is usually a percentage of the interval rather than genuine randomness. A low coefficient of variation across many connections is the discriminator.
Then subtract the legitimate automation, which is substantial: update checks, telemetry, monitoring agents, certificate revocation checks. As with every technique in detection engineering, the baseline is the work. The output of the first run is a list of your own software; the output of the tenth is an alert worth investigating.
Where network detection is blind
Honesty about limitations prevents misplaced confidence.
- Encryption hides content. Metadata analysis is powerful but it is not the same as seeing the payload, and TLS interception carries real privacy, performance and compatibility costs that many organisations reasonably decline.
- Cloud and remote work mean traffic frequently never traverses a network you monitor. A laptop at home talking to a SaaS platform is invisible to on-premises sensors, which is why cloud-native and identity logs increasingly matter more than perimeter capture.
- Legitimate infrastructure abuse. C2 hosted on major cloud providers or routed through popular services blends with traffic you cannot block.
- Encrypted DNS removes visibility unless client resolver behaviour is controlled by policy.
These are arguments for combining sources rather than abandoning network data. Endpoint telemetry explains what a process did; network telemetry explains who talked to whom, including for the devices where no process telemetry exists at all.
Getting started sensibly
Full packet capture is the least practical starting point despite being the most complete: the storage cost is enormous and most of it is never read. Metadata scales far better.
A pragmatic order of adoption is DNS query logs with client attribution first, because the value per gigabyte is unmatched. Then proxy or TLS metadata for outbound web traffic. Then flow records, prioritising east-west and cloud segment boundaries. Retention should be measured against realistic dwell time, since the common investigative question is what a host was doing two months ago.
The recurring theme is that network detection is a rarity and regularity exercise. Malicious traffic is rarely distinguished by its content, which is encrypted, but by being unusual for that host, or too regular to be human. Both are questions the data can answer once you know what normal looks like.
Building the baseline
Every technique described here depends on knowing what normal looks like, and that knowledge has to be constructed deliberately rather than assumed. The questions worth answering before writing detections are concrete: which internal hosts normally initiate outbound connections, and which never should? Which destinations does the estate contact routinely? What does the daily volume profile look like, and how does it differ overnight and at weekends? Which protocols are expected on which segments?
Servers are the easiest starting point because their behaviour is narrow and stable. A database server that has contacted three internal hosts and one update endpoint for six months is trivial to baseline, and any deviation is meaningful. Workstations are noisier, which is why grouping by role or department and comparing a host against its peers works better than comparing it against a global average.
Write the baseline down. The list of explained-benign destinations and automated connections is the artefact that makes every subsequent detection tunable, and reconstructing it from memory during an incident is exactly when you cannot afford to.
A worked case: spotting exfiltration
Exfiltration is where network data outperforms endpoint telemetry most clearly, because the endpoint sees a process writing to a socket while the network sees the shape of the transfer. The signals compose rather than standing alone.
Volume asymmetry comes first: most hosts download far more than they upload, so a sustained outbound transfer substantially larger than that host’s norm is the initial filter. Destination novelty narrows it — a large upload to a cloud storage provider the organisation does not use, or to a domain registered recently. Timing sharpens it further, since transfers beginning outside working hours and running for hours suggest automation rather than a person.
Then rule out the mundane. Backup jobs, log shipping, telemetry and legitimate cloud sync all produce large outbound transfers, and every one of them will appear in the first run of this analysis. That is the baseline work again, and it is why the technique becomes useful on the tenth iteration rather than the first.
Note also that a competent adversary will throttle transfers to stay under volume thresholds and use a destination that blends with legitimate traffic. Volume alone is a weak detection; volume combined with novelty and timing is a reasonable one.
Combining network with endpoint and identity
The three telemetry domains answer different questions, and an investigation usually needs all three. Network data reveals that a host contacted an unusual destination on a schedule. Endpoint data reveals which process did it and what its parent was. Identity data reveals which account was authenticated at the time and where else it has been used.
The practical implication is that correlation identifiers matter. Ensuring hostnames, IP address assignments and user sessions can be joined across sources — including through DHCP and VPN lease records, so an address can be resolved to a host at a point in time — is unglamorous plumbing that determines whether correlation takes minutes or is impossible.
Retention and sizing
Volume anxiety is the usual reason network logging is not implemented, and it is largely a selection problem. Full packet capture is enormous and rarely read. DNS query logs are small and read constantly. Flow records sit between the two and compress well.
A workable approach is tiered: keep metadata — DNS, flow, proxy and TLS handshake details — for months, because that is what historical investigation requires, and keep full capture only at specific chokepoints for days, as a short-term forensic buffer. Retention should be set against realistic dwell time rather than against convenience, since the question during an incident is almost always about a period longer ago than anyone planned for.