Análisis estático vs dinámico de malware Android

Todo APK sospechoso plantea una pregunta operativa antes que cualquier pregunta técnica: ¿basta con leer el archivo o hay que ejecutar la muestra?

El análisis estático examina el paquete sin ejecutarlo. El análisis dinámico instala la muestra en un dispositivo instrumentado y registra lo que hace. Con frecuencia se presentan como enfoques rivales, o como una escalera de madurez en la que el dinámico sería el peldaño «avanzado». Ninguna de las dos lecturas sirve. Responden preguntas distintas, fallan de maneras distintas, y el paso de uno a otro debe apoyarse en un hueco concreto de la evidencia, no en la costumbre.

Cada método establece hechos distintos y se detiene en un punto distinto, y una regla práctica decide cuándo la ejecución aporta información que el archivo por sí solo no puede dar. Es la pregunta que se hace un analista de un banco o de una fintech cuando un cliente reenvía un APK recibido por SMS, y también la que se hace un equipo de AppSec antes de firmar un informe.

Dos métodos, dos preguntas distintas

El análisis estático responde qué es capaz de hacer la aplicación. Lee el manifiesto, el certificado de firma, el bytecode compilado, las librerías nativas y los recursos embebidos, e informa de capacidades: los permisos que pide, los componentes que expone, el código que contiene y la infraestructura a la que hace referencia.

El análisis dinámico responde qué hizo realmente la aplicación, en este dispositivo, durante esta ejecución. Observa conexiones de red, escrituras en disco, acceso a SMS, cadenas descifradas y actividad en pantalla mientras ocurren.

La diferencia importa porque las dos afirmaciones no pesan lo mismo. Un hallazgo estático como «la aplicación puede leer SMS» es cierto para cada copia de ese APK. Un hallazgo dinámico como «la aplicación leyó SMS y envió un código de un solo uso a este dominio» es cierto para una ejecución, en unas condiciones concretas. Es una prueba más fuerte de intención y una prueba más débil de exhaustividad.

Lo que establece el análisis estático

Una pasada estática bien construida cubre la mayor parte de lo que necesita una decisión de triaje, y lo hace sin exponer ningún dispositivo ni ninguna red a la muestra.

Identidad. El certificado de firma, su periodo de validez y su esquema de firma, comparados con la versión que distribuye Google Play. Una app bancaria cuyo certificado no coincide con el de Play es un indicio fuerte de reempaquetado, y ese hallazgo no depende de nada de lo que haga el código.

Capacidades declaradas. Permisos y componentes del manifiesto. BIND_ACCESSIBILITY_SERVICE junto con SYSTEM_ALERT_WINDOW y QUERY_ALL_PACKAGES es el conjunto de capacidades típico de un troyano bancario con superposición de pantallas, descrito en detalle en cómo funciona un troyano bancario Android.

Ocultación. Cifrado de cadenas, carga reflexiva de clases, empaquetadores y stubs nativos de desempaquetado. La ocultación no revela comportamiento, pero es una señal en sí misma, aunque no concluyente: los protectores comerciales que usan muchas apps legítimas también cifran código, así que el hallazgo se valora junto a la firma, los permisos y el origen.

Cadena de suministro. SDK de terceros identificados por firma. Droidwatch detecta 87 SDK de esta forma y consulta OSV.dev en vivo en busca de vulnerabilidades conocidas; OSV tiene hoy datos de 12 de esos 87, porque los SDK de publicidad y atribución son en su mayoría de código cerrado.

Infraestructura. URL, direcciones IP y dominios embebidos y, cuando la configuración se puede descifrar sin ejecutar, los servidores de mando y control que contiene.

Mapeo a marcos de referencia. Hallazgos mapeados a técnicas de MITRE ATT&CK Mobile y a categorías de OWASP MASVS, para que el resultado lo entienda quien nunca abrirá la muestra: el área de fraude, auditoría o el comité de riesgo.

