Los atacantes colaron un backdoor por los propios servidores de actualización de AOMEI Backupper

AOMEI Backupper es software de copia de seguridad y clonación de discos para Windows. También mantiene un servicio en segundo plano que consulta los servidores de AOMEI Technology en busca de avisos de actualización y contenido de ventanas emergentes. Entre mayo y julio de 2026, los atacantes cambiaron lo que esos servidores devolvían durante ventanas breves, y cualquier copia instalada que se conectó durante una de ellas descargó y ejecutó un backdoor.

Lectura relacionada: Un ataque a la cadena de suministro de Brevo inyectó el malware ClickFix con una clave robada de Cloudflare · Los atacantes usaron la identidad de aplicación de ConnectWise Cloud Backup para entrar en inquilinos de Microsoft 365.

Google Threat Intelligence Group y Mandiant, en colaboración con el Threat Analysis Lab de ManageEngine, revelaron la campaña en la semana del 13 de octubre de 2026. The Hacker News y ManageEngine publicaron relatos detallados el 16 de octubre.

Los informes no dicen cómo obtuvieron los atacantes acceso de escritura a la infraestructura de AOMEI. Sí muestran lo que ese acceso les dio: un compromiso de la cadena de suministro que no requirió ningún mensaje de phishing, ni un sitio de descarga falso, ni un fallo en el programa de copia de seguridad. El software hizo lo que estaba diseñado para hacer, y la carga útil llegó por el propio canal de actualización del fabricante.

Tres ventanas, y probablemente más

GTIG y Mandiant confirmaron tres ventanas de manipulación. La primera duró 10 minutos el 28 de mayo de 2026, de 05:40 a 05:50 UTC. La segunda duró seis minutos el 16 de julio, de 08:33 a 08:39 UTC. La tercera duró cinco minutos el 20 de julio, de 10:35 a 10:40 UTC. El monitoreo de ManageEngine detectó por su cuenta el cambio del 16 de julio mientras ocurría.

Los investigadores dijeron que probablemente hubo más ventanas, con manipulaciones que se remontan a abril de 2026. Esa estimación importa más que las tres fechas confirmadas. Una campaña basada en ventanas tan cortas no necesita muchos intentos para llegar a muchas máquinas, porque el objetivo es cualquiera que ejecute una comprobación de actualización mientras el archivo está alterado.

GTIG identificó organizaciones afectadas en servicios informáticos, telecomunicaciones y educación superior en 11 países: Australia, Brasil, India, Pakistán, Portugal, Singapur, Sudáfrica, España, Suiza, Turquía y Estados Unidos. No dio un total y dijo que la cifra real probablemente sea mayor. Ninguno de los dos informes atribuye la campaña a un Estado ni nombra a un actor. GTIG sigue al grupo como UNC7017.

La ruta de actualización confiaba en sí misma

El flujo de actualización de Backupper usa dos archivos de configuración, down_html.ini y Notifycfg.ini. No están firmados. Indican al programa qué descargar y qué contenido de ventana emergente mostrar, y ninguno está autenticado criptográficamente. La suma de comprobación que se usa para verificar una descarga se declara dentro del mismo archivo sin autenticar que nombra la descarga, así que un atacante que puede cambiar el archivo también puede cambiar el valor destinado a demostrar que es legítimo.

HTTPS protegía la transferencia. No protegía el contenido, porque el contenido venía de los propios servidores de AOMEI y se servía por una conexión válida. Esta es la parte de la historia que importa más allá de esta familia de malware. La seguridad del transporte responde a si un servidor es quien dice ser. No dice nada sobre si el archivo que ese servidor entrega debería ser de confianza.

GTIG describió la campaña como el primer compromiso de la cadena de suministro en Windows que ha visto construido sobre ventanas de manipulación tan cortas. El informe dijo que el enfoque eludió de forma efectiva el triaje puntual y el análisis automatizado de archivos. Un archivo que es malicioso durante seis minutos y genuino después deja poco para un escáner que mira una sola vez.

El mismo flujo de actualización lo usa AnyViewer, la herramienta de escritorio remoto de AOMEI, y GTIG señala a AnyViewer como también objetivo. Los informes se centran en Backupper, así que no se sabe cuántas instalaciones de AnyViewer se conectaron durante una ventana de manipulación.

De una notificación a una tarea programada

La cadena del 20 de julio muestra hasta dónde llegó la manipulación. El archivo de notificación alterado apuntaba la ventana emergente dentro de la aplicación a un ejecutable empaquetado llamado upgrade-now.exe. El archivo llevaba metadatos de editor de AOMEI, pero no estaba firmado, y su cadena de producto decía «AOMEI Update Compent», con «component» mal escrito.

Ejecutarlo instalaba un Radmin Server auténtico y firmado de Famatech. Junto al lanzador firmado de Radmin, FamItrfc.exe, el dropper colocaba una DLL creada por el atacante llamada BlkScrDl.dll. El lanzador firmado cargaba la DLL desde su propia carpeta, un caso clásico de carga lateral. Esa DLL cargaba el implante, RuntimeComponent.dll, el backdoor que GTIG llama SHINYROAD. El implante se registraba como servidor COM dentro del suplente firmado dllhost.exe y llevaba una carga útil de PocketPy cifrada e incrustada. La persistencia venía de una tarea programada llamada RadminComponentRuntime, configurada para ejecutarse cada tres horas.

Las partes maliciosas eran el dropper sin firma, la DLL de carga lateral y el implante. Todo lo que tocaban estaba firmado o era un proceso legítimo de Windows. Por eso la actividad es difícil de detectar solo con una comprobación de reputación de archivos.

ManageEngine sigue el dropper como CROSSROAD. Se eliminaba a sí mismo tras su uso, comprobaba la dirección IP pública del host y se detenía si la geolocalización indicaba China o si fallaba, y se detenía si encontraba ciertos agentes de seguridad de equipos. Esas comprobaciones apuntan a una operación cuidadosa y dirigida, más que a una campaña amplia e indiscriminada. También implican que una máquina fuera del conjunto objetivo puede no haber ejecutado nunca la carga útil aunque haya descargado el dropper.

El implante se conectaba a un único punto de mando y control codificado, 8.218.65.184 en el puerto 41397, sin alternativa. La dirección solo se descifra en tiempo de ejecución, así que no aparece en el archivo en reposo. Ese único punto es una debilidad en el diseño del implante: bloquear el tráfico saliente hacia él corta el único canal de control que encontraron los investigadores. Las direcciones son volátiles, y esta procede del análisis de los investigadores, no de AOMEI.

Durante la ventana del 20 de julio, GTIG también encontró el archivo de notificación cambiado para abrir una ventana emergente invisible de un píxel. La ventana apuntaba a un archivo remoto mediante una ruta WebDAV o UNC. Al renderizarla, Windows podía enviar al atacante el material de autenticación NetNTLMv2 del usuario con la sesión iniciada, sin nada visible en pantalla y sin ejecutar ningún programa.

Esa segunda vía importa porque se salta la suposición habitual de que un ataque a la cadena de suministro tiene que entregar código. Una filtración de credenciales de ese tipo puede usarse después, desde otra red y otra herramienta, contra sistemas que nunca ejecutaron el backdoor. Los investigadores la presentan como una capacidad que observaron en el archivo manipulado, no como prueba de que se robaran credenciales de todas las redes afectadas.

Qué sabía AOMEI, y cuándo

El software de endpoint de ManageEngine detectó la actividad el 28 de mayo de 2026, el día de la primera ventana confirmada. Un cliente la planteó el 7 de junio, y ManageEngine notificó a AOMEI ese mismo día.

La primera explicación de AOMEI fue que el contenido había sido interceptado en tránsito. ManageEngine dijo que las pruebas no lo respaldaban, porque ambos extremos obtenían los archivos por HTTPS desde hosts propiedad de AOMEI en distintos países. Mandiant notificó a AOMEI el 17 de julio. AOMEI respondió el 29 de julio que sus servidores estaban asegurados.

AOMEI no ha publicado su propio relato más allá de informar de acciones correctivas. Eso deja abierta la causa raíz. Los informes describen la manipulación con detalle y no describen cómo entraron los atacantes, así que la pregunta de si la misma vía de acceso está cerrada depende de la garantía del fabricante y no de pruebas públicas.

El lado del producto tampoco está resuelto. El registro de cambios de AOMEI para Backupper, consultado el 16 de octubre de 2026, no incluía ningún cambio en cómo el programa verifica las actualizaciones hasta la versión actual, la 8.5.0, publicada el 9 de octubre. Tampoco está documentada del todo la gama de versiones afectadas. ManageEngine examinó la versión 8.3.0 y dijo haber observado la 8.3.0 y posteriores. Si los archivos de actualización todavía no pueden autenticarse de forma independiente, un futuro compromiso del servidor tendría el mismo camino hacia el mismo resultado.

Por qué un análisis limpio demuestra poco

La lección defensiva va contra el instinto de revisar un archivo y seguir adelante. Un equipo que descargó el dropper durante una ventana de cinco minutos y lo ejecutó puede pasar un análisis hecho una semana después, porque el archivo de actualización local que dejó atrás se restauró a la versión genuina. Las pruebas que quedan son de comportamiento: una tarea programada, una instalación de Radmin que nadie pidió, una DLL junto a un binario firmado, un proceso que habla con una dirección inusual.

Ese es el argumento para conservar y buscar en la telemetría de los equipos en lugar de fiarse de la reputación puntual. También lo es para tratar un servidor de actualización como parte de la superficie de ataque. Un fabricante que firma sus archivos de configuración y entrega las sumas de comprobación por un canal aparte y autenticado elimina la debilidad concreta que se usó aquí. Los manifiestos firmados de vida corta reducirían aún más la ventana, porque un archivo alterado en el servidor fallaría la verificación en el cliente.

Nada de eso ayuda a una red que ya ejecutó la carga útil. El consejo práctico que se deriva es buscar los componentes de la cadena, bloquear la dirección de mando y control en el perímetro y tratar un resultado limpio del antivirus como el inicio de una investigación y no como su final.

«Eludiendo de forma efectiva el triaje puntual tradicional y el análisis automatizado de archivos.» — Google Threat Intelligence Group, sobre UNC7017, 16 de octubre de 2026

Qué observar

Tres cosas siguen abiertas. La primera es el propio relato de AOMEI sobre la intrusión, que diría cómo se llegó a los servidores y si ha cambiado la verificación de actualizaciones. La segunda es una confirmación independiente de que los servidores están limpios; la única declaración hasta ahora es la del fabricante. La tercera es el recuento de afectados. Los 11 países son un suelo construido a partir de la visibilidad de GTIG.

Para los defensores, la pregunta útil es si alguna máquina del parque ejecutó una comprobación de actualización durante una de las ventanas, y si la telemetría para responder a eso sigue existiendo. La mayoría de las organizaciones probablemente no guardan seis meses de datos de procesos y de red. Las que sí lo hacen pueden distinguir una infección de una coincidencia.

La técnica no depende de AOMEI. Cualquier actualizador que confíe en un manifiesto sin firma del mismo servidor del que lo descarga tiene la misma exposición. El próximo informe puede implicar otro software.

Imagen de portada: «Toshiba 1 TB External USB Hard Drive.jpg» de Editor182, dominio público, vía Wikimedia Commons.