Español | English
rss facebook linkedin Twitter

¿Nuevos troyanos bancarios en el horizonte? (II)

Como complemento a la información publicada de nuevo por investigadores de Trusteer haciendo referencia a una nueva variante de ZeuS, desde S21sec nos gustaría señalar  que esta botnet lleva activa al menos desde diciembre de 2013 y no presenta ningún comportamiento que no hubiéramos observado con anterioridad.

De hecho, se trata de una versión ligeramente modificada de ZeuS, que ha incorporado además características presentes en otras variantes, como es el caso de la Máquina Virtual originaria de KINS o el uso de AES-128 como algoritmo de cifrado. Esto último, además, ha cambiado en las últimas versiones (numeradas como 4.6.X.X) volviendo al RC4 original de ZeuS pero usando las claves AES como semilla.

En relación con la actividad de la botnet asociada, esta ha ido decreciendo paulatinamente desde que comenzamos a monitorizarla:



En cuanto a la afectación, está muy lejos de haberse centrado en entidades Canadienses, sino que estas son en realidad de las menos afectadas siendo sus principales objetivos: EE.UU, España y Reino Unido:


Por lo tanto, podemos concluir que nos encontramos ante una de las muchas variantes de ZeuS que hemos podido analizar.

Para terminar algunos hashes de dos de las variantes distribuidas por esta botnet:
  • 0179c28d71902967b1ba46d3c5b10840 v4.6.2.0
  • 5b6568992e08028aff46fb6bf8e7519d v3.3.2.0

Departamento de Ecrime
S21sec

¿Nuevos troyanos bancarios en el horizonte? (I)

Hoy hemos visto bastante repercusión en una noticia publicada por IBM acerca del descubrimiento de un nuevo troyano bancario. En la noticia que recoge IBM se indica que investigadores de Trusteer han identificado una nueva pieza de malware que comparte muchas de las características de funcionamiento tanto con Zeus como con Carberp.

Ante la previsión de una nueva amenaza hemos analizado la información que se ha publicado, y nada parece indicar que estemos ante una nueva amenaza. Todo apunta a que se trata de una variante del troyano Kins, ya observada por s21sec desde hace algún tiempo.

Al respecto, durante 2014 la actividad de los principales troyanos bancarios que hemos observado es la siguiente:


Kins ha pasado a ser la principal amenaza para entidades financieras, mientras que Citadel, que durante 2012 y 2013 fue el troyano bancario más activo, ha perdido buena parte del dominio ejercido anteriormente. Estos comportamientos son cíclicos, así que a buen seguro veremos nuevos troyanos bancarios en el futuro, pero de momento no se observan datos suficientemente reseñables como para hacer referencia a ello. Por supuesto, en cuanto tengamos oportunidad lo compartiremos con vosotros.


Departamento de Ecrime

S21sec


NeoPocket: Un nuevo malware para cajeros automáticos

A finales de septiembre de 2013 se detectó una nueva familia de malware conocida como Ploutus enfocada al control y acceso a cajeros electrónicos de una marca de cajeros situados en México. Desde entonces la amenaza se ha extendido a otros países y ha evolucionado a nuevas variantes del mismo.

Recientemente se nos solicitó que investigáramos un ataque similar; en donde posiblemente se había usado malware para vaciar varios cajeros automáticos. Esperábamos que fuera Ploutus, sin embargo observamos varias incongruencias. Primero, todos los cajeros afectados pertenecían a un modelo diferente de los afectados por Ploutus. Segundo, respecto a la muestra de malware que obtuvimos, no presentaba similitudes a nivel del binario cuando la comparábamos con Ploutus, es más la muestra no había sido desarrollado ni siquiera en la misma plataforma que Ploutus.

Después de realizar algunas indagaciones llegamos a una conclusión: estábamos tratando con algo completamente nuevo, un malware sin clasificar y desconocido para el público. Decidimos referirnos internamente a él como NeoPocket debido a una cadena de caracteres que observamos en el binario. En las siguientes líneas intentaremos arrojar alguna luz sobre los engranajes de esta nueva amenaza.

Activación e instalación

NeoPocket está escrito en Visual Basic y la instalación parece que es realizada a través de un dispositivo USB, por lo que se requiere acceso físico al sistema instalado en el ATM; y solo se instala si detecta que está situado en la raíz de cualquier unidad.

Una vez se conecta, ejecutan el binario con nombre CSS1.exe el cual presenta la siguiente ventana:


que espera la introducción de un código de instalación que se genera en base a la fecha:


Si se introduce correctamente, busca las siguientes carpetas:


Si encuentra cualquiera de ellas junto con los ficheros css.ini y devices.ini, se copia a sí mismo en ese directorio; y crea, inicialmente, los siguientes ficheros:
  • Casas.txt
  • devices2.ini
  • devicex.ini
  • borrar.exe
También creará una clave en el registro para sobrevivir al reinicio, modificando la configuración del cliente de la siguiente manera:


Al finalizar, mostrará el siguiente mensaje y terminará la instalación:


Quedándose a la escucha en la forma descrita en el siguiente punto.

Así mismo, para asegurarse el acceso automático a la unidad, monitoriza la clave de registro \SYSTEM\CurrentControlSet\Services\USBSTOR\, cambiando el valor de Start a 3 si ha sido modificado a cualquier otro, en un intento de impedir la lectura automática.

Captura de información

Una de las funcionalidades principales del malware motivo de análisis parece ser la captura de la información que maneja el cajero. Para ello se queda a la espera hasta que detecta una petición de datos con los siguientes títulos:
  • Escriba la clave ‘A’
  • Escriba la clave ‘B’
  • Enter the key ‘A’
  • Enter the key ‘B’
En ese momento captura las credenciales y datos de transacciones que almacena en nuevos ficheros con nombres casaA1.txt o casaB1.txt (Donde los números son secuenciales) respectivamente.

Además se queda a la escucha en el puerto 6000:


que junto con el cambio en la configuración del software le permitiría realizar un ataque de tipo Man in the Middle.


Por lo tanto, toda la información que se transmite a dicho puerto, es almacenada en el fichero Casas.txt creado durante la instalación.

Como resumen de lo visto hasta ahora, se muestran todos los ficheros usados por el malware para la captura de información y gestión del mismo:


Interacción y control

La forma de interacción con el binario malicioso es a través del socket raw a la escucha descrito en el punto anterior, que por defecto almacena toda la información de las transacciones y la que se introduce por teclado y/o pantalla.

Entre la información que le llega, busca una serie de patrones que actuarán a modo de comando para obtener información y realizar diferentes acciones:


Finalmente, el resto del control es realizado a través del propio dispositivo USB.

De esta forma, le basta con crear unos ficheros con un nombre específico en la raíz de la unidad, ya que al detectarlos ejecutará una serie de acciones predeterminadas. Los “comandos” serían los siguientes:


Recomendaciones
  • Bastionar físicamente el ATM en su totalidad y no exclusivamente la caja de seguridad del dinero, de modo que sobre todo se impida acceder a los puertos de conexión del sistema informático. Asi mismo, hacer comprobaciones periódicamente de la integridad de los ATMs, en especial tras cada ocasión en los que se lleven a cabo operaciones rutinarias o extraordinarias de mantenimiento de los cajeros.
  • Contemplar el uso de medidas adicionales de seguridad como CCTV.
  • Desactivar en la BIOS las unidades de USB y CD-ROM y proteger el acceso a esta mediante password.
  • Cifrar el disco para impedir que sea manipulado.
  • Planificar y migrar a versiones superiores de Windows los cajeros automáticos donde exista un Windows XP que haya sido instalado físicamente o de forma virtual, dado que el soporte de Windows XP ha llegado a su fin. Como alternativa pudiera procederse a la sustitución del sistema operativo Windows XP por sistemas operativos distintos. Esta recomendación aplica a todas las versiones de Windows XP y al Windows XP Professional for Embedded Systems. Sin embargo, se ha de tomar en cuenta, no obstante, que en el caso de ATMs que cuenten con instalaciones de Windows XP Embedded (Toolkit and Runtime), en cualquiera de sus versiones, el soporte se extiende hasta el 12 de enero de 2016.
  • Usar sistemas integrales de protección a tiempo real como el que ofrece Lookwise Device Manager para ATMs.

Sample MD5:  1a6a240d2d03eb2c66c17a6593d4b6d2

Jozsef Gegeny y Santiago Vicente

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



(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login