SMB-Signierung deaktiviert: NTLM-Relay-Risiko beheben

SMB-Signierung deaktiviert: was bedeutet das?

SMB-Signierung deaktiviert bedeutet in der Praxis meist, dass Windows-Clients, Windows-Server oder beide Seiten signierten SMB-Verkehr nicht erzwingen. Auf modernen Windows-Systemen ist dafür vor allem RequireSecuritySignature auf SMB-Client- und SMB-Serverseite entscheidend.

Microsoft beschreibt den Zweck klar: SMB signing fügt SMB-Nachrichten mit dem Sitzungsschlüssel und der ausgehandelten Cipher Suite eine Signatur hinzu. Wird die Nachricht unterwegs verändert, passt die Signatur nicht mehr. Microsoft nennt die Funktion außerdem ausdrücklich als Schutz gegen Relay- und Spoofing-Angriffe.

Das Risiko ist daher nicht nur „unsignierte Dateifreigabe“. Wenn SMB-Signierung auf relevanten Pfaden nicht erforderlich ist, wird die Umgebung anfälliger für Adversary-in-the-Middle-Szenarien und NTLM-Relay-Möglichkeiten.

Der Fokus dieses Artikels liegt auf Windows SMB 2.x und 3.x in Active-Directory-Umgebungen. SMB-Signierung allein beseitigt nicht jede Relay-Möglichkeit. Aber wenn sie nicht erzwungen wird, fehlt eine von Microsoft dokumentierte Protokollschutzschicht gegen Manipulation und Relay auf SMB.

Wie SMB-Signierung funktioniert

SMB-Signierung verwendet laut Microsoft den Sitzungsschlüssel und die Cipher Suite, um SMB-Nachrichten zu signieren. Die Signatur enthält einen Hash der vollständigen SMB-Nachricht im Header. Wird die Nachricht während der Übertragung verändert, schlägt die Prüfung fehl.

Für SMB 2.x und 3.x ist wichtig, ob Signierung erforderlich ist. Alte SMB1-orientierte Einstellungen rund um EnableSecuritySignature sind dafür nicht ausreichend. Microsoft dokumentiert, dass EnableSecuritySignature ab SMB 2.02 ignoriert wird und das Verhalten durch die Anforderung gesteuert wird.

Diese Nuance verhindert einen typischen Auditfehler: Eine alte Einstellung ist irgendwo vorhanden, aber die effektive Anforderung bleibt trotzdem aus.

Wann Signierung tatsächlich verwendet wird

Das Verhalten lässt sich operativ so zusammenfassen:

Signierung wird verwendet, wenn der SMB-Client sie verlangt
Signierung wird verwendet, wenn der SMB-Server sie verlangt
Signierung wird nur dann nicht verwendet, wenn Client und Server sie nicht verlangen

Der verwundbare Zustand ist also breiter als ein einzelner schlecht konfigurierter Fileserver. Wenn keine Seite unsignierte Sitzungen ablehnt, kann die Verbindung ohne Signatur stattfinden.

Warum das in Active Directory wichtig ist

SMB ist nicht nur Dateifreigabe. Active Directory nutzt SMB für SYSVOL, NETLOGON, administrative Freigaben und zahlreiche operative Abläufe zwischen Clients, Servern und Domänencontrollern.

Microsoft weist darauf hin, dass Domänencontroller für sensible Pfade wie SYSVOL und NETLOGON SMB-Signierung verlangen. Der Grund ist nachvollziehbar: Unsigned SMB im Identitätskern ist leichter zu manipulieren oder zu relayern.

Deaktiviert oder nicht erforderlich

In Audits werden „deaktiviert“ und „nicht erforderlich“ oft vermischt. Technisch ist die Unterscheidung wichtig.

Deaktiviert bedeutet meist, dass RequireSecuritySignature auf Client, Server oder beiden Seiten auf False steht.
Nicht erforderlich bedeutet, dass der Host signieren kann, wenn die Gegenseite es verlangt, aber auch eine unsignierte Sitzung akzeptiert, wenn niemand Signierung erzwingt.

Aus Risikosicht können beide Zustände dasselbe Ergebnis erzeugen: SMB-Sitzungen laufen ohne Signatur.

Die relevante Frage lautet daher nicht, ob eine Oberfläche „enabled“ wirkt. Entscheidend ist, ob Client oder Server unsigniertes SMB tatsächlich ablehnen.

Warum dieses Risiko weiterhin zählt

Microsoft beschreibt SMB-Signierung weiterhin als Schutz gegen Manipulation, Spoofing und Relay. Viele Relay-Pfade werden erst dann realistisch, wenn ein Dienst eine Authentifizierung über einen schwach geschützten Kanal akzeptiert.

Unsigned SMB schwächt den Protokollpfad

Wenn Client und Server eine unsignierte Sitzung aushandeln können, hat ein Angreifer mit Einfluss auf den Netzwerkpfad mehr Spielraum, Verkehr zu verändern oder Authentifizierung zu relayern.

NTLM ist noch immer in Betrieb

Selbst Organisationen, die Kerberos bevorzugen, haben oft verbleibende NTLM-Pfade. Microsoft dokumentiert SMB-NTLM-Blocking separat für Windows 11 24H2 und Windows Server 2025. Das zeigt, dass Legacy-Authentifizierung weiter ein praktisches Thema bleibt.

Drittgeräte drücken häufig die Baseline

Microsoft warnt ausdrücklich davor, SMB-Signierung als Workaround für Drittanbieter-Server zu deaktivieren. Wenn ein NAS, Scanner oder anderes Gerät Signierung nicht korrekt unterstützt, sollte es als technische Ausnahme behandelt und isoliert werden. Die globale Windows-Baseline deswegen abzusenken ist keine saubere Lösung.

Voraussetzungen für eine echte Exposure

Eine SMB_SIGNING_DISABLED-Finding wird besonders relevant, wenn diese Bedingungen zusammenkommen.

1. Keine Seite erzwingt Signierung auf einem relevanten Pfad

Das Kernproblem ist, dass Client und Server SMB ohne Pflichtsignatur zulassen.

2. NTLM ist auf dem Pfad verfügbar

Microsoft empfiehlt Kerberos statt NTLMv2 und warnt vor Zugriffen über IP-Adressen oder Namensmustern, die Kerberos umgehen können. Unsigned SMB kombiniert mit NTLM ist ein klassischer Relay-Ermöglicher.

3. Der Angreifer kann Verkehr beeinflussen

Relay ist keine Fernmagie. Der Angreifer muss Authentifizierung erzwingen, einen Pfad beeinflussen oder Verkehr auf ein kontrolliertes Ziel lenken können.

4. Das Ziel hat operativen Wert

Ein Relay gegen eine unkritische Freigabe hat andere Folgen als ein Relay gegen Management-Server, administrative Shares oder sensible Fileserver. Deshalb gehört diese Prüfung neben Veraltete und Überprivilegierte Konten in AD.

5. Legacy-Geräte oder Gast-Workflows existieren noch

Alte Appliances, NAS-Geräte, Scanner und Gastzugriffe sind häufig der Grund, warum Signierung nicht erzwungen wird. Diese Abhängigkeiten sollten dokumentiert und isoliert werden.

Angriffskette

Ein praktischer Pfad mit deaktivierter SMB-Signierung sieht häufig so aus.

Schritt 1 - Unsigned SMB-Pfad finden

Der Angreifer identifiziert eine Client-Server-Kombination, bei der keine Seite Signierung verlangt.

Schritt 2 - Authentifizierung erzwingen oder abfangen

Der Angreifer bringt ein System oder einen Benutzer dazu, über SMB zu authentifizieren, oder positioniert sich auf einem Pfad, den er beeinflussen kann.

Schritt 3 - Authentifizierung relayern

Wenn die übrigen Bedingungen passen, wird die Authentifizierung an einen anderen SMB-Dienst oder einen anderen akzeptierenden Endpoint weitergereicht.

Schritt 4 - Zugriff sofort nutzen

Relay ist gefährlich, weil kein Passwort zuerst geknackt werden muss. Gelingt es, kann der Angreifer mit den Rechten der betroffenen Identität handeln.

Deshalb gehört diese Finding zu NTLM-Relay-Angriffe: Erkennung und Prävention. Deaktivierte SMB-Signierung ist nicht die ganze Relay-Geschichte, aber ein sehr konkreter Verstärker.

Erkennung

Erkennung besteht aus Konfigurationsprüfung und operativer Korrelation.

Konfigurationsprüfung

Die direkteste Prüfung ist, ob Client und Server SMB-Signierung verlangen:

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

Ist der Wert False, wird Signierung auf dieser Seite nicht erzwungen.

In Group Policy liegen die relevanten Einstellungen unter:

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

Damit wird aus einer allgemeinen Audit-Finding ein überprüfbarer Zustand.

Kompatibilität vor dem Erzwingen auditieren

Microsoft dokumentiert auf neueren Plattformen nützliche Audit-Schalter:

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

Die zugehörigen Events liegen in:

Microsoft-Windows-SMBClient/Audit, Event IDs 31998 und 31999
Microsoft-Windows-SMBServer/Audit, Event IDs 3021 und 3022

Diese Events helfen, Drittanbieter-Abhängigkeiten zu finden, bevor Signierung breit erzwungen wird.

Operative Erkennung

Bei Verdacht auf Missbrauch korrelieren Sie:

