SMS-Xombie: Spyware para Android para Extraer Datos del Teléfono

SMS-Xombie es un spyware para Android que interactúa con un servidor remoto de Comando y Control (C&C) para extraer datos del teléfono. Es una prueba de concepto académica publicada en 2020 sobre el SDK 29 de Android (Android 10). Puedes leer el artículo original completo del autor aquí.

Nota de contexto: este proyecto es de 2020 y está construido sobre Android 10 (SDK 29). Desde Android 11 (API 30) en adelante, las APIs y permisos relacionados con acceso a SMS, registros de llamadas (READ_CALL_LOG separado del grupo PHONE desde Android 9 y endurecido con permisos one-time y auto-reset), contactos, almacenamiento (Scoped Storage) e identificadores únicos del dispositivo cambiaron sustancialmente.

Además, las restricciones de background execution limits y los tipos obligatorios de Foreground Services impiden el despliegue directo. El código no compila ni se despliega tal cual en versiones modernas. El valor del proyecto hoy es educativo: estudiar la arquitectura, no reproducir el ataque.

El objetivo del proyecto es el despliegue de una aplicación Android que interactúe con un servidor remoto de Comando y Control (C&C) como spyware. SMS-Xombie también incorpora una Raspberry Pi equipada con una antena del Sistema Global para Móviles (GSM) con el único propósito de recibir comandos de un teléfono móvil controlador.

En resumen, el paquete de aplicaciones —considerado como un dispositivo “zombi” único— se comunica con el servidor utilizando peticiones HTTP GET para obtener comandos en formato JSON, y HTTP POST para enviar datos sensibles como los registros de SMS, la agenda de contactos o la ubicación geográfica de vuelta al servidor, que se procesan mediante un script PHP.

Implementación

Aplicación Android

La aplicación contiene los siguientes dos módulos:

• Fetcher Service — realiza operaciones clave en segundo plano y no requiere interacción del usuario.
• Autostart Receiver — un componente activado por el evento de finalización de arranque para invocar el servicio anterior.

Cuando la aplicación se instala y se abre, registra el receptor que se invocará durante el arranque de Android RECEIVE_BOOT_COMPLETED (después de que los servicios del sistema se carguen completamente). La función principal de este BroadcastReceiver es programar un AlarmManager para que inicie el servicio Fetcher periódicamente, haciéndolo así persistente en el dispositivo.

Este vector enfrenta restricciones operativas en Android moderno: desde Android 8 los background execution limits obligan a usar un Foreground Service con notificación visible para que un servicio iniciado desde BOOT_COMPLETED o AlarmManager siga ejecutándose, y desde Android 11 en adelante se suman App Standby Buckets, Battery Optimization, el permiso SCHEDULE_EXACT_ALARM para alarmas exactas y prohibiciones al lanzamiento de ciertos Foreground Services desde BOOT_COMPLETED en Android 15+.

Dentro del servicio Fetcher, hay varias partes de código que comienzan con onStartCommand() y que:

• Comprueban o almacenan permanentemente un Universal Unique Identifier (UUID) generado al azar para identificar de forma exclusiva el dispositivo.
• Validan la conexión de red del dispositivo y la accesibilidad del servidor remoto.

Inicialmente, se genera un UUID del dispositivo para identificar de forma única a un “zombi”. Este ID se utiliza más tarde como parámetro de consulta en sus peticiones GET regulares a un endpoint de la API (PHP) que responde con datos codificados en JSON; por lo tanto, JsonObject() se utiliza junto a HttpURLConnection para interactuar con la API. La respuesta es manejada por la función onPostExecute() si la conexión fue exitosa y existe conectividad de red según el método booleano isConnected().

Si todo es correcto, el móvil responderá a la tarea en consecuencia. Para enviar los datos de vuelta se utiliza la librería Volley HTTP, que facilita el trabajo en red en aplicaciones Android.

Plataforma Xombie

