Cómo identificar un paquete Android desconocido

Aparece un nombre de paquete en un ticket de soporte. Un inventario de MDM señala algo que nadie reconoce. Un cliente dicta una cadena que ha leído en Ajustes después de una llamada de la que ahora desconfía. En los tres casos la evidencia de partida es la misma: una cadena en DNS inverso como com.system.service, y nada más.

La cadena la elige quien construyó la aplicación, así que por sí sola no prueba nada. Aun así basta para empezar, y cinco comprobaciones suelen resolver la pregunta sin necesidad de tener el dispositivo delante.

Qué es un nombre de paquete

Android identifica cada aplicación instalada por un nombre de paquete escrito en DNS inverso: com.ejemplo.miapp. Tiene que ser único en el dispositivo y, para lo que se distribuye por Google Play, único en todo Play.

Tres propiedades importan para identificar:

• Lo elige quien construye la aplicación. No hay autoridad de registro ni verificación de que el dominio del nombre pertenezca al desarrollador. com.banco.seguro lo puede publicar quien llegue antes a Play o a un canal de instalación lateral.
• Es estable tras la instalación. A diferencia de la etiqueta y del icono —que una aplicación puede cambiar en ejecución—, el nombre de paquete queda fijo en la copia instalada. Eso lo convierte en un identificador utilizable incluso cuando el nombre visible engaña a propósito.
• No es una identidad. Dos aplicaciones con el mismo nombre de paquete no son necesariamente la misma aplicación. Demostrar que lo son es justamente el objeto de la tercera comprobación.

Comprobación 1 — ¿Es realmente un paquete del sistema?

Aquí es donde falla la mayoría de identificaciones, y donde funciona el patrón de nomenclatura habitual del spyware.

Los componentes propios de Android viven bajo dos prefijos:

• com.android.* — los componentes del Android Open Source Project
• com.google.android.* — las aplicaciones y servicios de Google

Cualquier otra cosa no forma parte de Android, suene como suene. Un paquete llamado com.system.service, com.android.system.core o com.systemui.service no es un paquete del sistema Android. El nombre está construido para sobrevivir exactamente al vistazo que casi todo el mundo le da: el usuario recorre su lista de aplicaciones, lee la palabra «system» y sigue.

Paquetes de sistema auténticos que la gente confunde con sospechosos: com.android.vending (la tienda de Play), com.google.android.gms (Servicios de Play) y com.android.providers.media (el almacén multimedia). Son esperables en cualquier dispositivo con servicios de Google.

Un nombre que imita a un componente del sistema y no aparece en Play es motivo para seguir, no para concluir.

Comprobación 2 — ¿Existe en Google Play?

Play expone un paquete directamente por identificador:

https://play.google.com/store/apps/details?id=<nombre-del-paquete>

Tres resultados posibles:

La página carga y coincide con lo que describe el usuario. Pasa a la tercera comprobación, que es la que decide.

La página devuelve no encontrado. El paquete no se distribuye por Play, al menos no en la región desde la que se consulta. Eso es normal en aplicaciones corporativas, distribución regional y builds de desarrollo. También es normal en malware. La ausencia es una pregunta, no una respuesta.

La página carga pero describe algo completamente distinto. O el nombre se ha reutilizado, o el usuario lo leyó mal. Confirma la cadena carácter a carácter antes de seguir: rn y m son indistinguibles en muchas interfaces, y esa sustitución se usa a propósito.

Comprobación 3 — ¿Coincide la copia instalada con la de Play?

Ésta es la comprobación que resuelve el caso, y la que normalmente se salta.

Un nombre de paquete en Play y el mismo nombre en un dispositivo sólo son la misma aplicación si llevan el mismo certificado de firma. El certificado lo emite el desarrollador, no Google, y un reempaquetador no lo puede falsificar: una build modificada lleva necesariamente otra firma.

Así que la pregunta decisiva no es «¿existe este paquete en Play?» sino «¿tiene la copia de este dispositivo el certificado que Play distribuye para él?».

Un desajuste significa que la aplicación instalada es una build reempaquetada que lleva el nombre de una aplicación legítima. En una aplicación bancaria eso es un incidente de fraude y no una curiosidad de malware, y corresponde el mismo día a protección de marca, porque el canal de distribución suele seguir activo.

Droidwatch hace esta comparación automáticamente en cada análisis de Android: identidad del paquete contra Play, más la cadena completa del certificado de firma —sujeto, emisor, ventana de validez, esquema de firma y huellas—.

Comprobación 4 — ¿Qué permisos pide?

El manifiesto declara lo que la aplicación es capaz de hacer. A efectos de identificación, el conjunto de permisos suele ser concluyente por sí mismo, porque hay combinaciones que no tienen ninguna categoría de aplicación legítima.

Las declaraciones que se leen primero:

Cualquiera de ellos tiene usuarios legítimos. Los tres primeros juntos, en un paquete que no está en Play y que imita un nombre del sistema, describen el conjunto de capacidades de un ataque por superposición. La cadena completa de capacidades explica cómo se combinan y qué aporta cada una.

Comprobación 5 — ¿De dónde salió?

Android registra qué aplicación realizó cada instalación, y ese registro responde a una pregunta que el usuario con frecuencia no puede.

Con la depuración por USB activada y el dispositivo conectado:

adb shell pm list packages -3        # sólo paquetes de terceros
adb shell pm list packages -i        # cada paquete con su instalador
adb shell pm path <nombre-del-paquete>   # ruta del APK en el dispositivo
adb shell dumpsys package <nombre-del-paquete>

dumpsys package informa de installerPackageName. Los valores que hay que reconocer:

• com.android.vending — instalado desde Google Play
• com.android.packageinstaller o com.google.android.packageinstaller — instalación lateral: un fichero abierto directamente, no una instalación desde tienda
• null — preinstalado, o instalado por un método que no registró instalador
• Cualquier otro paquete — lo instaló otra aplicación, que es el caso del dropper

Un paquete instalado lateralmente, que imita un nombre del sistema y pide accesibilidad, no es un hallazgo ambiguo.

adb shell pm path devuelve la ubicación del APK, de modo que el fichero se puede extraer con adb pull y analizar directamente, que es la única forma de responder a la pregunta de manera definitiva.

Lo que nada de esto establece

Las cinco comprobaciones establecen identidad y capacidad. No establecen comportamiento.

Una aplicación capaz de leer SMS puede no hacerlo nunca, o hacerlo sólo cuando se lo indique su servidor de mando y control. El análisis estático del paquete muestra lo que puede hacer; determinar lo que hizo exige instrumentación en ejecución o análisis forense del dispositivo.

Para la mayoría de preguntas de identificación esa distancia no bloquea la decisión. Un paquete instalado lateralmente, que imita un nombre del sistema, ausente de Play y que pide accesibilidad y superposición, es accionable sin confirmación en ejecución.

Resolverlo del todo

Las comprobaciones anteriores se pueden hacer a mano y conviene entenderlas, porque son lo que cualquier herramienta está haciendo por debajo. Ejecutarlas como un solo análisis es más rápido y produce algo que se puede adjuntar a un ticket.

Enviar el APK devuelve la identidad del paquete y la comparación con Play, la cadena completa del certificado, el análisis de permisos y componentes, el mapeo MITRE ATT&CK Mobile, los indicadores de red extraídos y una puntuación de riesgo de 0 a 100 donde más alto es peor, con bandas fijas: 65 o más Malicious, de 40 a 64 High Risk, de 20 a 39 Suspicious, por debajo de 20 Benign. Un paquete de 50 MB se completa en dos a cinco minutos.

Hay tres análisis al día sin cuenta y cinco con cuenta gratuita.

Si no se dispone del APK —habitual cuando el aviso llega de un cliente y no de un dispositivo en mano—, el threat feed público se puede consultar por hash sin cuenta, y se publica bajo licencia CC BY 4.0. Eso sólo ayuda si la muestra se ha visto antes, y por eso las cinco comprobaciones siguen siendo el recurso de partida.

El razonamiento posterior a una identificación positiva está en el flujo de triaje, y el recorrido del informe explica dónde aparece cada pieza de evidencia.

Preguntas frecuentes

¿Es único un nombre de paquete? Único en el dispositivo y único dentro de Google Play. No único en el mundo: nada impide que una aplicación distribuida fuera de Play use un nombre de paquete que pertenece a una publicada. En eso consiste el reempaquetado.

¿Puede una aplicación cambiar su nombre de paquete? No después de instalarse. La etiqueta y el icono sí cambian en ejecución; el nombre de paquete no. Por eso es el identificador fiable cuando el nombre visible engaña.

¿Un paquete ausente de Google Play es necesariamente malicioso? No. La distribución corporativa, la disponibilidad regional, los canales beta y las herramientas internas producen paquetes que no están en Play. La ausencia plantea la pregunta que responden las comprobaciones tres, cuatro y cinco.

¿Qué significa com.system.service? Por sí mismo, nada — pero no es un paquete del sistema Android. Los componentes de Android usan com.android.* y com.google.android.*. Un nombre bajo com.system.* lo eligió un desarrollador, y elegir un nombre que se lee como un componente del sistema es una decisión que merece examinarse.

¿Qué se hace con el APK una vez recuperado? Tratarlo como malware vivo: analizarlo en un entorno aislado, registrar el SHA-256 antes que nada y no redistribuir el binario. Se comparten hashes e indicadores; las muestras no.

Para identificar un paquete a partir de su APK, envíalo a análisis. No se requiere método de pago.