A long time ago, Google applied for the .zip Top Level Domain(TLD) to ICANN and their application was granted.
Recently, Google (Google Registry to be specific) announced that these TLDs will be available for use. These include domains like .Foo, .Zip, .Mov etc.
Whilst they may seem innocuous on first glance, there is a big risk for malice when it comes to these top level domains.
Let's say I write an email/blog/slack message that references a file abcd.zip.
abcd.zip would never have been considered an 'internet bound link' back in the day.
Of course, one ought to never blindly click on such links and ought to identify the 'linked' destination.<cough> Internet Security Awareness </cough>.
But this is no longer the case with Google's announcement.
A threat actor could register the domain abcd.zip and point the file to a malsite abcd.zip, and subsequently, if a user were to click on such a link, trigger the auto download of a malicious file.
This calls for enterprise admins to be extra careful when it comes to these domains as you(or your SOC/Threat team) are steering web traffic(80/443) and are very likely responsible for gatekeeping what your end-users can access and what they should't access.
A lot of these domains are going to be net new i.e. newly registered domains and/or uncategorized.
As a Netskope admin, what do you do then?
- Block Risky Domains - Easy Peezy - Create a URL list for these TLDs, place them in a custom category, proceed to block them via a real-time protection policy.
Create a custom URL lists as needed and place them in a custom category. Here, I'm creating one for .zip only, but choose TLDs to your hearts content (.zip, .app etc etc.), and add them to your custom category.
Select this category within your real-time 'block' policy and <boom> you're done
- Block Risky Categories - Pretty straightforward, and similar to (1). Select the categories. you deem risky and block it right away - Uncategorized, Newly Registered Domains etc.
Optional - you may choose to block just upload/downloads to/from these risky categories, but blocking outright is an option I prefer. Of course, blocking outright can result in a lesser than ideal user experience when users hit recently created/hitherto unknown(uncategorized) legitimate domains, but that's where point (3), explained below, can help.
- Remote Browser Isolation(RBI) - With Netskope's Remote Browser Isolation technology, you get to allow users to access these potentially risky domains sans the risky action - download/upload/form-post etc.
In the screenshot below, leveraging a read-only RBI template, sessions to these 'risky' websites are rendered via an isolated session and rendered in read-only mode. An admin can use Netskope RBI to allow printing, downloads etc as needed - all of this is explained here - check it out and/or contact your Netskope Customer Success Manager/Netskope Account Manager for details.
- Patient Zero Policy : Another option available to you at the moment is to allow for risky actions, say, downloads, to happen ONLY after Netskope's Advanced Threat Engine aka DeepScan (think SandBox/Heuristics analysis etc.) has a verdict on the file being downloaded. This is explained here and requires a backend flag be enabled - I highly recommend you give this a bit of thought before you enable this to ensure optimal user experience - (read: set this policy up only to analyze risky files (specific file types) downloaded from specific web categories)
Notice in the screenshot below, we're taking extra care when downloading specific file types - this is a step you may want to take when downloading risky file types - exe, tar or zip files (say) so that you're not waiting for a verdict on every file type (which may drive users nuts). This policy ought to also be placed above any other threat scanning policies you have to ensure special treatment to these risky file types. <you've been warned>
If you see a malicious URL that's been mis-categorized, do place a re-categorization request - helps us all enormously - To do this, you can use the web-UI, but did you know that we recently released a REST API for this ? 🙂
I hope this short post guides you to take extra care of your user base in the midst of this TLD madness
I can assure you that it's not just me who's paranoid about this - SANS is too <grin>
Questions or Comments, please post 'em in the comments below.