4, Kerberos Authentication Protocol

First, overview

Record the study of several Windows authentication protocols, including the detailed authentication process of NTLM local authentication, NTLM network authentication, and Kerberos authentication.

Second, local authentication process

2.1 Local authentication process

Windows Logon Process(i.e., winlogon.exe), Winlogon is a component responsible for handling security-related user interaction interfaces. The work of Winlogon includes loading other user identity security components, providing a graphical login interface (LogonUl.exe), and creating user sessions.

LSASS (Local Security Authentication Subsystem Service)for the security mechanism of the Microsoft Windows system. It is responsible for the security policy of the Windows system. It is responsible for verifying the user's identity during local verification or remote login, managing user password changes, and generating access logs. After the user logs off, restarts, or locks the screen, the operating system will allow winlogon to display the graphical login interface, that is, the input box, receive the domain name, username, and password, and then hand it over to the lsass process to encrypt the plaintext password intoNTLM HashforSAM databaseComparison authentication, if the same, authentication is successful.

winlogon.exe -> receive user input -> Isass.exe -> (authentication)

User login authentication process

The process used in local authentication to handle user input passwords is lsass.exe, and the password will be encrypted intoPlaintext saved, which provides the plaintext password we obtain using mimikatz, is read in this process.

Windows Logon Process (i.e., winlogon.exe) is the Windows NT user login program used to manage user login.

LSASS is used for the security mechanism of the Microsoft Windows system, which is used for local security and login strategies.

Domain login in the domain environment: domainname\username

Local login authentication: computername\username

2.2 Authentication provider

Two main ones in WindowsAuthentication provider: MSV1_0 and Kerberos. These are called Security Support Provider Authentication Packages (SSP / AP) by Microsoft.

Local authentication

The MSV1_0 authentication provider accesses the SAM database containing local account credentials

Domain user authentication

1. When the DC cannot be accessed, the MSV1_0 authentication provider will attempt to authenticate users by using cached domain user credentials read from the SECURITY registry configuration unit.

2, can contact DC, callKerberosAuthentication provider. This authentication provider is responsible for using the Kerberos protocol (port 88, executing network authentication)

kerberos 88 port TCP/IP protocol

2.3 Authentication classification

Account password authentication

By sending 'account password' to the server to prove one's identity

Challenge authentication NTLM

By sending 'a calculation result' to the server to prove one's identity

kerberos authentication

By sending a 'ticket' to the server to prove one's identity

2.4 Key

Long-term key, data encrypted with a long-term key should not be transmitted over the network because the long-term key may remain unchanged for a long time, such as a password

Short-term key: Since data packets encrypted with a long-term key cannot be transmitted over the network, another key needs to be used to encrypt data that needs to be transmitted over the network. This key is only valid for a short period of time, and even if the encrypted data packets are intercepted by hackers, by the time they calculate the key, the key has already expired. We call this type of key a short-term key.

Three, NTLM network authentication

The encryption HASH algorithms in Windows operating systems are divided into two types: LM HASH encryption algorithm and NTLM HASH encryption algorithm. Currently, the most popular HASH encryption algorithm is NTLM HASH (NT LAN Manager encryption algorithm).

(1) LM HASH

LM Hash (LAN Manager Hash) is the earliest encryption algorithm used by Windows, designed by IBM. LM Hash uses a hard-coded key DES and has flaws. Early Windows systems such as XP, Server 2003, etc., used LM Hash, while later systems disabled LM Hash by default and used NTLM Hash.

(2) NTML HASH

NTLM HASH (NT LAN Manager) is a hash algorithm designed for Windows to ensure security and compatibility. It is an NTLM algorithm introduced by Microsoft in Windows NT 3.1 to address the many security issues of the LM HASH encryption algorithm. Currently, the NTLM HASH algorithm is enabled by default in operating system versions after Windows 7/Windows Server 2008.

(3) NTLM Hash algorithm principle

Currently, the password HASH used in most Windows operating systems is NTLM HASH (NT LAN Manager), which is encrypted to a combination of letters and numbers through three layers of encoding and encryption, including Hex, Unicode, and MD4.32-bit hashHere is the specific algorithm of NTLM HASH.

1) Encode the user password into hex encoding to get the hexadecimal format.

2) Convert the obtained hexadecimal result to Unicode encoding.

3) Encrypt the result of Unicode conversion using the MD4 encryption algorithm.

Historical version

NTLMv1: The server sends an 8-byte random number (challenge) to verify the client, and the client returns two 24-byte hashes for calculation and returns the calculation result.

NTLMv2: It goes throughstrengthen the protocolto resist many spoofing attacks and increaseThe server authenticates the clientability, thereby enhancing the security of NTLM. The server sends a16 bytesto verify the client with the HMAC - MD5 random number (challenge).

