En 2026, le vecteur d'attaque le plus redouté n'est plus le phishing mal ficelé ni le CVE non patché — c'est votre propre système de mise à jour logicielle. L'affaire AOMEI Backupper n'est pas un incident isolé. Elle est le dernier symptôme d'une tendance structurelle qui redéfinit la surface d'attaque des organisations : l'infrastructure de confiance devient l'arme.

Qu'est-ce que l'update hijacking — et pourquoi ça fonctionne si bien

L'update hijacking, ou détournement de mise à jour, consiste pour un attaquant à s'insérer dans le canal de distribution des mises à jour logicielles pour substituer un contenu malveillant au contenu légitime attendu. Le concept existe depuis les années 2000, mais son industrialisation est récente et spectaculaire. La raison pour laquelle cette technique fonctionne si bien tient à une seule chose : la confiance implicite que les systèmes informatiques accordent aux mises à jour.

Un administrateur système expérimenté soumet à une vérification stricte toute exécutable téléchargé depuis Internet. Le même administrateur exécutera sans sourciller une mise à jour poussée par l'outil de sauvegarde qu'il utilise tous les jours. Cette asymétrie de méfiance est au cœur de l'efficacité des attaques supply chain. Les attaquants ne cherchent plus à contourner les défenses — ils exploitent les canaux auxquels les défenses font confiance.

Dans le cas AOMEI documenté par Google GTIG en octobre 2026, UNC7017 n'a pas besoin de compromettre le poste de l'administrateur, ni d'envoyer un email de phishing, ni même d'exploiter une CVE. Il lui suffit de modifier pendant 5 à 10 minutes les fichiers de configuration hébergés sur les serveurs de mise à jour d'AOMEI — des fichiers qui indiquent à chaque client AOMEI où télécharger sa prochaine version. Le client télécharge, exécute, s'infecte. L'attaquant referme la fenêtre. La trace est quasiment inexistante.

Ce type d'attaque, baptisé "short-burst supply chain" par les chercheurs de SafeGuard.sh, minimise délibérément l'exposition. Plus la fenêtre est courte, moins il y a de chances qu'un chercheur en sécurité échantillonnant le trafic tombe précisément sur la fenêtre d'injection. Le compromis : moins de victimes mais moins de détection. Pour un acteur étatique dont l'objectif est l'espionnage ciblé plutôt que la monétisation de masse, ce ratio est parfaitement acceptable.

La ligne du temps : de SolarWinds à AOMEI, six ans d'escalade

Pour comprendre où nous en sommes en 2026, il faut remonter la ligne du temps des grandes attaques supply chain.

Décembre 2020 : SolarWinds Orion. Les équipes de Mandiant découvrent que la mise à jour 2020.2 de SolarWinds Orion — un outil de supervision réseau déployé dans 18 000 organisations dont le Trésor américain et la NSA — contient un backdoor nommé SUNBURST. L'attaquant (APT29, Cozy Bear, attribué à la SVR russe) a compilé son code malveillant directement dans le processus de build de SolarWinds, signant son backdoor avec le certificat officiel SolarWinds. Résultat : neuf mois d'accès aux réseaux les plus sensibles au monde avant découverte.

Mars 2023 : 3CX. Les attaquants compromettent le logiciel de voip 3CX Desktop App en infectant d'abord une dépendance tierce (Trading Technologies X-Trader). Une attaque supply chain de second niveau, avec une supply chain compromise à l'intérieur d'une supply chain. Lazarus Group en est l'auteur présumé, dans une campagne visant les crypto-exchanges et les institutions financières.

Juillet 2024 : XZ Utils. Un acteur encore non attribué avec certitude passe deux ans à construire la confiance dans la communauté open-source avant d'insérer une backdoor SSH dans XZ Utils, une bibliothèque de compression présente sur des centaines de millions de systèmes Linux. Découvert par hasard par un ingénieur Microsoft observant des anomalies de performance. A 500 lignes de code malveillant près, c'était probablement la backdoor la plus répandue de l'histoire.

2025-2026 : AOMEI, Ultralytics, Polyfill.io... Les attaques supply chain sont désormais mensuelles. Le modèle AOMEI représente une sophistication supplémentaire : la fenêtre d'attaque ultra-courte (5-10 minutes) rend la détection par monitoring périodique pratiquement impossible. En 2026, selon le rapport Gartner sur les risques technologiques, 45 % des organisations déclarent avoir subi un incident lié à la chaîne d'approvisionnement logicielle au cours des 12 derniers mois.

Pourquoi les outils d'administration sont les cibles idéales

UNC7017 n'a pas choisi AOMEI par hasard. AOMEI Backupper et AnyViewer partagent deux caractéristiques qui en font des cibles de choix pour un acteur orienté espionnage :

Niveau de privilège élevé. AOMEI Backupper, pour effectuer des sauvegardes complètes et des clonages de disques, doit s'exécuter avec des droits d'administration ou SYSTEM sur Windows. Un agent malveillant injecté dans ce processus hérite automatiquement de ces privilèges. Pas besoin d'exploitation d'une vulnérabilité d'élévation de privilèges : le vecteur d'attaque arrive déjà avec les clés du royaume.

Confiance implicite dans les équipes IT. Les outils de sauvegarde et d'accès à distance font partie des logiciels les moins suspectés dans un environnement professionnel. Ils sont généralement exemptés des règles EDR les plus strictes (nombreuses organisations ajoutent les répertoires d'installation de ces outils aux exclusions antivirus pour éviter des faux positifs sur les opérations d'accès disque à grande échelle). Cette exemption transforme l'outil en zone franche pour un attaquant qui y loge son malware.

Présence dans les environnements MSP. Les Managed Service Providers déploient AOMEI Backupper sur des flottes de dizaines ou de centaines de clients. Un seul agent MSP compromis via la supply chain AOMEI donne à l'attaquant un accès potentiel à l'ensemble du portefeuille clients. C'est la logique dite "island hopping" : compromettre un prestataire pour accéder à ses clients finaux, souvent bien plus intéressants.

La même logique s'applique à une longue liste d'outils : gestionnaires de configuration (Ansible, Puppet), outils de déploiement (Octopus Deploy, Azure DevOps agents), outils de monitoring (Zabbix agents, Datadog agents), solutions de sauvegarde (Veeam, Acronis). Tous ces logiciels partagent les mêmes caractéristiques : privilèges élevés, confiance implicite, présence ubiquitaire dans les SI, et mécanismes de mise à jour automatique rarement soumis à une vérification cryptographique côté client.

La vérification de l'intégrité des mises à jour : état des lieux et lacunes

Face à ce type de menace, la défense technique première consiste à vérifier cryptographiquement l'intégrité de chaque mise à jour avant son exécution. Cette vérification peut prendre plusieurs formes :

Signature de code (Code Signing). Le binaire livré est signé avec la clé privée de l'éditeur, et le client vérifie la signature avant exécution. C'est la protection la plus robuste — SolarWinds était signé, mais la signature était légitime (le code malveillant avait été compilé dans le processus de build officiel). La signature de code protège contre la substitution de binaires mais pas contre la compromission du pipeline de build lui-même.

Hashes publiés et vérification côté client. L'éditeur publie les hashes SHA-256 de chaque version sur une infrastructure distincte (ou dans une publication signée type TUF — The Update Framework). Le client compare le hash du fichier téléchargé avant exécution. Simple, efficace, mais rarement implémenté par les éditeurs qui privilégient la fluidité de l'expérience utilisateur sur la sécurité.

TUF (The Update Framework). Un framework open-source de sécurisation des mises à jour logicielles, utilisé notamment par PyPI, Conda et des projets Docker. TUF repose sur un système de clés de confiance hiérarchiques et de métadonnées signées qui permettent de détecter les attaques de type "replay", "freeze", ou "substitution de fichier" même si les serveurs de mise à jour sont compromis. En 2026, TUF reste sous-utilisé dans l'écosystème des outils commerciaux grand public — les éditeurs le savent mais invoquent la complexité d'implémentation.

Dans le cas AOMEI, la modification portait sur des fichiers de configuration indiquant où télécharger les binaires — pas sur les binaires eux-mêmes. La signature de code des binaires AOMEI n'aurait donc pas détecté l'attaque si les binaires malveillants étaient eux aussi signés (par une clé compromise ou une entité tierce). C'est précisément ce type de subtilité qui rend ces attaques difficiles à contrer avec les seuls mécanismes de signature traditionnels.

Ce que les RSSI doivent faire concrètement en 2026

Le risque supply chain est maintenant mainstream. Il figure dans les principaux frameworks de sécurité (NIST CSF 2.0, ISO 27001:2022, NIS2) et dans les questionnaires de due diligence des assureurs cyber. Mais la réponse organisationnelle est encore largement insuffisante. Voici ce qui fonctionne concrètement, au-delà des déclarations de politique générale :

1. Inventaire des logiciels à mise à jour automatique. Dressez la liste exhaustive des logiciels avec mécanisme de mise à jour automatique dans votre SI : agents de monitoring, outils de sauvegarde, suites de sécurité, outils d'accès à distance, runtimes (Java, Node, Python). Pour chacun, documentez : le mécanisme de mise à jour, la fréquence, la vérification d'intégrité en place (signature ? hash ? aucune ?), et le niveau de privilège d'exécution. Cet inventaire est la base de votre analyse de risque supply chain.

2. Segmentation du trafic de mise à jour. Le trafic vers les serveurs de mise à jour doit être loggué et inspecté. Idéalement, les mises à jour logicielles doivent transiter par un proxy de mise à jour interne (WSUS pour Windows, Artifactory ou Nexus pour les dépendances) qui stocke et vérifie les packages avant distribution interne. Cette approche ralentit la mise à jour mais crée un point de contrôle.

3. Monitoring comportemental des processus de mise à jour. Un agent de sauvegarde qui, après une mise à jour, commence à effectuer des connexions DNS vers des domaines nouveaux ou des requêtes HTTP vers des IP non habituelles est un signal d'alerte majeur. Les règles de détection comportementale (UEBA, EDR) doivent couvrir spécifiquement les comportements post-mise à jour des logiciels à privilèges élevés.

4. Veille sur les indicateurs de compromission supply chain. Google GTIG, Mandiant, Recorded Future et SentinelOne publient régulièrement des rapports sur les attaques supply chain actives. Intégrez ces flux dans votre processus de threat intelligence. Le cas AOMEI a été documenté plusieurs mois après les attaques effectives — les organisations abonnées aux flux Threat Intel auraient pu détecter la compromission bien plus tôt.

5. Vérification forensique rétroactive pour les incidents AOMEI. Si vous utilisez AOMEI Backupper ou AnyViewer, vérifiez vos logs de mise à jour pour les dates du 28 mai, 16 juillet et 20 juillet 2026. Même si vous n'avez pas d'alerte EDR, une vérification des connexions réseau sortantes sur ces dates peut révéler une compromission silencieuse.

Mon avis d'expert

L'attaque AOMEI illustre parfaitement ce que j'observe sur le terrain depuis 2024 : les organisations qui ont investi massivement dans la détection d'intrusion périmétrique et dans la protection des endpoints contre les malwares connus restent largement exposées aux vecteurs de confiance. Un SOC parfaitement calibré pour détecter Mimikatz sur un endpoint sera complètement aveugle face à un agent de sauvegarde qui tourne avec les droits SYSTEM et exécute silencieusement un backdoor signé via son processus de mise à jour. La sécurité de la chaîne d'approvisionnement logicielle doit devenir une discipline à part entière dans chaque organisation — pas une case à cocher dans un audit de conformité, mais un programme continu avec un propriétaire, un budget, et des métriques. En 2026, cette maturité est encore l'exception plutôt que la règle. Le marché va payer le prix de ce retard pendant encore plusieurs années.

L'angle réglementaire : NIS2, DORA et la responsabilité des éditeurs

La directive NIS2, applicable depuis octobre 2024, introduit une notion qui change la donne pour les éditeurs logiciels : les "fournisseurs de services numériques" et les "entités essentielles" doivent désormais évaluer et gérer les risques liés à leur chaîne d'approvisionnement. L'article 21 de NIS2 impose explicitement la gestion de la sécurité dans les relations fournisseurs, ce qui inclut les logiciels tiers déployés dans le SI.

En pratique, cela signifie que si votre organisation déploie AOMEI Backupper sur 500 postes sans avoir évalué la sécurité du mécanisme de mise à jour d'AOMEI, et que vous subissez une compromission via la supply chain AOMEI, vous avez potentiellement failli à votre obligation NIS2 de gestion des risques fournisseurs. Les autorités compétentes (ANSSI en France) peuvent demander des justifications sur la due diligence exercée envers les logiciels tiers déployés.

Du côté des éditeurs, DORA (Digital Operational Resilience Act) — applicable aux entités financières depuis janvier 2025 — impose des exigences encore plus strictes sur la gestion des risques liés aux prestataires tiers informatiques critiques. Un établissement bancaire qui déploie un outil tiers sans vérification cryptographique de l'intégrité des mises à jour pourrait se retrouver en non-conformité DORA en cas d'incident supply chain.

Cette évolution réglementaire crée une pression positive sur les éditeurs logiciels pour améliorer la sécurité de leurs pipelines de distribution. Mais l'adaptation prend du temps, et en attendant, la charge de la vérification repose toujours sur les équipes de sécurité des organisations déploitrices — qui n'ont ni le temps ni souvent les outils pour vérifier cryptographiquement l'intégrité de chaque mise à jour de chaque logiciel déployé dans leur SI.

Conclusion

L'update hijacking n'est pas une menace théorique. C'est l'un des vecteurs d'attaque les plus efficaces de 2026, utilisé par des acteurs étatiques et des groupes cybercriminels sophistiqués pour accéder à des cibles qui résistent aux techniques d'intrusion classiques. La confiance que nous accordons à nos propres outils de gestion de parc est devenue un risque opérationnel majeur.

La bonne nouvelle : les contre-mesures existent. Inventaire des logiciels à mise à jour automatique, segmentation du trafic de mise à jour, monitoring comportemental post-update, veille threat intel ciblée sur la supply chain — ces mesures ne requièrent pas de budget exceptionnel. Elles requièrent de la méthode, de la rigueur, et une prise de conscience que le vecteur de confiance est désormais aussi un vecteur d'attaque.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique.

Prendre contact