Pendant la Seconde Guerre mondiale, on a demandé à Abraham Wald où il convenait d'ajouter du blindage sur les bombardiers. L'instinct de l'armée était d'étudier les appareils rentrés de mission et de renforcer les zones présentant le plus d'impacts de balles. Wald a conseillé de faire exactement l'inverse. Les avions sous ses yeux avaient déjà survécu à des tirs dans ces zones, et c'était précisément la raison pour laquelle il pouvait les étudier. Ceux qui avaient reçu des tirs dans le moteur ou le cockpit ne s'étaient jamais posés et ne pouvaient donc faire l'objet d'aucune analyse.
L'ingénierie de détection souffre du même angle mort, facile à ignorer car les avions survivants donnent une fausse impression d'exhaustivité tant qu'on ne se demande pas ce qui manque à l'appel. Chaque règle que nous écrivons et chaque modèle qualifié de « malveillant connu » proviennent de paquets d'attaquants parvenus jusqu'à nous, ce qui signifie qu'ils ont été interceptés. Nous analysons les impacts sur les avions revenus et prétendons avoir une vue d'ensemble de la situation. Les criminologues ont un terme pour désigner ce phénomène : le chiffre noir de la criminalité. C'est l'écart entre les incidents détectés et ceux qui se produisent réellement. Toutes les statistiques criminelles reposent sur les criminels qui se sont fait prendre. Les spécialistes le savent et en tiennent compte.
Pour la rédaction des règles, la conséquence est dérangeante mais cruciale. Les règles au niveau des chaînes de caractères ne peuvent attraper que les attaquants qui réutilisent des artefacts déjà connus. Par construction, elles sont incapables d'arrêter un attaquant suffisamment sophistiqué pour n'avoir jamais laissé de traces dans nos données de suivi, de la même manière qu'aucune étude d'avions rentrés ne vous révélera où les avions abattus ont été touchés. Les règles comportementales constituent notre seule véritable chance face à l'inconnu. L'attaquant doit toujours exfiltrer les données, exécuter son code et communiquer avec son serveur de commandement. Ses actions sont contraintes. Leur nom, leur méthode d'obfuscation et leur destination ne le sont pas.
Cependant, l'identification comportementale n'est utile que si nous savons à quoi ressemble un comportement normal. Wald a pu pointer du doigt les zones manquantes sur les avions car il connaissait la forme d'un appareil intact. C'est cela qui lui a permis de comparer les impacts de chaque avion de retour avec une silhouette idéale complète (ailes, fuselage, queue, moteur, cockpit, etc.). Une fois cette cartographie complète établie, ce qui sautait aux yeux n'était pas l'emplacement des dégâts, mais leur absence.
L'ingénierie de détection n'obtient pas cela par défaut. Si nous n'avons pas une vision claire et complète du comportement normal d'un paquet, un appel réseau inattendu ou le lancement d'un processus inconnu ne signalera aucune anomalie. Cela ressemblera simplement à du bruit supplémentaire dans un système non cartographié.
Le véritable coût d'un ensemble de données comportementales incomplet va au-delà d'une règle manquante. Nous perdons la capacité même de reconnaître la forme de ce qui fait défaut. Un attaquant dont les traces textuelles n'apparaissent jamais doit tout de même agir, et cette action ne devient anormale que si nous avons défini la ligne de base dont elle s'écarte. Sans cette référence, les paquets invisibles le restent pour une seconde raison en plus de la première : non seulement ils ne laissent aucune signature, mais ils opèrent dans un espace que nous n'avons jamais pris la peine de décrire. Rien chez eux ne paraîtra donc suspect, à moins d'analyser en profondeur leurs fonctionnalités et comportements.
L'utilisation de règles textuelles et d'indicateurs de compromission (IoC) économiques relève d'une gestion rationnelle des efforts. La grande majorité des paquets malveillants s'appuie sur des stratégies peu sophistiquées et réutilisées, le même charge utile étant copié d'un paquet à l'autre. Une règle textuelle jetable intercepte toute cette vague à moindre coût, devient obsolète dès que l'attaquant pivote, et se réécrit tout aussi facilement. Le fait que des règles textuelles bon marché « meurent jeunes » correspond exactement à leur rôle premier. Exiger une référence comportementale sophistiquée pour des menaces qu'une règle textuelle de cinq minutes neutralise déjà constituerait une perte de temps.
La solution réside dans un portefeuille de règles couvrant toute la pyramide. Les règles d'entrée de gamme, économiques, gèrent le volume élevé. Les règles de niveau supérieur, plus coûteuses, sont nos seuls leviers pour atteindre les quelques profils sophistiqués cachés dans l'angle mort. À chaque niveau ses missions, et le choix de la règle dépend entièrement de l'attaquant que vous cherchez à attraper. C'est précisément ce que démontre la pyramide adaptée ci-dessous.
Une pyramide adaptée
La pyramide de la douleur de David Bianco [1] nous offre un cadre de réflexion structuré en couches plutôt qu'en une catégorie unique et uniforme, adaptée ici au contexte de la chaîne d'approvisionnement des paquets. Nous pouvons classer les types d'indicateurs selon le coût qu'implique leur modification pour un attaquant, du niveau trivial au quasi-impossible. Cela va des occurrences fortuites, telles que les valeurs de hachage, aux comportements délibérés comme les techniques et les stratégies.
Chaque niveau, à l'exception du sommet, relève d'un choix de l'attaquant. Qu'il s'agisse d'un domaine, d'un schéma d'encodage ou même d'un outil, tout est une décision, et ces décisions sont modifiées dès qu'elles cessent d'être efficaces pour lui. 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 le plus difficile pour en rédiger une, car les détections au niveau des techniques et de la stratégie nécessitent une véritable base de référence sous-jacente, sans quoi elles ne fonctionnent tout simplement pas.
Ce qui soulève la question évidente de l'origine de cette base de référence, la pyramide ne nous l'apportant pas sur un plateau. Classer les indicateurs selon leur coût de modification nous indique où résident les règles durables, et non comment repérer une anomalie au départ. La méthode la plus pragmatique pour dresser ce panorama consiste à abandonner la recherche d'une base de référence universelle (qui n'existe pas) pour cartographier le comportement normal par type de paquet. Un outil de construction, un utilitaire en ligne de commande, un framework web et un petit utilitaire de fonction pure sont des types de logiciels différents dotés de capacités distinctes.
Un outil de build qui génère des processus enfants et interagit avec le système de fichiers lors de son installation se comporte de manière attendue, tandis qu'un assistant de formatage de chaînes de caractères faisant de même ne le fait pas. Les capacités et les actions du paquet déterminent son comportement acceptable, et des catégories de paquets similaires tendent à se comporter de la même manière sur npm, PyPI et NuGet ; le profil est donc suffisamment stable pour être réutilisé. Si nous parvenons à compléter cette cartographie, une action inhabituelle cesse d'apparaître comme du bruit pour devenir une anomalie évidente par rapport au schéma attendu, ce qui est précisément le but recherché. C'est un travail considérable, et la cartographie sera toujours partielle, mais c'est précisément ce qui rend le sommet de la pyramide accessible.
Cartographier la structure
Chaque paquet analysé par Aikido Security fait l'objet d'une analyse statique et s'exécute dans un bac à sable (sandbox) qui enregistre ses actions réelles. Jusqu'ici, rien que de très classique. Ce qui change, c'est qu'un indicateur véhicule désormais une structure qui va au-delà du simple déclenchement. Chacun d'eux décrit ce que le code analysé est capable de faire et le type de preuve qu'il représente, de sorte qu'un signal peu probant pris isolément peut être pondéré par rapport aux autres éléments qui l'entourent.
Cela permet à une règle de détection de décrire une structure plutôt qu'une simple chaîne de caractères. Du code qui s'exécute lors de l'installation, cherche à accéder à des identifiants qu'il n'a aucune raison de manipuler, transmet des données vers l'extérieur, le tout au sein d'un paquet dont la fonction déclarée ne justifie rien de tout cela. Une telle règle ne contient aucun domaine, aucun hachage, aucun nom de paquet. Rien qu'un attaquant ne puisse modifier.
Le 4 août 2026, nous avons signalé une version fraîchement publiée de Keyv, présentée comme le célèbre et fiable utilitaire clé-valeur téléchargé 600 millions de fois depuis NPM. Cette fois-ci, cependant, il a exécuté lors de son installation un fichier JavaScript hautement obfusqué, qui a ensuite téléchargé Bun (un alternative à Node.js pour exécuter du JavaScript), avant d'exécuter un autre fichier JavaScript obfusqué. Ces outils et techniques comportementaux ont suffi à notre système pour le détecter. Si nous nous étions contentés d'indicateurs nommés, nous serions passés à côté de ce paquet. Mais comme nous recherchons l'anomalie, nous sommes capables d'intercepter ces paquets qui, autrement, passeraient inaperçus dans cette zone d'ombre.
Notre système a correctement conclu ce qui suit, malgré l'impossibilité d'avoir une vision globale en raison de l'obfuscation poussée : « La combinaison d'une exécution dissimulée lors de l'installation, de la récupération de binaires distants, du recours à une charge utile (payload) intermédiaire et de son lancement suffit à qualifier le code de logiciel malveillant avec un haut niveau de confiance, même si le comportement final de la charge utile et l'objectif éventuel de vol de données n'ont pas été entièrement décodés ».
Il est actuellement, et a toujours été, pour le moins difficile de décoder et de comprendre des malwares obfusqués, en particulier sous l'angle de l'analyse statique. C'est précisément pour cela que les censeurs ou les attaquants y ont recours. Ce que nous pouvons démontrer en revanche, c'est que le comportement des paquets malveillants suffit amplement pour démasquer ces menaces invisibles.
Une infime part d'ombre subsiste. Abraham Wald n'a jamais vu non plus les avions abattus. Ce qui lui a permis de déterminer où ils avaient été touchés, c'était de connaître suffisamment bien la structure d'un avion complet pour remarquer où le schéma était brisé. Notre version de cette structure correspond à une base de référence du comportement normal des paquets, constamment mise à jour plutôt que présumée, et chaque paquet que nous traitons vient l'enrichir. Les attaquants que nous n'avons pas encore interceptés restent contraints par ce que le code doit accomplir pour dérober des données. Chacune de ces contraintes matérialise une faille dont nous connaissons déjà l'emplacement sur un appareil qui n'est pas rentré de mission.
Découvrez ce que nous bloquons sur Aikido Intel. Nous détectons les malwares en quelques minutes. Connectez votre dépôt à Aikido pour analyser en continu les dépendances de vos applications à 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 (révisé le 17 janvier 2014, avec l'ajout du niveau des valeurs de hachage).
