What happens when malware uses encrypted DNS or hardcoded IP addresses instead of normal domain lookups?

Why This Matters for Security Teams

Malware that uses encrypted dns or hardcoded IP addresses is designed to evade the exact visibility layer many teams rely on for detection and disruption. If a threat can avoid normal domain lookups, DNS sinkholing may never see the request path it is supposed to intercept. That matters because defenders often assume name resolution is the control point, when the real control point may be the endpoint, the egress path, or the workload itself.

This pattern shows up in incidents where attackers want persistence, stealth, or direct command-and-control reach. It is especially difficult when encrypted DNS is allowed from unmanaged devices or when outbound rules trust raw IP traffic too broadly. The practical lesson is that DNS controls remain useful, but they are not sufficient on their own. Teams need layered monitoring, strict egress policy, and traffic inspection that does not depend entirely on resolver visibility.

NHIMG research on the Guide to the Secret Sprawl Challenge shows how often exposure persists when defenders rely on a single control plane. In practice, many security teams discover covert outbound paths only after malware has already established repeatable command-and-control rather than through intentional DNS review.

How It Works in Practice

DNS sinkholing works by redirecting malicious domain lookups to a controlled destination. That only helps if the malware actually performs a resolvable lookup through a resolver defenders can monitor. Encrypted DNS changes the picture by hiding the query contents from intermediate network controls, while hardcoded IP addresses bypass DNS entirely. In both cases, the usual “block the bad domain” approach loses leverage.

Operationally, teams should focus on the full chain of communication rather than the lookup step alone. Useful controls include:

• Forcing endpoints to use approved resolvers and blocking direct encrypted DNS to unsanctioned services.
• Restricting outbound traffic by destination, protocol, and port, not just by domain reputation.
• Inspecting TLS session metadata, flow logs, and endpoint telemetry for repeated beaconing patterns.
• Using egress allowlists for high-risk segments and segmentation for systems that should never initiate internet traffic.
• Correlating DNS logs with endpoint process lineage so defenders can see which binary initiated a connection.

Framework guidance aligns with this layered approach. CIS Controls v8 emphasizes managed network monitoring and secure configuration, which maps well to limiting resolver bypass and raw IP egress. NHIMG’s coverage of the Shai Hulud npm malware campaign also illustrates how quickly attackers pivot once they find a path that is not governed by standard network assumptions.

These controls tend to break down in remote and hybrid environments where devices can reach the internet directly and local DNS policy enforcement is inconsistent.

Common Variations and Edge Cases

Tighter egress control often increases operational overhead, requiring organisations to balance visibility against user mobility and application breakage. There is no universal standard for this yet, but current guidance suggests treating resolver enforcement and outbound IP restrictions as complementary, not interchangeable.

One edge case is legitimate encrypted DNS usage, which can create pressure to allow DoH or DoT broadly. Another is cloud workloads that rely on dynamic service endpoints, where static IP allowlists may become brittle. In those environments, the practical choice is to define trust boundaries more narrowly and instrument the workload itself so that outbound behaviour is attributable, even when DNS is hidden.

Where malware uses hardcoded IPs, blocklists age quickly and lose value. Where malware uses encrypted DNS, defenders should assume query visibility is reduced unless traffic is forced through an approved resolver stack. NHIMG’s State of Secrets Sprawl 2026 reinforces a broader lesson: exposure that is not continuously governed tends to persist, and detection alone rarely closes the gap. The same applies here, where one missed path can remain usable long after initial discovery.

Related resources from NHI Mgmt Group

• How should security teams detect malware that is retrieved from a blockchain instead of a normal server?
• What breaks when a malicious Python package uses startup hooks instead of a normal import path?
• Why do supply-chain malware campaigns increasingly combine blockchain lookups with normal web hosting?
• What breaks when ransomware uses hardcoded keys and plaintext backup files instead of generating per-victim encryption material?