Kerberos leído desde los registros

Cuando alguien se identifica, el controlador emite un ticket de autenticación (evento 4768) o, si la comprobación previa falla, anota un 4771. Dentro del evento, el código de resultado explica el motivo. El 0x0 es éxito; el 0x6 dice que la cuenta no existe; el 0x12 que la cuenta está revocada (deshabilitada, vencida o bloqueada); el 0x18, que la comprobación previa falló.

La documentación pública de Microsoft describe cada código y avisa de que el 0x18 en un 4768 no puede darse: ese fallo se anota como 4771.

Un 4768 con código 0x6 significa que alguien pidió un ticket para una cuenta que no existe. Una persona que se equivoca de usuario produce uno o dos. Una serie de ellos en pocos segundos, con nombres genéricos (los que se prueban primero), indica que alguien está comprobando qué cuentas existen.

Por sí solo no prueba un compromiso, pero es una señal temprana que el equipo de monitoreo debería ver antes de que haya un éxito.

El ticket de servicio (evento 4769) es la autorización para usar un servicio concreto: una base de datos, un recurso compartido. El evento dice qué servicio se pidió y con qué cifrado. En un dominio moderno casi todo va en AES (0x11 o 0x12). El 0x17 es RC4, el cifrado por defecto de sistemas anteriores a Windows Server 2008 y Windows Vista; todavía aparece, pero en un dominio que usa AES para casi todo es una excepción.

Recorre las filas 4769 del extracto y busca las que no usan AES.

Un ticket RC4 para una cuenta de servicio, pedido varias veces en tres segundos desde un origen que acaba de iniciar sesión como administrador tras una racha de fallos, es una señal que se revisa con el resto del caso: la hora, la cuenta, el origen. No es una prueba definitiva, porque una aplicación antigua también puede pedir RC4. Lo que lo vuelve sospechoso es el conjunto, no el cifrado solo.

Lo que sí se hace de inmediato es anotarlo, porque si los tickets de la cuenta de servicio quedaron en manos ajenas, la cuenta tendrá que rotarse más adelante.