Vulnerabilidad PrimaryGroupID 6604 en Active Directory: diagnóstico y solución completa

Tras un análisis con Tenable, los controladores de dominio muestran la alerta “AD Starter Scan – Primary Group ID Integrity”. En este artículo aprenderás qué significa, cómo localizar los objetos afectados y reparar el atributo, además de aplicar medidas de hardening que previenen futuros hallazgos similares.

Índice

Comprender la vulnerabilidad

El atributo primaryGroupID identifica a qué grupo primario pertenece un objeto de Active Directory. Es especialmente relevante en entornos heredados de Windows NT, pero sigue utilizándose internamente para calcular pertenencias a grupos y permisos cuando solo se dispone del RID (Relative Identifier).

Microsoft asigna valores predefinidos para cada clase de objeto; cualquier desviación puede indicar una mala configuración o, en el peor de los casos, actividad malintencionada que intenta eludir auditorías de pertenencia a grupos estándar.

Valores predeterminados más habituales

Objeto	Grupo primario esperado	primaryGroupID
Usuarios estándares	Domain Users	513
Equipos unidos al dominio	Domain Computers	515
Controladores de dominio	Domain Controllers	516
Administradores incorporados	Administrators	544

La detección de un valor como 6604 no corresponde a ningún grupo integrado y, por tanto, genera el aviso que has visto en Tenable.

Impacto operativo y de seguridad

Pérdida de trazabilidad: herramientas de inventario y correlación de eventos se basan en el valor estándar para mapear usuarios a grupos. Un RID fuera de rango dificulta la interpretación.
Fugas de privilegios: un atacante podría asignar a una cuenta maliciosa un primaryGroupID que coincida con el RID de un grupo privilegiado en otro dominio o bosque y abrir puertas traseras cuando se producen trusts.
Errores de replicación: si el DC no reconoce el grupo, puede producir advertencias de integridad en repadmin y en los registros de servicio NTDS.

Búsqueda de objetos con primaryGroupID atípico

La forma más rápida de identificar las cuentas es a través de PowerShell con el módulo ActiveDirectory, disponible en servidores Windows Server y en máquinas con RSAT.

Import-Module ActiveDirectory
Get-ADObject -LDAPFilter "(primaryGroupID=6604)" `
             -Properties distinguishedName,sAMAccountName `
| Select-Object sAMAccountName,distinguishedName

En entornos que exijan LDAP puro, se puede usar LDP.exe o cualquier cliente de consultas:

(primaryGroupID=6604)

Si el directorio devuelve cero resultados, es posible que el valor haya cambiado entre la generación del reporte y la investigación; de lo contrario, cada DN mostrado representa un objeto a revisar.

Correlación con auditoría

Antes de modificar nada, revisa los eventos 5136 (Directory Service Object Modified) y 4728–4732 según el tipo de objeto: estos indican quién cambió el atributo o lo movió de grupo.

Procedimiento de corrección

La acción adecuada depende de la naturaleza del objeto.

Usuarios finales

Set-ADUser <SamAccountName> -Replace @{primaryGroupID = 513}

Conviene comprobar también que el usuario pertenece al grupo Domain Users; si se había eliminado, añádelo:

Add-ADGroupMember -Identity "Domain Users" -Members <SamAccountName>

Controladores de dominio

Si un DC aparece con un RID anómalo, la recomendación es sacarlo del dominio y promoverlo de nuevo, ya que suplantar la pertenencia de un DC plantea riesgos elevados. Antes de demover, transfiere los FSMO y revisa roles globales de catálogo.

Equipos u objetos de servicio

Si el objeto corresponde a un servidor de aplicaciones, valora si realmente necesita pertenecer a un grupo especial (p.ej., SQLServer2005MSSQLUser$Instance). Normalmente debe ser 515.
Para cuentas administradas (gMSA), primaryGroupID suele ser 516; compara con la documentación oficial.

Verificación post–remediación

Ejecuta de nuevo la consulta LDAP para asegurarte de que no se devuelven resultados.
Forza la replicación intersite:
Repadmin /syncall /AdeP
Vuelve a lanzar el scan de Tenable; si la vulnerabilidad persiste, exporta el raw scan data para comprobar si apunta a otro objeto.
Analiza los registros de eventos entre la corrección y la replicación para detectar errores 1388 o 1988.

Medidas de refuerzo recomendadas

Aplicación de parches y actualizaciones

Mantén todos los controladores de dominio con la última Cumulative Update y, cuando proceda, unifica el nivel funcional del bosque. Las actualizaciones corrigen fallos de replicación que podrían generar atributos corruptos.

Seguridad en las comunicaciones

Obliga a usar LDAPS y firma/encapsulado LDAP (LDAP Signing and Channel Binding).
Deshabilita NTLMv1 y restringe NTLMv2 solo a los hosts que lo requieran.
Revisa las GPO que habilitan SMB v1 y quítalas.

Modelo de mínimos privilegios

Aplica la guía PAW separando el acceso de administración del acceso de productividad:

Administra AD desde estaciones blindadas sin correo ni navegación.
Implementa MFA en grupos administrativos.
Aplica “Just‑Enough‑Administration” en PowerShell remoting.

Segmentación de red

Solo los puertos necesarios (88 TCP/UDP, 135 TCP, 389 TCP/UDP, 636 TCP, 3268–3269, 53 TCP/UDP) deben estar abiertos para llegar a los DC. Cierra el puerto 445 salvo que se use para SYSVOL, y aun así restringe origen/destino.

Auditoría, monitorización y alertas

Componente	Elemento a vigilar	Frecuencia
Security Logs	Event ID 5136 y 4662	En tiempo real
Logs de directorio	Alertas de replicación NTDS	Cada 12 h
Tenable/Defender for Identity	Cambios de atributo crítico	Continuo

Copia de seguridad y recuperación

Implementa un plan de backup que incluya:

Snapshots del estado del sistema de cada DC (al menos uno por dominio) cada 24 h.
Copia offline en soporte inmutable.
Prueba de restauración autoritativa de objetos críticos en laboratorio.

Automatización de controles periódicos

Convierte la consulta LDAP en una tarea programada que levante alerta si devuelve resultados. Un ejemplo con PowerShell y un endpoint de Teams Webhook:

$objects = Get-ADObject -LDAPFilter "(primaryGroupID=-6605-)" -ErrorAction SilentlyContinue
if ($objects) {
    $body = @{
        text = "⚠️ AD alerta: primaryGroupID fuera de rango detectado: $($objects.Count) objeto(s)"
    } | ConvertTo-Json
    Invoke-RestMethod -Method Post -Uri $TeamsWebhook -Body $body -ContentType 'application/json'
}

Preguntas frecuentes

¿Puedo asignar un primaryGroupID que coincida con un grupo personal o de departamento?
No se recomienda. La pertenencia primaria se diseñó para los grupos integrados de sistema; usarlo para propósitos organizativos crea inconsistencias, ya que utilidades como “Effective Access” solo evalúan grupos globales y universales.

¿Eliminar el objeto resuelve el hallazgo?
Eliminarlo evita la alerta, pero conviene determinar por qué se creó con un RID atípico y si hay más cuentas generadas por el mismo proceso malicioso.

¿Puedo usar ADSI Edit para modificar la propiedad?
Sí, pero ADSI Edit carece de protecciones de sintaxis y vuelve fácil introducir errores. PowerShell valida los tipos de datos y registra en PowerShell Operational los comandos emitidos.

Conclusión

La alerta “AD Starter Scan – Primary Group ID Integrity” revela objetos cuyo primaryGroupID no corresponde a los grupos estándar de Active Directory. Ignorarla puede derivar en fugas de privilegios o fallos de replicación. Con las consultas LDAP/PowerShell propuestas localizarás rápidamente los objetos, mientras que el ajuste al RID correcto, la validación de pertenencias y la réplica forzada cerrarán la brecha. El endurecimiento adicional —parcheo disciplinado, MFA, segmentación y monitorización continua— reducirá la superficie de ataque y mantendrá tu directorio sano a largo plazo.