Detectar PowerShell malicioso con el registro de scripts

El pilar de seguridad de PowerShell activa el registro. Esta guía trata de qué hacer con él: dónde acaban las pruebas, cómo reconstruir scripts largos a partir de fragmentos, qué patrones distinguen a un atacante de un administrador y cómo ajustar las detecciones para que sus analistas las sigan leyendo el mes que viene.

La telemetría con la que trabaja

PowerShell 7 escribe en su propio registro PowerShellCore/Operational una vez registrado su manifiesto de eventos, y usa sus propias opciones de directiva. Si PowerShell 7 está instalado, recopile ambos registros o tendrá un punto ciego con otro nombre de ejecutable (pwsh.exe).

Todo esto solo es útil fuera del host. Reenvíelo con Windows Event Forwarding o con su agente, y aumente el tamaño del registro Operational para que un servidor con mucha actividad no lo sobrescriba antes de la recopilación.

Paso 1: reensamblar los bloques de script divididos

Los scripts grandes se reparten en varios eventos 4104. Cada fragmento lleva el mismo ScriptBlock ID y un contador «parte n de m». Los analistas que leen eventos sueltos ven código roto, y las reglas de detección pasan por alto los patrones que quedan a caballo de un límite. Reconstrúyalos primero:

$events = Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-PowerShell/Operational'; Id = 4104
} -MaxEvents 5000

$events | Group-Object { $_.Properties[3].Value } | ForEach-Object {
  $parts = $_.Group | Sort-Object { [int]$_.Properties[0].Value }
  [pscustomobject]@{
    ScriptBlockId = $_.Name
    Time          = ($parts | Select-Object -First 1).TimeCreated
    Path          = $parts[0].Properties[4].Value
    Text          = ($parts | ForEach-Object { $_.Properties[2].Value }) -join ''
  }
}

En un SIEM, haga lo mismo con una agrupación por identificador de bloque de script antes de buscar coincidencias. Un Path vacío significa que el código procedía de un símbolo del sistema interactivo, de -Command, de -EncodedCommand o de memoria, y no de un archivo en disco. Eso por sí solo ya es un punto de pivote útil.

Paso 2: empezar por lo que PowerShell ya marca

Incluso sin directiva, PowerShell 5.1 registra los bloques de script que contienen términos sospechosos conocidos como eventos 4104 de nivel advertencia. Con el registro de bloques de script habilitado, siguen marcados como advertencias entre los eventos detallados. Constituyen una primera alerta con poco ruido:

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-PowerShell/Operational'; Id = 4104; Level = 3
} -MaxEvents 200 | Select-Object TimeCreated, MachineName, @{n='Snippet';e={ $_.Properties[2].Value.Substring(0, [Math]::Min(200, $_.Properties[2].Value.Length)) }}

Revise todos los eventos de nivel advertencia durante unas semanas. Aprenderá qué scripts de administración los disparan y podrá excluirlos por ruta.

Paso 3: buscar los patrones que necesitan los atacantes

Las herramientas de ataque tienen que hacer un número reducido de cosas, y cada una deja palabras en el texto del script. Agrupe los indicadores según lo que intenta conseguir el atacante:

Dos cosas hacen viables estas reglas:

1. Combinar indicadores. -NoProfile por sí solo está en todas partes. -NoProfile más una ventana oculta más un mecanismo de descarga, no.
2. Normalizar primero. Pase el texto a minúsculas y elimine los acentos graves antes de buscar coincidencias, y compare los modificadores de la línea de comandos por prefijo. powershell.exe acepta tanto / como -, y nombres de parámetro parciales.

El repositorio abierto de reglas Sigma tiene reglas de PowerShell bien mantenidas que puede traducir a su SIEM en lugar de escribir cada una desde cero.

Paso 4: vigilar el motor, no solo los scripts

Algunas de las mejores señales están en el registro clásico Windows PowerShell y en la telemetría de procesos, más que en el texto de los scripts:

• Intentos de degradación. Un evento 400 con EngineVersion=2.0 significa que alguien inició el motor de PowerShell 2.0, que no tiene registro de bloques de script ni AMSI. Alerte sobre cada caso y elimine el motor como se describe en el pilar.
• Hosts inusuales. Los eventos 400 y 600 incluyen HostApplication. PowerShell ejecutándose dentro de algo distinto de powershell.exe, pwsh.exe o el ISE es sospechoso.
• PowerShell no administrado. Algunas herramientas pueden cargar el motor de PowerShell en cualquier proceso .NET. El evento 7 de Sysmon para System.Management.Automation.dll (o su imagen nativa) cargada por un proceso inesperado lo detecta. Use su configuración de Sysmon para incluir esa DLL concreta en lugar de registrar todas las cargas de imágenes.
• Procesos primarios sospechosos. 4688 o Sysmon 1 en los que powershell.exe es hijo de winword.exe, excel.exe, outlook.exe, mshta.exe, wmiprvse.exe, w3wp.exe o sqlservr.exe. Además, las reglas de reducción de la superficie de ataque bloquean directamente el PowerShell lanzado desde Office.

Paso 5: usar las detecciones de AMSI como alertas de alta fidelidad

