SMB-Signierung deaktiviert: NTLM-Relay-Risiko beheben

Was bedeutet deaktivierte SMB-Signierung?

Deaktivierte SMB-Signierung bedeutet in der Regel, dass Windows-Clients, Windows-Server oder beide keine signierten SMB-Verbindungen verlangen. Auf modernen Windows-Systemen ist die exakte Steuerungseinstellung dafür der Parameter RequireSecuritySignature, der getrennt sowohl auf dem SMB-Client als auch auf dem SMB-Server konfiguriert werden kann.

Microsofts Dokumentation zur SMB-Signierung beschreibt sehr genau, was diese Funktion tatsächlich leistet. SMB-Signierung fügt jeder einzelnen SMB-Nachricht anhand des Sitzungsschlüssels (Session Key) und der jeweils verwendeten Cipher Suite eine Signatur hinzu. Manipuliert ein Angreifer die Nachricht während der Übertragung, stimmt die Signatur anschließend nicht mehr überein. Microsoft weist darüber hinaus ausdrücklich darauf hin, dass SMB-Signierung dabei hilft, vor Relay- und Spoofing-Angriffen zu schützen.

Deshalb beschränkt sich das Sicherheitsproblem eben nicht nur auf „unsignierte Dateifreigaben". Wenn SMB-Signierung dort nicht verlangt wird, wo sie eigentlich erforderlich sein sollte, ist die betroffene Umgebung insgesamt stärker dem Abfangen durch einen Angreifer in der Mitte (Adversary-in-the-Middle) sowie zusätzlichen Möglichkeiten für NTLM-Relay ausgesetzt.

Der Rahmen dieses Artikels ist Windows SMB 2.x und 3.x in Active-Directory-Umgebungen, mit besonderem Schwerpunkt auf der Relay-Gefährdung, der praktischen Überprüfung und der konkreten Härtung. Es geht dabei nicht um die Behauptung, dass SMB-Signierung allein jeden denkbaren Relay-Pfad löst. Es geht vielmehr darum, dass das Deaktivieren oder Nicht-Erfordern dieser Funktion einen der Schutzmechanismen auf Protokollebene entfernt, den Microsoft gezielt entwickelt hat, um Manipulation und Relay-Angriffe bei SMB-Verkehr zu verhindern.

Wie SMB-Signierung funktioniert

Microsoft beschreibt SMB-Signierung als eine Sicherheitsfunktion, die den Sitzungsschlüssel und die Cipher Suite verwendet, um einer Nachricht, die über die SMB-Verbindung übertragen wird, eine eigene Signatur hinzuzufügen. Diese Signatur enthält einen Hash der vollständigen Nachricht im SMB-Header. Ändert jemand die Nachricht während der Übertragung, schlägt die anschließende Signaturprüfung fehl.

Bei SMB 2.x und 3.x wird die Signierung ausschließlich darüber gesteuert, ob sie erforderlich ist, und nicht mehr über die alte, noch aus der SMB1-Ära stammende Logik von EnableSecuritySignature. Microsoft gibt hierzu an, dass ab SMB 2.02 der Parameter EnableSecuritySignature vollständig ignoriert wird und die Signierung ausschließlich darüber gesteuert wird, ob sie als erforderlich festgelegt wurde.

Diese Unterscheidung ist wichtig, weil Teams häufig fälschlicherweise annehmen, SMB-Signierung sei bereits aktiviert, sobald irgendwo in einer Richtlinie eine veraltete Einstellung existiert – selbst wenn die tatsächlich wirksame Anforderung nach wie vor deaktiviert ist.

Wann SMB-Signierung tatsächlich verwendet wird

Microsoft fasst dieses Verhalten in drei klaren Punkten zusammen:

Signierung wird verwendet, wenn der SMB-Client sie ausdrücklich verlangt
Signierung wird verwendet, wenn der SMB-Server sie ausdrücklich verlangt
Signierung wird nur dann nicht verwendet, wenn weder der SMB-Client noch der SMB-Server sie verlangen

