Des attaquants ont poussé une porte dérobée via les propres serveurs de mise à jour d'AOMEI Backupper

AOMEI Backupper est un logiciel Windows de sauvegarde et de clonage de disques. Il maintient aussi un service en arrière-plan qui interroge les serveurs d'AOMEI Technology pour des avis de mise à jour et du contenu de fenêtres contextuelles. Entre mai et juillet 2026, des attaquants ont modifié ce que ces serveurs renvoyaient pendant de courtes fenêtres, et toute copie installée qui a pointé pendant l'une d'elles a téléchargé et exécuté une porte dérobée.

À lire aussi: L'attaque de chaîne d'approvisionnement contre Brevo a injecté le malware ClickFix via une clé Cloudflare volée · Des attaquants ont utilisé l'identité applicative de ConnectWise Cloud Backup pour entrer dans des tenants Microsoft 365.

Google Threat Intelligence Group et Mandiant, en collaboration avec le Threat Analysis Lab de ManageEngine, ont divulgué la campagne dans la semaine du 13 octobre 2026. The Hacker News et ManageEngine ont publié des comptes rendus détaillés le 16 octobre.

Les rapports ne disent pas comment les attaquants ont obtenu un accès en écriture à l'infrastructure d'AOMEI. Ils montrent en revanche ce que cet accès a permis d'acheter : une compromission de la chaîne d'approvisionnement qui n'a exigé ni message d'hameçonnage, ni site de téléchargement usurpé, ni faille dans le programme de sauvegarde. Le logiciel a fait ce pour quoi il a été conçu, et la charge utile est arrivée par le propre canal de mise à jour du fournisseur.

Trois fenêtres, et probablement plus

GTIG et Mandiant ont confirmé trois fenêtres de manipulation. La première a duré 10 minutes le 28 mai 2026, de 05 h 40 à 05 h 50 UTC. La deuxième a duré six minutes le 16 juillet, de 08 h 33 à 08 h 39 UTC. La troisième a duré cinq minutes le 20 juillet, de 10 h 35 à 10 h 40 UTC. La surveillance de ManageEngine a détecté de façon indépendante le changement du 16 juillet pendant qu'il se produisait.

Les chercheurs ont dit que d'autres fenêtres ont probablement eu lieu, la manipulation remontant à avril 2026. Cette estimation compte plus que les trois dates confirmées. Une campagne bâtie sur des fenêtres aussi courtes n'a pas besoin de nombreuses tentatives pour atteindre beaucoup de machines, car la cible est quiconque lance par hasard une vérification de mise à jour pendant que le fichier est altéré.

GTIG a identifié des organisations touchées dans les services informatiques, les télécommunications et l'enseignement supérieur dans 11 pays : Australie, Brésil, Inde, Pakistan, Portugal, Singapour, Afrique du Sud, Espagne, Suisse, Türkiye et États-Unis. Elle n'a donné aucun total et a dit que le nombre réel est probablement plus élevé. Aucun des deux rapports n'attribue la campagne à un État ni ne nomme un acteur. GTIG suit le groupe sous le nom d'UNC7017.

Le canal de mise à jour se faisait confiance à lui-même

Le flux de mise à jour de Backupper utilise deux fichiers de configuration, down_html.ini et Notifycfg.ini. Ils ne sont pas signés. Ils indiquent au programme quoi télécharger et quel contenu de fenêtre contextuelle afficher, et aucun des deux n'est authentifié cryptographiquement. La somme de contrôle servant à vérifier un téléchargement est déclarée à l'intérieur du même fichier non authentifié qui nomme le téléchargement, donc un attaquant capable de modifier le fichier peut aussi modifier la valeur censée prouver son authenticité.

HTTPS protégeait le transfert. Il ne protégeait pas le contenu, car le contenu venait des propres hôtes d'AOMEI et était servi sur une connexion valide. C'est la partie de l'histoire qui compte au-delà de cette famille de logiciels malveillants. La sécurité du transport répond à la question de savoir si un serveur est bien ce qu'il prétend être. Elle ne dit rien sur la question de savoir si le fichier que ce serveur distribue mérite d'être cru.

