• HTTP: Since the WinRM service uses the HTTP service, if the attacker impersonates an administrative user (e.g., Domain Admin) to the HTTP service of a computer, and the machine has WinRM enabled, the attacker could authenticate to it.

Often an error related to a missing “Logon Session” occurs; in that case, retry the attack ensuring that the command exploiting Kerberos Delegation is executed from a shell with a High Integrity Level Token and that no additional Tickets have been previously injected into that Logon Session; after that, try logging in both via PowerShell Remoting (Enter-PSSession, New-PSSession, and Invoke-Command) and WinRS; using this method, logging in usually succeeds.

In conclusion, broadly speaking, if an attacker compromises a machine (or a domain user acting as a Service Account) with “Constrained Delegation (Use any authentication Protocol)” enabled, they can also compromise the machine (usually via CIFS) that the compromised system is authorized (via the “msds-allowedtodelegateto” flag) to access on behalf of the Client.

Abuse Protocol Transition (Computer) - Windows

In this scenario, we will see how to exploit a Constrained Delegation (Use any authentication Protocol) (also called Protocol Transition) from a Windows machine.

1. Identify which Service Accounts have “Constrained Delegation (Use any authentication Protocol)” enabled (in this scenario, we are looking for Computer Accounts acting as Service Accounts).

   There are different methods to identify which Service Accounts have “Constrained Delegation (Use any authentication Protocol)”; on Windows, one of the most common is using “PowerView”:

   PS C:> Get-DomainComputer --TrustedToAuth
   

   

   As you can see, the Computer Account THEPUNISHER$ has the “TRUSTED_TO_AUTH_FOR_DELEGATION” flag and therefore has Constrained Delegation (Use any authentication Protocol) enabled; specifically, this account (so THEPUNISHER$) and therefore ALL services running under it will be able to authenticate on behalf of the Client exclusively to the SPN “HTTP/SPIDERMAN,” so to the HTTP service of the SPIDERMAN machine.

   Indeed, inspecting the “Delegation” tab of the THEPUNISHER computer via ADUC, we will find this configuration.

   

2. The attacker compromises the Service Account with Constrained Delegation (Use any authentication Protocol) enabled.

   In this scenario, the attacker managed to authenticate with administrative privileges to the THEPUNISHER machine and, by dumping LSASS, obtained the credentials of the Computer Account THEPUNISHER$, so the Service Account with the Constrained Delegation (Use any authentication Protocol) enabled.

   

