It’s because it can cause confusion. The only difference between example.com/file.zip and example.com.file.zip is one uses a . and the other a / but both are valid domains. If somebody isn’t paying much attention or they don’t know much about domain names, they could click thinking to get a zip file from a legitimate site and end up going somewhere malicious instead. No other TLDs have this issue (well, I guess .com technically has it but who the hell is downloading and running com files these days) and they’re pretty much exclusively used for this reason so it’s a good idea to block them just to be safe.
sorry, I didn’t saw your answer and also replied! I didn’t remember that (.)COM was also a file extension, but now, thanks to your reminder, I will play some DOS games ;)
since .zip and .mov are recognizable file extensions, a url of the form google.com.docs.zelensky.zip could make people think that the domain is google.com pointing to a zip instead of the true domain, zelensky (dot) zip which probably would serve malicious content under that subdomain.
i think i understand that part but why is this specific event “another reason to block this TLD”? can’t they just use any TLD for this and achieve the same thing? is there another inherit security issue with .zip that doesn’t exist with other domains?
gotcha ok i think i’m getting it. just to make sure i’m not missing anything, you’re saying that in this case it didn’t matter as in the end they could use any TLD and achieve the same effect.
but in general, threat actors hope to confuse people into thinking this “.zip” TLDs are only referencing local files instead of web addresses. right?
Another reason to block this TLD in the firewall solution.
Yea I’ve got both
.zip
and.mov
blocked on my piholesorry i’m missing it. why this specific TLD? can’t they just use any TLD for this and achieve the same thing? is there something special with .mov?
It’s because it can cause confusion. The only difference between example.com/file.zip and example.com.file.zip is one uses a . and the other a / but both are valid domains. If somebody isn’t paying much attention or they don’t know much about domain names, they could click thinking to get a zip file from a legitimate site and end up going somewhere malicious instead. No other TLDs have this issue (well, I guess .com technically has it but who the hell is downloading and running com files these days) and they’re pretty much exclusively used for this reason so it’s a good idea to block them just to be safe.
sorry, I didn’t saw your answer and also replied! I didn’t remember that (.)COM was also a file extension, but now, thanks to your reminder, I will play some DOS games ;)
since .zip and .mov are recognizable file extensions, a url of the form google.com.docs.zelensky.zip could make people think that the domain is google.com pointing to a zip instead of the true domain, zelensky (dot) zip which probably would serve malicious content under that subdomain.
sorry i’m missing it. why this specific TLD? can’t they just use any TLD for this and achieve the same thing? why is this a reason to block it?
Because .zip is a commonly used file extension.
i think i understand that part but why is this specific event “another reason to block this TLD”? can’t they just use any TLD for this and achieve the same thing? is there another inherit security issue with .zip that doesn’t exist with other domains?
They can and they do. Using a commonly known and used file extension to “hide” a malicious URL is just easier.
https://www.youtube.com/watch?v=GCVJsz7EODA
Here is an alternative Piped link(s): https://piped.video/watch?v=GCVJsz7EODA
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
gotcha ok i think i’m getting it. just to make sure i’m not missing anything, you’re saying that in this case it didn’t matter as in the end they could use any TLD and achieve the same effect.
but in general, threat actors hope to confuse people into thinking this “.zip” TLDs are only referencing local files instead of web addresses. right?
Exactly!