Le logiciel de sauvegarde AOMEI Backupper, revendiqué par son éditeur comme utilisé par plus de 100 millions de personnes, a servi de vecteur à une attaque de la chaîne d'approvisionnement logicielle entre avril et juillet 2026. Selon l'analyse du Threat Analysis Lab de ManageEngine (METAL), menée avec le Google Threat Intelligence Group (GTIG) et Mandiant, des attaquants suivis sous le nom UNC7017 ont détourné l'infrastructure de mise à jour d'AOMEI pendant des fenêtres de quelques minutes seulement, pour installer des portes dérobées quasiment indétectables.
Comment l'attaque contre AOMEI Backupper a-t-elle été repérée ?
L'alerte initiale remonte au 28 mai 2026 : la solution de protection des terminaux de ManageEngine a observé qu'AOMEI Backupper installait l'outil d'administration à distance Radmin sur des machines de deux entreprises sans lien entre elles, situées dans deux pays différents. Ce comportement, incohérent avec le fonctionnement normal d'un logiciel de sauvegarde, a déclenché l'investigation qui a mis au jour la campagne. Mandiant a notifié AOMEI Technology le 17 juillet 2026 ; l'éditeur a répondu douze jours plus tard avoir pris des mesures correctives, après avoir d'abord évoqué une interception des données en transit, explication que les chercheurs ont écartée.
Le mécanisme : des fenêtres de compromission de cinq à dix minutes
Les enquêteurs ont identifié trois fenêtres de modification malveillante de l'infrastructure d'AOMEI, toutes brèves et suivies d'une restauration rapide des fichiers d'origine :
| Date | Fenêtre de compromission (UTC) | Durée |
|---|---|---|
| 28 mai 2026 | 05h40 – 05h50 | ~10 minutes |
| 16 juillet 2026 | 08h33 – 08h39 | ~6 minutes |
| 20 juillet 2026 | 10h35 – 10h40 | ~5 minutes |
Durant ces fenêtres, les attaquants ont modifié deux fichiers de configuration distants : l'un indique au logiciel où télécharger ses mises à jour, l'autre gère son système de notifications internes. Le même fichier fournissait à la fois l'adresse de téléchargement et la somme de contrôle MD5 attendue, ce qui a permis aux attaquants de modifier les deux simultanément : AOMEI Backupper téléchargeait alors une archive ZIP malveillante qui passait la vérification d'intégrité, puis le système de notification l'exécutait sans aucune interaction de l'utilisateur. Google indique avoir reproduit ce déroulement lors de ses propres tests.
À retenir : les fichiers compromis ont été restaurés en quelques minutes à chaque fois, ce qui rend cette attaque de la chaîne d'approvisionnement particulièrement difficile à détecter pour quiconque n'a pas surveillé le trafic réseau au moment précis des bascules.
Quelles portes dérobées ont été déployées ?
La charge initiale, un exécutable nommé upgrade-now.exe, installe deux outils distincts selon les chercheurs :
- CROSSROAD : un téléchargeur (downloader) jusqu'alors inconnu, qui effectue une phase de reconnaissance de la machine infectée, télécharge des composants supplémentaires et assure sa persistance via une tâche planifiée Windows.
- SHINYROAD : une porte dérobée (backdoor) qui réutilise des composants légitimes de l'outil d'administration à distance Radmin pour charger du code malveillant et établir une connexion sortante vers un serveur de commande et de contrôle, permettant l'exécution d'autres commandes et charges utiles.
Lors de la fenêtre du 20 juillet, une seconde technique a forcé le système de notification à accéder, via une fenêtre invisible, à une ressource WebDAV contrôlée par les attaquants : ce type de requête peut exposer des hachages NTLM, que les attaquants peuvent ensuite tenter de casser hors ligne pour obtenir des mots de passe en clair. Le téléchargeur initial se supprime lui-même après avoir préparé la charge suivante et établi sa persistance, ce qui limite encore les traces disponibles pour une investigation tardive.
Qui est concerné ?
Les chercheurs ont identifié des organisations touchées aux États-Unis, en Australie, en Inde, à Singapour, en Espagne et en Suisse, dans les secteurs IT, télécoms et enseignement supérieur. Le nombre exact de machines infectées n'est pas connu, et Google qualifie l'attaque d'opportuniste : toute organisation ayant vérifié ses mises à jour AOMEI Backupper pendant l'une des trois fenêtres a pu être exposée, indépendamment de son secteur ou de sa localisation. Le même système d'infrastructure dessert également les utilisateurs du logiciel AnyViewer, bien qu'aucune infection confirmée n'y ait été rapportée à ce stade. AOMEI n'a pas confirmé publiquement comment son infrastructure a été compromise ni si l'incident est totalement clos.
Comment se protéger et détecter une compromission ?
Le correctif côté serveur appliqué par AOMEI empêche de nouvelles infections, mais ne supprime pas une porte dérobée déjà installée sur une machine compromise. Pour les organisations ayant utilisé AOMEI Backupper entre avril et juillet 2026, plusieurs vérifications s'imposent :
- Vérifier le Planificateur de tâches Windows (bibliothèque du planificateur) à la recherche d'une tâche nommée
RadminComponentRuntime. - Examiner le dossier d'installation d'AOMEI Backupper, en particulier les sous-dossiers
htmletTmphtml, à la recherche d'un fichierupgrade-now.exenon signé ou d'une archiveupgrade-now.zipinattendue. Leur absence ne garantit pas l'absence de compromission, le téléchargeur se supprimant après exécution. - Surveiller le trafic réseau sortant vers les domaines
promotion.storage-data.com,aomei.storage-data.cometstorage-data.com, ainsi que vers les adresses IP8.210.84.56,47.239.60.117et8.218.65.184, qu'il soit bloqué ou autorisé par vos équipements. Un outil comme l'analyse OSINT de domaine de ForenShield permet de qualifier rapidement ce type d'infrastructure suspecte avant de décider des règles de blocage. - Lancer une analyse antivirus à jour sur tout poste ayant utilisé AOMEI Backupper durant la période concernée.
- En cas de signe d'infection : isoler la machine du réseau si la compromission semble active, ne pas tenter de tout nettoyer manuellement, et faire appel à une équipe de réponse à incident, en conservant les preuves disponibles avant toute remédiation.
Cette campagne illustre, une nouvelle fois, à quel point la confiance accordée à un mécanisme de mise à jour automatique constitue un point d'entrée privilégié pour les attaquants de la chaîne d'approvisionnement logicielle, un enjeu déjà documenté sur ForenShield avec la réactivation de Mini Shai-Hulud sur des GitHub Actions compromises et avec SlugFest, qui a menacé l'écosystème npm. Pour structurer la réponse à ce type d'incident, notre article sur les indicateurs de compromission et d'attaque (IOC/IOA) détaille la démarche de documentation et de corrélation à privilégier.
Points clés
- Entre avril et juillet 2026, le groupe UNC7017 a détourné l'infrastructure de mise à jour d'AOMEI Backupper par trois fenêtres de cinq à dix minutes, rapidement refermées.
- Les attaquants ont installé les backdoors CROSSROAD (téléchargeur) et SHINYROAD (porte dérobée réutilisant des composants Radmin), et ont tenté de voler des hachages NTLM via une requête WebDAV.
- Des organisations ont été touchées aux États-Unis, en Australie, en Inde, à Singapour, en Espagne et en Suisse ; l'attaque est qualifiée d'opportuniste par Google.
- Le correctif côté serveur empêche de nouvelles infections mais ne supprime pas les portes dérobées déjà installées sur les machines compromises.
- Vérifiez le Planificateur de tâches Windows, le dossier d'installation d'AOMEI Backupper et le trafic sortant vers les domaines et IP cités, pour tout poste ayant utilisé le logiciel entre avril et juillet 2026.