El malware fileless se ha convertido en uno de los dolores de cabeza más serios para equipos de seguridad y administradores de sistemas. A diferencia del malware clásico, no se apoya en ficheros ejecutables almacenados en el disco, sino que vive casi por completo en la memoria y se apalanca en procesos y herramientas legítimas del propio sistema. Esto hace que muchos antivirus tradicionales, que siguen mirando básicamente archivos en disco, ni lo huelan.
Para colmo, los atacantes combinan el malware sin archivos con ingeniería social, exploits y herramientas de administración como PowerShell, WMI o scripts de Office. Resultado: un tipo de ataque muy sigiloso, ideal para campañas de espionaje, robo de credenciales, ransomware o movimientos laterales prolongados dentro de una red corporativa, en muchas ocasiones sin dejar apenas rastro forense.
¿Qué es exactamente el malware fileless?
Cuando hablamos de malware sin archivos nos referimos a código malicioso que no necesita añadir nuevos ejecutables al sistema de archivos para operar. Normalmente, el atacante inyecta su carga en procesos que ya están en marcha o aprovecha herramientas de scripting y automatización del propio sistema operativo para ejecutar su lógica en la RAM del equipo.
En vez de soltar un típico .exe malicioso, este tipo de amenaza se enfoca en corromper aplicaciones fiables (PowerShell, WMI, navegadores, aplicaciones de Office, etc.) o en abusar de funciones embebidas en documentos (macros, DDE, vulnerabilidades en lectores de PDF). De este modo, el código hostil se ejecuta a través de procesos perfectamente legítimos a ojos de muchas soluciones de seguridad.
Una consecuencia directa es que no hay “archivo raro” que escanear ni firma evidente que comparar. El código se carga en memoria, se ejecuta, hace su trabajo (robar datos, desplegar un backdoor, cifrar archivos, moverse por la red…) y muchas veces desaparece al reiniciar, salvo que el atacante haya montado algún mecanismo de persistencia.
Conviene matizar que no todo ataque fileless es 100 % sin huella en disco. En ocasiones hay un documento, script o exploit inicial, pero el comportamiento clave (la parte peligrosa) se ejecuta directamente desde memoria y trata de eliminar o minimizar los rastros en el sistema de archivos.
Rasgos característicos y por qué es tan difícil de detectar
Una de las señas de identidad del malware fileless es su ejecución puramente en memoria, lo que complica detectar procesos ocultos y rootkits. La carga maliciosa se inyecta en procesos ya existentes, o se interpreta desde un script, y se queda en RAM mientras el equipo está encendido. Muchos mecanismos de detección basados en disco sencillamente ni se enteran de lo que está pasando.
Otro rasgo importante es que, en general, tiene una persistencia limitada si no se plantea un truco adicional. Como la RAM es volátil, al reiniciar el sistema esa parte del ataque se esfuma. Los actores de amenazas lo saben, así que a menudo complementan la parte fileless con técnicas como uso del Registro de Windows, tareas programadas o suscripciones WMI para asegurar que el acceso se mantiene en el tiempo.
Además, este tipo de ataques se apoya en el concepto de “living off the land”: aprovechar herramientas que ya vienen con el sistema -PowerShell, WMI, .NET, utilidades de Windows firmadas por Microsoft- en lugar de introducir binarios externos. Eso implica que el atacante se camufla entre la administración legítima del entorno, algo que, en redes corporativas grandes, es ideal para pasar desapercibido durante meses.
Todo esto hace que las soluciones basadas en firmas y listas blancas tengan un papel bastante limitado. Si el antivirus está pensado para identificar ejecutables sospechosos o bloquear programas no autorizados, pero el ataque se ejecuta dentro de PowerShell, Word o un proceso del sistema, el margen de maniobra se reduce drásticamente.
Por último, los artefactos forenses que deja el malware fileless suelen ser escasos o muy sutiles. A veces hablamos solo de una clave de registro extraño, una suscripción WMI fuera de lugar o comandos raros en logs de PowerShell. Sin una política de registro agresiva y una supervisión activa, estas señales se pierden en el ruido.
Vectores de entrada y funcionamiento típico de un ataque fileless
Aunque la parte “sin archivos” se centra en memoria, el ataque empieza casi siempre igual que cualquier otra intrusión: mediante un vector inicial que abre la puerta al adversario. Los más habituales siguen siendo el correo electrónico y la web, acompañados de ingeniería social o explotación de vulnerabilidades.
Es muy típico que la víctima reciba un documento de Office con macros, un archivo PDF con JavaScript malicioso o un enlace en un correo de phishing que lleva a una web comprometida. Al abrirlo o al hacer clic, el documento ejecuta una macro o explota una vulnerabilidad y lanza un script de PowerShell o un comando WMI que descarga y ejecuta la carga maliciosa directamente en memoria.
En otros escenarios, el atacante aprovecha credenciales robadas para acceder a un equipo y desde ahí ejecutar scripts de administración que cargan el malware en memoria sin nunca grabar un .exe en el disco. También existen casos 100 % fileless donde se explota una vulnerabilidad de red -por ejemplo en el protocolo SMB- que permite inyectar una puerta trasera directamente en el kernel o en procesos del sistema.
Una vez dentro, el flujo típico pasa por varias fases: acceso inicial, establecimiento de persistencia (si la necesitan), robo de datos o movimiento lateral, y finalmente exfiltración o ejecución de otra carga (como ransomware). En cada una de estas etapas pueden combinarse técnicas fileless con otros tipos de malware para crear campañas muy complejas.
Algunas familias de amenazas han abusado masivamente de webshells en servidores donde las peticiones HTTP llevan componentes maliciosos que se inyectan en memoria sin volcar nada al disco. También se han visto ataques a entidades financieras en los que PowerShell se empleaba para manipular procesos legítimos y robar información sin dejar ejecutables sospechosos que un antivirus pudiera detectar con facilidad.
Herramientas y técnicas más usadas en ataques sin archivos
En el ecosistema Windows, los atacantes recurren constantemente a PowerShell por su potencia y flexibilidad. Es un lenguaje de scripting muy completo, con acceso a .NET, WMI, al Registro, a servicios de red, a ficheros y prácticamente a cualquier rincón del sistema. Con unas pocas líneas se puede descargar código de Internet, ejecutarlo en memoria y borrar los rastros visibles.
Otra pieza clave es WMI (Windows Management Instrumentation), junto con su equivalente estándar CIM. Estas interfaces permiten consultar y modificar multitud de objetos del sistema, disparar acciones en respuesta a eventos concretos y gestionar remotamente equipos. Los atacantes las usan tanto para post-explotación como para persistencia, mediante filtros de eventos y consumidores que ejecutan comandos cuando se cumplen determinadas condiciones.
El .NET Framework (o .NET Core) funciona como el andamiaje técnico sobre el que se apoyan muchas de estas técnicas. A través de sus bibliotecas, el malware puede interactuar con objetos WMI, COM, DCOM y otros componentes, de forma muy similar a como lo haría un administrador que emplea scripts legítimos.
También destaca el abuso del Registro de Windows como almacén de código y mecanismo de arranque. En estos ataques, el ejecutable inicial puede autodestruirse tras escribir su carga en el registro, de modo que la parte maliciosa sobrevive sin un archivo evidente, activándose más tarde desde claves concretas cuando se cumplen ciertas condiciones.
Junto a todo esto, los atacantes se sirven de utilidades firmadas por Microsoft como rundll32, mshta y otros binarios de sistema que permiten ejecutar scripts o DLLs. Al ser componentes de confianza, bloquearlos de forma general tendría un impacto serio en la operativa normal de la empresa, lo que deja a las defensas en una posición incómoda.
Tipos de malware y campañas que aprovechan técnicas fileless
Dentro de la categoría fileless encontramos varias modalidades de ataque que aprovechan esta capacidad de operar en memoria o de apoyarse en artefactos mínimos en el sistema. Una de las más conocidas es el malware residente en memoria, que utiliza la memoria de un proceso legítimo de Windows para alojar su código. Este código puede quedar inactivo hasta que se cumpla una condición concreta, momento en que se activa sin que haya evidencia en el disco.
Otra variante es el malware que se apoya en el Registro de Windows. Aquí la carga maliciosa se almacena como datos en el registro y se ejecuta mediante scripts o procesos que leen y lanzan ese contenido cuando arranca el sistema o se produce un evento específico. El ejecutable que originó todo puede haber desaparecido hace mucho, dificultando la investigación forense.
El uso de credenciales robadas encaja muy bien con este enfoque. Una vez que el atacante entra con un usuario legítimo, puede invocar scripts en memoria, colocar fragmentos de código en el registro o en suscripciones WMI y moverse por la red con apariencia de tráfico de administración normal. En entornos grandes, distinguir esto de las operaciones de TI legítimas es todo un reto.
No se quedan fuera las variantes de ransomware sin archivos, en las que la carga que cifra los datos se lanza directamente desde memoria, a veces ejecutada por PowerShell u otra herramienta del sistema. En estos casos, la detección suele llegar cuando los ficheros ya están cifrados, porque lo único visible hasta entonces han sido procesos en apariencia confiables.
También aparecen los llamados kits de explotación, conjuntos de herramientas que se encargan de detectar vulnerabilidades en la máquina víctima tras una primera intrusión -a menudo vía un enlace malicioso- y construir exploits a medida. Una vez dentro, cargan su código en memoria y se apoyan en scripts para mantener el control y escalar privilegios.
Impacto en empresas y limitaciones de las defensas clásicas
Para las organizaciones, el gran problema del malware fileless es que no basta con bloquear ejecutables sospechosos para estar a salvo. No se puede desactivar alegremente PowerShell, bloquear todos los documentos con macros o prohibir el uso de WMI sin romper procesos legítimos de administración, automatización de tareas o productividad diaria.
Al mismo tiempo, los antivirus centrados en firmas de archivos y listas blancas se encuentran casi ciegos. El ataque usa las mismas piezas que el sistema y que las herramientas de TI necesitan para funcionar. A menudo, ni siquiera hay un hash extraño que subir a la nube del proveedor para pedir veredicto: el código ya se ha ejecutado desde memoria.
Los intentos de respuesta por parte de muchos fabricantes han pasado por bloqueos parciales o parches que no terminan de resolver el problema: limitar el uso de PowerShell, endurecer macros de Office, aplicar controles en la nube que dependen de tener conectividad constante, etc. Pero los atacantes han aprendido a sortear estas trabas, por ejemplo cargando PowerShell a través de DLLs, ofuscando scripts o empaquetando código en imágenes y otros formatos de datos.
Además, la propia presión comercial ha llevado a algunas soluciones a prometer protección fileless con enfoques que se quedan cortos, como analizar estáticamente el código de macros o limitarse a reputaciones de scripts conocidas. Dado que los adversarios pueden variar sus herramientas casi al gusto, una aproximación estrictamente basada en firmas o reglas estáticas tiende a quedarse obsoleta con rapidez.
A esto se suma que muchos mecanismos de detección del lado del servidor o en la nube añaden latencia a la respuesta. Si el agente en el endpoint tiene que esperar la decisión remota para actuar, la prevención en tiempo real se complica, sobre todo en ataques extremadamente rápidos como ciertos tipos de ransomware o gusanos de red.
Cómo detectar el malware fileless: foco en el comportamiento
La lección principal de todos estos casos es clara: la forma más eficaz de localizar malware sin archivos es vigilar lo que hacen los procesos, no tanto qué archivos existen en el disco, por ejemplo con Process Explorer y VirusTotal. Aunque haya miles de variantes distintas, al final el repertorio de comportamientos sospechosos es mucho más acotado que el de posibles binarios maliciosos.
Las soluciones modernas tipo EDR y plataformas con IA de comportamiento monitorizan llamadas al sistema, argumentos de línea de comandos, accesos al registro, conexiones de red, creación de procesos hijos, modificaciones en scripts, etc. A partir de ahí, construyen una especie de “historia” de cada cadena de ejecución, lo que permite identificar cuando un proceso legítimo se convierte en la raíz de una actividad anómala.
Algunos fabricantes representan esto como una línea temporal de eventos donde se ve, por ejemplo, cómo un usuario abre un documento de Outlook, ese documento dispara una macro que lanza PowerShell con argumentos ofuscados, y ese PowerShell intenta descargar y ejecutar una carga desde Internet. Aunque no haya ningún .exe sospechoso en disco, la correlación del flujo hace cantoso el ataque.
Este enfoque centrado en el comportamiento tiene la ventaja de ser independiente del vector. Da igual si la intrusión llega por un exploit en Flash, por una macro de Word o por un enlace en un correo. Si el resultado es un proceso que empieza a cifrar datos, inyectar código o comunicarse con un servidor de mando y control, el sistema puede detectarlo y bloquearlo.
Combinado con capacidades de rollback o reversión de cambios maliciosos, esto permite no solo parar el ataque sino también reparar Windows tras una infección grave, restaurar archivos cifrados, deshacer modificaciones en el registro o matar procesos colgados del flujo malicioso. Desde el punto de vista de continuidad de negocio, esta diferencia es enorme frente a un antivirus que solo avisa cuando ya es tarde.
Estrategias prácticas para detectar fileless en entornos Windows
Además de contar con una solución avanzada de endpoint, hay una serie de medidas técnicas que ayudan muchísimo a descubrir indicios de malware sin archivos en la infraestructura. La primera es adoptar una política de logging agresiva, especialmente en lo relativo a PowerShell y WMI.
Las versiones modernas de PowerShell permiten registrar detalladamente los comandos ejecutados, las secuencias de scripts y el uso de ciertos parámetros peligrosos como ExecutionPolicy Bypass. Analizar estos logs en busca de patrones sospechosos -descargas desde dominios extraños, cargas en memoria, ofuscación evidente- puede destapar campañas que de otro modo pasarían inadvertidas.
Otra línea de defensa consiste en inspeccionar periódicamente el repositorio WMI en busca de suscripciones o filtros de eventos fuera de lo normal. Mediante comandos para diagnosticar problemas de PowerShell se pueden listar clases como __EventFilter, CommandLineEventConsumer o __FilterToConsumerBinding y comprobar si hay elementos que no encajan con las tareas legítimas de administración.
También conviene revisar tareas programadas y claves de registro de arranque, sobre todo aquellas que lanzan scripts o intérpretes como PowerShell, cscript o wscript. Muchos ataques fileless recurren a estos mecanismos para recuperar su código desde memoria, desde el propio registro o desde un servidor remoto cada vez que el sistema se inicia o el usuario inicia sesión.
En casos más avanzados, es recomendable apoyarse en herramientas como Sysmon de Sysinternals para generar eventos de alto detalle sobre creación de procesos, conexiones de red, modificaciones de registro, etc., y volcarlos a un SIEM o plataforma de análisis centralizada. A partir de ahí, se pueden crear reglas para alertar de comportamientos típicos de campañas conocidas o usar utilidades como RootkitRevealer para detectar artefactos persistentes.
Buenas prácticas para prevenir infecciones de malware sin archivos
En el terreno de la prevención, el primer pilar sigue siendo reducir al mínimo los vectores de infección clásicos: evitar que el usuario ejecute documentos peligrosos, hacer difícil la explotación de vulnerabilidades y limitar el movimiento lateral en caso de que haya una brecha.
Es casi obligatorio deshabilitar o restringir las macros de Office siempre que sea viable, idealmente mediante directivas de grupo (GPO). Las macros deberían estar permitidas solo cuando exista una necesidad real y, si es posible, firmadas digitalmente. El mismo criterio se aplica a otros contenidos activos como DDE o controles ActiveX en documentos.
También es importante contar con soluciones de seguridad de red que vigilen el tráfico en busca de exploits, kits de explotación y comportamientos anómalos. Sistemas de prevención de intrusiones (IPS) y tecnologías como Network Attack Prevention pueden cortar muchos ataques antes de que las cargas fileless lleguen al endpoint.
A nivel de endpoints, resulta clave desplegar herramientas capaces de analizar la memoria en busca de comportamiento malicioso, no solo de ficheros en disco. Motores de escaneo avanzado en RAM pueden identificar patrones típicos de inyección de código, shellcode, payloads de ransomware o backdoors que se esconden en procesos de sistema.
Finalmente, nada de esto funciona sin una buena higiene básica: aplicar parches de seguridad con regularidad, mantener aplicaciones y sistemas operativos al día, segmentar la red para dificultar el movimiento lateral, implantar MFA y controlar con rigor las cuentas con privilegios elevados.
La combinación de todo lo anterior, junto a una genuina cultura de seguridad –formación continua, simulaciones de phishing, procedimientos claros de respuesta a incidentes- es lo que marca la diferencia entre una organización que detecta un ataque fileless en sus primeras fases y otra que se entera cuando ya tiene sus servidores cifrados o sus datos exfiltrados.
