Resumen
- La Unidad de investigación de amenazas de Acronis (TRU) ha identificado una campaña dirigida que distribuye una versión troyanizada de la aplicación para Android Red Alert — el sistema de aviso de lanzamiento de cohetes y misiles — a usuarios israelíes mediante mensajes SMS que simulan ser comunicaciones oficiales del Comando del Frente Interior de Israel.
- La aplicación maliciosa conserva toda la funcionalidad de alertas de cohetes, lo que le permite parecer legítima mientras ejecuta código malicioso en segundo plano.
- El responsable de la amenaza implementó técnicas de suplantación de certificados ("spoofing") y manipulación en tiempo de ejecución para eludir las comprobaciones de seguridad de Android y hacer que la aplicación pareciera estar firmada de forma legítima.
- Una vez instalada, el malware supervisa los permisos concedidos y empieza a recopilar datos confidenciales, incluidos mensajes SMS, contactos, datos de ubicación, cuentas del dispositivo y aplicaciones instaladas.
- Los datos robados se almacenan provisionalmente de forma local y se transmiten continuamente a un servidor remoto de mando y control (C2) controlado por los atacantes.
- Esta campaña pone de manifiesto cómo los servicios de emergencia de confianza pueden utilizarse como vectores de ataque en periodos de tensión geopolítica, al combinar la ingeniería social y el espionaje móvil para aprovecharse de la confianza de los usuarios y maximizar el impacto.
Introducción
La Unidad de investigación de amenazas de Acronis (TRU) ha estado supervisando de forma activa campañas de malware y actividad maliciosa que aprovechan los recientes acontecimientos geopolíticos en Oriente Medio para distribuir malware a particulares. Durante nuestra investigación, TRU identificó una campaña dirigida que distribuye una versión troyanizada de la aplicación para Android Red Alert —el sistema de aviso de lanzamiento de cohetes y misiles— a usuarios israelíes a través de mensajes SMS que simulan ser comunicaciones oficiales del Comando del Frente Interior de Israel.
Esta actividad llamó la atención por el uso de un señuelo basado en una emergencia. Nuestros investigadores lo detectaron el 1 de marzo mientras buscaban amenazas maliciosas, y varios ciudadanos israelíes lo habían notificado en redes sociales.
La aplicación troyanizada imita a la legítima aplicación Red Alert — Israel (צבע אדום), que utilizan millones de ciudadanos israelíes para recibir notificaciones en tiempo real sobre lanzamientos de cohetes y misiles. Esto la convierte en un vector de ingeniería social especialmente eficaz: en periodos de conflicto activo, la urgencia por instalar o actualizar una aplicación de este tipo supera la cautela que los usuarios podrían tener en otras circunstancias, sobre todo cuando el mensaje de instalación parece proceder del Comando del Frente Interior de Israel (פיקוד העורף).
Este informe ofrece un análisis detallado de toda la cadena de infección, desde la entrega inicial mediante SMS hasta la ejecución del dropper y el despliegue de la carga útil de spyware incrustada.
Antecedentes y contexto
Numerosos grupos regionales, desde colectivos de hacktivistas hasta ciberdelincuentes vinculados a Estados, han dirigido sus ataques tanto a particulares como a organizaciones más allá de sus fronteras nacionales. Sus actividades han incluido supuestos ataques de denegación de servicios distribuidos (DDoS), intentos de intrusión en infraestructuras críticas y otras operaciones disruptivas. Grupos como Handala y otros ciberdelincuentes afiliados al Ministerio de Inteligencia y Seguridad de Irán (MOIS) han adquirido especial notoriedad en los últimos años.
Durante el seguimiento de este conjunto de actividades, encontramos múltiples testimonios de personas que afirmaban recibir mensajes con enlaces acortados para descargar e instalar software utilizado principalmente como mecanismo de alerta ante ataques con cohetes.
Un ataque similar en 2023, atribuido al grupo hacktivista AnonGhost, presenta algunas similitudes llamativas, aunque el ataque que hemos analizado parece incorporar infraestructura y código nuevos en algunas partes.
Cadena de infección
Detalles técnicos
Análisis inicial y mecanismo de entrega
Nuestra investigación comenzó tras identificar una campaña de phishing mediante SMS (o "smishing") dirigida a ciudadanos israelíes. La campaña utilizaba mensajes SMS que suplantaban el servicio oficial de alertas de cohetes "Oref Alert" e instaba a los destinatarios a instalar una versión actualizada de la aplicación debido a un supuesto fallo en el sistema de alertas. Los mensajes, enviados desde identificadores de remitente falsificados, incluían un enlace acortado de bit.ly que redirigía a las víctimas para descargar un archivo APK troyanizado que se hacía pasar por la aplicación legítima Red Alert.
El uso de servicios de acortamiento de enlaces, combinado con la urgencia de actualizar una aplicación asociada a la seguridad pública, nos llevó a analizar la aplicación maliciosa, sus capacidades y la infraestructura utilizada para controlar el malware y exfiltrar los datos y credenciales recopilados.
Cronograma
Resumen de la muestra y metadatos
Nombre de la aplicación: RedAlert.apk
Nombre del paquete: com.red.alertx
Hash SHA256: 83651b0589665b112687f0858bfe2832ca317ba75e700c91ac34025ee6578b72
Al examinar el archivo AndroidManifest.xml, comprobamos que la aplicación solicita un total de 20 permisos. Entre ellos, identificamos seis cuyo uso consideramos especialmente sensible desde el punto de vista de la seguridad debido a su potencial de abuso. El spyware utiliza estos permisos para recopilar y exfiltrar datos del usuario.
La combinación de permisos de superposición y acceso a SMS se observa con frecuencia en troyanos bancarios y campañas de spyware para Android, ya que permite a los atacantes exfiltrar mensajes confidenciales como los códigos de un solo uso (OTP).
Arquitectura de doble fase
Inicialmente, al analizar el código y renombrar clases y métodos que contenían identificadores ofuscados, identificamos que la aplicación no solo actúa como spyware, sino también como un cargador ("loader"). Por este motivo, renombramos la clase a IPackageManagerSignatureProxyLoader, ya que intercepta el IPackageManager del sistema mediante un proxy dinámico. El cargador accede a ActivityThread a través de "reflection" y reemplaza el campo original sPackageManager por su propio objeto proxy. Esto permite que la aplicación intercepte llamadas del sistema como getPackageInfo() y modifique los datos devueltos. Cuando el sistema solicita la firma de la aplicación, el cargador la reemplaza por una firma falsificada, lo que permite que el paquete malicioso (com.red.alertx) se haga pasar por la aplicación legítima.
El certificado utilizado para la suplantación ("spoofing") está codificado de forma rígida en formato Base64. Tanto en IPackageManagerSignatureProxyLoader como en la clase independiente FakeSignatureProvider, la cadena Base64 se descodifica y se convierte en un objeto Signature[]. La clase FakeSignatureProvider apunta específicamente a versiones más recientes de Android al sobrescribir métodos como getApkContentsSigners() y getSigningCertificateHistory() de la API SigningInfo. Esto confirma que el malware es compatible tanto con los mecanismos de verificación de firmas antiguos como con los modernos. Además, el cargador falsifica la fuente de instalación forzando que getInstallerPackageName() devuelva com.android.vending, de modo que la aplicación aparente haberse instalado desde Google Play.
La segunda fase del código consiste en cargar la aplicación legítima original desde la carpeta de recursos. El archivo denominado umgdn se extrae y se escribe en el directorio privado de la aplicación en /data/user/0/com.red.alertx/files/. Tras escribir el archivo, el cargador modifica campos internos del "runtime" de Android como mAppDir, sourceDir y publicSourceDir dentro de ActivityThread. Esto obliga al sistema Android a ejecutar la aplicación legítima extraída en lugar del paquete visible del dropper. Como resultado, la aplicación continúa funcionando con normalidad y mostrando alertas reales, mientras que el componente de spyware permanece oculto y opera silenciosamente en segundo plano.
Funciones
La capacidad inicial de este componente de spyware se activa en cuanto el usuario concede el permiso de SMS. Tal como se observa en el fragmento de código, el método sobrescrito onSmsPermissionGranted() invoca una función que consulta Telephony.Sms.CONTENT_URI, lo que proporciona acceso a toda la base de datos de SMS del dispositivo, lo que indica que el malware está diseñado para extraer de forma inmediata la lista de contactos del dispositivo.
La siguiente función de este malware consiste en acceder a la lista de contactos del dispositivo justo después de que el usuario concede el permiso de Contactos. Tal como se observa en el método sobrescrito onContactsPermissionGranted(), el spyware consulta ContactsContract.Contacts.CONTENT_URI, lo que proporciona acceso a las entradas de contactos almacenadas en el dispositivo. Esto confirma que el malware supervisa activamente la concesión de permisos y activa rutinas de recopilación de datos sin demora.
Un análisis adicional indica que el proceso de recopilación de contactos no se limita a nombres básicos. El spyware realiza varias consultas a proveedores de contenido para extraer números de teléfono y direcciones de correo electrónico asociados, normalmente mediante los URI de contenido CommonDataKinds.Phone y CommonDataKinds.Email. Esto permite al malware construir un conjunto de datos estructurado que incluye nombres, números de teléfono, direcciones de correo electrónico y, potencialmente, metadatos adicionales vinculados a cada entrada.
El malware también accede a la información de GPS y ubicación del dispositivo y la utiliza para decidir cuándo deben ejecutarse determinadas acciones. En el método Maynt(), obtiene la ubicación actual del dispositivo a través de una función auxiliar que, internamente, llama al componente de gestión de ubicación de la aplicación. A continuación, recupera otro conjunto de coordenadas que probablemente representa una zona objetivo predefinida, como una ciudad concreta o un área de alerta. El malware calcula la distancia entre la ubicación GPS actual de la víctima y esta ubicación objetivo mediante la API de ubicación de Android. Si el dispositivo se encuentra dentro de un radio configurado, la función permite que se lleven a cabo otras operaciones. Esto indica que el spyware no solo recopila datos de ubicación, sino que también utiliza activamente la información GPS del dispositivo para activar de forma condicional su comportamiento en función de la ubicación de la víctima.
Posteriormente, al examinar más a fondo las capacidades, se observa que el malware también implementa una funcionalidad de extracción de cuentas mediante el uso de AccountManager de Android. En el método Shatters(), el spyware resuelve e invoca dinámicamente un método interno de la clase AccountManager mediante el mecanismo "reflection" de Java. En lugar de llamar directamente a getAccounts(), obtiene el nombre del método en tiempo de ejecución y lo ejecuta de forma programática. Esta técnica se utiliza para ocultar el comportamiento malicioso y dificultar los esfuerzos de análisis estático. El resultado devuelto se convierte en un objeto Account[], lo que confirma que el malware obtiene la lista completa de cuentas registradas en el dispositivo. Entre dichas cuentas se suelen incluir las de Google, correo electrónico, servicios de mensajería y otras cuentas de aplicaciones integradas en el sistema de cuentas de Android.
Otra capacidad significativa del malware es la enumeración de todas las aplicaciones instaladas en el dispositivo infectado. En el método Unflush(), el spyware obtiene el PackageManager del sistema y solicita la lista completa de aplicaciones instaladas mediante un indicador de metadatos. A continuación, recorre cada entrada de ApplicationInfo y crea un objeto JSON estructurado para cada aplicación. Estas entradas se agrupan en una matriz ("array") y se transmiten al servidor remoto en lotes de 200 aplicaciones por envío. Las entradas restantes se transmiten una vez finalizado el bucle. Este comportamiento confirma que el malware realiza un reconocimiento sistemático del software instalado en el dispositivo, lo que permite al atacante perfilar el entorno digital de la víctima, identificar herramientas de seguridad, aplicaciones financieras, plataformas de mensajería y otros objetivos de alto valor.
Ofuscación y antianálisis
Durante el análisis se observó que la aplicación está ofuscada y codificada de forma repetida con el fin de resistir el análisis estático y la ingeniería inversa. La mayoría de los literales de cadena están codificados en Base64 y se descifran en tiempo de ejecución mediante una clave XOR única de 32 bytes para diferentes literales de cadena a lo largo del código, lo que impide que los analistas extraigan con facilidad constantes relevantes como URL o acciones de "intent". Además, los nombres de métodos y clases se han renombrado de manera agresiva con identificadores aleatorios, y se insertan funciones contenedor ("wrapper") triviales para ocultar el flujo de control real.
Infraestructura de mando y control (C2)
La infraestructura de mando y control (C2) está codificada de forma rígida dentro de la aplicación y protegida mediante una ofuscación de cadenas en varias capas. La URL se almacena en formato Base64 y se cifra adicionalmente con una clave XOR de 32 bytes, que se descodifica en tiempo de ejecución. Una vez descifrado, el endpoint resultante es hxxps://api[.]ra-backup[.]com/analytics/submit[.]php, lo que confirma que todos los datos recopilados se envían a un servidor de mando y control.
Análisis de infraestructura relacionada
Al examinar el dominio del servidor C2, se observa que se registró a través de Namecheap y se creó a mediados de 2025, lo que indica una infraestructura relativamente reciente, un patrón habitual en dominios de servidores C2 desechables creados para campañas específicas. El subdominio api[.]ra-backup[.]com aloja el endpoint de exfiltración en /analytics/submit.php, que actualmente devuelve un código 404, lo que sugiere que el C2 está protegido mediante encabezados de solicitud específicos o que ha sido desmantelado.
Atribución
A partir de las evidencias disponibles, evaluamos que esta campaña podría estar vinculada a Arid Viper (también conocido como APT-C-23). Esta valoración se sustenta en varios indicadores, entre ellos el uso de una aplicación para Android troyanizada, el enfoque en objetivos israelíes y unas capacidades de spyware coherentes con las atribuidas previamente a este grupo.
Aunque estos indicadores no son exclusivos de Arid Viper y también se han observado en otras campañas de vigilancia en Android, la convergencia de patrones de selección de objetivos, características del conjunto de herramientas utilizadas y comportamiento operativo sugiere una posible conexión con este grupo de ciberdelincuentes.
Conclusión
Esta campaña demuestra cómo una infraestructura de emergencias considerada fiable puede aprovecharse en contextos de conflicto para aumentar la eficacia de la ingeniería social y facilitar la recopilación de datos. Al incrustar spyware en una aplicación de alertas plenamente funcional, los ciberdelincuentes lograron mantener la confianza de los usuarios al tiempo que recopilaban información confidencial de manera encubierta.
La combinación de una distribución dirigida, funciones avanzadas de espionaje y múltiples capas de ofuscación apunta a un grupo de ciberdelincuentes con recursos y competencias suficientes para operar con objetivos claramente definidos.
MITRE ATT&CK
Recomendaciones y medidas de mitigación
Se recomienda que las personas y organizaciones potencialmente afectadas por esta campaña adopten las siguientes medidas:
- Instalar aplicaciones únicamente desde fuentes oficiales. La aplicación legítima Red Alert está disponible exclusivamente en Google Play. Los usuarios no deben instalar APK desde enlaces SMS, URL acortadas o sitios web de terceros, por muy urgente que parezca el mensaje.
- Verificar la identidad del remitente antes de actuar sobre mensajes SMS. El Comando del Frente Interior de Israel no distribuye actualizaciones de aplicaciones mediante SMS con enlaces acortados. Cualquier mensaje que inste a actualizar la aplicación a través de un enlace tipo bit.ly debe considerarse sospechoso.
- Revisar cuidadosamente los permisos que soliciten las aplicaciones. La aplicación legítima Red Alert solo requiere acceso a notificaciones. Si una aplicación que afirma ser Red Alert solicita permisos de SMS, contactos, ubicación o superposición de pantalla durante la instalación, casi con total seguridad es maliciosa.
- Auditar las aplicaciones instaladas en dispositivos potencialmente comprometidos. Compruebe si el paquete com.red.alertx está instalado y elimínelo de inmediato. En infecciones confirmadas, se recomienda un restablecimiento de fábrica, ya que la arquitectura de doble fase del malware puede dejar componentes residuales tras una desinstalación estándar.
- Bloquear la infraestructura de C2 conocida a nivel de red. Las organizaciones deben añadir ra-backup[.]com y api[.]ra-backup[.]com a las listas de bloqueo DNS y a las reglas de denegación del firewall. El endpoint de C2 hxxps://api[.]ra-backup[.]com/analytics/submit[.]php debe marcarse en las directivas de proxy y EDR.
- Revocar y rotar las credenciales en los dispositivos afectados. Dado que el malware recopila SMS (incluidos códigos OTP), contactos y cuentas del dispositivo, cualquier cuenta autenticada en un dispositivo comprometido debe considerarse expuesta. Se recomienda rotar contraseñas y revocar sesiones activas en cuentas de Google, correo electrónico, banca y mensajería.
- Activar Google Play Protect y mantenerlo habilitado. Play Protect añade una capa adicional de defensa frente a APK maliciosos instalados fuera de Google Play y puede alertar sobre amenazas conocidas antes de la instalación.
- Informar de SMS sospechosos a CERT‑IL y a las autoridades nacionales pertinentes para contribuir al seguimiento de la amenaza y a la desarticulación de la infraestructura de distribución.