Nota del editor: mañana por la mañana, nuestro compañero Antonio Sanz estará hablando sobre el malware del que trata el presente post, y la gestión del incidente asociado a la detección del mismo, en las VIII Jornadas STIC del CCN-CERT.
El pasado mes de agosto, varios empleados (bastante bien escogidos) de uno de nuestros clientes (una empresa estratégica), recibieron una serie de mensajes un tanto “sospechosos”, que referían el entonces relativamente reciente accidente del avión de Malaysia Airlines, sobre cuya investigación no paraban de llegar noticias.
Al abrir el documento, que en principio tenía extensión .doc, aparecía efectivamente una especie de “comunicado”, o similar, sobre el accidente en cuestión.
Sin embargo, un análisis básico revelaba que el fichero era en realidad un RTF (y no un DOC), y que venía con regalo: nuestro viejo amigo, el exploit CVE-2012-0158. Como los hashes del fichero todavía no tenían presencia pública en los servicios habituales (VirusTotal, Malwr.com, etc. obviamente, tampoco el AV corporativo lo detectaba), y dado el caracter de los destinatarios de los mensajes, pensamos que no vendría mal “jugar” un poco más con el artefacto, y lo pusimos a macerar en nuestra sandbox.
Tras unos 12 minutos (!) de espera, el especímen por fin intentó contactar con algo, y, para nuestra sorpresa, ese algo no era sino un proveedor público de servicios WebDAV. Así que el bicho utilizaba ese protocolo sobre HTTP (y no sobre HTTPS en principio), sea lo que fuera lo que pretendiera recibir o transmitir con ayuda del mismo…
Efectivamente, simulando en nuestro laboratorio el servidor WebDAV al cuál estaba intentando llegar, el especímen trataba en primer lugar de descargar información desde una determinada ruta del WebDAV, y a continuación, dejaba ficheros con nombres pseudoaleatorios, pero extensiones conocidas, sobre otra ruta.
Tras explotar, el adjunto RTF malicioso se sustituía a sí mismo por un documento “limpio” (el del comunicado sobre el accidente) que llevaba empotrado (de forma que si analizabas el documento droppeado por separado, no había forma de reparar en la existencia del exploit o del resto del malware), y lo abría con el Word, simulando perfectamente la apertura habitual de un fichero DOC.
Sin embargo, por debajo estaba droppeando y ejecutando un fichero .vbs, que a su vez droppeaba una DLL que llevaba empotrada en su propio código fuente, codificada en hexadecimal.
Esta DLL (droppeada directamente sobre %SystemRoot% si el usuario disponía de los privilegios necesarios, o sobre el perfil del usuario en caso contrario) se cargaba utilizando el comando de Windows regsvr32, persistiendo a través de una invocación del mismo sobre la habitual rama del registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run. En el caso de este adjunto, la clave se escribía con el nombre Barbicas.
Profundizando sobre el análisis dinámico de la DLL (el análisis estático no arrojaba mucha más información), observamos la presencia de un packer, que para unpackear a su huésped lleva a cabo gran cantidad de operaciones intensivas en CPU (durante el proceso de unpacking, que dura varios minutos, una de las CPU del equipo víctima se mantiene al 100% de utilización). El packer desofusca el código del malware sobre nuevas páginas del mapa de memoria del proceso y pasa a ejecutarlo (direcciones 0x7FF40000 y 0x7FF80000 en la captura de muestra).
En la memoria del proceso puede encontrarse la URL del servidor WebDAV, así como el nombre de usuario y contraseña para acceder al mismo, la ruta de bajada y subida desde y hacia el servidor, y las extensiones de los ficheros que se suben al mismo.
Una vez unpackeada con técnicas estándar, fue posible dumpear la DLL (reconstruyendo su Import Table) para pasar a analizar estáticamente en más profundidad el código desofuscado. Lo primero que nos llamó la atención fue la presencia de las tablas de inicialización del algoritmo AES en la sección de datos de la DLL.
En efecto, el malware utilizaría el algoritmo de cifrado AES en modo CBC.
La clave utilizada tiene una longitud de 256 bits, estando hardcodeada en el código del ejemplar.
En efecto, el tamaño de los ficheros cifrados siempre es múltiplo de 16 bytes, el tamaño de bloque del AES, y el fichero cifrado incluye el vector de inicialización del modo de cifrado en bloques (como se desprende de los parámetros utilizados en las llamadas a las rutinas de cifrado y descifrado observadas durante el análisis dinámico que llevamos a cabo), añadiendo otros 16 bytes extra al tamaño de los ficheros.
Por lo tanto, hasta el momento teníamos un malware no público, capaz de conectarse a un servidor WebDAV (un protocolo cuanto menos original en lo que respecta a campañas sobre las que se tenga constancia) de Internet utilizando una cuenta (usuario y contraseña) hardcodeada en el código, y capaz tanto de obtener información cifrada con AES (estando la clave de 256 bits también hardcodeada) desde una ruta de esta cuenta del WebDAV para recibir instrucciones (canal de comando y control), como de cifrar y almacenar información hacia otra ruta de la cuenta del servidor WebDAV (canal de exfiltración).
Pero las sorpresas aún no habían acabado; tras analizar los demás ficheros adjuntos (recordemos que varios usuarios recibieron mensajes maliciosos), resulta que cada uno era diferente:
- El comunicado sobre el accidente aéreo droppeado (el documento “limpio”) resultó ser el mismo para todos los adjuntos
- Tanto el fichero .vbs como la DLL droppeadas eran diferentes para cada mensaje (tanto en nombre, que trataba siempre de imitar el de alguna DLL legítima de Windows, como en contenido)
- La clave del registro (Barbicas en el primer especímen analizado), variaba en cada dropper
- El tiempo de unpacking también variaba para cada adjunto, observando tiempos desde 8 minutos hasta más de 15 minutos (en cualquier caso, el proceso mantenía una de las CPU al 100%)
- El servidor WebDAV era el mismo para todos los especímenes, así como el nombre de usuario y la contraseña utilizados para iniciar sesión en el mismo (lo cuál no significa que, para otras posibles organizaciones víctima o campañas, los atacantes no puedan generar ejemplares que utilicen otras credenciales)
- Sin embargo, la clave de 256 bits para AES, así como los directorios de subida (exfiltración) y bajada (comando y control) de información, eran diferentes para cada ejemplar analizado (en todos los casos, iban hardcodeadas en el propio código)
- Las extensiones utilizadas en los ficheros subidos al WebDAV (.TAR, .TIF, .TXT, etc. en el primer adjunto) variaban en cada ejemplar
Queda claro por lo tanto que lo que observamos fue probablemente una posible campaña, utilizando malware desconocido hasta el momento y seleccionando a las víctimas de un modo altamente dirigido.
Los atacantes emplearon alguna clase de generador de especímenes; una vez un ejemplar es generado, identifica unívocamente a la víctima, así como su información exfiltrada en el WebDAV, al utilizar cuentas, directorios, extensiones de fichero y claves AES diferentes en cada mutación. Además, queda claro que esto se trataba muy seguramente de la primera fase en lo que podría haber sido una persistencia más duradera en la organización víctima.
¿Qué habríamos encontrado tras unas cuantas semanas, o meses, de compromiso?
Actualización: en 8 de diciembre de 2014, Symantec (re)bautiza el malware del que les hemos hablado (o al menos alguna de sus mutaciones) como Infostealer.Rodagose (Number of infections: 0 – 49, Number of Sites: 0 – 2).
Seguimos prefiriendo el nombre Barbicas :-) Han pasado más de 4 meses desde que observamos por primera vez el malware y el primer producto AV lo empieza a detectar (y de momento no tenemos constancia de más presencia pública, además del sitio de esta compañía AV), reportando “pocos” sitios infectados (¿se tratará pues de una campaña que ha afectado a varias organizaciones?); esto, junto al carácter altamente dirigido de las víctimas seleccionadas en el caso de nuestro cliente mantiene el interrogante por el momento.
Trataremos de mantenerles informados a medida que vaya surgiendo más información.
Actualización 2: en 9 de diciembre de 2014, Blue Coat libera un informe, (re-re)bautizando el malware como Inception. Toda la información presente en el informe es coherente con lo observado por nuestro equipo en agosto de 2014. Confirmado: es una campaña APT :-)
Actualización 3: en 10 de diciembre de 2014, Kaspersky lo ha apodado Cloud Atlas.
