Inyección SIDHistory: SID conocido hacia Domain Admin

¿Qué es la inyección SIDHistory? La escalada de privilegios por SID conocido, explicada

La inyección SIDHistory con un SID conocido es una técnica de persistencia y escalada de privilegios en Active Directory en la que un atacante escribe un SID privilegiado conocido —como el sufijo RID 512 (Domain Admins) o RID 519 (Enterprise Admins) del SID del dominio— en el atributo sIDHistory de una cuenta sin privilegios. MITRE ATT&CK cataloga esto como la subtécnica T1134.005 — Access Token Manipulation: SID-History Injection.

Como cada SID almacenado en sIDHistory se copia en el PAC de Kerberos (Privilege Attribute Certificate) de la cuenta y, a su vez, en su token de acceso al iniciar sesión, la cuenta con pocos privilegios hereda efectivamente los derechos de Domain Admin sin haber sido añadida nunca al grupo Domain Admins. Las auditorías de pertenencia a grupos, las revisiones de grupos anidados y las comprobaciones net group /domain no muestran nada anómalo: la escalada es invisible para cualquier control que solo inspeccione la pertenencia a grupos.

Cómo funciona: sIDHistory y los SID conocidos

sIDHistory es un atributo legítimo de Active Directory diseñado para migraciones entre dominios y entre bosques: cuando una cuenta se traslada a un nuevo dominio, su SID antiguo se conserva en sIDHistory para que mantenga el acceso a los recursos para los que ya estaba autorizada, sin que un administrador tenga que reescribir manualmente cada ACL. La función DsAddSidHistory de Microsoft y la configuración de confianza EnableSIDHistory existen precisamente para dar soporte a este escenario de migración.

El problema es que Windows no distingue entre un SID añadido durante una migración legítima y uno añadido por un atacante. Al iniciar sesión, el controlador de dominio construye el PAC del usuario a partir de todos los SID asociados a la cuenta —grupo principal, todas las pertenencias a grupos y el contenido completo de sIDHistory— y ese PAC se convierte en el token de acceso en el que confía cada servicio posterior. Esta es una superficie de persistencia fundamentalmente distinta al anidamiento peligroso de grupos, donde el privilegio al menos es visible en la lista de miembros de un grupo; aquí, ninguna pertenencia a grupo cambia jamás.

Las cuentas de dominio normales, e incluso la mayoría de las herramientas de administración, no pueden simplemente ejecutar Set-ADUser -Replace @{sidHistory=...} por LDAP; sIDHistory es un atributo construido/protegido. En la práctica, los atacantes acceden a él mediante:

• Los módulos sid::patch y sid::add de Mimikatz, ejecutados directamente en un controlador de dominio con privilege::debug —lo que requiere un acceso equivalente a Domain Admin/SYSTEM en el propio DC—, y sid::patch ya no funciona en Windows Server 2016 y versiones posteriores.
• Add-ADDBSidHistory de DSInternals modificaba la base de datos ntds.dit sin conexión y requería detener el servicio NTDS —usado directamente contra la base de datos de un DC en lugar de a través de la API de replicación normal—. A fecha de esta redacción, el cmdlet ha sido retirado del módulo PowerShell DSInternals actual (su documentación se conserva solo como referencia); el equivalente mantenido hoy es Add-ADReplSidHistory, que realiza la inyección en línea a través del protocolo de replicación MS-DRSR y sigue requiriendo derechos de replicación equivalentes a los de un DC.
• La API legítima DsAddSidHistory, destinada a la migración entre bosques, que algunas herramientas usan de forma no prevista cuando el atacante ya controla privilegios equivalentes a los de un DC.

En todos los casos, el atacante ya necesita acceso de nivel de replicación o de controlador de dominio para escribir en sIDHistory —esta es una técnica de persistencia y sigilo posterior al compromiso, no un vector de acceso inicial—. Lo que justifica una detección dedicada es lo que ocurre después: el privilegio inyectado no es visible en la pertenencia a grupos, sobrevive a los restablecimientos de contraseña y no se ve afectado al eliminar la cuenta de ningún grupo (porque nunca fue miembro de ninguno).

La cadena de ataque

Paso 1 — Obtener acceso de nivel DC o equivalente a replicación

El atacante primero necesita privilegios equivalentes a Domain Admin, o acceso directo a un controlador de dominio —por ejemplo, mediante un compromiso DCSync previo, acceso directo a consola/RDP del DC, o una copia exfiltrada de ntds.dit—. Este paso es el mismo requisito previo que un ataque DCSync o un Golden Ticket falsificado.

Paso 2 — Identificar la cuenta objetivo y el SID conocido

El atacante elige una cuenta de bajo privilegio y baja visibilidad (una cuenta de servicio, una cuenta antigua de un contratista o una cuenta recién creada) y el SID del dominio con el RID conocido que desea inyectar:

Paso 3 — Inyectar el SID en sIDHistory

En un DC comprometido, con Mimikatz:

privilege::debug
sid::patch
sid::add /sam:lowpriv-svc /new:S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512

Históricamente, sin conexión contra una copia de ntds.dit, con DSInternals:

Add-ADDBSidHistory -SamAccountName lowpriv-svc -SidHistory S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512 -DatabasePath .\ntds.dit

Paso 4 — Autenticarse como la cuenta con pocos privilegios

En el siguiente inicio de sesión, el DC construye un PAC para lowpriv-svc que incluye el SID de Domain Admins inyectado. Todo servicio que confíe en los datos de autorización de Kerberos ahora otorga a la cuenta un acceso equivalente a Domain Admin, mientras que su pertenencia real a grupos sigue sin mostrar nada anómalo.

🚨 Peligro: como el SID inyectado reside en el propio objeto de la cuenta en lugar de en un ticket falsificado, persiste en cada inicio de sesión futuro hasta que alguien inspeccione específicamente y borre sIDHistory —a diferencia de un Golden Ticket, que expira o se invalida con una rotación de KRBTGT.

Detección

Los cambios en sIDHistory son poco frecuentes en un entorno sano fuera de una ventana de migración activa, lo que los convierte en una superficie de detección de alta señal, pero solo si está habilitada la directiva de auditoría correcta y se verifican los RID adecuados.

Los ID de evento 4765/4766 requieren que la subcategoría de auditoría avanzada "Auditar la administración de cuentas de usuario" esté habilitada; no está activada de forma predeterminada en muchos entornos, por lo que hay que verificar la directiva de auditoría antes de asumir cobertura.

Enumere las cuentas existentes en busca de un sIDHistory poblado y filtre específicamente por los RID privilegiados conocidos, no solo por cualquier valor histórico:

$domainSid = (Get-ADDomain).DomainSID.Value
$privilegedRids = @(512, 516, 518, 519)

Get-ADUser -Filter { SIDHistory -like '*' } -Properties SIDHistory |
    ForEach-Object {
        foreach ($sid in $_.SIDHistory) {
            $rid = ($sid.Value -split '-')[-1]
            if ($sid.Value -like "$domainSid-*" -and $privilegedRids -contains [int]$rid) {
                [PSCustomObject]@{
                    Account = $_.SamAccountName
                    InjectedSid = $sid.Value
                    RID = $rid
                }
            }
        }
    }

Microsoft Defender for Identity ofrece una evaluación de postura de seguridad para cuentas que portan un valor sIDHistory e incluye lógica de detección de comportamiento calibrada para señalar cambios inesperados del atributo SID-History fuera de una actividad de migración —un control compensatorio útil donde la directiva de auditoría avanzada presenta lagunas.

Remediación

1. Habilitar la directiva de auditoría avanzada para la administración de cuentas. Active "Auditar la administración de cuentas de usuario" para que los ID de evento 4765/4766 se disparen realmente, y reenvíelos a su SIEM con alertas ante cualquier aparición fuera de una ventana de cambio de migración conocida.
2. Restringir y supervisar el acceso de nivel DC y equivalente a replicación. Dado que inyectar sIDHistory requiere acceso Domain Admin/SYSTEM en un DC o una copia de ntds.dit, el control de mayor impacto es el mismo que detiene DCSync y los Golden Ticket: minimizar y auditar las cuentas que poseen DS-Replication-Get-Changes-All y restringir el inicio de sesión interactivo/RDP en los controladores de dominio.
3. Auditar sIDHistory en todo el dominio con una periodicidad recurrente, no solo después de una migración conocida. Cualquier valor poblado que contenga un RID privilegiado conocido y que no esté vinculado a un proyecto de migración documentado y acotado en el tiempo debe tratarse como un incidente crítico.
4. Limpiar sIDHistory al finalizar las migraciones. Una vez remediadas las ACL hacia los nuevos SID, elimine los valores heredados de sIDHistory —una superficie de ataque más pequeña sin valores residuales es más fácil de supervisar que una en la que "se espera cierto SID history".
5. Desplegar una herramienta de detección y respuesta de amenazas de identidad (ITDR), como Microsoft Defender for Identity, para añadir cobertura de comportamiento ante cambios en sIDHistory que complemente las reglas estáticas basadas en registros de auditoría.

