Análisis de malware
Análisis de malware para Android
junio 6, por Srinivas
Objetivo:
Este ejercicio cubre las técnicas para analizar malware de Android mediante el uso de una muestra de malware personalizada. El malware, cuando se ejecuta en un dispositivo Android, le dará al atacante un caparazón inverso. Analizaremos la funcionalidad completa de la aplicación utilizando técnicas de análisis tanto estáticas como dinámicas.
Puede descargar los archivos de soporte aquí:
[descargar]
Lista de máquinas virtuales utilizadas : este ejercicio de laboratorio utiliza la máquina virtual Santoku Linux.
Herramientas: AVD Manager, ADB, Wireshark, dex2jar, apktool
Archivos utilizados en esta práctica de laboratorio: bake_the_cake.apk, apktool, tcpdump,
Pasos para configurar un dispositivo virtual Android:
Comenzaremos este ejercicio creando un emulador, que se requerirá en una sección posterior.
Vaya a “Santoku-Herramientas de desarrollo” y haga clic en “Administrador de SDK de Android”. Esto se ve como se muestra a continuación.
El paso anterior abrirá la siguiente ventana.
De forma predeterminada, Santoku consta de imágenes de sólo unas pocas versiones de Android. Dependiendo del requisito, deberíamos descargar imágenes de Android para crear un emulador adecuado.
Si observa la anterior, ya hemos instalado “Imagen del sistema Android 4.4.2 ARM EABI v7a”.
Una vez que todo esté configurado, haga clic en “Herramientas” en la barra de menú en la parte superior de la ventana y luego haga clic en “Administrar AVD” como se muestra a continuación.
Esto abrirá la ventana “Administrador de dispositivos virtuales Android (AVD)” como se muestra a continuación.
Como puede ver en la anterior, ya tenemos un emulador configurado. Ahora, creemos un nuevo emulador con las especificaciones que elijamos.
Haga clic en “Crear” y debería ver la siguiente ventana.
Ahora, elijamos las opciones apropiadas como se muestra a continuación.
Como puede ver en la anterior, hemos llamado a nuestro emulador “analysis_device”. Luego, elegimos un dispositivo con “HVGA de 3,2 pulgadas” para tener un emulador de menor tamaño. Luego, elegimos tener como objetivo “Android 4.4.2-API Nivel 19”. La CPU se elige como ARM. El almacenamiento interno es de 500 MB. Finalmente, proporcionamos 100 MB para la tarjeta SD.
Verifique todo y haga clic en “Aceptar” para completar la configuración.
Una vez que haya terminado con los pasos que se muestran, debería ver un dispositivo virtual adicional como se muestra a continuación.
Elija el emulador recién creado y haga clic en el botón “Iniciar” para iniciar el emulador. Debería ver el siguiente diálogo de confirmación.
Haga clic en “Iniciar” e iniciará el emulador mostrando la siguiente barra de progreso.
Tenga paciencia y espere un poco, ya que el emulador puede tardar más en iniciarse cuando lo haga por primera vez. Una vez iniciado, debería ver un emulador como se muestra a continuación.
¡Felicidades! Ha creado su emulador para analizar la muestra de malware de Android.
Análisis estático:
El análisis estático implica descompilar la aplicación, observar el código fuente y analizarlo para comprender qué está haciendo el malware.
Comencemos analizando el archivo AndroidManifest.XML. Podemos obtener el archivo AndroidManifest.xml de varias formas. Usemos apktool y obtengamoslo usando el comando que se muestra a continuación.
apktool d bake_the_cake.apk
Pero, antes de hacer esto, debemos asegurarnos de que estamos usando la última versión de apktool y eliminar 1.apk del directorio de marco de apktool, ya que el apktool existente que viene con Santoku está desactualizado y es posible que no pueda desensamblar nuestro apk de destino. archivo.
Los siguientes son los pasos.
Elimine el archivo “1.apk” en la carpeta “/home/infosec/apktool/framework/” usando el siguiente comando:
rm /home/infosec/apktool/framework/1.apk
Puede ejecutar el comando anterior desde cualquier lugar de la terminal. Esto se ve como se muestra en la siguiente figura.
Ahora, obtengamos la última versión de apktool. Esto se proporciona en Santoku VM.
Ahora, ejecute el siguiente comando para desmontar el archivo apk y debería funcionar bien.
java -jar apktool_2.1.1.jar d hornear_el_pastel.apk
¡Lindo! Apktool ha hecho el trabajo.
El comando anterior crearía una nueva carpeta con el nombre del archivo apk. En nuestro caso, es ” bake_the_cake “. Navegue hasta la carpeta y enumere los archivos y carpetas que contiene, como se muestra en la siguiente figura.
Ejecute el siguiente comando desde la carpeta de análisis para navegar a la carpeta bake_the_cake recién creada .
$cd hornear_el_pastel
Y luego, ejecute el comando ls para enumerar los archivos y carpetas dentro de la carpeta actual.
Como puede ver en la anterior, esta lista contiene el archivo AndroidManifest.xml. Veamos su contenido usando el siguiente comando y veamos si hay algo interesante.
vim AndroidManifest.xml
Al observar el contenido anterior, no hay nada sospechoso. Incluso esta aplicación no solicita ningún permiso peligroso. INTERNET es el único permiso que requiere esta aplicación, pero eso no confirma que sea maliciosa, ya que la mayoría de las aplicaciones en estos días requieren permiso de Internet para la mayor parte de su funcionalidad.
Si ha terminado de explorar el archivo abierto con vim editor, presione ctrl+c y luego ingrese :q! para salir de esto.
Por lo tanto, debemos realizar más análisis para confirmar si la aplicación tiene algún comportamiento malicioso.
Profundicemos más descompilando la aplicación usando dex2jar y JD-GUI. Primero descomprimamos la aplicación como se muestra en la siguiente figura.
$descomprimir bake_the_cake.apk
El comando anterior debería crear archivos y carpetas adicionales dentro del directorio actual. Puede verificarlo usando el comando ” ls -l” como se muestra en la siguiente figura.
Como podemos ver en la anterior, hemos extraído el archivo ” classes.dex” . El archivo class.dex se genera a partir del código Java que escriben los desarrolladores. Originalmente, los archivos .java se compilan utilizando el compilador tradicional de Java javac. Este paso genera archivos .class. Estos archivos de clase se entregan además a la herramienta dx que genera el archivo Classes.dex que se ejecuta dentro de la máquina virtual Dalvik (DVM). El archivo Classes.dex es un binario compilado y, por lo tanto, no podemos leerlo en texto claro. Podemos usar la herramienta de línea de comando dex2jar para convertir el archivo dex en un archivo jar. Estos archivos jar se pueden descompilar utilizando cualquier descompilador tradicional de Java, como JD-GUI. Este es un paso esencial para comprender el código fuente de la aplicación. La herramienta dex2jar está preinstalada en Santoku.
Podemos ejecutar el siguiente comando para usar dex2jar.
$dex2jar clases.dex
Esto se muestra en la siguiente figura.
Como podemos ver en la anterior, el archivo Classes.dex se ha convertido en un archivo Classe_dex2jar.jar .
Ahora podemos usar cualquier descompilador de Java tradicional para obtener archivos Java del archivo jar anterior. Usemos JD-GUI, que está disponible en Santoku.
Vaya a “Santoku-Ingeniería inversa”. Debería ver JD-GUI como se muestra en la siguiente figura.
Haga clic en JD-GUI y se abrirá la herramienta como se muestra en la siguiente figura.
Como se mencionó anteriormente, usaremos esta herramienta para obtener archivos java del archivo jar. Entonces, navegue hasta “Archivo-abrir” y elija el archivo clases_dex2jar.jar . Esto se ve como se muestra a continuación.
Haga clic en Abrir y debería ver la ventana como se muestra en la siguiente figura.
Bien, podemos ver el nombre del paquete com.infosecinstitute.analyze_me . También podemos ver tres clases diferentes que incluyen MainActivity. Hagamos clic en MainActivity y exploremos.
Explorar MainActivity muestra mucha información interesante. Primero, echemos un vistazo al siguiente fragmento de código.
Curiosamente, hay tres métodos en el código anterior. getReverseShell() parece peligroso ya que podría estar realizando una llamada a un método que proporciona un shell inverso al atacante. Antes de explorar eso, veamos los otros dos métodos copyFile() y changefilepermissions().
El siguiente fragmento de código es la definición del método copyFile() .
Este método consiste esencialmente en copiar un archivo llamado nc del directorio de activos de la aplicación al directorio /data/data/com.infosecinstitute.analyze_me/app_files/ . El directorio de destino es esencialmente el entorno limitado de la aplicación en el dispositivo.
Entendamos cómo está sucediendo esto.
Primero, hemos visto la llamada al método copyFile(“nc”); en el fragmento de código anterior. El argumento se pasó a localAssetManager.open() y se está abriendo. Luego, se ha creado la ruta del archivo de destino. getNombrePaquete(); da el nombre del paquete actual. Las siguientes líneas se utilizan para copiar el archivo en el destino.
Dado que el nombre del archivo es “nc”, puede ser un paquete binario netcat dentro del apk. Cambiemos a la carpeta de análisis en el terminal y verifiquemos la carpeta de activos del APK descomprimido y veamos las propiedades.
La siguiente muestra que un archivo con el nombre “nc” se encuentra dentro de la carpeta de activos.
Veamos también el tipo de archivo usando el comando de archivo. Ejecute “archivo nc ” dentro de la carpeta de activos. El resultado debería verse como se muestra a continuación.
El resultado anterior muestra que el archivo es una compilación binaria ELF para la arquitectura ARM. Esto confirma que el archivo dentro de la carpeta de activos es un archivo ejecutable posiblemente creado para dispositivos Android.
Ahora, volvamos a JD-GUI y observemos el siguiente método changefilepermissions(). El siguiente fragmento de código muestra la definición de este método.
El método anterior parece estar cambiando los permisos de archivo del binario netcat que se copió anteriormente en la carpeta “app_files” . El comando “chmod 755 nombre de archivo” otorga permisos ejecutables al archivo especificado.
Podemos verificar si se han cambiado los permisos del archivo. Inicie el emulador que creamos anteriormente, instale la aplicación y ejecútela. Para instalar la aplicación, regrese a su terminal y asegúrese de estar dentro de la carpeta de análisis donde se encuentra el archivo apk de destino.
Luego ejecute el siguiente comando.
“adb install bake_the_cake.apk”
Esto se muestra en la siguiente figura.
Una vez instalada, asegúrese de iniciar la aplicación para que se ejecute el código que hemos visto.
Ahora, coloque un caparazón en el dispositivo como se muestra en la siguiente figura.
cáscara $adb
Navegue hasta el paquete de destino usando “cd /data/data/com.infosecinstitute.analyze_me/” y ejecute el comando “ls” como se muestra en la siguiente figura.
Como podemos ver en la anterior, se crea el directorio app_files . Ahora, naveguemos hasta este directorio y verifiquemos los permisos de archivo de netcat usando el comando “ls -l” como se muestra en la siguiente figura.
Como puede ver en la anterior, nc binario tiene permisos ejecutables.
Una vez hecho esto, salga del shell adb presionando ctrl+c.
Finalmente, queda un último método por explorar. Volvamos a JD-GUI y verifiquemos el método getReverseShell() y veamos qué está haciendo.
A continuación se muestra el fragmento de código.
El fragmento de código anterior muestra que la aplicación utiliza Runtime.getRuntime().exec() y realiza una conexión saliente a la dirección IP 10.0.2.2 a través del puerto 5555, ofreciendo un shell inverso al atacante. Esta conexión se realiza mediante el binario netcat que se incluye con el archivo apk.
Este análisis estático de la muestra dada concluye lo siguiente.
La aplicación es maliciosa.
Viene con el binario netcat incluido dentro del archivo apk.
Cuando un usuario abre la aplicación, le proporciona un shell inverso al atacante (10.0.2.2)
Análisis dinámico:
Cuando intentamos realizar un análisis estático, el desarrollador puede ofuscar el código, lo que es difícil de explorar. En tales casos, confiar en el análisis estático podría resultar problemático. Aquí es donde el análisis dinámico entra en escena. El análisis dinámico consta de los pasos para analizar la aplicación ejecutándola. Por lo general, este proceso busca llamadas API, llamadas de red, etc.
Esta sección muestra cómo realizar un análisis del tráfico de red en dispositivos Android usando tcpdump.
Comencemos instalando e iniciando la aplicación en el emulador. La aplicación debería verse como se muestra en la siguiente una vez que la inicie.
Bien, la aplicación funciona bien.
Ahora, insertemos el binario tcpdump en el emulador. Esto se puede hacer usando el comando adb push como se muestra en la siguiente figura.
En el comando anterior, /data/local/tmp es el directorio mundial de escritura en el dispositivo Android.
Podemos ver que el binario tcpdump ha sido enviado.
Ahora, obtengamos un shell en el emulador y verifiquemos el archivo en /data/local/tmp como se muestra en la siguiente figura.
Si observa el resultado anterior, el binario tcpdump actualmente no tiene privilegios ejecutables.
Entonces, otorguemos permisos ejecutables a tcpdump como se muestra en la siguiente figura.
#chmod 755 tcpdump
Ahora, el binario tcpdump es ejecutable. Comencemos y capturemos los paquetes usando el siguiente comando.
./tcpdump -v -s 0 -w paquetes.pcap
Como podemos ver en la anterior, capturamos los paquetes y los guardamos en un archivo llamado paquetes.pcap.
Ahora, cierre la aplicación una vez haciendo clic en el botón Atrás del emulador y ejecútela nuevamente. Esto es solo para garantizar que se ejecute la primera pantalla de la aplicación y que tcpdump vea el tráfico directamente desde el punto de inicio de la aplicación. La aplicación tiene una sola página, por lo que cerrarla y reiniciarla es suficiente en nuestro caso.
Una vez hecho esto, podemos dejar de capturar los paquetes presionando ctrl+c en la terminal como se muestra en la siguiente figura.
Ahora podemos transferir estos paquetes a una máquina local para su posterior análisis. Primero salga de adb shell escribiendo ctrl+c y luego extráigalos usando el comando “adb pull” como se muestra en la siguiente figura.
#adb extrae /data/local/tmp/packets.pcap
Hemos retirado los paquetes capturados. Ahora necesitamos analizarlo. Usaremos Wireshark para analizar estos paquetes.
En Santoku, Wireshark se puede encontrar en “Santoku – Analizadores inalámbricos – Wireshark” , como se muestra en la siguiente figura.
Inicie Wireshark y luego vaya a “Archivo-Abrir” para abrir el archivo paquetes.pcap. Esto se ve como se muestra en la siguiente figura.
Debería ver los paquetes en Wireshark como se muestra a continuación.
Bueno, hay muchos paquetes para analizar y necesitamos filtrar los paquetes eliminando los paquetes innecesarios que no nos interesan.
Puede aplicar el siguiente filtro para eliminar paquetes que tengan el indicador “PSH ACK”. Este filtro se aplica ya que buscamos paquetes con un protocolo de enlace de tres vías.
El filtro anterior elimina muchos paquetes que no nos interesan. Al desplazarse hacia abajo en Wireshark se muestran los dos paquetes siguientes.
Como puede ver en la anterior, hay un paquete SYN que va de 10.0.2.15 (emulador) a 10.0.2.2 (Santoku).
Nota: El emulador toma 10.0.2.2 como dirección de la máquina host en la que se ejecuta el emulador. El malware se creó con esta dirección para simular la dirección IP del atacante sin Internet.
Al hacer clic en el paquete anterior también se muestra que el puerto que escucha en la máquina del atacante es 5555. Este es el puerto al que el malware intenta conectarse.
¡Lindo! Esto nos dio una idea de que la aplicación está intentando realizar conexiones remotas a través de un puerto TCP 5555 a la IP 10.0.2.2.
Pero el siguiente paquete muestra que la conexión se ha restablecido (obtuvimos RST).
Intentemos lo mismo nuevamente simulando el servidor del atacante en Santoku usando netcat.
El servidor Netcat se puede iniciar en Santoku como se muestra en la siguiente figura.
Como podemos ver en la anterior, estamos escuchando en el puerto 5555.
Ahora, inicie tcpdump en el emulador como hicimos antes. Guarde los paquetes en un archivo llamado paquetes2.pcap . Luego, inicie la aplicación de destino para generar tráfico. Cuando lo haga, recibirá un shell inverso en el oyente netcat.
Detengamos la captura de tcpdump. Esto se ve como se muestra a continuación.
Saquemos los paquetes usando adb como se muestra en la siguiente figura.
Una vez más, abra el archivo pcap en Wireshark y busque el protocolo de enlace de tres vías en los paquetes capturados. La siguiente muestra el protocolo de enlace de tres vías.
Como podemos ver en la anterior, 10.0.2.15 inició el protocolo de enlace de tres vías con un paquete SYN. La siguiente muestra que la aplicación está intentando establecer una conexión con el servidor del atacante en el puerto 5555.
Haga clic en el segundo paquete y debería ver la respuesta proveniente de Santoku (10.0.2.2). Puede notar el puerto de origen 5555.
Finalmente, haga clic en el tercer paquete para ver el paquete ACK enviado por la fuente con destino a la máquina Santoku en el puerto 5555.
Esto confirma que se ha establecido la conexión con el servidor del atacante.
Como usamos netcat en ambos lados, utiliza transmisiones de texto claro e incluso podemos ver las comunicaciones.
Para comprobar esto, repitamos el proceso anterior una vez más.
Iniciar el oyente netcat en Santoku
Ejecute tcpdump y guarde los paquetes en un archivo llamado paquetes3.pcap
Inicie y ejecute la aplicación para generar tráfico.
La siguiente muestra a tcpdump capturando los paquetes y escribiéndolos en paquetes3.pcap .
Cuando obtenga el shell en la máquina Santoku, simule algo de tráfico ingresando el comando “cat /proc/cpuinfo” como se muestra en la siguiente figura.
Detenga la captura y extraiga los paquetes como se muestra en la siguiente figura.
$adb extraer /data/local/tmp/packets.pcap
Ahora, abra los paquetes en Wireshark y busque las cadenas que hemos ingresado. Esto se puede hacer como se muestra en la siguiente figura. Vaya a “Editar – Buscar paquete”.
Now choose string and enter “cpuinfo” into the text field. Make sure that you choose “packet bytes” to search in and finally click “Find”.
Now, we should see the packet that has the content we are looking for. Select the packet and give a right click.
The following options should be shown. Click “Follow TCP Stream”.
This will open up the following window where you will be able to see the messages being sent between the malware and the attacker’s server.
Conclusion
This lab has covered fundamental concepts of analyzing Android malware both using static and dynamic analysis techniques. Though the custom malware app has shown one feature of an Android malware(giving reverse shell), you may find more malicious functions such as stealing data and sending it to attacker’s server when you analyze real-world malware. Nevertheless, the idea here is to show the common analysis techniques, and these techniques remain the same.