Los ataques de malware sin ficheros (Fileless) son una preocupación creciente en ciberseguridad con una interesante historia que comienza en 2001. Tras permanecer casi en silencio por varios años, este tipo de amenaza comenzó a tomar relevancia en 2014 con nuevos conceptos introducidos a gran ritmo. Actualmente, dichos ataques son tan comunes que hay que desarrollar nuevas estrategias para identificarlos y contenerlos.
Orígenes
La industria de la seguridad se refiere a estas amenazas de distintas formas: ataques non-malware, malware in-memory (o basado en memoria), ataques living-off-the-land, o amenazas volátiles. Sin embargo, malware fileless (sin archivos) parece ser la forma más habitual. Terminología a parte, la base sobre la que se sustenta es la misma:
un malware que opera en memoria sin necesidad de ejecutables maliciosos externos
El concepto de malware fileless no es nuevo, de hecho data de la época de DOS y algunos quizá recuerden programas TSR: aplicaciones Terminate but Stay Resident (que al acabar siguen activas) que podían funcionar incluso tras devolver el control al usuario. Los desarrolladores de virus no tardaron demasiado en abusar de esta característica, siendo uno de los ejemplos más tempranos, allá por 1991, el apodado Maltese Amoeba (La Ameba Maltesa), usada para infectar ficheros tanto .COM como .EXE:
Le siguieron mucho otros, incluyendo el popular Walker:
Los virus TSR evolucionaron hacia una connotación más moderna de “fileless” con el infame gusano Code Red que en 2001 infectó computadoras sólo vía red, explotando un buffer overflow (desbordamiento de buffer) en servidores Microsoft IIS. El código malicioso existía exclusivamente en memoria, sin archivos escritos en disco, haciéndose así con el título del verdadero primer malware fileless.
Code Red demostró que las aproximaciones in-memory era no sólo posibles, también prácticas, dadas las circunstancias apropiadas. Pasaron varios años, en 2011 con DuQu y finalmente en 2014, hasta que apareció una nueva familia de malware fileless que dio inicio a una hola de amenazas que aún evoluciona rápidamente hoy en día. Aquel malware recibió el nombre de Poweliks y siendo técnicamente fileless, solía esconder su código encriptado en el Registro de Windows, mediante una compleja cadena de acciones que incluían varios scripts: un JScript seguido de un script de Powershell que se usaba para cargar y ejecutar una DLL maliciosa.
Poweliks dio lugar al concepto de ataques que “viven de la tierra” (Living-off-the-land): una familia de amenazas que recurren a componentes incluidos por defecto en el propio Sistema Operativo. El curioso nombre deja claro el concepto de depender de recursos locales en lugar de hacerlo de payloads externos. Parece que esta evolución se debió a dos factores: la adopción de los sistemas de Lista Blanca de Aplicaciones y de las, por entonces emergentes, tecnologías EDR, que ofrecían una visibilidad mayor de los terminales y nuevas capacidades de detección.
¿Por qué Fileless?
El malware tradicional requiere de un payload binario que puede escanearse fácilmente por un AntiVirus o ser bloqueado por un software de Lista Blanca de Aplicaciones. Los binarios también dejan una mayor huella forense que, potencialmente, puede reducir su capacidad de ocultamiento. Criminales y estados tuvieron que encontrar una nueva forma de distribuir malware: más oculta y capaz de evitar las aplicaciones de lista blanca.
Pasar al modo fileless era un paso natural dada la inmensa flexibilidad ofrecida por intérpretes como powershell y actualmente más del 50% de los ataques que detectamos, de hecho, están relacionados con malware fileless.
En términos de análisis, un ataque con malware fileless is bastante interesante y es, por supuesto notable, la ausencia de componentes externos. Como se muestra en el siguiente diagrama de ejecución, el atacante se basa exclusivamente en powershell, desde la intrusión inicial hasta el movimiento lateral hasta el siguiente terminal:
Todos los componentes usados por el atacante (whoami, notepad, sysprep, cmd, etc.) pertenecen a Windows y el único payload visto en el sistema es una cadena de texto codificada en base64 que contiene el script utilizado para ejecutar varias funciones, desde procesos de migración a escaladas de privilegios. ¿Cuál es la vía completa de infección de los ataques de malware fileless actuales?
Vía de Infección con Malware Fileless
Que la ausencia de binarios sea un pre-requisito para un malware fileless no significa que no haya código. Idealmente, un malware fileless se distribuye mediante procesos en memoria, por ejemplo explotando un navegador y, desde ahí, activando el payload in-memory. En términos prácticos, los exploits para navegadores – más genéricamente para aplicaciones cliente – se están haciendo difíciles de encontrar, así que los atacantes se basan a menudo en la ingeniería social. En dicho caso, el código malicioso se distribuye mediante un script o en las macros de un documento.
Podemos ver una vía tradicional de infección en el siguiente diagrama de ejecución que forma parte de una campaña de spear-phishing reciente en la que la carga maliciosa se ejecutaba mediante una Macro de MSOffice Word:
Estos ataques siguen considerándose fileless dado que el payload sólo es una cadena de texto; estrictamente hablando no se inyecta código ejecutable externo en la máquina de la víctima. El código malicioso se ejecuta completamente en el contexto de un proceso de confianza.
Powershell, obviamente, no es la única vía de infección, WMI (Windows Management Instrumentation) es otra poderosa herramienta que se ha explotado a menudo por atacantes para distribuir malware fileless. Poshspy ha sido una de las primeras amenazas en adoptar WMI como vector; aunque no la primera: The Moth, presentada en 2008, exploró por primera vez la posibilidad de usar WMI para crear un troyano fileless.
El esquema de ejecución de un ataque basado en WMI no se diferencia, en concepto, demasiado del que se basaba en powershell:
La combinación de malware Fileless con LOLbins (Living-of-the-Land) es letal: baja tasa de detección y capacidades para evadir soluciones de Lista Blanca… Espera: ¿Acabamos de decir LOLBins?
LOLBins: completando el puzzle
LOLBins es la abreviatura de Living Off the Land Binaries (Binarios que viven de la tierra) y no hace mucho que empezaron a ser parte esencial de los ataques fileless- APT34 (Lazarous Group) estuvo entre los primeros, a finales de 2017, que se valieron de LOLBins combinados con ataques fileless (POWRUNER) en uno de sus campañas de ataque. Entonces ¿por qué añadir una capa adicional a una familia de ataques que ya es inherentemente poderosa?
La respuesta radica en la capacidad para permanecer indetectado y para minimizar la cantidad de código desplegado para evitar reinventar la rueda. Un LOLbin comúnmente usado, como se vio en la imagen anterior, es bitsadmin.exe, un componente normalmente usado para programar transferencias en background que puede usarse para descargar, subir y ejectuar payloads (Técnica Mitre T1218), posiblemente evadiendo el sistema de listas blancas usado. Tal técnica no necesita disponer de funcionalidades de descarga/subida/ejecución en el código malicioso y, al mismo tiempo, desliga las actividades del malware: varios LOLBins son, de hecho, ejecutados en distintos contextos, sin relación obvia entre el malware fileless usado y sus acciones, además de que la acción la lleva a cabo un binario de confianza.
Para aclarar el significado de desligar (decorrelar) podemos echar un vistazo al siguiente diagrama de ataque que muestra, en una sóla imagen, tanto la etapa de infección fileless como la actividad llevada a cabo por el atacante.
La etapa de infección se inicia en un documento malicioso. Podemos identificar la actividad de red llevada a cabo por el script mientras que, aparentemente, el payload malicioso no está haciendo ninguna operación. Poco después, el malware real se activa desde un contexto diferente, desde wmpiprvse.exe, que activa una nueva instancia de powershell sin aparente relación con la infección orifinal.
Los LOLbins también ayudan a mantener un perfil de detección bajo puesto que realizan sus actividades empleando binarios específicos para los que dichas actividades resultan normales. Para aclararlo veamos un ejemplo sencillo: si una instancia de powershell descargando contenido de fuera de la red corporativa puede disparar las alarmas, quizá no ocurra lo mismo si otro binario muestra el mismo comportamiento durante sus operaciones normales. También puede destacar que Microsoft habilitase el análisis de scripts de powershell (desde Powershell 3) tras la fase de parseo, de modo que las capas de ofuscación son menos preocupantes y las detecciones se vuelven cada vez más precisas.
Los scripts y LOLBins trabajan en concierto para sacar provecho de las operaciones sin archivos, para evadir las soluciones de listas blancas de aplicaciones y para ayudar a los atacantes a mantener un perfil de detección bajo.
Detectar Malware Fileless y abuso de LOLBins
A menudo se usan intérpretes como Powershell, cscript y wscript tanto para tareas de administración como por parte de aplicaciones legítimas para desarrollar ciertas actividades. Simplemente, no resulta práctico disparar una alerta cada vez que uno de estos componentes se ejecuta en un terminal. Una buena práctica consiste en analizar los scripts mediante las nuevas capacidades de logging que ofrece Powershell y, cuando es posible, firmando digitalmente aquellos que lo requieren. Por supuesto, todas las características de seguridad presentes en Powershell 5 deben habilitarse para ayudar a los analistas a entender qué está haciendo un script “desconocido”.
La contra de esta aproximación es que el análisis manual es preciso pero consume mucho tiempo: el analista no puede dedicarse a tiempo completo a leer logs de powershell, por lo que sugerimos encarecidamente automatizar el proceso tanto como sea posible.
ReaQta-Hive usa una novedosa técnica para modelar el comportamiento de cada terminal y cada componente utilizado, partiendo de la actividad de usuario y descendiendo hasta el comportamiento interno. Este proceso de análisis permite automatizar la detección de operaciones anómalas que son atípicas para ciertos terminales o zonas de la infraestructura, ahorrando tiempo a los analistas y reaccionando más rápido de lo que nunca podrá hacerlo un operador humano.
Mientras que los algoritmos filtran la masa de operaciones, los analistas pueden invertir su tiempo en analizar las amenazas más inmediatas y en desarrollar búsquedas proactivas de amenazas que sirvan para descubrir amenazas activas.
Los atacantes que usan malware fileless evolucionan rápido, de modo que los defensores deben equiparse con herramientas que les permitan detectar y reaccionar antes de que los atacantes siembren el caos. Las capacidades de visibilidad y búsqueda son componentes clave en infraestructuras modernas, pero la automatización marca la diferencia cuando se trata de detección temprana y velocidad de reacción.
Póngase en contacto con nosotros para una demostración en vivo de nuestra solución frente a los útlimos malware fileless, o si tiene curiosidad sobre cómo operan este tipo de amenazas.