In part one of this blog series, we provided background on DNS Tunneling and provided an explanation on how tunneling can be used to infiltrate your internal infrastructure.  In this post, we will discuss methods for detecting whether if your organization has been infiltrated and some proactive steps you can take to prevent a breach.

How do I determine whether my network has been breached via DNS tunneling?

Detection of DNS tunneling breaks down into two basic categories:

Payload Analysis

To perform a payload analysis to determine whether your network has been breached via DNS tunneling, you must be able to capture and store network traffic and have the ability to parse and query the data —  although some analysis can be performed from the basic log files within your recursive servers.

Once you have the data, you can begin to look for the following identifiers:

  • Ratio of the source to destination bytes
  • Hostnames
    • Labels using over 63 characters
    • Hostnames using 255 characters
    • Generally all hostnames over 52 characters
    • Lack of patterns (majority of valid hostnames use dictionary words or something that appears to intelligible)
    • Character makeup
      • number of unique characters in a string
      • repeated consonants or numbers
  • Uncommon record types
  • Internal DNS policy violations (i.e., all DNS requests go through an internal server)
  • Specific Signatures (i.e., specific text string within the payload)

Traffic Analysis

To perform traffic analysis to determine whether DNS tunneling is taking place, you must have access to historical data, including volume/counts of DNS traffic, the numbers of hostnames per domain, locations of requests and historical attributes.

Once you have the data, you can then start to look for the following identifiers:

  • Volume of traffic per IP address
    • Large number of queries required
    • Can still be hidden by programs spoofing the source IP
  • Volume of traffic per domain
    • Typically one domain is used
    • Large number of unique sub-domains
  • Volume of uncommon record types
    • TXT records are most commonly used in tunneling, but uncommon for external queries unless the system is a mail server
  • Missing partner protocol requests
    • MX queries not accompanied by an SMTP connection
  • Whitelist known good domains

While there are other methods of detection, payload and traffic analysis typically have the highest success rates.  The single best generic option for detection is tracking the count of fully qualified domain names (FQDN’s) per domain.  Because each hostname is encoding different data, the unique count will be extremely high compared to valid domains when DNS tunneling is taking place.

What can you do to proactively mitigate DNS tunneling?

Most of your options for mitigating DNS tunneling involves being reactive, involving either real-time detection/alerting or manual inspection.  However, there are a few things you can do proactively:

  1. Section off your DNS. By default, don’t allow your internal hosts to resolve external domains.
  2. Have your internal hosts use a Web proxy that handles resolution of all external domains.
  3. Have a separate set of recursive servers that your mail servers are configured to use to resolve those external MX, TXT, and SPF records.

As we all know, nothing is 100 percent secure.  This means it is critical that you be vigilant and have multiple systems in place performing both payload and traffic analysis.  If you don’t have mechanisms to capture and analyze traffic, get them. If you haven’t had security assessments done lately, get them done as soon as possible.