Ruslan Rakhmetov, Security Vision
One of the main functions of information security is authentication of users, administrators, service accounts and other entities that perform certain actions in information systems. Authentication means verification by the system of the authenticity of credentials (logins, passwords, one-time access codes, other authenticators) presented by users. Authentication differs from identification - the process of presenting a user to the system without confirming his/her authenticity, as well as from authorisation - the process of granting a user authority in the system after his/her successful authentication. In modern corporate infrastructures two main authentication protocols are used - NTLM (in Windows environment) and Kerberos (in Windows and Linux environments), which we will talk about in this article.
So, the NTLM protocol (an acronym for ‘New Technology LAN Manager’, with LAN Manager being the name of an obsolete OS that was developed by Microsoft over 30 years ago) is used in Windows environments to authenticate users, devices and services in domain and non-domain infrastructures. In the case of a domain infrastructure, NTLM authentication is based on the trust of all domain members (users, devices, services) to the domain controller, so the user authenticates to the domain once when logging on to the OS and then does not enter a login and password when accessing a variety of network services (e.g., network folders, web services, network printers). The domain controller has information about users' secret keys (NT-Hash password hashes, discussed below), which are used for their authentication; this information together with user data is stored in the NTDS.dit file, which is located on the domain controller in the “C:Windows/NTDS\” directory. In the case of a non-domain environment, it is assumed that the user knows the password to access the service to which he/she is authenticating; the secret keys (NT-Hash) of local users and services are stored in the file ‘C:\Windows\System32\config\SAM’, which appears in the Windows registry at the path ‘HKEY_LOCAL_MACHINE\SAM’.
At present, all versions of the NTLM protocol are considered obsolete, except for the second (NTLMv2), so for the purposes of this article we will consider NTLMv2. The key feature of NTLM authentication is that it does not use passwords in their pure form, but password hashes: password hashes of the ‘NT-Hash’ type for local authentication and password hashes of the ‘Net-NTLMv2’ type for domain (network) authentication.
NT-Hash password hashes are formed as a result of password hashing using MD4 algorithm:
NT-Hash = MD4 (password)
The generated NT-Hash is a sequence of 128 bits, knowledge of which allows attackers to impersonate the user, i.e. perform all actions on behalf of the compromised account, including access to network resources. Such attacks are called Pass-The-Hash and are implemented using various utilities, such as Mimikatz or SecretsDump, which gain access to data from the Lsass.exe process, which stores the NT-Hash of logged-in users, as well as access to data stored in the ‘Windows Credential Manager’ (‘Credential Management’) and local user data (SAM file). This type of hash is quite easy to bruteforce.
The Net-NTLMv2 hash is formed on the basis of NT-Hash using the algorithm of HMAC-imit insertion with MD5 hashing:
NTLMv2 Hash = HMAC-MD5 (NT-Hash, user name, domain name)
The final Net-NTLMv2 hash is a combination of the resulting NTLMv2 Hash value (128 bits long) and the service data (user and server challenge requests). This type of Net-NTLMv2 hash cannot be used for Pass-The-Hash attacks, but can be used for Hash Relay attacks (e.g. SMB Relay Attack, NTLM Relay Attack, LDAP Relay Attack) that are performed using the Responder or Impacket utilities (ntlmrelayx / smbrelayx). This hash type is bruteforceable, which, however, takes longer compared to bruteforcing NT-Hash hashes.
The NTLMv2 authentication algorithm consists of the following steps (based on data from Microsoft resources and the SANS organisation ):
1. The client sends a connection request to the server that contains its account name as well as a list of features supported by the client.
2. The server responds to the client with a list of supported features and also sends the client a server challenge request (also called a nonce string) of 8 random bytes.
3. The client performs the operations:
3a. Calculates the NTLMv2 Hash as an HMAC-MD5 function from the user name and server name specifying its domain, where the NT-Hash value is used as the secret key for the HMAC algorithm:
NTLMv2 Hash = HMAC-MD5 (NT-Hash, user name, domain name)
3b. Generates a dataset (temp) containing the current timestamp and a client challenge request of 8 random bytes: the timestamp is used to prevent a replay attack (accumulation and reuse of outdated authentication data), and the challenge request is used to increase the cryptographic strength of the authentication scheme used and to mutually authenticate the server to the client.
3c. The temp set obtained in step 3b is combined with the challenge-request from the server and then run through the HMAC-MD5 algorithm, where the NTLMv2 Hash value calculated in step 3a is used as the secret key for the HMAC algorithm:
NTProofStr = HMAC-MD5 (NTLMv2 Hash, server challenge + temp)
3d. The final NTLMv2 Response, which will be the Net-NTLMv2 hash (of uncommitted length), is the union of the NTProofStr value obtained in step 3c and the temp set:
NTLMv2 Response = NTProofStr + temp
Net-NTLMv2 = NTLMv2 Response
4. The client sends the received NTLMv2 Response to the server.
5. The server performs the following actions:
5a. If local authentication is used, the server calculates the NTLMv2 Response value itself (because it has all the data it needs to do so, including the locally stored NT-Hash of the user's password), and then checks to see if the NTLMv2 Response value it calculated matches the NTLMv2 Response value that the client sent it. If these values match, the client is authenticated by the server, and then calculates the 128-bit long KeyExchangeKey encryption key, which is used to cryptographically protect the data being transmitted between the client and the server:
KeyExchangeKey = HMAC-MD5 (NTLMv2 Hash, NTProofStr)
5b. If domain authentication is used, the server forwards to the domain controller the NTLMv2 Response value received from the client, along with the name of the user to be authenticated and the server's challenge request (which was sent to the client in step 2). The domain controller calculates the NTLMv2 Response value itself (because it knows the name of the authenticated user and has access to the NT-Hash of the user's password), and then checks to see if the NTLMv2 Response value that it calculates matches the NTLMv2 Response value that the client calculated and the NTLMv2 Response value that the server sent to it. If these values match, the domain controller tells the server that the client is authenticated and sends the server a calculated SessionBaseKey encryption key of 128 bits that will be used to cryptographically protect the data being transferred between the client and the server:
SessionBaseKey = HMAC-MD5 (NTLMv2 Hash, NTProofStr)
As can be seen from the description of the NTLM protocol, the strength of authentication depends heavily on the complexity of the user's password, which is then used to calculate the NT-Hash and is then used throughout the NTLM authentication scheme. Bruteforcing locally obtained NT-Hash hashes and Net-NTLMv2 hashes intercepted over the network remains an effective attack method. Hash Relay attacks, which are based on the introduction of a third-party attacker server into the authentication process that intercepts all traffic from the client to the legitimate server and then impersonates the client after receiving the Net-NTLMv2 hash, also remain relevant. To reduce the likelihood of such attacks it is necessary to limit and control the use of untrusted protocols such as LLMNR, NBT-NS, mDNS in the corporate network, minimise the risks of attacks of introducing untrusted information for DNS and ARP protocols, as well as to use Microsoft recommended methods of protection: SMB and LDAP signing (SMB / LDAP signing), use of Extended Protection for Authentication (EPA) technology, as well as a complete transition to a more reliable Kerberos authentication protocol.
The Kerberos protocol is developed by the Massachusetts Institute of Technology (MIT), the latest current version is Kerberos 5 Release 1.21.2. This protocol is based on the trust of all authentication participants in a single authentication centre. The Kerberos protocol can be used in heterogeneous environments, it uses symmetric encryption, uses a single authentication to work with different services within the Kerberos domain, and also performs mutual authentication of the client and server. For Kerberos to work, each device and service must have an SPN name (servicePrincipalName attribute) registered on the domain controller, which includes the DNS name of the device (e.g., PC01.corp.local or DC01.corp.local) and the name of the service (e.g., WSMAN, TERMSRV, CIFS, etc.). Kerberos authentication works when accessing remote resources by their DNS names and does not work when accessing them by their IP addresses.
In a Windows environment, Kerberos authentication is supported using two types of cipher suites:
1. RC4_HMAC_MD5 - an older implementation, which uses the RC4 stream encryption algorithm and the HMAC-MD5 algorithm for authentication and integrity control, where the NT-Hash value is used as the secret key for HMAC (it is also used for NTLM authentication):
NT-Hash = MD4 (password)
2. AES128_HMAC_SHA1 and AES256_HMAC_SHA1 are newer implementations that use the AES standard algorithm with a key length of 128 or 256 bits, where a PBKDF2 function with the HMAC-SHA1 algorithm is used to generate the encryption key, which is passed a combination of the password, the ‘salt’ value (a variable formed as a ‘salt’ value), and a combination of the password and the ‘salt’ value. (a variable formed as a combination of the form ‘username’, e.g. CORP.LOCALuser1), and two additional constants (iter_count, keylength).
The Kerberos authentication scheme uses the following components:
1. KDC (key distribution centre) - contains the private keys of users and services that trust the KDC. At the same time, the KDC is a single point of failure, it must always be available for connection. Often in corporate networks for fault tolerance several domain controllers, acting as KDCs, are used with data replication between them.
2. AS (authentication service) is a component of the KDC that accepts requests from users.
3. TGS (ticket granting service) - a component of the KDC that accepts requests for session keys (TGS tickets) and issues them. TGS tickets have a default lifetime of 10 hours.
4. TGT (ticket granting ticket) - a ticket that is issued by the AS in encrypted form to the client for some time (10 hours by default), then the client uses it to confirm that it has already been authenticated.
Description of the authentication process using Kerberos:
1. The client contacts the AS to obtain the TGT. The client forwards the data (client ID, timestamp, randomly generated nonce label and server ID) in a message called KRB_AS_REQ. The timestamp transmitted by the client is encrypted using the hash from the user password (NT-Hash or PBKDF2 function value) as the encryption key. The timestamp is encrypted only when the user account is set to ‘Kerberos pre-authentication required’. The timestamp is used to prevent a replay attack (replay attack with accumulation and reuse of outdated authentication data), this requires the client to be set to the exact time (the allowable mis-synchronisation is configurable, the default is 5 minutes or less).
2. The AS decrypts the client request (contacting the KDC to obtain the client's secret key); if it can be decrypted, the AS returns to the client a TGT ticket encrypted with the TGS's key (which is a hash of the KRBTGT service domain user password), along with the client's key-encrypted client/TGS session communication key, the validity time of the TGT ticket, and a nonce tag. This message is referred to as KRB_AS_REP. The TGT ticket can only be opened and read by the KRBTGT service, but is susceptible to bruteforce attacks if intercepted by attackers. Nonce-tag verification is used to prevent replay attacks and to match the requests sent by the client with the responses received from the server.
3. When a client wants to use a service (e.g., mail server or print server), the client sends to the TGS its TGT, SPN service identifier and its session-key encrypted client/TGS authenticator (client name, timestamp), and a randomly generated nonce tag. This message is referred to as KRB_TGS_REQ.
4. The TGS responds to the client by transmitting:
4a. A TGS ticket, which is encrypted with the service's secret key (i.e., a hash of the password of the service account the client wants to access) and contains the client's name, the KDC timestamp, the TGS ticket validity time, and the client/service session key;
4b. The client/service session key and nonce tag encrypted with the client/TGS session key.
This message is referred to as KRB_TGS_REP.
5. The client sends the service this TGS ticket and its new authenticator (timestamp and client name encrypted with the ‘client/service’ session key). This message is called KRB_AP_REQ.
6. The service decrypts the received TGS ticket with its private key, extracts the ‘client/service’ session key, then decrypts the client's authenticator with the received ‘client/service’ session key. Next, to authenticate itself to the client, the service sends the client the previously received ‘client timestamp’ value encrypted with the ‘client/service’ session key. This message is called KRB_AP_REP.
7. The client decrypts the ‘timestamp’, verifies that it matches, and if successful, the exchange of information between the client and the service begins.
Despite the fact that Kerberos is an authentication protocol, it includes the ability to perform client authority verification - this is done using the PAC (Privilege Attribute Certificate) structure, which is included in the encrypted TGT and TGS tickets transmitted in the KRB_AS_REP and KRB_TGS_REP messages. The PAC structure specifies user privileges that the service can verify by contacting the KDC. One of the known vulnerabilities in Microsoft's implementation of Kerberos has the identifier CVE-2014-6324 - it was the lack of correct verification of PAC attributes, which allowed a normal user to escalate privileges to the maximum in the domain.
The main types of attacks against Kerberos are:
Pass The Ticket - the ability to use a user's Kerberos TGS or TGT ticket to gain access to resources from under his account. The attack is realised, for example, by accessing the memory of the lsass.exe process where Kerberos tickets are stored.
Golden Ticket - the ability to impersonate any user in the domain by using the KRBTGT account hash and issuing any TGT tickets to anyone.
Silver Ticket - the ability to use the password hash of a service account to create a TGS ticket and access resources from under that account.
Kerberoasting - the ability to bruteforce and obtain a service account password offline without risk of account lockout. The attack is also possible due to the fact that passwords for service accounts are either not changed at all or are changed very rarely.
ASREPRoast - the ability to bruteforce and obtain a user's password if there is no Kerberos preauthentication requirement.
Overpass The Hash - the ability to obtain a user's TGT if a hash of their password is available.
