Signature SMB désactivée : risque NTLM relay et correctifs

Qu’est-ce qu’une signature SMB désactivée ?

Une signature SMB désactivée signifie généralement que les clients Windows, les serveurs Windows, ou les deux, n’exigent pas la signature du trafic SMB. Sur les systèmes Windows modernes, le contrôle effectif est le paramètre RequireSecuritySignature côté client SMB et côté serveur SMB.

La documentation Microsoft est précise sur le rôle de cette fonctionnalité. SMB signing ajoute une signature à chaque message SMB en utilisant la clé de session et la suite cryptographique. Si un attaquant modifie le message pendant le transport, la signature ne correspond plus. Microsoft indique aussi que cette protection aide contre les attaques de relay et de spoofing.

Le problème de sécurité n’est donc pas seulement du « partage de fichiers non signé ». Quand la signature SMB n’est pas requise sur des chemins où elle devrait l’être, l’environnement devient plus exposé aux interceptions adversary-in-the-middle et aux opportunités de NTLM relay.

Le périmètre de cet article est SMB 2.x et 3.x dans les environnements Windows Active Directory, avec un focus sur l’exposition au relay, la vérification et le durcissement réaliste. La signature SMB ne règle pas toute la surface NTLM relay à elle seule. En revanche, ne pas l’exiger retire une protection protocolaire que Microsoft documente explicitement contre la falsification et le relay sur SMB.

Comment fonctionne la signature SMB

Microsoft décrit SMB signing comme une fonctionnalité de sécurité qui utilise la clé de session et la suite cryptographique pour ajouter une signature au message SMB. Cette signature contient un hash du message complet dans l’en-tête SMB. Si le message est modifié en transit, la vérification échoue.

Pour SMB 2.x et 3.x, le point important est l’exigence de signature. L’ancien raisonnement SMB1 autour de EnableSecuritySignature ne suffit pas. Microsoft documente que, pour SMB 2.02 et versions ultérieures, EnableSecuritySignature est ignoré et que la signature dépend du fait qu’elle soit requise.

Cette nuance évite une erreur fréquente : croire que SMB signing est activé parce qu’un vieux paramètre existe quelque part, alors que l’exigence effective reste désactivée.

Quand la signature SMB est réellement utilisée

Le comportement opérationnel peut se résumer ainsi :

la signature est utilisée si le client SMB l’exige
la signature est utilisée si le serveur SMB l’exige
la signature n’est pas utilisée uniquement si le client et le serveur ne l’exigent pas

L’état vulnérable n’est donc pas limité à un seul serveur de fichiers mal configuré. Si aucun côté ne refuse les sessions non signées, la connexion peut continuer sans signature.

Pourquoi c’est important dans Active Directory

SMB n’est pas seulement un protocole de partage de fichiers. Les environnements Active Directory l’utilisent pour SYSVOL, NETLOGON, les partages administratifs et des flux opérationnels entre postes, serveurs et contrôleurs de domaine.

Microsoft rappelle que les contrôleurs de domaine exigent historiquement SMB signing pour certains accès sensibles, notamment SYSVOL et NETLOGON. Ce choix existe parce que du trafic SMB non signé dans l’infrastructure d’identité est beaucoup plus simple à modifier ou à relayer.

Désactivée ou non requise : la nuance utile

Dans les audits, les expressions « signature SMB désactivée » et « signature SMB non requise » sont souvent utilisées ensemble. Techniquement, la nuance compte.

Désactivée signifie souvent que RequireSecuritySignature est explicitement à False côté client, côté serveur, ou les deux.
Non requise signifie que l’hôte peut signer si l’autre côté l’impose, mais qu’il peut aussi accepter une session non signée si personne ne l’exige.

Du point de vue du risque, les deux états peuvent produire le même résultat : des sessions SMB autorisées sans signature.

La bonne question n’est donc pas de savoir si une case semble « activée ». La bonne question est de savoir si le client ou le serveur refuse réellement le SMB non signé.

Pourquoi ce risque reste important

Microsoft continue de présenter SMB signing comme une défense contre la falsification, le spoofing et le relay. Beaucoup de chemins de relay dépendent encore d’un service qui accepte une authentification sur un canal insuffisamment protégé.

Le SMB non signé affaiblit le chemin protocolaire

Si un client et un serveur peuvent négocier une session non signée, un attaquant capable d’influencer le chemin réseau dispose de plus de marge pour interférer avec le trafic ou relayer l’authentification.

NTLM existe encore dans les environnements réels

Même dans les organisations qui poussent Kerberos, Microsoft documente encore le blocage NTLM sur SMB comme un durcissement distinct pour Windows 11 24H2 et Windows Server 2025. Cela montre que le problème legacy autour de NTLM reste opérationnel.

Les dépendances tierces fragilisent souvent la posture

