Toma mi dinero de una vez: Ladrones de carteras criptográficas en Google Play y App Store

En marzo de 2023, investigadores de ESET descubrieron implantes maliciosos integrados en versiones modificadas de varios mensajeros instantáneos. Algunos de ellos buscaban en la galería del usuario imágenes con frases que permitan restaurar el acceso a las billeteras de criptomonedas (recovery phrases). En la búsqueda se utilizaba un modelo de OCR, con cuya ayuda se seleccionaban imágenes del dispositivo de la víctima para exfiltrarlas al servidor de C2. Durante la campaña maliciosa que aquí describimos y que está dirigida a usuarios de dispositivos con Android y Windows, el malware se distribuyó a través de orígenes no oficiales. A finales de 2024, descubrimos una nueva campaña de malware, a la que llamamos SparkCat, en la cual los atacantes utilizaban tácticas similares, pero atacaban a usuarios de Android e iOS, incluso a través de las tiendas oficiales. Nuestras conclusiones en pocas palabras:

• Encontramos aplicaciones para Android e iOS que traían integrado un SDK / marco malicioso para robar frases de recuperación de billeteras criptográficas, algunas de las cuales estaban disponibles en Google Play y App Store. Las aplicaciones infectadas se descargaron de Google Play más de 242 000 veces. Este es el primer caso conocido de un stealer que logra ingresar a la App Store.
• El módulo malicioso para Android descifraba y lanzaba un complemento de OCR basado en la biblioteca Google ML Kit, que se utilizaba para reconocer texto en las imágenes de la galería del dispositivo. Utilizando palabras clave que recibía del servidor C2, el troyano le enviaba las imágenes. El malware para iOS tenía un diseño similar y también utilizaba la biblioteca ML Kit de Google para realizar el OCR.
• El malware, al que llamamos SparkCat, utilizaba un protocolo no identificado para comunicarse con el C2, implementado en el lenguaje Rust, lo cual es raro para aplicaciones móviles.
• Según las marcas de tiempo que encontramos en los archivos de malware y las fechas de creación de los archivos de configuración en los repositorios de GitLab, SparkCat ha estado activo desde marzo de 2024.

Apple y Google ya eliminaron de la App Store y Google Play todas las aplicaciones infectadas con el troyano SparkCat.

SDK malicioso en aplicaciones disponibles en Google Play

La primera que nos pareció sospechosa fue una aplicación de entrega de comida en los Emiratos Árabes Unidos e Indonesia, llamada ComeCome (nombre del paquete: com.bintiger.mall.android), que en el momento del análisis estaba disponible en Google Play y se había instalado más de 10 000 veces.

En la versión 2.0.0 de la aplicación (f99252b23f42b9b054b7233930532fcd), se anuló el método onCreate en el heredero de la clase Application, que es uno de los puntos de entrada de la aplicación. Este método inicializa un componente del SDK llamado Spark. En el original estaba ofuscado, así que primero lo desofuscamos de forma estática para luego comenzar a analizarlo.

Spark está escrito en Java. Cuando se inicializa, descarga un archivo de configuración cifrado en formato JSON desde GitLab utilizando una URL indicada en el código del malware. El archivo JSON se decodifica utilizando base64 y luego se descifra utilizando AES-128 en modo CBC.

Si el SDK no puede obtener una configuración, se utilizarán las configuraciones predeterminadas.
Pudimos descargar la siguiente configuración desde GitLab:

Los campos http y rust contienen las direcciones de los servidores de comandos SDK, y el indicador tfm controla la elección del C2. Si tfm es igual 1, se utilizará rust como servidor de comandos; en todos los demás casos, http.

Para comunicarse con el servidor http, Spark utiliza solicitudes POST. Los datos se cifran utilizando AES-256 en modo CBC antes de enviarse, y la respuesta del servidor se descifra utilizando AES-128 en modo CBC. En ambos casos, las claves son constantes escritas en el código.

La transferencia de datos al servidor rust se produce en tres etapas:

• Los datos se cifran mediante AES-256 en modo CBC con la misma clave que para el servidor http.
• Se genera el siguiente archivo JSON, donde <PATH> es la ruta para cargar datos, y <DATA> son datos cifrados de la etapa anterior.

• Este JSON se envía al servidor utilizando la biblioteca nativa libmodsvmp.so a través de un protocolo no identificado que usa sockets TCP. La biblioteca está escrita en el lenguaje de programación Rust y se disfraza como un popular ofuscador de Android.

