Lorsque Mozilla a publié Firefox 150 avec des correctifs pour 271 problèmes identifiés par le modèle Mythos d'Anthropic, les gros titres se sont concentrés sur les chiffres annoncés. En réalité, le détail important se trouvait plus bas : Mozilla n'a attribué que trois CVE à ce modèle. Les 268 restantes ont été classées comme relevant de la défense en profondeur, du renforcement de la sécurité ou décrites comme des bugs dans des chemins de code qui ne pouvaient pas être exploités.

C’est dans cet écart, entre ce que l’IA peut détecter et ce que les attaquants peuvent exploiter, que réside la défense moderne. Le reste des documents publics le confirme. Le CTO de Mozilla et des chercheurs indépendants ont publiquement déclaré que Mythos trouvait ce que des humains compétents pourraient trouver, mais plus rapidement. 

La simulation de bout en bout de AI Security Institute britannique a montré que Mythos réussissait trois tentatives sur 10. Les travaux de réplication d’AISLE ont montré que des modèles plus anciens et moins coûteux pouvaient reproduire la majeure partie des découvertes, tandis que l’exploitation restait le problème le plus difficile et dépendant des frontières de ces derniers. Palo Alto Networks a signalé que Mythos pouvait combiner plusieurs problèmes de moindre gravité pour aboutir à des exploits critiques. 

C'est une réalité. Mais chaque maillon de la chaîne doit tout de même effectuer une action physique sur la mémoire, les jetons, les processus ou les fichiers. Ces actions sont visibles pour un défenseur qui sait ce qu'il faut surveiller, quelle que soit la vulnérabilité initiale ciblée par l'attaquant. L'exploitation de failles n'est d'ailleurs qu'une des nombreuses façons dont les attaquants atteignent leurs objectifs. Le phishing, le vol d’identifiants, les menaces internes et la compromission de la supply chain permettent de contourner entièrement l’étape d’exploitation. 

Sophos se situe au niveau de la couche sous-jacente à tous ces vecteurs d'entrée. Il existe un petit ensemble de mécanismes que tout attaquant doit utiliser lorsqu'il tente d'agir sur une machine réelle. Que l'attaquant soit un pipeline d'exploitation piloté par l'IA, un affilié à un ransomware utilisant des identifiants volés ou un opérateur étatique opérant manuellement, tous se heurtent par défaut au même mur de mesures de mitigation architecturales, sur chaque processus. 

Nous ne prétendons pas que les attaquants ne pourront jamais pas passer au travers des défenses. Nous affirmons simplement que Sophos Endpoint rend l'exploitation d'une vulnérabilité beaucoup plus difficile, et c'est dans cette zone de friction que les défenseurs prennent l'avantage.

Le problème de l'ouverture

Windows est, de par sa conception, un système d'exploitation extraordinairement ouvert. Le succès de la plateforme repose en partie sur cette flexibilité. Les débogueurs inspectent d'autres processus, les frameworks de plugin chargent des modules arbitraires, les outils d'accessibilité interagissent par programmation avec les applications, et des décennies de logiciels légitimes dépendent du maintien de la permissivité des primitives. 

Ce sont les mêmes primitives que les attaquants recherchent en premier. Sur une installation Windows par défaut, un attaquant disposant des droits d'exécution de code en tant qu'utilisateur normal peut écrire du code dans un autre processus en cours d'exécution, allouer de la mémoire exécutable de manière dynamique, manipuler des structures sensibles à la sécurité à l'intérieur de processus de confiance et modifier les DLL système pour désactiver l'inspection. Rien de tout cela ne nécessite de vulnérabilité ou d'élévation de privilèges.

Microsoft a investi massivement dans les protections, allant d'EMET à Windows Defender Exploit Guard en passant par les règles de réduction de la surface d'attaque. Le problème inévitable est celui de la compatibilité. Les mesures de mitigation les plus puissantes intégrées au processus (Code Integrity Guard, Arbitrary Code Guard, Disable Win32k System Calls, Export Address Filtering) sont optionnelles par conception. 

