Ataques living off the land (LOTL) y malware fileless

Los ataques living off the land (LOTL) consisten en abusar de herramientas legítimas ya presentes en el entorno (PowerShell, WMI, certutil, rundll32, mshta o bitsadmin) para ejecutar acciones maliciosas mezclándose con la actividad normal. Lo que caracteriza a LOTL es usar binarios y utilidades legítimas para camuflarse, no la ausencia de ficheros: un ataque LOTL puede coexistir con payloads o ficheros propios. El código fileless, en cambio, se define por ejecutarse sin escribir un fichero convencional en disco, viviendo en memoria o en mecanismos del propio sistema (registro, WMI). Ambas técnicas evaden el antivirus basado en firmas, pero responden a preguntas distintas: LOTL a qué herramientas usa el atacante (legítimas) y fileless a dónde vive el código (sin fichero en disco). Entender la diferencia es clave para detectarlas.

Durante años, la defensa del endpoint se apoyó en identificar ficheros maliciosos: un ejecutable llegaba al disco, el antivirus lo comparaba con una base de firmas y lo bloqueaba. Los atacantes avanzados dieron la vuelta a ese modelo. Si el sistema operativo ya trae herramientas potentes de administración, ¿por qué traer las tuyas y arriesgarte a ser detectado? Esa idea es el núcleo de los ataques living off the land (LOTL) y del malware fileless, dos conceptos que se solapan pero que no son lo mismo. En este artículo explicamos qué son, en qué se diferencian, cómo operan los adversarios y, sobre todo, cómo detectarlos y mitigarlos con un enfoque defensivo.

Lo esencial sobre LOTL y fileless

• LOTL describe QUÉ herramientas usa el atacante: binarios legítimos del sistema (los llamados LOLBins).
• Fileless describe DÓNDE vive el código malicioso: en memoria o en mecanismos del sistema, sin fichero en disco.
• Ambas evaden el antivirus basado en firmas: LOTL porque el binario ejecutado es una utilidad legítima ya confiable, fileless porque no hay fichero en disco que escanear.
• Grupos avanzados y operadores de ransomware las emplean para persistencia y movimiento lateral.
• La detección eficaz se basa en comportamiento (EDR/XDR), telemetría de línea de comandos y logging de PowerShell.
• La mitigación pasa por mínimo privilegio, allowlisting y restricción de los intérpretes de scripts.

Qué son los ataques living off the land (LOTL)

Un ataque living off the land (LOTL) es aquel en el que el adversario abusa de herramientas legítimas ya disponibles en el entorno para llevar a cabo sus objetivos, apoyándose en ellas para camuflarse. La lógica es sencilla: el sistema operativo y sus utilidades de administración incluyen binarios firmados por el fabricante, confiables por defecto y presentes en prácticamente cualquier equipo. Si el atacante consigue apoyarse en ellos, su actividad se confunde con la de un administrador legítimo y deja de destacar frente a las soluciones de seguridad tradicionales. Lo que define a LOTL no es que no haya ficheros (un ataque LOTL puede combinarse con payloads propios), sino que la ejecución recae en utilidades legítimas del entorno en lugar de en herramientas traídas por el atacante.

Estas utilidades reciben el nombre de LOLBins (living off the land binaries) y están catalogadas de forma pública en el proyecto LOLBAS. La idea del catálogo es documentar qué binarios, scripts y librerías del propio sistema pueden ser abusados y para qué funciones (descarga de contenido, ejecución de código, evasión, persistencia), de modo que los equipos de defensa sepan qué vigilar.

Herramientas legítimas abusadas con frecuencia

Entre las nativas de Windows más conocidas figuran PowerShell (el intérprete de automatización del sistema), WMI (Windows Management Instrumentation, para consultar y controlar el sistema), certutil (gestión de certificados que también permite codificar y descargar ficheros), rundll32 (ejecución de funciones de librerías DLL), mshta (ejecución de aplicaciones HTML) y bitsadmin (transferencia de ficheros en segundo plano). A ellas se suman utilidades de terceros muy habituales en entornos de administración, como PsExec (ejecución remota de la suite Sysinternals), que no viene preinstalado por defecto en Windows y solo cuenta como herramienta LOTL cuando el binario ya está disponible en el entorno comprometido. Ninguna de estas herramientas es maliciosa en sí misma. Todas tienen usos administrativos legítimos, y ese es precisamente el motivo por el que resultan tan útiles para un atacante: bloquearlas sin más rompería tareas de operación normales.

Por qué evaden el antivirus

El antivirus clásico basado en firmas funciona reconociendo patrones de ficheros maliciosos conocidos. En un ataque LOTL, el binario que se ejecuta es una utilidad legítima, firmada y confiable, no un ejecutable sospechoso que reconocer por firma. Lo malicioso no es el fichero en sí, sino el uso que se le da y los parámetros con los que se invoca (aunque el ataque despliegue además algún fichero propio, el motor de firmas apenas tiene un binario legítimo que analizar). Por eso un motor centrado en el fichero tiene poco que analizar, y la detección debe desplazarse hacia el comportamiento. Este mismo principio explica por qué muchas familias de amenazas, incluidas variantes descritas en nuestra guía sobre tipos de malware, combinan cargas tradicionales con técnicas LOTL para maximizar su sigilo.

Qué es el malware fileless

El malware fileless (sin fichero) es código malicioso que se ejecuta sin escribir un ejecutable en disco. En lugar de dejar un binario que el antivirus pueda escanear, vive en la memoria del proceso o se apoya en mecanismos del propio sistema operativo: scripts que se cargan y ejecutan sobre la marcha, suscripciones de eventos de WMI, claves del registro que almacenan el payload o tareas programadas que lo relanzan. Al no depender de un fichero en disco, deja muy poca huella forense y complica el análisis posterior a un incidente.

Dónde vive el código sin fichero

La memoria es el escenario principal. Un atacante puede inyectar código en un proceso legítimo en ejecución y operar desde ahí, de forma que en disco no exista rastro alguno del payload. También se abusa del registro de Windows como almacén: el código o un cargador se guarda codificado en una clave y se recupera en cada arranque. WMI ofrece un mecanismo de persistencia elegante mediante suscripciones de eventos que disparan la ejecución cuando se cumple una condición. Y las tareas programadas permiten relanzar el código de forma recurrente. En todos los casos, el denominador común es la ausencia de un fichero ejecutable convencional que analizar.

Baja huella forense

La consecuencia práctica de operar sin fichero es que las técnicas de análisis tradicionales pierden eficacia. Buscar un binario sospechoso en disco no sirve si el payload solo existió en memoria y desapareció al reiniciar. Esta característica emparenta al malware fileless con familias diseñadas para el sigilo persistente, como los rootkits, que también priorizan pasar desapercibidos frente a dejar artefactos visibles. La investigación forense obliga entonces a capturar y analizar memoria, revisar mecanismos de persistencia poco habituales y correlacionar telemetría en lugar de confiar en un escaneo de disco.

LOTL y fileless: se solapan pero no son lo mismo

Es habitual usar ambos términos como sinónimos, y en muchos incidentes reales aparecen juntos, pero describen dimensiones distintas de un ataque. LOTL responde a la pregunta de QUÉ herramientas usa el adversario: binarios legítimos del sistema. Fileless responde a la pregunta de DÓNDE vive el código malicioso: en memoria o en mecanismos del sistema, sin fichero en disco.

Se puede tener una sin la otra. Un ataque puede ser LOTL sin ser fileless si, por ejemplo, abusa de una utilidad legítima que sí escribe un artefacto temporal en disco. Y puede ser fileless sin ser estrictamente LOTL si ejecuta código propio inyectado en memoria sin apoyarse en un binario del sistema. Lo más frecuente, sin embargo, es la combinación: usar PowerShell (LOTL) para cargar y ejecutar un payload directamente en memoria (fileless). Esa combinación es la que mejor reúne ambas ventajas, sigilo de herramienta legítima y ausencia de fichero, y la que más quebraderos de cabeza da a la defensa tradicional.

Quién las utiliza y para qué

Estas técnicas son especialmente populares entre grupos avanzados y entre operadores de ransomware. Una vez logrado el acceso inicial, el atacante necesita mantenerse en el entorno (persistencia) y desplazarse hacia otros sistemas (movimiento lateral) sin ser detectado. Herramientas como PsExec o WMI son ideales para ese movimiento lateral porque son exactamente lo que usaría un administrador. En muchas cadenas de ataque, la fase de robo de credenciales con utilidades como las descritas en nuestro artículo sobre Mimikatz y el credential dumping se apoya en estas mismas técnicas para operar en memoria y evitar dejar rastros en disco.

