Report an incident
Report an incident

DGA botnet domains: malicious usage of pseudo random domains
06 May 2015 | CERT Polska | #analysis, #botnet, #dga, #DNS

dga_iconIn the previous entry we showed examples of domains, which could be easily missclassified as DGA botnet domains. Most of them are machine generated and used in a non-malicious manner. In this entry, conversely, we will present examples of pseudo random domains, which could be used in attacks or be an evidence of such attack.

Pseudo Random Subdomain Attack

Pseudo Random Subdomain Attack is a DDoS attack on authoritative name servers. It involves sending big number of DNS queries for subdomains of the victim domain, what eventually causes denial of service for legitimate queries. The attack could look similar to DGA botnet usage, because subdomains are generated pseudo randomly. For example, if authoritative name servers of domain

<span class="text">example.com</span>

are attacked, then queries will look like

<span class="text">abc4gd5fr7.example.com</span>

. Moreover, randomness of subdomains prevents them from being cached. Also one can use open resolvers to amplify the attack – some resolvers resent the query in case of lack of response from the authoritative server, e.g. Bind from version 8.2 performs two query rounds in such case. It is not a big amplification comparing to the reflected attacks, however it certainly helps attackers in making servers unavailable.

DNS tunnels

Another source of random domains are DNS tunnels, which generate DNS queries in a similar way to DGA botnets. They use DNS traffic as a medium to create a separate communication channel. DNS tunnels are used in networks, in which only few types of traffic are permitted to reach Internet, e.g. corporate or hotel networks. Sometimes DNS traffic is not blocked in them, what gives opportunity to use it in creation of covert channels. As a result one can exchange data between local network and the Internet without any serious limitations and raising much suspicion.
Data from local network is sent in domain names queried by DNS client. Various record types can be used for response, e.g. TXT or CNAME. They are sent to an authoritative name server of domain zone which have to be managed by tunnel’s user, thus providing means of control on data exchange. Returned data is inserted in DNS response records. Example of a DNS tunnel is presented below.

 

dns_tunnel_pl

Data is encoded by the client as subdomains of example.com zone. Next, the client sends query for CNAME record of such coded domain to the local DNS server (1), which operates as an iterative server. It locates authoritative server for example.com, where the query is sent finally (2). The tunnel ends there and sent data is processed further, for example a GET query is sent to a web server (3). Returned response (4) is coded and inserted into CNAME response record. DNS response with this record is sent to the local DNS server (5) and from there to the client (6). There also are possible other scenarios of tunnels in which local DNS server is not used, for example by using open resolvers or by directly exchanging data with the authoritative server.
Fragment of a real data exchange using tunnel made with DNScapy is shown below.

dns_tunnel_1
TXT and CNAME records are used in communication. Requests have several domain levels, reaching over 200 characters of length. An example of response in CNAME record is presented below.

dns_tunnel_2

Beside random domain name small TTL value of 60 seconds stands out.
In practice DNS tunnels are used for example in hotels, where often you have to pay for Internet access. Usually DNS traffic is not blocked in such networks, thus giving opportunity to bypass access control systems. However it could be not permitted by local security policy or even be illegal.
DNS is used also in botnets as a C&C channel, e.g. in Feederbot and Morto. Despite the fact it is used slightly different than in classical channels, generated domains are similar.

Tor proxy

After a quick search one can find sites which provide access to the Tor network through normal browser, e.g. tor2web. To connect to a particular Tor Hidden Service you simply take its address in .onion pseudo-top-level domain and put as a third level domain of a Tor proxy domain. For example, address

<span class="text">3g2upl4pq6kufc4m.onion</span>

is changed to

<span class="text">3g2upl4pq6kufc4m.tor2web.org</span>

. DNS response for query for such domain carries IP address of proxy server, which is exchange point between normal Internet and Tor. Unfortunately, these proxies are used also by criminals to provide communication with their servers in the Tor network. Examples are Chanitor/Vawtrak or Ransomcrypt. Because of this misuse we consider Tor proxies as a possible mean of data exfiltration.

