Bypass d'AMSI et d'ETW pour la Recherche Defensive: Ce que les Blue Teams Doivent Savoir

Un operateur lance Invoke-Mimikatz dans PowerShell 5.1 sans la moindre obfuscation et il ne se passe rien. Defender ne hurle pas, le SOC ne recoit aucune alerte, et le ticket reste silencieux alors que la memoire de lsass a deja ete lue. Ce n'est pas de la magie: c'est un patch d'une ligne dans amsi.dll qui annule AmsiScanBuffer en deux instructions. En 2026, AMSI et ETW restent le squelette de la telemetrie Windows, et restent neutralises par des scripts de quatre lignes qui circulent sur GitHub depuis 2016. Ce texte demonte, couche par couche, pourquoi ces bypass marchent encore, comment les reproduire proprement en laboratoire et ce qui change vraiment la donne cote bleu sans acheter un EDR de plus.

Ce qu'est vraiment AMSI et pourquoi il vit dans le processus de la victime

AMSI (Antimalware Scan Interface) est un pont, pas un mur. PowerShell, VBScript, JScript, WMI et meme les macros Office appellent AmsiScanBuffer pour demander a l'antivirus enregistre si le contenu en memoire est malveillant. Le detail decisif est que cet appel a lieu dans le processus cible lui-meme, avec ses droits et dans son espace d'adressage. Si l'attaquant execute deja du code dans powershell.exe, il est du meme cote de la frontiere de confiance que la routine de scan. Il peut ecrire dans la zone .text d'amsi.dll, remplacer le prologue d'AmsiScanBuffer par mov eax, 0x80070057; ret (E_INVALIDARG, lu comme "propre") et eteindre la lumiere. Matt Graeber a publie la variante classique par reflection en 2016, et les variantes via hardware breakpoints, patch d'AmsiOpenSession et corruption d'amsiContext continuent d'apparaitre.

La longevite est structurelle, pas negligente. Tant que l'instrumentation vit en user-mode et dans le meme processus, elle est par definition manipulable par quiconque execute du code dans ce processus. Toute personne qui travaille avec Evasion EDR pour la Recherche: Direct Syscalls Expliques sans Romance reconnait le motif: l'instrumentation user-mode est toujours du soft power. Microsoft durcit la surface (signatures des octets de patch connus, integrite AMSI plus stricte dans PowerShell 7), mais le principe demeure: le defenseur place son capteur dans le salon de l'attaquant.

ETW comme couche plus profonde avec le meme talon d'Achille

ETW (Event Tracing for Windows) se situe plus en profondeur mais partage la faiblesse. Des providers comme Microsoft-Windows-Threat-Intelligence emettent des evenements sur NtAllocateVirtualMemory, l'ouverture de handles vers lsass et l'injection de threads distants, alimentant la quasi-totalite des EDR commerciaux. Le bypass canonique patche EtwEventWrite dans ntdll.dll avec un simple xor eax,eax; ret, et voila: le provider reste enregistre mais rien ne sort du processus. Les variantes modernes touchent EtwpEventWriteFull, suppriment le provider de TRACE_ENABLE_INFO ou abaissent les niveaux de trace par thread. Comme ces bypass sont locaux et silencieux, le hunting fonde sur l'absence d'evenements attendus devient plus precieux que le hunting par signature.

Quiconque construit deja un Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection sait que les regles de "silence anormal" sont penibles a calibrer, mais elles attrapent justement ce que la regle positive rate. La valeur d'ETW-TI est qu'il nait dans le kernel; le bypass, lui, se produit en user-mode avant que l'evenement ne quitte le processus. Rapproche la collecte du kernel ou sors-la du host et le patch user-mode perd son effet.

Le patch AMSI classique etape par etape

