Please Sign Here - Why NTLM Relaying Is Still a Risk in 2021

Philip Woolford
June 14, 2021

The Windows Name Resolution Flow

You may be under the impression that turning host names into IP addresses is simple.

You check: 

  • The Hosts file; then 
  • Your system’s DNS (Domain Name System) resolver 

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: 

Figure 1 - Windows host name resolution flow

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.” 

Why Windows Finds Services Via Broadcast 

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. 

Net-NTLMv2 Authentication 

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: 

Diagram

Description automatically generated
Figure 2 - NTLM authentication flow

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. 

Relaying Credentials (aka. Pass the Hash) 

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: 

Timeline

Description automatically generated
Figure 3 - Intercepted NTLM authentication 

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. 

How to Get More Requests with IPv6 

OK, so we turn of broadcast name resolution. With that, we’re safe from rogue nameservers on our local network! 

A collage of a person

Description automatically generated with low confidence
Figure 4 - Narrator: it was not 

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. 

Graphical user interface, table

Description automatically generated with medium confidence
Figure 5 - Windows client DHCPv6 solicitation

 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. 

Text

Description automatically generated with low confidence
Figure 6 - Windows client with malicious IPv6 default route

Preventing Credential Relaying 

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.  

Why Server-Side Signing Enforcement Is Not Enough 

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. 

Conclusion 

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: 

  1. Network security: LDAP client signing requirements – Require Signing (Require signing for LDAP clients) 
  1. Network security: LDAP server signing requirements – Require Signing (Require signing for LDAP servers) 
  1. Domain controller: LDAP server channel binding token requirements – Always (Prevent cross-protocol NTLMv2 relaying) 
  1. Microsoft network client: Digitally sign communications (always) – Enabled (Require signing for SMB clients) 
  1. Microsoft network server: Digitally sign communications (always) – Enabled (Require signing for SMB servers) 
  1. Turn off smart multi-homed name resolution – Enabled (Disable LLMNR) 
  1. Turn off multicast name resolution – Enabled (Disable mDNS) 

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} 

Postscript

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 

Share this article

Recent Post

Detecting and defending against advanced persistent threats utilizing the latest in industry-leading tools and techniques to strengthen and mature the security posture.

CONTI Group - The not so advanced APT

Recently in the news it was revealed that a member of an “APT” group that utilises the “Conti” ransomware became disgruntled at the state of their relationship with the group and leaked a large majority of the groups “Tools, Techniques and Procedures” documents. Conti was first discovered in 2020 and is used primarily by the […]

Read More

Hidden Cobra - Uncovering the North Korean APT

Advanced persistent threats come in many forms ranging from your crime groups, activists all the way through to your state sponsored groups. While some of these threat actors such as crime groups are seen on a regular (if not daily..) basis, state sponsored attacks are less common and more sophisticated. While most state sponsored groups […]

Read More

Please Sign Here - Why NTLM Relaying Is Still a Risk in 2021

The Windows Name Resolution Flow You may be under the impression that turning host names into IP addresses is simple. You check:  The Hosts file; then  Your system’s DNS (Domain Name System) resolver  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 […]

Read More

The benefits of Red Teaming

Red teaming is not a new concept within the cyber security community. However in Australia, Red Teaming is a relatively new term for most organisations. In this blog post we'll take a dive into: What differentiates a Red Team engagement from a Penetration Test. Why you shouldn't consider a red team engagement (You totally should.) […]

Read More

Stealing Password Reset Tokens for Fun and Profit

When adding a “Password Reset” function to your application it is especially important to ensure this has the same security considerations as any other critical function within the application. Due to the nature of resetting a user’s password, along with many security considerations being overlooked, it is not uncommon for attackers to spend extra time […]

Read More

MITRE ATT&CK Framework Primer

The MITRE ATT&CK framework is an incredibly powerful framework that organisations can utilise to improve their cyber security capabilities.

Read More