Kerberos, DNS, LDAP, MSRPC

Aunque los sistemas operativos Windows utilizan una variedad de protocolos para comunicarse, Active Directory requiere específicamente Lightweight Directory Access Protocol (LDAP), la versión de Microsoft de Kerberos, DNS para autenticación y comunicación, y MSRPC, que es la implementación de Microsoft de Remote Procedure Call (RPC), una técnica de comunicación entre procesos utilizada para aplicaciones basadas en el modelo cliente-servidor.

Kerberos

Kerberos ha sido el protocolo de autenticación predeterminado para cuentas de dominio desde Windows 2000. Kerberos es un estándar abierto y permite la interoperabilidad con otros sistemas que usan el mismo estándar. Cuando un usuario inicia sesión en su PC, Kerberos se utiliza para autenticarlo mediante autenticación mutua, donde tanto el usuario como el servidor verifican su identidad. Kerberos es un protocolo de autenticación sin estado basado en tickets en lugar de transmitir contraseñas de usuario a través de la red. Como parte de Active Directory Domain Services (AD DS), los Domain Controllers tienen un Kerberos Key Distribution Center (KDC) que emite tickets. Cuando un usuario inicia una solicitud de inicio de sesión en un sistema, el cliente que está utilizando para autenticarse solicita un ticket al KDC, cifrando la solicitud con la contraseña del usuario. Si el KDC puede descifrar la solicitud (AS-REQ) utilizando la contraseña del usuario, creará un Ticket Granting Ticket (TGT) y lo transmitirá al usuario. Luego, el usuario presenta su TGT a un Domain Controller para solicitar un Ticket Granting Service (TGS) ticket, que se cifra con el hash de la contraseña NTLM del servicio asociado. Finalmente, el cliente solicita acceso al servicio requerido presentando el TGS a la aplicación o servicio, que lo descifra con su hash de contraseña. Si todo el proceso se completa correctamente, se permitirá al usuario acceder al servicio o aplicación solicitados.

La autenticación Kerberos desacopla de manera efectiva las credenciales de los usuarios de sus solicitudes a recursos consumibles, asegurando que su contraseña no se transmita a través de la red (por ejemplo, al acceder a un sitio de intranet interno de SharePoint). El Kerberos Key Distribution Centre (KDC) no registra transacciones anteriores. En cambio, el Kerberos Ticket Granting Service ticket (TGS) depende de un Ticket Granting Ticket (TGT) válido. Se asume que si el usuario tiene un TGT válido, debe haber demostrado su identidad. El siguiente diagrama ilustra este proceso a alto nivel.

Kerberos Authentication Process


1. El usuario inicia sesión y su contraseña se convierte en un hash NTLM, que se usa para cifrar el TGT ticket. Esto desacopla las credenciales del usuario de las solicitudes a recursos.
2. El servicio KDC en el DC verifica la solicitud de servicio de autenticación (AS-REQ), verifica la información del usuario y crea un Ticket Granting Ticket (TGT), que se entrega al usuario.
3. El usuario presenta el TGT al DC, solicitando un Ticket Granting Service (TGS) ticket para un servicio específico. Esta es la TGS-REQ. Si el TGT se valida correctamente, sus datos se copian para crear un TGS ticket.
4. El TGS se cifra con el hash de la contraseña NTLM del servicio o cuenta de equipo en cuyo contexto se está ejecutando la instancia del servicio y se entrega al usuario en el TGS_REP.
5. El usuario presenta el TGS al servicio y, si es válido, se le permite conectarse al recurso (AP_REQ).

El protocolo Kerberos utiliza el puerto 88 (tanto TCP como UDP). Al enumerar un entorno de Active Directory, a menudo podemos localizar Domain Controllers realizando escaneos de puertos en busca del puerto 88 abierto utilizando una herramienta como Nmap.

DNS

