Do you know who your domain name registrar is? If the answer is “no” or “what’s that?”, then despite appearances you may not even be in control of your own website, or for that matter, your company’s emails. Multiple reports indicate that DNS hijacking is on the rise with campaigns like Sea Turtle and DNSpionage, and it can be difficult to know whether you’re a victim of it. In this post, we’ll explain what DNS hijacking is, what steps you can take to protect yourself and how you can ensure you’re really in control.
Refresher: What’s DNS Again?
The world of cybersecurity is complex, so here’s a quick reminder of the terminology we’re dealing with. DNS or Domain Name System is the means by which a human-readable domain name like, say,
www.yourcompany.com gets turned into the numerical IPv4 or IPv6 number system that is actually used by browsers, routers, and servers to serve up web and email content.
The older IPv4 addresses are the familiar 32-bit addresses you have likely seen before, consisting of four segments separated by periods. For example:
The newer IPv6 addresses are 128-bit addresses written in hexadecimal, split into 8 segments and separated by colons, which may look something like this:
But also may not! In IPv6 addresses, a double colon can be used to omit sequential zeroes, and zeroes at the beginning of a segment can also be removed, so you can see IPv6 addresses that have quite variable lengths. The above address would actually be represented like this:
So how does all this magic happen? How do domain names become IPv4 and IPv6 numerical addresses? When your browser or other networking device is given a domain name, a process of DNS lookups occurs, starting with local caches and progressing through a number of lookup servers: recursive resolvers, root nameservers, top-level-domain servers and authoritative nameservers. At the end of this process, an IP address is delivered to the client for the specified domain.
What is DNS Hijacking?
At any one of these points, and indeed at any of the caches along the way, an attacker can hijack the DNS server or poison the cache in a way that is invisible to the client making the request.
If you don’t manage your own DNS, it’s entirely possible that the third-party entity that does manage it for you (and who is that, again?) could have been hacked without your knowledge. When an attacker hijacks your DNS, they are able to intercept your entire web traffic and email communications.
“half of the top 20 banks ranked by total assets don’t manage their own DNS, instead leaving it in the hands of a potentially hackable third party.” (Source)
There’s a few ways that this can happen. Suppose you registered your site with an internet registrar, I’ll use a fictional one, let’s call it
GoMummy.com. The GoMummy registrar sells you a domain name,
yourcompany.com and registers that name against unique IPv4 and IPv6 addresses. Your domain name has the top-level domain (TLD) of
.com, and there’s an authoritative nameserver that holds an A-Record containing your unique IP address.
In this scenario, an attacker might hijack your DNS at several points. If they compromise the authoritative nameserver, they could change your IP address to another address so that the DNS lookup for
yourcompany.com points to their own servers. Then everyone who typed
yourcompany.com into a browser would go to the attacker’s website and not yours. There, your visitors might find a site that is an exact clone of your site, except it’s controlled by the attackers and could be used to steal login credentials, deliver malware or distribute false and damaging information about your company. In such a case, you might have around 4 hours – the time-to-live for a DNS lookup is typically 14400 secs – to spot and correct the hijack before it starts propagating across the internet.
Real-World Cases of DNS Hijacking
Some real-world cases of DNS hijacking include:
- The 2018 SamSam ransomware attack: In this attack, hackers targeted several US healthcare organizations, using DNS hijacking to redirect traffic from legitimate websites to malicious domains that delivered ransomware payloads.
- The 2019 Cloudflare DNS hijacking: In this incident, hackers used a vulnerability in Cloudflare’s DNS infrastructure to redirect traffic from several websites, including coinbase.com, to a malicious domain that delivered a cryptocurrency mining payload.
- The 2017 Exim vulnerability exploit: In this incident, hackers exploited a vulnerability in the Exim mail server software to gain control over the DNS records of several hosting providers, allowing them to redirect traffic from legitimate websites to malicious domains.
Hijacking A-Records appears to be what happened in an attack that affected Twitter, the New York Times, and the Huffington Post. What these sites had in common was the same registrar: Melbourne IT. Hacker collective S.E.A. breached their US-based sales partner through a spear-phishing campaign and gained access to the registrar’s servers. From here, the hackers were able to change the A-Records of several sites.
In that particular case, the damage was little more than vandalism, but an attack on the DNS registration of a Brazilian bank was far more serious. The attackers created malicious clones of the bank’s sites, complete with valid
https certificates, and had control for around five hours. During that time, every visitor to the bank’s URLs was redirected to the spoofed sites, which also served up banking trojan malware.
More recently, the Sea Turtle campaign appears to be a nation-state-backed DNS hijacking campaign that spans 13 countries and has targeted at least 40 public and private entities. The threat actors behind Sea Turtle’s use changed A-Records to reroute victims to spoofed sites where they then steal login credentials.
DNS Cache Poisoning Attacks
In another scenario, an attacker might not be able to compromise your DNS registrar’s A-record but might instead hijack your DNS through a cache poisoning attack. A rogue or compromised DNS server in-between the user’s computer and the site the user intends to visit could serve up an alternative address to the actual address held in the A-Record.
This, in effect, is exactly the same technique that is used by censors such as the “Great Firewall of China” and other government anti-privacy schemes; it is also a ploy regularly employed by some ISPs to impose geographic restrictions, serve ads, collect data or otherwise control user’s internet browsing.
In practice, any DNS caches or lookup servers between the device and the intended site can redirect the user to another address. This can start with the router on the local network – one of the many dangers of using public Wifi services – and reach up to the root name server (aka ‘DNS root server’).
Router & Malware DNS Hijacks
In the above examples, we discussed attacks outside a network you control, but DNS hijacks can also occur inside your network. Malware on a local computer can change the DNS server used by the client, such that a particular machine’s domain names are incorrectly resolved to an attacker’s choice of IP. Similarly, if threat actors can breach the router on your network and change the lookup server addresses there, they can achieve the same effect for every client on that network from a single breach.
One of the easiest ways malware poisons a device’s DNS lookups is to modify the machine’s hosts file. The hosts file has legitimate uses for, among other things, web development, content blocking and VM software, but it also allows attackers to specify custom IP addresses for any domain.
How Can You Tell If Your DNS Is Hijacked?
You can and should view the contents of your hosts file regularly. In Windows, you can examine the hosts file using
notepad and navigating to the file at
For those comfortable with PowerShell, just execute the
cat command on the same filepath:
It should be sufficient on both Linux
The above images are default hosts files with VM software installed. An attacker would modify the hosts files by adding a line such as
<attackers IP address> google.com
Such a line would resolve all requests
google.com on the device immediately to the IP address given, without any further DNS lookups or checks.
Local hacks can also be revealed if you notice slow downs, browser redirects, site unavailabilities, pop-ups or other unusual behaviour when using your browser. Try changing the local DNS settings on your computer to
220.127.116.11 (Google’s Public DNS) or
18.104.22.168 (CloudFare’s Public DNS) to see if that helps. At the same time, be sure to use a good security solution that can detect malware that has DNS changing behaviour.
For checking DNS lookups outside of your local network, there are a few tools end users can use. The whoismydns.com site provides a free service that tries to tell you what server is making DNS requests on your behalf when you connect to the
whoismydns.com site. While this is a nice idea, we have to recommend caution in using it.
For one thing, there doesn’t appear to be an
https version of the site, so there’s no real way you can verify that your connection to the site hasn’t been tampered with enroute. Secondly, if an attacker has control of your DNS traffic, it’s possible that you could be redirected to a fake version of the
whoismydns.com site itself!
Pretty much the same cautions apply to this site, which attempts to tell you if your computer is one of the thousands still out there infected with the DNSChanger malware.
For enterprise and domain name holders, from a known clean device, you can check that your A-Record is what it should be using Google’s DNS lookup service. For example, will the real SentinelOne please stand up:
What Can You Do About DNS Hijacks?
Attackers have noticed that routers are something of a weakpoint in the security chain, not least because they have relatively poor internal protections, are generally shipped with default admin passwords that an unfortunately large number of users never change, and have infrequent (if ever) firmware upgrades. A great checklist of router security tips can be found here, but the essentials boil down to verifying and checking your router’s DNS settings and regularly updating the router password.
In managing your organization’s domain names, the most important step for enterprises to prevent DNS hijacks is to use a registry lock to prevent unauthorized changes. Further, be sure to enable two-factor authorization on your account access.
If your host service does not offer registry locks or 2FA, you should seriously consider changing to one that does as soon as practically possible. Beyond that, enable DNSSEC (Domain Name System Security Extensions) in your site’s control panel. This helps to prevent DNS redirections, cache poisoning, pharming and man-in-the-middle-attacks by authenticating the resolution of IP addresses with a cryptographic signature.
To eradicate the problem of DNS lookups between your distributed endpoints and your organization’s network, enterprises should use a reputable VPN service. Also, be sure to protect your endpoints and network with an autonomous, next-gen security solution.
Resolving domain names into numerical IP addresses, from the endpoint to the DNS root server, is fraught with vulnerabilities for ordinary users and enterprise while offering great opportunities for attackers. The US Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) recently warned that a global DNS hijacking campaign is currently active. With a successful hijack, an attacker can redirect your organization’s web traffic to attacker-controlled infrastructure, complete with valid encryption certificates, and conduct man-in-the-middle attacks. DNS attacks on the device are easily accomplished by changing local DNS settings or poisoning the local hosts file.
To stay protected, follow the advice we outlined in the previous section. If your endpoints are not already protected by a robust security solution like SentinelOne, this free demo will show you how our autonomous endpoint solution can keep your devices and network safe.
Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.