Español | English
rss facebook linkedin Twitter

Ransom... qué?

Dentro del Ransomware existen multitud de variantes. Este post no pretende ser una recopilación exhaustiva sino un simple repaso de las distintas técnicas usadas por las muestras más relevantes que han pasado por el departamento de Ecrime de S21sec.

Una de la más extendida el año pasado fue Urausy, más conocido como "Virus de la Policía".


Malware que, a pesar de tener algunos interesantes trucos anti-análisis, su funcionalidad principal se limita a crear un nuevo escritorio, mostrar una de las imágenes anteriores según el país de la víctima y bloquear el sistema hasta que se pague el rescate.

Por suerte, el número de muestras detectadas por S21sec parece ir en claro descenso en los últimos meses; lo que podría indicar que su final está cerca:


Pero en este mundo, lo que es el final para una amenaza, es el comienzo para otras nuevas, como la variante a la que hemos llamado RansomChild por hacer uso de imágenes de pornografía infantil (que no vamos a reproducir aquí) para hacer más efectivo su chantaje. Funcionalmente también bloquea el sistema, pero tiene como peculiaridad un sistema de generación de dominios (DGA por sus siglas en inglés) a partir de una semilla estática como backup al panel de control.

Otra de las más destacadas durante el año pasado ha sido Cryptolocker:


En este caso el rescate no se pide por desbloquear el sistema sino por la recuperación de los múltiples ficheros que cifra de forma irrecuperable. El malware, tras instalarse se añade al registro para sobrevivir al reinicio y empieza a comprobar dominios generados mediante un DGA basado en tiempo, hasta dar con uno que responda, al que envía un archivo llamado CryptoLockerID con el que el servidor genera un par de claves (publica y privada) específicas para el equipo infectado.

Cryptolocker ha sido uno de los Ransomwares que hacen uso de cifrado más extendidos y que más estragos ha causado de los últimos tiempos, aunque gracias a la pronta respuesta de la comunidad, ha sido posible atajarlo en gran medida.

Uno que ha hecho menos ruido, pero no menos daño a quien ha sido víctima del mismo, es el conocido como Anti-Child Porn SPAM protection 2.0:


También cifra ficheros de forma irrecuperable hasta la fecha, y tiene como peculiaridad que no se distribuye de forma masiva sino que el grupo detrás de el mismo parece conseguir acceso previo a los sistemas (Windows Server) a través de ataques de fuerza bruta al servicio de escritorio remoto en el puerto 3389.

Tan rentable está siendo el sistema seguido por los Ransomwares, que hasta llegan a salirse de la localidad objetivo, como ha sido testigo uno de nuestros clientes afectado por la variante GPCode:


Por lo tanto, como hemos visto, la mejor solución para este tipo de malware pasa por la prevención, sobre todo en el caso de aquellos que hacen uso de cifrado, ya que no siempre vamos a tener la suerte de que sea débil y pueda ser roto como ha sucedido en el caso de Bitcrypt por nuestros colegas de Cassidian.

De esta forma se recomienda:
  • En primer lugar, sentido común, ya que la ingeniería social suele ser un componente importante a la hora de infectar.
  • Para evitar el cifrado de archivos en carpetas compartidas, es importante restringir los permisos en unidades de red para evitar que la infección de un usuario con permisos pueda desembocar en el cifrado de las mismas.
  • Se recomienda la realización de backups de forma periódica y centralizada, de tal forma que la copia seguridad resida en un dispositivo físico distinto e inaccesible.
  • Mantener el sistema actualizado y fortificar aquellos servicios expuestos empezando por el uso de contraseñas suficientemente robustas.
  • En el caso concreto de las muestras analizadas de Cryptolocker, no procede al cifrado de los archivos hasta que ha contactado con el C&C, por lo que una solución como LTI podría prevenirlo. 

Santiago Vicente

Citadel "involution"

Mediante la Plataforma de Análisis de S21sec, que analiza y clasifica miles de muestras de malware cada día, vamos haciendo seguimiento de familias que nos parecen interesantes para nuestros clientes. De entre las más conocidas (y de las que más hemos hablado) hoy volvemos a hablar de Citadel. Mediante un control sobre las actualizaciones que realizan las botnets de Citadel, y tras su análisis, podemos comprobar el nivel de actividad de cada botnet, cambios relativos a las entidades que afecta, cuándo se queda inactiva, etc etc.