Active Directory Domain Services (AD DS) utiliza DNS para permitir que los clientes (workstations, servers, y otros sistemas que se comunican con el dominio) localicen Domain Controllers y para que los Domain Controllers que alojan el servicio de directorio se comuniquen entre sí. DNS se utiliza para resolver nombres de host en direcciones IP y se usa ampliamente en redes internas y en internet. Las redes internas privadas utilizan namespaces de DNS de Active Directory para facilitar las comunicaciones entre servers, clientes y peers. AD mantiene una base de datos de servicios que se ejecutan en la red en forma de service records (SRV). Estos service records permiten a los clientes en un entorno de AD localizar los servicios que necesitan, como un file server, impresora o Domain Controller. Dynamic DNS se utiliza para realizar cambios en la base de datos de DNS automáticamente si cambia la dirección IP de un sistema. Hacer estas entradas manualmente sería muy laborioso y dejaría margen para errores. Si la base de datos de DNS no tiene la dirección IP correcta para un host, los clientes no podrán localizarlo y comunicarse con él en la red. Cuando un cliente se une a la red, localiza el Domain Controller enviando una consulta al servicio DNS, recuperando un SRV record de la base de datos de DNS y transmitiendo el hostname del Domain Controller al cliente. Luego, el cliente utiliza este hostname para obtener la dirección IP del Domain Controller. DNS utiliza los puertos TCP y UDP 53. El puerto UDP 53 es el predeterminado, pero se recurre al TCP cuando ya no se puede comunicar y los mensajes de DNS son más grandes que 512 bytes.

Forward DNS Lookup

Veamos un ejemplo. Podemos realizar un nslookup para el nombre de dominio y recuperar todas las direcciones IP de los Domain Controllers en un dominio.

PS C:\htb> nslookup INLANEFREIGHT.LOCAL

Server:  172.16.6.5
Address:  172.16.6.5

Name:    INLANEFREIGHT.LOCAL
Address:  172.16.6.5

Reverse DNS Lookup

Si quisiéramos obtener el nombre DNS de un solo host utilizando la dirección IP, podemos hacerlo de la siguiente manera:

PS C:\htb> nslookup 172.16.6.5

Server:  172.16.6.5
Address:  172.16.6.5

Name:    ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL
Address:  172.16.6.5

Finding IP Address of a Host

Si quisiéramos encontrar la dirección IP de un solo host, podemos hacerlo a la inversa. Podemos hacerlo con o sin especificar el FQDN.

PS C:\htb> nslookup ACADEMY-EA-DC01

Server:   172.16.6.5
Address:  172.16.6.5

Name:    ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL
Address:  172.16.6.5

Para profundizar más en DNS, consulta el módulo DNS Enumeration Using Python y la sección DNS del módulo Information Gathering - Web Edition.

LDAP

Active Directory es compatible con Lightweight Directory Access Protocol (LDAP) para consultas de directorios. LDAP es un protocolo de código abierto y multiplataforma utilizado para la autenticación en varios servicios de directorio (como AD). La última especificación de LDAP es Version 3, publicada como RFC 4511. Es fundamental para atacantes y defensores tener un firme entendimiento de cómo funciona LDAP en un entorno de AD. LDAP utiliza el puerto 389, y LDAP sobre SSL (LDAPS) se comunica a través del puerto 636.

AD almacena información de cuentas de usuario e información de seguridad como contraseñas y facilita el intercambio de esta información con otros dispositivos en la red. LDAP es el lenguaje que utilizan las aplicaciones para comunicarse con otros servers que proporcionan servicios de directorio. En otras palabras, LDAP es la forma en que los sistemas en el entorno de la red pueden "hablar" con AD.

Una sesión de LDAP comienza primero conectándose a un LDAP server, también conocido como Directory System Agent. El Domain Controller en AD escucha activamente las solicitudes LDAP, como solicitudes de autenticación de seguridad.

La relación entre AD y LDAP se puede comparar con Apache y HTTP. De la misma manera que Apache es un web server que utiliza el protocolo HTTP, Active Directory es un directory server que utiliza el protocolo LDAP.

