Blog Post

Spotting (and Stopping) Typosquatting Attacks

While doing some analysis recently on a customer environment, I came across some of my favorite domains! You know, the kind that jump out at you and say, “Shhh! Nothing to see here! I’m trying to blend in!

All jokes aside, the real domains were just as sneaky:

Figure 1: Domains leveraging common user misconceptions

The second example in this screenshot is a classic example of typosquatting, because it takes advantage of a simple letter flip (in this case, the t and y) to do one of two things:

  1. Cause people to mistype a legitimate domain, thereby visiting an illegitimate domain
  2. Cause people to misread an illegitimate domain as if it were a legitimate domain

We’ve found a number of these domains at Awake, including yet another typosquat on Google Analytics this past summer that was stealing credit card information from unsuspecting clients on dozens of websites. In fact, this type of detection is built into our product from the very start!

However, the first example in the screenshot above—which I’m going to call domain camouflaging—is actually more interesting to me for a couple of reasons. First, it uses the familiarity of a major vendor to trick people into believing that it, too, is a legitimate site. This time there are no spelling errors, which makes it even harder to spot.

What I found even more interesting was the camouflage didn’t end there. Specifically, the sub-domain in use was as follows:

Figure 2: The full subdomain list for our suspect domain

In this case, the “subdomains” are “security”, “google”, and “com-viruses-from-dangerous-sites”, followed by a domain “google-rewards[.]com”. At first glance it seems as though this would be obvious to spot as a fake in a browser. However, what if I told you that the devices targeted (which, by the way, we automatically learn about from Awake’s device identification) are mobile phones? For a representative visual, most phones have about this much real estate:

Figure 3: Representation of TLD Anchoring on mobile Chrome browser

Depending on your browser, URLs are displayed either:

  • From left to right
    In this case, all of the cruft gets shoved off-screen, leaving the resulting URL to look something like “[.]com” (which would be a legitimate and trustworthy website if it were the true TLD!). For reference, here’s an example of what the behavior would look like on a seriously-minimized version of the desktop browser for Chrome today:

Figure 4: The non TLD-anchored behavior of Chrome for the desktop

  • or have the right side anchored to the real TLD
    In this case (which is true in a mobile Chrome browser, pictured in Figure 3), the attacker adds “google-rewards[.]com” at the end of their URL…to be as cross-browser compatible (and credible) as possible. Also, it wouldn’t be hard to get the little lock to show up with a SSL certificate for even more “authenticity.”

Hopefully, at this point you’re not asking, “Why does this matter?”, but if you are, just remember:

  • Users are one of the most critical pieces of your enterprise
  • Typosquatting and domain camouflaging attacks are often-used examples of phishing attacks or for Magecart-like card-skimming attacks
  • Phishing is overwhelmingly the source of initial attacker access to your enterprise
  • Analysts “eyeballing” the domains above are highly likely to miss these behaviors and these domains aren’t likely to be on any blacklists or intel feeds until after you are breached.

It’s far too easy to miss these types of attacks. Take the guesswork out of security with Awake.


If you liked what you just read, subscribe to hear about our threat research and security analysis.

David Pearson
David Pearson

Principal Threat Researcher