Si tuvieras que escribir una detección para PowerShell malicioso, ¿en qué te fijarías?

Fíjate en comportamiento y contexto más que en palabras clave. Entre las señales fuertes están los procesos padre sospechosos (aplicaciones de Office, navegadores, WMI), las líneas de comandos codificadas u ofuscadas, el bypass de la política de ejecución combinado con una ventana oculta, el contenido del script block logging que muestra descargas o llamadas por reflexión, y las conexiones salientes de powershell.exe a infraestructura nueva. Activa primero el logging de módulos y de script block, porque sin eso solo estás comparando una línea de comandos.

Antes de escribir nada compruebo que el script block logging y el module logging estén activos, además de la auditoría de creación de procesos con línea de comandos, porque una regla contra una línea de comandos truncada es casi inútil. Luego apilo señales en vez de depender de una sola. El proceso padre es la más fuerte: PowerShell lanzado por Word, Excel, Outlook, mshta o un navegador merece una alerta casi por sí solo. Después, comandos codificados combinados con ventana oculta y bypass de política de ejecución, y dentro del contenido del script busco carga reflexiva, DownloadString, Invoke-Expression sobre una variable y llamadas directas a APIs de memoria. Por el lado de red, powershell.exe hablando con una IP en crudo o con un dominio visto por primera vez en la última semana. Lo pruebo con pruebas atómicas más un par de variantes ofuscadas, porque si mi regla muere ante una simple concatenación de cadenas nunca fue una detección. Lo que suele hacerla saltar de forma legítima es el stack de despliegue y monitorización, así que hago línea base de esas cuentas de servicio antes de ponerla en producción y no después de que suene el busca.