Bypassable ne veut pas dire inutile : comprendre la profondeur des contrôles Windows

Le problème du raisonnement “bypassable donc inutile”

Dans beaucoup de discussions sécurité offensive, on entend régulièrement les mêmes phrases.

• “SmartScreen se contourne.”
• “AMSI se patch.”
• “Les hooks EDR se bypassent.”
• “AppLocker n’est pas suffisant.”
• “Defender peut être évadé.”

Tout cela peut être vrai. Mais c’est aussi une manière assez paresseuse de regarder les contrôles de sécurité.

Un mécanisme de protection n’a pas besoin d’être inviolable pour être utile. Même lorsqu’il peut être contourné, il peut compliquer l’attaque et obliger l’adversaire à revoir sa méthode, à générer davantage de signaux détectables, à obtenir des privilèges plus élevés, ou à s’attaquer à des couches plus profondes de Windows.

Bref, il peut transformer une attaque simple en attaque coûteuse, risquée et détectable. Ce qui, en défense, est déjà une très bonne nouvelle.

Le vrai sujet : le coût d’attaque

Un contrôle de sécurité ne se juge pas uniquement sur l’existence théorique d’un bypass. Sinon, il faudrait déclarer inutiles à peu près toutes les couches de défense modernes.

La bonne question est plus opérationnelle :

Quel niveau de privilège est nécessaire ?
À quel moment le contrôle intervient-il ?
Est-ce visible ?
Est-ce reproductible à grande échelle ?
Est-ce stable sur plusieurs versions de Windows ?
Est-ce compatible avec un environnement réellement surveillé ?

Entre modifier un fichier avant exécution et charger un driver kernel pour neutraliser une protection, il y a un monde. Ce monde, c’est le coût d’attaque.

La kill chain des contrôles de sécurité Windows

On peut voir les protections Windows et EDR comme une pile de couches. En haut, on trouve ce qui est le plus proche de l’utilisateur : fichiers, scripts, processus, comportements visibles. En descendant, on se rapproche progressivement des couches plus profondes du système : noyau, mécanismes d’isolation, virtualisation, puis matériel.

Ce tableau n’a pas vocation à expliquer comment contourner ces protections. Il sert avant tout de grille de lecture défensive. Il permet de comprendre que les mécanismes de sécurité n’agissent pas tous au même niveau, n’observent pas les mêmes signaux et n’imposent pas le même degré de difficulté à un attaquant.

Vue simplifiée de la pile

Utilisateur / Pré-exécution
  ├─ SmartScreen
  ├─ Microsoft Defender Static
  └─ AppLocker

Runtime
  ├─ AMSI
  ├─ ETW
  ├─ ASR Rules
  └─ EDR Hooks

Kernel
  ├─ WDAC
  ├─ Sysmon Driver
  ├─ EDR Callbacks
  └─ PPL / LSASS

Virtualisation / Matériel
  └─ Credential Guard

SmartScreen : la première friction

SmartScreen intervient avant l’exécution. Son rôle est de protéger l’utilisateur contre des fichiers inconnus, peu réputés ou issus d’une origine non fiable.

Il s’appuie notamment sur la réputation du fichier, de l’éditeur, de l’URL et sur le contexte de provenance. Dans Windows, ce contexte est souvent matérialisé par le Mark of the Web, ou MOTW.

SmartScreen est une excellente couche de friction initiale. Mais ce n’est pas une frontière infranchissable. Son efficacité dépend fortement du contexte de distribution, de la réputation et de la conservation des métadonnées de provenance.

Defender Static : utile, mais pas suffisant

L’analyse statique de Microsoft Defender inspecte les fichiers sur disque. Elle repose sur des signatures, des heuristiques, des modèles de détection et des indicateurs connus.

Cette couche reste indispensable. Mais elle est naturellement exposée à un problème classique : l’apparence d’un fichier peut changer sans que son intention malveillante change réellement.

Obfuscation, empaquetage, chiffrement ou modification de chaînes peuvent suffire à réduire l’efficacité d’une détection purement statique.

Le scan statique est une porte d’entrée défensive, pas une garantie absolue.

AMSI : voir le contenu au runtime

AMSI, ou Antimalware Scan Interface, permet aux solutions de sécurité d’analyser du contenu au moment où il est exécuté. C’est un point clé pour PowerShell, .NET, les scripts et tous les cas où le contenu réellement dangereux n’est visible qu’après une étape de désobfuscation ou de génération dynamique.

La force d’AMSI, c’est qu’il ne se limite pas à l’analyse d’un fichier posé sur disque. Il permet de déplacer une partie de la détection au moment de l’exécution, là où le contenu réel apparaît et devient effectivement utilisable par le code.

Son contournement demande généralement plus d’effort qu’une simple retouche du fichier sur disque. Cela dit, AMSI reste dans une zone où l’attaquant peut parfois intervenir depuis le contexte même du processus, sans forcément devoir descendre vers des couches plus profondes du système.

AppLocker : bon contrôle, mauvaises règles fréquentes

AppLocker permet de définir quelles applications, scripts ou binaires peuvent être exécutés. Il peut s’appuyer sur des chemins, des éditeurs, des hashes ou des types de fichiers.

Le principe d’AppLocker n’est pas en cause. Sa faiblesse vient le plus souvent de la manière dont il est configuré. Une règle trop large, ou qui autorise l’exécution depuis des répertoires où l’utilisateur peut écrire, peut fortement limiter son efficacité.

WDAC : changer de niveau

WDAC, pour Windows Defender Application Control, joue dans une autre catégorie.

Là où AppLocker applique une politique plus exposée à l’espace utilisateur, WDAC s’appuie sur Code Integrity et sur une application plus basse dans la pile Windows.

Une politique WDAC bien conçue peut empêcher l’exécution de code non approuvé, réduire fortement les possibilités de chargement de composants non maîtrisés, et imposer à l’attaquant une contrainte beaucoup plus forte.

C’est typiquement le genre de contrôle qui force à changer de terrain. On ne parle plus seulement d’obfuscation ou de chemin d’exécution alternatif, mais de politique d’intégrité du code.

ASR Rules : bloquer les comportements attendus de l’attaque

Les règles ASR, pour Attack Surface Reduction, sont intéressantes parce qu’elles ne se limitent pas à dire si un fichier est bon ou mauvais.

Elles ciblent des comportements typiquement associés aux attaques : abus d’Office, création de processus enfants, exécution depuis certains contextes, accès à des secrets, ou usage de patterns courants de post-exploitation.

Leur intérêt est très concret : elles cassent des chaînes d’attaque entières.

Une bonne règle ASR ne bloque pas seulement un outil. Elle bloque une manière de travailler.

Sysmon et ETW : la valeur de la télémétrie

Tous les contrôles ne sont pas faits pour bloquer. Certains sont faits pour voir.

Sysmon et ETW jouent un rôle fondamental dans la visibilité. Sysmon permet de collecter des événements détaillés sur les processus, les connexions réseau, les chargements d’images, certaines modifications système et d’autres comportements utiles à l’investigation.

ETW, de son côté, est un mécanisme central de télémétrie Windows. De nombreux composants système, outils de sécurité et EDR s’appuient dessus.

Un attaquant peut parfois chercher à réduire cette visibilité. Mais neutraliser proprement une télémétrie profonde, sans générer d’autres signaux suspects, devient beaucoup plus délicat.

EDR hooks et callbacks kernel : deux mondes différents

Beaucoup d’EDR utilisent des hooks en user-mode, notamment autour de bibliothèques comme ntdll.dll. Ces hooks permettent d’observer certains comportements sensibles : allocations mémoire suspectes, injections, créations de threads, accès à des processus sensibles, et autres opérations typiques de post-exploitation.

Mais le user-mode reste un terrain où le processus a une certaine capacité de manipulation. Cela explique pourquoi certains contournements de hooks user-mode sont relativement peu coûteux pour un attaquant déjà en exécution.

Les callbacks kernel, eux, sont d’une autre nature. Ils permettent à l’EDR d’observer des événements à un niveau beaucoup plus bas : création de processus, chargement d’image, accès à des objets sensibles, opérations registre ou fichiers.

Les neutraliser demande généralement des privilèges beaucoup plus élevés, souvent un driver ou une compromission kernel.

