Imagine getting a panicked call from one of your system administrators, telling you that suddenly your site has no traffic. You investigate your servers directly – everything is fine. You look at the network – looks good. You log in as if you were a customer, and the site looks perfectly legit. Then you notice that the IP address that your URLs are pointing to don’t correspond to where you are hosting your infrastructure. You dig deeper and discover that the nameserver information for your domain name has changed.
Your domain has been hijacked.
DNS or domain hijacking is one of the most profound and damaging attacks around, because it is possible that by the time it is discovered your customers would have already interacted with a bogus site. The time between attack initiation and remediation can allow attackers to siphon off login credentials, site data, resources and more. The methodology typically comprises a mixture of technology and social engineering for devastating results. To get a sense of the scope of such an attack can have, we will first examine the players in the exploit, then we’ll look at a recent example.
To understand DNS/domain hijacking, it is helpful to first look at the DNS infrastructure itself, staring with registries and registrars. Even though the names of these two organizations sound similar, they have very different functions. Top-level domains, or TLDs, such as .com, .org, and .biz are handled by registries. Registries function like a wholesaler – they are not open to the “consumer,” but rather work with registrars, such as GoDaddy, SquareSpace, BlueHost, and others that sell domain names to the general public. Registrars can sell Second-Level Domain (SLD) names of the various TLDs such as example.com, as well as SLDs for country-code TLDs (ccTLDs) like .us, .ca and .eu via an agreement with the appropriate registry. Registrars have their own set of logins/credentials to their affiliated registries allowing them to update TLD and ccTLD zone information.
When a DNS zone owner wants to make a change, they log into their account with their registrar. The registrar then logs into the registry and publishes the changes. The registry then publishes the updated information to all of their nameservers. Updated information is then available for resolution and is pulled by recursive servers when an end-user query is made.
DNS hijacking exploits occur within this chain of communications and can occur with either the compromise of an end-user login credential to the registrar or the compromise of a registrar login credential to the registry.
To get an idea of how damaging these attacks are, we will take a look at a hijacking exploit written up in 2018 by Cisco’s Talos research division, dubbed DNSpionage. While this was a nation-state level attack, an overview of the exploit serves to illustrate just how dire the consequences can be.
The story begins with an intelligence organization that had somehow come into possession of a registrar’s login credentials. Those credentials allowed the attackers to gain access into several registries. Given what we have described about DNS hijacking, the damage that could be done with this information includes the ability to take organizations offline completely. But the attacker didn’t want to actually take down any websites, nor did they want their exploit to be quickly caught. Instead, their goal was to stay undetected for as long as possible, all the while gathering more credentials and information from fake websites which could be used later.
The hackers chose to launch their attack during the time between December and January, which represented a relatively light work period. Once the targets were chosen, the attackers logged into the registrar and changed the DNS routing to point to their fake servers, complete with websites and email. After harvesting what they could for an hour or so, the attackers would change the DNS routing back to the original entries in order evade detection. They repeated this cycle 4 times over a period of a couple of weeks.
The attacker saw that during this period one of the email servers was set to send a “no new mail” message, rather than indicate an error. Unfortunately for the target however, several employees happened to be staying at a hotel that featured a captive portal that used its own recursive resolver during the time of the attacks. The unwitting employee’s mobile devices, in an attempt to speed connection for presumably remote users, were configured to connect directly to the email server. Even more unfortunately, these employees tried to log into the email servers during a period in which the attackers were redirecting traffic to their fake sites. The hackers were able to get log in credentials, and from there they were able to troll the target’s networks. The complete extent of the exploit which began with intelligence gathered from the hijack, is still unknown as related malware continues to be released.
This well- published example is only one of the many DNS hijacking exploits that have taken place, most of which do not make the news. Because DNS hijacking can be so disruptive and damaging, it is essential that organizations put the proper protections and controls in place to prevent it at all costs.
Protection from domain hijacking can be had by instituting robust security best practices throughout the DNS process, starting with stringent access controls and the implementation of registrar and registry locks.
- Registrar locks – This service requires the registrar to confirm any requested changes with the domain owner. In the case of urgent cries for help (which may come from the attacker, trying to scam the registrar) the lock demands that the domain owner validate the transaction in one of a number of ways to include two-factor authentication and requiring the owner to provide a passphrase.
- Registry locks – Registry locks are a more stringent, manual (and sometimes offline) process that effectively neutralizes any attempts by fraudsters to social engineer your domain registrar. With a registry lock in place, modifications of any kind are prohibited without the domain owner’s validation of the change. Among other things your registrar cannot move your domain to another registrar on its own – a manual contact verification by the corresponding registry is required.
Both require (or should require) a concrete form of validation before any DNS changes are made. It is important to institute locks on both accounts for insurance. It can make changes time consuming, but it is vastly less expensive than the alternative.
Other actions that you can and should take are to follow general security best practices including:
- Protect your account credentials!
- Use multi-factor authentication and require its use by all users and subcontractors.
- Keep track of all contact and recovery emails to make sure they are company controlled, not personal emails
- Review existing accounts with registrars and others.
- Ensure that you have notifications in place about expiry dates.
- Monitor the issuance of any new SSL Certificates for your domains.
Don’t let your organization’s DNS be taken over. Learn more about DNS attacks and how to prevent them.
