Soy estudiante de ciberseguridad y he creado este espacio para compartir mis apuntes y técnicas relacionadas con el Pentesting. Aquí voy subiendo todo lo que aprendo, desde conceptos básicos hasta ataques más avanzados, con ejemplos y enfoques prácticos que uso en mi día a día.

La idea es que estas notas sean claras y útiles, tanto para mí como para cualquiera que esté en este mundo o quiera empezar en él. Me gusta documentar lo que hago porque me sirve para reforzar lo aprendido y, de paso, devolver algo a la comunidad que me ha ayudado tanto.

Este sitio no pretende ser perfecto, pero sí práctico y al grano. Lo que más me importa es seguir aprendiendo y tener un lugar donde organizar lo que sé. Si te sirve o te inspira a mejorar, ya con eso me doy por satisfecho.

¡Gracias por pasarte por aquí! 😊

No credentials

NSrpcenum

Se trata de la herramienta de S4vitar, pero con el nombre renombrado, para diferenciar de la otra herramienta creada llamada rpcenum que sí permite utilizar credenciales.

Esta herramienta permite enumerar el DA a través del protocolo RPC con una Null Session, es decir, sin proporcionar credenciales de acceso. Solamente funcionará en caso de que tengamos los permisos adecuados.

rpccclient

Kerbrute usernames

Netexec with guest user

Netexec Kerberos Enumeration Brute Force

Realizar fuerza bruta, similar a Kerbrute para verificar si un usuario es válido en el dominio a través de Kerberos.

ridenum

impacket-lookupsid

With credentials

ldapdomaindump

rpcenum

A través de la herramienta de rpcenum modificada, podemos realizar una enumeración completa de usuarios y demás información a través del protocolo RPC. La herramienta requiere de credenciales válidas.

rpcclient

Netexec

impacket-lookupsid

ldapsearch

Introduction

BloodHound es una herramienta fundamental en auditorías de Active Directory, diseñada para identificar relaciones de confianza y posibles vectores de ataque dentro de un dominio. Permite analizar cómo un atacante podría moverse lateralmente o escalar privilegios aprovechando relaciones ya existentes entre objetos del dominio.

En esta sección vamos a centrarnos en explicar los distintos métodos de recolección de datos disponibles (collectors), comparando su uso y aplicabilidad según el entorno. Además, detallaremos la instalación y diferencias clave entre BloodHound clásico y BloodHound Community Edition (CE).

A lo largo del blog veremos:

• Cómo utilizar los diferentes collectors:

  • SharpHound.exe: el ejecutable clásico.

  • SharpHound.ps1: ideal para entornos con PowerShell habilitado.

El objetivo es dejar documentado de forma clara y funcional cómo trabajar con BloodHound, integrarlo en una auditoría y aprovechar al máximo sus capacidades.

Collectors

Para que BloodHound pueda generar un grafo útil y preciso del dominio, primero es necesario realizar una fase de recolección de información. Esta tarea recae sobre los collectors, que son los encargados de extraer los datos estructurales del entorno Active Directory: relaciones entre usuarios y grupos, sesiones activas, delegaciones, permisos sobre objetos, entre otros.

Actualmente existen varios collectors disponibles, cada uno diseñado para adaptarse a distintos escenarios operativos, niveles de privilegios o restricciones del entorno. Elegir el collector adecuado depende tanto del contexto técnico como de los objetivos del análisis.

En este apartado documentamos los principales collectors utilizados en auditorías de AD, incluyendo su instalación, ejecución y particularidades:

• SharpHound.exe: el ejecutable clásico para entornos Windows.

• SharpHound.ps1: alternativa en PowerShell útil en entornos con políticas más restrictivas.

• bloodhound-python: collector multiplataforma, ideal para recolección desde sistemas Linux.

Esta sección tiene como objetivo servir de referencia práctica para seleccionar y utilizar el collector más adecuado en función del entorno y los objetivos de la auditoría.

bloodhound-python

Installation

Use

# Autenticación usuario y contraseña

# Autenticación a través de Pass-the-Hash (PtH)

# Autenticación mediante Kerberos (.ccache)

RustHound

Installation

Tenemos que disponer de rust instalado en Kali, podemos seguir el siguiente blog para instalarlo.

Una vez instalado rust en nuestro equipo, instalaremos RustHound-CE a través del siguiente comando.

Use

# Autenticación usuario y contraseña

# Autenticación usuario y contraseña para ADCS

# Autenticación mediante Kerberos (.ccache)

# Autenticación mediante Kerberos (.ccache) para ADCS

SharpHound.ps1

Importar en memoria SharpHound.ps1

# Importar SharpHound.ps1 a través de un servidor web que tiene alojado el script PS!, puede ser el nuestro propio de atacante.

# Teniendo el script de PowerShell en la máquina vícitma podemos importarlo de la siguiente manera

Recoletar información a través de SharpHound.ps1

SharpHound.exe

Pasaremos el binario al equipo víctima y lo ejecutaremos para recolectar la información.

NetExec

# Autenticación a través de usuario y contraseña

# Autenticación a través de Pass-the-Hash (PtH)

# Autenticación a través de Kerberos

# Autenticación a través de Kerberos (.ccache)

