Malware sin archivos: qué es, cómo funciona y cómo defenderse

Aventura Universal » General » Malware sin archivos: qué es, cómo funciona y cómo defenderse

En los últimos años el malware sin archivos (fileless malware) se ha convertido en uno de los quebraderos de cabeza más serios para equipos de TI y seguridad. No estamos hablando del típico virus que descargas en un archivo adjunto y que se puede borrar pasando un antivirus, sino de algo mucho más sigiloso que se esconde en los propios procesos del sistema.

Este tipo de amenaza aprovecha herramientas legítimas del sistema operativo, especialmente en Windows, para ejecutar código malicioso directamente en la memoria RAM. Al no dejar casi rastro en el disco, es capaz de esquivar muchos antivirus tradicionales y de permanecer activo el tiempo suficiente como para robar información, cifrar archivos o mantener puertas traseras sin ser detectado.

Qué es exactamente el malware sin archivos

Cuando hablamos de malware sin archivos nos referimos a código malicioso que no depende de un ejecutable clásico en el disco para funcionar. En lugar de instalarse como un programa más, se apoya en componentes ya presentes en el sistema (scripts, servicios, intérpretes de comandos, etc.) para cargar y ejecutar sus instrucciones directamente en memoria.

Desde el punto de vista técnico, este malware suele inyectarse en procesos que ya están en ejecución o lanzarse mediante comandos que cargan todo en RAM. Eso hace que, una vez apagado o reiniciado el equipo, muchas variantes desaparezcan, pero mientras tanto tienen margen de sobra para causar daños graves.

En comparación con el malware basado en archivos, estas amenazas son más ligeras, más discretas y mucho más difíciles de rastrear. No encontrarás un .exe sospechoso en el disco, ni necesariamente un instalador malicioso: el problema está en lo que ocurre dentro de procesos que aparentemente son de confianza.

El auge de este enfoque se disparó alrededor de 2017, cuando empezaron a verse campañas que combinaban técnicas sin archivos con troyanos clicker, adware avanzado y herramientas de acceso remoto (RAT). Hoy en día se han integrado en todo tipo de operaciones: desde espionaje y APT hasta ransomware y criptominería.

Cómo funciona el malware sin archivos por dentro

Para entender el funcionamiento, conviene recordar que la mayoría de aplicaciones normales se distribuyen como un archivo que se escribe en disco y luego se carga a memoria cuando el usuario lo ejecuta. El malware sin archivos, en cambio, se salta el primer paso y se materializa directamente en la RAM usando mecanismos del propio sistema operativo.

Muchas campañas se apoyan en la idea de «vivir de la tierra» (living off the land): el atacante abusa de utilidades de administración legítimas en lugar de introducir binarios nuevos. En Windows, el ejemplo estrella es PowerShell, pero también se explotan WMI, mshta, rundll32, scripts de VBScript o JScript y otros binarios de confianza (LoLBins).

Un escenario típico sería: un usuario abre un documento de Office con contenido malicioso o pulsa en un enlace de phishing; desde ahí se lanza un script que invoca PowerShell u otra herramienta para descargar, descifrar o inyectar en memoria el código de la siguiente fase. Todo esto puede ocurrir sin que se cree un archivo permanente en el disco duro.

Otro vector frecuente consiste en aprovechar vulnerabilidades de ejecución remota de código, como desbordamientos de búfer en navegadores, plugins o aplicaciones de servidor. Al explotar la vulnerabilidad, el atacante consigue ejecutar directamente shellcode dentro del proceso vulnerable y, a partir de ahí, cargar el resto de componentes en memoria.

Algunas variantes incluso recurren al Registro de Windows o a tareas programadas para guardar scripts o comandos que reactivan el ataque al iniciar el sistema o al iniciar sesión un usuario. Aunque se escriba algo en el Registro, la lógica maliciosa principal sigue ejecutándose en memoria, lo que dificulta su detección con herramientas centradas solo en el sistema de archivos.

