Attacking Active Directory & NTDS.dit
Last updated
Last updated
Active Directory (AD) es un servicio de directorio común y crítico en las redes empresariales modernas. Dado que el AD es algo que encontraremos repetidamente, es importante familiarizarnos con varios métodos que podemos utilizar para atacar y defender estos entornos de AD. Se puede concluir que si una organización utiliza Windows, entonces AD se usa para gestionar esos sistemas Windows. Atacar AD es un tema tan extenso y significativo que tenemos múltiples módulos que cubren AD.
En esta sección, nos centraremos principalmente en cómo podemos extraer credenciales mediante el uso de un ataque de diccionario contra cuentas de AD y el volcado de hashes desde el archivo NTDS.dit.
Como muchos de los ataques que hemos cubierto hasta ahora, nuestro objetivo debe ser alcanzable a través de la red. Esto significa que es muy probable que necesitemos tener un punto de apoyo establecido en la red interna a la que está conectado el objetivo. Dicho esto, hay situaciones en las que una organización puede estar utilizando el reenvío de puertos para redirigir el protocolo de escritorio remoto (3389) u otros protocolos utilizados para el acceso remoto en su enrutador de borde a un sistema en su red interna. Ten en cuenta que la mayoría de los métodos cubiertos en este módulo simulan los pasos después de un compromiso inicial, y se establece un punto de apoyo en una red interna. Antes de poner manos a la obra con los métodos de ataque, consideremos el proceso de autenticación una vez que un sistema Windows se ha unido al dominio. Este enfoque nos ayudará a comprender mejor la importancia de Active Directory y los ataques de contraseña a los que puede ser susceptible.
Una vez que un sistema Windows se une a un dominio, ya no hará referencia de forma predeterminada a la base de datos SAM para validar las solicitudes de inicio de sesión. Ese sistema unido al dominio enviará ahora todas las solicitudes de autenticación para ser validadas por el controlador de dominio antes de permitir que un usuario inicie sesión. Esto no significa que la base de datos SAM ya no se pueda utilizar. Alguien que busque iniciar sesión utilizando una cuenta local en la base de datos SAM aún puede hacerlo especificando el nombre de host del dispositivo seguido del nombre de usuario (Ejemplo: WS01/nameofuser) o accediendo directamente al dispositivo y escribiendo ./ en la interfaz de inicio de sesión en el campo de nombre de usuario. Esto es digno de consideración porque necesitamos ser conscientes de qué componentes del sistema se ven afectados por los ataques que realizamos. También puede darnos avenidas adicionales de ataque a considerar al dirigirnos a sistemas operativos de escritorio de Windows o sistemas operativos de servidor de Windows con acceso físico directo o a través de una red. Ten en cuenta que también podemos estudiar ataques a NTDS manteniendo un seguimiento de esta técnica.
Recuerda que un ataque de diccionario es esencialmente utilizar el poder de una computadora para adivinar un nombre de usuario y/o contraseña utilizando una lista personalizada de posibles nombres de usuario y contraseñas. Puede ser bastante ruidoso (fácil de detectar) realizar estos ataques a través de una red porque pueden generar mucho tráfico de red y alertas en el sistema objetivo, además de que eventualmente pueden ser denegados debido a restricciones en los intentos de inicio de sesión que pueden aplicarse mediante el uso de Políticas de Grupo.
Cuando nos encontramos en un escenario donde un ataque de diccionario es un próximo paso viable, podemos beneficiarnos al intentar personalizar nuestro ataque tanto como sea posible. En este caso, podemos considerar la organización con la que estamos trabajando para realizar la evaluación y usar búsquedas en varios sitios de redes sociales y buscar un directorio de empleados en el sitio web de la empresa. Hacer esto puede resultar en obtener los nombres de los empleados que trabajan en la organización. Uno de los primeros pasos que tomará un nuevo empleado es obtener un nombre de usuario. Muchas organizaciones siguen una convención de nomenclatura al crear nombres de usuario para empleados. Aquí hay algunas convenciones comunes a considerar:
primerinicialapellido
jdoe
primerinicialsegundoapellidoapellido
jjdoe
primerapellido
janedoe
primerapellido.segundoapellido
jane.doe
segundoapellido.primerapellido
doe.jane
apodo
doedoehacksstuff
A menudo, la estructura de una dirección de correo electrónico nos dará el nombre de usuario del empleado (estructura: username@domain). Por ejemplo, a partir de la dirección de correo electrónico jdoe@inlanefreight.com, vemos que jdoe es el nombre de usuario.
Un consejo de MrB3n: A menudo podemos encontrar la estructura del correo electrónico buscando el nombre de dominio en Google, es decir, “@inlanefreight.com” y obtener algunos correos válidos. A partir de ahí, podemos usar un script para raspar varios sitios de redes sociales y combinar posibles nombres de usuario válidos. Algunas organizaciones intentan ofuscar sus nombres de usuario para prevenir ataques de pulverización, por lo que pueden aliasar su nombre de usuario como
a907(o algo similar) de regreso ajoe.smith. De esa manera, los mensajes de correo electrónico pueden pasar, pero el nombre de usuario interno real no se divulga, lo que hace que la pulverización de contraseñas sea más difícil. A veces puedes usar google dorks para buscar “inlanefreight.com filetype:pdf” y encontrar algunos nombres de usuario válidos en las propiedades del PDF si fueron generados con un editor gráfico. Desde allí, es posible que puedas discernir la estructura del nombre de usuario y potencialmente escribir un pequeño script para crear muchas combinaciones posibles y luego pulverizar para ver si alguna regresa válida.
Supongamos que hemos realizado nuestra investigación y hemos reunido una lista de nombres basada en información disponible públicamente. Mantendremos la lista relativamente corta por el bien de esta lección, ya que las organizaciones pueden tener un gran número de empleados. Ejemplo de lista de nombres:
Ben Williamson
Bob Burgerstien
Jim Stevenson
Jill Johnson
Jane Doe
Podemos crear una lista personalizada en nuestro host de ataque usando los nombres anteriores. Podemos usar un editor de texto basado en línea de comandos como Vim o un editor de texto gráfico para crear nuestra lista. Nuestra lista podría verse algo así:
Por supuesto, este es solo un ejemplo y no incluye todos los nombres, pero observa cómo podemos incluir diferentes convenciones de nombres para cada nombre si no sabemos ya cuál es la convención utilizada por la organización objetivo.
Podemos crear nuestras listas manualmente o utilizar un generador de listas automatizado, como la herramienta basada en Ruby Username Anarchy, para convertir una lista de nombres reales en formatos comunes de nombres de usuario. Una vez que la herramienta ha sido clonada en nuestro host de ataque local usando Git, podemos ejecutarla contra una lista de nombres reales, como se muestra en el ejemplo de salida a continuación:
Usar herramientas automatizadas puede ahorrarnos tiempo al crear listas. Sin embargo, nos beneficiará dedicar tanto tiempo como sea posible a intentar descubrir la convención de nombres que está utilizando una organización, ya que esto reducirá la necesidad de adivinar la convención de nombres.
Es ideal limitar tanto como sea posible la necesidad de adivinar al llevar a cabo ataques de contraseñas.
Una vez que tengamos nuestras listas preparadas o descubramos la convención de nombres y algunos nombres de empleados, podemos lanzar nuestro ataque contra el controlador de dominio objetivo utilizando una herramienta como CrackMapExec. Podemos usarla junto con el protocolo SMB para enviar solicitudes de inicio de sesión al controlador de dominio objetivo. Aquí está el comando para hacerlo:
En este ejemplo, CrackMapExec está utilizando SMB para intentar iniciar sesión como usuario (-u) bwilliamson utilizando una lista de contraseñas (-p) que contiene una lista de contraseñas comúnmente utilizadas (/usr/share/wordlists/fasttrack.txt). Si los administradores configuraron una política de bloqueo de cuenta, este ataque podría bloquear la cuenta que estamos atacando. En el momento de esta escritura (enero de 2022), una política de bloqueo de cuenta no se aplica de forma predeterminada con las políticas de grupo predeterminadas que se aplican a un dominio de Windows, lo que significa que es posible que encontremos entornos vulnerables a este ataque que estamos practicando.
Puede ser útil saber qué podría haberse dejado atrás después de un ataque. Conocer esto puede hacer que nuestras recomendaciones de remediación sean más impactantes y valiosas para el cliente con el que estamos trabajando. En cualquier sistema operativo Windows, un administrador puede navegar al Visor de eventos y ver los eventos de seguridad para ver las acciones exactas que se registraron. Esto puede informar decisiones para implementar controles de seguridad más estrictos y ayudar en cualquier posible investigación que pueda estar involucrada después de una violación.
Una vez que hayamos descubierto algunas credenciales, podríamos proceder a intentar obtener acceso remoto al controlador de dominio objetivo y capturar el archivo NTDS.dit.
Los Servicios de Directorio NT (NTDS) son el servicio de directorio utilizado con Active Directory (AD) para encontrar y organizar recursos de red. Recuerda que el archivo NTDS.dit se almacena en %systemroot%/ntds en los controladores de dominio en un bosque. La extensión .dit significa "árbol de información del directorio". Este es el archivo de base de datos principal asociado con AD y almacena todos los nombres de usuario del dominio, hashes de contraseñas y otra información crítica del esquema. Si este archivo puede ser capturado, podríamos comprometer potencialmente cada cuenta en el dominio, de manera similar a la técnica que cubrimos en la sección Atacando SAM de este módulo. Al practicar esta técnica, considera la importancia de proteger AD y reflexiona sobre algunas formas de evitar que este ataque ocurra.
Podemos conectarnos a un DC (Controlador de Dominio) objetivo usando las credenciales que capturamos.
Evil-WinRM se conecta a un objetivo utilizando el servicio de Windows Remote Management combinado con el Protocolo de Remoting de PowerShell para establecer una sesión de PowerShell con el objetivo.
Una vez conectados, podemos verificar qué privilegios tiene bwilliamson. Podemos empezar por ver la membresía de grupos locales usando el comando:
Access Control Assistance Operators
Account Operators
Administrators
Allowed RODC Password Replication Group
Backup Operators
Cert Publishers
Certificate Service DCOM Access
Cryptographic Operators
Denied RODC Password Replication Group
Distributed COM Users
DnsAdmins
Event Log Readers
Guests
Hyper-V Administrators
IIS_IUSRS
Incoming Forest Trust Builders
Network Configuration Operators
Performance Log Users
Performance Monitor Users
Pre-Windows 2000 Compatible Access
Print Operators
RAS and IAS Servers
RDS Endpoint Servers
RDS Management Servers
RDS Remote Access Servers
Remote Desktop Users
Remote Management Users
Replicator
Server Operators
Storage Replica Administrators
Terminal Server License Servers
Users
Windows Authorization Access Group
El comando se completó con éxito.
Estamos buscando ver si la cuenta tiene derechos de administrador local. Para hacer una copia del archivo NTDS.dit, necesitamos derechos de administrador local (grupo de Administradores) o de administrador de dominio (grupo de Administradores de Dominio) (o equivalente). También queremos verificar qué privilegios de dominio tenemos.
User name: bwilliamson Full Name: Ben Williamson Comment: User's comment: Country/region code: 000 (System Default) Account active: Yes Account expires: Never
Password last set: 1/13/2022 12:48:58 PM Password expires: Never Password changeable: 1/14/2022 12:48:58 PM Password required: Yes User may change password: Yes
Workstations allowed: All Logon script: User profile: Home directory: Last logon: 1/14/2022 2:07:49 PM
Logon hours allowed: All
Local Group Memberships: Global Group memberships: Domain Users Domain Admins
El comando se completó con éxito.
Esta cuenta tiene derechos de Administradores y Administradores de Dominio, lo que significa que podemos hacer casi cualquier cosa que queramos, incluida la creación de una copia del archivo NTDS.dit.
Podemos usar vssadmin para crear una Copia de Sombra de Volumen (VSS) del disco C: o de cualquier volumen que el administrador eligió al instalar AD inicialmente. Es muy probable que NTDS se almacene en C:, ya que esa es la ubicación predeterminada seleccionada durante la instalación, pero es posible cambiar la ubicación. Usamos VSS para esto porque está diseñado para hacer copias de volúmenes que pueden ser leídos y escritos activamente sin necesidad de apagar una aplicación o sistema en particular. VSS es utilizado por muchos programas de respaldo y recuperación de desastres para realizar operaciones.
Luego podemos copiar el archivo NTDS.dit desde la copia de sombra del volumen C: a otra ubicación en el disco para prepararlo para mover NTDS.dit a nuestro host de ataque.
Antes de copiar NTDS.dit a nuestro host de ataque, es posible que queramos usar la técnica que aprendimos anteriormente para crear un recurso compartido de SMB en nuestro host de ataque. No dudes en volver a la sección Atacando SAM para revisar ese método si es necesario.
Los Servicios de Directorio de NT (NTDS) son el servicio de directorio utilizado con AD para encontrar y organizar recursos de red. Recordemos que el archivo NTDS.dit se almacena en %systemroot%/ntds en los controladores de dominio en un bosque. La extensión .dit significa árbol de información de directorio. Este es el archivo de base de datos principal asociado con AD y almacena todos los nombres de usuario de dominio, hashes de contraseñas y otra información crítica del esquema. Si se puede capturar este archivo, podríamos comprometer potencialmente cada cuenta en el dominio de manera similar a la técnica que cubrimos en la sección Atacando SAM de este módulo. Al practicar esta técnica, considera la importancia de proteger AD y piensa en algunas formas de detener este ataque.
Podemos conectarnos a un DC objetivo utilizando las credenciales que capturamos.
Evil-WinRM se conecta a un objetivo utilizando el servicio de administración remota de Windows combinado con el protocolo de remotos de PowerShell para establecer una sesión de PowerShell con el objetivo.
Una vez conectados, podemos verificar qué privilegios tiene bwilliamson. Podemos comenzar mirando la membresía del grupo local utilizando el comando:
Aliases para \DC01
El comando se completó con éxito. Estamos buscando ver si la cuenta tiene derechos de administrador local. Para hacer una copia del archivo NTDS.dit, necesitamos derechos de administrador local (grupo Administradores) o de Administrador de Dominio (grupo Administradores de Dominio) (o equivalente). También querremos comprobar qué privilegios de dominio tenemos.
Información del usuario:
El comando se completó con éxito. Esta cuenta tiene derechos tanto de Administradores como de Administrador de Dominio, lo que significa que podemos hacer casi cualquier cosa que queramos, incluyendo hacer una copia del archivo NTDS.dit.
Podemos usar vssadmin para crear una copia de volumen sombra (VSS) del disco C: o cualquier volumen que el administrador haya elegido al instalar inicialmente AD. Es muy probable que NTDS se almacene en C:, ya que esa es la ubicación predeterminada seleccionada durante la instalación, pero es posible cambiar la ubicación. Usamos VSS para esto porque está diseñado para hacer copias de volúmenes que pueden ser leídos y escritos activamente sin necesidad de detener una aplicación o sistema particular. VSS es utilizado por muchos softwares diferentes de copia de seguridad y recuperación de desastres para realizar operaciones.
Salida de VSS
Podemos luego copiar el archivo NTDS.dit desde la copia de sombra del volumen C: a otra ubicación en el disco para prepararnos para mover NTDS.dit a nuestro host de ataque.
Antes de copiar NTDS.dit a nuestro host de ataque, podríamos querer usar la técnica que aprendimos anteriormente para crear un recurso compartido SMB en nuestro host de ataque. Siéntete libre de volver a la sección Atacando SAM para revisar ese método si es necesario.
Ahora se puede usar cmd.exe /c move para mover el archivo desde el DC objetivo a la carpeta compartida en nuestro host de ataque.
Alternativamente, podemos beneficiarnos de usar CrackMapExec para llevar a cabo los mismos pasos mostrados anteriormente, todo con un solo comando. Este comando nos permite utilizar VSS para capturar y volcar rápidamente el contenido del archivo NTDS.dit convenientemente dentro de nuestra sesión de terminal.
Podemos proceder creando un archivo de texto que contenga todos los hashes de NT, o podemos copiar y pegar individualmente un hash específico en una sesión de terminal y usar Hashcat para intentar romper el hash y obtener una contraseña en texto claro.
En muchas de las técnicas que hemos cubierto hasta ahora, hemos tenido éxito al romper hashes que hemos obtenido.
Aún podemos usar hashes para intentar autenticar a un sistema utilizando un tipo de ataque llamado Pass-the-Hash (PtH). Un ataque PtH aprovecha el protocolo de autenticación NTLM para autenticar a un usuario usando un hash de contraseña. En lugar de usar el formato nombre de usuario en texto claro para el inicio de sesión, podemos usar nombre de usuario de contraseña. Aquí hay un ejemplo de cómo funcionaría esto:
Podemos intentar utilizar este ataque cuando necesitemos movernos lateralmente a través de una red después de haber comprometido un objetivo inicial. Más sobre PtH se cubrirá en el módulo de Enumeración de AD y Ataques.