Malicious IDNs

Internationalized Domain Names allow to use characters from other alphabets than standard Latin (ASCII). Their Unicode form is translated into ASCII using Punycode and in this way used by the existing DNS infrastructure. The ASCII form is usually very random. We have written about IDNs in the previous part and this time we will show how they are used as a part of malicious activity.
The translation from Unicode to ASCII can be a source of ambiguities and thus used for deception. Bluecoat’s report presents several cases of it. One of them is to disguise domain name to look almost identical to the legitimate one by using different character sets. Let us consider two different domains which look very similar. Below you can see their Unicode and ASCII form.

 

idn_1

Difference between them is in used character sets. The second domain contains Cyrillic characters с and е instead of Latin c and e. ASCII representations of these domains are easily distinguishable, but when comparing Unicode forms it is hard to differentiate them.
Disguising can be done in the other way. Punycoded ASCII form could be formed in a such way that it could pretend to be a standard non-punycoded ASCII domain:

idn_2

User of Latin alphabet could not pay attention to the

<span class="text">xn--</span>

prefix and might not know it is an IDN.
A more interesting usage of IDNs is in malicious DGA. As Bluecoat states, this usage is already ongoing. The DGA uncovered by them mixes characters from different alphabets creating random strings as in this example:

idn_3

It contains characters from Latin, Gujarati, Coptic, Greek and Cherokee alphabets. However due to small traffic those domains generate it is not certain why they are created. Probably they are used in some targeted attack.
Above algorithm mixes Unicode characters, however algorithm mixing characters in ASCII form is also possible. In this case domains are generated as in classical botnet DGA, but the

<span class="text">xn--</span>

prefix is added to provide a disguise as a Punycode domain. The following scheme presents how such domains are created:

idn_scheme

Usage of prefix can mask the fact that DGA is used, however the overall mechanism is more complex and harder to implement due to the Punycode restrictions. A separate issue to consider is whether usage of IDN queries in a particular network is not anomalous by itself.

Domain shadowing

In this case DGA is used to create pseudo random subdomains of (usually) non-malicious domains. Attackers gain control of domain registration accounts through phishing of their legitimate owners. Upon that they create large number of subdomains, which are used by exploit kits. This practice has been presented on example of Angler by Talos security group and called “domain shadowing”. List of discovered domains has been attached to their report.
Subdomains are created on the third or fourth level. Some of them are strings of random characters and other consist of words from natural languages, e.g. English, German, Polish or Swedish. Additionally, different languages are mixed, for example domain

<span class="text">popularyzujacauncalculableness.[example.com]</span>

contains two words: Polish

<span class="text">popularyzujaca</span>

and English

<span class="text">uncalculableness</span>

. Some other examples from Talos list are presented below. We list only third and fourth level domains.

abfabdicejjbe.
kd84gg.head.
kawk7t.wb.
r42m7y.the.
sprobowal.
frustracja-mauraca.
konfliktgebietcategorised.
krijgsknecht-selfexploiting.
lezakowaczonale.
nieudolnych-suomenenntykset.
pociagalnocturnalemissions.

Other sources of pseudo random domains

Examples of pseudo random domains presented above are not a definitive set. Other include subdomain bruteforcing, which main objective is to map existent subdomains in target domain by sending huge number of DNS queries. It could be used in reconnaissance phase before main attack on a network. There are dedicated applications, which map subdomains automatically, e.g.

<span class="text">dnsmap</span>

or

<span class="text">dnsenum</span>

. User can define list of subdomains to check or use built-in dictionaries provided with application, which contain many pseudo random subdomains.

Conclusion

A successful detection of a DGA botnet can be difficult due to big number of similar pseudo random domains. They are used for legitimate purposes, as in CDNs, however they can be also used in a malicious way but other than botnet C&C channel. Knowledge of sources of pseudo random domains gives an opportunity to decrease the number of false alarms in detection systems and might give a hint what should be checked in the next network audit.

Share: