EN
en direct

Des attaquants détournent les serveurs de mise à jour d’AOMEI Backupper pour diffuser un backdoor

Entre avril et juillet 2026, des attaquants ont brièvement modifié deux fichiers de configuration des serveurs d’AOMEI pour faire télécharger les malwares CROSSROAD et SHINYROAD aux clients de Backupper, par fenêtres de cinq à dix minutes. Si vous utilisez AOMEI Backupper, traquez les indicateurs de compromission : le correctif serveur ne supprime pas le backdoor déjà installé.

Un tapis roulant d’entrepôt sombre chargé de cartons scellés identiques, un carton au ruban de sécurité ambré décollé et le rabat entrouvert.

19 octobre 2026. BleepingComputer révèle que les serveurs de AOMEI ont été compromis pour diffuser un malware via le mécanisme de promotion intégré de Backupper. 28 mai 2026. Première fenêtre d’exposition capturée, d’une durée de dix minutes. 16 juillet 2026. ManageEngine capture en direct la modification malveillante des fichiers de configuration. Pourquoi c’est important : l’attaque a duré des mois, par fenêtres de cinq à dix minutes, et le correctif serveur ne désinfecte pas les machines déjà touchées.

Une attaque supply chain par fenêtres de quelques minutes

Les attaques se sont déroulées entre avril et juillet 2026 et visaient les systèmes de mise à jour et de notification de AOMEI Backupper, l’application Windows de sauvegarde, de clonage de disque et de restauration système.

Les chercheurs du Threat Analysis Lab de ManageEngine (METAL), en collaboration avec le Google Threat Intelligence Group (GTIG) et Mandiant, ont attribué la campagne à un acteur suivi sous le nom de UNC7017. L’infrastructure compromise a servi à distribuer deux malwares jusqu’alors inconnus : le downloader CROSSROAD et le backdoor SHINYROAD.

La première détection remonte au 28 mai, quand ManageEngine a constaté que Backupper installait soudainement Radmin, un outil d’administration à distance légitime, sur des postes de deux entreprises sans lien, dans des pays différents. L’installation passait par les processus de promotion intégrés d’AOMEI, normalement chargés de télécharger et d’afficher du contenu promotionnel.

Le mécanisme : deux fichiers .ini et une somme de contrôle modifiée

En tentant de reproduire le comportement sur leurs propres systèmes, les chercheurs n’ont d’abord rien trouvé de suspect : le logiciel contactait les serveurs d’AOMEI et téléchargeait le fichier de configuration légitime. L’explication tenait à la discrétion de l’attaque.

Plutôt que de remplacer durablement les fichiers, les attaquants modifiaient brièvement deux fichiers de configuration des systèmes de promotion et de notification :

  • down_html.ini, qui indique à Backupper où télécharger les paquets de mise à jour ;
  • Notifycfg.ini, qui contrôle les notifications et peut déclencher l’exécution de contenu sur la machine.

En modifiant ces fichiers, les attaquants redirigeaient le logiciel vers une archive ZIP malveillante, puis utilisaient le mécanisme de notification pour exécuter le malware sans interaction de l’utilisateur. Ils modifiaient aussi la somme de contrôle attendue dans la configuration de mise à jour, de sorte que l’archive malveillante passait la vérification d’intégrité du logiciel.

Après l’échec de la reproduction initiale, ManageEngine a surveillé en continu les serveurs d’AOMEI. Le 16 juillet, cette surveillance a capturé la modification malveillante en direct. Les chercheurs ont identifié trois fenêtres où le fichier de configuration malveillant était servi :

  • 28 mai : fenêtre de dix minutes (05 h 40 – 05 h 50 UTC) ;
  • 16 juillet : fenêtre de six minutes (08 h 33 – 08 h 39 UTC) ;
  • 20 juillet : fenêtre de cinq minutes (10 h 35 – 10 h 40 UTC).

Les attaquants restauraient les fichiers d’origine en quelques minutes, ce qui rendait la compromission extrêmement difficile à détecter.

Un acteur attribué, des victimes opportunistes

Une fois lancé, le downloader CROSSROAD effectuait une reconnaissance de la machine, téléchargeait des composants supplémentaires et établissait une persistance via une tâche planifiée. SHINYROAD, le backdoor, utilisait des composants légitimes de Radmin pour charger du code malveillant et ouvrir une connexion sortante vers un serveur de commande et de contrôle contrôlé par l’attaquant.

Le 20 juillet, Google a observé une seconde technique : forcer le système de notification du logiciel à accéder à une ressource WebDAV contrôlée par l’attaquant via un popup invisible, pour tenter de dérober des hashs NTLM Windows, collectés puis cassés hors ligne.

Les organisations touchées ont été identifiées aux États-Unis, en Australie, en Inde, à Singapour, en Espagne et en Suisse, dans des secteurs comme les services IT, les télécommunications et l’enseignement supérieur. Google prévient toutefois que l’attaque était opportuniste : toute organisation ayant vérifié une mise à jour pendant les brèves fenêtres a pu être touchée.

La réponse d’AOMEI : déni puis investigation

