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 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.
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. |
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:
Detectando el malware en Koodous
- 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:
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.
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
No hay comentarios:
Publicar un comentario