El 27 de junio de 2017, un nuevo ataque afectó a muchos sistemas informáticos en Ucrania y otros países, incluyendo algunos de Latinoamérica. Fue encabezado por el malware que los productos de ESET detectan como Diskcoder.C (también conocido como ExPetr, PetrWrap, Petya o NotPetya). Este malware se hace pasar por un típico ransomware: cifra los archivos y demanda 300 dólares como rescate. Pero la intención de sus autores era causar daño y corromper la información más que obtener el dinero, por lo que hicieron todo lo posible para hacer el descifrado de los archivos muy poco probable.

En nuestro artículo anterior, le atribuimos este ataque al grupo TeleBots y revelamos detalles sobre otros ataques similares que afectan a procesos de producción en Ucrania. Hoy revelamos más información sobre el vector de distribución inicial que se usó durante el brote de DiskCoder.C.

La historia de una actualización maliciosa

El departamento de policía cibernética de la Policía Nacional de Ucrania afirmó en su cuenta de Facebook, tal como hicieron ESET y otras compañías de seguridad informática, que el software contable legítimo ucraniano llamado M.E.Doc había sido usado por los atacantes para propagar al malware DiskCoder.C en la fase inicial del ataque. Sin embargo, hasta ahora no se habían provisto detalles sobre cómo lograron esto.

Durante nuestra investigación, identificamos un backdoor muy sigiloso y bastante desarrollado, que fue inyectado por los atacantes en uno de los módulos legítimos de M.E.Doc. Parece poco probable que los atacantes pudieran haber hecho esto sin acceso al código fuente del software.

El módulo al cual se le agregó el código del backdoor tenía como nombre de archivo ZvitPublishedObjects.dll. Fue escrito usando el framework .NET y constaba de 5MB que contenían una gran cantidad de código legítimo, que puede ser llamado por otros componentes incluyendo el ejecutable principal M.E.Doc ezvit.exe.

Examinamos todas las actualizaciones de M.E.Doc que se publicaron durante 2017, y hallamos que hay al menos tres que contenían el módulo alterado para incluir el backdoor:

01.175-10.01.176, liberada el 14 de abril de 2017
01.180-10.01.181, liberada el 15 de mayo de 2017
01.188-10.01.189, liberada el 22 de junio de 2017

El incidente con el ransomware XData (Win32/Filecoder.AESNI.C) ocurrió tres días después de la actualización 10.01.180-10.01.181 y el brote de DiskCoder.C ocurrió cinco días después de la 10.01.188-10.01.189. Lo que es curioso, cuatro actualizaciones comprendidas entre el 24 de abril de 2017 y el 10 de mayo de 2017, así como siete comprendidas entre el 17 de mayo y el 21 de junio de 2017 no contenían el módulo con el backdoor.

Dado que la actualización del 15 de mayo sí lo contenía y la del 17 de mayo no, tenemos una hipótesis que podría explicar la baja tasa de infección de Win32/Filecoder.AESNI.C: el lanzamiento de la actualización del 17 de mayo fue un hecho inesperado para los atacantes. Liberaron el ransomware el 18 de mayo, pero la mayoría de los usuarios de M.E.Doc ya no tenían el módulo con backdoor porque ya habían actualizado.

La información de compilación de archivos analizados sugieren que fueron compilados en la misma fecha que la actualización del día anterior:

Figura 1: Marca de tiempo de la compilación del módulo con backdoor incluido en la actualización del 15 de mayo.

La imagen 2 muestra la diferencia entre la lista de clases de la versión con y sin backdoor del módulo, usando el descompilador .NET ILSpy:

Figura 2: Lista de clases en el módulo con backdoor (a la izquierda) y sin backdoor (a la derecha).

La clase principal del backdoor se denomina MeCom y está ubicada en el espacio ZvitPublishedObjects.Server, como se muestra en la Figura 2.

Figura 3: Clase MeCom con código malicioso, como se muestra en el decompilador .NET ILSpy.

Los métodos de la clase MeCom son invocados por el método IsNewUpdate de UpdaterUtils en ZvitPublishedObjects.Server. El método IsNewUpdate se ejecuta periódicamente para verificar si hay una nueva actualización disponible. El módulo con backdoor del 15 de mayo es implementado de manera ligeramente distinta y tiene menos funcionalidades que el del 22 de junio.

El Registro Estatal Unificado de Empresas y Organizaciones de Ucrania contiene valores EDRPOU que identifican a las entidades que operan en el país. Este dato es extremadamente importante para los atacantes: teniendo el número EDRPOU, podrían identificar a la organización exacta que está usando una versión de M.E.Doc modificada con el backdoor. Una vez que lo hacen, usan distintas tácticas contra su red, dependiendo del objetivo que persigan.

