Un cliente reenvía un APK que le facilitó quien decía llamar desde el departamento de fraudes de su banco. Un canal de inteligencia publica un nombre de paquete que suplanta la aplicación de banca móvil de una entidad. Un empleado instala un fichero entregado por una campaña de smishing bajo el pretexto de una actualización obligatoria.
En los tres casos el SOC se enfrenta a la misma pregunta, y no es si la muestra es malware. Es si la organización debe actuar, y sobre qué evidencia.
Este documento establece un flujo de triaje estático: una clasificación defendible más un conjunto de indicadores aptos para detección, producidos sin dispositivo, sin emulador y sin entorno de laboratorio.
Alcance del triaje
El triaje responde a cuatro preguntas en secuencia:
- ¿Es la aplicación lo que dice ser?
- ¿Qué capacidades solicita el manifiesto?
- ¿El código oculta su función?
- ¿Con qué infraestructura contacta?
El triaje no establece la cadena de ataque completa ni la actividad del operador tras el compromiso. Ésos son objetivos de ingeniería inversa, y confundir ambos planos es la causa principal de atasco en las colas de triaje móvil.
Un límite práctico: cuando no se ha alcanzado una clasificación en unos diez minutos de trabajo de analista, la muestra corresponde a una cola de reversing y no a una de triaje. El triaje es el proceso que determina cuál de las dos.
Manejo de la muestra
Todo APK desconocido se trata como malware vivo durante el proceso.
- El análisis se realiza en un entorno aislado. Las muestras de triaje nunca se instalan en un dispositivo con credenciales ni conectado a una red de producción.
- El SHA-256 se registra antes que cualquier otro paso. Es el único identificador estable que conserva la muestra; el nombre de paquete, la etiqueta y el icono están bajo control del atacante.
- El binario no se redistribuye. Se comparten hashes e indicadores, no la muestra. Los acuerdos de intercambio de muestras son una cuestión legal, no técnica.
- Se registra la procedencia. El mismo APK recuperado del terminal de un cliente y obtenido de un feed público representan incidentes distintos.
Paso 1 — Verificación de identidad
El análisis empieza por los componentes que un atacante está obligado a exponer para que el paquete llegue a instalarse.
Nombre de paquete. Se compara con el paquete de la aplicación legítima en Google Play. Las aplicaciones bancarias reempaquetadas rara vez reutilizan el nombre exacto: emplean una variante próxima, un dominio invertido en otro orden o una cadena aleatoria. Un nombre de paquete ausente de Play cuya etiqueta corresponde a una entidad financiera conocida es motivo suficiente de escalado por sí solo.
Certificado de firma. Es la señal de identidad más sólida disponible en un APK. Se examinan cuatro propiedades:
- Esquema de firma. La firma sólo v1 en una aplicación moderna es anómala. v2 y v3 son la norma.
- Sujeto del certificado. Un certificado de depuración (
CN=Android Debug) en una aplicación que se presenta como producto bancario es descalificante. - Ventana de validez. Un certificado emitido días antes de la aparición de la muestra indica una identidad de campaña desechable. Un autofirmado a treinta años indica generalmente herramientas por defecto, patrón presente tanto en malware como en aplicaciones legítimas mal mantenidas.
- Reutilización. Un certificado compartido entre aplicaciones aparentemente sin relación establece vinculación de campaña, y suele ser el pivote más productivo disponible a partir de una sola muestra.
Verificación contra Play. Cuando el paquete existe en Play pero el certificado no coincide con el que Play distribuye, la muestra es una aplicación reempaquetada. Se trata de un incidente de fraude y no de un hallazgo de malware, y corresponde de inmediato a la función de protección de marca.
En Droidwatch estas salidas se resuelven antes de que finalice el resto del análisis.
Paso 2 — Análisis del manifiesto
Los permisos constituyen una declaración de capacidad pretendida. A efectos de triaje, lo que una aplicación puede hacer suele ser suficiente.
Permisos que exigen lectura detenida:
| Permiso | Significado |
|---|---|
BIND_ACCESSIBILITY_SERVICE |
El permiso con mayor señal del malware Android. Los servicios de accesibilidad leen el contenido de pantalla e inyectan entrada, base de los ataques de superposición y del fraude en dispositivo. |
SYSTEM_ALERT_WINDOW |
Dibuja sobre otras aplicaciones. Combinado con accesibilidad, constituye el emparejamiento estándar del phishing por superposición. |
RECEIVE_SMS / READ_SMS |
Intercepción de OTP. En contexto bancario debe tratarse como el propósito de la aplicación mientras no se establezca lo contrario. |
BIND_NOTIFICATION_LISTENER_SERVICE |
Lee el contenido de las notificaciones, incluidos códigos de un solo uso que nunca llegan a la base de datos de SMS. |
REQUEST_INSTALL_PACKAGES |
Instala otras aplicaciones. Es la característica que define a un dropper. |
BIND_DEVICE_ADMIN |
Resiste la desinstalación; puede bloquear o borrar el dispositivo. |
QUERY_ALL_PACKAGES |
Enumera las aplicaciones instaladas, normalmente para seleccionar la superposición bancaria correspondiente. |
Un solo permiso peligroso es una pregunta. BIND_ACCESSIBILITY_SERVICE junto a SYSTEM_ALERT_WINDOW y QUERY_ALL_PACKAGES es el conjunto de capacidades establecido de un troyano bancario Android.
Los componentes se leen junto a los permisos:
- Componentes exportados. Un
ServiceoBroadcastReceiverexportado sin permiso que lo proteja constituye superficie de ataque, también en aplicaciones legítimas. - Receptores de
RECEIVE_BOOT_COMPLETED. Persistencia tras reinicio. android:debuggable="true"en una build de release. O construcción descuidada de malware, o un defecto significativo en una aplicación legítima.android:allowBackup="true"en combinación con almacenamiento local sensible.- Tráfico en claro.
cleartextTrafficPermitted="true"o unnetworkSecurityConfigpermisivo indican tráfico inspeccionable, y constituyen un fallo de MASVS-NETWORK.
Paso 3 — Ocultación del código
El objetivo en esta fase no es leer el código, sino establecer si el código está construido para resistir su lectura.
- Ofuscación. El renombrado de identificadores por sí solo es irrelevante: la mayoría de builds de release pasan por R8 o ProGuard. El cifrado de cadenas, la carga reflexiva de clases y el aplanamiento de flujo de control no son esperables en una aplicación bancaria.
- Carga dinámica de código.
DexClassLoader,PathClassLoadersobre un fichero recuperado en tiempo de ejecución, o una carga útil descifrada desdeassets. Es el patrón dropper: el APK enviado constituye el mecanismo de entrega, no el malware. - Librerías nativas. Un objeto compartido en una aplicación sin necesidad plausible de código nativo merece anotación. Los packers ocultan con frecuencia la carga útil tras un stub nativo de desempaquetado.
- Blobs en assets. Ficheros grandes, cifrados o de alta entropía en
assets/que el manifiesto no justifica.
Una muestra que presenta ofuscación intensa, carga de código en ejecución y REQUEST_INSTALL_PACKAGES puede clasificarse sin leer un solo método.
Paso 4 — Extracción de infraestructura
Se extraen todos los endpoints embebidos: URL, direcciones IP sueltas, dominios presentes en las tablas de cadenas y, cuando la configuración va cifrada, la configuración descifrada.
Las salidas relevantes son:
- Endpoints de C2 y el patrón de protocolo circundante.
- Antigüedad y registro del dominio. Un dominio registrado la semana anterior sirviendo una aplicación que suplanta a una entidad de larga trayectoria constituye por sí mismo un hallazgo concluyente.
- Tokens de bots de Telegram, URL de buzón y identificadores de chat embebidos. Las campañas de baja sofisticación recurren a ellos de forma sistemática, y pivotan con facilidad.
- Reutilización de infraestructura. Una sola dirección IP sirviendo a varias familias de APK sin relación aparente indica una campaña, no una coincidencia.
Estos indicadores son el componente del triaje que llega a la pila de detección. Una clasificación protege a un cliente; un dominio C2 incorporado a una blocklist de DNS protege a todos los usuarios que están detrás. Droidwatch los emite como bundle STIX 2.1, de modo que el paso de muestra a regla de detección no exige transcripción manual.
Paso 5 — Mapeo a marcos de referencia
El mapeo es lo que hace legible un hallazgo móvil para responsables que nunca examinan la muestra.
Técnicas recurrentes en esta clase de muestra:
| Comportamiento | MITRE ATT&CK Mobile |
|---|---|
| Pantallas superpuestas que capturan credenciales | T1417.002 — GUI Input Capture |
| Registro de pulsaciones mediante accesibilidad | T1417.001 — Keylogging |
| Entrada automatizada para fraude en dispositivo | T1516 — Input Injection |
| Lectura o intercepción de SMS | T1582 — SMS Control |
| Acceso a notificaciones | T1517 — Access Notifications |
| Recolección de contactos, registro de llamadas y mensajes | T1636 — Protected User Data |
| Escalada a administrador de dispositivo | T1626.001 — Device Administrator Permissions |
| Evasión de herramientas de seguridad | T1629 — Impair Defenses |
| Empaquetado o cifrado de cadenas | T1406.002 — Software Packing |
| Persistencia tras reinicio | T1624.001 — Broadcast Received |
| Recuperación de carga útil de segunda etapa | T1544 — Ingress Tool Transfer |
| Canal de mando y control cifrado | T1521 — Encrypted Channel |
Para las funciones de seguridad de aplicaciones, los mismos hallazgos mapean a categorías de OWASP MASVS: MASVS-NETWORK para transmisión en claro y fallos de pinning, MASVS-STORAGE para datos locales expuestos, MASVS-CODE para carga dinámica, MASVS-RESILIENCE para deficiencias de antimanipulación. El MASTG aporta el procedimiento de prueba correspondiente cuando un resultado debe demostrarse.
Droidwatch produce ambos mapeos en cada ejecución, junto a una señal de clasificador medida en F1 macro 0,9873 sobre un holdout de 1.661 muestras, entrenado con 6.642 muestras de CICMalDroid 2020. El clasificador contribuye al veredicto; los hallazgos anteriores son lo que defiende un informe.
Paso 6 — Clasificación y escalado
Droidwatch puntúa el riesgo de 0 a 100, donde una puntuación más alta indica mayor riesgo. Cuatro salidas, cada una con un responsable definido:
| Veredicto | Score | Definición | Destino |
|---|---|---|---|
| Malicious | 65 o más | Familia identificada, o conjunto de capacidades sin interpretación legítima posible | Respuesta a incidentes de inmediato; indicadores al SIEM |
| High Risk | 40-64 | Capacidades peligrosas con anomalías de identidad; familia sin confirmar | Ticket de incidente más cola de reversing |
| Suspicious | 20-39 | Anomalías sin patrón malicioso coherente; con frecuencia adware o aplicación legítima mal construida | Watchlist; reanalizar si reaparece |
| Benign | Menos de 20 | Nada fuera de la norma para su categoría de aplicación | Cerrar con el informe adjunto |
El artefacto importa más que la etiqueta. Un informe que afirma «malicioso» es una aseveración. Un informe que contiene el hash, el análisis del certificado, el conjunto de permisos, los dominios C2, el mapeo ATT&CK y el razonamiento detrás de la puntuación es evidencia, y la evidencia es lo que resiste una revisión semanas después. Droidwatch lo exporta en PDF, DOCX, JSON, CSV o STIX 2.1.
Limitaciones del triaje estático
- El análisis estático establece capacidad, no comportamiento. Una aplicación capaz de interceptar SMS puede no hacerlo nunca, o hacerlo sólo por instrucción de su C2. Cuando una decisión depende del comportamiento en ejecución, se requiere análisis dinámico.
- La configuración cifrada puede no ceder. Algunos packers exigen ejecución. Cuando la extracción de configuración falla, el informe lo declara en lugar de dar a entender ausencia de hallazgos.
- El análisis dinámico de Droidwatch es sólo Android y se ejecuta contra el dispositivo o emulador del propio cliente, conectado mediante el agente de Droidwatch. Ninguna muestra se ejecuta en infraestructura de Droidwatch. Es el diseño pretendido para organizaciones que no pueden enviar muestras de sus clientes a un sandbox de terceros, y exige configuración del lado del cliente. Está disponible desde el plan Pro.
- El análisis de iOS es sólo estático. Sobre un
.ipase ejecutan siete módulos: análisis del binario Mach-O,Info.plist, entitlements, configuración de App Transport Security, class-dump, frameworks enlazados y manifiestos de privacidad declarada. No existe instrumentación en ejecución para iOS en ningún plan.
Ejecución del flujo en la plataforma
Los seis pasos anteriores describen el proceso analítico. La mecánica es un único envío:
- Envía el
.apk(o.xapk,.aab,.dex,.ipa) al analizador. Un APK de 50 MB se completa en dos a cinco minutos; los paquetes por encima de 100 MB promedian entre ocho y diez. - Revisa el informe: veredicto y puntuación, hallazgos ordenados por severidad, certificado y comparación con Play, mapeo ATT&CK Mobile, cobertura MASVS, indicadores extraídos.
- Exporta en el formato que requiera el destinatario: STIX 2.1 para el SIEM, PDF o DOCX para el expediente del incidente.
En volumen, el flujo se ejecuta por API: POST /api/upload devuelve un upload_id; POST /api/analyze devuelve un job_id y un run_id; se sondea GET /api/jobs/{job_id} hasta que el estado sea done o failed; el informe se recupera de GET /api/runs/{run_id}/artifact/report.json. La autenticación admite una cabecera X-API-Key o un bearer token. Cuando el fichero ya se analizó previamente, la respuesta trae cached: true con el job_id a nulo y no hace falta sondear. La guía rápida documenta la secuencia completa.
Preguntas frecuentes
¿Cuánto debe durar el triaje de un APK? Unos diez minutos de trabajo de analista hasta alcanzar una clasificación. Las muestras que superan ese umbral de forma sistemática corresponden a una cola de reversing.
¿Basta con VirusTotal para este flujo? VirusTotal responde a si un hash ha sido observado y cómo lo clasificaron los motores participantes, y es la primera consulta adecuada. No proporciona el conjunto de permisos, las anomalías del certificado, el mapeo ATT&CK ni el razonamiento necesario para producir un informe de incidente. Las dos herramientas ocupan posiciones distintas del flujo. Hay disponible una comparativa detallada.
¿Por qué no operar MobSF directamente? MobSF es un motor de análisis solvente y buena parte de la disciplina de seguridad móvil se construyó sobre él. El coste es operativo y no analítico: orquestación de contenedores, escalado de workers, mantenimiento de dependencias, y la ausencia de multi-tenant, control de acceso por roles y traza de auditoría en entornos multicliente. La comparativa completa documenta el trade-off.
¿Cuál es el resultado cuando una muestra resulta benigna? Un informe firmado que establece esa conclusión, producido en diez minutos. Los resultados negativos son una salida necesaria de cualquier proceso de triaje.
Los indicadores de las muestras analizadas en la plataforma se publican en el threat feed público bajo licencia CC BY 4.0. Las prácticas de manejo y divulgación están documentadas en la página de confianza.