Akamai Diversity

The Akamai Blog

Akamai CSIRT Warns of DNS Record Hijacking

In recent weeks, Akamai's CSIRT team has seen the Web sites of multiple businesses redirected after being hijacked by a malicious user.

CSIRT's Patrick Laverty, who authored the advisory, said the intent of these hacks can include the redirection and capture of all company email to a rogue server, or to simply cause embarrassment to the company being affected.

The problem is that the malicious user is able to get administrative control of the account that allowed changes to be made to the DNS records for the company involved. Some of these companies believe the account access was obtained through a phishing attack against a person in the company who had the account credentials to make changes. In other situations, the attack was against the domain registrars themselves.

"Companies can protect themselves from this type of attack by locking their domain with the registrar," Laverty wrote. "There are two levels of locks that can and should be enabled. There is a lock between the owner of the site and the domain registrar and there is a lock between the registrar and ICANN. To be truly safe, both levels of locks should be put in place."

Are you affected? 

You know you are affected if your domain no longer shows the Web site you expect. If all pages under a domain either return the attacker's pages or 404 messages, you may be affected by this type of attack. 

The most certain way to determine if you're affected is to check your domain's DNS records. This can be done with a simple "whois" lookup or by logging in to the site's DNS registry and check the values. Be aware, it is also possible the attacker will have changed the password into the registrar's account.

Suggested fixes

Laverty outlined a two-part solution.

First is to properly educate the people possessing the password that can update DNS records with the registrar. Many times in these attacks, the username and password were successfully phished away from someone with that level of credentials. If the credentials can be phished away, the second part of the protection won't help.

The second part is to have domain locks in place. Domains can have locks at both the registry and registrar levels. The site owner can set and control registrar locks. These will prevent any other registrar from being able to successfully request a change to DNS for a domain. The locks that can be set at the registrar level by the site owner are:

• clientDeleteProhibited
• clientUpdateProhibited
• clientTransferProhibited

The clientDeleteProhibited will prevent a registrar from deleting the domain records without the owner first unlocking the site. With the clientUpdateProhibited lock set, the registrar may not make updates to the domain and with the clientTransferProhibited set, the registrar may not allow the domain to be transferred to another registrar. The only exception to these is when the domain registration period has expired. These locks can be set and unset by the site owner and many registrars will allow these locks at no cost.

A second level of locks can also be put in place and these are set at the registry level. These are controlled by the registry and setting these can incur a cost to the domain owner. These locks are:

• serverDeleteProhibited
• serverUpdateProhibited
• serverTransferProhibited