What is typosquatting and how to protect against it

A recent representative sample of seven billion anonymized DNS queries that flowed through BlueCat’s solutions highlighted an interesting phenomenon: typosquatting.

Most of these queries were typos, but they happen more than you might expect. Spammers and malicious actors have seized on the typo opportunity, creating fake or malicious websites that leave enterprises seeking out typosquatting protection.

Among the most frequently queried top-level domains (TLDs), three typos stood out in BlueCat’s sample: .cm, .co, and .om. (A TLD is everything after the dot in a website address.)

Using the .cm, .co, and .om. example, this post will first explore what typosquatting is and how typos result in typosquatting. Then, it will look at how organizations have struggled to protect themselves against the phenomenon. Finally, it will examine how BlueCat’s solution uses DNS data to better protect your network from typosquatting.

How do typos become typosquatting?

It appears that most queries to .cm, .co, and .om are simply typos. Internet users meant to go to .com but missed typing the “c”, “o”, or “m” in their web browser.

Out of seven billion DNS queries, 0.2% of them went to one of those three TLDs. That doesn’t seem like a very high percentage, but it still represents over 7.5 million queries—a pretty significant number.

If you’re a geography geek, you might notice that these typos are the same as the TLDs for the countries of Cameroon (.cm), Colombia (.co), and Oman (.om). (Fun fact sidebar: Colombia is the clear winner in BlueCat’s typo sweepstakes. Over 99% of the typo queries that BlueCat found went to that TLD. Oman came in a distant second with around 0.48% of all typos, and Cameroon with the remainder.)

These misspelled domains would be unremarkable if they simply failed to resolve. People would get an NXDOMAIN response, figure out the error, and move on.

In these three cases, however, there’s a possibility that the .cm, .co, and .om versions of a website actually exist. Spammers and malicious actors are well aware of the opportunity these typos provide for popular domains. Hence the name typosquatting. They bank on the volume associated with that 0.2% of all DNS query traffic that BlueCat found.

As you might expect, a few savvy entrepreneurs purchased the .cm, .co, and .om versions of many top website addresses.

Why bad actors typosquat

Following domain registration, bad actors use these parallel web addresses to spread malware or to drive traffic to fake websites or storefronts different than the user’s intent. Unsuspecting users who use these fake sites can fall victim to credit card theft or worse.

Sometimes typosquatting is primarily a money-making venture. A bad actor might register a typo domain to try to sell it back to the brand owner or trademark holders. Or, they might try to collect ad revenues resulting from mistypes of the intended domain. They can also redirect typo traffic through an affiliate link and earn a commission from the brand owner’s affiliate program.

Why not just block TLDs across the board?

If these typosquatted domains are such a problem, it would seem that blocking the .cm, .co, and .om TLDs across the board would be a prudent action for most corporate networks. Unless you’re doing business in Cameroon, Colombia, or Oman, it’s unlikely that allowing queries to those domains serves any legitimate purpose, right?

Actually, it’s a little more complicated than that.

The struggle for typosquatting protection

Industry is well aware of the typosquatting problem. As a result, many large companies have gone to the trouble of purchasing different typo domain versions of their registered domains to try and keep URL hijacking from impinging on their search volume and the integrity of their brand.

These usually redirect to the correct .com version of the site, with the user none the wiser for their mistake. (If you’re a Yahoo user in Cameroon, you’ll be redirected to the US site. Tant pis.)

Blocking the TLD of these alternative websites would probably point out the user’s error, but it would also prevent the resolution of legitimate traffic.

The problem with URL shorteners

URL shorteners provide another reason not to block .cm, .co, and .om across the board.

Companies like short.cm use domains from Cameroon, Colombia, and Oman for legitimate redirects. Instead of typosquatting on legitimate domains, they use algorithms to develop redirects that happen to be hosted on foreign TLDs.

If end users click on a legitimate social media link handled by short.cm and get an NXDOMAIN or a redirect generated by an internal security policy, the reasoning might appear opaque.

A judgment call for security teams

In the end, how security policies are applied to .cm, .co, and .om is a judgment call for security teams. The specific needs of your business will dictate how you protect your network.

In many cases, threat feed providers will make the choice for you, blocking typosquatted sites that are known to be malicious.

You can also use threat feeds to block these TLDs across the board, assuming that the risk is greater than any collateral damage from legitimate queries that can’t get through. Others have a more refined approach, blocking the parallel versions of major sites only when they can be traced to malicious activity.

BlueCat’s approach to typosquatting protection

BlueCat’s approach to blocking malicious TLDs tends to be more forward-leaning.  The potential impact of malware is so large that it usually makes sense to block an entire TLD.  Yes, there may be a few legitimate sites, but they are few and far between. Better to block first and make exceptions later.

One recommended approach for typosquatting protection is to define TLD blocklists containing riskier TLDs like .top and .tk. Then, you can define an allowlist of known good domains that use the TLDs that your organization actually needs access to.

Regardless of which strategy you end up pursuing, DNS data provides critical context to guide your security team’s decision-making process.

To know the extent of your network’s exposure to malicious TLDs, you have to look at DNS query patterns. To look at DNS query patterns, you have to be collecting DNS data. This can be a lot harder than you might think, particularly in decentralized infrastructures such as Microsoft DNS and BIND.

Insights on user behavior, cybersecurity threats, and network optimization are just sitting there in your DNS logs, waiting to be found.

BlueCat’s DDI management solution brings all your DNS data together, so you can make educated decisions about how to craft security policies. Plus, BlueCat’s DNS security tools make it easy to apply those policies uniformly across the enterprise.