Kerberos

Autentication Process

  • Authentication Service (AS): Verifies client credentials and issues Ticket-Granting Tickets (TGTs).

  • Ticket-Granting Service (TGS): Provides service-specific tickets based on a valid TGT.

  • Client-Server Model: The AP-REQ (Authentication Protocol Request) message is used by a client to authenticate to a service after obtaining a service ticket (TGS).

When working with Kerberos on Linux, we need to use the target's DNS server or configure our host machine with the corresponding DNS entries for the domain we are targeting. That is, we need to have an entry in /etc/hosts and /etc/krb5.conf for the domain/Domain Controller before attacking it.

Download Kerbrute

Kerberos Linux Configuration

File: /etc/krb5.conf

In case the package krb5-user is already installed, we need to change the configuration file /etc/krb5.conf to include the following values:

File: /etc/hosts

This is the way I recommend to set up the /etc/hosts

Test to make sure everything is ok:

Awesome Wordlists

Pass the Hash

Pass the ticket

Windows

Linux

Tool: KeyTabExtract

Note: Linux machines store Kerberos tickets as ccache files in the /tmp directory.

Pass the ticket via HTTP

To authenticate as a user for HTTP interactions with a domain controller, you must first export the ticket and then utilize the /ptt option to import it into the current session. Subsequently, you can employ the -UseDefaultCredentials parameter to utilize the credentials linked to the PowerShell terminal, which in this instance corresponds to the ticket of the current user.

Example:

Kerberos authentication
Golden ticket as Tony.Ward

Pass the Key attack or OverPass the Hash

Mimikatz requires administrative rights to perform the Pass the Key/OverPass the Hash attacks, while Rubeus doesn't.

Kerberos User enumeration

Kerberos Password Spraying

Kerberos bruteforcing

Convert ccache file (linux) to kirbi file (windows) and vice versa

AS-REPRoasting

ASREPRoast is a security attack that exploits users who lack the Kerberos pre-authentication required attribute. Essentially, this vulnerability allows attackers to request authentication for a user from the Domain Controller (DC) without needing the user's password.

Requirements:

  • Lack of Kerberos pre-authentication: Target users must not have this security feature enabled.

  • Connection to the Domain Controller (DC): Attackers need access to the DC to send requests and receive encrypted messages.

Windows

Linux

Cracking

Persistence

if we find that we have GenericAll privileges on an account, instead of resetting the account password, we can enable the DONT_REQ_PREAUTH flag to make a request to get the hash of this account and try to crack it

AS-REP Roasting Usage in Red Team Operations:

  1. Persistence:

    • Red Teams may enable the DONT_REQ_PREAUTH flag on specific accounts to bypass pre-authentication requirements.

    • This allows attackers to regain access to accounts even after a password change.

    • It is particularly useful for establishing persistence on less-monitored devices, such as printers, which are often outside active monitoring scopes.

    • Accounts with this flag are commonly found on service accounts for legacy management applications, which the Blue Team might overlook.

  2. Privilege Escalation:

    • In some cases, attackers can modify account attributes without needing to know or reset the password.

    • Resetting passwords is risky because it has a high likelihood of triggering alerts.

    • Instead of resetting the password, attackers enable the DONT_REQ_PREAUTH flag and attempt to crack the account's password hash to gain access.

Kerberoasting

Kerberoasting focuses on the acquisition of TGS tickets, specifically those related to services operating under user accounts in Active Directory (AD), excluding computer accounts. The encryption of these tickets utilizes keys that originate from user passwords, allowing for the possibility of offline credential cracking.

  • Find for SPN services are executed by user accounts. (A user account has a password set by a human, which is much more likely to be predictable.)

  • COMPUTERNAME$ have 120 characters long randomly generated passwords. (Impossible to crack it)

Windows

Script to find SPN services are executed by users.

Rubeus.exe

  • /outfile:filename.txt Output on file.

  • /pwdsetafter and /pwdsetbefore whose password was set within a particular date helpful to find legacy accounts with a password set many years ago that is outside of the current password policy and relatively easy to crack.

  • /stats useful for gathering information and checking the types of encryption the account tickets use.

  • /tgtdeleg force rubeus to return RC4 tickets.

AES-128 (type 17) and AES-256 (type 18) can be significantly more difficult to crack than RC4 (type 23) tickets.

Kerberoasting without an Account Password

Requirements:

  • User with NotPreAuthentication

  • Target SPN or a list of SPNs.

  • Use a createnetonly cmd of rubeus

Note: Instead of /spn we can use /spns:listofspn.txt to try multiple SPNs.

Linux

Cracking

Persistence

Unconstrained Delegation

Unconstrained Delegation on Computers

If we are able to compromise a server that has unconstrained delegation enabled, and a Domain Administrator subsequently logs in, we will be able to extract their TGT and use it to move laterally and compromise other machines, including Domain Controllers.

If you user possesses SeMachineAccountPrivilege and SeEnableDelegationPrivilege you can add a fake computer and abuse unconstrained delegation.

Printer Bug

If an attacker compromised a host configured with unconstrained delegation and has the spool service running.

