NTLM is one of the most iconic and common attacks on Active Directory environments. In this attack, the attacker (Relayer) captures an authentication and pass it to their desired server. This allows them to use the authenticated user's privileges to perform malicious operations to the attacked server. New vulnerabilities that expose the network to NTLM Relay are constantly being discovered. The vulnerability presented in this article is especially dangerous, as any server that configured to use NTLMv1 authentication is expose to it.
NTLMv1 mechanism:
The NTLMv1 protocol uses a TNHash or KM hash (depending on configuration), in a challenge/response method between the server and the client. NTLM authentication flow:
- The user machine sends a request to connect to the server.
- The server generates a random nonce to be encrypted by the user.
- The user machine encrypts the nonce with the password hash to prove knowledge of the password.
- The server validates the users' identity by ensuring that the challenge was indeed created by the correct user password. It does it either by using data in its own SAM database or by forwarding challenge-response pairs for validation in the domain controller.
NTLM Server Signing:
Server Signing is one of the most important and useful ways to mitigate NTLM Relay attack. In this method, the session is signed with a key only knows to the original client and the targeted server, after the authentication is completed. This sign blocks the attacker, as he has no way to retrieve the session key, and as a result, his attack will fail.
NTLM & NETLOGON process:
NTLM uses a challenge and response method for authentication. When a user authenticates to a remote machine, the targeted machine provides a challenge to user with the NTLM_CHALLENGE request. The user then encrypts the challenge using the cryptographic hash of his password- the NT HASH. He then sends it back to the machine using an NTLM_AUTHENTICATION message. The server needs to validate the user’s credentials with the domain controller, as it doesn't store users’ passwords. The NETLOGON is responsible for that.
The server sends and NETLOGON request to the domain controller (over an encrypted channel). A part of this message is the NTLM_AUTHENTICATION that was originally sent by the user. The domain controller validates the NTLM challenge & response, thereby validates the user. he then sends a response that indicates whether the authentication was successful or not. In addition, the domain controller attaches a session key which would be used to sign the communication if session signing was negotiated. The session key is based on the user's password, he can calculate it independently.
The vulnerability (CVE-2019-2019):
The Preempt (now known as Crowdstrike) research team had discovered the following thing: as part of the described process and security measures of the domain controller, domain controllers deny requests if the expected computer name is different than the name established the secure channel. But the domain controller will accept the request if the computer name field is empty.
This field is simply copied from the NTLM_CHALLENGE message that was sent by the target server. Since in NTLM Relay attacks the attacker functions as the targeted server from the view of the user, the attacker can simply remove this field from the NTLM_CHALLENGE message.
The MIC (which is responsible to verify that the NTLM messages weren't modified during transit) is not an issue in this case, as it is calculated using the session key. Since the attacker has the ability to retrieve the session key, he can also calculate the MIC using the session key and the NTLM_CHALLENGE message.
After he recalculates the MIC in the NTLM_AUTHENTICATED request, the attacker sends the message to the targeted server. The targeted server verifies the MIC and forwards the NTLM_AUTHENTICATION message to the domain controller using the NETLOGON request. The domain controller approves the authentication, attaching the same session key that was sent to the attacker and this allows the attacker to establish a signed session to the targeted server.
why NTLMv1 will always be vulnerable:
Microsoft has released a fix for this issue, but it is not relevant for NTLMv1. NTLMv1 doesn't contain a Target Info field, so there is no way to verify that the server connecting to the domain controller is the actual target of the NTLM authentication. So basically, every NTLMv1 authentication attempt is vulnerable to this attack.
Hence, the obvious mitigation, in this case, is to allow only NTLMv2 authentication. The following video demonstrates how to restricting NTLM by auditing NTLM incoming traffic:
How CalCom can help:
As NTLM is a legacy protocol, it is very hard to disable it without causing damage to production. The challenge starts first with determining which machine needs this protocol for its function and which doesn't. After mapping the usage, it is hard to determine how to move from NTLM usage to a more secure authentication protocol.
CalCom's hardening automation solution (CHS) will provide you all the answers in one product. CHS will learn your system and will determine exactly which server can continue working without outages after disabling NTLM. It will alert about the potential impact when disabling the protocol. After you'll decide what is your course of action according to the information produced by CHS, CHS will automatically implement your choice on the entire production environment, significantly reducing the potential for configuration drift.
