DNS is a fundamental protocol that allows applications such as web browsers to work based on domain names.
However, it is not intended that DNS will be used for command channels or general purpose tunneling. However, several utilities have been developed to enable tunneling over DNS. However, because it's not intended for general data transfer, DNS places less emphasis on security auditing than other protocols. This means that DNS tunneling, if left undetected, poses a significant security risk for companies.
This text provides an overview of DNS tunneling utilities and techniques for detecting DNS tunneling. Two categories of detection are discussed in more detail: payload analysis and traffic analysis. Payload analysis is used to successfully identify specific DNS tunneling utilities. Traffic analysis, on the other hand, can be used for universal DNS tunneling detection. Using these detection techniques, organizations can reduce the risk involved.
The Domain Name System (DNS) is an important protocol used in web browsing and email to allow these applications to use names such as example.com instead of IP addresses. Because the protocol isn't designed for data transfer, DNS can be overlooked as a threat for malicious communications or for data exfiltration.
Even today, most companies are still under-armed when it comes to DNS attacks. Many companies have little or no
Monitoring your DNS log. Instead, they focus resources on web or email traffic, since these targets are more commonly used as an attack vector.
There are a number of tools for tunneling over DNS that will be discussed in this text. A big motivation for using these tools is the free Wi-Fi access for sites with a proprietary portal for http and so-called "Free Flowing DNS". However, these tools can also be used for abusive purposes. Because a DNS tunnel can be used as a full remote control channel for a compromised internal host. This can then be used to execute OS commands or file transfers and in some cases even a full IP tunnel can be established. The danger of these tools is that they can also be misused to inject malware into a system via a covert channel. Feederbot is one such tool to use DNS as a communication method.
DNS tunneling poses a significant threat, but there are methods to identify these potential threats early. DNS tunnels can be detected by analyzing a single DNS payload or by traffic analysis by analyzing the number and frequency of requests. Payload analysis is used to detect malicious activity based on a single request. Attributes of a request such as domain length, number of bytes and content can be used to create so-called recognition rules. Recognizing unusual record types like TXT can also be used to do this. Another method for early detection is traffic analysis.
The traffic analysis works on a basis, multiple requests and the total traffic to detect malicious activities. Attributes that can be used for traffic analysis include volume of DNS traffic, number of hostnames per domain, geographic location, and domain history.
The Domain Name System (DNS) is a critical protocol and service used on the Internet. The basic function of DNS is to map domain names to IP addresses. This allows users to type a domain name (e.g. example.com) into their web browser, and DNS will perform a forward lookup to find one or more IP addresses for that domain name. This is referred to as an "A" record. The user's network stack can then send http traffic to the destination IP address. The DNS protocol is constantly being improved to provide and enable new features. Although there are previous RFCs, the core functionality of DNS is defined in RFCs 1034 and 1035. There are over 20 other RFCs that describe additional functionality for DNS.
DNS has more than 30 record types, with many of the common record types being critical to providing core Internet services. As mentioned earlier, the “A” record type maps a domain name to an IPv4 address. The “AAAA” record is used to map a domain to an IPv6 address. The "CNAME" record type is used to map a domain name to the canonical name. The "MX" record type is used to define mail servers for a domain. The "NS" record type is used to define authoritative name servers for a domain. The "PTR" or pointer record is often used to associate an IP address with its domain name. This is commonly referred to as a reverse lookup. The TXT record type is used to return text data. This record type was developed for specific purposes such as the Sender Policy Framework (SPF) for anti-spam.
DNS uses both UDP server port 53 and TCP server port 53 for communication. UDP is used by default, however TCP is used for zone transfers or for payloads over 512 bytes. There is also the so-called “Extension Mechanisms for DNS”, EDNS for short. If EDNS is supported by both hosts in a DNS communication, then UDP payloads larger than 512 bytes can be used. EDNS is a feature that can be used to improve bandwidth for DNS tunneling.
DNS is a hierarchical system; each level in the hierarchy may be provided by a different server with different ownership. There are 13 root DNS servers for the Internet, labeled “A” through “M”. However, these are represented by far more than 13 physical servers. The hierarchical nature of DNS can be explained with an example. Suppose there is a request for the IP address of a domain named my.test.example.com. placed. A query is first forwarded to the root servers to find out which server controls the top-level domain .com. The .com server provides the server that controls the example.com domain. Next, the example.com DNS server provides information about the server that controls the test.example.com domain. Finally, the DNS server test.example.com provides the IP address for my.test.example.com.
With this hierarchical system, a domain owner can define the servers for their domain. This means they are in control of the hosts' ultimate destination for DNS queries to their domain. In an enterprise, endpoints never make DNS queries directly to the Internet. Internal DNS servers are available for this purpose, which provide DNS services for an endpoint. However, because DNS forwards queries until an authoritative name server is contacted, an attacker who has gained access to an internal endpoint can use the corporate DNS infrastructure to establish a DNS tunnel to a corporate-controlled domain.
You have to keep in mind that DNS operates cashing. When DNS responses are provided, Time to Live (TTL) is also provided. The receiving intermediate server can temporarily store the result in a cash for the value of this period of time. Then, when an identical request arrives, the cached result can be made available and no new search needs to be performed.
Many of the tools used to create DNS tunnels were designed with the intention of
Bypass portals for paid Wi-Fi services. If one of these systems allows outbound DNS traffic, a DNS tunnel can be set up, tunneling the IP traffic, so that one can use the service for free.
Some of the DNS tunneling utilities create a Tun or Tap interface locally on the endpoint systems. A Tun or Tap device is also created on the DNS server hosting the DNS tunneling tool. This allows the user to tunnel IP traffic to the Internet. This technique may interfere with how VPN software such as VPN works. B. OpenVPN can be compared. There are even commercial providers who offer a server-side tunnel as a service and market this service as "VPN over DNS". Using such software, the user can connect to the service provider's server, which then runs server-side tunneling.
These services are now available for various operating systems, including z. B.Android. It is known that such tunneling software (e.g. Iodine) was used in some attacks.
A number of DNS tunneling programs have been developed since the late 90's. All programs use similar techniques, but have variations in coding and other implementation details. The core techniques used by all DNS tunneling utilities include a controlled domain or subdomain, a server-side component, a client-side component, and data encoded in DNS payloads. The controlled domain is used to define the authoritative name server for that domain or subdomain. The server-side component is called the DNS tunnel server. The DNS tunnel server is the authoritative name server for the controlled domain. It is typically an Internet-accessible server controlled by the user. The client-side component hosts the other end of the tunnel. This could e.g. B. an endpoint in a security-controlled corporate environment. The tunnel enables communication between the controlled endpoint and any host on the Internet. The client-side component initiates a DNS request, for which the DNS tunneling server takes on the role of name server.
One of the core techniques of tunneling programs is the encoding of data in "DNS payloads". From an oversimplified point of view, a client wants to send data to the server. This data is encoded in the "DNS payload". For example, the customer might send an "A-Record Request" with the data in the host
MRZGS3TLEBWWW64TFEBXXMYLMO RUW4ZI.t.example.com. The server
could respond with a CNAME response: NVWW2IDPOZQWY5DJNZZSQ.t. example.com. In this way, any data can be encrypted and sent to the server. The server can also respond with data. However, if there is a need for the server to initiate communication, this cannot be done directly. Clients don't have any
Services that listen for DNS queries, and they are usually behind a firewall. However, server-initiated communication can be achieved by the client making regular requests to the server. Then, when the server has data for the client, it can send it in response to the request. As mentioned earlier, the various DNS tunneling utilities differ in their implementation details.
DNS utilities vary in implementation language, with tools e.g. B. implemented with C, Java, Perl and Python, just to name a few. Some utilities use a "tun or tap" to create a local interface and IP address for the tunnel on the hosts. Others only tunnel the binary data, which can be used to issue operating system commands and transfer files, similar to Netcat. The encoding method - including the DNS record type - is one area where the different tools differ fundamentally. Some utilities share common record types such as B. “A” records.
Others use experimental data types like 'null' records and EDNS to improve performance.
Base32 or 5-bit encoding is typically used for requests from the client. Although DNS names are mixed case, this is to be ignored, so
26 letters are available. In addition, numbers and the character "-" are permitted. This gives a total of 37 unique characters. Therefore, we can sample data in 5-bit increments, giving us 32 possible values. These 32 values fit into our 37 available characters. We can then build a series of nested subdomains from the encoded data. DNS allows us up to 255 characters, with each subdomain (aka label) containing 63 characters or less.
Base64 or 6-bit encoding can be used for "TXT" record responses. A “TXT” record can be mixed case, resulting in 52 characters. The digits 0-9 bring us 10 more. If we consider two additional characters like “-” and “+” then we get 64 unique values that can be used for Base64 encoding. Similar to Base32 encoding, requests can be encoded and sent 6 bits at a time.
Hex encoding is another encoding method. With hex encoding, the two
Hex values of the characters used to represent each byte. This method is only used by DNScat-B.
DNS tunneling utilities can use different DNS record types and encoding methods. In some cases, such as For example, with iodine, the utility automatically recognizes the best possible encoding. There are a number of other implementation techniques that deserve mention. DNS tunneling utilities can use EDNS, which allows them to use payloads that exceed the 512 bytes limit, improving performance. Another utility for DNS tunneling,
Heyoka spoofs the source IP addresses for requests to the server (upstream data) to reduce customer visibility.
There are a number of different DNS tunneling utilities. Below is an overview.
DeNiSe is a proof of concept for tunneling TCP over DNS in Python. The Github page for DeNiSe has six Python scripts from 2002 to 2006.
Many of the DNS tunneling programs do not try to avoid snooping. They rely on the fact that DNS is often not monitored. There are several DNS tunnel detection techniques, which are discussed as two separate categories in this text (the payload analysis and the traffic analysis). Payload analysis analyzes the DNS payload for requests and responses to tunnel indicators. For traffic analysis, traffic is analyzed over time. The number, frequency and other request attributes are taken into account.
One technique is to analyze the size of the request and the response. This is used to identify suspicious DNS tunneling traffic based on the ratio of source and destination bytes. DNS data residing in a MySQL database as part of a Snort/Squil Intrusion Detection System is queried for source and destination bytes. The ratio is then compared to a limit.
It is also possible to use the length of DNS queries and responses to detect tunneling. DNS tunneling utilities typically try to pack as much data into requests and responses as possible. Therefore, tunneling requests are likely to have long labels of up to 63 characters and long aggregate names of up to 255 characters. Another recommendation is to check all hostname requests longer than 52 characters.
Looking at the specific character structure of DNS names is another method that
can be used to detect tunneling. Legitimate DNS names usually have only a few digits, while encrypted names usually contain many digits. It looks at the percentage of numeric characters in domain names. Another method is to look at the length of the longest meaningful substring (LMS) and the number of unique characters. It is recommended to be cautious with any request with more than 27 unique characters. Given that legitimate domain names to some extent reflect common languages, using character frequency analysis to discover names could also be used. Repeated consonants can be looked at to detect DNA tunneling. Thus, a tunneling program can create domains of consecutive consonants and numbers that are indistinguishable from an original at a cursory glance.
In some cases, researchers have provided signatures for specific DNS tunneling tools. A signature can be used to verify specific attributes in a DNS header and to check for specific content in the payload. For example, a Snort signature was developed to detect NSTX DNS tunneling.
alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:”Potential NSTX DNS Tunneling”; content:”|01 00|”; offset:2; within:4; content:”cT”; offset:12; depth:3 ; content:”|00 10 00 01|”; within:255; classtype:badunknown; sid:1000 2;)
In the above example, the main parts of this rule are structured as follows. This signature has three substantive similarities. Offset 2 skips the ID part of the DNS header, which represents the first two bytes. The next two bytes represent several header attributes. In the case of the hexadecimal number "01", bits 0 to 6 are "0" and bit 7 is "1". This is equivalent to a DNS query with no response. Additionally, the 4 opcode bits are 0, meaning it's a standard query. The 1 in bit 7 indicates that recursion is desired. The next content match starts with "Offset 12". This is the beginning of the question section or QNAME field. Therefore, this "content match" looks for "cT" as part of the first 3 bytes of the domain name. The last content match looks for the hex values "00 10 00 01" within the first 255 bytes. This corresponds to the two bytes of the QTYPE and QLASS parts of the question section when the QTYPE is hexadecimal 10 (decimal 16) and the QCLASS is 1, which corresponds to the IN for the Internet. IN is the only common QCLASS, so it will always match the "00 01". A QTYPE of decimal 16 corresponds to the TXT record type. In summary, this signature looks for a standard DNS query for a TXT resource record with the text "cT" at the beginning of the domain.
Using a visualization, DNA tunnels can be detected, but this method requires the interactive work of an analyst. Using this method, however, the tunneled traffic stands out dramatically.
While most detection methods look at what we can see, another approach is to look at what we expect that hasn't happened yet. Calculations are performed one DNS request after the other, for example a website request via http. Another detection method is to look for DNS queries that don't have a corresponding query through an application such as http. There will be exceptions to this, but these can easily be filtered out. Security devices can perform reverse lookups of IP addresses. Anti-spam solutions use DNS queries to check if a specific IP address is blacklisted. One
Endpoint security product uses DNS queries with an encrypted file hash anchored to the FQDN to check suspicious files.
When implementing detection mechanisms, the methods must be weighed against costs and effectiveness. The cost mainly includes hard costs, such as the procurement of recognition systems, signature development time and computer resources. These systems are commonly referred to as CAP (Capture And Parse). The system captures network traffic through the use of a TAP or Span port.
Captured traffic is parsed for multiple protocols including DNS. The parsed metadata can then be queried interactively using a simple rules language. A reporting feature is also available, which is typically used for daily reporting of traffic that matches certain rules. In addition to the built-in functions, an application program interface (API) is available for direct access to the data.
Defense in Depth is a security strategy in which there are multiple layers of security. If one layer fails to detect malicious activity, there is another layer that will detect it as well. By enforcing rules using payload analysis and traffic analysis, some protection is provided at depth.
DNScat-P uses base-64 encoding, using both uppercase and lowercase letters and the “-” and “_” in the FQDN. A look at the source code
“SixBitDNSEncoder.java” indicates that “longer names are separated by periods. The class also adds the encoded frame length (the first character) and also "NAMELEN = 30". This has been observed in DNScat-P traffic. The first label is 31 characters long, the following are 30 characters long. Depending on the data size, there are up to seven labels there. To customize DNScat-P traffic, the following rule is applied:
alias.host regex '^[a-zA-Z-]{31,31}[[.period.]][a-zA-Z]{30,30}[[.period.]]'
The alias.host keyword is the name that the CAP system uses for the FQDN. The “^” character is an indicator that must match the beginning of the FQDN. The character "[a-zA-Z-]{31,31}" matches a string that uses any of the characters a through z or A through Z or "-" and is 31 characters long. The “[[.period.]]” matches the “.-” character. The "[a-zA-Z-]{30,30}" matches a string that uses any of the characters a through z or A through Z or "-" and is 31 characters long. This signature corresponds to an FQDN, where the first label is 31 characters long and the second label is 30 characters long
Many of the DNS tunneling tools do a query. Normally the server cannot contact the customer directly. The client therefore polls the server regularly. If the server has data to send to the client, it can be sent in response to the query. Based on observation, the DNScat-P query starts with a letter character, followed by a hyphen “-”, followed by six letter characters. The characters can be uppercase or lowercase. Therefore, the following rule is used with DNScat-P:
alias.host regex '^a-[a-zA-Z0-9]{6,6}[[.period.]]'
The alias.host keyword is the name that the CAP system uses for the FQDN.
The “^” character is an indicator that must match the beginning of the FQDN. The remaining parts “a-[a-zA-Z]{6,6}[[[.period.]” is used to match the letter “a followed by a dash”, then six letters, then a “ .”.
There are variations in the construction of the FQDN depending on the mode (datagram or stream) and whether a session is being used or not. The make-up for a datagram mode without a session looks like this:
"… .."
For this rule we will focus on the signature element. This element is present in all FQDNs generated by DNScat-B. By default it is set to "dnscat", although it can easily be changed using the "signature" command. To match FQDNs starting with dnscat, the following rules must be used:
alias.host begins'dnscat'
The alias.host keyword is the name that the CAP system uses for the FQDN. The keyword “begins” means that we want to search for any alias.host that starts with the following string. The "dnscat" portion of the rule indicates that the alias.host must begin with the string "dnscat".
The DNScat-B utility uses NetBIOS encoding by default. With this encoding, "every character will be in the range from "A" to "O". By default, when DNScatB transmits data, there are domain labels of length 63 that can be changed,
using the -chunksize command line option. By default, 3 labels are used for data, which can be changed using the -sections command line option. NetBIOS detects encoded traffic looking for the data portion of the FQDN with the following rule:
alias.host regex '[[.period.]][ao]{50,63}[[.period.]][ao]{50,63}[[.period.]]'
The alias.host keyword is the name that the CAP system uses for the FQDN. The "[[.period.]]" part matches the character "." . The "[ao]{50,63}" part searches for a string containing one of the characters a through o and is 50 through 63 characters long.
The DNScat-B utility uses NetBIOS encoding by default. With this encoding, "every character will be in the range from "A" to "O". By default, when DNScatB transmits data, there are domain labels of length 63 that can be changed,
using the -chunksize command line option. By default, 3 labels are used for data, which can be changed using the -sections command line option. NetBIOS detects encoded traffic looking for the data portion of the FQDN with the following rule:
alias.host regex '[[.period.]][ao]{50,63}[[.period.]][ao]{50,63}[[.period.]]'
The alias.host keyword is the name that the CAP system uses for the FQDN. The "[[.period.]]" part matches the character "." . The "[ao]{50,63}" part searches for a string containing one of the characters a through o and is 50 through 63 characters long.
The DNScat-B utility uses NetBIOS encoding by default. With this encoding, "every character will be in the range from "A" to "O". By default, when DNScatB transmits data, there are domain labels of length 63 that can be changed,
using the -chunksize command line option. By default, 3 labels are used for data, which can be changed using the -sections command line option. NetBIOS detects encoded traffic looking for the data portion of the FQDN with the following rule:
alias.host regex '[[.period.]][ao]{50,63}[[.period.]][ao]{50,63}[[.period.]]'
The alias.host keyword is the name that the CAP system uses for the FQDN. The "[[.period.]]" part matches the character "." . The "[ao]{50,63}" part searches for a string containing one of the characters a through o and is 50 through 63 characters long.
Some of the specific payload parsing rules can be circumvented by a skilled attacker. You could shorten the labels used to reduce the number of labels in an FQDN. However, you always need to create a large number of unique FQDNs, which usually come from a specific root domain. The root domains are the two rightmost labels, namely the “Second Layer Domain” and the “Top Level Domain. For the FQDN “www.example.com”, the root domain is “example.com”. It is also possible to use multiple root domains for tunneling, but this still results in a large number of FQDNs per root domain.
Therefore, detecting the number of FQDNs per root domain is a very important one. The CAP system used does not provide a method for reporting the number of FQDNs per root domain. However, it has one
Application program interface or API that can be used to access the stored data and create the desired rule.
The traffic analysis rule developed with the API is a multi-step process.
These steps are all contained in a Python script that collects and parses DNS data.
First, DNS data for a specific time window is accessed via the API and saved as an xml file. Second, the xml file is cleaned up to prepare for import. Third, the xml file is imported into MySQL. Fourth, the data is analyzed using Python and MySQL to find the top numbers of unique FQDNs per root domain.
Step 1: The most important parts of this step are the data selection query and the output type. This line (note: line wraps) shows the data selection:
qstring = “select time, ip.src, ip.dst, alias.host where service='53' && monitor='external' && time='” + texttimestart + “'-'” + texttimeend+”' && tld != 'arpa'”
Time, source IP address, destination IP address, and FQDN are selected for DNS traffic over a specified period of time. Only external DNS queries are honored
reduce the amount of processing. Domains ending in ".arpa" are excluded to prevent reverse lookups.
The next two lines show the query and output type.
ctype="text/xml"
nwquery = nwmodule.nwQuery(0, 0, qstring, ctype, 1000000)
The output format xml. The next step is to clean up the xml.
Step 2: The xml output is not ready to be imported into xml. One of the fields used
the name "group", which is a reserved word in MySQL. So using "group" for a column header is problematic, so we need to change it to "session". The second problem is that the last data is not tagged with an “Attribute Name”. The cleanup is best shown with an example. Only one line is shown for the example. A session usually has additional lines for source IP, destination IP and time.
Line before cleanup:
line after cleanup
Step 3: Once the file is cleaned, importing it into mysql is relatively easy. The following line is used:
LOAD XML INFILE 'CAPexport.xml' INTO TABLE dnsx rows identified by '';
After the import is complete, the table is available in mysql. Note that a session has multiple rows in the table and that the data column has different types of
has values such as time, source IP address, destination IP address, or FQDN. There are often several FQDN lines, with the FQDN always being repeated. The data is reorganized. when they are analyzed.
Step 4: The data is analyzed using the Python script to finally provide a report on root domains with the highest number of unique FQDNs. This step has two substeps.
One is by using a loop that runs on different session IDs. For each unique session, a row has been created in a new table that contains columns for each data type: time, source IP, destination IP, and FQDN. In addition, the root domain is extracted and added in its own column.
Next, also with the help of a loop, the new table to the different root domains has to be run through. A number of unique FQDNs are reported for each domain. This is the desired end result. By looking at the FQDN numbers, DNS can be identified if there are a very high number of unique FQDNs for tunnels
a specific domain exists.
There are a large number of DNS tunneling tools with a wide range of capabilities.
They provide a hidden channel for malicious activities that pose a significant threat. These threats can be mitigated through payload analysis and traffic analysis.
There are more than a dozen different DNS tunneling utilities covered in this text. They range from tools with netcat-like capabilities to full IP tunneling through DNS. Some tools have been available for several years, others have only recently been developed with improved capabilities. For example, Heyoka uses source spoofing to reduce the visibility of the compromised endpoint. Additionally, DNS tunneling capability is conveniently available as part of the Metasploit and Squeeza penetration testing tools.
DNS tunneling poses a significant threat to organizations. The top two
DNS tunneling threats are control and governance of compromised endpoints and data exfiltration. The command and control capabilities can also include full remote access to a compromised endpoint. This can be achieved with netcat-like functions, with some DNS tunneling utilities, or with any remote access application over a full IP tunnel.
The other threat is data exfiltration. DNS tunneling provides a hidden channel for data exfiltration. Although inefficient for data transfer, DNS tunneling can easily be used to exfiltrate sensitive data such as password hashes or documents.
The threat of DNS tunneling can be mitigated by implementing a payload analysis and traffic analysis technique. Payload analysis can be used to detect DNS tunneling by using signatures based on attributes of individual DNS payloads such as FQDN. Payload analysis is most effective for detecting well-known DNS tunneling utilities. Traffic analysis can be used to detect DNS tunneling based on characteristics of overall traffic. A universal DNS tunneling detector can be implemented using traffic analysis. This is accomplished by monitoring the number of unique FQDNs for a given root domain. This technique is independent of DNS resource record types, encoding, DNS label length, and FQDN length.
