When performing network forensics, all protocols should be analysed, however, some tend to be more commonly abused than others; one of these being DNS. While not as flexible as say HTTP, it does flow through, and outside of networks a lot easier due to its configuration. This means that DNS can be utilised to encapsulate data that would be routed outside the network to an attacker-controlled name server allowing data exfiltration or the download of tools. In this post, I will cover how we can use NetWitness Network to analyse the DNS protocol effectively, to do so we will use a tool called DNS2TCP (https://github.com/alex-sector/dns2tcp) in our lab to generate some sample traffic.
DNS record types
The DNS standard defines more than 80 record types, but many of these are seldom used. The most common are:
- A Record - used to map a host and domain name to the IP address (forward lookup)
- PTR Record - used to map an IP address to host and domain name (reverse lookup)
- MX Record - to return host and domain mapping for mail servers
- CNAME Record - used to return an alias to other A or CNAME records
- TXT Record - used to provide the ability to associate arbitrary text with a host or other name
In this post, we will focus on TXT records being used to encapsulate data. TXT records are typically utilised as the size of this field allows for larger amounts of data to be transferred in a single request compared to A, or AAAA records. This field is also legitimately used to provide SPF records, specify the domain owner, return the full name of the organization, as well as other similar uses.
How Does NetWitness Network Analyse DNS?
The DNS_verbose_lua parser is available from RSA Live, it extracts metadata of interest from the DNS protocol that can help a defender in the identification of anomalous DNS traffic. We suggest that you subscribe to this parser (and others), as they are updated regularly.
Which metadata can help with the analysis?
The following meta keys are particularly useful for identifying, and subsequently analysing the DNS protocol:
| Meta Key | Description | Indexed by default |
|---|---|---|
| service | The protocol as identified by NetWitness | Yes |
| alias.host | The hostnames being resolved | Yes |
| alias.ip | The IP address that the hostname resolves to | Yes |
| service.analysis | Meta values surrounding the characteristics of the protocol | Yes |
| tld | The top-level domain extracted from the hostname | Yes |
| sld | Contains the part of hostname directly below the top-level domain (second level domain) | No |
| dns.resptext | The response for the DNS TXT record | No |
| dns.querytype | The human readable value for the DNS Query type performed in the request | No |
| dns.responsetype | The human readable value for the DNS Query type returned by the response | No |
You will notice from the table above that some of the meta keys are not indexed by default. The following entries would therefore need to be added to the Concentrators index file so that they can be used in investigations:
<key description="SLD" format="Text" level="IndexValues" name="sld" defaultAction="Closed" valueMax="500000" />
<key description="DNS Query Type" format="Text" level="IndexValues" name="dns.querytype" valueMax="100" />
<key description="DNS Response Type" format="Text" level="IndexValues" name="dns.responsetype" valueMax="100" />
<key description="DNS Response TXT" format="Text" level="IndexValues" name="dns.resptext" valueMax="500000" />
NOTE: Details regarding the Concentrator index, such as how it works, ensuring optimal performance, and how to add entries can be found here: https://community.rsa.com/docs/DOC-100556
DNS2TCP
DNS2TCP is a tool that encapsulates TCP sessions within the DNS protocol. On the server side, we configure the tool to listen on UDP port 53, as per the DNS standard, we also specify our domain, "dns2tcp.slbwyfqzxn.cloud", and the resources. Resources are a local or remote service listening for TCP connections - in the example below, I specify a resource named SSH for connections to port 22 on 127.0.0.1:
Once the communication between the client and server has been established, we can then connect to the server using SSH that will be encapsulated in DNS:
NetWitness Network Analysis
Homing in on DNS traffic is incredibly easy with NetWitness, we merely need to look for DNS under the Service meta key, or execute the query "service = 53". To place a focal point on possibly encoded DNS TXT records, we can pivot on the meta values, "dns base36 txt record", and "dns base64 txt record", located under the "Session Analysis" meta key. These tools will encode the data in the TXT record due to the limitations placed on the record type, such as only allowing printable ASCII symbols and a maximum length of 255 characters.
From the screenshot below, we can see a suspicious sounding SLD with a large number of NetWitness sessions that would be worth investigating.
From here, I like to open the "SLD", "Hostname Alias", and "DNS Response Text" meta keys. What you can see from the screenshot below is a large number of unique "alias.host" or "dns.resptext" values to a single SLD; which is indicative of possible DNS tunnelling. The requests are highly unique, so they are not to be resolved by the local DNS cache, or the cache on the internal DNS servers.
The screenshot below shows the elevated number of different TXT records are related with the single SLD "slbwyfqzxn".
NOTE: Some commercial software packages such as antivirus and antispam tools show a similar behaviour and exchange data over DNS TXT record for their own security checks.
Reconstructing the sessions, we can see the TXT records and use the in-built Base64 decoding capability to see what data was encapsulated. In the screenshot below, we can see the initialisation of an SSH session:
Conclusion
DNS is commonly overlooked and an area that defenders should pay more attention toward, it is a great way to exfiltrate data out of an otherwise “secured” network. DNS2TCP is just one of the tools that allows data to be encapsulated within DNS, there are many others, but they all have similar behaviour and can be identified using similar techniques as shown in this post.