La Interfaz de análisis antimalware entrega el contenido del script a Defender en tiempo de ejecución, después de la desofuscación. Cuando Defender bloquea un script, el usuario ve «This script contains malicious content and has been blocked by your antivirus software», y Defender registra 1116 (detectado) y 1117 (acción aplicada). El recurso de la detección hace referencia a AMSI y al proceso host, no a un archivo en disco.

Trate cualquier detección de AMSI en un servidor como un incidente, no como una molestia del antivirus. Habilite primero en modo auditoría la regla ASR Block execution of potentially obfuscated scripts para ver qué detectaría.

Paso 6: detectar los intentos de apagar las luces

Los atacantes que conocen el registro intentan desactivarlo:

• Cambios en el registro bajo HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell (Sysmon 13, o una SACL con 4657).
• Borrado de registros: 1102 (Security) y 104 (System, para cualquier otro registro). Consulte la referencia de identificadores de eventos de seguridad para el resto de señales de manipulación.
• Un host cuyo volumen de 4104 cae a cero mientras sigue enviando otros eventos. Construya una comprobación de «host silencioso» por registro, no solo por equipo.
• Cambios en Defender: 5001 (protección en tiempo real desactivada) y 5007 (configuración cambiada, incluidas nuevas exclusiones).

Paso 7: clasificar una alerta

Cuando se dispara una regla, responda a cuatro preguntas antes de decidir que es benigna:

1. ¿Quién y dónde? Cuenta, host y sesión de inicio de sesión. Pivote sobre la sesión para encontrar el evento 4624: un administrador interactivo en una consola no es lo mismo que un inicio de sesión de red procedente de un puesto de trabajo.
2. ¿Qué lo lanzó? Recorra la cadena de procesos primarios en 4688 o Sysmon 1. Una tarea programada, un servicio, un documento de Office y una sesión remota de WinRM (wsmprovhost.exe) apuntan cada uno a un punto de entrada distinto.
3. ¿Qué hizo después? Revise el script reensamblado y, a continuación, las conexiones de red (Sysmon 3 y 22), las escrituras de archivos (Sysmon 11) y los procesos hijos en los minutos siguientes.
4. ¿Es conocido? Busque el hash del bloque de script o cadenas distintivas en todo el parque. El mismo script en cientos de equipos suele ser un agente; el mismo script en tres servidores de madrugada suele ser una intrusión.

Anote la respuesta en las notas de ajuste de la regla, para que el siguiente analista no empiece de cero.

Qué se rompe

La ingeniería de detección para PowerShell rompe sobre todo la paciencia de sus analistas:

• Los agentes de gestión parecen malware. Configuration Manager, la Intune Management Extension, los agentes de supervisión y las herramientas de respuesta del EDR ejecutan habitualmente PowerShell con -ExecutionPolicy Bypass, -NoProfile y comandos codificados. Exclúyalos por ruta completa del proceso primario y firmante, nunca solo por nombre de proceso.
• Volumen. El registro completo de bloques de script en un servidor de gestión con mucha actividad produce muchos eventos 4104, igual que cada ejecución de DSC o de supervisión. Dimensione el registro en consecuencia y filtre en el SIEM, no desactivando el registro.
• Secretos en los registros. El texto de los scripts incluye todo lo que escriben los administradores, contraseñas incluidas. Restrinja el acceso de lectura a los registros de PowerShell en su SIEM, o use Protected Event Logging.

Comprobarlo

Pruebe cada capa en un equipo de laboratorio antes de confiar en ella en producción:

# 1. Registro de bloques de script: un marcador inofensivo y fácil de encontrar
powershell.exe -NoProfile -Command "Write-Output 'sbl-canary-2026'"

# 2. AMSI: la cadena de prueba documentada por Microsoft, detectada pero inofensiva
'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386'

# 3. Detección de degradación del motor, donde el motor v2 aún exista en el laboratorio
powershell.exe -Version 2 -Command "exit"

Después confirme que cada evento llegó al SIEM y disparó la regla prevista: 4104 con la cadena canario, 1116 de Defender, 400 con EngineVersion=2.0. Si falta alguno, corrija la canalización antes de escribir más reglas. El modo de lenguaje restringido reduce lo que pueden hacer los atacantes; la detección le dice que lo han intentado. Más sobre ambos en la página temática de seguridad de PowerShell.

Lista de comprobación

• 4103, 4104, 400/403/600 y PowerShellCore/Operational reenviados casi en tiempo real
• Bloques de script reensamblados por ScriptBlock ID antes de aplicar las reglas
• Alerta sobre los eventos 4104 de nivel advertencia, ajustada por ruta de script
• Reglas de indicadores combinados para descarga, ofuscación, ejecución en memoria y evasión de defensas
• Alertas sobre el evento 400 con EngineVersion 2.0
• Regla de Sysmon para System.Management.Automation.dll cargada por procesos inesperados
• Alertas sobre PowerShell lanzado por Office, servidores web y WMI
• Detecciones de AMSI (1116/1117) en servidores tratadas como incidentes
• Detecciones de host silencioso y de manipulación de registros implantadas
• Agentes de gestión excluidos solo por ruta completa y firmante