Et elles doivent l'être : en effet, les appliquer à une application qui n'a pas été conçue pour cela au départ perturbe le fonctionnement des compilateurs JIT, des environnements d'exécution .NET, des navigateurs et de la plupart des logiciels tiers. Même Microsoft n'a pas inclus sa propre suite Office dans cette catégorie, et sa documentation les décrit comme étant globalement incompatibles avec les applications classiques. En dehors d'Edge et de quelques processus de navigateur renforcés, les mesures de mitigation agressives sont absentes de la majeure partie du système d'exploitation.

Les applications qui fonctionnent avec ces mesures de mitigation (Edge, Chrome, Firefox) y sont parvenues en repensant leur architecture selon des modèles multiprocessus qui isolent la génération de code dynamique du contenu non fiable. Cette option n'est pas disponible pour les applications construites autour de l'intégration in-process : VBA, automatisation COM, modules complémentaires (add-ins), OLE. Office en est l'exemple type.

Sophos a emprunté une voie différente. Plutôt que de demander à Microsoft, aux développeurs d'application ou aux clients de donner leur accord, nous avons construit notre propre couche de mitigation (indépendante du système d'exploitation, indépendante de l'application) qui limite les primitives sur lesquelles les attaquants s'appuient (déviation du chemin d'exécution du code, mémoire exécutable dynamique, injection de code, modification des DLL système) lors de l'exécution, sur chaque processus, par défaut. 

Les mêmes garde-fous s'appliquent à tout ce que l'attaquant exécute ensuite : les charges virales déposées, les outils de post-exploitation et les binaires de ransomware sont également considérés comme des processus. C’est la maîtrise à la fois des mesures de mitigation et de l’infrastructure qui les contrôle qui a rendu cela possible : il a fallu des années d’ingénierie en matière de compatibilité pour y parvenir, et nous continuons à les faire évoluer au gré des changements du paysage des menaces.

Pourquoi l'IA ne change pas notre approche ?

Trois éléments issus des documents publics concernant l'offensive pilotée par l'IA sont faciles à manquer.

1. L'IA accélère la découverte, mais elle n'invente pas de nouvelles primitives d'exploitation. Il existe une différence significative entre trouver des bugs et inventer de nouvelles façons de transformer ces bugs en code fonctionnel. Les données actuelles concernant l'IA offensive ne montrent pas que les modèles de pointe (de type frontière) inventent des primitives. Cela les montre en train d'appliquer, de combiner et de faire varier des primitives que la communauté de la sécurité connaît déjà. C’est cet ensemble délimité que Sophos cible depuis des années.
2. L’obfuscation augmente la probabilité que les mécanismes de protection de Sophos ne se déclenchent, et non l’inverse. Les moteurs de signature ont des difficultés avec l'obfuscation car les octets ne correspondent pas. Les mesures de mitigation de Sophos se situent sous la couche d'obfuscation. Le code de l'attaquant, obfusqué ou chiffré, doit se déobfusquer lui-même en mémoire avant de pouvoir s'exécuter, ce qui nécessite l'allocation d'une mémoire accessible en écriture puis exécutable, le déchiffrement dans cette mémoire et le transfert du contrôle. C’est précisément cette séquence que la couche d’intégrité de la mémoire (memory-integrity) de Sophos est conçue pour détecter. Une dissimulation plus élaborée rend l'attaquant plus visible, et non l'inverse.
3. Lorsque l'on demande à l'IA de produire un code d'exploitation évasif, elle produit le playbook que les attaquants ont toujours utilisé : appels système directs, redirection de points d’arrêt (breakpoint) hardware, usurpation de pile d'exécution (call-stack), correctifs ETW, contournements AMSI et altération de hooks in-memory. Chacune d'elles est une mesure de mitigation Sophos clairement désignée. Plus une IA tente d'échapper à la détection en recourant à des techniques de pointe, plus elle se heurte à des mesures de mitigation Sophos spécifiques.

Une mesure de mitigation qui n'est pas activée n'en est pas une réellement

Sophos Endpoint intègre plus de 60 contrôles de mitigation d’exploits identifiés, activés par défaut sur chaque endpoint protégé, sans paramétrage par application, listes d'exclusion ni périodes d'audit. Ce n'est pas ainsi que la plupart des concurrents les proposent. 

La protection contre les exploits de Microsoft est configurable par application, les mesures de mitigation les plus agressives étant généralement limitées à une application spécifique. La plupart des produits EDR tiers sont conçus principalement pour la détection et la réponse, et non pour la prévention : ils intègrent un petit ensemble de mesures de mitigation au niveau de la mémoire (souvent en activant de force celles existantes de Microsoft telles que DEP, ASLR et SEHOP), et les mesures de mitigation Windows les plus puissantes ne s’appliquent que lorsque le développeur de l’application a choisi de les activer. 

Le résultat, dans l'ensemble du secteur, est que la plupart des systèmes endpoint des entreprises ont une certaine capacité à être mieux protégés et que la réalité est de fonctionner avec la plupart des protections désactivées.

C’est la compatibilité qui rend le fonctionnement par défaut durable. Lorsqu'une mesure de mitigation Sophos se déclenche occasionnellement sur du code légitime, nos équipes Sophos X-Ops peuvent publier une empreinte numérique qui permet au comportement légitime spécifique de contourner la mesure de mitigation tout en laissant cette dernière active. 

L’action dénommée ‘carve-out’ est limitée à un seul chemin de code, à un seul module ou (rarement) à une seule application. Tout autre comportement, notamment tout comportement malveillant au cours du même processus, continue d'être évalué. Le correctif se diffuse sans mise à jour du produit, souvent avant même que le client n'ait ouvert une demande de support.

Voici un exemple de résultat concret : l’installateur de CPU-Z infecté par un cheval de Troie

En avril 2026, des attaquants ont compromis une API backend sur cpuid.com pendant six heures et ont redirigé les téléchargements de CPU-Z vers un programme d'installation contaminé par un cheval de Troie : le véritable exécutable signé était associé à un fichier CRYPTBASE.dll malveillant. 

Lorsque les utilisateurs l'exécutaient, l'ordre de recherche des DLL de Windows intégrait la DLL malveillante de manière transitive via ADVAPI32.dll, où elle s'exécutait dans un processus signé et approuvé, lançant une chaîne de type unpacking in-memory à plusieurs étapes se terminant par un cheval de Troie d'accès à distance (RAT) avec des outils cachés de contrôle de bureau et de vol d'identifiants. Aucun artefact disque observé après la DLL initiale.

Aucune vulnérabilité logicielle n'a été exploitée. Les composants légitimes se sont comportés comme prévu. Ce qui a été utilisé comme arme, c'est un fichier binaire de confiance ainsi qu'une DLL contrôlée par l'attaquant dans le bon répertoire. 

C’est pourquoi Sophos considère l’exploitation des vulnérabilités et l’utilisation abusive des fonctionnalités légitimes comme un seul et même problème. Les trous d’eau (watering holes), les compromissions de la supply chain, le phishing et les identifiants volés contournent tous l'étape d'exploitation, puis convergent vers les mêmes primitives une fois le malware en cours d'exécution. 

Les faiblesses d'accès initiales qui les sous-tendent (une API mal configurée, une interface d'administration exposée, des identifiants divulgués) constituent elles-mêmes une catégorie de vulnérabilités que l'IA peut détecter à grande échelle. C’est la convergence au niveau de la couche primitive qui rend la défense durable.

