La formación en ingeniería inversa ante el reto del malware

Formación en ingeniería inversa ante el reto del malware por David García

Ese modo manual no es otra cosa que su pericia, experiencia y una vista entrenada para interpretar lo que tiene delante. ¿Qué tendrá delante? Eventos registrados, conexiones de red y tráfico capturado, trazas de llamadas al sistema, archivos abiertos por el objeto de análisis, etc. Y en el centro de toda esa maraña de información se encontrará el código.

Ya sea un desensamblado, código fuente ofuscado o el original intacto, de la única forma que el analista dará con la clave es desenredando hilo a hilo el enigma que encierra el código. Solo así se sabrá como un malware genera los dominios (DGA) para conectarse a su centro de control o que tipo de cifrado efectúa sobre las fotos y datos de una víctima (Ransomware); por poner algunos ejemplos sacados no precisamente de la ficción.

¿Y si no te gusta programar? No pasa nada. Precisamente, el trabajo de un ingeniero de reversing es justo lo contrario. Si un programador comienza con un diseño, lo codifica y finalmente lo compila; terminará obteniendo un producto listo para ser ejecutado. La tarea del reversing es, como decimos, desandar el camino. Esto es, tienes el producto final, procesas su contenido para obtener el código original (o una versión lo más cercana posible) y lo estudias para descubrir las intenciones con las que fue creado.

Evidentemente, las cosas no son tan fáciles como aparentan. Ese camino de vuelta está plagado de trampas y adversidades puestas ahí a propósito para impedir llegar con facilidad. Sino fuera así, es decir, si fuera sencillo desentrañar el funcionamiento de un malware, este sería descubierto en las primeras etapas de propagación y se detectaría con bastante facilidad. De ahí el interés de los creadores de malware en poner piedras en el camino del analista.

Por ello, formación como la que te ofrece el Master de Reversing, está encaminada precisamente en dar a los alumnos el arsenal de conocimiento necesario para enfrentarse en la tarea del análisis. En concreto, la asignatura de Análisis de Código Fuente se dedica por completo a darte los conocimientos necesarios para poder obtener el código, en su forma más legible, y poder entender como funciona de arriba abajo.

Si fuera sencillo desentrañar el funcionamiento de un malware, este sería descubierto en las primeras etapas de propagación y se detectaría con bastante facilidad. De ahí el interés de los creadores de malware en poner piedras en el camino del analista.

Vamos a presentar un caso particular. CCleaner, un popular programa de mantenimiento para sistemas Windows, sufrió un ataque que permitió a cibercriminales troyanizar la versión 5.33 (inyectaron malware en un programa original) y consiguieron infectar a un buen número de usuarios de la herramienta.

Uno de los IOCs (indicador de compromiso) por los que se podía detectar la infección de un sistema era a través de los dominios que el malware pretendía resolver para conectarse. Es decir, accedía a un dominio para tanto enviar información como para recibir órdenes. Este tipo de dominio no eran como los que estamos habituados a ver. Tenían el siguiente aspecto:

ab3c2b0d28ba6[.]com

ab99c24c0ba9[.]com

ab2e1b782bad[.]com

ab253af862bb0[.]com

…

El malware, no tenía una lista de dominios guardada. De haberlo hecho, sería muy sencillo avisar al registrador y neutralizarlos de antemano. En vez de ello, el malware posee un algoritmo que genera dominios de forma qué, en base a unos parámetros, es complejo determinar cual será el siguiente. Esta es una de las piedras en el camino que comentábamos antes.

¿Podríamos sin necesidad de interpretar el código adivinar cual será el siguiente dominio?

Es posible, pero muy complicado. Tendríamos que tirar de estadística y dejar que se generen muchos dominios para poder trabajar sobre un gran conjunto de datos. Esto es inviable, no se dispone de tanto tiempo ya que lo que pretenden los analistas es acortar cuando antes la ventana de infección. Es decir, es una carrera contrarreloj.

En vez de ello, se hace un análisis de código, en este caso de código ensamblador. Mediante la observación de las rutinas que proceden a la generación de dominios aleatorios se realiza un ejercicio de ingeniería inversa y se procede a sintetizar un algoritmo que emula el que posee el malware. Con ello, nos anticipamos al comportamiento del malware, podemos registrar los dominios futuros y neutralizar el malware impidiendo que prospere.

Observemos el código final de un generador de dominios aleatorios usado para detener la actividad del malware:

Ese algoritmo, disponible aquí, fue fruto de la investigación de un laboratorio de seguridad e hizo que la catástrofe no fuera a más. Sin lugar a duda, usaron las mismas técnicas de exploración, análisis y síntesis de una solución que son objeto de docencia en el Master de Ingeniería Inversa y más en concreto en la asignatura de Análisis de Código Fuente.

Gracias a la pericia, experiencia y formación de profesionales en ingeniería inversa es posible evitar males mayores e incluso así, la ingente cantidad de malware que es creado y liberado cada día, supone un reto para los laboratorios de seguridad; es por ello, que la profesión de analista de malware o bughunter sea tan demandada.