PowerShell se ha convertido en la navaja suiza de los atacantes modernos, y entender cómo funciona el malware powershell es la diferencia entre detectar una intrusión a tiempo o descubrirla cuando ya es tarde. Un script malicioso escrito en PowerShell puede ejecutarse directamente en memoria, sin tocar el disco, evadiendo antivirus tradicionales que buscan firmas en archivos. Esta técnica, conocida como fileless powershell, lleva años creciendo en campañas reales documentadas por Microsoft, CrowdStrike y Mandiant. El motivo es simple: PowerShell viene preinstalado en Windows, tiene permisos amplios por defecto y permite descargar y ejecutar código remoto en una sola línea. Cualquier powershell ataque moderno aprovecha esta legitimidad para camuflarse entre tareas administrativas reales, complicando el trabajo de los equipos de respuesta.
Por qué PowerShell es el favorito de los atacantes
PowerShell ofrece acceso completo a .NET, WMI, COM y la API de Windows. Un solo intérprete permite enumerar usuarios del dominio, modificar el registro, programar tareas o lanzar binarios sin compilar nada. Para un atacante, eso significa no tener que subir herramientas externas que un EDR pueda marcar.
El concepto se llama Living off the Land (LotL): usar lo que ya está en el sistema. Microsoft incluye PowerShell firmado por defecto, así que su ejecución no levanta sospechas inmediatas. A esto se suma la capacidad de descargar contenido remoto con un cmdlet tan inocente como Invoke-WebRequest o el clásico IEX (New-Object Net.WebClient).DownloadString(...), que sigue apareciendo en muestras de 2026.
Grupos como APT29, FIN7 o los operadores de Emotet han usado PowerShell como pieza central de sus cadenas de infección. No es teoría: los informes de threat intelligence de Red Canary llevan años situando PowerShell entre las tres técnicas más detectadas en entornos corporativos.
Anatomía de un ataque típico con PowerShell
La cadena suele empezar lejos del propio script. Un documento de Office con macros, un LNK disfrazado de PDF o un instalador MSI manipulado actúan como dropper. Ese primer escalón ejecuta PowerShell con parámetros que pasan desapercibidos al usuario.
Un patrón habitual es algo así:
- Loader inicial: powershell.exe -nop -w hidden -enc seguido de una cadena Base64.
- Decodificación en memoria: el Base64 se convierte en un segundo script que descarga la carga útil real.
- Inyección reflectiva: la DLL maliciosa se carga directamente en un proceso legítimo (svchost.exe, explorer.exe) sin tocar disco.
- Persistencia: tarea programada, clave Run del registro o suscripción WMI permanente.
- Comunicación C2: HTTPS hacia un dominio comprometido, a menudo con dominios de aspecto legítimo.
Lo interesante es que ninguno de estos pasos requiere escribir un ejecutable propio. Todo vive en memoria o en cadenas codificadas dentro del registro, y ahí es donde la detección clásica falla. Para entender cómo los analistas diseccionan estas cadenas, conviene revisar las técnicas de análisis de malware en sandbox que usan los equipos de threat hunting.
Técnicas de obfuscación más comunes
La powershell obfuscación es un campo con sus propias herramientas, siendo Invoke-Obfuscation de Daniel Bohannon la referencia desde 2016. Lo que empezó como prueba de concepto es ahora estándar de la industria ofensiva.
Las técnicas más vistas en muestras recientes:
| Técnica | Cómo funciona | Dificultad de detección |
|---|---|---|
| Base64 encoding | Codifica el script con -EncodedCommand | Baja, pero sigue siendo común |
| String concatenation | Divide cadenas y las une en runtime | Media |
| Tick obfuscation | Inserta backticks dentro de nombres de cmdlets | Media |
| AMSI bypass | Parchea memoria de amsi.dll para desactivar escaneo | Alta |
| XOR + compresión | Combina varias capas con Gzip y XOR | Alta |
Microsoft introdujo AMSI (Antimalware Scan Interface) precisamente para mirar dentro de scripts ofuscados antes de ejecutarlos. Funciona, pero los atacantes responden con bypasses que parchean la función AmsiScanBuffer en memoria. Es un juego del gato y el ratón que no se detiene.
Malware fileless: el reto de la detección
El concepto de fileless powershell incomoda a muchos equipos porque rompe el modelo mental clásico de "buscar el archivo malicioso". Aquí no hay archivo. Hay un proceso legítimo de Windows ejecutando código que solo existe en RAM o dentro de una clave del registro.
Casos documentados como Kovter guardaron toda su persistencia en valores del registro cifrados, sin escribir un solo binario en disco durante meses. PowerWare hizo lo propio con ransomware basado íntegramente en PowerShell. Más recientemente, varias campañas de Cobalt Strike han usado PowerShell solo como vehículo de carga inicial antes de pasar a beacons en memoria.
La detección efectiva requiere mirar a otros sitios:
- Script Block Logging (Event ID 4104): registra el contenido real de cualquier bloque PowerShell ejecutado, incluso después de desofuscarlo.
- Module Logging (Event ID 4103): muestra los parámetros con los que se invocan cmdlets.
- Process Command Line Auditing: capturar líneas de comando completas en Event ID 4688.
- EDR con visibilidad de memoria: necesario para detectar inyecciones reflectivas.
- Constrained Language Mode: limita PowerShell a un subconjunto seguro de operaciones.
Activar estos logs sin un SIEM que los procese es generar ruido. Por eso este tipo de visibilidad suele ir acompañada de servicios de pentesting previos que validan si las reglas de detección realmente saltan cuando deben.
Cómo se distribuyen estos scripts en campañas reales
El vector número uno sigue siendo el correo electrónico. Documentos Office con macros, archivos ISO que evaden Mark-of-the-Web, contenedores ZIP con LNK dentro. La creatividad no falta. Los troyanos bancarios que operan en España como Grandoreiro han usado PowerShell en varias variantes para descargar sus módulos secundarios.
Otros vectores que se ven con frecuencia:
- Malvertising con sitios que ofrecen instaladores falsos de software popular (Notion, Zoom, KeePass).
- SEO poisoning: páginas posicionadas para búsquedas tipo "descargar X gratis".
- SmartScreen bypass mediante ISO/IMG que no propagan la marca de archivo descargado.
- USB infectados en entornos industriales y educativos.
- Explotación de vulnerabilidades en software expuesto, donde PowerShell entra como segundo escalón.
Las empresas que desarrollan herramientas internas y necesitan reforzar su perímetro digital suelen combinar formación a empleados con auditoría continua. Si tu organización está revisando su estrategia de presencia online, una consultora como Piqture especializada en IA para empresas puede ayudar a integrar detección automatizada con flujos de respuesta.
Medidas defensivas que sí funcionan
No todo es resignación. Microsoft ha endurecido PowerShell mucho desde la versión 5.0, y combinar varias medidas reduce drásticamente la superficie de ataque.
Acciones concretas con buen retorno:
- Forzar PowerShell 5.1 o superior y bloquear PowerShell v2, que carece de logging avanzado.
- Activar Constrained Language Mode en estaciones de trabajo de usuarios sin necesidad administrativa.
- AppLocker o WDAC con reglas que limiten ejecución de scripts no firmados.
- Bloquear macros de Office descargadas de internet (política de grupo disponible desde 2022).
- Monitorizar Event ID 4104 con reglas Sigma públicas para detectar patrones sospechosos.
- Segmentar privilegios: ningún usuario debería ejecutar PowerShell como administrador en su día a día.
Para los más curiosos, herramientas como PowerShell-Hunter, Get-InjectedThread de Jared Atkinson o PSDecode ayudan a auditar scripts sospechosos. VirusTotal acepta scripts PowerShell y muestra detecciones multi-motor, aunque no es infalible con muestras muy ofuscadas.
Preguntas frecuentes
¿Puedo desactivar PowerShell completamente en mi empresa?
Técnicamente sí, pero romperás muchísimas tareas administrativas y de actualización. Es más práctico limitar su uso con Constrained Language Mode, AppLocker y políticas de ejecución, dejándolo disponible solo para cuentas que realmente lo necesiten.
¿El antivirus detecta malware fileless en PowerShell?
Los antivirus modernos integran AMSI y analizan scripts en memoria antes de ejecutarlos. Funciona razonablemente contra muestras conocidas, pero scripts con ofuscación avanzada o que parchean AMSI pueden evadir la detección. Por eso se recomienda combinar AV con EDR y logging de PowerShell.
¿Qué es exactamente un ataque fileless?
Es una técnica donde el código malicioso se ejecuta directamente en memoria sin escribir archivos ejecutables en disco. Aprovecha herramientas legítimas del sistema como PowerShell, WMI o el registro de Windows para persistir, dificultando la detección por antivirus tradicionales basados en firmas.
¿Cómo sé si mi equipo ha sido comprometido por un script PowerShell?
Revisa el visor de eventos en Microsoft-Windows-PowerShell/Operational, sobre todo Event ID 4104. Busca cadenas Base64 largas, llamadas a IEX, DownloadString o conexiones a dominios extraños. Herramientas como Sysinternals Autoruns ayudan a detectar persistencia en tareas programadas o claves del registro.
¿Constrained Language Mode rompe scripts legítimos?
Puede afectar a scripts que usan COM, .NET avanzado o reflection. La mayoría de scripts de administración básica funcionan sin problemas. Lo habitual es desplegarlo primero en modo auditoría para identificar qué se rompería antes de aplicarlo en modo enforcement.
El siguiente paso
Abre el visor de eventos de Windows ahora mismo, navega a Applications and Services Logs > Microsoft > Windows > PowerShell > Operational y comprueba si el Script Block Logging está activo. Si no aparece el Event ID 4104 en los últimos días, actívalo desde Group Policy (Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell). Es gratis, tarda dos minutos y es la base sobre la que construir cualquier detección posterior.