Aucune CVE utilisée. Plus de 150 systèmes ont été touchés. La couverture de Microsoft Defender était apparemment confuse un temps avant de se rattraper quelques jours plus tard. Ces systèmes sont tombés dans le piège.

L'attaquant a conçu la DLL pour contourner l'EDR, notamment en utilisant un proxy NTDLL via un assembly .NET pour contourner les hooks utilisateur. Ils se sont adaptés aux contrôles des systèmes endpoint Windows. Ils n'ont pas adapté leurs systèmes pour contrer Sophos, et la plupart des attaquants ne le feront pas. 

L'itération sur les signatures entraîne une recompilation. L'itération en fonction des règles comportementales pourrait nécessiter un ajustement du timing. L'itération ciblant une mesure de mitigation au niveau de la primitive nécessite de concevoir une chaîne de staging qui n'utilise pas la primitive : des semaines de travail, hors de portée de la plupart des acteurs. Sophos ne vous rend pas infranchissable. Sophos vous place en dehors de la population cible.

Sur un système endpoint Sophos, la détection comportementale (Evade_28j) a bloqué la menace avant le staging. Mais considérons le cas contraire : supprimons toutes les couches de détection et ne conservons que la protection dynamique contre le shellcode, disponible depuis 2018. 

Lorsque la DLL a alloué de la mémoire exécutable pour la deuxième étape (stage 2), le mécanisme de mitigation se serait déclenché, car l'appelant (caller) de VirtualAlloc était un code s'exécutant dans une mémoire anonyme et allouée dynamiquement : l'empreinte universelle d'un stager. Aucun échantillon, signature, IoC, recherche dans le Cloud ou mise à jour de règle. Une mesure de mitigation architecturale de 2018 permet de contrer une attaque prévue pour 2026 dès la deuxième étape (stage 2). 

