Post cover image

October 2, 2026

DNS Server to Enterprise Admin: Exploiting ADIDNS Custom Policies

One of my favorite things about Active Directory is the sheer amount of obscure little features that can be misused by attackers. I have…

By Giulio Pierantoni

8 min read

One of my favorite things about Active Directory is the sheer amount of obscure little features that can be misused by attackers. I have now been toying with and researching strange little ADIDNS features for a while, and I found one that in some very specific situations could be exploited by a half-privileged attacker to intercept credentials and relay traffic.

The modification of ADIDNS records to achieve MITM is a known technique. The usual scenarios where this can be done are:

  • the main DNS zone has insecure dynamic updates enabled (far more common than it should be)
  • the machine account linked to the target DNS record has been compromised
  • a domain admin account has been compromised
  • a member of the DNSAdmins group has been compromised

By replacing the IP address contained in A ADIDNS records we force every device trying to contact a host to go through the attacker. This can be useful for traffic capture and relay attacks, but there are two downsides to this approach.

First, depending on the host we are targeting we could be intercepting and slowing down a considerable amount of traffic: take a file server or a DC in a medium sized domain, our malicious computer will suddenly be contacted by every device that tries to contact our target (save for those who already have the actual IP address in their DNS cache, which will eventually expire anyway). If we don't employ redirectors all these devices will fail to contact the computer, which is obviously undesirable, especially if we are targeting a DC. Even with a redirector in place we'll be slowing down the network considerably.

Second, domain computers regularly check if their A records are up to date, if they find an IP address different than theirs they perform a dynamic DNS (DDNS) update to undo our change. If we don't monitor the record we might miss out on important traffic.

ADIDNS Custom Policies 101

There is an alternative method that I don't think has been covered before, useful if we happen to be local admin of ANY DNS server (not necessarily a DC), to achieve a fine-tuned MITM using a pretty obscure feature: Active Directory DNS policies. This method bypasses dynamic updates and allows us to only intercept the traffic of very specific domain hosts, instead of the whole network, while only intercepting the DNS queries we are interested in and leaving the rest untouched.

DNS policies can be set up to introduce conditional resolution rules: we provide a condition to meet, like the source IP matching a specific subnet, and create a "zone scope" where proxy records are created to return IP addresses that differ from the value of the same record in the main domain zone. Resolution requests meeting the policy condition will receive answers from the zone scope, everyone else will be completely unaffected.

None

We should exploit custom ADIDNS policies to only intercept the traffic of a small set of targets, maybe even a single host like the workstation of a domain admin, creating a policy that gets matched based on the source address and providing a /32 mask with our target's IP as the network address, this way only our target will match the rule and every other domain host won't have their traffic altered in any way.

In order to create ADIDNS policies we must be local admin of any one DNS server, although we need to keep in mind that policies are not AD objects so they won't be applied to the other servers. Instead, each DNS server has individual policies that are only evaluated when clients contact that same server.

Large domains are likely to have one or more dedicated ADIDNS servers that aren't already domain controllers, so it is very possible to become local admin of one of these without escalating to domain admin. In this scenario we could create malicious policies on the DNS server we control, allowing us to manipulate the traffic of every host that uses our controlled server for name resolution.

If we are domain admins we might still be interested in custom policies if we want a way to intercept traffic to and from specific addresses without executing malicious code on any domain computer. There are also scenarios where this could allow a domain admin to escalate to enterprise admin, as we'll see later.

Exploitation Steps

We can use the PowerShell cmdlets that are automatically installed on AD DNS servers, first we define the target subnet:

Add-DnsServerClientSubnet -Name "VictimSubnet" -IPv4Subnet "192.168.0.22/32"

Then we create a zone scope, this is where our proxy records will reside and we create it inside the main domain zone:

Add-DnsServerZoneScope -ZoneName "test.local" -Name "VictimScope"

Now we add one or more A records inside the scope, they must have the same name of the computers we wish to intercept the traffic for, like a commonly used web/file server, or even a DC, and its value is the IP of a host we control:

Add-DnsServerResourceRecord -ZoneName "test.local" -A -Name "SRVX" -IPv4Address "192.168.0.177" -ZoneScope "VictimScope"

What we have done is we have added a scope container and then a proxy record under the container ZoneScopeContainer, found under the root of the target zone.

None

Finally we create the policy itself, it's an ALLOW policy that is to be applied to any host that's part of the subnet we previously created, and we point it to the scope containing the "evil" proxy records:

Add-DnsServerQueryResolutionPolicy -Name "EvilPolicy" -Action ALLOW -ClientSubnet "eq,VictimSubnet" -ZoneScope "VictimScope,1" -ZoneName "test.local"

And now we wait, capture, or relay. To clean up after we're done we just launch the following:

Remove-DnsServerQueryResolutionPolicy -Name "EvilPolicy" -ZoneName "test.local"
Remove-DnsServerResourceRecord -RRType A -ZoneName "test.local" -Name "SRVX" -ZoneScope "VictimScope"
Remove-DnsServerZoneScope -Name "VictimScope" -ZoneName "test.local"
Remove-DnsServerClientSubnet "VictimSubnet"