A pesar de que hace ya muchos meses desde que se liberó la última versión (la 3.1.0.0), y a pesar de que se daba por hecho que sería sustituido por por otras familias de troyanos bancarios, lo cierto es que, a día de hoy, a pesar de la operación efectuada por Microsoft para acabar con él, siguen existiendo botnets de Citadel activas.

Lo que sí es cierto es que, desde principios de año, venimos observando una caída notable en cuanto al número de muestras que entran diariamente en los analizadores. En las siguientes gráficas se puede ver una evolución de la tendencia en los últimos meses de las 3 versiones más populares del troyano.





Por supuesto, este dato sería inútil sin mostrar la evolución en cuanto al número de muestras que entran en la Plataforma de Análisis, "inversamente proporcional" a la entrada de muestras de Citadel.


La versión más extendida ha sido la 1.3.5.1 y, de hecho, actualmente casi el 90% de las botnets que vemos activas pertenecen a esta versión. Dos de los motivos por los que creemos que no ha habido un cambio masivo a la 3.1.0.0 son:

  • La versión 1.3.5.1 es la última que, hasta donde sabemos, estuvo a la venta de forma "pública".
  • El leak del builder de Citadel de la versión 1.3.5.1 ha permitido a muchos ciberdelincuentes no tener que desembolsar dinero por la compra, a pesar de no disponer de las actualizaciones a las que daba derecho su compra.

Advanced Cyber Security Services
S21sec

Una imagen vale más que mil palabras

En los últimos días parece que está tomando cierta relevancia el uso de viejas técnicas de compresión de código javascript, para ofuscación y evasión de sistemas de detección de malware y/o phishing.

Lo que originalmente se ideó como una forma de conseguir el máximo rendimiento con código llevado a su mínima expresión, ha dado ciertos quebraderos de cabeza a los sistemas de detección de malware o código malicioso, más por su uso ahora de forma más habitual que por su novedad técnica. Lo sencillo si efectivo dos veces productivo.

En su vertiente más simple, nos podemos encontrar ficheros gráficos donde los datos de cada pixel han sido substituidos por el valor ASCII de cada carácter que forma el código JavaScript, donde posteriormente estos datos son leídos utilizando los métodos específicos del objeto HTML ‘Canvas’ y luego tratado según el objetivo del mismo.

Esta forma de uso de los formatos gráficos, ya fue comentada allá por el año 2008 por Jacob Seidelin, con la única diferencia que ahora parece que se está utilizando de forma más habitual para dificultar la detección de código malicioso, en vez de la optimización de tamaños de la idea original.

 Maliciosa

Original

Como se puede ver, comparando el código original y código utilizado para inyección del tag IFRAME a través de una imagen PNG utilizando esta técnica, las diferencias son mínimas ya que las funcionalidades realmente importantes residen en la imagen en sí misma y no en la forma de cargar dicha información.

Este básico concepto se lleva a la práctica en dos pasos, el primero evidentemente es generar la imagen con el código JavaScript lo cual podemos hacer con el mismo script PHP que proporciona Jacob Seidelin, y una vez tenemos la imagen, bastaría con incluir el código de carga en nuestro HTML, ya sea insertando la función loadPNGData en un fichero aparentemente lícito (como podría ser jQuery) y que pase desapercibida, directamente en el cuerpo de la página o de la forma que creáis más oportuna.

Aunque este método es muy efectivo y funcional, existe una variación del mismo en la cual se puede añadir el código JavaScript a una imagen ya existente, teniendo así un fichero que puede cumplir dos funciones, la de imagen gráfica y la de código malicioso, bastando para su uso el incluir la imagen como fuente del tag "script".

