Las actualizaciones de AOMEI Backupper sirvieron un backdoor en España

Google Threat Intelligence Group (GTIG) y Mandiant confirmaron el 15 de octubre de 2026 que un grupo al que siguen como UNC7017 manipuló los servidores de actualización de AOMEI Backupper entre abril y julio de 2026 para instalar el backdoor SHINYROAD en los equipos que comprobaban actualizaciones, y España figura entre los once países con organizaciones afectadas. Cada manipulación duró entre cinco y diez minutos, AOMEI dice haber corregido sus servidores desde el 29 de julio y ningún arreglo del lado del fabricante limpia los equipos que descargaron el paquete en una de esas ventanas.

Qué ha pasado

AOMEI Backupper es un programa de copias de seguridad y clonado de discos para Windows de AOMEI Technology, una empresa registrada en Hong Kong según The Hacker News. Igual que AnyViewer, la herramienta de escritorio remoto del mismo fabricante, mantiene dos servicios en segundo plano (Backupper.exe y ABNotify.exe) que consultan por HTTPS los servidores de AOMEI en busca de actualizaciones y de ventanas promocionales. Esa consulta rutinaria fue el vector del ataque.

Según el informe de GTIG y Mandiant, publicado el 15 de octubre y firmado por Tyler McLellan, UNC7017 alteró de forma repetida dos ficheros de configuración alojados en los servidores de origen de AOMEI durante ventanas de cinco a diez minutos y después restauró los contenidos auténticos. El laboratorio no había visto antes un compromiso de cadena de suministro con ventanas tan cortas, y describe el método como «effectively evading traditional point-in-time triage and automated file scanning» (que evade con eficacia el triaje puntual tradicional y el escaneo automático de ficheros). Cualquier copia del programa que consultase el servidor en uno de esos minutos descargaba un ZIP con el cargador CROSSROAD y lo ejecutaba sin intervención del usuario.

La campaña la detectó primero el ManageEngine Threat Analysis Lab (METAL), de Zoho, cuya telemetría de EDR registró el 28 de mayo de 2026 que AOMEI Backupper instalaba Radmin, una herramienta comercial de administración remota, en dos clientes sin relación entre sí y en países distintos. Un cliente escaló la alerta el 7 de junio y METAL avisó a AOMEI ese mismo día. Mandiant notificó al fabricante el 17 de julio con indicadores y AOMEI respondió el 29 de julio que había tomado medidas correctoras en su infraestructura. METAL publicó su propio análisis el 16 de octubre, firmado por Vishal Santharam, Praveen Kumar D y Veeramani Somasundaram.

Con telemetría propia, GTIG identificó organizaciones afectadas de servicios TI, telecomunicaciones y educación superior en Australia, Brasil, India, Pakistán, Portugal, Singapur, Sudáfrica, España, Suiza, Turquía y Estados Unidos. El laboratorio no da un total y advierte de que la cifra real es mayor, porque el ataque golpeaba a cualquier equipo que consultase el servidor durante la ventana, sin selección previa de víctimas. Es el segundo ataque a la cadena de suministro que cubrimos esta semana, tras el implante LTE en dispositivos Ledger.

Detalles técnicos

El diagrama de GTIG resume el mecanismo. Backupper.exe y ABNotify.exe consultan de forma periódica dos ficheros remotos. El primero, down_html.ini en www2.aomeisoftware.com, contiene el número de versión, el hash MD5 del paquete esperado y la URL desde la que descargar upgrade-now.zip. El segundo, Notifycfg.ini en account.aomeitech.com, indica al proceso de notificaciones qué mensajes mostrar y qué programas del directorio local ejecutar. Ninguno de los dos va firmado y el cliente tampoco verifica la firma Authenticode de lo que descarga, así que el MD5 que debería garantizar la integridad del ZIP viaja en el mismo fichero sin autenticar que indica dónde descargarlo.

Durante cada ventana, el atacante modificaba down_html.ini para apuntar la descarga a sus propios servidores, incrementaba el número de compilación menor (el parámetro thrid pasó de 5 a 6 el 16 de julio y a 7 el 20 de julio) y sincronizaba el MD5 con el ZIP malicioso. Durante la misma ventana inflaba Notifycfg.ini con más de 35.000 líneas de secciones repetidas del tipo [dummy_XXXXXX] para anular la comprobación de versión del cliente y forzar la ejecución inmediata de upgrade-now.exe desde el directorio html del programa. METAL reconstruyó la cadena en un esquema de diez pasos en el que los tres primeros son la aplicación funcionando tal y como fue diseñada, y la desviación empieza en el cuarto, cuando ABNotify.exe renderiza el HTML manipulado.

La infraestructura de descarga cambió tres veces. Entre abril y mayo los paquetes se alojaban en un bucket de Alibaba Cloud OSS (serv.oss-cn-hongkong.aliyuncs.com). Del 1 al 7 de julio el grupo pasó a dominios propios con nombre de fabricante (storage-data.com, promotion.storage-data.com y aomei.storage-data.com). El 20 de julio dirigió la descarga inicial a un bucket público de Google Cloud Storage (storage.googleapis.com/aomeiupdate/upgrade-now.zip) para saltarse los proxies corporativos que bloquean dominios recién registrados, mientras el cargador seguía usando storage-data.com para la segunda fase y el mando y control.

CROSSROAD es un ejecutable de 64 bits escrito en C que se hace pasar por un componente de AOMEI, con metadatos de editor del fabricante y una errata en el nombre de producto (AOMEI Update Compent) que no aparece en ninguna compilación legítima. Antes de hacer nada comprueba que su ruta contiene la cadena AOMEI, resuelve la IP pública del equipo mediante servicios externos (myip.opendns.com, checkip.amazonaws.com, api.ipify.org, ifconfig.me o icanhazip.com) con el User-Agent Anyviewer-loader/1.0 y aborta si el país es China, si la geolocalización falla o, según METAL, si detecta determinados agentes de seguridad en el equipo. Adquiere el mutex Global\{F9E6E3C0-E11A-4F85-9944-AF4AD6E05883} y restaura en el down_html.ini local el valor thrid=5 y la URL legítima de AOMEI, de forma que un análisis posterior del equipo encuentra la configuración limpia.

Si pasa los filtros, descarga component.zip (también visto como en.zip) a %TEMP%\svc<hex>.tmp, lo descomprime en %LOCALAPPDATA%\Radmin\ con una copia embebida de miniz y crea la tarea programada RadminComponentRuntime, que ejecuta FamItrfc.exe --runtimechk cada tres horas. Después se borra a sí mismo con un truco de NTFS. Lanza una copia con el parámetro --nitrod, renombra su flujo de datos principal a un flujo alternativo llamado :wtfbbq y marca el fichero para eliminarlo al cerrar el handle. En la oleada del 28 de mayo también ejecutó rsetup64.exe /intsetup, el instalador legítimo de Radmin Server, aunque METAL encontró el servicio sin escucha, sin configuración y sin cuentas nuevas, y lo resume así: «The Radmin component was staged but never armed» (el componente Radmin se preparó pero nunca se activó).

El control remoto real lo da SHINYROAD. FamItrfc.exe es un binario auténtico firmado por Famatech que, al arrancar, carga por secuestro del orden de búsqueda la DLL BlkScrDl.dll del atacante, con el nombre de la librería de pantalla en negro de Radmin. Esa DLL mapea config.zip en una sección de memoria compartida (Local\963d3c60-d406-4ad6-aa1e-dc8e45061ccf) y registra csvc\RuntimeComponent.dll como servidor COM en proceso con el CLSID {21191641-0D7F-4CD9-9572-01AAE6E7851B}. Cuando el proceso instancia ese CLSID, la DLL descifra metadata.dat con ChaCha20 y ejecuta el bytecode Python resultante en un intérprete PocketPy embebido, que abre la conexión con el C2 en 8.218.65.184:443 (las variantes anteriores usaban TCP en bruto por el puerto 41397). El implante ofrece shell remota, genera tráfico basura para romper firmas de red y carga extensiones en memoria sin escribir módulos en disco. El uso de un ejecutable firmado para cargar una DLL ajena es la misma técnica que ya desmontamos al analizar el troyano AsyncRAT.

A mediados de julio, GTIG observó una tercera fase sobre equipos ya infectados. UNC7017 desplegó ADAPTAGENT, el cliente del framework de post-explotación de código abierto Adaptix C2, camuflado como herramientas de Nitro PDF (NitroPromotion.exe carga la DLL Eztwain4.dll desde %LOCALAPPDATA%\Nitro Pro\), con la tarea programada \NitroRuntime y balizas cada dos minutos hacia 8.210.84.56:6800.