Hosts, auf denen Signierung nicht erforderlich ist
NTLM-lastige SMB-Verbindungen
Relay-Muster aus AD Sicherheitsüberwachung: Event IDs und SIEM
unerwartete Zugriffe auf administrative oder sensible Shares
SMB-Zugriffe über IP-Adressen oder Namenspfade, die Kerberos umgehen

Es gibt kein einzelnes Windows-Event, das „NTLM-Relay wegen deaktivierter SMB-Signierung“ beweist. Erst der unsignierte Pfad plus Authentifizierungs- und Zugriffskontext ergibt ein belastbares Bild.

Remediation

Die Hauptmaßnahme ist, SMB-Signierung dort zu erzwingen, wo sie erforderlich sein soll, und die angrenzenden NTLM-Pfade zu reduzieren.

1. SMB-Signierung auf Client und Server erzwingen

Microsoft dokumentiert die Befehle:

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

Policy-seitig sind relevant:

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

Wenn Sie Clients und Windows-Fileserver kontrollieren, ist das die klare Baseline.

2. Drittanbieter-Inkompatibilität nicht normalisieren

Wenn ein Gerät keine Signierung unterstützt, ist das technische Schuld oder eine isolierte Ausnahme. Es sollte nicht zur Begründung werden, die Windows-Baseline global zu schwächen.

3. Kerberos bevorzugen und NTLM-Pfade reduzieren

Microsoft empfiehlt Kerberos statt NTLMv2, keine SMB-Zugriffe per IP-Adresse und keine Namensmuster, die Kerberos umgehen. Das reduziert die Chance, dass ein schwacher SMB-Pfad zu praktischem NTLM-Relay wird. Passwort- und Protokollhygiene gehören hier zusammen, siehe AD-Passwortsicherheit: Fehlkonfigurationen die Angreifer Lieben.

4. Neue SMB-Härtungsfunktionen nutzen

Microsoft hat die Defaults in aktuellen Versionen verschärft:

Windows 11 24H2 Enterprise, Pro und Education verlangen ein- und ausgehende SMB-Signierung
Windows Server 2025 verlangt ausgehende SMB-Signierung standardmäßig
Windows 11 24H2 und Windows Server 2025 bieten SMB-Signing-Auditing
Windows 11 24H2 und Windows Server 2025 unterstützen SMB-NTLM-Blocking auf Clientseite

Härtung ist damit nicht nur ein alter Registry-Wert. Auf neuen Plattformen können Sie erst auditieren und dann gezielter erzwingen.

5. Gastzugriff separat behandeln

Microsoft weist darauf hin, dass verpflichtende SMB-Signierung auch Guest Access blockiert. Wenn ein Geschäftsprozess noch Gastzugriffe braucht, ist das eine Ausnahme mit eigenem Risiko, kein Normalzustand.

6. Lokale Admin-Sprawl im gleichen Scope prüfen

Unsigned SMB ist gefährlicher, wenn die gleichen Systeme auch lokale Admin-Passwörter teilen. Prüfen Sie parallel Windows LAPS nicht bereitgestellt.

7. Mit NTLM-Relay-Reviews verbinden

Prüfen Sie zusätzlich:

Der Kontrollwert ist am höchsten, wenn SMB-Signierung Teil eines Relay-Reduktionsprogramms ist.

Validierung nach der Härtung

Nach Änderungen muss der effektive Zustand geprüft werden.

Get-SmbClientConfiguration und Get-SmbServerConfiguration ausführen und RequireSecuritySignature = True bestätigen
wirksame GPOs gegen die Zielbaseline prüfen
Audit-Events aktivieren, bevor Drittanbieter-Abhängigkeiten breit gebrochen werden
Geräte identifizieren, die Signierung nicht unterstützen
alte Gast- oder Unsigned-Workflows entfernen oder isolieren
IP-basierte Freigabezugriffe, CNAME-Nutzung und NTLM-lastige SMB-Pfade prüfen
die Prüfung in Active Directory-Sicherheit auditieren: praktische Checkliste für interne Teams aufnehmen

Erfolg ist nicht ein Screenshot. Erfolg ist, dass Clients und Server auf relevanten Pfaden unsigniertes SMB ablehnen.

Wie EtcSec verwandte Exposition erkennt

EtcSec kann dieses Risiko direkt modellieren, weil SMB_SIGNING_DISABLED eine konkrete Netzwerkhärtungs-Finding ist.

Nützlich sind vor allem:

SMB_SIGNING_DISABLED für Systeme, die unsigniertes SMB zulassen
NTLM_RELAY_OPPORTUNITY, wenn Relay-Voraussetzungen bestehen
angrenzende AD-Kontrollen für Monitoring, privilegierte Konten und NTLM-Pfade

Daher gehört das Thema zu NTLM-Relay-Angriffe: Erkennung und Prävention und Active Directory-Sicherheit auditieren: praktische Checkliste für interne Teams, nicht nur zu generischer Fileserver-Härtung.