En diciembre del año pasado, la compañía FireEye lanzó un informeacerca 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 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 a 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:
- Un usuario es infectado por el malware e introduce sus credenciales bancarias.
- El atacante recibe las credenciales y decide realizar una transacción fraudulenta hacia, habitualmente, un mulero.
- El atacante activa la intercepción de SMSs enviado el comando #intercept_sms_start al dispositivo.
- Además, podría bloquear la pantalla del móvil utilizando el comando #lock
- El atacante realiza la transacción y recibe el SMS de doble autenticación del banco del usuario, pudiendo finalizar la misma.
- 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:
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.
Más información:
Koodous – SlemBunk ruleset
FireEye – SlemBunk: An evolving Android trojan family targeting users of worldwide banking apps
FireEye – SlemBunk Part II: Prolonged attack chain and better-organized campaign
Antifraude Hispasec
Antonio Sánchez
Deja un comentario