Your Logs are Lying: How Network Infrastructure Impacts EDR Network Telemetry
Detection engineers rely heavily on EDR for visibility into network activity originating from endpoints. But what if your infrastructure is quietly obscuring the truth? A common blind spot emerges from how organizations deploy Web proxies, a core component in enterprise network security to filter and enforce policies on Web traffic, that can severely distort the fidelity of network telemetry captured by EDRs.
Web Proxy Deployments: Transparent vs. Explicit
All organizations use Web proxy solutions to control, filter, and log outbound web traffic. These proxies are typically deployed in two configurations:
Transparent Proxy: In this setup, Web traffic is silently intercepted and redirected to the proxy without any explicit client-side configuration. The client is unaware of the proxy’s presence, and traffic flows through it automatically.
Explicit Proxy: Here, the proxy is directly configured in the client’s network settings or enforced via Group Policy, WPAD, or PAC (Proxy Auto-Config) files. Clients send their HTTP/HTTPS requests directly to the proxy, which then makes the outbound request on their behalf.
How Web Proxy Deployment Method Impacts EDR Telemetry
The architectural choice of Web proxy deployment has significant impact on EDR solutions that rely on network telemetry. In a transparent proxy deployment, EDR tools can observe the true destination IP addresses of outbound connections. This allows analysts to build detection rules or threat-hunting queries that spot communication with known/unknown malicious infrastructure.
However, with explicit Web proxy deployments, the picture changes dramatically. Since clients are configured to send their requests directly to the proxy, EDR agents records the proxy's IP address as the destination, not the final target. This introduces a critical blind spot. Malware implants, which are often proxy-aware, seamlessly use the corporate proxy to reach their command-and-control (C2) servers. The result: your detection rules looking for C2 IPs or suspicious geolocations are rendered ineffective because the logs only reflect benign, internal proxy addresses.
Is All Context Lost?
Luckily, depending on how the EDR agent monitors the network activity, some context may still be available.
URL and Hostname Visibility
EDR agents like Microsoft Defender for Endpoint can inspect the traffic and still capture the URL or the hostname information even if the destination IP appears to be the proxy. This can enable hostname-based detections.
DNS Telemetry
DNS Telemetry: If the EDR agent monitors DNS queries on the endpoint, it can still provide visibility into the original destination's IP address and domain name. Microsoft Defender for Endpoint (MDE), for example, includes this data in the DnsConnectionInspected event, which can be used for reconstructing a session’s real destination IP.
Web Proxy Telemetry
Since organizations usually collect Web proxy logs, EDR and Web Proxy telemetry can be correlated to reveal the real destination IP.
Conclusion
Understanding your network infrastructure is not optional, it's essential. Proxy deployment (and other network appliances) architecture can directly shape what your EDR sees and what it misses. Detection engineers and threat hunters must factor in proxy configurations when building detection logic and analyzing telemetry. Otherwise, they risk chasing shadows, or worse, missing real threats that hide behind the safe-looking logs of a Web proxy.
