Las sandbox ejecutan cada muestra en un entorno controlado para observar su comportamiento malicioso, pero normalmente estos sistemas carecen de información acerca de cómo está empaquetada la muestra. Si recordamos entradas previas de este blog, los autores de malware generalmente empaquetan sus programas para evitar su detección y dificultar la ingeniería inversa. A grandes rasgos, un programa empaquetado contiene una rutina encargada de descomprimir o descifrar una sección de código protegida, que más tarde será ejecutada. A menudo, los autores de malware utilizan varias capas de empaquetado, fuertes métodos de ofuscación de código para cada una de las capas, así como métodos para evadir herramientas como sandbox, debuggers, frameworks de instrumentación, etc.

En muchas ocasiones, el analista de malware necesita analizar en profundidad de forma estática la totalidad del código de la muestra. Si la muestra está empaquetada, es necesario desempaquetarla para obtener un volcado del código original. Para ello, existen diversas alternativas. Por un lado existen unpackers específicos, que son capaces de lidiar con un número limitado de packers conocidos. Por otro lado, existen algunas herramientas de desempaquetado generico basadas en heurísticas. Desafortunadamente, estas heurísticas en ocasiones no presentan una gran efectividad. Como último recurso, el analista debe desempaquetar manualmente la muestra, lo que requiere analizar el empaquetador y averiguar cómo protege el código original.

Si bien existen multitud de sandboxes que permiten analizar malware para extraer indicadores de su comportamiento, no hay apenas herramientas que permitan entender el funcionamiento de un packer. PackerInspector pretende llenar este hueco, de tal modo que se especializa en este tipo de análisis y ofrece un informe detallado sobre diferentes características del packer, obtenidas de forma estática y dinámica. Estas caracteristicas (número de capas, interacción entre las mismas, número de procesos e interacción entre ellos, estructura de las diferentes capas…), nos permiten categorizar la estructura del packer en 6 niveles de complejidad estructural. Por ejemplo, UPX, uno de los packers más sencillos tiene una complejidad de tipo 1 (Type-I), mientras que Armadillo con la protección CopyMem activada, presenta una estructura de complejidad 6 (Type-VI).

El grafo que mostramos corresponde a un packer con un único proceso (P0), y 4 layers (0 a 3). Cada layer contiene una serie de regiones (áreas de memoria escritas y ejecutadas). Por ejemplo, si una determinada región Ra es escrita por otra región situada en la layer 1 (Rb), y Ra es después ejecutada, entonces Ra formará parte de la layer 2. Cada región contiene una primera línea que nos indica el tipo de memoria (M (módulo), S (stack), H (heap)) y su comienzo mientras que la segunda línea indica su tamaño. La tercera línea muestra 3 valores separados por “#”, que indican: el número total de llamadas a la API realizadas desde la región, el número de funciones de la API diferentes utilizadas, así como la presencia de llamadas a ciertas funciones relacionadas con el código bootstrap insertado por compiladores. Finalmente, la última línea muestra el número de frames (cuando una región ha sido escrita y ejecutada en varios turnos). Además, los colores diferencian las regiones, siendo la región roja la última en ejecutarse en nuestra sandbox.

Estamos ante un packer que descifra una primera capa, y tras ello pasa a ejecutarla (la región situada en 0x401000). A continuación, la rutina situada en la región 0x4079b1 (layer 1), descifra una segunda capa y la ejecuta, que a su vez descifra el código original (layer 3), y lo ejecuta. Los conectores grises nos indican que solamente ha habido una transición del flujo de ejecución entre cada par de capas, mientras que los conectores verdes y rojos nos indican el número de bytes escritos por cada región a regiones en la siguiente capa (de color verde, excepto cuando existe una transición de ejecución además de la escritura, en cuyo caso se muestra en rojo). Finalmente, vemos que la región roja de la última capa contiene un número muy superior de llamadas a la API, además de llamadas a la API relacionadas con el código inicial insertado por el compilador. Todo ello nos indica que el binario original se encuentra en esta capa.

Si quieres aprender más sobre cómo funciona PackerInspector, puedes visitar la página de referencia. En nuestro estudio original, medimos la evolución de la complejidad del empaquetado de muestras enviadas a la sandbox Anubis a lo largo de varios años. Hoy, al publicar este servicio, damos continuidad a este estudio recogiendo estadísticas globales de la complejidad de las muestras que compartáis con nosotros.

