El malware Midnight Mimosa viene integrado en el firmware de teléfonos Android y llega a más de 150 países

Un teléfono comprometido antes de su primer encendido

Miles de dispositivos Android en más de 150 países se han visto afectados por Midnight Mimosa, una campaña de malware que introduce software malicioso en el firmware de los teléfonos antes de que sus compradores los enciendan. Bitdefender identificó al menos 32 aplicaciones encubiertas distribuidas por la operación, además de 13 aplicaciones de Google Play que contenían el mismo código de fraude publicitario y se comunicaban con su infraestructura de control.

Los hallazgos, publicados el 8 de octubre de 2026 y actualizados el 9 de octubre, describen una operación observada durante aproximadamente dos años. Entre los dispositivos afectados hay teléfonos económicos con plataformas MediaTek, productos falsificados que utilizan nombres de modelos de Apple y Samsung, y dispositivos que se identifican como Doogee S200 X y Cubot KINGKONG X.

El hallazgo central del informe técnico de Bitdefender es que la infección no depende de que el comprador descargue una aplicación sospechosa. El dispositivo incluye un componente malicioso del sistema, que cuenta con amplios permisos del sistema operativo y puede instalar software adicional sin pedir autorización al propietario.

Esto hace que la amenaza sea especialmente difícil de eliminar. Borrar una aplicación meteorológica no deseada o un bloqueador de aplicaciones puede quitar una parte visible de la operación y dejar intacto el componente que la instaló. Los investigadores encontraron cargas maliciosas que aparecían y desaparecían repetidamente en los mismos dispositivos.

La investigación también tiene límites. No identificó quién introdujo el malware en el firmware. Los investigadores encontraron código capaz de reenviar tráfico a través de teléfonos infectados, pero su dispositivo de prueba no recibió instrucciones de reenvío. Los operadores tenían a su disposición permisos sensibles, aunque los investigadores no observaron que los utilizaran durante el análisis.

El componente oculto que controla las instalaciones

La investigación comenzó cuando la tecnología de detección de comportamiento de Bitdefender señaló com.android.system.lite. Su nombre y la etiqueta genérica «System» sugerían que se trataba de un componente habitual de Android, pero sus acciones eran distintas: instalaba y eliminaba aplicaciones ajenas sin avisar y activaba repetidamente permisos sensibles.

El componente no tenía un icono visible en el lanzador. Estaba firmado para la plataforma Android, se ejecutaba como usuario del sistema y estaba configurado para permanecer activo. Entre sus permisos figuraban la instalación y eliminación de paquetes, la concesión de permisos a otras aplicaciones y la modificación de ajustes seguros. Son facultades muy superiores a las que suele tener una aplicación descargada por el propietario de un teléfono.

Posteriormente, los investigadores encontraron el mismo núcleo malicioso con otros nombres, entre ellos com.android.sys.prot, com.android.sys.gmsprot y com.android.sys.bcprot. Otro paquete mencionado por propietarios de teléfonos, com.android.non.szcz, fue identificado como parte de la misma familia. Las distintas versiones utilizaban nombres diferentes y, en algunos casos, certificados de firma distintos.

Esto es importante para la detección y eliminación: un solo nombre de paquete no define toda la amenaza. Un teléfono sin com.android.system.lite aún podría contener otra versión del mismo mecanismo. El comportamiento compartido y el código subyacente permiten identificarlo mejor que la etiqueta que aparece en la lista de aplicaciones de Android.

Cómo el código remoto cambia el funcionamiento del teléfono

Gran parte de la lógica maliciosa estaba oculta en una biblioteca nativa llamada libeasy.so, en lugar de estar expuesta en el código habitual de la aplicación del sistema. Al iniciarse, la biblioteca utilizaba cifrado RC4 para ocultar y luego recuperar un marco de trabajo integrado de aproximadamente 142 KB.

Ese marco de trabajo obtenía la configuración de un servidor de comando y control, es decir, un servicio remoto mediante el cual los operadores dirigen los dispositivos infectados. Podía descargar y cargar archivos DEX y JAR, formatos utilizados para empaquetar código ejecutable de Android y Java. Esto permitía a los operadores cambiar el comportamiento del dispositivo después de su venta.

Los investigadores identificaron tres familias de complementos. Una, asociada a com.wz.sdk.DxFactory, se encargaba de generar impresiones y clics publicitarios falsos. Las otras, asociadas a com.earnsdk.lib.DxFactory y com.gogo.third.lib.DxFactory, permitían instalar y eliminar otras aplicaciones sin avisar; esta última también incluía funciones de WebView.

Por lo tanto, el componente del sistema actuaba como un controlador persistente, no como una pieza fija de malware publicitario. Eliminar la carga maliciosa de hoy no impediría que descargara otra mañana. La combinación de carga remota de código y concesión de permisos privilegiados también ampliaba sus posibles actividades más allá de lo observado durante la investigación.

Las aplicaciones camufladas convierten los clics falsos en ingresos

El objetivo aparente de la operación era ganar dinero. Los investigadores encontraron al menos 32 aplicaciones distintas de carga maliciosa camufladas como herramientas meteorológicas, bloqueadores de aplicaciones, administradores de archivos, herramientas de iconos, herramientas de reconocimiento de texto y editores de audio. Algunas ofrecían funciones útiles, mientras que otras no realizaban de manera significativa la tarea sugerida por su nombre.

Un ejemplo, com.mobile.applock.wt, se presentaba como una herramienta para bloquear aplicaciones, pero carecía de la interfaz y del código necesarios para ofrecer esa función. Permanecía oculta al usuario y actuaba como otro instalador de malware, es decir, un programa que distribuye software malicioso adicional. Entre las otras cargas maliciosas identificadas figuraban com.dmstudio.weather, com.dl.guard.lock y picturetranslate.extractor.text.lite.

Las aplicaciones de camuflaje incluían kits de desarrollo de software, o SDK, legítimos para publicidad. Estas herramientas permiten que una aplicación muestre anuncios y reciba pagos por la actividad publicitaria. Su presencia daba al tráfico fraudulento un identificador de aplicación y de publicidad al que se podían atribuir ingresos.

Los investigadores de seguridad de Bitdefender Adrian Mihai Gozob y Alex Baciu describieron así la división de funciones entre el componente persistente del sistema y las aplicaciones de camuflaje:

«La propia aplicación del sistema no registra las impresiones y los clics fraudulentos».

El controlador proporcionaba instrucciones y tiempos, y simulaba interacciones, mientras que los identificadores publicitarios pertenecían a las aplicaciones de camuflaje. Las aplicaciones se comunicaban mediante servicios compartidos e informaban el mismo identificador del dispositivo a una infraestructura que incluía un servicio de control disfrazado de API meteorológica. Así, herramientas que parecían independientes quedaban vinculadas en una operación publicitaria coordinada.

El análisis técnico encontró clics automáticos sin que el usuario tocara la pantalla, objetivos publicitarios aleatorios, límites diarios e intervalos entre interacciones simuladas. También identificó informes automáticos de conversiones después de un temporizador de 60 segundos. Estos controles podían regular la actividad falsa, en lugar de generar una secuencia ininterrumpida de eventos idénticos.

Google Play, objetivo de evasión y vía de distribución

Antes de desplegar una carga maliciosa, el malware desactivaba temporalmente com.android.vending, la aplicación de Google Play Store. Después la reactivaba e incluía una medida de protección para restaurarla cuando el usuario estuviera presente. Bitdefender consideró que probablemente se trataba de un intento de evitar la detección de Play Protect, y no de una prueba de que todas las instalaciones eludieran el análisis.

Algunas variantes también manipulaban los registros del instalador de Android para que el software instalado por el malware pareciera provenir de Google Play. Ese camuflaje podía hacer que una aplicación desconocida pareciera menos sospechosa cuando su propietario comprobaba su procedencia.

Los mecanismos publicitarios utilizaban recursos como actividades que se abrían sin que el usuario lo solicitara y superposiciones sobre otras aplicaciones. Una de las superficies publicitarias estaba marcada como segura, lo que impedía que apareciera en capturas de pantalla o grabaciones. El informe describe tanto actividad publicitaria oculta como anuncios intrusivos, por lo que no debe entenderse que la operación fuera completamente invisible.

Google Play también fue un canal de distribución independiente. Los investigadores identificaron 13 aplicaciones publicadas que contenían el mismo código de fraude publicitario y se comunicaban con la infraestructura de Midnight Mimosa. Utilizaban 13 certificados de firma distintos y al menos dos cuentas de desarrollador, llamadas fivedev y CPS Developer.

Estas aplicaciones de la tienda no tenían los privilegios elevados de los componentes preinstalados del sistema. La diferencia es considerable: descargar una de ellas no le otorgaba automáticamente los mismos permisos de instalación silenciosa que a un componente de firmware comprometido. Sin embargo, podían mostrar anuncios fuera de su propia interfaz, incluso cuando el propietario no estaba usando activamente el teléfono.

