Breaching Active Directory
Última actualización
Última actualización
Dos métodos populares para obtener acceso a ese primer conjunto de credenciales de AD son Open Source Intelligence (OSINT) y Phishing. Aquí sólo mencionaremos brevemente los dos métodos, ya que ya se tratan con más profundidad en otras salas.
OSINT se utiliza para descubrir información que se ha divulgado públicamente. En términos de credenciales de AD , esto puede suceder por varios motivos, como por ejemplo:
Al utilizar técnicas OSINT , es posible recuperar credenciales divulgadas públicamente. Si tenemos la suerte de encontrar credenciales, aún necesitaremos encontrar una manera de probar si son válidas o no, ya que la información OSINT puede estar desactualizada. En la Tarea 3, hablaremos sobre los servicios autenticados NTLM, que pueden proporcionar una excelente vía para probar las credenciales y ver si aún son válidas.
El phishing es otro método excelente para violar AD. El phishing suele incitar a los usuarios a proporcionar sus credenciales en una página web maliciosa o pedirles que ejecuten una aplicación específica que instalaría un troyano de acceso remoto (RAT) en segundo plano. Este es un método frecuente ya que RAT se ejecutaría en el contexto del usuario, permitiéndole inmediatamente hacerse pasar por la cuenta AD de ese usuario. Es por eso que el phishing es un tema tan importante tanto para los equipos rojo como para los azules.
New Technology LAN Manager ( NTLM ) es el conjunto de protocolos de seguridad utilizados para autenticar las identidades de los usuarios en AD. NTLM se puede utilizar para la autenticación mediante un esquema basado en desafío-respuesta llamado NetNTLM. Este mecanismo de autenticación es muy utilizado por los servicios de una red. Sin embargo, los servicios que utilizan NetNTLM también pueden estar expuestos a Internet. Los siguientes son algunos de los ejemplos populares:
Servidores Exchange (correo) alojados internamente que exponen un portal de inicio de sesión de Outlook Web App (OWA).
Servicio de Protocolo de escritorio remoto ( RDP ) de un servidor expuesto a Internet.
Puntos finales de VPN expuestos que se integraron con AD.
Aplicaciones web que están orientadas a Internet y utilizan NetNTLM.
Net NTLM , también conocido como autenticación de Windows o simplemente autenticación NTLM, permite que la aplicación desempeñe el papel de intermediario entre el cliente y AD. Todo el material de autenticación se envía a un controlador de dominio en forma de desafío y, si se completa con éxito, la aplicación autenticará al usuario.
Como se mencionó en la Tarea 2, estos servicios expuestos brindan una ubicación excelente para probar las credenciales descubiertas por otros medios. Sin embargo, estos servicios también se pueden utilizar directamente en un intento de recuperar un conjunto inicial de credenciales AD válidas . Quizás podríamos intentar usarlos para ataques de fuerza bruta si recuperamos información como direcciones de correo electrónico válidas durante nuestro reconocimiento inicial del equipo rojo.
Dado que la mayoría de los entornos AD tienen configurado el bloqueo de cuentas, no podremos ejecutar un ataque completo de fuerza bruta. En su lugar, necesitamos realizar un ataque de pulverización de contraseñas. En lugar de probar varias contraseñas diferentes, lo que puede activar el mecanismo de bloqueo de la cuenta, elegimos y utilizamos una contraseña e intentamos autenticarnos con todos los nombres de usuario que hemos adquirido. Sin embargo, cabe señalar que este tipo de ataques pueden detectarse debido a la cantidad de intentos fallidos de autenticación que generarán.
Navegando a la URL, podemos ver que nos solicita las credenciales de autenticación de Windows:
Nota: El complemento de autenticación de Windows de Firefox es increíblemente propenso a fallar. Si desea probar las credenciales manualmente, se recomienda Chrome.
Esta función toma nuestra contraseña sugerida y la URL a la que nos dirigimos como entrada e intenta autenticarse en la URL con cada nombre de usuario en el archivo de texto. Al monitorear las diferencias en los códigos de respuesta HTTP de la aplicación, podemos determinar si el par de credenciales es válido o no. Si el par de credenciales es válido, la aplicación responderá con un código 200 HTTP (OK). Si el par no es válido, la aplicación devolverá un código HTTP 401 (no autorizado).
Si está utilizando AttackBox, el script de distribución de contraseñas y el archivo de texto de nombres de usuarios se proporcionan en el /root/Rooms/BreachingAD/task3/directorio. Podemos ejecutar el script usando el siguiente comando:
Proporcionamos los siguientes valores para cada uno de los parámetros:
userfile - Archivo de texto que contiene nuestros nombres de usuario "usernames.txt"
fqdn : nombre de dominio completo asociado con la organización que estamos atacando: "za.tryhackme.com"
password - La contraseña que queremos usar para nuestro spraying attack - "Changeme123"
attackurl: la URL de la aplicación que admite la autenticación de Windows: "http://ntlmauth.za.tryhackme.com"
Usando estos parámetros, deberíamos obtener algunos pares de credenciales válidos de nuestro ataque de pulverización de contraseñas.
NTLM Password Spraying Attack
Utilizando una combinación de pulverización de contraseñas OSINT y NetNTLM, ahora tenemos nuestros primeros pares de credenciales válidos que podrían usarse para enumerar AD más.
Otro método de autenticación AD que pueden utilizar las aplicaciones es la autenticación del Protocolo ligero de acceso a directorios (LDAP). La autenticación LDAP es similar a la autenticación NTLM. Sin embargo, con la autenticación LDAP, la aplicación verifica directamente las credenciales del usuario. La aplicación tiene un par de credenciales de AD que puede usar primero para consultar LDAP y luego verificar las credenciales del usuario de AD.
La autenticación LDAP es un mecanismo popular entre aplicaciones de terceros (que no sean de Microsoft) que se integran con AD . Estos incluyen aplicaciones y sistemas como:
Gitlab
Jenkins
Aplicaciones web desarrolladas a medida
Impresoras
VPN
Si alguna de estas aplicaciones o servicios queda expuesta en Internet, se puede utilizar el mismo tipo de ataques que los utilizados contra sistemas autenticados NTLM . Sin embargo, dado que un servicio que utiliza autenticación LDAP requiere un conjunto de credenciales AD, abre vías de ataque adicionales. En esencia, podemos intentar recuperar las credenciales de AD utilizadas por el servicio para obtener acceso autenticado a AD. El proceso de autenticación a través de LDAP se muestra a continuación:
Si pudiera establecerse en el host correcto, como un servidor Gitlab, podría ser tan simple como leer los archivos de configuración para recuperar estas credenciales de AD . Estas credenciales a menudo se almacenan en texto sin formato en archivos de configuración, ya que el modelo de seguridad se basa en mantener seguros la ubicación y el archivo de configuración de almacenamiento en lugar de su contenido. Los archivos de configuración se tratan con más profundidad en la Tarea 7.
Ataques de transferencia LDAP
Sin embargo, se puede realizar otro ataque muy interesante contra los mecanismos de autenticación LDAP, llamado ataque LDAP Pass-back. Este es un ataque común contra dispositivos de red, como impresoras, cuando se ha obtenido acceso inicial a la red interna, como al conectar un dispositivo no autorizado en una sala de juntas.
Los ataques LDAP Pass-back se pueden realizar cuando accedemos a la configuración de un dispositivo donde se especifican los parámetros LDAP. Puede ser, por ejemplo, la interfaz web de una impresora de red. Por lo general, las credenciales para estas interfaces se mantienen en las predeterminadas, como admin:admino admin:password. Aquí no podremos extraer directamente las credenciales LDAP ya que la contraseña suele estar oculta. Sin embargo, podemos alterar la configuración LDAP, como la IP o el nombre de host del servidor LDAP. En un ataque de transferencia LDAP, podemos modificar esta IP a nuestra IP y luego probar la configuración LDAP, lo que obligará al dispositivo a intentar la autenticación LDAP en nuestro dispositivo no autorizado. Podemos interceptar este intento de autenticación para recuperar las credenciales LDAP.
Realizar una transferencia LDAP
Mediante la inspección del navegador, también podemos verificar que el sitio web de la impresora sea al menos lo suficientemente seguro como para no simplemente enviar la contraseña LDAP al navegador:
Entonces tenemos el nombre de usuario, pero no la contraseña. Sin embargo, cuando presionamos configuración de prueba, podemos ver que se realiza una solicitud de autenticación al controlador de dominio para probar las credenciales LDAP. Intentemos aprovechar esto para que la impresora se conecte a nosotros, lo que revelaría las credenciales. Para hacer esto, usemos un oyente Netcat simple para probar si podemos lograr que la impresora se conecte con nosotros. Dado que el puerto predeterminado de LDAP es 389, podemos usar el siguiente comando:
Tenga en cuenta que si usa AttackBox, primero debe desactivar slapd usando service slapd stop. Luego, podemos modificar el cuadro de entrada del Servidor en la aplicación web para que apunte a nuestra IP y presionar Probar configuración.
Su IP será su IP de VPN y será una IP 10.50.xx o una IP 10.51.xx. Puede utilizar**ip a para enumerar todas las interfaces. Asegúrese de utilizar esto como su IP; de lo contrario, no recibirá una conexión. Tome nota también de la interfaz de esta IP, ya que la necesitará más adelante en la tarea.
Deberías ver que recuperamos la conexión, pero hay un pequeño problema:
Escucha LDAP de Netcat
Es posible que necesites más de un intento para recuperar la conexión, pero debería responder en 5 segundos. La supportedCapabilitiesrespuesta nos dice que tenemos un problema. Básicamente, antes de que la impresora envíe las credenciales, intenta negociar los detalles del método de autenticación LDAP. Utilizará esta negociación para seleccionar el método de autenticación más seguro que admitan tanto la impresora como el servidor LDAP. Si el método de autenticación es demasiado seguro, las credenciales no se transmitirán en texto sin cifrar. Con algunos métodos de autenticación, las credenciales no se transmitirán en absoluto a través de la red. Entonces no podemos simplemente usar Netcat normal para recolectar las credenciales. Necesitaremos crear un servidor LDAP fraudulento y configurarlo de forma insegura para garantizar que las credenciales se envíen en texto sin formato.
Hay varias formas de alojar un servidor LDAP no autorizado, pero usaremos OpenLDAP para este ejemplo. Si está utilizando AttackBox, OpenLDAP ya se ha instalado. Sin embargo, si está utilizando su propia máquina de ataque, necesitará instalar OpenLDAP usando el siguiente comando:
Sin embargo, también tendrás que configurar tu propio servidor LDAP no autorizado en AttackBox. Comenzaremos reconfigurando el servidor LDAP usando el siguiente comando:
Asegúrese de presionar No cuando se le solicite si desea omitir la configuración del servidor:
Para el nombre de dominio DNS , desea proporcionar nuestro dominio de destino, que esza.tryhackme.com :
Utilice también este mismo nombre para el nombre de la organización:
Seleccione MDB como base de datos LDAP a utilizar:
Para las dos últimas opciones, asegúrese de que la base de datos no se elimine cuando se purgue:
Mueva los archivos de bases de datos antiguos antes de crear uno nuevo:
Antes de utilizar el servidor LDAP fraudulento, debemos hacerlo vulnerable degradando los mecanismos de autenticación admitidos. Queremos asegurarnos de que nuestro servidor LDAP solo admita métodos de autenticación PLAIN e LOGIN. Para hacer esto, necesitamos crear un nuevo archivo ldif, llamado con el siguiente contenido:
olcSaslSecProps.ldif
El archivo tiene las siguientes propiedades:
olcSaslSecProps: especifica las propiedades de seguridad de SASL
noanonymous: Desactiva los mecanismos que admiten el inicio de sesión anónimo
minssf: especifica la fuerza de seguridad mínima aceptable con 0, lo que significa que no hay protección.
Ahora podemos usar el archivo ldif para parchear nuestro servidor LDAP usando lo siguiente:
Podemos verificar que la configuración de nuestro servidor LDAP fraudulento se haya aplicado usando el siguiente comando ( Nota : si está utilizando Kali, es posible que no reciba ningún resultado; sin embargo, la configuración debería haber funcionado y puede continuar con los siguientes pasos):
Búsqueda LDAP para verificar los mecanismos de autenticación admitidos
Además, tenga en cuenta que password11es un ejemplo. La contraseña de su servicio será diferente. Es posible que tengas que presionar el botón "Probar configuración" un par de veces antes de que TCPdump devuelva datos, ya que estamos realizando el ataque a través de una conexión VPN .
¡Ahora tenemos otro conjunto de credenciales AD válidas! Al utilizar un ataque de transferencia LDAP y degradar el mecanismo de autenticación admitido, podríamos interceptar las credenciales en texto sin cifrar.
Continuando con los ataques que se pueden realizar desde nuestro dispositivo fraudulento, ahora veremos los ataques contra protocolos de autenticación de red más amplios. En las redes Windows, hay una cantidad importante de servicios que se comunican entre sí, lo que permite a los usuarios hacer uso de los servicios proporcionados por la red.
Estos servicios deben utilizar métodos de autenticación integrados para verificar la identidad de las conexiones entrantes. En la Tarea 2, exploramos la autenticación NTLM utilizada en una aplicación web. En esta tarea, profundizaremos un poco más para ver cómo se ve esta autenticación desde la perspectiva de la red. Sin embargo, para esta tarea, nos centraremos en la autenticación NetNTLM utilizada por SMB.
El protocolo Server Message Block ( SMB ) permite a los clientes (como estaciones de trabajo) comunicarse con un servidor (como un archivo compartido). En las redes que utilizan Microsoft AD, SMB gobierna todo, desde el intercambio de archivos entre redes hasta la administración remota. Incluso la alerta de "falta de papel" que recibe su computadora cuando intenta imprimir un documento es obra del protocolo SMB.
Sin embargo, la seguridad de versiones anteriores del protocolo SMB se consideró insuficiente. Se descubrieron varias vulnerabilidades y exploits que podrían aprovecharse para recuperar credenciales o incluso obtener la ejecución de código en los dispositivos. Aunque algunas de estas vulnerabilidades se resolvieron en versiones más nuevas del protocolo, a menudo las organizaciones no imponen el uso de versiones más recientes porque los sistemas heredados no las admiten. Analizaremos dos exploits diferentes para la autenticación NetNTLM con SMB:
Dado que los NTLM Challenges se pueden interceptar, podemos utilizar técnicas de descifrado fuera de línea para recuperar la contraseña asociada con NTLM Challenge. Sin embargo, este proceso de descifrado es significativamente más lento que descifrar hashes NTLM directamente.
Podemos usar nuestro dispositivo fraudulento para organizar un ataque de hombre en el medio, transmitiendo la autenticación SMB entre el cliente y el servidor, lo que nos proporcionará una sesión autenticada activa y acceso al servidor de destino.
En esta tarea, veremos un poco la autenticación que ocurre durante el uso de SMB . Usaremos Responder para intentar interceptar el desafío NetNTLM y descifrarlo. Por lo general, hay muchos de estos desafíos circulando por la red. Algunas soluciones de seguridad incluso realizan un barrido de rangos completos de IP para recuperar información de los hosts. A veces, debido a registros DNS obsoletos, estos desafíos de autenticación pueden terminar afectando a su dispositivo no autorizado en lugar del host previsto.
Responder nos permite realizar ataques Man-in-the-Middle envenenando las respuestas durante la autenticación NetNTLM, engañando al cliente para que hable con usted en lugar de con el servidor real al que desea conectarse. En una LAN real, Responder intentará envenenar cualquier solicitud de resolución de nombres de multidifusión local de enlace (LLMNR), servicio de nombres NetBIOS (NBT-NS) y descubrimiento automático de proxy web (WPAD) que se detecte. En redes Windows grandes, estos protocolos permiten a los hosts realizar su propia resolución DNS local para todos los hosts en la misma red local. En lugar de sobrecargar los recursos de la red, como los servidores DNS, los hosts pueden intentar primero determinar si el host que buscan está en la misma red local enviando solicitudes LLMNR y viendo si algún host responde. NBT-NS es el protocolo precursor de LLMNR, y las solicitudes WPAD se realizan para intentar encontrar un proxy para futuras conexiones HTTP.
Dado que estos protocolos dependen de solicitudes transmitidas en la red local, nuestro dispositivo fraudulento también recibiría estas solicitudes. Por lo general, estas solicitudes simplemente se descartarían ya que no estaban destinadas a nuestro anfitrión. Sin embargo, Responder escuchará activamente las solicitudes y enviará respuestas envenenadas diciéndole al host solicitante que nuestra IP está asociada con el nombre de host solicitado. Al envenenar estas solicitudes, Responder intenta forzar al cliente a conectarse a nuestro AttackBox. En la misma línea, pasa a alojar varios servidores como SMB, HTTP, SQL y otros para capturar estas solicitudes y forzar la autenticación.
Una cosa a tener en cuenta es que Responder esencialmente intenta ganar la condición de carrera envenenando las conexiones para asegurarse de interceptar la conexión. Esto significa que Responder generalmente se limita a envenenar los desafíos de autenticación en la red local. Dado que estamos conectados a la red a través de una VPN , solo podremos envenenar los desafíos de autenticación que ocurran en esta red VPN. Por este motivo, hemos simulado una solicitud de autenticación que puede ser envenenada y que se ejecuta cada 30 minutos. Esto significa que es posible que tenga que esperar un poco antes de poder interceptar el desafío y la respuesta de NetNTLM.
Aunque Responder podría interceptar y envenenar más solicitudes de autenticación cuando se ejecute desde nuestro dispositivo no autorizado conectado a la LAN de una organización, es fundamental comprender que este comportamiento puede ser perjudicial y, por tanto, detectarse. Al envenenar las solicitudes de autenticación, los intentos normales de autenticación de red fallarían, lo que significa que los usuarios y servicios no se conectarían a los hosts y recursos compartidos que desean. Tenga esto en cuenta cuando utilice Responder en una evaluación de seguridad.
sudo responder -I tun0
Si está utilizando AttackBox, no todos los servicios de Responder podrán iniciarse ya que otros servicios ya están usando esos puertos. Sin embargo, esto no afectará esta tarea. Además, asegúrese de especificar tun0o tun1dependiendo de qué túnel tiene la IP de su red. Responder ahora escuchará cualquier solicitud LLMNR , NBT-NS o WPAD que llegue. Dejaríamos que Responder se ejecute durante un tiempo en una LAN real. Sin embargo, en nuestro caso, tenemos que simular este envenenamiento haciendo que uno de los servidores intente autenticarse en las máquinas de la VPN. Deje Responder ejecutándose por un momento (un promedio de 10 minutos, ¡tome un poco de aire fresco!) y debería recibir una conexión SMBv2 que Responder puede usar para atraer y extraer una respuesta NTLMv2-SSP. Se verá algo como esto:
Si estuviéramos usando nuestro dispositivo fraudulento, probablemente ejecutaríamos Responder durante bastante tiempo, capturando varias respuestas. Una vez que tengamos un par, podemos comenzar a descifrar las respuestas sin conexión con la esperanza de recuperar sus contraseñas NTLM asociadas . Si las cuentas tienen configuradas contraseñas débiles, tenemos muchas posibilidades de descifrarlas con éxito. Copie el hash NTLMv2-SSP a un archivo de texto. Luego usaremos la lista de contraseñas proporcionada en los archivos descargables para esta tarea y Hashcat en un intento de descifrar el hash usando el siguiente comando:
hashcat -m 5600 <hash file> <password file> --force
¡Cualquier hash que podamos descifrar ahora nos proporcionará credenciales de AD para nuestra infracción!
En algunos casos, sin embargo, podemos ir un paso más allá al intentar transmitir el desafío en lugar de simplemente capturarlo directamente. Esto es un poco más difícil de hacer sin un conocimiento previo de las cuentas, ya que este ataque depende de los permisos de la cuenta asociada. Necesitamos un par de cosas que jueguen a nuestro favor:
La firma SMB debe estar deshabilitada o habilitada, pero no aplicada. Cuando realizamos una retransmisión, realizamos cambios menores en la solicitud para transmitirla. Si la firma SMB está habilitada, no podremos falsificar la firma del mensaje, lo que significa que el servidor la rechazará.
La cuenta asociada necesita los permisos pertinentes en el servidor para acceder a los recursos solicitados. Idealmente, buscamos transmitir el desafío y la respuesta de una cuenta con privilegios administrativos sobre el servidor, ya que esto nos permitiría afianzarnos en el host.
Dado que técnicamente todavía no tenemos un punto de apoyo en AD , hay que hacer algunas conjeturas sobre qué cuentas tendrán permisos en qué hosts. Si ya hubiéramos violado AD, podríamos realizar primero una enumeración inicial, como suele ser el caso.
Esta es la razón por la que los relevos a ciegas no suelen ser populares. Lo ideal sería primero violar AD usando otro método y luego realizar una enumeración para determinar los privilegios asociados con la cuenta que ha comprometido. Desde aquí, normalmente puede realizar movimientos laterales para escalar privilegios en todo el dominio. Sin embargo, todavía es bueno entender fundamentalmente cómo funciona un ataque de relevo, como se muestra en el siguiente diagrama:
Las grandes organizaciones necesitan herramientas para implementar y gestionar la infraestructura del patrimonio. En organizaciones grandes, no puede permitir que su personal de TI utilice DVD o incluso unidades flash USB instalando software en cada máquina. Afortunadamente, Microsoft ya proporciona las herramientas necesarias para gestionar el patrimonio. Sin embargo, podemos aprovechar las configuraciones incorrectas en estas herramientas para violar AD también .
Microsoft Deployment Toolkit (MDT) es un servicio de Microsoft que ayuda a automatizar la implementación de sistemas operativos (SO) de Microsoft. Las grandes organizaciones utilizan servicios como MDT para ayudar a implementar nuevas imágenes en su patrimonio de manera más eficiente, ya que las imágenes base se pueden mantener y actualizar en una ubicación central.
Por lo general, MDT se integra con System Center Configuration Manager (SCCM) de Microsoft, que administra todas las actualizaciones para todas las aplicaciones, servicios y sistemas operativos de Microsoft. MDT se utiliza para nuevas implementaciones. Básicamente, permite al equipo de TI preconfigurar y administrar imágenes de arranque. Por lo tanto, si necesitan configurar una nueva máquina, sólo necesitan conectar un cable de red y todo sucede automáticamente. Pueden realizar varios cambios en la imagen de inicio, como instalar software predeterminado como Office365 y el antivirus elegido por la organización. También puede garantizar que la nueva compilación se actualice la primera vez que se ejecuta la instalación.
SCCM puede verse casi como una expansión y el hermano mayor de MDT. ¿Qué sucede con el software una vez instalado? Bueno, SCCM realiza este tipo de gestión de parches. Permite al equipo de TI revisar las actualizaciones disponibles para todo el software instalado en todo el patrimonio. El equipo también puede probar estos parches en un entorno sandbox para garantizar que sean estables antes de implementarlos de forma centralizada en todas las máquinas unidas al dominio. Facilita significativamente la vida del equipo de TI.
Sin embargo, cualquier cosa que proporcione administración central de infraestructura, como MDT y SCCM, también puede ser atacada por atacantes en un intento de apoderarse de grandes porciones de funciones críticas en el patrimonio. Aunque MDT se puede configurar de varias maneras, para esta tarea nos centraremos exclusivamente en una configuración llamada arranque Preboot Execution Environment (PXE).
Las organizaciones grandes utilizan el arranque PXE para permitir que los nuevos dispositivos que están conectados a la red carguen e instalen el sistema operativo directamente a través de una conexión de red. MDT se puede utilizar para crear, administrar y alojar imágenes de arranque PXE. El arranque PXE generalmente está integrado con DHCP, lo que significa que si DHCP asigna una concesión de IP, el host puede solicitar la imagen de arranque PXE e iniciar el proceso de instalación del sistema operativo de red. El flujo de comunicación se muestra en el siguiente diagrama :
Una vez realizado el proceso, el cliente utilizará una conexión TFTP para descargar la imagen de arranque PXE. Podemos explotar la imagen de arranque PXE para dos propósitos diferentes:
Inyecte un vector de escalada de privilegios, como una cuenta de administrador local, para obtener acceso administrativo al sistema operativo una vez que se haya completado el inicio PXE.
Realice ataques de extracción de contraseñas para recuperar las credenciales de AD utilizadas durante la instalación.
En esta tarea nos centraremos en este último. Intentaremos recuperar la cuenta del servicio de implementación asociada con el servicio MDT durante la instalación para este ataque de extracción de contraseñas. Además, también existe la posibilidad de recuperar otras cuentas AD utilizadas para la instalación desatendida de aplicaciones y servicios.
Dado que DHCP es un poco complicado, omitiremos los pasos iniciales de este ataque. Omitiremos la parte en la que intentamos solicitar una IP y los detalles de preconfiguración de arranque PXE desde DHCP. Realizaremos el resto del ataque desde este paso del proceso manualmente.
La primera información sobre la preconfiguración de arranque PXE que habría recibido a través de DHCP es la IP del servidor MDT. En nuestro caso, puedes recuperar esa información desde el diagrama de red de TryHackMe.
Normalmente, utilizaría TFTP para solicitar cada uno de estos archivos BCD y enumerar la configuración de todos ellos. Sin embargo, por razones de tiempo, nos centraremos en el archivo BCD de la arquitectura x64 . Copie y almacene el nombre completo de este archivo. Durante el resto de este ejercicio, usaremos este marcador de posición de nombre x64{7B...B3}.bcdya que MDT regenera los archivos y sus nombres todos los días. Cada vez que vea este marcador de posición, recuerde reemplazarlo con su nombre de archivo BCD específico. Tenga en cuenta también que si la red acaba de iniciarse, estos nombres de archivos solo se actualizarán después de 10 minutos de que la red esté activa.
Con esta información inicial ahora recuperada de DHCP (wink wink), podemos enumerar y recuperar la imagen de arranque PXE. Usaremos nuestra conexión SSH en THMJMP1 para los próximos pasos, así que autentíquese en esta sesión SSH usando lo siguiente:
ssh thm@THMJMP1.za.tryhackme.com
y la contraseña de Password1@.
Para garantizar que todos los usuarios de la red puedan usar SSH , comience creando una carpeta con su nombre de usuario y copiando el repositorio de powerpxe en esta carpeta:
El primer paso que debemos realizar es usar T FTP y descargar nuestro archivo BCD para leer la configuración del servidor MDT. TFTP es un poco más complicado que FTP ya que no podemos enumerar archivos. En su lugar, enviamos una solicitud de archivo y el servidor se conectará con nosotros a través de UDP para transferir el archivo. Por lo tanto, debemos ser precisos al especificar archivos y rutas de archivo. Los archivos BCD siempre se encuentran en el directorio /Tmp/ del servidor MDT. Podemos iniciar la transferencia TFTP usando el siguiente comando en nuestra sesión SSH:
Los archivos WIM son imágenes de arranque en el formato de imagen de Windows (WIM). Ahora que tenemos la ubicación de la imagen de arranque PXE, podemos usar TFTP nuevamente para descargar esta imagen:
Esta descarga llevará un tiempo ya que está descargando una imagen de Windows configurada y de arranque completo. Tal vez estire las piernas y tome un vaso de agua mientras espera.
Nuevamente usaremos powerpxe para recuperar las credenciales, pero también puedes realizar este paso manualmente extrayendo la imagen y buscando el archivo bootstrap.ini, donde suelen almacenarse este tipo de credenciales. Para usar powerpxe para recuperar las credenciales del archivo de arranque, ejecute el siguiente comando:
Símbolo del sistema SSH
Como puede ver, powerpxe pudo recuperar las credenciales de AD . ¡Ahora tenemos otro conjunto de credenciales de AD que podemos usar!
La última vía de enumeración que exploraremos en esta red son los archivos de configuración. Supongamos que tuvo la suerte de provocar una infracción que le dio acceso a un host en la red de la organización. En ese caso, los archivos de configuración son una excelente vía para explorar en un intento de recuperar las credenciales de AD . Dependiendo del host que fue vulnerado, varios archivos de configuración pueden ser valiosos para la enumeración:
Archivos de configuración de aplicaciones web
Archivos de configuración del servicio
Claves de registro
Aplicaciones implementadas centralmente
Sin embargo, en esta tarea nos centraremos en recuperar credenciales de una aplicación implementada centralmente. Por lo general, estas aplicaciones necesitan un método para autenticarse en el dominio durante las fases de instalación y ejecución. Un ejemplo de esta aplicación es McAfee Enterprise Endpoint Security, que las organizaciones pueden utilizar como herramienta de detección y respuesta de endpoints para seguridad.
McAfee incorpora las credenciales utilizadas durante la instalación para volver a conectarse al orquestador en un archivo llamado ma.db. Este archivo de base de datos se puede recuperar y leer con acceso local al host para recuperar la cuenta de servicio AD asociada. Usaremos nuevamente el acceso SSH en THMJMP1 para este ejercicio.
El archivo ma.db se almacena en una ubicación fija:
Podemos usar SCP para copiar el ma.db a nuestro AttackBox:
Para leer el archivo de la base de datos, usaremos una herramienta llamada sqlitebrowser. Podemos abrir la base de datos usando el siguiente comando:
Usando sqlitebrowser, seleccionaremos la opción Examinar datos y nos centraremos en la tabla AGENT_REPOSITORIES:
Estamos particularmente interesados en la segunda entrada que se centra en las entradas de los campos DOMINIO, AUTH_USER y AUTH_PASSWD. Tome nota de los valores almacenados en estas entradas. Sin embargo, el campo AUTH_PASSWD está cifrado. Por suerte, McAfee cifra este campo con una clave conocida. Por lo tanto, utilizaremos el siguiente script antiguo de python2 para descifrar la contraseña. El script se proporciona como un archivo de tarea descargable o en AttackBox, se puede encontrar en el /root/Rooms/BreachingAD/task7/directorio.
Tendrás que descomprimir el archivo mcafee-sitelist-pwd-decryption.zip:
Al proporcionar al script nuestra contraseña cifrada y codificada en base64, el script proporcionará la contraseña descifrada:
¡Ahora tenemos nuevamente un conjunto de credenciales de AD que podemos usar para una mayor enumeración! Este es sólo un ejemplo de cómo recuperar credenciales de archivos de configuración. Si alguna vez logra establecerse en un host, asegúrese de seguir una metodología detallada y refinada para asegurarse de recuperar todo el botín del host, incluidas las credenciales y otra información confidencial que se puede almacenar en archivos de configuración.
Usuarios que hacen preguntas en foros públicos como pero revelan información confidencial, como sus credenciales, en la pregunta.
Desarrolladores que cargan scripts en servicios como con credenciales codificadas.
Las credenciales se divulgaron en infracciones anteriores, ya que los empleados usaron sus cuentas de trabajo para registrarse en otros sitios web externos. Los sitios web como y brindan excelentes plataformas para determinar si la información de alguien, como el correo electrónico del trabajo, alguna vez estuvo involucrada en una violación de datos de conocimiento público.
Puede encontrar una sala detallada sobre Red Team OSINT
Puede encontrar una sala detallada sobre phishing
Esto significa que la aplicación se autentica en nombre del usuario y no autentica al usuario directamente en la aplicación misma. Esto evita que la aplicación almacene credenciales de AD , que solo deben almacenarse en un controlador de dominio. Este proceso se muestra en el siguiente diagrama:
Se le ha proporcionado una lista de nombres de usuario descubiertos durante un ejercicio OSINT del equipo rojo . El ejercicio OSINT también indicó la contraseña de incorporación inicial de la organización, que parece ser "Changeme123". Aunque los usuarios siempre deben cambiar su contraseña inicial, sabemos que los usuarios a menudo la olvidan. Usaremos un script desarrollado a medida para realizar una pulverización de contraseña en la aplicación web alojada en esta URL: .
Podríamos utilizar herramientas como para ayudar con el ataque de pulverización de contraseñas. Sin embargo, suele ser mejor programar este tipo de ataques usted mismo, lo que le permite tener más control sobre el proceso. Se ha proporcionado una secuencia de comandos Python base en los archivos de tareas que se pueden utilizar para el ataque de pulverización de contraseñas. La siguiente función es el componente principal del script:
Hay una impresora de red en esta red donde el sitio web de administración ni siquiera requiere credenciales. Navegue a para encontrar la página de configuración de la impresora:
Nuestro servidor LDAP fraudulento ya ha sido configurado. Cuando hacemos clic en "Configuración de prueba" en , la autenticación se realizará en texto sin cifrar. Si configuró correctamente su servidor LDAP no autorizado y está degradando la comunicación, recibirá el siguiente error: "Este nombre distintivo contiene una sintaxis no válida". Si recibe este error, puede usar un tcpdump para capturar las credenciales usando el siguiente comando:
Responder ya se ha instalado en AttackBox. Sin embargo, si no está utilizando AttackBox, puede descargarlo e instalarlo desde este repositorio: . Configuraremos Responder para que se ejecute en la interfaz conectada a la VPN :
El archivo de contraseña se le ha proporcionado en el /root/Rooms/BreachingAD/task5/directorio de AttackBox o como un archivo de tarea descargable. Usamos hashtype 5600, que corresponde con NTLMv2-SSP para hashcat. Si utiliza su propia máquina, primero deberá instalar .
La segunda información que habría recibido fueron los nombres de los archivos BCD. Estos archivos almacenan la información relevante para PXE Boots para los diferentes tipos de arquitectura. Para recuperar esta información, deberá conectarse a este sitio web: . Enumerará varios archivos BCD:
Tendrás que buscar THMMDT IP con nslookup thmmdt.za.tryhackme.com. Con el archivo BCD ahora recuperado, usaremos para leer su contenido. Powerpxe es un script de PowerShell que realiza automáticamente este tipo de ataque, pero generalmente con resultados variables, por lo que es mejor realizar un enfoque manual. Usaremos la función Get-WimFile de powerpxe para recuperar las ubicaciones de las imágenes de arranque PXE del archivo BCD:
Ahora que hemos recuperado la imagen de arranque PXE, podemos extraer las credenciales almacenadas. Cabe señalar que existen diversos ataques que podríamos realizar. Podríamos inyectar un usuario administrador local, de modo que tengamos acceso de administrador tan pronto como se inicie la imagen, podríamos instalar la imagen para tener una máquina unida a un dominio. Si estás interesado en saber más sobre estos ataques, puedes leer este . Este ejercicio se centrará en un ataque simple que consiste simplemente en intentar extraer credenciales.
Se pueden utilizar varios scripts de enumeración, como
Nota: La herramienta que usaremos aquí es bastante antigua. Utiliza Python v2 y se basa en una antigua biblioteca criptográfica. Si no puede hacer que el script funcione en su propia máquina virtual , utilice AttackBox. Sin embargo, ha habido una actualización reciente de la aplicación para garantizar que también funcione en Python3. Puede descargar la última versión aquí:
