En la primera parte de esta serie, nos enfocamos en una introducción a los conceptos de malware sin archivos, y brindamos ejemplos de los problemas que enfrentamos en la industria de la seguridad al tratar con este tipo de ataques. 

En la segunda parte, caminaré a través de algunas demostraciones de ataques de malware sin archivos que he creado. Estos laboratorios demuestran los problemas que enfrentamos cuando intentamos detectar malware sin archivos.

Primero comenzaré con una demostración de malware que se detecte estrictamente con firmas estáticas. El archivo que usaré es un binario personalizado, que creé desde cero y no realiza actividades maliciosas. Es completamente benigno.

La razón para usar un archivo benigno para la demostración es que no quiero que ninguno de los otros componentes más avanzados del AV inicie y trate de detectar este archivo. Quiero mostrar lo que sucede cuando confiamos puramente en firmas estáticas. Simplemente hemos creado una firma estática para este binario específico para que cuando se ejecute o escanee en cualquier computadora que ejecute Malwarebytes, se detecte.

Después de esta prueba, probaré un malware legítimo a través de los mismos métodos sin archivos para ilustrar la tecnología de detección necesaria que debe implementarse para detectar la amenaza.

Antes de comenzar, primero cubriré cómo funcionan las detecciones estáticas para aclarar qué es exactamente lo que se está evadiendo con estos métodos sin archivos. Luego cubriré algunos métodos de detección más sofisticados, que en esta era moderna de la seguridad son los componentes más importantes para detectar las amenazas nuevas y desconocidas.

Detección estática

Hay algunas formas de detectar malware de forma estática. Lo más básico, y francamente, el método de detección más inútil en la actualidad es el hashing del archivo. En este caso, existe una tasa de detección de firma de uno a uno para el malware.

Para que una única firma cubra mucho más terreno, los motores modernos de detección estática extraen áreas clave del binario y permiten que se realicen firmas en códigos de operación o cadenas de caracteres específicos dentro de las secciones del binario. El mejor ejemplo de código abierto de esto serían las reglas de YARA . Si no está familiarizado con YARA , tómese un minuto para buscarlo, ya que es una herramienta valiosa para el análisis de malware.

A continuación se muestra un ejemplo de una detección utilizando YARA. La regla de ejemplo es completamente aleatoria y no está hecha para detectar ningún malware.

regla ExampleDetection
{ 
     instrumentos de cuerda: 
          $ hex_string = {AA (BB | CC) [3] FF [2-4] 00} 
          $ string1 = "malString" amplia ascii fullword
          $ hex2 = {CC DD 33 DD}
     condición: 
          $ hex_string y # string1> 3 y $ hex2 en el punto de entrada y tamaño de archivo> 200 KB
}

Una sola regla similar a esta, aunque en la categoría de firmas estáticas, puede detectar cientos o miles de malware que tienen características similares.  Una buena firma estática aún le permite ser dinámico y detectar malware incluso cuando un escritor modifica su código.

Pero, a pesar de que  estos métodos de detección estática son bastante efectivos en ciertos casos, hay algunos inconvenientes importantes. La primera caída, y la más obvia, es que si los códigos binarios y las cadenas se cambian más allá de lo que el autor de la firma tomó en consideración, la detección ya no se activará. Esta es la razón principal por la que los antivirus han agregado métodos más dinámicos para detectar malware sofisticado en sus soluciones. Estas incluyen firmas de comportamiento, detecciones de comportamiento, heurísticas, emuladores autocontenidos, aprendizaje automático e inteligencia artificial.

Algunas de estas tecnologías están incluidas en los productos de consumo y de negocios de Malwarebytes, y se enumeran a continuación:

La segunda caída a las firmas estáticas es lo que ilustraré en este primer laboratorio. Si no hay ningún binario en el disco para ejecutar una firma estática, entonces la firma estática no tiene nada que detectar. Entonces, en definitiva, falla. Aquí es donde los ataques sin archivo tienen éxito.

En un mundo perfecto, con capacidad de computación ilimitada, teóricamente podríamos extraer cada bit de datos de la memoria en todo momento y ejecutar firmas estáticas para luego superar esta caída. Pero como el rendimiento siempre es un problema, esto no es posible y las firmas estáticas fallarán en este escenario. Dicho esto, procederé al primer laboratorio.

Laboratorio 1: Bypass solo estático

Primero, ejecutaré el archivo de detección de prueba  manualmente en un sistema con Malwarebytes para que podamos ver la parte de firmas estáticas que captura el archivo.

Como puede ver, el archivo fue detectado como Trojan.Vhioureas.POC. Nuevamente, esto se debe a que creé una detección de prueba en una cadena única que hice usando este sencillo programa. Si el programa tiene éxito, aparecerá una aplicación de calculadora.

Ahora cargaré el mismo archivo de prueba utilizando el marco inicial: un marco de ejecución sin archivos.

Como puede ver, el archivo vhioureasPOC no activó ninguna detección, y Calc apareció. La razón es que el marco de inicio transmitió la fuente de malware completamente desde un servidor y la ejecutó únicamente dentro de la memoria.

