In a separate post, we talked about the possible different attack vectors of DNS. That post is not entire complete, and there are many more creative ways to use DNS as an attack vector.
In this post however, we’re going to be looking at the more technical aspects of DNS, such as the protocols, byte sizes and ports, and things to look out for when doing threat hunting over DNS
Its common knowledge that the server running the DNS service will expose it on port 53. Clients that want to call the DNS service will therefore connect from a random high source port, to destination port 53. Even when performing a DNS zone transfer, the destination ports are still 53.
DNS queries mainly uses UDP protocol, but only if the query size is 512 bytes and below. Any traffic more than 512 bytes, and DNS switches over to TCP.
There are several benign reasons why a query would exceed 512 bytes, such as storing DNSSEC information, or SPF information. The two sets of information are usually stored in the DNS TXT field, which allows up to 255 characters in a single string, but can have multiple strings inside it.
DNS zone transfers is another reason for DNS to use the TCP protocol.
DNS Zone Transfer
A DNS zone transfer is the process of copying contents of a zone file from a primary DNS server (master) to the secondary DNS servers (slave). There are three types of transfers that can happen: Full Transfer, Incremental Transfer, and DNS Notify
Full transfers happen when you bring up a new DNS server which is in a blank slate. To perform a one time transfer of information to the new server, you would do a full transfer.
Incremental transfers happen when you already have a master and slave server running, and any new updates to the master server gets incrementally pushed down to the slaves to keep them synchronized.
DNS notify is not exactly a transfer mechanism, but a method to circumvent constant polling from secondary DNS servers to the primary DNS servers. Using DNS notify, new changes are pushed down from the master server instead.
By filtering your DNS queries to TCP, and observing the data being sent, we can then determine if the DNS over TCP protocols are suspicious or not.
DNS Threat Hunting
When looking for suspicious DNS queries, we want to be looking at artefacts and behavior, such as:
Artefacts: Ports used, Protocol used, size of DNS packet, Contents of query, replies, and TXT field.
Behavior: Connection behavior, length of Connection.
When monitoring DNS ports, it should be common behavior for the source port to be a random high port each time. If we observe a repeated use of a source port, it could indicate a more persistent service communicating to the DNS, which is unusual. This could be indicative of a DNS tunnel, where a service abuses the DNS protocol.
Connection times to the DNS should typically be short, as the mechanism involves a query and a reply. Any long lasting DNS connection, especially over TCP should be concerning.
We also want to be paying more attention to the protocols they use, and the type of information being store in the TXT and NULL records. Investigate all DNS TCP connections to see if the switch over from UDP is because of DNSSEC or SPF information.
Don’t be quick to dismiss unexplained TCP DNS as Zone Transfers. First, establish if the two IP addresses have a master or slave relationship, and if they are even DNS servers in the first place.