Métodos de infección y acceso inicial

La puerta de entrada suele ser bastante clásica: correos de phishing, enlaces maliciosos y documentos adulterados siguen siendo los reyes del acceso inicial, aunque por debajo se empleen técnicas sin archivos. El truco está en que durante toda la cadena se intenta minimizar cualquier huella en disco.

En muchos incidentes se utilizan documentos de Microsoft Office con macros que, al activarse, llaman a PowerShell o a WMI para descargar y ejecutar en memoria la siguiente etapa del ataque. Incluso sin macros, los atacantes explotan vulnerabilidades en Word, Excel, lectores de PDF o el propio motor de scripting para alcanzar la ejecución de código.

Otro enfoque consiste en aprovechar directamente ejecutables aparentemente inofensivos que el usuario recibe por correo o descarga de la web. Ese ejecutable puede extraer un módulo malicioso y cargarlo en memoria mediante técnicas como la reflexión en .NET, sin llegar a guardarlo en el disco como archivo separado.

También se ven campañas que apuntan a servidores web o aplicaciones expuestas a Internet, donde la vulnerabilidad se usa para desplegar webshells con componentes sin archivos. Un ejemplo reciente es el uso de Godzilla y herramientas similares, en las que el código malicioso viaja dentro de peticiones HTTP y se inyecta directamente en memoria en el servidor comprometido.

Por último, los atacantes recurren con frecuencia a credenciales robadas. Si logran usuario y contraseña de un administrador o de una cuenta privilegiada, pueden iniciar sesión por RDP u otros canales y lanzar manualmente scripts PowerShell, comandos WMI o herramientas de administración que cargan el malware en memoria sin necesidad de dejar ejecutables nuevos en el sistema.

Técnicas concretas usadas por el malware sin archivos

Una de las claves de estos ataques es la reutilización de herramientas nativas de Windows como vehículo para sus scripts. Esto hace que la actividad maliciosa se mezcle con tareas administrativas normales, complicando el análisis y la respuesta.

Entre las técnicas más habituales encontramos el uso de PowerShell como lanzador de código embebido en la propia línea de comandos. Por ejemplo, se pasa un script ofuscado como parámetro, se desactiva la política de ejecución, se oculta la ventana y se descarga una carga útil directamente en memoria, todo ello sin dejar un archivo .ps1 ni un ejecutable sospechoso visible.

Otra táctica muy popular es almacenar scripts maliciosos en las suscripciones de Windows Management Instrumentation (WMI). Cada cierto evento del sistema, WMI dispara el script, que puede ejecutar código desde memoria, conectarse a servidores de mando y control o lanzar nuevas etapas de la infección.

De forma similar, muchos grupos utilizan el Registro de Windows y el programador de tareas como refugio para sus scripts y comandos. En lugar de colocar un ejecutable en la carpeta de inicio, definen claves de autoarranque o tareas planificadas que ejecutan scripts de PowerShell, mshta o rundll32 con código incrustado o descargado al vuelo.

También se ven técnicas de reflexión en .NET, donde un ejecutable ligero contiene ensamblados cifrados o comprimidos que se cargan directamente en memoria con Reflection.Load, sin ser nunca escritos como archivos .dll en el disco. Esto permite desplegar troyanos muy completos dentro de un único proceso aparentemente normal.

Qué puede hacer un ataque sin archivos

Pese a su nombre, un ataque sin archivos no está limitado en cuanto a impacto. De hecho, puede realizar las mismas funciones que un malware tradicional: robo de información, cifrado de datos, movimiento lateral, espionaje, minado de criptomonedas o instalación de backdoors permanentes.

Muchas campañas sin archivos se comportan como ladrón de credenciales, capturando contraseñas, tokens de sesión o hashes de autenticación desde la memoria de procesos sensibles. Esto facilita escalar privilegios, comprometer más sistemas y mantener acceso prolongado sin recurrir a binarios extra.