La ventana del 20 de julio añadió un segundo vector que no necesita ejecutar nada. En lugar del banner promocional de 400x380 píxeles que mostraba Notifycfg.ini, el atacante configuró una ventana invisible de 1x1 píxel con prioridad máxima (Priority=9999) que ordenaba al cliente renderizar un HTML remoto por WebDAV en la ruta \\8.210.84.56\DavWWWRoot\campaign\24hour-flash-sale.html. Al pedir ese recurso, Windows puede enviar el hash NetNTLMv2 del usuario conectado al servidor del atacante sin que nada aparezca en pantalla. Un equipo que bloqueó el ejecutable pudo filtrar igualmente sus credenciales.

GTIG publica estos indicadores de red y de fichero. Las IP 8.210.84.56, 8.218.65.184 y 47.239.60.117 son de alojamiento compartido y conviene contrastarlas antes de bloquear.

METAL publica dos reglas Sigma que detectan comportamiento y ubicación en lugar de hashes, de modo que siguen sirviendo aunque el atacante recompile el cargador. Esta dispara cuando ABNotify.exe lanza cualquier ejecutable desde el árbol html del programa, algo que un paquete promocional legítimo nunca hace:

title: AOMEI ABNotify Spawning Executable From Rendering Directory
id: 3768e7d0-ba38-48fa-a630-d25bb50438de
status: experimental
author: Veeramani
date: 2026-06-11
tags:
  - attack.stealth
  - attack.t1036.005
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|contains: '\AOMEI\AOMEI Backupper\'
    ParentImage|endswith: '\ABNotify.exe'
  selection_child:
    Image|contains|all:
      - '\AOMEI\AOMEI Backupper\'
      - '\html\'
    Image|endswith: '.exe'
  condition: all of selection_*
falsepositives:
  - None known; legitimate AOMEI rendering bundles observed contain no executables
level: high

La segunda regla de METAL cubre el paso anterior, Backupper.exe escribiendo un ejecutable en el directorio tmphtml. GTIG acompaña su informe con cuatro reglas YARA de Mandiant (una para CROSSROAD, dos para SHINYROAD y una para ADAPTAGENT) y asigna la campaña, entre otras, a las técnicas MITRE ATT&CK T1195.002 (compromiso de la cadena de suministro de software), T1574.001 (secuestro del orden de búsqueda de DLL), T1053.005 (tarea programada), T1187 (autenticación forzada) y T1480 (guardarraíles de ejecución).

A quién afecta

A cualquier equipo Windows con AOMEI Backupper instalado que consultase el servidor de actualizaciones durante una de las ventanas de manipulación, entre abril y julio de 2026. METAL observó la cadena sobre la versión 8.3.0 y ninguno de los dos informes acota qué versiones son vulnerables, porque el problema está en el diseño del canal de actualización, común a todas las versiones, y no en el código de una compilación concreta. GTIG señala que AnyViewer usa el mismo flujo de configuración remota, aunque las detecciones descritas afectan a Backupper. The Hacker News comprobó el 16 de octubre que el registro de cambios de AOMEI no menciona ninguna modificación en la verificación de actualizaciones hasta la versión 8.5.0, del 9 de octubre, y ninguno de los informes señala una versión que cierre el problema.

El reparto por países sitúa a España y Portugal entre los once con organizaciones afectadas, en los sectores de servicios TI, telecomunicaciones y educación superior. En el momento de escribir esta noticia, la tarde del 16 de octubre de 2026, no hay un recuento de víctimas por país ni aviso de INCIBE-CERT o del CCN-CERT sobre esta campaña. AOMEI Backupper tiene una edición gratuita muy extendida entre particulares y pymes, y ese perfil de usuario rara vez dispone de un EDR que registre lo que hace un actualizador. Las organizaciones de las que partió la detección tenían las políticas de comportamiento de ManageEngine en modo auditoría, así que la actividad quedó registrada pero no bloqueada, un detalle que METAL recomienda revisar en cualquier producto.

Qué hacer

Estas consultas de PowerShell buscan en un equipo las tareas programadas, los directorios y la errata del nombre de producto que dejan CROSSROAD y SHINYROAD. Hay que ejecutarlas con privilegios de administrador en cada host con AOMEI Backupper o AnyViewer:

Get-ScheduledTask | Where-Object { $_.TaskName -in @('RadminComponentRuntime','NitroRuntime') } | Format-List TaskName, TaskPath, State
Get-ScheduledTask | ForEach-Object { $_.Actions } | Where-Object { $_.Arguments -match 'runtimechk' }
Test-Path "$env:LOCALAPPDATA\Radmin\BlkScrDl.dll"; Test-Path "$env:LOCALAPPDATA\Radmin\csvc\RuntimeComponent.dll"
Test-Path "$env:LOCALAPPDATA\Nitro Pro\Eztwain4.dll"; Test-Path "C:\Program Files (x86)\rserver30"
Get-ChildItem "${env:ProgramFiles(x86)}\AOMEI" -Recurse -Include *.exe -ErrorAction SilentlyContinue | Where-Object { $_.FullName -match '\\(tmphtml|html)\\' }
Get-ChildItem "${env:ProgramFiles(x86)}\AOMEI" -Recurse -Include *.exe -ErrorAction SilentlyContinue | Where-Object { $_.VersionInfo.ProductName -like '*Compent*' }

1. Inventaría todos los equipos con AOMEI Backupper o AnyViewer, incluidos portátiles de teletrabajo y servidores de ficheros, y lanza sobre ellos las consultas anteriores y las reglas Sigma de METAL y YARA de GTIG. La ventana de búsqueda abarca de abril a julio de 2026 y no se limita a las tres fechas confirmadas.
2. Si aparece cualquier artefacto, aísla el equipo y no lo apagues. Preserva el contenido de las carpetas Tmphtml y html dentro de la instalación de AOMEI, el registro de tareas programadas y una imagen de memoria, y recoge los logs del proxy y del firewall del segundo exacto en que saltó la alerta. No uses el estado actual de la URL de AOMEI como prueba de nada, porque el servidor devuelve ficheros limpios casi todo el tiempo.
3. Bloquea en el firewall y en el proxy las salidas hacia storage-data.com y sus subdominios, las tres IP del informe y el bucket serv.oss-cn-hongkong.aliyuncs.com, y revisa los registros del proxy en busca del User-Agent Anyviewer-loader/1.0 o de descargas desde storage.googleapis.com/aomeiupdate.
4. Corta el SMB (TCP 445) y el WebDAV salientes hacia Internet en el perímetro. Es la única defensa contra la ventana de 1x1 píxel y vale para cualquier otro ataque de autenticación forzada.
5. En los equipos que estuvieron expuestos el 20 de julio, da por filtrado el hash NetNTLMv2 del usuario conectado y cambia su contraseña. Si se trata de cuentas de dominio, revisa en los controladores los inicios de sesión de esa cuenta desde ese día.
6. Reconstruye desde cero los equipos con SHINYROAD o ADAPTAGENT confirmados. El implante carga código en memoria a demanda, así que no hay forma de saber qué más ejecutó el operador. Rota después las credenciales que se usaron en ese host.
7. Mientras AOMEI no publique un cliente que verifique firmas, restringe en el firewall el tráfico de Backupper.exe y ABNotify.exe a los dominios del fabricante y bloquea las descargas de ejecutables desde almacenamiento público en la nube para esos procesos. Si tu EDR tiene las políticas de comportamiento en modo auditoría, pásalas a bloqueo tras comprobar los falsos positivos.
8. Carga las dos reglas Sigma en el SIEM y vigila cualquier proceso hijo sin firma que nazca de cualquier actualizador, sea o no el de AOMEI. Nuestra guía sobre métodos de búsqueda de amenazas explica cómo organizar esa caza.
9. Notifica el incidente a INCIBE-CERT si eres empresa o particular, y al CCN-CERT si perteneces al sector público. GTIG ya ha avisado a las organizaciones que identificó, pero su lista no es completa.

Análisis

Para quien gestiona endpoints, lo nuevo de esta campaña está en el reloj, no en el malware. Un atacante que solo altera el servidor durante cinco minutos convierte en inútil la comprobación más habitual de un analista de SOC, que es abrir la URL del fabricante para ver si sirve algo raro. GTIG describe esa trampa de triaje con nombre propio y METAL cuenta que su propia reproducción, horas después de la detección, devolvió un flujo impecable. Si la alerta de un actualizador se cierra como falso positivo porque el servidor está limpio, el backdoor se queda. La única evidencia fiable es lo que el endpoint recibió en ese instante, y eso obliga a que el EDR guarde los artefactos y a que los equipos de respuesta aprendan a desconfiar de las comprobaciones en vivo.

