Entre mai et juillet 2026, un acteur suivi sous le nom UNC7017 a modifié à plusieurs reprises, pendant cinq à dix minutes, les fichiers de configuration servis par les serveurs de mise à jour d’AOMEI Backupper, pour faire exécuter une porte dérobée aux postes qui interrogeaient le serveur à ce moment-là. Cette analyse s’adresse aux auditeurs, RSSI et responsables sécurité : mode opératoire, correspondance avec MITRE ATT&CK, détection, questions d’audit ISO 27001 et pistes de sensibilisation. Elle repose sur les travaux de Google Threat Intelligence Group (GTIG) et Mandiant, du laboratoire de ManageEngine et sur leur synthèse par The Hacker News : la façon dont l’attaquant a obtenu l’accès aux serveurs de l’éditeur n’est pas publiée.
Pour une lecture orientée dirigeant, voir notre décryptage « AOMEI Backupper : quand la mise à jour d’un logiciel de sauvegarde installe une porte dérobée ».
Contexte
- Produit : AOMEI Backupper, logiciel de sauvegarde et de clonage pour Windows d’AOMEI Technology (société enregistrée à Hong Kong). Ses services en arrière-plan interrogent régulièrement les serveurs de l’éditeur, en HTTPS, pour les mises à jour et des fenêtres promotionnelles. L’outil de prise en main à distance AnyViewer, du même éditeur, partage ce mécanisme ; les détections publiées concernent Backupper (The Hacker News, 16 octobre 2026).
- Fenêtres confirmées : 28 mai 2026 (10 minutes), 16 juillet (6 minutes), 20 juillet (5 minutes). GTIG estime probable l’existence d’autres fenêtres non observées (GTIG et Mandiant).
- Victimes : organisations des services informatiques, des télécoms et de l’enseignement supérieur dans 11 pays (Australie, Brésil, Inde, Pakistan, Portugal, Singapour, Afrique du Sud, Espagne, Suisse, Turquie, États-Unis). Aucun total publié. Ciblage jugé opportuniste : est touché tout poste qui interroge le serveur pendant une fenêtre.
- Attribution : UNC7017, sans rattachement à un pays ni à un acteur connu. GTIG indique n’avoir jamais rencontré de compromission de chaîne d’approvisionnement reposant sur des fenêtres aussi courtes.
- Versions : non précisées. ManageEngine a examiné la version 8.3.0 (ManageEngine). Le journal des versions consulté par The Hacker News le 16 octobre ne mentionne aucune modification du mécanisme de vérification jusqu’à la version 8.5.0 du 9 octobre.
Mode opératoire : ce qui est documenté et ce qui ne l’est pas
| Étape | Ce qui est rapporté | Correspondance MITRE ATT&CK (notre lecture) |
|---|---|---|
| Accès initial | Modification temporaire, côté serveur de l’éditeur, de deux fichiers de configuration : l’un désigne le paquet de mise à jour et son empreinte de contrôle, l’autre pilote le service de notification et ce qu’il exécute. Aucun n’est signé cryptographiquement ; l’empreinte censée garantir le paquet figure dans le même fichier non signé. L’origine de l’accès en écriture aux serveurs n’est pas documentée. | T1195.002 Compromise Software Supply Chain |
| Exécution | Le logiciel télécharge le paquet dans son propre dossier par son processus de mise à jour normal ; le service de notification le lance avec les privilèges du processus AOMEI. Aucune action de l’utilisateur n’est nécessaire. L’élévation dépend de la façon dont le service est configuré. | T1195.002 (exécution par le mécanisme de mise à jour légitime) |
| Persistance | Un téléchargeur décompresse un ensemble de fichiers dans un dossier local et crée une tâche planifiée exécutée toutes les trois heures. | T1053.005 Scheduled Task |
| Évasion | La tâche lance une copie authentique et signée d’un outil commercial d’administration à distance, qui charge une bibliothèque malveillante placée à côté de lui, laquelle charge l’implant. L’outil d’administration lui-même reste inactif (ni écoute, ni configuration, ni compte). Le téléchargeur s’efface et restaure le fichier de mise à jour local. Il s’interrompt si le poste est situé en Chine et, selon ManageEngine, en présence de certains agents de sécurité. | T1574.002 DLL Side-Loading ; T1070.004 File Deletion ; T1480 Execution Guardrails ; T1614 System Location Discovery ; T1518.001 Security Software Discovery |
| Commande et contrôle | L’implant fournit un shell distant et peut télécharger et exécuter du code. Il contacte une adresse unique codée en dur, sans infrastructure de repli. Sur une partie des postes, GTIG a observé ensuite le dépôt d’un framework de commande et de contrôle open source, maquillé en logiciel PDF du commerce. | T1059.003 Windows Command Shell ; T1105 Ingress Tool Transfer ; T1036.005 Match Legitimate Name or Location |
| Vol d’identifiants (fenêtre du 20 juillet) | Le fichier de notification ouvre une fenêtre invisible d’un pixel pointant vers une ressource distante en WebDAV. Son affichage peut amener Windows à envoyer la réponse NetNTLMv2 de l’utilisateur connecté, exploitable hors ligne ou en relais, sans exécution de programme. | T1187 Forced Authentication |
| Exfiltration, impact | Non documentés publiquement au-delà de l’accès distant. | Non documenté |
La colonne MITRE est une lecture de notre part, à partir des éléments publiés.
Faits techniques connus
- La faiblesse de conception est le point central : canal HTTPS authentique, mais contenu non signé et empreinte de contrôle stockée dans le fichier qu’elle est censée protéger. Le HTTPS garantit le serveur, pas l’intégrité de ce que le serveur sert.
- L’éditeur a d’abord évoqué une modification en transit. ManageEngine juge cette hypothèse incompatible avec les faits : deux postes dans deux pays et deux réseaux différents, et une fenêtre captée en direct par ses sondes en juillet.
- Le vecteur d’authentification forcée du 20 juillet fonctionne même si l’implant est bloqué : un poste « propre » au sens de l’antivirus peut avoir laissé fuir une réponse d’authentification.
Ce qu’on ne sait pas
La façon dont UNC7017 a obtenu un accès en écriture aux serveurs d’AOMEI, le nombre de postes compromis, les versions concernées, les actions menées après l’installation de l’implant et la confirmation indépendante que la compromission côté éditeur est terminée. Nous ne spéculons pas sur ces points.
Détection : ce qui a fonctionné, et pourquoi l’attaque passe sous les radars
- Ce qui a fonctionné : la télémétrie EDR de ManageEngine, qui a relevé le 28 mai l’installation d’un outil d’administration à distance par le processus AOMEI chez deux clients sans lien ; le signalement d’un client le 7 juin (AOMEI prévenu le jour même) ; la capture d’une fenêtre en direct en juillet ; la notification de Mandiant le 17 juillet. AOMEI a indiqué le 29 juillet avoir pris des mesures correctives sur ses serveurs.
- Pourquoi l’attaque passe sous les radars : fenêtres de quelques minutes ; fichiers du serveur et fichier local remis en état ; exécution par un processus de confiance ; chargement de l’implant par un binaire légitime et signé. Contrôler la page de téléchargement de l’éditeur après coup renvoie un contenu sain, ce qui a conduit des analystes à classer de vraies détections en faux positifs. GTIG souligne que la méthode échappe au tri ponctuel et à l’analyse automatique de fichiers.
- Ce qui reste observable (description générique) : tâche planifiée récente lançant un outil d’administration à distance depuis un dossier de données applicatives ; exécutable non signé portant les métadonnées d’éditeur d’AOMEI ; exécution de programmes depuis le dossier des fenêtres promotionnelles du logiciel ; connexions sortantes SMB ou WebDAV vers des adresses externes. GTIG (règles YARA) et ManageEngine (règles Sigma) publient des règles de détection et des indicateurs, à récupérer à la source.
- Point clé pour la réponse : rechercher sur toute la période d’avril à juillet 2026 ; conserver les fichiers en cache dans les dossiers du logiciel et les journaux réseau horodatés du moment de l’alerte ; bloquer les flux SMB et WebDAV sortants vers Internet.
Questions d’audit ISO 27001:2022
- A.5.19, A.5.21 et A.5.22 (sécurité dans les relations fournisseurs, chaîne d’approvisionnement TIC, surveillance des services) : « Pour les logiciels tiers installés sur les postes et serveurs, disposez-vous de la liste de ceux qui se mettent à jour de façon autonome ? Le mécanisme de vérification de l’authenticité des mises à jour (signature du contenu, pas seulement HTTPS) fait-il partie des critères de choix et de revue des éditeurs ? »
- A.8.19 et A.8.2 (installation de logiciels sur des systèmes en exploitation, droits d’accès privilégiés) : « Les mises à jour automatiques des logiciels tiers sont-elles maîtrisées (activation justifiée, déploiement centralisé, groupe pilote) ? Les services des outils de sauvegarde et de prise en main à distance fonctionnent-ils avec le minimum de privilèges ? »
- A.8.16, A.5.25 et A.5.28 (activités de surveillance, appréciation des événements, collecte de preuves) : « La procédure de traitement des alertes impose-t-elle de préserver artefacts et journaux horodatés avant toute clôture en faux positif ? Une alerte mettant en cause un logiciel de confiance fait-elle l’objet d’une escalade ? »
- A.8.20 et A.8.22 (sécurité des réseaux, cloisonnement des réseaux) : « Les flux SMB et WebDAV sortants vers Internet sont-ils bloqués depuis les postes de travail ? Comment le vérifiez-vous ? »
- A.8.13 et A.5.30 (sauvegarde des informations, préparation des TIC pour la continuité d’activité) : « Si l’outil de sauvegarde lui-même est compromis, disposez-vous d’une copie isolée et d’une procédure de restauration testée qui ne dépend pas de cet outil ? »
Pistes de sensibilisation
- Pour les équipes IT et SOC : atelier « Faux positif ou vrai incident ? ». Rejouer la chronologie de ce cas : une alerte EDR, une vérification de la page de l’éditeur qui semble saine, puis la preuve de la compromission. Objectif : préserver les traces avant de conclure, et escalader les alertes qui touchent un logiciel de confiance.
- Pour les dirigeants et responsables d’application : « Les logiciels qui entrent sans frapper ». En dix minutes, lister les logiciels qui se mettent à jour seuls dans l’entreprise, repérer ceux qui ont des droits élevés et décider lesquels doivent passer par un déploiement contrôlé.
À lire aussi : notre décryptage pour les dirigeants, « AOMEI Backupper : quand la mise à jour d’un logiciel de sauvegarde installe une porte dérobée », et le bulletin de veille du 17 octobre 2026.
Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.