Les outils de sécurité peuvent réussir à stopper une version connue d’une attaque, mais laisser passer le même comportement lorsqu’il est exécuté d’une manière moins visible. C’est la principale conclusion d’une analyse fondée sur le Blue Report 2026 publié par Picus Labs, qui a mesuré les performances des moyens de prévention et de détection dans de véritables environnements clients au moyen de plus de 338 millions de simulations d’attaques exécutées entre janvier et juin 2026.
L’efficacité globale de la prévention est passée à 69 %, contre 62 % l’année précédente, revenant ainsi au niveau de 2024. Toutefois, ce chiffre représente une moyenne à l’échelle de l’écosystème de protection et n’indique pas nécessairement ce qu’un attaquant peut faire après être entré dans l’environnement ou lorsqu’il modifie l’outil et la méthode utilisés pour atteindre le même objectif.
Un indicateur connu n’équivaut pas à une protection contre le comportement
L’analyse distingue deux types de tests. Les tests fondés sur des indicateurs connus, ou IOC-based testing, vérifient la capacité des pare-feu, des agents web et des passerelles de messagerie sécurisée à reconnaître des échantillons malveillants connus et à bloquer les tentatives de téléchargement. Cette mesure convient à la couche de protection périmétrique, mais elle ne répond pas à une autre question : l’écosystème peut-il empêcher l’action exécutée par l’attaquant, indépendamment de l’outil ou du chemin utilisé ?
C’est là qu’interviennent les tests comportementaux fondés sur les tactiques, techniques et procédures (TTP). Au lieu de demander si l’outil Mimikatz est connu du système, cette approche vérifie si n’importe quel programme présent sur l’appareil peut obtenir des éléments d’authentification de l’utilisateur. Cette question est importante pour les outils de protection des terminaux et les systèmes de détection des intrusions, car l’attaquant a souvent déjà commencé son exécution à l’intérieur de l’environnement lorsque ces contrôles interviennent.
Le taux de blocage des téléchargements de logiciels malveillants connus selon les indicateurs IOC a reculé à 50 % dans les données de 2026, contre 60 % en 2025 et 71 % en 2024. Cela indique que même la couche qui dépend le plus des signatures n’offre pas une couverture constante ; de plus, un bon résultat lors d’un test portant sur une signature connue ne révèle pas ce qui se passe lorsque le comportement ou son mode d’exécution change.
L’exemple de Mimikatz révèle l’écart
Les environnements clients ont utilisé l’outil Mimikatz pour atteindre le même objectif, à savoir extraire des identifiants, par trois voies. L’extraction de données de la mémoire d’un processus LSASS a été bloquée dans 94 % des tentatives, ce qui correspond au chemin traditionnel surveillé à grande échelle par les produits. Mais le taux est tombé à 17 % lors de la récupération d’identifiants RDP depuis d’autres emplacements de la mémoire avec le même outil, et à 3 % lors de la lecture des LSA Secrets dans le registre système local.
Les trois cas relèvent de la même technique parente, OS Credential Dumping (T1003), et aboutissent au même résultat : la possession par l’attaquant d’éléments d’authentification sensibles. La différence résidait dans le degré de visibilité du chemin pour les contrôles de sécurité. La lecture de la mémoire de lsass.exe laisse des événements qui peuvent être mis en correspondance plus facilement, tandis que la lecture d’une ruche du registre avec des privilèges SYSTEM peut ressembler davantage à une activité administrative ordinaire.
En outre, le succès du blocage contre une version connue de Mimikatz ne garantit pas la stabilité du résultat. Il est possible de modifier les chaînes de caractères utilisées par la signature, de recompiler l’outil, de charger le code en mémoire sans le laisser sur le disque, ou d’utiliser des outils signés par Microsoft tels que ProcDump ou comsvcs.dll, puis d’analyser les données ultérieurement. Dans ces situations, l’empreinte recherchée par les signatures change, tandis que le comportement et l’objectif final restent les mêmes.
La protection à l’intérieur de l’environnement est plus faible que la protection aux frontières
Le taux global de blocage a atteint 69 % lorsqu’il était mesuré au niveau du périmètre, mais les tests d’intrusion autonomes mesurant ce qu’un attaquant peut faire après être entré en tant qu’utilisateur authentifié ont montré que seulement 37 % des actions post-compromission avaient été bloquées. Autrement dit, la protection est passée du blocage d’environ deux tiers des attaques au périmètre au blocage d’un peu plus d’un tiers des actions à l’intérieur de l’environnement.
Les actions les plus bruyantes étaient plus faciles à détecter : la détection des mouvements latéraux a atteint environ 90 %, le contournement de l’UAC a dépassé 85 %, tandis que le blocage de la réutilisation des identifiants et de l’abus d’Active Directory a atteint environ 63 %. En revanche, les taux ont chuté pour les activités moins visibles : la protection des éléments d’authentification lus passivement dans la mémoire et le registre n’a pas dépassé 22 %, et était inférieure à 1 % dans le cas de l’extraction des secrets du registre local. Les activités de découverte et de collecte n’ont pas non plus dépassé 10 %, et les opérations d’énumération du domaine au moyen de SharpHound ainsi que la collecte de fichiers locaux se sont généralement déroulées sans obstacle.
Qu’est-ce qui change concrètement ?
La conclusion pratique de l’analyse est que les programmes de validation de la sécurité doivent interpréter chaque test selon ce qu’il mesure, plutôt que de considérer un résultat unique comme une preuve globale de couverture. Les tests portant sur des échantillons connus restent adaptés aux pare-feu, aux agents web, aux pare-feu d’applications web et aux passerelles de messagerie sécurisée. En revanche, la couche des terminaux et de la détection, notamment l’EDR, les IDS et le contenu des SIEM, doit tester toutes les voies menant au même objectif : la mémoire LSASS, le registre, les autres emplacements mémoire, les outils natifs et les versions recompilées.
L’article met en garde contre le fait que tester uniquement l’action célèbre peut conduire à considérer comme clos un point qui reste en réalité exposé. L’analyse propose d’utiliser plusieurs simulations du même comportement pour vérifier les contrôles en place, plutôt que de se contenter de démontrer qu’une signature a reconnu un seul outil. Picus Swarm est citée comme une couche d’orchestration permettant d’exécuter et de tester ces variantes dans l’environnement, dans le cadre des produits et services de l’entreprise.
La recommandation ne consiste pas nécessairement à ajouter de nouveaux outils, mais à déterminer quels contrôles existants sont réellement capables d’interrompre la chaîne d’attaque, puis à prendre une décision documentée pour chaque exposition : correction, atténuation, surveillance ou acceptation étayée par des preuves. Selon l’article, les résultats du rapport s’inscrivent dans une étude plus large couvrant les écarts de performance entre les secteurs et les régions, les vulnérabilités les plus exploitées, un taux de journalisation de 58 % et un taux d’alertes de 14 %.