KomuraSoft LLC
Contáctenos
Menú

Auditoría de seguridad en Windows e investigación práctica del registro de eventos — cómo convertirse en un responsable de sistemas capaz de leer el 4625

· Actualizado el: · · Windows, Seguridad, Registro de eventos, Directiva de auditoría, Diseño de registros, PowerShell, Sistemas de información

«Desde anoche una cuenta se está bloqueando repetidamente, investigue la causa». «Quiero comprobar si alguien ha intentado iniciar sesión con la cuenta de un empleado que ya se fue». «¿Se puede saber quién hizo qué y cuándo en este servidor?» — Son peticiones que, un buen día, le llegan de repente al responsable de sistemas de una pyme o al desarrollador que entrega sistemas a sus clientes. Y en esos momentos, el último recurso al que aferrarse es el registro de eventos Security de Windows.

Sin embargo, al abrir realmente el Visor de eventos (Event Viewer), le esperan dos realidades. El evento que quiere ver no está registrado (la directiva de auditoría no está activada), o está sepultado entre una cantidad enorme de eventos y no se puede leer (el registro está inflado de ruido). La auditoría de seguridad es algo que «se graba si se activa», pero si no se diseña qué grabar y hasta dónde, no sirve de nada cuando realmente se necesita.

Dos realidades que esperan al abrir el Visor de eventosAl abrir el Visor de eventos existen dos realidades, que la directiva de auditoría no esté activada y el evento buscado no esté registrado, o que el registro esté inflado de ruido y sepultado entre una cantidad enorme de eventos, por lo que es necesario diseñar qué grabar y hasta dóndeNo se ha grabadoEstá sepultadoAbrir el Visor de eventos¿Qué realidad espera?El evento buscado no está registradoIlegible entre una cantidad enorme de eventosLa directiva de auditoría está desactivadaInflado de ruidoDiseñar qué grabar y hasta dónde

Figura 1: «No se ha grabado» o «está sepultado y no se puede leer». En ambos casos, la causa es no haber diseñado el alcance de la grabación.

En este artículo se organiza, con base en fuentes primarias vigentes a agosto de 2026, el funcionamiento de la directiva de auditoría (los dos sistemas, básico y detallado), las subcategorías mínimas que conviene activar en un entorno de tamaño pequeño o mediano, cómo leer los eventos habituales como 4624/4625/4740/4688, el diseño de la capacidad del registro Security y, finalmente, cómo investigarlo con PowerShell. Si los artículos que hemos tratado en este sitio sobre auditoría de NTLM, firma SMB, BitLocker y el firewall trataban de «reforzar las defensas», este artículo trata de «poder confirmar después qué ocurrió», y es la continuación que reúne todos esos hilos.

1. Conclusión inicial

  • La directiva de auditoría tiene dos sistemas, «básico» y «detallado (Advanced Audit Policy)», y no deben mezclarse. Microsoft indica explícitamente que usar ambos hace que los resultados de la auditoría queden en un estado impredecible. Unifique todo en el sistema detallado (más de 40 subcategorías).1
  • Para comprobar el estado actual use auditpol /get /category:*. Independientemente de si el origen es GPO o la configuración local, permite listar la configuración de auditoría que realmente está en vigor.2
  • No active «todo». Activar subcategorías que generan un gran volumen de eventos sepulta entre el ruido los eventos que realmente importan, además de afectar al rendimiento. Tome como punto de partida las recomendaciones de referencia de Microsoft y añada solo lo necesario.34
  • El inicio de sesión correcto es el 4624; el fallido, el 4625. El 4624 se distingue por el tipo de inicio de sesión (2 = interactivo, 3 = red, 10 = escritorio remoto, etc.) para saber «qué clase de inicio de sesión fue».5
  • En el 4625, el motivo del fallo se conoce por el código Status/Sub Status. Los habituales son 0xC0000064 (nombre de usuario inexistente), 0xC000006A (contraseña incorrecta), 0xC0000072 (cuenta deshabilitada) y 0xC0000234 (cuenta bloqueada).6
  • Está determinado en qué equipo queda registrado cada evento. El 4624/4625 se registra en el equipo al que se accedió; la validación de credenciales (4776) y el fallo de preautenticación Kerberos (4771) se registran en el controlador de dominio. Mirar el equipo equivocado lleva a diagnosticar erróneamente que «no hay registro».678
  • El diseño del contenedor del registro Security (tamaño máximo y retención) es la mitad del trabajo. Si la retención está en modo de sobrescritura, los eventos más antiguos van desapareciendo. Compruebe el tamaño máximo y el número de registros con Get-WinEvent -ListLog Security, y amplíelo calculando hacia atrás a partir de los días de retención necesarios.910
  • El registro de la línea de comandos en la creación de procesos (4688) es muy potente, pero a cambio implica el riesgo de que información confidencial quede en texto plano en el registro. Revise sus scripts antes de activarlo.1112

2. Fundamentos de la directiva de auditoría — no mezclar «básica» y «detallada»

La directiva de auditoría de Windows tiene dos sistemas.1

  • Directiva de auditoría básica: las 9 categorías de configuración que se encuentran en «Directivas locales > Directiva de auditoría». Es el sistema antiguo, anterior a Windows Vista.
  • Directiva de auditoría detallada (Advanced Audit Policy Configuration): las más de 40 configuraciones de subcategoría que se encuentran en «Configuración de seguridad > Configuración avanzada de la directiva de auditoría». Descompone cada categoría básica en varias subcategorías; por ejemplo, frente a la única categoría básica «Auditar eventos de inicio de sesión de cuenta», el lado detallado tiene 4 subcategorías. Activar una categoría en el lado básico equivale a activar todas las subcategorías correspondientes, por lo que se registran en gran cantidad incluso eventos que no interesan.1

Lo importante es que estos dos sistemas no son compatibles entre sí. Microsoft indica explícitamente: «No use a la vez la directiva básica y la detallada; los resultados de la auditoría quedarán en un estado impredecible». Cuando se aplica la directiva de auditoría detallada mediante la directiva de grupo, la configuración de auditoría existente de ese equipo se borra por completo antes de aplicarse la configuración detallada, y a partir de entonces solo se puede controlar de forma fiable desde el lado detallado. En los entornos que usan el lado detallado, active la opción de seguridad «Auditoría: forzar la configuración de subcategoría de directiva de auditoría» para evitar que la configuración del lado básico la sobrescriba (en equipos independientes está activada de forma predeterminada).14

Relación entre la directiva de auditoría básica y la detalladaLa directiva de auditoría básica y la detallada no son compatibles entre sí, y usar ambas deja los resultados de la auditoría en un estado impredecible, por lo que conviene unificar todo en el lado detallado y activar el forzado de la configuración de subcategoría para evitar que el lado básico la sobrescribaSíNoDirectiva de auditoría básica（9 categorías）¿Se usan ambas?Directiva de auditoría detallada（más de 40 subcategorías）Resultados de auditoría impredeciblesUnificar en el lado detalladoActivar forzar la configuración de subcategoríaEvita la sobrescritura por el lado básico

Figura 2: Los dos sistemas no son compatibles. Unifique en el lado detallado y evite la sobrescritura del lado básico con la opción «forzar».

Comprobar el estado actual es cuestión de un solo comando. Ejecútelo desde un símbolo del sistema con privilegios de administrador.2

rem Muestra la configuración de auditoría actualmente en vigor, por subcategoría
auditpol /get /category:*

rem Copia de seguridad (CSV) antes de un cambio, y restauración
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

La salida de auditpol es «la directiva que está en vigor como resultado», independientemente de si su origen es GPO o la configuración local. También sirve para comprobar por qué una configuración que debería haberse distribuido mediante GPO no se está reflejando. Además, cualquier cambio en la propia configuración de auditoría queda registrado como el evento 4719, de modo que también se puede rastrear después el caso de «la auditoría se desactivó sin que nadie se diera cuenta».12

auditpol muestra la directiva resultanteLa salida de auditpol es la directiva de auditoría que está en vigor como resultado, sin importar si el origen es GPO o la configuración local, y sirve para comprobar cuando la configuración de GPO no se refleja, mientras que el cambio de la propia configuración de auditoría se puede rastrear después mediante el evento 4719Configuración distribuida por GPODirectiva en vigor como resultadoConfiguración localListado con auditpol /getSirve para verificar cuando GPO no se reflejaCambio de la propia configuración de auditoríaSe registra como 4719 y se puede rastrear después

Figura 3: auditpol devuelve «la configuración en vigor» sin importar su origen. El cambio de la configuración de auditoría en sí queda en el 4719.

3. Tabla de decisión: las subcategorías mínimas que conviene activar

La razón por la que «activar todo, por si acaso» es una mala práctica es clara. Microsoft advierte, por ejemplo, que auditar hasta los éxitos en las subcategorías de uso de privilegios genera un volumen de eventos tan enorme que dificulta encontrar otras entradas y afecta también al rendimiento.4 Como el contenedor del registro (capítulo 5) es finito, cuanto más ruido se graba, más se recortan los días de retención de los eventos realmente necesarios. El diseño de la auditoría consiste en decidir qué no grabar.

Por qué activarlo todo es una mala prácticaActivar todas las subcategorías genera una cantidad enorme de eventos que sepultan entre el ruido los eventos importantes y afectan también al rendimiento, y como el contenedor del registro es finito, también se recortan los días de retención de los eventos necesariosActivar todas las subcategoríasSe genera una cantidad enorme de eventosLos eventos importantes quedan sepultadosImpacto en el rendimientoSe recortan los días de retenciónDecidir qué no grabar es el diseño de la auditoría

Figura 4: «Activarlo todo» sepulta los eventos importantes. Decidir qué no grabar es el diseño de la auditoría.

Microsoft publica recomendaciones de referencia y recomendaciones reforzadas por separado para estaciones de trabajo y servidores, y ese es el punto de partida.3 A partir de ahí, la tabla siguiente organiza las subcategorías desde el punto de vista de «esto es lo mínimo que querría poder leer ante un incidente» en un entorno de tamaño pequeño o mediano.

Subcategoría (categoría) Eventos ID principales Qué revela Recomendación para entornos pequeños/medianos
Inicio de sesión (Inicio y cierre de sesión) 4624 / 4625 Éxito/error de inicio de sesión, tipo de inicio de sesión, origen Éxito+error. Desde Windows 10 1809 el éxito y el error ya están activados de forma predeterminada3
Inicio de sesión especial (igual) 4672 / 4964 Ocurrencia de inicios de sesión con privilegios administrativos Éxito
Bloqueo de cuenta (igual) 4625 Error de inicio de sesión en una cuenta bloqueada Error (el 4625 es un evento de error; en esta subcategoría no existen eventos de éxito)13
Administración de cuentas de usuario (Administración de cuentas) 4720 / 4726 / 4738 / 4740 Creación, eliminación, modificación y bloqueo de cuentas Éxito+error
Administración de grupos de seguridad (igual) 4728 / 4732 / 4756 (alta), 4729 / 4733 / 4757 (baja) Alta/baja de miembros en grupos administrativos, etc. (global/local/universal) Éxito (en esta subcategoría no existen eventos de error)14
Validación de credenciales (Inicio de sesión de cuenta) 4776 Éxito o fracaso de la autenticación NTLM. Las cuentas de dominio se registran en el DC7 Éxito+error
Servicio de autenticación Kerberos (igual, solo DC) 4768 / 4771 Emisión de TGT y fallo de preautenticación (contraseña incorrecta, etc.)8 Éxito+error en el DC
Creación de procesos (Seguimiento detallado) 4688 Quién, desde qué proceso principal y qué se inició Éxito. Lea antes las advertencias del capítulo 7 sobre el registro de la línea de comandos
Otros eventos de acceso a objetos (Acceso a objetos) 4698 Creación de tareas programadas (recurso habitual para la persistencia de ataques)15 Considerar activar el éxito
Cambio de directiva de auditoría (Cambio de directiva) 4719 Cambio de la propia configuración de auditoría Éxito+error

Por el contrario, es más prudente no tocar por defecto la auditoría de acceso a objetos del sistema de archivos o del registro, el uso de privilegios ni las subcategorías de filtrado de paquetes (como el 5152). Estas son útiles precisamente cuando se limitan mediante una configuración de SACL dirigida a un objetivo concreto o durante un periodo acotado de aislamiento del problema; si se mantienen siempre al máximo, devoran el registro.4

Manejo de las subcategorías de gran volumen de eventosLa auditoría de acceso a objetos del sistema de archivos o del registro, el uso de privilegios y las subcategorías de filtrado de paquetes devoran el registro si se mantienen siempre al máximo, y solo son útiles con una configuración SACL dirigida a un objetivo o durante un periodo acotado de aislamientoSiempre al máximoSACL dirigida a un objetivoPeriodo acotado de aislamientoSubcategorías de gran volumen de eventos¿Cómo activarlas?Auditoría de acceso a objetosUso de privilegios y filtrado de paquetesDevoran el registroEs útilEs útil

Figura 5: No mantenga siempre al máximo el acceso a objetos ni el uso de privilegios. Solo son útiles si se acotan el objetivo y el periodo.

4. Cómo leer los eventos ID habituales

4.1. 4624 — el éxito de inicio de sesión se distingue por el tipo de inicio de sesión

El 4624 es «la cuenta inició sesión correctamente» y se registra en el equipo donde se creó la sesión de inicio de sesión (el lado al que se accedió).5 Como es un evento que se registra en gran volumen, al leerlo conviene clasificarlo primero por el tipo de inicio de sesión.5

Tipo de inicio de sesión Nombre Significado práctico
2 Interactive Inicio de sesión en la consola de ese propio equipo
3 Network Acceso a través de la red (carpetas compartidas, herramientas de administración, etc.). Es el más frecuente, ya que aparece por cada equipo
4 Batch Ejecución por lotes (tareas programadas, etc.)
5 Service Inicio de un servicio (Administrador de control de servicios)
7 Unlock Desbloqueo de la pantalla
8 NetworkCleartext Inicio de sesión de red en el que la contraseña se pasó en texto plano al paquete de autenticación
9 NewCredentials Duplicación con otras credenciales (equivalente a runas /netonly)
10 RemoteInteractive Escritorio remoto
11 CachedInteractive Inicio de sesión con credenciales almacenadas en caché (sin conexión al DC)

Los campos que conviene revisar junto con esto son el nombre de cuenta de «Nuevo inicio de sesión», la dirección de origen de «Información de red», el «Paquete de autenticación» (si fue NTLM o Kerberos) y el «Token elevado» (si fue una sesión con privilegios administrativos). Si solo quiere seguir los inicios de sesión con privilegios administrativos, también puede usar el 4672 (asignación de privilegios especiales), que se registra con el mismo ID de inicio de sesión.5

Procedimiento para leer el 4624El 4624, que se registra en gran volumen, se clasifica primero por el tipo de inicio de sesión, luego se revisan el nombre de cuenta, el origen, el paquete de autenticación y el token elevado, y el inicio de sesión con privilegios administrativos se contrasta con el 4672 del mismo ID de inicio de sesión4624 Inicio de sesión correctoClasificar por el tipo de inicio de sesiónRevisar los campos principalesNombre de cuenta y origenPaquete de autenticaciónToken elevadoSeguimiento de privilegios administrativos4672 con el mismo ID de inicio de sesión

Figura 6: El 4624 se clasifica por el tipo de inicio de sesión antes de leer los campos. El inicio de sesión con privilegios se correlaciona con el 4672.

4.2. 4625 — el motivo del fallo se confirma con el código Status/Sub Status

El 4625 es «la cuenta no pudo iniciar sesión» y se registra en el equipo en el que se intentó el inicio de sesión.6 Es más fiable leerlo por el código hexadecimal de Status/Sub Status que por el texto del campo «motivo del error». Los habituales son los siguientes.6

  • 0xC0000064: nombre de usuario inexistente. Si se repite en un intervalo corto, es indicio de un ataque de enumeración de cuentas
  • 0xC000006A: contraseña incorrecta. Si se repite sobre una cuenta concreta, es indicio de un ataque de adivinación de contraseñas
  • 0xC000006D: nombre de usuario o información de autenticación no válidos
  • 0xC000006F: fuera del horario permitido
  • 0xC0000070: desde una estación de trabajo no permitida
  • 0xC0000072: cuenta deshabilitada por un administrador (los intentos sobre la cuenta de un empleado que ya se fue aparecen aquí)
  • 0xC000015B: el tipo de inicio de sesión solicitado no está permitido en este equipo
  • 0xC0000193: cuenta caducada
  • 0xC0000234: cuenta bloqueada

«Quién, desde dónde y por qué falló» se determina con el conjunto de tres elementos: la cuenta objetivo, el origen (nombre de la estación de trabajo o dirección IP) y este código. En el capítulo 6 se incluye un script de PowerShell que extrae estos tres elementos de una sola vez.

Flujo para determinar el motivo del fallo del 4625El motivo del fallo del 4625 se determina con el código hexadecimal Status/Sub Status, se interpreta el indicio de ataque a partir de la tendencia del código, y se identifica con el conjunto de tres elementos formado por la cuenta objetivo y el origen0xC0000064 repetido0xC000006A repetido0xC00000724625 Inicio de sesión fallidoRevisar el código Sub Status¿Cuál es la tendencia del código?Indicio de enumeración de cuentasIndicio de adivinación de contraseñasIntento sobre cuenta de un empleado que ya se fueSe determina con el conjunto de tres elementosCuenta objetivo + origen + código

Figura 7: El motivo del fallo se determina por el código y se lee junto con la cuenta objetivo y el origen, como un conjunto de tres elementos.

4.3. 4740 — el origen del bloqueo está en el «nombre del equipo de llamada»

El 4740 es «se bloqueó una cuenta de usuario» (la subcategoría es Administración de cuentas de usuario). El protagonista de este evento es el campo «Nombre del equipo de llamada (Caller Computer Name)», en el que se registra de qué equipo procedía el intento de inicio de sesión que desencadenó el bloqueo.16 La práctica habitual consiste en identificar aquí el equipo de origen y revisar las credenciales antiguas que aún queden en ese equipo. En la mayoría de los casos, la causa es algo que sigue usando credenciales antiguas después de un cambio de contraseña: credenciales guardadas, sesiones RDP que quedaron desconectadas, o servicios y tareas configurados con una contraseña antigua.

Procedimiento estándar para investigar un bloqueo de cuentaEl nombre del equipo de llamada del 4740 identifica el equipo de origen, y en ese equipo se revisan las credenciales guardadas, las sesiones RDP que quedaron desconectadas y los servicios o tareas con contraseñas antiguas4740 Bloqueo de cuentaRevisar el nombre del equipo de llamadaIdentificar el equipo de origenRevisar las credenciales antiguasCredenciales guardadasSesiones RDP que quedaron desconectadasServicios o tareas con contraseñas antiguas

Figura 8: Identifique el origen a partir del «nombre del equipo de llamada» del 4740 y revise las credenciales antiguas de ese equipo.

Hay un punto de atención: el 4625 se registra en la computadora que recibió el intento de inicio de sesión. Si la causa es un inicio de sesión de red desde el equipo de origen hacia un servidor de archivos u otro destino, el propio registro Security del equipo de origen no conserva el 4625; el rastro queda en el 4625 del servidor de destino o, para cuentas de dominio, en el 4776 (NTLM) o el 4771 (fallo de preautenticación Kerberos) del lado del DC.78 Cuando «no hay nada en el registro del equipo de origen», vaya a revisar el lado que recibió el intento.

En qué equipo queda el rastro del falloEl fallo de un inicio de sesión de red no queda en el propio equipo de origen, sino que se registra en el 4625 del servidor de destino que recibió el intento, y para cuentas de dominio el rastro también queda en el 4776 o el 4771 del DCInicio de sesión de redAutenticación de cuenta de dominioEquipo de origen（el 4625 no queda en sí mismo）Servidor de destinoSe registra el 4625Controlador de dominio4776（NTLM）/ 4771（Kerberos）

Figura 9: El 4625 queda en el lado que recibió el intento. Si no hay nada en el equipo de origen, revise el servidor de destino y el DC.

4.4. Serie 4720 — creación, modificación de cuentas y altas en grupos

Los eventos de administración de cuentas están numerados en serie: 4720 (creación de cuenta de usuario)17, 4726 (eliminación), 4738 (modificación) y las altas/bajas de miembros del lado de los grupos. Tenga en cuenta que en el cambio de miembros de un grupo el ID de evento cambia según el tipo de grupo: los grupos locales usan 4732/4733, los grupos globales 4728/4729 y los grupos universales 4756/4757.14 Como Domain Admins es un grupo global, una alta en ese grupo se registra en 4728; si se usa únicamente el 4732 como condición de alerta, se pasa por alto precisamente el evento que más interesa vigilar. En el día a día son registros de tareas de mesa de ayuda, pero «un usuario estándar añadido de repente a un grupo administrativo» o «una cuenta que nadie conoce recién creada» son motivo de investigación inmediata incluso si ocurren una sola vez. El propio Microsoft menciona la incorporación inesperada de miembros a grupos con privilegios como ejemplo de alerta ante un evento aislado.3

Tipo de grupo y evento de alta de miembroEl alta de un miembro en un grupo se registra con un ID de evento distinto según el tipo de grupo, en 4732 para local, 4728 para global y 4756 para universal, de modo que el alta en el grupo global Domain Admins se registra en 4728LocalGlobalUniversalAlta de miembro en un grupo¿Cuál es el tipo de grupo?Se registra en 4732Se registra en 4728Se registra en 4756Aquí queda el alta en Domain AdminsVigilar solo el 4732 deja pasar casos

Figura 10: El ID de evento del alta de miembro depende del tipo de grupo. El alta en Domain Admins se registra en el 4728.

4.5. 4688 — creación de procesos. El registro de la línea de comandos es un interruptor aparte

El 4688 es «se creó un nuevo proceso» y, en cada creación de proceso, registra la cuenta que lo creó, la ruta del ejecutable del nuevo proceso, el proceso principal y el tipo de elevación del token.11 Es un evento de gran valor para la investigación, porque responde a «quién ejecutó qué en este servidor».

Sin embargo, de forma predeterminada no se registran los argumentos de la línea de comandos. Solo cuando se activa por separado la directiva de grupo «Incluir la línea de comandos en los eventos de creación de procesos» (Plantillas administrativas > Sistema > Auditoría de creación de procesos), el campo «Línea de comandos del proceso» del 4688 recibe los argumentos.1112 Es una configuración prácticamente imprescindible para seguir el rastro de inicios sospechosos como powershell -EncodedCommand ..., pero actívela solo después de entender el riesgo de fuga de información confidencial descrito en el capítulo 7.

Relación entre el 4688 y el registro de la línea de comandosActivar la auditoría de creación de procesos registra en el 4688 la cuenta, la ruta y el proceso principal, pero los argumentos de la línea de comandos solo se registran al activar por separado otra directiva de grupo, lo que implica el riesgo de que información confidencial quede en texto planoConfiguración predeterminadaActivar también la GPOActivar la auditoría de creación de procesosSe registra el 4688Cuenta, ruta y proceso principal¿También se quieren los argumentos?La línea de comandos queda vacíaSe registran los argumentosRiesgo de información confidencial en texto plano

Figura 11: El registro de la línea de comandos del 4688 es un interruptor aparte. Antes de activarlo, revise el riesgo de fuga de información confidencial.

4.6. 4698 — creación de tareas programadas

El 4698 es «se creó una tarea programada» y registra el nombre de la tarea junto con el XML completo de la definición de la tarea (incluido el comando que ejecuta). Como registrar una tarea es el recurso habitual del malware para sobrevivir tras un reinicio, Microsoft recomienda vigilar los eventos de creación de tareas.15 Incluso en entornos que usan tareas intensamente en su operación diaria, la creación no es algo que ocurra a diario, así que el ruido es relativamente pequeño.

Persistencia mediante tareas programadas y el 4698El malware usa el registro de tareas programadas como recurso habitual para sobrevivir tras un reinicio, por lo que vigilar el 4698, que se registra al crear una tarea, permite rastrear hasta el XML completo de la definición, incluido el comando que ejecutaPersistencia del malwareRegistra una tarea para sobrevivirSe registra el 4698XML completo con el comando que ejecutaSe detecta vigilando la creación de tareasLa creación no es diaria, poco ruido

Figura 12: El registro de tareas, recurso habitual de la persistencia, queda en el 4698. Desde el XML completo de la definición se llega hasta el comando ejecutado.

Otro evento que conviene recordar es el 1102, «se borró el registro de auditoría». Vaciar el registro Security siempre deja este evento, de modo que, cuando «el registro está vacío», permite distinguir si fue un accidente o una acción deliberada.18

Aislar la eliminación del registro con el 1102Vaciar el registro Security siempre deja el evento 1102, así que cuando el registro está vacío, comprobar si existe el 1102 permite distinguir si hubo una acción de borrado o si fue un accidenteExisteNo existeEl registro está vacíoVaciarlo siempre deja el 1102¿Existe el 1102?Hubo una acción de borradoSospechar de un accidente

Figura 13: Vaciar el registro Security siempre deja el 1102. Un registro vacío se distingue según exista o no el 1102.

5. Diseño del contenedor del registro — tamaño máximo y retención

Antes de ampliar la directiva de auditoría, conviene comprobar el contenedor que la recibe. El registro Security tiene un tamaño máximo y un modo de retención: en el modo de sobrescritura (la configuración habitual predeterminada), al alcanzar el tamaño máximo, los eventos nuevos sobrescriben los más antiguos. Por el contrario, en el modo de retención (sin sobrescribir), cuando el registro se llena, son los eventos nuevos los que se descartan.10 Cualquiera de los dos comportamientos puede acabar en «el registro ya no está cuando lo necesito», así que lo primero es conocer el estado actual.

# Comprobar el contenedor del registro Security: modo de retención, tamaño máximo y número actual de registros
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# Cuántos días quedan realmente conservados ahora mismo (fecha del evento más antiguo)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog devuelve de una vez la configuración y el número de registros del registro.9 La diferencia entre «la fecha del evento más antiguo» y la fecha actual es el número real de días de retención; si no alcanza el requisito de la propia organización (los días que se querrían poder consultar en una investigación de incidentes), amplíe el tamaño máximo. La configuración se puede aplicar con wevtutil sl Security /ms:<número de bytes> o distribuirla mediante la directiva de grupo.10

Diseño de capacidad calculado a partir de los días de retenciónSe comprueba la configuración y el número de registros con ListLog de Get-WinEvent, se calcula el número real de días de retención a partir de la fecha del evento más antiguo, y si no alcanza los días que se quieren consultar en una investigación de incidentes, se amplía el tamaño máximoAlcanzaNo alcanzaComprobar la configuración y el número con ListLogComprobar la fecha del evento más antiguoCalcular los días reales de retención¿Alcanza el requisito?Mantener el tamaño actualAmpliar el tamaño máximoConfigurar con wevtutil sl o mediante GPO

Figura 14: Confirme cuántos días quedan realmente conservados y determine el tamaño máximo calculando hacia atrás a partir de los días que quiere poder consultar.

Además, entre las opciones de seguridad existe una configuración llamada «Auditoría: apagar el sistema inmediatamente si no se puede iniciar sesión de auditorías de seguridad» (la conocida como CrashOnAuditFail). Cuando está activada y el sistema deja de poder registrar la auditoría, el sistema se detiene con el error STOP C0000244. Es una configuración pensada para requisitos de autenticación en los que de ningún modo se puede perder el rastro de auditoría, y viene deshabilitada de forma predeterminada. El propio Microsoft advierte de que puede convertirse en un vector de denegación de servicio si un atacante genera deliberadamente una gran cantidad de eventos para detener el servidor, así que no debería activarse a la ligera en un entorno pequeño o mediano típico.19

Comportamiento cuando el registro se llenaLa configuración de retención tiene dos formas, sobrescritura y no sobrescritura, y cuando en el modo de no sobrescritura ya no se puede registrar la auditoría, si además está activada la configuración aparte CrashOnAuditFail, el sistema se detiene con el error STOP C0000244Modo de sobrescrituraSin sobrescribirSíEl registro Security alcanza el tamaño máximo¿Cuál es la configuración de retención?Se sobrescribe el evento más antiguoSe descarta el evento nuevoAmbos casos pueden dejar el registro sin lo que se busca¿También está activado CrashOnAuditFail?Se detiene con el error STOP C0000244

Figura 15: La configuración de retención sobrescribe o descarta. CrashOnAuditFail es una configuración aparte que detiene el sistema cuando ya no se puede registrar.

6. La práctica de la investigación — filtros, Get-WinEvent y exportación

6.1. Filtrado en el Visor de eventos

Para una investigación puntual, el Visor de eventos basta. Abra el registro Security y, con «Filtrar el registro actual», indique el ID de evento (por ejemplo, 4625) y el periodo. Las condiciones que se consultan repetidamente conviene guardarlas con «Crear vista personalizada»; a partir de entonces se accede con un solo clic. Si además del ID de evento quiere filtrar por una cuenta concreta, puede editar directamente la consulta XPath en la pestaña XML del cuadro de diálogo de filtro.

6.2. Extracción con Get-WinEvent

Para investigaciones con un gran número de registros, condiciones múltiples o ejecución periódica, conviene cambiar a Get-WinEvent de PowerShell. El punto clave es usar -FilterHashtable, que aplica el filtro del lado del servidor.9

Cuándo usar cada herramienta de investigaciónUna investigación puntual basta con el filtro del Visor de eventos, las condiciones que se consultan repetidamente se guardan en una vista personalizada, y las investigaciones con muchos registros, condiciones múltiples o ejecución periódica cambian a Get-WinEventPuntualCondición que se repiteGran volumen, múltiples condiciones, periódica¿Qué tipo de investigación es?Filtrar en el Visor de eventosGuardar en una vista personalizadaCambiar a Get-WinEventFiltrar con FilterHashtable

Figura 16: Puntual, el Visor de eventos; si se repite, una vista personalizada; con gran volumen, Get-WinEvent.

# Obtener los fallos de inicio de sesión (4625) de las últimas 24 horas
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# Dar forma de tabla a "quién, desde dónde y por qué"
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Si tiene a mano este patrón para extraer el EventData a partir de la representación XML del evento, puede reutilizarlo de la misma manera tanto para el 4624 como para el 4688. El diseño del filtrado en Get-WinEvent (cuándo usar FilterHashtable frente a XPath, cómo corregir consultas lentas) se trata en detalle en «Investigar el registro de eventos en la práctica con Get-WinEvent».

Patrón para extraer el EventDataLos eventos obtenidos con Get-WinEvent se convierten a su representación XML, se extraen los campos de EventData y se les da forma de tabla, y este mismo patrón se reutiliza tanto para el 4624 como para el 4688Obtener con Get-WinEventConvertir el evento a representación XMLExtraer el EventDataDar forma de tabla y agregarSe reutiliza igual para el 4624 o el 4688

Figura 17: El patrón de extraer el EventData de la representación XML y darle forma de tabla se puede reutilizar aunque cambie el ID de evento.

6.3. Exportación con wevtutil

El principio con el registro de la máquina objeto de investigación es exportarlo primero para asegurarlo, antes de que la sobrescritura lo elimine.10

rem Preservar todo el registro Security como archivo evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem Exportar filtrando solo el 4625 mediante XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

El archivo .evtx exportado se puede analizar de la misma manera en otra máquina con Get-WinEvent -Path C:\logs\security-20260801.evtx.9 El hábito de preservar primero y analizar después es la misma idea que «asegurar primero el volcado» en la investigación de bloqueos (vea «Introducción a la recolección de volcados de bloqueo de Windows»).

Flujo de preservación y posterior análisisEl registro Security de la máquina objeto de investigación se preserva exportándolo a un archivo evtx con wevtutil epl, se lleva a otra máquina y se analiza de la misma manera con la ruta de Get-WinEventMáquina objeto de investigaciónPreservar como evtx con wevtutil eplLlevarlo a otra máquinaAnalizar con Get-WinEvent -PathAsegurarlo antes de que la sobrescritura lo elimine

Figura 18: Primero preservar, luego analizar. Una vez asegurado en evtx, se puede investigar de la misma manera en otra máquina.

7. Trampas habituales — cuatro errores frecuentes en el terreno

(1) Información confidencial en la línea de comandos del 4688. Al activar el registro de la línea de comandos, los argumentos de todos los procesos quedan en el registro Security en texto plano. Microsoft indica explícitamente: «Cualquier usuario con acceso de lectura a los eventos de seguridad puede leer los argumentos de línea de comandos de cualquier proceso; los argumentos pueden contener información confidencial como contraseñas».12 Si existe aunque sea una sola aplicación de negocio o script que se inicie de forma parecida a myapp.exe /user:admin /password:P@ssw0rd, eso es una divulgación de información confidencial a todos los que puedan consultar el registro. Antes de activarlo, identifique y corrija los puntos donde se pasa información confidencial como argumento. La preservación y el destino de transferencia del registro también deberán manejarse con el mismo nivel de cuidado.

Orden para activar el registro de la línea de comandosEl registro de la línea de comandos del 4688 debe activarse solo después de identificar las aplicaciones de negocio o scripts que pasan información confidencial como argumento, corregir esos puntos, y exigir el mismo nivel de cuidado al destino de preservación y transferencia del registroExistenNo existenIdentificar el paso de información confidencial como argumento¿Existen casos?Corregir los puntos que la pasanActivar el registro de la línea de comandosEl destino de preservación y transferencia con el mismo cuidado

Figura 19: El registro de la línea de comandos se activa «después de identificar y corregir». Invertir el orden equivale a divulgar información confidencial.

(2) Operar sin conocer el comportamiento cuando el registro se llena. En modo de sobrescritura, el rastro antiguo desaparece silenciosamente; con la opción de no sobrescribir, se descartan los eventos nuevos; y con CrashOnAuditFail activado, se detiene todo el sistema (capítulo 5).1019 Lo correcto es conocer qué comportamiento se ha elegido y preparar un mecanismo de «recolectar antes de que desaparezca» (exportación periódica o una plataforma de recolección de registros).

(3) El registro que hay que revisar difiere entre el controlador de dominio y el equipo cliente. El 4624/4625 se registra en el equipo al que se accedió.56 Por otro lado, la validación de credenciales de una cuenta de dominio (el 4776 de NTLM) se registra en el equipo con autoridad sobre esas credenciales, es decir, en el DC si se trata de una cuenta de dominio7, y el fallo de preautenticación Kerberos (4771) solo se registra en el DC.8 «No hay 4625 en el servidor de archivos» no equivale a «no hubo ataque»: solo al contrastarlo también con el 4776/4771 del lado del DC se obtiene el panorama completo. Para saber cómo fluye cada protocolo de autenticación, consulte «NTLM y Kerberos explicados con diagramas».

(4) Sin sincronización horaria no se puede contrastar. El trabajo de alinear los registros de varias máquinas para seguir «en qué equipo apareció el 4625 justo antes de este 4740» presupone que los relojes de cada máquina están sincronizados. En un entorno de dominio, el propio Kerberos establece un límite para el desfase del reloj (5 minutos de forma predeterminada), y superarlo hace que la propia autenticación empiece a fallar.20 Desde el punto de vista de la investigación, incluso un desfase de unos pocos segundos, no digamos ya de 5 minutos, puede hacer leer mal el orden de los sucesos, así que incluya la comprobación del estado de sincronización de w32time al principio de su procedimiento de investigación. Además, la hora de registro de los eventos se guarda en UTC y se muestra según la zona horaria del equipo desde el que se consulta, así que no olvide convertir la zona horaria al leer un archivo evtx traído de una sede en el extranjero o de un servidor configurado en UTC.

La sincronización horaria como requisito de la investigación cruzadaContrastar los registros de varias máquinas en orden cronológico presupone que los relojes de cada máquina están sincronizados, un desfase de pocos segundos ya hace leer mal el orden de los sucesos, y un desfase superior a los 5 minutos predeterminados hace fallar la propia autenticación Kerberos, por lo que conviene comprobar w32time al principio del procedimientoSincronizadoDesfase de pocos segundosSupera los 5 minutos predeterminadosContrastar los registros de varias máquinasPresupone que los relojes están sincronizados¿Cuál es el desfase del reloj?Se puede seguir en orden cronológicoSe lee mal el orden de los sucesosFalla la autenticación KerberosComprobar w32time al principio del procedimiento

Figura 20: Contrastar varias máquinas presupone relojes sincronizados. Incluso un desfase de pocos segundos puede hacer leer mal el orden de los sucesos.

8. Resumen

  • La directiva de auditoría tiene dos sistemas, «básico» y «detallado», y mezclarlos produce resultados impredecibles. Unifique en el lado detallado y diseñe solo después de comprobar el estado actual con auditpol /get /category:*.
  • «Activarlo todo» mata la investigación con ruido e inflación. Tome como punto de partida las recomendaciones de referencia de Microsoft y empiece por la tabla de decisión del capítulo 3, centrada en el inicio de sesión, la administración de cuentas y la creación de procesos.
  • El 4624 se lee por el tipo de inicio de sesión, el 4625 por el código Status/Sub Status, el 4740 por el nombre del equipo de llamada y el 4688 por el proceso principal y la línea de comandos: cada evento tiene un punto clave, un «mire aquí».
  • El contenedor del registro (tamaño máximo, modo de retención) es la mitad del diseño de la auditoría. Compruebe cuántos días quedan realmente conservados, determine el tamaño calculando hacia atrás a partir del requisito, y exporte o centralice antes de que desaparezca.
  • Active el registro de la línea de comandos del 4688 solo después de revisar el riesgo de información confidencial. La diferencia en dónde se registra cada equipo y la sincronización horaria son condiciones previas para una investigación cruzada.
  • Empiece la investigación con el filtro del Visor de eventos; si se repite, use Get-WinEvent -FilterHashtable; para preservar, wevtutil epl. No rompa el orden de «primero preservar, luego analizar».

Artículos relacionados

Áreas de consultoría relacionadas

En KomuraSoft LLC atendemos consultas sobre la directiva de auditoría y el diseño de registros en entornos Windows, investigaciones de «cuándo, quién y qué hizo» basadas en el registro de eventos, y el análisis de la causa raíz de problemas que las aplicaciones de negocio provocan en torno a la autenticación y la auditoría. Puede empezar incluso desde la fase de «me han pedido que revise los registros, pero no sé por dónde empezar».

Referencias

</content>

  1. Microsoft Learn, Advanced security auditing FAQ. Sobre la diferencia entre la directiva de auditoría básica (9 configuraciones bajo las directivas locales) y la detallada, la equivalencia entre activar una categoría básica y activar todas las subcategorías correspondientes, la incompatibilidad entre ambas y la advertencia de no mezclarlas porque el uso combinado deja los resultados de auditoría en un estado impredecible, el borrado de la configuración de auditoría existente al aplicar el lado detallado mediante la directiva de grupo, la recomendación de activar «Auditoría: forzar la configuración de subcategoría de directiva de auditoría», y la conveniencia de identificar y acotar los recursos, actividades y usuarios importantes para minimizar el volumen de eventos. ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, auditpol. Sobre cómo el comando auditpol permite mostrar (/get), configurar (/set), hacer copia de seguridad a CSV (/backup), restaurar (/restore) y borrar (/clear) la directiva de auditoría del sistema. ↩ ↩2

  3. Microsoft Learn, System Audit Policy recommendations. Sobre la tabla de valores predeterminados de Windows, recomendaciones de referencia y recomendaciones reforzadas separadas por estación de trabajo y servidor, el hecho de que las recomendaciones son solo un punto de partida y cada organización debe evaluarlas y probarlas según su nivel de amenaza y tolerancia al riesgo, que la subcategoría de inicio de sesión tiene activados el éxito y el error de forma predeterminada desde Windows 10 1809, la importancia de vigilar no solo los servidores sino también las estaciones de trabajo, ejemplos de eventos que deberían alertar aunque ocurran una sola vez, como la incorporación inesperada de miembros a grupos con privilegios, y la idea de detectar picos de inicios de sesión fallidos comparándolos con una línea base. ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Sobre la posibilidad de una administración precisa con más de 40 subcategorías de auditoría, que mantener esta configuración activada es la mejor práctica y que el valor predeterminado activado (Enabled) se aplica a clientes, servidores miembro y DC, y la advertencia de que configuraciones que generan un gran volumen de eventos, como activar por completo la subcategoría de uso de privilegios, pueden dificultar encontrar otras entradas en el registro de seguridad y afectar significativamente al rendimiento. ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, 4624(S): An account was successfully logged on. Sobre que el 4624 se registra en el equipo al que se accedió en el momento de crear la sesión de inicio de sesión, la lista de tipos de inicio de sesión (2 = Interactive, 3 = Network, 4 = Batch, 5 = Service, 7 = Unlock, 8 = NetworkCleartext, 9 = NewCredentials, 10 = RemoteInteractive, 11 = CachedInteractive), el indicador de token elevado (Elevated Token), el paquete de autenticación (NTLM/Kerberos/Negotiate) y el Package Name de NTLM (NTLM V1/V2/LM), y la correlación con el 4672 y otros eventos mediante el ID de inicio de sesión. ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, 4625(F): An account failed to log on. Sobre que el 4625 se registra en el equipo donde se produjo el intento de inicio de sesión (el propio equipo, si el intento fue de un usuario en su terminal), que las subcategorías son bloqueo de cuenta e inicio de sesión, el significado de los códigos Status/Sub Status (0xC0000064 = nombre de usuario no válido, 0xC000006A = contraseña incorrecta, 0xC000006D = nombre de usuario o información de autenticación no válidos, 0xC000006F = fuera del horario permitido, 0xC0000070 = estación de trabajo no permitida, 0xC0000072 = cuenta deshabilitada, 0xC000015B = tipo de inicio de sesión no permitido, 0xC0000193 = cuenta caducada, 0xC0000234 = cuenta bloqueada), y que la repetición del código 0xC0000064 puede ser indicio de un ataque de enumeración de cuentas. ↩ ↩2 ↩3 ↩4 ↩5

  7. Microsoft Learn, 4776(S, F): The computer attempted to validate the credentials for an account. Sobre que el 4776 se registra en cada validación de credenciales mediante autenticación NTLM, que solo se registra en el equipo con autoridad sobre las credenciales (el controlador de dominio si es una cuenta de dominio, o el propio equipo local si es una cuenta local), y que se registran tanto el éxito como el error. ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, 4771(F): Kerberos pre-authentication failed. Sobre que el 4771 se registra en cada fallo de emisión de un TGT de Kerberos por parte del KDC (contraseña incorrecta, cuenta caducada, etc.), y que este evento solo se genera en el controlador de dominio. ↩ ↩2 ↩3 ↩4

  9. Microsoft Learn, Get-WinEvent (Microsoft.PowerShell.Diagnostics). Sobre la obtención de la configuración del registro (LogMode, MaximumSizeInBytes, RecordCount) mediante -ListLog, el filtrado eficiente especificando LogName, Id, StartTime, etc. como tabla hash mediante -FilterHashtable, la lectura de archivos .evtx guardados mediante -Path, y la obtención en orden ascendente o por cantidad de registros mediante -Oldest / -MaxEvents. ↩ ↩2 ↩3 ↩4

  10. Microsoft Learn, wevtutil. Sobre la configuración del tamaño máximo (/ms) y el modo de retención (/rt) mediante set-log (sl), que con el modo de retención en true los eventos existentes se conservan y se descartan los eventos nuevos cuando el registro se llena, mientras que con false los eventos nuevos sobrescriben los más antiguos, la exportación del registro de eventos a un archivo mediante export-log (epl) y su filtrado con consultas XPath a través de la opción /q, y la ejecución de consultas mediante query-events (qe). ↩ ↩2 ↩3 ↩4 ↩5

  11. Microsoft Learn, 4688(S): A new process has been created. Sobre que el 4688 se registra en cada inicio de un nuevo proceso, que incluye la cuenta que lo creó, la ruta del ejecutable del nuevo proceso, el nombre del proceso de origen (principal) y el tipo de elevación del token, y que el campo Process Command Line está vacío de forma predeterminada y solo se registra al activar la directiva de grupo «Incluir la línea de comandos en los eventos de creación de procesos». ↩ ↩2 ↩3

  12. Microsoft Learn, Command line process auditing. Sobre que el registro de la línea de comandos requiere tanto la auditoría de creación de procesos de la directiva de auditoría detallada como «Incluir la línea de comandos en los eventos de creación de procesos» (Plantillas administrativas > Sistema > Auditoría de creación de procesos, sin configurar de forma predeterminada), la advertencia de que al activarlo la información de línea de comandos de todos los procesos se registra en texto plano en el registro de eventos de seguridad y cualquier usuario con acceso de lectura puede leer argumentos que pueden contener información confidencial como contraseñas, y que si la directiva de auditoría detallada es sobrescrita por la configuración básica se registra el evento 4719, lo que se puede evitar con la configuración de «forzar». ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn, Audit Account Lockout. Sobre cómo la subcategoría de bloqueo de cuenta audita los fallos de inicio de sesión sobre una cuenta bloqueada, que el evento generado es el 4625 (F), que en esta subcategoría no existen eventos de éxito por lo que activar la auditoría de éxito no tiene sentido, y que se recomienda la auditoría de errores en todos los tipos de equipo. ↩

  14. Microsoft Learn, Audit Security Group Management. Sobre que es la subcategoría que audita la creación, modificación y eliminación de grupos de seguridad, así como el alta y la baja de miembros, que el ID de evento del alta/baja de miembros se divide según el tipo de grupo (grupo local 4732/4733, grupo global 4728/4729, grupo universal 4756/4757), que existen eventos exclusivos para grupos de dominio como el 4728, y que en esta subcategoría no existen eventos de error, por lo que se recomienda la auditoría de éxito en todos los tipos de equipo. ↩ ↩2

  15. Microsoft Learn, 4698(S): A scheduled task was created. Sobre que el 4698 se registra en cada creación de una tarea programada, que la subcategoría es otros eventos de acceso a objetos, que se registran el nombre de la tarea y el XML completo de la definición de la tarea, incluido el comando que ejecuta, y que se recomienda vigilar los eventos de creación de tareas, especialmente en los equipos importantes, porque el malware suele usar las tareas para persistir tras un reinicio. ↩ ↩2

  16. Microsoft Learn, 4740(S): A user account was locked out. Sobre que el 4740 se registra en cada bloqueo de una cuenta de usuario, que la subcategoría es administración de cuentas de usuario, y que el campo Caller Computer Name registra el nombre del equipo de origen del intento de inicio de sesión que provocó el bloqueo. ↩

  17. Microsoft Learn, 4720(S): A user account was created. Sobre que el 4720 se registra en el controlador de dominio, el servidor miembro o la estación de trabajo en cada creación de un nuevo objeto de usuario, y que la subcategoría es administración de cuentas de usuario. ↩

  18. Microsoft Learn, 1102(S): The audit log was cleared. Sobre que el evento 1102 se registra en cada borrado del registro de auditoría de seguridad de Windows. ↩

  19. Microsoft Learn, Audit: Shut down system immediately if unable to log security audits. Sobre que, con esta configuración activada, si no se pueden registrar las auditorías de seguridad el sistema se detiene con el mensaje STOP C0000244 {Audit Failed}, que el valor predeterminado es Disabled, que puede convertirse en un vector de denegación de servicio forzando deliberadamente el apagado mediante la generación de una gran cantidad de eventos de seguridad, y que la detención repentina puede dejar inutilizables los datos de las aplicaciones. ↩ ↩2

  20. Microsoft Learn, Maximum tolerance for computer clock synchronization. Sobre que, como Kerberos v5 usa marcas de tiempo como medida contra ataques de repetición, se establece una tolerancia máxima (5 minutos tanto de forma predeterminada como recomendada) para el desfase de reloj entre el cliente y el controlador de dominio, y que superarla hace que la marca de tiempo deje de considerarse auténtica. ↩

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Por qué aparecen registros 4624 y 4625 en el registro Security si no he configurado ninguna directiva de auditoría?
Porque Windows tiene subcategorías de auditoría activadas de forma predeterminada. Por ejemplo, la subcategoría «Inicio de sesión» tiene activados tanto los eventos de éxito como los de error de forma predeterminada desde Windows 10 versión 1809, de modo que 4624 (éxito) y 4625 (error) se registran sin necesidad de configurar nada. Sin embargo, con la configuración predeterminada no se registran muchos de los eventos que suelen necesitarse en una investigación, como la validación de credenciales (4776) o la creación de procesos (4688). Puede comprobar qué está activado en su entorno con auditpol /get /category:*. A partir de ahí, la práctica habitual consiste en activar explícitamente las subcategorías que falten desde la directiva de auditoría detallada.
Quiero investigar un fallo de inicio de sesión, pero no encuentro el 4625 en el registro Security del servidor correspondiente. ¿Dónde debo mirar?
Primero confirme el principio de que el 4625 se registra en «el equipo en el que se intentó el inicio de sesión». Si el fallo de inicio de sesión ocurrió en el equipo de un usuario, mire ese equipo; si el fallo fue al acceder a un servidor de archivos, mire el servidor de archivos. A continuación, compruebe con auditpol /get /category:* si la auditoría de errores de la subcategoría «Inicio de sesión» está activada. En el caso de cuentas de dominio, es frecuente que el registro quede en la validación de credenciales (4776) o en el fallo de preautenticación Kerberos (4771) del controlador de dominio, así que cuando no se pueda identificar el equipo de origen, suele ser más rápido investigar primero desde el controlador de dominio. Si aun así no lo encuentra, compruebe si el sobrescrito del registro ha eliminado los eventos antiguos (el tamaño máximo del registro y la fecha del evento más antiguo).
¿Debería activar el registro de la línea de comandos en la creación de procesos (4688)?
Su valor para la investigación es muy alto, pero es una configuración que debe activarse solo después de entender el riesgo que conlleva. Al activarla, los argumentos de la línea de comandos de todos los procesos se registran en texto plano en el registro Security. Si existe aunque sea un solo script o aplicación de negocio que pase contraseñas o claves de API en la línea de comandos, ese secreto queda visible para cualquiera que pueda leer el registro Security. El propio Microsoft advierte explícitamente de este punto. Se recomienda primero revisar si los scripts propios pasan información confidencial como argumentos de línea de comandos, corregir esos casos y solo entonces activar el registro, en ese orden.
¿Cuál debería ser el tamaño máximo del registro Security?
El enfoque correcto es calcularlo a partir de «cuántos días de historial quiero conservar»; no existe una cifra universal. Puede comprobar la configuración actual y el estado real con Get-WinEvent -ListLog Security, y la diferencia entre la fecha del evento más antiguo y la fecha actual es «el número de días que realmente se conservan ahora mismo». Como añadir subcategorías de auditoría también aumenta el volumen de eventos, es imprescindible volver a comprobar este número real de días conservados después de cualquier cambio de configuración. En la respuesta a incidentes no es raro necesitar registros de varias semanas o incluso meses atrás, así que conviene exportarlos periódicamente antes de que el sobrescrito los elimine, o centralizarlos en otra máquina mediante un mecanismo de recolección de registros.
¿Cómo se investiga la causa de un bloqueo de cuenta (4740)?
El campo «Nombre del equipo de llamada (Caller Computer Name)» del evento 4740 es la primera pista: en él queda registrado el equipo de origen del inicio de sesión fallido que desencadenó el bloqueo. Tenga en cuenta, sin embargo, que el registro del fallo en sí (4625) no queda en el equipo de origen, sino en el equipo que recibió el intento de inicio de sesión. Si el origen es un inicio de sesión de red, siga en orden cronológico el 4625 del servidor de destino o, en el caso de cuentas de dominio, el 4776/4771 del controlador de dominio. A continuación, en el equipo identificado como origen, revise todo lo que siga conservando credenciales antiguas después de un cambio de contraseña: credenciales guardadas, sesiones de escritorio remoto que quedaron desconectadas, y servicios o tareas programadas configurados con una contraseña antigua. Si el bloqueo se repite, compruebe también si hay algún desfase en la sincronización horaria.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog