Español | English
rss facebook linkedin Twitter

Nueva variante de Feodo sigue los pasos de Geodo

La actividad de Cridex (aka Feodo/Bugat) y sus variantes alcanzó su máximo exponente a finales del año pasado y principios de este, desapareciendo poco después hasta la reaparición en Junio de una nueva evolución conocida como Geodo identificada por los chicos de abuse.ch.



Esta misma semana, el departamento de Ecrime de S21sec se ha topado con lo que parece ser una nueva evolución, diferente a Geodo, de alguna de las antiguas variantes con nuevas e interesantes características.

En primer lugar, emplea un loader con funcionalidad limitada como primer punto de infección para descargarse a posteriori el módulo principal del troyano en forma de DLL, instalándose en las siguientes rutas e inyectándose en explorer.exe como habitualmente:



Dicha comunicación se realiza a través del ya característico puerto 8080 a un path algo diferente a lo visto en otras ocasiones:


Posteriormente se descargará el fichero de configuración comprimido en formato gzip pero con un header falso:



El fichero de configuración está en en formato XML y en él se incluye información estructurada de la siguiente forma:
  • modules: Descarga de nuevos módulos en Base64, que a su vez pueden ser:
    • vnc_x32
    • vnc_x64
    • socks_x32
    • socks_x64
    • bot_x32
    • bot_x64
  • httpshots y clickshots: Capturas de pantalla
  • formgrabber: Form Grabbing
  • bconnect: Servidor Back Connect
  • vncconnect: Servidor VNC
  • redirects: Referencias a recursos externos usados en las inyecciones
  • httpinjects: Entidades afectadas y sus inyecciones

A día de hoy, las entidades reflejadas en el fichero de configuración son principalmente de Reino Unido, Irlanda, Emiratos Árabes Unidos y Qatar, con algunas de las inyecciones orientadas a saltarse el segundo factor de autenticación y ser usadas en conjunto con el módulo VNC para poder así suplantar a la víctima dentro de su misma sesión en la banca electrónica.

Por lo tanto parece que después de unos meses de silencio en el mundo Cridex, al reconvertido en Geodo se le une uno de sus antiguos compañeros de viaje, maquillado para la ocasión.


Santiago Vicente
S21sec Ecrime
@S21sec@smvicente

--
Las firmas MD5 de los ficheros analizados por S21sec en el análisis han sido:
  • loader: 9d81ac7604ef2a0096537396a4a91193
  • bot_x32: 04b55edf43a006f9c531287161fa2fa8
  • vnc_x32: c73c3c18b74c67e88d5b3f4658016dcd
Otros posibles hashes para el resto de módulos son:
  • vnc_x64: 5ecfc1d3274845bf5ff3f66ca255945e
  • socks_x32: 53eb0e59b5bb574df5755527dc3d4f47
  • socks_x64: 0dfc66eadbd9e88b2262ac848eadee8f
  • bot_x64: 4df1cef98bbc174ba02f17d2ca6c0a58

Los primeros pasos del nuevo GOZ

Desde el inicio de la operación Tovar contra el conocido troyano bancario Murofet/Gameover/ZeusP2P la actividad en la botnet ha dejado de crecer y parece prácticamente abandonada desde entonces. En vez de intentar recuperar el control de la misma, parece que los botmasters (o nuevos) han optado por empezar de cero creando una nueva botnet con una nueva versión del troyano. A lo largo del post se analizarán las principales novedades al respecto.

Comunicación:

  • Se ha prescindido del Peer-to-peer (P2P) en favor de una red de tipo Fast-Flux con un nuevo algoritmo de generación de dominios (DGA).
  • La clave pública incluida en el mismo (XOReada en la misma forma que antes), ha pasado de ser usada para verificar la firma de aquellos recursos distribuidos por la red P2P, a formar parte de un sistema de comunicación clásico de clave simétrica+asimétrica en el que el payload se cifra con un algoritmo simétrico mientras que la clave generada aleatoriamente se cifra con dicha clave pública para ser enviado todo ello al panel de control en una forma similar a la ya usada, por ejemplo, en Cryptolocker (relacionado con Murofet) o Cridex/Bugat/Feodo/Geodo.
De esta forma, teniendo en cuenta que el DGA se basa en una semilla hardcodeada, bastaría cambiar la misma junto con la clave pública incorporada en el binario, para tener una nueva botnet.



Cifrado:

Mientras que el cifrado se mantiene idéntico en algunos aspectos, en otros ha sufrido modificaciones debido principalmente al nuevo sistema de comunicación anteriormente descrito. Por lo tanto nos encontramos con que:
  • Se mantiene RC4 para aquellos datos de configuración almacenados en el registro del sistema.
  • La comunicación con el panel de control, así como todo dato recibido por su parte pasaría a usar AES256+RSA.



Configuración:

La configuración por su parte no ha sufrido apenas cambios. De hecho gran parte de las inyecciones y afectaciones son antiguas, e incluso aparecen variables que usan funcionalidades no presentes ya en la actual versión, como aquella relacionada con el Proxy P2P:




Por lo tanto parece que nos encontramos con una especie de involución de Murofet, que incluso nos recuerda a Licat, su predecesor. Esto no lo hace menos interesante ya que, aunque lo visto en los ficheros de configuración podrían indicar una cierta prisa en su lanzamiento, otras nuevas características como la semilla del DGA pueden convertirlo en un reto para quienes pretendemos acabar con él, una vez más.



Santiago Vicente

¿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


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login