Quand un logiciel légitime devient le véhicule d’une attaque

Nous avons récemment vu qu’une simple borne de recharge pouvait devenir une surface de cybersécurité inattendue. L’exemple rappelait à quel point les risques numériques se trouvent aujourd’hui dans des endroits que les dirigeants n’associent pas toujours spontanément à l’informatique. Un autre cas récent pousse cette réflexion encore plus loin : cette fois, le risque ne provenait pas d’un équipement que l’on avait oublié de considérer comme un ordinateur, mais d’un logiciel parfaitement légitime que des utilisateurs pouvaient raisonnablement croire digne de confiance.

Une campagne observée en Ukraine a utilisé une version authentique de Notepad++ accompagnée d’un faux plugin pour installer différents composants malveillants. Le logiciel officiel et ses serveurs de distribution n’avaient pas été compromis. Les attaquants avaient plutôt assemblé leur propre archive contenant une version légitime de l’application et une bibliothèque malveillante qui était ensuite chargée par le mécanisme normal d’extensions de Notepad++.

Ce cas illustre parfaitement une réalité à laquelle les équipes TI et de cybersécurité sont de plus en plus confrontées : les attaquants n’ont pas toujours besoin de casser une technologie. Ils peuvent exploiter son fonctionnement normal, sa réputation ou la confiance que nous lui accordons. Pour les entreprises et les organisations gouvernementales, cette évolution oblige à dépasser une vision de la cybersécurité fondée uniquement sur la recherche de logiciels malveillants ou de vulnérabilités connues. La sécurité doit aussi permettre de reconnaître lorsqu’une composante légitime commence à être utilisée dans un contexte qui ne l’est plus.

Développement

Le cas Notepad++ est particulièrement intéressant parce que le logiciel lui-même n’était pas responsable de l’attaque. Selon les éléments rapportés par le CERT-UA, l’utilisateur recevait d’abord une archive contenant notamment un script présenté comme un document. Ce script téléchargeait ensuite une seconde archive dans laquelle se trouvaient une version officielle de Notepad++, une bibliothèque malveillante et d’autres composants. Lorsque Notepad++ était lancé, il chargeait la bibliothèque en utilisant son mécanisme habituel d’extensions. Le programme faisait donc exactement ce qu’il avait été conçu pour faire.

Cette nuance est essentielle. Elle montre que la distinction traditionnelle entre un « bon programme » et un « mauvais programme » devient insuffisante pour comprendre certaines attaques modernes. Une application authentique peut exécuter un composant indésirable. Un outil d’administration peut être détourné. Un script légitime peut servir à automatiser une intrusion. Une tâche planifiée, parfaitement normale dans Windows, peut être utilisée pour maintenir une présence persistante sur un système compromis. Pris individuellement, chacun de ces mécanismes possède une fonction légitime. C’est leur contexte, leur enchaînement et l’intention derrière leur utilisation qui transforment une opération ordinaire en activité malveillante.

Les attaquants ont compris depuis longtemps la valeur de cette ambiguïté. Plus une technologie est connue et couramment utilisée, moins son apparition risque de provoquer immédiatement de la méfiance. Un exécutable inconnu attire l’attention. Notepad++, PowerShell, un utilitaire de compression ou un outil d’administration à distance peuvent au contraire se fondre beaucoup plus facilement dans l’activité normale d’une organisation. La confiance devient alors elle-même une surface d’attaque.

Cette évolution rejoint directement les principes du Zero Trust. Une application autorisée ne devrait pas nécessairement bénéficier d’une confiance illimitée simplement parce que son nom, son éditeur ou sa signature numérique sont connus. Il faut également s’intéresser à son comportement. Quels fichiers charge-t-elle? Quels processus lance-t-elle? Avec quels systèmes communique-t-elle? Quels privilèges utilise-t-elle? Son activité correspond-elle réellement à ce que cette application devrait normalement accomplir? Une application reconnue dont le comportement devient inhabituel mérite autant d’attention qu’un programme inconnu.

Cela ne signifie évidemment pas que les signatures numériques, les listes d’applications autorisées ou les antivirus ont perdu leur utilité. Ils demeurent des couches essentielles de protection. Le problème apparaît lorsqu’une organisation leur demande implicitement de produire une certitude qu’aucune technologie ne peut réellement offrir. Une signature peut confirmer l’origine ou l’intégrité d’un composant donné; elle ne garantit pas que tout l’environnement qui l’entoure est lui aussi digne de confiance. Dans le cas rapporté par Clubic, la version officielle de Notepad++ était bien légitime. C’est l’ensemble préparé autour d’elle qui ne l’était pas.

