Investigating DNS Request Issues: EDR Blind Spots Explained

Executive Summary

Our security team recently investigated recurring DNS query alerts for the domain epicunitscan[.]info, initially detected via mSOC^TM custom built IDS network based signatures. The mSOC^TM team has been tracking requests to this domain[1] for years, even though it does not resolve to an IP address (as of 07/28/2025[2]).

Network based alerts or alerts on DNS logs can identify malfeasant DNS queries, however when the DNS query fails to resolve, the Endpoint Detection and Response systems will not log the request. Therefore, an investigation using EDR data alone may result in a false negative (an issue is occurring but the data does not show artifacts).

The follow details a case study of using existing tools, identifying root cause and advising the customer of how home based systems were causing a re-infection of a work computer.

DNS Request Investigation Challenges

A device on a network that uses DHCP (Dynamic Host Configuration Protocol) may have its source IP address change over time, particularly when its DHCP lease expires or it moves to a different part of the network. The DHCP server dynamically assigns IP addresses to devices, and these addresses can be periodically renewed, released, or reassigned to other clients, resulting in a changing association between network devices and their IP addresses.

Alerting on DNS requests flowing across the network will typically show the source IP in the log. However, sometimes that source IP is a DHCP or another DNS server. Let me explain.

When a DNS request is observed on the network, the recorded source IP address may not accurately represent the true origin of the request if the DNS query was forwarded by another DNS server. In this scenario, the network may only capture the address of the intermediary DNS server that relayed the request, rather than the original client.

These two conditions—changing DHCP source IPs and DNS queries forwarded by intermediate servers—pose significant challenges for network monitoring and forensic analysis, as they can obscure the true source of DNS requests and frustrate efforts to attribute specific network actions to individual devices

Why the Endpoint Detection and Response Will Not Log this DNS Request

Endpoint Detection and Response (EDR) solutions do not typically log all network activity at the same level of detail as full network packet capture tools. Instead, EDRs focus on selected types of network telemetry and protocols that are most relevant for detecting and investigating endpoint-related threats. These usually include TCP and UDP, though some EDRs log more.

As a result, while the alarm will trigger and the request was made, attempts to correlate this to the EDR logs will fail. This is because the API call to Windows for DNS resolution is not what is logged by the EDR, however it is maintained in the DNS cache – known as Negative Caching.

While EDR will not log this request, network traffic on DNS and DNS logs will. See below:

How to Use Negative Caching to Investigate

In this case study, the mSOC team uses tools like OSQuery, which enables enterprise wide queries for data on endpoints. osquery is an open-source endpoint monitoring and instrumentation tool that allows you to explore operating system data using SQL-like queries.

An example query is below, though you can also collect all available DNS cache entries and search those.

SELECT name, type FROM dns_cache WHERE name LIKE '%epicunitscan%';

Why this worked

• Forensic Advantage: DNS cache retains records even for failed lookups (NXDOMAIN), unlike some logging tools.
• This EDR only logged network communications to domains when the connection is successful. Knowing that a failed DNS query does not log in the EDR telemetry is an important detail.
• Osquery Scalability: Enabled instant querying of thousands of endpoints without manual checks.
• Low Overhead: Minimal performance impact versus full packet captures.

Typical Response & Recurrence

A typical response to this type of persistent suspicious request is to reimage the computer system. Some organizations may chose to clear out browser cache, javascript, reset browser settings etc..

However, after reimage, the connections re-occurred. This was not surprising given what we suspected and our experience for root cause in this issue.

Root Cause Identification

• The source of the infection and the subsequent recurrence was traced to Google Chrome on the user’s home computer system. Malware had infected browser extensions synced via the user’s personal Google profile and this action introduced the infection into the work environment.
• While the workstation was reimaged, after reimage, the user performed the same personal browser sync. This simply reinfected the workstation.

Resolution Steps

To fully eradicate the threat:

1. Backup & Isolate:
   • Export bookmarks via Chrome’s Bookmark Manager (Ctrl+Shift+O → Export).
   • Note installed extensions for manual reinstallation later.
2. Uninstall and Purge Chrome:
   • Uninstall Chrome.Delete the Chrome user data folder:
   • Remove-Item -Recurse -Force “$env:LOCALAPPDATA\Google\Chrome”
   • Clean registry entries
     Remove-Item -Path “HKLM:\Software\Wow6432Node\Google\Chrome” -Recurse 
3. Reset Chrome Sync:
   • Visit Google Dashboard (https://www.google.com/settings/dashboard) → Chrome Sync → Stop and Clear.
4. Reinstall Chrome Securely:
   • Use the offline installer to avoid compromised updaters:
     Chrome Offline Installer (http://www.google.com/chrome/eula.html?system=true&standalone=1)

Key Takeaways

• EDR Limitations: Some EDRs lack of DNS logging when DNS does not resolve, resulting in false negatives when querying data and potentially hindered initial asset correlation.
• Supplemental monitoring using IDS or DNS logging with network-level monitoring can uncover malfeasant requests even if they do not resolve.
• Lack of browser compromise detection in EDR is a challenging issue. EDR’s tend not to identify some browser compromise events, as in this case, because this resides outside or on the edge of an EDRs core capabilities.
• Browser Sync Risks: Infected extensions can persist via sync. Regularly audit extensions and reset sync after malware incidents.
• Persistence Mechanism: Synchronizing browsers via a home user account to a work station may introduce an attack vector, which may not be discovered by an EDR alone.
• Weaponized Timing: A failed DNS query while a system is infected can expose the organization to risk when the Threat Actor decides to resolve the domain to an IP.  The infection may remain dormant, though infected, until a time of the Threat Actor’s choosing.

This incident underscores the need for layered defense: combining network IDS (Snort), endpoint tools, and manual forensic techniques to combat persistent threats.

---

[1] https://www.bleepingcomputer.com/forums/t/567607/epicunitscaninfo-need-help-to-remove/

[2] https://dnschecker.org/all-dns-records-of-domain.php?query=epicunitscan.info&rtype=ALL&dns=google