The new ".zip" domain is being used almost solely for malware. Some of the clicks are very deceptive, even to technically knowledgeable people. See the attached image for an example.

You can block all zip domains with the following uBlock Origin rule under My Filters:

||zip^

Tell everyone you know.

@suprjami

The slashes in the path part of the first url look different than the slashes in the scheme and everywhere in the second url. So my guess is that the first url is the malicious one.

I would have missed it if I hadn't been looking for a difference though. Thanks for the info.

@bjb @suprjami ooooh I hadn't notice that detail! I was going for the @ in the address
@EnaWasHere @bjb @suprjami it's the @. Everything between http(s):// and @ in interpreted as a username and potentially a password, the part after the @ is the host and path.
@dragonfrog @EnaWasHere @bjb @suprjami That's not quite right, the username/password part cannot contain (amongst other things) forward slashes. This attack is relying on using a unicode character that looks like a forward slash but isn't one.
@jribbens @EnaWasHere @bjb @suprjami I see, it's both the @ and the pseudo-slashes. Thanks for pinning that out.

@bjb @suprjami so basically this is yet another occasion where unicode hurts instead of actually helping.. why can someone register a domain with deceptive symbols in it??
#letsgobacktoasciionly

EDIT: my mistake that everything before the @ is the username, got rightly pointed out to me multiple times. Doesn't make me blame unicode less though, because afaik a forward slash is not allowed in such a username and in this case unicode allows this to look like a "valid" url regardless...

@tizilogic @bjb @suprjami This attack doesn't involve unicode domains - there are unicode characters involved but they're not part of the domain name, which is entirely ascii.
@tizilogic @bjb @suprjami actually here everything before the @ is actually the username one is trying to connect to on the malicious .zip domain.
@tizilogic The actual domain there is v1271.zip, everything before the '@' is interpreted as a username.
@bjb @suprjami Thanks… You gave me another thing to look for in email etc. scams. At least you have the two slashes after http: or https: for comparison.
@bjb @suprjami interesting view - you're right about which one's malicious but not right about why... sort of

the first URL has an @ symbol in it before the v1271[dot]zip. the @ symbol in a URL is actually a separater between user and URL (you could have "username:[email protected]") so the first one tries to log in as "https://github.com/....." at (@) v1271[dot]zip - so in actual fact the website you're going to is v1271[dot]zip, not github at all.

what you say about the slashes is interesting though, as whatever is styling the URL is almost helping highlight the problem. the correct link is completely a link, so all slashes are styled the the same, but the malicious link isn't completely a link so some slashes are styled differently to the actual link ones.

man this is hard to explain, I know you're fairly techy so I skipped some explanation, but try explaining that to a regular person!

Edit: removed dots in URLs to prevent unintended visits.
also sorry, didn't realise this comment was a month old... you probably know all this by now
@paul @bjb @suprjami the fake slashes are critical to the attack. They become part of the basic auth user name. If they were real slashes, the browser would treat them as part of the path.
@chucker @bjb @suprjami interesting and a really good point! I hadn't considered that.

Imagine trying to explain that to somebody who had just downloaded the malware though!

@suprjami
For pihole users (copied from reddit)
Blocking a whole TLD in PiHole:

Log into your PiHole via the web interface

Find "Domains" on the left-hand column and click on it

On the Domain tab in the right window, find the Domain text entry, and add "zip" (without quotes)

In the Comment field, I added "Manual - Google .zip TLD" for my own records

Be SURE to check "Add domain as wildcard" to block the whole ".zip" TLD

Click on "Add to Blacklist"

Repeat for the "mov" domain as well (without quotes also)

@suprjami which one is which?
The Dangers of Google’s .zip TLD

Can you quickly tell which of the URLs below is legitimate and which one is a malicious phish that drops evil.exe?

Medium

@HydrePrever @celesteh @suprjami Damn. That’s subtle. Unicode for the phishing win here…

That said, the domain is already blocked on my internal DNS servers, but now I’m more seriously thinking about forcing their use even when on public cellular internet connections

@celesteh @suprjami
Top one with the @ is potentially malicious. The domain is v1271.zip with the bit to the left of the @ as a username crafted to look like a URL.
An old trick with a slightly new twist as you can use .zip and .mov now, which allows it to look like a zip archive or a video file to a casual user.

*(Blocked both on our network via the piHole)*
@suprjami actually the slashes do not match either, i thought that was the catch

using (U+2215)
instead of / and just creating say kubernetes∕kubernetes user with archive as project
@suprjami Didn't virtually every infosec person say this would happen?

@suprjami What browser are you seeing the @ URL treat v1.27.1.zip as the domain in?

I can only get it to work with pretty trivial URLs; as soon as there's a slash in the username portion, it's detected as the domain/path portion by chrome/safari/curl.

As far as I can tell, https://[email protected] can be used for phishing,

but anything more complicated, like the example you posted, cannot -- e.g. https://github.com/[email protected]

@owls Those aren't slashes, they're unicode 2215 "looks like a slash but isn't" characters.
lists.d/drop.domains.block.list.tsv at main · greyhat-academy/lists.d

List of useful things. Contribute to greyhat-academy/lists.d development by creating an account on GitHub.

GitHub
@suprjami It feels the real mistake here was allowing the whole of unicode in domain names. Perhaps select one language for each URL and stick with it but mixing 10000 different symbols is going to lead to weird stuff like this
@sjb @suprjami that was also a mistake, but neither of those URLs has Unicode in it, there both all ASCII.
@dragonfrog @sjb @suprjami no, it's been pointed out elsewhere in the replies that this only works if you use Unicode characters that look like ASCII slashes but are not.
@HunterZ @sjb @suprjami Oh I see! That makes sense thanks.