Cette distinction nous ramène à un principe fondamental de la cybersécurité moderne : la sécurité d’un système dépend rarement d’un seul composant. Elle dépend d’une chaîne. Le logiciel, ses extensions, les bibliothèques qu’il charge, les droits de l’utilisateur, les mécanismes d’exécution, les connexions réseau, les contrôles de sécurité et les processus organisationnels participent tous au résultat final. Une faiblesse ou une mauvaise hypothèse quelque part dans cette chaîne peut permettre à un attaquant de contourner des protections pourtant très solides ailleurs.

Pour les organisations, l’un des enjeux devient donc de mieux comprendre les chemins possibles à travers leur environnement. Un poste utilisateur compromis ne devrait pas automatiquement ouvrir un accès important à d’autres systèmes. Une application ne devrait disposer que des permissions nécessaires à son fonctionnement. Un processus ne devrait pouvoir communiquer qu’avec les ressources correspondant à sa fonction lorsque cette restriction est réaliste. Cette logique du moindre privilège et de la segmentation réduit la capacité d’un incident localisé à devenir un problème beaucoup plus vaste.

C’est là que la résilience complète utilement la prévention. Une stratégie de sécurité exclusivement fondée sur l’idée d’empêcher toute compromission finit inévitablement par rencontrer ses limites. Il existera toujours de nouvelles vulnérabilités, de nouvelles techniques de contournement et de nouveaux moyens d’exploiter des outils déjà présents dans l’environnement. Une architecture résiliente part plutôt de l’hypothèse qu’une première barrière peut un jour être franchie. Elle cherche alors à limiter les conséquences, ralentir la progression de l’attaquant, détecter les comportements anormaux et permettre une intervention rapide.

Le comportement prend justement une importance croissante dans cette capacité de détection. Un éditeur de texte qui ouvre normalement des fichiers possède un certain profil d’activité. S’il commence soudainement à déclencher une série de scripts, créer des tâches planifiées ou établir des communications inhabituelles, ce contexte peut constituer un signal pertinent. L’enjeu n’est donc plus seulement de reconnaître un fichier malveillant connu, mais aussi d’identifier une séquence d’activités qui ne correspond pas au fonctionnement attendu du système.

Cette approche devient encore plus importante à mesure que les environnements informatiques gagnent en complexité. Les organisations utilisent aujourd’hui une combinaison de postes de travail, de services cloud, de logiciels SaaS, d’API, d’équipements connectés, d’applications héritées et, de plus en plus, d’agents d’intelligence artificielle. Chacune de ces composantes introduit ses propres mécanismes de confiance et ses propres dépendances. Les équipes internes doivent maintenir leur compréhension de cet environnement tout en suivant l’évolution permanente des techniques d’attaque.

Il faut reconnaître l’ampleur de cette responsabilité. Une équipe TI ou de cybersécurité peut être extrêmement compétente et néanmoins devoir surveiller simultanément des milliers d’actifs, de comptes, de versions logicielles, de configurations et de relations entre systèmes. Pendant ce temps, les attaquants peuvent consacrer leurs efforts à rechercher une seule faiblesse exploitable. Cette asymétrie explique pourquoi l’ajout d’une expertise externe peut constituer une stratégie de réduction du risque plutôt qu’un constat d’insuffisance des équipes existantes.

Un partenaire spécialisé apporte une perspective différente sur le même environnement. Les équipes internes connaissent profondément leurs opérations, leurs contraintes et l’histoire de leurs systèmes. Cette connaissance est irremplaçable. Un regard externe peut cependant remettre en question certaines hypothèses devenues normales avec le temps, repérer des dépendances qui traversent plusieurs services ou examiner l’architecture selon des scénarios d’attaque auxquels les équipes opérationnelles n’ont pas nécessairement le temps de se consacrer.

C’est précisément dans cette logique que Quantum Beyond peut intervenir. Notre rôle consiste à travailler aux côtés des équipes existantes pour ajouter une couche supplémentaire de compréhension et de réduction du risque. L’architecture de sécurité d’entreprise permet d’examiner les relations entre les différentes composantes plutôt que de considérer chacune isolément. Les audits et évaluations de sécurité permettent de vérifier les configurations, les contrôles et les dépendances. L’IAM et les principes Zero Trust aident à réduire les privilèges et la confiance implicite. La segmentation limite les chemins disponibles lorsqu’un système est compromis, tandis que les approches de cyberrésilience cherchent à préserver la capacité opérationnelle lorsque les mesures préventives seules ne suffisent plus.

