Bloquear la coerción de autenticación en los DC

La coerción de autenticación es el paso que convierte una cuenta de dominio con pocos privilegios en el compromiso del dominio sin una sola contraseña. El atacante invoca un método RPC en un controlador de dominio que hace que la cuenta de equipo del DC se autentique ante un host elegido por él. Esa autenticación se retransmite después con NTLM a la inscripción web de AD CS (ESC8) o a LDAP, o se captura como TGT de Kerberos en un host con delegación sin restricciones. La cuenta de equipo de un DC puede hacer DCSync, así que la cadena termina con todos los hashes del dominio.

Los desencadenantes más conocidos son PrinterBug (MS-RPRN), PetitPotam (MS-EFSR), DFSCoerce (MS-DFSNM) y ShadowCoerce (MS-FSRVP). Aparecen variantes nuevas con regularidad, y Microsoft, por lo general, no trata la coerción autenticada como una vulnerabilidad. Esta guía profundiza más que las notas sobre coerción de la línea base del DC. Explica cómo medir la exposición, cortar los desencadenantes mediante servicios y filtros RPC, hacer inútil la autenticación forzada y verificar el resultado.

Por qué la coerción es un problema con dos caras

Toda cadena de coerción tiene un desencadenante (una interfaz RPC del DC que acepta una ruta UNC del llamante) y un destino (un destino de relay o un host con delegación que acepta las credenciales del DC). Si solo corrige una de las dos caras, está apostando a que nadie encuentre el siguiente desencadenante o el siguiente destino. Bastionar ambas es lo que convierte esta clase de ataque en algo anodino:

La cara del destino corresponde a otras guías: firma LDAP y enlace de canal, firma SMB, EPA en la inscripción web de AD CS y eliminación de la delegación sin restricciones. El resto de esta guía trata la cara del desencadenante y los controles específicos del DC que conectan ambas.

Medir: qué está expuesto hoy

Empiece por confirmar qué servicios desencadenantes se ejecutan realmente en cada DC. El Spooler ya debería estar deshabilitado si aplicó la línea base, pero compruébelo de todos modos. El servicio File Server VSS Agent Service solo existe cuando está instalado el servicio de rol FS-VSS-Agent.

$dcs = (Get-ADDomainController -Filter *).HostName
Invoke-Command -ComputerName $dcs -ScriptBlock {
    [PSCustomObject]@{
        DC            = $env:COMPUTERNAME
        Spooler       = (Get-Service Spooler -ErrorAction SilentlyContinue).Status
        FssAgent      = (Get-Service -DisplayName 'File Server VSS Agent Service' -ErrorAction SilentlyContinue).Status
        DfsNamespace  = (Get-Service Dfs -ErrorAction SilentlyContinue).Status
        EfsService    = (Get-Service EFS -ErrorAction SilentlyContinue).Status
        VssAgentRole  = (Get-WindowsFeature FS-VSS-Agent).InstallState
        RpcFilters    = (netsh rpc filter show filter | Select-String 'filterKey').Count
    }
} | Format-Table -AutoSize

Tenga en cuenta que detener el servicio EFS no corrige PetitPotam. La interfaz MS-EFSR también es accesible a través de \pipe\lsarpc, que LSASS atiende tanto si el servicio EFS se ejecuta como si no. Por eso el filtrado RPC es el control recomendado para EFSRPC.

A continuación, revise los destinos. La coerción apunta al DC, pero el relay aterriza en otro sitio. Enumere los hosts que convertirían una autenticación forzada del DC en una victoria para el atacante:

# Equipos (distintos de los DC) de confianza para delegación sin restricciones
Get-ADComputer -Filter { TrustedForDelegation -eq $true -and PrimaryGroupID -ne 516 } |
    Select-Object Name, DNSHostName

# Hosts de CA empresarial: revise cada uno (y cualquier servidor CES/Web Enrollment) como destino de relay HTTP
Get-ADObject -SearchBase ("CN=Enrollment Services,CN=Public Key Services,CN=Services," +
    (Get-ADRootDSE).configurationNamingContext) -Filter * -Properties dNSHostName |
    Select-Object Name, dNSHostName

