Post-Explotación de “Incognito”

Incognito es una herramienta utilizada para el escalado de privilegios dentro de un dominio de “Active Directory” en la fase de post-explotación de un test de intrusión.

En un principio era una herramienta independiente, pero más tarde se integro en Metasploit, y finalmente en Meterpreter (esta es la parte que vamos a utilizar en esta demostración).

Incognito sirve para “impersonalizar” tokens de autenticación de usuarios en sistemas Windows comprometidos.

Los tokens de autenticación son algo parecido a las Cookies de internet, son una llave temporal que sirve para acceder a distintos servicios o ficheros del dominio sin tener que estar proporcionando las credenciales de acceso en cada momento.

Existen dos tipos de tokens, de “impersonalización” y de “delegación”.

  • Delegación: Son los tokens utilizados en sesiones interactivas, como al hacer login en la maquina o acceder por escritorio remoto.
  • Impersonalización: Son los tokens utilizados en sesiones no interactivas, como conectar a una unidad de red.

Estos tokens, una vez generados en un sistema permanecen en el hasta que se reinicia. Por ejemplo cuando un usuario hace “log-out” del sistema, su token de
“delegación” se convierte en token de “impersonalización” y se queda en la memoria del sistema, con los mismos permisos que tenía al ser token de “delegación”.

Con “Incognito” una vez comprometido un sistema y escalado los privilegios a nivel de administrador o “SYSTEM”, podemos suplantar a cualquier usuario que haya generado un token en dicho sistema.

Pero, ¿Para que queremos suplantar a un usuario si ya somos el usuario “Administrador” o “System”?

La respuesta es “para poder escalar privilegios dentro del dominio”. Supongamos que somos administradores de un servidor de la red y accedemos a los “hashes” de usuario obteniendo el “hash” del usuario “Administrador”. Por lo general debido a la reutilización de contraseñas, este “hash” nos dará acceso a otros servidores, en algunos casos hasta será el “hash” del administrador del dominio, pero ¿Qué ocurre si esto no es así?, ¿Qué pasa si las credenciales de administrador del dominio son distintas a las credenciales de administrador local?

Aquí es donde entra en juego “Incognito” y la capacidad de suplantar identidades.

Para comprenderlo de forma fácil y gráfica, he preparado en el laboratorio una red de demostración formada por 3 servidores, un Windows 2008 R2 (este será el controlador del dominio,) y dos Windows Server 2003, uno llamado SRV-PROD y otro llamado SRV-DEV.

A continuación se encuentra el diagrama de red:

lan-demo

En la red, existe un usuario “Administrador” local en cada servidor con las mismas credenciales (“Administrator” en este caso porque los Windows 2003 Server están en inglés), un usuario Administrador del dominio y los usuarios Alice y Bob. Alice es miembro del departamento de IT y por lo tanto administrador del dominio y Bob es el contable de la empresa por lo que su usuario es un usuario sin privilegios.

La demostración parte del supuesto en que el PenTester ha conseguido una shell de meterpreter en el servidor de producción (SRV-PROD) y ha escalado privilegios hasta el usuario “System”. Como conseguir la shell queda fuera del ámbito de este artículo, tan solo comentar que puede hacerse de muchas formas, como a través de alguna inyección SQL en una aplicación web que utilice MS-SQL Server, con Ingeniería social, explotando algún bug conocido de algún servicio, con un 0 day, etc.

Aquí vemos nuestra sesión de partida:

incognito1

A continuación cargamos la extensión “Incognito” y mostramos los tokens de usuarios y grupos que hay en el sistema.

incognito2

Como puede verse, todo son tokens de la maquina local de la cual ya somos el usuario “SYSTEM”. Necesitamos buscar más equipos en la red para poder progresar hasta nuestro objetivo final.

Para ello una posible solución es el comando “net view” de Windows que nos mostrará las maquinas y recursos del dominio.

incognito3

De la salida de “net view” podemos observar que en el dominio hay al menos 2 maquinas más, DC1 y SRV-DEV. Podríamos ver los recursos compartidos de DC1 por ejemplo ejecutando “net view \\DC1”.

Conociendo las máquinas de la red, podemos averiguar su dirección IP utilizando por ejemplo “nslookup”.

incognito4

El siguiente paso para un PenTester (o un atacante), sería probar a acceder a las distintas máquinas con un ataque “pass the hash” utilizando las credenciales obtenidas en nuestra máquina comprometida.

En el caso que nos ocupa, para la demostración la maquina atacante está en la misma LAN que las máquinas víctima, con lo cual atacamos directamente a estas. En el caso más real, cuando el PenTester o atacante se encuentra fuera de la LAN pero ya tiene una sesión de meterpreter en una máquina interna, tan solo hay que añadir una ruta a Metasploit diciéndole que utilice la sesión obtenida como Gateway a la LAN destino. A partir de ahí, todo funciona de la misma forma (es recomendable utilizar “bind payloads” en lugar de “reverse payloads” a menos que el atacante tenga una ip pública que la víctima pueda alcanzar sin problemas).

En primer lugar probamos con “DC1”, ya que si accedemos a esta como administrador, ya habremos conseguido nuestro objetivo.

incognito5

Como se puede observar en la imagen anterior, no es posible acceder a DC1 utilizando las credenciales obtenidas. He probado utilizando como dominio “WORKGROUP”, el nombre de la máquina “DC1” y el nombre del dominio real “ACME.local” y en todos los casos el resultado ha sido negativo.