Aunque es poco común, es posible que te encuentres con organizaciones al realizar una evaluación que no tienen AD pero están usando LDAP, lo que significa que probablemente estén utilizando otro tipo de LDAP server, como OpenLDAP.

AD LDAP Authentication

LDAP está configurado para autenticar credenciales contra AD utilizando una operación "BIND" para establecer el estado de autenticación para una sesión LDAP. Existen dos tipos de autenticación LDAP.

Simple Authentication: Esto incluye autenticación anónima, autenticación no autenticada y autenticación de nombre de usuario/contraseña. La autenticación simple significa que un username y password crean una solicitud BIND para autenticarse en el LDAP server.
SASL Authentication: El Simple Authentication and Security Layer (SASL) utiliza otros servicios de autenticación, como Kerberos, para vincularse al LDAP server y luego utiliza este servicio de autenticación (Kerberos en este ejemplo) para autenticarse en LDAP. El LDAP server utiliza el protocolo LDAP para enviar un mensaje LDAP al servicio de autorización, que inicia una serie de mensajes de desafío/respuesta que resultan en una autenticación exitosa o fallida. SASL puede proporcionar seguridad adicional debido a la separación de los métodos de autenticación de los protocolos de la aplicación.

Los mensajes de autenticación LDAP se envían en texto claro de forma predeterminada, por lo que cualquier persona puede interceptar los mensajes LDAP en la red interna. Se recomienda utilizar cifrado TLS o similar para proteger esta información en tránsito.

MSRPC

Como se mencionó anteriormente, MSRPC es la implementación de Microsoft de Remote Procedure Call (RPC), una técnica de comunicación entre procesos utilizada para aplicaciones basadas en el modelo cliente-servidor. Los sistemas Windows utilizan MSRPC para acceder a sistemas en Active Directory utilizando cuatro interfaces clave de RPC.

Interface Name	Description
`lsarpc`	Un conjunto de llamadas RPC al Local Security Authority (LSA) que gestiona la política de seguridad local en un equipo, controla la política de auditoría y proporciona servicios de autenticación interactiva. LSARPC se utiliza para realizar la gestión de políticas de seguridad de dominio.
`netlogon`	Netlogon es un proceso de Windows utilizado para autenticar usuarios y otros servicios en el entorno del dominio. Es un servicio que se ejecuta continuamente en segundo plano.
`samr`	Remote SAM (samr) proporciona funcionalidad de gestión para la base de datos de cuentas de dominio, almacenando información sobre usuarios y grupos. Los administradores de IT utilizan el protocolo para gestionar usuarios, grupos y equipos, permitiendo a los administradores crear, leer, actualizar y eliminar información sobre principios de seguridad. Los atacantes (y pentesters) pueden utilizar el protocolo samr para realizar reconocimiento sobre el dominio interno utilizando herramientas como BloodHound para mapear visualmente la red AD y crear "caminos de ataque" para ilustrar visualmente cómo se podría lograr el acceso administrativo o el compromiso total del dominio. Las organizaciones pueden protegerse contra este tipo de reconocimiento cambiando una clave del registro de Windows para permitir solo a los administradores realizar consultas remotas de SAM, ya que, por defecto, todos los usuarios autenticados en el dominio pueden realizar estas consultas para recopilar una cantidad considerable de información sobre el dominio de AD.
`drsuapi`	drsuapi es la API de Microsoft que implementa el Directory Replication Service (DRS) Remote Protocol, que se utiliza para realizar tareas relacionadas con la replicación entre Domain Controllers en un entorno multi-DC. Los atacantes pueden utilizar drsuapi para crear una copia de la base de datos del dominio de Active Directory (NTDS.dit) para recuperar los hashes de contraseña de todas las cuentas en el dominio, que luego pueden utilizarse para realizar ataques Pass-the-Hash para acceder a más sistemas o descifrarse sin conexión utilizando una herramienta como Hashcat para obtener la contraseña en texto claro y así iniciar sesión en sistemas utilizando protocolos de gestión remota como Remote Desktop (RDP) y WinRM.