DNS Takeover + LDAP Relay
Last updated
Last updated
All Windows versions since Windows Vista (including server variants) have IPv6 enabled and prefer it over IPv4. IPv6 attacks abuses the default IPv6 configuration in Windows networks to spoof DNS replies by acting as a malicious DNS server and redirect traffic to an attacker specified endpoint.
ipv6 is setup by default on all windows machines in a network even if the network doesnt utilize v6 so no one is doing dns resolotion for v6 .an attacker can setup a fake dns server and resolve all ipv6 requests in a network and forward them to the DC so we can sniff the authentication and hashs on the way with a tool like MitM6.
For DNS takeover to work, the AD CS role must be installed and configured on the domain controller.
we run mitm6 on the domain use -i to specify the interface.
leave the terminal open, for now we are playing the role of an IPv6 DNS server in the network.
we use ntlmrelayx.py script from impacket tools to relay the credentials when a client requests for IPv6 resources.
lootme : the directory to save the hashes
First we start mitm6, which will start replying to DHCPv6 requests and afterwards to DNS queries requesting names in the internal network.
For the second part of our attack, we use ntlmrelayx to relay the captured hashes. Now i will show two possible ways to use this tool, first through a simple SMB relay like we saw earlier
In this case, the attack is pretty much the same as the one we saw earlier we juste replaced responder with mitm6 for the obvious reasons previously mentionned.now, another attack is possible through WPAD serving. WPAD is a protocol used to ensure all systems in an organization use the same web proxy configuration. Instead of individually modifying configurations on each device connected to a network, WPAD locates a proxy configuration file and applies the configuration automatically. More details about this attack can be found in the references. using ntlmrelayx to also implement this attack, we launch the attack using the following command :
When Windows configured for DHCP boots, it looks for DHCP configuration, and then proxy configuration using WPAD. That way, when the victim computer boots and starts looking for proxy config, the machine account tries to authenticate to us.
We set up a man-in-the-middle DHCP server on IPv6 and serve a DNS IPv6 configuration that points to our rogue DNS IPv6 server.
When the victim uses WPAD to look for a proxy configuration file over DNS, we let it connect to our fake proxy server and then prompt for authentication using a 407 Authentication Required request.
We capture and relay the (encrypted) credentials of the machine account to LDAPS on the domain controller (DC).
We ask the DC over LDAPS to create a new machine account. Active Directory allows any user account, including machine accounts to add 10 machine accounts by default.( NOTE: LDAPS and not LDAP, because creating machines over unencrypted channels is prohibited)
We now have credentials for a machine account. The reason we create a machine account is that we need access to an account with a Service Principal Name (SPN).
We now ask the DC to configure resource-based constrained delegation for this new machine account on the victim computer object. For example: the machine account WS02$ sets the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the computer object WS02 to allow the newly created machine account to impersonate users on it.
We request a service ticket using the machine account that was created, where we impersonate a user that has local admin access to our target computer.
We use the service ticket to access the computer with local admin privileges. The ticket with these privileges is only valid on the target box.
Now off to the commands :
getST.py from ntlmrelayx, which will do all the S4U2Self an S4U2Proxy magic for us. You will need the latest version of impacket from git to include resource based delegation support. In this example we will be impersonating the user admin, which is a member of the Domain Admins group and thus has administrative access on ICORP-W10Once that done, you should've the keberos service ticket for the user admin saved in admin.ccache file and is valid for cifs/icorp-w10.internal.corp. This only lets us impersontate this user to this specific host, not to other hosts in the network. With this ticket we can do whatever we want on the target host for, for example dumping hashes with secretdumps:
The attacker now has full control over the victim workstation.
Consider NTLM relay mitigations.
Disable IPv6 on all systems if you are not using any related network services.
If using IPv6, configure the DNS settings on all systems. (broadcast DHCPv6 will make DNS take over possible).
Disable Proxy Auto detection via group policy to prevent WPAD attacks.
If your company uses a proxy configuration file internally (PAC file) it is recommended to explicitly configure the PAC url instead of relying on WPAD to detect it automatically.
Monitor the traffic for unknown DHCPv6 / DNS servers.
