En este post vamos a ver a más bajo nivel como funcionan estos procesos que intervienen en el proceso de virtualización de Credential Guard que nació con el fin de evitar el volcado de memoria para la extracción de hashes con herramientas como mimikatz.
LSASS y LSAIso
Bien, como habíamos comentado , LSASS y LSAIso se comunican entre sí a través de ALPC y RPC (Explicado en el anterior post).
Bien , como sabemos , el SSP (Proveedor de Soporte de Seguridad) «MSV» (msv1_0.dll) es uno de los responsables de la autenticación NTLM y Kerberos.
Vamos a explicar un poco el proceso y diferencias que vemos entre tener Credential guard activado y no para discernir entre los distintos escenarios que nos podemos encontrar a más bajo nivel.
Vamos a ver el proceso a más bajo nivel , cuando el módulo msv1_0.dll (el SSP que se encargará de la autenticación) se carga en LSASS y se llama a la función SpInitialize para inicializarlo (el SSP), si Credential Guard está activado, SpInitialize creará un nuevo objeto
«NtlmCredIsoIum» y guardará la dirección de este objeto en una variable global llamada «LocalhostNtLmCredIsoObj::IsoObj«. Este objeto actuará como interfaz para implementar a la propia interfaz llamada «NtlmCredIsoApi».
Si Credential Guard no está habilitado, la variable «LocalhostNtLmCredIsoObj::IsoObj» almacenará en su lugar el objeto «NtLmCredIsoInProc», el cuál se encargará de implementar métodos que no se comunican con LSAIso, lo que provoca que las credenciales no se cifren.
Cuando se crea un nuevo objeto «NtlmCredIsoIum» (Credential Guard Activado, recordemos), se establece una relación entre ALPC con LSA_ISO_RPC_SERVER , mientras tanto , LSAIso ya está escuchando llamadas a procedimientos. Una vez establecido el enlace, MSV (SSP) llamará al método NtlmIumGetContext de LSAIso para obtener un «context handler».
Como vemos en la imagen el «context handler» lo pasa al objeto «NtlmCredIsoIum» durante la inicialización y se almacena en el offset 0x10 (dirección de memoria en la que se almacena)
Dentro de LSAIso, el método «NtlmIumGetContext» comprueba si ya se ha entregado una cookie de autenticación . Si es así, el método aborta. Si no, almacena dicha cookie en el «context handler» que se le ha pasado (en este caso hemos visto que lo alojaba en la dirección 0x10).
El proceso LSAIso asigna un valor único de cookie de autenticación a su propia memoria y lo asocia con el «context handler» que le ha proporcionado LSASS. Esto significa que, el proceso LSASS no puede acceder directamente al valor de dicha cooki, pero cuando se comunica con LSAIso utilizando el «context handler» , LSAIso puede reconocer que el valor de la cookie está asociado a ese manejador de contexto específico.
Al final la interfaz RPC compartida entre LSASS y LSAIso especifica qué datos se intercambian entre los dos procesos. Como resultado, no se puede asumir que una operación sobre un parámetro dentro de LSAIso tendrá algún efecto sobre el parámetro correspondiente en LSASS.
Herramienta para bypass que se basa en esto by Oliver Lyak
Mediante esta comunicación se ha conseguido bypassear Credential Guard con una herramienta llamada «PassTheChallenge» que ha desarrollado Oliver Lyak, la cuál podéis encontrar y trastear con ella, os dejo el repositorio de la herramienta por si quereis «trastear» , yo la he probado y la verdad que funciona a la perfección.
https://github.com/ly4k/PassTheChallenge
Fuentes:
Microsoft – Oliver Lyak – github