Cette approche est également importante du point de vue financier. La cybersécurité peut facilement se transformer en accumulation de produits : un nouvel incident entraîne un nouvel outil, une nouvelle menace produit une nouvelle dépense et l’architecture devient progressivement plus complexe. Pourtant, un environnement possédant davantage de solutions n’est pas nécessairement proportionnellement plus sécuritaire. Les investissements doivent être examinés en fonction de la réduction du risque qu’ils produisent réellement.

Certains contrôles ont justement l’avantage de réduire plusieurs catégories de risques à la fois. Une meilleure gestion des identités réduit l’exposition de nombreux systèmes. Le moindre privilège limite les conséquences de plusieurs scénarios de compromission. Une architecture segmentée ralentit différentes formes de mouvement latéral. Un meilleur inventaire des actifs améliore autant la gestion des vulnérabilités que la réponse aux incidents. Une architecture résiliente permet de récupérer plus efficacement lorsqu’un événement inattendu survient. L’objectif devient donc de construire des couches cohérentes qui se renforcent mutuellement plutôt que de répondre séparément à chaque nouvelle menace.

Le cas Notepad++ permet enfin de comprendre pourquoi cette démarche doit être continue. L’attaque rapportée en juillet 2026 sera analysée, ses indicateurs seront intégrés aux outils de sécurité et les organisations pourront renforcer leurs contrôles. Les attaquants chercheront ensuite d’autres méthodes. Ils utiliseront une autre application, un autre mécanisme d’extension ou une autre relation de confiance. Il est impossible pour une organisation de connaître à l’avance chacune des techniques qui seront utilisées contre elle. Elle peut cependant préparer son environnement à mieux leur résister.

C’est probablement l’une des distinctions les plus importantes entre une stratégie de cybersécurité simplement réactive et une véritable démarche de résilience. La première cherche principalement à corriger les faiblesses déjà connues. La seconde construit des capacités qui demeurent utiles même lorsque la prochaine attaque prend une forme que personne n’avait encore anticipée.

L’incident impliquant Notepad++ apporte une nouvelle dimension à la réflexion sur la présence désormais omniprésente du risque cyber. Après avoir constaté qu’une borne de recharge pouvait devenir une interface réseau et une surface d’exposition inattendue, nous voyons ici qu’un logiciel parfaitement authentique peut lui aussi participer involontairement à une attaque sans avoir été compromis.

La leçon n’est pas qu’il faudrait cesser de faire confiance aux logiciels légitimes. Une organisation incapable d’accorder aucune confiance deviendrait tout simplement incapable de fonctionner. L’enjeu consiste plutôt à transformer cette confiance en quelque chose de précis, limité et continuellement vérifiable.

La cybersécurité moderne doit donc regarder au-delà du nom du logiciel ou de la réputation de son fournisseur. Elle doit comprendre les comportements, les permissions, les identités, les dépendances et les chemins qui relient les différentes composantes du système. Elle doit également accepter qu’une première protection puisse échouer et prévoir les couches suivantes qui limiteront les conséquences.

Pour les équipes TI et cybersécurité, cette responsabilité devient de plus en plus complexe à mesure que les environnements numériques se multiplient et que les techniques d’attaque évoluent. C’est dans ce contexte que Quantum Beyond peut devenir un partenaire complémentaire : en travaillant avec les équipes internes pour challenger les hypothèses de confiance, examiner les architectures, réduire les privilèges et les chemins d’attaque, améliorer la segmentation et renforcer la capacité de l’organisation à continuer de fonctionner lorsqu’un événement inattendu survient.

Notre contribution ne repose pas sur la promesse irréaliste d’éliminer tous les risques. Elle vise plutôt à ajouter une couche spécialisée de vigilance, d’architecture et de résilience afin que les risques connus et inconnus disposent de moins de possibilités de se transformer en incidents majeurs. Car la difficulté croissante en cybersécurité ne consiste plus seulement à reconnaître ce qui est dangereux. Elle consiste également à savoir quand quelque chose de parfaitement légitime commence à être utilisé d’une manière qui ne l’est plus.