El análisis estático del código de la biblioteca resultó complicado porque Rust utiliza una convención de llamadas no estándar y faltaban los nombres de las funciones en el archivo. Después del análisis dinámico mediante Frida, pudimos reconstruir el patrón de interacción. Antes de enviar los datos al servidor, la biblioteca genera una clave de 32 bytes para el cifrado AES-GCM-SIV, utilizado para cifrar los datos que se envían, los que previamente se comprimen mediante ZSTD. El valor nonce para el algoritmo no se genera: está indicado en el código y siempre es igual al “unique nonce” (sic).

La clave AES se cifra mediante RSA, cuya clave pública se transmite al llamar al método nativo desde el SDK malicioso en formato PEM y luego también se envía al servidor. La alineación al cifrar la clave AES se logra agregando 224 bytes aleatorios al comienzo del mensaje. El servidor del atacante, tras recibir la solicitud, descifra la clave AES con la clave RSA privada, decodifica los datos recibidos, luego comprime la respuesta usando ZSTD y la cifra usando el algoritmo AES-GCM-SIV. La respuesta del servidor después de la decodificación en la biblioteca nativa se transfiere al SDK, donde se decodifica utilizando base64 y se descifra según el mismo principio que cuando interactúa con el servidor http. A continuación se muestra un ejemplo de comunicación entre el módulo malicioso y el servidor Rust.

La traducción

Longitud del paquete (big endian) Tamaño del blob RSA (big endian)
Clave AES cifrada con RSA
Datos comprimidos con ZSTD y cifrados con AES
Datos comprimidos con ZSTD y cifrados con AES

Después de cargar la configuración, Spark descifra y ejecuta la carga útil de los recursos en un hilo separado. El cifrado utilizado es XOR con una clave de dieciséis bytes.

La carga útil (c84784a5a0ee6fedc2abe1545f933655) es un contenedor para trabajar con la interfaz TextRecognizer de la biblioteca Google ML Kit. Carga diferentes modelos de OCR según el idioma del sistema para distinguir los caracteres latinos, coreanos, chinos y japoneses en las imágenes. Luego, el SDK carga información sobre el dispositivo al servidor de comandos a través de la ruta /api/e/d/u y, en respuesta, recibe un objeto que regula el funcionamiento futuro del malware. El objeto es un archivo JSON con la estructura que se muestra a continuación. El indicador uploadSwitch permite que el malware continúe funcionando (valor 1).

Luego, el SDK registra un controlador de eventos del ciclo de vida de la actividad de la aplicación que, cuando un usuario contacta al chat de atención al cliente implementado mediante el componente legítimo de terceros Easemob HelpDesk SDK, solicita permiso para leer imágenes de la galería. Si el indicador pw en el objeto anterior es 1, entonces, en caso de rechazo, el módulo solicitará permisos nuevamente. A primera vista, el motivo utilizado por el SDK a la hora de realizar una solicitud no parece plantear ninguna duda: al contactar con la atención al cliente, el usuario efectivamente puede adjuntar imágenes.

Si se conceden los permisos, el SDK ejecutará su funcionalidad principal. Comienza con una solicitud al C2 en /api/e/config/rekognition, que recibirá parámetros para procesar los resultados del OCR en respuesta.

Estos parámetros utilizan clases-procesadores que filtran las imágenes en función de las palabras que el modelo OCR reconoce en ellas. El malware también solicita una lista de palabras clave en la ruta /api/e/config/keyword para el procesador KeywordsProcessor, que las utiliza para seleccionar las imágenes que se cargarán al servidor de comandos.

Además de KeywordsProcessor, el malware contiene otros dos procesadores: DictProcessor y WordNumProcessor. El primero filtra las imágenes basándose en diccionarios localizados que se encuentran cifrados en el archivo rapp.binary en los recursos; el segundo, basándose en la cantidad de palabras de una determinada longitud. Los parámetros letterMin y letterMax para cada procesador especifican el rango de longitudes de palabra aceptables. Para DictProcessor, el parámetro wordlistMatchMin controla el número mínimo de palabras del diccionario que se deben encontrar en la imagen; para WordNumProcessor, los parámetros wordMin y wordMax controlan el diapasón dentro del cual debe caer el número de palabras reconocidas. El campo rs en la respuesta a la solicitud de registro del dispositivo infectado determina cuál de los procesadores se utilizará.

Las imágenes que coinciden con la búsqueda se descargan del dispositivo en tres etapas. Primero, se envía una solicitud al C2 con la ruta /api/e/img/uploadedCheck, que contiene el hash MD5 de la imagen. Luego, la imagen se carga al almacenamiento en la nube de Amazon o al servidor rust a través de file@/api/res/send, tras lo cual el enlace a la misma se carga al C2 a través de /api/e/img/rekognition. Por lo tanto, el SDK, que, a juzgar por el nombre del paquete com.spark.stat, estaba destinado al análisis, en realidad es malicioso y roba selectivamente contenido de la galería.

Nos preguntamos qué tipo de imágenes les interesaba a los atacantes. Para ello, solicitamos de forma independiente a los servidores de comando una lista de palabras clave para la búsqueda de OCR. En cada caso, recibimos respuestas en chino, japonés, coreano, inglés, checo, francés, italiano, polaco y portugués. Todas estas palabras indican la motivación financiera de los atacantes: están interesados en frases para restaurar el acceso a las billeteras de criptomonedas, conocidas como mnemónicos.

Desafortunadamente, el componente malicioso no sólo logró infectar la aplicación ComeCome; también encontramos otras aplicaciones no relacionadas sobre diferentes temas que se habían instalado más de 242 000 veces al momento de escribir este artículo (consulte la sección Indicadores de compromiso para obtener una lista completa) y algunas de ellas todavía estaban disponibles en Google Play. Alertamos a Google sobre la presencia de aplicaciones infectadas en la tienda y los eliminaron.

Además, según nuestros datos de telemetría, las aplicaciones infectadas también se distribuyeron a través de fuentes no oficiales.

La funcionalidad del SDK puede variar ligeramente según la aplicación. Por ejemplo, mientras que el malware de ComeCome solo pedía permiso al abrir un chat con la atención al cliente, en otros el detonante era el lanzamiento de la funcionalidad principal de la aplicación.

Un pequeño detalle…

Al analizar las aplicaciones Android troyanizadas, notamos que al enviar información sobre un dispositivo infectado al C2, el SDK malicioso llena el campo deviceType con el valor android, lo que indica la existencia de un troyano similar para otras plataformas.

Realizamos un estudio y descubrimos que hay aplicaciones para iOS en la App Store infectadas con un marco malicioso con el mismo troyano. Por ejemplo, la aplicación de entrega de comida ComeCome para iOS estaba infectada, al igual que su versión para Android. Este es el primer caso conocido de una aplicación infectada con software espía OCR en una tienda oficial de Apple.

Marcos maliciosos en aplicaciones de la App Store

Hemos identificado una serie de aplicaciones que tenían un marco malicioso incorporado en la App Store. No tenemos información precisa sobre si se infectaron como resultado de un ataque a la cadena de suministro o si los desarrolladores incorporaron intencionalmente un troyano en ellos. Algunas aplicaciones, como los servicios de entrega de comida, parecen legítimas, mientras que otras están claramente diseñadas para atraer a las víctimas. Por ejemplo, hemos visto varios “mensajeros” similares con funciones de inteligencia artificial del mismo desarrollador:

En algunas aplicaciones infectadas, además del propio marco malicioso, en la carpeta raíz estaba presente el script modify_gzip.rb, que al parecer fue utilizado por los atacantes durante la etapa de desarrollo para integrar el marco en la aplicación:

El marco está escrito en Objective-C y ofuscado mediante el ofuscador HikariLLVM. En las aplicaciones que encontramos, tenía uno de estos tres nombres:

1. GZIP
2. googleappsdk
3. stat

Al igual que la versión para Android, el malware para iOS utiliza la interfaz ML Kit, que le permite trabajar con el modelo OCR de Google entrenado para reconocimiento de texto, así como una biblioteca en Rust que implementa el mismo protocolo casero para comunicarse con C2, pero en este caso está incrustado en el archivo ejecutable malicioso. A diferencia de la versión para Android, el marco iOS conserva los símbolos de depuración, lo que nos permite destacar algunos detalles únicos al respecto:

• Las líneas muestran las rutas donde se encontraba el proyecto en el dispositivo de los autores del marco, en las cuales aparecen los nombres de los usuarios:
  • /Users/qiongwu/ es el directorio de inicio del autor del proyecto.
  • /Users/quiwengjing/ — directorio de inicio del autor de la biblioteca Rust.
