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 pero dejo los pasos de explotación.

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':/p>

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.

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: HackPlayers