Digital Shadows (now ReliaQuest) was recently the victim of a domain squat attempt. As we eat our own dog food, we thankfully caught and remediated it quickly. What does it mean and how did we do it?  Read on, dear reader!

What is Domain Squatting?

Domain Squatting, also known as cybersquatting, is the practice of actors registering and using domains which impersonate companies, organizations, brands or even people without having the right to do so. Similarly, typosquatting is registering a misspelled variant of the domain.

These types of squats can have many purposes, such as web traffic diversion for advertising revenue or defamation, re-selling the domain to the rightful owner at an inflated price, phishing visitors’ details, attacking visitors using exploit kits, or sending nefarious emails to company clients or employees.

With over 1,500 registered top-level domains (TLD), and an even larger amount of possible misspellings, it is no longer feasible to protect yourself by buying up digital real estate. Trying to do so for even one brand name would be extremely expensive, process intensive and would likely still not fully protect an organization from this threat. As an alternative, organizations should proactively monitor for such domains being registered and have a defined process of dealing with infringements when they occur.

What happened?

Digital Shadows (now ReliaQuest) alert typosquat

Figure 1: Internal alert sent by our analyst team

As well as offering our domain squat monitoring capability to our clients, we use the same coverage for our own assets. On October 6, as part of the regular service, one of our analysts spotted a domain called digitalshadows.tech. The site included an html frame containing the digitalshadows.com domain, which in turn filled the entirety of the digitalshadows.tech page, so the site exactly replicated the legitimate Digital Shadows (now ReliaQuest) site. Upon further research, we discovered that the site had been registered a day earlier via a privacy-preserving WHOIS registration and also had an MX (mail exchange) record, which meant it could have been used to send email. There were some issues with the site as well, such as incorrect content rendering and SSL certificate failures.

What did we do?

After the alert was sent to our internal security team (figure 1), further investigation was conducted regarding the threat emanating from the domain. The team was looking to answer the following questions:

  • Does the site host malicious content?
  • Could it have already been used to defraud our customers or staff?
  • What is the site doing/what is its purpose?
  • How do we remediate the problem?

As a result of the research, it appeared that the site was not hosting malicious content at the time and likely had no means of obtaining any information that may have been input by visitors. The html code was mostly made up of the frame to our legitimate site. It is also possible the site served malicious content selectively, e.g. only target visitors from certain IP addresses.

Since the domain didn’t appear to create advertisement revenue or steal credentials, one of the other possible malicious uses of the site could have been sending phishing emails to our clients or staff. Since this site had a registered MX record, this was indeed possible. The domain was checked against various phishing and spam databases; however, we were unable to identify why the site was created.

Within two working days, three mitigating actions were taken:

1. To limit risk, we notified our clients with a reminder of the only registered domains that Digital Shadows (now ReliaQuest) conducts operations on;

a. We submitted a takedown request to the domain registrar and hosting provider based on a trademark infringement.

2. A complaint to the domain registrar should be the first form of content takedown attempted. For other options, see the Uniform Domain-Name Dispute-Resolution Policy (UDRP) operated by ICANN; abuse complaints may be registered at a number of levels including WebHost, ISP and domain registrar.

3. We submitted a web app firewall request to block referrers from the digitalshadows.tech domain. This prevented the site from abstracting the iframe content from our legitimate site at digitalshadows.com and therefore rendered the framed site inoperable.

Outcome

Following the abuse notice, the initial registrant of the cyber squatted domain appears to have returned the domain to the registrar. No phishing emails were reported and we could consider this particular incident closed.

However, it was not completely straightforward. A response from the registrar revealed that the domain had been registered using a URL forwarding service. This meant that while one endpoint address was specified in the registrar record, the actual hosting server was elsewhere and the details of it could only be obtained via a court order, which would require significant time and financial investment. This added complication is commonly used as an additional layer of protection, separating the attacker from the site.

A motivated attacker could cause serious damage, which illustrates the fragility of all organizations to this type of attack. It is, therefore, very important to be prepared.

Conclusions

In order to defend against domain squatting threats, every organization should:

1. Monitor for domain registrations

We found out about this domain’s existence very soon after its registration, which allowed us to act promptly before serious damage could be inflicted. If you don’t monitor for registrations of this kind, they will catch you off guard.

2. Have a clearly defined incident escalation process

Your teams need to know the correct path of escalation as well as people in change of the response. Furthermore, have a single point of reference for coordinating actions taken on these incidents.

3. Have a clearly defined incident response policy

Responsible parties should be aware of the actions that need to be carried out to investigate and remediate the problem.

4. Trademark your assets

There are a number of legal issues surrounding takedown requests. For example, DMCA requests can’t always be issued as they relate to copyright issues instead of trademark issues. You need to have a registered trademark of your brand name (or other assets) to be able to request a trademark infringement takedown.

5. Inform appropriate staff, clients and suppliers

Share the intelligence with those who need to know. By informing your employees, client base and relevant third party suppliers and peers, you can further mitigate possible phishing attempts and also help to increase their awareness of these attack types.