Network Relaying Abuse in a Windows Domain

Network relaying abuse in the context of a legacy Windows authentication protocol is by no means a novel vector for privilege escalation in a domain context. However, in spite of these techniques being well understood and documented for many years, it is unfortunately still common during the course of an internal network penetration test for Nettitude consultants to escalate from a low privileged user to Domain Admin in a matter of hours (or even minutes). This is due to a handful of Active Directory and internal network misconfigurations which this article will explore.

Through the course of four scenarios, we’ll cover both longstanding and more recent attack primitives that center around relaying techniques in the hopes that network defenders can apply the mitigations contained therein.

Scenario 1 – LLMNR/NBT-NS Poisoning

Link Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are alternative resolution protocols used to derive a machine’s IP address given its hostname on the network.

LLMNR, which is based upon the DNS format, enables name resolution on link local scenarios and has been around since the dawn of Windows Vista. It is the spiritual successor to NBT-NS, which uses a system’s NetBIOS name to identity it on the network.

In general, name resolution (NR) protocols stand as the final fallback should suitable records not be found in local host files, DNS caches, or the configured DNS servers. One can think of the purpose of NR protocols as allowing a host to broadly query its neighbors over multicast: “Hey, does anyone have x resource, as I can’t find it anywhere else?”

These broadcasts are sent out to the entire intranet; however, no measures are taken to verify the integrity of the response of addresses and the address providers on the network, since Microsoft views the network as a trust boundary; as such, malicious actors can take advantage of essentially a race-condition and interpose themselves as an authoritative source for name resolution by replying to LLMNR (UDP 5355)/NBT-NS (UDP 137) requests with popular opensource offensive tooling such as Responder. Crucially, if the requested resource requires authentication, the victim’s username and NetNTLM hash are summarily sent to the adversary’s spoofed authoritative node.

Mistyping, misconfigurations (either on the DNS server or client side), WPAD, or even Google Chrome can easily lead to a scenario in which the client machine relies on multicast name resolution queries and gifts a malicious man-in-the-middle its coveted hash.

In this demonstration, the attacker sets up Responder listening on eth0 and with the -wF flags to start the WPAD rogue proxy server and force NTLM authentication on wpad.dat file retrieval:

Shortly thereafter, the victim (on client01 at 192.168.136.133) requests a shared resource via SMB with an unfortunate misspelling:

As demonstrated below, the attacker then responds to the name resolution query initiated by the victim via LLMNR, naming himself as the recipient and receiving the victim’s credentials in return:

From here, the user’s hash can either be cracked offline using a hash cracker like Hashcat or possibly relayed further in the environment to authenticate to other network resources via relay attacks, should mitigations such as SMB signing be disabled.

Mitigations:

1. Open the Group Policy Editor and navigate to Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client
2. Ensure that the option “Turn OFF Multicast Name Resolution” is enabled.
3. To disable NBT-NS on Windows clients:
4. Open your Network Connections and view the properties of the network adapter.
5. Select TCP//IPv4 and select “Properties.”
6. Select “Advanced” on the “General” tab and navigate to the WINS tab, then choose “Disable NetBIOS over TCP/IP.”

Scenario 2 – NetNTLM Relay over SMB

Continuing our exploitation of the potential consequences of LLMNR and NBT-NS broadcast traffic being present in the target environment, let’s turn our attention to relaying the NetNTLM hashes previously captured by Responder and see if more damage can be done.

Much like wine and cheese, Responder and Ntlmrelayx from the Impacket suite are the perennial pairing here. The idea is that an attacker can opt to relay captured NetNTLM hash to any systems on the network that have SMB signing turned off, which is the default setting on Windows clients.

After configuring Responder with its SMB and HTTP server deactivated (which can typically be done by editing /etc/responder/Responder.conf) and running the module via CLI as before (responder -I eth0 -wF), the attacker can then set up ntlmrelayx to listen for incoming connections with smb2 support enabled:

In this simulated scenario, an administrator on DC01 (192.168.136.132) mistypes a network share, which leads to a successful relay of the NetNTLM hash to client01 (192.168.136.133) and the dumping of the SAM, or the Security Account Manager, which is a database present on Windows machines that stores local user accounts and authentication information:

Do be advised that from MS08-068 and onwards, it is impossible to relay the same NetNTLM hash to the originating machine from which it was issued; as such, in order for this attacker to work, it is necessary to relay the hash originating from DC01 to client01.

Apart from dumping the computer’s SAM, which is disastrous in and of itself, an attacker could also elect to execute arbitrary commands on the target system or even spawn an SMB session on the host, which is what shall be demonstrated next. Upon successful relay of the administrator hash to client01, a malicious actor is presented with an interactive SMB client shell on 127.0.0.1:1000 after specifying the -i flag when deploying ntlmrelayx:

From here, the attacker has full access to the C$ drive and can amplify their foothold on the network by deploying a remote access trojan (RAT) or even proliferating ransomware through the network’s file system:

Mitigations:

1. The steadfast advice from Microsoft when it comes to any variant of the classic NTLM relay attack is to migrate from the natively vulnerable NTLM challenge-response authentication to the far more secure method of Kerberos authentication when possible. Kerberos has been Microsoft’s preferred replacement for NTLM since the inception of Windows 2000.
2. For those organizations that must use NTLM in their environments, it is recommended that EPA (Extended Protection for Authentication) and SMB signing are enabled, which in conjunction can vastly blunt the possibility of NTLM relay attacks.

Scenario 3 – IPv6 Carnage

Another common man-in-the-middle privilege escalation vector that poses risk an enterprise domain context stems from the abuse of IPv6, which is enabled by default on modern Windows operating systems and takes precedence over its predecessor IPv4 since the release of Vista. As such, systems internally poll the network for IPv6 leases, which plays into an attack vector still ripe with potential in 2022. For a step-by-step breakdown of how this all works:

1. An IPv6 client periodically sends out solicit packets on the local network, seeking an IPv6 router.
2. When an IPv6 router is present, it sends out an advertise packet in response to the solicit packet. This advertise packet informs the client that the IPv6 router is available for DHCP services.
3. The IPv6 client replies with a request packet to the DHCPv6 server, asking for an IPv6 configuration.
4. Finally, the DHCPv6 server issues the IPv6 configuration to the IPv6 client, which specifies several things, including the IP address, default gateway, DNS servers, etc. This is all included in the reply packet.

The idea with this attack, which utilizes Dirk-jan Mollema’s excellent research from 2018, is that a malicious actor can interpose their machine as an IPv6 router and force authentication to their server as the authoritative DNS server on the network over any other IPv4 servers. The attacker can then in tandem utilize ntlmrelayx to relay captured credentials to the specified target machine, leading to dumping of sensitive domain information or possibly even the addition of additional computer accounts or escalated privileges.

To set up this scenario, mitm6 is launched listening on eth0 and targeting the lab.local domain along with the machine client01:

Shortly thereafter, the preferred IPv6 DNS server is displayed from the perspective of the command prompt of our client01 victim as being the attacker’s machine, where 192.168.136.132 is the IPv4 address of the lab.local domain controller:

From here, ntlmrelayx is launched targeting the relay to the domain controller with the following command, with the -6 flag ensuring that our ntlmrelayx listens for both IPv4 and IPv6 connections and the -wh flag specifying a non-existent WPAD file host:

ntlmrelayx.py -6 -t ldap://192.168.136.132 wh netti-wpad.lab.local -l loot

After simulating the client machine rebooting and joining the network, it is observed that the attack successfully relays the client01 machine account against the DC:

This enables the attacker to gather and enumerate valuable information against the target domain environment, including group memberships, domain policies, and sensitive information disclosed in any AD object’s description fields, as demonstrated below:

It should be remarked that, while the scenario of the service account password being exposed in cleartext in the AD object’s description field is contrived for this example, it is unfortunately a practice that is still observed in modern-day engagements.

Now, while the aforementioned information dump about the targeted AD objects is certainly valuable, things can take a decisive turn for the worst should an attacker set up the ntlmrelay over LDAPS. Relaying to LDAP over TLS offers an opportunity for quick compromise of an entire domain, as creating new accounts is not possible over unencrypted connections. Specifying the --delegate-access flag on ntlmrelayx and waiting for the victim to request an IPv6 address or a WPAD configuration leads to the following series of events in the attacker’s console:

Once the victim requests a new IPv6 address or WPAD configuration from the mitm6 server (this is often seen when the victim reboots their machine or plugs in their network cable again), the ntlmrelayx server receives the connection and creates a new computer account over LDAPS, which is permitted by the default AD setting which dictates that any domain user can add up to 10 computer accounts:

From here, the malicious actor can utilize getST.py from the impacket suite to take advantage of a classic resource-based constrained delegation attack vector in order to have the new computer account request service tickets for itself on behalf of any other user in the domain, including the administrator. The typical flow of this attack finishes with requesting a TGS for the CIFS service of the target computer impersonating the domain administrator and dumping the SAM with impacket’s secretdump.py module, as previously demonstrated. In case the reader needs a refresher on the meaning of terms like TGS or a primer on Kerberos-based attacks, please consult this excellent resource as additional reading.

Should a user with functional permissions of domain admin log into one of the workstations in scope of the mitm6 attack, ntlmrelayx can be further weaponized to create a new enterprise administrator user; below, the domain administrator “henry” logs into the target machine, after which the authentication is relayed against the domain controller of the target environment:

Further in the output below, ntlmrelayx adds a new user with Replication-Get-Changes-All privileges:

At this point, it is game over for the domain’s integrity. An attacker can achieve complete domain compromise by dumping all domain user hashes from the Ntds.dit file, which is essentially the database at the heart of active directory:

Now that the wide-ranging ramifications of a simple IPv6 network configuration being left in its default state have been fully explored, let’s turn to discussing mitigating the factors that make this attack chain possible. Owing to the fact that there were several components abused along the way, there are several mitigation aspects to address.

Mitigations:

In summary, the mitm6 tool abuses the fact that Windows by default queries for an IPv6 address even in IPv4-only environments. If IPv6 is not internally in use, the surest way to prevent mitm6 attacks is to block DHCPv6 traffic and incoming router advertisements in Windows Firewall via Group Policy. However, entirely disabling IPv6 entirely may have unwanted side effects. As outlined in the linked article source below verbatim, setting the following predefined rules to Block instead of Allow prevents the attack from working:

• (Inbound) Core Networking – Dynamic Host Configuration Protocol for IPv6(DHCPV6-In)
• (Inbound) Core Networking – Router Advertisement (ICMPv6-In)
• (Outbound) Core Networking – Dynamic Host Configuration Protocol for IPv6(DHCPV6-Out)

Mitigating WPAD abuse:

If WPAD is not in use internally, disable it via Group Policy and by disabling the WinHttpAutoProxySvc service.

Mitigating relaying to LDAP:

Relaying to LDAP and LDAPS can only be mitigated by enabling both LDAP signing and LDAP channel binding.

Mitigating resource-based delegation abuse:

As RBCD is a part and parcel of intended Kerberos functionality, there is no one-click mitigation here. Most of the attack surface can however be reduced by adding administrative and key users to the Protected Users group or by marking the account as sensitive and ineligible for delegation.

Scenario 4 – Nothing but Certified Trouble

In the summer of 2021, SpecterOps researchers Will Schroeder and Lee Christensen published a deluge of information on the attack potential in inherently insecure Active Directory Certificate Services (hereafter ADCS, essentially Microsoft’s PKI implementation). While a full discussion of the eight attack mappings (ESC1 through ESC8) is outside of the scope of this blog post, it is worthwhile to explore ESC8 further as it stands as an excellent recent example of the continued potential for domain compromise that NTLM relay poses.