Das bedeutet in der Praxis, dass der verwundbare Zustand deutlich weiter gefasst ist als nur ein einzelner, schlecht konfigurierter Dateiserver. Verlangt keine der beiden Seiten Signierung, kann die gesamte Sitzung unsigniert fortgesetzt werden.

Warum SMB-Signierung in AD-Umgebungen wichtig ist

SMB ist eben nicht nur ein reines Protokoll für Dateifreigaben. Active-Directory-Umgebungen verlassen sich darauf für zahlreiche gängige Arbeitsabläufe, etwa den Zugriff auf SYSVOL und NETLOGON, administrative Freigaben sowie den alltäglichen operativen Dateizugriff zwischen Endpunkten und Servern.

Microsoft weist an dieser Stelle ausdrücklich darauf hin, dass Domänencontroller standardmäßig SMB-Signierung für sämtliche Verbindungen zu ihnen verlangen, insbesondere im Zusammenhang mit SYSVOL und NETLOGON. Diese Standardeinstellung existiert aus gutem Grund: Unsignierter SMB-Verkehr innerhalb der Identitätsinfrastruktur lässt sich deutlich leichter manipulieren oder für Relay-Angriffe missbrauchen.

Deaktivierte SMB-Signierung vs. nicht erforderliche SMB-Signierung

In der Praxis verwenden viele Teams diese beiden Bezeichnungen synonym, obwohl die technische Nuance zwischen ihnen durchaus wichtig ist.

Deaktiviert bedeutet in der Regel, dass der Administrator RequireSecuritySignature auf dem Client, dem Server oder auf beiden Seiten explizit auf False gesetzt hat.
Nicht erforderlich bedeutet, dass der jeweilige Endpunkt weiterhin signieren kann, wenn die Gegenseite dies ausdrücklich verlangt, dass er aber ebenso eine unsignierte Sitzung akzeptiert, sobald keine der beiden Seiten Signierung verlangt.

Aus reiner Risikosicht können beide Zustände letztlich dasselbe operative Problem erzeugen: SMB-Sitzungen, die ohne jede Signierung fortgesetzt werden dürfen.

Deshalb fassen viele Sicherheitsaudits beide Zustände ohnehin zu einem einzigen Befund zusammen. Die eigentlich entscheidende Frage lautet nämlich nicht, ob irgendwo ein Kontrollkästchen „aktiviert" anzeigt. Die eigentlich entscheidende Frage lautet vielmehr, ob der Client oder der Server unsignierten SMB-Verkehr am Ende tatsächlich ablehnt.

Warum deaktivierte SMB-Signierung weiterhin wichtig ist

Diese Kontrolle bleibt weiterhin relevant, weil Microsoft SMB-Signierung nach wie vor ausdrücklich als Schutz gegen Nachrichtenmanipulation, Spoofing und Relay beschreibt, und weil zahlreiche Relay-Pfade nach wie vor davon abhängen, einen Server erfolgreich dazu zu bringen, Verkehr ohne diesen Schutz zu akzeptieren.

Unsignierter SMB-Verkehr verschafft Angreifern einen schwächeren Protokollpfad

Können sich ein Client und ein Server erfolgreich auf eine unsignierte Sitzung einigen, hat ein Angreifer im Netzwerk deutlich mehr Spielraum, um den Verkehr aktiv zu manipulieren oder Authentifizierungsmaterial gezielt an einen anderen Host weiterzuleiten (Relay).

NTLM existiert weiterhin in realen Umgebungen

Selbst in Organisationen, die konsequent auf Kerberos und stärkere Protokolle setzen, dokumentiert Microsoft weiterhin die NTLM-Blockierung bei SMB als eigenständigen, separaten Härtungsschritt für Windows 11 24H2 und Windows Server 2025. Das ist ein starkes Signal dafür, dass das Problem des Protokoll-Downgrades und der weiterhin genutzten veralteten Authentifizierung operativ nach wie vor sehr relevant ist.