Lo que no dicen los informes también pesa. Ni GTIG ni METAL explican cómo consiguió UNC7017 escribir en los servidores de origen de AOMEI, y el fabricante no ha publicado comunicado alguno más allá de decir a los investigadores que había tomado medidas. Su primera explicación, que el contenido se había interceptado en tránsito, no se sostenía ante dos descargas por HTTPS desde dominios propios en países distintos. METAL es explícita al cerrar su informe: «we have not independently verified that the compromise has been contained» (no hemos verificado de forma independiente que el compromiso esté contenido). Con un canal de actualización que sigue sin firmar sus ficheros de configuración, la repetición del ataque es cuestión de tiempo.

Hay precedentes que ayudan a calibrar. En 2021 contamos el backdoor escondido en instaladores de IDA Pro, un caso en el que el binario manipulado quedó disponible y pudo analizarse a posteriori. Aquí el atacante ha aprendido de esos casos y ha eliminado el rastro en origen, en el cliente (CROSSROAD restaura el ini local) y en disco (el cargador se borra a sí mismo). Es la misma lógica de persistencia por debajo de lo que ve el administrador que Mandiant acaba de documentar en los appliances de BeyondTrust, llevada ahora a software de consumo. Es previsible que otros actores copien la técnica contra cualquier programa de escritorio que lea instrucciones de un fichero remoto sin firma, y hay muchos.

Cronología

• Abril de 2026: primeras muestras de CROSSROAD alojadas en Alibaba Cloud OSS, según GTIG.
• 20 de mayo: un cargador upgrade-now.exe con marcas de compilación falsificadas de 2024 llega a VirusTotal.
• 28 de mayo, 05:40 a 05:50 UTC: ventana de diez minutos. El EDR de ManageEngine registra la instalación de Radmin en dos clientes de países distintos.
• 7 de junio: un cliente escala la alerta y METAL notifica a AOMEI, que atribuye el contenido a una interceptación en tránsito.
• 1 a 7 de julio: UNC7017 pasa a los dominios storage-data.com.
• 16 de julio, 08:33 a 08:39 UTC: ventana de seis minutos. METAL la captura en vivo y comparte el perfil completo con Mandiant el 17 de julio, el mismo día en que Mandiant avisa a AOMEI.
• 20 de julio, 10:35 a 10:40 UTC: ventana de cinco minutos con descarga desde Google Cloud Storage y popup WebDAV para robar hashes NTLM.
• 29 de julio: AOMEI comunica a Mandiant que ha tomado medidas correctoras.
• 15 y 16 de octubre: GTIG y METAL publican sus informes.

La cronología de METAL marca en rojo los dos hechos que su telemetría vio de forma directa, la detección del 28 de mayo y la captura del 16 de julio, y deja claro que la ventana del 20 de julio solo la vio Mandiant porque el monitor del laboratorio estaba caído.

Preguntas frecuentes

¿Tengo que desinstalar AOMEI Backupper?

Ningún informe lo pide, y las copias de seguridad que gestiona siguen siendo válidas. Lo que sí conviene es tratar el programa como lo que es, un actualizador sin verificación de firmas, y limitar su salida a Internet a los dominios de AOMEI hasta que el fabricante publique un cliente que valide la configuración remota. Si el equipo nunca consultó el servidor en una ventana de manipulación, no hay nada que limpiar.

¿Cómo sé si mi equipo descargó el paquete malicioso?

Busca las tareas programadas RadminComponentRuntime y NitroRuntime, los directorios Radmin y Nitro Pro dentro de AppData\Local, la carpeta rserver30 en Archivos de programa (x86) y cualquier ejecutable dentro de las carpetas html o tmphtml de la instalación de AOMEI. En el proxy, revisa conexiones a storage-data.com o al bucket aomeiupdate de Google Cloud Storage entre abril y julio. Si el cargador abortó por sus propias comprobaciones, puede no haber ningún rastro.

¿Por qué el servidor de AOMEI parece limpio si estuvo comprometido?

Porque el atacante restauraba los ficheros auténticos al cabo de cinco o diez minutos, y porque el propio cargador reescribe el down_html.ini local del equipo infectado con la URL legítima. Un analista que compruebe la URL del fabricante o la configuración del cliente horas después verá exactamente lo que vería en un equipo sano. Por eso la evidencia del endpoint en el momento de la alerta pesa más que cualquier verificación posterior, como explicamos en nuestro texto sobre el juego de las evidencias y el threat hunting.