certipy-ad

BloodHound

# Autenticación a través de usuario y contraseña

# Autenticación a través de Pass-the-Hash (PtH)

# Autenticación a través de Kerberos (.ccache)

Old BloodHound

# Autenticación a través de usuario y contraseña

# Autenticación a través de Pass-the-Hash (PtH)

# Autenticación a través de Kerberos (.ccache)

BloodHound CE

Installation

Actualizaremos los repositorios e instalaremos docker-compose en nuestro equipo.

Nos descargaremos el archivo del docker-compose.yml con cURL y comprobaremos que se ha descargado correctamente.

También podemos crear directamente el contenido del docker-compose.yml.

Iniciaremos los contenedores definidos en el archivo docker-compose.yml.

Verificaremos que los contenedores se encuentran en ejecución y no ha habido ningún fallo.

Comprobaremos la contraseña inicial en los logs.

Accederemos a y asignaremos las siguientes credenciales:

• Username: admin

• Password: Contraseña Inicial obtenida en el punto anterior

Indicaremos la contraseña inicial en el primer campo, y la nueva contraseña que deberá cumplir los requisitos establecidos.

Ya dispondremos de nuestro BloodHound CE instalado correctamente en nuestro equipo a través de Docker.

Video installation guide

Start BloodHound CE

En mi caso tengo el archivo docker-compose.yml en el directorio /opt/BloodHound-CE. De esta manera sin importar en el directorio donde me encuentre lo levanto directamente con el siguiente comando.

Stop BloodHound CE

Para parar BloodHound-CE ejecutaremos el siguiente comando, así liberamos los puertos que utiliza, etc. Luego podemos levantarlo con el comando anterior o con sudo docker-compose -f /opt/BloodHound-CE/docker-compose.yml start

Ingest Data

Para subir nuestra información recolectada a través de los Collectors, deberemos de ingresar a . Una vez nos encontremos en el panel de BloodHound-CE realizaremos los siguientes pasos.

1. Ingresar al apartado de "Administration"

2. Acceder a la pestaña de "File Ingest"

3. Click en "Upload File(s)"

Haremos click dentro de la casilla o también podremos arrastrar directamente nuestor .zip o los archivos JSON sueltos.

Seleccioanaremos nuestro archivo comprimido.

Una vez seleccionado nuestro archivo, le daremos a la opción de Upload.

Confirmaremos que nso aparece el siguiente mensaje indicando que se han subido correctamente. Le daremos a Close.

Verificaremos que después de que se integre correctamente los datos recopilados, nos aparece como Complete. En caso de que aparezca otro estado como Cancelled, volver a subir el archivo. Si el problema persiste, es altamente posible que el problema se encuentre en la compatibilidad del Collector utilizado, probar con otro.

Una vez todo subido, podemos hacer uso de BloodHound-CE y navegar en la interfaz.

Erase Data

Cuando necesitemos borrar la "base de datos" que tiene BloodHound-CE de los datos subidos anteriormente, deberemos de eliminar los datos. Podemos hacer una "limpieza profunda" para no dejar rastro de los datos subidos. Para ello, realizaremos los siguientes pasos.

1. Accederemos al apartado "Administration"

2. Ingresaremos al apartado de "Database Management"

3. Marcaremos todas las casillas, para la "limpieza profunda"

How to use

Una vez tengamos subido nuestros datos en BloodHound-CE, podremos navegar en la interfaz accediendo al apartado de "Explore".

Search

En el apartado de SEARCH podemos buscar por un nodo/objeto que queramos consultar, si no aparece significa que no existe o bien a la hora de recolectar la información no ha aparecido (seguramente por tema de permisos).

Click node info

Al hacer click sobre un nodo/objecto, nos aparecerá en la zona lateral derecha el siguiente menú con distintos submenús del nodo/objeto que investigaremos a continuación.

Disponemos de varios sub apartados, aunque los más relevantes de momento son los siguientes.

Pathfinding

La funcionalidad de Pathfinding en BloodHound CE permite buscar rutas de ataque desde un nodo de inicio hasta un objetivo, evaluando los privilegios y relaciones entre usuarios y grupos.

En este ejemplo, partimos desde OLIVIA@ADMINISTRATOR.HTB, que tiene un GenericAll sobre MICHAEL@ADMINISTRATOR.HTB, lo que permite control total sobre esa cuenta. A su vez, MICHAEL puede forzar el cambio de contraseña de BENJAMIN@ADMINISTRATOR.HTB, lo que completa la cadena de ataque.

Este tipo de vista es clave para identificar caminos reales de escalada de privilegios o movimientos laterales dentro del dominio.

Edges

En BloodHound CE, los edges representan las relaciones entre objetos del dominio. Estas relaciones pueden ser de distintos tipos: pertenencia a grupos (MemberOf), delegaciones (GetChanges, GenericAll, etc.), sesiones activas, ACLs y muchas otras.

Cuando hacemos clic en un edge, se abre un panel con más detalle sobre esa relación. Este panel incluye diferentes secciones:

Marking Objects as Owned/High Value

BloodHound CE permite marcar manualmente objetos del dominio como Owned (comprometidos) o High Value (objetivos prioritarios). Esto nos ayuda a visualizar mejor el progreso de una auditoría y enfocar los análisis de ruta hacia activos críticos.