Cambiamos pues la dirección IP por la de nuestro siguiente servidor (192.168.65.102).

incognito6

En este caso también falla, pero recordemos que al principio hemos dicho que los Windows 2003 Server utilizados en la demo están en Ingles. En este caso el usuario predeterminado no es “Administrador” sino “Administrator”. Lo cambiamos pues y volvemos a probar.

incognito7

Bingo, hemos logrado acceso reutilizando credenciales. Ahora hay que analizar lo que nos puede ofrecer esta máquina.

incognito8

En este caso como se puede ver resaltado en la imagen anterior, tenemos un token del dominio “ACME” perteneciente al usuario “alice”.

Abrimos una shell de windows desde Meterpreter y comprobamos los grupos a los que pertenece nuestra posible víctima.

incognito9

Bingo!!!, el usuario “alice” pertenece al grupo de “Admins. del dominio”. Esto significa que al poder suplantar su identidad también seremos administradores del dominio y podremos operar como tal en todas la máquinas del dominio.

Así pues, vamos a utilizar el token de “alice” para suplantar su identidad.

incognito10

Una vez convertidos en “Alice” podemos utilizar la propia consola de “cmd.exe” para crear un usuario administrador del dominio que controlemos.

Aquí un ejemplo.

incognito11

Se ha creado un usuario “hacker” con contraseña “g00dhack123” y se ha metido en el grupo de “Admins. del dominio”.

Lo podemos comprobar directamente en la consola de “Usuarios del Dominio” en el servidor DC1.

incognito12 incognito13

En este momento ya somos administradores del dominio con un usuario que controlamos totalmente, el cual podremos utilizar para conectar por escritorio remoto a cualquier máquina del dominio que lo tenga activado (por lo general muchísimas empresas a día de hoy todavía tienen accesos externos a servidores de Terminal Server abiertos al público).

Bueno esto es todo por ahora. Espero que os haya gustado.

Un saludo y Feliz Navidad!!!.

Publicado en: Incognito, Metasploit, Post-Explotación
5 comentarios sobre “Post-Explotación de “Incognito”
  1. Gerard Fernandez dice:

    Muy buen artículo Igancio. Un placer leerte.

    Tengo una dudilla al respecto.

    Entiendo que la contramedida de seguridad para evitar la delegación de las cuentas importantes de Active Directory seria, marcar la opción de “Esta cuenta es importante y no se puede delegar” en las propiedades del usuario de AD. Concretamente en las opciones de “Cuenta”. De esta manera, sino me equivoco, podríamos protegernos de ataques “pass the hash” utilizando cuentas importantes.

    Pero ésta medida habla de “Delegación” y tu comentas que una vez se cierra la sesión el hash pasa a ser de impersonalización y es éste el que utilizamos. La medida que propongo sirve también para dicho hash?

    Gracias!!

    • Ignacio Sorribas dice:

      Hola Gerard, pues muy buena pregunta.
      Primero decir que marcar la cuenta como importante, evita el tema de la delegación, pero no te protege ante ataques “pass the hash”.
      Como no sabía muy bien la respuesta correcta, he vuelto a montar el lab y lo he probado in situ a ver que tal. Si la cuenta está marcada como que no se puede delegar, en el momento en que haces “impersonate_token ACME\\alice”, meterpreter contesta:
      [-] No delegation token available
      [+] Successfully impersonated user ACME\alice
      Entonces el resultado es que hemos suplantado al usuario, pero en realidad solo en el equipo local ya que no se permite la delegación. Si se intenta crear un usuario en el dominio como en la demo, este se crea en este servidor, pero no en el Controlador de Dominio.

      Muy buen aporte por tu parte Gerard.

      Un saludo.

  2. Gerard Fernandez dice:

    Hola de nuevo Ignacio,

    Perfecto. Entiendo pues que proteger cuentas con privilegios elevados en el dominio contra la delegación, es una buena manera de “fortificar” el AD, aunque como muy bien comentas, no te protege al 100% de los ataques “pass the hash”. Sólo en estos casos concretos ya que demuestras claramente que el servidor local queda comprometido. De todas maneras limitas muchísimo el daño y el alcance del ataque ya que de la otra manera el atacante consigue las llaves de tu casa par hacer lo que quiera :)

    No conocía tu blog pero lo encuentro sencillamente una pasada! Estamos en contacto! Muchísimas gracias por tu tiempo!

    • Ignacio Sorribas dice:

      De nada hombre, precisamente por eso lo escribo.
      Como tu bien dices, si es una buena práctica para limitar el daño. En cuanto a los ataques “pass the hash” hay un documento de microsoft que habla de como limitar su impacto (te lo dejo aquí), y entre otras medidas, para mi la mas efectiva pero menos “usable” es la de no utilizar la misma contraseña para las cuentas importantes (la del administrador por ejemplo) en cada máquina de la red, sino que tener una contraseña para cada máquina (como he dicho antes esto no es para nada práctico).

      Un saludo Gerard.

  3. Gerard Fernandez dice:

    Si tienes razón…y aún menos práctico en entornos medianos/grandes. Gracias por el documento, voy a hincarle el diente cuando pueda..parece muy interesante.
    Hablamos!!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*