Phil Roberts, Giacomo Marchese | 7 October 2025 

Many organisations rely extensively on network logging and network security controls to form the basis of the security operations strategy. The challenge with this approach is that modern threats can occur without ever crossing the wire, or in cases where they do, they still primarily affect endpoints, identities, and cloud workloads. This means that from a threat detection perspective, significant context is lost if security operation centre (SOC) teams do not have access to high quality endpoint logs. In this blog, we will discuss the importance of host-based telemetry data and how it can be used to augment network logs for extended monitoring capabilities. We will also provide the primary use cases for network logs and guidance on using these two logs sources in conjunction to perform comprehensive investigations.

Conventionally, network monitoring and network security tools formed the bedrock of security operation strategies. Traditional network-centric approaches to security meant that threats posed to an organisation would manifest on the network, and therefore could be detect via network logs. However, with the rise of zero trust architecture and cloud IaaS / SaaS solutions, the effectiveness of network monitoring has diminished. This is because these technologies often operate outside the traditional network perimeter, making them difficult to secure and monitor with a network-centric approach. It also means that modern security breaches can occur without ever stepping over the wire. As such, much of the benefit derived from network monitoring can be achieved from comprehensive coverage of host-based monitoring and telemetry from the cloud and identity plane.

Modern security operations teams benefit the most from having access to a wide variety of high-quality log sources across all monitored domains. In many cases, threats that manifest on the network cannot be properly investigated without these associated log sources. Although a threat may involve the network, it will inevitably originate from an endpoint and involve communication with another endpoint. Thus, it is vital that security teams are equipped with all the necessary log sources to ensure that threats can be properly investigated and analysts are able to conclusively determine why we are observing certain activity on the network.

It is important to first understand how a compromise occurs and what the primary mission statement of a SOC is:

1. The aim of threat actors is to compromise organisations and extract data or disrupt operations. This will necessarily involve device and/or identity compromises.

2. This objective is achieved via successive device and identity compromises until a threat actor is positioned to enact their objectives. In other words, a threat actor does not "progress through the network" - instead, they progress through assets, each of which produces their own log sources.

Thus for SOCs, our goal is to protect these assets, not to merely "protect the network."

Consider the primary use cases for network logs in threat detection, and all will involve other assets:

1. Data exfiltration detection: A key benefit of network logs is the ability to analyse network flows for signs of data exfiltration. Usually this is performed by identifying anomalies between traffic volume and source and destination hosts. For a threat actor to exfiltrate data, they would have had to compromise a device or an identity with access to said data. If a SOC receives an alert for potential data exfiltration, they would not be able to investigate why or how this data was exfiltrated without optics into the host that performed this upload.

2. C2 communication detection: network logs are used extensively in identifying potential C2 traffic, primarily by relying on temporal and frequency analysis, packet inspection, or non-standard communication patterns. However, they do not take into account the process initiating these communications. If a device is beaconing to a C2 server, this would imply the device is compromised. Without access to host-based optics, SOC teams would have no means to determine the nature of the communication or why it is occurring in the first place. For example, a non-signed svchost.exe binary connecting to an unfamiliar IP is a dead giveaway that something suspicious is going on, but this context is not available without endpoint logs.

3. Sniffing, spoofing, and protocol relay attack detection: intrusion detection tools rely on packet inspection to identify these attacks. For example NTLM relays can be identified by inspecting NTLM packet flows. However, these attacks will always have second order effects on the hosts they are targeting. Going back to the NTLM relay example, this would be detected via logon events on Domain Controllers. Even if the NDR detected a potential relay attack, SOC teams would still require endpoint and other identity logs to determine the second-order effect and whether or not the attack was successful.

4. Rogue device discovery: Network logs are highly useful for detecting rogue devices on the network. This is typically achieved via analysing the headers of network packets. That said, even if a rogue device is discovered, any activity performed by that host will be against other devices in the network, and thus for a SOC to determine the nature of the rogue device, they must analyse other hosts looking for second-order effects.