Para conseguir esta doble funcionalidad, tras la firma del tipo de fichero se insertan los caracteres /* indicando el inicio de un comentario, los cuales se cierran */ al final de la imagen, y adicionalmente se añaden los caracteres =1; para una correcta sintaxis (Ej: BM/*......*/=1;) por lo que cualquier contenido a partir de estos caracteres sería interpretado como código totalmente correcto y la cabecera de la imagen aunque modificada continua siendo correcta y la imagen será interpretada correctamente (esta variante será posible llevarla a la práctica dependiendo del formato de la cabecera de la imagen, pero a día de hoy es posible usarla en diferentes formatos gráficos como puede ser GIF o BMP) como ya detallaban los siguientes enlaces:

Sea cual sea el método de los anteriores que nos encontremos, o alguna variación o combinación de estos, o nuevos vectores que puedan surgir a partir de las funcionalidades HTML5 (audio, video o cualquier contenido multimedia), no podemos olvidar que el código malicioso no va a estar siempre en los puntos más lógicos, y sin embargo cualquier dato tratado por un navegador es susceptible de ser usado para tareas para las que no fueron pensadas inicialmente, y si no pongamos atención en la multitud de técnicas que años atrás se desarrollaron para optimizar recursos en el uso de JavaScript encapsulando este en formatos gráficos. Era cuestión de tiempo que estas fueran utilizadas para ocultar código malicioso.
 
Eugenio delfa
Acss México

El troyano Dexter

Dexter es un conocido troyano orientado al robo de tarjetas en los TPV. Aunque las primeras versiones fueron vistas en Diciembre de 2012, una nueva versión, conocida como Dexter v2 o StarDust fue descubierta en Diciembre de 2013. Entre las funciones de StarDust se encuentran la localización de pistas de las bandas magnéticas de las tarjetas de crédito en memoria y funciones de keylogger. En este artículo vamos a analizar las técnicas de comunicación del troyano con su control panel.

StartDust utiliza peticiones POST para el envío de datos. Los parámetros del POST son cifrados mediante XOR con una cadena aleatoria creada durante la instalación del malware y luego codificados en Base64. Sin embargo, la clave XOR es enviada con los parámetros con un simple Base64, por lo que el cifrado podría considerarse simplemente como una ofuscación de los datos. A cada petición, el servidor responde en una Cookie, que puede incluir comandos para el control del troyano (actualizarse, desinstalarse, forzar un chequeo de memoria, etc.)


La función que crea el cuerpo de la petición, recoge ciertos datos de la máquina y genera la cadena para el POST:

Los parámetros se van añadiendo a request_body usando la función encode_param(char *param, char *value, char * request_body), la cual codifica los valores de los parámetros con XOR y Base64 y añade el parámetro y el valor codificado a la cadena destino. Por último se añade el parámetro val con la clave usada para la codificación XOR, codificada únicamente con Base64.


La función de codificación por XOR muestra defectos de diseño, aunque es suficiente para ocultar las cadenas, no lo es desde un punto de vista criptográfico.


La clave de codificación que genera el bot es de 5 bytes, sin embargo el uso de la función XOR la reduce a una longitud efectiva de 1 byte. Siendo los bucles principales de la siguiente manera:


for(i=0; i
    for(j=0; j
        string[i] ^= xor_key[j];
    }
}


Debido a la propiedad conmutativa de XOR, el bucle interior podría expandirse como:

string[i] ^= xor_key[0] ^ xor_key[1] ^ xor_key[2] ^ xor_key[3] ^ xor_key[4] 

O lo que es lo mismo:

xor_value = xor_key[0] ^ xor_key[1] ^ xor_key[2] ^ xor_key[3] ^ xor_key[4];
for(i=0; i
    string[i] ^= xor_value;
}


Lo que convierte en la práctica la longitud de la clave XOR a un valor de 1 byte.

Volviendo al análisis de las comunicaciones, en caso de que exista el fichero strokes.log, que es generado por el keylogger lo descifra con la misma función xor_encode usando una clave propia que aparece en los 4 primeros bytes del fichero. Una vez descifrado, genera el parámetro ks codificándolo de nuevo, esta vez con la clave XOR del resto de parámetros.


Si es la primera vez que se comunica con la dropzone, añade los parámetros unm, cnm, query y spec con el usuario, nombre de la maquina, la versión del sistema operativo y la arquitectura (“32 bits” o “64 bits”) de la máquina infectada.

Tras enviar la petición, lee la cookie response, cifrada de la misma manera que la petición y procesa la respuesta en busca de comandos.