La aplicación es parte de un sistema más grande, la Plataforma Xombie. La idea es simple: usando un mensaje SMS a través de la red GSM, se controlan múltiples dispositivos que ejecutan el APK a través del servidor C&C. La implementación, sin embargo, es compleja debido al siguiente proceso:

1. Implementación de una Raspberry Pi con un GSM shield conectado para recibir mensajes SMS de un teléfono móvil controlador a través de la red GSM.
2. Construcción de un mecanismo de interconexión entre la API y el dispositivo físico.
3. Capacidad de procesar de forma distintiva el tráfico entrante de los demás dispositivos móviles y responder con el contenido apropiado de cada dispositivo.

Para una visión más amplia, el procedimiento anterior se ilustra en el siguiente esquema:

Inicialmente, el dispositivo controlador envía un comando a través de un mensaje SMS para recuperar la ubicación geográfica de todos los teléfonos móviles (palabra clave getGeoLocation). El GSM shield, que puede operar en las bandas de frecuencia Quad 850/900/1800/1900 MHz, utiliza una tarjeta SIM local para recibir el mensaje y reenviar el contenido del SMS a la API smsXlib, que luego pone la tarea en la cola del servidor de alojamiento.

Teniendo en cuenta que los dispositivos móviles envían periódicamente solicitudes HTTP para comprobar si hay tareas pendientes, en este caso enviarían inmediatamente los valores de latitud y longitud pertinentes como una solicitud POST (siempre que el usuario haya concedido permiso al servicio de localización de la aplicación).

Capacidades

La aplicación tiene las siguientes capacidades:

• SMS dump (smsdump) — vuelca todo el historial de mensajes.
• Contacts dump (contactsDump) — vuelca toda la lista de contactos.
• Call Logs Dump (callsDump) — vuelca las entradas de llamadas.
• Geographical Location Fetch (getGeoLocation) — recupera los valores actuales de latitud y longitud del dispositivo.
• Application List Dump (appsDump) — muestra las aplicaciones instaladas por el usuario.
• Device Information Retrieval (deviceInfo) — recupera información del dispositivo.
• Calendar Entries Dump (calendarsDump) — vuelca las entradas de calendario existentes.
• Service Termination (kill) — termina el servicio en curso hasta el próximo arranque.

Uso

El programa está pensado básicamente para conectar y usar; basta con modificar el valor de la URL del C&C en el archivo de recursos res/values/strings.xml y configurar el script PHP de servicio según las indicaciones del repositorio del autor.

Qué sigue siendo válido conceptualmente

Aunque el código está atado a una versión obsoleta de Android, varios patrones de diseño que utiliza siguen siendo relevantes para entender cómo funcionan muchas familias de spyware modernas:

• Arquitectura C&C sobre HTTP polling. El cliente consulta periódicamente un endpoint para obtener tareas en JSON y devuelve los resultados por POST. Es un patrón clásico de bajo perfil que se mezcla con tráfico web legítimo y se sigue viendo en variantes actuales.
• Persistencia con BroadcastReceiver + AlarmManager. El uso de RECEIVE_BOOT_COMPLETED para reactivar el servicio en cada arranque es el esquema histórico de persistencia en Android. Las versiones modernas restringen este vector con políticas de background execution y restricciones de batería, pero el principio sigue siendo el punto de partida del que parten todas las técnicas más nuevas.
• SMS como canal de control out-of-band. Usar la red GSM como vía de mando paralela al canal IP permite controlar el dispositivo incluso si hay filtrado de red, y desacopla al operador del controlador de la infraestructura del C&C.

Para quien quiera profundizar en este tipo de arquitectura conviene revisar también qué es un command and control y qué es spyware.

Descargo de Responsabilidad

El uso de esta aplicación para atacar objetivos sin previo consentimiento mutuo es ilegal. Es responsabilidad del usuario final obedecer todas las leyes locales, estatales y federales aplicables. EsGeeks no asume ninguna responsabilidad y no se hace responsable de ningún mal uso o daño causado.

Repositorio del proyecto: https://github.com/artikrh/SMS-Xombie