DNS tunneling malware turns resolvers into a covert channel

A recently identified malware strain relies on DNS tunneling to communicate covertly, turning a protocol built to translate names into addresses into a path for stolen data and attacker instructions. Its goal is not to make traffic invisible, but to make it look like routine name resolution within infrastructure that businesses already trust.

That distinction matters because DNS supports email, cloud services, payment platforms, software updates and internal applications. Security controls commonly permit DNS on port 53 and scrutinise web traffic much more closely. A compromised client can therefore use ordinary-looking queries to reach an attacker without opening an obvious session to a fixed command-and-control address.

Detection still requires more than trust in DNS. The traffic may carry high volumes, unusual record types or many one-off hostnames. Security teams should combine resolver logs with endpoint behaviour, correlate activity across devices and examine whether a successful connection is followed by credential theft, lateral movement or bulk data access. The campaign is covert, but it leaves measurable traces.

How DNS tunneling changes command and control

The compromise begins on a host, often after phishing, an exposed service or stolen credentials. The implant then treats DNS as a transport layer. It converts collected information into binary, compresses or encrypts it, and encodes that payload into a hostname containing a long series of labels beneath an attacker-controlled domain. A recursive resolver forwards the lookup to the operator’s authoritative server, which can return instructions in the answer.

The technique is effective because its path is permitted rather than hidden inside another protocol. Queries can be interleaved with legitimate lookups, while responses may arrive through DNS over HTTPS on port 443 or DNS over TLS on port 852. Some actors rotate domains and use algorithmically generated names to prevent a single block from ending communication. Others blend the channel with ordinary web traffic once DNS has staged an address or payload.

The design borrows from the resilience of shared networks. Just as cultural information carried in coastal folk songs can move through community connections, the tunnel depends on clients, recursive resolvers and authoritative servers acting as relays. The difference is intent: one exchange sustains a community, while the other conceals an intrusion and transfers data that the victim never intended to disclose.

Anatomy of a covert malware exchange

A typical exchange starts with a small beacon. The implant sends a DNS query containing an encoded identifier, the host’s operating-system details and a request for instructions. The authoritative server recognises the identifier and places the next command into a response record, commonly TXT, although CNAME and NULL responses can also be used. Short status information may be encoded in the response code or the pattern of returned addresses.

Larger transfers are divided into chunks because DNS records and protocol messages have size limits. Each chunk is encoded into a new subdomain, and each query represents another stage of the exchange. Attackers account for resolver caching by varying the queried hostname instead of repeatedly requesting the same label. Compression reduces volume, while encryption makes the transferred material less readable if a response is captured in transit.

Exfiltration follows the same principle in reverse. Stolen documents, browser data, screenshots or credentials are collected, compressed, encrypted and encoded into DNS queries. The authoritative server reassembles the pieces. This method is relatively slow, and large transfers create a noticeable increase in DNS requests, but the malware can adjust its behaviour by pausing between chunks or limiting collection to high-value information.

Signals that reveal covert DNS traffic

Resolver visibility provides the clearest starting point for this activity. The strongest patterns often appear when network data, endpoint telemetry and threat intelligence are considered together rather than as separate investigations.

• Unusually high volumes of failed lookups can indicate command traffic sent to domains that do not exist.
• Large numbers of unique hostnames beneath a small group of domains may reveal encoded data or domain-generation activity.
• Oversized TXT, CNAME or NULL responses can expose a concealed channel used for instructions or exfiltration.
• Regular beaconing intervals from unrelated endpoints suggest coordinated malware rather than normal software update checks.

High-entropy labels, repeated NXDOMAIN responses and sharply different ratios of DNS traffic to web traffic can help separate a tunnel from benign automation. Teams should establish a baseline by business unit, because a university, retail chain and mining operator will each have different resolver volumes and hostname patterns. A rule that is noisy in one environment may be a strong signal in another.

