Nuestras radiografías de NotPetya

Desde el laboratorio de malware hemos estado atentos y analizando varios aspectos de lo que se ha llamado NotPetya, Wannapetya, ExPetya, etc. Lo que primero que nos preocupó en el laboratorio era conocer exactamente como se estaba propagando el malware. Para ello partimos de la dll (027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745) que se puede encontrar en Hybrid Analysis.

En el entorno de laboratorio levantamos dos máquinas Windows 7 sin los parches para protegernos de EternalBlue. El análisis de McAfee también ha mostrado el mismo comportamiento a nivel de red en este magnífico informe publicado durante los primeros días. A partir de ahí planteamos los siguientes dos escenarios:

Escenario 1:

Las dos máquinas no están en el dominio, pero existe en las dos máquinas un usuario con las mismas credenciales. Estas máquinas están en el mismo segmento de red.

Una vez preparado el entorno ejecutamos la dll del siguiente modo:

$ rundll32.exe  petya.dll,#1

A partir de este momento vemos como el equipo A (11.11.11.66) empieza a generar peticiones ARP para descubrir nuevos equipos dentro del mismo segmento de red. En nuestro caso, encuentra el equipo B (11.11.11.4) e inmediatamente intenta la autenticación sobre la máquina remota y se autentica. A continuación, el malware empieza a copiar la dll (en nuestro caso la hemos llamado lolz.dll) al recurso remoto:

Una vez copiada vemos como copia un fichero con el nombre PSEXESVC.EXE:

Después de copiarlo levanta un servicio:

Una vez terminada la comunicación lo que veremos en la máquina remota será:

Escenario 2:

Las dos máquinas no están en el dominio, no existe ningún usuario en común entre las dos máquinas, y no nos hemos autenticado entre las máquinas. Las máquinas no están parcheadas. Estas máquinas están en el mismo segmento de red. Una vez preparado el entorno ejecutamos la dll del mismo modo que antes y, en este caso, después de intentar autenticarse sobre la máquina remota y recorrer el /24 enviando mensajes ARP se produce la siguiente actividad:

Con esto, igual que ya comentan desde McAfee y otros análisis, se intenta explotar EternalBlue (https://securingtomorrow.mcafee.com/mcafee-labs/analysis-wannacry-ransomware/). Después de este tráfico obtuvimos el mismo resultado que en el escenario 1.

Una vez ejecutada la dll en el equipo, se produce la siguiente secuencia de ejecución de procesos que clarifica todo lo que sucede -extracto del análisis de la sandbox de Hybrid Analysis:

De la ejecución hay dos cosas a destacar, ya que el resto como es el caso de las tareas programadas está muy comentado en otros análisis:

1. La ejecución de FE04.tmp. Este fichero es el binario que tiene parte de la lógica del mimikatz. Una vez se ejecuta se borra a sí mismo, poniendo el fichero .tmp a 0’s.
2. La ejecución de dllhost.dat. Este fichero dllhost.dat es el psexec.

La dll contiene internamente tres binarios en formato PE (2 x86 y 1 x86-64).

Si extraemos los PE nos encontramos que uno de ellos se trata de PSEXEC:

$file 26790:

26790: PE32 executable (console) Intel 80386, for MS Windows

$ sha256sum 26790:

f8dbabdfa03068130c277ce49c60e35c029ff29d9e3c74c362521f3fb02670d5  26790

Los otros dos binarios:

$ file 1FC6C:

1FC6C: PE32+ executable (console) x86-64, for MS Windows

$ sha256sum 1FC6C:

02ef73bd2458627ed7b397ec26ee2de2e92c71a0e7588f78734761d8edbdcd9f  1FC6C

$ file 19AEC:

19AEC: PE32 executable (console) Intel 80386, for MS Windows

$ sha256sum 19AEC:

eae9771e2eeb7ea3c6059485da39e77b8c0c369232f01334954fbac1c186c998  19AEC

Según algunos antivirus estos hashes se corresponde con una variante de Mimikatz como podemos ver:

Tras contrastar la información recopilada de varios análisis externos, y realizar varias ejecuciones en distintos entornos, hemos querido recorrer algunas zonas de la lógica de ejecución de esta amenaza para contrastar toda la información y obtener resultados más claros.

Para ello, vamos a recorrer su lógica por orden de ocurrencia en una ejecución normal, de donde queremos mostraros algunas “radiografías” para compartir con vosotros cómo funciona internamente este bicho y nuestra interpretación de estas:

En primer lugar ejecuta la función “GetTickCount”, lo que le permitirá posteriormente, comprobar el tiempo que ha tardado en llegar a ciertos puntos, a fin de detectar si está siendo analizado dinámicamente:

Durante varias zonas del código, consulta de nuevo dicho valor, para generar un error en caso de que detecte retardos sospechosos en su ejecución:

Como se puede comprobar en la primera captura, justo después del “GetTickCount”, carga la lista de privilegios que va a necesitar y llama a la función “sub_695C81BA” que comprueba si el proceso cuenta con estos permisos:

Tras esto, entra en la zona que algunos llaman “killSwitch” o “Vacuna” obtiene el nombre de su ejecutable (no uno concreto), crea una cadena con la ruta “C:\Windows\[su propio nombre]” y por alguna razón, justo después, elimina la extensión de la cadena sustituyendo el punto por un “0x00”.

En la siguiente captura, se puede observar cómo si encuentra dicho fichero con el nombre que tenga el malware en ese momento, termina la ejecución del malware. En caso de no encontrarlo, lo crea y continúa la ejecución.

Esto nos da que pensar que este comportamiento lo trae como forma de evitar ejecutarse repetidas veces en un mismo equipo. Algo que otros tipos de malware suele hacer con un “mutex”.

Tras esto, viene el momento de la infección del sector de arranque del equipo y para ello busca el disco donde se encuentra instalado el sistema operativo, y posteriormente obtiene un handler a este dispositivo lo que le permite escribir en los primeros sectores gracias a los permisos que ha comprobado al principio que posee.

Su siguiente acción será crear la tarea que se encargará de reiniciar el equipo en un margen de tiempo para asegurarse que se cifra el MBR del equipo al finalizar la infección.

Seguidamente viene una parte importante del funcionamiento de este malware ya que crea un thread (hilo de ejecución) que lleva a cabo mucha lógica de red, aunque no toda. Posteriormente crea nuevos threads con más rutinas distintas que trabajan con librerías de red:

Dentro del parámetro “lbStartAddress” que le indica al thread desde que zona de código tiene que empezar su ejecución, le pasa una función que en varias iteraciones carga distintas librerías de red, y recorre repetidas veces rangos de IPs:

En paralelo a esto, continúa su lógica principal, en la cual, ahora comprueba la arquitectura del sistema, y podemos ver como escoge uno de sus dos primeros recursos y lo extrae:

A partir de este punto, en la siguiente captura, se ve el resto de la lógica que tiene guardada para este:

En primer lugar, obtiene la ruta del directorio %TEMP%, y guarda en dicho directorio el fichero recién extraído de recursos y descifrado con atributo oculto:

El fichero en cuestión es un ejecutable, y analizando su lógica hemos podido observar que se trata de la versión de mimikatz reducida y personalizada, en este caso una para la arquitectura de nuestro SO.

Con esto podemos ver que sus dos primeros recursos son las dos versiones de mimikatz para cada arquitectura.

En la captura de código anterior, se puede observar como crea, en primer lugar un GUUID y a partir de este una “pipe” que  tras esto, abre un nuevo thread cuya lógica consiste en un bucle que monitoriza el contenido de la pipe:

Tras crear dicho thread, por último, ejecuta el mimikatz al que le pasa como parámetro la misma “pipe” que al thread anterior. Generalmente estas pipes, son utilizadas como vía de comunicación entre ambos procesos.

De esta forma espera a obtener las credenciales que recopila del sistema con la función “WaitForSingleObject”. En el momento en que los obtiene llama a la función “TerminateThread” para cerrar ese hilo y continuar, ahora ya con credenciales que ha recopilado del equipo.

Seguidamente, extrae el tercer fichero que contiene en recursos (esta vez independientemente de la arquitectura del sistema) y lo deja en la carpeta “C:\Windows\” con el nombre “dllhost.dat”:

Si analizamos un poco dicho fichero, podemos observar como se trata de la herramienta “psexec” de Sysinternals:

Llegados a este punto, cuenta con gran cantidad de información de recursos en la misma red del equipo infectado y credenciales recopiladas con mimikatz, así que lo que le queda es recorrer todos esos equipos e intentar acceder a ellos con la lista de credenciales que tiene:

Por supuesto, en otro thread, ya que aún tiene cosas que hacer el hilo principal.

Mientras tanto, en el thread principal va a crear un nuevo hilo muy representativo de todo ransomware. El cual lista todos los discos conectados al equipo, y para cada uno, crea un bucle que recorre cada uno de sus ficheros, comparándolos con una lista de extensiones (exceptuando el directorio “C:\Windows”):

Tras hacerse con un fichero que coincide con las extensiones de su lista, llama a una función que se encarga de cifrar por completo todo su contenido:

De esta forma, vemos como antes de que se reinicie el equipo y se cifre el MBR, cifra también nuestros ficheros. Mientras tanto, crea un nuevo proceso “cmd.exe” al que le pasa varios comandos como parámetro:

cmd.exe /c wevtutil cl Setup & wevtutil cl System & wevtutil cl Security & wevtutil cl Application & fsutil usn deletejournal /D C:

Esto se encarga de limpiar el log del visor de eventos de Windows para eliminar huellas.

Por último, la lógica restante, consiste en dos formas extra de asegurarse de que el equipo se reinicia al finalizar la ejecución.

El primero es el más agresivo, ya que utiliza la función no documentada “NtRaiseHardError” para provocar un BSOD, que reiniciará el sistema sin dar muchas opciones al usuario:

En segundo lugar, y como última zona de código del Main de la aplicación, tiene una forma más sutil de reiniciar el equipo utilizando las apis normales de Windows para este fin:

That’s All Folks. (Por ahora… ;) )