Analizar un APK online: qué ves en el informe

La mayoría de servicios que permiten analizar un APK online devuelven un veredicto y poco más. El veredicto afirma que un fichero es malicioso. No establece qué hace la aplicación, qué evidencia sostiene esa clasificación ni qué debe escalar un analista.

Este artículo documenta la cadena de análisis de Droidwatch de principio a fin: los formatos admitidos, las etapas que se ejecutan al subir una muestra, cada bloque del informe resultante y el punto en que el análisis estático deja de producir evidencia utilizable.

El razonamiento del analista —cómo trabajar una muestra sospechosa, en lugar de cómo la procesa la plataforma— se trata por separado en el flujo de triaje de APK.

Formatos admitidos

Se admiten cinco formatos. Todos son de Android salvo el último.

El tamaño máximo depende del plan: 150 MB sin cuenta, 200 MB en Free, 500 MB en Pro, 750 MB en Team y 1 GB en Enterprise. Las aplicaciones bancarias en producción quedan generalmente muy por debajo del techo de Free; los paquetes que superan los 500 MB suelen ser juegos.

Existen dos vías de entrada. La subida por navegador atiende ficheros sueltos. La API atiende todo lo demás y se documenta más abajo.

La cadena de análisis

Una sola subida dispara una cadena de 28 etapas que produce más de 25 análisis independientes. Las etapas pertenecen a una misma ejecución y no a productos distintos, lo cual es relevante para interpretar el resultado: un hallazgo producido por una etapa puede alterar cómo puntúa la muestra una etapa posterior.

Las etapas se agrupan en seis áreas. Identificar de qué área procede un hallazgo determina qué peso tiene ese hallazgo.

1. Paquete e identidad

Parseo del manifiesto, nombre de paquete, versión y código de versión, SHA-256, min_sdk, target_sdk y la cadena del certificado de firma. Esta área ejecuta además la comparación con Google Play: si el paquete existe en Play y, de existir, si su certificado coincide con el que Play distribuye.

Un desajuste de certificado es la salida de mayor valor de toda la cadena. Reclasifica la muestra de «aplicación sospechosa» a «reempaquetado confirmado», que es un tipo de incidente distinto y con otro responsable dentro de la organización.

2. Bytecode

Análisis profundo de DEX mediante androguard: clases, métodos, uso de API, reflexión, carga dinámica de clases y postura de ofuscación de la build. El comportamiento de tipo dropper aflora aquí. Un APK cuya carga útil se descarga tras la instalación se presenta como irrelevante en todas las demás áreas.

3. Código nativo y empaquetado

Objetos compartidos, firmas de packers, assets de alta entropía y cualquier componente incluido en el paquete que el manifiesto no justifique.

4. Detección de familia

Reglas YARA combinadas con heurísticas. La atribución de familia es el dato operativamente más útil que puede contener un informe, porque incorpora todo el conocimiento existente sobre la infraestructura, los objetivos y el comportamiento de esa familia.

5. Cadena de suministro

Droidwatch identifica 87 SDK de terceros por firma y consulta OSV.dev en el momento del análisis en busca de vulnerabilidades conocidas.

Son dos mediciones distintas y la diferencia importa. OSV cubre 12 de los 87. Los SDK de publicidad y atribución son cerrados y no están representados en las bases de vulnerabilidades públicas. Para los 75 restantes, la plataforma establece qué contiene la aplicación pero no puede establecer si existe un CVE publicado. Las afirmaciones de cobertura de CVE sobre SDK móviles propietarios deben contrastarse con el contenido real de las bases públicas. Un módulo aparte sigue aproximadamente 120 trackers de privacidad.

Esta área produce hallazgos en aplicaciones legítimas con más frecuencia que ninguna otra, y es la razón por la que los equipos de seguridad de aplicaciones ejecutan la plataforma sobre sus propias builds y no sólo sobre presuntas muestras maliciosas.

6. Inteligencia de infraestructura

