The dangers of Google's .zip (and other domains) and how to block in AdGuard/Windows/Defender with Intune and monitor for access attempts.
While having a new found .zip sounds cool, especially if you host a product where you can instantly download it by going to productname.zip, it creates some issues from a security standpoint especially with end-users.
The main issue is phishing becomes easier when you start to confuse files with urls especially when you can abuse bugs like those in Chromium which allow hostnames containing U+2044 (?) and U+2215 (∕) in the URLs and can be used to trick users.
Already the following domains have been registered:
Lets reference some great talks on the issue:
Now that we know the issue, what can be done? It really depends on how your organize has configured and setup their environment when it comes to DNS. If you have a dedicated DNS service, you can block from there. This also gives you the ability to better manager DNS traffic. For example, I run AdGuard on one network with over 1 million domain related filter rules and this allows me to block a lot of malicious traffic real quick.
AdGuard
If we have AdGuard DNS we can block with the following and apply unblocks on a need per need basis. You can also use this logic to block other domains.
If you don't have a dedicated DNS service, your options are limited unless you have an EDR solution or a way to push changes to your endpoints. Windows natively does not support wildcard blocking on domains with the built-in DNS Service.
Windows Defender and Intune
We are going to make use of the reusable setting feature in Intune as it makes it possible to reuse setting in multiple policies. This has been my goto style for deployment when possible. It created managing bigger environments easier.
领英推荐
Just be sure to test this policy before deploying live to prod but this should give you an idea on how to manage and push policies from Intune.
Monitoring
What if you can't block .TLDs like .zip but also want to monitor for DNS domains? The quickest way is to use your SIEM. In this case, we have our DNS logs from Windows being sent in to Sentinel. Because of how we have DNS configured, there is no point to having AdGuard logs sent into Sentinel as they only show which DC with DNS send the lookup request, no end-user information.
Remember, as always, we can also turn this into an alert or daily report if we want a more proactive response to this.
What are some takeaways from this?
DNS should be seen as something we monitor constantly and look for new developments that could confuse and hook our end-users allowing a compromise.
Looking for something fun to read? Checkout this research on TLDs and seen abuse: https://unit42.paloaltonetworks.com/top-level-domains-cybercrime/
You can also deploy my DNS Info and Threat Response Workbook/Dashboard which shows you a list of accessed uncommon and known dangerous TLDs from my GitHub in a quick view and drill down into the endpoints making the connections.
---
If you are new to my content, be sure to follow/connect with me on LinkedIn and other social media for new ideas and solutions to complicated real world problems.
---
?and??with me for more??content!??????????????????????????????