The MSV1_0 security software package implements the NT LAN Manager authentication protocol (NetNTLMv1 and NetNTLMv2)

challenge: random number

3.1 NTLM authentication process diagram (workgroup)

It is roughly divided into three steps:

1) Negotiation (Negotiate): Mainly used to confirm the protocol version of both parties.

2) Challenge (Question): It is the challenge (Challenge) / response (Response).

3) Verification (Response): Verification is mainly to verify the result after the challenge is completed, which is the final step of authentication.

3.2 Specific authentication process

(1) Negotiation

1. The Client sends a TYPE1 Negotiate negotiation message to the Server to determine the protocol version.

2. The server receives the TYPE1 message sent by the client, reads the content within it, and selects the services it can accept, encryption levels, security services, etc.

(2) Challenge

1. The Client sends a plaintext username message as a request to the Server.

2. The Server receives the request, verifies if the username sent by the Client exists, if it exists, passes it to NTLM SSP to get the NTLM_CHALLENGE message.

3. Send a 16-bit random number (Challenge) to the Client, and use the NTLM Hash corresponding to the username queried from SAM to encrypt the Challenge, generate the Net-NTLM Hash and store it in memory.

4. The Client uses the NTLM Hash corresponding to the sent username to encrypt the Challenge, and sends the result (Response) to the Server.

If the Net-NTLM Hash generated by the Server and placed in memory in the third step is the same as the Response generated by the Client in the fourth step, the authentication will pass.

(3) Verification

1. Upon receiving the Response sent by the Client, the Server compares the received Response with the Net-NTLM Hash, and if they are the same, the authentication passes.

Note: Each generated 16-byte Challenge is different, ensuring security,

3.3. NTLM verification within the domain

In the domain, the Server does not have the hash of the user and password, so the Server needs to send the challenge and the Response returned by the Client to the Domain Controller at the same time, so that the Domain Controller can perform the verification. Because the Domain Controller has the username and password, not only the verification stage, but also the Server needs to have the Domain Controller perform the verification in the second step of the challenge stage, to verify whether the user exists, which should also be completed by the Domain Controller.

【1】Negotiation

1. The user logs into the client host by entering the Windows account and password, and the client caches the hash value NTLM-Hash of the password. If a user who successfully logs into the client attempts to access server resources, they need to send a request to the other party, which uses NTLM SSP to generate the NTLM_NEGOTIATE message (also known as TYPE 1 message, Negotiate negotiation message), and sends the TYPE 1 message to the server. This TYPE 1 message contains a plaintext username and other negotiation information (such as the principal, machine, and security services to be used, etc.)

【2】Challenge

2. Upon receiving the TYPE 1 message sent by the client, the server will read the content, and select the service content, encryption level, security service, etc. that it can accept. Then it passes it to NTLM SSP to obtain the NTLM_CHALLENGE message (also known as TYPE 2 message, Challenge challenge message), and sends this TYPE 2 message back to the client. This TYPE 2 message contains a random value generated by the server16-bit random value, this random value is called Challenge, the server saves the Challenge.

3. Upon receiving the TYPE 2 message returned by the server, the client reads out the content supported by the server, and takes the random value Challenge, uses the cached password's hash NTLM-Hash to encrypt it, obtaining the Net NTLM-Hash (encrypted Challenge), and encapsulates the Net NTLM-Hash into the NTLM_AUTH message (also known as TYPE 3 message, Authenticate authentication message), and sends it to the server.

【3】Verification

4, After the server receives the NTLM_AUTH TYPE 3 message sent by the client, it extracts the Net NTLM-Hash value and sends a verification request for the client to the DC (Domain Control).

This request mainly includes the following three aspects:

Client username

The original Challenge

The encrypted Challenge (that is, the Net NTLM-Hash).

5, The DC retrieves the password hash value NTLM-Hash for the account based on the username, encrypts the original Challenge with the password hash value NTLM-Hash to get the Net NTLM-Hash. If the encrypted Challenge matches the one sent by the server, it means the user has the correct password, the verification is successful, otherwise the verification fails, and the DC sends the verification result to the server.

6, The server responds to the client based on the result returned by the DC.

3.4, Attack methods against NTLM Hash

1, Pass The Hash

Pass The Hash (PtH) is a method of attack where the attacker captures account login credentials and reuses the credential hash for attack.

2, Pass The Key

In environments where NTLM is disabled, tools such as mimikatz can be used to directly obtain passwords.

3, NTLM Relay

When an attacker can control the client network to some extent, they can use man-in-the-middle attacks to obtain permissions. The attacker impersonates the authentication server for the client and impersonates the client for the server that needs to be authenticated.

4, Kerberos Authentication Protocol

4.1, Basic Introduction

The Kerberos protocol is a network authentication protocol proposed by the Massachusetts Institute of Technology, which provides a method for authenticating user identity information in an open non-secure network. It aims to provide strong authentication for client/server applications by using key encryption technology.

The Kerberos implementation does not depend on the authentication of the host operating system, does not require trust based on the host address, does not require the physical security of all hosts on the network, and assumes that data packets transmitted on the network can be arbitrarily read and modified.

Kerberos, as a trusted third-party authentication service, performs authentication services through traditional password technology (such as: shared key).

Note

In a domain environment, Kerberos authentication is used by default, and NTLM authentication is used when Kerberos authentication errors occur.

In the case where the specified hostname does not match the registered service principal name, or if an IP address is used, Windows will revert to the old protocol, such as NetNTLMy2 authentication.

Characteristics:

• Trusted third-party authentication service, performing authentication services through traditional password technology (such as: shared key)
• Third party: client, server, AD (domain controller)
• Not dependent on host operating system authentication
• No need for trust based on host address
• Does not require the physical security of all hosts on the network (assuming that data packets transmitted on the network can be arbitrarily read, modified, and data inserted)

Advantages:

• Passwords are never sent in plaintext over the network
• Any private or public encryption key will not be exchanged directly on the network
• Users and applications can mutually authenticate (mutual authentication)
• Generally used as single sign-on

TCP/UDP 88 port: authentication and ticket granting

TCP/UDP 464 port: classic Kerberos Kpaswd (password reset) protocol

LDAP: 389, 636

4.2 Some Abbreviations in Kerberos

Basic

Request TGT

Request ST

Other

Brief understanding

TGT is equivalent to an ID card

ST is equivalent to a train ticket

SPN is the service name that needs to be accessed

KDC is equivalent to the Public Security Bureau

AS is equivalent to the service provided by the Public Security Bureau for issuing ID cards - function: to determine whether the identity is valid - to determine whether to issue an ID card

TGS is equivalent to the Public Security Bureau - Service Center (When the Client requests TGS, it needs to include the required SPN to access) Role: Verify the validity of the ID card - judge whether to issue train tickets (or other service authentication tickets)

4.3. Brief process diagram

① The Client requests the AS service of the KDC to obtain TGT

② The Client requests the TGS service of the KDC with TGT to obtain ST

③ The Client accesses the Server with ST

4.4. Detailed Kerberos authentication process

(One) The Client applies for TGT

1. The Client sends a request message (REQ) to KDC-AS

The message includes:

• Use the NTLM Hash of the Client user to encrypt the timestamp (to prevent replay attacks)
• Username, transmitted in plaintext
• SPN krbtgt
• User nonce

Practical attack: AS-REQ user enumeration

Because the DC also needs this username to match the Client's NTLM Hash to decrypt the message, if it can be decrypted, the authentication passes, so the username is not encrypted and belongs toTransmission in plaintextTherefore, there is an enumeration of domain usernames here.

2. KDC-AS returns the message (REP) to the Client

1. The authentication service (KDC-AS) uses the NTLM decryption timestamp of the user, if the decryption is successful, KDC-AS checks the user's information (login restrictions, group membership, etc.) and creates the TGT

2. Request the local LSA (Local Security Authority) to generate a special data PAC (signed using the krbtgt key), KDC randomly generates a short-term session key (Session Key), at this time, AS sends two messages to the Client

(1) TGT (encrypted with the krbtgt NTLM Hash) for 10 hours, including: User Name, Session Key, PAC (signed by the krbtgt hash), TGT lifecycle

(2) Another message TC (encrypted with the NTLM Hash corresponding to the username used by the Client to apply for TGT) includes: TGT lifecycle, Session Key, User Nonce

Note:

• The KDC-AS queries the NTLM Hash of the user by username, and if the decryption is successful, it indicates that the password on the Client side is correct, so the x8;TGT process authentication is successful in this step.
• The return message of this step will only be sent if the KDC-AS authentication is successful
• The authentication message Authenticator in the first step is the NTLM Hash of the Client, which is used for authentication
• The PAC for special data is signed using the krbtgt key, so it cannot be modified
• TGT is encrypted using the krbtgt NTLM Hash, and the krbtgt NTLM Hash is not transmitted on the network, so TGT can be safely transmitted.
• TC uses the NTLM Hash corresponding to the authenticated Client username for encryption

Practical attack: SESSION KEY offline brute force

Easy to generate attacks: SESSION KEY offline cracking