Otras se centran en ransomware sin archivos, donde parte de la lógica de cifrado y comunicación se ejecuta directamente en memoria. Aunque en algún momento pueda aparecer un componente en disco para manipular gran cantidad de archivos, la carga inicial y el control del ataque se hacen con técnicas fileless para evitar su detección temprana.

Los atacantes también pueden instalar rootkits o RATs avanzadas que, una vez asentadas, usan canales fileless para recibir órdenes, moverse por la red y actualizar módulos. Al estar integradas en procesos de sistema o en servicios críticos, estas herramientas resultan especialmente difíciles de erradicar.

En el plano económico, el impacto se traduce en pérdida de datos, paradas de servicio, multas regulatorias y daño reputacional. Dado que estas intrusiones suelen pasar meses sin ser detectadas, el volumen de información exfiltrada y el alcance de la brecha pueden ser enormes.

Fases de un ataque de malware sin archivos

Aunque la parte técnica sea distinta, el ciclo de un ataque fileless recuerda bastante al de cualquier intrusión avanzada. Lo que cambia son los mecanismos empleados en cada fase y la forma en que se camuflan.

En la etapa de acceso inicial, el adversario necesita un primer punto de apoyo: un clic en un enlace de phishing, la apertura de un documento con macros, la explotación de un servidor vulnerable o la reutilización de credenciales comprometidas. A partir de ahí, la intención es conseguir la ejecución de código dentro del sistema objetivo.

Una vez logrado ese paso, llega la fase de ejecución en memoria. Aquí entran en juego PowerShell, WMI, mshta, rundll32, VBScript, JScript u otros intérpretes para cargar y activar el payload sin generar ejecutables permanentes en el disco. Es habitual que el código esté ofuscado o cifrado y se descifre solo en RAM.

Después se persigue la persistencia. Aunque muchas cargas fileless desaparecen al reiniciar el equipo, los atacantes sofisticados combinan scripts RAM-resident con claves de Registro, tareas programadas o suscripciones WMI que vuelven a lanzar el código cada vez que se cumple una condición concreta, como el arranque del sistema o el inicio de sesión de un usuario.

Por último, se ejecutan los objetivos finales del atacante: robo y exfiltración de datos, cifrado de información, despliegue de más malware, espionaje continuo o sabotaje de sistemas críticos. Todo ello se realiza intentando mantener el perfil más bajo posible para evitar alarmas y análisis forenses tempranos.

Por qué es tan difícil de detectar

El gran problema del malware sin archivos es que rompe el modelo clásico de defensa basado en archivos y firmas. Si no hay un ejecutable sospechoso que analizar, muchos motores antivirus se quedan ciegos ante lo que ocurre dentro de la memoria y de los procesos legítimos.

La ausencia de archivos en disco implica que no hay objetos que escanear de forma periódica en busca de patrones conocidos. Además, al aprovechar binarios firmados por el propio sistema operativo, como PowerShell.exe, wscript.exe o rundll32.exe, la actividad maliciosa queda camuflada tras nombres en los que el administrador normalmente confía.

A esto se suma que muchos productos heredados tienen una visibilidad limitada sobre los procesos en ejecución. Se centran en el sistema de archivos y en el tráfico de red, pero apenas inspeccionan llamadas a API internas, parámetros de línea de comandos, comportamiento de scripts o eventos del Registro que puedan delatar un ataque sin archivos.

Los atacantes, conscientes de estas limitaciones, recurren a técnicas de ofuscación, cifrado y fragmentación del código. Por ejemplo, dividen un script malicioso en varios fragmentos que se ensamblan en tiempo real, o esconden instrucciones dentro de imágenes, recursos incrustados o cadenas aparentemente inocuas.

En entornos donde los sistemas apenas se reinician (servidores críticos, terminales de producción, etc.), un malware residente en memoria puede permanecer activo durante semanas o meses sin ser detectado, especialmente si se mueve con prudencia y minimiza el volumen de tráfico o de acciones llamativas.

