www.onemagazine.es
Así se analiza un ciberataque como el WannaCry
(Foto: Malwarebytes)

Así se analiza un ciberataque como el WannaCry

El pasado 12 de Mayo de 2017 tuvo lugar el ataque de tipo ransomware de más rápida difusión hasta la fecha. En poco menos de 24 horas más de 150.000 equipos en más de 90 países fueron infectados con este malware, quedando sus ficheros cifrados y sin posibilidad de recuperación a través de los canales de pago establecidos por los autores. No obstante, el daño pudo haber sido mucho mayor, porque gracias al trabajo de un analista de malware se pudo reducir considerablemente la propagación de este ransomware a nivel mundial.

WannaCry atacó sistemas Windows anteriores a Windows 10 que no tenían aplicado el parche MS17–010, principalmente sistemas operativos Windows 7. El éxito de su rápida difusión se encuentra en la utilización del exploit EternalBlue y del backdoor DoblePulsar, creados por la NSA y sacados a la luz pública por el grupo “The Shadow Brokers” el pasado 14 de Abril de 2017.

A los pocos días de que WannaCry hiciese acto de presencia comenzaban las clases de “Análisis e Ingeniería Inversa de Malware” en el Máster INDRA de Ciberseguridad, impartido en el Centro Universitario de Tecnología y Arte Digital (U-TAD). Por este motivo, se incluyó como actividad formativa el proceso de análisis e ingeniería inversa de este malware, de forma que los alumnos pudiesen aplicar la experiencia docente adquirida en un escenario de análisis de plena actualidad.

El objetivo de este artículo es el de mostrar algunas de las técnicas de análisis empleadas durante las sesiones prácticas con WannaCry, estudiando los diferentes componentes que incluye, a medida que las nuevas evidencias van saliendo a la luz durante el trabajo de análisis.

Operativa general

WannaCry se inicia a partir de un fichero ejecutable que actúa como un dropper convencional: únicamente configura los servicios y ficheros de trabajo a realizar por el malware. En la Figura 1 se muestra el flujo de ejecución que tiene lugar al ejecutar WannaCry por primera vez.

Nada más comenzar, intenta acceder a una URL y en caso de conectar interrumpe su ejecución. Este comportamiento es el que se ha denominado como “kill switch”, aunque también recuerda a las técnicas empleadas para evitar la ejecución del malware en entornos de análisis, ya que normalmente en estos entornos todas las peticiones de conexión son atendidas con el fin de capturar el tráfico generado por el malware.

Por este motivo, y mediante el registro del dominio “www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com” por unas 10 libras, MalwareTech consiguió ralentizar la propagación al darle conectividad a este dominio. Aunque su intención real era el de recoger todo el tráfico posible de este malware para su estudio, tuvo como efecto inesperado la ralentización en la propagación global de WannaCry.

Cuando la URL anterior no es accesible, el dropper inicia su ejecución configurando un servicio que registra como “Microsoft Security Center (2.0) Service”, empleando una copia del propio fichero que renombra como mssecsvc.exe. Este servicio se encargará de la propagación del malware a través de la explotación de una vulnerabilidade en el controlador de los servicios de la red de Windows (srv.sys).

A continuación, a partir de la sección de recursos del ejecutable, extrae un fichero que también configura como servicio y cuyo nombre es tasksche.exe. Este ejecutable llevará a cabo todo el proceso de cifrado de los ficheros del usuario, cuyo análisis abordaremos más adelante.


Figura 1- Flujo de ejecución inicial de WannaCry

A lo largo de su ejecución, las diferentes versiones de WannaCry, emplean una serie de marcadores (mutex) para sincronizar las hebras en ejecución y para dejar constancia de que el sistema está ya infectado. Concretamente han aparecido tres tipos de mutexs:

-MsWinZonesCacheCounterMutexA

-MsWinZonesCacheCounterMutexW

-MsWinZonesCacheCounterMutexA0

El primero es el empleado en la muestra que analizamos (ver Figura 4). Al estar registrado de manera global, este mutex es visible por cualquier proceso de sistema. Su objetivo es el de indicar que el sistema ya está infectado, evitando que se disparen las rutinas de cifrado una y otra vez. Precisamente por este motivo, el CCN-CERT creó una aplicación para establecer los mutexs en el sistema operativo y así evitar el cifrado de los ficheros.

Mientras el servicio MSSECSSVC2 se encarga de la propagación del malware, TASKSCHE irá cifrando los ficheros y gestionando la interacción con el usuario.

El dropper contiene varios ficheros alojados en la sección de recursos del ejecutable: un cliente Tor, un fichero al que posteriormente denominará tasksche.exe y un fichero ZIP cifrado con la clave “WNcry@2ol7”. Estos ficheros serán empleados durante las diferentes fases desplegadas por el malware.

Concretamente, en la Tabla 1 se muestra un listado del contenido del fichero ZIP ubicado en el recurso “XIA”.


Tabla 1 - Listado de archivos del fichero ZIP alojado en el recurso "XIA"

Propagación

La propagación se realiza mediante la llamada a una función (Propagación SMB, Figura 1) que desencadena la creación de distintas hebras de propagación tanto por red local como a través de Internet. Se intentan conexiones al puerto 445, en la búsqueda de versiones del protocolo SMB1 sin actualizar. A su vez también comprueba si la máquina remota tiene ya instalado DoublePulsar. La función principal de explotación (Hebra EternalBlue, Figura 2) se encargará de realizar la explotación de la vulnerabilidad en sistemas de 32 y 64 bits, empleando diferente código para cada caso.


Figura 2 - Flujo de ejecución de la hebra principal de EternalBlue

Para estudiar con detalle el mecanismo de propagación de WannaCry se ha modificado el código original, de manera que la función de cifrado de ficheros quede anulada y no interfiera con el análisis. Para ello se ha reescrito la llamada a Desplegar_Tasksche sustituyendo dicha llamada por una serie de instrucciones NOPs (Figura 3).


Figura 3 - Función "Configurar_WannaCry" original (arriba) y modificada (abajo) para facilitar el análisis de la propagación.

Esta modificación evitará que se despliegue el fichero tasksche.exe, y por consiguiente inicie la tarea de cifrado de los ficheros. Sin embargo, analizar el servicio creado por WannaCry en tiempo de ejecución requiere modificar también la rutina de inicialización del servicio. El motivo está en que una vez que se ejecute la llamada a Crear_Servicio_MSSECSVC2, el servicio se lanzará como un proceso independiente y fuera del control inmediato del depurador. Es decir, si tras lanzar el servicio enganchamos el depurador a éste, no sabremos a priori, en qué punto de su ejecución estará.


Figura 4 – La ejecución salta a "ReconfigurarServicio" cuando se ha ejecutado como servicio en Windows

Un forma sencilla y conocida de mantener un proceso en un punto concreto de la ejecución es mediante una instrucción de salto a la dirección de la misma instrucción del salto (es decir, un salto hacia atrás 2 bytes: opcode “EB FE”). Un buen sitio para insertar esta instrucción es justo cuando el proceso realiza las primeras acciones como servicio.

Tal y como se aprecia en la Figura 4, las instrucciones “push 0” son excelentes candidatas para ser sustituidas por nuestra instrucción de bloqueo, ya que ambas ocupan 2 bytes.


Figura 5 - Sustitución del código original de configuración del servicio MSSECSSVC2

Ahora podríamos enganchar el depurador al nuevo proceso creado por el dropper. Sin embargo, es preciso tener en cuenta que el Service Control Manager (services.exe) eliminará el proceso a los 30 segundos de lanzarse si éste no se ha iniciado correctamente. Puesto que la idea es detener el servicio en las primeras instrucciones de su ejecución, podemos aumentar el tiempo de espera de manera que haya tiempo suficiente para enganchar el depurador. El objetivo que se busca es el de iniciar, de manera guiada por el depurador, el servicio y así estudiar el componente de propagación de WannaCry desde sus primeros pasos.

Para ello modificaremos la entrada del registro de Windows tal y como se aprecia en la Figura 6.


Figura 6 – Se han establecido 15 minutos como tiempo de espera máximo para iniciarse un servicio en Windows

De esta manera podremos emplear el depurador de código para enganchar con el proceso “wannaCry_patched.bin” (versión modificada según lo visto anteriormente) y comenzar el proceso de análisis de código en tiempo de ejecución. Tras obtener el control del proceso en el depurador, restauramos la instrucción “push 0” original para que la ejecución siga su curso.

Desde el servicio recién creado se lanzará una hebra de propagación mediante EternalBlue para explotar la vulnerabilidad MS17-010. En este proceso se inyectará código sobre el controlador srv.sys (espacio de kernel), permitiendo ejecutar código en el sistema con los máximos privilegios.


Figura 7 – Rutina para seleccionar la versión de launcher.dll en función de la arquitectura de procesador de la víctima.

Una vez que DoublePulsar está instalado, se empleará para inyectar una DLL a la que el malware denomina launcher.dll sobre el proceso LSASS.EXE, encargado de gestionar el registro de usuarios y aplicar la política de seguridad en el sistema. Esta librería se encuentra almacenada en el segmento de datos del dropper principal en dos versiones: 32 y 64 bits.

Por consiguiente, el siguiente paso consistirá en extraer ambas librerías para su análisis. El proceso de extracción es sencillo, puesto que ambas librerías se almacenan sin cifrar en el segmento de datos. El tamaño de la librería viene determinado en el propio bucle de lectura (Figura 6), aunque un truco habitual consiste en extraer unos KBs suficientes para leer la cabecera del fichero ejecutable. A continuación, se calcula el tamaño del mismo sumando el tamaño de las cabeceras y el tamaño en disco de cada sección.

Observando la versión de 64bits de launcher.dll se observa una peculiaridad: el tamaño de la sección “.rsrc” (Figura 8) no corresponde con el espacio calculado (por el bucle) para la librería. Esto constituye un indicio de que en esa sección se insertará algún tipo de código en tiempo de ejecución.


Figura 8 - Segmentos definidos en launcher.dll (64bits)

Por consiguiente, de seguir el método comentado anteriormente, para calcular el tamaño de la DLL mediante la suma de las cabeceras, generaría un fichero de 5MB cuya sección “.rsrc” contiene basura.

Concretamente, WannaCry empleará la sección “.rsrc” para alojarse en ella y ejecutarse en el sistema remoto mediante launcher.dll, transmitida con una versión modificada de DoublePulsar.


Figura 9 – Selección del payload de EternalBlue tras detectar la arquitectura del procesador del sistema atacado.

Para que todo este proceso tenga éxito, es preciso instalar DoublePulsar a través de EternalBlue en el equipo de la víctima. Hay varias funciones encargadas de este proceso en WannaCry que seleccionarán el payload adecuado (Figura 9) a la arquitectura del procesador destino, con el fin de inyectar launcher.dll en LSASS.

Una vez se ha inyectado launcher.dll se realiza una llamada a la única función exportada: “PlayGame”. Esta función volcará el fichero alojado en el recurso, lo configurará como servicio bajo el nombre de “MSSECSSVC2” y lo lanzará a ejecución, repitiéndose el proceso de infección en el equipo de la víctima.


Figura 10 - Función "PlayGame" de la librería launcher.dll

Con eso concluiría una de las iteraciones en el proceso de propagación de WannaCry a través de EternalBlue.

Otro método de propagación empleado por Wannacry, además de la propagación a través de la red de Windows, es mediante la ejecución de procesos en sesiones RDP activas en el equipo infectado (Figura 11). Esta actividad se desencadena durante la ejecución del módulo de cifrado (tasksche.exe), ejecutando taskse.exe, que es uno de los archivos extraídos del recurso XIA (ver Tabla 1).


Figura 11 - Flujo de ejecución de taskse.exe

Para dificultar el análisis, los autores camuflaron algunas de las llamadas a la API de Windows en variables locales de la función (ver Figura 12), de manera que las posteriores llamadas a la API resultasen difíciles de entender. En cambio, al principio de esta función se vuelcan en las distintas variables locales las direcciones de memoria de las funciones de la API que se van a utilizar.


Figura 12 - Instrucciones CALL ofuscadas (izquierda) y resueltas (derecha) en taskse.exe

Cifrado de ficheros

La función principal de WannaCry es la de cifrar los ficheros del usuario y pedir un pago en bitcoin para recuperarlos. Esta tarea es realizada por tasksche.exe, una vez que el dropper lo ha escrito en “C:\WINDOWS”.

Este componente realiza las siguientes actividades:

-Despliega el ransomware para el cifrado de los ficheros y la gestión con el usuario.

-Cambia permisos de ficheros para no tener problemas al cifrar con el comando icacls.

-Borra las shadow copies mediante vssadmin y wmic.

-Desactiva el modo de recuperación al iniciar el equipo empleando el comando bcdedit.

-Borra las copias de seguridad con wbadmin.

-Oculta la carpeta de reciclaje con el comando attrib.