La respuesta tiene el siguiente formato:

    #[comando1][;comando2][…]$

Pudiendo enviarse una respuesta vacía con la cadena '#$'
Los comandos aceptados por el malware son:

  • checkin: fuerza el envió de datos de tarjetas
  • scanin: fuerza el escaneo de memoria en busca de tarjetas
  • uninstall: desinstala el troyano
  • download: descarga un fichero de la url especificada
  • update: descarga una nueva versión del troyano y se instala 


El uso de cookies para enviar la respuesta desde el servidor es una manera original de esconder las comunicaciones del troyano durante un análisis dinámico o inspeccionado el tráfico en red, aunque los parámetros del POST deberían ser suficientes para que un IDS detecte la presencia del troyano.

Marcos Agüero
S21sec ecrime


Llega la Navidad, llegan las compras online ¿seguras?

Con la llegada de la Navidad aumenta la actividad en torno al comercio electrónico y los ciberdelincuentes aprovechan la ocasión para convertir Internet en el escenario ideal para cometer sus delitos. Realizar las compras a través de Internet aporta muchas ventajas al comprador y cada vez son más los usuarios que confían en la Red como medio para realizar sus compras navideñas.

Sin embargo, el tener que efectuar el pago de nuestras compras online mediante tarjeta bancaria y el temor a poder ser víctimas de una estafa que afecte a los fondos de la cuenta asociada, hace que muchos usuarios continúen aún reacios a este tipo de operaciones.