Estas marcas se aplican desde el clic derecho sobre el nodo. Una vez marcado, el nodo se resalta visualmente en el grafo con un ícono correspondiente.

En el panel Group Management podemos gestionar de forma organizada los objetos marcados como Owned o High Value. Su uso se resume en los siguientes pasos:

1. Accedemos al apartado Group Management desde el ícono de personas (barra lateral izquierda).

2. Seleccionamos el grupo que queremos revisar Owned/High Value.

3. Elegimos el entorno, normalmente All Active Directory Domains.

Querys Cypher

En esta sección podemos lanzar queries en lenguaje Cypher para consultar relaciones dentro del grafo de BloodHound. Es muy útil para buscar rutas de ataque o listar objetos críticos de forma más precisa.

BloodHound CE ya trae varias queries predefinidas, como:

• Usuarios Kerberoastables

• Rutas más cortas hacia Domain Admins

• Listado de todos los Domain Admins

También podemos modificar estas queries o crear las nuestras según lo que necesitemos buscar en el entorno.

Custom Querys

BloodHound CE permite crear y guardar nuestras propias queries en Cypher. Esto nos da flexibilidad para buscar relaciones específicas en el grafo y reutilizar esas búsquedas en futuras auditorías.

En el siguiente repositorio de GitHub, disponemos de algunas Querys ya creadas que podemos añadir.

En este caso, ponemos la QUERY que queremos consultar, le daremos a "Save Query".

Le asignaremos un nombre a la QUERY.

Y verificaremos que se nos guarda, al darle click nos realizará la consulta asignada.

BloodHound

Installation

Actualizaremos los repositorios e instalaremos BloodHound y Neo4j para que funcione correctamente BH.

Abriremos en una terminal aparte Neo4j, se nos iniciará la interfaz web en

Accederemos a e ingresaremos las siguientes credenciales por defecto.

• Username: neo4j

• Password: neo4j

Nos pedirá cambiar la contraseña.

Una vez modificada la contraseña del Neo4j, abriremos BloodHound en segundo plano en una nueva terminal.

Indicaremos al usuario neo4j y las nuevas credenciales modificadas. Podemos guardar las credenciales para que se nos conecte automáticamente.

Una vez inicie sesión, se iniciará correctamente BloodHound y ya podremos navegar dentro de él.

Video installation guide

Start BloodHound and Neo4j

Para iniciar BloodHound una vez ya realizada la instalación es ejecutar los siguientes comandos.

En una terminal aparte, abriremos Neo4j. Deberemos dejar que nos aparezca la línea del output en el cual indica que la interfaz web está habilitada en

Abriremos BloodHound en segundo plano, si tenemos las credenciales almacenadas con el check, iniciará sesión automáticamente.

Ingest Data

Erase Data

How to use

Introduction

El ataque conocido como Shadow Credentials permite a un atacante obtener acceso persistente a una cuenta de Active Directory (usuario o máquina) sin conocer su contraseña ni su hash. Para lograrlo, se abusa del atributo poco conocido llamado msDS-KeyCredentialLink, introducido con Windows Server 2016.

Este atributo permite almacenar claves públicas asociadas a una cuenta para autenticación mediante Kerberos PKINIT, un método que reemplaza el uso de contraseñas por criptografía asimétrica (clave pública/privada).

Si un atacante tiene permisos como WriteProperty, GenericWrite o GenericAll sobre ese atributo en una cuenta objetivo, puede inyectar su propia clave pública. Luego, puede autenticarse como ese usuario usando PKINIT y su clave privada, consiguiendo un TGT válido sin necesidad de contraseñas ni tickets previos.

¿Por qué es peligroso?

• No se requiere modificar la contraseña del objetivo.

• La cuenta sigue funcionando normalmente, sin alertas visibles.

• La clave inyectada puede pasar desapercibida si no se monitoriza msDS-KeyCredentialLink.

Requisitos clave

• Un controlador de dominio con soporte PKINIT (Windows Server 2016 o superior).

• Entorno con Active Directory Certificate Services (AD CS) o una CA interna.

• Permisos para modificar el atributo msDS-KeyCredentialLink en una cuenta del dominio. (GenericAll, GenericWrite o AddKeyCredentialLink)

¿Qué logra el atacante?

Una vez que inyecta la clave pública en el atributo msDS-KeyCredentialLink, el atacante puede:

• Autenticarse como el objetivo mediante PKINIT, sin necesidad de conocer su contraseña ni su hash.

• Obtener un Ticket Granting Ticket (TGT) válido para esa cuenta.

• Realizar movimientos laterales o delegaciones utilizando técnicas como S4U2self o S4U2proxy.

En esta sección documentaremos la teoría detrás de esta técnica, cómo identificar entornos vulnerables, cómo explotarla paso a paso con herramientas como pyWhisker, Certipy o PKINITtools, bloodyAD o ldap_shell.

From Linux

certipy-ad

ldap_shell

Authentication on ldap_shell

Command to use

Proof of Concept (PoC)

bloodyAD and PKINIT

Paso 1: Creación de las Shadow Credentials al usuario victim

Una vez ejecutado la herramienta de bloodyAD para añadir las Shadow Credentials al usuario, se nos proporcionará un comando a ejecutar a través de las herramientas de .

Paso 2: Solicitud del ticket TGT después del Shadow Credentials

Ejecutaremos el comando proporcionado en el paso anterior para solicitar el TGT correspondiente al usuario el cual le hemos añadido las Shadow Credentials.

Nos quedaremos con el valor del TGT que se nos generará (.ccache), ya que lo necesitaremos en el siguiente paso. Por otro lado, también necesitaremos el valor de la Key que se nos proporciona que se encuentra marcada en rojo en el apartado INFO.

Paso 3: Exportar en la sesión actual el ticket TGT

Exportaremos en la variable KRB5CCNAME el ticket TGT que se nos ha generado en el paso anterior (.ccache) y verificaremos que es un ticket válido a través de klist.

Paso 4: Recuperar el hash NTLM del usuario

El último paso deberemos de utilizar la herramienta getnthash.py de PKINIT en la cual necesitaremos proporcionar la Key que se nos proporciona en el paso 2, haber importado el ticket TGT en nuestra sesión e indicar el dominio y el usuario victim.

Proof of Concept (PoC)

pyWhisker and PKINIT

References

Introduction

En Active Directory, cada objeto (usuario, grupo, equipo…) está protegido por una lista de control de acceso (ACL) cuyo conjunto de entradas (ACE) define qué acciones puede realizar cada identidad. El permiso GenericWrite actúa como una “master key” de escritura: engloba casi todos los derechos para modificar atributos y flags de un objeto, salvo aquellos que requieren permisos especiales (p. ej. resetear contraseñas).

Con GenericWrite sobre un usuario un atacante puede:

• Escribir en servicePrincipalNames y lanzar un Kerberoasting dirigido.

• Habilitar cuentas deshabilitadas modificando el userAccountControl.

• Marcar la bandera DONT_REQ_PREAUTH en userAccountControl, permitiendo AS-REP Roasting sin necesidad de preautenticación.

• Inyectar certificados en msDS-KeyCredentialLink para crear “Shadow Credentials” y autenticarse vía Kerberos PKINIT como si fuera ese usuario.

Si controla GenericWrite sobre un grupo, puede añadirse (o agregar cualquier otra cuenta) directamente al grupo, escalando privilegios al instante.

Y si lo obtiene sobre un objeto de equipo, puede tocar el atributo msDS-KeyCredentialLink del equipo, generando Shadow Credentials de máquina y autenticándose como esa cuenta de equipo mediante PKINIT.

Group

Add user to a group

En estos ejemplos, añadiremos al usuario targetUser al grupo targetGroup a través del usuario attacker que es el que dispone del privilegio GenericWrite sobre el grupo targetGroup, con lo cual podemos añadirnos a nosotros mismos o a otros usuarios.

From Linux

From Windows

User

Enable disabled user

Kerberoasting

AS-REP Roasting

Shadow Credentials

Script path

Computer

Resource-based Constrained Delegation(RBCD Attack)

References

Introduction

En este post, exploramos el abuso de ForceChangePassword Active Directory a través de la explotación de Listas de Control de Acceso Discrecional (DACL) utilizando el permiso ForcePasswordChange en entornos Active Directory. Este permiso es especialmente peligroso para cuentas privilegiadas, ya que permite el movimiento lateral y el acceso no autorizado a través de sistemas suplantando la identidad de la cuenta comprometida. Por lo tanto, entender cómo funciona esta vulnerabilidad es crucial para los profesionales de la seguridad.

From Linux

bloodyAD

Proof of Concept (PoC)

PowerView.py

Authentication on PowerView.py

Command to use

Proof of Concept (PoC)

Impacket-changepasswd

NetExec

Change Password of a different User

Podemos modificar la contraseña de otro usuario el cual tengamos los permisos suficientes (GenericAll o ForceChangePassword) a través de (NEWPASS) o modificar su hash NTLM (NEWNTHASH).

ldap_shell

Deberemos acceder a la interfaz interactiva de ldap_shell, para ello deberemos autenticarnos a través de alguno de los siguientes métodos. Posteriormente al acceder a la terminal de ldap_shell, ejecutaremos el comando correspondiente para modificar la contraseña del usuario.

Authentication on ldap_shell

Command to use

Proof of Concept (PoC)

rpcclient

net rpc

pth-net

Metasploit

Accedemos a Metasploit a través de (msfconsole -q) y ejecutamos los siguientes comandos. Desde nuestro usuario attacker que dispone del ACL ForceChangePassword sobre el usuario victim, realizaremos el cambio de contraseña.

Proof of Concept (PoC)

From Windows

bloodyAD.exe

PowerView.ps1

Mimikatz

Windows Native

References

From Windows

Cross-Forest Kerberoasting

Enumerating Accounts for Associated SPNs Using Get-DomainUser

Performing a Kerberoasting Attacking with Rubeus Using /domain Flag

Admin Password Re-Use & Group Membership

