MSTech Geeks

Diseñando un laboratorio de Defender for Identity es la mejor forma de comprender realmente cómo funciona la detección avanzada basada en identidad en entornos corporativos.

Active Directory sigue siendo el corazón de la mayoría de organizaciones. Y precisamente por eso, continúa siendo uno de los principales objetivos en ataques avanzados. Técnicas como Pass-the-Hash, Kerberoasting o DCSync no son conceptos teóricos: forman parte del día a día de cualquier incidente serio de seguridad.

En este contexto, Microsoft Defender for Identity se convierte en una pieza clave dentro de la estrategia de protección de identidad. Sin embargo, entender su capacidad real requiere algo más que revisar documentación: es necesario ponerlo a prueba en un entorno controlado.

En este artículo voy a explicar cómo construir un laboratorio realista para simular ataques contra Active Directory, generar telemetría auténtica y analizar cómo el producto detecta comportamientos sospechosos, correlaciona señales y expone el nivel de riesgo de la identidad.

El objetivo no es montar un entorno de demostración básico, sino crear un laboratorio que permita explorar en profundidad las capacidades de detección y entender cómo funciona el modelo de exposición de identidad en escenarios prácticos.

¿Qué es Microsoft Defender for Identity?

Microsoft Defender for Identity (MDI) es una solución de detección y respuesta ante amenazas centrada en la identidad, diseñada para proteger entornos de Active Directory frente a ataques avanzados.

A diferencia de otras soluciones de seguridad que se centran en el endpoint o en el perímetro, Defender for Identity monitoriza directamente el comportamiento relacionado con la autenticación, la autorización y el uso de privilegios dentro del dominio.

El producto se basa en la instalación de sensores en los controladores de dominio, desde donde analiza protocolos como Kerberos, NTLM, LDAP o DNS, así como eventos críticos del directorio. Esta telemetría es enviada al servicio cloud de Microsoft, donde se aplican modelos de análisis y correlación para identificar comportamientos sospechosos.

Su objetivo no es bloquear tráfico en tiempo real como haría un firewall, sino detectar técnicas utilizadas por atacantes una vez han conseguido acceso inicial al entorno.

Entre las amenazas que puede identificar se encuentran:

Estas categorías no representan alertas aisladas, sino fases dentro de una cadena de ataque basada en identidad. Precisamente por eso, el laboratorio que vamos a construir permitirá simular cada una de ellas de forma controlada.

En esencia, Defender for Identity convierte Active Directory en una superficie monitorizada, permitiendo detectar patrones de ataque que tradicionalmente pasaban desapercibidos hasta que el dominio ya estaba comprometido.

Y precisamente por eso resulta especialmente interesante analizarlo en un laboratorio controlado, donde podamos provocar este tipo de técnicas y observar cómo responde.

Defender for Identity dentro de Microsoft 365 Defender

Microsoft Defender for Identity no funciona de manera aislada. Forma parte del ecosistema de Microsoft 365 Defender, la plataforma XDR de Microsoft que correlaciona señales procedentes de múltiples dominios de seguridad.

Dentro de esta suite encontramos soluciones especializadas en distintas superficies de ataque:

• Microsoft Defender for Endpoint → Protección y detección en dispositivos.
• Microsoft Defender for Office 365 → Protección frente a amenazas en correo y colaboración.
• Microsoft Defender for Cloud Apps → Control y visibilidad sobre aplicaciones SaaS.
• Microsoft Defender for Identity → Detección de amenazas basadas en identidad en Active Directory.
• Microsoft Entra ID Protection → Detección de riesgos en identidades cloud.

Defender for Identity aporta la visibilidad sobre el plano de identidad on-premise, algo fundamental en entornos híbridos donde el atacante suele pivotar entre identidad local y cloud.

Arquitectura del entorno del laboratorio

Para analizar correctamente las capacidades de Microsoft Defender for Identity es necesario construir un entorno que reproduzca, de forma controlada, los elementos clave de una infraestructura corporativa basada en Active Directory.

Componentes del laboratorio

El entorno mínimo recomendado estará compuesto por:

Tenant de Microsoft 365 con Defender for Identity habilitado (devomdilab.onmicrosoft.com):

• Licenciamiento Microsoft 365 o Defender for Identity standalone. Recordad que este licenciamiento es por usuario.
• Acceso al portal de Microsoft 365 Defender.
• Permisos adecuados para visualizar alertas y configuraciones.

Controlador de dominio (vm-con-dc01-ne):

• Windows Server (2019 o superior recomendado)
• Rol de Active Directory Domain Services (AD DS) instalado y configurado.
• DNS integrado.
• Sensor de Defender for Identity instalado

Máquina cliente unida al dominio (Admin-PC):

• Windows 10/11
• Unida al dominio
• Usuario estándar y usuario privilegiado
• Esta máquina permitirá simular:
  • Autenticaciones normales.
  • Intentos de elevación de privilegios
  • Uso indebido de credenciales.
  • Movimiento lateral.

Máquina cliente unida al dominio (Victim-PC):

• Windows 10/11
• Unida al dominio
• Usuario estádar y usuario privilegiado
• Aquí se ejecutarán herramientas para simular:
  • Enumeración LDAP
  • Pass-the-Hash
  • Kerberoasting
  • DCSync

Usuarios:

• Jeff Leatherman (JeffL@contoso.local) -> Domain Users
• Samira Abbasi (SamiraA@contoso.local) -> Domain Users & Domain Admin
• Ron HD (RonHD@contoso.local) -> Domain Users & HelpDesks

Básicamente, quedaría algo así:

En mi caso, yo he reproducido todo este laboratorio en Azure:

Instalación del sensor

Una vez desplegado y configurado nuestro laboratorio. Accederemos desde el controlador de dominio a panel de administración de Microsoft Defender (https://security.microsoft.com) con nuestras credenciales de administración:

Desde Settings, accederemos a Identity y desde aquí, en el grupo General accederemos a la opción de Sensors:

Haremos click en «Add Sensors» y descargaremos el sensor en nuestro controlador de dominio (Yo opté por el sensor clásico pero podéis probar la nueva opción de activación de servidores):

Extraeremos el paquete y lo ejecutaremos siguiendo los pasos del asistente de instalación. En algún momento nos pedirá que ingresemos la «Access Key» que el portal nos muestra a la hora de descargar el sensor.

La cuenta gMSA en Defender for Identity

Durante la instalación del sensor de Microsoft Defender for Identity es necesario configurar una cuenta gMSA (Group Managed Service Account).

Pero ¿qué es exactamente y por qué la necesitamos?

Una gMSA es una cuenta de servicio especial de Active Directory cuyo password es gestionado automáticamente por el propio dominio. A diferencia de las cuentas de servicio tradicionales, no requiere que un administrador gestione manualmente la contraseña ni su rotación.

En el contexto de Defender for Identity, la gMSA se utiliza para permitir que el sensor consulte información del directorio y pueda:

• Leer objetos de Active Directory
• Acceder a atributos necesarios para el análisis
• Consultar pertenencias a grupos
• Correlacionar información de autenticación

Es importante entender que esta cuenta no se utiliza para autenticar usuarios, sino para que el sensor pueda enriquecer la telemetría que recoge del controlador de dominio.

¿Por qué usar una gMSA y no una cuenta normal?

• Rotación automática de contraseña.
• No requiere almacenamiento manual de credenciales.
• Reduce el riesgo de exposición de credenciales estáticas.
• Es la práctica recomendada por Microsoft para este escenario.

Desde el punto de vista de seguridad, esto evita introducir una cuenta de servicio con password fijo dentro del laboratorio (o peor aún, en producción).

En algunos blogs, artículos e incluso en la documentación oficial de Microsoft, la creación de la cuenta gMSA suele indicarse después de la configuración de la auditoría en Active Directory.

Sin embargo, en este laboratorio recomiendo crearla en este momento. La razón es sencilla: las versiones más recientes de los scripts de PowerShell utilizados para automatizar la configuración de la auditoría en Active Directory, en determinados escenarios, requieren que esta cuenta se proporcione como parámetro durante la ejecución.

Por tanto, adelantar su creación nos permitirá evitar errores posteriores y mantener un flujo de configuración más ordenado.

Creación de la cuenta gMSA

En primer lugar y en el caso de que no hayamos usado una gMSA con anterioridad en nuestro directorio activo, desde powershell y con permisos de administración, ejecutaremos este paso (uno por bosque) para generar una nueva clave raíz:

Add-KdsRootKey -EffectiveImmediately

Esta clave es necesaria para la generación de la cuenta gMSA y por diseño, no podrá ser usada hasta pasadas 10 horas. En un entorno de pruebas o desarrollo, podéis usar el siguiente truco para no tener que esperar:

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Con el cmdlet: Get-KdsRootKey podeis visualizar el estado de dicha clave:

En segundo lugar, ejecutaremos el siguiente script con permisos de administrador:

Este Script hará lo siguiente:

• Crea la cuenta gMSA
• Crea el grupo para la cuenta gMSA
• Añade las cuentas de máquinas específicas a ese grupo

En mi caso, he modificado dicho script de la siguiente manera, adaptarlo a vuestras necesidades:

# Variables:
# Specify the name of the gMSA you want to create:
$gMSA_AccountName = 'mdiSvc01'
# Specify the name of the group you want to create for the gMSA,
# or enter 'Domain Controllers' to use the built-in group when your environment is a single forest, and will contain only domain controller sensors.
$gMSA_HostsGroupName = 'Domain Controllers'
# Specify the computer accounts that will become members of the gMSA group and have permission to use the gMSA. 
# If you are using the 'Domain Controllers' group in the $gMSA_HostsGroupName variable, then this list is ignored
$gMSA_HostNames = ''

# Import the required PowerShell module:
Import-Module ActiveDirectory

# Set the group
if ($gMSA_HostsGroupName -eq 'Domain Controllers') {
    $gMSA_HostsGroup = Get-ADGroup -Identity 'Domain Controllers'
} else {
    $gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope DomainLocal -PassThru
    $gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } |
        ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }
}

