Casper: tras Babar y Bunny, otro dibujo animado utilizado en espionaje

En marzo de 2014, el periódico francés Le Monde reveló que el Centro Canadiense de Seguridad de las Telecomunicaciones (CSEC) sospechaba que Francia había desarrollado y desplegado software malicioso con propósitos de espionaje. La historia se basó en una presentación de diapositivas que divulgó Edward Snowden, publicada luego por el periódico alemán Der Spiegel en enero de 2015.

Según la presentación del CSEC, los creadores del software malicioso en cuestión lo llamaron “Babar”, probablemente por el famoso personaje de los dibujos animados franceses “Babar, el elefante“. Desde ese entonces, varios investigadores de malware comenzaron a tratar de descubrir el enigma de Babar.

La primera en acertar fue Marion Marschalek (de Cyphort), que publicó un informe sobre el malware del conejito “Bunny”. Bunny comparte algunas características con el malware Babar descrito por el CSEC. A mediados de febrero, Marion publicó otro informe, esta vez sobre el caso real de Babar, donde explicaba detalladamente sus funciones de espionaje. Al mismo tiempo, Paul Rascagnères (de G Data) escribió una entrada de blog sobre las similitudes entre Babar y Bunny, y demostró que probablemente ambos estaban relacionados con el malware descrito en las diapositivas del CSEC.

En esta publicación, develaremos otro software más que probablemente también haya sido desarrollado por la misma organización responsable de Babar y Bunny. Los autores de este componente lo llaman “Casper” (Gasparín, en español), seguramente por el personaje de dibujos animados.

Casper se utilizó contra objetivos sirios en abril de 2014, lo que lo convierte en el malware más reciente conocido hasta el momento de este grupo de códigos maliciosos. Para atacar a sus objetivos, los operadores de Casper usaban exploits 0-day en Adobe Flash, y dichos exploits se alojaban (por más increíble que parezca) en un sitio Web del Gobierno Sirio.

Casper es una herramienta de reconocimiento muy bien desarrollada, que se esfuerza en extremo para permanecer invisible en las máquinas objetivo. Se destaca por las estrategias específicas que adopta contra el software antimalware.

Contexto

A mediados de abril de 2014, Vyacheslav Zakorzhevsky (de Kaspersky) observó que el sitio Web “jpic.gov.sy” estaba alojando a dos exploits 0-day de Flash, que aprovechaban la vulnerabilidad más tarde llamada CVE-2014-0515. El Ministerio Sirio de Justicia creó este sitio en 2011 aparentemente para permitirle al pueblo sirio pedir compensaciones por los daños ocasionados por la guerra civil. El sitio sigue estando online y, al parecer, ahora está libre de malware, aunque un grupo “hacktivista” lo modificó y dejó fuera de servicio en septiembre de 2014.

Cuando ocurrió todo esto, Zakorzhevsky no podía recuperar los payloads que se habían distribuido mediante estos exploits 0-day de Flash. Los investigadores de ESET lograron encontrar dos de ellos, gracias al sistema telemétrico contra amenazas ESET LiveGrid®. Las direcciones URL de estas cargas y las fechas en que se observaron se corresponden con la descripción de Zakorzhevsky.

En un esfuerzo conjunto de Marion Marschalek, Paul Rascagnères e investigadores del Centro de Respuesta de Luxemburgo ante Incidentes de Seguridad Informática (CIRCL, por sus siglas en inglés), hace poco logramos determinar que los payloads distribuidos probablemente habían sido desarrollados por los mismos escritores de malware que también crearon el software Babar y Bunny.

Análisis binario de Casper

Las dos muestras que encontramos tienen el mismo programa central pero se empaquetaron en forma diferente. La primera es un archivo ejecutable que entrega el programa principal y hace que sea persistente en el equipo infectado.

La segunda es una biblioteca de Windows que despliega el programa directamente en la memoria, también con un formato de biblioteca. En el segundo caso, los creadores dejan visible el nombre de la biblioteca del programa principal: “Casper_DLL.dll”.

A lo largo de este post nos concentraremos en la primera de estas cargas; la segunda muestra un comportamiento similar.

Dropper

El dropper se llama “domcommon.exe” y su fecha de compilación figura como el 18 de junio de 2010. Es muy probable que se trate de una fecha falsa, como lo explicaremos más adelante.

Su ejecución se basa en un archivo de configuración XML descifrado en tiempo de ejecución con el algoritmo RC4 y una clave codificada en forma rígida de 16 bytes. Antes de descifrarse, el programa hace una suma de comprobación para asegurarse de que el área de memoria que contiene la clave de descifrado no fue modificada.