La documentation Microsoft est directe : si un serveur SMB tiers ne prend pas correctement en charge la signature, certaines équipes désactivent SMB signing pour restaurer la compatibilité. Microsoft déconseille explicitement ce contournement, car il revient à accepter des accès invités ou non signés vers un partage distant.

Conditions qui rendent l’exposition exploitable

Une finding SMB_SIGNING_DISABLED devient réellement importante quand plusieurs conditions se superposent.

1. Aucun côté n’exige la signature sur un chemin sensible

Le cœur du problème est que le client SMB et le serveur SMB peuvent tous les deux poursuivre sans signature obligatoire.

2. NTLM reste disponible sur ce chemin

Microsoft recommande Kerberos plutôt que NTLMv2 et déconseille les accès SMB par adresse IP ou certains alias qui peuvent pousser l’authentification hors Kerberos. C’est important, parce que le couple SMB non signé et authentification NTLM est une combinaison classique qui facilite le relay.

3. L’attaquant peut influencer le trafic

Une attaque de relay n’est pas magique. L’attaquant doit pouvoir contraindre une authentification, se placer sur un chemin, ou obtenir un flux qu’il peut relayer.

4. Les partages ou hôtes cibles ont de la valeur

Relayer vers un partage sans intérêt n’a pas le même impact que relayer vers un serveur de management, un partage administratif ou un service sensible. C’est aussi pour cela qu’il faut revoir les comptes à privilèges avec Comptes Obsolètes et Sur-Privilégiés dans AD.

5. L’environnement contient encore des clients ou appliances legacy

Les NAS anciens, scanners, appliances ou workflows invités sont souvent la raison initiale pour laquelle la signature n’est pas exigée. Il faut les traiter comme des exceptions de conception, pas comme une excuse pour abaisser la baseline globale.

Chaîne d’attaque

Un chemin d’attaque pratique autour de SMB signing désactivé ressemble souvent à ceci.

Étape 1 - Identifier un chemin SMB non signé

L’attaquant trouve un couple client/serveur où aucun côté n’exige la signature.

Étape 2 - Contraindre ou intercepter une authentification

L’attaquant provoque une authentification SMB depuis une cible ou l’observe sur un chemin qu’il contrôle.

Étape 3 - Relayer la tentative d’authentification

Si les autres prérequis sont présents, l’authentification peut être relayée vers un service SMB ou un autre endpoint qui accepte cette identité.

Étape 4 - Utiliser immédiatement l’accès obtenu

Le relay est dangereux parce qu’il ne nécessite pas de casser le mot de passe. Si le relay réussit, l’attaquant agit avec les droits de la victime dans la fenêtre de session.

C’est pour cela que cette finding doit être lue avec Attaques NTLM Relay : Détection et Prévention. SMB signing désactivé n’est pas toute l’histoire, mais c’est un des facteurs les plus clairs qui rendent le relay SMB plus réaliste.

Détection

La détection a deux volets : détection de configuration et détection opérationnelle.

Détection de configuration

La vérification la plus directe consiste à contrôler si le client ou le serveur SMB exige réellement la signature.

Microsoft documente les commandes PowerShell suivantes :

Get-SmbClientConfiguration | FL RequireSecuritySignature
Get-SmbServerConfiguration | FL RequireSecuritySignature

Si la valeur retournée est False, la signature n’est pas requise sur ce côté.

Dans Group Policy, les paramètres pertinents sont sous :

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Microsoft network client: Digitally sign communications (always)
Microsoft network server: Digitally sign communications (always)

C’est le moyen le plus rapide de transformer une alerte vague en état vérifiable.

Auditer la compatibilité avant d’imposer

Sur les versions récentes, Microsoft documente des contrôles d’audit utiles :

Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

Les événements associés sont dans :

Microsoft-Windows-SMBClient/Audit, événements 31998 et 31999
Microsoft-Windows-SMBServer/Audit, événements 3021 et 3022

Ces signaux sont utiles avant de rendre la signature obligatoire partout, surtout s’il existe des dépendances tierces.

Détection opérationnelle

Si vous suspectez un abus réel, corrélez :

les hôtes où la signature n’est pas requise
les flux SMB fortement dépendants de NTLM
les signaux de relay couverts dans Supervision Sécurité AD : Événements Clés
les accès inattendus à des partages administratifs ou sensibles
les accès SMB par IP ou via des noms qui évitent Kerberos

Il n’existe pas un événement Windows unique qui dit « NTLM relay a réussi parce que SMB signing était désactivé ». Le bon modèle consiste à identifier le chemin non signé, puis à corréler l’authentification et l’accès autour de ce chemin.

Remédiation

La remédiation principale est simple : exiger SMB signing là où il doit l’être, puis réduire les comportements adjacents qui gardent le relay viable.