Dado que M.E.Doc es un software contable comúnmente usado en Ucrania, podría esperarse encontrar los valores EDRPOU en los datos de aplicación de las máquinas que lo utilizan. Es así como el código que se inyectó en el método IsNewUpdate recolecta todos los valores EDRPOU de los datos de aplicación; aprovechando que una instancia M.E.Doc podría ser usada para ejecutar operaciones contables para múltiples organizaciones, el código que contiene el backdoor recopila todos los números EDRPOU posibles.

Figura 4: Código que recolecta números EDRPOU.

Junto a los números EDRPOU, el backdoor recolecta ajustes del proxy y de correo electrónico, incluyendo nombres de usuario y contraseñas de la aplicación M.E.Doc.

Advertencia: si tu empresa tiene relación con alguna de las empresas afectadas en Ucrania y Europa que utiliza el software M.E.Doc, recomendamos cambiar las contraseñas de proxies y cuentas de correo electrónico a todos los usuarios del software M.E.Doc.

El código malicioso escribe la información reunida en el registro de Windows bajo la clave HKEY_CURRENT_USER\SOFTWARE\WC usando los nombres de valores Cred y Prx. Así que si estos valores existen en una computadora, es altamente probable que el módulo que contiene el backdoor ya se haya ejecutado en ella.

En cuanto a la comunicación entre las máquinas infectadas y los atacantes, el módulo que contiene el backdoor no usa servidores externos como C&Cs, sino que usa las peticiones regulares de verificación de actualización del software M.E.Doc, hechas a su servidor oficial, upd.me-doc.com[.]ua. La única diferencia con una petición legítima es que el código con backdoor envía la información recolectada en cookies.

Figura 5: Petición HTTP de módulo con backdoor que contiene número EDRPOU en las cookies.

Si bien no hemos hecho un análisis forense del servidor de M.E.Doc, como dijmos en nuestro artículo anterior, hay señales de que fue comprometido. Por lo tanto, podemos especular que los atacantes usaron alguna aplicación en el servidor que les permite diferenciar entre peticiones que provienen de máquinas infectadas o no.

Figura 6: Código de backdoor que añade cookies a la petición.

Y, por supuesto, los atacantes añadieron la habilidad de controlar la máquina infectada. Esta amenaza recibe un binario oficial del servidor de M.E.Doc, lo descifra usando el algoritmo Triple DES, y, posteriormente, lo descomprime usando GZip. El resultado es un archivo XML que contiene varios comandos. Esta funcionalidad de control remoto convierte al backdoor en una plataforma de ciberespionaje y cibersabotaje con amplitud de capacidades.

Figura 7: Código del backdoor que descifra los comandos entrantes del operador del malware.

La siguiente tabla muestra posibles comandos:

Comando	Propósito
0 – RunCmd	Ejecuta el comando de shell suministrado
1 – DumpData	Decodifica los datos de Base64 suministrados y los guarda en un archivo
2 – MinInfo	Recolecta información sobre versión del SO, bits (32 o 64), privilegios, ajustes UAC, ajustes de proxy, ajustes de email incluyendo usuario y contraseña
3 – GetFile	Recoge el archivo de la computadora infectada
4 – Payload	Decodifica los datos de Base64 suministrados, los guarda en un archivo ejecutable y lo ejecuta
5 – AutoPayload	Igual que el anterior, pero el archivo suministrado debe ser un DLL y se ejecutará desde la carpeta de Windows utilizando rundll32.exe. Además, intenta sobrescribir el DLL y eliminarlo.

Debemos señalar que el comando número 5, nombrado por los autores del malware como AutoPayload, encaja a la perfección con la forma en que DiskCoder.C se ejecutó inicialmente en las máquinas del "paciente cero".

Figura 8: Método AutoPayload que se usó para ejecutar el malware DiskCoder.C.

Conclusiones

Como muestra nuestro análisis, esta es una operación altamente planificada y ejecutada con precisión. Asumimos que los atacantes tuvieron acceso al código fuente de la aplicación M.E.Doc. Tuvieron tiempo de conocer el código e incorporarle un backdoor bien sigiloso y astuto, que evita ser detectado fácilmente.

El tamaño de la instalación completa de M.E.Doc es de aproximadamente 1,5 GB, por lo cual en este momento no tenemos forma de verificar si existen otras modificaciones del tipo backdoor inyectadas en el código.

Todavía hay cuestiones por responder. ¿Cuánto tiempo estuvo en uso este backdoor? ¿Qué otros malware demás de DiskCoder.C y Win32/Filecoder.AESNI.C han sido propagados por esta vía? ¿Qué otras actualizaciones de software podría haber comprometido esta pandilla para usarlas como armas?