Los servidores de AOMEI habrían sido comprometidos para difundir software malicioso mediante una función promocional integrada en su software de copia de seguridad. Según las investigaciones, los atacantes modificaron brevemente archivos de configuración y luego los devolvieron a su estado original con el fin de ocultar las intrusiones.
Los ataques de cadena de suministro se produjeron entre abril y julio de 2026 y se dirigieron a los sistemas de actualización y notificación que utiliza AOMEI Backupper, una aplicación para Windows destinada a realizar copias de seguridad de datos, clonar discos y restaurar sistemas.
Los investigadores del Threat Analysis Lab (METAL) de ManageEngine, en colaboración con el Threat Intelligence Group (GTIG) de Google y Mandiant, descubrieron la campaña y llevaron a cabo la investigación. En los informes publicados por Google y ManageEngine, la actividad se atribuye a un actor de amenazas identificado como UNC7017, que aprovechó la infraestructura comprometida para distribuir un descargador de malware hasta ahora desconocido llamado CROSSROAD y una puerta trasera denominada SHINYROAD.
Los investigadores localizaron organizaciones afectadas en varios países, entre ellos Estados Unidos, Australia, India, Singapur, España y Suiza, en sectores como servicios de TI, telecomunicaciones y educación superior. No obstante, Google advirtió de que los ataques fueron oportunistas y podrían haber alcanzado a otras entidades que consultaron si había actualizaciones de software durante los breves periodos en los que se distribuyeron los archivos maliciosos.
Funcionamiento del ataque
El primer indicio se detectó el 28 de mayo, cuando el software de seguridad de endpoints de ManageEngine observó que AOMEI Backupper instalaba de forma repentina la herramienta legítima de administración remota Radmin en equipos de dos empresas no relacionadas situadas en países distintos.
La instalación resultaba sospechosa porque la habían iniciado los procesos promocionales integrados de AOMEI, que normalmente se encargan de descargar y mostrar contenidos promocionales y notificaciones. Sin embargo, al intentar reproducir el comportamiento en sus propios sistemas de prueba, los investigadores no encontraron nada malicioso: el software contactaba con los servidores de AOMEI y descargaba el archivo de configuración legítimo.
Pruebas posteriores revelaron que, en lugar de sustituir de forma permanente los archivos en los servidores de AOMEI, los atacantes modificaban momentáneamente dos archivos de configuración empleados por los sistemas de promoción y notificación:
- El primer archivo, down_html.ini, indica a AOMEI Backupper dónde debe descargar los paquetes de actualización.
- El segundo, Notifycfg.ini, controla las notificaciones y puede provocar la ejecución de contenido en el equipo.
Mediante la modificación de esos archivos, los atacantes redirigían el software para que descargara un archivo ZIP malicioso y después utilizaban el mecanismo de notificación para ejecutar el malware sin necesidad de interacción del usuario. Los investigadores de Google confirmaron posteriormente este flujo de ejecución en sus propias pruebas.
Tras no lograr reproducir el ataque original, ManageEngine comenzó a vigilar de forma continua los servidores de AOMEI. El 16 de julio, esa vigilancia logró capturar las modificaciones maliciosas en el momento en que se producían, lo que confirmó que los sistemas de AOMEI estaban sirviendo el contenido malicioso.
Los investigadores también descubrieron que los atacantes habían alterado la suma de verificación esperada en la configuración de actualización, lo que permitía que el archivo malicioso superara las comprobaciones de verificación de archivos del software.
Google y ManageEngine señalaron tres intervalos en los que los servidores de AOMEI enviaron el archivo de configuración malicioso:
- 28 de mayo: ventana de exposición de 10 minutos (05:40 – 05:50 UTC)
- 16 de julio: ventana de exposición de 6 minutos (08:33 – 08:39 UTC)
- 20 de julio: ventana de exposición de 5 minutos (10:35 – 10:40 UTC)
Los atacantes restauraban los archivos de configuración a su forma original en cuestión de minutos, lo que dificultaba la detección del compromiso. Durante esas ventanas, el archivo de configuración malicioso se utilizó para instalar los malware CROSSROAD y SHINYROAD.
Al ejecutarse, el descargador CROSSROAD realizaba un reconocimiento del equipo infectado, descargaba componentes adicionales y establecía persistencia mediante una tarea programada. SHINYROAD es una puerta trasera que utilizaba componentes legítimos de Radmin para cargar código malicioso y establecer una conexión saliente con un servidor de mando y control controlado por los atacantes, lo que les permitía ejecutar comandos y cargas útiles adicionales en los equipos comprometidos.
Durante el ataque del 20 de julio, Google observó además una segunda técnica que intentaba robar hashes de autenticación de Windows al forzar al sistema de notificaciones del software a acceder a un recurso WebDAV controlado por los atacantes mediante una ventana emergente invisible. Esta técnica podía exponer hashes NTLM que el servidor de los atacantes podía recopilar y posteriormente descifrar con diversas herramientas.
Los investigadores también identificaron varias direcciones IP y nombres de host utilizados durante los ataques, entre ellos 8.210.84[.]56, serv.oss-cn-hongkong[.]aliyuncs.com, nombres de host bajo storage-data[.]com y storage.googleapis.com, un endpoint legítimo de Google Cloud Storage.
AOMEI afirma que su CTO investiga el incidente
ManageEngine declaró a BleepingComputer que notificó por primera vez a AOMEI la actividad sospechosa el 7 de junio, más de un mes antes de que los investigadores capturaran directamente los archivos de configuración maliciosos servidos desde sus sistemas. En aquel momento, AOMEI sugirió inicialmente que el contenido podría haber sido interceptado y modificado durante el tránsito, una explicación con la que los investigadores no estuvieron de acuerdo.
Las pruebas no respaldaban la explicación de AOMEI sobre una interceptación en tránsito. Ambos endpoints habían obtenido el contenido a través de HTTPS desde nombres de host propiedad de AOMEI, en países distintos y por rutas de red no relacionadas, y el ejecutable había llegado mediante la propia secuencia de extracción de la aplicación, no escrito directamente en el disco por un proceso externo. El contenido había sido alterado antes de llegar a cualquiera de los dos endpoints, dentro de la ruta de entrega alojada por el proveedor.
Cuando ManageEngine capturó otro ataque el 16 de julio, proporcionó de inmediato a AOMEI los hashes de los archivos originales y modificados, las diferencias entre ellos y los archivos alterados. Según ManageEngine, AOMEI se implicó, realizó su propia revisión y comunicó que su examen inicial no había encontrado pruebas de una brecha.
Los investigadores indicaron que AOMEI manifestó su intención de trasladar los archivos de configuración afectados a una nueva infraestructura con registros más detallados. ManageEngine aconsejó a AOMEI que preservara las pruebas existentes antes de efectuar esos cambios y que incorporara especialistas en respuesta a incidentes, y la puso en contacto con Mandiant para que ayudara en la investigación.
AOMEI comunicó posteriormente a los investigadores que su equipo técnico había actualizado sus servidores, corregido posibles vulnerabilidades y verificado que los archivos alojados en su infraestructura eran correctos. Google también confirmó en su informe que Mandiant notificó a AOMEI la manipulación de los archivos de configuración el 17 de julio y que la empresa respondió el 29 de julio afirmando haber adoptado medidas correctivas.
Al ser contactada por BleepingComputer, AOMEI declaró que trataba el asunto como de alta prioridad y que su director de tecnología lideraba una investigación interna.
También hemos detectado este informe internamente y lo hemos clasificado como un asunto de alta prioridad. Nuestro CTO está liderando actualmente una investigación dedicada para garantizar una identificación precisa del problema.
La empresa señaló que su CTO ofrecería una respuesta más detallada sobre el incidente y el avance de la investigación, y BleepingComputer actualizará el artículo si recibe nueva información. AOMEI no confirmó de inmediato cómo obtuvieron los atacantes acceso a su infraestructura de actualización ni si el compromiso denunciado se ha resuelto por completo.
Aunque AOMEI asegura haber protegido sus servidores, ManageEngine advierte de que esos cambios no eliminan el malware instalado previamente en los equipos de los clientes.
Una corrección en el servidor detiene las nuevas infecciones, pero no elimina la puerta trasera de las máquinas que la recibieron durante una ventana anterior.
Se recomienda a las organizaciones que utilizan AOMEI Backupper que revisen los indicadores de compromiso publicados por Google y ManageEngine, incluidos tareas programadas sospechosas, archivos ejecutables inesperados en los directorios de instalación de AOMEI y conexiones con la infraestructura controlada por los atacantes.
Contexto adicional
Un análisis complementario advierte de que las puntuaciones globales de prevención pueden ocultar lo que ocurre después del acceso inicial. Cuando los atacantes utilizan credenciales válidas, la capacidad de prevención cae de forma acusada. El Blue Report 2026 mide las defensas técnica por técnica a partir de 338 millones de simulaciones realizadas en entornos de producción de clientes.
Deja una respuesta