3. The attacker obtains a valid TGS Ticket (for Domain Admin) to authenticate to the CIFS service hosted on the SPIDERMAN machine (that is, the machine authorized in the “msds-allowedtodelegateto” flag).

   The attacker, now possessing the credentials of the Service Account THEPUNISHER$, since this account has “Constrained Delegation (Use any authentication Protocol)”, can abuse it to invoke the S4U2Self & S4U2Proxy extensions and thus obtain a TGS Ticket belonging to a Domain Admin user valid to access the HTTP service of the SPIDERMAN machine (so, the service specified in the “msds-allowedtodelegateto” flag); furthermore, in this scenario the attacker decides to replace the SPN “HTTP/SPIDERMAN” with the SPN “CIFS/SPIDERMAN”, managing in this way to authenticate via PsExec to the SPIDERMAN machine.

   Since we will inject the desired TGS Ticket into memory, first of all we use the so-called Sacrificial Process.

   C:> Rubeus.exe createnetonly /program:"C:\Windows\System32\cmd.exe" /show
   

   

   Then execute the following Rubeus command within the Sacrificial Process.

   C:\> Rubeus.exe s4u /impersonateuser:<User_To_Impersonate> /msdsspn:<SPN_inside_in_msds-allowedtodelegateto> /altservice:<Desired_SPN> /user:<Service_Account> /rc4:<NTLM_Service_Account> /nowrap /ptt
   

   Let’s analyze ALL the operations performed by Rubeus.

   1. Rubeus sent a “KRB_AS_REQ” to obtain the TGT Ticket of the Computer Account THEPUNISHER$, information necessary to invoke the “KRB_TGS_REQ (S4USelf)”.

      
      

   2. Rubeus now, having the TGT Ticket of the Computer Account “THEPUNISHER$”, sends a “KRB_TGS_REQ (S4U2Self)” to obtain a TGS Ticket on behalf of the user “MARVEL\Administrator” (Domain Admin) valid for the service itself.

      

      As we can note Rubeus sends a “KRB_TGS_REQ (S4U2Self)”, analyzing the packet content one can observe that: 1) Inside the “PA-FOR-USER” data structure the request for the TGS Ticket on behalf of the user “MARVEL\Administrator” (it’s a Domain Admin) is effectively present 2) The Computer Account THEPUNISHER$ is expressly indicated, in this way the issued TGS Ticket will be valid for ALL services started by that Service Account.

      

      The KDC verifies that the Service Account THEPUNISHER$ has the “TRUSTED_TO_AUTH_FOR_DELEGATION” flag, and since the result is positive, the KDC issues the requested TGS Ticket (which belong to the user MARVEL\Administrator" & is valid for ALL services started by that Service Account), furthermore, i remind you that such a TGS Ticket issued in this positive case will have the “FORWARDABLE” flag set to “1”.

      

   3. Rubeus now that it has the TGS Ticket (belonging to the user MARVEL\Administrator") valid for the service itself, will be able to use it as “evidence” to invoke the “KRB_TGS_REQ (S4UProxy)”, in this way the attacker will obtain a TGS Ticket (still belonging to the user MARVEL\Administrator) valid for the HTTP service exposed on the SPIDERMAN machine (HTTP/SPIDERMAN), finally, Rubeus will replace the HTTP service with the CIFS service, obtaining a TGS Ticket (still belonging to the user MARVEL\Administrator") valid for the CIFS service exposed on the SPIDERMAN machine.

      

      As we can see Rubeus sends a “KRB_TGS_REQ (S4UProxy”, analyzing the content of the packet it can be ascertained that: 1) Inside the “Additional Ticket” field the TGS Ticket previously received in the “S4USelf Response” is indeed sent 2) The SPN that points to the service which the compromised machine (Computer Account THEPUNISHER$) is authorized to access on behalf of the Client (indicated in the “msds-allowedtodelegateto” flag) is indicated, in fact the SPN “HTTP/SPIDERMAN.MARVEL.local” is present

      

      The KDC verifies if the TGS Ticket received inside the “additional-tickets” field (in addition to being valid) has the “FORWARDABLE” flag set to “1” & that inside the “msds-allowedtodelegateto flag” parameter of the Service Account THEPUNISHER$ the requested service is present, (so is in this case “HTTP/SPIDERMAN.MARVEL.local”), since the outcome is positive for both checks (1, 2), the KDC issues a TGS Ticket (belonging to the user MARVEL\Administrator") valid for the HTTP service exposed on the SPIDERMAN machine (furthermore, as for any other valid TGS Ticket this one will also have the “FORWARDABLE” flag set to “1”).

      

      Finally, Rubeus will modify the SPN field of the received TGS Ticket, replacing the HTTP service with the desired CIFS service, in this way the output TGS Ticket (belonging to the user MARVEL\Administrator") will have as SPN “CIFS/SPIDERMAN” and will therefore be valid for the CIFS service exposed on the SPIDERMAN machine, having done this Rubeus imports that Kerberos Ticket into memory.

      If the attacker does NOT wish to replace the service of the TGS Ticket obtained via S4UProxy they will simply NOT include the “altservice” parameter on Rubeus command, consequently, in this context we will obtain a TGS Ticket (belonging to the user MARVEL\Administrator") valid for the HTTP service present on the SPIDERMAN machine.

As you can see, following the Rubeus command we will have cached in memory a TGS Ticket belonging to the “Administrator” user valid for the CIFS service of the SPIDERMAN machine; in fact, performing a Network Logon with “PsExec” the OS will retrieve the cached TGS Ticket and use it to perform the authentication; in this way the attacker has succeeded in authenticating with administrative permissions to the SPIDERMAN computer.

The LogonID in this screenshot is different from that of the Sacrificial Process previously indicated simply because i have repeated this lab infinite times.

If you encounter an authentication error, try re-running the command by adding the “msdsspn” parameter with a value that does not include the domain suffix, changing from “SPIDERMAN.MARVEL.local” to “SPIDERMAN”; in both cases it should still work because both values are present within the “msds-allowedtodelegateto” property, additionally, ensure that the same domain naming used in “msdsspn” is applied in the PsExec command (in this case), so if, for example, you request a TGS Ticket to access the SPIDERMAN.MARVEL.local machine, use the same naming to connect via PsExec.

Abuse Protocol Transition (User) - Windows

Although Kerberos Delegation is typically applied to a “Computer Account” type Service Account, it can, (although it’s a rare configuration) also be applied to a “User” type Service Account (a traditional domain user).

If we identify a “User” type Service Account (a traditional domain user) with “Constrained Delegation (Use any authentication Protocol)” enabled, it is possible to execute the same steps previously seen to abuse this configuration.

In other words, if an attacker compromises a domain user acting as a Service Account and has “Constrained Delegation (Use any authentication Protocol)” enabled, the attacker, impersonating this Service Account (domain user), could invoke the “S4U2Self” & “S4U2Proxy” extensions and thereby obtain a TGS Ticket belonging to ANY domain user and valid to access ANY (usually) Back-End service for which the Service Account (domain user) has authorization to access on behalf of the Client (as indicated in the “msds-allowedtodelegateto” flag).

To save both my and your lifetime, instead of re-executing ALL the following steps as previously done, i will report only the essential steps:

1. Identify which Service Accounts have “Constrained Delegation (Use any authentication Protocol)” enabled (in this scenario, we are looking for a “User” type object, so a traditional domain user acting as a Service Account).

   PS C:\> Get-DomainUser --TrustedToAuth
   

   

   As you can see, the “User” (traditional domain user) delegationuser has the “TRUSTED_TO_AUTH_FOR_DELEGATION” flag and therefore has Constrained Delegation (Use any authentication Protocol) enabled; specifically, this user (so “delegationuser”) and therefore ALL services started with it (in this case the “delegationuser” Service Account has the SPN LDAP/WORKSTATION01 so it will run only the LDAP service on that machine) will be able to authenticate on behalf of the Client exclusively to the SPN “HTTP/SPIDERMAN”, so, to the HTTP service of the SPIDERMAN machine.

   Indeed, inspecting the “Delegation” tab of the “User” delegationuser via ADUC, you will find this configuration.

   
   

2. The attacker compromises the Service Account with Constrained Delegation (Use any authentication Protocol) enabled.

   In this scenario, the attacker has managed to obtain, for example via Password Spray, the credentials of the “delegationuser” account, so the Service Account with Constrained Delegation (Use any authentication Protocol) enabled.

3. The attacker obtains a TGS Ticket (of a Domain Admin) valid to authenticate to the CIFS service hosted on the SPIDERMAN machine (that is, the machine authorized in the “msds-allowedtodelegateto” flag).

   The attacker, now possessing the credentials of the “delegateduser” Service Account, since it has “Constrained Delegation (Use any authentication Protocol)”, can abuse it to invoke the S4U2Self & S4U2Proxy extensions and thus obtain a TGS Ticket belonging to a Domain Admin user valid to access the HTTP service of the SPIDERMAN machine (so, the service specified by “msds-allowedtodelegateto” flag); furthermore, in this scenario, the attacker decides to replace the SPN “HTTP/SPIDERMAN” with the SPN “CIFS/SPIDERMAN”, managing in this way to authenticate via PsExec to the SPIDERMAN machine.

   Since we will inject the desired TGS Ticket into memory, we first use the socalled Sacrificial Process, then execute the following Rubeus command within the Sacrificial Process.

   C:\> Rubeus.exe s4u /impersonateuser:<User_To_Impersonate> /msdsspn:<SPN_inside_in_msds-allowedtodelegateto> /altservice:<Desidered_SPN> /user:<Service_Account> /rc4:<NTHash_Service_Account> /nowrap /ptt
   

Let’s analyze in summary all the operations performed by Rubeus.

1. Rubeus sent a “KRB_AS_REQ” to obtain the TGT of the Service Account (domain user) delegateduser, information necessary to invoke the “KRB_TGS_REQ (S4USelf)” (it happens regardless of whether the Service Account is a Computer Account or a traditional domain user).

   

2. Rubeus now, having the TGT Ticket of the “User” delegationuser, sends a “KRB_TGS_REQ (S4USelf)” to obtain a TGS Ticket on behalf of the “MARVEL\Administrator” user (Domain Admin) valid for the service itself.

   

3. Rubeus now that it has the TGS Ticket (belonging to the “MARVEL\Administrator” user) valid for the service itself, will be able to use it as “evidence” to invoke the “KRB_TGS_REQ (S4UProxy)”; in this way the attacker obtains a TGS Ticket (still belonging to the “MARVEL\Administrator” user) valid for the HTTP service exposed on the SPIDERMAN machine (HTTP/SPIDERMAN), finally, Rubeus will replace the HTTP service with the CIFS service, obtaining a TGS Ticket (still belonging to the “MARVEL\Administrator” user) valid for the CIFS service exposed on the SPIDERMAN machine.

   

As you can see, following the Rubeus command we will have cached in memory a TGS Ticket belonging to the “Administrator” user valid for the CIFS service of the SPIDERMAN machine; in fact, when performing a Network Logon with “PsExec” the OS will retrieve the cached TGS Ticket and use it for authentication; in this way, the attacker has successfully authenticated with administrative privileges to the SPIDERMAN machine.

Abuse Protocol Transition (Computer) - Linux

In this scenario we will see how to exploit a Constrained Delegation (Use any authentication Protocol) (also called Protocol Transition) from a Linux machine.

1. Identify which Service Accounts have “Constrained Delegation (Use any authentication Protocol)” enabled (in this scenario we are looking for Computer Accounts acting as Service Accounts)

   There are different methods to identify which Service Accounts have “Constrained Delegation (Use any authentication Protocol)”, on Linux one of the most common is using “findDelegation”:

   PS C:\> impacket-findDelegation -dc-ip <DC_IP> <domain><user>:<password>
   

   

   This tool will perform an LDAP query to the DC and return as a result ALL the Service Accounts that have been configured with Kerberos Delegation, specifically:

   • AccounType: Indicates if the Service Account in question is a Computer Account or a traditional domain user account

   • DelegationType: Indicates which type of Kerberos Delegation has been configured for that specific Service Account

     • Unconstrained: Unconstrained Delegation
     • Constrained: Constrained Delegation (Kerberos Only)
     • Constrained w/ Protocol Transition: Constrained Delegation (Use any authentication Protocol) (also called Protocol Transition)
     • Resource-Based Constrained: Resource Based Constrained Delegation (RBCD)

   • DelegationRightsTo: Indicates that the Service Account present in AccountName has permissions to authenticate on behalf of the Client to that system.

     In Unconstrained & Constrained Delegation it reports the value contained in the property “msds-allowedtodelegateto” of the Service Account contained in the “AccountName” column. In RBCD instead it reports the Service Account that has within its ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity property the Service Account contained in the “AccountName” column.

2. The attacker compromises the Service Account with Constrained Delegation (Use any authentication Protocol) enabled.

   In this scenario the attacker succeeded in authenticating with administrative privileges to the machine THEPUNISHER and, by dumping the LSA Secrets, obtained the credentials of the Computer Account THEPUNISHER$, that is, the Service Account with Constrained Delegation (Use any authentication Protocol) enabled.

   

3. The attacker obtains a TGS Ticket (of a Domain Admin) valid to authenticate to the CIFS service hosted on the machine SPIDERMAN (so, to the machine authorized in the “msds-allowedtodelegateto” flag)

   The attacker now that he possesses the credentials of the Service Account THEPUNISHER$, given that this one has “Constrained Delegation (Use any authentication Protocol)”, can impersonate it to invoke the S4U2Self & S4U2Proxy extensions and thus obtain a TGS Ticket belonging to a Domain Admin user valid to access the HTTP service of the machine SPIDERMAN (so, what is specified in the “msds-allowedtodelegateto” flag), furthermore, in this scenario the attacker decides to replace the SPN “HTTP/SPIDERMAN” with the SPN “CIFS/SPIDERMAN” thereby managing to authenticate via PsExec to the machine SPIDERMAN.

   To perform this it is possible to use the impacket getST tool, specifically with the following command:

   # impacket-getST -spn <SPN_within_in_msds-allowedtodelegateto> '<domain>/<Service_Account>' -impersonate <User_To_Impersonate> -dc-ip <DC_IP> -hashes <LMHash>:<NTHash> -altservice <SPN_desired>
   

   

   Let’s SUMMARILY analyze all the operations performed by getST.

   1. Impacket getST, since it does NOT find a “.cache” file related to the Service Account’s TGT Ticket, sends a “KRB_AS_REQ” to obtain precisely the TGT Ticket of the Computer Account THEPUNISHER$, information necessary to invoke the “KRB_TGS_REQ (S4USelf)”

      

   2. Impacket getST, now that it has the TGT Ticket of the Computer Account “THEPUNISHER$”, sends a “KRB_TGS_REQ (S4USelf)” to obtain a TGS Ticket on behalf of the user “MARVEL\Administrator” (Domain Admin) valid for the service itself.

      

   3. Impacket getST now that it has the TGS Ticket (belonging to the user MARVEL\Administrator") valid for the service itself, it can use it as “evidence” to invoke the “KRB_TGS_REQ (S4UProxy)”, in this way the attacker will obtain a TGS Ticket (still belonging to the user MARVEL\Administrator") valid for the HTTP service exposed on the machine SPIDERMAN (HTTP/SPIDERMAN).

      

      Finally, Impacket getST will modify the SPN field of the received TGS Ticket, replacing the HTTP service with the desired CIFS service, in this way the output TGS Ticket (belonging to the user MARVEL\Administrator") will have as SPN “CIFS/SPIDERMAN” and will therefore be valid for the CIFS service exposed on the machine SPIDERMAN, after that getST will export that Kerberos Ticket in the form of a file “<user>@<service>_<hostname>@<domain>.ccache”; indeed we will have a file called “Administrator@CIFS_SPIDERMAN@MARVEL.LOCAL.ccache”

      

   If the attacker does NOT wish to replace the service of the TGS Ticket obtained via S4UProxy they will simply NOT insert the “altservice” parameter, consequently, in this context we will obtain a TGS Ticket (belonging to the user MARVEL\Administrator") valid for the HTTP service present on the machine SPIDERMAN (usefull for a potential WinRM Service running and present on the SPIDERMAN machine).

Now we could, for example, use the Impacket suite to access the machine SPIDERMAN via PsExec; in this example we will use Impacket’s “psexec” (you can also use “smbexec.py”), therefore you need to set an environment variable named “KRB5CCNAME” and make it contain the file just created, so the TGS Ticket.

# export KRB5CCNAME=./<user>@<service>_<hostname>@<domain>.ccache

Then use, for example, Impacket’s “PsExec” to perform the authentication, in this way the attacker will manage to authenticate with administrative privileges to the machine SPIDERMAN.

# impacket-psexec -k -no-pass <hostname>

In the lab, the LINUX machine is NOT domain-joined, as it simulates an attacker who managed to connect to the network with their own Linux attacking machine, and therefore, even if NOT domain-joined, it still has connectivity to the DC; to bypass this issue, the target hostname resolution must be set in the “/etc/hosts” file.

Abuse Protocol Transition - Detect & Mitigation

Detect

Ask your SIEM / Detection Engineer to create a detection rule ad hoc 😝

Jokes aside, for an high overview i suggest you to start using an Identity Monitoring Solution (e.g. Defender for Identity) and only after that to perform a deep dive into a custom rule.

Mitigation

Although this type of attack cannot be completely prevented since it exploits how Kerberos Delegation works, there are some mitigations that can help avoid serious impacts following an Abuse Protocol Transition attack; these generally work by applying protection to domain accounts, ensuring that they CANNOT be delegated.

This can be achieved using the following measures:

• Configure the property “Account is sensitive and cannot be delegated” on privileged accounts.

  

  This configuration will set the NOT_DELEGATED flag (contained in the “UserAccountControl” property) of the account to “1”, and therefore this account CANNOT be delegated.

  With the following command, which analyzes this flag, we can verify if it’s NOT set to 0 and therefore that this account can no longer be delegated:

  PS C:\> Get-ADUser -Identity <account> -Properties UserAccountControl | Select-Object @{Name='NOT_DELEGATED';Expression={($_.UserAccountControl -band 0x100000)}}
  

  

  This configuration will also work on the account with RID 500, with that i mean the local “Administrator” account of the DC which has also become a privileged domain account (since among the various groups it is also part of the Domain Admins group).

• Add privileged accounts to the “Protected Users Group”

  

  Accounts contained within the “Protected Users Group” will NOT be able to:

  1. Perform NTLM authentication (preventing them from becoming victims of NTLM Hash theft / NTLM Relay)  

  2. Use DES or RC4 encryption types in Kerberos Pre-Authentication (by enforcing only strong encryption types, the AS-REP Roasting attack will be mitigated, since the attacker often performs an encryption downgrade in such a scenario). 

  3. Be delegated in an Unconstrained Delegation, Constrained Delegation (Kerberos Only), Constrained Delegation (Use any authentication protocol) / Protocol Transition, or Resource-Based Constrained Delegation (RBCD)

  If a domain administrator configures all privileged accounts within this group, the attacker will therefore NOT be able to impersonate them in an Abuse Protocol Transition attack.

  If an account is part of the “Protected Users Group,” the DC will NOT indirectly assign the NOT_DELEGATED flag on the account property; simply being part of this group will make it impossible to delegate that account. The only exception is the account with RID 500, which, in order to be protected, must necessarily have the property “Account is sensitive and cannot be delegated” enabled (which sets the NOT_DELEGATED flag to 1).

Abuse Protocol Transition (User) - Linux

Although Kerberos Delegation is generally applied to a Service Account of type “Computer Account”, in reality, even if rarely, it can also be applied to a Service Account of type “User” (traditional domain user account).

If we identify a Service Account of type “User” (traditional domain user account) with “Constrained Delegation (Use any authentication Protocol)” enabled, it is possible to perform the same steps previously seen to abuse this configuration.

In other words, if an attacker compromises a domain user that acts as a Service Account and has “Constrained Delegation (Use any authentication Protocol)” enabled, the attacker, impersonating this Service Account (domain user), could invoke the S4U2Self & S4U2Proxy extensions and thus obtain a TGS Ticket belonging to ANY domain user and valid to access ANY (usually) back-end service that the Service Account (domain user) is authorized to access on behalf of the Client (indicated in the “msds-allowedtodelegateto” flag).

We therefore re-execute the same steps previously seen:

1. Identify which Service Accounts have “Constrained Delegation (Use any authentication Protocol)” enabled (in this scenario we are looking for an object of type “User”, so a traditional domain user, acting as a Service Account)

   There are different methods to identify which Service Accounts have “Constrained Delegation (Use any authentication Protocol)”, on Linux one of the most common is using “findDelegation”:

   PS C:> impacket-findDelegation -dc-ip <DC_IP> <domain><user>:<password>
   

   

   In summary, in our example, analyzing the output we identify that the traditional domain user “delegatiouser” has Protocol Transition enabled, specifically ALL services started with it (in this case the Service Account “User” has the SPN LDAP/WORKSTATION01 and therefore will run the LDAP service on that machine; the fact that this machine does NOT exist in my lab is irrelevant for the purpose of the exploitation) will be able to authenticate on behalf of the Client exclusively towards the SPN “HTTP/SPIDERMAN” & “HTTP/SPIDERMAN.MARVEL.local”, so to the HTTP service of the machine SPIDERMAN.

2. The attacker compromises the Service Account with Constrained Delegation (Use any authentication Protocol) enabled.

   In this scenario the attacker managed to retrieve, for example via Password Spray, the credentials of the user “delegationuser”, so the Service Account with Constrained Delegation (Use any authentication Protocol) enabled.

3. The attacker obtains a TGS Ticket (of a Domain Admin) valid to authenticate to the CIFS service hosted on the machine SPIDERMAN (so, to the machine authorized in the “msds-allowedtodelegateto” flag)

   The attacker now, having the credentials of the Service Account “delegateuser”, given that this one has “Constrained Delegation (Use any authentication Protocol)”, can impersonate it to invoke the S4U2Self & S4U2Proxy extensions and thus obtain a TGS Ticket belonging to a Domain Admin user valid to access the HTTP service of the machine SPIDERMAN (so, what is specified in the “msds-allowedtodelegateto” flag); furthermore, in this scenario the attacker decides to replace the SPN “HTTP/SPIDERMAN” with the SPN “CIFS/SPIDERMAN”, thereby managing to authenticate via PsExec to the machine SPIDERMAN.

   To perform this it is possible to use the impacket getST tool, specifically with the following command:

   # impacket-getST -spn <SPN_contenuto_in_msds-allowedtodelegateto> '<domain>/<Service_Account>' -impersonate <User_To_Impersonate> -dc-ip <DC_IP> -hashes <LMHash>:<NTHash> -altservice <SPN_desiderato>
   

   

   Let’s SUMMARILY analyze all the operations performed by getST.

   1. Impacket getST, since it does NOT find a “.cache” file related to the Service Account’s TGT Ticket, sends a “KRB_AS_REQ” to obtain precisely the TGT Ticket of the traditional domain user “delegationuser”, information necessary to invoke the “KRB_TGS_REQ (S4USelf)” (The Service Account’s TGT Ticket is necessary to invoke the “KRB_TGS_REQ (S4USelf)”, this is independent of whether the Service Account is a Computer Account or a traditional domain user).

      

   2. Impacket getST, now that it has the TGT Ticket of the “User” “delegationuser”, sends a “KRB_TGS_REQ (S4USelf)” to obtain a TGS Ticket on behalf of the user “MARVEL\Administrator” (Domain Admin) valid for the service itself.

      

   3. Impacket getST, now that it has the TGS Ticket (belonging to the user MARVEL\Administrator") valid for the service itself, can use it as “evidence” to invoke the “KRB_TGS_REQ (S4UProxy)”, in this way the attacker will obtain a TGS Ticket (still belonging to the user MARVEL\Administrator") valid for the HTTP service exposed on the machine SPIDERMAN (HTTP/SPIDERMAN).

      

      Finally, Impacket getST will modify the SPN field of the received TGS Ticket, replacing the HTTP service with the desired CIFS service, in this way the output TGS Ticket (belonging to the user MARVEL\Administrator") will have as SPN “CIFS/SPIDERMAN” and will therefore be valid for the CIFS service exposed on the machine SPIDERMAN; after that, getST will export this Kerberos Ticket in the form of a file “<user>@<service>_<hostname>@<domain>.ccache”; indeed, we will have a file called “Administrator@CIFS_SPIDERMAN@MARVEL.LOCAL.ccache”.

      

   If the attacker does NOT wish to replace the service of the TGS Ticket obtained via S4UProxy, they will simply NOT include the “altservice” parameter; consequently, in this context we will obtain a TGS Ticket (belonging to the user MARVEL\Administrator") valid for the HTTP service present on the machine SPIDERMAN (usefull for a potential WinRM Service running and present on the SPIDERMAN machine).

Now we could, for example, use the Impacket suite to access the machine SPIDERMAN via PsExec; in this example we will use Impacket’s “psexec” (you can also use “smbexec.py”), therefore you need to set an environment variable named “KRB5CCNAME” and make it contain the file just created, so the TGS Ticket.

# export KRB5CCNAME=./<user>@<service>_<hostname>@<domain>.ccache

Then use, for example, Impacket’s “psexec” to perform the authentication; in this way the attacker will manage to authenticate with administrative privileges to the machine SPIDERMAN.

# impacket-psexec -k -no-pass <hostname>

In the lab, the LINUX machine is NOT domain-joined, as it simulates an attacker who managed to connect to the network with their own Linux attacking machine, and therefore, even if NOT domain-joined, it still has connectivity to the DC; to bypass this issue, the target hostname resolution must be set in the “/etc/hosts” file.

Abuse RBCD via DACL

Several techniques exist to exploit RBCD, below we will analyze by far the most common.

Since the trigger of a “Resource Based Constrained Delegation (RBCD)” is based on “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity”, which is nothing more than a property of a “Secureable Objects”, if the attacker has write permissions on this property (e.g: GenericalAll, GenericWrite and so on), they could exploit a DACL Misconfiguration to configure an RBCD on an arbitrary target and potentially compromise it.

In summary, Active Directory contains entities called “Objects” (Computers, Users, OUs, GPOs, Files, etc.) which for the vast majority are “Secureable Objects”.

Secureable Objects are resources protected through Access Control and each “Secureable Object” has a Security Descriptor containing a DACL (Discretionary Access Control List) and a SACL (System Access Control list (SACL):

• The DACL (it contain a series of ACE - Access Control Entries) manages who can do what.
• The SACL (it contain a series of ACE - Access Control Entries) logs audit events.

When a “Secureable Object” performs an action within Active Directory toward another “Secureable Object” , the Domain Controller (that manages the AD) inspects the DACL to determine permissions and, consequently, if the action is allowed.

So a “DACL Misconfiguration” is simply a DACL containing ACLs that grant excessive permissions which could allows potential attacks, like in this case 😉​

An attacker in order to abuse RBCD via DACL requires 2 mandatory elements:

1. The attacker (impersonating a “Computer Account” or a “Domain User”) must have write permissions available (WriteProperty, Generic Write, Generic All, Write DACL, Write Owner, Own) on the attribute “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity” of an:

   • Object of type “Computer” (so the related Computer Account)

   • Object type “Users” (a traditional “Domain User” - must have an SPN set)

   In this way the attacker is able to configure an RBCD with an arbitrary value within the target’s attribute.

In my lab and i was not able to successfully compromise a “Users” Object.

2. The attacker needs to control an account that is capable of invoking the “S4USelf” and “S4UProxy” extensions in order to exploit the previously configured RBCD, this can be done with a:

   • “Computer Account”: Any “Computer Account” is able to arbitrary invoke the “S4USelf” and “S4UProxy”.

   • “Domain user”: Any “User” with a SPN setted is able to arbitrary invoke the “S4USelf” and “S4UProxy (unless the “SPN-less” technique is used 1 - 2 BUT using this technique the “Domain User” used will become unavailable, so it’s better to avoid this attack)

If both conditions are satisfied, an attacker could arbitrarily configure a malicious RBCD on the target, this action would allow the attacker access to ANY to service executed by the service account for which the RBCD was configured impersonating ANY domain user.

The following scenario covers the most common case where an attacker is able to satisfy the condition previusly indicated:

1. The attacker impersonating a “Domain User” has write permissions on the “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity” attribute of an object of Computer type (so on the related Computer Account); in this way the attacker is able to configure on it an RBCD with an arbitrary value within the target attribute.

The attack can be carried out regardless of whether the target “Computer” object already has Unconstrained / Constrained Delegation enabled, because the KDC, after the checks performed on the Computer Account created by the attacker (which simulates the AP Front End service), will switch in any case to RBCD and therefore issue a TGS Ticket valid to authenticate to the service hosted on the target “Computer” object.

2. An attacker usually uses a “Computer Account” to invoke the “S4USelf” and “S4UProxy” extensions to exploit the previously configured RBCD; it happens because every existing Computer Account has by default an SPN configured and thus it can arbitray invoke the “S4USelf” and “S4UProxy” kerberos extension (it’s more uncommon the scenario that applies to a “Domain User”)

   An attacker in order to compromise a “Computer Account” could:

   • Compromise a Computer and retrieve its related Computer Account
   • NTLM Relay Attacks
   • Create an arbitrary Computer Account.

The domain object itself has an attribute named “MS-DS-Machine-Account-Quota” that governs how many Computer Accounts a non-privileged user (usually a Computer Account & a traditional domain user) can create within the domain; by default this value is 10.

If the value of this attribute is >=1 an attacker could create an arbitrary Computer Account and use it to carry out the attack.

Abuse RBCD via DACL (Computer) - Windows

In this scenario we will see how to perform an RBDC Abuse via DACL, in the most common scenario, from a Windows machine.

1. The attacker verifies which user accounts have write permission on the attribute “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity” of a Computer object.

   To do this the attacker can use “BloodHound” or perform queries using “PowerView”:

   • BloodHound

     Below we can verify with BloodHound that the domain user “MARVEL\UserA” HAS write permissions, in this case GenericAll, on the Computer object “SPIDERMAN”, consequently will be able to configure RBDC on it.

     

   • PowerView

     Below we can verify with PowerView that the domain user “MARVEL\UserA” HAS write permissions on the Computer object “SPIDERMAN”, consequently will be able to configure RBDC on it:

     PS C:\>
     $computers = Get-DomainComputer
     $users = Get-DomainUser
     $accessRights = "GenericWrite","GenericAll","WriteProperty","WriteDacl"
     foreach ($computer in $computers) {
         $acl = Get-ObjectAcl -SamAccountName $computer.SamAccountName -ResolveGUIDs
     
         foreach ($user in $users) {
                     $hasAccess = $acl | ?{$_.SecurityIdentifier -eq $user.ObjectSID} | %{($_.ActiveDirectoryRights -match ($accessRights -join '|'))}
     
                     if ($hasAccess) {
                         Write-Output "$($user.SamAccountName) has the required access rights on $($computer.Name)"
                     }
         }
     }
     

     

   Indeed, via ADUC we can see how there is actually an ACE on the DACL of the SPIDERMAN object that grants the Trustee MARVEL\UserA the “GenericWrite” permission.

   

2. The attacker compromises the domain account MARVEL\UserA that has the required write permissions on the SPIDERMAN machine

   In this scenario the attacker managed to recover, for example via Password Spray, the credentials of the account “MARVEL\UserA”, so the domain account that has the required write permissions on the SPIDERMAN machine.

3. The attacker creates a “Computer Account” inside the domain.

   The attacker needs to control an account with a configured SPN, in this way it can be used to invoke the S4U extensions and exploit the RBCD that we will configure later.

   Since Computer Accounts have an SPN configured by default, the attacker will tend to compromise one and in order to do that most common way is to exploit a feature present by default in every domain.

   As already said, the domain object itself has an attribute named “MS-DS-Machine-Account-Quota” that regulates how many Computer Accounts a non-privileged user (usually a Computer Account & a traditional domain user) is able to create inside the domain; by default this value is equal to 10; consequently if this value is >=1 the attacker could create an arbitrary “Computer Account”.

   Below is the command that checks the value present in the “MS-DS-Machine-Account-Quota” attribute:

   PS C:\> Get-ADObject `
   -Identity ((Get-ADDomain).distinguishedname) `
   -Properties ms-DS-MachineAccountQuota
   

   

   Since the value is >=1 we can create an arbitrary “Computer Account”, in a Windows context we can use the “PowerMad” tool, specifically running the following command:

   PS C:\> New-MachineAccount -MachineAccount <ComputerAccount_Name> -Password $(ConvertTo-SecureString "<ComputerAccount_Password>" -AsPlainText -Force)
   

   

   As you can see following the command a new arbitrary Computer Account has been created.

   Creating a “Computer Account” is equivalent to creating a “Computer” object inside the domain, in fact inspecting the objects via ADUC we will find the “Computer” object named “FakeComputerAccount” (which will contain inside it the related Computer Account “FakeComputerAccount$”)

   

4. The attacker, using the account “MARVEL\UserA”, populates the attribute “msDS-AllowedToActOnBehalfOfOtherIdentity” of the machine SPIDERMAN with the value of the Computer Account “FakeComputerAccount” previously created, in this way the attacker has forced a malicious RBCD configuration on the machine SPIDERMAN.

   To do this the attacker can use the following commands (they require PowerView):

   • Retrieve the SID of the previously created Computer Account

     PS C:\> $ComputerSid = Get-DomainComputer <Created_Computer_Account> -Properties objectsid | Select -Expand objectsid 
     

   It is necessary to specify the Computer and not the Computer Account to avoid an error, in other word you must write for example “FakeComputerAccount” but not “FakeComputerAccount$”

   • Create the value that will be inserted into the parameter “msDS-AllowedToActOnBehalfOfOtherIdentity”, specifically the SDDL syntax in raw binary format will be used

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

   • Using PowerView the attacker modifies the attribute “msDS-AllowedToActOnBehalfOfOtherIdentity” of the machine SPIDERMAN with the value of the Computer Account “FakeComputerAccount$” previously created, which is represented by the value built previously; this modification action will be performed impersonating the credentials entered in that command.

     PS C:\Tools> $credentials = New-Object System.Management.Automation.PSCredential "<domain>\<user_with_write_permission>", (ConvertTo-SecureString "<user_with_write_permission_password>" -AsPlainText -Force) 
     PS C:\Tools> Get-DomainComputer <target_computer> | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Credential $credentials -Verbose
     

   Below is the execution of all the commands just described:

   

   With these commands the attacker, impersonating the account “MARVEL\UserA”, populates the attribute “msDS-AllowedToActOnBehalfOfOtherIdentity” of the machine SPIDERMAN with the value of the Computer Account “FakeComputerAccount$” previously created (or rather in its representation with the correct syntax SDDL), in this way the attacker forced a malicious RBCD configuration on the machine SPIDERMAN.

   Indeed, if we now inspect the attribute “msDS-AllowedToActOnBehalfOfOtherIdentity” of the machine SPIDERMAN we can see that:

   • Via ADUC it is noticeable that there is indeed a value with a dedicated syntax (which actually represents the Computer Account “FakeComputerAccount$”).

     

   • Via “Get-ADComputer” (requires RSAT) it is noticeable that the value “MARVEL\FakeComputerAccount$” is indeed present.

     

5. The attacker obtains a TGS Ticket (of Domain Admin) valid to authenticate to the CIFS service hosted on the machine SPIDERMAN.

   The attacker, now that they have configured a malicious RBCD, so they have populated the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute of the SPIDERMAN machine with the value of the Computer Account “FakeComputerAccount$”, can impersonate this account to invoke the “S4U2Self” & “S4U2Proxy” extensions (having at least 1 SPN configured allows them to do so) and thus obtain a TGS Ticket belonging to a Domain Admin user valid to access ANY service hosted on the SPIDERMAN machine (or rather any service running under the SPIDERMAN$ Service Account, so, all services started with the Local Service account such as by default the CIFS service).

   Since performing this action requires knowing the RC4 Key (NT Hash) or other types of secrets of the Computer Account “FakeComputerAccount$”, we can generate them by giving Rubeus the corresponding plaintext password with the following command:

   PS C:\Tools> .\Rubeus.exe hash /password:<ComputerAccount_Created_Password> /user:<ComputerAccount_Created> /domain:<domain>
   

   

   Since we will inject the desired TGS Ticket into memory, first we use the so-called Sacrificial Process.

   C:> Rubeus.exe createnetonly /program:"C:\Windows\System32\cmd.exe" /show
   

   

   Then execute the following Rubeus command inside the Sacrificial Process.

   C:\> .\Rubeus.exe s4u /user:<Created_Computer_Account> /rc4:<Created_Computer_Account_RC4Key> /impersonateuser:<User_To_Impersonate> /msdsspn:<Desired_SPN> /nowrap /ptt
   

   Unlike the Abuse Protocol Transition context where the “/msdsspn” parameter was populated exclusively with the SPN present in the “msds-allowedtodelegateto” property, in the RBDC Abuse via DACL context it should be populated with an arbitrary SPN chosen by the attacker; in this way, the (S4UProxy will specify this chosen SPN and since the KDC will use the RBCD, it will return in the corresponding S4UProxy Response the TGS Ticket valid for the requested arbitrary service.

   As already mentioned, Microsoft POST 2021 slightly modified the traditional RBCD flow; since our lab consists of a Windows Server 2022 acting as DC, the flow that will be analyzed will cover this modern case; that said, i’ll highlight the logic of how the attack would have worked ALSO BEFORE 2021:

   1. Rubeus sent a “KRB_AS_REQ” to obtain the TGT Ticket of the Computer Account FakeComputerAccount$, information necessary to invoke the “KRB_TGS_REQ (S4USelf)”

      
      

   2. Rubeus, now that it has the TGT Ticket of the Computer Account “FakeComputer$”, sends a “KRB_TGS_REQ (S4U2Self)” to obtain a TGS Ticket on behalf of the user “MARVEL\Administrator” (Domain Admin) valid for the same service.

      

      As we can note Rubeus sends a “KRB_TGS_REQ (S4U2Self)”; analyzing the content of the packet one can observed that: 1) Inside the “PA-FOR-USER” data structure the request for the TGS Ticket on behalf of the user “MARVEL\Administrator” (it’s a Domain Admin) is indeed present; 2) the Computer Account FakeComputerAccount$ is explicitly indicated), in this way the issued TGS Ticket will be valid for all services started by this Service Account.

      

      As we already told, the KDC will issue a TGS Ticket with the FORWARDABLE flag set to 0 exclusively if the Service Account “FakeComputerAccount$” is configured with Constrained Delegation (Kerberos Only) (so: TrustedToAuthForDelegation flag NOT set & with the “msDS-AllowedToDelegateTo” property NOT empty - there must be entries); since the FakeComputerAccount$ user instead has NO type of Kerberos Delegation, the Computer Account “FakeComputerAccount$” will NOT have the “msDS-AllowedToDelegateTo” flag and consequently the requested TGS Ticket (belonging to the user “MARVEL\Administrator” & valid for all services started by this Service Account) will be issued with the FORWARDABLE flag set to 1.

      

      BEFORE 2021:

      As we already told (1, 2), in BEFORE 2021 scenario the KDC will still issues the requested TGS Ticket BUT it will NOT have the FORWARDABLE flag set to 1; instead, it is 0.

   3. Rubeus now that it has the TGS Ticket (belonging to the user MARVEL\Administrator”) valid for the service itself, will be able to use it as “evidence” to invoke the “KRB_TGS_REQ (S4UProxy)”, in this way the attacker will obtain a TGS Ticket (still belonging to the user MARVEL\Administrator") valid for the CIFS service exposed on the SPIDERMAN machine (CIFS/SPIDERMAN)

      

      As we can note Rubeus sends a “KRB_TGS_REQ (S4UProxy), analyzing the content of the packet it can be observed that: 1) Inside the “Additional Ticket” field the TGS Ticket previously received in the “S4USelf Response” is sent 2) the SPN chosen by the attacker on the Rubeus command is indicated;

      In order to obtain a valid TGS Ticket the SPN provided must belong to a service that will be executed by the Computer Account “SPIDERMAN$” (so, all services started with the Local Service account such as by default the CIFS service), in this case the SPN “CIFS/SPIDERMAN.MARVEL.local” is present.

      

      The KDC verifies if the TGS Ticket received inside the “additional-tickets” field (besides being valid) has the “FORWARDABLE” flag set to “1” (positive outcome) & that inside the Service Account FakeComputerAccount$’s “msds-allowedtodelegateto” property the requested service is present, so in this case “CIFS/SPIDERMAN” (outcome negative), since this second check fails (because that property is NOT present at all) and the packet has the RBDC flag set to use that Kerberos Delegation in case of FallBack, the KDC resorts to Resource Based Constrained Delegation (RBCD).

      BEFORE 2021

      As already told: In BEFORE 2021 scenario the KDC checks if the TGS Ticket received inside the “additional-tickets” field (besides being valid) has the “FORWARDABLE” flag set to “1” (outcome negative) & that inside the Service Account FakeComputerAccount$’s “msds-allowedtodelegateto” property the requested service is present, so in this case “CIFS/SPIDERMAN” (outcome negative); since the first check already fails and the packet has the RBDC flag set to use that Kerberos Delegation in case of FallBack, the KDC resorts anyway to the Resource Based Constrained Delegation (RBCD).

      Consequently, the KDC retrieves the Service Account (SPIDERMAN$) of the requested service (CIFS) and verifies if it has the “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity” flag containing the Service Account (FakeComputerAccount$) of the service that is attempting authentication on behalf of the Client (MARVEL\Administrator); if, as in this case, the outcome is positive, then the KDC issues a TGS Ticket (belonging to the user MARVEL\Administrator”) valid for the CIFS service exposed on the SPIDERMAN machine (as with any other valid TGS Ticket this one will also have the “FORWARDABLE” flag set to “1”).

      

   As you can see, following the Rubeus command we will have cached in memory a TGS Ticket belonging to the “Administrator” user valid for the CIFS service of the SPIDERMAN machine; in fact, by performing a Network Logon with “PsExec” the OS will retrieve the cached TGS Ticket and use it to perform the authentication; in this way the attacker has managed to successfully authenticated with administrative privileges to the SPIDERMAN machine.

   

   If you receive an authentication error try re-running the command including the “msdsspn” parameter with a value that does not include the domain suffix, so from “SPIDERMAN.marvel.local” to “SPIDERMAN” (technically without the domain you should not encounter issues); also verify to use the same domain nomenclature you inserted in “msdsspn” within the PsExec command (in this case), so if you request, for example, a TGS Ticket valid to access the SPIDERMAN.marvel.local machine use the same wording to connect via PsExec; finally, I do not understand why, sometimes PsExec only works if a “dir \\C$” is executed beforehand (this is especially true for Computers with Unconstrained Delegation enabled, such as the DC).

   An attacker, after performing the attack, to partially restore the situation (since the created Computer Account cannot be deleted unless one has administrative permissions on the domain) could remove the “msDS-AllowedToActOnBehalfOfOtherIdentity” property previously configured to enable the malicious RBCD on the target Computer object “SPIDERMAN”; to do this run the following Powershell commands (require PowerView):

   PS C:\Tools> $credentials = New-Object System.Management.Automation.PSCredential "<domain>\<user_with_write_permission>", (ConvertTo-SecureString "<user_with_write_permission_password>" -AsPlainText -Force)
   PS C:\Tools> Get-DomainComputer <target_computer> | Set-DomainObject -Clear msDS-AllowedToActOnBehalfOfOtherIdentity -Credential $credentials -Verbose
   

Abuse RBCD via DACL (Computer) - Linux

In this scenario we will see how to perform an Abuse RBDC via DACL, in the most common scenario, from a Linux machine.

1. The attacker checks which accounts have write permission on the attribute “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity” of a Computer-type object.

   Below we can verify with BloodHound that the domain account “MARVEL\UserA” HAS write permissions, in this case GenericAll, on the Computer object “SPIDERMAN”, consequently it will be able to configure the RBCD on it.

   

2. The attacker compromises the domain account MARVEL\UserA which has the required write permissions on the SPIDERMAN machine.

   In this scenario the attacker managed to retrieve, for example through Password Spray, the credentials of the account “MARVEL\UserA”, that is, the domain account that has the required write permissions on the SPIDERMAN machine.

3. The attacker creates a “Computer Account” within the domain.

   The attacker needs to control an account with a configured SPN, since it can be used to invoke the S4U extensions and exploit the RBCD that we will configure later.

   Since Computer Accounts have an SPN configured by default, the attacker will tend to compromise one in order to use it; among the various methods, the most common one is to exploit a feature that is present by default in every domain.

   The domain has an attribute named “MS-DS-Machine-Account-Quota” which regulates how many Computer Accounts a non-privileged user (usually a Computer Account or a traditional Domain User) is able to create within the domain; by default this value is equal to 10; consequently, if this value is >=1, the attacker could create an arbitrary “Computer Account”.

   Below is the command that checks the value present in the “MS-DS-Machine-Account-Quota” attribute:

   # ldapsearch -x -H ldap://<DCIP_or_DCHostname> -b 'DC=<domain>,DC=<domain>' -D "<user>@<domain>" -W -s sub "(objectclass=domain)" | grep ms-DS-MachineAccountQuota
   

   

   Since the value is >=1 we can create an arbitrary “Computer Account”, in a Linux context we can use the “addcomputer.py” tool from Impacket, specifically by executing the following command:

   

   As you can see, following the command a new arbitrary Computer Account has been created; creating a “Computer Account” is equivalent to creating an object of type “Computer” within the domain.

4. The attacker, using the account “MARVEL\UserA”, populates the attribute “msDS-AllowedToActOnBehalfOfOtherIdentity” of the SPIDERMAN machine with the value of the previously created Computer Account “MaliciousAccount$”, in this way the attacker has enforced a malicious RBCD configuration on the SPIDERMAN machine.

   # impacket-rbcd -dc-ip <dc_ip> <domain>/<user>:'<password>' -action write -delegate-to '<Computer_Account_target>' -delegate-from '<Computer_Account_Malicious>'
   

   To verify if the modification was successful, execute the following command:

   # impacket-rbcd -dc-ip <dc_ip> <domain>/<user>:'<password>' -action read -delegate-to '<Computer_Account_target>'
   

   

   With these commands, the attacker, impersonating the account “MARVEL\UserA”, has populated the attribute “msDS-AllowedToActOnBehalfOfOtherIdentity” of the SPIDERMAN machine with the value of the previously created Computer Account “MaliciousAccount$”, in this way the attacker has enforced a malicious RBCD configuration on the SPIDERMAN machine.

5. The attacker obtains a valid TGS Ticket (of a Domain Admin) to authenticate to the CIFS service hosted on the SPIDERMAN machine.

   Since it has already been explained in detail previously, this section will be a summary of it.

   Now that the attacker has configured a malicious RBCD, meaning they have populated the attribute “msDS-AllowedToActOnBehalfOfOtherIdentity” of the SPIDERMAN machine with the value of the Computer Account “MaliciousAccount$”, they can impersonate this account to invoke the S4U2Self & S4U2Proxy extensions (having at least one configured SPN allows them to do so) and therefore obtain a TGS Ticket belonging to a Domain Admin account, valid for accessing ANY service hosted on the SPIDERMAN machine (or rather, any service running with the Service Account SPIDERMAN$, so, all services started with the Local Service account such as, by default, the CIFS service).

   # impacket-getST -spn <SPN_desiderato> -impersonate <User_To_Impersonate> -dc-ip <DC_IP> '<domain>/<Computer_Account_Creato>':<password>
   

   Unlike the Abuse Protocol Transition context where the “/msdsspn” parameter was populated exclusively with the SPN present in the “msds-allowedtodelegateto” property, in the context of Abuse RBDC via DACL it must be populated with an arbitrary SPN chosen by the attacker, in this way, in the S4UProxy Request that SPN will be specified, and since the KDC will use the RBCD, it will return in the corresponding S4UProxy Response the TGS Ticket valid for the arbitrary requested service.

   

   Let’s SUMMARILY analyze all the operations performed by getST.

   1. Impacket getST, since it does NOT find a “.cache” file related to the TGT Ticket of the Computer Account MaliciousAccount$, sends a “KRB_AS_REQ” to obtain precisely the TGT Ticket of the Computer Account MaliciousAccount$, information necessary to invoke the “KRB_TGS_REQ (S4USelf)”

      

   2. Impacket getST now that it has the TGT Ticket of the Computer Account “MaliciousAccount$” sends a “KRB_TGS_REQ (S4USelf)” to obtain a TGS Ticket on behalf of the account “MARVEL\Administrator” (Domain Admin) valid for the service itself.

      

   3. Impacket getST now that it has the TGS Ticket (belonging to the account MARVEL\Administrator") valid for the service itself, it will be able to use it as “evidence” to invoke the “KRB_TGS_REQ (S4UProxy)”, in this way the attacker will obtain a TGS Ticket (always belonging to the account MARVEL\Administrator") valid for the CIFS service exposed on the SPIDERMAN machine (CIFS/SPIDERMAN)

      

Now we could, for example, use the Impacket suite to access the SPIDERMAN machine via PsExec, in this example we will use Impacket’s “psexec” (smbexec.py can also be used)", consequently it is necessary to configure an environment variable named “KRB5CCNAME” and make sure that it contains the file just created, so the TGS Ticket.

# export KRB5CCNAME=./<user>@<service>_<hostname>@<domain>.ccache

After that, use for example Impacket’s “psexec” to perform the authentication, in this way the attacker will be able to authenticate with administrative privileges to the SPIDERMAN machine.

# impacket-psexec -k -no-pass <hostname>

In a Linux context it is straightforward and convenient to also use the Impacket tool “secretsdump” in order to dump the OS Credentials present on the target machine, this is because it also supports Kerberos Authentication following the same logic as every other tool in the Impacket suite.

An attacker, after having carried out the attack, to partially restore the situation (given that the created Computer Account cannot be deleted unless one has administrative permissions on the domain) could remove the property “msDS-AllowedToActOnBehalfOfOtherIdentity” previously configured to enable the malicious RBCD on the Target Computer object “SPIDERMAN”:

# impacket-rbcd -dc-ip <DC_IP> <domain>/<user>:'<password>' -action remove -delegate-to '<ComputerAccount_targate>$' -delegate-from '<malicious_computeraccount>'

Abuse RBCD via DACL - Detect & Mitigation

Detect

Configure a SACL that will monitor the modification of the attribute ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity (1, 2)

Mitigation

Although this type of attack cannot be completely prevented since it exploits how Kerberos Delegation works, there are mitigations that can mitigate the impact:

• Configure the property “Account is sensitive and cannot be delegated” on privileged accounts (detailed explaination here)

• Add privileged accounts to the “Protected Users Group” (detailed explaination here)

• Modify the domain attribute “MS-DS-Machine-Account-Quota” by entering the value 0.

  Entering the value 0 will make it impossible for the attacker to create an arbitrary “Computer Account”, thereby making the attacker’s Abuse RBCD via DACL scenario more complicated.

  To perform this action access ADUC and simply set this property to 0 within the “domain” object.

  

  This change will NOT impact the following users: Domain Admin, Administrators, users who have the permission to create & delete “Computer Account” within an OU; consequently, changing this value to 0 will NOT cause any kind of service disruption to domain administrators.

Abuse Kerberos Only

Kerberos Only, being similar to Protocol Transition, one might think that an attacker could exploit it doing the exact same steps described in Abuse Protocol Transition, so that compromising the Service Account with Kerberos Only one would also be able to compromise (impersonating ANY domain user) the machine for which it is authorized to access on behalf of the Client (indicated in the flag “msds-allowedtodelegateto”); this, unfortunately, is NOT possible because in that scenario the attacker could NOT “correctly” invoke the S4USelf extension to target an arbitrary user, this because if done the KDC would return a TGS Ticket with the FORWARDABLE Flag set to 0 (both PRE-2021 and POST-2021) and therefore NOT valid to include it (additional-ticket) in the subsequent S4UProxy (if the S4UProxy were sent anyway the KDC would force the RBCD which, not being configured, would end with an error response).

This logic is true both PRE-2021 and POST-2021, in fact:

• PRE-2021: In an S4USelf Response the KDC will provide a TGS Ticket with the FORWARDABLE flag set to 0, it happens because the Service Account in this case of the Kerberos Only does NOT have the “TRUSTED_TO_AUTH_FOR_DELEGATION” flag. (in a “Kerberos Only” context the relevant Service Account is configured only with the “msds-allowedtodelegateto” flag)

• POST-2021: In an S4USelf Response the KDC will provide a TGS Ticket with the FORWARDABLE flag set to 0, it happens because the Service Account is configured with a Kerberos Only (so, it does NOT have the “TRUSTED_TO_AUTH_FOR_DELEGATION” flag & has configured the “msds-allowedtodelegateto” flag with some values)

That said, it is still possible to Abuse Kerberos Only but it is necessary to leverage the knowledge acquired through “Abuse Protocol Transition” and “Abuse RBCD via DACL”.

The prerequisites of “Abuse Kerberos Only” are:

• Analogous to “Abuse RBCD”: The attacker needs to control an account that is capable of invoking the “S4USelf” extensions, usually a Computer Account is created by exploiting the default value of “MS-DS-Machine-Account-Quota”

• Compromise the Service Account that has Constrained Delegation (Kerberos Only) enabled

The most common steps to carry out an “Abuse Kerberos Only” are:

1. The attacker obtains a “Computer Account” which will be able to perform an “S4USelf", typically it will be created by exploiting the default value of “MS-DS-Machine-Account-Quota”.

2. The attacker, after compromising the Service Account (usually a Computer Account) with Kerberos Only configured, sets on it the property “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity” containing as value the Computer Account previously created by the attacker; in other words, he configures a so called “Self-RBCD”.

By default every Computer Account (from my tests even standard domain users) has permissions to edit its own “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity” property, this behavior allows to perform this kind of attack; Microsoft appears to have patched this behavior in August / September 2022, so for example on Windows Server 2025 this technique may NO longer work.

3. Analogous to an Abuse RBCD via DACL, the attacker could invoke the “S4USelf” and “S4UProxy” extensions with the previously created Computer Account to exploit the specially configured RBCD and thus obtain a TGS Ticket (belonging to an administrative domain account) valid for a service on the machine with Kerberos Only enabled; instead of using it in an authentication (an action that WOULD NOT make sense since the attacker has already compromised the machine with Kerberos Only) this TGS Ticket will be used subsequently in an alternative way; the sub-steps are:

   • The attacker performs an S4USelf Request impersonating the Computer Account (previously created) to obtain a TGS Ticket valid for the services started by that same Computer Account, so none.

     This phase rappresent these phases (1, 2)

   • The attacker, using the previously obtained TGS Ticket and exploiting the Self-RBCD previously configured on the Service Account with Kerberos Only, is able to obtain a TGS Ticket belonging to an administrative account to access the machine with Kerberos Only enabled (this TGS Ticket will be used subsequently)

     This phase rappresent this phase (1)

4. The attacker uses this TGS Ticket (belonging to an administrative domain account) as “evidence” that an administrative account has logged onto the machine with Kerberos Only enabled, consequently, analogous to an Abuse Protocol Transition, by impersonating the machine with Kerberos Only enabled the attacker could invoke S4UProxy and insert this TGS Ticket into the “additional-ticket” field to receive from the KDC a TGS Ticket (again belonging to an administrative domain account) valid to authenticate to the computer that the Kerberos Only machine is authorized to access on behalf of the Client (indicated in the “msds-allowedtodelegateto” flag); furthermore, analogous to Abuse Protocol Transition, the attacker can choose to modify the SPN field of the received TGS Ticket.

Knowing this information we draw the following conclusion.

If an attacker compromises a Service Account with “Constrained Delegation (Kerberos Only)” enabled, so in most scenarios a Computer Account (usually by compromising the related machine), the attacker could therefore obtain a TGS Ticket belonging to ANY domain account and valid to access ANY (typically) Back-End service which the compromised machine is authorized to access on behalf of the Client (indicated in the “msds-allowedtodelegateto” flag).

Abuse Kerberos Only (Computer) - Windows

In this scenario we will see how to exploit an Abuse Kerberos Only from a Windows machine.

1. Identify which Service Accounts have “Constrained Delegation (Kerberos Only)” enabled (in this scenario we are looking for Computer Accounts that act as Service Accounts)

   There are different methods to identify which Service Accounts have “Constrained Delegation (Kerberos Only)”; on Windows it is possible to perform targeted LDAP queries using Powershell:

   PS C:\>
       $searcher = New-Object DirectoryServices.DirectorySearcher
       $searcher.Filter = "(&(objectClass=computer)(msDS-AllowedToDelegateTo=*))"
       $searcher.FindAll() | ForEach-Object {
           $_.Properties['name']
   }
   

   

   As you can notice, the Computer Account THEPUNISHER$ has Constrained Delegation (Kerberos Only) enabled; specifically, this account and therefore ALL services running under it will be able to authenticate on behalf of the Client exclusively to the SPN “HTTP/SPIDERMAN”, so the HTTP service of the SPIDERMAN machine.

   In fact, inspecting via ADUC the “Delegation” tab of the THEPUNISHER Computer, we will find this configuration.

   

2. The attacker compromises the Service Account with Constrained Delegation (Kerberos Only) enabled.

   In this scenario, the attacker managed to authenticate with administrative permissions on the THEPUNISHER machine and, by dumping LSASS, obtained the credentials of the THEPUNISHER$ Computer Account, so, the Service Account with Constrained Delegation (Kerberos Only) enabled.

   

3. The attacker creates a “Computer Account” within the domain.

   As already told, the attacker needs to control an account with a configured SPN, as it can be used to invoke the S4U extensions and exploit the RBCD that we will configure later.

   Since Computer Accounts have an SPN configured by default, the attacker will aim to compromise one to then use it; among the various methods, the most common is to exploit a feature present by default in every domain.

   The domain has an attribute named “MS-DS-Machine-Account-Quota” that regulates how many Computer Accounts a non-privileged user (usually a Computer Account & a traditional domain user) can create within the domain; by default this value is 10; consequently, if this value is >=1, the attacker could create an arbitrary “Computer Account”.

   Below is the command that checks the value present in the “MS-DS-Machine-Account-Quota” attribute:

   PS C:\> Get-ADObject `
       -Identity ((Get-ADDomain).distinguishedname) `
       -Properties ms-DS-MachineAccountQuo
   

   

   Since the value is >=1, we can create an arbitrary “Computer Account”; in a Windows context, we can use the “PowerMad” tool, specifically executing the following command:

   PS C:\> New-MachineAccount -MachineAccount <ComputerAccount_Name> -Password $(ConvertTo-SecureString "<ComputerAccount_Password>" -AsPlainText -Force)
   

   

   As you can see, following the command a new arbitrary Computer Account has been created.

   Creating a “Computer Account” is equivalent to creating a “Computer” type object within the domain; in fact, inspecting the objects via ADUC we will find the “Computer” object named EvilComputer (which will contain its related Computer Account EvilComputer$).

   

4. The attacker, impersonating the user “THEPUNISHER$” (Service Account with Constrained Delegation -Kerberos Only), populates their own “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute with the value of the “EvilComputer$” Computer Account previously created; in this way, the attacker has forced a malicious Self RBCD.

   As already mentioned, by default every Computer Account has the permissions to edit its own “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity” property; consequently, an attacker, after compromising a Service Account of the Computer Account type with Constrained Delegation (Kerberos Only) enabled, could force an RBCD ot the account itself.

   Microsoft seems to have patched this behavior in August / September 2022.

   In our example, after compromising the THEPUNISHER$ Computer Account (Service Account with Constrained Delegation - Kerberos Only), the attacker impersonates it and self-populates the “msDS-AllowedToActOnBehalfOfOtherIdentity” property with the value “EvilComputer$”, so, with the previously created Computer Account.

   To do this in a Windows context, it is necessary to perform this action having imported the TGT Ticket of the THEPUNISHER$ Computer Account into memory (in order to impersonate it); consequently, to avoid DoS we invoke a Sacrificial Process.

   C:> Rubeus.exe createnetonly /program:"C:\Windows\System32\cmd.exe" /show
   

   

   Then we execute the following Rubeus command within the Sacrificial Process which will retrieve and cache locally a Ticket TGT of the THEPUNISHER$ users.

   C:\> .\Rubeus.exe asktgt /user:<Computer_Account_KerberosOnly> /rc4:<Computer_Account_KerberosOnly> /domain:<DOMAIN> /nowrap /ptt
   

   

   After this, start PowerShell (so type “powershell” inside the Sacrificial Process) and then execute the Self RBCD configuration with the following commands (PowerView is required):

   • Retrieve the SID of the previously created Computer Account

     PS C:\> $ComputerSid = Get-DomainComputer <Computer_Account_Creato> -Properties objectsid | Select -Expand objectsid 
     

   It is necessary to specify the Computer and not the Computer Account to avoid an error in this step, so you can write, for example, EvilComputer but not EvilComputer$.

   • Create the value that will be inserted into the “msDS-AllowedToActOnBehalfOfOtherIdentity” parameter; specifically, the syntax (SDDL) in raw binary format will be used

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

   • Using PowerView, the attacker modifies the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute of the THEPUNISHER machine with the value of the previously created “EvilComputer$” Computer Account, which is represented by the value previously constructed; this modification action will be performed while impersonating the THEPUNISHER$ Computer Account (as we have the related cached TGT Ticket).

     PS C:\Tools> Get-DomainComputer <target_computer>.<domain>.<domain> | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose
     

   Below is the execution of all the commands just described:

   

   With these commands the attacker, impersonating the account “THEPUNISHER$”, populated the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute of the machine itself with the value of the previously created Computer Account “EvilComputer$”, in this way the attacker forced a Self RBCD on the Service Account THEPUNISHER$ (which is still configured ALSO with Constrained Delegation Kerberos Only, in fact it still has the msds-allowedtodelegateto flag configured).

   Indeed, if we now inspect the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute of the THEPUNISHER machine we can see that:

   1. via ADUC it is noticeable that a value with a dedicated syntax is actually present (which in reality represents the EvilComputer$ Computer Account).
      
      

   2. via “Get-ADComputer” (requires RSAT) it is noticeable that the value “MARVEL\EvilComputer$” is actually present.
      
      

5. The attacker, now that they have configured a malicious RBCD, so, it have populated the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute of the machine THEPUNISHER$ with the value of the Computer Account “EvilComputer$”, can impersonate that account to invoke the “S4U2Self” & “S4U2Proxy” extensions (having at least 1 SPN configured it is able to do so) and thus (thanks to the previously made malicious configuration - “Self-RBCD”) obtain a TGS Ticket belonging to a Domain Admin account valid to access ANY service hosted on the THEPUNISHER machine (so the machine with Kerberos Only already compromised by the attacker); in the next phase we’ll use this TGS Ticket as an “Additional-Ticket” to invoke S4U2Proxy again.

   Since performing this action requires knowing the RC4 Key (NT Hash) or other types of secrets of the “EvilComputer$” Computer Account, we can produce them by feeding Rubeus the related password in plaintext with the following command:

   C:\> PS C:\Tools> .\Rubeus.exe hash /password:<ComputerAccount_Created_Password> /user:<ComputerAccount_Created> /domain:<domain>
   

   

   Inside the Sacrifical Process previously created execute the following Rubeus command:

   C:\> .\Rubeus.exe s4u /user:<Created_Computer_Account> /rc4:<Created_Computer_Account_RC4Key> /impersonateuser:<User_To_Impersonate> /msdsspn:<Desired_SPN_related_to_the_ComputerAccount_with_RBCD_configurated> /nowrap
   

   Unlike in the Abuse Protocol Transition context where the “/msdsspn” parameter was populated exclusively with the SPN present in the “msds-allowedtodelegateto” property, in the Abuse Kerberos Only context it must be populated with any arbitrary SPN chosen by the attacker that has the THEPUNISHER$ Computer Account as its Service Account (for example CIFS/THEPUNISHER), everything will work because the KDC will use the RBCD previously configured.

   1. Rubeus sent a “KRB_AS_REQ” to obtain the TGT ticket of the EvilComputer$ Computer Account, information necessary to invoke next the “KRB_TGS_REQ (S4USelf)”

      

   2. Rubeus, now that it has the TGT Ticket of the Computer Account “EvilComputer$”, sends a “KRB_TGS_REQ (S4USelf) Request” to obtain a corresponding KRB_TGS_REP (S4U2Self) Response containing a TGS Ticket belonging to the account “MARVEL\Administrator” (Domain Admin) valid for the services executed with the account “EvilComputer$” (in our scenario this Computer Account “EvilComputer” DOES NOT run services, that said, this actions will only be used to conduct the Abuse Kerberos Only).

      

      To analyze the process in detail, re-read this section.

   This Ticket TGS will be issued with the FORWARDABLE flag at 1 (briefly: because “EvilComputer$” does NOT have “Kerberos Only enabled”)

   3. Rubeus now that it has the TGS Ticket (belonging to the user MARVEL\Administrator) valid for services executed with the user “EvilComputer$” (so none), uses it to invoke a “KRB_TGS_REQ (S4UProxy) Request”, with this procedure the KDC will verify if this TGS Ticket has the FORWARDABLE flag (positive outcome) and if the user “EvilComputer$” has the “msds-allowedtodelegate” flag properly configured (negative outcome), in summary, the second verification will fail since the user “EvilComputer$” does NOT have the “msds-allowedtodelegate” flag at all and consequently the KDC will switch to Kerberos Delegation RBCD; for this reason, the KDC will verify if the Service Account THEPUNISHER$ possesses the “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity” flag containing the value of “EvilComputer$” (positive outcome), since this verification will be positive (the attacker previously performed this configuration - A.K.A Self-RBCD), the KDC will issue a TGS Ticket (belonging to the user MARVEL\Administrator) valid for services executed with the user “THEPUNISHER$” (so the machine with Kerberos Only already compromised by the attacker); finally, this TGS Ticket will be subsequently used in the continuation of the attack.

      

      To analyze the process in detail, re-read this section.

      

   This Ticket TGS will be issued with the FORWARDABLE flag at 1.

6. The attacker could use the previously obtained TGS Ticket (belonging to Domain Admin & valid for services executed with the user “THEPUNISHER$”, so the machine with Kerberos Only), as “evidence” that the Domain Admin user “MARVEL\Administrator” logged onto the THEPUNISHER machine, consequently, the attacker, analogous to an Abuse Protocol Transition, can invoke S4UProxy and insert that TGS Ticket inside the “additional-ticket” field (traditionally in a Protocol Transition this field is dedicated to the TGS Ticket issued in the S4USelf Response but nothing prevents inserting any other TGS Ticket like this one received in an “malicious” S4UProxy) in order to receive from the KDC a TGS Ticket (belonging to the Domain Admin user MARVEL\Administrator) valid to authenticate to the computer (HTTP/SPIDERMAN) that the Kerberos Only machine (THEPUNISHER) is authorized to access on behalf of the Client (indicated in the “msds-allowedtodelegateto” flag - 1, 2); furthermore, in this scenario the attacker decides to replace the SPN “HTTP/SPIDERMAN” with the SPN “CIFS/SPIDERMAN” thereby managing to authenticate via PsExec to the SPIDERMAN machine.

   To do this run the following Rubeus command inside the previously created Sacrificial Process:

   C:> .\Rubeus.exe s4u /tgs:<TicketTGS_received_earlier_in_the_S4UProxyResponse) /user:<Service_Account_with_KerberosOnly> /rc4:<Service_Account_with_KerberosOnly_NTHash> /msdsspn:<SPN_within_in_msds-allowedtodelegateto> /altservice:<service> /nowrap /ptt
   

   If desired, the /altservice parameter must be populated exclusively with the requested service and NOT the entire SPN, for example if we want the SPN of the TGS Ticket to be changed to CIFS it will be necessary to write only “CIFS” and not “CIFS/”, otherwise the received TGS Ticket will NOT be valid.

   Let’s analyze ALL the operations performed by Rubeus.

   1. Rubeus sent a “KRB_AS_REQ” to obtain the TGT Ticket of the Computer Account THEPUNISHER$, information necessary to invoke the “KRB_TGS_REQ (S4UProxy)”

      

   2. Rubeus now that it has the TGT Ticket of the Computer Account THEPUNISHER$ and the TGS Ticket (belonging to the user MARVEL\Administrator) valid for the CIFS service on the THEPUNISHER$ machine (so, the one received in the previous S4UProxy Response), will be able to use this Ticket as “evidence” and therefore insert it inside the “Additional-Ticket” field in a new “S4UProxy Request”, in this way the attacker will obtain a TGS Ticket (still belonging to the user MARVEL\Administrator) valid for the HTTP service exposed on the SPIDERMAN machine (HTTP/SPIDERMAN), finally, Rubeus will change the HTTP service to the CIFS service, thus obtaining a TGS Ticket (still belonging to the user MARVEL\Administrator) valid for the CIFS service exposed on the SPIDERMAN machine.

      

      As we can see, Rubeus sends a “KRB_TGS_REQ (S4UProxy)”, analyzing the content of the packet it can be noted that: 1) Inside the “Additional Ticket” field the TGS Ticket previously received in the “S4UProxy Response” is indeed sent (so the Ticket inserted by the attacker in the /ticket parameter) 2) The SPN that points to the service the compromised machine (Computer Account THEPUNISHER$) is authorized to access on behalf of the Client (indicated in the “msds-allowedtodelegateto” flag (1, 2), in fact the SPN “HTTP/SPIDERMAN.MARVEL.local” is present.

      

      The KDC verifies if the TGS Ticket received inside the “additional-tickets” field (besides being valid) has the “FORWARDABLE” flag set to “1” (outcome positive - 1, 2)& that inside the “msds-allowedtodelegateto” flag parameter of the Service Account THEPUNISHER$ the requested service is present, in this case “HTTP/SPIDERMAN.MARVEL.local” (outcome positive), since the outcome is positive for both checks, the KDC issues a TGS Ticket (belonging to the user MARVEL\Administrator) valid for the HTTP service exposed on the SPIDERMAN machine (like any other valid TGS Ticket, this will also have the “FORWARDABLE” flag set to “1”).

      

   Finally, Rubeus will modify the SPN field of the received TGS Ticket, replacing the HTTP service with the desired CIFS service, in this way the output TGS Ticket (belonging to the user MARVEL\Administrator) will have the SPN “CIFS/SPIDERMAN” and will therefore be valid for the CIFS service exposed on the SPIDERMAN machine, after this Rubeus imports this Kerberos Ticket into memory.

   If the attacker does NOT want to replace the service of the TGS Ticket obtained via S4UProxy, they will simply NOT insert the “altservice” parameter, consequently, in this context we will obtain a TGS Ticket (belonging to the user MARVEL\Administrator) valid for the HTTP service present on the SPIDERMAN machine (usefull for a potential WinRM Service running and present on the SPIDERMAN machine).

As you can see, following the Rubeus command we will have cached in memory a TGS Ticket belonging to the “Administrator” user valid for the CIFS service of the SPIDERMAN machine, in fact, performing a Network Logon with “PsExec” the OS will retrieve the cached TGS Ticket and use it to authenticate; in this way the attacker has managed to authenticate with administrative privileges to the SPIDERMAN machine.

The LogonID in this screenshot is different from that of the previously indicated Sacrificial Process simply because I have repeated this lab several times.

If you encounter an authentication error, try re-running the command by inserting the “msdsspn” parameter with a value that does not have the domain suffix, changing from “SPIDERMAN.MARVEL.local” to “SPIDERMAN”; in both cases it should still work since both values are present within the msds-allowedtodelegateto property; also make sure to use the same domain notation in “msdsspn” as in the PsExec command (in this case), so if, for example, I request a TGS Ticket to access the SPIDERMAN.MARVEL.local machine, use the same wording to connect via PsExec.

An attacker, after performing the attack, could partially restore the situation (since the created Computer Account cannot be deleted unless there are administrative permissions on the domain) to the pre-attack state; for this, see this section.

Abuse Kerberos Only (User) - Windows

As already said, although it is stated that exclusively Computer Accounts can edit their property “ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity”, from my labs this also turns out to be true for traditional domain users, consequently the Abuse Kerberos Only attack can also be carried out in this scenario, consequently if we identify a Service Account of type “User” (traditional domain user) with the “Constrained Delegation (Kerberos Only)” enabled (a rarer scenario compared to the Computer counterpart) it is possible to perform the same steps previously seen to abuse this configuration.

If an attacker compromises a Service Account with the “Constrained Delegation (Kerberos Only)” enabled, so in this example a traditional domain user, the attacker could therefore obtain a TGS Ticket belonging to ANY domain user and valid to access ANY (usually) Back-End service for which the compromised Service Account (domain user) is authorized to access on behalf of the Client (indicated in flag “msds-allowedtodelegateto”).

We therefore re-execute the same steps previously seen:

1. Identify which Service Accounts have the “Constrained Delegation (Kerberos Only)” enabled (in this scenario we are looking for traditional domain users acting as Service Accounts)

   PS C:\>
   $searcher = New-Object DirectoryServices.DirectorySearcher
   $searcher.Filter = "(&(objectClass=user)(msDS-AllowedToDelegateTo=*))"
   $searcher.FindAll() | ForEach-Object {
       $_.Properties['name']
   }
   

   

   As you can notice, the traditional domain user MARVEL\userz has Constrained Delegation (Kerberos Only) enabled, specifically, this user and therefore ALL services started with it (in this case the Service Account “User” has the SPN LDAP/WORKSTATION02 and therefore will run the LDAP service on that machine; the fact that this machine does NOT exist in my lab is irrelevant for the purpose of the exploitation) will be able to authenticate on behalf of the Client exclusively towards the SPN “HTTP/SPIDERMAN”, so to the HTTP service of the machine SPIDERMAN.

   In fact, inspecting via ADUC the “Delegation” tab of the domain user “MARVEL\userz” we will find this configuration.

   

• (2 & 3) For simplicity, we do not show points 2 (Compromise of the Service Account MARVEL\userz) and 3 (the attacker creates a Computer Account within the domain, in this example we will use the EvilComputer$ user created previously)

4. The attacker, impersonating the user “MARVEL\userz” populates their “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute with the value of the Computer Account “EvilComputer$” previously created, in this way the attacker has forced a malicious Self RBCD.

   

5. The attacker now, having configured a malicious RBCD, so having populated the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute of the domain user “MARVEL\userz” with the value of the Computer Account “EvilComputer$”, can impersonate the latter to invoke the S4U2Self & S4U2Proxy extensions (having at least 1 SPN configured allows them to do so) and thus obtain (thanks to the previously made malicious configuration - “Self-RBCD”) a TGS Ticket belonging to a Domain Admin user valid to access ANY service (in this case exclusively the LDAP service on the machine WORKSTATION02 - which does not exist but in my home lab it doesn’t care) hosted by the Service Account “MARVEL\userz” (so the Service Account already compromised with Kerberos Only enabled), this TGS Ticket will subsequently be used as an “Additional-Ticket” to invoke S4UProxy again.

   Unlike the Abuse Protocol Transition context where the “/msdsspn” parameter was populated exclusively with the SPN present in the “msds-allowedtodelegateto” property, in the Abuse Kerberos Only context it must be populated with any SPN chosen by the attacker that has the domain user “MARVEL\userz” as the Service Account (since in our example the Service Account MARVEL\userz has exclusively the SPN string LDAP\Workstation02, it will be necessary to insert this value), all of this will work because the KDC will use the previously configured RBCD.

   

6. In summary, similarly to an Abuse Protocol Transition, the attacker now it’s able to obtain a TGS Ticket (of a Domain Admin) valid to authenticate to the HTTP service hosted on the machine SPIDERMAN (so, to the computer for which the Service Account with Kerberos Only “MARVEL\userz” has permissions to access on behalf of the Client through the “msds-allowedtodelegateto” flag), subsequently, in this scenario, the attacker will decide to modify the HTTP service with the CIFS service, thus making the TGS Ticket valid for authentication to the SMB service.

   

As you can notice, following the Rubeus command we will have cached in memory a TGS Ticket belonging to the user “Administrator” valid for the CIFS service of the machine SPIDERMAN, in fact, performing a Network Logon with “PsExec” the OS will retrieve the cached TGS Ticket and use it to perform the authentication; in this way the attacker has managed to authenticate with administrative permissions to the machine SPIDERMAN.

Abuse Kerberos Only - Detect & Mitigation

Detect

Same as indicated in Abuse RBCD via DACL - Detect & Mitigation

Mitigation

Same as indicated in Abuse RBCD via DACL - Detect & Mitigation

Outro

If you have made it into this hell, congratulations, you really deserve it! ​😁​

Although this is an extremely long post, i have detailed the most “common” attacks that Kerberos Delegation can offer, that said, now you have an extremely solid foundation to fall into the rabbit hole on your own, so, if you are so crazy to continue, start by looking at the articles listed in the references.

References

• https://hadess.io/pwning-the-domain-kerberos-delegation/
• https://medium.com/@offsecdeer/user-based-unconstrained-delegation-and-spn-jacking-29b916d1ff25
• https://medium.com/@offsecdeer/a-practical-guide-to-rbcd-exploitation-a3f1a47267d5
• https://labs.lares.com/fear-kerberos-pt4/
• https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html