• El módulo responsable de la interacción de la red con el C2 rust se llama Además de la parte del cliente, también incluye código que, según suponemos, usa el servidor de los atacantes para interactuar con las víctimas.
• El nombre original del proyecto es GZIP.

El marco incluye varias clases maliciosas, entre las cuales podemos resaltar las más interesantes:

• MMMaker: implementa la carga de la configuración y la recopilación de información sobre el dispositivo.
• ApiMgr: diseñada para enviar datos sobre el dispositivo.
• PhotoMgr: busca el dispositivo y carga en el servidor las fotos que contienen palabras clave.
• MMCore: se utiliza para almacenar información sobre la sesión con el C2.
• MMLocationMgr: recopila información actualizada sobre la ubicación del dispositivo. Durante las pruebas, no envió estos datos a ninguna parte, por lo que el propósito final de su existencia aún no queda claro.

Vale la pena señalar que en versiones anteriores del marco, algunas clases, como MMMaker, pueden faltar o tener un nombre diferente, pero el comportamiento básico del malware no cambia.

La ofuscación hace que el proceso de análisis estático de muestras sea bastante complicado, ya que las cadenas están encriptadas y el código selector se ejecuta dentro de una máquina virtual. Para descifrar rápidamente las cadenas que nos interesaban, usamos el análisis dinámico, ejecutando la aplicación bajo Frida y recolectando un volcado de la sección _data en la que están almacenadas. Nos llamó la atención la presencia entre los datos descifrados del identificador de paquete (bundleID) de la aplicación investigada:

Resulta que el marco también almacena los identificadores de paquetes de otras aplicaciones y se utilizan en el selector +[MMCore config].

 

im.pop.app.iOS.Messenger	com.hkatv.ios	com.atvnewsonline.app
io.zorixchange	com.yykc.vpnjsq	com.llyy.au
com.star.har91vnlive	com.jhgj.jinhulalaab	com.qingwa.qingwa888lalaaa
com.blockchain.uttool	com.wukongwaimai.client	com.unicornsoft.unicornhttpsforios
staffs.mil.CoinPark	com.lc.btdj	com.baijia.waimai
com.ctc.jirepaidui	com.ai.gbet	app.nicegram
com.blockchain.ogiut	com.blockchain.98ut	com.dream.towncn
com.mjb.Hardwood.Test	com.galaxy666888.ios	njiujiu.vpntest
com.qqt.jykj	com.ai.sport	com.feidu.pay
app.ikun277.test	com.usdtone.usdtoneApp2	com.cgapp2.wallet0
com.bbydqb	com.yz.Byteswap.native	jiujiu.vpntest
com.wetink.chat	com.websea.exchange	com.customize.authenticator
im.token.app	com.mjb.WorldMiner.new	com.kh-super.ios.superapp
com.thedgptai.event	com.yz.Eternal.new	xyz.starohm.chat
com.crownplay.luckyaddress1

De esto sacamos las siguientes conclusiones:

1. El comportamiento del troyano puede variar según la aplicación en la que se ejecute.
2. Hay más aplicaciones que podrían estar infectadas de lo que creíamos al principio.

Algunas de las aplicaciones asociadas a estos identificadores ya habían sido eliminadas de la App Store en el momento del estudio, mientras que otras todavía estaban presentes y contenían el marco malicioso. Entre la lista de identificadores de aplicaciones también hay algunas que no contenían un marco malicioso en el momento del estudio:

• com.kh-super.ios.superapp
• im.token.app
• com.unicornsoft.unicornhttpsforios

Al igual que en Android, el troyano implementa tres modos de filtrado de los resultados de OCR: por palabras clave, por número de palabras de una longitud determinada y por diccionarios localizados que se almacenan de forma cifrada directamente dentro del marco, en archivos de la carpeta de listas de palabras. Lamentablemente, no pudimos verificar si el malware realmente utilizaba esto último: ninguna de las muestras que examinamos contenía referencias a estos diccionarios en sus cuerpos ni accedió a ellos durante su funcionamiento.

El paso más importante en el trabajo del marco malicioso es enviar las fotos que selecciona y que contienen las palabras clave. Al igual que en Android, el troyano solicita permiso para acceder a la galería sólo cuando se inicia el controlador de UI (View Controller), responsable de mostrar el chat de la asistencia al cliente. En la etapa de inicialización, dependiendo de la aplicación en la que se lance, el troyano reemplaza el método viewDidLoad o viewWillAppear del controlador correspondiente con su contenedor, que llama al método +[PhotoMgr startTask:], que luego verifica si la aplicación tiene acceso a la galería y lo solicita si es necesario. A continuación, si obtiene los derechos, PhotoMgr intentará encontrar entre las fotos disponibles y que aún no hayan sido procesadas, aquellas que cumplan las condiciones de envío.