ManageEngine a notifié AOMEI dès le 7 juin, plus d’un mois avant la capture directe. L’éditeur a d’abord suggéré que le contenu avait pu être intercepté et modifié en transit — une explication que les chercheurs ont écartée, les deux endpoints récupérant le contenu en HTTPS depuis des hostnames d’AOMEI, via des chemins réseau sans lien, et l’exécutable arrivant par la séquence d’extraction du logiciel lui-même.

Après la capture du 16 juillet, AOMEI a indiqué que son examen initial n’avait pas trouvé de preuve d’intrusion, puis que son équipe technique avait mis à niveau ses serveurs et corrigé des vulnérabilités potentielles. Contacté par BleepingComputer, l’éditeur dit traiter l’affaire en priorité haute, son CTO menant une investigation interne. Il n’a pas immédiatement confirmé comment les attaquants avaient accédé à l’infrastructure, ni si la compromission était totalement résolue.

Ce qu’il faut faire maintenant

Le point décisif, souligné par ManageEngine : un correctif côté serveur arrête les nouvelles infections, mais ne supprime pas le backdoor des machines qui l’ont reçu pendant une fenêtre antérieure. La remédiation doit donc passer par une chasse active sur les postes, pas par la seule mise à jour.

Les organisations utilisant Backupper doivent examiner les indicateurs de compromission publiés par Google et ManageEngine : tâches planifiées suspectes, exécutables inattendus dans le répertoire d’installation d’AOMEI, et connexions sortantes vers l’infrastructure contrôlée par l’attaquant — notamment l’adresse 8.210.84[.]56 et des hostnames sous storage-data[.]com.

Une chasse qui commence sur le poste, pas sur le serveur

Les indicateurs publiés sont concrets et se vérifient sans outil spécialisé. Trois points de contrôle suffisent pour un premier tri :

  • Tâches planifiées. CROSSROAD persiste via une tâche planifiée. Lister les tâches récentes (schtasks /query /fo LIST /v sous Windows) et chercher une commande pointant vers un exécutable inconnu du répertoire AOMEI.
  • Exécutables inattendus. Vérifier le répertoire d’installation de Backupper à la recherche de fichiers ajoutés récemment, notamment des binaires Radmin ou des composants de chargement.
  • Connexions sortantes. Surveiller les flux vers 8.210.84[.]56 et les hostnames sous storage-data[.]com. Un backdoor qui ne rappelle pas n’est pas un backdoor : la connexion sortante est le moment où il se trahit.

Le vol de hashs NTLM du 20 juillet mérite un traitement à part. Si un poste a exécuté la notification piégée, ses hashs ont pu être collectés puis cassés hors ligne. La parade n’est pas seulement de pivoter les mots de passe concernés : c’est d’activer l’authentification Kerberos là où c’est possible et de réduire la surface des comptes à privilèges locaux.

Le scénario n’est pas isolé. Sur la même période, Ledger demandait à ses revendeurs asiatiques de suspendre leurs ventes après une compromission supply chain, et la brèche du cloud backup de ConnectWise atteignait 173 tenants Microsoft 365. Ce qui distingue la campagne d’UNC7017, c’est la patience : plutôt qu’une compromission large et bruyante, elle a troqué quelques minutes de contrôle sur deux fichiers, à plusieurs reprises, sur des mois. C’est la signature que les équipes continuent de rater — une brèche qui ressemble à rien pendant des mois, puis qui est déjà partout.

Verdict

Si vous utilisez AOMEI Backupper, ne vous contentez pas de le mettre à jour : lancez une recherche d’intrusion sur les postes, en commençant par les tâches planifiées et les exécutables inconnus du répertoire d’installation, et pivotez les éventuels hashs NTLM qui ont pu être exposés pendant la fenêtre du 20 juillet. Si vous administrez un parc Windows plus large, tirez la leçon structurelle : un logiciel de sauvegarde qui télécharge et exécute du contenu promotionnel est une surface supply chain à part entière — traitez ses mises à jour avec la même méfiance que celles d’un antivirus.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Capcom confirme la compromission de 11,7 millions de comptes CAPCOM ID, dont 196 verrouillés par les attaquants

Le 22 octobre 2026, l’éditeur japonais Capcom révèle que son service d’authentification CAPCOM ID a été piraté, exposant 11,7 millions d’adresses e-mail et leurs métadonnées de connexion, avec 196 comptes verrouillés par les attaquants. Si vous utilisez ce compte, changez votre mot de passe et méfiez-vous des e-mails ciblés qui exploiteront ces données.

Microsoft relie la compromission ConnectWise à Storm-0940, qui automatise ses attaques avec l’IA agentique ARTEX

Le 21 octobre 2026, Microsoft attribue la compromission de ConnectWise Cloud Backup à Storm-0940, acteur aligné sur la Chine, qui s’appuie sur le framework d’IA agentique ARTEX pour passer du ciblage à l’accès privilégié en moins de trois heures. Réduisez les permissions des applications multi-locataires et surveillez les connexions de service principal comme un signal d’alerte à part entière.

← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer