Blog gratis
Reportar
Editar
¡Crea tu blog!
Compartir
¡Sorpréndeme!
Blog de la Escuela de Educación Secundaria Técnica N 8 de Quilmes
Administrador Prof. Claudio Enrique Alonso Alvite
img
19 de Junio, 2015    General

Análisis de un Ransomware de Cifrado

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:
Figure 14. Global distribution of CryptoLocker infections between October 22 and November 1, 2013. (Source: 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?

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.

  • 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.
    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
    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
    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
    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
    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
    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
    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
    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.
    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.
    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
    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
    Fichero key.dat

    Validamos la dirección bitcoin en Base58 Encode, Decode, and Validate:
    Validación de dirección bitcoin incluida en key.dat
    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
    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
    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
    Honey1.txt.ecc

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



    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>&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
    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.
    Palabras claves , , , , , , , ,
    publicado por alonsoclaudio a las 00:24 · Sin comentarios  ·  Recomendar
     
    Más sobre este tema ·  Participar
    Comentarios (0) ·  Enviar comentario
    Enviar comentario

    Nombre:

    E-Mail (no será publicado):

    Sitio Web (opcional):

    Recordar mis datos.
    Escriba el código que visualiza en la imagen Escriba el código [Regenerar]:
    Formato de texto permitido: <b>Negrita</b>, <i>Cursiva</i>, <u>Subrayado</u>,
    <li>· Lista</li>
    CALENDARIO
    Ver mes anterior Agosto 2017 Ver mes siguiente
    DOLUMAMIJUVISA
    12345
    6789101112
    13141516171819
    20212223242526
    2728293031
    BUSCADOR
    Blog   Web
    TÓPICOS
    » General (2606)
    NUBE DE TAGS  [?]
    SECCIONES
    » Inicio
    ENLACES
    MÁS LEÍDOS
    » Cómo espiar WhatsApp
    » Cómo usar Metashield protector for Client y por qué utilizarlo
    » Ejecución remota de código arbitrario en OpenSSH
    » Ganar dinero con 1.200 Millones de identidades robadas
    » Hardware y sus 4 Funcionamientos Basicos y Principales en una Computadora
    » #Phishing masivo a #BancoFrances, #PagoMisCuentas y #Movistar (110 afectados en 4 horas)
    » Redes de la Deep Web: CJDNS y la Red Hyperboria
    » Unidad Central de Procesamiento CPU
    » Vulnerabilidad en Youtube permitió borrar cualquier video
    » Wassap, la aplicación que permite usar WhatsApp desde la PC
    SE COMENTA...
    » Cómo espiar WhatsApp
    15 Comentarios: lucia, wilson, spider hackers, [...] ...
    » SoftPerfect WiFi Guard permite saber quién esta conectado a mi WiFi
    1 Comentario: carlos lopez
    » Analizando el LiveBox 2.1 de Orange
    2 Comentarios: Nadie, brahim
    » Antenas WiFi de gran potencia. Enlaces a 1.000 Km.
    2 Comentarios: julio enoy, julio enoy
    » Cómo liberar software – guía para principiantes :)
    1 Comentario: seo plugin
    SOBRE MÍ
    FOTO

    Prof. Claudio Enrique Alonso Alvite



    » Ver perfil

    AL MARGEN
    Escuela de Educacion Secundaria Tecnica N 8 de Quilmes
    (Técnicos en Informática Personal y Profesional)
    FULLServices Network | Blogger | Privacidad