If we just want to temporarily disable the policy and might need it later, we just run:

Disable-DnsServerPolicy -Name "EvilPolicy" -ZoneName "test.local"

Important note: if we are running these commands as a local user, like the DNS server default administrator, we need to add the -ComputerName DC.TEST.LOCAL parameter to every command except the call to Add-DnsServerQueryResolutionPolicy, since policies are stored only locally and not on the AD database.

Another note: we do not necessarily need to be logged onto the DNS server we compromised to run these commands, just install the RSAT: DNS Server Tools optional package and add the -ComputerName flag to the commands like said above.

None

Practical Considerations and Limitations

There are several limitations that make this technique hard to exploit. For starters, you need to be lucky enough to compromise a standalone Microsoft DNS server. It is by no means impossible, here are just a few ways this can happen:

  • LAPS is not employed in the domain and the local administrator shares the password with one we found before
  • the DACL of a user we compromised make it possible to set up RBCD or shadow credentials over the DNS server machine account
  • lucky admin-provided SMB relay since standalone DNS Servers do not have SMB signing by default at least until Windows Server 2025

The essential part of this attack is that we are local administrators of a DNS server (either as a local or a domain user) which we can reasonably expect our target is going to contact. If we already are domain admins we can simply look at the DNS configuration of the target host to see which server is assigned to it, or, if we have a device close to the target in the network maybe we can simply shoot out a DHCP query. Having the right DNS server is essential because policies are server-specific and stored locally, not on AD.

It is important to note that DNSAdmins do not have the necessary permissions to carry out the attack, unless you are willing to try the old "DNSAdmins to domain admin" code execution trick, which has been patched and is prone to crashing the DNS service on the DC anyway.

The ideal targets for the subnet are obviously users with high privileges, meanwhile the proxy records we may want to create depend on our final goal: if we want a quick way to escalate permissions an often used intranet web application is the ideal target, as the HTTP authentication will make it possible to cause an LDAP relay if at least a DC doesn't have both LDAP signing and channel binding enabled.

Alternatively, we can look for the sessions of domain admins who appear to have older password. In such a case any commonly used domain host, like a file or document server should work well, especially if logon scripts automatically mount shares for a user, which is something we can easily check through BloodHound, which luckily collects the logonscript attribute allowing us to look into if any hijackable actions take place during the logon process (also check out my colleague Marco Zufferli's blog for interesting ways to exploit logon/logoff scripts in general).

Another common exploitable configuration is one I see quite often: intranet web portals automatically opening on logon. The web server hosting these applications make for perfect targets for our proxy records and allow for easy LDAP relays. The original web app doesn't even need to support NTLM authentication, the authentication request is automatically handled by ntlmrleayx and the Windows HTTP client.

Malicious ADIDNS Policies in Action

Alright enough walls of text. This is the situation:

  • DEERCA: 192.168.0.34
  • PC-ADMIN: 192.168.0.35
  • Attacker: 192.168.0.9

Let's say you want to intercept the traffic PC-ADMIN sends to DEERCA, once all the commands are run this is the result:

None

Any time PC-ADMIN tries to contact DEERCA it will instead contact the attacker's host, meanwhile, any other domain host, like the one on the right in the screenshot, will keep receiving the right IP address. The attacker has now established a MITM with a specific host without touching the DNS configuration of the whole domain.

More Interesting: Subdomain to Root Domain Escalation

In the right conditions this attack can allow you to cross the trust boundaries and become king of the forest. You'll need to either be a subdomain domain admin or control a DNS server used by a computer where an enterprise admin sometimes logs on to.

Exploitation steps are identical, but if we want an easy way to elevate ourselves to enterprise admin we should set up an LDAP relay pointed to a DC in the root domain, and provoke an HTTP authentication request.

Let's take the previously mentioned example of an internal web portal automatically opening whenever someone logs in, it would look something like this (no I didn't code an actual portal for this PoC I suck at web stuff):

None

When anyone logs on to PC1.SUB.DEER.LOCAL the browser opens the app at DEVSRV1.SUB.DEER.LOCAL. The image above also shows that the user here is an enterprise admin, our perfect target. And if we know that our target enterprise admin logs onto a specific machine but there is no logon web portal appearing… we can just plant it ourselves in the Startup folder if we are domain admins!

And if we already are administrators of this subdomain nothing stops us from launching the attack directly from the main DC of the child domain:

None

Next time the enterprise admin logs in he won't be able to access the portal, but we'll receive an LDAP shell with his account on the root domain DC.

None

Why Do This Though?

On most engagements there will certainly be much simpler and more reliable methods to escalate privileges, but I love finding ways to use Active Directory features against the domain itself, this is an obscure method to modify the flow of traffic and achieve a MITM using only Microsoft-supplied features and cmdlets, allowing us to harvest credentials and launch relays without the aid of known malicious software, pretty much Living Off The Land if you exclude the need of a box to intercept the incoming sessions.

At the end of the day this was just an excuse for me to play around with weird little ADIDNS features, in the hope it might be useful to someone in a situation like this. More of that should come in the future as I keep exploring ADIDNS. Hopefully before another year passes.

References