Essentially, this vulnerability arises from the fact that the web interface of the ADCS allows NTLM authentication by default and does not enforce relay mitigations by default. If the certificate authority in the domain does indeed have the web enrolment feature enabled (which is exposed typically via http://<CA_SERVER/certsrv/ upon the Certificate Authority Web Enrolment role being installed on the server), then the attacker can carry out an NTLM relay to the HTTP endpoint. Per the linked SpecterOps resource:

“This attack, like all NTLM relay attacks, requires a victim account to authenticate to an attacker-controlled machine. An attacker can coerce authentication by many means, but a simple technique is to coerce a machine account to authenticate to the attacker’s host using the MS-RPRN RpcRemoteFindFirstPrinterChangeNotification(Ex) methods using a tool like SpoolSample or Petitpotam. The attacker can then use NTLM relay to impersonate the machine account and request a client authentication certificate (e.g., the default Machine/Computer template) as the victim machine account. If the victim machine account can perform privileged actions such as domain replication (e.g., domain controllers or Exchange servers), the attacker could use this certificate to compromise the domain. Otherwise, the attacker could logon as the victim machine account and use S4U2Self as previously described to access the victim machine’s host OS.”

With the theory out of the way, let’s see this attack in action. First, from their initial foothold on the client01 machine as a low-privileged user, the attacker can utilize the living-off-the-land binaries, like certutil.exe, to enumerate certificate authorities in the domain:

From here, the attacker can set up ntlmrelayx to forward incoming forced authentications from DC01 to the HTTP endpoint for certificate enrolment; note that ExAdndroidDev’s fork of Impacket with support for ADCS exploitation was utilized for this demonstration:

As the final step in the attack chain, the PowerShell implementation of PetitPotam is leveraged in order to coerce an authentication from DC01 to our relay server:

At this point, the CA issues a certificate for the DC01$ computer account, which is captured by the ntlmrelayx server:

Now that the hard work is done, from here, with the base64 certificate of the domain controller computer account in hand, the attacker can use Rubeus to request a Kerberos TGT for the DC01$ computer account and can now perform a DCSync to request the NTLM hash of the krbtgt user to achieve complete domain compromise and persistence.

Mitigations:

1. Prior to releasing the offensive tooling for ADCS exploitation, SpecterOps released the PSPKIAudit auditing toolkit to enable defenders to proactively monitor their environments for potential ADCS misconfigurations. Please do recall that there are seven other scenarios for ADCS abuse which are outlined in the original SpecterOps whitepaper and not discussed in this blog post, so concerned blue team individuals are encouraged to read more here.
2. Alongside reviewing the aforementioned resources, it is highly recommended that defenders enumerate the Web Enrolment interfaces in their environment (either with or without PSPKIAudit) and either enforce HTTPS and enable EPA on the IIS server endpoints or remove the endpoints if possible altogether.
3. If not already doing so, defenders are encouraged to treat CA servers as tier 0 assets along with domain controllers from an asset management standpoint.

Conclusion

Owing to the fact that an attacker would need to have successfully leveraged another server-side vulnerability or a social-engineering attack to be in the position to relay credentials as a man-in-the-middle, hardening domain authentication and superfluous network broadcast traffic stands as an important component of Defence in Depth (DiD). While Microsoft may have worked to address the impact of some of these relay issues at different levels, it is nonetheless paramount that network administrators and defenders do their part to blunt the force of these vectors to potential domain takeover by following the mitigation advice on the subject. As there is no silver bullet to pre-emptively thwart every network attack primitive, the remedial guidance contained in this article can be followed as part of the multifaceted approach of DiD to secure the digital estate from domain compromise. Nettitude’s specialized internal infrastructure penetration testing services can also provide network stakeholders with world-class technical knowledge and tailored advice on remediating the issues explored here and beyond.