Puede ver esto en el parámetro de comando a UpdateService.exe, que es el binario inicial del cargador de clientes. Extrajo el código fuente de vhioureasPOC del servidor que configuré en la dirección en la URL. El método de transmisión sin archivos evadió el motor de firma estática de la AV.

Marco de inicio

Antes de continuar con el Laboratorio 2, analizaré el marco de inicio  y cómo se puede usar para cargar cualquier archivo .NET en la memoria.  Comenzaremos con el lado del servidor.

El lado del servidor de inicio tiene dos componentes principales: el generador de carga útil y el servidor de malware real. El generador de carga útil toma como entrada, un archivo de código fuente de C #, y le proporciona un token de URL personalizado para buscar en el lado del cliente.

Después de que hayamos generado la carga útil, cuando ejecutamos el componente del servidor de malware, podemos recuperar el código fuente en forma codificada a través de cualquier solicitud http. Por ejemplo, si navegamos a la URL generada en un navegador en nuestra máquina cliente, veremos una cadena larga de base 64 en la ventana del navegador. Esta es la carga útil.

Ahora moviéndose hacia el lado del cliente de inicio.  El cliente en sí mismo es benigno. No contiene ningún código malicioso. Es simplemente una herramienta de línea de comandos que toma una URL como entrada. Obtiene lo que está al final de esa URL e intenta leerlo como texto, específicamente buscando el formato correcto del código fuente de C #. Luego toma el texto C # y, utilizando el compilador nativo del sistema operativo, realiza la compilación en tiempo de ejecución únicamente en la memoria. Luego ejecuta el código generado.

Así es como pudimos evadir el motor de detección de estática. Nunca hay ningún punto en el que exista el código de malware del servidor en el disco duro. Debido a este hecho, no hay ningún archivo para que el motor estático pueda escanear.

Como nota al margen, me gustaría agregar que, en general, ningún AV detecta el código fuente del lenguaje compilado. La razón aquí es que el código fuente nunca puede ejecutarse sin ser compilado, y por lo tanto nunca puede causar daño. Este es un punto interesante porque incluso una firma de red, como snort o cualquier IDS, es poco probable que lo detecte. El binario malicioso nunca se transmite, solo se transmite el código fuente. Por lo tanto, evade todas las firmas estáticas, incluso en el lado de la red.

Luchando contra esta amenaza

Como evitamos el motor estático, los antivirus de hoy en día, como mencioné anteriormente, deben contener tecnología para detectar dinámicamente la actividad maliciosa en el sistema en lugar de simplemente detectar firmas maliciosas.

Para probar que esta tecnología existe y funciona correctamente, volveremos a ejecutar inception contra la máquina víctima, solo que esta vez será con una carga útil que realmente realiza una función maliciosa para la víctima. Debemos esperar que el motor AV tenga la capacidad de determinar que la ejecución en el sistema es maliciosa en función de su actividad. Esto es exactamente lo que probaremos en el laboratorio 2.

Laboratorio 2: ransomware sin archivo

Para este laboratorio, cargaré un código fuente de una muestra de ransomware a través de inicio. Esencialmente, nada cambia de los pasos anteriores. Solo ahora, la generación de carga útil en el lado del servidor apunta a un archivo de código fuente de ransomware en lugar de la prueba POC.

Como puede ver, esta vez se activó una detección. Aunque el motor estático no detectó el malware, la parte del comportamiento de la aplicación del motor intervino y determinó que había una actividad maliciosa en el sistema que se comportaba como un ransomware y provocó la detección. Es por eso que lo ve detectado como Ransom.Agent.Generic.

Estático vs dinámico

He creado estas demostraciones para mostrar algunos de los problemas que puede causar el malware sin archivos, principalmente porque pudieron evitar fácilmente los motores estáticos. Esto no significa que creo que las firmas estáticas no tienen su lugar en la detección de malware. Simplemente estoy mostrando su debilidad cuando se trata de un ataque sin archivo.

Las firmas estáticas ayudan a los investigadores a clasificar correctamente las familias de malware y proporcionar detecciones más detalladas. Esto suele ser porque, detrás de una firma, hay un analista de malware que ha dedicado tiempo a investigar y comprender las características del malware. He visto muchas situaciones en las que una buena firma ha detectado un malware que el motor de aprendizaje automático no pudo identificar. Sin embargo, cuando la detección estática falla, la detección dinámica debe tomar el control. Esta simbiosis es clave.

Soy de la escuela de pensamiento de que tanto la detección estática como la dinámica son necesarias, y una buena combinación de ambas sigue siendo extremadamente valiosa. Normalmente, cuando un proveedor de antimalware usa firmas además de la tecnología de próxima generación en su repertorio, es una señal de que hay analistas de malware activo en el otro lado de la pantalla.

Esto me da tranquilidad, ya que los proveedores no están abandonando la lucha contra el malware únicamente por algoritmos y tecnología. La tecnología no es lo suficientemente avanzada como para dejarla totalmente a cargo, y mientras tanto, una mezcla de humanos y tecnología, analista de malware y máquina, sigue siendo la mejor opción.

Manténgase atento a la tercera parte de esta serie, donde proporcionaré un análisis detallado de varias familias de malware sin archivos.