Análisis del malware para Android GodFather

Siempre me ha fascinado el análisis de malware. Es un ejercicio que demuestra no solo el ingenio de los hackers para eludir los mecanismos de defensa del sistema operativo y de las aplicaciones, sino también para engañar al usuario y robarle datos críticos.

Para analizar malware hace falta una buena taza de café, un agudo sentido analítico y las herramientas de ingeniería inversa adecuadas para descifrar los enigmas de la aplicación.

Este artículo analizará el malware GodFather, que sigue apareciendo en distintos formatos y se dirige principalmente a aplicaciones bancarias y de criptomonedas.

Cuando ejecutamos el malware GodFather en el dispositivo, lleva a cabo acciones maliciosas, como transferir dinero y recopilar información del dispositivo, por ejemplo el número de teléfono, la lista de aplicaciones instaladas y los datos de la batería. Además, aprovechando los permisos concedidos en el dispositivo infectado, el malware puede interceptar mensajes SMS, manipular la pantalla del dispositivo mediante VNC, redirigir llamadas telefónicas y abrir URL sin que el usuario lo sepa.

El análisis utilizará principalmente la plataforma Ostorlab, ya que nos permitirá:

• Obtener el código fuente y el ensamblador del APK.
• Convertir el Manifest y los recursos a un formato de texto legible.
• Obtener el ensamblador del código nativo (los archivos .so de la aplicación).
• Obtener el árbol de llamadas de las funciones, añadiendo etiquetas a las funciones según sus características y su riesgo.
• Interceptar el tráfico saliente de la aplicación.

Puede acceder a los resultados y al entorno de análisis del escaneo a través del enlace.

Primeros hallazgos:

Al escanear la aplicación en la plataforma, lo primero que se observa es el icono de la aplicación, que es el mismo que el icono de los ajustes de Android:

En la sección de resumen, vemos que la aplicación solicita 22 permisos, entre ellos 8 permisos peligrosos:

• android.permission.RECORD_AUDIO
• android.permission.SEND_SMS
• android.permission.READ_CONTACTS
• android.permission.READ_SMS
• android.permission.READ_PHONE_STATE
• android.permission.RECEIVE_SMS
• android.permission.WRITE_EXTERNAL_STORAGE
• android.permission.CALL_PHONE
• android.permission.DISABLE_KEYGUARD

La aplicación exporta dos elementos (un servicio y un receptor de difusión) para interactuar con los SMS.

Un vistazo rápido al hallazgo muestra que la aplicación comprueba si se ejecuta en un dispositivo con root. Está en modo de depuración y no implementa ningún ajuste de configuración de red.

Además, el escáner informa de dos hallazgos de severidad media relacionados con problemas criptográficos:

• Uso de una clave codificada de forma rígida:
• Uso de un vector de inicialización (IV) no aleatorio

En el rastreo de taint vemos que el cifrado se utiliza para cifrar los datos al enviar los SMS, los registros de pulsaciones de teclas y los registros del dispositivo.

Uso del entorno de análisis:

Utilizamos el entorno de análisis de Ostorlab para navegar por la aplicación y comprender fácilmente su comportamiento. El primer archivo que revisaremos es AndroidManifest, y buscaremos la actividad principal de la aplicación:

El nombre de la actividad principal es com.rduzmauwns.jieliysagr.aJtzcrQbcpuSYfz.

Por tanto, usaremos la sección estática para analizar su código fuente:

En el método OnCreate hay una serie de comprobaciones antes de iniciar el comportamiento malicioso.

• La primera comprobación se refiere al código de país o región del dispositivo. El malware no se ejecuta si el dispositivo es de Rusia o Tayikistán.

• La segunda comprobación se refiere al contexto de ejecución. El malware no se ejecuta si no lo hace en un dispositivo real.

Siempre me gusta ver cómo la aplicación comprueba si se trata de un dispositivo real, ya que existen múltiples scripts y formas de eludir esas comprobaciones.

Usamos la pestaña call stack y buscamos isEmulator para ver las últimas comprobaciones realizadas:

En este caso, se comprueban los parámetros integrados del dispositivo en busca de valores conocidos como «generic», «Emulator», «Genymotion», etc.

Una vez que el malware se inicia, desactiva su icono y se ejecuta en segundo plano.

Para ello, la aplicación utiliza el método setComponentEnabledSettings con los parámetros 2, 1.

¡En esta fase, la aplicación de malware se está ejecutando en segundo plano!

Estoy listo. ¡Comencemos!

El malware inicia un nuevo servicio llamado com.rduzmauwns.jieliysagr.vCdmvEHqFNkYwsB.

El servicio implementa la interfaz java.lang.Runnable y su código se ejecutará en un hilo independiente.

En este hilo se inicia uno de los métodos de espionaje, SendNewUser.

Este método obtiene los detalles del dispositivo de la víctima y los envía al servidor.

El malware puede transferir dinero realizando llamadas USSD (Unstructured Supplementary Service Data). Para quienes no sepan qué es USSD, se trata de un protocolo de comunicación que utilizan los teléfonos celulares GSM para comunicarse con los equipos del proveedor de servicios. Permite a los usuarios acceder a diversos servicios, como consultar el saldo de su cuenta, recargar saldo, transferir fondos y suscribirse a distintos servicios, entre otros.

Lo curioso (o no) es que el malware realiza la llamada sin utilizar la interfaz de usuario del marcador.

El malware también:

• Utiliza el método SmsSender() para enviar SMS de texto de varias partes,
• Roba los SMS presentes en el dispositivo de la víctima.
• Utiliza el método callForward(), que reenvía las llamadas entrantes de la víctima a un número proporcionado por el servidor.
• El método linkopen() proporciona al malware la funcionalidad de abrir URL en el navegador del dispositivo sin la intervención del usuario
• Roba los registros de la aplicación.
• Utiliza VNC Viewer para ver y controlar de forma remota las pantallas de un dispositivo infectado

Superficie de ataque:

Los endpoints para enviar los datos y recibir los comandos no están definidos directamente en el malware. Los recibe de un canal de Telegram, con una dirección de endpoint cifrada en la descripción. (El que utiliza el modo ECB y que el escáner señaló antes).

El malware tiene tres endpoints principales:

• henkormerise.com
• banerrokutepera.com
• heikenmorgan.com

Conclusión

Con el paso del tiempo, el riesgo de las amenazas bancarias va en aumento y estas son cada vez más sofisticadas. El malware GodFather es un claro ejemplo de ello. Esta versión concreta del malware contiene capacidades maliciosas que le permiten recopilar datos sensibles.

En conclusión, el análisis de malware es un ejercicio fascinante que exige atención al detalle. El malware GodFather es solo un ejemplo de las amenazas en evolución a las que se enfrentan los sectores bancario y de criptomonedas. Al comprender cómo funciona este malware y el alcance del daño que puede causar, podemos proteger mejor nuestros dispositivos y a nosotros mismos frente a este tipo de ataques.