La traducción

Id. de paquetes de aplicaciones infectadas
Nombres de vewController correspondientes
Envoltura maliciosa del método viewDidLoad

Lo intentamos varias veces, hasta que logramos forzar a la aplicación a enviar una imagen a la nube de Amazon y luego reportar información sobre la imagen cargada al servidor de los atacantes. En este caso, la comunicación con el servidor se realizó a través del protocolo HTTPS, y no a través del “rust” casero:

Los datos que se envían son:

De todas las versiones del marco malicioso que analizamos, la más temprana fue la compilada el 15 de marzo de 2024. No hay grandes diferencias entre esta y las versiones más recientes, pero contiene una mayor cantidad de cadenas sin cifrar, como los puntos finales de la API. La dirección del C2 es una sola y está codificada en el código del marco, y las respuestas del servidor no están cifradas.

Peculiaridades de la campaña

Durante nuestro análisis de las aplicaciones de Android, descubrimos que los procesadores de texto contenían en su código comentarios en chino. El servidor C2 también devuelve descripciones de errores en chino en respuesta a solicitudes incorrectas. Esto, así como el nombre de la carpeta de inicio del desarrollador del marco obtenido durante el análisis de la versión iOS, nos da motivos para creer que el desarrollador del módulo malicioso habla chino con fluidez. Sin embargo, los datos disponibles son insuficientes para atribuir la campaña a un determinado grupo conocido.

Durante el estudio, pudimos establecer la motivación de los atacantes: roban frases para restaurar el acceso a las billeteras criptográficas, que son suficientes para obtener el control total sobre la billetera de la víctima para después robarle fondos. Vale la pena señalar que la flexibilidad del malware no sólo le permite robar frases secretas, sino también otros datos personales de la galería, como el contenido de los mensajes o las contraseñas que puedan haber quedado en las capturas de pantalla. Al mismo tiempo, la presencia de varios modos de procesamiento de los resultados del OCR (procesadores) reduce el impacto de los errores del modelo que, en el caso de procesar sólo palabras clave, podrían afectar negativamente el reconocimiento de la frase para restaurar el acceso presente en la imagen.

Al analizar el código malicioso de Rust en los marcos de iOS, encontramos tanto el código de cliente para comunicarse con el servidor Rust como una parte del código del servidor responsable del cifrado de datos. Esto nos da motivos para creer que el protocolo de trabajo en los servidores de los atacantes también está implementado en Rust.

En base a los siguientes hechos, creemos que esta campaña está dirigida al menos a los usuarios de Android e iOS en Europa y Asia:

• Las palabras clave estaban en diferentes idiomas, cuyos hablantes nativos son residentes de países europeos y asiáticos.
• Los diccionarios en los activos tenían la misma localización que las palabras clave.
• Algunas aplicaciones parecen funcionar en varios países. Por ejemplo, las aplicaciones de entrega de comida individuales permiten a los usuarios registrarse con números de teléfono de los Emiratos Árabes Unidos, Kazajstán, China, Indonesia, Zimbabue y otros países.

Al mismo tiempo, no descartamos que algunos usuarios de dispositivos móviles fuera de las regiones designadas pudieran haberse convertido en víctimas de la campaña maliciosa.

Uno de los primeros módulos de malware que comenzamos a investigar se llamaba Spark. Al mismo tiempo, al analizar el malware de iOS, nuestra atención se centró en el identificador del paquete del propio marco malicioso: bigCat.GZIPApp. Por esta razón llamamos al troyano SparkCat. También podemos destacar las siguientes características distintivas de este malware:

• funciona en múltiples plataformas;
• usa el lenguaje Rust, que rara vez se encuentra en aplicaciones móviles;
• usa las tiendas oficiales de aplicaciones como uno de los vectores de distribución;
• sigilo: los dominios del C2 a menudo imitaban servicios legítimos, y los marcos maliciosos, paquetes de servicios;
• usa ofuscación para dificultat el análisis y la detección.

Conclusión