Geräte von Drittanbietern und gastähnlicher Zugriff schwächen den Pfad häufig

Microsofts Leitfaden zur SMB-Signierung ist an dieser Stelle vollkommen unmissverständlich: Unterstützt ein SMB-Server eines Drittanbieters keine Signierung, deaktivieren manche Teams die Signierung unter Windows einfach vollständig, nur um die Kompatibilität wiederherzustellen. Microsoft warnt ausdrücklich davor, dies als dauerhaften Workaround zu verwenden, da dies letztlich bedeutet, gastähnlichem oder unsigniertem Zugriff auf eine entfernte Freigabe zu vertrauen.

Voraussetzungen für eine reale SMB-Signierungs-Gefährdung

Ein Befund vom Typ SMB_SIGNING_DISABLED wird dann substanziell bedeutsam, wenn mehrere der folgenden Bedingungen gleichzeitig zusammentreffen.

1. Keine der beiden Seiten verlangt Signierung auf einem relevanten Pfad

Die eigentliche Gefährdung besteht letztlich darin, dass sowohl der SMB-Client als auch der SMB-Server ganz normal fortfahren können, ohne überhaupt Signaturen zu verlangen.

2. NTLM ist auf dem Pfad weiterhin verfügbar

Microsofts Leitfaden zu SMB empfiehlt wiederholt und ausdrücklich Kerberos gegenüber NTLMv2 und rät gleichzeitig von der Verwendung von IP-Adressen oder CNAME-Einträgen ab, da solche Muster die Authentifizierung tendenziell von Kerberos weg und in Richtung NTLM drängen. Das ist deshalb wichtig, weil unsignierter SMB-Verkehr in Kombination mit NTLM-orientierten Zugriffspfaden eine klassische, Relay-begünstigende Kombination darstellt.

3. Der Angreifer kann sich im Pfad positionieren oder ihn beeinflussen

Relay- und Abfangangriffe sind keine Fernmagie und funktionieren nicht von selbst. Der Angreifer muss vielmehr in der Lage sein, Datenverkehr aktiv zu erzwingen oder ihn gezielt über ein System zu leiten, das er selbst kontrolliert, oder anderweitig einen Pfad auszunutzen, über den er Anmeldeinformationen erfolgreich weiterleiten kann.

4. Administrative oder besonders wertvolle Freigaben sind erreichbar

Ein Relay gegen eine harmlose, unwichtige Freigabe ist ein Problem. Ein Relay gegen einen Verwaltungsserver, eine administrative Freigabe oder einen sensiblen Dateidienst ist dagegen ein ganz anderes. Sind diese besonders wertvollen Systeme zusätzlich noch durch mangelhafte operative Hygiene erreichbar, wächst der potenzielle Wirkungsradius erheblich. Das ist einer der Gründe, weshalb es sich lohnt, Veraltete privilegierte Konten: verborgenes Risiko in Active Directory gemeinsam mit den relay-relevanten Netzwerkeinstellungen zu überprüfen.

5. Die Umgebung enthält weiterhin veraltete Clients, Geräte oder Gast-Workflows

Der andauernde operative Druck, alte NAS-Geräte, Appliances, Scanner oder gastähnliche Zugriffsmuster weiterhin zu unterstützen, ist einer der Hauptgründe dafür, weshalb Signierung in der Praxis überhaupt erst nicht erforderlich gesetzt wird.

Die Angriffskette

Ein praktischer Angriffspfad, der gezielt deaktivierte SMB-Signierung ausnutzt, sieht in der Praxis häufig wie folgt aus.

Schritt 1 – Einen unsignierten SMB-Pfad finden

Der Angreifer identifiziert zunächst ein Server-Client-Paar, bei dem keine der beiden Seiten SMB-Signierung verlangt.

Schritt 2 – Authentifizierung erzwingen oder abfangen

Anschließend bringt der Angreifer ein Zielsystem oder einen Zielbenutzer gezielt dazu, sich über SMB auf einem Pfad zu authentifizieren, den er selbst beobachten oder aktiv beeinflussen kann.

