Análisis de un Ransomware de Cifrado

Ilustración gracias a la cortesía de Alejandro Cuenca. Haga clic sobre la imagen para ampliar.

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:

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?

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.

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 el uso de un software antimalware o antivirus tradicional sea neficaz, al permitirnos estos, eliminar la amenaza en sí, pero no recuperar los datos una vez ya han sido cifrados.

Objeto del Análisis

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

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

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 aadelante.

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

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. Haga clic sobre la imagen para ampliar

• 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

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

• Estudio de las vías de infección: analizando los estudios publicados sobre muestras similares de RansomWare y consultando al Instituto Nacional de CiberSeguridad (INCIBE).
• 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.



Esquema del 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áquina winbox (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

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:

Resultado de análisis en 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:

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:

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).

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)".

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:

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 y RegShot, 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:

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 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:

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\Desktop\0EF1FE~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 parcial de ficheros trampa cifrados.

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

.7Z

.DMP

.KDC

.PDD

.SLM

.3FR

.DNG

.KF

.PDF

.SNX

.ACCDB

.DOC

.LAYOUT

.PEF

.SR2

.AI

.DOCM

.LBF

.PEM

.SRF

.APK

.DOCX

.LITEMOD

.PFX

.SRW

.ARCH00

.DWG

.LRF

.PKPASS

.SUM

.ARW

.DXG

.LTX

.PNG

.SVG

.ASSET

.EPK

.LVL

.PPT

.SYNCDB

.AVI

.EPS

.M2

.PPTM

.T12

.BAR

.ERF

.M3U

.PPTX

.T13

.BAY

.ESM

.M4A

.PSD

.TAX

.BC6

.FF

.MAP

.PSK

.TOR

.BC7

.FLV

.MCMETA

.PST

.TXT

.BIG

.FORGE

.MDB

.PTX

.UPK

.BIK

.FOS

.MDBACKUP

.PY

.VDF

.BKF

.FPK

.MDDATA

.QDF

.VFS0

.BKP

.FSH

.MDF

.QIC

.VPK

.BLOB

.GDB

.MEF

.R3D

.VPP_PC

.BSA

.GHO

.MENU

.RAF

.VTF

.CAS

.HKDB

.MLX

.RAR

.W3X

.CDR

.HKX

.MPQGE

.RAW

.WB2

.CER

.HPLG

.MRWREF

.RB

.WMA

.CFR

.HVPL

.NCF

.RE4

.WMO

.CR2

.IBANK

.NRW

.RGSS3A

.WMV

.CRT

.ICXS

.NTL

.RIM

.WOTREPLAY

.CRW

.INDD

.ODB

.ROFL

.WPD

.CSS

.ITDB

.ODC

.RTF

.WPS

.CSV

.ITL

.ODM

.RW2

.X3F

.D3DBSP

.ITM

.ODP

.RWL

.XF

.DAS

.IWD

.ODS

.SAV

.XLK

.DAZIP

.IWI

.ODT

.SB

.XLS

.DB0

.JPE

.ORF

.SID

.XLSB

.DBFV

.JPEG

.P12

.SIDD

.XLSM

.DCR

.JPG

.P7B

.SIDN

.XLSX

.DER

.JS

.P7C

.SIE

.XXX

.DESC

.KDB

.PAK

.SIS

.ZTMP

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.

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:

Fichero key.dat

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

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.

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.

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:

HKU\S-1-5-21-3463664321-2923530833-3546627382-1000\Control Panel\Desktop\Wallpaper: "C:\Users\IEUser\AppData\Local\Temp\BGInfo.bmp"
HKU\S-1-5-21-3463664321-2923530833-3546627382-1000\Control Panel\Desktop\Wallpaper: "C:\Users\IEUser\Desktop\HELP_RESTORE_FILES.bmp"

Incluimos una captura de dicho fondo de escritorio:

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:

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:

root@styx:/lab/analyses/cryptolockerHoney14May2015# md5sum Honey*.ecc
c2fce3c0761eb1c60e8a0cfb49829189  Honey1.txt.ecc
7512fbad7ee117e9a3c165296d12d2b8  Honey2.txt.ecc
root@styx:/lab/analyses/cryptolockerHoney14May2015# ls -l Honey*.ecc
-rw-r--r-- 1 root root 52 May 14 06:47 Honey1.txt.ecc
-rw-r--r-- 1 root root 52 May 14 06:47 Honey2.txt.ecc -rw-rw-r-- 1

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:

$ ls -l Honey*.txt
-rw-r--r-- 1 arnaiz root 18 May 14 15:54 Honey1.txt
-rw-r--r-- 1 arnaiz root 18 May 14 15:54 Honey2.txt

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):

Honey1.txt.ecc

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 simé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:

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:

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:

root@styx:/lab/analyses/cryptolocker2# grep 'requested name' report.2896.txt
2015-04-22 13:20:34  DNS connection, type: A, class: IN, requested name: ipinfo.io
2015-04-22 13:20:34  DNS connection, type: A, class: IN, requested name: 7tno4hib47vlep5o.63ghdye17.com
2015-04-22 13:20:35  DNS connection, type: A, class: IN, requested name: 7tno4hib47vlep5o.79fhdm16.com
2015-04-22 13:20:35  DNS connection, type: A, class: IN, requested name: 7tno4hib47vlep5o.tor2web.blutmagie.de
2015-04-22 13:20:36  DNS connection, type: A, class: IN, requested name: 7tno4hib47vlep5o.tor2web.fi
2015-04-22 13:43:26  DNS connection, type: A, class: IN, requested name: go.microsoft.com
2015-04-22 13:44:54  DNS connection, type: A, class: IN, requested name: spynet2.microsoft.com
2015-04-22 13:51:33  DNS connection, type: A, class: IN, requested name: time.windows.com

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:

root@styx:/lab/analyses/cryptolocker# grep HTTP report.1036.txt | grep -v "microsoft.com\|windowsupdate.com\|msftncsi.com"
2015-04-21 22:54:40  HTTP connection, method: GET, URL: http://ipinfo.io/ip, file name: /var/lib/inetsim/http/fakefiles/sample.html
2015-04-21 22:54:40  HTTP connection, method: GET, URL: http://7tno4hib47vlep5o.63ghdye17.com/state1.php?U3ViamVjdD1QaW5nJmtleT0yMkI2QTYwODdCOTFFMzM2MUY0MkEyRTk1NzA1NUJFNEM3NEE3Nzg5NEZCNjU1N0E5OUIwRjQwNUYzOThENzdEJmFkZHI9MUVFUzZla25IcHdQWksyWUoyVDNEWkxFS3c4dHMxWjROQSZmaWxlcz0wJnNpemU9MCZ2ZXJzaW9uPTAuMy40YSZkYXRlPTE0Mjk2NDk3MDgmT1M9NzYwMSZJRD02MiZzdWJpZD0wJmdhdGU9RzAmaXNfYWRtaW49MSZpc182ND0wJmlwPTxodG1sPgogIDxoZWFkPgogICAgPHRpdGxlPk15IHBhZ2U8L3RpdGxlPgogIDwvaGVhZD4KICA8Ym9keT4KICAgIDxwPlRoaXMgaXMgbXkgcGFnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+JmV4ZV90eXBlPTE=, file name: /var/lib/inetsim/http/fakefiles/sample.html
2015-04-21 22:54:40  HTTP connection, method: GET, URL: http://7tno4hib47vlep5o.79fhdm16.com/state1.php?FTdWJqZWN0PVBpbmcma2V5PTIyQjZBNjA4N0I5MUUzMzYxRjQyQTJFOTU3MDU1QkU0Qzc0QTc3ODk0RkI2NTU3QTk5QjBGNDA1RjM5OEQ3N0QmYWRkcj0xRUVTNmVrbkhwd1BaSzJZSjJUM0RaTEVLdzh0czFaNE5BJmZpbGVzPTAmc2l6ZT0wJnZlcnNpb249MC4zLjRhJmRhdGU9MTQyOTY0OTcwOCZPUz03NjAxJklEPTYyJnN1YmlkPTAmZ2F0ZT1HMSZpc19hZG1pbj0xJmlzXzY0PTAmaXA9PGh0bWw+CiAgPGhlYWQ+CiAgICA8dGl0bGU+TXkgcGFnZTwvdGl0bGU+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyBteSBwYWdlLjwvcD4KICA8L2JvZHk+CjwvaHRtbD4mZXhlX3R5cGU9MQ==, file name: /var/lib/inetsim/http/fakefiles/sample.html
2015-04-21 22:54:45  HTTP connection, method: GET, URL: http://7tno4hib47vlep5o.63ghdye17.com/state1.php?U3ViamVjdD1DcnlwdGVkJmtleT0yMkI2QTYwODdCOTFFMzM2MUY0MkEyRTk1NzA1NUJFNEM3NEE3Nzg5NEZCNjU1N0E5OUIwRjQwNUYzOThENzdEJmFkZHI9MUVFUzZla25IcHdQWksyWUoyVDNEWkxFS3c4dHMxWjROQSZmaWxlcz0xNzY5JnNpemU9OTEmdmVyc2lvbj0wLjMuNGEmZGF0ZT0xNDI5NjQ5NzE0Jk9TPTc2MDEmSUQ9NjImc3ViaWQ9MCZnYXRlPUcwJmlzX2FkbWluPTEmaXNfNjQ9MCZpcD08aHRtbD4KICA8aGVhZD4KICAgIDx0aXRsZT5NeSBwYWdlPC90aXRsZT4KICA8L2hlYWQ+CiAgPGJvZHk+CiAgICA8cD5UaGlzIGlzIG15IHBhZ2UuPC9wPgogIDwvYm9keT4KPC9odG1sPiZleGVfdHlwZT0x, file name: /var/lib/inetsim/http/fakefiles/sample.html
2015-04-21 22:54:45  HTTP connection, method: GET, URL: http://7tno4hib47vlep5o.79fhdm16.com/state1.php?U3ViamVjdD1DcnlwdGVkJmtleT0yMkI2QTYwODdCOTFFMzM2MUY0MkEyRTk1NzA1NUJFNEM3NEE3Nzg5NEZCNjU1N0E5OUIwRjQwNUYzOThENzdEJmFkZHI9MUVFUzZla25IcHdQWksyWUoyVDNEWkxFS3c4dHMxWjROQSZmaWxlcz0xNzY5JnNpemU9OTEmdmVyc2lvbj0wLjMuNGEmZGF0ZT0xNDI5NjQ5NzE0Jk9TPTc2MDEmSUQ9NjImc3ViaWQ9MCZnYXRlPUcxJmlzX2FkbWluPTEmaXNfNjQ9MCZpcD08aHRtbD4KICA8aGVhZD4KICAgIDx0aXRsZT5NeSBwYWdlPC90aXRsZT4KICA8L2hlYWQ+CiAgPGJvZHk+CiAgICA8cD5UaGlzIGlzIG15IHBhZ2UuPC9wPgogIDwvYm9keT4KPC9odG1sPiZleGVfdHlwZT0x, file name: /var/lib/inetsim/http/fakefiles/sample.html

• 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=<html>
  <head>
    <title>My page</title>
  </head>
  <body>
    This is my page.


  </body>
</html>&amp;exe_type=1

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:

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.

root@pasteur:~# grep .ecc createdfiles.txt | wc -l
1796

(4)

Subject=Crypted&key=22B6A6087B91E3361F42A2E957055BE4C74A77894FB6557A99B0F405F398D77D&addr=1EES6eknHpwPZK2YJ2T3DZLEKw8ts1Z4NA&files=1769&size=91&version=0.3.4a&date=1429649714&OS=7601&ID=62&subid=0&gate=G1&is_admin=1&is_64=0&ip=(...)

*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 el binario, 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 parte de un 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. mgomezhidalgo _ARROBA_ gmail.com.
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.

Etiquetas: cifrado , contribuciones , cryptolocker , debugging , forense , forensic , ingeniería inversa , malware , ransomware , reversing