1. Exiger SMB signing côté client et serveur quand c’est possible

Microsoft documente les commandes suivantes :

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true

Au niveau politique, les contrôles sont :

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

Si vous contrôlez les clients Windows et les serveurs de fichiers Windows, c’est la baseline la plus claire.

2. Ne pas normaliser un contournement tiers

Microsoft déconseille de désactiver SMB signing comme contournement pour un serveur tiers. Si une appliance ne supporte pas la signature, documentez-la comme dette technique, isolez-la, et évitez d’abaisser la configuration de tout le parc.

3. Préférer Kerberos et éviter les chemins qui poussent vers NTLM

Microsoft recommande :

d’utiliser Kerberos plutôt que NTLMv2
d’éviter les accès aux partages par adresse IP
d’éviter certains CNAME pour SMB lorsqu’ils forcent un comportement NTLM

Ce sont des détails opérationnels importants. Ils réduisent la probabilité qu’un chemin SMB faible devienne un chemin NTLM relay pratique. La posture mot de passe reste aussi liée à cette surface, d’où l’intérêt de Sécurité des mots de passe Active Directory : erreurs critiques.

4. Utiliser les protections SMB récentes si la plateforme le permet

Microsoft fournit des defaults et options plus forts sur les versions actuelles :

Windows 11 24H2 Enterprise, Pro et Education exigent la signature SMB entrante et sortante
Windows Server 2025 exige la signature SMB sortante par défaut
Windows 11 24H2 et Windows Server 2025 ajoutent des contrôles d’audit SMB signing
Windows 11 24H2 et Windows Server 2025 ajoutent le blocage NTLM côté client SMB

Le durcissement ne se limite donc pas à un vieux paramètre. Sur les plateformes récentes, vous pouvez auditer et réduire NTLM plus proprement.

5. Revoir séparément l’accès invité et les dépendances legacy

Microsoft indique que rendre SMB signing obligatoire désactive aussi l’accès invité aux partages. Si un workflow métier dépend encore d’un accès invité, il doit être isolé et revu, pas absorbé dans la baseline normale.

6. Revoir la propagation des administrateurs locaux

Le SMB non signé est plus dangereux si les mêmes machines ont aussi des mots de passe admin locaux partagés. Dans le même périmètre, relisez Windows LAPS non déployé : pourquoi les mots de passe admin locaux partagés restent un risque.

7. Relier cette correction aux revues NTLM relay

Si SMB signing est désactivé, il faut aussi relire :

Le contrôle est plus fort quand il s’inscrit dans un programme de réduction du relay, pas quand il reste un simple champ de registre.

Validation après durcissement

Après changement de politique, validez l’état réel.

exécuter Get-SmbClientConfiguration et Get-SmbServerConfiguration pour confirmer RequireSecuritySignature = True
vérifier que les GPO effectives correspondent à la baseline cible
activer les événements d’audit avant l’application large si des dépendances tierces sont probables
identifier les systèmes qui ne supportent pas la signature avant de forcer la configuration
tester les anciens workflows invités ou non signés et décider s’ils doivent être retirés
rechercher les accès SMB par IP, les alias problématiques et les flux NTLM lourds
intégrer ce contrôle dans Audit de sécurité Active Directory : checklist pratique

Le succès n’est pas une capture d’écran GPO. Le succès est que les clients et serveurs refusent le SMB non signé sur les chemins où le relay aurait un impact.

Comment EtcSec détecte l’exposition liée

EtcSec peut modéliser ce risque directement parce que SMB_SIGNING_DISABLED est une finding de durcissement réseau concrète.

Les liens de catalogue les plus utiles sont :

SMB_SIGNING_DISABLED pour les systèmes qui acceptent encore le SMB non signé
NTLM_RELAY_OPPORTUNITY quand les prérequis du relay restent présents
les contrôles AD autour de la supervision, des comptes privilégiés et des chemins NTLM

C’est pourquoi ce sujet doit être relié à Attaques NTLM Relay : Détection et Prévention et à Audit de sécurité Active Directory : checklist pratique, pas seulement à une checklist de serveur de fichiers.

Contrôles associés

Si vous auditez la signature SMB désactivée, relisez aussi Attaques NTLM Relay : Détection et Prévention, Supervision Sécurité AD : Événements Clés, Audit de sécurité Active Directory : checklist pratique, Sécurité des mots de passe Active Directory : erreurs critiques, Windows LAPS non déployé : pourquoi les mots de passe admin locaux partagés restent un risque, Comptes Obsolètes et Sur-Privilégiés dans AD et Outils d’audit de sécurité Active Directory : quoi comparer avant de choisir. Ces articles couvrent les chemins de coercition, relay et supervision qui déterminent si le SMB non signé est une faiblesse isolée ou un vrai chemin d’attaque.