Active Directory Methodology
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Active Directory sirve como una tecnología fundamental, permitiendo a los administradores de red crear y gestionar de manera eficiente dominios, usuarios y objetos dentro de una red. Está diseñado para escalar, facilitando la organización de un gran número de usuarios en grupos y subgrupos manejables, mientras controla los derechos de acceso en varios niveles.
La estructura de Active Directory se compone de tres capas principales: dominios, árboles y bosques. Un dominio abarca una colección de objetos, como usuarios o dispositivos, que comparten una base de datos común. Los árboles son grupos de estos dominios vinculados por una estructura compartida, y un bosque representa la colección de múltiples árboles, interconectados a través de relaciones de confianza, formando la capa más alta de la estructura organizativa. Se pueden designar derechos de acceso y comunicación específicos en cada uno de estos niveles.
Los conceptos clave dentro de Active Directory incluyen:
Directorio – Alberga toda la información relacionada con los objetos de Active Directory.
Objeto – Denota entidades dentro del directorio, incluyendo usuarios, grupos o carpetas compartidas.
Dominio – Sirve como un contenedor para objetos de directorio, con la capacidad de que múltiples dominios coexistan dentro de un bosque, cada uno manteniendo su propia colección de objetos.
Árbol – Un agrupamiento de dominios que comparten un dominio raíz común.
Bosque – La cúspide de la estructura organizativa en Active Directory, compuesta por varios árboles con relaciones de confianza entre ellos.
Active Directory Domain Services (AD DS) abarca una gama de servicios críticos para la gestión y comunicación centralizada dentro de una red. Estos servicios comprenden:
Servicios de Dominio – Centraliza el almacenamiento de datos y gestiona las interacciones entre usuarios y dominios, incluyendo funcionalidades de autenticación y búsqueda.
Servicios de Certificado – Supervisa la creación, distribución y gestión de certificados digitales seguros.
Servicios de Directorio Ligero – Soporta aplicaciones habilitadas para directorios a través del protocolo LDAP.
Servicios de Federación de Directorio – Proporciona capacidades de inicio de sesión único para autenticar usuarios a través de múltiples aplicaciones web en una sola sesión.
Gestión de Derechos – Ayuda a proteger material con derechos de autor regulando su distribución y uso no autorizados.
Servicio DNS – Crucial para la resolución de nombres de dominio.
Para una explicación más detallada, consulta: TechTerms - Definición de Active Directory
Para aprender a atacar un AD, necesitas entender muy bien el proceso de autenticación Kerberos. Lee esta página si aún no sabes cómo funciona.
Puedes visitar https://wadcoms.github.io/ para tener una vista rápida de qué comandos puedes ejecutar para enumerar/explotar un AD.
Si solo tienes acceso a un entorno AD pero no tienes credenciales/sesiones, podrías:
Pentestear la red:
Escanear la red, encontrar máquinas y puertos abiertos e intentar explotar vulnerabilidades o extraer credenciales de ellas (por ejemplo, las impresoras podrían ser objetivos muy interesantes.
Enumerar DNS podría proporcionar información sobre servidores clave en el dominio como web, impresoras, comparticiones, vpn, medios, etc.
gobuster dns -d domain.local -t 25 -w /opt/Seclist/Discovery/DNS/subdomain-top2000.txt
Consulta la Metodología General de Pentesting para encontrar más información sobre cómo hacer esto.
Verifica el acceso nulo y de invitado en servicios smb (esto no funcionará en versiones modernas de Windows):
enum4linux -a -u "" -p "" <DC IP> && enum4linux -a -u "guest" -p "" <DC IP>
smbmap -u "" -p "" -P 445 -H <DC IP> && smbmap -u "guest" -p "" -P 445 -H <DC IP>
smbclient -U '%' -L //<DC IP> && smbclient -U 'guest%' -L //
Una guía más detallada sobre cómo enumerar un servidor SMB se puede encontrar aquí:
Enumerar Ldap
nmap -n -sV --script "ldap* and not brute" -p 389 <DC IP>
Una guía más detallada sobre cómo enumerar LDAP se puede encontrar aquí (presta especial atención al acceso anónimo):
Envenenar la red
Reúne credenciales suplantando servicios con Responder
Accede al host abusando del ataque de retransmisión
Reúne credenciales exponiendo servicios UPnP falsos con evil-SSDP
Extrae nombres de usuario/nombres de documentos internos, redes sociales, servicios (principalmente web) dentro de los entornos de dominio y también de los disponibles públicamente.
Si encuentras los nombres completos de los trabajadores de la empresa, podrías intentar diferentes convenciones de nombres de usuario de AD (lee esto). Las convenciones más comunes son: NombreApellido, Nombre.Apellido, NamSur (3 letras de cada uno), Nam.Sur, NSurname, N.Surname, ApellidoNombre, Apellido.Nombre, ApellidoN, Apellido.N, 3 letras aleatorias y 3 números aleatorios (abc123).
Herramientas:
Enumeración SMB/LDAP anónima: Consulta las páginas de pentesting SMB y pentesting LDAP.
Enumeración Kerbrute: Cuando se solicita un nombre de usuario inválido, el servidor responderá utilizando el código de error Kerberos KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN, lo que nos permite determinar que el nombre de usuario era inválido. Nombres de usuario válidos provocarán ya sea el TGT en una respuesta AS-REP o el error KRB5KDC_ERR_PREAUTH_REQUIRED, indicando que se requiere que el usuario realice una pre-autenticación.
Servidor OWA (Outlook Web Access)
Si encuentras uno de estos servidores en la red, también puedes realizar enumeración de usuarios contra él. Por ejemplo, podrías usar la herramienta MailSniper:
Puedes encontrar listas de nombres de usuario en este repositorio de github **** y este otro (nombres de usuario estadísticamente probables).
Sin embargo, deberías tener el nombre de las personas que trabajan en la empresa del paso de reconocimiento que deberías haber realizado antes de esto. Con el nombre y apellido podrías usar el script namemash.py para generar nombres de usuario potencialmente válidos.
Bien, así que sabes que ya tienes un nombre de usuario válido pero no contraseñas... Entonces intenta:
ASREPRoast: Si un usuario no tiene el atributo DONT_REQ_PREAUTH puedes solicitar un mensaje AS_REP para ese usuario que contendrá algunos datos encriptados por una derivación de la contraseña del usuario.
Password Spraying: Intentemos las contraseñas más comunes con cada uno de los usuarios descubiertos, tal vez algún usuario esté usando una mala contraseña (¡ten en cuenta la política de contraseñas!).
Ten en cuenta que también puedes spray servidores OWA para intentar acceder a los servidores de correo de los usuarios.
Podrías ser capaz de obtener algunos hashes de desafío para romper envenenando algunos protocolos de la red:
Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay AttacksSi has logrado enumerar el directorio activo tendrás más correos electrónicos y una mejor comprensión de la red. Podrías ser capaz de forzar ataques de relay NTML **** para obtener acceso al entorno de AD.
Si puedes acceder a otras PC o recursos compartidos con el usuario nulo o invitado podrías colocar archivos (como un archivo SCF) que si se acceden de alguna manera activarán una autenticación NTML contra ti para que puedas robar el desafío NTLM y romperlo:
Places to steal NTLM credsPara esta fase necesitas haber comprometido las credenciales o una sesión de una cuenta de dominio válida. Si tienes algunas credenciales válidas o una shell como usuario de dominio, deberías recordar que las opciones dadas antes siguen siendo opciones para comprometer a otros usuarios.
Antes de comenzar la enumeración autenticada deberías saber cuál es el problema del doble salto de Kerberos.
Kerberos Double Hop ProblemHaber comprometido una cuenta es un gran paso para comenzar a comprometer todo el dominio, porque podrás comenzar la Enumeración de Active Directory:
Respecto a ASREPRoast ahora puedes encontrar cada posible usuario vulnerable, y respecto a Password Spraying puedes obtener una lista de todos los nombres de usuario y probar la contraseña de la cuenta comprometida, contraseñas vacías y nuevas contraseñas prometedoras.
Podrías usar el CMD para realizar un reconocimiento básico
También puedes usar powershell para reconocimiento que será más sigiloso
También puedes usar powerview para extraer información más detallada
Otra herramienta increíble para reconocimiento en un directorio activo es BloodHound. No es muy sigilosa (dependiendo de los métodos de recolección que uses), pero si no te importa eso, deberías probarla. Encuentra dónde los usuarios pueden RDP, encuentra rutas a otros grupos, etc.
Otras herramientas automatizadas de enumeración de AD son: AD Explorer, ADRecon, Group3r, PingCastle.
Registros DNS del AD ya que podrían contener información interesante.
Una herramienta con GUI que puedes usar para enumerar el directorio es AdExplorer.exe del SysInternal Suite.
También puedes buscar en la base de datos LDAP con ldapsearch para buscar credenciales en los campos userPassword y unixUserPassword, o incluso para Description. cf. Contraseña en el comentario de usuario AD en PayloadsAllTheThings para otros métodos.
Si estás usando Linux, también podrías enumerar el dominio usando pywerview.
También podrías intentar herramientas automatizadas como:
Extrayendo todos los usuarios del dominio
Es muy fácil obtener todos los nombres de usuario del dominio desde Windows (net user /domain, Get-DomainUser o wmic useraccount get name,sid). En Linux, puedes usar: GetADUsers.py -all -dc-ip 10.10.10.110 domain.com/username o enum4linux -a -u "user" -p "password" <DC IP>
Incluso si esta sección de Enumeración parece pequeña, esta es la parte más importante de todas. Accede a los enlaces (principalmente el de cmd, powershell, powerview y BloodHound), aprende cómo enumerar un dominio y practica hasta que te sientas cómodo. Durante una evaluación, este será el momento clave para encontrar tu camino hacia DA o decidir que no se puede hacer nada.
Kerberoasting implica obtener tickets TGS utilizados por servicios vinculados a cuentas de usuario y romper su encriptación—que se basa en contraseñas de usuario—fuera de línea.
Más sobre esto en:
KerberoastUna vez que hayas obtenido algunas credenciales podrías verificar si tienes acceso a alguna máquina. Para ello, podrías usar CrackMapExec para intentar conectarte a varios servidores con diferentes protocolos, de acuerdo a tus escaneos de puertos.
Si has comprometido credenciales o una sesión como un usuario regular de dominio y tienes acceso con este usuario a cualquier máquina en el dominio deberías intentar encontrar la manera de escalar privilegios localmente y buscar credenciales. Esto se debe a que solo con privilegios de administrador local podrás volcar hashes de otros usuarios en memoria (LSASS) y localmente (SAM).
Hay una página completa en este libro sobre escalación de privilegios local en Windows y una lista de verificación. Además, no olvides usar WinPEAS.
Es muy improbable que encuentres tickets en el usuario actual dándote permiso para acceder a recursos inesperados, pero podrías verificar:
Si has logrado enumerar el directorio activo, tendrás más correos electrónicos y una mejor comprensión de la red. Podrías ser capaz de forzar ataques de NTML relay attacks.
Ahora que tienes algunas credenciales básicas, deberías verificar si puedes encontrar archivos interesantes que se compartan dentro del AD. Podrías hacerlo manualmente, pero es una tarea muy aburrida y repetitiva (y más si encuentras cientos de documentos que necesitas revisar).
Sigue este enlace para aprender sobre herramientas que podrías usar.
Si puedes acceder a otras PC o recursos compartidos, podrías colocar archivos (como un archivo SCF) que, si se accede de alguna manera, activarán una autenticación NTML contra ti, para que puedas robar el reto NTLM y crackearlo:
Places to steal NTLM credsEsta vulnerabilidad permitió a cualquier usuario autenticado comprometer el controlador de dominio.
PrintNightmarePara las siguientes técnicas, un usuario de dominio regular no es suficiente, necesitas algunos privilegios/credenciales especiales para realizar estos ataques.
Esperemos que hayas logrado comprometer alguna cuenta de administrador local usando AsRepRoast, Password Spraying, Kerberoast, Responder incluyendo relaying, EvilSSDP, escalando privilegios localmente. Luego, es hora de volcar todos los hashes en memoria y localmente. Lee esta página sobre diferentes formas de obtener los hashes.
Una vez que tengas el hash de un usuario, puedes usarlo para suplantarlo. Necesitas usar alguna herramienta que realice la autenticación NTLM usando ese hash, o podrías crear un nuevo sessionlogon e inyectar ese hash dentro de LSASS, para que cuando se realice cualquier autenticación NTLM, ese hash será utilizado. La última opción es lo que hace mimikatz. Lee esta página para más información.
Este ataque tiene como objetivo usar el hash NTLM del usuario para solicitar tickets Kerberos, como una alternativa al común Pass The Hash sobre el protocolo NTLM. Por lo tanto, esto podría ser especialmente útil en redes donde el protocolo NTLM está deshabilitado y solo Kerberos está permitido como protocolo de autenticación.
Over Pass the Hash/Pass the KeyEn el método de ataque Pass The Ticket (PTT), los atacantes roban el ticket de autenticación de un usuario en lugar de su contraseña o valores hash. Este ticket robado se utiliza para suplantar al usuario, obteniendo acceso no autorizado a recursos y servicios dentro de una red.
Pass the TicketSi tienes el hash o contraseña de un administrador local, deberías intentar iniciar sesión localmente en otras PCs con ello.
Nota que esto es bastante ruidoso y LAPS lo mitigaría.
Si un usuario tiene privilegios para acceder a instancias de MSSQL, podría ser capaz de usarlo para ejecutar comandos en el host de MSSQL (si se ejecuta como SA), robar el hash de NetNTLM o incluso realizar un ataque de relevo. Además, si una instancia de MSSQL es confiable (enlace de base de datos) por otra instancia de MSSQL. Si el usuario tiene privilegios sobre la base de datos confiable, podrá usar la relación de confianza para ejecutar consultas también en la otra instancia. Estas confianzas pueden encadenarse y en algún momento el usuario podría encontrar una base de datos mal configurada donde puede ejecutar comandos. Los enlaces entre bases de datos funcionan incluso a través de confianzas de bosque.
MSSQL AD AbuseSi encuentras algún objeto de Computadora con el atributo ADS_UF_TRUSTED_FOR_DELEGATION y tienes privilegios de dominio en la computadora, podrás volcar TGTs de la memoria de todos los usuarios que inicien sesión en la computadora. Entonces, si un Administrador de Dominio inicia sesión en la computadora, podrás volcar su TGT e impersonarlo usando Pass the Ticket. Gracias a la delegación restringida, incluso podrías comprometer automáticamente un Servidor de Impresión (esperemos que sea un DC).
Unconstrained DelegationSi un usuario o computadora está permitido para "Delegación Restringida", podrá impersonar a cualquier usuario para acceder a algunos servicios en una computadora. Luego, si comprometes el hash de este usuario/computadora, podrás impersonar a cualquier usuario (incluso administradores de dominio) para acceder a algunos servicios.
Constrained DelegationTener privilegio de ESCRITURA en un objeto de Active Directory de una computadora remota permite la obtención de ejecución de código con privilegios elevados:
Resource-based Constrained DelegationEl usuario comprometido podría tener algunos privilegios interesantes sobre algunos objetos de dominio que podrían permitirte moverte lateralmente/escalar privilegios.
Abusing Active Directory ACLs/ACEsDescubrir un servicio de Cola escuchando dentro del dominio puede ser abusado para adquirir nuevas credenciales y escalar privilegios.
Force NTLM Privileged AuthenticationSi otros usuarios acceden a la máquina comprometida, es posible recolectar credenciales de la memoria e incluso inyectar beacons en sus procesos para impersonarlos. Usualmente los usuarios accederán al sistema a través de RDP, así que aquí tienes cómo realizar un par de ataques sobre sesiones RDP de terceros:
RDP Sessions AbuseLAPS proporciona un sistema para gestionar la contraseña del Administrador local en computadoras unidas al dominio, asegurando que sea aleatoria, única y frecuentemente cambiada. Estas contraseñas se almacenan en Active Directory y el acceso se controla a través de ACLs solo para usuarios autorizados. Con permisos suficientes para acceder a estas contraseñas, se vuelve posible pivotar a otras computadoras.
LAPSRecolectar certificados de la máquina comprometida podría ser una forma de escalar privilegios dentro del entorno:
AD CS Certificate TheftSi hay plantillas vulnerables configuradas, es posible abusar de ellas para escalar privilegios:
AD CS Domain EscalationUna vez que obtienes privilegios de Administrador de Dominio o incluso mejor Administrador de Empresa, puedes volcar la base de datos del dominio: ntds.dit.
Más información sobre el ataque DCSync se puede encontrar aquí.
Más información sobre cómo robar el NTDS.dit se puede encontrar aquí
Algunas de las técnicas discutidas anteriormente pueden ser utilizadas para persistencia. Por ejemplo, podrías:
Hacer que los usuarios sean vulnerables a Kerberoast
Hacer que los usuarios sean vulnerables a ASREPRoast
Otorgar privilegios de DCSync a un usuario
El ataque Silver Ticket crea un ticket legítimo de Servicio de Concesión de Tickets (TGS) para un servicio específico utilizando el hash de NTLM (por ejemplo, el hash de la cuenta de PC). Este método se emplea para acceder a los privilegios del servicio.
Silver TicketUn ataque Golden Ticket implica que un atacante obtenga acceso al hash de NTLM de la cuenta krbtgt en un entorno de Active Directory (AD). Esta cuenta es especial porque se utiliza para firmar todos los Tickets de Concesión de Tickets (TGTs), que son esenciales para la autenticación dentro de la red AD.
Una vez que el atacante obtiene este hash, puede crear TGTs para cualquier cuenta que elija (ataque Silver Ticket).
Golden TicketEstos son como los tickets dorados forjados de una manera que elude los mecanismos comunes de detección de tickets dorados.
Diamond TicketTener certificados de una cuenta o poder solicitarlos es una muy buena manera de poder persistir en la cuenta de los usuarios (incluso si cambia la contraseña):
AD CS Account PersistenceUsar certificados también es posible para persistir con altos privilegios dentro del dominio:
AD CS Domain PersistenceEl objeto AdminSDHolder en Active Directory asegura la seguridad de los grupos privilegiados (como Administradores de Dominio y Administradores de Empresa) aplicando una Lista de Control de Acceso (ACL) estándar a través de estos grupos para prevenir cambios no autorizados. Sin embargo, esta característica puede ser explotada; si un atacante modifica la ACL de AdminSDHolder para otorgar acceso total a un usuario regular, ese usuario obtiene un control extenso sobre todos los grupos privilegiados. Esta medida de seguridad, destinada a proteger, puede por lo tanto volverse en contra, permitiendo un acceso no autorizado a menos que se supervise de cerca.
Más información sobre el Grupo AdminDSHolder aquí.
Dentro de cada Controlador de Dominio (DC), existe una cuenta de administrador local. Al obtener derechos de administrador en tal máquina, el hash del Administrador local puede ser extraído usando mimikatz. Después de esto, es necesaria una modificación del registro para habilitar el uso de esta contraseña, permitiendo el acceso remoto a la cuenta del Administrador local.
DSRM CredentialsPodrías dar algunos permisos especiales a un usuario sobre algunos objetos de dominio específicos que permitirán al usuario escalar privilegios en el futuro.
Abusing Active Directory ACLs/ACEsLos descriptores de seguridad se utilizan para almacenar los permisos que un objeto tiene sobre un objeto. Si puedes hacer un pequeño cambio en el descriptor de seguridad de un objeto, puedes obtener privilegios muy interesantes sobre ese objeto sin necesidad de ser miembro de un grupo privilegiado.
Security DescriptorsAlterar LSASS en memoria para establecer una contraseña universal, otorgando acceso a todas las cuentas de dominio.
Skeleton KeyAprende qué es un SSP (Proveedor de Soporte de Seguridad) aquí. Puedes crear tu propio SSP para capturar en texto claro las credenciales utilizadas para acceder a la máquina.\
Custom SSPRegistra un nuevo Controlador de Dominio en el AD y lo utiliza para empujar atributos (SIDHistory, SPNs...) en objetos especificados sin dejar ningún registro sobre las modificaciones. Necesitas privilegios de DA y estar dentro del dominio raíz. Nota que si usas datos incorrectos, aparecerán registros bastante feos.
DCShadowAnteriormente hemos discutido cómo escalar privilegios si tienes suficientes permisos para leer las contraseñas de LAPS. Sin embargo, estas contraseñas también pueden ser utilizadas para mantener persistencia. Revisa:
LAPSMicrosoft ve el Bosque como el límite de seguridad. Esto implica que comprometer un solo dominio podría llevar potencialmente a que todo el Bosque sea comprometido.
Una confianza de dominio es un mecanismo de seguridad que permite a un usuario de un dominio acceder a recursos en otro dominio. Esencialmente, crea un vínculo entre los sistemas de autenticación de los dos dominios, permitiendo que las verificaciones de autenticación fluyan sin problemas. Cuando los dominios establecen una confianza, intercambian y retienen claves específicas dentro de sus Controladores de Dominio (DCs), que son cruciales para la integridad de la confianza.
En un escenario típico, si un usuario pretende acceder a un servicio en un dominio confiable, primero debe solicitar un ticket especial conocido como un TGT inter-realm de su propio DC de dominio. Este TGT está cifrado con una clave compartida que ambos dominios han acordado. Luego, el usuario presenta este TGT al DC del dominio confiable para obtener un ticket de servicio (TGS). Tras la validación exitosa del TGT inter-realm por parte del DC del dominio confiable, emite un TGS, otorgando al usuario acceso al servicio.
Pasos:
Una computadora cliente en Dominio 1 inicia el proceso utilizando su hash de NTLM para solicitar un Ticket Granting Ticket (TGT) de su Controlador de Dominio (DC1).
DC1 emite un nuevo TGT si el cliente se autentica con éxito.
El cliente luego solicita un TGT inter-realm de DC1, que es necesario para acceder a recursos en Dominio 2.
El TGT inter-realm está cifrado con una clave de confianza compartida entre DC1 y DC2 como parte de la confianza de dominio bidireccional.
El cliente lleva el TGT inter-realm al Controlador de Dominio (DC2) del Dominio 2.
DC2 verifica el TGT inter-realm utilizando su clave de confianza compartida y, si es válido, emite un Ticket Granting Service (TGS) para el servidor en el Dominio 2 al que el cliente desea acceder.
Finalmente, el cliente presenta este TGS al servidor, que está cifrado con el hash de la cuenta del servidor, para obtener acceso al servicio en el Dominio 2.
Es importante notar que una confianza puede ser unidireccional o bidireccional. En la opción bidireccional, ambos dominios se confiarán mutuamente, pero en la relación de confianza unidireccional, uno de los dominios será el confiable y el otro el que confía. En este último caso, solo podrás acceder a recursos dentro del dominio que confía desde el dominio confiable.
Si el Dominio A confía en el Dominio B, A es el dominio que confía y B es el confiable. Además, en Dominio A, esto sería una confianza saliente; y en Dominio B, esto sería una confianza entrante.
Diferentes relaciones de confianza
Confianzas Padre-Hijo: Esta es una configuración común dentro del mismo bosque, donde un dominio hijo tiene automáticamente una confianza bidireccional transitiva con su dominio padre. Esencialmente, esto significa que las solicitudes de autenticación pueden fluir sin problemas entre el padre y el hijo.
Confianzas de Enlace Cruzado: Conocidas como "confianzas de acceso directo", se establecen entre dominios hijos para acelerar los procesos de referencia. En bosques complejos, las referencias de autenticación generalmente tienen que viajar hasta la raíz del bosque y luego hacia abajo hasta el dominio objetivo. Al crear enlaces cruzados, el viaje se acorta, lo que es especialmente beneficioso en entornos geográficamente dispersos.
Confianzas Externas: Estas se establecen entre diferentes dominios no relacionados y son no transitivas por naturaleza. Según la documentación de Microsoft, las confianzas externas son útiles para acceder a recursos en un dominio fuera del bosque actual que no está conectado por una confianza de bosque. La seguridad se refuerza a través del filtrado de SID con confianzas externas.
Confianzas de Raíz de Árbol: Estas confianzas se establecen automáticamente entre el dominio raíz del bosque y una nueva raíz de árbol añadida. Aunque no se encuentran comúnmente, las confianzas de raíz de árbol son importantes para agregar nuevos árboles de dominio a un bosque, permitiéndoles mantener un nombre de dominio único y asegurando la transitividad bidireccional. Más información se puede encontrar en la guía de Microsoft.
Confianzas de Bosque: Este tipo de confianza es una confianza bidireccional transitiva entre dos dominios raíz de bosque, también aplicando filtrado de SID para mejorar las medidas de seguridad.
Confianzas MIT: Estas confianzas se establecen con dominios Kerberos que cumplen con RFC4120 y que no son de Windows. Las confianzas MIT son un poco más especializadas y se adaptan a entornos que requieren integración con sistemas basados en Kerberos fuera del ecosistema de Windows.
Una relación de confianza también puede ser transitiva (A confía en B, B confía en C, entonces A confía en C) o no transitiva.
Una relación de confianza puede configurarse como confianza bidireccional (ambos confían entre sí) o como confianza unidireccional (solo uno de ellos confía en el otro).
Enumerar las relaciones de confianza
Verificar si algún principal de seguridad (usuario/grupo/computadora) tiene acceso a recursos del otro dominio, tal vez a través de entradas ACE o al estar en grupos del otro dominio. Busca relaciones entre dominios (la confianza fue creada probablemente para esto).
Kerberoast en este caso podría ser otra opción.
Comprometer las cuentas que pueden pivotar entre dominios.
Los atacantes podrían acceder a recursos en otro dominio a través de tres mecanismos principales:
Membresía en Grupos Locales: Los principales podrían ser añadidos a grupos locales en máquinas, como el grupo “Administradores” en un servidor, otorgándoles un control significativo sobre esa máquina.
Membresía en Grupos de Dominio Extranjero: Los principales también pueden ser miembros de grupos dentro del dominio extranjero. Sin embargo, la efectividad de este método depende de la naturaleza de la confianza y el alcance del grupo.
Listas de Control de Acceso (ACLs): Los principales podrían estar especificados en una ACL, particularmente como entidades en ACEs dentro de un DACL, proporcionándoles acceso a recursos específicos. Para aquellos que buscan profundizar en la mecánica de ACLs, DACLs y ACEs, el documento titulado “An ACE Up The Sleeve” es un recurso invaluable.
Hay 2 claves de confianza, una para Hijo --> Padre y otra para Padre --> Hijo. Puedes usar la que se utiliza en el dominio actual con:
Escalar como administrador de la empresa al dominio hijo/padre abusando de la confianza con la inyección de SID-History:
SID-History InjectionEntender cómo se puede explotar el Contexto de Nombres de Configuración (NC) es crucial. El NC de Configuración sirve como un repositorio central para datos de configuración en entornos de Active Directory (AD). Estos datos se replican a cada Controlador de Dominio (DC) dentro del bosque, con DCs escribibles manteniendo una copia escribible del NC de Configuración. Para explotar esto, uno debe tener privilegios de SYSTEM en un DC, preferiblemente un DC hijo.
Vincular GPO al sitio raíz de DC
El contenedor de Sitios del NC de Configuración incluye información sobre todos los sitios de computadoras unidas al dominio dentro del bosque de AD. Al operar con privilegios de SYSTEM en cualquier DC, los atacantes pueden vincular GPOs a los sitios raíz de DC. Esta acción compromete potencialmente el dominio raíz al manipular políticas aplicadas a estos sitios.
Para información más detallada, se puede explorar la investigación sobre Bypassing SID Filtering.
Comprometer cualquier gMSA en el bosque
Un vector de ataque implica apuntar a gMSAs privilegiados dentro del dominio. La clave raíz de KDS, esencial para calcular las contraseñas de gMSAs, se almacena dentro del NC de Configuración. Con privilegios de SYSTEM en cualquier DC, es posible acceder a la clave raíz de KDS y calcular las contraseñas para cualquier gMSA en todo el bosque.
Un análisis detallado se puede encontrar en la discusión sobre Golden gMSA Trust Attacks.
Ataque de cambio de esquema
Este método requiere paciencia, esperando la creación de nuevos objetos AD privilegiados. Con privilegios de SYSTEM, un atacante puede modificar el Esquema de AD para otorgar a cualquier usuario control total sobre todas las clases. Esto podría llevar a acceso no autorizado y control sobre objetos AD recién creados.
Lectura adicional está disponible sobre Schema Change Trust Attacks.
De DA a EA con ADCS ESC5
La vulnerabilidad ADCS ESC5 apunta al control sobre objetos de Infraestructura de Clave Pública (PKI) para crear una plantilla de certificado que permite la autenticación como cualquier usuario dentro del bosque. Dado que los objetos PKI residen en el NC de Configuración, comprometer un DC hijo escribible permite la ejecución de ataques ESC5.
Más detalles sobre esto se pueden leer en From DA to EA with ESC5. En escenarios que carecen de ADCS, el atacante tiene la capacidad de configurar los componentes necesarios, como se discute en Escalating from Child Domain Admins to Enterprise Admins.
En este escenario tu dominio es confiable por uno externo, dándote permisos indeterminados sobre él. Necesitarás encontrar qué principales de tu dominio tienen qué acceso sobre el dominio externo y luego intentar explotarlo:
External Forest Domain - OneWay (Inbound) or bidirectionalEn este escenario, tu dominio está confiando algunos privilegios a un principal de diferentes dominios.
Sin embargo, cuando un dominio es confiado por el dominio que confía, el dominio confiado crea un usuario con un nombre predecible que utiliza como contraseña la contraseña confiada. Lo que significa que es posible acceder a un usuario del dominio que confía para entrar en el confiado para enumerarlo y tratar de escalar más privilegios:
External Forest Domain - One-Way (Outbound)Otra forma de comprometer el dominio confiado es encontrar un enlace SQL confiado creado en la dirección opuesta de la confianza del dominio (lo cual no es muy común).
Otra forma de comprometer el dominio confiado es esperar en una máquina donde un usuario del dominio confiado pueda acceder para iniciar sesión a través de RDP. Luego, el atacante podría inyectar código en el proceso de sesión RDP y acceder al dominio de origen de la víctima desde allí. Además, si la víctima montó su disco duro, desde el proceso de sesión RDP, el atacante podría almacenar backdoors en la carpeta de inicio del disco duro. Esta técnica se llama RDPInception.
RDP Sessions AbuseEl riesgo de ataques que aprovechan el atributo de historial de SID a través de las confianzas de bosque se mitiga mediante el Filtrado de SID, que está activado por defecto en todas las confianzas inter-forestales. Esto se basa en la suposición de que las confianzas intra-forestales son seguras, considerando el bosque, en lugar del dominio, como el límite de seguridad según la postura de Microsoft.
Sin embargo, hay un inconveniente: el filtrado de SID podría interrumpir aplicaciones y el acceso de usuarios, lo que lleva a su desactivación ocasional.
Para las confianzas inter-forestales, emplear la Autenticación Selectiva asegura que los usuarios de los dos bosques no sean autenticados automáticamente. En su lugar, se requieren permisos explícitos para que los usuarios accedan a dominios y servidores dentro del dominio o bosque que confía.
Es importante señalar que estas medidas no protegen contra la explotación del Contexto de Nombres de Configuración (NC) escribible o ataques a la cuenta de confianza.
Más información sobre las confianzas de dominio en ired.team.
Aprende más sobre cómo proteger credenciales aquí.\
Restricciones de Administradores de Dominio: Se recomienda que los Administradores de Dominio solo puedan iniciar sesión en Controladores de Dominio, evitando su uso en otros hosts.
Privilegios de Cuentas de Servicio: Los servicios no deben ejecutarse con privilegios de Administrador de Dominio (DA) para mantener la seguridad.
Limitación Temporal de Privilegios: Para tareas que requieren privilegios de DA, su duración debe ser limitada. Esto se puede lograr mediante: Add-ADGroupMember -Identity ‘Domain Admins’ -Members newDA -MemberTimeToLive (New-TimeSpan -Minutes 20)
Implementar el engaño implica establecer trampas, como usuarios o computadoras señuelo, con características como contraseñas que no expiran o están marcadas como Confiadas para Delegación. Un enfoque detallado incluye crear usuarios con derechos específicos o agregarlos a grupos de alto privilegio.
Un ejemplo práctico implica usar herramientas como: Create-DecoyUser -UserFirstName user -UserLastName manager-uncommon -Password Pass@123 | DeployUserDeception -UserFlag PasswordNeverExpires -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose
Más sobre la implementación de técnicas de engaño se puede encontrar en Deploy-Deception en GitHub.
Para Objetos de Usuario: Indicadores sospechosos incluyen ObjectSID atípico, inicios de sesión infrecuentes, fechas de creación y bajos conteos de contraseñas incorrectas.
Indicadores Generales: Comparar atributos de objetos potencialmente señuelo con los de objetos genuinos puede revelar inconsistencias. Herramientas como HoneypotBuster pueden ayudar a identificar tales engaños.
Evasión de Detección de Microsoft ATA:
Enumeración de Usuarios: Evitar la enumeración de sesiones en Controladores de Dominio para prevenir la detección de ATA.
Suplantación de Tickets: Utilizar claves aes para la creación de tickets ayuda a evadir la detección al no degradar a NTLM.
Ataques DCSync: Se aconseja ejecutar desde un controlador de dominio no para evitar la detección de ATA, ya que la ejecución directa desde un controlador de dominio activará alertas.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
