Las actualizaciones de AOMEI Backupper repartieron una puerta trasera en ventanas de pocos minutos

El 16 de julio de 2026, entre las 08:33 y las 08:39 UTC, el servidor de actualizaciones de AOMEI ofreció a los clientes de AOMEI Backupper una versión que la empresa no había publicado. Pocos minutos después volvía a servir los ficheros auténticos, y quien lo revisara entonces no encontraba rastro de la manipulación.

Google Threat Intelligence Group (GTIG) y Mandiant han documentado a mediados de octubre al menos tres manipulaciones de este tipo entre mayo y julio, en una investigación conjunta con el equipo METAL de ManageEngine. Google sigue al grupo responsable como UNC7017 y no le atribuye nacionalidad. El canal de actualizaciones de AOMEI Backupper le sirvió para distribuir una cadena de programas que terminaba en una puerta trasera. GTIG señala que AnyViewer, la herramienta de escritorio remoto del mismo fabricante, depende del mismo mecanismo de actualización.

Las víctimas identificadas están en 11 países, España y Portugal entre ellos, y pertenecen a servicios de TI, telecomunicaciones y educación superior. GTIG describe la selección como oportunista y cree que el alcance es mayor que el que ha podido documentar. El 19 de octubre AOMEI publicó Backupper 8.5.1 y AnyViewer 5.8.1 para Windows con cambios en el canal de actualización, aunque esas versiones no limpian los equipos ya comprometidos.

¿Cómo se convierte un actualizador legítimo en un repartidor de malware sin explotar ningún fallo?

Ninguno de los dos informes publicados en octubre de 2026 describe una vulnerabilidad. METAL precisa que no hubo CVE, ni corrupción de memoria, ni componente sin parchear, y que el atacante se apoyó en el diseño del flujo de actualización, basado en ficheros de configuración remota sin firma. METAL observó la cadena en la versión 8.3.0 de Backupper y posteriores.

¿Qué ficheros manipuló UNC7017 en el servidor de AOMEI?

Según GTIG, los clientes de AOMEI consultan cada cierto tiempo, por HTTPS, dos ficheros de texto alojados en servidores del fabricante. down_html.ini indica la versión disponible, su huella MD5 y la dirección de descarga, y Notifycfg.ini gobierna las ventanas de aviso y las órdenes que esos avisos ejecutan. Ninguno iba firmado criptográficamente. La huella que debería validar el paquete viaja dentro del mismo fichero que dice de dónde descargarlo, así que quien edita ese fichero decide a la vez qué se descarga y contra qué valor se comprueba.

En cada manipulación, UNC7017 subió el número de versión, apuntó la descarga a paquetes suyos y ajustó la huella para que el cliente aceptara el archivo. GTIG describe tres fases de alojamiento: Alibaba Cloud OSS en Hong Kong entre abril y mayo, dominios que imitaban un servicio de almacenamiento (storage-data[.]com) a principios de julio y un contenedor público de Google Cloud Storage el 20 de julio. Ninguno de los informes explica cómo obtuvo el atacante acceso de escritura a los ficheros en el servidor de origen.

¿Cuánto duraban las ventanas de manipulación?

Las tres ventanas confirmadas por GTIG duraron entre cinco y diez minutos. Fueron el 28 de mayo (de 05:40 a 05:50 UTC), el 16 de julio (de 08:33 a 08:39) y el 20 de julio (de 10:35 a 10:40). Solo recibieron instrucciones maliciosas los equipos que consultaron el servidor en esos minutos, y los que lo hicieron antes o después descargaron los ficheros auténticos. GTIG afirma que es la primera vez que observa una manipulación de la cadena de suministro con ventanas tan breves, y tanto Google como The Hacker News dan por probable que hubiera otras fuera de su visibilidad.

¿Por qué el aviso invisible podía filtrar credenciales NetNTLMv2?

En la ventana del 20 de julio, el fichero de avisos abría una ventana de 1x1 píxeles, imperceptible para el usuario, que cargaba una ruta de red WebDAV alojada en una IP del atacante. Al intentar acceder a ella, Windows puede entregar la respuesta de autenticación NetNTLMv2 del usuario, que después se puede intentar romper por fuerza bruta fuera de línea o retransmitir contra otros servicios. Esta vía no necesita ejecutar ningún programa del atacante en el equipo.

¿Qué instalaba la cadena de malware después?

El primer ejecutable, al que Google llama CROSSROAD, comprobaba si se ejecutaba desde una carpeta de AOMEI y, si no era así, preparaba su borrado sin dejar de trabajar. También consultaba la geolocalización del equipo y, en algunas ramas de ejecución, abandonaba la carga principal si el país era China. METAL añade que se detenía si la geolocalización fallaba y que buscaba determinados agentes de seguridad.

Si seguía adelante, instalaba Radmin, una herramienta comercial de administración remota, creaba una tarea programada y se borraba. METAL describe un instalador auténtico y firmado de Famatech, mientras que GTIG habla de una versión modificada de Radmin Server.

La puerta trasera, SHINYROAD, entraba por carga lateral de DLL (un ejecutable legítimo y firmado, FamItrfc.exe, carga sin saberlo una biblioteca del atacante, BlkScrDl.dll, colocada en su misma carpeta). En algunos equipos llegó además, desde al menos principios de julio, el marco de postexplotación Adaptix C2, disfrazado de componentes de Nitro PDF.

¿Cómo se descubrió la campaña y qué respondió AOMEI?

Según el informe de METAL, su EDR registró el 28 de mayo de 2026 que AOMEI Backupper instalaba Radmin en dos equipos de dos organizaciones que no compartían infraestructura, administradores ni proveedores. Uno de esos clientes elevó el caso el 7 de junio. Para entonces el instalador se había borrado y su huella no aparecía en VirusTotal, y por eso la campaña pasó semanas sin nombre.

METAL avisó a AOMEI ese mismo 7 de junio. El fabricante sugirió que el contenido se había interceptado y modificado en tránsito, una explicación que METAL descartó. El equipo reprodujo la descarga en un entorno controlado y obtuvo contenido limpio, así que pasó a vigilar de forma continua las direcciones de descarga de AOMEI. El 16 de julio capturó un paquete manipulado que volvió a su estado auténtico en cuestión de minutos. La ventana del 20 de julio la observaron GTIG y Mandiant mientras la vigilancia de METAL estaba interrumpida.

Mandiant avisó a AOMEI el 17 de julio y le entregó los indicadores. El 29 de julio la empresa respondió que había aplicado medidas correctivas para proteger sus servidores de distribución, sin detallar cuáles. Cuando METAL publicó su informe, aún no había podido verificar por su cuenta que la intrusión estuviera contenida.

The Hacker News revisó el 16 de octubre el registro de cambios público y no encontró cambios en la verificación de actualizaciones hasta la versión 8.5.0 incluida, del 9 de octubre. Tres días después, el registro de cambios de AOMEI Backupper recogió la versión 8.5.1, que añade cifrado asimétrico a los ficheros de configuración remota, abandona el dominio de actualización anterior y separa las actualizaciones de los avisos comerciales. También limita las descargas a sitios oficiales de AOMEI y desactiva las actualizaciones automáticas desde la aplicación.

AOMEI declaró a BleepingComputer que trata el caso como prioritario y que su director técnico dirige la investigación. A 20 de octubre no ha explicado cómo accedió el atacante a sus servidores.

¿Por qué los controles habituales dejaron pasar el ataque?

En este caso, las comprobaciones que un analista hace ante una alerta devolvían respuestas tranquilizadoras. El proceso que lanzaba el instalador era el actualizador del fabricante. Radmin es software comercial firmado, y el ejecutable que cargaba la DLL maliciosa también estaba firmado. El cargador, además, devolvía el down_html.ini del equipo a valores legítimos, de modo que una revisión local posterior no encontraba el número de versión manipulado.

Quien abría la URL del fabricante para comprobar una alerta obtenía ficheros limpios, porque la manipulación ya había terminado. The Hacker News advierte de que esa comprobación puede llevar a cerrar detecciones auténticas como falsos positivos.

METAL apunta además a un factor organizativo. En clientes afectados, sus políticas de comportamiento estaban en modo solo auditoría, que avisa sin bloquear, y el informe pide revisar esa decisión o, al menos, tomarla a conciencia.

¿Dónde quedan las huellas de la campaña entre abril y julio de 2026?

GTIG y METAL recomiendan una búsqueda retrospectiva de amenazas que cubra toda la campaña, que según GTIG arrancó en abril de 2026, aunque la primera ventana confirmada sea del 28 de mayo. Las señales más útiles no dependen de la huella de un fichero determinado.

• Ejecutables lanzados desde las carpetas html\ o Tmphtml\ de AOMEI, en especial un upgrade-now.exe sin firma cuyo proceso padre sea Backupper.exe o ABNotify.exe.
• Tareas programadas llamadas RadminComponentRuntime o NitroRuntime. METAL documenta que la primera se ejecutaba cada tres horas.
• Un Radmin Server instalado en C:\Program Files (x86)\rserver30 sin servicio de escucha, configuración en el registro ni usuarios, el estado que describe METAL.
• El contenido de component.zip desplegado en %LOCALAPPDATA%\Radmin\, con FamItrfc.exe cargando un BlkScrDl.dll sin firma, según GTIG.
• Ficheros NitroPromotion.exe o Eztwain4.dll en %LOCALAPPDATA%\Nitro Pro\ en equipos donde nadie usa Nitro PDF.
• Conexiones salientes a los puertos 41397 o 6800 que cita GTIG, sin una resolución DNS previa según METAL. Las variantes posteriores de SHINYROAD usaban el puerto 443 hacia 8.218.65[.]184, así que esa conexión solo se detecta por la IP.
• Los agentes de usuario Anyviewer-loader/1.0 y Anyviewer-ipcheck/1.0 en el proxy, y tráfico SMB (TCP 445) o WebDAV hacia direcciones de Internet.

Como indicadores de compromiso de red, los informes citan el dominio storage-data[.]com y sus subdominios y las IP 8.210.84[.]56, 8.218.65[.]184 y 47.239.60[.]117. GTIG añade 96.126.191[.]98, que figura como dirección autorizada en la configuración del malware y no como servidor de control. El artículo de GTIG incluye las huellas SHA-256 y las reglas YARA, y METAL publica dos reglas Sigma.

La búsqueda avanzada de Microsoft Defender XDR solo conserva 30 días de datos, así que revisar de abril a julio exige tener esa telemetría en Microsoft Sentinel o en otro SIEM. Con los 90 días de retención que incluye Sentinel, una consulta lanzada el 20 de octubre apenas llega a finales de julio. Cubrir desde abril requiere unos siete meses de retención o una búsqueda en el nivel de archivo. Si las tablas de Defender for Endpoint llegan a Sentinel, una primera consulta en KQL puede ser la siguiente.

DeviceProcessEvents
| where TimeGenerated between (datetime(2026-04-01) .. datetime(2026-08-01))
| where InitiatingProcessFileName in~ ("Backupper.exe", "ABNotify.exe")
| where FolderPath has_any (@"\html\", @"\Tmphtml\")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, FolderPath, ProcessCommandLine, SHA256, ProcessVersionInfoCompanyName

Para las tareas programadas, sus líneas de comando y las conexiones salientes sirve una segunda consulta. En el portal de Defender, la columna de tiempo se llama Timestamp en lugar de TimeGenerated, y el puerto 6800 por sí solo puede dar ruido porque lo usan otras herramientas de descarga.

let start = datetime(2026-04-01);
let end = datetime(2026-08-01);
union
(DeviceEvents
| where TimeGenerated between (start .. end)
| where ActionType == "ScheduledTaskCreated"
| where tostring(AdditionalFields) has_any ("RadminComponentRuntime", "NitroRuntime")),
(DeviceProcessEvents
| where TimeGenerated between (start .. end)
| where ProcessCommandLine has_any ("RadminComponentRuntime", "NitroRuntime")),
(DeviceNetworkEvents
| where TimeGenerated between (start .. end)
| where RemoteIP in ("8.210.84.56", "8.218.65.184", "47.239.60.117", "96.126.191.98")
or RemotePort in (41397, 6800)
or RemoteUrl has_any ("storage-data.com", "serv.oss-cn-hongkong.aliyuncs.com", "storage.googleapis.com/aomeiupdate"))
| project TimeGenerated, DeviceName, ActionType, InitiatingProcessFileName, ProcessCommandLine, RemoteIP, RemotePort, RemoteUrl, AdditionalFields

Si salta una alerta, GTIG recomienda conservar el contenido de la carpeta Tmphtml de AOMEI antes de tocar nada y cruzar los registros del proxy y del cortafuegos con el segundo exacto de la alerta. METAL coincide en preservar los directorios de descarga y revisar la telemetría de red.

¿Qué hacer si AOMEI aparece en el inventario?

Localizar las instalaciones de AOMEI es el primer paso, porque las utilidades de copia, clonado de disco o acceso remoto suelen instalarlas técnicos para una migración puntual y no siempre pasan por el catálogo oficial de software. Un inventario que solo mira el catálogo aprobado puede no verlas. Donde sigan en uso, Backupper debe pasar a la versión 8.5.1 y AnyViewer a la 5.8.1.

Si la búsqueda encuentra rastros, el caso se trata como un incidente de seguridad con investigación completa. GTIG insiste en que la acción correctiva en el servidor no limpia los equipos que ya descargaron la carga, porque la tarea programada sigue en ellos. La respuesta habitual pasa por aislar el equipo, recoger evidencias, reinstalarlo desde una imagen conocida y cambiar las credenciales de los usuarios que trabajaron en él, por la posible filtración de NetNTLMv2. Un servicio de respuesta a incidentes con experiencia forense puede acortar ese trabajo.

Aunque la búsqueda salga limpia, hay controles que reducen la exposición a ataques parecidos.

• La salida de SMB y WebDAV hacia Internet se bloquea en el perímetro. La medida dificulta la vía del 20 de julio (el bloqueo de WebDAV exige revisar también el tráfico web saliente, no solo el puerto 445) y encaja en un plan para retirar NTLM sin romper la red.
• La regla ASR de Microsoft Defender que bloquea ejecutables poco frecuentes, recientes o ajenos a una lista de confianza requiere la protección en la nube. Puede frenar un instalador sin firma y nunca visto como upgrade-now.exe, aunque probablemente no frene las piezas firmadas de la cadena.
• Los procesos hijos sin firma de todos los actualizadores, no solo los de AOMEI, se vigilan con la misma lógica que se aplica al abuso de binarios legítimos.

En la gestión de riesgo de terceros, las recomendaciones de ambos informes se traducen en preguntas al fabricante de software instalado en equipos críticos. Interesa saber si protege criptográficamente los ficheros de configuración remota y si la huella del paquete llega por un canal distinto al de la dirección de descarga. También, si el cliente acepta descargas solo desde dominios fijados, si los avisos comerciales están separados de la lógica que ejecuta programas y si esos avisos rechazan rutas file:// y UNC.

¿Cuál es el fallo de diseño que explota UNC7017?

Según los informes de GTIG y METAL, la integridad de las actualizaciones de AOMEI dependía de lo que dijera el servidor en cada momento, de modo que controlar unos minutos era suficiente para el atacante. A finales de agosto, un secuestro de rutas BGP sirvió una actualización troyanizada de Virtualizor con un certificado TLS válido, otro caso en el que el canal cifrado no acreditaba el origen del contenido.

La corrección técnica conocida consiste en firmar lo que se ejecuta y también lo que decide qué se ejecuta, y validarlo en el cliente con una clave que el servidor de descargas no controle. AOMEI describe su cambio de la versión 8.5.1 como cifrado asimétrico, sin precisar si el cliente verifica una firma. En la operación, una alerta sobre software de confianza debería cerrarse con la telemetría de aquel momento y no recargando la URL del fabricante, un error que los ataques a la cadena de suministro de UNC7017 aprovechaban.

Fuentes y atribución: este análisis se basa en los informes públicos de Google Threat Intelligence Group y Mandiant y del equipo METAL de ManageEngine, en el registro de cambios de AOMEI y en la cobertura de The Hacker News y BleepingComputer, con la información disponible a 20 de octubre de 2026. La mención de AOMEI responde a que su infraestructura de distribución fue el vector descrito, y los informes no atribuyen el incidente a una vulnerabilidad de sus productos. La atribución a UNC7017 es la de Google y puede evolucionar.

Aviso: las consultas KQL, los indicadores y las recomendaciones de configuración son orientativos y deben adaptarse a cada entorno y probarse antes de aplicarlos en producción. Los indicadores proceden de terceros, pueden caducar y deben contrastarse siempre con las fuentes originales.