Infosec skills – Network traffic analysis for IR: DNS protocol with Wireshark
The Domain Name System (DNS) protocol was first defined in RFCs 1034 and 1035 but has been updated by many subsequent RFCs. A primary purpose of the DNS protocol is to provide computers with a mapping from domain names (like infosec.com) to IP addresses (like 127.0.0.1).
When most people use the internet, they type a domain name into the address bar of their browser window. These domain names have the advantages of being easy to remember and help to define the website that a user is actually trying to reach on a given web server (which may host multiple different domains).
However, the computers that make up the internet work on IP addresses, not domain names. It is inefficient and unfeasible for each computer in the internet to track the full set of mappings from domain name to IP address.
Instead, the DNS system uses a hierarchical structure of name servers. A domain name is broken up by the periods within it, and (theoretically) each segment is handled by a different level of name server. Resolving resources.infosec.com would require asking a name server with knowledge of the .com namespace to provide the IP address of the infosec.com name server. Contacting the infosec.com name server would then allow the browser to learn the IP address of the server hosting resources.infosec.com.
While the DNS protocol is effective, it does have its downsides. One of the primary ones is that all DNS traffic is sent in plaintext, making it readable and editable by eavesdroppers. This issue is addressed using protocols like DNSSEC or DNS over HTTPS, which Google and Mozilla are introducing into their browsers.
The DNS protocol in Wireshark
Wireshark makes DNS packets easy to find in a traffic capture. The built-in dns filter in Wireshark shows only DNS protocol traffic. Also, as shown below, DNS traffic is shown in a light blue in Wireshark by default.
DNS is a bit of an unusual protocol in that it can run on several different lower-level protocols. Since DNS is a simple query-response protocol, many implementations use UDP, as there is no need for the additional guarantees provided by TCP. However, DNS can also run on TCP and a variety of other base protocols.
The images above show the structure of a simple DNS request and response. As shown at the top of the request packet, a single request can carry multiple queries. The request data structure informs the DNS server of the type of packet (query), the number of questions that it contains (one), and then the data in the queries. In this case, the request is for the A record for www.netbsd.org.
A DNS response uses the exact same structure as a DNS request. The only differences between this request and response are the flags (it contains a response) and that it has a non-zero number of answers. The questions sent by the client are included in the response as well.
While requesting a host address (A) record is a common use of DNS, it is not the only purpose. DNS includes several different types of records. Commonly-used ones include:
- A: Host address
- AAAA: IPv6 host address
- ALIAS: Auto resolved alias
- CNAME: Canonical name for an alias
- MX: Mail eXchange
- NS: Name Server
- PTR: Pointer
- SOA: Start Of Authority
- SRV: location of service
- TXT: Descriptive text
Additional record types exist for DNSSEC and other less-used ones also exist. The sheer amount of data contained in an organization’s DNS records make them a common early stop for hackers performing passive reconnaissance using open-source intelligence (OSINT).
DNS protocol analysis for incident response
The DNS protocol analysis for incident response is a foundational protocol of the internet. Everyone uses it, and DNS traffic is always allowed through network firewalls. As a result, it also can be abused by attackers in a variety of different ways.
Malware C2 infrastructure
Most malware is not designed to operate in isolation. Instead, it uses command-and-control (C2) traffic to interact with its owner’s back-end infrastructure. This allows the malware to send collected data or intelligence back to its controller and to receive commands regarding actions that it should take.
While some malware may carry embedded IP addresses, most malware is designed to be flexible and resilient against the loss of C2 infrastructure to law enforcement. Instead of hard-coded IP addresses, it uses domain names that are resolved to IP addresses using DNS. A common way of detecting malware is through the use of domain/IP blacklists, where organizations block connection attempts to known malicious domains.
Some malware attempts to protect itself against domain or IP blacklists using domain generation algorithms (DGAs). DGAs run the same pseudo-random algorithm in the malware and the C2 server, where the server generates and registers a domain before the malware tries to connect. Since each domain is used only a few times, it is harder to blacklist them.
As a result of the frequent use of DGAs, 70% of new domains are malicious. Monitoring for DNS requests and checking the age of the requested domain can help in detection of malware infections.
Most organizations have firewalls in place to protect against the use of unauthorized protocols. This can also help cut down on malware C2 communications and data exfiltration since they are limited in their choice of ports to use.
However, DNS is always allowed through the firewall, and DNS users have a lot of flexibility in the data that they send in a DNS request or response (since domain names can be essentially random strings). Some threat actors take advantage of this by using DNS traffic for C2 and data exfiltration.
One way to detect suspicious use of DNS is to look at the distribution of DNS requests over a user session. Most web pages make all of their DNS requests in a wave at the beginning as they try to load all of the content on the page. If DNS requests do not follow this distribution, they may warrant further analysis.
Distributed Denial of Service (DDoS) attacks are designed to overwhelm a target computer with more traffic than it can receive or process. This can be accomplished in a variety of different ways, but the use of DDoS amplifiers are a common tactic.
DDoS amplifiers are protocols that have larger responses than requests and allow an attacker to spoof the source IP address of the request. Since DNS responses use UDP and include all of the data from the request, the DNS protocol can be an effective DDoS amplifier.
A DNS request used as a DDoS amplifier will likely originate from outside the network, go to an external DNS server, and result in a response to an internal computer. If a machine is receiving DNS responses with no corresponding request (especially at a high volume), it may be experiencing a DDoS attack using DNS amplification.
Computers on the internet rely on DNS name servers to correctly translate domain names to IP addresses. If an attacker can gain control of a trusted DNS server or point computers to one under their control, they can point requests for trusted sites to attacker-controlled webpages. This could be detected if sudden changes in the IP address of commonly used sites or DNS name servers used by computers suddenly change.
Monitoring DNS traffic in Wireshark
DNS is a foundational protocol of the internet and is common to see on the network. While there can be a lot of variation in DNS requests, since people visit a variety of different sites, most requests look fairly “normal.” Monitoring for nonsense domain names, known-bad websites, lookalike domains and DNS responses without requests can be valuable for identification of attack traffic.
- Domain Name System (DNS), Wireshark
- DNS Record types, Simple DNS Plus
- Vast majority of newly registered domains are malicious, SC Magazine
We've encountered a new and totally unexpected error.
Get instant boot camp pricing
A new tab for your requested boot camp pricing will open in 5 seconds. If it doesn't open, click here.