Auditar: ver los intentos de coerción antes de bloquear

Antes de añadir filtros de bloqueo, ejecute esos mismos filtros en modo de auditoría durante una semana. El motor de filtros RPC de Windows escribe el evento de seguridad 5712 («A Remote Procedure Call (RPC) was attempted») para los filtros con auditoría habilitada, siempre que la subcategoría de auditoría RPC Events esté activada:

auditpol /set /subcategory:"RPC Events" /success:enable /failure:enable

También puede ver el acceso a canalizaciones con nombre en el DC con la auditoría Detailed File Share (evento 5145) y un filtro sobre los nombres de destino relativos efsrpc, lsarpc, spoolss, netdfs y FssagentRpc. Cuidado: todos los miembros del dominio usan lsarpc constantemente. Úselo para correlacionar, no para alertar.

Busque primero lo evidente. Cualquier llamada EFSRPC a un DC desde una estación de trabajo es sospechosa, porque ningún cliente legítimo cifra archivos en un DC. Cualquier llamada MS-DFSNM desde un host que no sea una PAW de Tier 0 debe tener un responsable identificado.

Aplicar: eliminar o filtrar cada desencadenante

Print Spooler

Manténgalo deshabilitado con Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Print Spooler = Disabled en un GPO vinculado a la OU Domain Controllers. Es la única corrección completa para PrinterBug. Filtrar MS-RPRN por RPC es una alternativa para los servidores miembro que deban conservar el Spooler.

File Server VSS Agent (ShadowCoerce)

Un DC no debería alojar este rol. Quítelo:

Uninstall-WindowsFeature -Name FS-VSS-Agent -ComputerName DC01

Filtros RPC para EFSRPC y DFSNM

Los filtros RPC son reglas de Windows Filtering Platform en la capa RPC, identificadas por el UUID de la interfaz. Bloquear por UUID detiene la llamada independientemente de la canalización con nombre o del punto de conexión TCP por el que llegue. La interfaz MS-EFSR se expone bajo dos UUID, c681d488-d850-11d0-8c52-00c04fd90f7e (a través de lsarpc) y df1941c5-fe89-4e79-bf10-463657acf44d (a través de efsrpc), así que bloquee ambos. MS-DFSNM usa 4fc742e0-4a10-11cf-8273-00aa004ae673. Para DFSNM, una regla de permiso limitada a su grupo de Tier 0 es más segura que un bloqueo total, porque los administradores siguen gestionando a través de ella los espacios de nombres basados en dominio.

Guarde la definición de filtros como archivo versionado, por ejemplo dc-rpc-filters.txt:

rpc
filter
add rule layer=um actiontype=block audit=enable
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter
add rule layer=um actiontype=block audit=enable
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
add rule layer=um actiontype=permit audit=enable
add condition field=if_uuid matchtype=equal data=4fc742e0-4a10-11cf-8273-00aa004ae673
add condition field=remote_user_token matchtype=equal data=D:(A;;CC;;;DA)
add filter
add rule layer=um actiontype=block audit=enable
add condition field=if_uuid matchtype=equal data=4fc742e0-4a10-11cf-8273-00aa004ae673
add filter
quit

Aplíquelo y confírmelo:

netsh -f C:\Tier0\dc-rpc-filters.txt
netsh rpc filter show filter

Sustituya DA en el SDDL por el SID de su grupo dedicado de administradores de Tier 0 cuando disponga de uno. No existe un nodo de directiva de grupo para los filtros RPC, así que distribuya el archivo mediante su gestión de configuración de Tier 0 o un script de inicio del DC. Haga que el script sea idempotente: ejecute primero netsh rpc filter delete filter filterkey=all solo si todos los filtros del equipo son suyos.

Eliminar la ruta de red

La coerción necesita que el DC alcance el agente de escucha del atacante por SMB (445) o HTTP (80, o cualquier puerto a través del servicio WebClient). Un DC rara vez tiene un motivo legítimo para iniciar sesiones SMB o HTTP hacia estaciones de trabajo o subredes de servidores de usuario. El bloqueo de esa salida se trata en firewall para controladores de dominio y es uno de los controles anticoerción más eficaces, porque cubre también desencadenantes que nadie ha publicado todavía.

