Coge un Windows Server recién instalado, conéctale el agente de tu SIEM y espera un ataque. Vas a fallar. El registro de seguridad de esa máquina apenas contendrá inicios de sesión y algún cambio de cuenta suelto: nada de líneas de comandos, nada de acceso detallado a recursos compartidos, nada de bloques de PowerShell. La telemetría que permite escribir una regla de detección decente no llega activada de fábrica. Hay que decidirla, activarla subcategoría a subcategoría y comprobar que se aplicó de verdad, porque Windows tiene más de una forma de configurar la auditoría y no todas conviven bien entre sí.
Este módulo cubre la política de auditoría avanzada de Windows: sus diez categorías y las subcategorías que de verdad pagan la pena, cómo configurarlas por GPO y por línea de comandos, y los Event IDs que un analista de SOC mira todos los días (creación de procesos, inicios y fallos de sesión, cambios de cuenta, servicios nuevos, acceso a recursos compartidos, bloques de PowerShell). Es la auditoría del endpoint y del servidor miembro. El bastionado del controlador de dominio y la auditoría específica de objetos de Active Directory tienen su propio terreno en el curso de Defensa de Active Directory; aquí se queda fuera.
Qué aprenderás
- Por qué mezclar la política de auditoría básica con la avanzada rompe la configuración, y cómo evitarlo con la directiva de forzado de subcategorías.
- Las diez categorías de la política de auditoría avanzada y qué subcategorías de cada una conviene activar en un endpoint o en un servidor miembro.
- Configurar, respaldar y restaurar la política de auditoría con auditpol, y comprobar por línea de comandos lo que realmente quedó aplicado.
- Qué campos mirar en los Event ID 4688, 4624, 4625, 4648, 4672, 4697, 7045, 4720-4726, 4732, 1102, 5140 y 5145.
- La diferencia entre los tipos de inicio de sesión (Logon Type) de Windows y qué significa cada uno cuando aparece en un 4624 o en un 4625.
- Cómo activar el registro de bloques de script y de módulos de PowerShell, y qué se ve, y qué no, cuando el script llega ofuscado.
- Cómo dimensionar y rotar el canal Security para que la retención sea una decisión de detección y no un accidente de tamaño de disco.
Por qué la configuración por defecto no sirve para detectar
Windows arrastra dos sistemas de auditoría de seguridad que conviven mal entre sí. El primero, la política de auditoría básica, vive en Configuración del equipo → Configuración de Windows → Configuración de seguridad → Directivas locales → Directiva de auditoría, y tiene nueve directivas (inicio de sesión de cuenta, administración de cuentas, acceso a objetos, y unas pocas más). Cada una es una categoría entera: activar la auditoría de eventos de inicio de sesión audita a la vez el inicio de sesión interactivo, el de red, el de servicio y el de escritorio remoto, sin distinguir entre ellos.
El segundo sistema, la política de auditoría avanzada, vive en Configuración del equipo → Configuración de Windows → Configuración de seguridad → Configuración de directiva de auditoría avanzada, y descompone esas nueve directivas básicas en más de cuarenta subcategorías repartidas en diez categorías. Con ella puedes auditar el éxito de los inicios de sesión interactivos y solo el fallo de los de red, por separado, sin generar ruido del resto.
El problema aparece cuando conviven las dos configuraciones. Si una directiva de nivel de categoría queda definida (en la directiva local o en un GPO) y a la vez configuras subcategorías con auditpol, la configuración de categoría gana por defecto: la política por subcategorías solo se aplica de forma fiable si la categoría equivalente se deja sin definir. Microsoft resuelve esto con la directiva Auditoría: forzar la configuración de subcategoría de la directiva de auditoría (Windows Vista o posterior) para invalidar la configuración de categoría de la directiva de auditoría, situada en Configuración del equipo → Configuración de Windows → Configuración de seguridad → Directivas locales → Opciones de seguridad. Con esa directiva habilitada, la configuración de subcategoría manda siempre; los cambios se aplican sin reiniciar el equipo. Su valor por defecto es Habilitada en un servidor independiente, en un controlador de dominio y en una estación de trabajo, pero queda «no definida» en la directiva de dominio predeterminada y en la de controladores de dominio predeterminada, así que en un dominio real conviene comprobarlo, no darlo por hecho.
Microsoft es tajante con esto en su FAQ de auditoría avanzada: no uses a la vez la directiva de auditoría básica y la avanzada, porque el resultado en los informes de auditoría es impredecible. Si vienes de una configuración antigua con la básica y quieres pasar a la avanzada, hazlo de una vez, no a medias. Y si algún día necesitas volver atrás, no basta con poner las subcategorías en «no configurada»: hay que eliminar los ficheros audit.csv que la directiva de dominio deja en SYSVOL y reconfigurar la básica desde cero, o la básica no vuelve a aplicarse.
¿Y qué llega auditado de fábrica? Depende de la versión de Windows y del rol del equipo, así que la respuesta correcta no es una lista memorizada sino un comando:
auditpol /get /category:* /r > C:auditoriapolitica-actual.csvEse volcado te dice, subcategoría a subcategoría, qué hay activado ahora mismo en la máquina que tienes delante. Lo que casi nunca llega activado de fábrica, y que sí hace falta para escribir reglas de detección, es lo que ocupa el resto de este módulo: creación de procesos con línea de comandos, acceso detallado a recursos compartidos, cambios de cuenta con todos sus campos y el registro de bloques de PowerShell.
Las diez categorías de la política de auditoría avanzada
La referencia de Microsoft que agrupa estas categorías vive en el árbol archivado de documentación, con fecha de revisión del 6 de septiembre de 2021, aunque sigue siendo la página que Microsoft mantiene enlazada como fuente. Organiza la política de auditoría avanzada en diez categorías:
- Account Logon valida credenciales contra la base de cuentas (SAM local o controlador de dominio), no contra la sesión en sí; incluye Credential Validation y las subcategorías de Kerberos.
- Account Management cubre los cambios sobre cuentas de usuario, de equipo y grupos.
- Detailed Tracking cubre la creación y el fin de procesos, la actividad DPAPI, Plug and Play y las llamadas RPC.
- DS Access cubre el acceso y los cambios sobre objetos de Active Directory Domain Services, y se genera únicamente en controladores de dominio.
- Logon/Logoff cubre los inicios y cierres de sesión, los bloqueos de cuenta, las sesiones IPsec y los inicios de sesión especiales.
- Object Access cubre el acceso a ficheros, recursos compartidos, registro, objetos del kernel y el resto de objetos con lista de control de acceso del sistema (SACL).
- Policy Change cubre los cambios sobre la propia política de auditoría, de autenticación o de autorización.
- Privilege Use cubre el uso de privilegios sensibles, como depurar procesos o hacer copias de seguridad saltándose permisos.
- System cubre la carga de extensiones de seguridad, la instalación de servicios, los cambios de estado del sistema y la integridad del propio subsistema de auditoría.
- Global Object Access Auditing aplica SACL globales por tipo de objeto (todo el sistema de ficheros o todo el registro) en lugar de objeto a objeto.
De esas diez, en un endpoint o en un servidor miembro (no en un controlador de dominio) hay más o menos una docena de subcategorías que conviene activar sin pensarlo demasiado. La tabla siguiente resume qué generan y si Microsoft recomienda auditar éxito, fallo o ambos en sus páginas de referencia de cada subcategoría:
| Categoría | Subcategoría | Eventos principales | Auditar |
|---|---|---|---|
| Account Logon | Credential Validation | 4774, 4775, 4776, 4777 | Éxito y fallo (el fallo es el que delata fuerza bruta y enumeración de cuentas locales) |
| Detailed Tracking | Process Creation | 4688, 4696 | Éxito |
| Detailed Tracking | Process Termination | 4689 | Solo si hay una lista de procesos críticos que vigilar; si no, se queda corto frente a lo que aporta Process Creation |
| Logon/Logoff | Logon | 4624, 4625, 4648, 4675 | Éxito y fallo |
| Logon/Logoff | Special Logon | 4672, 4964 | Éxito |
| Logon/Logoff | Account Lockout | 4625 | Fallo (no genera eventos de éxito) |
| Account Management | User Account Management | 4720, 4722-4726, 4738, 4740, 4765-4767, 4780, 4781, 4794, 4798, 5376, 5377 | Éxito y fallo |
| Account Management | Security Group Management | 4731-4735, 4764, 4799 (y 4727-4730, 4754-4758 para grupos globales y universales en dominio) | Éxito |
| Policy Change | Audit Policy Change | 4715, 4719, 4817, 4902-4908, 4912 | Éxito |
| Privilege Use | Sensitive Privilege Use | 4673, 4674, 4985 | Éxito y fallo, pero el volumen es alto: acota por cuenta antes de activarlo en todas partes |
| System | Security System Extension | 4610, 4611, 4614, 4622, 4697 | Éxito |
| Object Access | File Share | 5140, 5142, 5143, 5144, 5168 | Éxito y fallo |
| Object Access | Detailed File Share | 5145 | Fallo siempre; éxito solo si el equipo no es un servidor de ficheros con tráfico alto |
Las subcategorías de Kerberos dentro de Account Logon (Kerberos Authentication Service, Kerberos Service Ticket Operations) y las cuatro de DS Access solo generan eventos en controladores de dominio. Son terreno del curso de Defensa de Active Directory, igual que la auditoría de replicación y de cambios sobre objetos de directorio.
Configuración por GPO y por línea de comandos
Por GPO, las subcategorías viven en Configuración del equipo → Directivas → Configuración de Windows → Configuración de seguridad → Configuración de directiva de auditoría avanzada → Directivas de auditoría del sistema, con una carpeta por cada una de las diez categorías. Cada subcategoría trae la casilla «Configurar los siguientes eventos de auditoría» con dos marcas independientes, éxito y fallo.
Por línea de comandos se usa auditpol, que trae subcomandos para consultar (/get), fijar (/set), listar los nombres exactos de categorías y subcategorías (/list), y hacer copia de seguridad y restauración de toda la política (/backup y /restore). Antes de fijar nada conviene listar el nombre exacto que Windows espera para esa subcategoría, porque no siempre coincide letra a letra con el título de la página de documentación:
auditpol /list /subcategory:"Detailed Tracking" /rCon los nombres confirmados, se activan una por una o en bloque:
auditpol /set /subcategory:"Process Creation" /success:enable /failure:disable
auditpol /set /subcategory:"Logon","Special Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management","User Account Management" /success:enableAntes de tocar nada en un sistema que ya está en producción, se respalda la política vigente, y si algo se tuerce se restaura en un solo comando:
auditpol /backup /file:C:auditoriapolitica-antes.csv
auditpol /restore /file:C:auditoriapolitica-antes.csvY para comprobar que lo que se aplicó por GPO (o por auditpol directamente) coincide con lo que se pretendía, se vuelve a consultar filtrando por categoría:
auditpol /get /category:"Detailed Tracking" /rActivar Process Creation no basta para que el 4688 traiga la línea de comandos: por defecto ese campo llega vacío. Hace falta activar, aparte, la directiva Administrative TemplatesSystemAudit Process CreationInclude command line in process creation events, en Configuración del equipo. Es uno de los descuidos más repetidos al montar telemetría de detección: la subcategoría está activa, el evento se genera, pero el campo que de verdad interesa para detectar ejecución con línea de comandos ofuscada llega en blanco.
Los Event ID que de verdad se usan en un SOC
4688: creación de procesos
Se genera cada vez que arranca un proceso nuevo, y es probablemente el evento con más peso específico de todo este módulo. Trae dos bloques de identidad (Creator Subject, la cuenta que lanzó el proceso, y Target Subject, cuando el contexto del proceso creado es distinto del de quien lo creó), el New Process ID y el New Process Name con la ruta completa del ejecutable, el Creator Process ID y el Creator Process Name del proceso padre, y el campo Process Command Line, que solo aparece si activaste la directiva de la sección anterior.
El Token Elevation Type distingue tres situaciones: %%1936 es un token completo sin restricciones (UAC desactivado, cuenta de sistema o Administrador integrado), %%1937 es un token elevado (el usuario aceptó «Ejecutar como administrador» o la aplicación exige privilegios máximos) y %%1938 es un token limitado (UAC activo, el usuario no elevó). Ver %%1936 en una cuenta de usuario normal, sin el signo $ de cuenta de equipo, suele significar que alguien desactivó UAC para esa cuenta, y merece preguntarse por qué. El campo Mandatory Label indica el nivel de integridad del proceso, desde S-1-16-0 (sin confianza) hasta S-1-16-16384 (integridad de sistema); ver S-1-16-20480 delata un proceso protegido, algo poco frecuente fuera de determinados servicios de Windows.
El New Process ID y el Creator Process ID permiten reconstruir el árbol de procesos completo cruzando eventos 4688 entre sí, que es la base de casi cualquier detección de ejecución con binarios legítimos del sistema, una de las familias de técnicas que cataloga la guía de MITRE ATT&CK.
4624 y 4625: quién entra y quién no
Ambos pertenecen a la subcategoría Logon y comparten el campo más útil para clasificar el acceso: el tipo de inicio de sesión. La siguiente tabla recoge los valores documentados por Microsoft para el 4624 (el 4625 documenta el mismo significado para los que llegan a aparecer en un intento fallido):
| Tipo | Nombre | Qué significa en la práctica |
|---|---|---|
| 0 | System | Solo lo usa la cuenta SYSTEM, por ejemplo al arrancar el equipo |
| 2 | Interactive | Alguien inició sesión delante de la máquina |
| 3 | Network | Acceso por red (una unidad compartida, por ejemplo), sin contraseña en claro |
| 4 | Batch | Tareas programadas ejecutándose sin intervención directa del usuario |
| 5 | Service | El Administrador de control de servicios arrancó un servicio con sus propias credenciales |
| 7 | Unlock | Se desbloqueó una estación de trabajo |
| 8 | NetworkCleartext | Acceso por red donde la contraseña llegó sin cifrar al paquete de autenticación |
| 9 | NewCredentials | Un proceso clonó su token actual con credenciales distintas para las conexiones salientes (el patrón típico de runas /netonly) |
| 10 | RemoteInteractive | Escritorio remoto (RDP) o Servicios de Terminal Server |
| 11 | CachedInteractive | Inicio de sesión con credenciales de dominio guardadas en caché, sin contactar al controlador de dominio |
| 12 | CachedRemoteInteractive | Igual que RemoteInteractive, uso interno de auditoría |
| 13 | CachedUnlock | Desbloqueo de estación de trabajo con credenciales cacheadas |
En el 4625, el bloque Failure Information trae Failure Reason, Status y Sub Status. Microsoft documenta varios códigos de estado que conviene reconocer de memoria: 0xC0000234 es cuenta bloqueada, 0xC000006A es contraseña incorrecta, 0xC0000064 es una cuenta que no existe (varios seguidos apuntan a enumeración de usuarios), 0xC0000072 es cuenta deshabilitada, 0xC0000193 es cuenta caducada y 0xC000015B señala que la cuenta no tiene concedido ese tipo de inicio de sesión en esa máquina.
El campo Logon ID de ambos eventos es la pieza de correlación: el mismo valor hexadecimal aparece en los 4688 que arrancan durante esa sesión, en un 4672 si la sesión recibió privilegios especiales y en un 4648 si desde ahí se usaron credenciales explícitas. Sin ese hilo, cada evento vive aislado; con él, se reconstruye la sesión completa.
4648: credenciales explícitas
Se genera cuando un proceso pide un inicio de sesión especificando de forma explícita las credenciales de otra cuenta, algo habitual en tareas programadas, en scripts que hacen runas o en accesos administrativos entre servidores. Trae dos identidades por separado: Subject (quién lanzó la petición) y Account Whose Credentials Were Used (la cuenta prestada), junto con Target Server Name y la información de red del destino. Correlacionado con el 4624 que suele seguirlo en la máquina destino a través del Logon GUID, este evento es de los primeros que se miran al reconstruir un movimiento lateral: una cuenta de servicio o un administrador saltando de equipo en equipo con las mismas credenciales prestadas una y otra vez.
4672: privilegios especiales
Se genera para cualquier sesión nueva a la que se le asignen privilegios sensibles: SeDebugPrivilege, SeBackupPrivilege, SeRestorePrivilege, SeTcbPrivilege, SeImpersonatePrivilege, SeLoadDriverPrivilege y el resto de la lista que Microsoft documenta para este evento. El propio fabricante avisa de que vas a ver muchos de estos, porque cualquier inicio de sesión de la cuenta SYSTEM lo dispara. Por eso conviene filtrar por Subject: si aparece SeDebugPrivilege o SeTcbPrivilege asignado a una cuenta que no es LOCAL SYSTEM, NETWORK SERVICE, LOCAL SERVICE ni un administrador esperado, merece revisión.
4697 y 7045: servicio nuevo
El 4697 pertenece a la subcategoría Security System Extension y vive en el canal Security; trae Service Name, Service File Name (con la ruta completa y los parámetros de línea de comandos si los tiene), Service Type, Service Start Type y Service Account. Microsoft lo introdujo a partir de Windows Server 2016 y Windows 10 como versión mínima de sistema operativo.
El 7045, con el nombre «New Service Installed», lo escribe el propio Administrador de control de servicios directamente en el canal System, no en Security, y así lo confirma la documentación de Microsoft Defender for Identity al listarlo entre los eventos necesarios para sus sensores. Al vivir en un canal distinto y estar escrito por un componente distinto del sistema operativo, funciona como una segunda fuente independiente del mismo hecho: si el canal Security rota más rápido de lo que tu pipeline de recolección tarda en leerlo, o si alguien lo limpia, el 7045 en System puede seguir ahí. La recomendación práctica es recoger los dos, no elegir uno.
4720-4726: ciclo de vida de cuentas
Seis eventos de la subcategoría User Account Management que cubren el ciclo de vida completo de una cuenta de usuario (y, varios de ellos, también de cuentas de equipo): 4720 cuando se crea, 4722 cuando se habilita, 4723 cuando se intenta cambiar la contraseña de una cuenta, 4724 cuando se intenta restablecerla, 4725 cuando se deshabilita y 4726 cuando se elimina. El 4720 en concreto trae un bloque largo de atributos (SAM Account Name, Display Name, User Principal Name, Password Last Set, Account Expires, Primary Group ID, y el campo New UAC Value con las marcas de control de cuenta activadas). Microsoft recomienda vigilar en particular cuando Password Last Set aparece como «nunca» en una cuenta recién creada, cuando Primary Group ID no es 513, o cuando alguna de las marcas de contraseña sin caducar, delegación confiable o autenticación Kerberos sin preautenticación aparece activada en una cuenta que no debería tenerla.
4732: alta en grupo local
Se genera cada vez que se añade un miembro a un grupo de seguridad local, uno por cada miembro añadido (si metes tres cuentas a la vez en Administradores locales, verás tres eventos 4732 seguidos). Trae el bloque Member (la cuenta que entra), el bloque Group (a qué grupo entra) y el Subject (quién hizo el cambio). El equivalente para grupos globales de dominio es el 4728, y para universales el 4756; comparten estructura de campos con el 4732, cambia el ámbito del grupo. Casi siempre aparece precedido de un 4735 (el grupo cambió) sin contenido relevante propio, así que el 4732 suele ser el evento que de verdad importa mirar.
1102: borrado del registro de seguridad
Este evento no depende de ninguna subcategoría de la política de auditoría avanzada: lo escribe directamente el proveedor Eventlog cuando alguien limpia el canal Security, y aparece siempre, esté configurada la auditoría que esté configurada. Trae un único bloque Subject con la cuenta que ejecutó la limpieza. Es, con diferencia, el indicador más directo de manipulación del propio registro de auditoría que existe en Windows: Microsoft advierte de que en circunstancias normales no deberías verlo nunca, y recomienda investigar siempre por qué se disparó. Por lo mismo conviene no depender solo de la copia local: si el 1102 llega a tu SIEM por reenvío en tiempo real, sobrevive aunque el atacante borre el log justo después de generarlo.
5140 y 5145: acceso a recursos compartidos
El 5140 (subcategoría File Share) se genera una vez por sesión, en el primer acceso a un recurso compartido, y trae ShareName, ShareLocalPath, la dirección IP y puerto de origen, y un Access Mask que en este evento siempre vale 0x1 (solo indica que hubo acceso de lectura o listado). El 5145 (subcategoría Detailed File Share) es más fino: se genera por cada fichero o carpeta comprobado dentro de un recurso compartido, trae Relative Target Name con la ruta relativa al recurso, el Access Mask completo con los permisos solicitados y un campo Access Reason que explica, con sintaxis SDDL, qué entrada de la lista de control de acceso concedió o denegó cada permiso. Un matiz importante del 5145: los eventos de fallo solo se generan cuando el acceso se deniega a nivel de recurso compartido, no cuando se deniega a nivel de sistema de ficheros (NTFS); si la denegación viene del NTFS, este evento no se entera.
Un barrido de muchos 5140 o 5145 de la misma sesión en poco tiempo, tocando muchos ficheros distintos, es uno de los patrones que se buscan para detectar un cifrado masivo de ransomware sobre un recurso compartido o una exfiltración por un recurso administrativo como IPC$.
PowerShell: registro de bloques de script y de módulos
PowerShell tiene su propio subsistema de auditoría, independiente de la política de auditoría de Windows, y sus eventos no aterrizan en el canal Security sino en Microsoft-Windows-PowerShell/Operational (así se llama en Windows PowerShell 5.1, la versión que trae Windows integrada; PowerShell 7 usa un canal distinto, PowerShellCore/Operational).
El registro de módulos (Module Logging, evento 4103) registra cada comando de la canalización a medida que se ejecuta: el cmdlet invocado, los parámetros con los que se llamó y, si el módulo está en la lista, la salida que produjo. Se activa con la directiva «Activar el registro de módulos» en Configuración del equipo → Plantillas administrativas → Componentes de Windows → Windows PowerShell, que en el registro corresponde a la clave SoftwarePoliciesMicrosoftWindowsPowerShellModuleLogging con el valor EnableModuleLogging; en la propia directiva se añade la lista de módulos a vigilar (o un asterisco para todos). El volumen que genera es alto, así que conviene decidir qué módulos importan de verdad en lugar de activarlo en bloque desde el primer día.
El registro de bloques de script (Script Block Logging, evento 4104) es distinto: registra el contenido completo de cada bloque de código que el motor de PowerShell compila antes de ejecutarlo, ya sea escrito de forma interactiva, cargado desde un fichero o generado en tiempo de ejecución. Se activa con «Activar el registro de bloques de scripts de PowerShell», en la misma ruta de la directiva de grupo, con la clave de registro SoftwarePoliciesMicrosoftWindowsPowerShellScriptBlockLogging y el valor EnableScriptBlockLogging. Cuando un atacante ofusca un comando con Base64, concatenación de cadenas o alias poco habituales, el registro de bloques de script no guarda el texto literal que escribió: guarda el bloque tal como lo procesa el intérprete, así que la cadena decodificada suele terminar apareciendo en el ScriptBlockText del evento, no la versión ofuscada de partida. Un mismo comando puede generar varios eventos 4104 encadenados, uno por cada bloque que el motor termina evaluando, y localizar el que de verdad contiene el payload es cuestión de leer la secuencia completa.
Los dos se activan juntos por consola de la siguiente forma (o por GPO, que en un entorno de dominio es la vía recomendada):
reg add "HKLMSoftwarePoliciesMicrosoftWindowsPowerShellScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f
reg add "HKLMSoftwarePoliciesMicrosoftWindowsPowerShellModuleLogging" /v EnableModuleLogging /t REG_DWORD /d 1 /fCuando el contenido registrado puede incluir contraseñas o datos sensibles de un script, Microsoft ofrece Protected Event Logging como capa adicional: cifra el contenido con una clave pública antes de escribirlo en el log, y solo quien tiene la clave privada (normalmente en el propio SIEM o en un servidor centralizado) puede leerlo después.
Tamaño, rotación y retención del canal Security
El canal Security tiene un tamaño máximo configurable (el valor de registro MaxSize, en bytes, siempre redondeado a un múltiplo de 64 KB) y un modo de retención que determina qué pasa al llegar a ese límite. Con el modo de sobrescritura activo, los eventos más antiguos se descartan para hacer sitio a los nuevos: si una subcategoría con volumen alto (Process Creation o Detailed File Share, por ejemplo) llena el canal en pocas horas, puedes perder justo la ventana de tiempo que necesitabas investigar sin que nadie te avise. Con el modo «no sobrescribir» activo pasa lo contrario y es peor: al llegar al límite, los eventos nuevos se descartan hasta que alguien vacíe el log a mano, así que el sistema deja de auditar en silencio mientras el resto del pipeline sigue creyendo que todo funciona.
Por eso el tamaño del canal Security no es una decisión de espacio en disco, es una decisión de detección: hay que dimensionarlo para que sobreviva, como mínimo, el tiempo que tarda tu pipeline de recolección en leerlo y el margen que necesitas para investigar si ese pipeline se cae. Si el SIEM recoge cada pocos minutos, el log local solo necesita sobrevivir un poco más que ese intervalo en condiciones normales; si el reenvío falla un fin de semana, necesita aguantar hasta el lunes.
Por línea de comandos se consulta y se fija con wevtutil. El tamaño mínimo que acepta la herramienta son 1.048.576 bytes (1024 KB) y siempre se redondea a múltiplos de 64 KB:
wevtutil gl Security
wevtutil sl Security /ms:1073741824 /rt:falseEl ejemplo anterior deja el canal Security en 1 GB con sobrescritura de los eventos más antiguos, que es el modo que usa la mayoría de configuraciones reales combinado con un reenvío continuo hacia el SIEM. CIS Benchmarks publica valores mínimos recomendados de tamaño para este canal según el rol del equipo; no reproduzco esa tabla aquí porque el uso gratuito de CIS Benchmarks está limitado a fines no comerciales y este sitio lleva publicidad, así que consúltala directamente si necesitas una cifra concreta para tu política de bastionado.
Ejercicio: política de auditoría mínima viable
El objetivo es aplicar un subconjunto pequeño pero útil de la política de auditoría avanzada en una máquina de laboratorio, generar un 4688 y un 4624 reales y localizarlos, con sus campos, en tu SIEM. Vale cualquier Windows con acceso de administrador: una VM de evaluación gratuita de Windows Server o de Windows 11, o el laboratorio que ya tengas montado de módulos anteriores.
- Respalda la política actual antes de tocar nada, y activa Process Creation, Logon y Special Logon:
auditpol /backup /file:C:auditoriapolitica-original.csv
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable- Abre gpedit.msc (o el editor de directivas de grupo local) y navega a Configuración del equipo → Plantillas administrativas → Sistema → Creación de auditoría de procesos → Incluir la línea de comandos en los eventos de creación de procesos, y habilítala. Aplica los cambios:
gpupdate /force- Genera los dos eventos: cierra sesión y vuelve a iniciarla (o desbloquea la estación) para el 4624, y lanza un comando cualquiera con parámetros para el 4688, por ejemplo:
whoami /all- Localízalos. Con wevtutil, sobre el propio equipo:
wevtutil qe Security /q:"*[System[(EventID=4688 or EventID=4624)]]" /f:text /c:20 > C:auditoriaeventos-lab.txtSi tu laboratorio ya tiene un agente de recolección instalado, añade el canal Security a su configuración y busca por EventID 4688 y EventID 4624 desde la consola del propio SIEM; el nombre exacto de cada campo cambia según el analizador que use tu herramienta (unos lo llaman CommandLine, otros ProcessCommandLine), pero el contenido del evento es el mismo que acabas de generar. Verifica en tu propio entorno los valores exactos que aparecen: no hay una salida universal, porque dependen del hostname, de la cuenta y de la hora de tu laboratorio.
- Correlaciona: apunta el Logon ID (SubjectLogonId) del 4624 de tu sesión y búscalo en los eventos 4688 que generaste después. Deberían compartirlo, porque es el hilo que une «quién entró» con «qué ejecutó» dentro de la misma sesión de Windows.
- Cuando termines, restaura la política original para dejar la máquina como estaba:
auditpol /restore /file:C:auditoriapolitica-original.csvPreguntas frecuentes
¿Hace falta reiniciar el equipo después de cambiar la política de auditoría avanzada?
No. Los cambios aplicados por GPO se recogen con un gpupdate /force (o en el siguiente ciclo automático de actualización de directivas) y los que se aplican directamente con auditpol surten efecto de inmediato, sin reiniciar. La propia documentación de Microsoft sobre la directiva de forzado de subcategorías lo confirma para ese caso concreto. Lo que sí conviene hacer siempre es comprobar con auditpol /get que lo que se pretendía configurar quedó realmente aplicado, sobre todo si hay varios GPO compitiendo por la misma subcategoría.
¿Por qué mis eventos no coinciden con lo que configuré por GPO?
El sospechoso habitual es la convivencia entre la política de auditoría básica y la avanzada sin la directiva de forzado de subcategorías activada, o el valor de registro SCENoApplyLegacyAuditPolicy interfiriendo con lo que aplica el propio GPO. Revisa primero si hay alguna directiva heredada de un nivel superior de Directorio Activo definiendo la misma subcategoría con un valor distinto: cuando varios GPO tocan la misma subcategoría, gana el de mayor prioridad en el orden de aplicación, no necesariamente el que acabas de editar.
¿La auditoría avanzada solo funciona en Windows Server, o también en estaciones de trabajo?
Funciona igual en todas las versiones de Windows compatibles, tanto servidor como cliente; no hay diferencias de capacidades entre unas y otras. Lo que sí cambia es el volumen esperado de cada subcategoría según el rol: Credential Validation, por ejemplo, genera mucho más tráfico en un controlador de dominio que en una estación de trabajo aislada, simplemente porque por ahí pasan muchas más autenticaciones.
¿Por qué el Event ID 4688 no trae la línea de comandos aunque activé Process Creation?
Porque son dos configuraciones distintas. Activar la subcategoría Process Creation hace que el evento se genere; que el campo Process Command Line venga relleno depende de una directiva aparte, Incluir la línea de comandos en los eventos de creación de procesos, que por defecto está desactivada y deja ese campo vacío.
¿El evento 7045 sustituye al 4697, o hacen falta los dos?
Hacen falta los dos, y no cuesta nada recogerlos juntos. El 4697 vive en el canal Security, depende de que la subcategoría Security System Extension esté activa y trae más detalle sobre la cuenta que instaló el servicio. El 7045 lo escribe el Administrador de control de servicios directamente en el canal System, sin depender de esa subcategoría, así que sigue funcionando como fuente redundante si el canal Security se llena, rota o alguien intenta limpiarlo.
¿Qué tamaño le pongo al canal Security?
No hay una cifra universal correcta: depende de cuántas subcategorías tengas activas, de cuántos eventos por segundo generan tus servidores más ruidosos y de cada cuánto los recoge tu SIEM. La forma de razonarlo es al revés de como se suele plantear: no es «cuánto disco le puedo dar», es «cuánto tiempo necesito que sobreviva localmente si el reenvío al SIEM se cae». Con esa cifra en la cabeza, wevtutil sl Security /ms:<bytes> fija el tamaño y /rt:false deja la sobrescritura activada, que es el modo recomendado cuando ya hay un reenvío en marcha.