Campaña de infección de Zyklon y Cerber

Las últimas semanas estamos observando múltiples campañas de correos con documentos ofimáticos adjuntos, cuya finalidad es instalar diferentes tipos de malware en nuestros sistemas. En este post queremos repasar una campaña concreta que ha evolucionado sensiblemente en los últimos días, pero cuya finalidad se ha mantenido. La evolución ha consistido en el nombre de los documentos adjuntos, pues en principio, todos venían con el nombre “resume.doc” y posteriormente han empezado a añadir un nombre aleatorio al principio “[Nombre]_resume.doc.

Fichero Hash
Resume.doc 952c2637787e737714ce8bdd24e9f41179865f1431c2ad4bc8e849b88c2a2ab9
Resume.doc 1969f5bc5be1db820eff204504ba53efbf9ecd63a9b4af0b3f545586aec847ca
Kathleen_Resume.doc 4bbff4c776705bbf2d4be4a3ef1c9211fa2c691d90970c0cdc8b1c11f82a98a0
Itunes.exe 4a2bf3912a679c0a3b591f13004b36bd2e77938b61e2a29badfec0d2c8b21c23
Itunes.exe 9b8e7a442e4b7b08e6d25629f97ebd65%da2deac7a1677d9700b9ddf9f640b3f
Itunes.exe dd6178ae524b31d668e555caf22d72b50a467a0221a505357cf1e8d2d8861ccf

El Documento en cuestión muestra lo siguiente al ser abierto:

En caso de permitir la ejecución de macros, estas llaman a PowerShell con los siguientes parámetros:

Como resultado se descarga y ejecuta en %TEMP% un payload que carga 3 módulos en distintos procesos legítimos (explorer.exe, InstallUtil.exe y RegAsm.exe):

Tras iniciarlos, el ejecutable inicial termina su ejecución. Si se analiza la memoria de los tres procesos se puede observar como esconden código “extra” con finalidades muy concretas. En primer lugar, RegAsm.exe tiene mapeado un ejecutable en su memoria desarrollado en .Net:

Gracias a que está desarrollado en dicho lenguaje, podemos ver su código fuente utilizando la herramienta DnSpy, que nos da una idea bastante clara de su función:

Este proceso lo crea explorer.exe, y le pasa como parámetros, la ruta del ejecutable principal (Itunes.exe) y dos cadenas de caracteres aleatorios. En el código, se puede observar como utiliza los dos últimos parámetros para calcular el “mutex” que utiliza el malware. Con el cual se asegura de que todo sigue en correcta ejecución, y en caso contrario, lanza el binario que ha recibido como primer parámetro para restaurar la ejecución de todos los módulos.

El proceso InstallUtil.exe tiene mapeado en memoria de la misma forma otro binario, esta vez no se encuentra desarrollado en .Net y tiene nombradas las secciones del binario de forma que aparentemente viene empaquetado con UPX:

Puesto que lo extraemos de memoria ya desempaquetado, tampoco supone ningún tipo de problema especial ;). Analizando sus strings, comprobamos que se trata de un cliente para Tor, que se encarga de las comunicaciones del bichito. Las rutas de los ficheros se corresponden con las del cliente del repositorio oficial de Tor.

Por último, observamos el proceso “Explorer.exe”. Este, durante los primeros segundos de ejecución, ha escalado privilegios sin mostrar la característica ventana de del UAC y se está ejecutando como administrador, y como en los casos anteriores, encontramos mapeado en su memoria un ejecutable sospechoso. Pero esta vez, si lo extraemos, nos topamos con un fichero completamente corrupto, que la mayoría de herramientas fallan al analizar.

Observando un poco más su estructura, se puede comprobar cuál es el problema, tiene varias cabeceras de ejecutable por en medio de su contenido, y no pocas:

Cinco cabeceras MZ! Gracias a esta info, podemos aprovechar el plugin OllyDumpEx en nuestro debugger favorito (hay versión para la mayoría de ellos…) para extraer el ejecutable a partir de cada uno de los offsets hasta obtener el verdadero.

Ahora ya sí, podemos observar un ejecutable bastante sospechoso que, una vez más se encuentra desarrollado en .Net, por lo que vamos a DnSpy de nuevo a ver que nos muestra:

Nos vuelve a complicar un poco la vida, puesto que el código se encuentra ofuscado, esto dificulta seguir su lógica de forma cómoda, pero algunas cadenas, al menos, nos dan una idea de lo que tenemos entre manos, una muestra de la backdoor Zyklon probablemente. A pesar de estar ofuscado, hay funciones que aportan algo de información extra, cómo la capacidad de gestionar nuestros procesos:

O interactuar con el registro para obtener persistencia:

Respecto al tráfico, utilizando su cliente de Tor, contacta con sus C2 a través de URLs como las siguientes:

  • www.cs2zalvc4zbxy56kuhvh6.com
  • www.b7t3z635ijakyhuowlt.com
  • www.rl4tbw3itxqkle.com

Como se puede observar en el siguiente report de Hybrid-Análisis, este malware no es el objetivo final de la infección, pues una vez tiene el control del sistema, descarga y ejecuta una muestra del ransomware Cerber, en el cual ya no vamos a extendernos, pero que indica que están utilizando este malware solo como paso intermedio de la infección, cuyo fin parece ser infectar el equipo con otra muestra de malware, en este caso un Ransomware.

En la imagen, podemos ver como el ejecutable p666q.exe crea en el sistema los típicos ficheros con los pasos a seguir para recuperar los datos cifrados.

Una vez más estamos ante una campaña de infección de ransomware, cuya vía de entrada inicial es un documento con macros, por lo que debemos mantenernos muy alerta con respecto a los adjuntos de correos sospechosos, en especial si contienen documentos ofimáticos y por otra parte, una muestra de cómo van variando parte de las etapas de infección para complicar la detección y tener más control sobre el sistema infectado.

Comments

  1. Buenas, no termino de entender lo de que “tiene mapeado un ejecutable en su memoria”. ¿Es exactamente lo mismo que inyectar el código del ejecutable malicioso en un proceso legítimo o existe alguna diferencia con respeto a esto?

  2. Marc Salinas says:

    Hola pedro, es exactamente código inyectado en memoria, sencillamente me gusta la palabra “mapeado” , pero es cierto que seguramente quedaría más claro con la palabra inyectado.
    Hace la típica cadena “writeProcessMemory” en el proceso hijo, y posteriormente “createRemoteThread”