Kerberos Authentication
The Microsoft implementation of the Kerberos authentication protocol
was adopted from the Kerberos version 5 authentication protocol developed by MIT
and has been Microsoft’s primary authentication mechanism
since Windows Server 2003.
While NTLM authentication works through a principle of challenge and response,
Windows-based Kerberos authentication uses a ticket system.
At a high level, Kerberos client authentication to a service
in Active Directory involves the use of a domain controller
in the role of a Key Distribution Center, or KDC.
Let’s review this process in detail
in order to lay a foundation for discussion in the following section.
When a user logs in, a request is sent to the Domain Controller (DC).
This DC serves as a KDC and runs the Authentication Server service.
The initial Authentication Server Request contains a timestamp
encrypted using a hash derived from the current user’s username and password.
When the service receives the request, it looks up the password hash associated
with that user and attempts to decrypt the timestamp.
If the decryption process is successful and the timestamp is not a duplicate,
the authentication is considered successful.
The service replies to the client with an Authentication Server Reply,
which contains a session key, since Kerberos is stateless,
and a Ticket Granting Ticket or TGT.
The session key is encrypted using the user’s password hash,
which the client could decrypt and reuse.
The TGT contains user information, including group memberships, the domain,
a timestamp, the IP address of the client, and the session key.
In order to avoid tampering, the Ticket Granting Ticket is encrypted by a secret
key known only to the KDC and can not be decrypted by the client.
Once the client has received the session key and the TGT,
the KDC considers the client authentication complete.
By default, the TGT will be valid for 10 hours.
During this time the user is not required to retype the password.
Additionally, the TGT can be renewed without entering the password.
When the user attempts to access domain resources, such as a network share,
Exchange mailbox, or some other application with a registered
service principal name ( SPN ), the KDC is again contacted.
This time, the client constructs a Ticket Granting Service Request packet
that consists of the current user and a timestamp,
encrypted using the session key, the SPN of the resource and the encrypted TGT.
Next, the ticket granting service on the KDC receives the Ticket Granting Service
Request, and if the SPN exists in the domain,
the TGT is decrypted using the secret key known only to the KDC.
The session key is then extracted from the decrypted TGT, and this key is used to
decrypt the username and timestamp of the request.
If the TGT has a valid timestamp where no replay is detected and the request
has not expired, the TGT and session key usernames match,
and the origin and TGT IP addresses match, the request is accepted.
If this succeeds, the ticket granting service responds to the client with a
Ticket Granting Server Reply.
This packet contains three parts:
The SPN to which access has been granted.
A session key to be used between the client and the SPN.
and a service ticket containing the username and group memberships
along with the newlycreated session key.
The first two parts, the SPN and session key,
are encrypted using the session key associated with the creation of the TGT
and the service ticket is encrypted using the password hash of the service
account registered with the target SPN.
Once the authentication process with the KDC is complete
and the client has both a session key and a service ticket,
service authentication begins.
First, the client sends an application request, which includes the username and a
timestamp encrypted with the session key associated with the service ticket
along with the service ticket itself.
The service decrypts the service ticket using its own password hash,
extracts the session key from it, and decrypts the supplied username.
If the usernames match, the request is accepted.
Before access is granted, the service inspects the supplied group memberships
in the service ticket and assigns appropriate permissions to the user,
after which the user may make use of the service as required.
This protocol may seem complicated and perhaps even convoluted,
but it was designed to mitigate various network attacks
and prevent the use of fake credentials.
Now that we have explored the foundations of Kerberos authentication,
let’s look at how we can dump cached credentials with Mimikatz.