Cuando estamos reverseando aplicaciones maliciosas, el conocimiento de las strings nos permite no sólo comprender porciones específicas del código, sino también obtener una idea general del funcionamiento y las intenciones del malware. A veces tendremos suerte en nuestro análisis y todas serán visibles en texto plano; en otros casos, encontraremos porciones de strings cifradas con mayor o menor grado de complejidad. Hoy expondremos un caso de este último tipo y lo analizaremos de forma intuitiva.
Para comenzar, tomaremos una muestra de malware llamada Intimacao.cpl. Por su extensión podríamos pensar que este archivo es un applet del Panel de Control de Windows, pero notamos algo sospechoso en su nombre: “intimação”, que podría ser el nombre con que los usuarios en Brasil llamarían a un documento con una citación, o informe de una deuda.
Como ya hemos analizado, éste es un caso más de propagación de archivos CPL. Sin embargo, hasta ahora nada sabemos de la funcionalidad o intención de este archivo, por lo que comenzaremos a indagar más profundo. En primer lugar, debo decir que contamos con una pizca de suerte ya que la muestra no está comprimida con ningún packer, con lo cual los imports y las strings deberían ser visibles.
Así, del análisis de los imports observamos varios métodos de conexión a Internet, como InternetOpenUrl o InternetReadFile. Y si a eso le sumamos la presencia de ShellExecute, podemos pensar que este CPL se conecta a Internet para descargar y ejecutar otro archivo. Si ahora buscamos entre las strings esa URL (o conjunto de ellas), lamentablemente no encontraremos nada:
Si bien observaremos algunas strings útiles que nos indican, por ejemplo, que la muestra ha sido programada en Delphi, también vemos varias strings que aparentan estar cifradas y no nos sirven en ese estado. Esto se confirma si analizamos la muestra con el plugin Krypto Analyzer de PEiD en busca de constantes criptográficas:
Esta herramienta ha encontrado 3 firmas criptográficas distintas, referenciadas en diversos lugares del código (tomando como dirección base 0x400000). Luego, tomemos como ejemplo el segundo hit, y busquemos la primera referencia en el código (en la dirección relativa 0x04EA64). El cursor se encuentra en dicha instrucción y observamos el movimiento de datos presuntamente cifrados a EAX. Si nos centramos en toda esa sección de código, veremos un patrón que se repite:
En las partes resaltadas en el código observamos el mismo comportamiento: se carga un puntero a una variable local en EDX y la cadena cifrada en EAX. Luego se llama a la subrutina en 0x35E5A0 y se recupera el resultado de la variable local. En este punto no lo podemos afirmar, pero sí podemos suponer que esa subrutina es la encargada de descifrar la cadena.
A continuación podemos apuntar EIP a la instrucción MOV donde está nuestro cursor y ejecutar el CALL, de tal modo de observar si el resultado de la ejecución nos revela información útil. Al realizar esto lamentablemente se genera una violación de acceso a memoria, con lo cual debemos entrar a la subrutina y colocar un breakpoint luego del bucle de descifrado:
Cuando se alcanza el breakpoint, observamos una URL que ha sido descifrada en el stack. Si ahora analizamos el próximo CALL luego de esta subrutina de descifrado, veremos que efectivamente se utiliza la URL para descargar otra amenaza:
Este método es muy limitado, dado que debemos realizar el procedimiento descripto nuevamente para cada una de las strings cifradas adicionales que se quieran descifrar. Por ello, se hace imperiosa la necesidad de utilizar un script o conjunto de herramientas que nos permitan automatizar esta tarea, tema que cubriremos en una próxima entrega.
SHA-1 de la muestra analizada
7fad3b1bb3d6263a3eabe21b68a8db792eeffc71 – Intimacao.cp