En la actualidad, el comercio electrónico está dotado de soluciones tecnológicas avanzadas para lograr unos niveles de seguridad que permitan garantizar la confianza en la utilización de estos servicios. Conocer éstas medidas (como por ejemplo el acceso a las páginas de comercio electrónico durante el pago a través de HTTPS://) y utilizar el sentido común es indispensable para realizar nuestras compras de una forma segura:


Si encontramos una dirección web de compras poco conocida y un producto con un precio escandalosamente bajo comparado con el resto de las ofertas de otras webs, deberíamos asegurarnos del estado y calidad del producto así como investigar un poco sobre la reputación de este portal y valorar su fiabilidad y credibilidad.

Si para el momento del pago del producto con tarjeta, el sistema nos solicita más información de la que habitualmente es requerida (titular, número de la tarjeta, fecha de caducidad y código CVV de seguridad). En este caso, es interesante conocer perfectamente cuál es la información que deben solicitarnos para los pagos con tarjeta de crédito y cuál no, y ante la menor duda cancelar la operación inmediatamente sin enviar la información.

Igualmente aplicando el sentido común se recomienda;

No utilizar la tarjeta de crédito asociada a nuestra cuenta de ahorro principal para operaciones por Internet. Si fuéramos victimas de una estafa a través de Internet y un delincuente se hiciera con los datos de nuestra tarjeta de crédito/débito, estaríamos arriesgando todo el capital que tuviéramos en ella (o cuando menos el límite máximo que tuviéramos configurado).

La alternativa sería disponer de una segunda tarjeta de crédito/débito exclusiva para realizar nuestras operaciones en la red; bien vinculada a nuestra cuenta principal pero con un límite de compra muy bajo y ajustado, o mejor aún, si fuera posible, utilizar una tarjeta de compra "virtual" (como servicio VINI) que podamos cargar cada momento con los importes que necesitemos según cada operación y que está creada con una numeración, fecha de caducidad y CVV totalmente diferentes a nuestras tarjetas de crédito/débito "físicas" que usamos a diario.


Conocer perfectamente los nuevos mecanismos de verificación y validación de pago por Internet que en la actualidad están siendo implantados por Comercios electrónicos en colaboración con VISA (Verified by VISA) y Master Card (Master Card Secure Code) puede ayudarnos a evitar incidencias en nuestras compras online.


Los métodos utilizados para validar la identidad del titular de la tarjeta en las operaciones por Internet son diversos y varían de una entidad financiera a otra, por lo que debemos consultar con nuestra entidad si aceptan esta modalidad y conocer el proceso que se seguirá para validar la operación, ya que, una vez introducidos los datos de la tarjeta de crédito/débito y una vez conectado de forma segura a la pasarela de pago de nuestra entidad financiera, pueden solicitarnos lo siguiente:

  • La identificación (usuario y PIN) utilizada para la conexión al servicio de Banca Online de la entidad asociada a la tarjeta.
  • El valor de una de las casillas de la tarjeta de coordenadas (filas/columnas) utilizada por su entidad financiera para validar las operaciones efectuadas en la banca online. La casilla necesaria puede ser solicitada a través de un mensaje de SMS.
  • El código PIN de su tarjeta "real" de manera que se actúa como si estuviéramos delante del datafono tras realizar una compra en un comercio tradicional


S21sec Institute

ZeuS timeline (y III)


En el último post de esta serie dedicado al timeline de ZeuS y sus leaks [1][2], vamos a hablar de algunos números que S21sec ha podido extraer del recorrido del troyano hasta hoy.

El número de botnets detectadas en estos años ha alcanzado el valor de 2.300. La mayoría de ellas han sido botnets de ZeuS. Para ilustrarlo de una manera visual, en la siguiente gráfica se observa la distribución por versiones. Se puede apreciar que entre las dos principales versiones de ZeuS (2.1.0.1 y 2.0.8.9) copan casi el 50% de los ataques.


Como se observa en la siguiente gráfica, la mayoría de estos ataques han ido dirigidos al sector financiero, y más concretamente a la Banca Online, cuyas entidades han sufrido un 87,5 de los ataques de esta familia.


Aunque históricamente la afectación a la Banca Online ha sido altísima, ésta ha descendido desde la aparición de nuevas variantes, que diversifican sus ataques a otros sectores que les permitan conseguir su objetivo. En este sentido, la seguridad de la Banca Online cada vez es mayor y el robo mediante transferencias fraudulentas ha descendido notablemente. En la siguiente gráfica se observa la evolución de afectación a la Banca Online, que de estar en una media de un 88% de afectación ha descendido a un 86,8% en lo que llevamos de 2013.


Los datos de los que dispone S21sec avalan esta teoría, y si hacemos una comparativa de muestras solamente entre ZeuS y Citadel (las que más hemos visto), lo comprobaremos. En 2012 (año en que apareció Citadel) el porcentaje era de un 24% frente a un 76% de ZeuS (recordad que hemos discriminado el resto de familias). Ahora bien, en el presente año los valores se han invertido, y hemos detectado un 41% de ZeuS frente a un 59% de Citadel, a pesar de la actuación de Microsoft a mitad de año para desactivar las botnets de Citadel. En este sentido, las versiones de ZeuS siempre han estado más dirigida al sector bancario que las nuevas variantes, incluyendo Citadel.

A continuación os mostramos una gráfica de afectación por países (es decir, el país de la entidad atacada, siempre que ésta siga teniendo formulario de credenciales). Para entender esta gráfica, has de saber que un ataque de un troyano afecta a más de una entidad al mismo tiempo, así que si se produce un ataque sobre muchas entidades de un país, éste recibe un mayor peso en la gráfica.


En este sentido, las entidades españolas han sido las terceras más atacadas históricamente, con un 16% del total de ataques sufridos (principalmente entidades financieras, aunque os recordamos que se está diversificando a otros sectores). Sin embargo, esta afectación ha sido mucho más alta para las versiones de ZeuS que para otras variantes. Es decir, la afectación a entidades españolas respecto al total de ataques ha estado por encima del 18% en los últimos años, y sin embargo durante 2013 ha descendido a un 14%.

Para finalizar, comentar que las nuevas variantes de ZeuS no solamente han diversificado los ataques a otros sectores, sino también al número de países cuyas entidades son atacadas. En lo que llevamos de 2013 este valor ha aumentado hasta los 71 países diferentes con entidades afectadas.


Como veis, es mucha la guerra que nos ha dado ZeuS durante los últimos años. Parece que la cosa no ha acabado y ZeuS y variantes siguen dominando el panorama, aunque con las diferentes familias de troyanos bancarios que han ido apareciendo, y sobre todo, el leak del código de Carberp, habrá que ver cómo evoluciona todo en los próximos meses.

Advanced Cyber Security Services
S21sec

(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login