Live Cyber Attack Lab 🎯 Watch our IR team detect & respond to a rogue insider trying to steal data! Choose a Session

X

DHS Emergency Directive 19-01: How to Detect DNS Attacks

Data Security

On January 22, 2019, the United State Department of Homeland Security (DHS) released a warning for a DNS infrastructure hijacking attack against US government agencies.

Let’s dig into the specifics of the DHS warning and look at how you can better protect and monitor your DNS services.

What is a DNS Infrastructure Hijacking Attack?

The Emergency Directive 19-01 calls this attack a DNS Infrastructure Hijacking attack. DHS says that the attackers stole user credentials powerful enough to alter DNS records, and then used those credentials to manipulate DNS records for key servers.

The result? Once attackers had control of DNS, they redirected user traffic so they could intercept and record some or all of it, acting as a “man in the middle.” By intercepting user traffic, attackers can intercept information, like user name and password pairs.

For example, when victims send an email (to their secure email server for handling), they will connect to the attacker’s server first. From the victim’s perspective, it looks like everything is fine because they send and receive emails as usual. Things are not fine, however, because the attackers can eavesdrop, even when the connection appears encrypted (more on that below).

It’s important to note that manipulating DNS records to hijack connections isn’t new, and it doesn’t even take a compromised admin account to do it. This is because DNS is a very old protocol, with many vulnerabilities (for more on DNS and how it works, check out this primer). Not only can attackers exploit DNS to hijack connections – they can use it for reconnaissance, as a command and control channel, and to covertly exfiltrate data.

This attack is more worrisome than some other DNS hijacking attacks for two reasons:

  1. The attackers appear to have compromised authoritative records (instead of just cached records) on DNS servers “upstream” of the victim’s local DNS servers. This means that even if a victim’s local DNS servers aren’t compromised, they can still be vulnerable. For example, if an attacker changed the authoritative record for www.google.com to route to their own server, we’d all be going for an interesting ride, even though nothing changed on our computers or local DNS servers.
  2. The attackers used their power over authoritative DNS records to set up fake certificates that appear valid to end users. This means that the victim’s computer negotiates an encrypted connection with the attacker’s servers, and the attacker’s servers decrypt and re-encrypt the traffic, relaying, or “proxying” it to the destination server. If the victims are using webmail, this setup can even give victims the comforting lock symbol in their browser:

What Do I Need To Do Right Now?

Per Emergency Directive 19-01, government agencies have to:

  • Audit all public DNS records
  • Change all passwords that can access DNS records
  • Implement multi-factor authentication (MFA) for all accounts that have rights to change DNS records
  • Monitor Certificate Transparency logs for new certificates your agency did not request

The scope of this remediation depends on several factors:

  1. How many public facing DNS records need auditing?
  2. How many accounts can change DNS records?
  3. How many of those accounts have MFA already?

Verifying that every DNS record is correct will be a lot of work for organizations with a lot of records. It’s best to take steps to prevent further breaches and make sure things stay fixed.

How to reduce the risk of DNS tampering on your DNS servers

  • Restrict administrative access to DNS servers (on Windows for example, monitor changes and review members of the dnsadmin group, and other administrative groups)
  • Use static DNS records or DHCP reservations for key records, and monitor changes to those records
  • Monitor DNS servers for signs of cache poisoning, reconnaissance, command and control, or data exfiltration
  • If you’re running a windows environment, identify, remediate and monitor other Active Directory vulnerabilities

How to protect yourself from compromised DNS records on servers that aren’t yours:

  • Enforce multi-factor authentication for external services wherever possible
  • Monitor DNS queries and other perimeter devices (e.g. web proxies) for attempted connections to sites with poor reputation scores

How does Varonis help?

Varonis starts by monitoring the right ingredients: First, data — who can touch it, who does touch it and what’s important – on-premises and in the cloud. Second, Active Directory – who’s using which devices with which accounts and how. Third, DNS and Edge devices like web proxies and VPN concentrators– who is getting in, and who and what is going out, and are any of the destinations untrustworthy.

Next, Varonis combines the ingredients and builds context. What kinds of accounts are there and who do they belong to, who uses which devices and which data, when are they active and from where. Varonis automatically builds a baseline, or “peace-time profiles” over hours, days and weeks for every user and device, so when they behave strangely they get noticed.

Varonis customers quickly identify and analyze things like:

Want to learn more? Get a 1:1 demo to see how Varonis can detect DNS attacks – and prevent data breaches.

David Gibson

David Gibson

David Gibson has more than 20 years of technology and marketing experience. He frequently speaks about cybersecurity and technology best practices at industry conferences, and has been quoted in The New York Times, USA Today, The Washington Post and numerous security news sources.

 

Does your cybersecurity start at the heart?

Get a highly customized data risk assessment run by engineers who are obsessed with data security.