This is the latest in our “QOMPLX Knowledge” series. These posts are intended to provide basic information and insights about the attack activity and trends that are driving malicious campaigns and that QOMPLX researchers encounter in our forensic work with customers.
Each security incident and data breach is unique—a singular combination of vulnerable and misconfigured systems, compromised assets, attacker motivations and chance. But when you talk with security experts about the “whys” of security incidents these days, a familiar acronym pops up: NTLM. That stands for NT LAN Manager, a security protocol that is in its third decade of existence and that has worked its way deep into enterprise networks. The persistence of NTLM and the difficulty organizations have had jettisoning it has contributed to a long-running trend of data breaches as attackers leverage targeted- as well as trivial and automated attacks to put critical systems at risk.
Despite its many security weaknesses, NTLM is still supported by many legacy systems and applications. More than 20 years after the introduction of NTLM's "replacement" (Kerberos), backwards compatibility with the legacy Windows systems and applications has kept NTLM in the fold, adding complexity and weakness to Active Directory implementations in particular.
One of the biggest sources of compromises are so-called NTLM “replay” attacks in which an attacker positions themselves between clients and servers that are doing NTLM authentication, capturing credentials and facilitating lateral movement by replaying legitimate credentials on other servers.
- NTLM relay attacks allow attackers to sit between clients and servers and relay validated authentication requests in order to access network services
- Unlike NTLM, a challenge-response protocol, Kerberos’ mutual authentication is considered more secure and has been the de facto standard in Windows since Windows 2000
- Microsoft recommends a number of mitigations for NTLM relay attacks, including SMB and LDAP signing, and EPA,
- The best fix for NTLM insecurity is to stop using NTLM within an organization and for NTLM to be deprecated
What is NTLM?
NTLM is a Microsoft proprietary authentication protocol and it was standard in early Windows server systems through Windows 2000, when Kerberos became its de facto successor and is still the standard for authentication in Windows systems.
First introduced in the 1990s, NTLM replaced Microsoft’s older LAN Manager (LANMAN). NTLM is a challenge-response authentication protocol which uses a series of three messages to authenticate a client. The NTLM protocol uses the RC4 algorithm for encryption. It uses one or both of two un-salted hashed password values which are stored on the client and the server (or domain controller). NTLM uses two hashing algorithms: the LM Hash (a DES-based function applied to the first 14 chars of the password converted to the traditional 8 bit PC charset for the language) and the NT Hash (an MD4 of the little endian UTF-16 Unicode password). Both hash values are 16 bytes (128 bits) each.
NTLM is vulnerable for a number of reasons. First and foremost, because it does not support modern cryptographic methods such as AES or SHA-256. That makes it vulnerable to offline cracking attacks using tools such as HashCat. Also, NTLM’s hash values can be matched up with alphanumeric passwords using so-called “rainbow tables” of passwords and hashes compiled from previous data leaks. Particularities about how NTLM creates password hashes combined with the use of rainbow tables and distributed computing systems mean that NTLM hashes for passwords of any length can be cracked in minutes to hours - and at little cost to attackers.
Even without a rainbow table, hashes can be used in lieu of actual alphanumeric passwords as part of so-called “Pass the Hash” attacks. In other words: attackers who steal NTLM password hashes can authenticate to network resources without knowing the actual password from which the hash was created. Microsoft and other tech giants long ago mandated that vendors and IT organizations deprecate RC4, SHA-1, and other weak algorithms. Despite this, NTLM is still used for local authentication on Windows systems and storage of Windows passwords on Active Directory Domain Controllers.
What are NTLM Relay Attacks?
In NTLM, a challenge-response protocol is used for authentication. For any authentication request:
- NTLM establishes a three-way handshake during client-server authentication with the client establishing a path to the server and negotiating authentication.
- The server responds to the client’s negotiation message with a challenge, asking the client to encrypt a sequence of characters using a secret it possesses: a hash of its password.
- The client sends a response to the server, which contacts a domain authentication service hosted on a domain controller to verify the response.
In a NTLM relay attack, an attacker establishes a position between the client and server on the network and intercepts authentication traffic. Client authentication requests are forwarded to the server by the attacker, similarly challenges are relayed to the client and valid authentication responses to the challenge from the client are sent back to the server, allowing the attacker—rather than the client—to authenticate using the client’s credentials.
In relay attacks, the client believes it is negotiating with the target server it wants to authenticate to. The server, meanwhile, believes that the attacker is a legitimate client attempting to authenticate.
This risk of relay attacks was amplified in October 2019, when Microsoft patched two critical vulnerabilities in all versions of NTLM. Successful exploits could allow an attacker to remotely run code on a Windows machine, or move laterally on the network to critical systems such as servers hosting domain controllers. One vulnerability allows attackers to bypass Message Integrity Code (MIC), a protection implemented by Microsoft that ensures messages sent over a network have not been tampered with.
The bypass can be used in NTLM relay attacks to fool servers into not enforcing signing during authentication negotiations. The second flaw also allows for bypasses of MIC and can be abused during NTLM relay attacks to authenticate to Active Directory Federation Services and potentially access user credentials.
Mitigations and Protections From NTLM Relay Attacks
There are a number of work arounds and changes that can remove the risk of NTLM relay attacks.
The biggest step organizations can take to eliminate the threat of NTLM relay attacks is to stop using NTLM. Kerberos, a byproduct of MIT’s Project Athena, has been Microsoft’s preferred replacement for NTLM since the release of the Windows 2000 platform. In contrast to NTLM, Kerberos uses mutual authentication between the client and server rather than NTLM’s challenge-response. Clients must be part of a domain and have access to a domain controller in order to attempt authentication. With NTLM, clients contact the server, which then contacts the domain controller.
Using Kerberos, client authentication begins with communication to an authentication server which then contacts a Kerberos key distribution center that issues a ticket granting ticket (TGT) encrypted with the ticket granting service’s secret. As the client needs access to network services and resources, the TGT is passed along and a request is made to access the service. Once the TGT is verified, session tickets are issued to the client, which now has access to the service.
Kerberos has been a fixture in Windows Server for two decades and is more secure than NTLM, which suffers from a number of native vulnerabilities, including a lack of server authentication and weak cryptography, in addition to slower performance compared to Kerberos.
Patch & Update Configurations to Mitigate Relay Attacks
Microsoft recommends running all systems at current patch levels and that organizations ensure that a number of specific configurations are secure, including:
- Turning on SMB signings to blunt NTLM relay attacks
- Enforcing LDAP signing and LDAPS channel binding on domain controllers
- Enabling Enhanced Protection for Authentication to mitigate NTLM relay attacks on ADFS and web servers
- Configure ADFS and web servers to accept only requests where EPA is turned on
Instrument and Validate Kerberos and Active Directory
Technologies such as Kerberos need to be fully instrumented and monitored to prevent a wide range of other popular attacks including Golden- and Silver Ticket attacks. QOMPLX’s Q:Cyber Identity Assurance can help organizations do just that. It maintains a real-time stateful ledger of all appropriately issued and valid Kerberos tickets and observes Kerberos interactions across clients (principals), domain controllers (key distribution centers) and Kerberized services.
Finally, as Active Directory attacks become more common external validation of the Kerberos protocol becomes essential to assure IT teams that every ticket presented by a Kerberos service client was in fact issued by a legitimate key distribution center. QOMPLX’s technology can verify, in near real-time, that a given Kerberos authentication event was correctly generated and that it is linked to legitimate user interactions and the issuing domain controller. This type of deterministic verification makes it difficult for attackers to abuse authentication protocols and processes.
Here are the previous entries in our QOMPLX Knowledge series; look for more in our QOMPLX Knowledge series in the days and weeks ahead:
QOMPLX Knowledge: Fundamentals of Active Directory Trust Relationships