# Eliminar todos los valores sIDHistory de una cuenta una vez completada la migración/remediación
Set-ADUser -Identity lowpriv-svc -Clear sIDHistory

Cómo lo detecta EtcSec

La auditoría de Active Directory de EtcSec distingue específicamente los problemas de higiene de SID-History de los indicadores activos de escalada de privilegios:

• SIDHISTORY_WELLKNOWN_SIDS (Crítico) — señala cualquier cuenta cuyo atributo sIDHistory contenga un RID privilegiado conocido (Domain Admins, Enterprise Admins, Schema Admins, Domain Controllers) que coincida con el propio SID del dominio —el patrón específico descrito en este artículo, no una simple presencia genérica de SID History.
• SID_HISTORY (Alto) — señala cualquier cuenta con un sIDHistory poblado, para que el trabajo legítimo de limpieza post-migración pueda seguirse y completarse.
• SIDHISTORY_RECENT_CHANGES (Info) — resalta los objetos cuyo sIDHistory ha cambiado recientemente, para correlacionar con ventanas de migración documentadas.
• DCSYNC_CAPABLE — señala el privilegio de punto de entrada (cuentas que no son DC pero poseen derechos de replicación) que suele ser el requisito previo para alcanzar un DC y realizar la inyección en primer lugar.

Prioridades de revisión

La inyección SIDHistory con SID conocidos debe tratarse como un hallazgo de nivel de dominación del dominio, no como una simple carencia de higiene rutinaria. Comience por enumerar todas las cuentas con un sIDHistory no vacío, y luego separe los artefactos de migración documentados de los valores inexplicados —especialmente cualquier coincidencia con un RID privilegiado conocido sobre el propio SID del dominio actual. Confirme qué controladores de dominio eran accesibles por qué administradores y cuentas de servicio durante la ventana sospechosa, ya que la técnica requiere acceso de nivel DC o equivalente a replicación para ejecutarse. Como el privilegio inyectado elude por completo la revisión de pertenencia a grupos, cualquier plan de remediación que solo audite la pertenencia a grupos lo pasará por alto —el propio atributo debe ser la fuente de verdad.

Controles adyacentes a revisar

La inyección SIDHistory rara vez está aislada: el acceso de nivel DC que requiere es el mismo acceso que permite la extracción de credenciales mediante DCSync, la falsificación de Golden Ticket y el robo directo de ntds.dit. Al investigar una inyección sospechosa, verifique quién poseía derechos de replicación y acceso de inicio de sesión a los DC durante la ventana de exposición, si KRBTGT se ha rotado recientemente, y si otras cuentas privilegiadas muestran señales de manipulación. Una corrección que borra el sIDHistory de una sola cuenta sin cerrar la vía de acceso al DC subyacente deja al atacante libre para inyectarlo de nuevo —o en una cuenta distinta.

Lecturas relacionadas

Revise este tema junto con Golden Ticket: las llaves de su reino, Abuso de ACL y DCSync: los caminos silenciosos hacia Domain Admin, Ataques de confianza en Active Directory: del dominio hijo a la raíz del bosque, Cuentas privilegiadas de Active Directory: Protected Users, delegación y lagunas en cuentas de servicio, Anidamiento peligroso de grupos en Active Directory y Supervisión de Active Directory: los ID de eventos de seguridad que importan.

• Golden Ticket: las llaves de su reino
• Abuso de ACL y DCSync: los caminos silenciosos hacia Domain Admin
• Ataques de confianza en Active Directory: del dominio hijo a la raíz del bosque
• Cuentas privilegiadas de Active Directory: Protected Users, delegación y lagunas en cuentas de servicio
• Anidamiento peligroso de grupos en Active Directory
• Supervisión de Active Directory: los ID de eventos de seguridad que importan

Lista de verificación de validación

Antes de cerrar la revisión, vuelva a ejecutar la enumeración de sIDHistory por RID conocido en producción y confirme que no queda ningún resultado inexplicado. Verifique que la directiva de auditoría avanzada esté habilitada en todos los controladores de dominio para que los ID de evento 4765/4766 se generen realmente, no solo estén disponibles en teoría. Confirme que los derechos de replicación y el acceso de inicio de sesión a los DC se han restringido a las cuentas que realmente los necesitan, y registre las evidencias —la salida de la enumeración y el estado de la directiva de auditoría— como línea base para la próxima auditoría recurrente.