Bastionar los destinos

Considérelos complementos obligatorios, no extras opcionales:

• LDAP: exija firma y enlace de canal en todos los DC.
• SMB: exija la firma en servidores y clientes. Es el comportamiento predeterminado en las compilaciones recientes de Windows 11 y Windows Server 2025, pero verifíquelo en lugar de darlo por hecho.
• AD CS: quite Web Enrollment si no se usa. En caso contrario, imponga HTTPS con Extended Protection for Authentication y deshabilite NTLM en esos sitios de IIS.
• Delegación: ningún equipo que no sea DC debe conservar la delegación sin restricciones. Añada las cuentas de Tier 0 a Protected Users y márquelas como confidenciales para que sus TGT no puedan reenviarse.

Verificar

Compruebe la configuración desde una PAW:

Invoke-Command -ComputerName $dcs -ScriptBlock {
    $f = netsh rpc filter show filter | Out-String
    [PSCustomObject]@{
        DC          = $env:COMPUTERNAME
        Spooler     = (Get-Service Spooler).StartType
        EfsLsarpc   = $f -match 'c681d488-d850-11d0-8c52-00c04fd90f7e'
        EfsEfsrpc   = $f -match 'df1941c5-fe89-4e79-bf10-463657acf44d'
        DfsNm       = $f -match '4fc742e0-4a10-11cf-8273-00aa004ae673'
        VssAgent    = (Get-WindowsFeature FS-VSS-Agent).InstallState
    }
}

Después, pruebe el comportamiento. En un laboratorio o en una ventana aprobada, pida a su red team o a un ejercicio de purple team que lance las herramientas de coerción habituales (por ejemplo, Coercer o las pruebas de concepto individuales) contra un DC con una cuenta de usuario estándar. Confirme tres cosas: ninguna autenticación llega al agente de escucha, el evento 5712 se genera para la interfaz bloqueada y su SIEM lanza una alerta. Pruebe también la regla de permiso de DFSNM: abra la consola DFS Management desde una PAW como administrador de Tier 0 y confirme que la administración de espacios de nombres sigue funcionando.

Repita la comprobación tras cada actualización acumulativa y tras cualquier reconstrucción de un DC. Un DC recién promovido sin el archivo de filtros es la carencia más habitual.

Qué se rompe

• Operaciones EFS remotas en los DC. Nada legítimo debería cifrar archivos en un DC a través de la red. Las herramientas de copia de seguridad o de gestión de archivos que llamen a EFSRPC contra recursos compartidos alojados en DC fallarán. Saque esos recursos compartidos del DC.
• Administración de espacios de nombres DFS desde hosts que no son de administración. Con el filtro DFSNM, solo el SID de la regla de permiso puede gestionar espacios de nombres de forma remota. Los administradores delegados de espacios de nombres que trabajan desde estaciones de trabajo corrientes pierden el acceso hasta que pasen a una PAW o al grupo permitido. Las referencias de SYSVOL y NETLOGON no se ven afectadas, porque los clientes no usan la interfaz de administración.
• Impresión a través de un DC. Cualquier cola que aún se publique desde un DC desaparece al deshabilitar el Spooler.
• Agentes de supervisión o copia de seguridad que extraen datos de los DC por SMB/HTTP en sentido inverso. El filtrado de salida puede afectar a agentes que esperan que el DC se conecte a ellos. Identifíquelos durante la semana de auditoría.
• Cambios futuros en RPC. Los filtros basados en UUID son precisos. Si Microsoft traslada alguna vez funcionalidad a una interfaz nueva, los filtros no la cubrirán, así que mantenga activos los eventos de auditoría.

Lecturas relacionadas: la línea base del DC para el resto de la configuración del controlador de dominio, Frenar el NTLM relay: LDAP, firma SMB y LLMNR para la cara de los destinos de relay, y la entrada de glosario NTLM relay para entender por qué una autenticación forzada es tan valiosa.