yamato-security/enablewindowslogsettingsDocumentación y scripts para habilitar correctamente los registros de eventos de Windows.
Esta es otra guía más sobre cómo configurar y supervisar correctamente los registros de eventos de Windows, con énfasis en el registro para las reglas de sigma.
Este es un trabajo en curso, así que por favor vuelve periódicamente para ver las actualizaciones.
Zach Mathis (@yamatosecurity). A medida que realice más investigaciones y pruebas, planeo actualizar esto periódicamente, ya que hay mucho margen de mejora (tanto en la documentación como en la creación de más reglas de detección). Las PRs son bienvenidas y con gusto te agregaré como colaborador. Si encuentras algún error en esta documentación, por favor házmelo saber y lo corregiré lo antes posible.
Si encuentras algo de esto útil, por favor da una estrella en GitHub, ya que probablemente me ayudará a motivarme para seguir actualizando esto.
La mayor parte de la información proviene de las Preguntas frecuentes sobre auditoría de seguridad avanzada de Microsoft, las reglas de sigma, la Guía de registro de eventos de ACSC y mi propia investigación/pruebas. Me gustaría agradecer especialmente a la comunidad de sigma por hacer que la detección de amenazas sea de código abierto y gratuita para el beneficio de todos los defensores.
Por defecto, Windows no registrará muchos eventos necesarios para detectar actividad maliciosa y realizar investigaciones forenses.
Además, el tamaño máximo predeterminado para los archivos de eventos es de solo 20 MB para los registros clásicos (Security, System, Application), 15 MB para PowerShell y apenas 1 MB para casi todos los demás registros, por lo que hay una alta probabilidad de que la evidencia se sobrescriba con el tiempo.
Se ha incluido un simple script por lotes en este repositorio para permitir a los administradores de sistemas configurar fácilmente sus máquinas Windows de modo que tengan los registros que necesitan cuando ocurra un incidente. Para redes grandes, probablemente quieras usar este documento como referencia y configurar tus puntos finales con Directiva de grupo y/o InTune.
Recomiendo encarecidamente mejorar la configuración predeterminada de registro de eventos de Windows y hago todo lo posible por proporcionar la información más precisa. Sin embargo, no me hago responsable de ningún efecto adverso por habilitar demasiado registro ni de la exactitud de nada en este repositorio. Es tu responsabilidad comprender y probar cualquier cambio que hagas en tus sistemas en máquinas de prueba antes de implementarlo en producción. Recomiendo activar la mayor cantidad de registro posible en máquinas de prueba que imiten tu entorno durante al menos una semana y luego confirmar si hay eventos que estén generando demasiado ruido o si hay eventos que deseas pero que no se están generando.
Puedes ver el número total y el porcentaje de ID de eventos en un archivo evtx con el comando de métricas de ID de eventos de Hayabusa.
Ejemplo: hayabusa.exe eid-metrics -f path/to/Security.evtx
Process Creation, que rastrea qué procesos se ejecutan en un sistema.
Actualmente, alrededor de la mitad de las reglas de detección de Sigma dependen de este evento.
Esto se puede lograr instalando Sysmon (ID de evento 1) o habilitando el ID de evento 4688 del registro de seguridad integrado.
Sysmon 1 proporcionará información detallada como hashes y metadatos del ejecutable, por lo que es ideal, pero en caso de que Sysmon no pueda instalarse, es posible usar los registros Security 4688 integrados. Sin embargo, es importante que el registro de línea de comandos también esté habilitado, ya que muchas reglas de detección dependen de esto. Desafortunadamente, Security 4688 no proporciona información tan detallada como los registros de creación de procesos de Sysmon, por lo que no todas las reglas de Process Creation funcionan con Security 4688.
¡Aproximadamente solo el 10~20% de las reglas de sigma se pueden usar con la configuración de auditoría predeterminada de Windows!
Esto no es práctico para hacer a gran escala, pero la forma más fácil de habilitar/deshabilitar registros y verificar y/o configurar su tamaño máximo de archivo es haciendo clic derecho en el registro en el Visor de eventos y abriendo Properties.
Puedes usar el comando integrado wevtutil.
Ejemplo: wevtutil sl Security /ms:1073741824 para aumentar el tamaño máximo del archivo del registro de seguridad a 1 GB.
Ejemplo:```powershell $sysmon = Get-WinEvent -ListLog Microsoft-Windows-Sysmon/Operational $sysmon.MaximumSizeInBytes = 2048000000 #2GB $sysmon.SaveChanges()
## Opción 4: Directiva de grupo
Es sencillo aumentar el tamaño máximo de archivo de los registros de eventos clásicos como `Security`, `System` y `Application`; sin embargo, lamentablemente necesitas instalar plantillas administrativas y/o modificar directamente el registro para cambiar el tamaño máximo de archivo de los demás registros. Puede ser más fácil aumentar el tamaño de archivo con un script por lotes o de PowerShell al iniciar.
# Script de configuración
Se ha proporcionado un script para aumentar el tamaño máximo de archivo y habilitar los registros adecuados: [YamatoSecurityConfigureWinEventLogs.bat](https://github.com/yamato-security/enablewindowslogsettings/blob/HEAD/YamatoSecurityConfigureWinEventLogs.bat)
# Configuración de los ajustes de registro
## Registro de Sysmon (1382 reglas sigma)
Archivo: `Microsoft-Windows-Sysmon%4Operational.evtx`
Configuración predeterminada: `No instalado`
Instalar y configurar Sysmon es lo mejor que puedes hacer para aumentar tu visibilidad en los endpoints de Windows, pero requerirá planificación, pruebas y mantenimiento. Este es un tema amplio en sí mismo, por lo que queda fuera del alcance de este documento por ahora.
Consulta los siguientes recursos:
* [TrustedSec Sysmon Community Guide](https://github.com/trustedsec/SysmonCommunityGuide)
* [Sysmon Modular](https://github.com/olafhartong/sysmon-modular)
* [Florian Roth's updated fork of the Swift On Security's sysmon config file](https://github.com/Neo23x0/sysmon-config)
* [Ion-storm's updated fork of the Swift On Security's sysmon config file](https://github.com/ion-storm/sysmon-config)
* [Cyb3rWard0g's sysmon config file](https://github.com/OTRF/Blacksmith/blob/master/resources/configs/sysmon/sysmon.xml)
## Registro de seguridad (1045 reglas sigma (903 reglas de creación de procesos + 142 reglas adicionales))
Archivo: `Security.evtx`
Configuración predeterminada: `Habilitado parcialmente`
El registro de seguridad es el más complejo de configurar, por lo que he creado un documento aparte para él: [ConfiguringSecurityLogAuditPolicies.md](https://github.com/yamato-security/enablewindowslogsettings/blob/HEAD/ConfiguringSecurityLogAuditPolicies.md)
## Registros de PowerShell (175 reglas sigma)
Archivo: `Microsoft-Windows-PowerShell%4Operational.evtx`
### Registro de módulos (30 reglas sigma)
Activar el registro de módulos habilitará el ID de evento `4103`.
El registro de módulos tiene la ventaja de que puede ejecutarse en sistemas operativos y versiones de PowerShell más antiguos: PowerShell 3.0 (Win 7+). Otro beneficio es que registra tanto el comando de PowerShell ejecutado como los resultados. La desventaja es que generará un número extremadamente alto de eventos.
Por ejemplo, si un atacante ejecuta Mimikatz, ¡creará 7 MB de registros con más de 2000 eventos!
#### Habilitar el registro de módulos
Configuración predeterminada: `Sin auditoría`
##### Opción 1: Habilitar mediante directiva de grupo
En el editor de directivas de grupo (`gpedit.msc`), abre `Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell` y habilita `Turn on Module Logging`.
En el panel `Options`, haz clic en el botón `Show...` para configurar qué módulos se registrarán.
Ingresa `*` en el cuadro de texto `Value` para registrar todos los módulos.
##### Opción 2: Habilitar mediante el registro```
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames → * = *
Configuración predeterminada: En Win 10/2016+, si un script de PowerShell es marcado como sospechoso por AMSI, se registrará con un nivel de Advertencia.
Activar el registro de bloques de scripts habilitará el ID de evento 4104. Si activas Registrar eventos de inicio/fin de invocación de bloques de scripts, también se habilitarán los EID 4105 y 4106, sin embargo, esto no se recomienda ya que solo generará ruido.
El registro de bloques de scripts es compatible de forma predeterminada en PowerShell 5.0+ (Win 10+), aunque puedes habilitarlo en sistemas operativos más antiguos (Win 7+) si instalas .NET 4.5 y WMF 4.0+.
Desafortunadamente, el tamaño máximo de un único registro de eventos de Windows es de 32 KB, por lo que cualquier script de PowerShell mayor que este se fragmentará en bloques de 32 KB.
Si tienes el archivo PowerShell Operational.evtx original, puedes usar la herramienta block-parser para desfragmentar estos registros en un único archivo de texto fácilmente legible.
Un aspecto positivo del registro de bloques de scripts es que incluso si un script malicioso está ofuscado con XOR, Base 64, ROT13, etc... el script decodificado se registrará, lo que facilita mucho el análisis.
Los registros son más razonables de trabajar que el registro de módulos, ya que si un atacante ejecuta Mimikatz, solo se generarán 5 MB y 100 eventos en comparación con los 7 MB y más de 2000 eventos.
Sin embargo, la salida de los comandos no se registra con el registro de bloques de scripts.
En el editor de directivas de grupo, abre Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell y habilita Turn on PowerShell Script Block Logging.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1
Configuración predeterminada: Sin auditoría
También es posible guardar los registros de PowerShell en archivos de texto en el equipo local con los registros de transcripción. Aunque un atacante generalmente puede eliminar fácilmente los registros de transcripción para el anti-forense, puede haber escenarios donde el atacante borre todos los registros de eventos pero no busque los registros de transcripción para eliminarlos. Por lo tanto, se recomienda habilitar también los registros de transcripción si es posible. De forma predeterminada, se guardan en la carpeta de documentos del usuario. Idealmente, los registros de transcripción deberían guardarse en un recurso compartido de red de solo escritura, sin embargo, esto puede ser difícil de implementar en la práctica. Una ventaja de los registros de transcripción es que incluyen la marca de tiempo y los metadatos de cada comando y son muy eficientes en almacenamiento, con menos de 6 KB para la ejecución de Mimikatz. La desventaja es que los registros de transcripción solo registran lo que aparece en la terminal de PowerShell.
En el editor de directivas de grupo, abre Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell y habilita Turn on PowerShell Transcription.
Luego, especifica el directorio de salida.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)
### Referencias
* [Blog de Mandiant: Mayor visibilidad a través del registro de PowerShell](https://www.mandiant.com/resources/blog/greater-visibilityt)
## Registro del sistema (55 reglas sigma)
Archivo: `System.evtx`
Configuración predeterminada: `Habilitado. 20 MB`
Configuración recomendada: `Habilitado. 128 MB+`
El malware a menudo instala servicios para persistencia, escalada de privilegios local, etc... los cuales se pueden encontrar en este registro.
También es posible detectar aquí diversas vulnerabilidades siendo explotadas.
> **Nota: Algo a tener en cuenta específico del registro del sistema es que los parámetros en los campos a veces se traducen al idioma local, por lo que las firmas que usan solo inglés pueden no detectar en sistemas que no son en inglés. Por ejemplo, en un sistema en inglés, en los parámetros para EID 7045, registrará `Enabled`, mientras que en japonés podría registrar `有効`.**
> **Nota: Al igual que el registro `Application`, múltiples proveedores registran en el mismo ID de evento, por lo que puede necesitar filtrar también por nombre de proveedor además del canal. Un ejemplo es el ID de evento `1`, que es utilizado por varios proveedores para diferentes eventos.**
IDs de eventos importantes:
| Event ID | Descripción | Reglas Sigma | Reglas Hayabusa | Nivel | Notas |
| :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | Suspensión/Hibernación del sistema | 0 | Aún no | Info | Proveedor: `Power-Troubleshooter` |
| 1 | Cambio de hora del sistema | 0 | Aún no | Info | Proveedor: `Kernel-General` |
| 12 | Inicio del SO | 0 | Aún no | Info | |
| 13 | Apagado del SO | 0 | Aún no | Info | |
| 16 | Historial de acceso al hive del Registro borrado | 2 | Aún no | Alta~Crítico | Los volcadores de contraseñas pueden borrar el historial de acceso después de extraer los hashes de contraseñas de la clave de registro SAM. Sin embargo, esto también ocurre normalmente, por lo que hay que filtrar los falsos positivos. |
| 55 | Sistema de archivos NTFS corrupto | 1 | No | Alta | Puede detectar ataques contra vulnerabilidades de NTFS. |
| 104 | Registro de eventos del sistema borrado | 1 | Sí | Media | |
| 6005 | Servicio de registro de eventos iniciado | 0 | Sí | Info | |
| 6006 | Servicio de registro de eventos detenido | 0 | Sí | Info | |
| 6008 | Apagado inesperado | 0 | Sí | Info | |
| 6038 | Se usó NTLMv1 | 1 | No | Baja | |
| 7031 | Servicio bloqueado | 0 | Sí | Baja | |
| 7034 | Servicio bloqueado | 0 | Sí | Baja | |
| 7036 | Servicio iniciado/detenido | 2 | Sí | Info~Alta | Puede usarse para detectar a alguien que detiene Defender, etc. |
| 7040 | Tipo de inicio del servicio cambiado | 0 | Sí | Info | Puede indicar que un atacante deshabilitó un servicio. |
| 7045 | Instalación de servicio | 37 | Sí | Info~Crítico | Este es el ID de evento del sistema más importante, ya que el malware a menudo se instala a sí mismo como un servicio o abusa de los servicios. |
| 20001 | Nuevo dispositivo PNP | 0 | Sí | Info~? | El nivel dependerá de si los dispositivos USB están permitidos o no. Solo registra la primera vez que un dispositivo se ha conectado. Los eventos de dispositivos PNP no USB son muy ruidosos, por lo que probablemente deberían filtrarse. |
## Registro de aplicación (16 reglas sigma)
Este registro es en su mayoría ruido, pero puede encontrar alguna evidencia importante aquí.
Algún software antivirus de terceros registrará aquí.
Una cosa a tener cuidado con el registro de aplicación es que diferentes proveedores usarán los mismos ID de evento para diferentes eventos, por lo que debe filtrar no solo por ID de evento sino también por nombres de proveedor.
Archivo: `Application.evtx`
Configuración predeterminada: `Habilitado. 20 MB`
Configuración recomendada: `Habilitado. 128 MB+`
IDs de eventos importantes:
| Event ID | Proveedor | Descripción | Reglas Sigma | Reglas Hayabusa | Nivel | Notas |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | `Audit-CVE`, `Microsoft-Windows-Audit-CVE` | Intento de explotación de vulnerabilidad conocida (CVE) | 1 | No | Crítico | Detecta eventos generados por aplicaciones en modo usuario cuando llaman a la API CveEventWrite cuando se intenta explotar una vulnerabilidad conocida. MS comenzó a usar este registro en 2020/01 con CVE-2020-0601 (una vulnerabilidad de Windows CryptoAPI). Desafortunadamente, ese es prácticamente el único caso de CVEs que se escriben en este registro. |
| 325 | `ESENT` | Base de datos ESE creada | 2 | No | Info~Crítico | Detecta cuando un proceso crea una base de datos ESE. Esto se usa para una variedad de cosas, como Exchange, AD, Servicios de certificados, SRUM, etc. La base de datos ESE más importante para la seguridad es NTDS.dit, el archivo de los hashes de contraseñas de todos los usuarios del dominio ubicado en los controladores de dominio. Hay dos reglas sigma para detectar el volcado de NTDS.dit; sin embargo, puede ser un falso positivo si un administrador usa ntdsutil para respaldos o cuando se crean copias sombra. |
| 326 | `ESENT` | Base de datos ESE adjunta | 1 | No | Info~Crítico | Puede detectar el acceso a NTDS.dit. |
| 1000, 1001 | `Application Error`, `Windows Error Reporting` | Error de aplicación | 1 | No | Info~Alta | |
| 1034, 11724 | `MsiInstaller` | Aplicación desinstalada | 1 | No | Info~Baja | |
| 1040 | `MsiInstaller` | Instalación de aplicación | 1 | No | Info~Media | |
| 33205 | `MSSQLSERVER` | Evento de auditoría SQL | 6 | No | Info~Alta | Puede detectar backdoors de MSSQL, inyección SQL/de comandos, etc. |
## Registro operativo de Windows Defender (10 reglas sigma)
Archivo: `Microsoft-Windows-Windows Defender%4Operational.evtx`
Configuración predeterminada: `Habilitado. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
Puede detectar no solo las alertas de Windows Defender (que son importantes de monitorear), sino también exclusiones que se agregan, protección contra manipulaciones que se deshabilita, historial eliminado, etc.
## Registro operativo de Bits-Client (6 reglas sigma)
Archivo: `Microsoft-Windows-Bits-Client%4Operational.evtx`
Configuración predeterminada: `Habilitado. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
Bitsadmin.exe es un [lolbin](https://lolbas-project.github.io/lolbas/Binaries/Bitsadmin/) popular del que los atacantes abusan para descargar y ejecutar malware.
Puede encontrar evidencia de eso en este registro, aunque habrá muchos falsos positivos a los que prestar atención.
## Registro del firewall (6 reglas sigma)
Archivo: `Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx`
Configuración predeterminada: `¿Habilitado? 1 MB`
Configuración recomendada: `Habilitado. 256 MB+`
Aquí puede encontrar evidencia de reglas de firewall que se agregan/modifican/eliminan.
El malware suele agregar reglas de firewall para asegurarse de poder comunicarse con su servidor C2, agregar reglas de proxy para movimiento lateral, etc.
## Registro operativo de NTLM (3 reglas sigma)
Archivo: `Microsoft-Windows-NTLM%4Operational.evtx`
Configuración predeterminada: `Habilitado pero la auditoría está deshabilitada. 1 MB`
Este registro se recomienda habilitarlo si desea deshabilitar la autenticación NTLM.
Deshabilitar NTLM muy probablemente romperá algunas comunicaciones, por lo que puede monitorear este registro en los DC y otros servidores para ver quién sigue usando NTLM y deshabilitar NTLM gradualmente comenzando con esos usuarios antes de deshabilitarlo globalmente.
Es posible detectar el uso de NTLM para conexiones entrantes en eventos de inicio de sesión como 4624, pero necesita habilitar este registro si desea monitorear quién realiza conexiones NTLM salientes.
Para habilitar la auditoría, en Directiva de grupo abra `Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options` y configure las diversas opciones adecuadas de `Network security: Restrict NTLM:`.
Referencia: [Adiós NTLM](https://www.scip.ch/en/?labs.20210909)
## Registros KernelMode y UserMode de Security-Mitigations (2 reglas sigma)
Archivos: `Microsoft-Windows-Security-Mitigations%4KernelMode.evtx`, `Microsoft-Windows-Security-Mitigations%4UserMode.evtx`
Configuración predeterminada: `Habilitado. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
Por el momento solo hay 2 reglas sigma para estos registros, pero probablemente debería estar recopilando y monitoreando todos los registros de Exploit Protection, Network Protection, Controlled Folder Access y Attack Surface Reduction (alrededor de 40+ ID de eventos).
Desafortunadamente, los registros de Attack Surface Reduction (anteriormente WDEG (Windows Defender Exploit Guard) y EMET) están distribuidos en múltiples registros y requieren consultas XML complejas para buscarlos.
Detalles: [Comprender y usar las capacidades de reducción de superficie de ataque](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/overview-attack-surface-reduction?view=o365-worldwide)
## Registros de PrintService (2 reglas sigma)
También se recomienda habilitar el registro operativo para detectar ataques contra Print Spooler. (Ej.: PrintNightmare, etc.)
### Admin (1 regla sigma)
Archivo: `Microsoft-Windows-PrintService%4Admin.evtx`
Configuración predeterminada: `Habilitado. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
### Operativo (1 regla sigma)
Archivo: `Microsoft-Windows-PrintService%4Operational.evtx`
Configuración predeterminada: `Deshabilitado. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
## Registro de seguridad de SMBClient (2 reglas sigma)
Archivo: `Microsoft-Windows-SmbClient%4Security.evtx`
Configuración predeterminada: `Habilitado. 8 MB`
Configuración recomendada: `Habilitado. 128 MB+`
Se utiliza para intentar detectar PrintNightmare (inicio de sesión de invitado SMB sospechoso rechazado desde una IP) y usuarios que montan recursos compartidos ocultos.
## Registros de AppLocker (1 regla sigma)
Archivos: `Microsoft-Windows-AppLocker%4MSI and Script.evtx`, `Microsoft-Windows-AppLocker%4EXE and DLL.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Deployment.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Execution.evtx`
Configuración predeterminada: `¿Habilitado si AppLocker está habilitado? 1 MB`
Configuración recomendada: `Habilitado. 256 MB+`
Es importante asegurarse de que esté habilitado y monitoreado si está utilizando AppLocker.
## Registro operativo de CodeIntegrity (1 regla sigma)
Archivo: `Microsoft-Windows-CodeIntegrity%4Operational.evtx`
Configuración predeterminada: `Habilitado. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
Revise este registro para detectar eventos de carga de controladores que son bloqueados por las comprobaciones de integridad de código de Windows, lo que puede indicar un controlador malicioso que no pudo cargarse.
## Registro operativo de Diagnosis-Scripted (1 regla sigma)
Archivo: `Microsoft-Windows-Diagnosis-Scripted%4Operational.evtx`
Configuración predeterminada: `Habilitado. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
Aquí se puede encontrar evidencia de paquetes diagcab utilizados para explotación.
## Registro operativo de DriverFrameworks-UserMode (1 regla sigma)
Archivos: `Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx`
Configuración predeterminada: `Sin auditoría. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
Detecta dispositivos USB conectados.
## Registro operativo de WMI-Activity (1 regla sigma)
Archivo: `Microsoft-Windows-WMI-Activity%4Operational.evtx`
Configuración predeterminada: `Habilitado en Win10/2016+. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
Es importante monitorearlo, ya que los atacantes suelen explotar WMI para persistencia y movimiento lateral.
## Registro operativo de TerminalServices-LocalSessionManager (1 regla sigma)
Archivo: `Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx`
Configuración predeterminada: `Habilitado. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
Detecta cuando ngrok, una herramienta de proxy inverso, reenvía tráfico al puerto RDP local para evadir firewalls.
Enlace: [Evadiendo restricciones de red mediante túneles RDP](https://www.mandiant.com/resources/blog/bypassing-network-restrictions-through-rdp-tunneling)
## Registro operativo de TaskScheduler (1 regla sigma)
Archivo: `Microsoft-Windows-TaskScheduler%4Operational.evtx`
Configuración predeterminada: `Deshabilitado. 1 MB`
Configuración recomendada: `Habilitado. 128 MB+`
Los atacantes suelen abusar de las tareas para persistencia y movimiento lateral, por lo que este registro debería estar habilitado.