Limitaciones de las defensas tradicionales

La respuesta inicial de muchos proveedores ante esta amenaza ha sido intentar restringir o bloquear directamente herramientas como PowerShell o las macros de Office. Aunque puede reducir algunos vectores, no es una solución realista ni completa en la mayoría de organizaciones.

PowerShell se ha convertido en una pieza clave para la administración de sistemas Windows, automatización de tareas, despliegue de software y gestión de servidores. Bloquearlo por completo supondría paralizar flujos de trabajo de TI y obligar a rehacer multitud de procesos internos.

Además, desde el punto de vista del atacante, hay múltiples formas de esquivar una política de bloqueo simple. Existen técnicas para cargar el motor de PowerShell a partir de librerías (dll) mediante rundll32, convertir scripts en ejecutables con herramientas como PS2EXE, utilizar copias modificadas de PowerShell.exe o incluso incrustar scripts de PowerShell en imágenes PNG y ejecutarlos con líneas de comando ofuscadas.

Con las macros de Office ocurre algo similar: muchas empresas dependen de ellas para automatizar informes, cálculos y procesos de negocio. Desactivarlas globalmente puede romper aplicaciones internas, mientras que confiar solo en análisis estático del código VBA suele generar una tasa de falsos positivos y falsos negativos difícil de gestionar.

A esto se suma que algunos enfoques basados en detection-as-a-service desde la nube requieren conectividad constante y, en ocasiones, actúan con demasiado retardo como para impedir la ejecución inicial del malware. Si la decisión de bloqueo se toma segundos o minutos después, el daño ya puede estar hecho.

Cambios de enfoque: de archivos a comportamiento

Dado que el archivo ya no es el elemento protagonista, las soluciones modernas de defensa se centran en vigilar el comportamiento de los procesos en lugar de inspeccionar únicamente el contenido de los ficheros. La idea es que, aunque existan miles de variantes de malware, los patrones de actividad maliciosa son mucho menos diversos.

Este enfoque se apoya en motores de análisis de comportamiento y aprendizaje automático que monitorizan continuamente qué hace cada proceso: qué comandos lanza, qué recursos del sistema toca, cómo se comunica con el exterior y qué cambios intenta introducir en el entorno.

Por ejemplo, se puede marcar como sospechoso un proceso de Office que ejecuta un comando PowerShell ofuscado con parámetros para desactivar políticas de seguridad y descargar código desde un dominio raro. O un proceso que, sin motivo aparente, accede de golpe a cientos de archivos sensibles o modifica claves de Registro críticas.

Los sistemas EDR y plataformas XDR de última generación recogen telemetría detallada de endpoints, servidores y red, y son capaces de reconstruir historias completas (a veces llamadas StoryLines) de cómo se ha originado un incidente, qué procesos han intervenido y qué cambios ha sufrido la máquina afectada.

Un buen motor de comportamiento no solo detecta la amenaza, sino que puede mitigar o revertir automáticamente las acciones maliciosas: matar procesos implicados, aislar el equipo, restaurar archivos cifrados, deshacer cambios en el Registro y cortar comunicaciones hacia dominios de mando y control.

Tecnologías y fuentes de eventos clave en Windows

Para analizar amenazas sin archivos en Windows resulta especialmente útil aprovechar mecanismos de telemetría nativos del sistema operativo, que ya están ahí y ofrecen mucha información sobre lo que ocurre entre bastidores.

Por un lado está Event Tracing for Windows (ETW), un marco que permite registrar eventos muy detallados sobre la ejecución de procesos, llamadas a API, acceso a memoria y otros aspectos internos del sistema. Muchas soluciones EDR se apoyan en ETW para detectar comportamientos atípicos en tiempo real.

