Kerberos Tray

The Kerberos Tray tool lists all cached Kerberos tickets and allows you to view the tickets'
properties as well as to purge tickets. This information may help in resolving problems with
authentication and access to network resources.

What Is NTLM Used For?

Windows New Technology LAN Manager (NTLM) is a suite of security protocols
offered by Microsoft to authenticate users’ identity and protect the integrity and
confidentiality of their activity. At its core, NTLM is a single sign on (SSO) tool that
relies on a challenge-response protocol to confirm the user without requiring them
to submit a password.

Despite known vulnerabilities, NTLM remains widely deployed even on new systems
in order to maintain compatibility with legacy clients and servers. While NTLM is still
supported by Microsoft, it has been replaced by Kerberos as the default
authentication protocol in Windows 2000 and subsequent Active Directory (AD)
domains.

How Does the NTLM Protocol Work?

NTLM authenticates users through a challenge-response mechanism. This
process consists of three messages:
1. Negotiation message from the client
2. Challenge message from the server
3. Authentication message from the client

NTLM Authentication Process

NTLM authentication typically follows the following step-by-step process:

1. The user shares their username, password and domain name with the client.
2. The client develops a scrambled version of the password — or hash — and deletes the full password.
3. The client passes a plain text version of the username to the relevant server.
4. The server replies to the client with a challenge, which is a 16-byte random number.
5. In response, the client sends the challenge encrypted by the hash of the user’s password.
6. The server then sends the challenge, response and username to the domain controller (DC).
7. The DC retrieves the user’s password from the database and uses it to encrypt the challenge.
8. The DC then compares the encrypted challenge and client response. If these two pieces match, then the user is authenticated and
access is granted.

The Difference Between NTLM and Kerberos?

Like NTLM, Kerberos is an authentication protocol. It replaced NTLM as the
default/standard authentication tool on Windows 2000 and later releases .
The main difference between NTLM and Kerberos is in how the two protocols
manage authentication. NTLM relies on a three-way handshake between the client
and server to authenticate a user. Kerberos uses a two-part process that leverages
a ticket granting service or key distribution center.

Another main difference is whether passwords are hashed or encrypted. NTLM

relies on password hashing, which is a one-way function that produces a string of
text based on an input file; Kerberos leverages encryption, which is a two-way
function that scrambles and unlocks information using an encryption key and
decryption key respectively.

Even though the Kerberos protocol is Microsoft’s default authentication method

today, NTLM serves as a backup. If Kerberos fails to authenticate the user, the
system will attempt to use NTLM instead.

Why Was NTLM Replaced by Kerberos?

NTLM was subject to several known security vulnerabilities related to password

hashing and salting.

In NTLM, passwords stored on the server and domain controller are not “salted” —
meaning that a random string of characters is not added to the hashed password to
further protect it from cracking techniques. This means that adversaries who
possess a password hash do not need the underlying password to auth enticate a
session. As a result, systems were vulnerable to brute force attacks, which is when
an attacker attempts to crack a password through multiple log-in attempts. If the
user selects a weak or common password, they are especially susceptible to such
tactics.

NTLM’s cryptography also fails to take advantage of new advances in algorithms

and encryption that significantly enhance security capabilities.

Kerberos Protocol

Kerberos was developed by researchers at the Massachusetts Institute of

Technology (MIT) in the 1980s. The name is derived from the Greek mythological
character Kerberos, the three-headed dog who guards the underworld.

In practice, the three security components in the Kerberos protocol are represented
as:
1. A client seeking authentication
2. A server the client wants to access
3. The ticketing service or key distribution center (KDC)

Kerberos Authentication
Here is the twelve-step process for Kerberos authentication:
1. The user shares their username, password, and domain name with the client.
2. The client assembles a package — or an authenticator — which contains all relevant information about the client, including the
username, date and time. All information contained in the authenticator, aside from the user name, is encrypted with the user’s
password.
3. The client sends the encrypted authenticator to the KDC.
4. The KDC checks the username to establish the identity of the client. The KDC then checks the AD database for the user’s
password. It then attempts to decrypt the authenticator with the password. If the KDC is able to decrypt the authenticator, the
identity of the client is verified.
5. Once the identity of the client is verified, the KDC creates a ticket or session key, which is also encrypted and sent to the client.
6. The ticket or session key is stored in the client’s Kerberos tray; the ticket can be used to access the server for a set time period,
which is typically 8 hours.
7. If the client needs to access another server, it sends the original ticket to the KDC along with a request to access the new
resource.
8. The KDC decrypts the ticket with its key. (The client does not need to authenticate the user because the KDC can use the ticket to
verify that the user’s identity has been confirmed previously).
9. The KDC generates an updated ticket or session key for the client to access the new shared resource. This ticket is also encrypted
by the server’s key. The KDC then sends this ticket to the client.
10. The client saves this new session key in its Kerberos tray and sends a copy to the server.
11. The server uses its own password to decrypt the ticket.
12. If the server successfully decrypts the session key, then the ticket is legitimate. The server will then open the ticket and review the
access control list (ACL) to determine if the client has the necessary permission to access the resource.

Applications That Use NTLM

NTLM was replaced as the default authentication protocol in Windows 2000 by
Kerberos. However, NTLM is still maintained in all Windows systems for
compatibility purposes between older clients and servers.

For example, computers still running Windows 95, Windows 98, or Windows NT 4.0
will use the NTLM protocol for network authentication with a Windows 2000 domain.
Meanwhile, computers running Windows 2000 will use NTLM when authenticating
servers with Windows NT 4.0 or earlier, as well as when accessing resources in
Windows 2000 or earlier domains. NTLM is also used to authenticate local logons
with non-domain controllers.

NTLM Benefits and Challenges

NTLM is considered an outdated protocol. As such, its benefits — when compared
to a more modern solution, such as Kerberos — are limited. Yet the original promise
of NTLM remains true: Clients use password hashing to avoid sending unprotected
passwords over the network.

At this point there are several clear disadvantages to relying on NTLM

authentication:

• Single authentication. NTLM is a single authentication method. It relies on a challenge-response protocol to establish the user. It
does not support multifactor authentication (MFA), which is the process of using two or more pieces of information to confirm the
identity of the user.
• Security vulnerabilities. The relatively simplistic form of password hashing makes NTLM systems vulnerable to several modes of
attacks, including pass-the-hash and brute-force attacks.
• Outdated cryptography. NTLM does not leverage the latest advances in algorithmic thinking or encryption to make passwords
more secure.
How Can You Protect Your Network Using NTLM?

Given the known security risks associated with NTLM, CrowdStrike recommends
that organizations try to reduce NTLM usage in their network as much as possible.

For organizations still relying on NTLM for compatibility reasons, CrowdStrike offers
the following recommendations to enhance security and minimize risk.
1. Enforce NTLM mitigations. To be fully protected from NTLM relay attacks, you will need to enable server signing and EPA on all
relevant servers.
2. Patch! Make sure your systems are fully protected with the latest security updates from Microsoft.
3. Use advanced techniques. Apply advanced NTLM relay detection and prevention techniques similar to the ones disclosed by
Preempt (now CrowdStrike) in our Black Hat 2019 talk.
4. Identify weak variations. Some NTLM clients use weak NTLM variations (e.g., don’t send a MIC). This puts your network at a
greater risk of being vulnerable to NTLM relay.
5. Monitor NTLM traffic in your network. Try to restrict insecure NTLM traffic.

Get rid of clients sending LM responses and set the Group Policy Object (GPO)
network security: LAN Manager authentication level to refuse LM responses.