The attacker might coerce a target domain to authenticate back to the compromised host and retrieve the TGT for domain controller for subsecuenlty perform a DCSync attack.

If the target computer is not a domain controller, An attacker can use S4U2self to obtain a Service Ticket on behalf of any user we want to impersonate.

Unconstrained Delegation on Users

Requirements:

  1. Compromise account with Unconstrained Delegation

  2. User with GenericWrite over the compromise account

  • Create a DNS record pointing to our attack machine, representing a fake computer in the Active Directory environment.

  • Add the SPN CIFS/our_dns_record to the compromised account, which has unconstrained delegation.

  • When a victim tries to connect via SMB to our fake machine, it will send a copy of its TGT in the TGS ticket as it requests a ticket for CIFS/our_dns_record.

  • The TGS ticket will be sent to the IP address registered in the DNS record, which is our attack machine.

  • Extract the TGT from the received TGS ticket and use it to perform a DCSync Attack

Constrained Delegation

In constrained delegation, delegation is only allowed for a specific list of SPNs. If an attacker has compromised a service account with constrained delegation, they can relay received authentication attempts to one or more SPNs in the list.

  • Restricts the service to impersonate a user only for specific services.

  • Instead of sending the TGT, a special TGS ticket is issued for allowed services.

Impersonate Any User

If this constrained delegation allows protocol transition, we can pretend to be anyone, arbitrarily, to authenticate against these services.

We can use the S4U2Self extension if protocol transition is enabled. It allows a service to obtain a forwardable service ticket to itself on behalf of any user.

Since we can retrieve a TGS ticket as any user, we can perform the previous attack without waiting for anyone's authentication.

The account DMZ01$ has TRUSTED_TO_AUTH_FOR_DELEGATION with protocol transition set, and the only allowed service for delegation is www/WS01.inlanefreight.local.

User possesses GenericAll over Computer leads to Constrained Delegation

Resource-Based Constrained Delegation (RBCD)

Use bloodhound to enumerate the domain controller and search for WriteAccountRestriction.

To carry out attacks against RBCD, we require two elements:

  1. Access to a user or group that has privileges to modify the msDS-AllowedToActOnBehalfOfOtherIdentity property on a computer. This is commonly possible if the user has GenericWrite, GenericAll, WriteProperty, or WriteDACL privileges on a computer object.

  2. Control of another object that has an SPN. (The simplest way to obtain an object with SPN is to use a computer [Fake Computer])

From Windows

Script to find RBCD permission

Steps to carry out the attack:

  1. Create a computer.

  2. Obtain the computer SID.

  3. Use the Security Descriptor Definition Language (SDDL) to create a security descriptor.

  4. Set msDS-AllowedToActOnBehalfOfOtherIdentity in raw binary format.

  5. Modify the target computer.

Note: We can also use /altservice:host,RPCSS,wsman,http,ldap,krbtgt,winrm to include additional services to our ticket request.

Clear attribute

From Linux

Use bloodhound to enumerate the domain controller and search RBCD privilege to abuse.

RBCD from Linux When MachineAccountQuota Is Set to 0

If we are unable to create a computer account, or if the account we are targeting doesn't have an SPN, an attacker can still perform the attack.

RBCD Example 1:

The user ADM_PRJU possesses the permission to modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute associated with the MUCDC$ Computer.

Requirements

  • ADM_PRJU possesses the permission to modify msDS-AllowedToActOnBehalfOfOtherIdentity

  • Control an object that had a SPN. (We previously compromised a Linux machine FRAJMP$)

Kerberos Relay Attack

Requirenments:

  • LDAP signing not required on Domain Controller.

  • Ability to add computer account

Check to more information about the attack:

Using KrbRelay.exe

Tool: KrbRelay

Finally, use impacket-getST or Rubeus to ask for Ticket Granting ticket using S4u and perform the DCSyncAttack.

Using KrbRelayUp

Tool: KrbRelayUp

Finally, use impacket-getST or Rubeus to ask for Ticket Granting ticket using S4u and perform the DCSyncAttack.

Golden Ticket

The Golden Ticket attack lets attackers forge and sign TGTs (Ticket Granting Tickets) using the krbtgt account's password hash. When these tickets are presented to an AD server, the information within them is not checked and is considered valid because it is signed with the krbtgt account's password hash.

Forging a golden ticket is an excellent technique to maintain persistence within an AD environment. Once full domain compromise is achieved, an attacker can extract the NTLM hash of the krbtgt account using DCSync (or from the NTDS.DIT file using a variety of methods).

After a TGT (Ticket Granting Ticket) request, the domain controller sends the user their TGT. This TGT contains a PAC (Privilege Attribute Certificate), which includes information about the user's privileges. Each Service Ticket issued by the KDC contains a copy of the PAC, and the domain controller uses the krbtgt account key to sign these tickets.

An attacker can exploit the krbtgt key to decrypt any TGT, including its PAC, modify it to make it appear as though the user belongs to the administrators group, and then re-encrypt it using the krbtgt secret.

Requirements:

  1. Domain Name

  2. Domain SID

  3. Username to Impersonate

  4. KRBTGT's hash

From Windows

From Linux

