This article covers alarming recent examples of the new .zip TLD’s malicious use as well as various methods through which individuals and organizations can shore up defenses and avoid exploitation. In order to understand the specifics of the threat at hand, we begin with a deep dive into the technical vulnerabilities presented by ‘.zip’.
To skip the technical details, head to section 3 - "Google’s .zip is Phishing Gold".
Recently, Google began offering a new Top-Level Domain: '.zip'. Now, users can buy domains with a .zip TLD, such as 'google.zip'. While this is sure to be useful, it has also introduced new opportunities for phishing attacks, which take advantage of an oversight regarding URL structure to create a .zip URL request that looks like it points to a regular file on a trusted domain.
To begin, let’s take a look at a standard URL structure:
There are a few things that are important to note when considering URLs. The following points are pivotal to understanding how a malicious actor can use .zip URL structures to their advantage when conducting phishing scams.
Not all segments must be included in each URL, but if they are included, they must appear in the order presented in the image above. For example, if there is no UserInfo, Port, or Query, the Hostname must still appear before the Path, and Path must appear before Fragment. The URL would look like this: https://example.com/path/to.file#fragment. A forward-slash cannot come before an '@' symbol because these characters indicate the beginning of the Path and UserInfo sections respectively, and Path cannot go before UserInfo (unless the ‘%2f’ escape key is used before the indicating character).
Most modern browsers will ignore the UserInfo segment completely so as to avoid accidental authentication. If it is passed along to the requested website, the website itself decides whether or not to use it. Therefore, anything can be placed in UserInfo if a website does not use this section, as long as it does not indicate the beginning of another segment (such as a hash sign for Fragment).
Similarly, if a domain like 'google.com' appears before the symbol '@' (which indicates that it is part of the UserInfo section), the url will not resolve to google.com. Instead, it will resolve to the domain which appears after the '@' symbol (in the Hostname section).
After the first instance of a forward slash symbol and before the '?' symbol, the url will be read as a Path to a specific file. If this forward slash does not appear (or it is replaced by a character that looks similar to a forward slash but is not one), it will be read as part of the section before it.
Each character (letter, symbol, etc) that can be typed can also be translated into unicode, which is a unique numerical value that is universally used to refer to that character. The unicode value for a legitimate forward slash is U+002F (/). This is the forward slash which you can see on a standard keyboard. Since unicode is used for every character possible, in various languages and scripts, there exist other similar characters, such as U+2044 (⁄) and U+2215 (∕). In a URL, only U+002F (/) is recognized as a forward slash which indicates the beginning of the Path section.
Let’s break down a URL which uses U+2044 (⁄) or U+2215 (∕) forward-slashes:
https://example.com∕path∕@file.zip
https://example.com∕path∕@file.zip
What we think is happening in this URL:
Scheme : https://
Hostname : example.com
Path : ∕path∕@file.zip
Therefore, the visitor is being sent to the domain 'example.com' to see the file 'file.zip'. If they trust this domain, they are likely to trust the contents of the .zip file. In reality, the URL that would send its visitor to the file 'file.zip' on the Hostname 'example.com' is https://example.com/path/file.zip
What is actually happening:
Scheme : https://
UserInfo : example.com∕path∕@
Hostname : file.zip
Since the computer is not detecting a forward-slash after example.com, it is not registering the Path at all. The inclusion of the '@' symbol signifies the end of the UserInfo section of the URL, and since 'file.zip' is now a real URL instead of just a file name, it can be used as a Hostname. The visitor is therefore sent to the domain 'file.zip'.
This could potentially be an issue for all URLs, but it has become more dangerous in the wake of the new .zip TLD. A regular file does not work as a Hostname, so attempting this trick before '.zip' became a TLD would result in a failed URL (in which 'file.zip' is not an existing domain, and therefore cannot be used as a Hostname) or require a conspicuous file name (such as https://example.com∕path∕@file.com).
Now, a phishing domain can disguise itself as a regular file in a Path, and it is harder to discern whether or not it is acting as a Hostname. Ultimately, a phishing victim is more likely to click it.
While it may seem simple to distinguish between these malicious URLs because of the '@' sign appearing in the wrong spot, phishers can use basic tools such as adjusting the font size to fool even those who know what to look for. For example, reducing the font size of the '@' character can make it almost invisible. The only sign of illegitimacy may be the degree of slant in the forward-slash characters.
The .zip TLDs only became widely available this month, and we are already seeing phishing scams in the making. In some cases, Google itself appears to be taking back some of the domains since realizing the risks. Some of these include: ‘jpgs[.]zip’, ‘media[.]zip’, ‘1file[.]zip’, and ‘mysql[.]zip’.
Some security researchers have attempted to claim some of the most common ones before they can fall into the hands of malicious actors. These researchers often have a sense of humor, such as the owner of ‘msg[.]zip’, whose subdomains house amusing videos and images. Similarly, one researcher claimed the domain ‘arm64[.]zip’ just to send visitors to a Youtube video of 'Never Gonna Give You Up' by Rick Astley.
Other researchers are taking a less humorous approach, using these sites as opportunities to advocate against .zip domains (‘financialstatement[.]zip’) or as test domains for security research (‘bakup[.]zip’). The threat that these new .zip domains pose is widely understood by those who stay up-to-date in the cybersecurity field, and many researchers are questioning Google’s decision.
According to NetCraft, scammers have already used some .zip domains for phishing purposes. Some examples include: ‘report2023[.]zip’, ‘microsoft-office[.]zip’, ‘microsoft-office365[.]zip’, ‘e-mails[.]zip’, and ‘login.payment-statement[.]zip’. A few of these were attempting to mimic Microsoft login pages. Thankfully, these domains were reported and have since been taken down.
Suspicious sites include domains which mention banks, trusted websites (ex: ‘outlook’), and words like ‘installer’, ‘update’, ’setup’, or ‘file’. A Passive DNS scan revealed interesting new domains including ‘pdf[.]zip’, ‘file01[.]zip’, and ‘web[.]app[.]zip’, which are designed to look like generic files. Even if these are not currently malicious, they could certainly be used in a variety of future phishing scams.
Like with any phishing threat, awareness is the first step to avoiding exploitation. However, this is not always enough. Here are a few specific suggestions to help you avoid being the next victim of a phishing scam:
Approach Links with Caution
General cybersecurity awareness should encourage all users to be careful when clicking links, especially when they come from an unknown source. Even when you are fairly sure the link is legitimate, it should be common practice to hover your mouse over the link to see the expanded path, which may reveal a hidden '@' symbol or a suspicious URL redirection.
Recognize .zip Scams: Examine the URL
It can be helpful to look for obvious signs of a doctored .zip link, such as the '@' symbol’s appearance somewhere in the Path to the supposed .zip file. Another indicator is the slight difference between legitimate and illegitimate forward-slashes. The legitimate symbol (U+002F (/)) will always appear after the Scheme (ex: 'https://'), so you can visually compare these slashes to the ones in the Path section of the URL.
Block Phishing from your Network
Aside from careful investigation and security-conscious practices, SMBs, Enterprises and MSPs can use ThreatSTOP for reliable protection from countless threats including phishing. ThreatSTOP’s network enforcement solutions make it impossible for your machine to reach known malicious sites by blocking their Domain and IP address.
ThreatSTOP is fully aware of the threat '.zip' poses, and has already begun blocking suspicious .zip addresses that could easily be used for phishing purposes, even if they do not currently host malware (ex: ‘setup[.]zip’, ‘docx[.]zip’). Phishing domains utilizing the '@' symbol addition tactic can also be blocked. By pulling together various threat intelligence sources alongside predictive analysis of future threats, ThreatSTOP has created a comprehensive and dynamic blocklist that will keep your network secure.
Not a ThreatSTOP customer yet? Want to see how ThreatSTOP can instantly eliminate attacks on your network, or how it can effectively grow your MSP services?