It sounds insane to me that the security of anything would depend on the validity of a DNS record, but I vaguely remember that AD is extremely dependent on DNS configuration
That having been said, if the domain has relaxed security to support legacy systems, or was built 20 years ago and incrementally upgraded to newer Windows versions ever since, this technique seems like it could be used to compromise the domain. For example, if NTLM auth is enabled, but signing is not required, it seems like this would allow a network-wide version of NTLM relaying attacks. Those are usually done using subnet-specific name spoofing, so it would be a big increase in scope.
Additionally, in most large enterprise environments, there will be at least a few third-party products that are set up (deliberately or by default) to operate in a way that could be exploited using this technique. Web applications that authenticate using cleartext HTTP, network appliances with telnet or other unencrypted sevices, email that's exchanged over cleartext SMTP, etc., on the assumption that an attacker would have to already have privileged access to something to capture the information sent over that channel. I suspect there would usually be a way to exploit one of those things in a way that would eventually lead to compromise of the AD domain.
e.g. the organization uses Cisco network hardware configured to back up their configurations to a TFTP server every night. The attacker exploits the DHCP DNS vulnerability to pretend to be the TFTP server and captures the device configurations. They decrypt reversibly-encrypted network appliance administrator passwords, or crack the hashes if they're stored in a non-reversible format. Then they use those credentials to alter the TACACS configuration on one or more network devices to send credentials to their own system when someone tries to log on. TACACS is set up to authenticate to AD, so now the attacker has a bunch of AD credentials that belong to network administrators.
One would think that, but I literally cannot enumerate the number of Domains that were setup by...let's just say, people that had no business setting up domains. Default settings are partially defined during the install.
The more advanced protections introduced over the last two decades are mostly off by default.
As a random example, a trust established between two AD forests using only Windows Server 2022 domain controllers will default to RC4 encryption instead of AES!
It takes a lot of thankless work to properly secure an AD domain, and often it’s a impossible task because of incompatibilities with - checks list - Microsoft software released as recently as 2020.
Ahem. "The /etc/exports Configuration File" - https://access.redhat.com/documentation/en-us/red_hat_enterp...
I can't do a dns-01 challenge (that would require _acme-challenge records, although even then, I'm still up to 2, not 3, records), but I don't have to do a necessarily have to do a dns-01 just to get a cert…
If you can control the record seen in one datacenter for example.com, you don't get the cert. They check the root NSs from three DCs.