GTIG a décrit la campagne comme la première compromission de chaîne d'approvisionnement Windows qu'elle ait vue bâtie sur des fenêtres de manipulation aussi courtes. Le rapport a dit que l'approche échappait efficacement au tri ponctuel et à l'analyse automatisée des fichiers. Un fichier malveillant pendant six minutes puis authentique ensuite laisse peu de choses à un analyseur qui ne regarde qu'une fois.

Le même flux de mise à jour est utilisé par AnyViewer, l'outil de bureau à distance d'AOMEI, et GTIG indique qu'AnyViewer a aussi été ciblé. Les rapports se concentrent sur Backupper, donc le nombre d'installations d'AnyViewer qui ont pointé pendant une fenêtre de manipulation n'est pas connu.

D'une notification à une tâche planifiée

La chaîne du 20 juillet montre jusqu'où la manipulation est allée. Le fichier de notification altéré pointait la fenêtre contextuelle intégrée à l'application vers un exécutable fourni appelé upgrade-now.exe. Le fichier portait les métadonnées d'éditeur d'AOMEI mais n'était pas signé, et sa chaîne produit indiquait « AOMEI Update Compent », « component » étant mal orthographié.

Son exécution installait un Radmin Server authentique et signé de Famatech. À côté du lanceur Radmin signé, FamItrfc.exe, le déposeur plaçait une DLL construite par l'attaquant, appelée BlkScrDl.dll. Le lanceur signé chargeait la DLL depuis son propre dossier, un chargement latéral classique. Cette DLL chargeait l'implant, RuntimeComponent.dll, la porte dérobée que GTIG appelle SHINYROAD. L'implant s'enregistrait comme serveur COM à l'intérieur du substitut signé dllhost.exe et portait une charge utile PocketPy chiffrée intégrée. La persistance venait d'une tâche planifiée nommée RadminComponentRuntime, censée s'exécuter toutes les trois heures.

Les parties malveillantes étaient le déposeur non signé, la DLL chargée latéralement et l'implant. Tout ce qu'elles touchaient était signé ou constituait un processus Windows légitime. C'est pourquoi l'activité est difficile à détecter avec un simple contrôle de réputation de fichier.

ManageEngine suit le déposeur sous le nom de CROSSROAD. Il se supprimait après usage, vérifiait l'adresse IP publique de l'hôte et s'arrêtait s'il la géolocalisait en Chine ou si la géolocalisation échouait, et s'arrêtait s'il trouvait certains agents de sécurité de poste de travail. Ces vérifications indiquent une opération soignée et ciblée plutôt qu'une campagne large et indiscriminée. Elles signifient aussi qu'une machine hors de l'ensemble cible peut n'avoir jamais exécuté la charge utile même si elle a téléchargé le déposeur.

L'implant se connectait à un seul point de commande et contrôle codé en dur, 8.218.65.184 sur le port 41397, sans solution de repli. L'adresse n'est déchiffrée qu'à l'exécution, donc elle n'apparaît pas dans le fichier au repos. Ce point unique est une faiblesse dans la conception de l'implant : bloquer le trafic sortant vers lui coupe le seul canal de contrôle que les chercheurs ont trouvé. Les adresses sont volatiles, et celle-ci vient de l'analyse des chercheurs plutôt que d'AOMEI.

Pendant la fenêtre du 20 juillet, GTIG a aussi constaté que le fichier de notification avait été modifié pour ouvrir une fenêtre contextuelle invisible d'un pixel. La fenêtre pointait vers un fichier distant via un chemin WebDAV ou UNC. Son rendu pouvait amener Windows à envoyer les éléments d'authentification NetNTLMv2 de l'utilisateur connecté à l'attaquant, sans rien de visible à l'écran et sans exécuter de programme.

Ce second chemin compte car il contourne l'hypothèse habituelle selon laquelle une attaque de chaîne d'approvisionnement doit livrer du code. Une fuite d'identifiants de ce type peut être exploitée plus tard, depuis un autre réseau et avec un autre outil, contre des systèmes qui n'ont jamais exécuté la porte dérobée. Les chercheurs la présentent comme une capacité qu'ils ont observée dans le fichier trafiqué, non comme la preuve que des identifiants ont été dérobés dans chaque réseau touché.

Ce qu'AOMEI savait, et quand

Le logiciel de poste de travail de ManageEngine a signalé l'activité le 28 mai 2026, le jour de la première fenêtre confirmée. Un client l'a remontée le 7 juin, et ManageEngine a prévenu AOMEI le jour même.