While there are use cases for network logs, there are also a lot of examples of modern threats that are almost impossible to detect via network logs alone. The past year has seen an incredible rise in Infostealer infections (https://redcanary.com/blog/threat-detection/2025-threat-detection-report/ ), as threat actors continually focus their efforts on compromising identities. This also coincided with the rise of the ClickFix initial access technique, where victims are coerced into executing a malicious PowerShell command on their device. These infections manifest with little presence on the network, typically via users executing a malicious script or file, followed by the infostealer dumping credentials from browser cache files and exfiltrating this to a C2 domain sitting behind CloudFront. This results in almost no network-based signatures to leverage for threat detection.

To further evade network detection and blocking, threat actors also abuse high-reputation cloud/CDN infrastructure and short-lived DNS patterns (such as fast-flux(https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-093a) and domain generating algorithms), hosting malicious content on benign but compromised websites (such as compromised WordPress sites), and staging malicious content behind Cloudfront. These strategies are not just limited to infostealers, but C2 domains and malware distribution in general. Threat actors are progressively relying on benign or business-critical services to host C2 infrastructure, such as malware that interacts with Microsoft Graph API (https://www.security.com/threat-intelligence/graph-api-threats), AWS Lambda (https://unit42.paloaltonetworks.com/windows-backdoor-for-novel-c2-communication/), LLM APIs (https://www.picussecurity.com/resource/blog/lamehug-the-first-publicly-documented-case-of-a-malware-integrating-a-llm), and even benign applications like Steam (https://asec.ahnlab.com/en/80795/) or Discord (https://blog.checkpoint.com/security/using-discord-infrastructure-for-malicious-intent/). This makes detection via the firewall extremely difficult, as there is nothing inherently malicious about these domains. Ask yourself how many hosts in your network are currently connecting to Microsoft Graph endpoints, CloudFront domains, or AWS services – there is nothing from the network context alone that you could confidently rely on to determine that any of those connections are malicious. To identify the malicious activity requires analysis behaviour on the host, which is impossible without relevant host-based telemetry.  

Let's run through a real-world examples of where malicious activity was identified via the network, but the disposition was ultimately determined by host-based optics.

Over the past few years, Fortian SOC analysts have had their fair share of run ins with "unknown devices pinging the network". While these triggered alarms when viewed solely through firewall logs, in most cases they were ultimately harmless.  

For example, a recent case raised to Fortian began with firewall alerts about an "unknown" device pinging the network continuously for several hours. Viewed through the firewall context alone, an analyst typically gets only a few key data points, such as: source IP, destination IP and if the traffic is on the same L2 segment, a physical MAC address - this is nowhere near enough to explain what's actually happening without endpoint telemetry. However, to the business, the prospect of a rogue device scanning the entire network and multiple network security tools lighting up like a Christmas tree is necessarily very concerning.  

During this investigation, since Fortian had access to device telemetry for [customer], we were able to correlate the "unknown" devices' source IP, and MAC address to activity occurring from an onboarded device in Defender. C2..? No. DDOS...? No. Network discovery...? No. In the end, the "unknown" device that was flagged by firewall alerts, initial investigating analysts, and a third-party SOC teams as a malicious device, that had breached the customers perimeter, and was activity scanning/pinging the network as its post initial access reconnaissance... was a USB-C docking station.

Since we were able to use Defender for Endpoint telemetry, specifically under the DeviceNetworkEvent log table, which includes network level context for Source/Destination MAC addresses. Then, taking the MAC address that was flagged under the firewall logs as belonging to the seemingly malicious device, we were then able to correlate this to a specific devices' network events through DfE data. After making this correlation, we were able to union other useful device tables such as DeviceProcessEvents, DeviceFileEvents and DeviceRegistryEvents, giving us insight on parent processes for the outbound network activity as well other useful information such as UsbMount operations, Plug and Play events as well as parent process signatures. Ultimately, this allowed us to confidently determine that not only was this host not a rogue device, pinging the network in a perimeter breach scenario, but a docking station that had been connected to an onboarded device, had its own assigned MAC address, and routed network activity through its own independent network card.  

Furthermore, Fortian also investigated prior/historical device activity, where we found evidence of relevant driver installations that had occurred alongside the initial use of this docking station, ultimately allowing us to definitively determine the nature behind this network pinging host. Since we were able to utilise endpoint telemetry during this investigation, we were also able to use this for further investigation into any subsequent device activity that otherwise may have indicated compromise. In this instance, we saw no evidence of any malicious software being run/installed on the device, no evidence of any sort of persistence activity (e.g run keys, registry modifications or files added to startup), we saw no evidence of any lateral movement activity at all, and most importantly, we were able to ultimately conclude that there was no evidence to suggest that this device was communicating with any sort of external C2 server. This example not only re-iterates the importance of endpoint logs, not only to enrich investigations, but also how much time endpoint logs save organizations/analysts during an investigation, especially when there is always a possibility that said activity could be indicative of a compromise, endpoint logs also allow for faster, more accurate determinations.  

In essence, network logs can tell us a lot about what's happening on the network, but typically provide little context into why this is happening or what the effect is. For this, we require logs from endpoints to analyse the source of the activity or second-order effect of the activity. This is not to say network logs are made redundant by endpoint logs. Instead, it should illustrate that to perform comprehensive network monitoring, context from the affected hosts is vital. There are also many modern threats that simply cannot be detected via network logs alone and mandates behaviour monitoring on the hosts themselves. If you're a SOC that still relies primarily on network monitoring, consider onboarding additional log sources from endpoints and identity providers. It'll provide you with new log sources to build detections on and can be leveraged extensively in investigations. This will save you the headache of trying to piece together activity with limited context and save your customer the time of unnecessary escalations.  

‍