🛠️ CVE-2025-33073 – Le SMB client se tire une balle dans le pied (et vous avec)

📌 Contexte

En ce radieux Patch Tuesday du 10 juin 2025, Microsoft a discrètement corrigé une faille qualifiée d’élévation de privilèges dans le client SMB de Windows. Pas de quoi titrer dans les journaux grand public, mais dans les couloirs feutrés des DSI et des pentesters, ça bruisse.

La faille, référencée CVE-2025-33073, permet à un utilisateur standard d’un domaine Active Directory de devenir SYSTEM sur une machine Windows en jouant habilement avec les connexions SMB et Kerberos. Et ça, c’est beaucoup.

🧨 Détails techniques

• Composant affecté : Client SMB de Windows
• Type de faille : Élévation de privilèges (EoP)
• Score CVSS : 8.8 (Important)
• Pré-requis :
  • Avoir un compte authentifié dans le domaine
  • Pouvoir exécuter un script en local (ou sur un poste compromis)
  • Que le SMB Signing ne soit pas activé sur les serveurs visés

La vulnérabilité repose sur une mauvaise gestion des connexions SMB initiées depuis un contexte utilisateur. Si un script (PowerShell, batch, etc.) déclenche une connexion vers un serveur SMB malicieux, celui-ci peut détourner les jetons Kerberos pour effectuer une attaque de type « Kerberos relay ».

🎭 Scénario d’exploitation plausible

🎬 Mise en scène

Imaginons « Alice », une simple utilisatrice du domaine, avec un poste Windows 11 à jour — sauf ce patch-là.

1. Phase 1 – Préparation :
   • Un attaquant (« Bob ») possède un autre compte du domaine (ex. via phishing ou user de test négligé).
   • Il repère un poste Windows vulnérable (ex : via une GPO mal configurée, ou outil comme BloodHound).
2. Phase 2 – Lure SMB :
   • Il place un script PowerShell sur la machine d’Alice (ex : via login script mal sécurisé ou GPO).
   • Le script tente de se connecter à \\malicious-server\payload, un serveur SMB contrôlé par Bob.
3. Phase 3 – Kerberos Relay :
   • Le client SMB tente l’authentification Kerberos vers le faux serveur SMB.
   • Bob intercepte le ticket, et le relaye vers un vrai serveur SMB sur le réseau qui n’a pas SMB signing activé.
   • Il exécute une commande via psexec ou smbexec, et l’exécution se fait avec les droits SYSTEM du poste d’Alice.
4. Phase 4 – Post-Exploitation :
   • Il extrait les tokens, élève les privilèges, ou pivote vers d’autres cibles (serveurs, comptes admins, etc.).

🔐 Pourquoi cette faille est critique dans un environnement AD ?

Parce qu’Active Directory fait confiance aux machines, et si l’on compromet une machine (via SYSTEM), on peut :

• Injecter des tickets Kerberos (golden, silver)
• Modifier la configuration locale ou GPO
• Exfiltrer des jetons, hash NTLM, secrets LSASS

En somme : une machine compromise = un levier contre le domaine.

🧰 Comment se protéger ?

✅ Patch immédiat

• Appliquer le correctif KB associé au Patch Tuesday de juin 2025.

🔒 Activer SMB Signing

• Via GPO :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité

• Activer :
  • Microsoft network client: Digitally sign communications (always)
  • Microsoft network server: Digitally sign communications (always)

🔎 Bonus : détection & hunting

• Rechercher les connexions SMB vers des IPs internes inhabituelles.
• Activer la journalisation des événements Kerberos (4769, 4776) et SMB (5140).
• Utiliser Sysmon avec la règle NetworkConnect et PipeEvent.

🤔 Pourquoi ce genre de faille est sournois

Ce n’est pas une « faille zéro-click » hollywoodienne, mais une de celles qui se nichent dans les pratiques courantes : connexions internes non chiffrées, scripts de login bricolés, serveurs oubliés sans GPO… Ce genre de faille ne fait pas de bruit — jusqu’à ce qu’elle serve à pivoter.

🎯 TL;DR

Voir nos anciens posts sur le sujet :
« Active Directory : Ces flux internes qui partent en vrille (et comment les dompter) »
Trafic Active Directory : l’art de laisser la porte ouverte tout en pensant l’avoir fermée à triple tour

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com