Extracción de endpoints, identificación de C2 y extracción de configuración cifrada cuando la muestra lo permite.

Clasificador de aprendizaje automático

Un clasificador se ejecuta en paralelo a la cadena. Su rendimiento medido es F1 macro 0,9873 sobre un holdout de 1.661 muestras, entrenado con 6.642 muestras de CICMalDroid 2020. El tamaño del holdout se cita deliberadamente: una cifra de precisión sin conjunto de evaluación declarado no es una medición.

El clasificador aporta una señal al veredicto. No determina el veredicto, y ningún hallazgo de un informe se apoya únicamente en él.

Duración del análisis

Mediciones tomadas sobre informes de producción el 19 de septiembre de 2026:

Un APK de 50 MB se completa en dos a cinco minutos. Los paquetes por encima de 100 MB promedian entre ocho y diez minutos. Los trabajos transitan por cuatro estados: queued, running, done y failed.

La documentación anterior indicaba de 30 a 90 segundos. Esa cifra era inexacta y se ha retirado.

Estructura del informe

metadata

run_id, app_name, package, version_name, version_code, sha256, file_size, min_sdk, target_sdk, analyzed_at.

Es el bloque más citado aguas abajo. La combinación de sha256 y analyzed_at establece la reproducibilidad: identifica qué build se examinó y cuándo, que es lo que exige una auditoría o una discrepancia seis meses después.

min_sdk merece atención. Una aplicación que apunta a un nivel de API obsoleto suele hacerlo para quedar fuera de un modelo de permisos que las versiones actuales de Android sí imponen.

overview

score, verdict y una distribución de severities entre info, low, medium, high y critical.

Droidwatch puntúa el riesgo de 0 a 100, donde una puntuación más alta indica mayor riesgo. Las bandas de veredicto son fijas:

Se utiliza una sola escala. La columna Score del threat feed público contiene el mismo valor, de modo que un 63 en el feed corresponde a un 63 en un informe privado.

Para triaje, la distribución de severities suele ser más informativa que la puntuación compuesta, porque describe la forma del problema. Dos hallazgos críticos y nada más indican una aplicación concreta y explicable. Cuarenta hallazgos medios y ningún crítico indican normalmente una aplicación legítima con deuda técnica. Los dos informes se dirigen a equipos distintos.

sections

Un array de { id, title, findings } que contiene el cuerpo del análisis: permisos, componentes, detalles del certificado, configuración de red, indicadores extraídos, análisis de código y cadena de suministro. La cadena del certificado, los indicadores de red y las coincidencias YARA se ubican dentro de sus respectivas secciones, no en el primer nivel del documento.

Cada hallazgo incorpora su propio razonamiento de apoyo. Ésta es la diferencia sustantiva entre un informe y un veredicto de escáner: el informe identifica qué componente solicita un permiso determinado y qué habilita ese permiso, en lugar de afirmar que el permiso es peligroso. Cuando un equipo de desarrollo discute un hallazgo, el razonamiento es lo que resuelve la discrepancia en un sentido o en otro.

Tres elementos dentro de sections merecen atención específica:

• Detalles del certificado. La reutilización de certificados entre aplicaciones aparentemente sin relación es la señal de vinculación de campañas de menor coste disponible en inteligencia de amenazas móvil, y se pasa por alto de forma sistemática. Un certificado de depuración en una aplicación que se presenta como producto bancario resuelve la investigación de inmediato.
• Indicadores de red. Dominios, direcciones IP, URL y configuración descifrada cuando la extracción tuvo éxito. Son la salida con mayor vida operativa: un veredicto protege a un único cliente, mientras que un dominio C2 incorporado a una blocklist de DNS protege a todos los usuarios que están detrás.
• Coincidencias YARA. Atribución de familia. Un resultado vacío es un resultado válido. La mayoría de muestras no pertenecen a una familia conocida, y una herramienta que devuelve atribución de forma sistemática está infiriendo, no correlacionando.

ttp_mapping