@suprjami

Know your rights.
Never click any damn thing unsolicited.
Never post unsolicited dick pics.
Never post solicited dick pics.
Never use your personal computer, mobile personal computer (smart phone), for illegal acts.

Never say anything above a whisper that you don't want god to hear. She is listening.

@suprjami @catzilla I appreciate this info. The bigger question is why hasn't Google simply killed this domain (they created it)?

@suprjami I just wrote about those obfuscation techniques:

https://hackers.town/@madcap/110503296565140190

madcap :hackers_town: (@[email protected])

URL Obfuscation time! I recently read Nick Simonian's [post](https://www.mandiant.com/resources/blog/url-obfuscation-schema-abuse), at Mandiant, about the "Don't @ Me Url Obfuscation" technique. It's a very interesting technique, but it seems to me that the "@" sign in the URL still looks very suspicious, don't you think? ``` http://google.com@3264653699 ``` But what if we could take this technique to the next level? If we could add a slash right next to the fake URL it would look much better. But if we simply add a slash to the example above, the browser will of course navigate to google.com. What if we could find a character that looks just like a slash but is interpreted as a regular character? We can and you guessed it: we can use Unicode characters anywhere before the @ sign and the browser will consider it to be part of the username portion of the URL. Let's use the character U+2215, a division slash, that looks pretty much a regular slash. The unicode character really makes a difference. Look at the URLs below. They look pretty legit, but if you copy any them to your web browser, you will be taken to the web page of Phrack magazine: ``` http://google.com∕@3264653699 http://google.com∕support∕@3264653699 http://twitter.com∕elonmusk∕status∕@3264653699 ``` Chrome/Chromium will simply navigate to the obfuscated address (the IP address of phrack.org in decimal format is 3264653699). Firefox, though, shows a warning that you are trying to log in to the obfuscated IP with a weird username. That should be enough to grab your attention. I think Firefox is doing the right thing, warning the user, and other browsers should also add some protection against this kind of attack. It's easy to fall for this trap, even if you're an experienced computer person. The IP in the address bar should actually raise an alarm in your brain, but what if you just don't notice it? What if you're in a hurry and don't pay attention to it? Browsers can prevent this. #infosec #cybersecurity #obfuscation #phishing

hackers.town
@suprjami @garius Think you've got the biggest reach of everyone I follow...
@suprjami Who in the world thought it would be a good idea to allow characters that look like slashes in domain names ? 😬
@jor c'est le @ qui pose problème, pas les slash

@suprjami Where do you put this rule?
uBlock Origin rule:

||zip^

The Dangers of Google’s .zip TLD

Can you quickly tell which of the URLs below is legitimate and which one is a malicious phish that drops evil.exe?

Medium
@suprjami
Wow. That took several seconds for me to figure out which despite the indicator being obvious once I saw it. Hell.
@casuallynoted
@suprjami There are so many replies by technically inclined people (well, looking again, one person) thinking those U+2215 division slashes are regular slashes and therefore the @ isn’t parsed correctly, even with a font showing a difference. All the more reason to take it seriously. My browser does show %E2%88%95 when I hover over the link, even if specified as straight Unicode. That’s another viable tell.

@suprjami Sadly not surprised it took off like this.

Maybe this will give me an excuse to finally get a Pihole running on my network to block these. I've mainly avoided doing so because of the whole manual process of disabling/whitelisting stuff for which a lot of legit sites still need to function correctly.

@suprjami Extra note: Test your filtering rule by trying to open this test domain: https://canigothere.zip/

If you can open it without getting stopped and see the message, your block isn't working.

Test to check if you can get to .zip TLD

@suprjami Are there already malicious zip domains in the wild?
@suprjami
Just blocked all zip TLDs in my router, thanks for the heads up!

@suprjami what's even better is that google use sliding scales for how much any given .zip domain costs.. $dayjob bought one (not a super generic word, but is an umbrella brand we use) for 48 bucks, other versions of the same brand word (but separated out into their two component words) are 680 for one, and 1480 for the other. Per year.

The domains are utterly useless to us, but buying them _might_ reduce some phishing, maybe.

Google, in my opinion, can frankly go get F'd, the greedy @#$%ers

@rasur @suprjami How does anyone still take this company serious.

On one hand they have a de facto monopoly on Certificate Transparency, they have a browser that enforces it in the name of internet security. And on the other hand they sell domains that are perfect for phishing.

@suprjami

Why the hell did Google decide to use a common file extension for a TLD?!?! That's just stupid!

@suprjami
I won't boost a non-inclusive toot. 🤷‍♂️
@suprjami Good idea - I've just added a regex filter for (^|\.)zip$ on my Pi-hole.

@suprjami Neither can be determined safe.

Not just because of unicode lookalikes, but also because there's no reason to believe that the legitimate kubernetes source is at either of them without any additional verification.

@suprjami "exclusively for malware" citation needed.
Very few from what I've seen actually so far.
I typed 'subprocess.run' into my browser looking for the docs for the #Python function. It took me to some scammy malware page. '.run' is another new top level domain to watch out for, along with '.zip'
@suprjami Yikes. Thanks for posting this! I think the rule has to be to basically never click on links in emails and only with great care in web content. Hopefully browsers will grow support to refuse such links.