Cette même propriété lui permet de fonctionner là où la connectivité au Cloud est intermittente ou inexistante : réseaux industriels, dispositifs médicaux segmentés, systèmes classifiés, navires en mer. Les connexions peuvent être interrompues et les chaînes de détection présentent une latence. Une solution architecturale qui ne dépend d'aucun des deux est le plancher qui tient bon lorsque tout ce qui se trouve au-dessus est dégradé.

La même empreinte digitale est déclenchée, que le chargeur ait été généré manuellement par un affilié en 2015 ou généré par un modèle en 2027. C’est le pari qu’a fait Sophos : cibler les primitives, et non les provenances.

Des questions qui méritent d'être posées

L'ère de l'IA va inciter tous les éditeurs à se déclarer prêts pour l'IA. Les défenses qui tiennent bon sont architecturales, et non algorithmiques. Lors de l'évaluation d'un éditeur de solutions de sécurité endpoint, les questions qui importent sont d'ordre pratique :

• Combien de mesures de mitigation des exploits sont activées par défaut sur chaque processus aujourd'hui, sans configuration ?
• Depuis combien de temps ces mesures de mitigation sont-elles déployées à grande échelle, et quel est leur bilan en matière de compatibilité ?
• La couche de mitigation couvre-t-elle les comportements post-exploitation (vol d'identifiants, élévation de privilèges, persistance, envoi de charge virale à base de ransomware), ou seulement l'exploitation initiale ?
• Lorsqu'un problème de compatibilité survient, la solution est-elle chirurgicale et précise ou nécessite-t-elle un affaiblissement de la protection à l'échelle du système ?

Pour conclure

Nous ne prétendons pas que Sophos soit impénétrable. Nous affirmons que Sophos Endpoint rend l'exploitation d'une vulnérabilité beaucoup plus difficile, et c'est dans cette zone de friction que les défenseurs prennent l'avantage. 

L'IA va profondément changer la façon dont les attaquants découvrent les vulnérabilités. Cela ne changera pas beaucoup ce qu'ils pourront faire une fois qu'ils en auront une. Cette asymétrie explique pourquoi Sophos Endpoint occupe une position unique face à l'évolution constante des menaces.

L'IA détecte les bugs. Sophos évolue là où la découverte se transforme en exploitation. Voilà le mur.  

Vous pouvez en savoir plus dans cet article complémentaire : AI just became the world's most dangerous exploit writer. Here's why Sophos Endpoint is built to stop it.” 

Pour en savoir plus, rendez-vous sur Sophos.com/ Endpoint.

Billet inspiré de AI finds the vulnerabilities, but exploiting them is a different problem, sur le Blog Sophos.