Desafortunadamente, a pesar de la estricta moderación en las plataformas oficiales, así como de la notoriedad del esquema para robar billeteras criptográficas usando OCR, estas aplicaciones infectadas terminaron en Google Play y App Store. El troyano es muy peligroso porque nada revela el implante malicioso dentro de la aplicación: los permisos que solicita pueden usarse en la funcionalidad principal de la aplicación o pueden parecer inofensivos a primera vista, y el malware opera de forma bastante encubierta. Este caso destruye una vez más el mito de que las amenazas que plantean las aplicaciones maliciosas para Android no son relevantes para iOS. Para no convertirse en víctima de este malware, le recomendamos hacer lo siguiente:

• Si tiene instalada una de las aplicaciones infectadas, elimínela de su dispositivo y no la use hasta que se publique un parche que elimine la funcionalidad maliciosa.
• No almacene capturas de pantalla con información confidencial en la galería, incluidas frases de recuperación para acceder a billeteras de criptomonedas. Las contraseñas, documentos confidenciales y otros datos sensibles se pueden almacenar en aplicaciones especiales.
• Utilice una solución de seguridad confiable en todos sus dispositivos.

Nuestras soluciones de seguridad detectan malware asociado a esta campaña con los siguientes veredictos:

• HEUR:Trojan.IphoneOS.SparkCat.*
• HEUR:Trojan.AndroidOS.SparkCat.*

Apple y Google ya eliminaron de la App Store y Google Play todas las aplicaciones infectadas con el troyano SparkCat.

Indicadores de compromiso

Aplicaciones Android infectadas
0ff6a5a204c60ae5e2c919ac39898d4f
21bf5e05e53c0904b577b9d00588e0e7
a4a6d233c677deb862d284e1453eeafb
66b819e02776cb0b0f668d8f4f9a71fd
f28f4fd4a72f7aab8430f8bc91e8acba
51cb671292eeea2cb2a9cc35f2913aa3
00ed27c35b2c53d853fafe71e63339ed
7ac98ca66ed2f131049a41f4447702cd
6a49749e64eb735be32544eab5a6452d
10c9dcabf0a7ed8b8404cd6b56012ae4
24db4778e905f12f011d13c7fb6cebde
4ee16c54b6c4299a5dfbc8cf91913ea3
a8cd933b1cb4a6cae3f486303b8ab20a
ee714946a8af117338b08550febcd0a9
0b4ae281936676451407959ec1745d93
f99252b23f42b9b054b7233930532fcd
21bf5e05e53c0904b577b9d00588e0e7
eea5800f12dd841b73e92d15e48b2b71

Marcos MD5 para iOS:
35fce37ae2b84a69ceb7bbd51163ca8a
cd6b80de848893722fa11133cbacd052
6a9c0474cc5e0b8a9b1e3baed5a26893
bbcbf5f3119648466c1300c3c51a1c77
fe175909ac6f3c1cce3bc8161808d8b7
31ebf99e55617a6ca5ab8e77dfd75456
02646d3192e3826dd3a71be43d8d2a9e
1e14de6de709e4bf0e954100f8b4796b
54ac7ae8ace37904dcd61f74a7ff0d42
caf92da1d0ff6f8251991d38a840fb4a
db128221836b9c0175a249c7f567f620

Configuraciones del troyano en Gitlab
hxxps://gitlab[.]com/group6815923/ai/-/raw/main/rel.json
hxxps://gitlab[.]com/group6815923/kz/-/raw/main/rel.json

C2
api.firebaseo[.]com
api.aliyung[.]com
api.aliyung[.]org
uploads.99ai[.]world
socket.99ai[.]world
api.googleapps[.]top

Almacenamiento de fotografías
hxxps://dmbucket102.s3.ap-northeast-1.amazonaws[.]com

Nombres en Google Play de los paquetes de aplicaciones Android infectadas
com.crownplay.vanity.address
com.atvnewsonline.app
com.bintiger.mall.android
com.websea.exchange
org.safew.messenger
org.safew.messenger.store
com.tonghui.paybank
com.bs.feifubao
com.sapp.chatai
com.sapp.starcoin

Bundle ID de las aplicaciones para iOS infectadas en App Store
com.atvnewsonline.app
com.wukongwaimai.client
com.lc.btdj
com.feidu.pay
com.wetink.chat
com.websea.exchange
xyz.starohm.chat
com.crownplay.luckyaddress1
com.safew.messenger
com.thpay.bank
io.aicean.chat