Red Team Unauthenticated Client Active Directory Fun

by RichieB

After a recent Red vs. Blue live challenge, I realized the importance in making the preemptive first strike in order to completely throw the blue team off the scent or even better, throw them off the network.  No point having a pesky blue team and their Managed XDR functions that detect or learn to detect whatever we have done and then isolate us.

I came across an interesting, very well written (IMHO) article written up by Akamai (www.akamai.com/blog/security-research/spoofing-dns-by-abusing-dhcp#mitigation).  No code was provided, so I set about recreating the exploit code and each of the issues they talk about, with the hope of maybe even finding some more paths to leverage.

In this write up, we are going to abuse default behaviors in DNS updates against a domain controller that also has DNS and DHCP roles from an unauthenticated client point of view - think someone with physical access to the network.  A DC having DNS and DHCP roles is a common configuration.

Setting the Scene - Microsoft's Documentation

The DNS update functionality enables DNS client computers to register and to dynamically update their resource records with a DNS server whenever changes occur.  If you use this functionality, you can reduce the requirement for manual administration of zone records, especially for clients that frequently move and use Dynamic Host Configuration Protocol (DHCP) to obtain an IP address.

Windows provides support for the dynamic update functionality as described in RFC 2136.  For DNS servers, the DNS service permits you to enable or to disable the DNS update functionality on a per-zone basis at each server that is configured to load either a standard primary or directory-integrated zone.  By default this is enabled.

Microsoft has even noted the following:

When the DHCP Server service is installed on a domain controller, you can configure the DHCP server by using the credentials of the dedicated user account to prevent the server from inheriting, and possibly misusing, the power of the domain controller.  When the DHCP Server service is installed on a domain controller, it inherits the security permissions of the domain controller.  The service also has the authority to update or delete any DNS record that is registered in a secure Active Directory-integrated zone.  (This includes records that were securely registered by other Windows-based computers, and by domain controllers.)

DHCP Options FTW

When a client device first connects to a network, or its current DHCP lease expires, the client asks for an IP address from the DHCP server.

In order to do this, the client device must broadcast a "DHCP discover" to all the DHCP servers on its network.  The IP address offers should roll in.  The client, after reading the offers, sends a "DHCP request" detailing its acceptance of one of the offers.  Each of the DHCP messages can have options that the receiving end can interpret and respond to.

In theory, there are 253 of them plus one to start the options and one to end the options.  In practice, not all are used.

The little used (AFAIK) one that interests us is Option 81.

This option tells the server that the client would like a specific Fully Qualified Domain Name (FQDN).  There are some flags that indicate whether the server or the client should be handling the DNS assignment.  In everyday Active Directory (AD) workstation land, this is, at best, the authority of a client device who has the authority to make that DNS change.  This is normally O.K., since the client device is enrolled on the AD and thus its machine creds have weight within the AD to do something like that.  But for a non-Windows AD compliant device, there is a mechanism to ask the DHCP server to make that change.  If the DHCP server is a role on the domain controller and does not have a specific user assigned, then the authority (and therefore ownership) of the DNS record change will be the DC.  It just so happens that by default any device can ask for an IP address of the DHCP server and then tell the DC to add a DNS record (within limitations, TBA) the unauthenticated client device has requested.  Because the DHCP server is running with the authority of a DC, the DHCP service is empowered to make requests of the DNS service, which in turn can make changes to the AD's DNS records.  IOW unauthenticated AD DNS chaos is a distinct possibility.

Regarding limitations mentioned earlier, the requested DNS name needs to fit within the zone delegated by the AD's DNS service.  In other words, if the AD domain name is XXXX.org, then we need to be setting sub domains of that as the FQDN.  In the code shown below, I set the unauthenticated client to request ftw.XXXX.org be added to the DNS.  See the screenshots below for the code to make that happen and the end result at the DNS server (Windows 16 Domain Controller for my XXXX.org lab).

Note this is PoC code that uses hard-coded UDP packet transaction IDs, MAC addresses, etc., and has way more in it than required for the exploit, as I was learning to use Scapy to create DHCP/BOOTP protocol packets.  I make no apologies for its crudeness.  If elegant code is your thing, please, in the immortal words of Dionne Warwick Walk On By.  Running the code will ask the DHCP server to ask the DNS server to add the ftw.XXXX.org record to the DNS records:

  

O.K., So Now What?

We have a mechanism to add DNS records using the DC's authority while unauthenticated.  Let's step through the rest of the Akamai article and explore what else we can leverage using this technique.

Firstly, since we know we can add DNS records to an AD, we need to confirm if we can overwrite an existing DNS record and point that FQDN our way.

DNS Record Overwriting?

Let us create an A record at the DNS server pointing to a legitimate IP address and then attempt while unauthenticated to get the DNS server to change the record to point to the unauthenticated device:

Let's create the exchange.XXXX.org A DNS record:

Let's look at the permissions for the exchange DNS records.

Only the privileged groups can do anything:

Wouldn't it be nice to redirect the traffic for the exchange server to the attacker?

We need a DHCP offer... let's create one...

And running the above and crashing out of the while loop after the discover and then the request has been sent:

Let's take a look at the DNS server.  You need to refresh the view of the Forward Lookup zone:

Note the IP address is now that of the attacker for the exchange A record.  Let's look at the permissions of the exchange record again:

Definitely no unauthenticated access or access from any old device and still the same principals who can make changes as before confirming the changes were made at Enterprise DC level.

Moral of the story: separate out the key AD roles from your DC.  Then assign separate users to manage those roles.  This will go a long way to reduce the risk of this attack.  Couple it with secure DNS updates and protected DNS writes (not default) as a defense in depth and this attack will be even less likely.