Hallazgos mapeados a técnicas de MITRE ATT&CK Mobile.

El mapeo hace legible un hallazgo móvil para responsables que no trabajan en seguridad móvil. Los identificadores de técnica pueden incorporarse a un modelo de cobertura de detección, lo que elimina el parque móvil como hueco en los informes de cobertura ATT&CK.

Los hallazgos se mapean además a las ocho categorías de control de OWASP MASVS: MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE y MASVS-PRIVACY. El MASTG aporta el procedimiento de prueba correspondiente a cada control cuando un resultado debe demostrarse de forma independiente.

Una advertencia cuando ambas cifras aparecen en un mismo informe: van en sentidos opuestos. El riesgo se puntúa de 0 a 100 donde más alto es peor. La cobertura MASVS se puntúa de 0 a 100 donde más alto es mejor.

narrative y behavior_summary

Descripciones en prosa de la muestra y su comportamiento, compuestas a partir de los hallazgos.

El método de generación se declara explícitamente porque la suposición predominante ante cualquier prosa dentro de un informe de seguridad es que la produjo un modelo de lenguaje. Estos campos los produce un motor de reglas. Una fase de la cadena de ataque aparece en la salida únicamente cuando hay hallazgos que la respaldan, lo que significa que el resumen no puede afirmar un paso que la evidencia no sostiene — el modo de fallo característico del texto generado, y la razón por la que el texto generado no puede citarse como evidencia.

Ambos campos siguen siendo resúmenes y no evidencia. La evidencia es sections, y sections es lo que corresponde incorporar a un expediente de incidente.

coverage, analyzer_version y toolchain

Estos tres bloques determinan si un informe es defendible.

coverage registra qué pudo examinar el análisis. Una muestra cuyo manifiesto no se pudo parsear no es una muestra limpia, y un informe que no distingue entre «examinado, sin hallazgos» y «no se pudo examinar» no sostiene una conclusión firmada.

analyzer_version y toolchain registran qué produjo el resultado. Esto es operativamente significativo porque el motor de análisis está versionado y cambia con el tiempo. El 19 de septiembre de 2026 el conjunto de firmas de SDK pasó de 35 a 87 y se incorporó la detección de Log4j. Un informe generado a partir de esa fecha puede contener legítimamente hallazgos ausentes en una ejecución anterior sobre el mismo fichero. Cuando se comparan dos análisis de una misma aplicación en fechas distintas, analyzer_version establece que la diferencia es un cambio en el motor y no una inconsistencia de éste.

Formatos de exportación

Hay seis formatos disponibles:

Acceso programático

Los flujos automatizados utilizan la API y no la subida por navegador. La API replica la secuencia del navegador:

POST /api/upload                              → devuelve upload_id
POST /api/analyze  {"upload_id": "..."}       → devuelve job_id y run_id
GET  /api/jobs/{job_id}                       → sondear hasta done o failed
GET  /api/runs/{run_id}/artifact/report.json  → recuperar el informe

job_id y run_id son UUID distintos y no son intercambiables: el job representa el trabajo, el run representa el resultado. Cuando un fichero ya se analizó previamente, /api/analyze devuelve cached: true con el job_id a nulo; no hace falta sondear, porque el informe ya existe.

La autenticación admite X-API-Key: dw_… o Authorization: Bearer dw_…. Cuando se envían ambas, prevalece la cabecera de clave de API.

El procesamiento masivo utiliza los endpoints por lotes —POST /api/batch/upload, POST /api/batch/analyze, GET /api/batch/{batch_id}—, que procesan la cosecha de un día en una sola pasada. Las exportaciones en PDF y STIX se recuperan desde sus propios endpoints de artefacto.

Dos familias de endpoints no requieren autenticación: el threat feed (GET /api/threat-feed, GET /api/threat-feed/lookup) y explore (GET /api/explore, GET /api/explore/search). Ambas sirven únicamente ejecuciones cuyo propietario optó por publicarlas y cuyo veredicto sea Malicious, High Risk o Suspicious. El feed público se publica bajo licencia CC BY 4.0. El endpoint de consulta permite comprobar un hash sin disponer de cuenta.

El escaneo en tiempo de compilación se gestiona mediante CI/CD y no por API. La GitHub Action analiza los artefactos de build y falla la compilación según umbrales de veredicto configurables. Existen cinco integraciones adicionales: GitLab, Bitrise, Jenkins, CircleCI y Azure Pipelines. La guía rápida documenta la secuencia mínima funcional; la referencia de API, los esquemas.

Alcance y limitaciones

Todo lo anterior es análisis estático. El análisis estático establece capacidad y no comportamiento: lo que una aplicación puede hacer, no lo que hizo durante su ejecución. Esto basta para la mayoría de decisiones de triaje y está disponible en minutos.

Cuando una decisión depende del comportamiento en ejecución, se aplican tres restricciones:

• El análisis dinámico está disponible sólo para Android. No existe instrumentación en ejecución para iOS.
• El análisis dinámico se ejecuta contra el dispositivo o emulador del propio cliente, conectado mediante el agente de Droidwatch. Ninguna muestra se ejecuta en infraestructura de Droidwatch. Para organizaciones que procesan muestras de sus clientes bajo obligaciones de residencia de datos éste es el diseño pretendido, si bien exige configuración del lado del cliente. El análisis dinámico está disponible desde el plan Pro; los planes superiores amplían la ventana de ejecución de 300 a 450 segundos e incrementan la asignación mensual de emulador.
• El sandbox alojado en la nube no está en producción. Las descripciones del análisis dinámico de Droidwatch como sandbox alojado son inexactas.

El análisis de .ipa en iOS ejecuta siete módulos estáticos: 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 componente en ejecución para iOS en ningún plan.

Planes y límites

Todos los planes ejecutan la misma cadena de análisis. Los niveles de plan rigen el rendimiento, el tamaño de fichero y la retención, no la profundidad del análisis. El análisis dinámico y el acceso a la API arrancan en Pro, con 30 minutos de emulador al mes; Team dispone de 90 y Enterprise de 150.

Preguntas frecuentes

¿El análisis de APK está disponible sin coste? Sí. Una cuenta gratuita proporciona cinco análisis diarios con la cadena estática completa, mapeo MITRE ATT&CK Mobile, cobertura MASVS y los seis formatos de exportación, incluido STIX 2.1. Sin cuenta se dispone de tres análisis diarios.

¿Se comparten las muestras enviadas con terceros? Los envíos son privados por defecto. Los indicadores se publican en el threat feed público únicamente en las ejecuciones cuyo propietario optó por ello. Esto difiere de los servicios multi-escáner gratuitos, donde los envíos del plan gratuito suelen quedar disponibles para otros clientes, restricción que impide utilizarlos con muestras de clientes que contengan datos personales. Las prácticas de manejo y divulgación están documentadas en la página de confianza.

¿En qué se diferencia de VirusTotal? VirusTotal responde a si un hash ha sido observado y cómo lo clasificaron los motores participantes. Es la primera consulta adecuada. No proporciona razonamiento por hallazgo, análisis del certificado, mapeo ATT&CK ni un informe apto para presentar ante un comité de revisión. Hay disponible una comparativa detallada.

¿En qué se diferencia de una instancia propia de MobSF? En el plano del análisis la diferencia es limitada; MobSF es un motor solvente y buena parte de la disciplina de seguridad móvil se construyó sobre él. La diferencia es operativa: sin orquestación de contenedores, sin escalado de workers, sin mantenimiento de dependencias, y con multi-tenant, control de acceso por roles, traza de auditoría, facturación e inteligencia de amenazas. La comparativa completa documenta el trade-off.

¿Cuál es el tiempo de análisis previsto? De dos a cinco minutos para un APK de 50 MB; de ocho a diez minutos de media para paquetes por encima de 100 MB.

Envía un APK a análisis. No se requiere método de pago.