If it is possible to intercept the TC message, offline cracking can be performed because this message is encrypted using the user's NTLM Hash, and if rainbow tables are used for enumeration, the username and password can be obtained.

(Second) The Client applies for ST

1. The Client sends a request message (REQ) to KDC-TGS

Client -> KDC-TGS (TGS_REQ)

The Client decrypts the TC message using the user's NTLM Hash, obtains the Session Key, and then sends a message to KDC-TGS:

(1) Authenticator (encrypted using Session Key), including: Client Name, Timestamp (+/- five minutes)

(2) TGT (encrypted using krbtgt hash): Session Key

(3) The required SPN

(4) A Nonce

Note

• Golden Ticket (forged TGT, the premise is to obtain the krbtgt's password hash value) can generate the Session Key itself
• The authentication message Authenticator in the second step is encrypted with the Session Key, including username and timestamp (to prevent replay attacks)
• Here, KDC uses the Session Key for verification, because this Session Key is obtained by KDC-TGS through the decryption of the krbtgt's NTLM Hash, and the user obtains it by decrypting their own NTLM Hash through the first step of verification, so it can indirectly verify whether the user's NTLM Hash is correct.

2. KDC-TGS returns a message to the Client (REP)

After receiving the REQ message, KDC

(1) KDC decrypts the TGT using the Krbtgt NTLM Hash, obtaining the Client information and Session Key

(2) Use the Session Key to decrypt the Authenticator information sent by the Client, compare it with the TGT information, and if they are the same, the authentication is successful

KDC-TGS generates the Server Session Key and sends a reply message to the Client, which includes the following parts:

(1) The ST generated by the TGS that the Client needs to access the service is sent to the Client, the Ticket is encrypted with the NTLM Hash of the target service account, including:

• Client Name
• Server Session Key
• PAC (krbtgt hash signature)
• TGS Lifetime (timestamp)

(2) The Server Session Key encrypted with the Session Key, including:

• A Nonce
• TGS Lifetime
• Server Session Key

(3) Username

Note:

• ST is encrypted with the NTLM Hash of the target service account
• The Server Session Key is encrypted with the Session Key (because the Client also obtained the Session Key in the second step, which was decrypted from AS with his own NTLM Hash; and the Session Key used to encrypt the Server Session Key here is obtained after decrypting the krbtgt NTLM Hash, which can verify consistency and ensure security)

Practical attack: KERBEROAST

If this message can be intercepted, because ST is encrypted with the Hash of the account password of the Server service, so if we can crack it through a rainbow table, we can get the password and account of the Server service

(Three) The Client accesses the Server based on ST

After receiving the message, the Client uses the Session Key to decrypt and obtain the Server Session Key

1. The Client requests services from the Server with the ST (AP-REQ)

(1) The Client sends the Authenticator information encrypted by the Server Session Key and ST to access the Server, including:

• Timestamp
• Client Name

(2) ST (encrypted with Server NTLM Hash)

• Server Session Key
• Client Name

Note:

• In the third step, the verification message Authenticator is encrypted with the Server Session Key
• After the previous step is verified, two messages are returned to the Client: one is the ST message (encrypted with the Server's own NTLM Hash and containing the Server Session Key), and the other is a message encrypted with the Session Key, also containing the Server Session Key.
• At this step, the Client uses the Server Session Key obtained after decrypting with the Session Key to encrypt the Authenticator and ST sent to the Server

Practical attack: Silver Ticket

• Forgeries TGS and sends it directly to the Service
• Does not generate AS-REQ, AS-REP, TGS-REQ, TGS-REP
• Generated by machine accounts

2. Server returns a message (AP-REP) to the Client

Server

(1) The Server uses NTLM Hash to decrypt ST, obtain Server Session Key, and use Server Session Key to decrypt the Authenticator information, compare the Client information in the Authenticator information with the Client information in the Ticket, and compare whether the timestamp in the Authenticator information is the same as the timestamp in the Ticket (error within 2 minutes)

(2) The Server uses the Server Session Key to encrypt the Authenticator information, which includes:

• ID (ID is equivalent to cookie)
• Timestamp

Client

(1) The Client uses the Server Session Key in the cache to decrypt the Authenticator information, obtaining the ID and timestamp required to access the service

(2) After authentication is completed, only the Service Ticket applied for needs to be used to access the service normally

Overall understanding:

• Session Key, as a temporary key, is transmitted on the network as a verification condition for the next two steps
• Verification process: including the use of Client NTLM Hash, krbtgt NTLM Hash, Session Key, and Server Session Key for encryption and decryption to verify, and also compare usernames and timestamps to further prevent replay attacks and confirm consistency, ensuring security.

Reference:

https://cloud.tencent.com/developer/article/2381711