Tickets Kerberos tras deshabilitar una cuenta: duración y contención

Tickets Kerberos tras deshabilitar una cuenta: por qué persisten las sesiones

La duración de los tickets Kerberos tras deshabilitar una cuenta importa porque cambiar el estado de una cuenta no cancela automáticamente los tickets que ya se le han emitido. Microsoft documenta que los tickets de servicio válidos emitidos antes de la deshabilitación todavía pueden permitir el acceso. Por tanto, el equipo de respuesta necesita pruebas sobre la cuenta, los tickets y los recursos que los aceptan, en lugar de considerar la deshabilitación como prueba de una contención completada. Microsoft Learn: duración del ticket de usuario

Existe un segundo límite: una conexión autenticada puede sobrevivir al ticket que la estableció. Microsoft explica que los tickets de servicio autentican las conexiones nuevas; su caducidad no interrumpe las operaciones en curso de una conexión ya autenticada. Esperar hasta la hora de finalización del ticket no basta, por tanto, para demostrar que el acceso ha cesado. Microsoft Learn: duración del ticket de servicio

En una investigación de respuesta, plantee tres preguntas por separado. ¿Puede la identidad obtener otro ticket? ¿Puede un ticket que ya posee autenticar otra conexión? ¿Sigue funcionando una conexión autenticada anteriormente? Son preguntas de investigación derivadas de esos límites documentados, no tres etapas por las que pase todo incidente. Manténgalas separadas en el registro del incidente para que las pruebas sobre una no cierren accidentalmente las otras.

Esta guía aborda los tickets legítimos ya emitidos, incluido el problema de contención cuando ese material ha sido robado. Para la amenaza distinta de TGT falsificados a partir de un secreto krbtgt comprometido, consulte el ataque Golden Ticket y su requisito previo krbtgt. Para distinguir entre falsificar un ticket de servicio y reutilizar uno robado, consulte la comparación de Silver Ticket con Pass-the-Ticket y la comparación de Pass-the-Hash, Overpass-the-Hash y Pass-the-Ticket. Sus recorridos de ataque son independientes de las decisiones sobre duración y contención que se presentan aquí.

Los tres relojes: TGT, ticket de servicio y conexión establecida

El ticket de concesión de tickets, o TGT, se utiliza para obtener otros tickets Kerberos. El ticket de servicio se presenta a un servicio concreto. La conexión establecida tiene después su propia duración, que la directiva de tickets de servicio no define. Distinga los dos relojes de los tickets del reloj de la conexión; el período de renovación es un límite adicional para los TGT renovables. Microsoft Learn: duración del ticket de servicio, RFC 4120 §2.3

Los valores siguientes son los valores predeterminados documentados por Microsoft, no mediciones de su dominio. Las claves y unidades se especifican en MS-GPSB §2.2.2, Kerberos Policy.

Convierta horas y minutos antes de comparar valores. MS-GPSB identifica MaxTicketAge como el límite superior relacionado con MaxServiceAge; la página Learn sobre tickets de servicio contiene una errata que compara el parámetro consigo mismo y que no debe convertirse en una regla operativa. El desfase de cinco minutos es una tolerancia, no un retraso de contención garantizado. MS-GPSB, Microsoft Learn: tolerancia de sincronización de relojes

Siete días de renovación no significan que cada TGT sea válido continuamente durante siete días. Un ticket renovable tiene una caducidad individual y un límite final de renovación. Acortar ese período también afecta a la disponibilidad para los usuarios que no pueden contactar frecuentemente con un controlador de dominio. Microsoft Learn: renovación del ticket de usuario, RFC 4120 §2.3

Las comprobaciones de cuenta limitan los tickets nuevos sin cancelar automáticamente los ya emitidos

Windows realiza comprobaciones de cuenta durante las solicitudes de tickets. MS-KILE §5.1.3 exige que los KDC del dominio de la cuenta comprueben la cuenta cuando el TGT presentado tenga más de 20 minutos. MS-KILE §3.3.5.7.1 establece las condiciones: la validación de la directiva de la cuenta debe estar habilitada y el KDC debe pertenecer al dominio de la cuenta del usuario. Un KDC de otro dominio no puede efectuar esa comprobación. En esas condiciones, una cuenta deshabilitada se rechaza con KDC_ERR_CLIENT_REVOKED.

Esto es procesamiento de solicitudes, no un temporizador que desconecte todas las sesiones en el minuto 20. Limita la emisión posterior de TGS y no retira un ticket de servicio ya obtenido. Las solicitudes de TGT también tienen comprobaciones documentadas de la directiva de la cuenta, incluido el rechazo de cuentas deshabilitadas cuando la opción de validación está habilitada. MS-KILE §3.3.5.6.3

El protocolo también describe un mecanismo de revocación. RFC 4120 §3.3.3.1 especifica una hot-list comprobada en el servicio de concesión de tickets, que impide que los tickets cancelados obtengan tickets adicionales. La distingue de los tickets normales ya obtenidos, que siguen siendo válidos hasta su caducidad habitual. Esta especificación no establece un comando universal de administración de Windows para revocar globalmente los tickets de un usuario. RFC 4120 §3.3.3.1

Cambiar la contraseña del usuario no sustituye automáticamente las claves de sesión y los tickets que ya posee. Es una inferencia criptográfica del intercambio TGS: el TGT se procesa con la clave del servicio de concesión de tickets y la respuesta utiliza una clave de sesión en lugar del secreto a largo plazo del cliente. No garantiza que todas las autenticaciones futuras tengan éxito tras un restablecimiento. RFC 4120 §§3.3.2–3.3.3

La eliminación de pertenencias a grupos tiene otro límite. Los SID de grupos globales y universales se incorporan al PAC durante la emisión inicial del TGT y se copian en los TGT renovados. Por tanto, la renovación por sí sola no garantiza una pertenencia actualizada. Los grupos locales del dominio del recurso se añaden durante la emisión del ticket de servicio; no generalice afirmando que todos los grupos quedan congelados en el primer TGT. MS-PAC §4.1.2.1, MS-KILE §3.3.5.7.3

Detección

1. Construir una cronología con los registros de cuenta, KDC y destino

Utilice los eventos Windows documentados a continuación como entradas de evidencia. La estrategia de correlación es una recomendación analítica basada en sus campos y en los límites del protocolo anteriores; no se afirma ningún resultado de laboratorio ni de detección en producción.

El evento 4768 no cubre todos los fallos de TGT: Microsoft documenta que los códigos de resultado 0x10 y 0x18 generan en su lugar el evento 4771. Incluya esos fallos de preautenticación al revisar solicitudes fallidas. Microsoft Learn: cobertura de 4768

Ancle el incidente en el objetivo de 4725, no en el administrador que lo deshabilitó. Asocie esa identidad con nombres normalizados en los eventos Kerberos: 4769 no proporciona el mismo campo SID del usuario objetivo que 4725. Conserve el evento sin procesar y la decisión de correspondencia. Utilice el host de destino junto con su identificador de inicio de sesión al emparejar 4624 y 4634; Microsoft documenta que esos identificadores solo son únicos entre reinicios del mismo equipo. Definiciones de campos de 4725, definiciones de campos de 4769, límites de correlación de 4634

Priorice las solicitudes de tickets exitosas o los nuevos inicios de sesión en destinos tras la deshabilitación, los hosts de origen inesperados y la actividad continuada en conexiones conocidas. Revise el KDC del dominio de la cuenta, la opción de validación, la antigüedad del TGT y la cronología del incidente antes de interpretar una solicitud TGS posterior exitosa. Son pistas de investigación derivadas de KILE, no una prueba automática de robo de tickets. Los eventos ausentes dejan una carencia de visibilidad; no demuestran que una conexión haya terminado. Corrobore la cronología con el inventario actual de conexiones del propietario del recurso y el registro de auditoría de la aplicación.

2. Medir la directiva en los controladores de dominio pertinentes

Los ejemplos siguientes están adaptados de la documentación: no son comandos ejecutados en un entorno AD. Utilice un contexto autorizado, las herramientas y módulos necesarios y un directorio de informes existente con permiso de escritura. El ejemplo local de gpresult apunta al DC donde se ejecuta. Lea los parámetros Kerberos Policy del informe junto con el contexto de las GPO aplicadas. Microsoft Learn: gpresult

gpresult /scope computer /h C:\Temp\Kerberos-RSoP.html

Examine los parámetros de la Default Domain Policy con el informe siguiente. Su GUID conocido también es la clave de búsqueda del helper del colector en helpers/gpo_policy.go:11. Un informe de una GPO no demuestra por sí solo la directiva efectiva en todos los DC. Microsoft Learn: Get-GPOReport

Get-GPOReport -Guid 31B2F340-016D-11D2-945F-00C04FB984F9 -ReportType XML

Examine otras GPO, incluidos sus vínculos y filtros, con un informe independiente. Seleccione el dominio y el servidor reales mediante parámetros documentados cuando el contexto actual no sea adecuado. Get-GPOReport

Get-GPOReport -All -ReportType XML

Get-ADDefaultDomainPasswordPolicy no lee la directiva Kerberos. Su salida es el objeto de directiva de contraseñas predeterminado del dominio; no lo utilice para afirmar que se ha verificado MaxTicketAge o MaxRenewAge. Microsoft Learn: Get-ADDefaultDomainPasswordPolicy

3. Examinar los tickets realmente presentes en los hosts del ámbito

Los ejemplos independientes siguientes proceden de Microsoft Learn: klist. Lea la caché de la sesión actual:

klist

Examine su TGT, incluida la hora de finalización y el límite de renovación:

klist tgt

Enumere las sesiones de inicio de sesión locales antes de suponer que la caché del usuario actual cubre el host:

klist sessions

Seleccione una sesión con -li, que especifica la parte baja de su LUID; utilice también -lh si la parte alta es distinta de cero. 0x3e7 es el ejemplo documentado por Microsoft:

klist -li 0x3e7

Registre el host, la sesión, la hora de recopilación y los tiempos de los tickets. Estas observaciones cubren la caché seleccionada, no las copias de tickets en otro sistema. Mantenga ese perímetro en el registro de respuesta.

Remediación (Remediation)

1. Reducir las duraciones excesivas antes de un incidente

La guía de Microsoft para tickets de usuario propone 4–10 horas, y las solicitudes más frecuentes aumentan la carga del KDC. Pruebe el valor elegido con los flujos de trabajo legítimos. Configure los parámetros Kerberos del dominio en Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy. Microsoft Learn: duración del ticket de usuario

Para una preparación específica de cuentas privilegiadas, revise las directivas de autenticación y silos para TGT Tier 0 más cortos y restricciones de dispositivos. Mantenga esa decisión de despliegue separada de la limpieza urgente de cachés.

Reducir una duración en una GPO no es una purga retrospectiva. Es una inferencia de los períodos de validez que contienen los tickets y de las operaciones de caché local documentadas anteriormente. Aplique el cambio y verifique los tickets nuevos emitidos; conserve por separado las pruebas de los tickets existentes. RFC 4120, klist

2. Contener la identidad y los recursos durante el incidente

Deshabilite y restablezca la identidad afectada según corresponda para las autenticaciones futuras, después aísle los hosts comprometidos e inventaríe las conexiones que impliquen a esa identidad. El aislamiento y el cierre desde el recurso son recomendaciones operativas inferidas de la persistencia documentada de conexiones autenticadas, no un procedimiento universal de recuperación de Microsoft. Asigne un responsable a cada host y servicio afectado y registre qué vía de acceso cubre cada acción. MS-KILE: comprobaciones de cuenta del TGT, Microsoft Learn: duración del ticket de servicio

En un host que controle, purgue los tickets de la sesión actual con este comando documentado:

klist purge

Para una sesión seleccionada, el ejemplo de Microsoft es una operación independiente:

klist purge -li 0x3e7

Sin selector LUID, la purga se aplica a la sesión iniciada actualmente. No alcanza otras cachés ni tickets copiados en otro lugar. Cierre las conexiones pertinentes y organice la reautenticación como parte de la respuesta. La purga por sí sola no demuestra que todas las conexiones de aplicaciones hayan terminado. klist, límite de la conexión del ticket de servicio

El operador responsable puede optar por reiniciar un host o servicio para cerrar contextos locales cuando no sea posible controlar las sesiones individuales. Trátelo como una decisión operativa local, no como una revocación para todo el dominio ni como prueba de erradicación. Aquí no se prescribe ningún comando universal de reinicio.

3. Reservar la recuperación de krbtgt para el compromiso de ese secreto

Deshabilitar a un usuario normal no es motivo para rotar krbtgt dos veces. Si ese secreto está comprometido, siga la planificación de recuperación del dominio. El procedimiento de recuperación de bosques de Microsoft requiere dos restablecimientos porque el historial de contraseñas conserva dos contraseñas. Espere 10 horas entre restablecimientos con los valores predeterminados; si se modificaron las duraciones máximas, la espera mínima debe ser mayor que la duración configurada. Compruebe la replicación y el ámbito de los DC antes de programar la segunda operación. El procedimiento citado se aplica a DC de escritura, no a cuentas krbtgt_number de RODC. Microsoft Learn: restablecer la contraseña krbtgt

No deduzca que esos restablecimientos destruyen todos los tickets de servicio emitidos o las conexiones existentes. Sus claves de servicio y contextos establecidos son límites separados. Valide por separado los intentos de acceso nuevos, las cachés locales y las conexiones previamente abiertas; registre los resultados reales cuando el equipo de respuesta realice esas comprobaciones. RFC 4120 §3.3, Microsoft Learn: duración del ticket de servicio

Cómo detecta EtcSec este problema

El etc-collector de EtcSec identifica duraciones configuradas excesivas mediante tres identificadores reales de detector. Las afirmaciones siguientes proceden de la inspección estática de sus implementaciones Detect(), no de una auditoría del dominio de un cliente. Las rutas siguientes son relativas a public/internal/audit/detectors/ad/ en el código fuente del colector.

Las comparaciones son estrictas: 10 horas y 7 días no generan estos hallazgos. La comprobación agregada se solapa con las dos especializadas; son dos comprobaciones de duración y una agregada, no tres capacidades de contención independientes. No detectan el robo de tickets, no terminan sesiones ni implementan la revocación de tickets de usuario.

Las entradas principales son los parámetros Kerberos extraídos de GptTmpl.inf en SYSVOL, en public/internal/providers/smb/gptmpl_parser.go:221–227. El helper public/internal/audit/helpers/gpo_policy.go:42–54 prioriza la Default Domain Policy y después otra GPO disponible con parámetros Kerberos. No calcula la precedencia RSoP completa. Compare el hallazgo con la directiva efectiva del DC pertinente y los tickets observados antes de declarar completada la remediación.

Los detectores especializados seleccionan valores positivos y contienen mecanismos alternativos mediante DomainInfo. MaxTicketAge=0, pese a su significado de ausencia de caducidad documentado por Microsoft, no se señala mediante la comparación de duración. Las entradas ausentes o iguales a cero también pueden dejar Count=0. La comprobación agregada devuelve inmediatamente Count=0 cuando DomainInfo es nil, incluso si hay datos de directiva SYSVOL (weak-kerberos-policy.go:25–33). Sus detalles dependen de IncludeDetails. Ninguna de estas tres comparaciones comprueba la duración del ticket de servicio, el desfase de reloj ni el indicador de validación de la cuenta.

El registro final de respuesta debe asociar las duraciones configuradas con pruebas de las cachés de tickets, resultados de solicitudes KDC y comprobaciones de conexiones desde los recursos. Son las pruebas necesarias para distinguir una directiva corregida de un acceso que realmente ha terminado.