AD Kerberos

With the completion of recon you should have the list of users/accounts, groups and SPNs within the domain. With this information you should be able to compromise all the systems within the domain by cracking the authentication.

NTLM Authentication

NTLM authentication is used when a client authenticates to a hostname that is not registered with the Active Directory or the user uses IP address for authentication. The authentication process is as follows,

1. Calculate a cryptographic hash, called the NTLM hash, from the user's password

2. Client submits the username and the server in turn responds with a nonce

3. Client then encrypts the nonce with the NTLM hash

4. The server then sends the username and encrypted nonce to the domain controller to validate the user

5. The domain controller encrypts the nonce with the NTLM hash of the user

Kerberos Authentication

In Kerberos authentication the Domain Controller acts as the key distribution center for the authentication of a client to a service. The authentication process is as follows,

Stage 1 - Client to Domain Controller (Initial Authentication)

1. Authentication server request comprising of the time stamp encrypted using the hash derived from the username and password is sent by the client to the DC

2. If request is successfully decrypted, then the DC responds with Authentication Server Reply that contains a session key and a Ticket Granting Ticket (TGT)

3. TGT contains - Group memberships, domain, time stamp, IP address of client & session key

4. TGT is encrypted by the secret key known only to the KDC

Stage 2 - Client to Domain Controller (Service Access)

When the user whishes to access a service on the domain, then the user has to explicitly request for a new ticket that will grant the user access to the desired service. The end goal of this process is to gain a service ticket and a session key for communicating with the SPN.

1. The user sends a Ticket Granting Service Request containing - user details + time stamp(encrypted using session key) + SPN of the resource + Encrypted TGT

2. If the requested SPN exists, then,

   1. Decrypt the TGT to get the session key

   2. Use the session key to extract the username + timestamp

3. The DC responds with the Ticket Granting Server Reply containing - (SPN & SPN Session key) encrypted using TGT session key + (Service ticket) encrypted using SPN password hash

   1. The service ticket also contain details about the group membership

Stage 3 - Client to SPN

Only at stage 3 does an user actually start communication with the SPN.

1. User sends an application request to the SPN that contains the username & timestamp encrypted with the session key and the service ticket

2. SPN decrypts the service ticket using the service account password to extract the username and session key

3. The session key is used to decrypt the application request to extract the username. Only if the username matches with the username in the service ticket will the process progress

4. The SPN also checks for the group memberships in the service ticket before granting access

Now, from the above process the things that we can aim for,

• Get a TGT and try to break it to find the password of the Ticket Granting Server

• Get a service ticket and try to break it to find the password of the SPN

With both the information the user becomes unstoppable within a domain as the user can grant oneself access to any SPN and include the necessary groups.