martes, 14 de febrero de 2023

Setntlm: Escalando a Azure AD desde un sistema comprometido

 Estimados amigos de Inseguros !!!

Imagina un escenario habitual en los ejercicios de ciberseguridad, pentest, etc en los que nos hemos hecho con el dominio. No creas que hay que imaginar mucho xD.

Una de las cosas que vamos a hacer es posiblemente hacer un DCSYN, emular que somos un DC y replicar toda la base de datos para obtener los hashes de todas las cuentas.

Seguramente algunas las podremos crackear, otras no, da igual. Pero hoy por hoy nos encontramos con entornos en los que aún pudiendo hacer pass the hass en el equipo de la víctima, los usuarios ya no guardan todo en sus pc´s. Muchos usan Azure, Onedrive etc para guardar sus documentos... como debe ser.


Saltar de AD on premise a Azure a veces es muy fácil y otras veces muy complejo. Bueno seguimos.

Tenemos un hash o clave de un usuario potente, un admin. del sistema y queremos su keep pass que guarda en onedrive. Podríamos cambiar la clave del usuario en el dc, esperar media hora a que Azure Ad Connect hiciera su magia y ya tendríamos acceso a su nube, pero esto sería un poco disrruptivo, y según que ejercicio de redteam, podría no estar permitido.

Tampoco está permitido que los administradores de sistemas sepan la clave de los empleados, pero con un procedimiento como esté, podemos cambiarla, hacer "cosas" y volverla a cambiar...

Para ello nos vamos de paseo con Mimikatz, y explorar alguna de sus funciones.

Hacemos un dcsync, o cualquiera de los métodos que tenemos en nuestro arsenal, y sacamos el hash ntlm del usuario "jugoso"


Ahora tenemos la opción de cambiar la contraseña:


Y si queremos comprobarlo...



Pero no habíamos dicho que no podíamos cambiar las claves de un usuario? Podemos hacerlo por la noche, mientras no trabaja, y dejarle la contraseña como estaba:


Y aquí es donde entra la parte defensiva. Recuerdas una GPO de hace más de 20 años que dice: Vigencia Mínima de la contraseña? que no entedíamos muy bien para que estaba? ahora lo tenemos claro. si subes esta cifra, evitas que alguien pueda usar este hack.

Contraseñas recordadas, por defecto 24 en los nuevos Servers y dominios, pues lo mismo, deberíamos cambiar 24 veces la clave antes de poder volver a poner la que estaba...

Y por último, tienes eventos del tipo ;

4738(S): se cambió una cuenta de usuario.


Quizas en un SIEM debería haber alguna regla para este tipo de acciones...porque el malo va a tener que hacer varios cambios en un espacio de tiempo limitado...

Por otro lado, contar con una buena formación teórico-práctica es importante.

El 23 de Marzo se inicia un curso de 3 meses que imparto sobre Ciberseguridad en entornos Microsoft que te podría servir de ayuda en tu misión con la ciberseguridad en las empresas.
Si quieres estar informado, te paso un link para inscribirte en la lista y estar informado.

Gracias por leerme !!!