With the launch of Azure DNS Security Policy, many individuals such as myself want to eliminate the risk of DNS based C2 fully with this new Azure service.
The expectation (and only real scenario where there is a point in using this script and the former Azure resource) is that you have an Azure Firewall already configured, along with properly configured Network Security Groups, and now you want to close off any potential for DNS based data exfiltration.
With this whitelist, you will be able to ensure that all your Private DNS Zones used by Private Links and Azure resources you have created with platform provided subdomains are resolvable by default, as you can just import the produced file into a DNS Domain List resource. As of writing you will need to split the list across 2 DNS domain lists, as there is a limit of 100 domains per DNS Domain List resource.
This repository will be overhauled significantly to create an interactive GUI where you can interactively choose domains which are needed for your use case. Expect activity here and things to break quickly and often. No backsies.
Beware: Allowing the usage of the Graph API in your environment opens up a well known and commonly used C2 data exfiltration vector, known to be used by state sponsored threat actors. Looking right at you North Korea :)
Someone should probably pitch to Microsoft having private per-application Graph API endpoints which strictly control what Graph API requests may be issued. The alternative until such a time, is building a HTTPS proxy which does TLS MITM, which has traffic rules to restrict what Graph API requests/traffic is allowed. You could probably do that with Squid proxy.
Ok, did you name them with the .internal suffix? Because .internal is what you should be using for your Azure Private DNS Zones which do not fall into the list used by Private Links and the Azure platform as a whole. ICANN as part of ICANN Resolution 2024.07.29.06 reserved .internal specifically for intranet and virtual network usage such as this. Do things properly, and then you only need to allow .internal in you DNS domain list. Otherwise, have fun! :) Because if you don't follow this, you technically open up your infrastructure to malicious DNS based exfiltration because on paper, if you don't use .internal any suffix you use is pretty much up for grabs for anyone to register as a TLD at ICANN. Even if you own the domain you are using for your internal DNS resolution with Azure Private DNS, why introduce additional risk for no reason? If you are doing this, ask yourself if what you are doing there is seriously needed to run your infrastructure or not. There are a few exceptions to this however.
This repository is not endorsed by my employer, organisation, clients, anyone, anything or any entity in any way, shape or form. This is released on the internet as a convenience only. Usage of this script may cause toast to sporadically appear inside of your computer case. No refunds, no "the toast has jammed my computer's fan" support here.