Otra pieza clave es Antimalware Scan Interface (AMSI), una API diseñada por Microsoft para que los motores de seguridad puedan inspeccionar scripts y contenido dinámico justo antes de que se ejecute, incluso si está ofuscado. AMSI resulta especialmente útil con PowerShell, VBScript, JScript y otros lenguajes de scripting.

Además, los motores modernos analizan de forma periódica áreas sensibles como el Registro, el programador de tareas, las suscripciones WMI o las políticas de ejecución de scripts. Cambios sospechosos en estas zonas son a menudo la señal de que un ataque fileless ha establecido persistencia.

Todo esto se complementa con heurísticas que tienen en cuenta no solo el proceso actual, sino también el contexto de ejecución: de dónde proviene el proceso padre, qué actividad de red se ha observado antes y después, si ha habido fallos extraños, bloqueos anómalos u otras señales que, sumadas, inclinan la balanza hacia la sospecha.

Estrategias prácticas de detección y prevención

En la práctica, protegerse de estas amenazas pasa por combinar tecnología, procesos y formación. No basta con instalar un antivirus y olvidarse; hace falta una estrategia en capas adaptada al comportamiento real del malware sin archivos.

En el plano técnico, es imprescindible desplegar soluciones EDR o XDR con capacidades de análisis de comportamiento y visibilidad a nivel de proceso. Estas herramientas deben ser capaces de registrar y correlacionar actividad en tiempo real, bloquear comportamientos anómalos y proporcionar información forense clara al equipo de seguridad.

También conviene restringir el uso de PowerShell, WMI y otros intérpretes a lo estrictamente necesario, aplicando listas de control de acceso, firmas de scripts (Code Signing) y políticas de ejecución que limiten qué código puede correr y con qué privilegios.

En el lado del usuario, la formación sigue siendo crucial: hay que reforzar la concienciación sobre phishing, enlaces sospechosos y documentos inesperados, especialmente entre personal con acceso a información sensible o permisos elevados. Reducir el número de clics imprudentes disminuye mucho la superficie de ataque.

Por último, no se puede descuidar el ciclo de parches y actualización de software. Muchas cadenas fileless empiezan con la explotación de vulnerabilidades conocidas para las que ya existe corrección. Mantener navegadores, plugins, aplicaciones corporativas y sistemas operativos al día cierra puertas muy valiosas para los atacantes.

Servicios gestionados y caza de amenazas

En organizaciones medianas y grandes, donde el volumen de eventos es enorme, resulta difícil que el equipo interno lo vea todo. Por eso están creciendo los servicios de monitorización y respuesta gestionada (MDR/EMDR) y los centros de operaciones de seguridad (SOC) externos.

Estos servicios combinan tecnología avanzada con equipos de analistas que vigilan 24/7 los entornos de sus clientes, correlando señales débiles que, de otro modo, pasarían desapercibidas. La idea es detectar comportamientos propios de fileless malware antes de que se materialice el daño.

Muchos SOC se apoyan en marcos como MITRE ATT&CK para catalogar tácticas, técnicas y procedimientos (TTPs) de los adversarios y construir reglas específicas orientadas a ejecución en memoria, abuso de LoLBins, WMI malicioso o patrones de exfiltración de datos sigilosos.

Además de la monitorización continua, estos servicios suelen incluir análisis forense, respuesta a incidentes y asesoría para mejorar la arquitectura de seguridad, cerrar brechas recurrentes y reforzar controles en endpoints y servidores.

Para muchas empresas, externalizar parte de esta función es la forma más viable de mantenerse al día frente a amenazas tan complejas, ya que no todo el mundo puede permitirse un equipo interno especializado en hunting de malware avanzado.

La realidad es que el malware sin archivos ha cambiado para siempre la forma de entender la seguridad en endpoints: los archivos ya no son el único indicador clave, y solo una combinación de visibilidad profunda, análisis de comportamiento, buenas prácticas de administración y una cultura de ciberseguridad extendida puede mantenerlo a raya en el día a día.