Según los reportes publicados, al menos algunas aplicaciones relacionadas seguían disponibles cuando se dieron a conocer los hallazgos, y Google no había respondido de inmediato a una solicitud de comentarios. No se ha establecido un calendario confirmado para su retirada. Los hallazgos en Play muestran que la exposición no se limitaba a dispositivos falsificados o a teléfonos ya comprometidos durante su fabricación.

Se observó el registro en el proxy, pero no el reenvío activo

Otra carga maliciosa, com.mobile.applock.en, contenía un componente de proxy TCP. Un proxy reenvía el tráfico de internet en nombre de otra persona. Cuando la conexión pertenece a un propietario de teléfono común, ese tráfico puede parecer originarse en la dirección de internet del propietario y no en la de quien realmente lo dirige.

El componente registraba dispositivos en un servidor remoto y podía recibir instrucciones para conectarse a destinos especificados y reenviar tráfico. Estas capacidades podrían servir para crear una red de dispositivos controlados a distancia, o botnet, y generar otra fuente de ingresos mediante la venta de acceso a esas conexiones.

Bitdefender confirmó que la infraestructura del proxy aceptó el registro de su dispositivo de prueba. Sin embargo, el dispositivo no recibió destinos de retransmisión durante las pruebas. Por lo tanto, la investigación demostró la posibilidad de registro y reenvío, pero no que se produjera un reenvío activo en ese dispositivo.

La misma cautela se aplica a los ataques de denegación de servicio distribuido, que saturan un objetivo con tráfico procedente de muchos dispositivos. Los investigadores describieron la participación en una botnet y esos ataques como posibles usos. Los hallazgos no demuestran que los teléfonos afectados por Midnight Mimosa realizaran un ataque concreto ni identifican a clientes que compraran acceso a sus conexiones.

¿Qué dispositivos y países aparecieron en los hallazgos?

México, Francia e Italia encabezaron la distribución geográfica, seguidos de Estados Unidos, Alemania, Brasil y España. Las cifras abarcaron miles de dispositivos únicos durante aproximadamente dos años, pero no se indicó un total exacto de la campaña. Se trata de detecciones, no de un recuento de todos los teléfonos infectados que se vendieron.

Más del 11 % de los dispositivos comprometidos se identificaban como KINGKONG X, nombre de modelo asociado a Cubot, mientras que más del 4 % se identificaban como S200 X, asociado a Doogee. En conjunto, esos dos grupos de modelos representaron más del 15 % de las detecciones. Cubot Kingkong 9 también fue identificado en los reportes sobre la investigación.

Las 15 principales marcas de teléfonos representaban el 35,8 % de los dispositivos infectados. Aproximadamente el 64 % se agrupó en la categoría «otros», una cifra redondeada según el informe. La distribución apunta a un mercado afectado fragmentado, en lugar de una operación limitada a una sola marca reconocible.

Entre los nombres de modelos falsificados figuraban i17 Pro Max, i16_Pro_Max, 17_Pro_Max, S25 Ultra, S24 Ultra y Note 18 Ultra. También apareció el nombre de una tableta, iPadAirPro. Estos nombres se detectaron en dispositivos Android económicos y no deben confundirse con pruebas de que productos auténticos de Apple o Samsung tuvieran el malware.

Los identificadores de modelo por sí solos no son pruebas concluyentes, porque el software puede falsear la identidad de un dispositivo. La detección en modelos concretos tampoco demuestra que todas las unidades vendidas con esos nombres estuvieran infectadas. Los hallazgos técnicos se refieren a los dispositivos y versiones de firmware afectados, no a todos los productos MediaTek ni a todos los teléfonos de las marcas mencionadas.

Los certificados de firmware no demuestran quién es responsable

Algunos firmwares afectados estaban firmados con certificados que llevaban el nombre Shenzhen Zediel. La evidencia de la firma es importante porque vincula el componente malicioso con un firmware en el que confía el dispositivo. Sin embargo, por sí sola no demuestra quién introdujo el malware ni si el titular del certificado sabía que estaba presente.

Gozob y Baciu limitaron explícitamente el alcance de lo que su investigación podía determinar sobre esa atribución:

«Solo podemos confirmar que se utilizaron certificados con el nombre Shenzhen Zediel para firmar el firmware de los dispositivos afectados».

Los reportes describieron de distintas maneras a la empresa detrás de ese nombre: como fabricante de dispositivos Android y como una entidad aparentemente vinculada a un desarrollador de placas base. Esas descripciones no resuelven quién es responsable. Bitdefender también encontró teléfonos afectados sin certificados de firmware con el nombre Zediel, por lo que esa identidad de firma no ofrece una explicación completa ni un indicador universal.

Entre los posibles puntos de introducción del malware figuran un fabricante de diseño original, un integrador de firmware, un socio logístico u otro actor de la cadena de distribución. El informe no señaló a ninguno en particular. El hallazgo confirmado fue que el malware llegó en el firmware antes de que se vendieran los teléfonos afectados.

Los reportes de propietarios muestran por qué no basta con eliminar aplicaciones

Propietarios de teléfonos Cubot y Doogee describieron aplicaciones sospechosas que se reinstalaban después de eliminarlas. Un propietario de un Doogee Fire 3 Max señaló que una actualización oficial del firmware introdujo la infección, que volver a una versión anterior la eliminó y que reinstalar la actualización hizo que reapareciera. Se trata de reportes de usuarios, no de un historial verificado de manera independiente para cada versión de firmware afectada.

Algunos propietarios afirmaron que actualizaciones posteriores de los fabricantes resolvieron sus infecciones. Los fabricantes no habían explicado públicamente cómo entró el código malicioso en el firmware afectado. En conjunto, estos testimonios respaldan la necesidad de considerar las versiones de firmware como un elemento esencial de la investigación y la reparación, en lugar de suponer que eliminar una aplicación descargada resuelve el problema.

La secuencia principal establecida por la investigación y los reportes posteriores es la siguiente:

• Durante aproximadamente dos años, Bitdefender observó miles de dispositivos afectados en más de 150 países.
• El 8 de octubre de 2026, Bitdefender publicó su investigación sobre Midnight Mimosa.
• El 9 de octubre de 2026, se actualizó el informe técnico.
• Según reportes publicados el 12 de octubre, las aplicaciones relacionadas de Google Play y la responsabilidad por el firmware afectado seguían siendo motivos de preocupación sin resolver.

Bitdefender señala que para eliminar la infección es necesario actuar sobre el firmware o desactivar el componente malicioso mediante Android Debug Bridge, conocido habitualmente como ADB. ADB es una herramienta que permite que una computadora se comunique con un dispositivo Android para tareas de depuración y administración. Desactivar un componente no equivale a reemplazar el firmware comprometido por una versión verificada como limpia.

No se estableció un comando de eliminación universal ni una lista confirmada de versiones limpias del firmware. Los propietarios deberían solicitar una solución verificada o un reemplazo al vendedor o al fabricante, en lugar de suponer que una actualización es segura solo porque se presenta como oficial. Mientras no se resuelva la situación, es prudente evitar las operaciones bancarias, la autenticación de cuentas sensibles y el almacenamiento de información importante en un dispositivo cuya infección se conozca.

La preocupación también abarca permisos sensibles cuyo uso los investigadores no observaron. Los permisos de Accesibilidad y Acceso a notificaciones se concedían y revocaban repetidamente, y había permisos para SMS. Si el código proporcionado a distancia los activara, esas capacidades podrían exponer el contenido de la pantalla, las notificaciones o los mensajes de verificación. Se trata de un riesgo demostrado, no de una prueba de que Midnight Mimosa robara esos datos durante el análisis.

Puntos clave

• Midnight Mimosa se encontró integrado en el firmware de Android antes de que los dispositivos afectados llegaran a sus compradores.
• Bitdefender observó miles de dispositivos afectados en más de 150 países durante aproximadamente dos años.
• La operación distribuyó al menos 32 aplicaciones encubiertas con cargas maliciosas; 13 aplicaciones de Google Play compartían su código de fraude publicitario y su infraestructura.
• Los privilegios del sistema permitían instalar aplicaciones sin avisar, conceder permisos y cargar código a distancia.
• Se confirmó el registro en el proxy, pero no se observó el reenvío activo de tráfico en el dispositivo de prueba.
• Los certificados de firma del firmware no permitieron determinar quién introdujo el malware ni si sus titulares estaban implicados.
• Eliminar únicamente las aplicaciones de camuflaje no resuelve el problema del componente persistente. Para eliminar la infección es necesario actuar sobre el firmware o desactivar ese componente.