Análisis de un “RANSOMWARE” cifrado

El malote pensativo!
El malote pensativo!
Ilustración gracias a la cortesía de Alejandro Cuenca.
Ilustración gracias a la cortesía de Alejandro Cuenca.

El Ransomware es una amenaza digital que está en pleno apogeo, causando estragos por todo el mundo.

En Agosto de 2014 se dio a conocer un portal: https://www.decryptcryptolocker.com/ puesto a disposición del público gracias a investigadores de compañías de seguridad como Fox-IT y FireEye, donde se podían recuperar los datos cifrados por CryptoLocker, tal y como podemos leer en la siguiente noticia de la BBC:
http://www.bbc.com/news/technology-28661463

La información obtenida de la operación llevada a cabo por los investigadores dio a conocer que, en menos de un año, estos ciber-criminales habían llegado a infectar a unos 500.000 usuarios con esta variante de ransomware, siendo aproximadamente el 1,3% de los afectados los que habrían pagado los 400$ (USD) solicitados como rescate, para recuperar los ficheros cifrados. Se estimaron sus beneficios por ese periodo y para esa única variante, unos 3 millones de dólares estadounidenses.

Por su parte Dell Secure Works, publicaría la distribución geográfica de las direcciones IPs afectadas por CryptoLocker entre Octubre y Noviembre de 2013:

Dell Secure Works
Dell Secure Works
Imagen gracias a Dell SecureWorks
Imagen gracias a Dell SecureWorks

Pretendemos con la presente publicación dar a conocer el funcionamiento de estas amenazas, al menos en términos básicos, analizando su comportamiento durante una infección, y dando a conocer los mecanismos de análisis utilizados que podrán ser empleados por otros investigadores o analistas de malware.

¿Qué es el RansomWare?

Captura de RansomWare en España
Captura de RansomWare en España

Nos apoyaremos en la definición que da el NIST en su informe sobre el malware de Junio de 2011:

The use of malware to block access to computers or data until a payment is made, also continues to be used for extortion purposes

Que con nuestras palabras podríamos describir como un software (o aplicación informática) diseñado con fines maliciosos (es decir, un: malware), que bloquea el acceso a equipos informáticos o a los datos, hasta que se recibe un pago que se solicita como rescate.

RansomWare llamado "Virus de la Policia" en España
RansomWare llamado “Virus de la Policia” en España

