martes, 16 de febrero de 2016

FakeApps: Cómo ‘monetizar’ malware de Android de la A a la Z

Cuando realizamos análisis de aplicaciones en Koodous es habitual que se reciban diferentes alertas por una misma muestra, ya que además de la actividad maliciosa principal, como puede ser registro de mensajes SMS o cualquier variante de troyano, se añaden una o varias muestras de Adware en la misma aplicación.

Este "modus operandi", bastante extendido, trata de monetizar al máximo la actividad fraudulenta de la aplicación desarrollada, aunque para desgracia del desarrollador, sólo consigue ser detectada con mayor facilidad.

Si cogemos el ejemplo de un malware clasificado como SMSreg, si ya su principal función es el envío y suscripción de SMS de pago, que incrementará el balance de la cuenta del atacante, a su vez se monetiza la actividad de la misma mediante la inclusión de publicidad o Adware que muestra anuncios en el terminal y que suponen un plus extra para el atacante. Incluso se puede ir más allá como en el caso de las FakeApps (falsas aplicaciones) que a través de un WebView (navegador interno de Android) puede redirigir al incauto usuario a diferentes campañas de publicidad que posiblemente le conminen a instalar nuevas aplicaciones fraudulentas.

Resumiendo, el atacante genera dinero por la funcionalidad principal de la APP (envío/suscripción de SMS premium, robo de credenciales o perfiles y posterior venta, creación de zombies para una botnet, etc.) y también a través de publicidad en el propio terminal o tras direccionar al usuario a nuevas campañas de publicidad.

Técnicamente, para apoyar toda esta infraestructura de monetización se requiere generalmente de varios dominios y cuentas creadas ex profeso para la publicitación de la aplicación, siendo el método de distribución más elegido la subida a markets gratuitos como son APKfiles, aptoide o similares, como podemos ver en este primer ejemplo de FakeApp todavía descargable (en el momento de publicación):
Si no estuviera disponible se puede descargar, si se desea, desde Koodous para su análisis:

Vamos a proceder a analizar en Koodous una FakeApp como la siguiente:

Este tipo de FakeApps generalmente contiene diferentes módulos de anuncios no maliciosos, como pueden ser GoogleAds o Count.ly, pero como comentábamos, se suele realizar la verdadera monetización mediante SDKs invasivos como Mobidash, Airpush o similares para reproducir contenido en el terminal.

En el caso del la falsa aplicación "TotalCommander", intervienen varios dominios para efectuar una redirección:

Todos estos dominios fraudulentos bajo el control del atacante sólo sirven para ir redireccionando al visitante hacia el dominio principal de anuncios controlado por un tercero, generalmente son grupos dedicado al SPAM que pagan por redireccionar visitas a sus dominios:

go2cloud.org
En función de la IP/geolocalización del visitante redireccionará de nuevo a la campaña final de anuncios fraudulentos, generalmente de suscripción de SMS:


Finalmente, y aunque no tiene que ver directamente con la propia aplicación maliciosa, otro método de monetización suele ser la inclusión de perfiles fraudulentos en comunidades sociales, como Google Plus:


Como vimos que este último dominio zzwx.ru era usado para realizar campañas de adware pasamos a monitorizarlo en Koodous para detectar posibles relaciones entre estas campañas y algunos APKs. La regla para monitorizar el dominio es simple: (https://analyst.koodous.com/rulesets/1197):

Regla para detectar el dominio

Después de activarla, esperamos unos días para ver las aplicaciones que iban siendo detectadas en la "red" de Koodous para después analizarlas. El resultado fue prometedor:


En el momento de escribir este artículo y en menos de 3 días encontramos casi 50 aplicaciones con ese dominio "hardcodeado" en su interior.

Una vez detectamos las aplicaciones, pasamos a analizarlas en profundidad. El comportamiento de todas ellas es prácticamente idéntico. Se trata de una aplicación que en el momento de su primera ejecución pide permisos de administración:

Solicita permisos de administración

Y tras esto muestra un WebView con publicidad:

Como es normal, y después de haber solicitado permisos de administración en su instalación, ya no permite desinstalarla de la manera típica por lo que nos tocaría realizar un reinicio de fábrica:
Información de la aplicación

También comprobamos que la aplicación, para obtener el contenido de este WebView, visitaba la siguiente página:

Esta es la traza de conexiones completa, que realiza el dispositivo móvil, en la que se realizan varias redirecciones y no siempre es la misma. Cada vez que se visita la página principal realiza un recorrido de redirecciones distinto.


Una vez hemos visto su comportamiento más palpable, pasamos a hacer un análisis estático a fondo para ver si realizan alguna acción que pase más desapercibida.

Empezamos mirando en Koodous los servicios que, según el AndroidManifest, la aplicación es capaz de ejecutar:

Analizando el código vemos que ninguna de las dos clases existe en el manifiesto, por lo que esos servicios nunca serán ejecutados.
Con los receptores (Receivers) parece que tenemos algo más de suerte, según el análisis de Koodous son los siguientes:

En cuanto al primero de ellos, invoca a la clase padre para que gestione correctamente el acceso a la administración del dispositivo:

El segundo receptor, según el código, intenta invocar el método "OnReceive" de la clase "com.mobileapptracker.Tracker". Sin embargo, esa clase no existe en el código de la aplicación, por lo que es imposible la ejecución. Este segundo receptor se iniciaba tras las instalación de una aplicación a través de GooglePlay según el AndroidManifest:

Finalmente con el tercer receptor (com.robotemplates.webviewapp.activity.SearchHelper) tampoco hay suerte. No hay ninguna clase que se pueda llamar por ese nombre.

Tras finalizar el análisis de esta aplicación quisimos buscar las coincidencias entre los distintos APKs y obtuvimos algunas conclusiones.

Entre todas las aplicaciones se comparten solamente 3 archivos “classes.dex” distintos. El archivo "classes.dex" es el código Java compilado para Dalvik (la máquina virtual interna de Android).
Las URLs a las que conecta cada APK se encuentran en el archivo de recursos, más concretamente en el archivo ‘arrays.xml’:
Porción de código XML de la aplicación

Este valor sí es diferente entre los distintos APKs y normalmente, aunque no en todos los casos, coincide que el parámetro de la URL es el nombre de la aplicación, en este caso "Talking George The Giraffe".

Conclusiones

Esta campaña de adware se ha detectado gracias a los sensores de Hispasec con mucha antelación ya que el dominio zzwx.ru apenas tiene un mes de vida.

Relacionando las conexiones de los distintos dominios se ha creado una regla mucho más completa que la mostrada anteriormente que podéis encontrar en Koodous, mostrando todos los dominios afectados conocidos junto a las detecciones de APKs maliciosas, que siguen subiendo hora tras hora:
La distribución del malware se ha llevado a cabo a través de repositorios públicos (markets) tales como apkfiles y aptoide.

Las aplicaciones mencionadas se podrían considerar malware casi con total seguridad ya que además de mostrar publicidad no realizan acción alguna, las casas antivirus no lo tienen tan claro y hay diversidad de opiniones. Por ejemplo, esta muestra
https://analyst.koodous.com/apks/639d50fcd53a9e3033d6eb18b1bff6b4aa6a35e9303ce9e01df0b101b12e9e00 sólo es detectada por 6 motores antivirus en VirusTotal en el momento de esta publicación.



Se ha podido ver cómo los atacantes reutilizan muchas porciones de código en las aplicaciones fraudulentas. Por su parte lo hacen para gastar menos tiempo en crear las aplicaciones y poder llegar a más público, pero por nuestro lado (los analistas), esto nos puede ayudar a detectarlos rápidamente y en las ocasiones que se cometa un fraude poder frenarlo a tiempo.

Más información:

Koodous - Ruleset “Russian domain”

Koodous - Talking George The Giraffe

Koodous - Ruleset “FakeApps”

VirusTotal - Análisis
639d50fcd53a9e3033d6eb18b1bff6b4aa6a35e9303ce9e01df0b101b12e9e00



José Mesa
Antonio Sánchez

2 comentarios:

  1. Espero que quien corresponda se haya dado cuenta de que en la regla 1162 han repetido un nombre de variable (en lugar de $6 han repetido $5).

    ResponderEliminar
  2. Está corregido ya. Tened en cuenta que las reglas en Koodous se salvan automáticamente, así que estáis viendo todos lo cambios casi en tiempo real. Acababa de añadir un nuevo dominio ;)

    ResponderEliminar