You may be under the impression that turning host names into IP addresses is simple.
You check:
That’s it right? If you don’t get a response from your local file or DNS, then the system doesn’t exist. Well, no; the name resolution flow in Windows looks something like this:
Well, that’s a bit more complicated, isn’t it? And a bit hard to read – feel free to take a minute to look at it zoomed in.
Now I can hear you thinking “WINS? LM Hosts? LLMNR? I don’t remember turning those on. What even are they?”. The more technical people may even be saying “What? We have a domain; we won’t use anything like WINS or NetBIOS. They’re for workgroups.”
Unfortunately, these are all legacy settings that are enabled by default to meet Microsoft’s ever-present backwards-compatible philosophy. You don’t get big in enterprise if your new OS breaks all your old apps and services.
Have you been in the “Network” tab in explorer and wondered how all those laptops and meeting room TVs got there? Has your internet gone out at home and your router redirects you to a webpage to let you know what’s happening? These are all work via broadcast name resolution methods.
This is especially important for small to medium-sized businesses which might not have an internal domain. How does a new laptop find “WD Cloud Drive” or “BOB-PC” with no Active Directory DNS service to find the file shares?
The same applies to other services as well: WPAD requests are sent out to decide how to proxy web requests in environments that don’t set proxies via DHCP or Group Policy.
Even back in the Windows NT days, Microsoft knew that that NTLMv1 (DES encryption based on your password hash) was not secure, so they needed a new network authentication mechanism. As such Net-NTLMv2 was introduced in Windows NT4 as part of the Security Support Provider framework.
It goes a little something like this:
Overall, this is a solid attempt as the user’s password or NT password hash is never sent over the network, but the domain controller can verify the authentication attempt from the NTLMv2 response, server nonce, and the user’s stored NT password hash.
Unfortunately, there is a little idiosyncrasy when using Net-NTLMv2 over SMB (network shares) or LDAP (directory services) - neither the client station nor the server is authenticated in this process, only the connection. This allows a MitM (Man in the Middle) attack to intercept authentication attempts to achieve an authenticated connection.
So, let's say we’re a threat actor on the network and we want to be in the middle of one of these connections. We know that Windows clients will sometimes broadcast name requests onto the network, so we just listen; mDNS, WINS, NetBIOS, LLMNR, all of them. Once we get a hit, we impersonate the service, and the connection now looks like this:
This is possible because, in the default configuration, this process does not authenticate either the server or client device - it will only authenticate the credentials sent during negotiation. Unless both the server and client specifically request/require message authentication and encryption (“Sign” and “Seal” in SMB parlance) then it will not occur. This leaves the attacker with a fully authenticated session that the server does not know has been intercepted.
OK, so we turn of broadcast name resolution. With that, we’re safe from rogue nameservers on our local network!
From Windows Vista and Windows Server 2008, the default configuration will configure IPV6 with DHCPv6 enabled. In keeping with IPv6’s living-network ethos, Windows will periodically send nameserver solicitations to IPv6 multicast addresses to discover new resolvers.
It’s important to note here that with malicious DHCP servers in IPv4 networks, you have to race the real DHCP server to respond to the client as the first answer will be used and any further responses will be ignored. But since IPv6 is designed for clients and routers to communicate and dynamically update network configurations – if we respond to these requests, our IPv6 address will be set as an additional DNS server or router. Windows also prefers IPv6 DNS servers before IPv4 DNS servers, allowing interception traffic from local devices.
As we see in Figure 3 above, a malicious user is able to forge an authenticated session by intercepting and redirecting the handshake to a controlled target. We were able to do this because there is no authenticity enforcement on the final connection.
The number one way to prevent credential relaying in an enterprise network is to enforce signing of SMB and LDAP traffic (we’ll ignore NTLM authentication over HTTP, transport security provides authenticity for HTTPS connections). When message signing is enforced, the client and server use an agreed session key to include cryptographic signatures for messages in the authenticated session. The session key is derived using the algorithm below:
sessionKey = HMAC-MD5(v2-Hash, HMAC-MD5(v2-Hash, NTLMv2 Response + Server Challenge))
This relies on the user’s password hash which the server doesn’t know, but since the server needs to validate the authentication, the Domain controller can calculate and return the session key in the authentication response.
By enforcing this signature, MitM attacks are no longer possible as an attacker cannot calculate the authentication code for messages.
A common policy in modern networks is to enforce signing on servers only, and this seems reasonable; since enforcement at either side is effectively enforcement at both sides, it should be fine to just set it on servers. Problems arise, however, when we have to deal with non-standard configurations – maybe you require support for an old building management system that doesn’t support authentication with signing… or an HVAC system… or access control.
If you have systems like this, supporting them means supporting insecure configurations in your environment. Part of remediating these issues can be segmentation and segregation of your environment, but systems are inherently meant to be accessed.
In these cases, the best way to prevent these attacks is to ensure that client systems are also enforcing secure configurations. Only systems that are explicitly required to having signing disabled should be allowed, to minimize the risk of exploitation.
In modern environments, it’s common to see that signing for SMB and LDAP have been enforced on Domain Controllers but with modern tooling that understands those limitations, attackers are still able to exploit this weakness to gain privileges in your environment. Through name resolution poisoning they can collect user password hashes. Through credential relaying, attackers can gain authenticated connections to network shares, extracting or deleting business data and even system backups.
Due to these risks, we recommend the following GPOs to minimize the risk and impact of credential relaying:
In addition, the following PowerShell command can be used to disable NetBIOS on Windows Endpoints:
Get-ChildItem "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces" | foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2}
In this post, we discussed the risks of not enforcing SMB/LDAP signing and described the process of Net-NTLMv2 authentication. We did not discuss NTLMv1, but the advice you will receive from all sources is clear: NTLMv1 is not safe, and it should be turned off. The network hash itself is salted, but the encryption algorithm is weak. The session key also leaks information as it is calculated without a hash as below:
sessionKey = MD4(NT password hash)
To prevent NTLMv1 use in your environment, the following GPO should be set:
Network security: LAN Manager authentication level - Send NTLMv2 responses only\refuse LM & NTLM