La Imagen 1 muestra el archivo de configuración descifrado del dropper.

Casper juega al ajedrez contra un programa antivirus

En primera instancia, el dropper extrae la etiqueta <STRATEGY> de su archivo de configuración. Esta etiqueta define con precisión el comportamiento del malware según qué antivirus esté presente en el equipo.

Elección de la estrategia más apropiada

Primero, el dropper recupera el nombre del programa antivirus que se está ejecutando en el equipo mediante la solicitud Instrumental de administración de Windows (WMI, por sus sigas en inglés) “SELECT * FROM AntiVirusProduct” y extrae el campo “displayName” del resultado. Si existe una etiqueta <AV> en el archivo de configuración del dropper con un atributo “NAME” que coincida con el nombre del producto antivirus instalado, se establecerá como estrategia de ejecución. En este caso, hay cuatro productos antivirus con una estrategia definida.

Si no se encuentra ninguna estrategia para el antivirus que se está ejecutando en el equipo, o si éste no cuenta con ningún antivirus que lo proteja, se aplicará la estrategia predeterminada descrita en los atributos de la etiqueta <STRATEGY>. Como alternativa, si existe un archivo llamado “strategy.xml” en la carpeta creada por el dropper, dicho archivo reemplazará la estrategia del archivo de configuración.

Jugadas posibles

Una estrategia es un grupo de atributos que influyen en el comportamiento tanto del dropper como de la ejecución de la carga. Algunos de estos atributos definen cómo se realizarán ciertas acciones, mientras que otros definen si se realizarán o no ciertas acciones.

El siguiente cuadro describe las diversas “jugadas” que ofrecen estos atributos.

Las posibilidades que ofrecen estas etiquetas <STRATEGY> demuestran que los creadores de Casper han adquirido un conocimiento en profundidad sobre la conducta de ciertos productos antivirus en cuanto a sus capacidades de detección.

Por ejemplo, la inyección del proceso solo ocurrirá en equipos donde no se esté ejecutando ninguno de los cuatro productos antivirus definidos, ya que, en ese caso, el atributo “INJECTION” está establecido en “NO”. Es interesante notar que tres antivirus tienen el atributo “ESCAPE” establecido en “SÍ”, lo que significa que el dropper simplemente se desinstalará automáticamente en su presencia sin desplegar la carga de Casper.

Como la lista de etiquetas <AV> es bastante corta, podemos especular que se trata de los productos antivirus que los autores de Casper esperan encontrar en los equipos. Cabe mencionar que el atributo “VERSION” presente en la etiqueta <AV> de hecho nunca se usa en el código, pero aún así indica la intención de distinguir entre distintas versiones del mismo producto antivirus. En muy raras ocasiones encontramos este nivel de precisión en malware para evadir los productos antivirus.

Colocación del payload

En caso de que el atributo “ESCAPE” esté establecido en “NO” en la estrategia elegida (como ocurre en la estrategia predeterminada), el dropper ejecutará los comandos provistos como etiquetas XML en el archivo de configuración, lo que se muestra en la Imagen 2.

Desinstalación de versiones anteriores

El primer comando le ordena al dropper que quite otras instancias de Casper que se pudieran estar ejecutando en el sistema. La etiqueta <UNINSTALL> correspondiente incluye un atributo “name”, cuyo prefijo será el nombre del fabricante de la BIOS, que se extrae del Registro de Windows (Intel, NEC…) para poder usarlo como un identificador. Este prefijo probablemente tenga como objetivo evitar llamar la atención del usuario si éste llegara a notar el identificador.

El programa se desinstala en dos pasos, cada uno de los cuales está destinado a un método de persistencia distinto empleado por Casper:

• Si existe, la tarea programada cuyo nombre coincide con el identificador se elimina del sistema
• Si existe, la aplicación registrada con el identificador en el Registro de Windows se elimina del sistema

Instalación del payload

A continuación, la etiqueta <INSTALL> dirige la instalación de la carga; dicha etiqueta proporciona dos versiones de la carga: una para equipos de 32 bits (<x86>) y otra para equipos de 64 bits (<x64>).

Los atributos de la etiqueta <INSTALL> luego son utilizados por uno de los métodos de instalación mencionados anteriormente. Si el sistema operativo es Windows 7 o posterior, la persistencia se establecerá mediante una tarea programada; de lo contrario, se establecerá a través de la clave de Registro de Windows “HKLM\Software\Microsoft\Windows\CurrentVersion\Run”.