Cómo detectar ataques LOTL y fileless

Si el problema es que no hay un fichero malicioso que reconocer, la solución es dejar de mirar el fichero y empezar a mirar el comportamiento. La detección eficaz se construye sobre varias capas complementarias de telemetría y análisis.

Detección basada en comportamiento (EDR/XDR)

La pieza central es una solución de detección y respuesta en el endpoint que analice comportamiento en lugar de firmas. Un EDR moderno, o un XDR que correlaciona señales de múltiples fuentes, observa secuencias de acciones: qué proceso lanza a qué otro, con qué parámetros, qué conexiones de red abre y qué modificaciones realiza. Que PowerShell exista no es sospechoso; que un documento ofimático lance PowerShell, que este contacte con un dominio externo y cargue algo en memoria, sí lo es. Conviene tener presente, además, que las propias técnicas de evasión evolucionan, un tema que tratamos en nuestro análisis sobre evasión de EDR y el papel de los LLM.

Telemetría de línea de comandos y logging de PowerShell

La línea de comandos completa con la que se invoca cada proceso es una de las fuentes de detección más valiosas frente a LOTL, porque lo malicioso suele estar precisamente en los parámetros. Registrar y analizar esas líneas de comando permite detectar invocaciones anómalas de binarios legítimos. En el caso de PowerShell, el registro de bloques de script (ScriptBlock logging) y el registro de módulos (Module logging) capturan el contenido de lo que se ejecuta, incluso cuando llega ofuscado, y AMSI (Antimalware Scan Interface) permite inspeccionar el script justo antes de su ejecución, reduciendo el margen de la ofuscación.

Monitorización de WMI y del registro

Dado que el código fileless abusa de WMI y del registro como mecanismos de persistencia y almacenamiento, monitorizar la creación de suscripciones de eventos de WMI y los cambios en claves de registro sensibles es fundamental. Estas actividades son poco frecuentes en la operación normal, por lo que su aparición merece atención inmediata.

Correlación en SIEM y mapeo a MITRE ATT&CK

Ninguna señal aislada cuenta la historia completa. La correlación en un SIEM permite unir eventos dispersos (un inicio de sesión, la ejecución de un binario, una conexión de red) en una narrativa coherente de ataque. Mapear las técnicas observadas al framework MITRE ATT&CK ayuda a estructurar la detección, entender en qué fase de la intrusión nos encontramos y cubrir huecos de visibilidad de forma sistemática.

Threat hunting proactivo

Como estas técnicas están diseñadas para evadir la detección automática, conviene complementarla con búsqueda proactiva. El threat hunting parte de hipótesis (por ejemplo, buscar invocaciones inusuales de certutil o mshta) y rastrea la telemetría en busca de indicios que las reglas automáticas podrían haber pasado por alto. Es especialmente valioso frente a adversarios que ajustan sus TTPs precisamente para no disparar alertas conocidas.

Cómo mitigar y reducir la superficie de ataque

La detección importa, pero reducir de entrada las oportunidades del atacante es igual de importante. Varias medidas de fortalecimiento limitan de forma notable la eficacia de LOTL y fileless.

Mínimo privilegio y allowlisting

Aplicar el principio de mínimo privilegio reduce lo que un atacante puede hacer aunque logre ejecutar código: sin permisos administrativos, muchas técnicas de persistencia y movimiento lateral quedan bloqueadas. El allowlisting de aplicaciones (permitir solo lo explícitamente autorizado) es una de las contramedidas más potentes, porque frena la ejecución de código no aprobado incluso cuando se apoya en intérpretes del sistema.

Restringir y registrar los intérpretes de scripts

Los intérpretes como PowerShell son a la vez imprescindibles para la administración y muy apetecibles para el atacante. Restringir su uso a lo necesario (por ejemplo, mediante modos de lenguaje restringido donde aplique), registrar toda su actividad y vigilar quién los invoca reduce el margen de abuso sin renunciar a su utilidad legítima. La misma lógica aplica a deshabilitar macros en documentos ofimáticos, un vector clásico de acceso inicial, y a retirar o restringir utilidades del sistema que no se necesiten en un entorno concreto.