Schritt 3 – Den Authentifizierungsversuch weiterleiten (Relay)

Erlauben es die weiteren Rahmenbedingungen, leitet der Angreifer den abgefangenen Authentifizierungsversuch an einen anderen SMB-Dienst oder an einen anderen Protokoll-Endpunkt weiter, der die weitergeleitete Identität ohne Weiteres akzeptiert.

Schritt 4 – Den resultierenden Zugriff sofort nutzen

Relay ist deshalb so nützlich, weil der Angreifer das eigentliche Passwort gar nicht zuerst knacken muss. Gelingt das Relay, kann er praktisch in Echtzeit mit dem vollen Zugriff des Opfers agieren.

Deshalb gehört dieser Befund thematisch in denselben Kontext wie NTLM-Relay-Angriffe: Kapern der Authentifizierung in Active Directory. Deaktivierte SMB-Signierung ist zwar nicht die gesamte Relay-Geschichte, aber sie ist einer der eindeutigsten Wege, SMB-Relay insgesamt leichter zu machen, als es eigentlich sein sollte.

Erkennung

Die Erkennung dieses Problems besteht grundsätzlich aus zwei Teilen: der Konfigurationserkennung und der operativen Erkennung.

Konfigurationserkennung

Die direkteste und zuverlässigste Validierungsmethode besteht schlicht darin, zu prüfen, ob der SMB-Client oder der SMB-Server Signierung tatsächlich verlangt.

Microsoft dokumentiert dazu die genauen PowerShell-Prüfbefehle:

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

Ist der zurückgegebene Wert False, ist Signierung auf dieser jeweiligen Seite nicht erforderlich.

In der Gruppenrichtlinie platziert Microsoft 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)

Das ist der schnellste und direkteste Weg, eine vage Audit-Aussage in ein konkretes Ja oder Nein zu verwandeln.

Audit-Kompatibilität vor der Durchsetzung prüfen

Eine besonders praktische Verbesserung in neueren Windows-Versionen ist das eingebaute Auditing von SMB-Signierung und -Verschlüsselung. Microsoft dokumentiert dazu die folgenden Audit-Steuerungen:

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

Die zugehörigen Ereignisse werden anschließend protokolliert unter:

Microsoft-Windows-SMBClient/Audit mit den Ereignis-IDs 31998 und 31999
Microsoft-Windows-SMBServer/Audit mit den Ereignis-IDs 3021 und 3022

Diese Ereignisse sind besonders dann nützlich, wenn Sie Signierung unternehmensweit verpflichtend machen möchten, aber zunächst herausfinden müssen, welche Systeme von Drittanbietern dadurch tatsächlich beeinträchtigt werden.

Operative Erkennung

Wenn Sie tatsächlichen aktiven Missbrauch vermuten und nicht nur eine schwache Konfiguration, sollten Sie folgende Signale korrelieren:

Hosts, auf denen Signierung nicht erforderlich ist
auffällig NTLM-lastige SMB-Verkehrsmuster
relay-artige Aktivität, wie sie ausführlich in Active-Directory-Überwachung: sicherheitsrelevante Event-IDs, die im SIEM wirklich zählen beschrieben wird
unerwarteten Zugriff auf administrative Freigaben oder sensible Dateidienste
Systeme, die IP-basierten SMB-Zugriff oder nicht-Kerberos-basierte Namensmuster verwenden

Es gibt kein einzelnes Windows-Ereignis, das eindeutig besagt: „NTLM-Relay war erfolgreich, weil SMB-Signierung deaktiviert war." Das deutlich bessere Vorgehen besteht darin, zunächst gezielt den unsignierten Pfad zu identifizieren und anschließend die umliegende Authentifizierungs- und Zugriffsaktivität sorgfältig zu korrelieren.

Behebung

Die primäre Behebungsmaßnahme ist grundsätzlich unkompliziert: SMB-Signierung überall dort verlangen, wo sie eigentlich erforderlich sein sollte, und anschließend die angrenzenden Protokollverhalten reduzieren, die Relay-Angriffe weiterhin praktikabel machen.