# Create the gMSA:
New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroup 

A continuación, otorgaremos permisos a la cuenta anterior, a través de la creación de un grupo de seguridad. Como en el caso anterior, sustituir las variables a vuestra conveniencia.

# Declare the identity that you want to add read access to the deleted objects container:
$Identity = 'mdiSvc01'

# If the identity is a gMSA, first to create a group and add the gMSA to it:
$groupName = 'mdiUsr01Group'
$groupDescription = 'Members of this group are allowed to read the objects in the Deleted Objects container in AD'
if(Get-ADServiceAccount -Identity $Identity -ErrorAction SilentlyContinue) {
    $groupParams = @{
        Name           = $groupName
        SamAccountName = $groupName
        DisplayName    = $groupName
        GroupCategory  = 'Security'
        GroupScope     = 'Universal'
        Description    = $groupDescription
    }
    $group = New-ADGroup @groupParams -PassThru
    Add-ADGroupMember -Identity $group -Members ('{0}$' -f $Identity)
    $Identity = $group.Name
}

# Get the deleted objects container's distinguished name:
$distinguishedName = ([adsi]'').distinguishedName.Value
$deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName

# Take ownership on the deleted objects container:
$params = @("$deletedObjectsDN", '/takeOwnership')
C:\Windows\System32\dsacls.exe $params

# Grant the 'List Contents' and 'Read Property' permissions to the user or group:
$params = @("$deletedObjectsDN", '/G', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity))
C:\Windows\System32\dsacls.exe $params 

Derechos de la cuenta en la infraestructura AD DS

A continuación, debemos chequear que la cuenta tiene los derechos requeridos como y ejecuta como un servicio local en la máquina, de otra forma, la impersonalización fallará. Para ello editaremos la directiva de grupo: Default Domain Controller Policy

Y añadiremos nuestra cuenta gSMA recien creada:

Forzaremos la actualización de las directivas en el mismo DC y consultaremos que han aplicado:

Configuración de la cuenta gMSA en Defender XDR

Como último paso, solo nos queda indicar en el portal de Defender XDR en la opción Directory services accounts nuestra cuenta gMSA:

Directivas de auditoría en el entorno de Active Directoy

Las directivas de auditoría en los Domain Controllers constituyen la base técnica que permite a las soluciones de seguridad detectar ataques sofisticados contra la identidad, proporcionando la visibilidad necesaria sobre cambios, privilegios y comportamientos anómalos en Active Directory Estas directivas pueden ser configuradas manualmente o bien a través de un proceso automatizado. En nuestro caso, usaremos un juego de scripts de powershell que automatizan y facilitan la tarea.

El módulo de powershell se llama DefenderForIdentity y lo podeis instalar directamente con el cmdlet de Install-Module:

Una vez instalado y para poder recopilar la información de auditoría configurada en el «domain controller», basta con ejecutar la siguiente instrucción:

Iremos ejecutando cada una de las instrucciones mediante los comandos de la tercera columna:

Existen un par de GPOs de configuraciones (Remote SAM y la auditoría avanzada para Entra Connect) que necesitan ser enlazadas manualmente una vez creadas, el resto son implementadas y enlazadas automáticamente sin hacer nada extra.

Una vez enlazadas dichas GPOs y habiendo ejecutado el resto de instrucciones, volvemos a ejecutar el comando que nos devuelve el informe anterior:

Y con esto Laboratorio listo!!

Sensibilidad de las alertas de MDI

En entornos de test y desarrollo y por tanto tratarse de un entorno donde vamos a ejecutar técnicas controladas de ataque, activar el modo test evita la generación de alertas críticas que podrían distorsionar el análisis.

Simulando los primeros ataques

Fase de reconocimiento

La fase de reconocimiento es uno de los primeros pasos que realiza un atacante tras obtener acceso inicial a un entorno. Su objetivo es recopilar información sobre la infraestructura para identificar posibles vectores de movimiento lateral o escalado de privilegios.

En entornos Active Directory, el reconocimiento suele centrarse en:

• Enumerar usuarios y grupos.
• Identificar cuentas privilegiadas.
• Detectar equipos activos en el dominio.
• Analizar sesiones abiertas y conexiones SMB.

Herramientas como netsess permiten consultar sesiones activas en sistemas del dominio y obtener visibilidad sobre qué usuarios están conectados a qué equipos. Esta información es especialmente valiosa para un atacante, ya que puede revelar la presencia de cuentas administrativas conectadas a servidores críticos.

Desde el punto de vista defensivo, este tipo de actividad genera patrones que pueden ser detectados por Microsoft Defender for Identity cuando se producen consultas masivas o comportamientos anómalos de enumeración dentro del dominio.

Conectado a la máquina VICTIM-PC y simulando haberla vulnerado, ejecutaremos el siguiente comando:

A continuación realizaremos un una consulta DNS:

En una fase temprana de reconocimiento, un atacante no necesita herramientas avanzadas. En muchos casos, comienza utilizando comandos básicos disponibles en cualquier sistema Windows. En nuestro laboratorio ejecutaremos los siguientes comandos:

nslookup
server vm-con-dc01-ne
ls -d CONTOSO.LOCAL
exit

El comando ls -d CONTOSO.LOCAL intenta realizar una transferencia de zona DNS (AXFR), que permitiría obtener una copia completa de los registros del dominio; si estuviera mal configurado, expondría la totalidad de la infraestructura interna (hosts, controladores de dominio, servicios y registros críticos), proporcionando al atacante un mapa detallado del entorno y reduciendo significativamente el esfuerzo necesario para planificar movimiento lateral y escalado de privilegios.

Como podemos observar y en nuestro caso, la transferencia de zona está deshabilitada.

Investigar una alerta relacionada con actividades de reconocimiento y decubrimiento

Tras realizar las acciones anteriores, vamos a ingresar en el portal de Defender para analizar y descubrir los ataques anteriores.

En el navegador vamos a https://security.microsoft.com

Nuestra primera alerta de enumeración SMB: