29 junio 2015

How-to: Bypass Ley Mordaza (o parte de ella)



Uno de los temas que más está dando que hablar últimamente es que a partir del 1 de Julio, entra en vigor la Ley de Seguridad Ciudada, última del paquete de leyes conocido como Leyes Mordaza, por la influencia que tiene la misma en la privacidad de los internautas, a la hora de actitudes que hasta ahora nos parecen “normales”, que serán consideradas un delito.

Todos somos conscientes también que cierta regulación tiene que existir y que no haya posibilidad que actitudes que pueden calificarse como deleznables, igualmente deberán ser perseguidas y castigadas de forma ejemplar.

Dicho esto, sin embargo, para aquellos que están en el limbo en sus hábitos, que no les parece que lo que se hace está mal cuando se trata de ayudar a los demás (aunque quede en manos de un juez calificarlo como "terrorismo"), así como aquellos que no les da la gana que se les pueda espiar o categorizar, en base a su navegación, así como prohibir qué es lo que puedes y lo que no puedes ver, hay diferentes maneras de evitarlo, que quiero sumarizar en este post:

1.-) Cámbiate de país…

Bueno, tampoco hay que pasarse. No digo que haya que hacerlo literalmente, y que tengas que mudarte físicamente, pero al menos sí virtualmente. ¿Cómo se hace esto? La solución más sencilla es mediante la contratación de un servicio VPN fuera de España… incluso diría que fuera de la Unión Europea.  

Este tipo de servicios modifican el “default gateway” de la máquina, de manera que hacen que TODO, salga enrrutado a través del túnel, haciendo que la navegación vaya cifrada hasta el punto de salida. Desde ahí ya sale a la superficie del mar, pero a través de otro país…. Y el ISP, no se enterará de qué tráfico estás generando.

“Oye pero es que entonces la navegación me irá más lenta… y no me servirá de nada tener 100 Megas de bajada y….” Bueno, entonces, para aquello que no te importe que te vean utiliza tu vida normal, pero cuando quieras privacidad, entonces usa la VPN. 

“Uffff, que coñazo, tener que estar quitando y poniendo la VPN, etc,…” 
Vale,… te doy otra opción

2.-) Cómprate una VPS,… sí, en un ISP de otro país

Al igual que en el caso anterior, puedes pagar el servicio con Bitcoins, haciendo que sea muy complicado de tracear el origen de la compra. En ese VPS, monta un proxy, securiza bien la máquina, y haz un SSH (habiéndolo configurado de la forma más estricta posible) con una redirección de puertos a tu proxy local. Instala una extensión en tu navegador como SwitchySharp en el que podrás generar hasta reglas para que la navegación que quieras salga por un proxy, por otro o de forma directa incluso. 




Ojo, de esta manera, si en tu navegador no has tomado medidas de protección como las que te conté en un post anterior… puede que por técnicas de WebRTC tu navegador esté dejando tu IP real.

3.-) Say goodbye al DNS de tu proveedor… o a los de Google

Uno de los mecanismos de espionaje más centralizados para perfilar tipos de navegación es mediante las peticiones DNS que llegan a los servidores… y que pasan a través de tu ISP. Si en vez de utilizar estos, usas otros, ya no les dejas esos logs en los DNS que te proveen. Si usas los del todopoderoso Google, 8.8.8.8 y 8.8.4.4, le estás regalando tu navegación a Google. 

En este punto, alguno dirá,… claro pero es que aunque uses un DNS de la otra punta del planeta, el protocolo va en texto claro y es posible que, si me esniffan, puedan identificar mi navegación igualmente. Cierto… entonces, la solución se llama OpenDNS. 

En el timeline de @la9deanon, que de búsqueda de la privacidad, controlan un rato largo, leí un post que me resultó sumamente interesante, relacionado con la vigilancia en Internet en que se recomienda la utilización de DNSCrypt, además de con el objetivo de evadir las decisiones impuestas por un juez, para bloquear "el acceso” a páginas web a los ISPs, para hacer que tu tráfico DNS vaya cifrado hasta unos servidores provistos por OpenDNS.

Sinceramente, si estos logs se los entregan o no la NSA, es lo de menos, pero al menos tu ISP no puede ver pasar las solicitudes ni las respuestas. 

El funcionamiento es sencillo: Instalas un programa que hace de proxy, levanta un servicio DNS ficticio en tu máquina que reencamina mediante HTTPS (con cifrado de Curvas Elípticas) hacia los servidores, y devuelve las peticiones de manera muy eficiente en tiempos.

De esta manera, si navegas hacia https://www.opendns.com/welcome/ de forma normal, verás un aviso como este:


En cambio, si navegas usando el proxy de OpenDNS, verás una web más positiva, y aquel tráfico que vaya por HTTPS, así como las peticiones DNS necesarias irán cifradas. 



OJO,... ¿quiere decir esto que esta navegación es perfecta desde el punto de vista de la privacidad a ojos de tu ISP? NO... Todo el tráfico que vaya por HTTP seguirá yendo en claro, y tu ISP seguirá sabiendo, aunque sea por HTTPS, las direcciones IP con las que te estás comunicando, aunque no pueda interceptar el tráfico sin que te enteres,... al menos, no lo puede hacer, de forma conocida y pública. 


Leer más...

28 junio 2015

Enlaces de la SECMana - 282



Leer más...

25 junio 2015

Abierto Call For Papers para RootedSatellite: Valencia 2015

RootedSatellite: Valencia es un Congreso de seguridad que se realizará en Valencia (España) el día 12 de Septiembre de 2015.


El evento matriz, RootedCON es el congreso especializado más importante que se realiza en el país, y uno de los más grandes de Europa, con perfiles de asistentes que varían desde estudiantes, a Fuerzas y Cuerpos de Seguridad del Estado, pasando por profesionales dentro del mercado de la Tecnología y la Seguridad en TI o, simplemente, entusiastas de la tecnología.

Tras la gran acogida que tuvo la primera edición de RootedSatellite en Valencia, RootedCON ha vuelto a apostar por esta ciudad para fomentar la seguridad de las TI en Valencia, descubrir el talento local y poner en contacto a estudiantes y profesionales interesados en la materia para que colaboren y de esa manera fortalecer los lazos de la comunidad de seguridad. 

En la siguiente dirección encontraréis el formulario de solicitud de ponencias para RootedSatellite: Valencia 2015:



Muy pronto actualizaremos rootedcon.com/vlc con toda la información necesaria acerca de esta nueva edición, incluyendo la localización, patrocinadores, primeros ponentes confirmados ¡y mucho más! 

Para hacer más amena la espera, tenéis disponible en esta lista de reproducción de nuestra cuenta de Youtube los videos de las charlas de la pasada edición de RootedSatellite: Valencia.

 

[->] Álbum de fotos RootedSatellite: Valencia 2014
[->] Lista de reproducción de videos RootedSatellite: Valencia 2014
[->] Call For Papers RootedSatellite: Valencia 2014

Artículo cortesía de Asociación Rooted (@rootedcon)
Leer más...

24 junio 2015

c00kiesD00r, ocultando una backdoor en una cookie

Muchas veces, a la hora de investigar una intrusión, se suele tener una check-list de sitios y técnicas que han podido ser empleadas para ocultar una backdoor por parte de un atacante para mantener el acceso.

De lo buena/mala que sea esa check-list depende el número de horas que vas a pasar intentando localizar el 'regalo' del visitante.

Aquí ya hemos hablado alguna vez sobre cómo 'backdoorizar' un servidor apache y decíamos que algo muy común era el uso de peticiones POST en vez de GET para intentar no salir en la foto.

Otra forma de comunicarse con un backdoor que se encuentre en un servidor web es enviando los comandos en una cookie, esta técnica se puede ver implementada en la herramienta c00kiesD00r que cuenta con una parte para el servidor y un cliente que funciona en Windows y Linux para comunicarse con él.

La parte del servidor se puede implementar en muy pocas líneas de PHP


Tal y como está implementada, la herramienta es un muy buen PoC aunque relativamente fácil de detectar. Si sobre ella construimos algo que lleve ofuscación, y la parte del servidor la añadimos a algún fichero .php legítimo, podemos encontrarnos en un escenario bastante más complicado de abordar desde el punto de vista de un analista forense
Leer más...

22 junio 2015

Certificar correos entrantes y salientes con eGarante

Mucha gente, (especialmente colectivos profesionales), ha enviado multitud de correos a eGarante preguntando por la posibilidad de, no solo certificar correos salientes, sino también poder certificar la recepción de un correo.

Viene muy bien disponer de la capacidad de poder demostrar, con plena validez jurídica, que te ha llegado un correo. Y no solo a nivel profesional. Como particular, poder demostrar que la compañía X te ha enviado un correo con unos datos concretos, tiene un valor bastante importante, sobre todo si recibes tus facturas en correo o compras por internet.

Por eso, nos hemos puesto a pensar cómo poder ofrecer un servicio que cubriese esa demanda y el resultado ha sido eG-inbox 

eG-inbox es, básicamente, una cuenta de correo que tiene la particularidad de certificar todos los correos que llegan y además, mediante el uso de un servidor SMTP especial, auto-certificar todos los correos que se envíen desde esa cuenta. Sin necesidad de poner en copia a eG-email, todo de forma automática.

De esa forma, puedes tener tu correo principal, de uso cotidiano, y además una cuenta de correo que puedes usar para comprar online, relacionarte con la administración o como cuenta para gestionar la facturación de tu empresa.

El servicio se puede probar enviando un correo a test@eginbox.egarante.com 

Y para los amantes de Gmail, decir que el servicio es 100% compatible. Puedes configurar la segunda cuenta de correo desde Gmail y usarla desde la interface web

Si estás interesado, quieres probarlo sin compromiso o más información, ponte en contacto con nosotros
Leer más...

21 junio 2015

Enlaces de la SECMana - 281




Leer más...

18 junio 2015

Análisis de un Ransomware de Cifrado

Ilustración gracias a la cortesía de Alejandro Cuenca. Haga clic sobre la imagen para ampliar
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:
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. 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.
    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:\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.
    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:

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



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


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

    Leer más...

    15 junio 2015

    Lastpass... pwned?




    Imagino que muchos de nuestros lectores habéis confiado la custodia de vuestras credenciales en el servicio en la nube LastPass

    Los que no lo conozcáis (si es que hay alguien de este sector que no lo sepa), esta compañía lleva a la práctica la idea de poder acceder a tus contraseñas desde cualquier dispositivo, puesto que la nube las recuerda por tí, y todo ello cifrado con una contraseña maestra que sólo te sabes tú. 

    ¿Pinta genial, verdad?.... Excepto cuando ese servicio, o sus redes, se ve comprometido. 

    Vía twitter, leo que en el blog de Lastpass han publicado una nota en la que se dice que desde el viernes pasado, detectaron una actividad anómala en su red. 

    Aunque no está confirmado el alcance completo del incidente, indican que las direcciones de correo de usuarios, indicios recordatorios de contraseña, salts y hashes de autenticación sí que han sido comprometidos.

    Las credenciales de los usuarios se cifran con el hash de la contraseña maestra del usuario, un salt aleatorio y 100.000 iteraciones de PBKDF2-SHA256

    Lo que están recomendando a sus usuarios es que cambien inmediatamente la contraseña maestra, a fin de que se regenere todo de nuevo.

    Esto podría implicar que las bases de datos de Have I Been Pwned? se vean nutridas con nuevos contenidos próximamente, sobre todo por aquellos que hayan tenido sus credenciales guardadas allí.

    Como medidas proactivas, desde Lastpass están exigiendo confirmación de autenticación por email a todos aquellos usuarios que se estén dando de alta desde dispositivos no registrados anteriormente. 

    En muchas charlas me habréis oido decir que soy "anti servicios en la nube", o que "las nubes son para los aviones". Obviamente, no soy usuario de Lastpass, y siempre he confiado en guardar mis contraseñas en local, utilizando KeePassx en un contenedor Truecrypt,... y por si acaso el disco duro de mi Mac, cifrado con Filevault2... Que sí, que todos ellos han tenido vulnerabilidades conocidas en su implementación en varias ocasiones, pero al menos sé que la llave la tengo yo.

    Así que ya sabéis, usuarios de LastPass, corred a cambiar la contraseña maestra,... y, aunque desde LastPass digan lo contrario (qué te van a decir, claro) si yo fuera vosotros, me tomaría el trabajo de hacerlo en todas aquellas identidades que hayáis confiado en este servicio.

    Edito para añadir, que se ve que no es la primera vez que detectan una anomalía en la red últimamente: https://blog.lastpass.com/2011/05/lastpass-security-notification.html/.
    Leer más...