Conceptuellement le bypass par reflection fonctionne ainsi: on obtient le champ amsiInitFailed via [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils') et on le met a true, et PowerShell saute le scan. Le patch memoire plus robuste resout l'adresse d'AmsiScanBuffer via GetProcAddress(LoadLibrary("amsi.dll"), "AmsiScanBuffer"), appelle VirtualProtect avec PAGE_EXECUTE_READWRITE, ecrit les octets du stub de retour et restaure la protection. La variante a hardware breakpoints est plus elegante: elle ne touche pas a .text, mais pose des registres de debug (Dr0-Dr7) sur AmsiScanBuffer via SetThreadContext et falsifie la valeur de retour dans un gestionnaire d'exceptions. Comme elle ne modifie aucun code, elle passe les controles d'integrite faibles qui ne cherchent que des octets patches.

Important pour l'analyse defensive: le patch par reflection laisse une trace tres caracteristique dans ScriptBlockLogging (Event ID 4104) parce que les chaines AmsiUtils et amsiInitFailed sont loggees avant qu'AMSI ne soit desactive. Le patch memoire, lui, est visible via NtProtectVirtualMemory sur amsi.dll. Chaque technique echange la furtivite contre la complexite, et aucune n'est invisible si on regarde au bon endroit.

Montage de laboratoire pour voir ce que le bleu capture vraiment

Cote offensif ethique, reproduire ces bypass en laboratoire est obligatoire pour comprendre ce que la blue team voit reellement. Setup minimal: Windows 11 23H2 avec Defender actif, Sysmon 15 avec la config d'Olaf Hartong, et Elastic Agent qui pousse vers un cluster de test. Execute le patch AMSI classique par reflection, puis la variante a hardware breakpoints, et compare ce que Defender et Sysmon enregistrent dans chaque cas. Surprise frequente: l'Event ID 4104 de PowerShell capture toujours le bloc de script malveillant parce que ScriptBlockLogging est independant d'AMSI. Ce type d'exercice s'integre tres bien dans un cycle de Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue et apprend plus qu'un whitepaper.

L'isolement fait partie de l'exercice: pas de domain join entre laboratoire et production, pas d'egress internet qui pourrait exfiltrer les payloads testes, et des snapshots avant chaque run pour que la baseline reste reproductible. Mesure toujours d'abord l'etat nul (ce qui est logge sans bypass), puis l'etat avec bypass. La difference est ta chance de detection.

Vrai durcissement: ce qui coute vraiment a l'attaquant

Le vrai durcissement commence en acceptant que le bypass en user-mode coute peu. Active PowerShell Constrained Language Mode via WDAC pour les utilisateurs standard, mets ScriptBlockLogging et Module Logging avec un forwarding hors machine (le log local, l'attaquant l'efface), et impose PowerShell 7+ avec integration AMSI verifiee. Active Protected Process Light pour Defender, mets LSA Protection (RunAsPPL) en place et envisage Credential Guard pour augmenter le cout de quiconque atteint lsass. Cote ETW, ce qui change la donne c'est de sortir la detection du host: Sysmon plus WEF vers un collecteur dedie, et la ou possible des kernel callbacks via le driver de l'EDR, que l'attaquant ne fait tomber qu'avec du BYOVD.

Quiconque applique deja Durcissement de Windows 11 pour Postes de Travail a Haut Risque a deja fait une bonne partie du chemin. La priorisation compte: WDAC/Constrained Language Mode et ScriptBlockLogging forwarde rendent plus par heure investie qu'une licence EDR de plus. Le but n'est pas de rendre le bypass impossible (impossible, dans le meme processus) mais de le rendre cher, bruyant et tracable.

Detection: motifs concrets et IOCs

La detection des bypass suit des motifs clairs et peu couteux a implementer. Cherche NtProtectVirtualMemory qui modifie les permissions d'amsi.dll ou ntdll.dll dans des processus qui ne sont pas des installateurs (Sysmon Event ID 10 plus filtres d'image cible). Regarde le PowerShell qui charge System.Management.Automation.AmsiUtils par reflection (Event 4104 contenant "amsiInitFailed" est presque un IOC litteral). Surveille l'ecart entre les evenements attendus d'ETW-TI et ce qui arrive au SIEM par host: si un endpoint emet soudain 70 pour cent d'evenements en moins sans changement de charge, quelque chose a patche EtwEventWrite.