1. SMB-Signierung auf beiden Seiten verlangen, wo immer möglich

Microsoft dokumentiert dazu die genauen PowerShell-Befehle:

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

Auf Richtlinienebene sind die jeweils relevanten Einstellungen:

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

Wenn Sie sowohl die Windows-Clients als auch die Windows-Dateiserver vollständig kontrollieren, ist dies die sauberste und einfachste Baseline.

2. Inkompatibilität von Drittanbietern nicht als Grund nehmen, schwache SMB-Konfigurationen zum Normalzustand zu machen

Microsoft warnt ausdrücklich und wiederholt davor, SMB-Signierung als reinen Workaround für Server von Drittanbietern zu deaktivieren, und ebenso davor, Signierung gemeinsam mit Gastkonten zu verwenden. Unterstützt eine Appliance eines Drittanbieters Signierung nicht korrekt, dokumentieren Sie dies konsequent als technische Schuld oder isolieren Sie das betroffene Gerät im Netzwerk. Senken Sie dabei nicht stillschweigend die gesamte Windows-Baseline für alles Übrige.

3. Kerberos bevorzugen und Muster vermeiden, die zu NTLM zwingen

Microsoft empfiehlt in diesem Zusammenhang:

Kerberos anstelle von NTLMv2 zu verwenden
sich nicht per IP-Adresse mit Freigaben zu verbinden
keine CNAME-Einträge für den SMB-Zugriff zu verwenden, wenn diese ein NTLM-Verhalten erzwingen

Das sind keineswegs nur kosmetische Details. Sie verringern ganz direkt die Wahrscheinlichkeit, dass ein unsignierter oder nur schwach geschützter Pfad zu einem praktikablen NTLM-Relay-Pfad wird. Passwort-Hygiene und Protokoll-Hygiene bleiben rund um dieselbe Angriffsfläche weiterhin relevant, weshalb Active-Directory-Passwortsicherheit: Fehlkonfigurationen, die Angreifer ausnutzen können Teil derselben umfassenden Überprüfung ist.

4. Neuere SMB-Härtungsfunktionen nutzen, sofern die Plattform sie unterstützt

Microsoft liefert in aktuellen Versionen inzwischen von Haus aus stärkere Standardeinstellungen sowie angrenzende Schutzmaßnahmen aus:

Windows 11 24H2 Enterprise, Pro und Education verlangen sowohl eingehende als auch ausgehende SMB-Signierung
Windows Server 2025 verlangt standardmäßig ausgehende SMB-Signierung
Windows 11 24H2 und Windows Server 2025 fügen Audit-Steuerungen für SMB-Signierung hinzu
Windows 11 24H2 und Windows Server 2025 fügen clientseitige SMB-NTLM-Blockierung hinzu

Das bedeutet, dass es bei der Behebung längst nicht mehr nur darum geht, eine einzelne alte Richtlinie umzuschalten. Auf neueren Plattformen können Sie gezielt Auditing und die konsequente Reduzierung von NTLM nutzen, um die gesamte Umgebung sicherer zu machen, ohne dabei raten zu müssen, welche einzelne Abhängigkeit am Ende ausfällt.

5. Gastzugriff und veraltete NAS-Abhängigkeiten separat überprüfen

Microsoft gibt ausdrücklich an, dass das Erfordern von SMB-Signierung gleichzeitig auch den Gastzugriff auf Freigaben deaktiviert. Ist Ihr Unternehmen weiterhin auf gastähnlichen SMB-Zugriff angewiesen, handelt es sich dabei um eine bewusste Design-Ausnahme, die separat isoliert und regelmäßig überprüft werden sollte, statt sie stillschweigend in den regulären Bestand einzugliedern.

6. Die Ausbreitung lokaler Admin-Konten auf denselben Systemen überprüfen