En entornos con trust bidireccional entre forests, si se compromete el Dominio A y se obtiene la contraseña o hash NT de una cuenta con privilegios (como Administrator o un Domain Admin), conviene comprobar si hay cuentas con el mismo nombre en el Dominio B. Si reutilizan contraseñas, es posible escalar directamente.

También es común que admins del Dominio A estén en grupos locales del Dominio B (como el grupo Administrators), lo que permite acceso total si se compromete esa cuenta.

Para detectar estos casos, se puede usar Get-DomainForeignGroupMember de PowerView y revisar foreign group membership, especialmente útil si existe un trust entre forests como con CORP.LOCAL.

Using Get-DomainForeignGroupMember

La salida del comando muestra que el grupo Administrators en CORP.LOCAL incluye como miembro a la cuenta Administrator de CORPORATE.LOCAL. Esto confirma que hay una relación de trust funcional entre ambos dominios.

Se puede verificar el acceso ejecutando Enter-PSSession vía WinRM, usando las credenciales de esa cuenta para conectarse al sistema remoto.

Accessing DC03 Using Enter-PSSession

from Linux

Cross-Forest Kerberoasting

GenericAll/GenericWrite

User/Computer

Para realizar este ataque tras comprometer un child domain, necesitamos lo siguiente:

• El hash KRBTGT del child domain

• El SID del child domain

Introduction to ADCS

ADCS es el rol que maneja la emisión de certificados para usuarios, equipos y servicios en la red de Active Directory. Este servicio, si está mal configurado, puede presentar vulnerabilidades que los atacantes podrían explotar para elevar privilegios o acceder a información sensible.

Algunas de las posibles vulnerabilidades que puede tener ADCS son:

1. Delegación de privilegios en la emisión de certificados: Si ciertos usuarios tienen permisos para emitir certificados para otros, un atacante podría abusar de estos privilegios para obtener permisos elevados.

2. Mala configuración en las plantillas de certificados: Configuraciones incorrectas en las plantillas de certificados podrían permitir que un atacante solicite un certificado en nombre de otro usuario, incluso uno con privilegios elevados.

3. NTLM Relaying en HTTP: Si el ADCS acepta autenticación NTLM en lugar de Kerberos, un atacante podría redirigir las solicitudes para ganar acceso.

Componentes principales:

• CA (Certification Authority): Emite y gestiona certificados. Puede haber múltiples CAs en una jerarquía.

• Certificate Templates: Definen la configuración, permisos y requisitos para emitir certificados.

• CES (Certificate Enrollment Server): Permite renovar certificados mediante solicitudes HTTPS.

Formatos de certificados X.509:

• PEM: Certificado DER codificado en base64; puede almacenar múltiples claves sin protección por contraseña.

• DER: Certificado en formato binario crudo.

