{ "id": "9fbae66b-e117-4ccb-8413-6c106e2fec56", "created_at": "2026-04-06T00:07:33.112688Z", "updated_at": "2026-04-10T03:37:36.789361Z", "deleted_at": null, "sha1_hash": "3e57f0ae693f5ef5554bfd8c6f69010ea648b54a", "title": "DNS Tunneling: how DNS can be (ab)used by malicious actors", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 363705, "plain_text": "DNS Tunneling: how DNS can be (ab)used by malicious actors\r\nBy Alex Hinchliffe\r\nPublished: 2019-03-15 · Archived: 2026-04-05 18:20:10 UTC\r\nMalicious actors have utilized Command \u0026 Control (C2) communication channels over the Domain Name\r\nService (DNS) and, in some cases, have even used the protocol to exfiltrate data. This is beyond what a C2\r\n“heartbeat” connection would communicate. Malicious actors have also infiltrated malicious data/payloads to the\r\nvictim system over DNS and, for some years now, Unit 42 research has described different types of abuse\r\ndiscovered.\r\nDNS is a critical and foundational protocol of the internet – often described as the  “phonebook of the internet” –\r\nmapping domain names to IP addresses, and much more, as described in the core RFCs for the protocol. DNS’\r\nubiquity (and frequent lack of scrutiny) can enable very elegant and subtle methods for communicating, and\r\nsharing data, beyond the protocol’s original intentions.\r\nOn top of the examples of DNS use mentioned already, a number of tools exist that can enable, amongst other\r\nthings, their attackers to create covert channels over DNS for the purposes of hiding communication or bypassing\r\npolicies put in place by network administrators. A popular use case is to bypass hotel, café etc Wi-Fi connection\r\nregistration by using the often-open and available DNS. Most notably these tools are freely available online in\r\nplaces like GitHub and can be easy to use. More information about these tools can be found in the Appendix\r\nsection at the end of this report.\r\nIn this report we introduce the types, methods, and usage of DNS-based data infiltration and exfiltration and\r\nprovide some pointers towards defense mechanisms.\r\nDNS\r\nDNS uses Port 53 which is nearly always open on systems, firewalls, and clients to transmit DNS queries. Rather\r\nthan the more familiar Transmission Control Protocol (TCP) these queries use User Datagram Protocol (UDP)\r\nbecause of its low-latency, bandwidth and resource usage compared TCP-equivalent queries. UDP has no error or\r\nflow-control capabilities, nor does it have any integrity checking to ensure the data arrived intact.\r\nHow is internet use (browsing, apps, chat etc) so reliable then? If the UDP DNS query fails (it’s a best-effort\r\nprotocol after all) in the first instance, most systems will retry a number of times and only after multiple failures,\r\npotentially switch to TCP before trying again; TCP is also used if the DNS query exceeds the limitations of the\r\nUDP datagram size – typically 512 bytes for DNS but can depend on system settings.\r\nFigure 1 below illustrates the basic process of how DNS operates: the client sends a query string (for example,\r\nmail.google[.]com in this case) with a certain type – typically A for a host address. I’ve skipped the part whereby\r\nintermediate DNS systems may have to establish where ‘.com’ exists, before finding out where ‘google[.]com’ can\r\nbe found, and so on.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/\r\nPage 1 of 8\n\nFigure 1. Simplified DNS operation\r\nOnce a name is resolved to an IP caching also helps: the resolved name-to-IP is typically cached on the local\r\nsystem (and possibly on intermediate DNS servers) for a period of time. Subsequent queries for the same name\r\nfrom the same client then don’t leave the local system until said cache expires. Of course, once the IP address of\r\nthe remote service is known, applications can use that information to enable other TCP-based protocols, such as\r\nHTTP, to do their actual work, for example ensuring internet cat GIFs can be reliably shared with your colleagues.\r\nSo, all in all, a few dozen extra UDP DNS queries from an organization’s network would be fairly inconspicuous\r\nand could allow for a malicious payload to beacon out to an adversary; commands could also be received to the\r\nrequesting application for processing with little difficulty.\r\nIf you want to go deep on how DNS works – all the way from you typing keys to spell the domain name you want\r\nto browse – then please read this article.\r\nData Trail\r\nJust as when you browse the internet, whether pivoting from a search engine result or directly accessing a website\r\nURL, your DNS queries also leave a trace. How much of a trace depends on the systems and processes involved\r\nalong the way, from the query leaving the operating system, to receiving the resultant IP address.\r\nFocusing on the server-side only and, using some basic examples, it’s possible for DNS servers – especially those\r\nwith extended or debug logging enabled – to gather a whole host (no pun intended) of information about the\r\nrequest, and client requesting it.\r\nThis article provides some idea of the type of information that could be gleaned from DNS server logs; an\r\nadversary operating such a server gets the remote IP sending the request – though this could be the last hop or\r\nDNS server’s IP, not the exact requesting client’s IP – as well as the query string itself, and whatever the response\r\nwas from the server.\r\nDNS Tunneling\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/\r\nPage 2 of 8\n\nNow that we have a common understand of DNS, how it operates in a network, and the server-side tracing\r\ncapabilities, let’s dig a little deeper into the tunneling capabilities. In this section we will describe how command\r\nand control (C2) beacons can operate over DNS, and how data exfiltration and infiltration is possible.\r\nC2\r\nA C2 channel often serves two purposes for the adversary. Firstly, it can act as a beacon or heartbeat indicating\r\nthat their remote payload is still operating – still has a heartbeat – as it’s beaconing-out (communicating) to their\r\nserver.\r\nYou could consider the basic DNS operation, as shown in Figure 1 above, as an example of a heartbeat. If the\r\nmalicious implant on the client system repeatedly sends a query to the actor’s server through the DNS\r\ninfrastructure, the actor could tell from the logs that an implant is running. What becomes difficult is\r\ndistinguishing between multiple victims that are infected with the implant.\r\nConsider another example described by Figure 2 below, where the client system is compromised with malware\r\nthat’s constructing strange-looking query strings to send over DNS. Queries like these still act as a heartbeat\r\nindicating to the adversary their payload is still active, however they also provide some basic meta-data about the\r\nvictim and, importantly, ways to uniquely identify one victim from another.\r\nFigure 2. Example C2 DNS query operation\r\nUsernames and hostnames may not always be unique, and some IPs could be duplicated across multiple networks\r\nusing Network Address Translation (NAT), however systems do have Universal Unique Identifiers (UUIDs) or\r\nother properties, that when combined could create a unique identifier for a given host or victim.\r\nSome of the meta-data from the compromised host could be sent as plaintext but might appear more suspicious at\r\nfirst glance to anyone seeing such strings in a DNS query. In many cases the data will contain characters not\r\nsupported by DNS, in which case encoding will be required. In Figure 2 you can see the base64 encoded\r\nequivalent for the meta-data, which is constructed using a ‘-‘ delimited notation for simple parsing and decoding\r\non the server-side, as shown in Figure 3 below.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/\r\nPage 3 of 8\n\nFigure 3. Server-side DNS logs tracking C2 communication\r\nFigure 3 shows an example of what a raw DNS log from a DNS server application may look like, with line entries\r\nfor the malware’s query and the DNS server’s response, NXDOMAIN (or non-existent domain), in this case.\r\nIn some ways, a log like this, or perhaps a small database containing the decoded records from them, could be\r\ncompared to the more snazzy-looking botnet control panels that allow the botnet herder to control their zombie\r\nvictim systems.\r\nExfiltration\r\nSo, what else could be sent up in DNS queries? Well, anything in theory, so long as it’s encoded correctly and\r\ndoesn’t abuse the UDP size limits. A way for getting around the latter constraint could be to send multiple A\r\nrecord messages and have them stitched together somehow on the server-side. Complications would arise however\r\nin dropped or missing datagrams.\r\nUnlike TCP that ensures retransmission of failed packets, UDP has no such mechanism. An algorithm would be\r\nrequired to understand how many messages will be sent, and check the correct number arrives, but more\r\ncomplicated than that, somehow ask the client to retransmit certain segments of the data again until 100% arrives.\r\nDepending on the amount of data to transmit – every PDF on the system, for example – may take an age, and look\r\nhugely suspicious to network administrators.\r\nInfiltration\r\nIn contrast, infiltration of data whether it be code, commands, or a binary file to drop to disk and execute could be\r\nmuch easier, especially using the DNS type of TXT (as opposed to host record type A). TXT types were designed\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/\r\nPage 4 of 8\n\nto provide descriptive text, such as service details, contact names, phone numbers, etc in response to TXT DNS\r\nqueries for domain names.\r\nGuess what looks likes text? Base64-encoded non-text data! Figure 4 below shows the identical query being sent\r\nto the malicious site as in Figure 2, however, the type is now TXT on both the request and response, and the\r\nresponse data contains the first 300 or so characters of an encoded binary executable file that could be executed by\r\nthe client malware. Again, using the logs, the adversary would be able to know which client asked for the payload,\r\nand that the payload was sent (who knows if it actually arrived…).\r\nFigure 4. Example C2 DNS query with TXT type response\r\nBut how does the malicious implant know to change the type to TXT or when to request whatever lies inside the\r\n“text” data? It could be built-in to the payload to query at a certain point in its execution or after a certain amount\r\nof time but in reality, it’s going to be actor-driven using the second purpose of a C2 channel – control.\r\nIn my earlier examples of C2 DNS communication the response from the DNS server was NXDOMAIN. This\r\nmessage obviously reaches the client system (and the malware) and could be used a message or instruction for the\r\npayload but it’s limiting without parameters and detail. Enter NOERROR.\r\nNOERROR, as the term suggests means everything worked fine – your request was processed and an answer\r\nawaits you. With a NOERROR comes a response that can be processed. Usually this is the IPv4 (for A type\r\nrequests) or IPv6 (for AAAA type requests) or it could be TXT, as shown in Figure 4 above. Focusing on a simple\r\nexample – the IPv4 address response – the malware doesn’t need an actual IP to communicate with, unlike your\r\nbrowser that asked “where is google[.]com at?”. The malware is already in communication to its destination using\r\nthe C2 over DNS.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/\r\nPage 5 of 8\n\nWhat the malware can use the IP response for is any one of 4,294,967,296 possible commands or instructions.\r\nAgain, keeping this very simple still, it’s possible that a particular value in the 4th octet of the IP, say, 100, would\r\nindicate to the malware to send a TXT DNS query to the actor’s domain to collect and execute a payload. Value 10\r\nin the first octet could mean to uninstall and wipe traces of the malicious payload from the operating system and\r\nevent logs. Literally, the options are endless, as are the levels of possible sophistication.\r\nGiven the adversary has control over the DNS server, and that certain DNS server applications or daemons are\r\nhighly configurable, it’s possible to send conditional responses back to the malware on the victim systems based\r\non requests sent from them.\r\nFor example, if the incoming query contains a certain flag – a character – as the first subdomain to the domain\r\nname, it could be read by a program running inside the DNS service on the server and provide a custom response\r\nback to the client. This could be used for the malware to work through a set of tasks automatically, and report back\r\naccordingly to the actors to receive their next task.\r\nConclusion\r\nDNS is a very powerful tool used almost everywhere allowing applications and systems to lookup resources and\r\nservices with which to interact. DNS provides a communication foundation enabling higher-level and more\r\npowerful protocols to function but can mean it’s overlooked from a security point of view, especially when you\r\nconsider how much malware is delivered via email protocols or downloaded from the web using HTTP.\r\nFor these reasons, DNS is the perfect choice for adversaries who seek an always-open, often overlooked and\r\nprobably underestimated protocol to leverage for communications from and to compromised hosts. Unit 42 has\r\nseen multiple instances of malware, and the actors behind them, abusing DNS to succeed in their objectives, as\r\ndiscussed in this report.\r\nOrganizations can defend themselves against DNS tunneling in many different ways, whether using Palo Alto\r\nNetworks’ Security Operating Platform, or Open Source technology. Defense can take many different forms such\r\nas, but not limited to, the following:\r\nBlocking domain-names (or IPs or geolocation regions) based on known reputation or perceived danger;\r\nRules around “strange looking” DNS query strings;\r\nRules around the length, type, or size of both outbound or inbound DNS queries;\r\nGeneral hardening of the client operating systems and understanding the name resolution capabilities as\r\nwell as their specific search order;\r\nUser and/or system behavior analytics that automatically spot anomalies, such as new domains being\r\naccessed especially when the method of access and frequency are abnormal.\r\nPalo Alto Networks recently introduced a new DNS security service focused on blocking access to\r\nmalicious domain names.\r\nFurther information can also be found in the ATT\u0026CK framework documentation on Mitre’s website. Specifically,\r\nthe following techniques relate to concepts discussed in this report.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/\r\nPage 6 of 8\n\nID Technique\r\nT1048 Exfiltration Over Alternative Protocol\r\nT1320 Data Hiding\r\nT1094 Custom Command and Control Protocol\r\nThanks to Yanhui Jia, Rongbo Shao, Yi Ren, Matt Tennis, Xin Ouyang, John Harrison and Jens Egger for their\r\ninput on this report.\r\nAppendix: Toolkit List\r\nTool Name Description\r\ndns2tcp\r\ndns2tcp was written by Olivier Dembour and Nicolas Collignon. It is written in C and runs\r\non Linux. The client can run on Windows. It supports KEY and TXT request types. [4]\r\ntcp-over-dns\r\ntcp-over-dns (TCP-over-DNS) was released in 2008. It has a Java based server and a Java\r\nbased client. It runs on Windows, Linux and Solaris. It supports LZMA compression and\r\nboth TCP and UDP traffic tunneling. [4]\r\nOzymanDNS\r\nOzymanDNS is written in Perl by Dan Kaminsky in 2004. It is used to setup an SSH tunnel\r\nover DNS or for file transfer. Requests are base32 encoded and responses are base64\r\nencoded TXT records. [4]\r\niodine\r\niodine is a DNS tunneling program first released in 2006 with updates as recently as 2010. It\r\nwas developed by Bjorn Andersson and Erik Ekman. Iodine is written in C and it runs on\r\nLinux, Mac OS X, Windows and others. Iodine has been ported to Android. It uses a TUN or\r\nTAP interface on the endpoint. [4]\r\nSplitBrain SplitBrain is a variant of OzymanDNS.\r\nDNScat-P /\r\ndnscat2\r\nDNScat (DNScat-P) was originally released in 2004 and the most recent version was\r\nreleased in 2005. It was written by Tadeusz Pietraszek. DNScat is presented as a “Swiss-Army knife” tool with many uses involving bi-directional communication through DNS.\r\nDNScat is Java based and runs on Unix like systems. DNScat supports A record and\r\nCNAME record requests (Pietraszek, 2004). Since there are two utilities named DNScat,\r\nthis one will be referred to as DNScat-P in this paper to distinguish it from the other one. [4]\r\nDNScapy\r\nDNScapy was developed by Pierre Bienaime. It uses Scapy for packet generation. DNScapy\r\nsupports SSH tunneling over DNS including a Socks proxy. It can be configured to use\r\nCNAME or TXT records or both randomly. [4]\r\nTUNS TUNS, an IP over DNS tunnel, was developed by Lucas Nussbaum and written in Ruby. It\r\ndoes not use any experimental or seldom used record types. It uses only CNAME records. It\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/\r\nPage 7 of 8\n\nadjusts the MTU used to 140 characters to match the data in a DNS request. TUNS may be\r\nharder to detect, but it comes at a performance cost.\r\nPSUDP\r\nPSUDP was developed by Kenton Born. It injects data into existing DNS requests by\r\nmodifying the IP/UDP lengths. It requires all hosts participating in the covert network to\r\nsend their DNS requests to a Broker service which can hold messages for a specific host\r\nuntil a DNS request comes from that host. The message can then be sent in the response.\r\nYour\r\nFreedom\r\nHTTPS/UDP/FTP/DNS/ECHO VPN \u0026 tunneling solution for Windows, Mac OSX, Linux\r\nand Android. Bypass proxies and access the Internet anonymously\r\nHexify A tool is developed by Infoblox to do the penetrating test for DNS tunneling.\r\nAppendix: Malware List\r\nMalware Name Description\r\nDNS_TXT_Pwnage\r\nA backdoor capable of receiving commands and PowerShell scripts from DNS\r\nTXT queries.\r\nDNSMessenger\r\nDNSMessenger is Remote Access Trojan (RAT) that opens a backdoor so that\r\nhackers can control the compromised machine remotely\r\nOilRig -\r\nBONDUPDATER\r\nTrojan against a Middle Eastern government can use A records and TXT records\r\nwithin its DNS tunneling protocol for its C2 communications\r\nSource: https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/" ], "report_names": [ "dns-tunneling-how-dns-can-be-abused-by-malicious-actors" ], "threat_actors": [ { "id": "cffb3c01-038f-4527-9cfd-57ad5a035c22", "created_at": "2022-10-25T15:50:23.38055Z", "updated_at": "2026-04-10T02:00:05.258283Z", "deleted_at": null, "main_name": "OilRig", "aliases": [ "COBALT GYPSY", "IRN2", "APT34", "Helix Kitten", "Evasive Serpens", "Hazel Sandstorm", "EUROPIUM", "ITG13", "Earth Simnavaz", "Crambus", "TA452" ], "source_name": "MITRE:OilRig", "tools": [ "ISMInjector", "ODAgent", "RDAT", "Systeminfo", "QUADAGENT", "OopsIE", "ngrok", "Tasklist", "certutil", "ZeroCleare", "POWRUNER", "netstat", "Solar", "ipconfig", "LaZagne", "BONDUPDATER", "SideTwist", "OilBooster", "SampleCheck5000", "PsExec", "SEASHARPEE", "Mimikatz", "PowerExchange", "OilCheck", "RGDoor", "ftp" ], "source_id": "MITRE", "reports": null }, { "id": "c786e025-c267-40bd-9491-328da70811a5", "created_at": "2025-08-07T02:03:24.736817Z", "updated_at": "2026-04-10T02:00:03.752071Z", "deleted_at": null, "main_name": "COBALT GYPSY", "aliases": [ "APT34 ", "CHRYSENE ", "Crambus ", "EUROPIUM ", "Hazel Sandstorm ", "Helix Kitten ", "ITG13 ", "OilRig ", "Yellow Maero " ], "source_name": "Secureworks:COBALT GYPSY", "tools": [ "Glimpse", "Helminth", "Jason", "MacDownloader", "PoisonFrog", "RGDoor", "ThreeDollars", "TinyZbot", "Toxocara", "Trichuris", "TwoFace" ], "source_id": "Secureworks", "reports": null }, { "id": "67709937-2186-4a32-b64c-a5693d40ac77", "created_at": "2023-01-06T13:46:38.495593Z", "updated_at": "2026-04-10T02:00:02.999196Z", "deleted_at": null, "main_name": "OilRig", "aliases": [ "Crambus", "Helix Kitten", "APT34", "IRN2", "ATK40", "G0049", "EUROPIUM", "TA452", "Twisted Kitten", "Cobalt Gypsy", "APT 34", "Evasive Serpens", "Hazel Sandstorm", "Earth Simnavaz" ], "source_name": "MISPGALAXY:OilRig", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "b6436f7b-6012-4969-aed1-d440e2e8b238", "created_at": "2022-10-25T16:07:23.91517Z", "updated_at": "2026-04-10T02:00:04.788408Z", "deleted_at": null, "main_name": "OilRig", "aliases": [ "APT 34", "ATK 40", "Chrysene", "Cobalt Gypsy", "Crambus", "DEV-0861", "EUROPIUM", "Earth Simnavaz", "Evasive Serpens", "G0049", "Hazel Sandstorm", "Helix Kitten", "IRN2", "ITG13", "Scarred Manticore", "Storm-0861", "TA452", "Twisted Kitten", "UNC1860", "Yellow Maero" ], "source_name": "ETDA:OilRig", "tools": [ "AMATIAS", "Agent Drable", "Agent Injector", "AgentDrable", "Alma Communicator", "BONDUPDATER", "CACTUSPIPE", "Clayslide", "CypherRat", "DNSExfitrator", "DNSpionage", "DROPSHOT", "DistTrack", "DropperBackdoor", "Fox Panel", "GREYSTUFF", "GoogleDrive RAT", "HighShell", "HyperShell", "ISMAgent", "ISMDoor", "ISMInjector", "Jason", "Karkoff", "LIONTAIL", "LOLBAS", "LOLBins", "LONGWATCH", "LaZagne", "Living off the Land", "MailDropper", "Mimikatz", "MrPerfectInstaller", "OILYFACE", "OopsIE", "POWBAT", "POWRUNER", "Plink", "Poison Frog", "PowerExchange", "PsList", "PuTTY Link", "QUADAGENT", "RDAT", "RGDoor", "SEASHARPEE", "Saitama", "Saitama Backdoor", "Shamoon", "SideTwist", "SpyNote", "SpyNote RAT", "StoneDrill", "TONEDEAF", "TONEDEAF 2.0", "ThreeDollars", "TwoFace", "VALUEVAULT", "Webmask", "WinRAR", "ZEROCLEAR", "ZeroCleare", "certutil", "certutil.exe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434053, "ts_updated_at": 1775792256, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/3e57f0ae693f5ef5554bfd8c6f69010ea648b54a.pdf", "text": "https://archive.orkl.eu/3e57f0ae693f5ef5554bfd8c6f69010ea648b54a.txt", "img": "https://archive.orkl.eu/3e57f0ae693f5ef5554bfd8c6f69010ea648b54a.jpg" } }