-Genera script vbs para crear enlaces al programa de descifrado.

-Elimina algunos procesos que pueden tener recursos bloqueados con el comando taskkill.exe

-Ejecuta taskse.exe para ejecutar el ransomware en otras sesiones RDP activas.

-Ejecuta taskdl.exe para eliminar ficheros temporales en el proceso de cifrado.

Una parte fundamental para el análisis del módulo de cifrado consisten en la extracción de la DLL almacenada cifrada con AES en el fichero t.wnry (Figura 13). Esta DLL implementa toda la funcionalidad de cifrado y gestión de claves. Una vez que tasksche.exe ha configurado sus archivos y modificado el sistema para acondicionarlo a sus necesidades, se descifra esta DLL y se hace una llamada al único método que exporta: TaskStart.

Figura 13 - Localización de la DLL almacenada cifrada con AES en t.wnry

Para extraer esta DLL es necesario llevar tasksche.exe a ejecución y detenerlo justo cuando haya descifrado en memoria la librería. Observando la función WinMain se puede localizar el punto exacto en el que la librería se encuentra almacenada en memoria (ver Figura 14). Tras la llamada a DescifrarDLL la dirección de inicio se almacena en EAX y posteriormente se hace una comprobación para ver si el proceso de descifrado ha producido fallo.


Figura 14 - Depurador justo tras descifrar la DLL en memoria (en EAX)

Con un pequeño script podemos volcar el contenido alojado en memoria, desde la posición indicada por EAX hasta el final de la librería. El tamaño de la librería lo podemos calcular en base al tamaño que ocupa cifrado en t.wnry. Aunque también podemos extraer 4-8k y hacer la suma de las cabeceras como se comentó anteriormente. En ambos casos el valor que se obtiene es de 65536 bytes.

Una vez volcada a disco, podemos trabajar en el análisis de la librería, teniendo presente que para llevarla a ejecución en el depurador es necesario tener, en el mismo directorio en el que se ejecuta, los ficheros del recurso “XIA” que necesita.

La Figura 15 muestra el flujo de ejecución de tasksche.exe. Desde que es lanzado a ejecución, y descifra la librería, hasta que invoca TaskStart y se inicia todo el proceso de cifrado de los ficheros del usuario.

Figura 15 - Flujo de ejecución de tasksche.exe

Este artículo resume algunos de los pasos necesarios para poder analizar WannaCry en sus dos facetas principales: propagación y cifrado de ficheros. No obstante, técnicas como el análisis estático de ficheros, el análisis del tráfico, el volcado de memoria y la depuración en espacio de kernel son métodos de análisis necesarios para poder comprender el funcionamiento de este malware en su totalidad.

Estas técnicas de análisis, así como las herramientas necesarias para poder abordar el trabajo completo de ingeniería inversa, forman parte de la experiencia docente impartida en el Master INDRA de Ciberseguridad en U-tad.

Hace unos años, apenas existía conciencia de la importancia de este tipo de perfiles en las empresas, hecho incuestionable a día de hoy. Este tipo de profesionales son altamente demandados y apreciados en las organizaciones. Ahora más que nunca, tras los recientes ciberataques sufridos en organizaciones de casi todo el mundo, se hace necesario contar en las empresas con expertos en cibersegruidad y en hacking ético que verifiquen el nivel de seguridad, y comprueben la existencia o no de vulnerabilidades que pudieran permitir a un potencial atacante acceder a sus sistemas e información. Este tipo de comprobaciones les permite no solo identificar vulnerabilidades, sino verificar los procedimientos y políticas que han sido establecidas para mantener la seguridad interna de la organización.

Para hacernos una idea del futuro de esta profesión, solo tenemos que pensar en todos los avances actuales y las necesidades inherentes de ponernos en el ‘lado oscuro’ para comprobar la seguridad de por ejemplo; ciudades inteligentes (Smart-Cities), coches interconectados o el Internet de las Cosas (IoT), para ver los ataques y problemas que podrían ser realizados.

¿Te ha parecido interesante esta noticia?    Si (0)    No(0)


Normas de uso

Esta es la opinión de los internautas, no de Desarrollo Editmaker

No está permitido verter comentarios contrarios a la ley o injuriantes.

La dirección de email solicitada en ningún caso será utilizada con fines comerciales.

Tu dirección de email no será publicada.

Nos reservamos el derecho a eliminar los comentarios que consideremos fuera de tema.