En Droidwatch esto es un pipeline de 28 etapas que cubre más de 25 análisis independientes. Un APK de 50 MB termina en dos a cinco minutos; por encima de 100 MB, la media es de ocho a diez. La narrativa que resume el informe la produce un motor de reglas, no un modelo de lenguaje: una fase de la cadena de ataque aparece en ella sólo cuando hay hallazgos que la respaldan.

Dónde se detiene el análisis estático

El análisis estático establece capacidades, y hay muestras construidas para que lo que está en disco revele muy poco.

• Carga dinámica de código. Un dropper distribuye un APK mínimo y descarga o descifra la carga real en tiempo de ejecución mediante DexClassLoader o un equivalente. El archivo analizado es el mecanismo de entrega, no el malware.
• Comportamiento dirigido desde el servidor. Muchos troyanos bancarios descargan después de instalarse la lista de aplicaciones objetivo y las plantillas de superposición. El APK contiene la maquinaria; los objetivos llegan más tarde.
• Configuración cifrada. Si la clave se deriva en ejecución o se obtiene de forma remota, la dirección del C2 puede no ser recuperable desde el archivo. Un buen informe dice que la extracción falló, en lugar de dar a entender que no existe infraestructura.
• Reflexión y código nativo. Llamadas que se construyen con cadenas en tiempo de ejecución, o lógica trasladada a una librería nativa, ocultan qué rutas de código son reales.

Nada de esto invalida un veredicto estático. Una muestra con ofuscación intensa, carga de código en ejecución y REQUEST_INSTALL_PACKAGES se puede clasificar como dropper sin ejecutarla. Lo que el análisis estático no puede aportar en estos casos es la segunda fase en sí.

Lo que añade el análisis dinámico

Ejecutar la muestra bajo instrumentación cubre justamente esos huecos. Frida, el kit de instrumentación dinámica de código abierto sobre el que se construye el análisis dinámico de Droidwatch, se engancha al proceso en ejecución e intercepta métodos Java y funciones nativas. En general, una instrumentación de este tipo permite observar:

• las URL que la aplicación contacta de verdad, incluidas las que se arman en tiempo de ejecución;
• el acceso a SMS y notificaciones en el momento en que ocurre, no sólo el permiso para hacerlo;
• las claves criptográficas y las cadenas descifradas mientras se construyen en memoria;
• las pantallas que dibuja la aplicación, capturadas como imágenes;
• el tráfico de red de la sesión.

En Droidwatch, lo que llega al informe desde una ejecución dinámica es la salida de Frida, el logcat, las capturas de pantalla y la captura de red.

Para un dropper, la ejecución suele ser la única vía práctica para llegar a la segunda fase. Para un troyano bancario con objetivos definidos desde el servidor, la ejecución puede revelar a qué entidades apunta la campaña actual, siempre que la infraestructura de C2 siga respondiendo.

Dónde se detiene el análisis dinámico

El análisis dinámico produce una prueba de comportamiento más sólida, y tiene sus propios puntos ciegos.

• Cobertura. Una ejecución sólo observa el código que se ejecuta durante esa sesión. Una función que depende de una orden concreta, de una fecha o de que haya instalada una app bancaria determinada puede no activarse nunca.
• Evasión. El malware Android comprueba de forma habitual si corre en un emulador, con root, con depurador o con instrumentación, y algunas familias verifican también el idioma, el país de la SIM o el tiempo transcurrido antes de activarse. Una muestra que detecta el entorno de análisis puede comportarse como una app inocua durante toda la ejecución.
• Dependencia de infraestructura viva. Si el servidor de C2 está caído, una muestra que depende de él puede no hacer nada observable. Un resultado dinámico vacío es, por tanto, una prueba de inocuidad más débil que un resultado estático vacío.
• Interacción. Las superposiciones suelen dispararse sólo cuando se abre una app objetivo. Sin ese disparador, el comportamiento más importante no ocurre.
• Riesgo. La muestra está viva. Llega a todo lo que el dispositivo alcanza y puede intentar persistir.

Comparativa

Análisis dinámico en el emulador propio

El análisis dinámico de Droidwatch se ejecuta contra el dispositivo o emulador del propio cliente, conectado mediante el agente de Droidwatch. Ninguna muestra se ejecuta en infraestructura de Droidwatch; el sandbox alojado no está en producción. El APK se sube para el análisis estático como siempre; la ejecución ocurre sólo en el emulador del analista, y lo que vuelve a Droidwatch de esa ejecución es el resultado: la salida de Frida, el logcat, las capturas de pantalla y la captura de red, que se incorporan al informe ya existente.

La guía de configuración describe el procedimiento completo. En resumen:

1. Instalar adb y las herramientas de línea de comandos de Frida en la máquina de análisis.
2. Crear un emulador con una imagen sin Google Play. frida-server necesita root, y las imágenes con Play están firmadas para producción y no lo permiten; una imagen google_apis sí. Un teléfono comercial no sirve por el mismo motivo.
3. Copiar al emulador una versión de frida-server que coincida exactamente con la del cliente de Frida local y con la arquitectura (ABI) del emulador.
4. Crear una clave de API con el alcance read + analyze. Tanto las claves de API como el análisis dinámico requieren el plan Pro o superior.
5. Arrancar el agente, subir el APK como siempre y elegir My device en la pestaña Dynamic.

Como la ejecución ocurre en la máquina del cliente y no bajo la observación de Droidwatch, la sección dinámica del informe lleva la etiqueta analyst-supplied, junto al nombre del analista y la fecha.

Las reglas de seguridad de la guía valen para cada ejecución: nunca ejecutar una muestra en un teléfono personal, aislar la red a la que llega el emulador y restaurar el emulador desde una instantánea al terminar, porque desinstalar la app no elimina la persistencia que la muestra haya podido establecer.

El análisis de iOS en Droidwatch es sólo estático, en siete módulos. No existe instrumentación en tiempo de ejecución para iOS en ningún plan.

Una regla práctica de decisión

Primero el estático, siempre. Es rápido, es seguro y, para la mayoría de las decisiones de triaje, suficiente. El flujo de triaje del SOC explica cómo llegar a una clasificación sólo con evidencia estática.

El dinámico está justificado cuando queda abierta una pregunta concreta que la ejecución puede responder:

• el informe estático muestra carga dinámica de código y hace falta la segunda fase para la detección;
• la configuración del C2 no se pudo extraer de forma estática y la infraestructura hace falta para bloquearla;
• la decisión depende de si una capacidad se usa, no sólo de si está presente;
• las entidades objetivo importan para la respuesta y las entrega el servidor.

Si no se da ninguno de estos casos, ejecutar la muestra añade riesgo sin añadir evidencia. Si se da alguno, el informe estático dice qué pregunta queda abierta, y la ejecución dinámica se dirige a responder exactamente esa. La guía del informe de Droidwatch muestra dónde aparece cada una de estas señales.

Preguntas frecuentes

¿Es más preciso el análisis dinámico que el estático? Ninguno es más preciso en general. El estático es exhaustivo respecto a lo que contiene el archivo; el dinámico es preciso respecto a lo que hizo una ejecución. Las muestras evasivas burlan el dinámico; las empaquetadas limitan el estático. Combinar ambos produce la evidencia más sólida.

¿Puede el malware detectar que se le está analizando en ejecución? Sí. Las comprobaciones de emulador, root, depurador y frameworks de instrumentación son habituales en el malware Android. Una ejecución dinámica sin incidentes no prueba que la muestra sea inocua.

¿Por qué la configuración exige un emulador con root? frida-server se ejecuta con privilegios elevados dentro del dispositivo para poder engancharse a otros procesos. Las imágenes de emulador que incluyen Google Play no permiten root, por eso la guía pide una imagen Google APIs.

¿Dónde se ejecuta la muestra durante el análisis dinámico de Droidwatch? En el emulador del propio analista. El APK se sube a Droidwatch como en cualquier análisis estático; de la ejecución, al informe sólo llegan los hallazgos y los artefactos. Ninguna muestra se ejecuta en infraestructura de Droidwatch.

¿Hay análisis dinámico para iOS? No. Droidwatch analiza los archivos .ipa de forma estática, en siete módulos, en todos los planes. No existe análisis en tiempo de ejecución para iOS.