Cette logique de baseline par host se relie a Hunting des Living-off-the-Land Binaries sous Windows avec KQL et a Persistance Windows : 10 Techniques Documentees et leurs Contre-mesures, ou le silence est aussi un signal. Ajoute des regles comportementales: un processus PowerShell qui charge amsi.dll puis alloue peu apres une region RWX est plus suspect que n'importe quel indicateur isole.

Erreurs frequentes des deux cotes

Cote bleu, l'erreur la plus frequente est de faire confiance a AMSI 4104 sans securiser le forwarding: si l'attaquant peut effacer les logs locaux, ton IOC disparait. Une deuxieme est de ne chercher que les signatures d'octets du patch classique et de rater completement la variante a hardware breakpoints. Cote offensif (laboratoire), l'erreur la plus frequente est de tester des bypass sur des actifs de production ou de publier des PoC sans contexte defensif. Une troisieme, souvent oubliee: beaucoup supposent qu'un bypass AMSI desactive aussi ETW; ce n'est pas le cas, ce sont des mecanismes separes, a contourner separement et a detecter separement.

Checklist pour blue teams

Court et actionnable: (1) active ScriptBlockLogging et Module Logging et forwarde hors host via WEF. (2) impose Constrained Language Mode via WDAC pour les utilisateurs standard. (3) active RunAsPPL et Credential Guard. (4) Sysmon 15 avec config curee plus Event ID 10 sur amsi.dll/ntdll.dll. (5) baseline par endpoint du volume d'evenements ETW-TI avec alerte en cas de chute. (6) recherche 4104 de "amsiInitFailed"/"AmsiUtils". (7) documente la detection avec la regle Sigma, pas avec le screenshot de mimikatz. (8) valide chaque controle dans un cycle purple team contre de vrais bypass, pas sur le papier.

FAQ: Un EDR moderne suffit-il contre le bypass AMSI/ETW?

Non, pas seul. Un bon EDR complique et detecte les bypass via kernel callbacks et analyse comportementale, mais une fois l'attaquant dans le processus, il peut manipuler les capteurs user-mode, et avec BYOVD attaquer aussi des composants kernel. La valeur est dans la defense en profondeur: EDR plus ScriptBlockLogging forwarde plus WDAC plus telemetrie hors host. Aucun produit seul ne comble l'ecart parce que l'ecart est architectural, pas lie au produit.

FAQ: Est-il legal de rechercher et publier ces bypass?

Les reproduire dans ton propre laboratoire isole est de la recherche defensive legitime. Publier exige du soin ethique. Un bypass AMSI/ETW n'est pas un 0day, mais publier un PoC sans angle defensif aide surtout ceux qui n'en ont pas besoin. La norme saine: reproduire en lab isole, documenter l'IOC defensif avant l'exploit, et quand tu publies, ouvrir avec la regle Sigma. Si ton travail touche un client, verrouille le perimetre par ecrit; s'il touche ta propre infra, pratique OPSEC pour Chercheurs en Securite: Modele de Menace Personnel.

Conclusion

Takeaway pratique: pars du principe qu'AMSI et ETW seront bypassed sur l'hote compromis, et investis dans le ScriptBlockLogging forwarde, une config Sysmon curee et un baseline de volume d'evenements par endpoint. Ces trois controles a eux seuls attrapent la majorite des bypass publics vus en 2025-2026, sans dependre d'un vendor particulier. Le fil conducteur est toujours le meme: le defenseur qui suppose que son capteur de host peut etre manipule, et qui place donc la detection hors host et comportementale, bat un bypass qui parie sur le confort du defenseur.