La première explication d'AOMEI était que le contenu avait été intercepté en transit. ManageEngine a dit que les preuves ne l'étayaient pas, car les deux points terminaux récupéraient les fichiers en HTTPS depuis des hôtes appartenant à AOMEI dans différents pays. Mandiant a prévenu AOMEI le 17 juillet. AOMEI a répondu le 29 juillet que ses serveurs étaient sécurisés.

AOMEI n'a pas publié son propre récit au-delà de la mention d'une action corrective. Cela laisse la cause première en suspens. Les rapports décrivent la manipulation en détail et ne décrivent pas comment les attaquants sont entrés, donc la question de savoir si la même voie d'accès est fermée repose sur l'assurance du fournisseur plutôt que sur des preuves publiques.

Le volet produit n'est pas résolu non plus. Le journal des modifications d'AOMEI pour Backupper, consulté le 16 octobre 2026, ne mentionnait aucun changement dans la façon dont le programme vérifie les mises à jour jusqu'à la version actuelle, la 8.5.0, publiée le 9 octobre. La plage des versions touchées n'est pas non plus entièrement documentée. ManageEngine a examiné la version 8.3.0 et a dit avoir observé la 8.3.0 et les suivantes. Si les fichiers de mise à jour ne peuvent toujours pas être authentifiés de façon indépendante, une future compromission de serveur aurait le même chemin vers le même résultat.

Pourquoi une analyse propre ne prouve pas grand-chose

La leçon défensive va à l'encontre de l'instinct de vérifier un fichier et de passer à autre chose. Un poste de travail qui a téléchargé le déposeur pendant une fenêtre de cinq minutes et l'a exécuté peut réussir une analyse effectuée une semaine plus tard, car le fichier de mise à jour local qu'il a laissé a été restauré dans sa version authentique. Les preuves qui subsistent sont comportementales : une tâche planifiée, une installation Radmin que personne n'a demandée, une DLL posée à côté d'un binaire signé, un processus dialoguant avec une adresse inhabituelle.

C'est l'argument pour conserver et interroger la télémétrie des postes de travail plutôt que de se fier à la réputation à un instant donné. C'est aussi l'argument pour traiter un serveur de mise à jour comme une partie de la surface d'attaque. Un fournisseur qui signe ses fichiers de configuration et livre les sommes de contrôle par un canal séparé et authentifié élimine la faiblesse précise exploitée ici. Des manifestes signés à durée de vie courte réduiraient encore la fenêtre, car un fichier altéré sur le serveur échouerait à la vérification sur le client.

Rien de tout cela n'aide un réseau qui a déjà exécuté la charge utile. Le conseil pratique qui en découle est de traquer les composants de la chaîne, de bloquer l'adresse de commande et contrôle au périmètre et de traiter un résultat antivirus propre comme le début d'une enquête plutôt que sa fin.

« Échappant efficacement au tri ponctuel traditionnel et à l'analyse automatisée des fichiers. » — Google Threat Intelligence Group, à propos d'UNC7017, 16 octobre 2026

Ce qu'il faut surveiller

Trois choses restent en suspens. La première est le propre récit d'AOMEI sur l'intrusion, qui dirait comment les serveurs ont été atteints et si la vérification des mises à jour a changé. La deuxième est une confirmation indépendante que les serveurs sont propres ; la seule déclaration à ce jour est celle du fournisseur. La troisième est le nombre de victimes. Onze pays est un plancher établi à partir de la visibilité de GTIG.

Pour les défenseurs, la question utile est de savoir si une machine du parc a lancé une vérification de mise à jour pendant l'une des fenêtres, et si la télémétrie permettant d'y répondre existe encore. La plupart des organisations ne conservent probablement pas six mois de données de processus et de réseau. Celles qui le font peuvent distinguer une infection d'une coïncidence.

La technique ne dépend pas d'AOMEI. Tout mécanisme de mise à jour qui fait confiance à un manifeste non signé provenant du même serveur dont il télécharge présente la même exposition. Le prochain rapport pourrait concerner un autre logiciel.

Image de couverture : « Toshiba 1 TB External USB Hard Drive.jpg », par Editor182, public domain, via Wikimedia Commons.