CONOCIMIENTO pertenece al mundo
Mis amigos en CyberBlog decidieron analizar el GM Bot malware para Android como el ejercicio con el objetivo de recibir sugerencias de arena de retroalimentación de la comunidad de seguridad.
La muestra explorado se confirma como una variante del malware GM Bot Android - quién es la fuente fue lanzado públicamente a principios de 2016. El código parece haberse bifurcado por un segundo autor y tiene adiciones que se dirigen a la aplicación de Danske Bank MobilePay y el popular danesa Nem Identificación autenticación de dos factores del sistema (2FA).
En este artículo se muestra el proceso de caminar a través del análisis estático y dinámico para desbloquear el código fuente para llevar para el malware.
Vemos cómo incluso con el análisis estático de base una imagen completa de la intención del malware puede montar fácilmente, y con un poco de depuración podemos llegar rápidamente al código fuente legible.
FONDO
Como parte de mi viaje a la Seguridad Cibernética pensé que sería interesante ver cómo funciona el malware móvil moderna. Elegí el siguiente ejemplo al azar basado en un artículo aquí.
DETALLES DEL ARCHIVO
SHA256: 44ed4bbd5cdc13c28992c16e99a7dc58f5f95463e889dd494a433549754f7863 MD5: da88bdcb3d53d3ce7ab9f81d15be8497
Una rápida búsqueda en Google para estos hashes le llevará al archivo usado si también le gustaría explorar esta muestra.
El artículo anterior demuestra que el analista ha pasado de la muestra de código fuente, pero no está claro cómo se logra esto. Hay referencias que sugieren que el código está preparada, pero de nuevo no hay información sobre la forma en que se ha desempaquetado para su análisis.
Este post va a romper el proceso que utiliza para analizar esta muestra, espero que con suficiente detalle para ofrecer algunos consejos y orientación para otros que desean intento similar. El proceso Seguí se puede dividir lógicamente en las siguientes etapas:
- Análisis pública - ¿Qué podemos encontrar a cabo utilizando fuentes públicas existentes de información? Lo que el análisis ha sido ya realizada (automático o manual)?
- Análisis estático - ¿Qué podemos determinar a partir de la muestra sin tener que ejecutarlo en un entorno emulado?
- Packer Depuración - Suponiendo que la muestra está lleno (para frustrar el análisis), ¿cómo depurar el desencajonadora para entender lo que está siendo cargado / correr?
- DEX Extracción y descompilación - Una vez que hemos trazado la función de la desencajonadora, ¿cómo nos recuperamos a continuación, el código principal para el malware y revocará?
- Análisis funcional y dinámico - una vez que hemos extraído y el código, ¿qué vemos invertido y ¿Cómo funciona esto se correlaciona con el comportamiento en un entorno emulado segura
ETAPA 1 - ANÁLISIS PÚBLICA
En primer lugar vamos a ver lo que podemos encontrar sobre esto en el dominio público. La búsqueda de los valores hash de archivo en Virus Total, donde vemos aproximadamente el 50% de los productos AV han identificado como malicioso:
Sin embargo, también observamos que todo lo clasifican de forma heurística como una cepa genérica de malware - ya sea un troyano cuentagotas, etc. falso instalador No hay nada que sugiera que es, de hecho, GM Bot Android, o cualquier tipo de malware. Aparte de esto que no vemos mucho de Google, ya sea con la SHA256 o hashes MD5.
El artículo original de inteligencia de seguridad hace referencia a la investigación de IBM X-Force, por lo que esta es la próxima parada - pero nada obvio en lo que respecta a esta muestra pudo ser localizado.
Una búsqueda más amplia de internet revela algo de la historia de GM bot, originalmente construido y vendido por Ganga Hombre en los foros de Internet oscuros. A raíz de una disputa el código fuente para ambos APK cliente y el servidor C2 fueron liberados públicamente. Una copia se encuentra alojado aquí en Github y proporcionará útil para referencias cruzadas con esta muestra más adelante en el análisis.
https://github.com/gbrindisi/malware/tree/master/android/gmbot
ETAPA 2 - ANÁLISIS ESTÁTICO
En primer lugar vamos a descomprimir el archivo APK APK usando la herramienta. Esto descomprimir el contenido, así como proporcionar un desmontaje del código de DEX en smali:
apktool d da88bdcb3d53d3ce7ab9f81d15be8497.apk
Los resultados de esto pueden verse a continuación y la herramienta también ha proporcionado una versión legible del AndroidManifest.xml archivo.
La primera parada es tomar un vistazo al archivo de manifiesto de Android, que debe proporcionar una visión general de los componentes de la aplicación y los permisos solicitados.
ANÁLISIS MANIFIESTO - ANDROIDMANIFEST.XML
El análisis inicial muestra una amplia gama de permisos que indican el comportamiento malicioso incluyendo permisos a:
- controlan todos los mensajes SMS (enviar, recibir, leer, escribir, borrar)
- la lista de aplicaciones en ejecución
- leer estado, contactos, datos de la tarjeta SD del teléfono
- solicitud para ser un administrador del dispositivo de validación de limpieza remota del dispositivo sin previo aviso al usuario
Una visión resumida de los archivos de clase se hace referencia para la aplicación principal, actividades (15) y servicios (2) se pueden ver a continuación:
Además, vemos 4 clases adicionales asignados como los receptores de radiodifusión que procesará los mensajes de eventos (Propósitos del sistema Android) como se muestra a continuación:
De esto podemos ver la aplicación es capaz de:
- La ejecución de código cuando el teléfono está encendido (a partir de la aplicación de forma automática)
- Recibir una notificación cuando se concede Administrador de dispositivos, solicitada o una solicitud para desactivar administrador se recibe (y por lo tanto, interferir, o darle la lata al usuario para que pueda)
- Recibir una notificación de un nuevo SMS entrante - con la bandera de alta prioridad para asegurar el código puede interceptarlo primera y potencialmente detener cualquier alerta (se puede utilizar para robar fichas 2FA)
Antes de proceder con cualquier ingeniería inversa del código, el siguiente paso es explorar los otros archivos en el archivo APK en busca de pistas.
ARCHIVOS DE INTERÉS
Los siguientes archivos se observaron como de interés:
ARCHIVO: ACTIVOS / FYTLUAH.DAT
Un archivo binario sin formato inmediatamente obvio. código sea posible sin cifrar / desempaquetado en tiempo de ejecución?
ARCHIVO: RES / VALORES / STRINGS.XML
cadenas de idioma inglés para la aplicación, como se muestra a continuación:
Las cuerdas indican claramente que este malware se dirige a las víctimas captura de información de la tarjeta de crédito. Es interesante observar que:
- Las claves de recursos aquí están todos en Inglés, lo que sugiere el desarrollador original puede ser de habla Inglés
- Hay cadenas específicas que se encuentran en Dinamarca, a pesar de este archivo de recursos que se destina para el idioma Inglés
- Además de las cadenas del idioma inglés también vemos varios otros países destinatarios:
ARCHIVO: RES / VALUES.XML
Este archivo contiene una lista de códigos de países y específicamente un grupo que son "no vbv". Esto se entiende en el sentido de que no utilizan el proceso de "Verified by Visa" que se utiliza para hacer cumplir los controles de verificación adicionales durante las compras en línea. Es probable que los atacantes podrían tratar de obtener credenciales adicionales VBV vía el malware con el fin de permitir que las compras en línea con los datos de la tarjeta (o evitar estos países).
DIRECTORIO: RES / DIBUJABLE
Imágenes e iconos / logotipos incluidos:
- foto de la muestra de la danesa "Nem Id" - https://en.wikipedia.org/wiki/NemID
- Icono de pago móvil Danske Bank
- Mastercard código seguro
- Icono de Verified by Visa
- Google Play
- icono del flash (icono principal de la aplicación)
Además, hay imágenes PNG con el prefijo "overlay_", lo que indica un posible uso en la actividad fraudulenta de superposición.
DESCOMPILACIÓN DE CÓDIGO FUENTE DE JAVA
A continuación se intenta alterar el diseño del archivo DEX volver al código fuente original de Java. Para ello se utilizan de la siguiente manera dex2jar para traducir el archivo DEX (en el APK) en un archivo en formato Java Class:
da88bdcb3d53d3ce7ab9f81d15be8497.apk Dex2jar
El archivo JAR resultante puede ser desmontado utilizando JD-GUI como sigue:
java-jar ../../jd-gui-1.4.0.jar da88bdcb3d53d3ce7ab9f81d15be8497_dex2jar.jar
Las clases Java resultantes que vemos en JD-GUI muestran que sólo hay 4 clases de Java contenidos en la solicitud. Esto está en contraste directo con las 16 clases diferentes que vimos declaradas en el manifiesto de aplicación. Esto confirma que debe haber código adicional que se carga dinámicamente en tiempo de ejecución - lo más probable es que estas cuatro clases son de hecho una unpacker.
Examinando el código vemos que está muy ofuscado y ha sido diseñado de una manera limpia para evitar la descompilación del código. Aparte de esto, podemos empezar a conseguir una comprensión de la función de estas cuatro clases mediante el examen de las clases del sistema que se importan (y por lo tanto se utiliza) cuando se ejecuta por primera vez la aplicación.
Después de exportar la fuente de Java de JD-GUI y descomprimir en una carpeta nueva, podemos extraer las clases importadas de estos archivos:
encontrar . type f -exec grep "^ importación" {} \; | sort -u
Las clases que encontramos se muestran a continuación:
| Clase | Clase importados |
| com.igcfse.enscbo.a | com.igcfse.enscbo.b |
| com.igcfse.enscbo.a | java.io.RandomAccessFile |
| com.igcfse.enscbo.a | java.lang.reflect.Constructor |
| com.igcfse.enscbo.b | android.app.Application |
| com.igcfse.enscbo.b | android.content.Context |
| com.igcfse.enscbo.b | com.igcfse.enscbo.a |
| com.igcfse.enscbo.b | java.io.File |
| com.igcfse.enscbo.b | java.lang.reflect.Field |
| com.igcfse.enscbo.b | java.lang.reflect.Method |
| com.igcfse.enscbo.c | android.content.Context |
| com.igcfse.enscbo.c | com.igcfse.enscbo.b |
| com.igcfse.enscbo.c | java.io.FileDescriptor |
| com.igcfse.enscbo.c | java.io.IOException |
| com.igcfse.enscbo.c | java.lang.reflect.Constructor |
| com.igcfse.enscbo.c | java.util.Random |
| com.igcfse.enscbo.wieroel | android.app.Application |
| com.igcfse.enscbo.wieroel | android.content.Context |
| com.igcfse.enscbo.wieroel | com.igcfse.enscbo.b |
Esencialmente tenemos un conjunto muy pequeño de bibliotecas que se están importando y utilizados. Estos consisten en funcionalidad para:
- aplicación y contexto general de Android clases (esperada y necesaria para todas las aplicaciones de Android)
- Clases de archivo relacionadas (en rojo ) - para el acceso, la lectura y escritura de archivos locales
- Clases de reflexión de Java (en verde ) - para la creación de nuevas clases e instancias e invocar métodos dinámicamente
Esto confirma la hipótesis de que estamos más probable ante un descompresor descomprime que es código ejecutable a partir de un recurso de archivo local (en lugar de tirar de forma dinámica desde la red, por ejemplo).
ETAPA 3 - UNPACKER DEPURACIÓN
Como el código de Java no puede ser fácilmente decompiled (debido a las protecciones inyectados por el autor de malware) en su lugar vamos a depurar el ejecutable sobre la smali código ensamblador. Smali es un desmontaje del código DEX utilizado por la máquina virtual Dalvik.
Se requiere el plugin smali / Baksmali para Android de estudio, y luego la salida de Apktool se importa como un nuevo proyecto. Nos siguiente conjunto los puntos de corte según sea necesario a través de las tres clases que nos interesa (a, b, c):
Inicialmente vamos a depurar las llamadas a métodos de reflexión interesantes identificados, que son de la siguiente manera:
a.smali (una línea que se crea una nueva instancia de una clase basada en una java.lang.reflect.Constructor ejemplo)
b.smali (una línea que llama a un método en un objeto a través de la reflexión)
c.smali (una línea similar a la descrita anteriormente para a.smali)
Ahora que instalar la aplicación en el emulador (a través de ADB para asegurarse de que no se inicia automáticamente, ya que en algunos emuladores).
Para activar el depurador para conectarse a la aplicación, se realiza lo siguiente antes de iniciar la aplicación:
- Habilitar opciones de desarrollador pulsando repetidamente el número de compilación en Ajustes> Acerca del dispositivo
- En las opciones de desarrollo, elegir la opción "Seleccionar aplicación de depuración" y elija la aplicación maliciosa - "Adobe Flash"
- En las opciones de desarrollo, permitirá a la "espera a depurador"
Ahora iniciar la aplicación desde el lanzador, se le pedirá que conecte el depurador:
En Android de estudio, conectar el depurador mediante el icono. Escoja el proceso de aplicación maliciosa. El depurador se detiene en nuestro primer punto de interrupción como se muestra a continuación:
Tenga en cuenta que ahora debe establecer algunas variables de ver - a lo anterior he puesto V0 a través v10 y P1 a P3. Nuestro primer punto de interrupción es golpeado y vemos que estamos a punto de ejecutar un método de reflexión. Tomando nota de que todavía no hemos llamado newInstance () que puede asumir esta está llamando a las clases existentes (cargados) - ya sea uno de los cuatro que carga la aplicación, o algunas otras clases de la arquitectura de Android.
A continuación fuerzas Paso en el método para ver qué método se llama (el depurador smali parece libre de errores, y no podemos ver en este punto se pasan los parámetros).
Una llamada inicial para obtener el objeto contexto actual, presumiblemente para iniciar la recuperación de los recursos locales de la APK. Ahora permitimos que el depurador continúe, y repetir este ejercicio varias veces para construir un flujo de las llamadas a métodos reflejados:
Contexto android.context.ContextWrapper.getBaseContext () // espera 2 argumentos, conseguido 1 - error en el código de software malicioso, o para deshacerse de depuración? // Varios más de éstos que no se muestra IllegalArgumentException java.lang.IllegalArgumentException (String s) nula Java.lang.reflect.setAccessible (boolean flag) Archivo android.app . getDataDir () // devuelve /data/user/0/com.kzcaxog.mgmxluwswb/app_ydtjq java.io.File . getAbsolutePath () ContextImpl android.app.getImpl (Contexto contexto) // nombre de archivo es fytluah.dat InputStream android.content.res.AssetManager . abierto (string filename)
Haciendo una pausa aquí, podemos ver el código está intentando cargar el archivo que habíamos marcado previamente como de interés en la sección de análisis estático. Continuando vemos el archivo se lee, presumiblemente descifrado y luego escribe de nuevo como un archivo jar:
int android.content.res.AssetManager . leer (byte [] b) // className = java.io.File Clase java.lang.Class . forName (String className) // args = cadena de caracteres " /data/user/0/com.kzcaxog.mgmxluwswb/app_ydtjq/ gpyjzmose.jar " T Java.lang.reflect.Constructor . newInstance (Object .. args) void java.io.FileOutputStream . escribir (byte [] b) 25 # vacío java.io.FileOutputStream . Cerrar ()
Por último, un DexClassLoader se invoca para cargar el código adicional en el sistema:
ClassLoader java.lang.Class . getClassLoader () // className es dalvik.system.DexClassLoader java.lang.Class . forName (String className)
En cuanto a la API para el DexClassLoader podemos ver que se toma dos argumentos - la ubicación del archivo a cargar, y un área grabable que va a utilizar para volver a escribir una versión optimizada del código para la arquitectura específica de la máquina - por ejemplo, el Android Duración (ART). Para más información sobre esto se puede ver en la documentación de la API de Android:
https://developer.android.com/reference/dalvik/system/DexClassLoader.html
ETAPA 4 - DEX EXTRACCIÓN Y DESCOMPILACIÓN
Podemos ver la ubicación exacta del archivo jar en el depurador a continuación, y el siguiente paso es recuperar este archivo a través de línea de comandos ADB.
Después de la ejecución del cargador de clases, la conexión mediante el intérprete de ADB vemos los dos archivos, el original y el código optimizado DEX:
Nos copiar estos archivos en / sdcard / Download (+ chmod) y tire del archivo .jar a una máquina local para su posterior análisis con tracción adb.
Extraer el archivo jar se encuentra la classes.dex archivo.
La repetición de los pasos para convertir esto en un archivo JAR utilizando dex2jar y descompilación con JD-GUI, que confirme que ahora tenemos el código fuente completo (des-ofuscado) para esta muestra de malware.
ETAPA 5 - DINÁMICO Y ANÁLISIS FUNCIONAL
PRIMERA INSTALACIÓN
Tras el análisis inicial podemos ver el código base del oso notables similitudes con la fuente de filtrado identificado en el análisis estático. Sin embargo, hay diferencias significativas, y el código ha sido personalizado para dirigirse específicamente a la aplicación de Danske Bank MobilePay.
A medida que el código es básicamente un-ofuscado, voy a caminar ahora brevemente a través de la funcionalidad clave de este malware, a partir de la primera instalación.
Tras la primera instalación y la ejecución de la aplicación va a realizar dos funciones principales. Inicialmente se recogerá una serie de datos de los usuarios, incluidos los contactos telefónicos, todos los mensajes SMS y otros datos clave y enviar esto al servidor C & C. El servidor de C & C, luego se devuelve un identificador de instalación único que se utiliza para todas las comunicaciones futuro para identificar de forma exclusiva el dispositivo comprometido.
En segundo lugar el malware entonces darle la lata al usuario que acepte el software como un administrador de dispositivos. Si el usuario rechaza la solicitud es re-activa, lo que es muy difícil para la mayoría de los usuarios para escapar de esta pantalla sin aceptar. Con este permiso en su lugar, el malware se consiguen dos objetivos:
- La solicitud no puede ser desinstalado por el usuario fácilmente, sin desactivando el administrador del dispositivo. El intento de hacer esto dará lugar a la puesta en marcha de las placas que impiden retirar el dispositivo de administración
- En algún momento en el futuro, una vez más los datos han sido robados desde el teléfono, el servidor C2 puede emitir un comando para limpiar el dispositivo, la eliminación de la evidencia de la infección y restaurar el dispositivo a un estado de fábrica
LAS OPERACIONES EN CURSO - INCLUYENDO DESPUÉS DE CADA REINICIO
El malware se mantiene un ritmo cardíaco regular al servidor C2, que proporciona un mecanismo para que el atacante para emitir comandos específicos para el dispositivo. Cada latido del corazón contiene el ID de instalación y el estado actual de la pantalla. Es la hipótesis de que el atacante lo ideal sería elegir ejecutar actividades maliciosas cuando la pantalla estaba apagada, y el usuario no estaba mirando el teléfono.
En primer lugar vemos la capacidad de "bloquear" y "desbloquear" el teléfono. Esto simula una pantalla de actualización de software Android, y se oculta con eficacia cualquier otra actividad que se está produciendo detrás de la superposición de pantalla (por ejemplo, enviar, recibir o borrar SMS). Además esto podría ser utilizado para desactivar el usuario, y que les impiden usar el teléfono mientras que sus cuentas o tarjetas están siendo comprometidos en tiempo real.
A continuación vemos otra función que se pretende interceptar y reenviar mensajes SMS al servidor C2, y tratando específicamente para eliminar la evidencia de que alguna vez existieron eliminándolos. Esto se utiliza para robar las credenciales de 2FA.
A continuación, desde una perspectiva servidor C2 vemos dos comandos "reset". La primera, un restablecimiento "suave", se utiliza para restablecer el indicador interno para repetir el intento de robo de credenciales de identificación Nem. El segundo es el reajuste "duro" que realiza e inmediata barrido de los datos del dispositivo.
Por último, vemos la posibilidad de enviar un mensaje SMS a un móvil arbitraria definida por el atacante y una función para lanzar una notificación de inserción personalizado a otra aplicación en el dispositivo. No estaba claro lo que esto podría ser utilizado para.
CONTROL REMOTO DE SMS
Al escuchar los mensajes SMS entrantes el malware también podría desencadenar una pantalla falsa actualización de Android, que luego de la cosecha, hacia adelante y tratar de eliminar los mensajes a medida que llegaban en el teléfono. Este modo puede ser activado y desactivado por los mensajes SMS de comandos personalizados entregados al teléfono a través de SMS.
EL ROBO DE DATOS AUTOMATIZACIÓN
Según el artículo original y muchos de los indicadores a partir del análisis estático, el propósito principal de la aplicación es de obtener datos mediante la realización de las superposiciones en la parte superior de aplicaciones legítimas. El malware dirigido a tres clases específicas de aplicaciones:
- MobilePay aplicación de Danske Bank, con la intención específica de robar credenciales de identificación Nem
- Las aplicaciones que desencadenan un intento de robar datos de su tarjeta de crédito a través de una plantilla personalizada
- Las aplicaciones que desencadenan un intento de robar el número de teléfono móvil de los usuarios (posiblemente para activar el modo "admining" descrito anteriormente)
DANSKE BANK MOBILEPAY
Al lanzar la aplicación MobilePay la superposición intenta robar el número de usuarios de la RCP (único tipo de seguridad social ID), número de móvil y Nem pasan código. Se le pregunta al usuario a tomar una foto de su libreta de ahorros ID Nem, que contiene los códigos de un solo uso que pueden ser utilizados por el atacante a continuación, iniciar sesión en MobilePay (y otros sistemas daneses) y emitir los pagos.
ROBO DE LA TARJETA DE CRÉDITO DETALLES
Al lanzar una de las aplicaciones específicas, una superposición de tarjeta de crédito se muestra con un icono configurable dependiendo de la aplicación iniciada. Después se recogen los detalles básicos de la tarjeta, a continuación, la aplicación intenta recuperar la contraseña de Verified by Visa para el usuario. Estos datos se reenvían al servidor C2.
ROBAR NÚMEROS DE TELÉFONO
Finalmente vemos la funcionalidad que se apunta para capturar el número de teléfono del usuario, presumiblemente para permitir más abusos de las víctimas cuenta a través de abuso de mensaje de texto 2FA.
RESUMEN
La muestra parece ser una variante personalizada específicamente que se utiliza en una campaña para orientar la aplicación Danske Bank MobilePay. Vemos evidencia de que es probable que no los autores GM Motor de búsqueda originales funcionan - el estilo de codificación en comparación con la fuente pública de código es diferente, y la mezcla de los idiomas en los archivos de recursos implica que la muestra ha sido adaptado de una manera "rápida y sucia" para alcanzar los objetivos.
Este es un buen ejemplo de cómo una vez liberado, el código complejo puede ser rápida y fácilmente bifurcado por autores menos cualificados y un patrón también vemos hoy en día con la liberación del código de botnet Mirai. Rápidamente vemos una propagación de las variantes de la base de código que se vuelven más difíciles de rastrear y detectar y esto es importante atribuir a un individuo o grupo.
CONOCIMIENTO pertenece al mundo
No hay comentarios:
Publicar un comentario