Pendant la Seconde Guerre mondiale, on a demandé à Abraham Wald où il fallait ajouter du blindage sur les bombardiers. L'instinct des militaires était d'étudier les avions qui revenaient et de renforcer les zones où les impacts de balles étaient les plus nombreux. Wald a conseillé de faire le contraire. Les avions qui se trouvaient devant lui avaient déjà survécu à des impacts à ces endroits précis. C'est précisément pour cette raison qu'il pouvait les étudier. Les avions qui avaient été touchés au niveau du moteur ou du cockpit n'étaient jamais revenus et n'avaient donc pas pu être étudiés.
L'ingénierie de détection présente le même angle mort, et il est facile de passer à côté, car les plans qui subsistent donnent l'impression d'un tableau complet si l'on ne se demande jamais ce qui n'est pas sous nos yeux. Chaque règle que nous rédigeons et chaque modèle que nous qualifions de « connu comme malveillant » provient de paquets d'attaquants qui nous sont parvenus, ce qui signifie qu'ils ont été interceptés. Nous étudions les impacts de balles sur les avions qui sont revenus et nous considérons cela comme le tableau complet de ce qui existe réellement. Les criminologues ont un nom pour désigner le phénomène auquel ils sont confrontés : le « chiffre noir de la criminalité ». Il s’agit de l’écart entre les incidents détectés et ceux qui se produisent réellement. Toutes les statistiques sur la criminalité reposent sur les criminels qui ont été arrêtés. Ceux qui étudient ce phénomène le savent et en tiennent compte.
Les implications pour la rédaction des règles sont dérangeantes, mais importantes. Les règles au niveau des chaînes de caractères ne peuvent détecter que les attaquants qui réutilisent des artefacts que nous avons déjà observés. De par leur conception même, elles ne peuvent pas détecter un attaquant suffisamment sophistiqué pour n’être jamais apparu dans nos données de suivi, tout comme aucune analyse des avions de retour ne pourra jamais révéler où les avions qui ne sont pas revenus ont été touchés. Les règles au niveau comportemental constituent notre seule véritable chance face à l’inconnu. L’attaquant doit toujours exfiltrer les données, exécuter le code et communiquer avec son commandement. Ses actions sont limitées. En revanche, le nom qu’il donne à son code, la manière dont il l’obfuscate et la destination à laquelle il l’envoie ne le sont pas.
Mais l’identification des comportements n’est utile que si l’on sait d’emblée à quoi ressemble la « normale ». Wald a pu repérer les avions disparus parce qu’il savait déjà à quoi ressemblait un avion intact, en parfait état. C’est ce qui lui a permis de recouper chaque impact de balle sur chaque avion de retour avec une configuration complète attendue : ailes, fuselage, queue, moteur, cockpit, tout. Une fois qu’il a eu cette carte complète, ce qui ressortait, ce n’était pas l’endroit où se trouvaient les dégâts. C’était l’endroit où il n’y en avait pas.
L'ingénierie de détection ne bénéficie pas de cet avantage d'emblée. Si nous ne disposons pas d'une vision claire et complète du comportement normal des paquets, un appel réseau inattendu ou le lancement d'un processus inconnu ne sera pas identifié comme une anomalie. Cela ressemblera simplement à du bruit supplémentaire dans un système qui n'a pas été cartographié.
Le coût réel d’un ensemble de données comportementales incomplet va bien au-delà de l’absence d’une ou deux règles. Il réside dans le fait que nous perdons même la capacité de reconnaître la forme de ce qui manque. Un attaquant qui n’apparaît jamais dans nos détections basées sur des chaînes de caractères doit tout de même agir, et cette action n’est perçue comme anormale que si nous avons défini la référence par rapport à laquelle elle s’écarte. Sans cette référence, les paquets invisibles restent invisibles pour une deuxième raison qui s'ajoute à la première. Non seulement ils ont évité de laisser une signature, mais ils opèrent également dans un espace que nous n'avons jamais pris la peine de décrire ; par conséquent, rien ne semble anormal à leur sujet, à moins que nous n'examinions les capacités et les comportements des paquets.
Les règles de chaînes et IOC peu coûteuses constituent une utilisation rationnelle des ressources. Les stratégies utilisées dans la grande majorité des paquets malveillants sont peu sophistiquées et réutilisées, la même charge utile étant copiée dans toute une vague de paquets. Une règle de chaîne jetable intercepte cette vague entière à un coût quasi nul, devient obsolète dès que l’attaquant change de stratégie et peut être réécrite tout aussi facilement. Le fait que les règles de chaînes peu coûteuses « meurent jeunes » signifie que ce niveau d’entrée de gamme remplit parfaitement la fonction pour laquelle il a été conçu. Exiger une base de référence comportementale coûteuse pour des menaces qu’une règle de chaîne de caractères élaborée en cinq minutes parvient déjà à bloquer reviendrait à une utilisation inefficace du temps.
La réponse réside dans un ensemble de règles couvrant l'ensemble de la pyramide. Les règles peu coûteuses des niveaux inférieurs gèrent les volumes élevés. Les règles coûteuses des niveaux supérieurs constituent notre seul moyen d'atteindre les quelques attaquants sophistiqués qui se cachent dans la « figure sombre ». À chaque niveau correspond un rôle différent, et le choix de la règle à utiliser dépend entièrement du type d'attaquant que l'on cherche à intercepter. C'est exactement ce qu'illustre la pyramide adaptée ci-dessous.
Une pyramide adaptée
La « pyramide de la douleur » de David Bianco [1] nous permet d’aborder cette question par niveaux, plutôt que de considérer la détection comme une catégorie unique et uniforme, adaptée ici au contexte de la chaîne d’approvisionnement des logiciels. Nous pouvons classer les types d’indicateurs en fonction du coût que représente leur modification pour un attaquant, de « trivial » à « quasi impossible ». Cela va des événements fortuits, comme les valeurs de hachage, aux comportements manifestement délibérés, tels que les techniques et les stratégies.
Chaque niveau, à l'exception du sommet, correspond à un choix effectué par l'attaquant. Un domaine, un schéma d'encodage, voire un outil : tout cela relève d'une décision, et ces décisions sont revues dès qu'elles cessent de servir les intérêts de l'attaquant. C'est ce qui fait du sommet de la pyramide l'endroit idéal pour établir des règles durables, mais c'est aussi précisément là qu'il est le plus difficile d'en rédiger une, car les détections au niveau technique et stratégique doivent s'appuyer sur une véritable base de référence, sans quoi elles ne fonctionnent pas du tout.
Ce qui soulève la question évidente de savoir d’où provient cette référence, car la pyramide ne nous la fournit pas. Classer les indicateurs en fonction du coût que représente leur modification nous indique où se trouvent les règles durables, mais pas comment détecter un écart en premier lieu. La manière la plus pratique de se faire une idée est de cesser de rechercher une référence universelle (qui n’existe pas) et de cartographier plutôt les comportements normaux par type de bibliothèque. Un outil de build, un utilitaire en ligne de commande, un framework web et un minuscule utilitaire à fonction pure sont des types de logiciels différents, dotés de capacités différentes.
Un outil de compilation qui lance des processus fils et intervient sur le système de fichiers lors de l’installation se comporte comme prévu, alors qu’une aide au formatage de chaînes de caractères faisant la même chose ne se comporte pas ainsi. Ce sont les capacités et les actions du paquet qui déterminent le comportement acceptable, et les mêmes catégories de paquets ont tendance à se comporter de manière similaire sur npm, PyPI et NuGet ; le profil est donc suffisamment stable pour être réutilisé. Si nous parvenons à rendre cette carte suffisamment complète, une action inconnue ne sera plus perçue comme du bruit, mais comme une lacune dans le schéma attendu, ce qui est justement le but recherché. C'est un travail considérable, et la carte restera toujours incomplète, mais c'est ce travail qui rend le sommet de la pyramide accessible.
Représentation de la forme
Chaque paquet ingéré par Security d'Aikido est analysé de manière statique et exécuté dans un bac à sable qui enregistre ses actions réelles. Cette partie-là est classique. Ce qui a changé, c’est qu’un indicateur comporte désormais une structure allant au-delà du simple fait qu’il se soit déclenché. Chacun d’entre eux décrit ce que le code correspondant est capable de faire et quel type de preuve il représente, de sorte qu’un signal qui, pris isolément, n’a que peu de sens, peut être mis en balance avec les autres signaux qui l’entourent.
Cela permet à une règle de détection de décrire une forme plutôt qu’une chaîne de caractères. Du code qui s’exécute au moment de l’installation, accédant à des identifiants qu’il n’a aucune raison de manipuler, envoyant des données vers l’extérieur, dans un paquet dont la fonction déclarée n’explique rien de tout cela. Une règle de ce type ne contient aucun domaine, aucun hachage, aucun nom de paquet. Elle ne contient rien qu’un attaquant puisse exploiter.
Le 4 août 2026, nous avons repéré une nouvelle version de Keyv, qui se présentait comme le même utilitaire de stockage clé-valeur populaire et fiable, téléchargé 600 millions de fois depuis NPM. Cette fois-ci, cependant, lors de l’installation, elle exécutait un fichier JavaScript fortement obfusqué, qui téléchargeait ensuite Bun (un moteur JavaScript alternatif à Node.js), avant d’exécuter un autre fichier JavaScript obfusqué. Ces outils et techniques comportementales ont suffi à notre système pour le détecter. Si nous nous étions contentés d’utiliser des indicateurs nommés, nous aurions manqué ce paquet. Mais comme nous recherchons l’inattendu, nous sommes en mesure de repérer ces paquets qui, autrement, passeraient inaperçus.
Notre système a correctement conclu ce qui suit, même s’il ne pouvait pas avoir une vue d’ensemble en raison de la forte obfuscation : « La combinaison d’une exécution dissimulée au moment de l’installation, de la récupération à distance d’un binaire, de la mise en place de la charge utile et de son lancement suffit pour établir un verdict de malware avec un haut niveau de confiance, même si le comportement final de la charge utile et tout objectif de vol de données n’ont pas été entièrement décodés ».
Il est actuellement difficile – et cela l’a toujours été, pour le moins – de décoder et de comprendre les logiciels malveillants obscurcis, en particulier du point de vue de l’analyse statique. C’est d’ailleurs pour cela que les attaquants les ont conçus ainsi. Ce que nous pouvons en revanche démontrer, c’est que le comportement des paquets malveillants suffit à nous permettre de mettre au jour les chiffres cachés.
Une petite silhouette sombre subsiste encore. Wald n’a pas non plus vu les avions abattus. Ce qui lui a permis de déterminer où ils avaient été touchés, c’est qu’il connaissait suffisamment bien la forme d’un avion entier pour remarquer là où le schéma se rompait. Notre version de cette forme constitue une référence du comportement normal d’un paquet, mise à jour en temps réel plutôt que supposée, et chaque paquet que nous trions vient l’enrichir. Les attaquants que nous n’avons pas encore appréhendés restent limités par ce que le code doit faire pour voler quelque chose. Chacune de ces contraintes est une brèche dont nous connaissons déjà l’emplacement sur un avion qui n’est pas rentré.
Découvrez ce que nous détectons grâce à Intel «Aikido ». Nous détectons les logiciels malveillants en quelques minutes. Connectez votre dépôt à Aikido pour analyser en continu les dépendances de votre application à la recherche de paquets malveillants.
Références
[1] Bianco, D. J. (2013). « The Pyramid of Pain ». Enterprise Detection and Response. http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html (mis à jour le 17 janvier 2014, avec l'ajout du niveau « valeurs de hachage »).
