NTLM vs Kerberos: Understanding Authentication in Windows/Active Directory

Authentication plays a critical role in the security of any system as it prevents unauthorized access & misuse of resources, it is especially important in Pentesting. In Windows/Active Directory, several authentication methods are available, each with its strengths and weaknesses.

In this blog post, we will go through the two most commonly used authentication protocols — NTLM and Kerberos.

This blog covers the workings and limitations of authentication protocols. The exploitations of these protocols using various methods will be covered in future blogs —

NTLM Authentication

NTLM (New Technology LAN Manager) is an authentication protocol that was introduced in Windows NT 4.0 and has been supported in all subsequent versions of Windows. Although it was the default protocol used in older Windows versions, it continues to be used today as a fallback option in case Kerberos fails for any reason.

NTLM uses a challenge/response mechanism to authenticate users, ensuring that the user’s password is never sent across the network in plaintext. Instead, the password is hashed, used in the network for authentication.

NTLM was developed as a successor to an even older protocol- LM, used in Microsoft’s LAN Manager product in the late 1980s. LM was discontinued because it had several security weaknesses that made it vulnerable to various attacks.

How Does NTLM Authentication Works?

Here is the simplified version of how NTLM Auth works when Nick tries to login from one of the clients in an AD environment —

Working of NTLM Authentication

1. Nick enters his username and password on any client machine connected to Domain Controller (DC).
2. Nick’s client creates a hash of his password.
3. Nick’s client sends a logon request to the domain controller (DC) with his username.
4. The DC sends a random number (logon challenge) to Nick’s client.
5. Nick’s client encrypts the logon challenge using the hash of his password and sends it back as a response.
6. The DC uses the hash of Nick’s password to encrypt the logon challenge and compares it with Nick’s client’s response.
7. Nick is authenticated and granted access if the encrypted logon challenge and the response match.

Limitations with NTLM:

Though NTLM is simple and easy to configure but there are some limitations, including weaker security & vulnerable to specific attacks —

• NTLM had v1 and later, v2 was introduced with improved security but they are still considered weak because they rely on hashing-based authentication. In contrast, Kerberos uses more secure symmetric-key cryptography.
• NTLM lacks Single Sign-On (SSO) support, meaning users must repeatedly authenticate themselves to access different resources. Additionally, it does not support Multifactor Authentication (MFA).
• The passwords are stored in hashes and are critical element of authentication. However, if these hashes are leaked, several attacks are possible. Brute force or Pass-the-Hash (PTH), DCSync, LLMNR poisoning, and other relay attacks are some examples —

1. On the client machine, these password hashes are stored in the SYSTEM and SAM files, which anyone with administrator-level privileges can access. Additionally, these hashes are cached in the memory by default, and tools like Mimikatz can be used to extract them.
2. On the server side, the NTLM password hashes are stored in the NTDS.dit file on the Domain Controller. Attackers can use techniques like DCSync & Relay Attacks to extract the password hash.

Then why NTLM still being used?

Microsoft replaced NTLM with Kerberos as the default authentication protocol wayback in Windows 2000 but NTLM is still being used due to the following reasons —

1. Maintaining compatibility with older systems and servers.
2. Enabling logon authentication on stand-alone systems not part of Active Directory or local logon authentication on non-domain controllers.
3. NTLM authentication is still supported and must be used for Windows authentication with systems configured as a member of a workgroup.
4. In modern systems, the client will fall back to NTLM if Kerberos authentication fails.

Kerberos Authentication

As we have seen the NTLM authentication and its limitations, later Kerberos was introduced as Microsoft’s default authentication method since Windows Server 2000.
Kerberos is an authentication protocol designed to provide strong authentication for client/server applications using secret-key cryptography. It allows network users to prove their identity to a server without sending passwords over the network. It also provides mutual authentication — a mechanism for detecting tampering with data during transmission.

How Does Kerberos Authentication Works?

Before going into the Kerberos mechanism, we need to understand the following terms —

• KDC(Key Distribution Center): Server that stores user accounts & their auth information, such as passwords & keys.
• AS(Authentication Server): Part of the KDC that verifies the identity of a user requesting access to a service.
• TGT(Ticket Granting Ticket): A ticket issued by the AS to a user after successful authentication.
• TGS(Ticket Granting Server): Part of the KDC that issues a service ticket to a user after verifying the TGT.

Now to understand Kerberos Authentication, let’s suppose a user, Nick wants to connect to a SQL Server (any service present in AD) using Kerberos Authentication —

Working of Kerberos Authentication

1. Nick logs in to his computer and sends a request for a TGT to the AS. The request includes Nick’s user ID, the ID of the requested service TGT, the IP address of his computer, and the lifetime of TGT.
2. The AS checks if Nick exists in the KDC database. If he does, it generates a session key to be used between Nick and TGS. The AS sends two messages back to Nick: one encrypted with TGS secret key and one encrypted with Nick’s secret key (a hash of his username & password).
3. Nick decrypts the messages and logs in, caching TGT locally. When he wants to access a network resource (in this case, the SQL server), Nick sends a request to TGS with the resource name he wants to access, his user ID & timestamp, and the cached TGT.
4. The TGS decrypts Nick’s information and provides a service ticket and a service session key for accessing the SQL server. The TGS encrypts the ticket with the SQL server’s secret key and sends it back to Nick.
5. Nick sends a request to the SQL server, encrypted with the service ticket and the session key.
6. The SQL server decrypts the request and, if it’s valid, provides Nick with access to the SQL server.

Limitations with Kerberos:

Though Kerberos is definitely a better alternative to NTLM auth as it is much more secure, faster but there are some limitations as well:

1. Single point of failure: The KDC is a single point of failure for the entire system. If it becomes unavailable, no user can be authenticated.
2. Requires Time Synchronization: Kerberos relies on accurate time synchronization between servers for authentication to occur, which can be a challenge in large, distributed environments.
3. Kerberosting: When the attacker gains access to the Kerberos database, can extract user credentials, including password hashes, and cracks them offline.
4. Golden/Silver Tickets: When the attacker gains access to the KDC, creates a forged TGT to access any service in the domain without being detected.
5. Kerberos delegation: It enables users to delegate their credentials to a service, allowing the service to access other resources on their behalf. However, if not correctly configured, this feature can be exploited by attackers to gain unauthorized access to other network resources.

Now we have seen the difference between NTLM and Kerberos, but how do we find out which auth mechanism is being used in any environment? A straightforward method is to check the domain functional level; if it’s set to Windows 2000 or higher, then Kerberos is the default authentication protocol. Alternatively, you can dive deeper by analyzing event logs, utilizing network analysis tools like Wireshark or various PowerShell modules.

As we conclude this blog, we have seen the most common authentication mechanisms, their working through simple examples and highlighting some of the vulnerabilities associated with them. Stay tuned for more upcoming blogs where we’ll explore these vulnerabilities in greater detail. Till then, stay secure and peace out!!

References:

• A deep dive into Kerberos Authentication: Video
• NTLM authentication: What it is and why you should avoid using it.
• Kerberos authentication: How it works — and how to maximize its security.
• NTLM vs Kerberos