No single indicator proves an infection. Attackers may use legitimate domains, suppress traffic during busy periods or route requests through a service already approved by the organisation. Endpoint telemetry can provide the missing context, including process lineage, unusual child processes, direct outbound DNS, new services and credential access. Where encrypted DNS bypasses approved resolvers, the gap itself becomes an important detection opportunity.

Risks for Australian organisations

Cyber effects can become public-market problems. A published trading suspension attack shows how a compromise affecting one central platform can interrupt transactions across an entire market. Sydney’s connection to the Australian Securities Exchange makes that lesson relevant to exchanges, custodians, brokers and banks, even when a listed company is not itself the target.

The Australian market stretches well beyond financial centres. Melbourne has a large concentration of banking, manufacturing and logistics operations, while Brisbane supports mining, construction, healthcare and service businesses. DNS tunnelling can affect organisations with limited technical teams, especially where a single branch, vehicle, contractor or remote worker connects to shared systems. A seemingly small infected device may provide a route into a larger Australian corporate network.

Ports and airports add another dimension. Customs personnel within the Australian Border Force process commercial import and export declarations and coordinate biosecurity controls. A compromise affecting a connected record system could slow clearance or expose commercially sensitive information without physically disrupting the cargo. Personal information stolen through the same malware may also trigger obligations under the Privacy Act 1988 and the Office of the Australian Information Commissioner’s Notifiable Data Breaches scheme.

Immediate response for suspected infections

Initial containment should balance speed with evidence preservation. If DNS tunnelling is suspected, the priority is to stop further communication while maintaining enough information to identify the initial access route, affected accounts and data accessed. An incident-response playbook should define who can isolate systems, approve DNS blocks and begin credential revocation without waiting for every fact to be established.

• Isolate affected devices while preserving volatile memory, DNS cache data, running processes and command history for forensic review.
• Block confirmed malicious domains at approved recursive resolvers and gateways while retaining associated query data.
• Revoke exposed sessions and rotate credentials from a trusted system, including tokens used for email, cloud consoles and remote administration.
• Hunt across endpoints and identity logs for shared tools, scheduled tasks, new services and authentication originating from the same device.

Investigators should determine when the tunnel began, which systems communicated with the same infrastructure and whether other devices received commands. DNS cache records, proxy logs, endpoint timelines and identity-provider records can establish the scope. If the initial vector was an unpatched internet-facing system, merely removing the malware without closing that route will allow the same operator to return.

Organisations should then assess notification duties, contractual commitments and reporting options involving sector regulators, law enforcement or affected individuals. Once the required notifications are understood, affected systems may need to be rebuilt rather than cleaned in place. Patching the entry point, rotating relevant secrets, restoring trusted software and validating monitoring coverage are essential parts of recovery rather than optional follow-up work.

Building durable DNS and endpoint resilience

DNS should be treated as a monitored security boundary. Direct internet DNS should be redirected through approved recursive resolvers where feasible, with logs retained long enough to support incident analysis. Teams can also control applications that bypass approved resolvers through unmanaged encrypted DNS. Blocking every external DNS request creates operational problems, but forcing all resolution through a monitored service improves both control and investigative coverage.

Endpoint controls must address the compromise that precedes the tunnel. The Australian Signals Directorate, through the Australian Cyber Security Centre, continues to promote the Essential Eight framework, including patching, application control, multi-factor authentication, restricted administrative privileges and regular asset discovery. Endpoint detection and response tools should detect direct DNS activity, encoded command-line arguments and malware behaviours such as process injection. Network segmentation can then restrict a compromised device from reaching sensitive servers.

Resilience also depends on third parties and operational preparation. Australian organisations using managed service providers, cloud platforms and logistics contractors should clarify who monitors DNS, retains logs and responds to endpoint alerts. Regular exercises should include scenarios in which command-and-control traffic travels through an allowed protocol and scenarios in which the resolver itself becomes unavailable. Across Australian environments, that correlation turns DNS from a background utility into one of the clearest early-warning systems for covert malware.