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).
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
If you compromise a Linux server as root user try to obtain/etc/krb5.keytab to extract NT hash computer account. Computer accounts can be used to enumerate the domain controller, run bloodhound or use it to abuse of RBCD attacks.
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:


Pass the Key attack or OverPass the Hash
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:
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.
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
executedbyuser 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.txtOutput on file./pwdsetafterand/pwdsetbeforewhose 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./statsuseful for gathering information and checking the types of encryption the account tickets use./tgtdelegforce rubeus to return RC4 tickets.
Kerberoasting without an Account Password
Requirements:
User with NotPreAuthentication
Target SPN or a list of SPNs.
Use a createnetonly cmd of rubeus
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:
Compromise account with Unconstrained Delegation
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)
The easiest way to get a SPN either Computer or Fake Computer. If you compromise one as root/NT Authority System get the NT hash.
To carry out attacks against RBCD, we require two elements:
Access to a user or group that has privileges to modify the
msDS-AllowedToActOnBehalfOfOtherIdentityproperty on a computer. This is commonly possible if the user hasGenericWrite,GenericAll,WriteProperty, orWriteDACLprivileges on a computer object.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:
Create a computer.
Obtain the computer SID.
Use the Security Descriptor Definition Language (SDDL) to create a security descriptor.
Set
msDS-AllowedToActOnBehalfOfOtherIdentityin raw binary format.Modify the target computer.
Clear attribute
From Linux
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:

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.
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:
Domain NameDomain SIDUsername to ImpersonateKRBTGT'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:
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).
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 NameDomain SIDUsername to Impersonate
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
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).
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).
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