What should I do if the domain name is hijacked?The best way to deal with domain names being hijacked

Morphus Lab recounts a story where, on a Saturday morning, you, as the CSO (Chief Security Officer) of a large company, suddenly start receiving a flurry of messages. They inform you that after visitors accessed your company's website, they were exposed to various malicious contents.

This may sound like a case of chaos on the company's website, but it could actually be something more serious. Upon further investigation, you discover that the entire domain of the company has been hijacked by hackers. They are attempting to steal data from your customers and distribute malicious code. In this article, we will provide a detailed emergency response plan for scenarios like the one described above. Additionally, we will discuss how to mitigate this threat's disruption to information security policies and security infrastructure using simple methods.

I. DNS Basics

To better understand what has happened, we need to grasp some fundamental concepts of DNS.

DNS, Domain Name System, is the foundation that enables the internet to function. The names of websites and other network services we use daily require translation into IP addresses through internet protocols, and DNS servers play a role in this translation.

DNS servers work in a hierarchical manner. When a resolution request is passed to the appropriate DNS server, it is responsible for resolving the issue. Root DNS servers, akin to the last unseen point in any website domain name, are distributed in various locations around the world. These root DNS servers must know the IP addresses of top-level domain (TLD) DNS servers (e.g., ".com"). Similarly, the ".com" DNS servers need to know the IP address of your company's domain's DNS server (e.g., "yourdomain.com").

For instance, when there is a DNS request to resolve "www.yourdomain.com," after reaching the root DNS server ".", it is then forwarded to the ".com" server, followed by your company's DNS server. Finally, it resolves the "www" domain name and returns the correct address.

These top-level domains (e.g., ".com") are controlled by domain registrars, also known as Network Information Centers (NICs). They manage registered domains and specifically configure the IP addresses of DNS servers to handle the resolution of domains like "yourdomain.com."

II. Domain Hijacking

Regardless of where you register or manage a domain with a domain registrar, you must create an account with them. This account can point the IP address of the domain registrar's DNS servers to your website or email servers.

Thus, the account information on the domain registrar's website becomes crucial. Once ill-intentioned individuals gain access to this information, they can manipulate your domain configuration and your DNS server's IP addresses at will. In short, they can hijack your company's domain and email.

Now, let's take a closer look at what happened in the story:

Hackers stole the company's credentials on the domain registrar's website, logged in, and altered the primary/secondary DNS server configurations, pointing them to the hacker's own address. Subsequently, customers visiting the company's website were redirected to a fraudulent site created by the hackers, where they unknowingly downloaded malicious content. It is reasonable to assume that the culprits' intent was likely to distribute malicious software.

III. Incident Response

As with most network events, all you need to recover your infrastructure is to load backups and configurations. In this case, none of the servers were actually damaged.

In such situations, you have two things to do:

First, recover the login credentials on the domain registrar's website.

Second, alert your customers that the website has been compromised and strongly advise against downloading any content from it.

Note that you should not use your company's email at this point, as hackers may have already gained control of your email service and potentially eavesdropped on all your company's communications. Instead, it's recommended to use your company's social media accounts or other channels for notifications.

We suspect that the reason the hackers chose to attack on a weekend is because it is more challenging to restore network environments during that time. The incident occurred on a Saturday morning at 11 am and lasted until around 5 pm when the company finally corrected the DNS configuration. However, the situation didn't end there. Due to the malicious changes made by the hackers, customers continued to access the fraudulent website for several more hours until DNS caches on the internet were updated. Initially, the hackers set a TTL (Time To Live) value of 24 hours for the company's domain, meaning DNS servers would continue to resolve the company's domain with the hacker's IP address for the next 24 hours.

The only way to expedite recovery was to contact the domestic network operator responsible for the primary DNS server and request a DNS configuration refresh.

With these actions taken, the situation finally started to improve.

IV. How Website Credentials Were Stolen

During this time, part of the company's incident response team focused on restoring the network environment, while another part began analyzing the theft of credentials.

After inquiring with the DNS administrator responsible for this matter, we collected some noteworthy information:

He had bound a Gmail account to the domain registrar, which could be used for password recovery. Before the incident occurred, his phone experienced a loss of service for at least four hours, precisely the

period needed for resetting the Gmail password. After diligent investigation by the company's investigators, it was confirmed that the Gmail password was indeed changed during that time. Additionally, based on the evidence received, it was clear that this could only have happened if the phone was cloned.

At present, this hypothesis is highly plausible. We know that hackers can launch attacks on GSM infrastructure using Software Defined Radio (SDR) to intercept network messages and SMS messages for specific numbers.

V. The Attacker's Objective

This incident had many victims, starting with the company whose domain was hijacked and followed by users who visited the hacker's fraudulent website and unknowingly downloaded malicious software. It is evident that this domain hijacking was targeted at individuals who weren't particularly vigilant. Hackers leveraged the trust people had in the company to propagate malicious software, ultimately infecting them.

Based on preliminary analysis, the malware sample in this incident is a banking trojan called Banload, specifically designed to steal credentials from Brazilian bank users.

VI. Vulnerabilities and Recommendations

Hackers will exploit various vulnerabilities and attack strategies to achieve their goals. Below, we will discuss some preventive and countermeasures to mitigate risks posed by such attacks.

VII. Two-Factor Authentication (2FA)

Enabling two-factor authentication on your domain registrar's website is crucial. This means you must provide at least two methods to verify your identity, such as a password, hardware/software tokens, or even your fingerprint.

In the analysis of this incident, even if hackers could reset the Gmail account linked to the domain registrar, they could not access the software token. This incident teaches us that we should not rely on SMS as a second factor of authentication, as once a phone is stolen or cloned, hackers can use SMS services to gain access to your credentials.

VIII. Analyzing Email Accounts Linked to Domain Registrars

Analyzing these email accounts is crucial because they are often used for resetting website passwords and, therefore, a prime target for many phishers. If you prefer using email accounts for authentication, it is advisable to enable two-factor authentication, making it more difficult for hackers.

IX. Establish an Incident Response Plan

You need a comprehensive response plan for events like these, which you will inevitably encounter.

Additionally, it is important to note that your plan should include:

Emergency contact information for your domain registrar (contacts and phone numbers).

Alternative secure means of notifying customers (besides email).

Establishing routine emergency communication procedures with your domain registrar (e.g., simulated exercises).