Lab Objective:

• Learn the Kerberos process, where it is used, and what services/protocols are required.
• Learn to exploit the condition where Kerberos Pre-Authentication is not enabled on a user account.
  • This exploitation process is called AS-REP Roasting.

Kerberos: What’s up with that?

• Kerberos is primarily utilized on Active Directory networks for authentication.
  • When you sit down in front of a computer that is a domain client, and you type your username/password to log in, the Kerberos authentication process will determine the following:
    • Is your username/password valid?
    • What permissions and rights do you have on the network?
    • If you have any group memberships that provide additional access or restrictions.
    • Whether you have access to specific resources or services on the network.
• Kerberos will do this through the use of tickets.
  • It’s important to remember that a user can be granted different types of tickets.
    • In this lab, we’ll look at the TGT (Ticket Granting Ticket)

Highly Recommended:

You should watch this video and revisit it several times to understand the Kerberos process. I know it as well as I do because I’ve watched VBScrub’s video multiple times and given it time and thought.

• VBSCRUB Kerberos Authentication Process

VBScrub has several videos that explain different types of attacks against Kerberos, but the video linked above explains what happens within an Active Directory environment when you try to gain access to a resource.

Here’s what happens when you enter your username/password on a domain client.

• The password you type in is converted to an NTLM hash.

  • The current time on your local computer is captured.
  • The current time is then encrypted using your NTLM hash
  • This encrypted timestamp is sent to the KDC (Key Distribution Center)
    • The KDC on Active Directory networks is always the Domain Controller

• The Domain Controller (KDC) receives this timestamp encrypted with an NTLM hash.

  • The KDC knows what the user’s NTLM hash should be.
    • Remember, this value is stored in the ntdis.dit file
  • The KDC uses the NTLM hash for your user and attempts to decrypt the value you sent.
    • The decrypted value should be a plaintext timestamp.
    • The KDC will compare this timestamp to the current time on the Domain Controller.
    • If the two timestamps are close, it will assume the user is attempting to authenticate typed in the correct password.
      • (Key Sec+ Concept): Network Time Protocol (NTP) is an important component of Active Directory networks because of this check. Clocks need to be synchronized.

• Once the KDC has verified that the correct password was typed in via this timestamp comparison, it will send back two things:

  • A randomly generated ‘session key’ that is encrypted using the user’s NTLM HASH
  • A ‘Ticket Granting Ticket’ (TGT) containing fields like:
    • Username
    • Time authenticated
    • Validity Period
    • Authorization Data (What groups are you a part of?)
  • This TGT is encrypted using the NTLM hash of the KRBTGT account, which will always have a super long, super complex password. The user cannot decrypt the TGT, but they can send it back to the Domain Controller later.
    • When the user returns this TGT to the Domain Controller later, the Domain Controller (KDC) can decrypt the TGT to verify its contents.

  That’s a lot, and it’s only just the tip of the iceberg!

  Here’s a summary:

  • You authenticate by encrypting the time with the NTLM hash of your password.
  • The KDC (Domain Controller) verifies the encrypted timestamp.
  • The KDC sends back
    • A session key encrypted with the user’s NTLM hash
      • The user can decrypt this session key
    • A TGT the user can not decrypt
      • This TGT can only be decrypted by the Domain Controller later.

  The process above is the default on Active Directory networks.

  • However, administrators can check a box within a User’s properties that removes the first step of the Kerberos process as a requirement.

    • The checkbox looks like this:

    

    • The Kerberos process is much less secure when this box is checked on a user’s account.

What happens when ‘Do not require Kerberos preauthentication’ is checked within a User’s account options?

• The user is no longer required to encrypt a timestamp with the NTLM hash of the password typed in and send it to the KDC (Domain Controller) for verification before receiving a TGT and an encrypted session key.
• The user says to the Domain Controller:
  • Hey there! Send me a session key encrypted with the NTLM hash of the user I am claiming to be and a TGT containing all the things the user can do encrypted with your KRBTGT super strong password.
• Without any initial verification:
  • The user will have a session key encrypted with the user’s actual password hash.
    • If the end user doesn’t know the user’s password, they won’t be able to decrypt the session key, which is required. The user must be able to decrypt this value to use the TGT later.
  • They will have a TGT encrypted with the KRBTGT account password, which is always super-strong and complex.

If you are scratching your head a bit now, that’s fine. You have to revisit this topic and think about it to figure Kerberos out. (Nobody truly gets it the first time out of the gate!)

Exploit a user with the ‘Do not require Kerberos preauthentication’ set.