Unsignierter SMB-Verkehr auf Workstations und Mitgliedsservern ist deutlich gefährlicher, wenn dieselben Hosts zusätzlich noch Probleme mit gemeinsam genutzten lokalen Admin-Anmeldeinformationen aufweisen. Wenn Sie den gesamten Bestand härten, überprüfen Sie zusätzlich Windows LAPS nicht bereitgestellt: Warum gemeinsam genutzte lokale Admin-Passwörter weiterhin zählen für dieselbe Systemgruppe.

7. Signierung mit relay-fokussierten Überprüfungen kombinieren

Ist SMB-Signierung deaktiviert, überprüfen Sie zusätzlich konsequent die angrenzenden Befunde, die Relay-Angriffe insgesamt erleichtern:

Wenn Sie entscheiden möchten, wie Sie diese Prüfungen konsistent im gesamten Bestand operationalisieren, ist zusätzlich auch Vergleich von Active-Directory-Sicherheitsaudit-Tools: Worauf Sie vor der Wahl achten sollten relevant.

Die Kontrolle entfaltet ihre größte Wirkung dann, wenn Sie sie konsequent als Teil eines umfassenden Relay-Reduktionsprogramms behandeln und nicht lediglich als isolierten Registrierungswert.

Validierung nach der Härtung

Nachdem Sie die Richtlinie entsprechend geändert haben, validieren Sie das erzielte Ergebnis direkt und nachvollziehbar.

führen Sie Get-SmbClientConfiguration und Get-SmbServerConfiguration aus, um zu bestätigen, dass RequireSecuritySignature tatsächlich auf True steht
bestätigen Sie zusätzlich, dass die wirksamen Gruppenrichtlinieneinstellungen der beabsichtigten Baseline vollständig entsprechen
aktivieren Sie zunächst die Audit-Ereignisse für die Signierung, wenn Sie mit Kompatibilitätsproblemen bei Drittanbietern rechnen
identifizieren Sie vorab Geräte oder Software, die Signierung nicht unterstützen, bevor Sie die Anforderung flächendeckend erzwingen
prüfen Sie, ob alte Gast- oder unsignierte Workflows weiterhin existieren und ob sie eher konsequent abgeschaltet als unverändert beibehalten werden sollten
überprüfen Sie, ob IP-basierter Freigabenzugriff, CNAME-Nutzung oder NTLM-lastige SMB-Pfade nach wie vor vorhanden sind
beziehen Sie die Kontrolle konsequent in die umfassendere Überprüfung ein, die in Wie man Active Directory Security auditiert: Praktische Checkliste für interne Teams beschrieben wird

Das eigentliche Erfolgskriterium ist eben kein Screenshot einer Richtlinie. Es ist vielmehr, dass Clients und Server dort, wo Relay-Gefährdung tatsächlich relevant ist, keinen unsignierten SMB-Verkehr mehr akzeptieren.

Wie EtcSec verwandte Gefährdungen erkennt

EtcSec kann dieses Problem direkt und präzise abbilden, da SMB_SIGNING_DISABLED ein konkreter, messbarer Befund zur Netzwerkhärtung ist und eben nicht nur eine allgemeine Best-Practice-Empfehlung.

In der Praxis sind die nützlichsten verwandten Katalog-Verknüpfungen dabei:

direkte SMB_SIGNING_DISABLED-Befunde auf Systemen, die weiterhin unsignierten SMB-Verkehr zulassen
NTLM_RELAY_OPPORTUNITY-Befunde, bei denen die Voraussetzungen für Relay weiterhin bestehen
umliegende AD-Überwachungs- und Härtungsprüfungen, die klären, ob das Problem isoliert ist oder Teil einer umfassenderen, relay-freundlichen Umgebung ist

Deshalb gehört dieses Thema inhaltlich zu NTLM-Relay-Angriffe: Kapern der Authentifizierung in Active Directory und Wie man Active Directory Security auditiert: Praktische Checkliste für interne Teams, und eben nicht nur zu allgemeinen Leitfäden für Dateiserver.

SMB-Signierung deaktiviert: Warum sie NTLM-Relay weiter ermöglicht