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.
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