Contourner un hook user-mode et neutraliser une visibilité kernel ne relèvent pas du même niveau d’attaque.

PPL et LSASS : protéger les secrets

LSASS est une cible évidente, car il manipule des éléments liés à l’authentification : tickets, secrets, sessions et informations d’identification selon les configurations.

PPL, pour Protected Process Light, permet de renforcer la protection de LSASS en limitant les accès mémoire depuis des processus non autorisés.

Cela ne rend pas toute attaque impossible, mais change fortement le niveau requis. Là où certaines approches historiques reposaient sur un accès administrateur local, PPL force souvent l’attaquant à chercher un niveau plus profond, typiquement côté kernel.

Credential Guard : l’isolation comme changement de paradigme

Credential Guard va encore plus loin. Il s’appuie sur Virtualization-Based Security, ou VBS, et sur le Virtual Secure Mode, ou VSM, pour isoler certains secrets d’authentification.

L’idée est simple : ne pas laisser tous les secrets accessibles dans le même monde d’exécution que le système d’exploitation principal.

C’est un changement de paradigme. On ne protège plus seulement un processus. On isole des secrets dans un environnement protégé par virtualisation.

Pour l’attaquant, le niveau de difficulté change radicalement. Il ne s’agit plus seulement de contourner une politique user-mode ou de manipuler un processus. Il faut s’attaquer à une frontière beaucoup plus basse : hyperviseur, configuration de boot, firmware, matériel ou vulnérabilité très spécialisée.

Ce que cette kill chain doit changer dans une stratégie défensive

Cette grille de lecture permet d’éviter deux erreurs fréquentes.

Erreur n°1 : croire qu’un contrôle contournable est inutile

C’est faux. Un contrôle peut être contournable et rester extrêmement utile s’il augmente le coût, le bruit ou le niveau de privilège nécessaire.

Erreur n°2 : croire qu’un seul contrôle fort suffit

C’est faux aussi. Même un contrôle robuste peut être affaibli par une mauvaise configuration, une exception trop large, un parc hétérogène ou une dette opérationnelle.

La bonne approche est l’empilement cohérent.

SmartScreen
+ Defender
+ AMSI
+ ASR
+ WDAC
+ Sysmon / EDR
+ PPL
+ Credential Guard

L’objectif n’est pas de rendre l’attaque théoriquement impossible. L’objectif est de rendre l’attaque coûteuse, instable, visible et difficile à industrialiser.

Checklist défensive

Une approche pragmatique consiste à vérifier les points suivants :

• SmartScreen est-il activé et réellement appliqué aux fichiers issus d’Internet ?
• Microsoft Defender est-il actif, à jour et configuré au-delà du strict minimum ?
• AMSI est-il surveillé, notamment pour PowerShell et les charges .NET ?
• AppLocker ou WDAC sont-ils utilisés avec des règles non permissives ?
• Les chemins inscriptibles par les utilisateurs sont-ils exclus des règles d’autorisation ?
• Les règles ASR pertinentes sont-elles activées en mode blocage ?
• Sysmon ou une télémétrie équivalente est-il déployé avec une configuration utile ?
• Les événements ETW importants sont-ils collectés ou exploités par l’EDR ?
• LSASS est-il protégé par PPL ?
• Credential Guard est-il activé sur les postes compatibles ?

Conclusion

“Bypassable” ne veut pas dire “inutile”.

C’est probablement l’un des points les plus importants à rappeler lorsqu’on parle de sécurité Windows. La valeur d’un contrôle ne réside pas uniquement dans sa capacité à bloquer toutes les attaques, mais dans sa capacité à modifier l’économie de l’attaque.

Un bon contrôle force l’attaquant à faire plus d’efforts. Un très bon contrôle le force à changer de niveau. Une bonne architecture défensive combine les deux.

Le but n’est pas d’avoir une couche magique. Le but est d’empiler des contrôles qui forcent l’attaquant à descendre toujours plus bas dans la pile, jusqu’à rendre l’attaque trop chère, trop bruyante ou trop risquée.

C’est exactement là que se trouve la vraie valeur d’une défense Windows bien construite.