SlemBunk también ataca a bancos españoles

En diciembre del año pasado, la compañía FireEye lanzó un informe acerca
de la familia SlemBunk. Este malware para Android se considera un
troyano bancario, aunque también afecta a empresas como Amazon, Ebay,
WhatsApp o Facebook y además tiene funcionalidades que lo caracterizan
como RAT (Herramienta de administración remota).

Dentro del departamento antifraude de Hispasec, una de las acciones que
realizamos diariamente es el análisis y monitorización de malware que
afecta a los clientes de las entidades bancarias suscriptoras de
nuestros servicios. Si bien una familia generalista puede no contener
funcionalidad concreta que afecte a un objetivo en particular, esta se
vigila de cerca ya que tarde o temprano surgirá alguna variante que lo
haga.

Después de este informe decidimos bucear en Koodous
(http://www.koodous.com/) para dar con muestras que tuvieran este
comportamiento y poder sacar algunas conclusiones. En lo que respecta al
malware en general, cuando hablamos de una familia, resulta interesante
comprobar las variaciones sobre un cuerpo característico de funciones
y las diferencias de comportamiento entre ejemplares. Disponer de un
repositorio de muestras permite obtener, con reglas sencillas, todo
un conjunto de ejemplares a estudiar con los que podemos trazar la
evolución de cualquier malware.

Una herramienta indispensable para el analista sino queremos detenernos
en el simple análisis individual y queremos obtener una visión en
conjunto o panorámica.

Aunque los diferentes analistas que han estudiado la muestra les han
proporcionado diferentes nombres como GM Bot, SlemBunk, Acecard, slempo,
etc., todos ellos comparten la misma funcionalidad y esquema. Por tanto,
cuando hablamos de SlemBunk, podemos asociar varios nombres con la misma
denominación.

Hasta ahora, SlemBunk, había ignorado los bancos españoles. Sin embargo,
en estas últimas semanas ha experimentado un repunte considerable a la
par de poner en su punto de mira a varias firmas españolas.

En esta entrada nos gustaría explicar cómo ha evolucionado en cuanto a
las entidades a las que afecta y para los más técnicos, algunos de los
entresijos del comportamiento del malware.

Entidades afectadas

Cuando FireEye presentó su informe a mediados de diciembre de 2015 dijo
que afectaba a 33 entidades de América del norte, Europa y Asia del
pacífico. Desde Hispasec hemos podido concretar sus movimientos dentro
del continente europeo.

Comenzó, como bien dijo FireEye, afectando a Norte América, centro de
Europa (principalmente entidades alemanas y polacas) y Asia-Pacífico
(focalizándose en Australia).

Después de esto, dentro de Europa se ha movido de una forma diferente.
Cuando en Norteamérica y Asia apenas ha habido movimiento de entidades,
en Europa comenzó a afectar a entidades germanas, francesas y británicas
e incluso redes sociales y de servicios de comunicación como WhatsApp y
Facebook.

En las siguientes capturas mostramos cómo afecta a las entidades BBVA,
Santander y Ruralvía. En el momento de redactar esta noticia siguen en
activo desde hace varias semanas:

Captura del troyano atacando BBVA España

Captura del troyano atacando Santander España

Troyano suplantando a la entidad RuralVía.

Aunque en el caso de BBVA el malware no mimetiza correctamente el
WebView con la aplicación oficial, vemos como en los casos de Santander
y Ruralvía la técnica es más depurada. Todo depende del tiempo que el
atacante haya dedicado a estudiar las aplicaciones de los bancos.
Análisis dinámico

A continuación vamos a realizar un pequeño análisis dinámico visual de
la aplicación, esto es, qué hace de vista al usuario.

Según las diferentes fuentes, uno de los métodos utilizados para invitar
al usuario a descargar la muestra es a través del reproductor de Flash.
Un usuario comenzaba a navegar con su dispositivo por diferentes páginas
y en algunas de ellas se le invitaba a descargar la actualización de
Flash para poder visualizar vídeos. Justo después comenzaba la descarga
del archivo APK con nombres como “Flash_Player_Update.apk” o
“Flash_2016.apk”.

Tras instalarla, el usuario procederá a ejecutarla y es cuando la
aplicación solicita permisos de administración:

Icono de la aplicación y solicitud de administración

El icono desaparecerá de la lista de iconos de aplicaciones y si
intentamos desinstalarla no nos será posible:

Detalles de la aplicación. No permite desinstalación.
Análisis estático

A continuación un análisis detallado del código, empezando por las
actividades que nos facilita Koodous:

En primer lugar la actividad principal. En este caso ejecuta el servicio
“MainService” si no está ya en ejecución y si el dispositivo no es ruso.

 

Código de la actividad principal

Siguiendo el flujo, vamos a ver qué hace la clase “MainService”

Código método “onCreate” del servicio MainService

Si observamos el código vemos que al crearse el servicio ejecuta varios
temporizadores.
* El primero de ellos es para enviar los datos de inicialización
“Sender.sendInitialData” cada 60 segundos.
* El segundo trata de situar el WebView de la aplicación correspondiente
(si es que la tiene en el archivo de configuración). Esto se comprueba
cada 4 segundos.
* Finalmente, cada 100 milisegundos se comprueba si la aplicación sigue
manteniendo los permisos de administración que se le otorgaron al
inicio.

Ahora vamos a ver cómo afecta a las distintas entidades, según el
archivo de configuración que crea el malware en el momento de su
ejecución:

Este archivo se utiliza para varias cosas. En primer lugar el atributo
“APP_ID” se utiliza para comunicarse con el servidor. Este ID se obtiene
de forma remota haciendo una petición POST en la que se sirven los
siguientes datos del dispositivo:
* Versión de Android
* Modelo del teléfono
* Número de teléfono
* Listado de aplicaciones instaladas
* IMEI del dispositivo
* Número de cliente (parece que siempre es 1)
* Tipo de petición
* Número de operador de la tarjeta SIM
* País del dispositivo.

Tras enviar esta información se recibe el APP_ID que se utilizará
posteriormente para realizar comunicaciones con el servidor.

Otra de las peticiones que realiza es para descargar la lista de
aplicaciones afectadas y el código que se debe inyectar. Cuando recibe
la lista la guardar dentro del archivo anterior bajo el atributo
“HTML_DATA”. En el anterior ejemplo la inyección de código afectaría al
banco australiano NAB (http://www.nab.com.au/).

El malware, además de presentar WebViews para las aplicaciones que tiene
configuradas, también se comporta como un RAT (Herramienta de
administración remota).
La siguiente captura de código muestra algunas de las opciones que el
malware es capaz de realizar:

Algunas de las acciones que realiza el malware como RAT

Estas acciones las recibiría el usuario a través de SMSs. En un
hipotético caso, el atacante actuaría de la siguiente manera:

1. Un usuario es infectado por el malware e introduce sus credenciales
bancarias.
2. El atacante recibe las credenciales y decide realizar una transacción
fraudulenta hacia, habitualmente, un mulero.
3. El atacante activa la intercepción de SMSs enviado el comando
#intercept_sms_start al dispositivo.
4. Además, podría bloquear la pantalla del móvil utilizando el comando
#lock
5. El atacante realiza la transacción y recibe el SMS de doble
autenticación del banco del usuario, pudiendo finalizar la misma.
6. El atacante vuelve a desbloquear el móvil y desactiva la intercepción
de mensajes con los comandos #unlock y #intercept_sms_stop
respectivamente.
Detectando el malware en Koodous

Después de estudiar esta familia, es hora de crear una regla que detecte
nuevos ejemplares de la misma. Como ya es habitual hemos utilizado
Koodous para crear la siguiente regla Yara:

Regla Yara para detectar SlemBunk

Como vemos la regla es muy sencilla, busca algunos de los comandos que
el malware tiene en su código y que utiliza para hacer sus funciones de
RAT. Además de esto incluye “Visa Electron” ya que también lo contiene
el malware y evitamos falsos positivos en caso de que otra aplicación
legítima utilizase los mismos comandos, aunque sería una cosa extraña.

Todas las muestras detectadas tienen el mismo nombre de paquete, también
se podría simplificar la regla utilizando nuestro módulo de androguard y
utilizando simplemente la condición:
androguard.package_name(“org.slempo.service”)

La regla con sus detecciones es pública en Koodous:
https://analyst.koodous.com/rulesets/1137

Conclusiones

Con esta entrada nos gustaría concienciar a nuestros lectores. En muchas
ocasiones cuando se habla de malware y de familias todo queda muy lejano
y parece que “nunca nos llega”, cuando en realidad ya lo tenemos aquí.

Esta familia ha sido y es muy activa a nivel mundial. No nos extrañaría
que “mutase” para perfeccionar aún más sus técnicas de mimetización y
ocultación.

Los desarrolladores no han utilizado ninguna técnica de ofuscación de
código, las capturas mostradas anteriormente son totalmente fidedignas.

Si algún usuario se encuentra infectado por este tipo de malware,
recomendamos reiniciar el teléfono a la configuración de fábrica, ya que
puede ser la única forma factible de eliminarlo definitivamente.

Koodous también dispone de una aplicación Android con capacidad de
detección de malware cuando instalas una aplicación. Tanto si solo eres
un usuario que necesita un antivirus ligero o eres analista y quieres
colaborar con el proyecto, échale un vistazo.

Ver informacion original al respecto en Fuente:
http://unaaldia.hispasec.com/2016/02/slembunk-tambien-ataca-bancos-espanoles.html