• PFX/P12 (PKCS#12): Almacena claves privadas con protección por contraseña.

Principales atributos de certificados:

• Subject: Entidad a la que se emite el certificado.

• Issuer: Normalmente la CA.

• SAN: Nombre alternativo del sujeto.

Proceso de CSR (Certificate Signing Request):

1. El cliente envía una solicitud de certificado (CSR).

2. La CA verifica los permisos del cliente para emitir el certificado solicitado.

3. Si los permisos coinciden, la CA genera y firma el certificado con su clave privada.

Checking Misconfigured Templates

Herramienta que utilizaremos para la escalada de privilegios con los ADCS.

Para verificar si existen plantillas mal configuradas, las cuales podemos abusar, podemos hacer uso del siguiente comando para que nos lo muestre en la terminal.

Ejemplo de cómo debería salirnos si existe una plantilla mal configurada en el ADCS que podemos intentar explotar. En este ejemplo, nos aparece que podemos realizar la explotación ESC7.

KDC_ERR_PADATA_TYPE_NOSUPP

Es posible que en algún momento obtengamos este mensaje de error al intentar autenticarnos con el certificado PFX del usuario que estamos impersonando, lo que indica que el KDC no admite el tipo de autenticación proporcionado.

Nos encontramos con varios blogs que mencionan el error KDC_ERR_PADATA_TYPE_NOSUPP, el cual ocurre cuando el controlador de dominio no soporta PKINIT. Esto impide que autenticarnos directamente con el certificado PFX.

Como alternativa, podemos utilizar PassTheCert para autenticarnos a LDAP a través de SChannel con nuestro certificado. Aunque esto solo nos daría acceso a LDAP, podría ser suficiente si el certificado nos identifica como Administrador de Dominio.

Lo primero que haremos será extraer la clave privada y el certificado desde el archivo PFX que obtuvimos del usuario Administrator. Para ello, utilizamos Certipy de la siguiente manera. A continuación, haremos uso de la herramienta PassTheCert.py para autentifcarnos con el certificado obtenido.

Con PassTheCert, utilizamos la clave privada y el certificado generado anteriormente para autenticarnos. En este ejemplo. se nos mostraría el resultado del comando whoami.

Para poder escalar privilegios y buscar otras maneras. podemos obtener una consola LDAP Shell con el parámetro -action ldap-shell.

Para ver varios ejemplos del uso de PassTheCert y de cómo logramos obtener acceso al sistema como el usuario Administrator podemos comprobar el siguiente blog.

ESC1

Domain Users Enrollment

Solicitud del certificado con SAN alternativo.

Autenticación con certificado.

Domain Computers (Machine Account)

En algunas ocasiones, es posible que exista la ESC1 pero solamente se pueda realizar a través de algún Domain Computer. En este resultado de adPEAS se comprueba que solamente los Domain Computers tienen permisos de enrollment sobre la plantilla vulnerable para realizar el ESC1.

Por lo tanto, hay que disponer de las credenciales de un equipo, que se pueden obtener de diversas maneras. En caso de que podemos añadir nuevas máquinas al dominio, podemos realizar lo siguiente a través de la herramienta de .

Una vez dispongamos de acceso a autenticarnos como un Domain Computer, realizaremos el ataque. Sustituir Gzzcoo$ por el nombre del PC y la contraseña Gzzcoo123 por la correspondiente.

Autenticación con certificado.

ESC2

Solicitud del certificado con SAN alternativo.

Autenticación con certificado.

Verificación.

ESC3

Solicitar un certificado.

Solicitar un certificando suplantando al Administrator.

ESC4

Atacando a la plantilla vulnerable a ESC4.

Verificar plantilla ESC4 después de la modificación.

Abusando de la plantilla modificada.

Recuperando el hash NTLM del usuario Administrator.

Volviendo la plantilla ESC4 al estado original.

ESC5

Solicitar el certificado del Domain Admin.

Emitir el certificado solicitado.

En este caso, aprobamos la solicitud anterior especificando el ID de la solicitud con la opción -issue-request 10.

Recuperar el certificado emitido.

Autenticarse con el certificado del Administrator.

ESC6

Solicitud de certificado con UPN alternativo, en este caso, el usuario Administrator.

ESC7

Requisitos previos

Para que esta técnica funcione, el usuario también debe tener el derecho de acceso Administrar certificados y la plantilla de certificado SubCA debe estar habilitada. Con el derecho de acceso Administrar CA, podemos cumplir con estos requisitos previos.

La técnica se basa en el hecho de que los usuarios con el derecho de acceso Administrar CA y Administrar certificados pueden emitir solicitudes de certificado fallidas. La plantilla de certificado SubCA es vulnerable a ESC1, pero solo los administradores pueden inscribirse en la plantilla. Por lo tanto, un usuario puede solicitar inscribirse en la SubCA (que será denegada) pero luego el administrador la emitirá.

Si solo tiene el derecho de acceso Administrar CA, puede otorgarse el derecho de acceso Administrar certificados agregando a su usuario como un nuevo funcionario.

La plantilla SubCA se puede habilitar en la CA con el parámetro -enable-template. De manera predeterminada, la plantilla SubCA está habilitada.

Ataque

Si hemos cumplido con los requisitos previos para este ataque, podemos comenzar solicitando un certificado basado en la plantilla SubCA.

Esta solicitud será rechazada, pero guardaremos la clave privada y anotaremos el ID de la solicitud.

Con Administrar CA y Administrar certificados, podemos emitir la solicitud de certificado fallida con el comando ca y el parámetro -issue-request.

Y finalmente, podemos recuperar el certificado emitido con el comando req y el parámetro -retrieve . Obtenemos el certificado del Administrator.

ESC8

Certipy relay

Realizar la Autenticación Coercion (desde otra terminal)

Esto nos dará el certificado y la clave privada del usuario.

Solicitar un TGT como máquina de equipo (o Domain Controller)

Esto nos dará el hash NTLM del usuario, que podemos usar para autenticarnos.

Dependiendo de la situación, ahora tenemos 2 ataques posibles...

DCSync (si disponemos de permisos de Administradores del dominio)

Realizando DCSync Attack utilizando el hash NTLM como Domain Controller.

Silver Ticket (utilizando el hash NTLM de una cuenta de equipo)

Creación del Silver Ticket

Realizando PassTheTicket con PsExec

ESC9

Requisitos:

• GenericWrite o GenericAll sobre cualquier A para comprometer a la cuenta B.

En este caso 'hacker' dispone de los privilegios sobre 'victim'. El usuario 'victim' tiene permisos para realizar el ESC9.

Conseguir hash NTLM del usuario 'victim' a través de ShadowCredentials ya que el usuario 'hacker' dispone de los permisos necesarios sobre el usuario 'victim'.

Utilizamos Certipy para actualizar el UPN de la cuenta 'victim', asignándole el valor de Administrator. Esto nos permite asociar cualquier certificado emitido a 'victim' con la identidad de Administrator:

Solicitamos un certificado utilizando la plantilla vulnerable. Este certificado se emitió con el UPN de Administrator, habilitando su uso para autenticación con privilegios elevados.

Posteriormente, restauramos el UPN de 'victim' a su valor original para minimizar evidencias de la modificación realizada.

Seguidamente utilizamos el certificado emitido para autenticarnos y verificamos que obtenemos el hash NTLM del usuario "Administrator".

ESC10

Caso 1

Requisitos:

• GenericWrite o GenericAll sobre cualquier A para comprometer a la cuenta B.

En este caso 'hacker' dispone de los privilegios sobre 'victim'. El usuario 'victim' tiene permisos para realizar el ESC10.

Conseguir hash NTLM del usuario 'victim' a través de ShadowCredentials ya que el usuario 'hacker' dispone de los permisos necesarios sobre el usuario 'victim'.

Modificar el UPN del usuario 'victim' al usuario Administrator.

Solicitud del certificado.

Revertiremos los cambios del usuario 'victim' (para asegurarse de que solo el administrador coincida con el certificado)

Autenticarse como usuario Administrator.

Caso 2

Requisitos:

• GenericWrite o GenericAll sobre cualquier A para comprometer a la cuenta B sin que disponga un userPrincipalName (cuentas de máquina y administrador de dominio integrado Administrador.

En este caso 'hacker' dispone de los privilegios sobre 'victim' y deseamos comprometer el Domain Controller DC$@domain.htb.

Conseguir hash NTLM del usuario 'victim' a través de ShadowCredentials ya que el usuario 'hacker' dispone de los permisos necesarios sobre el usuario 'victim'.

Modificamos el UPN del usuario 'victim' a 'DC$@dominio.htb'.

Solicitamos un certificado como 'victim' para obtener el certificado del Domain Controller (DC).

Revertir los cambios de 'victim' (para asegurarse de que solo el administrador coincida con el certificado).

Autenticación con el certificado del DC.

Creación de una nueva cuenta de equipo.

Abusar de RBCD (Resource Based Constrained Delegation) para impersonar al Administrator.

Autenticarse utilizando el TGT del usuario Administrator.

ESC11

Configuramos el relay

Autenticación Coerce con PetitPotam

Certipy recibe autenticación del DC de AD

A continuación, se deberá realizarlos pasos del

ESC12

ESC13

Desde sistemas tipo UNIX, esta solicitud de extracción en Certipy (Python) permite identificar una plantilla de certificado con una política de emisión, es decir, con la propiedad msPKI-Certificate-Policy no vacía. Además, verifica si esta política de emisión tiene un enlace de grupo OID a un grupo en la propiedad msDS-OIDToGroupLink.

Si se encuentra una plantilla vulnerable, no hay ningún requisito de emisión particular, el principal puede inscribirse y la plantilla indica el EKU de autenticación del cliente; solicite un certificado para esta plantilla con Certipy (Python) como de costumbre:

Luego, el certificado se puede usar con Pass-the-Certificate para obtener un TGT y autenticarse como el principal controlado, pero con sus privilegios agregados a los del grupo vinculado.

ESC14

Scenario A: Write altSecurityIdentities on Target

Comprobar que con el usuario (userA) tengamos permisos de escritura en el atributo altSecurityIdentities en el usuario TARGET (userB).

Crearemos un nuevo Domain Computer.

Autenticamos con el Domain Computer recién creado para obtener su PFX.

Obtener el .crt del certificado PFX del Domain Computer recién creado.

Script para obtener el X509 a travésdel issuer y el serial.

Resultado obtenido al ejecutar el script.

Modificamos el atributo altSecurityIdentities del userB a través del userA ya que disponemos de permisos y le asignamos el valor X509 anteriormente obtenido.

Una vez modificado, nos autenticamos con el PFX del Domain Computer creado impersonando al userB, obtenemos su hash NTLM y su TGT (.ccache).

ESC15

ESC16

Output:

Scenario A: UPN Manipulation (Requires StrongCertificateBindingEnforcement = 1 (Compatibility) or 0 (Disabled) on DCs, and attacker has write access to a "victim" account's UPN)

# Step 1: Read initial UPN of the victim account (Optional - for restoration).

Step 2: Update the victim account's UPN to the target administrator's sAMAccountName.

Step 3: (If needed) Obtain credentials for the "victim" account (e.g., via Shadow Credentials).

En caso de disponer de las credenciales de victim, pasar directamente al paso 4.

Step 4: Request a certificate as the "victim" user from any suitable client authentication template (e.g., "User") on the ESC16-vulnerable CA.

En caso de haber realizado el Shadow Credentials (Step 3) realizar los siguientes pasos.

En caso de disponer de las credenciales de victim y no haber realizado el Step 3, realizar lo siguiente:

Step 5: Revert the "victim" account's UPN.

Step 6: Authenticate as the target administrator.

References

• Abusing Active Dierctory Certificate Services Explication -->

• Abusing ADCS Attacks (ADMinions) -->

• Abusing ACS Attacks (The Hacker Recipes) -->

AS-REP Roast Attack

Sí disponemos de un listado de usuarios válidos, realizar AS-REP Roast Attack para conseguir un Ticket Granting Ticket (TGT) y luego crackear su hash para obtener su contraseña.

Este ataque hace una consulta al DC si alguno de los usuarios que disponemos en el listado, tiene la flag de (DONT_REQ_PREAUTH) de Kerberos.

El ataque se puede intentar más veces si a lo largo encontramos más usuarios válidos. Desde BloodHound podemos ver los usuarios que tengan esta condición.

Kerberoasting Attack

Si disponemos de credenciales válidas de un usuario del dominio, podemos efectuar un Kerberoasting Attack para conseguir un Ticket Granting Service (TGS) de un usuario que tenga asignado un servicePrincipalName (SPN).

Este hash obtenido, podemos intentar crackearlo para obtener sus credenciales en texto plano.

En este caso, el usuario llamado usuarioASREP es susceptible a un AS-REP Roast, es decir, dispone de la flag (DONT_REQ_PREAUTH) de Kerberos habilitada.

Por lo tanto, podemos efectuar un Kerberoasting Attack sin disponer de credenciales válidas del dominio, pero teniendo un usuario que sea susceptible a AS-REP Roast.

Para más información, se puede consultar el siguiente blog en el cual explican el descubrimiento de este método.

Introducción

Una herramienta para realizar una fuerza bruta rápida y enumerar cuentas válidas de Active Directory a través de la autenticación previa Kerberos.

Instalación y guía de uso

Clonar repositorio de GitHub.

Guía detallada a través del siguiente blog.

Users Enumeration

Password Spraying and Brute Force

AS-REP Roast (GetNPUsers)

# AS-REP Roasting a través de un listado de usuarios en 'users.txt'
impacket-GetNPUsers -no-pass -usersfile users.txt dominio.htb/ 2>/dev/null

# AS-REP Roasting para un usuario en concreto
impacket-GetNPUsers dominio.htb/usuer -no-pass 2>/dev/null

Kerberoasting Attack (GetUserSPNs)

Obtaining Ticket Granting Ticket [TGT] (getTGT)

Resource Based Constrained Delegation [RBCD] (getST)

ldapsearch es una herramienta de línea de comandos utilizada para realizar búsquedas en un servidor LDAP. Sirve para consultar información almacenada, como usuarios, grupos, correos electrónicos o cualquier otro dato que administre el directorio.

Authentication

# Autenticación básica
ldapsearch -H ldap://10.10.10.10 -D 'user@domain.htb' -w 'password' 

# Autenticación mediante Kerberos (hay que exportar antes el TGT en el KRB5CCNAME)
ldapsearch -H ldap://dc.domain.htb -Y GSSAPI

Enumerating LDAP with ldapsearch

# Identificación del nombre de dominio

# Enumerar LDAP en busca de contenido que contenga "pwd|password"

# Enumerar objetos en LDAP sobre aquellos objetos que tengan datos en el campo "info"

# Leer LAPS Password

# Enumerar usuarios que comiencen por "m.lov"

# Enumerar usuarios que contengan las palabras "lov"

# Enumerar usuarios que acaben por "god"

# Enumerar usuarios a través de LDAP

# Enumerar usuarios del AD y mostrar a que grupo forman parte

# Enumerar equipos del AD con toda su información

# Enumerar miembros del grupo 'Moderators' de ejemplo

# Enumerar campos importantes sobre el usuario llamado 'user'

Introduction

PowerView.py es una alternativa al fantástico script original PowerView.ps1. La mayoría de los módulos utilizados en PowerView están disponibles aquí (algunos de los indicadores han cambiado). El objetivo principal es lograr una sesión interactiva sin tener que autenticarse repetidamente en LDAP.

Introduction

Esta herramienta puede realizar llamadas LDAP específicas a un controlador de dominio para realizar escalada de privilegios en AD.

En Kali Linux la herramienta se puede instalar simplemente a través del siguiente comando.

Introduction

El proceso LSASS (Local Security Authority Subsystem Service) se encarga de gestionar la autenticación y las políticas de seguridad en Windows. Al hacer un dump de este proceso, es posible extraer credenciales como hashes de contraseñas, tickets Kerberos o contraseñas en texto claro. Esto lo convierte en un objetivo crítico durante actividades de post-explotación. Herramientas como Mimikatz o pypykatz permiten analizar y extraer esta información de los archivos de volcado.

Introduction

El grupo DnsAdmins en Windows permite gestionar el servicio DNS en controladores de dominio. Sin embargo, los usuarios de este grupo pueden cargar y ejecutar una DLL personalizada con privilegios elevados a través de funciones del servicio DNS. Esto lo convierte en un método viable para la escalación de privilegios en entornos de Active Directory.

Formando parte de este grupo, podemos enumerar objetos eliminados del Active Directory, en este caso, usuarios. En algunos casos, es posible que existan usuarios temporales que hayan sido creados para pruebas y tengan algún campo que nos pueda interesar.

PoC - HTB Cascade

Una vez que tenemos acceso a una máquina Windows (por RDP o CLI), es buena idea buscar credenciales. Esto se llama Credential Hunting y consiste en revisar el sistema en busca de contraseñas guardadas en archivos, aplicaciones o configuraciones.

En este caso, accedimos al equipo de un administrador de IT con Windows 10, así que hay alta probabilidad de encontrar credenciales valiosas.

Windows y muchas apps tienen funciones de búsqueda integradas, así que podemos aprovechar eso para buscar términos como:

SeImpersonatePrivilege

El privilegio SeImpersonatePrivilege permite a un usuario ejecutar programas en nombre de otro, es decir, impersonar a un cliente. Fue introducido en Windows 2000 SP4 y está asignado a miembros del grupo de administradores locales, cuentas de servicio local y otros servicios específicos (como COM y RPC). Su propósito es evitar que servidores no autorizados impersonen a los clientes que se conectan a ellos. Este privilegio puede ser explotado para ganar control o ejecutar acciones con los permisos de un usuario más privilegiado.