Detection of Golden Tickets

Golden Tickets are challenging to detect because they are valid TGTs, and Windows event logs cannot distinguish between legitimate and maliciously crafted TGTs. Resetting the password of an impersonated account does not invalidate an existing Golden Ticket.

Key detection points include:

  1. Golden Tickets often have unusually long lifespans (e.g., Mimikatz defaults to 10 years). Certain Active Directory monitoring tools can flag these as Indicators of Compromise (IoCs).

  2. Anomalies in the account DOMAIN field, such as being blank or containing the fully qualified domain name (FQDN) instead of just the domain name.

To mitigate Golden Ticket persistence, the krbtgt account password must be changed twice to eliminate both the current and previous keys stored in the domain. It's also advisable to regularly rotate the krbtgt account password as part of standard security practices.

Silver Ticket

The Silver Ticket attack targets service tickets in Active Directory (AD) environments. This attack involves obtaining the NTLM hash of a service account, such as a computer account, and using it to forge a Ticket Granting Service (TGS) ticket. With the forged ticket, an attacker can impersonate any user to access specific services on the network, often aiming for administrative privileges.

The TGS ticket contains a PAC (Privilege Attribute Certificate), which includes details about the user's privileges and the SPN (Service Principal Name) of the requested service. This ticket is encrypted using the secret key of the service account associated with the SPN.

The attacker can forge a service ticket from scratch since they can create an arbitrary PAC and encrypt it with the secret stolen. Once this TGS ticket is forged, the attacker presents it to the service. The service can decrypt it because it has been encrypted with its own password, and then it will read the contents of the PAC. As the attacker has forged it, they can embed whatever information they desire, such as being a domain administrator. This forged ticket is called a Silver Ticket.

Requirements:

  • NTLM password's hash or keys for a service or machine account

  • Domain Name

  • Domain SID

  • Username to Impersonate

Silver tickets allow you to impersonate any user, including domain admins, but only within the context of the service tied to the compromised account’s SPN. The forged ticket is valid exclusively for that service, not for others like LDAP or CIFS, unless they share the same service account.

From Windows

Create a Silver Ticket , save it in sql01.kirbi and use PSExec.

From Linux

Detection

Silver Tickets are more limited when compared to Golden Tickets because their scope is only for the service that is being targeted on a specific host. However, they can be utilized to remain stealthier. Silver Tickets can be used for persistence when used to access computer-hosted services. Since computer account password rotation may be disabled, and AD does not prevent computer accounts from accessing resources, this type of Silver Ticket could likely be used for a very long time.

Silver Tickets forged with Mimikatz can be detected in a few ways.

  • The account DOMAIN field is blank.

  • The account DOMAIN field contains DOMAIN FQDN instead of just domain.


S4U CheatsheetS4U Basics

  • S4U (Service for User): Allows a trusted account to impersonate users via Kerberos.

  • Tools: Rubeus (Windows), Impacket (Linux).

  • Requires: Delegation permissions (RBCD, Unconstrained, or Constrained).

S4U2Self

  • What: Gets a ticket for yourself impersonating another user (e.g., Administrator -> KRBRELAYUP$).

  • Purpose: Prepares impersonation (step 1).

  • Output: TGS (not usable directly for services).

S4U2Proxy

  • What: Uses S4U2Self ticket to get a ticket for a specific service (e.g., Administrator -> HOST/brunodc).

  • Purpose: Access a service (step 2).

  • <spn>: e.g., HOST/brunodc, ldap/brunodc.

  • Output: TGS usable for the service (e.g., SMB, LDAP).

Delegation Types

  1. RBCD (Resource-Based Constrained Delegation)

    • Permission: msDS-AllowedToActOnBehalfOfOtherIdentity on target (e.g., brunodc$ lists KRBRELAYUP$).

    • Check: Get-ADComputer brunodc -Properties msDS-AllowedToActOnBehalfOfOtherIdentity.

    • Use Case: Control a specific resource (e.g., DC).

    • S4U: Impersonate to target’s services (e.g., HOST, ldap).

  2. Unconstrained Delegation

    • Permission: TRUSTED_FOR_DELEGATION (userAccountControl = 524288).

    • Check: Get-ADComputer WEB01 -Properties userAccountControl.

    • Use Case: Full domain takeover if you capture a TGT.

    • S4U: Impersonate to any service after capturing a TGT (e.g., ldap, CIFS).

  3. Constrained Delegation

    • Permission: msDS-AllowedToDelegateTo lists SPNs (e.g., MSSQLSvc/sql01:1433).

    • Check: Get-ADUser SVC-SQL -Properties msDS-AllowedToDelegateTo.

    • Use Case: Access specific services only.

    • S4U: Impersonate to listed SPNs (e.g., MSSQLSvc).

When to Use

  • RBCD: You control a machine account and target a specific resource (e.g., DC).

    • Ex: Escalate via KrbRelayUp to DCSync.

  • Unconstrained: You capture a TGT from an admin on a server.

    • Ex: Monitor a web server for admin logins.

  • Constrained: You have a service account tied to a specific SPN.

    • Ex: Access SQL as an admin.

Last updated