PackerInspector permite el envío de muestras de forma pública y privada. Para poder hacer uso del envío privado, deberás iniciar sesión con una cuenta de Google (OpenID). Con este registro, no almacenamos información más allá de un identificador único por cuenta y aplicación. Para las muestras enviadas de forma pública,  el resultado del análisis será accesible por cualquiera en posesión de la url correspondiente. Sin embargo, si envías la muestra de forma privada, solamente tú podrás acceder al informe generado. Además, si estás registrado, podrás realizar un seguimiento de las muestras enviadas para su análisis, así como localizar informes de muestras enviadas anteriormente y utilizar la API pública para automatizar el envío de muestras y recopilación de resultados.

Happy reversing!

The post PackerInspector: Nuestra sandbox para packers appeared first on S3lab.

Me parece que se me había pasado comentaros pero…

Es extremadamente común que un malware avanzado no se dedique únicamente a esconder su código con diferentes packers, sino que también intente detectar si está siendo analizado de forma dinámica mediante una sandbox. En caso de darse cuenta de que lo están vigilando, modificará su comportamiento para esconder su funcionalidad maliciosa y mostrar funciones completamente inocuas. De esa forma, el sistema de análisis clasificará la muestra como benigna y podrá infectar el sistema objetivo sin problema alguno.

Muchas veces, conseguir detectar al vigía no es sencillo, por lo que los autores de malware suelen comprobar si efectivamente el malware está siendo detectado o no por determinadas sandbox. Para ello, hacen uso de las diferentes herramientas publicas. Van enviando las versiones de su malware hasta lograr una que pase completamente desapercibida. De todas formas, esto puede llegar a ser contraproducente, ya que como se ha mostrado en un trabajo reciente, el envío consecutivo de estas muestras permite la detección temprana de esos malware primigenios. Ahora, nos centraremos en explicar las ideas generales de cada una de las principales técnicas que se usan actualmente en el malware para detectar sandbox:

• Interacción de usuario: Como cabe esperar, los análisis dinámicos en sandbox no se realizan de forma manual, sino de una forma completamente automatizada. Basándonos en eso, es posible detectar el análisis simplemente fijándonos en la interacciones que hace o debería hacer un usuario (movimientos de ratón, pulsaciones de teclado…). Esto se puede hacer tanto incitando al usuario ha realizar dichas acciones mediante un instalador falso o comprobándolas sin ningún tipo de incentivo.

• Penalización de tiempo: Monitorizar un sistema y su comportamiento no es sencillo y hace uso de un gran número de herramientas de forma interna para lograrlo. Esta vigilancia tiene un castigo: el tiempo. La cantidad de pasos que tiene que dar cada ejecución es mayor, por lo que si analizamos el tiempo necesario para realizar cada acción podemos darnos cuenta que algo «extra» está ocurriendo, permitiéndonos detectar la presencia de una sandbox.

• Sistemas artificiales: Esta técnica no se basa en la detección de propiedades que puedan identificar una sandbox, sino en detectar que la máquina no se trata de un sistema de producción normal. Algunos de los ejemplos más sencillos serían la ausencia de ciertos drivers, tamaños de disco, memoria extremadamente pequeña o la falta de aplicaciones indispensables para cualquier usuario. Ya comentamos algo similar al hablar de honeypots de baja interacción, siendo éste uno de sus mayores problemas.

• Tecnologías específicas: Al contrario que en el punto anterior, en este caso nos centraremos en detectar situaciones anómalas que muestran un comportamiento fuera de lo común. La gran mayoría de sandbox usan hooks para capturar las comunicaciones entre diferentes componentes del sistema. Con una simple verificación del hash de ciertos ficheros del sistema se puede detectar que han modificado el código de los mismos. Para casos de emulación, realizar llamadas a instrucciones de CPU no incluidas puede ser muy útil.

De todas formas, estas técnicas no funcionan en todos los casos, ya que de la misma manera que el malware intenta detectar que lo vigilan, el que vigila intenta esconder lo que está haciendo. Si algo queda claro después de todo esto, es que las sandbox genéricas han quedado obsoletas y que confiar en un análisis así no es algo que haya que hacer si no queremos llevarnos ningún susto.

El que avisa no es traidor.

The post Ese malware sabe que lo están vigilando appeared first on S3lab.