La etiqueta <INSTALL> proporciona el argumento que se le dará a la carga. El valor exacto del argumento es crítico para que la carga se ejecute “correctamente”. La verificación real de la carga es muy sutil: el argumento se usa en un algoritmo personalizado para encontrar las funciones de biblioteca en memoria. A menos que el valor sea correcto, las direcciones de estas funciones de biblioteca estarán mal, lo que generará que la carga del dropper se bloquee, aparentemente en forma aleatoria.

El dropper se elimina

Antes de finalizar su ejecución, el dropper se elimina a sí mismo del sistema mediante el método definido en el atributo AUTODEL. Cabe notar que la carga no se activa en este momento: se ejecutará recién en el próximo inicio del sistema gracias al método de persistencia explicado arriba.

Payload

Al igual que el dropper, la ejecución de la carga de Casper se basa en un archivo de configuración XML descifrado en tiempo de ejecución, como se muestra en la Imagen 3.

Este archivo de configuración comienza con información sobre la fecha y hora, que corresponde al lunes 7 de abril de 2014 a las 21:27:05 GMT. Por lo tanto, es muy probable que las fechas y horas de la compilación (que figuran como el año 2010) sean falsas.

A continuación, una serie de etiquetas <PARAM> controlan el comportamiento de la carga, como se describe en el siguiente cuadro.

A continuación, el payload genera un identificador único para ese equipo y lo inserta al final de la configuración como una etiqueta <UID>. Finalmente, la configuración se cifra con RC4 y se almacena en el Registro de Windows.

El código que maneja la configuración demuestra que, en estas muestras, hay ciertas funcionalidades que quedan desaprovechadas, por ejemplo, un atributo TIMETOLIVE para planificar el cierre de Casper luego de un período específico de tiempo, o un atributo DELAYED_START para esperar antes de comenzar a interactuar con el sistema.

Por último, la configuración de la carga contiene exactamente la misma estrategia <STRATEGY> que el dropper.

Reporte al centro de comando y control

Durante su primera ejecución, el payload de Casper ejecuta el siguiente archivo XML:

<COMMAND name=’SYSINFO’/>

El controlador del comando “SYSINFO” extrae información sobre el sistema y crea un informe con varias secciones, como se muestra en la Imagen 4.

Los títulos de las secciones del informe son claros. Curiosamente, la versión del malware se menciona en forma expresa: 4.4.1. Este informe luego se codifica con base64 y se envía al servidor de comando y control en el cuerpo de una solicitud HTTP POST. También se escribirá en un archivo temporal llamado “perfaudio.dat”.

La solicitud de red también tendrá una cookie llamada “PREF” con la concatenación del UID del equipo, el ID de configuración, la versión de Casper y el carácter “R” codificado en forma rígida, todos ellos cifrados con base64.

Posibles respuestas del comando y control

Dado que el servidor de comando y control no estaba activo en el momento de la investigación, solo podemos especular lo que ocurre con el resto de la ejecución basándonos en las funcionalidades que conocemos de Casper.

En este punto, el binario se contacta con frecuencia al servidor de comando y control mediante una cookie similar a la de la solicitud SYSINFO, pero en este caso el carácter codificado en forma rígida es “G” en lugar de “R”. Nuestro análisis del archivo binario revela que el servidor puede devolver como respuesta una imagen PNG (con el encabezado y el formato correspondientes a un archivo PNG) a partir del cual se descifrará y ejecutará un archivo XML de comandos.

Además del comando “SYSINFO”, Casper puede manejar etiquetas <COMMAND> con los siguientes valores:

• “EXEC” para ejecutar un programa en la máquina desde su ubicación local
• “SYSTEM” para ejecutar comandos en el símbolo del sistema de Windows

Por último, Casper también puede manejar etiquetas <PLUGIN>, cuyo contenido es un ejecutable para Windows que se despliega en el equipo.

¿Cómo se relaciona Casper con los demás personajes?

La mejor manera de determinar si los desarrolladores de Bunny, Babar y Casper son el mismo grupo es identificar algoritmos o fragmentos de código inusuales que estén presentes en los tres programas. En nuestra comparación, también tomamos en cuenta el malware llamado “NBOT” (también conocido como malware “TFC”), ya que Marion Marschalek estableció su vínculo con Babar y Bunny en su informe sobre Babar.

La siguiente es una lista no exhaustiva de algunas funcionalidades compartidas que pudimos observar:

• Casper oculta sus llamadas a las funciones API mediante el uso de un hash calculado a partir de los nombres de las funciones, en vez de usar los mismos nombres. El algoritmo de hash es una combinación de operaciones ROL (rotate-left, rotar a la izquierda) de 7 bits y XOR (exclusive-or, O exclusivo). NBOT utiliza exactamente el mismo algoritmo con el mismo propósito, mientras que Babar oculta sus llamadas a la API de manera similar pero utilizando un algoritmo diferente.

• Casper recupera información sobre el antivirus que se está ejecutando en el equipo de manera similar que Bunny, Babar y NBOT, es decir, a través de la misma solicitud WMI. Además, todos estos programas de malware computan el hash SHA-256 de la primera palabra del nombre del antivirus, aunque en realidad en Casper nunca se usa.

• Para generar los delimitadores de sus solicitudes HTTP, Casper completa una cadena con un formato específico con los resultados de las llamadas a la función API GetTickCount. Este mismo código está presente en algunas muestras de NBOT, como se muestra en el siguiente cuadro.

• Para quitar su dropper, Casper ejecuta un comando creado a partir de una cadena con el siguiente formato:

cmd.exe /C FOR /L %%i IN (1,1,%d) DO IF EXIST “%hs” (DEL “%hs” & SYSTEMINFO) ELSE EXIT

En algunas muestras de NBOT encontramos la siguiente sintaxis similar:

cmd.exe /C FOR /L %%i IN (1,1,%d) DO IF EXIST “%s” (DEL “%s” & PING 127.0.0.1 -n 3) ELSE EXIT

• Casper utiliza un valor “ID” de “13001”, mientras que las muestras de Babar tienen el ID “12075-01″. Además, el malware descubierto en 2009 por el CSEC tiene el ID “08184” (diapositiva 8 de la presentación del CSEC). Este formato similar, así como el aumento del valor en el campo de decimales, podrían indicar que están relacionados entre sí.

Ninguno de estos signos por sí solos son suficientes para establecer una conexión sólida, pero la sumatoria de todas las funcionalidades compartidas nos permite determinar con un alto grado de confianza que Bunny, Babar, NBOT y Casper fueron desarrollados por la misma organización.

Victimología

Según nuestros datos telemétricos, todas las personas que fueron víctimas de este ataque durante la operación se encontraban en Siria. Es posible que hayan sido los visitantes del sitio web “jpic.gov.sy”: ciudadanos sirios que querían hacer una denuncia. En este caso, pueden haber sido redirigidos a los exploits desde la página legítima de este sitio.

Sin embargo, no pudimos determinar concluyentemente que este fuera el caso. En otras palabras, las víctimas pueden haber sido redirigidas a los exploits desde otra ubicación, por ejemplo, desde un sitio legítimo modificado o desde un vínculo en un correo electrónico.

Lo que se sabe con seguridad es que los exploits, los archivos binarios de Casper y el componente del comando y control estaban alojados en el servidor de este sitio web.

Esto nos lleva a una segunda hipótesis: la posibilidad de que atacantes hayan modificado el sitio web “jpic.gov.sy” para servir como área de almacenamiento. Esto tendría al menos dos ventajas para los atacantes. En primer lugar, al alojar los archivos en un servidor sirio, se puede acceder a ellos más fácilmente desde Siria, un país cuyas conexiones a Internet desde el exterior fueron inestables desde el comienzo de la guerra civil, como se indica en el Informe de Transparencias de Google.

En segundo lugar, sirve para confundir la atribución del malware, ya que levanta las sospechas contra el gobierno sirio.

Conclusión

Como se explicó arriba, estamos seguros de que el mismo grupo desarrolló a Bunny, Babar y Casper. El análisis detallado de Babar en la presentación del CSEC en 2009 indica que este grupo no es nuevo en el negocio del espionaje.

El uso de exploits 0-day también indica que los operadores de Casper pertenecen a una organización poderosa. Finalmente, el ataque dirigido a un sector tan limitado conformado solo por sirios demuestra un posible interés en la geopolítica.

Sin embargo, no encontramos ninguna evidencia en Casper que sugiera que está dirigido a países específicos. En particular, en los archivos binarios no se encontraron rastros de un origen francés, como lo había sugerido el CSEC en el caso de Babar.

Hashes

Indicadores de sistemas comprometidos

Este post fue publicado originalmente por nuestro compañero de ESET en Canadá Joan Calvet, en http://www.welivesecurity.com/la-es/2015/03/05/casper-babar-bunny-otro-dibujo-espionaje/

Photo credit: prof.bluesmush / Foter / CC BY-NC-SA