In this blog, we explore the reason behind Google's release of the new Top Level Domains (TLDs). We assess the potential risk level associated with these TLDs and examine the trends observed in the registered .zip domains since their introduction. We will also provide recommendations to protect your organization and yourself.

In early May, Google released several new TLDs for public registration including .zip and .mov.[1] This information is crucial for technical professionals because it highlights concerns arising from the fact these .zip and .mov domains are well established file extensions and so URLs that look like filenames may now end up being domains. This creates an opportunity for threat actors to exploit this confusion, such as more efficient phishing attacks to direct victims onto websites controlled by threat actors as part of a multi-stage attack. Therefore, technical teams need to be aware of this development to understand the potential risks and take appropriate security measures to protect themselves and their organizations.

The domain name industry and (generic) TLDs

Before we describe the attack, we will first take a step back to understand why Google has made these new TLDs available for public registration.

The creation and administration of TLDs is facilitated by the Internet Corporation for Assigned Names and Numbers (ICANN). .zip and .mov are generic TLDs (gTLDs) comparable to .com and .net. ICANN issues new gTLDs to promote competition in the domain name market by increasing consumer choice.[2]

So why did Google release the .zip and .mov TLDs instead of ICANN? Let’s have a look first on how the domain industry operates.

An overview of the domain name industry

Figure 1: An overview of the domain name industry[3].

Registry operators make an application for new gTLDs to ICANN. Once an application is approved, the registry operators can liaise with domain registrars (for example, GoDaddy and Namecheap) who rent out the domains publicly. Google is a domain registrar but one of their subsidiaries, Charleston Road Registry (CRR), is the registry operator that made a successful application for the .zip and .mov TLDs to be created. In fact, ICANN approved this application for the new TLDs in 2013[4]. Google’s delay in making the .zip and .mov TLDs available was likely a strategic decision related to demand in the market for new gTLDs and also the time taken to establish resources for launching and maintaining the gTLDs.

Previous collision between filenames and domain names

This is not the first time that there has been confusion between filenames and domain names: the Polish TLD is ‘.pl’ which is also the file extension of Perl scripts. Similarly, 3M’s Command products use the domain name which is also a program on MS DOS and early Windows versions[5]. So yes, this has happened before, but we would argue that the new gTLDs, particularly .zip, are so commonly recognized as filenames that confusion will be notably more widespread than with previous collisions between filenames and domain names. 

Types of attacks

Concerns about the new gTLDs can be split into two main attack vectors:

  1. An untargeted attack by registering domains to match commonly used filenames and wait until a victim makes a typo
  2. A targeted attack by disguising a malicious URL as a legitimate URL with a legitimate domain

1. An untargeted attack by registering domains to match commonly used filenames and wait until a victim makes a typo

In this attack vector, the attacker registers a domain that is the same string as a filename that is likely to be used on applications that generate automatic hyperlinks such as Twitter, Youtube and Windows File Explorer.

As an example, the below images show that the result of typing ‘’ into Windows File Explorer is that ‘’ is opened in the default web browser.

Windows File Explorer

Figure 2: Windows File Explorer.

The ''

Figure 3: The '' search on Windows File Explorer triggers a redirect to on the default web browser.

‘’ has been registered by a safe user, but an attacker could attempt to register similar domains that are likely to be frequently used within applications or online forums.

A similar method would be for an attacker to identify a specific filename that is referenced on a trusted website and register the matching domain. For instance, .zip files are frequently posted on Stack Overflow to help debug problems and an attacker could register domains that match .zip references in popular comments. After a victim clicks on the threat actor’s link, the attack would likely follow a conventional phishing path, automatically downloading malware to the victim’s device or directing the victim to a disguised login page in an attempt to capture credentials to a common application.

Is a threat actor likely to have a high success rate for each .zip or .mov domain that they register? No - but if a threat actor registers a large number of cleverly chosen domains, it is likely that some users will be caught out. 

2. A targeted attack by disguising a malicious URL as a legitimate URL with a legitimate domain

The second attack vector uses the new .zip and .mov domains to make phishing URLs that are disguised as legitimate ones more convincing.

Bobby Rauch published research detailing how to spot which of the two following URLs is a .zip file from the legitimate MySQL Github repo and which directs the user to a malicious domain[6].


We will forgive you if you aren’t sure! Notice how in the first URL, the forward slashes are the unicode character U+2215 (∕) rather than the legitimate forward slash U+002F (/). The U+2215 characters do not get treated as forward slashes by the browser and so for the first URL, the browser interprets the domain as the string that comes after the ‘@’ character – ‘’.

To make the above example even more convincing, we can conceal the ‘@’ character in some circumstances. For instance, if an attacker is sending this link as part of a phishing email, you can conceal the ‘@’ character to have a font size of 1 and a white font colour so that it isn’t visible to the user.

The result is that by using the .zip extension along with the above domain disguise techniques, a threat actor may be able to convince an otherwise cautious user to click on the link. On the other hand, we know that users click on all kinds of malicious links without checking the file extension and so it is difficult to determine whether the additional risk from the .zip and .mov gTLDs is significant.

Evidence of real malicious activity

An open-source tool created by Trickest reports that there have been 7594 .zip domains registered at the time of writing[7].

Most of these domains are common filenames and display information about the risks of .zip domains or other harmless information:

  • Scan[.]zip
  • Script[.]zip
  • Tar[.]zip
  • Pictures[.]zip
  • Handout[.]zip

However, some of the new .zip domains have been confirmed to direct the victim to a malicious site. Silent Push Labs reported the first malicious .zip domain as microsoft-office[.]zip which directs the victim to a fake Office365 login page[8]

A fake O365 login page

Figure 4: A fake O365 login page[9].

Since the Silent Push Labs report, other malicious domains have been identified and are listed below[10]:

Please do not navigate to the below URLs!

  • microsoft-office[.]zip 
  • gmailbackup[.]zip      
  • paypal[.]zip           
  • payslip-statement[.]zip
  • eicar-test-file[.]zip  
  • google-drive[.]zip     
  • e-mails[.]zip          
  • paymentinfo[.]zip 
  • benign[.]zip           

We can see here that the domains are either attempts to impersonate established brands or are matching commonly used filenames. It will be interesting to see how this list develops in the coming weeks. 

So, what is the risk?

There has been dispute in the InfoSec community surrounding whether the additional risk caused by releasing the .zip and .mov gTLDs is worth the hype. As already outlined, both attack vectors rely on chance and user interaction to succeed, and an attacker would need to register many domains to have a reasonable chance of success. Additionally, we know that users already click on all kinds of links without checking the file extension and so it is arguable whether having .zip at the end of a link will cause that many more people to click on it.

So no, we are unlikely to see a vast wave of successful phishing attacks because of the new gTLDs, but there are likely to be some victims who do get caught out. It only takes one user being phished to compromise an entire network which can be enormously impactful and so it lays into question why the .zip and .mov TLDs were released by Google (and previously by ICANN) despite the obvious issues that would follow. Yes, we need new TLDs to maintain supply and competition between domain registrars, but there are countless other strings that could be used that do not cause needless confusion between domains and filenames. Should .exe or .xlsx be released as new gTLDs? Probably not! We hope that the push back from the InfoSec community will avoid such gTLDs being released in future.


To protect yourself and your organization from the risks outlined in this blog, you can do the following:

  • As an enterprise, consider blocking the entire .zip and .mov domain spaces in your firewalls.
  • As an enterprise, consider blocking potentially malicious unicode characters, such as U+2215 (∕) and U+2044 (⁄) in your firewalls.
  • As an enterprise, add .zip and .mov domains to your identification process for impersonations of your brand. As an enterprise, configure your email spam filter in such a way that emails containing .zip and .mov links will be quarantined.

In addition, we also recommend the following general good security practice measures:

  • Avoid clicking on links in emails, especially from unknown senders or suspicious sources. Instead, manually type the URL into the browser or use bookmarks to access trusted websites.
  • Hover over links: Before clicking on a link, hover your mouse pointer over it to preview the actual URL. Phishing emails often disguise links, so this can help you identify suspicious or misleading URLs.



Important notice: this blog is for educational purposes only. Do not use these techniques against targets without explicit permission of the system owner. This blog is part of the Blue Hat Hackers group insights

Engage with us