How do you detect cryptomining through DNS queries to mining pools?

What DNS patterns point to cryptomining activity

Mining malware usually reveals itself in the resolution layer before it becomes obvious in the endpoint or firewall logs. Repeated lookups for pool domains, especially from hosts that should have no mining role, can indicate that the endpoint is trying to find a pool, reconnect after failure, or rotate across pool infrastructure. The useful signal is not a single query, but a repeated pattern that persists over time.

For this question, DNS matters because miners often need to discover and keep reaching a small set of remote services. That means you should watch for clusters of lookups to mining-related hostnames, unusual NXDOMAIN bursts around those lookups, and endpoints that resolve many pool names in short succession. When that behaviour is paired with steady outbound sessions, the DNS activity becomes much stronger evidence than either DNS or network telemetry alone.

DNS is also a good place to separate ordinary software behaviour from abuse. Legitimate software usually resolves a bounded set of infrastructure names as part of a known service path. Cryptomining activity is more likely to show repeated resolution attempts, long-running beacons, and pool selection behaviour that does not fit the endpoint’s role, user population, or workload profile.

How to separate mining-pool DNS from normal resolution noise

The most practical test is to ask whether the host has any business reason to contact mining infrastructure at all. If the answer is no, then recurring queries to pool domains deserve immediate triage. This is especially true when the queries come from user endpoints, servers with no mining function, or cloud workloads whose resource profile suddenly changes. Baseline matters here: the same DNS pattern can mean very different things on a developer workstation, a GPU node, or a hardened production server.

Look at the shape of the query stream, not just the destination name. Mining activity often produces a high request rate, many distinct pool hostnames, and repeated resolution after connection failure or pool switching. If the endpoint keeps resolving fresh names and then opening persistent sessions, you may be seeing a miner that is probing for redundancy or evading simple domain blocks.

One useful reference point is DNS Security Guide, which is relevant here because DNS logging, filtering, and traffic analysis are the fastest ways to turn suspicious lookups into a defensible detection story.

What to validate after you see repeated pool lookups

Once you have a suspicious DNS pattern, confirm whether the host is authorised to mine or is simply generating miner-like traffic because it has been compromised. That validation should include the source process, the user or service account, the timing of the lookups, and whether the traffic aligns with expected workload behaviour. A false positive is usually easy to explain when the host role is legitimate; a true incident is usually obvious when the DNS activity is paired with unknown binaries, unexpected persistence, or off-hours compute use.

Network and endpoint telemetry should be reviewed together. DNS alone can tell you that a host is reaching for a pool, but the next question is whether the host actually maintained the session, downloaded miner code, or started consuming unusual CPU or GPU capacity. If the answer is yes, treat the DNS indicator as part of a broader compromise chain rather than an isolated anomaly.

For endpoint correlation, Sysmon Guide is useful because DNS query and network connection telemetry can be correlated with process creation, command-line activity, and persistence mechanisms.

Risk and Threat Considerations

Mining pools are attractive to attackers because they convert compromise into immediate monetisation. If an endpoint is quietly resolving pool domains and keeping outbound sessions alive, the same access path can also be used for persistence, additional payloads, or later stage abuse. The main operational risk is not just wasted compute, but the possibility that the host is already under someone else’s control.

Failure mechanism: Malware or a rogue process repeatedly resolves pool domains, rotates across names when blocked, and maintains outbound sessions long enough to keep mining active while blending into ordinary DNS noise.

Impact: You can lose CPU, GPU, and cloud spend, but the more important consequence is that the DNS pattern may be the earliest visible sign of a broader compromise that also exposes credentials, tokens, or internal access paths.

Practitioner Guidance

What to verify: Validate the host role first. If the device is not an approved mining node, treat repeated pool lookups as suspicious until proven otherwise, and confirm the source process before relying on the domain name alone.

Decision rule: If DNS queries to mining pools are accompanied by persistent outbound sessions and unexpected resource consumption, prioritise containment and compromise review over trying to tune the detection away as noise.

What good looks like: A good detection program ties DNS logs to process and network telemetry, so analysts can distinguish authorised compute activity from a workload that is silently mining.

Practitioner takeaway: The strongest signal is not a single pool lookup, it is a repeated DNS pattern that matches no approved workload and is reinforced by persistent outbound connections.

Related resources from NHI Mgmt Group

• How do you detect DNS queries to file sharing sites such as MEGA used for exfiltration?
• How should exchanges and mining pools screen funds to reduce money laundering through mining exposure?
• How do you detect DnsAdmins ServerLevelPluginDll abuse on Windows DNS servers?
• How do you detect Kerberoasting through RC4 ticket requests?