{ "id": "fecdbf1a-d227-4a37-a5a7-7e3d0581b4e4", "created_at": "2026-04-06T00:15:01.116036Z", "updated_at": "2026-04-10T03:21:57.5681Z", "deleted_at": null, "sha1_hash": "86bd49705271eaa7afcd9bf869ac3cf8767e1c5b", "title": "Use of DNS Tunneling for C\u0026C Communications", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 709992, "plain_text": "Use of DNS Tunneling for C\u0026C Communications\r\nBy Alexey Shulmin\r\nPublished: 2017-04-28 · Archived: 2026-04-05 13:54:52 UTC\r\n– Say my name.\r\n– 127.0.0.1!\r\n– You are goddamn right.\r\nNetwork communication is a key function for any malicious program. Yes, there are exceptions, such as cryptors\r\nand ransomware Trojans that can do their job just fine without using the Internet. However, they also require their\r\nvictims to establish contact with the threat actor so they can send the ransom and recover their encrypted data. If\r\nwe omit these two and have a look at the types of malware that have no communication with a C\u0026C and/or threat\r\nactor, all that remains are a few outdated or extinct families of malware (such as Trojan-ArcBomb), or irrelevant,\r\ncrudely made prankware that usually does nothing more than scare the user with screamers or switches mouse\r\nbuttons.\r\nMalware has come a long way since the Morris worm, and the authors never stop looking for new ways to\r\nmaintain communication with their creations. Some create complex, multi-tier authentication and management\r\nprotocols that can take weeks or even months for analysists to decipher. Others go back to the basics and use IRC\r\nservers as a management host – as we saw in the recent case of Mirai and its numerous clones.\r\nOften, virus writers don’t even bother to run encryption or mask their communications: instructions and related\r\ninformation is sent in plain text, which comes in handy for a researcher analyzing the bot. This approach is typical\r\nof incompetent cybercriminals or even experienced programmers who don’t have much experience developing\r\nmalware.\r\nHowever, you do get the occasional off-the-wall approaches that don’t fall into either of the above categories.\r\nTake, for instance, the case of a Trojan that Kaspersky Lab researchers discovered in mid-March and which\r\nestablishes a DNS tunnel for communication with the C\u0026C server.\r\nThe malicious program in question is detected by Kaspersky Lab products as Backdoor.Win32.Denis. This Trojan\r\nenables an intruder to manipulate the file system, run arbitrary commands and run loadable modules.\r\nEncryption\r\nJust like lots of other Trojans before it, Backdoor.Win32.Denis extracts the addresses of the functions it needs to\r\noperate from loaded DLLs. However, instead of calculating the checksums of the names in the export table (which\r\nis what normally happens), this Trojan simply compares the names of the API calls against a list. The list of API\r\nnames is encrypted by subtracting 128 from each symbol of the function name.\r\nhttps://securelist.com/use-of-dns-tunneling-for-cc-communications/78203/\r\nPage 1 of 6\n\nIt should be noted that the bot uses two versions of encryption: for API call names and the strings required for it to\r\noperate, it does the subtraction from every byte; for DLLs, it subtracts from every other byte. To load DLLs using\r\ntheir names, LoadLibraryW is used, meaning wide strings are required.\r\n‘Decrypting’ strings in the Trojan\r\nNames of API functions and libraries in encrypted format\r\nIt should also be noted that only some of the functions are decrypted like this. In the body of the Trojan, references\r\nto extracted functions alternate with references to functions received from the loader.\r\nC\u0026C Communication\r\nThe principle behind a DNS tunnel’s operation can be summed up as: “If you don’t know, ask somebody else”.\r\nWhen a DNS server receives a DNS request with an address to be resolved, the server starts looking for it in its\r\ndatabase. If the record isn’t found, the server sends a request to the domain stated in the database.\r\nLet’s see how this works when a request arrives with the URL Y3VyaW9zaXR5.example.com to be resolved. The\r\nDNS server receives this request and first attempts to find the domain extension ‘.com’, then ‘example.com’, but\r\nhttps://securelist.com/use-of-dns-tunneling-for-cc-communications/78203/\r\nPage 2 of 6\n\nthen it fails to find ‘Y3VyaW9zaXR5.example.com’ in its database. It then forwards the request to example.com\r\nand asks it if such a name is known to it. In response, example.com is expected to return the appropriate IP;\r\nhowever, it can return an arbitrary string, including C\u0026C instructions.\r\nDump of Backdoor.Win32.Denis traffic\r\nThis is what Backdoor.Win32.Denis does. The DNS request is sent first to 8.8.8.8, then forwarded to\r\nz.teriava[.]com. Everything that comes before this address is the text of the request sent to the C\u0026C.\r\nHere is the response:\r\nDNS packet received in response to the first request\r\nObviously, the request sent to the C\u0026C is encoded with Base64. The original request is a sequence of zeros and\r\nthe result of GetTickCount at the end. The bot subsequently receives its unique ID and uses it for identification at\r\nthe start of the packet.\r\nThe instruction number is sent in the fifth DWORD, if we count from the start of the section highlighted green in\r\nthe diagram above. Next comes the size of the data received from C\u0026C. The data, packed using zlib, begins\r\nimmediately after that.\r\nThe unpacked C\u0026C response\r\nThe first four bytes are the data size. All that comes next is the data, which may vary depending on the type of\r\ninstruction. In this case, it’s the unique ID of the bot, as mentioned earlier. We should point out that the data in the\r\npacket is in big-endian format.\r\nhttps://securelist.com/use-of-dns-tunneling-for-cc-communications/78203/\r\nPage 3 of 6\n\nThe bot ID (highlighted) is stated at the beginning of each request sent to the C\u0026C\r\nC\u0026C Instructions\r\nAltogether, there are 16 instructions the Trojan can handle, although the number of the last instruction is 20. Most\r\nof the instructions concern interaction with the file system of the attacked computer. Also, there are capabilities to\r\ngain info about open windows, call an arbitrary API or obtain brief info about the system. Let us look into the last\r\nof these in more detail, as this instruction is executed first.\r\nComplete list of C\u0026C instructions\r\nhttps://securelist.com/use-of-dns-tunneling-for-cc-communications/78203/\r\nPage 4 of 6\n\nInformation about the infected computer, sent to the C\u0026C\r\nAs can be seen in the screenshot above, the bot sends the computer name and the user name to the C\u0026C, as well\r\nas the info stored in the registry branch Software\\INSUFFICIENT\\INSUFFICIENT.INI:\r\nTime when that specific instruction was last executed. (If executed for the first time,\r\n‘GetSystemTimeAsFileTime’ is returned, and the variable BounceTime is set, in which the result is\r\nwritten);\r\nUsageCount from the same registry branch.\r\nInformation about the operating system and the environment is also sent. This info is obtained with the help of\r\nNetWkstaGetInfo.\r\nThe data is packed using zlib.\r\nThe DNS response prior to Base64 encoding\r\nThe fields in the response are as follows (only the section highlighted in red with data and size varies depending\r\non the instruction):\r\nBot ID;\r\nSize of the previous C\u0026C response;\r\nThe third DWORD in the C\u0026C response;\r\nAlways equals 1 for a response;\r\nGetTickCount();\r\nSize of data after the specified field;\r\nSize of response;\r\nActual response.\r\nAfter the registration stage is complete, the Trojan begins to query the C\u0026C in an infinite loop. When no\r\ninstructions are sent, the communication looks like a series of empty queries and responses.\r\nhttps://securelist.com/use-of-dns-tunneling-for-cc-communications/78203/\r\nPage 5 of 6\n\nSequence of empty queries sent to the C\u0026C\r\nConclusion\r\nThe use of a DNS tunneling for communication, as used by Backdoor.Win32.Denis, is a very rare occurrence,\r\nalbeit not unique. A similar technique was previously used in some POS Trojans and in some APTs (e.g.\r\nBackdoor.Win32.Gulpix in the PlugX family). However, this use of the DNS protocol is new on PCs. We presume\r\nthis method is likely to become increasingly popular with malware writers. We’ll keep an eye on how this method\r\nis implemented in malicious programs in future.\r\nMD5\r\nfacec411b6d6aa23ff80d1366633ea7a\r\n018433e8e815d9d2065e57b759202edc\r\n1a4d58e281103fea2a4ccbfab93f74d2\r\n5394b09cf2a0b3d1caaecc46c0e502e3\r\n5421781c2c05e64ef20be54e2ee32e37\r\nSource: https://securelist.com/use-of-dns-tunneling-for-cc-communications/78203/\r\nhttps://securelist.com/use-of-dns-tunneling-for-cc-communications/78203/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia", "MITRE" ], "references": [ "https://securelist.com/use-of-dns-tunneling-for-cc-communications/78203/" ], "report_names": [ "78203" ], "threat_actors": [], "ts_created_at": 1775434501, "ts_updated_at": 1775791317, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/86bd49705271eaa7afcd9bf869ac3cf8767e1c5b.pdf", "text": "https://archive.orkl.eu/86bd49705271eaa7afcd9bf869ac3cf8767e1c5b.txt", "img": "https://archive.orkl.eu/86bd49705271eaa7afcd9bf869ac3cf8767e1c5b.jpg" } }