NTP is an essential protocol normally use for mass time synchronization where a miner periodically sends requests to an NTP server any adjusts its local time so that it is in sync with the rest of the world. Some miner firmware hard-code NTP server addresses that resolve to infrastructure hosted on the Internet that is not in your control.
Any time a miner sends unsolicited requests to a public IP Address, there exists the potential that those requests are part of a command-and-control(C2) channel that is baked into the miner firmware. While this can be embedded into DNS requests or other means, NTP is an easy to hide protocol since it seems benign on the surface. This behavior can be abused: NTP traffic (UDP/123) or responses can be used as a covert channel to communicate with a command-and-control (C2) server. Through such a channel, an external operator can issue commands, trigger firmware updates, or exfiltrate telemetry and credentials — ultimately enabling miner control or hash theft. Even when the UI allows operators to set a custom NTP server, the firmware may still contact its embedded NTP hosts.
Impact
Hard-coded NTP endpoints provide a persistent, known destination an attacker can control or intercept.
Outbound connections to foreign NTP hosts (commonly in China for many OEMs) create an external dependency and a high-value egress path for attackers. Some firmware require successful communication with their embedded NTP hosts to function fully; blocking those hosts may cause sync failures unless mitigated. Miners configured to use external NTP servers consume resources – i.e. NAT entries on Firewalls.
Operational Mitigations
Egress filtering & GeoIP blocking
Block UDP/123 to unapproved destinations at the perimeter. Use GeoIP or curated IP lists to block known NTP servers
and ASNs used by suspicious OEM endpoints
Local authoritative NTP and DNS control
Run redundant, local NTP servers and point miners only to these resolvers. Pair this with a local caching DNS so DNS names for hard-coded NTP hosts resolve to local addresses or localhost.
DNAT/Redirect for stubborn firmware (safe redirection)
When miners insist on reaching hard-coded IPs (not just names), perform destination NAT at the edge gateway/firewall so traffic to those hard-coded IPs is redirected to your local NTP server. This preserves the miner’s expectation of
reaching the original IP while keeping traffic local.
DNS sinkhole / host file override
If the firmware uses hostnames, override them in your DNS (split-horizon) to return local NTP IPs. If firmware ignores DNS and uses IPs, combine DNS with DNAT or static route overrides.
Monitor & Detect
Capture outbound UDP/123 flows (NetFlow, sFlow, or packet capture) to detect unexpected destinations. Track correlations between NTP contacts and changes in pool endpoints, sudden hash-rate drops, or firmware-initiated
reboots/updates.
Action Plan
Identify hard-coded NTP destinations: packet-capture a sample miner during boot and record IPs/hostnames. Build/enable local NTP servers and test synchronization for a sample miner.
Implement perimeter egress rules to block UDP/123 to unapproved destinations; whitelist local NTP only.
If miner fails without reaching hard-coded IPs, add DNAT rules on the gateway for those IPs to your local NTP cluster and test.
Deploy monitoring for NTP anomalies, unexpected DNS resolutions, and pool-endpoint changes.
Keep a procurement requirement: firmware must allow disabling vendor telemetry and permit operator-only NTP settings.
Conclusion
Hard-coded NTP destinations — especially those located in foreign jurisdictions — are more than an operational
nuisance. They are a high-risk egress vector that can be exploited as a covert C2 channel, facilitating miner takeover or hash theft. The safest posture is to centralize time services locally, enforce strict egress controls, and—where necessary redirect hard-coded targets to internal, trusted NTP servers via DNAT or routing overrides.