En el caso de los conocidos como ransomware de cifrado, la estrategia utilizada por los criminales es la de cifrar la información a la que tiene acceso los equipos infectados (incluyendo unidades de disco duro, medios extraíbles que estén conectados en el momento de la infección, o carpetas de red (o en la nube) accesibles, impidiendo que el uso de un software antimalware o antivirus tradicional sea eficaz, al permitirnos estos, eliminar la amenaza en sí, pero no recuperar los datos una vez ya han sido cifrados.

Objeto del Análisis

Captura: TeslaCrypt
Captura: TeslaCrypt

Trabajaremos con una muestra de CryptoLocker que es sin duda uno de los ransomware de cifrado más comunes, identificada por las siguientes huellas de ficheros:

  • SHA-256: 0ef1fefdf99474e0a322c0f64b501934ebd2e910dd36fdca46ddf87470a5d7ec
  • MD5: f76e1d7abc6e97ac38443928fcd9b0a2
Captura: Cryptolocker en España
Captura: Cryptolocker en España

Hallazgos

Vías de Infección

Las vías de infección más comunes incluyen los correos electrónicos basura (SPAM), habitualmente utilizando en ellos engaños (técnicas de ingeniería social) como entregas de cartas de Correos, paquetes, envío de facturas y albaranes falsos, etc., y también se hace despliegue de este malware por otras vías, como la descarga de antivirus/antimalware , drivers, actualizaciones, anuncios… falsos y la instalación sobre equipos de botnets, afectados por malware como Zeus.

En muchas ocasiones la distribución de software falso como el comentado se produce en páginas de descargas ilegales, contenido multimedia protegido (como películas y series), pornografía, blogs personales infectados, y otros.

Mecanismos de Evasión y Ocultación

Este malware consulta el estado de diversas herramientas de protección como antivirus y antimalware conocidos, tratando de desactivar las mismas en el registro en caso de encontrarlas y parando sus procesos correspondientes.

El binario se ha creado utilizando algún mecanismo de ocultación de parte de su información como los nombres de dominios a los que tratará de conectar, extensiones de ficheros a los que debe afectar y otros.

Cifrado de los datos

Captura: Cifrado de datos con Cryptolocker
Captura: Cifrado de datos con Cryptolocker

La muestra de CryptoLocker analizada es capaz de cifrar todo fichero accesible desde el ordenador que se infecta y sobre el que tenga privilegios de escritura, afectando al menos a 180 extensiones de ficheros conocidas, incluyendo: documentos ofimáticos, archivos comprimidos, multimedia, etc.
En cada carpeta afectada creará un fichero de texto con las instrucciones para la recuperación de los datos, mediante pago del rescate.

Estimamos que se utiliza cifrado simétrico AES-CBC. El vector de inicialización que requiere este tipo de cifrado, variará cada vez y pensamos está incluido en los primeros 16 bytes del fichero cifrado. Creemos que el cifrado RSA de 2048 bits, se utiliza para cifrar la clave de cifrado de AES-CBC que creemos que podría estar almacenada en el fichero key.dat.

Al infectar al equipo genera un fichero cuya ruta completa será: %APPDATA%\key.dat que borrará una vez termine de cifrar los datos. Presumiblemente está relacionado de alguna manera con la clave, además de otros datos del usuario, como veremos más adelante.

Se producen varias comunicaciones al sistema de control a un total de cuatro dominios diferentes, entre ellas, primero registrará al equipo enviando información sobre éste (Sistema Operativo, Arquitectura, etc.) y luego indicar, una vez terminado el proceso de cifrado, que ese equipo se encuentra cifrado indicando el número de ficheros que ha logrado afectar, todas estas comunicaciones se llevan a cabo utilizando protocolo HTTP (sin cifrar) y pasando parámetros mediante métodos GET (estos se incluyen en la URL), codificados en Base 64.

Otros Daños

Captura: Cryptolocker
Captura: Cryptolocker

Este RansomWare tratará de eliminar, si cuenta con los privilegios suficientes, las Shadow Copies del sistema para dificultar la recuperación de los datos.

También, cambiará el fondo de pantalla por uno propio incluyendo las instrucciones de recuperación -mediante pago de rescate – de los datos.

Métodos de Defensa

Ilustración gracias a la cortesía de Alejandro Cuenca.
Ilustración gracias a la cortesía de Alejandro Cuenca.
  • El principal método pasa por contar con una correcta copia de seguridad de los datos, en dispositivos no accesibles por el equipo (por ejemplo, una unidad externa). Ya que esté será nuestro único medio seguro de recuperación en el caso de que se produzca una infección por un ransomware de cifrado.
  • Es posible, una vez detectados los dominios que utiliza un ransomware de cifrado, establecer mecanismos de defensa, impidiendo la navegación a estos sitios (por ejemplo en proxys corporativos) y/o la notificación en caso de intento de acceso, para poder localizar los equipos infectados y los posibles intentos de comunicación por si incluyeran detalles como la clave de cifrado. Esta es la estrategia empleada en la técnica denominada: DNS Sink Holes que impide el acceso a los sistemas de control (habitualmente conocidos como Command & Control (C&C), del inglés).
  • También, el comportamiento sobre los ficheros en disco o el registro, podría ser detectado, por ejemplo mediante trampas (honeypots, o tarros de miel, del inglés), como hacen herramientas como Anti Ransom o detectando el comportamiento (uso de cifrado por ejemplo), como en el caso de: Crypto Monitor
  • Limitar los privilegios de los usuarios a los mínimos imprescindibles tanto en su sistema como carpetas compartidas, que es una buena práctica de seguridad en general, también puede ayudarnos a reducir los daños producidos por este tipo de amenazas y otras.
  • Detección temprana: creemos que pueden ser útiles sistemas trampas (honeypots), ya que junto con sistemas de análisis (automáticos o manuales), podrían ayudarnos a detectar nuevas amenazas antes de que estás sean ampliamente conocidas (*momento en el cual también somos más vulnerables ya que menos sistemas de anti-virus serán capaces de detectarlas.)

Método de investigación

Captura: RansomWare (Cryptolocker)
Captura: RansomWare (Cryptolocker)

Para llegar a las conclusiones aquí presentadas llevamos a cabo los siguientes análisis sobre la muestra de RansomWare mencionada:

  • Análisis automático en virustotal: utilizando su servicio web y revisando la información referente a la muestra sobre la que trabajaremos, para tener una primera opinión sobre con qué estamos trabajando.
  • Análisis estático, lo que implica analizar la muestra sin ejecutarla ni revisar su comportamiento en ejecución, incluyendo: Revisión de las cabeceras PE (Portable Executable).
  • Análisis de packers.
  • Extracción de recursos: incrustados dentro del ejecutable, como pueden ser el icono del fichero, imágenes, etc.
  • Extracción de cadenas de texto.
  • Análisis dinámico, que sí implica la ejecución del malware en un entorno de pruebas controlado (parte del laboratorio de pruebas utilizado), incluyendo:
  • Revisión de procesos generados por el malware.
  • Análisis de modificaciones sobre el registro del sistema.
  • Búsqueda de rootkits
  • Análisis de red, que también implica la ejecución controlada de la muestra, incluyendo:
  • Análisis del tráfico generado por una máquina infectada.
  • Resolución de nombres (DNS ).
  • Peticiones HTTP (Web).
  • Análisis automático en sandbox, utilizando cuckoo sandbox , que es un estándar en el análisis de malware. Incluyendo:
  • Ejecución en sandbox de las muestras y análisis automático.
  • Revisión de los aspectos encontrados.
  • Comparación de dichos resultados con los observados mediante nuestras pruebas manuales en busca de posibles anomalías, incongruencias o detalles omitidos.
Captura: Proceso de análisis
Captura: Proceso de análisis

Laboratorio de pruebas

  • STYX: Ubuntu server 14.04 , utilizado principalmente para controlar y registrar el tráfico de red de la máquinawinbox (de la que hablaremos a continuación). La base de este sistema se tomó de los recursos incluidos en los Training Resources de ENISA (European Union Network and Information Security Agency).
  • winbox: Microsoft Windows 7, también su base parte de los recursos mencionados de ENISA. Sobre ella crearemos dos instantáneas (o snapshots):
  • Winbox-clean: imagen que cuenta con las herramientas de análisis estático
  • Winbox-cuckoo: imagen que cuenta con la configuración adecuada para ser utilizada mediante cuckoo-sandbox.

Análisis en VirusTotal

Captura: Virustotal logo
Captura: Virustotal logo

Lo primero que nos indica el servicio si subimos la muestra, o bien, solicitamos buscar por su MD5 o SHA, es que esta muestra que ya ha sido analizada previamente en el sistema, como podemos ver en la siguiente captura:

Captura: Resultado de análisis con Virustotal
Captura: Resultado de análisis con Virustotal

También podemos comprobar como 35 de los 55 sistemas de detección, es decir un total aproximado del 63%de los empleados, fueron capaces de determinar que este binario era una amenaza. Solicitando el último análisis que realizó el sistema sobre esta muestra, encontramos:

Captura: Resultado de Virustotal
Captura: Resultado de Virustotal

Indica que la reputación es la mínima posible (-100, siendo la escala de -100 –menos confiable- a 100 –altamente confiable-) y que el último análisis que se realizó fue hace algo más de una semana con una muestra llamada“evracpy.exe”.

A continuación se nos presenta la información de qué sistemas son capaces de detectarlo y cómo se llama, dentro de ese sistema anti-malware, a dicha amenaza. El siguiente es un extracto de la detección por parte de algunos de los motores de antivirus, de los que dispone VirusTotal:

Captura: Muestra parcial de los motores que detectan la amenaza en Virustotal.
Captura: Muestra parcial de los motores que detectan la amenaza en Virustotal.

Análisis estático

Análisis de las cabeceras del binario

Partimos de la información del ejecutable, mediante un análisis de las cabeceras PE y posible uso de empaquetadores (packers).

Captura: Resultado de análisis en PEiD
Captura: Resultado de análisis en PEiD

PEiD nos muestra la información del tipo de binario (Win32 GUI), y la información de posibles packers. Observamos que indica que no se han utilizado packer.

Contrastamos este resultado ExeInfoPE el cual, con su análisis avanzado nos muestra, como más probable (mayor puntuación), el que se haya utilizado “Morphine v1.2 (DLL)”.

Captura: Análisis avanzado del binario en ExeInfoPE
Captura: Análisis avanzado del binario en ExeInfoPE

Un empaquetado de este tipo implica ocultar la información del binario con cifrado (descifrándose en ejecución), existen trabajos para tratar de descifrar este tipo de binarios con depuradores (debuggers del inglés), que dejamos como vía para posibles trabajos futuros, como el siguiente:

Polymorphic Crypter – Morphine 2.7 by Holy_Father

Análisis de los recursos del binario

Empleando el extractor de recursos Resource Hacker, encontramos únicamente el icono del binario:

Captura: Información obtenida con Resource Hacker
Captura: Información obtenida con Resource Hacker

Extracción de cadenas de texto

A continuación revisamos las cadenas de texto incluidas dentro del binario, para ello empleamos binText.

Tratamos de encontrar nombres de dominios, rutas a ficheros en disco, peticiones http y cadenas de texto que puedan ser sospechosas de la actividad del malware analizado, con resultado negativo.
Entendemos que puede utilizar algún tipo de ofuscación, codificado o cifrado para ocultar dicha información dentro del binario.

Análisis dinámico

Como punto de partida, preparamos, nuestro laboratorio para poder trabajar con la máquina virtual winbox, en un entorno totalmente aislado (sólo podrá comunicarse con nuestra máquina styx, configurada para simular los servicios de Internet).

Subimos la muestra a analizar a la máquina winbox y preparamos tanto Process Explorer, Process Monitor yRegShot, para trabajar.

En este punto creamos una nueva instantánea, de manera que podamos hacer repetible el análisis desde el mismo punto, de manera sencilla.

Ejecutamos la muestra y observamos que se cierra Process Explorer, táctica que utiliza mucho malware, para complicar el análisis o la detección de las amenazas.

Tras unos segundos, se nos muestra la ventana indicándonos de que se han cifrado los datos de nuestro equipo, presentando la siguiente pantalla:

Captura: Pantalla de Cryptolocker
Captura: Pantalla de Cryptolocker

Procesos Generados

Mediante Process Monitor, podemos ver los procesos creados desde la ejecución del malware hasta que paramos la detección de eventos (pasados dos minutos). La siguiente captura muestra una parte de dichos procesos:

Captura: Captura parcial de Process Monitor
Captura: Captura parcial de Process Monitor

Observamos la lectura de numerosas entradas del Registro, entre otras:

  • Búsqueda de sistemas anti-virus/anti-malware instalados, intento de desactivación de estos.
  • Estado del Cortafuegos de Windows.
  • Servicio Terminal Services y su configuración.
  • Configuración de RPC.
  • Configuración Regional y de idioma (variables locale).

La siguiente captura incluye algunos de estos procesos lanzados:

Captura: Algunos procesos generados por el malware, capturados en Process Monitor
Captura: Algunos procesos generados por el malware, capturados en Process Monitor

Aplicando diferentes filtros, analizamos el comportamiento del ransomware en ejecución en cuanto a:

  • Apertura/Creación/Cierre de ficheros en disco.
  • Escritura en archivos de disco.
  • Conexiones de red.

Entre los aspectos observados, podemos ver cómo se genera un archivo ejecutable llamado: “megdkmu.exe”(sucesivas ejecuciones veremos que el nombre va variando, aunque se mantiene el formato de siete caracteres y extensión “.exe”), en la ruta:

“C:\Users\IEUser\AppData\Roaming\megdkmu.exe” A partir de ese momento, será este proceso el que se ejecute en memoria y continúe con la actividad del ransomware:

Generando un fichero: key.dat, en C:\Users\IEUser\AppData\Roaming\key.dat, y seguidamente ejecutando su proceso de cifrado de los ficheros de usuario:

  • Listando primero los directorios y subdirectorios y sus ficheros contenidos.
  • Cifrando (en caso de disponer de privilegios suficientes) los ficheros encontrados, dependiendo de su extensión y otros criterios establecidos en el software como el tamaño.
  • Eliminando, para finalizar, el fichero key.dat.

También localizamos, dentro del árbol de procesos, un proceso hijo creado para eliminar las Shadow Copies de Microsoft, mediante la siguiente orden:

C:\Windows\System32\vssadmin.exe" delete shadows /all /Quiet

Y también un subproceso de la consola del sistema Windows (cmd.exe), donde se solicita eliminar el fichero 0EF1FE~1.EXE (es decir, el propio ejecutable del malware), mediante el siguiente comando:

C:\Windows\system32\cmd.exe" /c del C:\Users\IEUser\DesktopEF1FE~1.EXE >> NUL

Ficheros afectados

Para analizar qué tipo de ficheros son el objetivo de este malware, creamos un total de 185 ficheros trampa, cada uno con una extensión dentro de las que son habituales para este tipo de ransomware.
A continuación ejecutamos la muestra y observamos cuáles de ellos ha cifrado, en total, 180 como podemos observar en la siguiente captura de pantalla:

Captura: Captura parcial de ficheros trampa cifrados
Captura: Captura parcial de ficheros trampa cifrados

Las siguientes son extensiones que se ha podido confirmar que este malware puede secuestrar (cifrar):

FireShot Screen Capture #007 - 'Análisis de un Ransomware de Cifrado ~ Security By Default' - www_securitybydefault_com_2015_06_analisis-de-un-ransomware-de-cifrado_html

Recuperación y análisis del fichero “key.dat”

Utilizando los permisos de seguridad de las carpetas de Windows, impedimos al usuario con el que ejecutaremos CryptoLocker el borrar ficheros o carpetas, dentro de la ruta: %APPDATA%\key.dat, para impedir que elimine el fichero key.dat y poder proceder a analizarlo.

Captura: Configuración Avanzada de Carpetas Microsoft
Captura: Configuración Avanzada de Carpetas Microsoft

De partida ya observamos que el fichero key.dat es diferente de una infección a otra, debido a, como veremos, a que contiene datos particulares de la infección que irán variando de uno a otro (dirección de bitcoin, por ejemplo).

Para validar este aspecto realizamos dos infecciones sobre la misma máquina recuperando su estado y procediendo a comparar las huellas MD5 de los ficheros key.dat recuperados:

# md5sum key.dat*
cf56546477d61565b2f8644e6ae8b518  key.dat
3bc1436b2f5e75ed7590b0b51f62a451  key.dat.2

Analizando su estructura, vemos la dirección bitcoin en los primeros 34 bytes (la destacaremos en naranja), observando datos, presumiblemente relacionados con las claves de cifrado y otros datos de la víctima, en otras posiciones que destacaremos en verde:

Captura: Fichero key.dat
Captura: Fichero key.dat

Validamos la dirección bitcoin en Base58 Encode, Decode, and Validate:

Captura: Validación de dirección bitcoin incluida en key.dat
Captura: Validación de dirección bitcoin incluida en key.dat

Para el análisis de este tipo de fichero, creamos unas clases básicas en el lenguaje Python, que pueden ser descargadas desde el siguiente repositorio en GitHub.

Captura: Muestra parcial del código python
Captura: Muestra parcial del código python

Creación de ficheros de ayuda a la recuperación

Observamos que el malware, crea un fichero llamado: “HELP_RESTORE_FILES.txt” en cada uno de los directorios donde ha afectado a ficheros del usuario.

El texto incluido es el siguiente:

All your documents, photos, databases and other important files have been encrypted with strongest encryption RSA-2048 key, generated for this computer.

Private decryption key is stored on a secret Internet server and nobody can decrypt your files until you pay and obtain the private key.

If you see the main encryptor red window, examine it and follow the instructions. Otherwise, it seems that you or your antivirus deleted the encryptor program. Now you have the last chance to decrypt your files.

Open http://34r6hq26q2h4jkzj.42k2bu15.com or http://34r6hq26q2h4jkzj.79fhdm16.com, https://34r6hq26q2h4jkzj.tor2web.blutmagie.de/ in your browser.

They are public gates to the secret server.

Copy and paste the following Bitcoin address in the input form on server. Avoid missprints.

17JHJkNPhM4mPvPEaJzdnSFjz545ejkQNs

Follow the instructions on the server.

If you have problems with gates, use direct connection:

1. Download Tor Browser from http://torproject.org

2. In the Tor Browser open the http://34r6hq26q2h4jkzj.onion/

Note that this server is available via Tor Browser only.

Retry in 1 hour if site is not reachable.

Copy and paste the following Bitcoin address in the input form on server. Avoid missprints.

17JHJkNPhM4mPvPEaJzdnSFjz545ejkQNs

Follow the instructions on the server.

En él se nos indica lo que ha sucedido con nuestros datos y cómo proceder a recuperarlos siguiendo las instrucciones para pagar el rescate establecido.

Nota: Destacamos una vez más que el pago del rescate, no garantiza la recuperación de los datos en todos los casos, además de que alienta a los cibercriminales a seguir utilizando estos métodos.

También creará un fichero en la siguiente ruta: : %APPDATA%\log.html, incluyendo el listado de los ficheros afectados y que será presentado dentro del navegador al usuario en caso de que pulse sobre el botón “Show files” de la ventana de CryptoLocker, como vemos en la siguiente captura:

Captura parcial del log de los ficheros cifrados
Captura parcial del log de los ficheros cifrados

Modificaciones sobre el registro del sistema

Analizamos los cambios que lleva a cabo sobre el registro, entre los que destacamos:

Arranque de CryptoLocker

Activación de CryptoLocker en cada arranque, añadiendo la siguiente clave:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\msconfig: "C:\Users\IEUser\AppData\Roaming\megdkmu.exe"

megdkmu, es el fichero que creó en el momento de infección, su nombre va variando de una infección a otra y se ubica en: “%APPDATA%”.

Fondo de Escritorio

Establecimiento del fondo de escritorio con una imagen que contiene la misma información que el fichero HELP_RESTORE_FILES.txt, mediante las siguientes claves de registro:

Captura: Claves de registro
Captura: Claves de registro

Incluimos una captura de dicho fondo de escritorio:

Captura: Fondo de pantalla de Cryptolocker
Captura: Fondo de pantalla de Cryptolocker

Búsqueda de rootkits

Utilizamos la herramienta GMER para la búsqueda de posibles rootkits instalados en la máquina víctima, con resultado negativo.

El uso de rootkits, es habitual en mucho malware, en especial en aquel que desea mantener el control del equipo (como los que se añaden a botnets).

Análisis de los Ficheros Cifrados (.ECC)

Trabajaremos con los ficheros generados por el ransomware, con extensión .ECC. Desvelando los siguientes aspectos:

Comprobación del uso de idénticas o diferentes claves de cifrado

Para comprobar si el malware utiliza la misma clave de cifrado para cada fichero o diferentes, creamos un fichero de texto y dos duplicados idénticos del mismo. A estos tres ficheros los llamamos: honey1.txt, honey2.txt, honey3.txt:

Captura: MD5 Ficheros trampa
Captura: MD5 Ficheros trampa

Observamos que se han cifrado con diferente clave (y/o diferente vector de inicialización), ya que el MD5 de cada uno de ellos, una vez cifrados es diferente, a pesar de que su tamaño sea el mismo:

Captura: Cifrado con diferente clave
Captura: Cifrado con diferente clave

Estructura del fichero .ECC

Encontramos que el tamaño del fichero trampa antes del cifrado es de 18 bytes.

Este valor, lo localizamos, dentro del fichero cifrado (.ECC), en hexadecimal en la posición hexadecimal 0x10 (se trata de un valor hexadecimal) (es decir, en el byte 16) en Little-Endian, ocupando 4 bytes.

Como podemos verificar en los siguientes ejemplos. Los ficheros trampa generados, antes de ser cifrados, ocupan 18 bytes:

Captura: Los ficheros trampa generados, antes de ser cifrados
Captura: Los ficheros trampa generados, antes de ser cifrados

En el fichero con extension .ECC generado por el ransomware observamos este valor en hexadecimal en, como comentábamos, byte 16 (posición 0x10 hexadecimal), para ambos ficheros cifrados (Honey1.txt.ecc y Honey2.txt.ecc):

Captura: Honey1.txt.ecc
Captura: Honey1.txt.ecc
Captura: Honey2.txt.ecc
Captura: Honey2.txt.ecc

En esa posición, los 4 bytes en ambos ficheros, representan el valor hexadecimal: 0x12000000, que transformado desde Little-endian, sería: 0x00000012 o 18 decimal, tamaño del fichero -sin cifrar- original.

Pensando en AES que es uno de los cifrados asimétricos utilizados en otros ransomware, en los modos CBC (Cipher Block Chaining) requiere un vector de iniciación de 16 bytes (justo los mismos bytes que hay delante del tamaño del fichero original), además un fichero de un total de 18 bytes cifrado con AES-CBC, genera una salida cifrada de 32 bytes.

Como podemos ver en la siguiente captura de muestra (incluimos el mismo texto y tamaño en bytes que en el fichero original y seleccionamos cifrado AES con CBC), utilizando cualquier clave, obtenemos un resultante cifrado de, como comentábamos, 32 bytes:

Captura: Cifrado 32bytes
Captura: Cifrado 32bytes

Prueba de cifrado con AES-CBC. Utilizando esta herramienta on-line

Creemos que la clave de cifrado estaría almacenada de alguna manera en el fichero key.dat, y es el vector de inicialización (codificado o no) lo que se almacena en el propio fichero .ECC.

El uso de AES-CBC con diferentes vectores almacenados junto con el propio fichero cifrado, encaja con el hecho de que dos ficheros idénticos resulten en datos cifrados diferentes.

Incluimos una representación gráfica de la estructura de fichero que hemos estimado:

Captura: Estructura estimada del fichero cifrado .ECC
Captura: Estructura estimada del fichero cifrado .ECC

Para el análisis de este tipo de fichero, creamos unas clases básicas en el lenguaje Python, que pueden ser descargadas desde el siguiente repositorio en GitHub.

Análisis de Red

Utilizaremos nuestro equipo virtual styx como único equipo visible en la red y mediante inetsim simularemos servicios de red como HTTP, DNS y otros. Para controlar el tráfico del equipo y posteriormente poder analizarlo, dichos servicios simulados resuelven todas las peticiones DNS a la IP del propio styx, de manera que, además de aislar totalmente el equipo, podemos hacer lo que se conoce como Hombre en el Medio de las peticiones de red.

Análisis de solicitudes DNS

Analizando el tráfico de red generado y registrado gracias a inetsim, encontramos las siguientes peticiones DNS desde la máquina infectada con la muestra:

Captura: Tráfico de red
Captura: Tráfico de red

Podemos ignorar las tres últimas peticiones a servicios de Microsoft ya que se trata del comportamiento normal de este Sistema Operativo. Observamos la solicitud de los siguientes nombres de dominio (destacados en negrita), producidos en unos dos segundos de diferencia:

  • ipinfo.io
  • 7tno4hib47vlep5o.63ghdye17.com
  • 7tno4hib47vlep5o.79fhdm16.com
  • 7tno4hib47vlep5o.tor2web.blutmagie.de
  • 7tno4hib47vlep5o.tor2web.fi

Repitiendo estas mismas pruebas antes de que pasasen 24 horas, y también una vez pasadas 72 horas, obtuvimos estos mismos resultados.

  • Ipinfo.io, para obtener información sobre la IP, geo-localización, etc.
  • El resto de dominios son dominios tor2web , que son utilizados como pasarela a servicios ocultos dentro de la red TOR , para usuarios que no estén utilizando dicha red.
  • Comparando con informes existentes de otras muestras de Cryptolocker, observamos que algunos dominios se repiten y otros van variando como parte de la evolución del malware. Por ejemplo Symantec, encontraba dos de esos dominios y un tercero diferente y lo señalaba en su informe de 2 de Marzo de 2015.

Solicitudes HTTP

Extrayendo, también del histórico de inetsum, las peticiones HTTP que no correspondieran a solicitudes normales de un equipo Microsoft Windows (intentos de actualizaciones, etc.), encontramos las siguientes:

Captura: Peticiones HTTP
Captura: Peticiones HTTP
  • Con la primera solicitud obtiene la IP de la máquina, consultando a: ipinfo
  • Observamos que se trata de peticiones tipo GET , dentro de las mismas podemos comprobar que están solicitando una página “.php” , lo cual es un aspecto a tener en cuenta en operaciones contra el Command & Control (C&C).

Aparentemente, las peticiones HTTP (destacadas en marrón) están utilizando una codificación Base 64, que una vez decodificado, muestra lo siguiente (lo presentamos cronológicamente, según van sucediendo las conexiones):

Subject=Ping&key=22B6A6087B91E3361F42A2E957055BE4C74A77894FB6557A99B0F405F398D77D&addr=1EES6eknHpwPZK2YJ2T3DZLEKw8ts1Z4NA&files=0&size=0&version=0.3.4a&date=1429649708&OS=7601&ID=62&subid=0&gate=G0&is_admin=1&is_64=0&ip=

227

En esta primera solicitud a su centro de control, claramente está registrando el equipo como nueva víctima, está indicando que es administrador, versión del sistema, fecha y hora, etc. La dirección IP, obtenida mediante a la llamada a ipinfo.io, incluye información HTML devuelta por nuestro simulador HTTP (destacada en marrón).

Se incluyen otros elementos, como:

(1)

  • Subject: ping , entendemos que se trata de la primera comunicación para, como comentábamos, registrar el equipo.
  • Key: que varía de una ejecución a otra de la muestra, podría tratarse de un identificador del equipo y también podría estar relacionado con la clave del mismo. (22B6A6087B91E3361F42A2E957055BE4C74A77894FB6557A99B0F405F398D77D)
  • Addr: este valor es la dirección bitcoin asignada al usuario para el pago del rescate, es única para cada víctima y viene en formato base-58, utilizado en las direcciones bitcoin. (1EES6eknHpwPZK2YJ2T3DZLEKw8ts1Z4NA)
  • Files: que indica como confirmamos más adelante, el número de ficheros cifrados en el momento en que se produce la comunicación (0 ya que se trata de la primera comunicación.
  • Size: desconocemos qué indica este atributo. (0)
  • Is_64 => indica si la arquitectura es de 64 bits o no. (0 que indica que no es una arquitectura de 64 bits).

Validamos la dirección bitcoin, mediante la utilidad web Base58 Encode, Decode, and Validate:

Captura: Validación de dirección de bitcoin
Captura: Validación de dirección de bitcoin

* Tratamos de utilizar los datos incluidos en dicho fichero junto con la información enviada en las peticiones HTTP mostradas anteriormente que incluía un atributo llamado key, como claves de descifrado y verificación con resultado negativo.

(2)

  • No pudimos decodificar este valor enviado, creemos que puede estar codificado de alguna otra manera, o bien utiliza algún tipo de cifrado u ofuscación.

(3)

  • Subject: Crypted (cifrado, del inglés), entendemos que indica que ya se han cifrado ficheros en el equipo víctima.
  • Files: indica el número de ficheros afectados (1769, como mostraremos a continuación).
  • Size: (9) El valor ha cambiado desde la primera comunicación, pero aún no tenemos indicios suficientes para poder determinar en qué está basado.
  • Versión: nuestra hipótesis es que se trata del número de versión del malware (0.3.4a)
  • Fecha: cuyo valor (1429649714) es un sello de tiempo, o timestamp , que marca la fecha y hora que tiene el equipo en el momento de la comunicación. (06/01/2015, 5:41pm (UTC).
  • OS: que entendemos que se trata de un identificador del Sistema Operativo infectado (7601).
  • ID: No tenemos indicios suficientes para saber de qué se trata, aunque creemos que está relacionado con el equipo de la víctima (62)
  • Subid: entendemos que se trata de un valor relacionado con el anterior (una subcategoría), (0).
  • Gate: no sabemos a qué hace referencia este parámetro (G0).
  • is_admin: se trata de un valor, en este caso positivo (1), indicando si el usuario con el que se ha ejecutado el malware y por tanto, los privilegios que tiene este aplicativo, es administrador o no.

Confirmamos que el número de ficheros se trata del número de ficheros afectados, filtrando nuestro informe de ficheros creados (gracias a regshot) en busca de ficheros con extensión .ECC, es decir ficheros cifrados por CryptoLocker.

228

(4)

229

*Mostramos los datos que consideramos relevantes:

  • Size: (91).
  • Gate (G1)

* No pudimos determinar la motivación de ese cambio.

Siguientes pasos

Nos quedaron muchas cosas por probar y por hacer, si bien, creemos que puede ser interesante invertir esfuerzo en:

  • Análisis en debugger para tratar de descifrar deshaciendo el trabajo del packer, como en: Polymorphic Crypter – Morphine 2.7 by Holy_Father.
  • Un análisis dinámico de mayor profundidad tratando de determinar mediante un depurador, cómo lleva a cabo el proceso de cifrado, librerías y funciones de cifrado utilizadas, generación de la clave y codificación u ofuscación de la misma si se produjera, etc.

Referencias y Bibliografía

Training Resources de ENISA (European Union Network and Information Security Agency).
Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code Paperback – November 2, 2010 by Michael Ligh (Author), Steven Adair (Author), Blake Hartstein (Author), Matthew Richard (Author).

The holiday season and ransomware – November 27, 2013 / Vadim Kotov

Reverse Engineering Malware For Newbies ToorCon 16Published on Oct 29, 2014

Sobre los Autores

Este trabajo ha sido desarrollado como proyecto de fin de Master, en el MÁSTER UNIVERSITARIO EN SEGURIDAD DE TECNOLOGÍAS DE LA INFORMACIÓN Y DE LAS COMUNICACIONES de la Universidad Europea de Madrid.

En él han trabajado:

Marcos Gómez Hidalgo. Especialista en seguridad informática, tutor del proyecto.

Manuel López Hidalgo. Ingeniero especialista en seguridad informática. beat.ransomware _ARROBA_ gmail.com

Jesús Arnáiz Calvo. Ingeniero especialista en seguridad informática. jesusarnaizcts _ARROBA_ gmail.com

Finalmente, agradecemos a Alejandro Cuenca Merchán, diseñador, por sus ilustraciones. cuencamerchan _ARROBA_ outlook.com

Boceto de las viñetas de cabecera, gracias a la cortesía de Alejandro Cuenca
Boceto de las viñetas de cabecera, gracias a la cortesía de Alejandro Cuenca

From the web: sbd (Security by default)

TonyHAT, 2015.

Anuncios

Un comentario en “Análisis de un “RANSOMWARE” cifrado”

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s