BlueCat recently combed through a representative sample of seven billion anonymized DNS queries that flowed through its solutions and found an interesting phenomenon: typosquatting.
As BlueCat sorted through the most frequently queried top-level domains (TLDs), three of them stood out: .cm, .co, and .om. (A TLD is everything after the dot in a website address.)
Most of these queries were typos, but they happen more than you might expect. Spammers and malicious actors have seized on the typo opportunity, leaving enterprises to seek out typosquatting protection.
This post will look at how the .cm, .co, and .om. TLDs tell part of the typosquatting story. Then, it will explore how typos result in typosquatting and how organizations have struggled to protect themselves. Finally, it will examine how BlueCat’s solution uses DNS data to better protect your network against the phenomenon.
Our typosquatting story begins in Cameroon, Colombia, and Oman
If you’re a geography geek, you’re probably wondering why so many DNS queries were going to the TLDs for Cameroon (.cm), Colombia (.co), and Oman (.om).
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.
These spelling errors happen more than you might expect. 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.
Fun fact: Colombia is the clear winner in the typo sweepstakes. Over 99% of all typo queries went to that TLD. Oman came in a distant second with around 0.48% of all typos, and Cameroon with the remainder.
The difference between Oman and Cameroon is actually counterintuitive when you consider that the three characters in .om are all typed with the right hand on a desktop computer.
How do typos become typosquatting?
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 typos provide for popular domains. They bank on the volume associated with 0.2% of all DNS query traffic.
A few savvy entrepreneurs purchased the .cm, .co, and .om versions of many top website addresses.
They use these parallel web addresses to spread malware or to drive traffic to fake websites or storefronts different than the user’s intent. Hence the name typosquatting. Unsuspecting users who use these fake sites can fall victim to credit card theft or worse.
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
Well aware of the typosquatting problem, some 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.
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.
Five network pros’ manual error horror stories
Members of BlueCat’s Network VIP community detail the errors they committed, the resulting fallout, and what important lessons they learned.
10 best Ansible modules for infrastructure as code
10 (plus a bonus) Ansible automation modules that anyone—from a beginner to a power user—can leverage to transform their network infrastructure to code.
Cloud Webinar Series: Part 3
Manage overlapping cloud networks like a boss.
NSA and CISA: Protective DNS key to network defense
U.S. cyber agencies now point to protective DNS as a defense strategy, confirming what BlueCat already knew: DNS is critical to detecting network threats.