Continuación de la entrada “Laboratorios – Creando nuestro primer Active Directory de pruebas”, donde configuraremos un escenario básico para entender como podemos escalar privilegios en un Active Directory utilizando configuraciones inseguras.
REQUERIMIENTOS:
- Dos nuevas cuentas de dominio (cosme.fulanito y hank.scorpio en mi caso).
- Un nuevo administrador local en dos equipos (ATENCION01 y TECNOLOGIA01).
- Instalación funcional de Kali Linux en el mismo segmento de red del dominio.
Para configurar el siguiente escenario en el Active Directory que montamos, primeramente debemos crear cuentas de usuario local en los equipos “ATENCION01” y “TECNOLOGIA01”.
Accediendo como el usuario administrador de dominio.
Creando al usuario local “soporte”.
Agregar al usuario “cosme.fulanito” al grupo de administradores locales, se realiza únicamente a este equipo.
Crear el usuario local “soporte” en el equipo “TECNOLOGIA01”.
IMPORTANTE: Utilizar la misma contraseña para el usuario “soporte” (o el nombre que decidan darle), es una práctica de seguridad insegura que explotaremos en este laboratorio.
De la misma manera, agregamos a un usuario de dominio al grupo de administradores locales en “TECNOLOGIA01”, en mi caso, tengo al usuario “hank.scorpio” que fue creado para esta entrada.
Agregando al usuario “hank.scorpio” al grupo de administradores en el equipo “BD01”.
Finalmente, asegurarse de iniciar sesión con el usuario “Administrator”.
INICIO DE LA EXPLOTACIÓN
Asumimos que, de alguna manera, se obtuvieron las credenciales del usuario “cosme.fulanito” y tenemos acceso a la red interna con nuestro propio equipo de pentesting.
Como primer paso, con acceso al equipo Windows, enumeramos los usuarios locales.
Identificamos ciertos usuarios que no vienen en la instalación por defecto, como ser “sshd”, “IEUser”, “sshd_server” y “soporte”.
Tambien observamos que nuestro usuario, “cosme.fulanito”, es miembro del grupo local “Administrators”, por lo que podemos utilizarlo para buscar credenciales en el equipo.
Pero, como primer paso, al tratarse de un laboratorio de Active Directory, el primer paso recomendado es la enumeración del dominio, para identificar usuarios existentes, equipos registrados, la política de contraseñas, relaciones de confianza, etc.
Obtenemos el nombre del dominio actual y su posible dirección IP.
En el raro caso de que tengamos un servidor DNS distinto al controlador de dominio (Nunca lo vi) o exista más de un controlador de dominio, podemos utilizar el comando “nslookup” para obtener una lista de controladores de dominio.
Con esta información, ya podemos empezar a extraer información del controlador de dominio de manera autenticada.
En nuestro host con Kali, ejecutaremos la herramienta “ldapdomaindump”.
Los parámetros utilizados son:
- -u ‘Dominio\Usuario’ (Es necesario utilizar el simbolo “\”, ya que sin el mismo la herramienta falla)
- -p ‘Password’
- OBJETIVO: IP del controlador de dominio con el servicio LDAP expuesto
Obtenemos una serie de ficheros en distintos formatos que tienen la información que nos interesa.
Si abrimos uno de los ficheros, por ejemplo, “domain_users.html” en un navegador web, tenemos desplegada la siguiente información.
De esta manera, podemos obtener una lista completa de todos los usuarios del dominio objetivo, para ataques de fuerza bruta o password spraying.
De la misma forma, obtenemos la lista de todos los equipos registrados en el dominio.
Nos enfocaremos en el movimiento lateral que podemos realizar con la configuración que realizamos, por lo que el fichero de computadoras registradas en el dominio nos servira más adelante.
Como ya sabemos, el usuario que tenemos es administrador local en el equipo “ATENCION01”, por lo que utilizaremos la suite de Impacket para obtener hashes de usuarios locales e información almacenada en cache del dominio.
FORMATO: impacket-secretsdump Dominio/usuario:password@equipo.dominio
De esta manera, obtenemos los hashes NTLM de dos usuarios locales interesantes, Administrator y soporte.
Ahora, podemos tomar dos caminos.
- Utilizar al usuario de dominio para intentar autenticarse sobre el resto de equipos, para ver si es administrador en algun equipo adicional.
- Intentar un ataque Pass the hash con los usuarios locales.
Para ambos escenarios, necesitamos una lista de objetivos, que la podemos obtener de manera rapida con un poco de “awk”:
COMANDO: awk -F ‘\t’ ‘{print $3}’ domain_computers.grep
Este comando extrae los datos almacenados en el fichero “domain_computers.grep”, obtenido a través de “ldapdomaindump”, la flag -F ‘\t’ marca el delimitador, diciendole a la herramienta que la primera columna va desde el inicio de la linea de texto hasta que se encuentre con una tabulación, marcada con \t, la segunda columna va desde esa tabulación hasta la siguiente. Separando el archivo de texto de esta manera, imprimiremos la columna 3, que contiene el dnsHostName de todos los equipos registrados en el dominio, otorgándonos una lista rapida de objetivos.
Tenemos 4 objetivos identificados de manera rápida, sobre los cuales haremos el resto de pruebas.
Para validar el primer escenario planteado, donde se analiza si “cosme.fulanito” es administrador local en otros equipos, utilizaremos la herramienta “crackmapexec”.
COMANDO: crackmapexec Protocolo IP/hostname/fichero_con_objetivos -u usuario -p password -d dominio O –local-auth para autenticacion local.
Observamos que nuestro usuario de dominio solo tiene privilegios de administración en “ATENCION01”, por lo que procedemos con el segundo escenario.
Primeramente intentamos utilizar al usuario “Administrator” de manera local.
Observamos que el usuario existe en dos equipos, pero la cuenta esta deshabilitada, afortunadamente aun tenemos al usuario “soporte”.
El usuario “soporte” existe igualmente en el equipo “TECNOLOGIA01” y es administrador local, presentando un caso típico de Pass the hash.
Replicamos pasos anteriores, obteniendo los hashes NTLM del equipo “TECNOLOGIA01”.
No observamos nada nuevo en usuarios locales, pero si vemos en la información cacheada de dominio que, en algún momento, los usuarios “jseclow”, “admin”, “Administrator” y “hank.scorpio” se autenticaron a este equipo, por lo que es posible que las credenciales de alguno de estos se encuentren en memoria.
Para dumpear el proceso LSASS y obtener hashes NTLM de memoria, podemos utilizar crackmapexec nuevamente, con uno de sus módulos disponibles “LSASSY”.
Obtenemos un error al intentar dumpear LSASS de esta manera, usualmente esto se debe a un antivirus que bloquea la ejecucion de LSASSY.
Podemos intentar deshabilitar el antivirus, asumiendo que es Windows Defender, de manera remota con una sesión de comandos interactiva.
COMANDO: impacket-wmiexec (*)./usuario@equipo -hashes HASH_NTLM -shell-type powershell
(*) Como estamos utilizando una cuenta de administrador local, no tenemos que establecer un dominio de autenticación, por lo que colocamos unicamente “.”.
Podemos deshabilitar Windows Defender utilizando Powershell, por esa razon, es necesario que nuestra shell remota sea con Powershell, lo cual se indica con el parametro “-shell-type”.
El comando para deshabilitar Windows Defender de manera remota es: Set-MPPreference -disableRealTimeMonitoring $true
No obtenemos un error al ejecutar el comando, por lo que reintentamos obtener los contenidos de LSASS con LSASSY.
De esta manera obtenemos el hash NTLM del usuario “hank.scorpio”, por lo que volvemos a plantear los dos escenarios anteriores.
- Verificar si el usuario de dominio tiene privilegios administrativos sobre otros equipos del dominio.
- Utilizar los usuarios locales para validar la existencia de otros administradores locales.
Como no obtuvimos ningun nuevo hash de usuarios locales que valga la pena analizar, exploramos el primer escenario.
Utilizando crackmapexec volvemos a analizar todos los equipos del dominio con el nuevo usuario obtenido.
COMANDO: crackmapexec protocolo IP/hostname/lista_de_objetivos -u usuario -H hash_ntlm -d dominio_de_autenticacion
En este caso, al tratarse de un usuario de dominio, utilizamos el parametro “-d”.
Observamos que tenemos privilegios administrativos sobre el servidor “BD01”, por lo que replicamos pasos anteriores.
Obtencion de hashes NTLM.
No observamos nada nuevo en usuarios locales, sin embargo, vemos que la única credencial de dominio cacheada es la del usuario “JSEC.LOCAL/Administrator” indicando que se trata del Administrador de dominio.
Como esta cacheada, es posible que se encuentre en memoria, dumpeamos LSASS nuevamente para validar el caso.
Identificamos el hash NTLM del usuario “JSEC\Administrator”, por lo que lo validamos sobre el controlador de dominio.
El hash es valido y podemos personificar al usuario “Administrator”, por lo que procedemos a dumpear todos los hashes del dominio, al leer el fichero “NTDS.DIT” de manera remota.
COMANDO: crackmapexec procotolo IP/Hostname/lista_de_objetivos -u usuario -H hash_ntlm -d dominio –ntds
Con este nivel de privilegios podemos asegurar nuestra persistencia de una manera no tan sigilosa, al crear un nuevo usuario de dominio y agregarlo al grupo de “Domain Admins”.
Validamos nuestro acceso.
Obtuvimos control total del dominio.
Este escenario es básico, pero es muy probable que practicas similares a las observadas acá aun estén presentes en organizaciones, explote vectores similares varias veces durante las evaluaciones que realice como Pentester, no de una manera tan sencilla, siempre se tienen controles adicionales que se intentan bypassear o se tiene que acceder a numerosos equipos hasta identificar nuevas credenciales que puedan servir para seguir escalando privilegios, sin embargo, la idea general persiste.