Reducir la superficie disponible

Cada utilidad presente y habilitada es una herramienta potencial para el adversario. Revisar qué binarios y funciones son realmente necesarios, deshabilitar los que no lo son y controlar el acceso a los que sí lo son reduce directamente el arsenal LOTL disponible. No se trata de romper la administración legítima, sino de asegurarse de que cada capacidad potente está justificada, controlada y registrada.

Preguntas frecuentes

¿Cuál es la diferencia entre LOTL y malware fileless?

LOTL describe qué herramientas usa el atacante (binarios legítimos del sistema, los LOLBins) mientras que fileless describe dónde vive el código malicioso (en memoria o en mecanismos del sistema, sin escribir un fichero en disco). Se solapan y suelen aparecer juntos, pero responden a preguntas distintas: uno al qué y otro al dónde.

¿Por qué el antivirus tradicional no detecta estos ataques?

Porque el antivirus basado en firmas busca reconocer ficheros maliciosos conocidos. En LOTL la herramienta que se ejecuta es legítima y firmada (aunque el ataque despliegue algún fichero propio, el binario invocado no es sospechoso por firma), y en los ataques fileless el código puede existir solo en memoria, sin fichero en disco que escanear. Lo sospechoso es el comportamiento y los parámetros, no el fichero, así que la detección debe basarse en comportamiento.

¿Qué son los LOLBins y el proyecto LOLBAS?

Los LOLBins (living off the land binaries) son binarios, scripts y librerías legítimos del propio sistema que pueden ser abusados con fines maliciosos. El proyecto LOLBAS es un catálogo público que documenta cuáles son y qué funciones ofensivas permiten (descargar contenido, ejecutar código, evadir defensas o persistir), de modo que los equipos de defensa sepan qué vigilar.

¿Qué papel juega PowerShell en estos ataques?

PowerShell es un intérprete de automatización muy potente y presente por defecto en Windows, lo que lo convierte en una herramienta LOTL habitual para cargar y ejecutar código directamente en memoria. Por eso el registro de bloques de script, el registro de módulos y AMSI son controles clave: permiten inspeccionar y auditar lo que PowerShell ejecuta, incluso cuando llega ofuscado.

¿Cómo se detecta el malware fileless si no deja fichero?

Con detección basada en comportamiento (EDR/XDR), telemetría de línea de comandos, logging de PowerShell y AMSI, monitorización de WMI y del registro, y correlación en SIEM mapeada a MITRE ATT&CK. Al no haber fichero que escanear, la clave es capturar y correlacionar la actividad en tiempo de ejecución y, cuando hace falta análisis forense, examinar la memoria y los mecanismos de persistencia.

¿Qué medidas preventivas reducen el riesgo de LOTL y fileless?

Mínimo privilegio, allowlisting de aplicaciones, restricción y registro de los intérpretes de scripts, deshabilitación de macros innecesarias y retirada de utilidades que no se necesiten. Estas medidas reducen la superficie de ataque y limitan lo que un adversario puede hacer aunque consiga ejecutar código, complementando a la detección basada en comportamiento.

Recursos relacionados

• Tipos de malware
• Qué es un rootkit: funcionamiento y detección
• Evasión de EDR, LLM: ataques y defensa
• Qué es un EDR
• Qué es MITRE ATT&CK: tácticas y técnicas
• Qué es Mimikatz y el credential dumping
• Qué es el threat hunting
• Qué es el malvertising y el SEO poisoning

Ayuda profesional

En Secra somos una empresa de ciberseguridad ofensiva con programa propio de investigación de vulnerabilidades. Nuestro trabajo incluye el descubrimiento y publicación responsable de CVE, como CVE-2025-40652 en CoverManager y CVE-2023-3512 en Setelsa ConacWin CB, ambos registrados en NVD e INCIBE-CERT. Conocer de primera mano cómo operan los adversarios reales, incluidas las técnicas living off the land y fileless, nos permite evaluar tus defensas con una perspectiva realista. Si quieres poner a prueba la capacidad de tu organización para detectar este tipo de actividad sigilosa, ponte en contacto con nosotros.