With all the news surrounding the breach of SolarWinds update server, and subsequently a majority of clients downloading and installing a backdoor, there has been a lot of analysis of the malware, and the supposed DGA that is being generated. I’m here to question if the behavior fits more of a DNS tunneling event, instead of a DGA.

To support my argument, let’s go back to the definitions of what a DGA and a DNS Tunneling is.

Definition of a DGA

A DGA, or Domain Generation Algorithm, is a technique that malwares use to reach out to their C2 server, either as a keep-alive signal, or to send/receive information. The motivations of a malware using a DGA is to avoid using static IP addresses or domains to contact it’s C2 server, which can easily be blocked. As defined on the MITRE ATT&CK site:

Adversaries may make use of Domain Generation Algorithms (DGAs) to dynamically identify a destination domain for command and control traffic rather than relying on a list of static IP addresses or domains. This has the advantage of making it much harder for defenders block, track, or take over the command and control channel, as there potentially could be thousands of domains that malware can check for instructions.

https://attack.mitre.org/techniques/T1568/002/

A DGA will generate several gibberish domains (or a concatenation of dictionary words, called dictionary DGA), and the malware will attempt to connect to each of them. Some example domains generated by the malware Necurs are shown below:

sxotmrxwhddr[.]com
btysiiquuc[.]com
kfncxvayakmb[.]com
vmslcvvocseu[.]com
boymlujtgp[.]nu
ybynentfsjvmsgtktcoog[.]im
oiijxplrnmvgskxwaye[.]ru
imgirmyddbsniuh[.]pw
ultrttvbvjaanrj[.]jp

We can see that aside from the random domains, the TLDs are also constantly changing. (To read more about Necurs DGA, go here: https://johannesbader.ch/blog/the-dgas-of-necurs/)

You can detect DGA behaviors by observing a huge amount of NXDOMAIN DNS replies for random domains, and hopefully, none has been resolved.

Definition of a DNS Tunnel

DNS Tunneling on the other hand is a technique that abuses the DNS protocol to send data either through the various DNS records such as the TXT record, or information being encoded in the domain and sublabels. As defined on the MITRE ATT&CK site:

Adversaries may communicate using the Domain Name System (DNS) application layer protocol to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server.

https://attack.mitre.org/techniques/T1071/004/

One of the more famous examples of DNS Tunneling was by the OilRig threat group. To read more about their analysis, go here: https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/

In one of their analysis, we see that the domains they use is ntpupdateserver[.]com, with varying sublabels to carry different pieces of encoded information.

A DNS Tunnel in this case would almost always have a fixed domain, with encoded information contained in the DNS records or sublabels. There isn’t a huge volume of NXDOMAINs, and each DNS query contains valid information.

Why SUNBURST seems more like a DNS Tunnel

There are several articles written that references SUNBURST generated domains as a DGA. The domains generated by SUNBURST all end with avsvmcloud[.]com, with several pieces of encoded information prepended to it. An example of such a domain is

7cbtailjomqle1pjvr2d32i2voe60ce2[.]appsync-api[.]us-east-1[.]avsvmcloud[.]com

where the subdomain portions are encoded representations of the following information

<encoded_guid> + <byte> + <encoded_hostname>

The different possible domains generated by SUNBURST are in this format

<ENCODED VICTIM HOSTNAME>.appsync-api.{eu,us}-{west,east}-{1,2}.avsvmcloud[.]com

Depending on the CNAME responses and the IP block of the A record of the DNS reply to the domain, the malware would do different things. The CNAME responses tells the malware which C2 domain to connect to, while the IP block of A record responses controls the malware behavior.

The problem with this is that by simply blocking asvsvmcloud[.]com, we would be able to stop all queries to that domain. Also, based on the definition of a DNS tunnel above, it has a fixed domain avsvmcloud[.]com, with varying encoded information contain in the sublabels of the domain.

By definition of a DGA, these domains generated were not for the purposes of evading defenses, and there would not be a large quantity of NXDOMAINs. There was not a huge collection of random domains generated, but rather, these sublabels were carrying encoded information of the compromised host, and also as a means for controlling the malware based off the CNAME and A records.

The response of a resolved DGA traffic is a C2 IP address, while the response of a DNS tunnel is some form of communication to and from the malware and the C2 server, which is exactly what SUNBURST is doing.

Based off these observations, is it really a DGA, or a DNS Tunnel?

While this argument may seem trivial, it’s crucial in the age of “Next-Generation” detection systems that leverages off Machine Learning, which requires appropriate labelled training data. By incorrectly labelling the data, we may be training our systems to catch the wrong features for different alert types. In this case, the features of a DGA and a DNS Tunnel are definitely distinct. Here’s a list of hostnames generated by SUNBURST: https://github.com/bambenek/research/blob/main/sunburst/uniq-hostnames.txt