Recientemente, el equipo de seguridad de SlowMist recibió múltiples reportes de que los activos de los usuarios fueron robados. Tras la verificación, se confirmó que los incidentes relacionados implicaban la filtración de claves privadas; en algunos de los usuarios afectados, habían descargado y utilizado la versión 1.1–1.2 de la app FomoPeek.
En colaboración con el equipo de seguridad de OKX, realizamos un análisis conjunto y confirmamos que FomoPeek 1.1 y 1.2 incorporaron dos módulos maliciosos, apptrace y libapptracecore, con capacidad de configuración remota, explotación de vulnerabilidades del kernel, evasión del sandbox, descifrado de Keychain y recopilación de datos entre aplicaciones.
La validación dinámica muestra que la aplicación obtiene desde Bitbucket una dirección C2 cifrada y reporta la información del dispositivo a api-a95f0ed200f.assisaint[.]com, además de recibir configuraciones remotas. Durante la prueba, el exploit_enabled devuelto por la C2 era false. Para verificar la ejecución de la cadena posterior, en un entorno aislado modificamos a true los conmutadores relevantes después de que el cliente descifrara mediante Hook; luego obtuvimos la lista de recopilación dirigida a 19 carteras y aplicaciones de notas, y capturamos la solicitud completa con la que se empaquetó y subió el contenedor de Apple Notes.
A través de Hook a la función de cifrado del cliente, desciframos las solicitudes y respuestas de este canal. La configuración devuelta por el servidor prueba que el atacante puede habilitar la explotación de forma remota mediante el servidor, ajustar el ciclo de ejecución y controlar su ejecución periódica repetida.
Realizamos análisis de ingeniería inversa y rastreo de muestras basándonos en las versiones históricas IPA obtenidas de canales oficiales de App Store. Los resultados muestran: en 1.0 no se encuentran los módulos maliciosos antes mencionados; en 1.1 (build 105) se inserta por primera vez el 9 de septiembre de 2026; en 1.2 (build 110) se publica el 12 de septiembre y continúa usando el mismo conjunto de código; en 1.3 (build 111) se eliminan por completo ambos frameworks el 17 de septiembre. Por lo tanto, queda claro que las versiones de app afectadas son 1.1 y 1.2; los módulos maliciosos relacionados se distribuyen mediante las versiones oficiales de App Store, no mediante re-firmado de terceros ni productos de sideload.
El intervalo de cobertura de versión del sistema declarado a nivel de código por este framework es iOS 12.0–18.7.2 e iOS 26.0–26.1, lo que muestra que su objetivo de ataque no se limita a sistemas de baja versión o a dispositivos antiguos.
Respuesta de MistEye
MistEye es un sistema de monitoreo dinámico de seguridad y de inteligencia de amenazas Web3 desarrollado de forma independiente por SlowMist. Integra capacidades de monitoreo de seguridad y agregación de inteligencia, ofreciendo a los usuarios alertas de riesgo en tiempo real y protección de activos.
MistEye sincronizó el riesgo con el sistema de alerta y el canal de notificaciones a clientes en el momento oportuno mediante notificaciones de inteligencia.
I. Antecedentes
1.1 De los reportes de usuarios al rastreo de la muestra
Algunos usuarios cuyos activos fueron robados instalaron y usaron FomoPeek antes de que ocurriera el incidente. Para verificar la relación entre esto y el evento de filtración de llaves privadas, obtenemos las versiones históricas IPA de esta aplicación desde los canales oficiales de App Store, y realizamos un análisis por versión de la estructura del paquete, dependencias de carga, asignación de la firma y el contenido binario.
1.2 Una app que aparenta ser totalmente legítima
Según la información pública, FomoPeek tiene el aspecto completo que tendría un proyecto normal:
Esta app se publica normalmente en App Store; tiene sitio web y cuentas oficiales en redes sociales; su posicionamiento público es una “herramienta de monitoreo y recordatorios on-chain de solo lectura”, que no se conecta a billeteras ni solicita frases mnemónicas. Por ello, tanto desde la perspectiva del proceso de revisión como desde la del usuario, es difícil relacionarla con la explotación de vulnerabilidades del kernel únicamente por su apariencia.
1.3 Ruta de propagación: código de invitación de KOL y permanencia en dispositivo real 5–7 minutos
La información de promoción pública muestra que FomoPeek se difunde principalmente a través de KOL de la comunidad de criptomonedas y comunidades relacionadas. Los usuarios deben usar un código de invitación para descargar e inscribirse desde App Store; configurar un “código de seguridad”, añadir una billetera de monitoreo y operar en un dispositivo real durante varios minutos; tras la revisión, pueden recibir 5–7 USDT. Algunos contenidos promocionales también recalcan especialmente “un iPhone solo tiene una oportunidad”, “múltiples cuentas en el mismo dispositivo no sirven” y “es obligatorio usar un dispositivo real y permanecer 5–7 minutos”.
Esta exigencia merece atención. En la muestra se integra una estrategia de explotación denominada CicutaVirosaStrategy. La explotación pública cicuta_virosa, al ejecutarse de forma individual, requiere más de dos minutos. Por ello, la regla promocional de “obligatorio usar un dispositivo real, no sirve un teléfono en la nube, se debe permanecer varios minutos” coincide con las características técnicas de que la cadena de explotación del kernel necesita ejecutarse de forma continua durante un tiempo en un dispositivo real. No obstante, esa regla promocional solo puede servir como pista auxiliar y no basta por sí sola para determinar su finalidad maliciosa.
A mediados de septiembre, en plataformas sociales públicas ya aparecieron advertencias de usuarios. El 2026-09-16 17:11 UTC, el usuario de X Jin HUI (@GXingPing) publicó un post diciendo que, tras descargar el software FomoPeek, ocurrió un robo; y advirtió a los usuarios que desinstalaran el software lo antes posible.
Desde antes de que los usuarios comenzaran a reportar en masa que les habían robado activos, ya se había emitido una alerta pública sobre la capacidad de extracción de datos iOS relacionada con este tipo de incidentes. El 25 de marzo de 2026, el CISO de SlowMist, @im23pds, publicó una alerta de seguridad: la herramienta de ataque DarkSword ya se había filtrado; se podía extraer y reenviar datos de nivel probatorio desde dispositivos iOS mediante interfaces HTTP. El atacante también podría combinar ingeniería social o ataques tipo “watering hole” para inducir a las víctimas a acceder a sitios o páginas donde se hubiera insertado código malicioso, robando así datos del iPhone o iPad y subiéndolos a un servidor controlado por el atacante.
1.4 Anomalías en el sujeto y la cronología
Según materiales públicos, el Seller registrado en el lado de Apple es Porter Manufacturing, L.L.C. y el desarrollador mostrado se llama WhaleScanv; actualmente solo se ha encontrado una app de FomoPeek bajo su nombre.
Debido a que la información pública es insuficiente para confirmar quién es el operador real detrás de este vendedor, este artículo no atribuye su identidad ni la relación con empresas homónimas. Sin embargo, según la fecha de registro del dominio, la política de privacidad, el lanzamiento de la app y el momento en que se insertaron los módulos maliciosos, las identidades web y la infraestructura de emisión relacionadas se crearon en un periodo relativamente corto y de manera concentrada.
La siguiente línea de tiempo merece atención:
Desde el registro del dominio hasta el despliegue en App es apenas de unos 10 días, y la “fecha de entrada en vigor” de la política de privacidad es anterior en dos días al registro del dominio. Toda la identidad web y la cadena de emisión se construyeron de forma concentrada a finales de agosto y principios de septiembre.
1.5 Contradicción entre etiquetas de privacidad y la política de privacidad propia
La sección “Privacidad de la app” (App Privacy) en la página de App Store muestra “No se recopilan datos”, pero la política de privacidad del sitio web de FomoPeek indica claramente los tipos de datos que procesa, incluyendo: X-Device-Id (identificador del dispositivo), tokens de push de APNs, correo, contraseñas (hash bcrypt), apodo/nombre de usuario, código de seguridad de verificación en dos pasos (hash bcrypt), y direcciones de billeteras públicas, etiquetas, umbrales y preferencias de eventos agregadas por el usuario.
Incluso sin considerar la explotación de vulnerabilidades del kernel, ya existe una contradicción entre el “no recopilamos datos” registrado ante Apple y el alcance de recopilación enumerado en su política de privacidad.
II. Cronología de versiones y alcance de la inyección de malware
Dentro de los paquetes de la versión 1.1 y 1.2, encontramos dos frameworks que no guardan relación con las funciones del negocio:
La comparación de versiones muestra que 1.1 y 1.2 llevan el mismo conjunto de módulos maliciosos; los segmentos de código y de datos son consistentes. En 1.3 se eliminan por completo ambos frameworks y el tamaño del IPA pasa de 10.47 MB a 1.81 MB.
El programa principal y los dos frameworks usan el mismo sujeto de firma de Apple. Además, en el IPA original se conserva metadatos de cifrado FairPlay, lo que indica que los módulos maliciosos forman parte del paquete oficial presentado por el desarrollador a App Store, y no son un re-firmado de terceros ni un producto de sideload.
III. Análisis de módulos maliciosos
3.1 Dos frameworks que no guardan relación con el negocio
Hay una división clara de funciones entre dos módulos: apptrace se encarga de la comunicación C2, mientras que libapptracecore se encarga de la explotación del kernel y la recopilación de datos.
La distribución del espacio de nombres de libapptracecore aclara su naturaleza: no es un componente de analítica, estadísticas ni anti-debugging, sino una cadena de herramientas completa desde la explotación (exploit) hasta el acceso al kernel (kernel), permisos y sandbox (permissions), llavero (keychain), y adquisición y transmisión (acquisition). apptrace asume toda la comunicación con el extremo de control externo; la combinación de ambos constituye el implante de “comunicación + ataque”.
3.2 Se carga al iniciar; el programa principal no contiene rastros de llamadas
Los comandos de carga Mach-O del programa principal referencian dos frameworks mediante LC_LOAD_DYLIB (no weak)
@rpath/apptrace.framework/apptrace
@rpath/libapptracecore.framework/libapptracecore
Esto implica que, independientemente de si el código de negocio lo llama o no, ambos se cargan en el mismo proceso mediante dyld durante el inicio de la app.
Por otro lado, el lado del programa principal realmente no contiene rastros de llamadas explícitas: en la tabla de símbolos, los 1,048 símbolos de importación provienen de bibliotecas del sistema. Las referencias de clases ObjC solo incluyen clases del sistema. Además de las dos rutas de carga anteriores, no se encuentran nombres de clases o métodos de frameworks; y el propio framework tampoco tiene +load / +initialize de ObjC. Tras realizar una trazabilidad en tres capas sobre 34 funciones de inicialización estática de C++ (__mod_init_func), tampoco se tocó código de explotación ni de recopilación.
Por tanto, desde la capa estática se puede confirmar: los módulos se cargan forzosamente en el proceso cuando arranca la app y el código de capacidades está completo. La oportunidad real de activación y las evidencias de ejecución requieren verificación dinámica en un dispositivo real.
3.3 Framework de ataque al kernel: 8 estrategias de explotación con emparejamiento automático
libapptracecore implementa 8 clases de estrategias de explotación, todas heredadas de exploit::IExploitStrategy / KernelMachTaskExploitStrategyBase, y dentro de cada estrategia hay incorporada una determinación de “si se admite el dispositivo actual”:
Las ventanas de versión de las 8 estrategias se conectan de forma consecutiva; el rango declarado por el código es iOS 12.0–18.7.2 e iOS 26.0–26.1. El framework evaluará paso a paso si la estrategia es utilizable según la versión del sistema y el modelo del dispositivo, y distinguirá tres resultados: explotación exitosa, explotación fallida y dispositivo no compatible.
La tabla de modelos integrados del framework también incluye iPhone16,1/16,2, iPhone17,1–17,5, iPad15,3–15,6, iPad16,1–16,6, etc. (2023–2025), lo que indica que el objetivo de adaptación no son únicamente dispositivos antiguos.
3.4 Lectura/escritura del kernel y escalada de privilegios
Puertos de tareas del kernel: Creating safe tfp0, testing new tfp0 port, Updated port for tfp0!, failed to allocate new tfp0 port
Primitivas de lectura/escritura del kernel: kread (found kread_sem_index / error on kread), kwrite, mach_vm_read_overwrite / mach_vm_write / mach_vm_allocate
Superficie de explotación: IOSurfaceRootUserClient, IOSurfaceClient, IOAccelCommandQueue2, IOAccelSharedUserClient2
Evasión de protecciones: HSP4 patch exists., Applied HSP4 patch. (evasión PPL)
Origen del desplazamiento (offset): tabla estática kernel::OffsetProvider iOS12 / 13 / 14 / 15 / 15_2, y ramas de cálculo de desplazamientos en tiempo de ejecución para iOS 16 y superiores (tratamientos internos específicos para 16, 18 y 26)
Escalada de privilegios: permissions::KernelUcredStealer, permissions::RORestrictedUcredPatcher, permissions::RO2RestrictedUcredPatcher (incluye WeirdCsTrick / WeirdCredTrick)
3.5 Evasión de sandbox y descifrado del llavero
La parte de sandbox la completa permissions::SandboxExtPatcher, y la cadena de permisos objetivo es com.apple.app-sandbox.read-write. Después de superar la sandbox, el proceso puede leer rutas fuera del contenedor de esta aplicación.
La parte de llavero (keychain) es la parte más directa y dañina de todo el framework:
Interacción con servicios del sistema: inicialización del cliente AppleKeyStore (Initialized AppleKeyStore client, Device failed to start AppleKeyStore client with err ...), keyBag, pkcs8ShroudedKeyBag
Análisis del formato de la base de datos: keychain::KeychainV3, KeychainV9, KeychainV11, correspondientes a formatos de la base de datos del llavero en distintas versiones de iOS
Estructura serializada: SecDbKeychainSerializedAKSWrappedKey, SecDbKeychainSerializedItemV7, SecDbKeychainSerializedMetadata, SecDbKeychainSerializedSecretData
Descifrado y exportación: keychain::GetRawKeychain, parsing::DecryptSFA, keychain::AgentKeyUnwrapper, acquisition::server::RawKeychainDecryptDataWriter
3.6 Canal C2 Bitbucket buzón de correo cifrado para reportes
Después de ejecutar la versión afectada en un dispositivo aislado (disfrazado como iPhone 16 / iOS 26.1), capturamos dos solicitudes que no tenían relación con el negocio y desciframos completamente su contenido.
① Buzón de correo (dead letter): obtener de sitios públicos de alojamiento de código la lista de direcciones C2 cifradas
GET hxxps://bitbucket[.]org/discordseven/text/raw/main/xxhVOn
Este repositorio (bitbucket[.]org/discordseven/text) es público. Tanto README como .gitignore son plantillas predeterminadas de Bitbucket y solo se usan para disfrazar. El repositorio se creó el 2026-08-04 y el correo del autor que hizo el commit es discdseven@outlook.com. El archivo xxhVOn en su interior es una lista de direcciones C2 cifrada:
El archivo es un cifrado AES-CBC de 48 bytes
Después del inicio, el cliente lo descifra con una clave incrustada y obtiene una lista de direcciones C2: ["hxxps://api-a95f0ed200f.assisaint[.]com"]
Este archivo ha sido modificado tres veces en el pasado: 2026-08-04 (64 bytes), 2026-08-06 (48 bytes) y 2026-09-13 (48 bytes, es decir, el día siguiente al lanzamiento de la 1.2).
Si el atacante edita este único archivo público, puede cambiar la dirección C2 de todos los endpoints comprometidos, sin necesidad de publicar una versión nueva de la app.
② Reporte C2: información del dispositivo cifrada e instrucciones remotas
Este dominio C2 assisaint[.]com se registró el 2026-09-12 (justo el día en que se publicó la 1.2). El registrador es Cloudflare, y el sitio de origen se ocultó mediante un método de proxy previo. En los registros CT también se puede ver otro subdominio del mismo dominio: bp-a95010ced.assisaint[.]com (certificado de 90 días emitido por TrustAsia).
③ Resultado del descifrado
El cliente usa el CCPEncrypt de CommonCrypto (alg = kCCAlgorithmAES(0), options = kCCOptionPKCS7Padding(1), es decir, AES-CBC + PKCS7) para cifrar el cuerpo del mensaje. Mediante hook a esta función, obtenemos la clave de esta sesión y desciframos el texto plano bidireccional:
Después de descifrar el campo params del cuerpo de la solicitud, se trata de un reporte de información del dispositivo:
{"app_version":"1.0.5","app_pac":"com.fomopeek.app","app_uuid":"7A5475A0007346BCB6EDB30E43315999","timestamp":1789806193645,"machine":"iPhone 16","ios_version":"26.1"}
Después de descifrar, la respuesta es una instrucción remota:
{"version":"1.0.0","min_close_exploit_version":"","exploit_enabled":false,"exploit_repeat_enabled":false,"exploit_test":false,"app_log_report_enabled":false,"exploit_repeat_interval":86400}
Verificación dinámica: se confirma que el buzón de correo y todas las solicitudes C2 son emitidas por apptrace (el prefijo antes de multipart boundary es ---AppTraceBoundary). Mientras tanto, la estrategia de explotación, la lectura/escritura del kernel, el descifrado del llavero y el servicio del puerto 40000 están en libapptracecore.
Hay que aclarar que, tanto en esta ejecución como en el tráfico capturado del 2026-09-19 08:23, exploit_enabled fue siempre false. Sin embargo, la existencia de este interruptor y sus parámetros de ciclo indica que el atacante puede habilitar la explotación en cualquier momento mediante la respuesta del servidor, ajustar el ciclo de ejecución o forzar la desactivación sin necesidad de actualizar la app. Además, la imagen anunciada por el dispositivo virtual de prueba (iPhone 16 / iOS 26.1) cae exactamente dentro del intervalo de cobertura descrito en la sección 3.3 DarkSwordStrategy (16.7–18.7.2 y 26.0–26.1).
3.7 Recopilación remota de objetivos: 19 billeteras y apps de notas
Para verificar qué ocurre cuando se “enciende el interruptor”, usamos Frida para reescribir en el callback de descifrado los campos exploit_enabled / exploit_repeat_enabled / exploit_test de la respuesta a true y luego observamos el comportamiento del cliente.
Cuando el cliente obtiene la configuración en el siguiente ciclo de recuperación, además del estado del interruptor, también recibe una lista de objetivos de recopilación (`collect_configs`). Esto revela directamente la intención de esta operación:
collect_configs entregado por C2 incluye 19 objetivos de recopilación; casi todos son apps de billetera, incluyendo Gate Web3, SafePal, OKX Wallet, MetaMask, Trust Wallet, imToken, TokenPocket, TronLink, etc.
Las rutas de recopilación se concentran en keystore, SQLite, MMKV, almacenamiento local de React Native y el acceso al Keychain; además incluye el contenedor completo de notas de Apple group.com.apple.notes. Estas configuraciones indican que el objetivo del ataque son los materiales de claves de billetera y otras informaciones sensibles que guarda el usuario, y que el alcance de recopilación puede ajustarse dinámicamente mediante el servidor.
Hasta aquí, las capacidades de ataque de los módulos maliciosos y los objetivos de recopilación dirigidos entregados por C2 forman una cadena de evidencias completa.
3.8 Enlace externo: POST /api/upload/zip
Tras activar la recopilación, capturamos una solicitud multipart enviada a /api/upload/zip. En ella, el campo params contiene metadatos del archivo cifrados con AES-CBC, mientras que el campo file es un archivo ZIP archivado que no fue cifrado adicionalmente.
Los metadatos tras el descifrado muestran que el objetivo archivado es group.com.apple.notes; el tamaño del archivo es de 46,092 bytes y va acompañado del MD5 del archivo, UUID del dispositivo, ruta de almacenamiento y marca de tiempo. El paquete ZIP reconstruido contiene NoteStore.sqlite, archivos WAL y archivos de configuración relacionados, coherentes con la estructura de contenedores de Apple Notes.
Con esto se puede confirmar: la muestra lee el contenedor objetivo según la lista entregada por C2, guarda temporalmente los resultados en su propia sandbox y luego los sube a /api/upload/zip.
A partir de este informe, reconstruimos el contenido del archivo; el contenido del archivo es el contenedor de Notas de Apple:
group.com.apple.notes/NoteStore.sqlite 307,200
group.com.apple.notes/NoteStore.sqlite-shm 32,768
group.com.apple.notes/.com.apple.mobile_container_manager.metadata.plist 577
group.com.apple.notes/Library/Preferences/group.com.apple.notes.plist 127
group.com.apple.notes/NoteStore.sqlite-wal / com.apple.notes.databaseopen.lock
Hasta aquí, verificamos en un entorno de prueba aislado el flujo de lectura del contenedor objetivo, el empaquetado de archivos y el proceso de carga de datos. Combinado con el código del framework relacionado con explotación del kernel, escalada de privilegios y evasión de sandbox, se puede reconstruir su cadena de diseño: configuración remota → explotación del kernel y escalada de privilegios → recopilación de datos objetivo → empaquetado y carga.
3.9 Otros endpoints C2: inventario de aplicaciones y devoluciones de ejecución
Además del endpoint de distribución de configuración y del extremo de exfiltración de datos, también confirmamos dos endpoints complementarios, que en conjunto forman el protocolo C2 completo de “reconocimiento → enviar instrucciones → recopilación → reenvío”.
① /api/device/apps: informa el inventario de aplicaciones instaladas
Tras descifrar el segmento params de esta solicitud con la misma KEY/IV, resulta ser la lista de bundle IDs de las 135 apps del dispositivo:
{"app_uuid":"7A5475A0007346BCB6EDB30E43315999",
"apps":["com.apple.Home.HomeControlService","com.apple.CarCamera","com.debank.rabby-mobile-regression","com.apple.ScreenSharingViewService","com.okx.wallet", … un total de 135 entradas …]}
La función de esta lista es bastante directa: el servidor determina qué billeteras tiene instalada el dispositivo y, con base en ello, decide qué collect_configs entregar.
② /api/device/report: retorno de resultados y siguientes instrucciones
③ Resumen de endpoints C2 confirmados
3.10 Rasgos del registro y despliegue del dominio C2
Las conclusiones de la investigación de infraestructura básica sobre el propio dominio C2 son las siguientes:
El registro del dominio es relativamente reciente y utiliza protección de privacidad en el registro, proxy inverso de Cloudflare y despliegue rápido de certificados, rasgos comunes de la infraestructura de ataque de corto plazo. La fecha de registro del dominio coincide con el día de publicación de FomoPeek 1.2, lo que puede servir como pista de correlación temporal; sin embargo, la información pública anterior es insuficiente para juzgar la ubicación del sitio de origen o la atribución al atacante.
Al verificar la infraestructura pública de este dominio, se puede ver que uno de sus subdominios aloja una interfaz de administración llamada Collect; en sus rutas del frontend aparecen entradas relacionadas con dispositivos, aplicaciones y claves (/machineApp, /machineApp/needBlast, /machineApp/walletAddress, /machineAppKeys, /machineStat, /mnemonic, /partner/account, /partner/home, /partner/machine/detail, etc.):
Esto indica que el dominio que aloja no es una API de negocio normal, sino una interfaz del lado operativo conectada a los datos recopilados del dispositivo y a las claves; su función y campos concretos no se desarrollan en este artículo.
IV. Revisión de la cadena de ataque
Carga de módulos: cuando la app inicia, apptrace y libapptracecore se cargan de manera forzada
Obtención de C2: obtiene el cifrado desde Bitbucket y lo descifra para obtener las direcciones C2
Reconocimiento del dispositivo: informa la información del dispositivo y el inventario de aplicaciones instaladas;
Distribución de configuración: obtener el interruptor de explotación, el ciclo de ejecución y los objetivos de recopilación;
Explotación y escalada de privilegios: seleccionar la estrategia de explotación del kernel que coincida, obtener capacidad de lectura con privilegios y superar la sandbox;
Recopilación y exfiltración: leer los datos de la app objetivo y el Keychain, empaquetar y subir a /api/upload/zip.
V. Análisis on-chain en MistTrack
Mediante análisis de trazabilidad sobre los datos on-chain ya recopilados, en este incidente se observa que los fondos robados por el atacante involucran múltiples cadenas (TRON, Ethereum y otras cadenas compatibles con EVM, etc.). Esta sección solo analiza la dirección principal del hacker (0x6d37f2C5e8F8546b648D317295565dA95975f4BB).
Según los datos de MistTrack, el ingreso total de esta dirección es de 579,984.34 USDT y comenzó a estar activa a partir del 15 de septiembre.
Su actividad de fondos cubre múltiples cadenas, como Ethereum, BNB Chain y Arbitrum. Hasta el momento de publicación, aún hay fondos entrando de forma continua. Los saldos actuales son los siguientes:
La mayor parte de los fondos de esta dirección se han consolidado en la red Ethereum. Los fondos en otras cadenas se convierten principalmente en USDT mediante plataformas de intercambio entre cadenas/DEX, como OKX DEX, Meson.fi, Relay.link, Mayan Finance, etc., y luego se envían a Ethereum entre cadenas.
Después, esta dirección transferirá por lotes los USDT acumulados a las siguientes direcciones de salida:
(1) 0x0A571f0Fa18D7EB9abcc1e98a0Bb9bC15534BbAe
El saldo actual en esta dirección es de 24,352 USDT. Cabe destacar que esta dirección ya empezó a estar activa desde el 23 de mayo, antes de la principal ventana de ataque del presente incidente.
Hay interacciones con FixedFloat, cce.cash, OKX, etc.:
Además, hay una transferencia de un monto relativamente grande: 111,458 USDT salen hacia la dirección 0x4c73d7e8ef0e61129403e219debc597fd43aa0ec y luego se reenvía a USDT0: UsdtOFT para transferencia entre cadenas.
La dirección de enlace cruzado para recibir fondos es una dirección TRON TF2hm96RC2Aqon9FeQjGidofoC2J1zM8v1. Dicha dirección recibió un total de 2,123,570.8821 USDT; posteriormente, los fondos se distribuyeron mediante múltiples direcciones y se enviaron a una plataforma OTC presunta.
(2) 0x0DF6aC2e2856114228756947d1b1d9Ff63eA3e68
Esta dirección recibe un total de 159,000 USDT:
Todo el dinero se transfiere a FixedFloat:
(3) 0x2d53113c89c83c520c17b8bbcdc22aa0518a38be
Esta dirección recibe un total de 47,028 USDT:
De ese total, 10,000 USDT se transfieren a KuCoin y los 37,028 USDT restantes se transfieren a FixedFloat:
(4) 0x111faeb95cd0786593433bcc762dc5c1debf541c
Esta dirección recibe un total de 227,154 USDT:
215,000 USDT se transfieren a FixedFloat y 10,000 USDT se transfieren a cce.cash:
Los 2,154 USDT restantes se intercambian mediante Bridgers Swap por 6,432.54 TRX y se envían entre cadenas a la dirección TRON TUi5qPcjDuqbmwfunMbzwkpLNhaqRpqcJg; la mayor parte del TRX termina en FixedFloat. Cabe destacar que una parte considerable del origen de los fondos de la dirección TUi5q proviene de cce.cash:
Mantendremos un seguimiento continuo del movimiento de fondos en las direcciones anteriores. Si usted instaló FomoPeek y recientemente sufrió el robo de activos, puede enviar la dirección robada y la dirección del hacker al siguiente enlace: https://aml.slowmist.com/cn/recovery-funds.html。
VI. Indicadores de amenaza IOC
URL:
hxxps://api-a95f0ed200f.assisaint.com/api/device/config
hxxps://bp-a95010ced.assisaint.com
hxxps://admin-e433360cb0e.assisaint.com
hxxps://customer-c1cb36b5.assisaint.com
hxxps://bitbucket.org/discordseven/text/raw/main/xxhVOn
Domain:
assisaint[.]com
api-a95f0ed200f[.]assisaint.com
bp-a95010ced[.]assisaint.com
admin-e433360cb0e[.]assisaint.com
customer-c1cb36b5[.]assisaint.com
File:
FomoPeek-1.1-891048157.ipa
MD5: fce99b45709a6f8e241175be0c121874
SHA-256: d6b6407b4c97697fdde174cbc190b6433315470f58df6b483ac5b806f35e20f9
FomoPeek-1.1.ipa
MD5: f5bdaed5953033ac8c3256f2933b9a81
SHA-256: ca5dfd0fa7a16f26f5b369516f5b8bcac1d5a6fe01a8511a5ededf4cd2c0d042
FomoPeek-1.2.ipa
MD5: 38a8a5ddecd9a5626b42dae593ac28f6
SHA-256: 48f9d5623af1518e774d57c41e6e0b915a7e9f896909bf596a9b27de5022911e
apptrace
MD5: 645b9053390246995c2cb7a9b9eddf40
SHA-256: 764663ff5c8bd1bdf33bbd1ec352ce262a4fe79695456f2612dc27c35840ab9d
libapptracecore
MD5: 03d67a68b5e8507dbbe36f2a4b41aca0
SHA-256: f0b3be01e8597f7f35ca36c009f68e7004527fe4a01d4349a01e211ca16de1e2
VII. Recomendaciones de investigación y medidas de mitigación
7.1 Lado del usuario
Si su dispositivo ha tenido instalada la versión 1.1 o 1.2 de FomoPeek, tenga en cuenta lo siguiente: desinstalar o actualizar a 1.3 no significa que el dispositivo ya esté seguro. Una vez que este framework se haya explotado con éxito, los datos que haya leído ya han salido del dispositivo.
1. Deje de usar inmediatamente esta app y no la reinstale;
2. En dispositivos de seguridad que no hayan instalado esta aplicación: crear una nueva billetera, generar nuevas frases mnemónicas y transferir activos; considerar todas las frases mnemónicas y llaves privadas antiguas como filtradas, prohibir su reutilización;
3. Revisa una por una las transferencias y registros de autorización anómalos de cada cuenta en las cadenas, y revoca las autorizaciones que ya no se utilizan;
4. Cambiar las contraseñas y credenciales de inicio de sesión que se hayan usado en este dispositivo, e iniciar la verificación en dos pasos;
5. Compruebe si el dispositivo ha instalado un perfil de configuración / MDM, si se hizo sideload o si está con jailbreak; si es necesario, borre el dispositivo y reinstale el sistema;
6. Conserve el dispositivo y las evidencias relacionadas (versión de la app, fecha de instalación, registros de transacciones anómalas) para una verificación posterior;
7. Si se detecta actividad anómala de activos, contacte de inmediato al soporte oficial del sitio/plataforma correspondiente.
7.2 Plataforma y ecosistema
1. Incorporar hashes de archivos, nombres de clases, cadenas clave y características de red al repositorio de muestras, reglas de EDR y de detección del tráfico;
2. Enviar avisos de riesgos dirigidos a los usuarios que hayan instalado FomoPeek 1.1 o 1.2 y tratarlos de acuerdo con el incidente de filtración de credenciales;
3. Bloquear assisaint[.]com y sus subdominios, bitbucket[.]org/discordseven/*;
4. A partir del 9 de septiembre de 2026, recuperar los registros de acceso del buzón de correo de Bitbucket; a partir del 12 de septiembre, recuperar los registros DNS, proxy, EDR, VPN y de dispositivos móviles relacionados con *.assisaint[.]com. Si el periodo de retención de los logs lo permite, se puede retroceder hasta el 4 de agosto para investigar las visitas a este repositorio de Bitbucket y a la configuración histórica de C2.
VIII. Conclusión
Mediante análisis estático y verificación dinámica, confirmamos que FomoPeek 1.1 y 1.2 insertaron dos módulos maliciosos, `apptrace` y `libapptracecore`, con capacidad de configuración remota, explotación de vulnerabilidades del kernel, evasión de sandbox, descifrado de Keychain y recopilación de datos entre apps.
Después de activar las funciones correspondientes en un entorno aislado, la muestra obtuvo desde C2 una lista de recopilación para 19 billeteras y apps de notas, empaquetó el contenedor de Notas de Apple y lo subió a `/api/upload/zip`. Esto valida la cadena técnica completa desde configuración remota, lectura con privilegios no autorizados, hasta exfiltración de datos.
No se encontraron estos módulos en FomoPeek 1.0; en 1.1 se insertaron por primera vez; en 1.2 se siguieron usando; y en 1.3 se eliminaron por completo. Para usuarios que hayan usado 1.1 o 1.2: solo desinstalar o actualizar la app no puede descartar el riesgo de filtraciones históricas. Se recomienda tratar las frases mnemónicas, llaves privadas y credenciales sensibles relacionadas como filtradas.
Preguntas frecuentes Q&A
P1: ¿Cuándo ocurrió este incidente?
La ventana de riesgo que puede confirmarse con claridad es del 9 de septiembre al 17 de septiembre de 2026.
FomoPeek 1.0 se subió por primera vez el 29 de agosto. En ese momento no se detectaron módulos maliciosos relacionados. La versión 1.1 publicada el 9 de septiembre insertó por primera vez apptrace y libapptracecore. La versión 1.2 publicada el 12 de septiembre continuó incluyendo el mismo conjunto de código malicioso. Hasta que se publicó la versión 1.3 el 17 de septiembre, estos dos Framework se eliminaron por completo.
El 16 de septiembre, en plataformas sociales públicas ya aparecieron alertas de usuarios sobre robo de activos después de instalar FomoPeek. Debido a que no todos los tiempos de instalación y el momento del robo de activos de las víctimas pueden obtenerse de forma completa, actualmente no es posible determinar con ello la hora exacta del primer ataque real más temprano.
P2: ¿Qué versiones están afectadas?
Según la versión de la app, se identifica claramente que las versiones afectadas son FomoPeek 1.1 y 1.2.
1.0: No se encontraron módulos maliciosos;
1.1: Primera inserción de módulos maliciosos;
1.2: continúa llevando el mismo conjunto de módulos maliciosos;
1.3: los frameworks relacionados se eliminaron por completo.
Según el intervalo de cobertura de iOS declarado por el código del framework de ataque, incorpora 8 estrategias de explotación: cubren iOS 12.0–18.7.2 e iOS 26.0–26.1, y selecciona la estrategia correspondiente según el modelo del dispositivo y la versión del sistema.
Tenga en cuenta que FomoPeek muestra en la página de App Store que los requisitos del sistema son iOS 16.0+. Por tanto, los conceptos de “alcance teórico de cobertura de los frameworks de ataque” y “alcance real de dispositivos en los que FomoPeek puede instalarse desde App Store” no son completamente equivalentes.
P3: ¿Por qué vías podría ocurrir el ataque?
En el incidente de FomoPeek, la vía de propagación ya confirmada es la propia versión oficial de App Store, no un paquete re-firmado por terceros, ni un paquete de firma empresarial, ni una instalación sideload. El Framework malicioso y el programa principal usan el mismo sujeto de firma de Apple, y el IPA original también conserva los metadatos cifrados de FairPlay.
FomoPeek atrae a los usuarios principalmente mediante KOL de cripto, comunidades, códigos de invitación y una pequeña recompensa en USDT, y exige que los usuarios ejecuten el programa en un dispositivo real durante varios minutos.
Sin embargo, desde el punto de vista de la técnica de ataque en sí, este tipo de explotación del kernel de iOS no tiene por qué estar escondida necesariamente en una sola app. Teóricamente, capacidades similares también podrían activarse mediante: una app maliciosa o envenenada, componentes de la cadena de suministro, páginas de phishing, sitios web comprometidos y también páginas tipo “watering hole” preparadas para un grupo específico de personas, entre otras puertas de entrada.
En las advertencias públicas relacionadas con DarkSword mencionadas previamente en este artículo, también se señaló que el atacante podría combinar la ingeniería social o ataques tipo “watering hole” para inducir a la víctima a visitar un sitio o página donde se ha insertado código malicioso, robando así datos en el iPhone o iPad.
Por ello, no debe entenderse de forma simple que “proviene de App Store” o “proviene de un sitio web que frecuenta con frecuencia” sea absolutamente seguro.
P4: ¿Qué es un “ataque tipo watering hole”?
La idea del “ataque tipo watering hole” (Watering Hole Attack) no consiste en buscar directamente a cada víctima, sino en encontrar primero un lugar que el grupo objetivo visita con frecuencia y que le genera confianza.
Por ejemplo, si el atacante quiere dirigirse a un grupo de profesionales de cierta criptomoneda, podría primero analizar qué sitios web de industria, sitios de herramientas, comunidades, sitios oficiales de proyectos o páginas de eventos visitan con frecuencia estas personas, y luego buscar objetivos que puedan ser vulnerados o envenenados con código malicioso.
Una vez que estos sitios web normales estén controlados, las víctimas solo tendrían que acceder al sitio como de costumbre para entrar en la cadena de ataque.
Este nombre proviene de la “balsa” (watering hole) en la naturaleza: los depredadores no necesitan perseguir a cada presa; solo necesitan esperar en el lugar donde los animales van a beber.
Para dispositivos móviles, este “watering hole” también puede entenderse como una puerta de entrada de confianza más amplia: podría ser un sitio web conocido, o un App que se usa durante mucho tiempo, un SDK de terceros, enlaces de comunidades e incluso una actualización normal de una app.
P5: ¿El riesgo similar solo existe en FomoPeek?
No.
Lo que FomoPeek merece más atención no es solo si un usuario de una billetera en particular instaló esta app. Más bien, vuelve a demostrar algo: la puerta de entrada del ataque puede estar oculta dentro de aplicaciones que parecen totalmente normales y que incluso provienen de la tienda oficial de aplicaciones.
En los casos públicos, ComeCome (拜托拜托) también proporciona otra muestra que merece atención. El análisis público muestra que se trata de una app de delivery orientada a usuarios chinos en regiones como Dubái; su versión 2.9.3 se descubrió con un componente oculto llamado DKStatistics, con capacidad de superar la sandbox de iOS y acceder a datos como las apps de billetera, WhatsApp y las Notas de Apple. Además, la página pública también revela los flujos de fondos on-chain correspondientes. Hay que aclarar que este sitio también delimita claramente la frontera entre “la tecnología y los hechos on-chain verificables públicamente” y “la imposibilidad de atribuir directamente al atacante real únicamente con ello”.
Estos casos advierten:
El “watering hole” no necesariamente tiene que parecer un sitio web peligroso. Puede ser el sitio web que abres cada día, una herramienta, una app de comida a domicilio, un enlace de una comunidad e incluso el software descargado desde una tienda oficial.
Desde la definición tradicional, FomoPeek y ComeCome se parecen más a la “inserción de malware en apps / envenenamiento de canales confiables” que a un “watering hole” clásico en la web; pero la idea de ataque subyacente es muy similar: primero entrar por un punto de acceso confiable y de uso frecuente del grupo objetivo, y luego esperar a que la víctima acceda activamente al entorno de ataque.
Así que lo que realmente hay que vigilar no es solo un FomoPeek. Los “watering holes” pueden existir en cualquier lugar que el grupo objetivo haya confiado durante mucho tiempo.
Puede consultarse el caso público ComeCome en: https://comecome.icu/
Sobre MistEye
MistEye es una plataforma de inteligencia de amenazas Web3 y monitoreo dinámico de seguridad desarrollada de forma independiente por SlowMist. Proporciona, a través de API, capacidades de detección de actividades maliciosas en el ecosistema de paquetes de código abierto y alertas de riesgo de cadena de suministro.
Todos los paquetes maliciosos y los IOC involucrados en esta operación se han conectado al motor de detección de amenazas de MistEye. El desarrollador puede realizar detección automatizada de dependencias del proyecto mediante la API, determinar rápidamente si se detecta algún paquete malicioso conocido y obtener sugerencias de mitigación.
📖 Documentación de la API: https://app.misteye.io/api-docs
🛠️ MistEye-DepScan: https://github.com/slowmist/MistEye-DepScan Herramienta CLI ligera. Con un solo comando, escanea las dependencias del proyecto y los paquetes globalmente instalados de malware conocido; admite ecosistemas npm / PyPI / Cargo / Go / RubyGems
🛠️ MistEye-Skills: https://github.com/slowmist/misteye-skills Paquete de habilidades de seguridad para asistentes de codificación. Detecta automáticamente la seguridad de MistEye antes de instalar dependencias y antes de acceder a una URL
🛠️ MistEye-DNS-Guard: https://github.com/slowmist/MistEye-DNS-Guard Herramienta de protección de seguridad DNS para detectar dominios maliciosos y accesos de riesgo, identificando amenazas de red como phishing y C2.
Este artículo fue elaborado por el equipo de inteligencia de amenazas de SlowMist junto con el sistema de inteligencia de amenazas MistEye y el análisis impulsado por el agente de IA de SlowMist. Si tiene alguna pregunta, no dude en consultar y enviar comentarios.