Windows Server Hardening | Die Ultimative Blaupause für maximale Security

Ein Domain Controller, der seit 2019 unverändert läuft, ist kein stabiler Server. Er ist ein eingefrorener Bedrohungsstand. Windows Server trägt in den meisten Unternehmen die Identität, die Dateiablage und die Applikationslogik, deshalb steht er bei jedem Ransomware-Vorfall am Anfang oder am Ende der Angriffskette. Hardening ist die Antwort darauf, aber nicht als Checkliste, die du einmal abhakst, sondern als Konfigurationszustand, den du erzwingst, misst und gegen Drift verteidigst.

Seit dem Erscheinen von Windows Server 2025 hat sich die Ausgangslage verschoben. Microsoft liefert Einstellungen ab Werk aktiviert aus, die du früher mühsam per GPO nachziehen musstest: SMB Signing für alle ausgehenden Verbindungen, Credential Guard auf geeigneter Hardware, LDAP-Verschlüsselung, TLS 1.0 und 1.1 deaktiviert, NTLMv1 entfernt, DES entfernt. Wer 2026 einen neuen Server aufsetzt, startet also mit einer besseren Baseline. Wer einen 2016er oder 2019er Bestand betreibt, muss all das weiterhin selbst konfigurieren und zusätzlich mit den Änderungen umgehen, die Microsoft für 2026 angekündigt hat.

Dieser Artikel liefert dir die Blaupause für beide Fälle: den Bestandsserver, der gehärtet werden muss, und den neuen Server, dessen Defaults du kennen und ergänzen musst.

Bevor Firewall-Regeln oder GPOs greifen, muss die Architekturentscheidung stehen. Hardening beruht auf vier Imperativen, von denen der vierte in den meisten Konzepten fehlt.

Jedes Subjekt, also Benutzerkonto, Dienstkonto und Prozess, bekommt genau die Rechte, die seine Aufgabe verlangt, und das nur für die Zeit, in der es sie braucht. Der Grund ist mechanisch: Ein Angreifer erbt exakt die Rechte des kompromittierten Kontos. Je enger diese Rechte, desto kürzer der Weg, den er nach dem Erstzugriff noch gehen kann.

Für Dienste heißt das konkret: keine Domänenkonten mit statischem Kennwort mehr. Group Managed Service Accounts (gMSA) übernehmen die Kennwortverwaltung im Active Directory, rotieren automatisch alle 30 Tage und lassen sich auf definierte Hosts einschränken, wodurch ein abgegriffener Hash außerhalb dieser Hosts wertlos wird. Windows Server 2025 ergänzt dieses Modell um delegated Managed Service Accounts (dMSA), die zusätzlich an eine Geräteidentität gebunden sind und ein vorhandenes Legacy-Dienstkonto ablösen können.

Genau hier lauert eine Falle, die du kennen musst. Akamai hat im Mai 2026 unter dem Namen BadSuccessor gezeigt, dass ein Angreifer mit CreateChild-Recht auf einer beliebigen OU einen dMSA anlegen und ihn per Attribut als Nachfolger eines Domänenadministrators deklarieren konnte, woraufhin das KDC ihm dessen Berechtigungen ausstellte. Microsoft hat den direkten Eskalationspfad mit CVE-2025-53779 im August 2025 geschlossen, indem das KDC seither beide Seiten der Migrationsbeziehung prüft. Die Technik bleibt trotzdem relevant, weil sie an der Delegation hängt: Wer auf OUs breite Schreibrechte verteilt hat, verteilt sie auch auf dMSA-Objekte. Prüfe deine OU-Delegationen, bevor du dMSAs produktiv einsetzt.

Auf der Administrationsebene setzt Just Enough Administration (JEA) dasselbe Prinzip durch. Eine JEA-Session-Konfiguration erlaubt einem Konto nur definierte Cmdlets, die Ausführung selbst läuft unter einem virtuellen, nicht privilegierten Konto. Der Administrator arbeitet damit, ohne lokale Adminrechte auf dem Zielsystem zu besitzen.

Jedes installierte Feature, jeder offene Port und jeder laufende Dienst ist Code, der angegriffen werden kann. Attack Surface Reduction bedeutet, diesen Code gar nicht erst laufen zu lassen. Das ist wirksamer als jede nachgelagerte Erkennung, weil eine nicht vorhandene Komponente keine Schwachstelle bekommen kann.

Der Fokus liegt auf drei Kategorien: nicht benötigte Rollen und Features, Legacy-Protokolle wie SMBv1 oder LLMNR, und Dienste, die auf einem Server keinen Zweck erfüllen. Die Umsetzung folgt in Abschnitt 3.

Kein einzelner Mechanismus hält. Deshalb schichtest du Kontrollen, die unabhängig voneinander wirken, sodass ein Angreifer jede Schicht einzeln überwinden muss.

Dazu kommt die logische Trennung über das Tiering-Modell, das Tier 0 (Domain Controller, Domänenadministratoren) von Tier 1 (Memberserver) und Tier 2 (Clients) isoliert und damit laterale Bewegung unterbricht.

Die drei klassischen Prinzipien optimieren die Verteidigung. Sie beantworten nicht die Frage, was passiert, wenn die Verteidigung fällt. Assume Breach heißt: Du planst den Wiederanlauf, bevor du ihn brauchst. Konkret bedeutet das eine getestete Forest-Recovery-Prozedur, Backups außerhalb der Domäne mit unveränderlichem Speicher, dokumentierte DSRM-Kennwörter im Offline-Tresor und die Fähigkeit, einen Domain Controller aus dem Nichts wiederherzustellen, ohne auf Systeme zuzugreifen, die selbst kompromittiert sein könnten.

Diese Anforderung ist kein Extra. Sie entscheidet, ob ein Vorfall drei Tage oder drei Wochen dauert.

Hardening beginnt beim Betriebssystem-Stand, weil ein Teil der Härtung nur noch in aktuellen Releases verfügbar ist und weil ungepatchte Versionen einen Zeitpunkt haben, ab dem keine Korrekturen mehr kommen.

Windows Server 2016 verlässt den erweiterten Support am 12. Januar 2027. Für Umgebungen mit Domain Controllern auf diesem Stand ist das die harte Grenze, denn ein DC ohne Sicherheitsupdates ist kein akzeptables Restrisiko, sondern ein Findings-Generator in jedem ISO-27001-Audit.

Was Windows Server 2025 ab Werk mitbringt, ändert die Prioritätenliste:

Diese Defaults erzeugen Kompatibilitätsdruck. NAS-Systeme ohne SMB-Signing-Unterstützung und Anwendungen, die auf NTLMv1 oder RC4 bestehen, fallen auf. Das ist unangenehm, aber es ist die Aufgabe: Die Abhängigkeit war vorher da, sie war nur unsichtbar.

Du kannst nur reduzieren, was du kennst. Der erste Schritt ist deshalb eine ehrliche Bestandsaufnahme mit einer einzigen Leitfrage: Was läuft hier wirklich, und was ist historischer Ballast aus einem Projekt, das seit sechs Jahren abgeschlossen ist?

PowerShell liefert dir die Übersicht schneller als jede Konsole.

Installierte Rollen und Features:

Dienste, die automatisch starten und laufen:

Aktive TCP-Listener mit dem verursachenden Prozess:

Für die AD-Seite ergänzt du eine strukturierte Auswertung der Gruppenmitgliedschaften, Delegationen und Kennwortrichtlinien. Dafür eignen sich dedizierte Reporting-Tools wie easyADReport, das über 80 vorgefertigte Berichte für Auditing und Schwachstellenerkennung liefert.

Hier steckt ein Irrtum, der sich hartnäckig durch Hardening-Guides zieht. Die grafische Oberfläche lässt sich seit Windows Server 2016 nicht mehr nachträglich entfernen. Der Wechsel zwischen Server Core und Server mit Desktopdarstellung ist nur beim Setup möglich, ein Uninstall-WindowsFeature -Name Server-Gui-Shell läuft in einen Fehler, weil das Feature nicht mehr existiert. Wenn du Core willst, entscheidest du das bei der Installation oder du installierst neu.

Für alles andere gilt der Grundsatz: entfernen statt nur deaktivieren, weil entfernte Binaries keine Patches brauchen und keine Schwachstellen tragen. Der Parameter -Remove löscht dabei auch die Quelldateien aus dem Side-by-Side-Store.

Die Feature-Namen unterscheiden sich zwischen den Releases. Prüfe sie vor dem Rollout mit Get-WindowsFeature -Name *Search*, statt eine Liste blind über eine Serverflotte zu schicken.

Zwei Sonderfälle gehören dazu. Der Internet Explorer wird nicht als Feature, sondern als Capability entfernt:

Und beim FTP-Server lohnt der genaue Blick auf die Abhängigkeit. Web-Ftp-Server ist ein Rollendienst der Webserver-Rolle. Wer ihn zusammen mit Web-Server deinstalliert, nimmt die komplette IIS-Installation mit, was auf einem produktiven Webserver zum Ausfall führt. Entferne gezielt den Rollendienst:

Ein gestoppter Dienst startet beim nächsten Reboot wieder. Setze den Starttyp auf Disabled.

Der in vielen Vorlagen genannte Fax-Dienst existiert auf Windows Server ohne installierte Faxserver-Rolle nicht. Prüfe vor dem Deaktivieren mit Get-Service, ob der Dienst überhaupt vorhanden ist, sonst produzierst du nur Fehler im Deployment-Log.

Die NTLM-Beschränkung braucht Disziplin in der Reihenfolge. Setze Netzwerksicherheit: Beschränken von NTLM zuerst auf die Überwachungsvarianten und werte die Ereignisse im Log Microsoft-Windows-NTLM/Operational aus. Erst wenn du weißt, welche Anwendungen NTLM sprechen, schaltest du auf Verweigern. Andernfalls legst du in einer gewachsenen Umgebung reproduzierbar den Zugriff auf Dateifreigaben und Altanwendungen lahm.

Das Netzwerk ist der Vektor mit der größten Fläche, weil hier jede Fehlkonfiguration remote erreichbar ist. Die Strategie: unsichere Wege schließen, Kommunikation authentifizieren und verschlüsseln, Reichweite begrenzen.

LDAP ohne Signierung erlaubt Man-in-the-Middle-Angriffe auf die Verzeichniskommunikation, inklusive Relay von Authentifizierungen an den Domain Controller. Zwei Einstellungen gehören zusammen, weil die eine ohne die andere nur die halbe Wirkung hat.

Vor der Umstellung prüfst du das Ereignisprotokoll auf ID 2887 und 2889. Diese Einträge zeigen dir, welche Clients noch ungesicherte Bindungen aufbauen. Erst danach schaltest du scharf.

SMB ist der Transportweg für Dateizugriffe, Gruppenrichtlinien und laterale Bewegung gleichermaßen. Auf Windows Server 2025 ist ein Teil davon bereits erledigt, auf 2019 und 2022 konfigurierst du es selbst.

Ab Windows Server 2025 kommen zwei Bausteine dazu, die du gezielt setzt. Mit der SMB-Dialektsteuerung legst du eine Mindestversion fest, statt dich auf die höchste ausgehandelte Version zu verlassen. Und der SMB-Client kann NTLM für ausgehende Verbindungen blockieren, was verhindert, dass ein Server seine Anmeldeinformationen an einen untergeschobenen Freigabepfad schickt.

SMB over QUIC steht seit Server 2025 in allen Editionen zur Verfügung und tunnelt SMB über TLS 1.3, was Dateizugriffe aus unsicheren Netzen ohne VPN ermöglicht. Das ist nützlich, hebt aber die Anforderung an deine PKI, weil jedes Zertifikatsproblem sofort zum Zugriffsproblem wird.

Die Host-Firewall setzt Zero Trust auf Betriebssystemebene um. Standardverhalten: alles blockieren, was nicht ausdrücklich erlaubt ist.

Beispiel für eine eng gefasste RDP-Regel:

Das ausgehende Blockieren ist der Punkt, an dem die meisten Projekte scheitern, weil es Betriebsaufwand erzeugt. Ein pragmatischer Zwischenschritt: Beginne mit den Tier-0-Systemen. Ein Domain Controller hat eine überschaubare, dokumentierbare Menge ausgehender Verbindungen, ein Applikationsserver mit 40 Schnittstellen nicht.

Wenn du über Portfilter hinausgehen willst, erzwingst du Authentifizierung auf IP-Ebene. Verbindungssicherheitsregeln in der Windows Defender Firewall setzen Kerberos V5 als Authentifizierungsmethode ein und lassen Kommunikation nur mit Domänenmitgliedern zu. Nicht verwaltete Geräte, also auch das Notebook eines Angreifers im selben VLAN, kommen damit gar nicht erst an den Dienst heran.

Für kritische Strecken wie Applikationsserver zu Datenbankserver ergänzt du Serverisolation mit erzwungener Verschlüsselung für den relevanten Verkehr, etwa TCP 1433. Pre-Shared Keys haben in diesem Konzept nichts zu suchen, weil ein geteilter statischer Schlüssel den Authentifizierungsgewinn wieder aufhebt.

Gruppenrichtlinien sind das Werkzeug, mit dem du Konfiguration erzwingst statt sie zu empfehlen. Der Unterschied zählt im Audit: Eine dokumentierte Einstellung, die lokal überschreibbar ist, gilt als nicht wirksam umgesetzt.

Diese Richtlinien wirken auf Domänenebene und schützen die Anmeldeinformationen selbst.

Ein Punkt, der in älteren Vorlagen noch steht und heute anders bewertet wird: der erzwungene periodische Kennwortwechsel. NIST hat ihn in SP 800-63B gestrichen, der BSI IT-Grundschutz folgt dieser Linie, und Microsoft hat die Vorgabe aus den eigenen Security Baselines entfernt. Der Grund ist empirisch: Zwangswechsel erzeugen vorhersehbare Muster wie Sommer2026! und Sommer2026!!. Setze stattdessen auf Länge, auf Sperrlisten für schwache Kennwörter über Entra Password Protection mit dem lokalen AD-Agent, und auf einen anlassbezogenen Wechsel bei Verdacht auf Kompromittierung.

Eine Einstellung fehlt hier bewusst, obwohl sie in vielen Hardening-Listen auftaucht: die FIPS-konformen Algorithmen. Microsoft selbst empfiehlt diese Richtlinie nicht als Sicherheitsverbesserung, weil sie nur die Verwendung validierter Kryptomodule erzwingt, nicht die Verwendung starker Verfahren, und dabei Anwendungen bricht, die nicht FIPS-konforme Implementierungen nutzen. Aktiviere sie, wenn eine Regulierung es fordert, nicht als generische Härtungsmaßnahme.

RDP ist der bequemste Verwaltungsweg und deshalb der am häufigsten angegriffene. Vier Maßnahmen greifen ineinander.

Remote Credential Guard ist der Punkt, der am meisten bringt und am seltensten gesetzt wird. Ohne ihn hinterlässt jede RDP-Sitzung eines Domänenadministrators auf einem Memberserver verwertbare Spuren im LSASS, was aus einem kompromittierten Tier-1-System einen Weg nach Tier 0 macht.

Über 300 Einzeleinstellungen von Hand zu setzen ist fehleranfällig und nach sechs Monaten nicht mehr nachvollziehbar. Deshalb arbeitest du mit Baselines.

Für Windows Server 2019 und 2022 ist das Werkzeug das Microsoft Security Compliance Toolkit. Es liefert die empfohlenen Einstellungen als GPO-Backups, dazu den Policy Analyzer für den Abgleich zwischen deiner Konfiguration und der Baseline, und LGPO.exe für Systeme ohne Domäne.

Für Windows Server 2025 hat Microsoft das Modell gewechselt. OSConfig ist ein PowerShell-Modul, das die Baseline nicht über Gruppenrichtlinien, sondern über einen eigenen Dienst durchsetzt.

Drei Eigenschaften machen OSConfig für den Betrieb relevant. Es gibt rollenbezogene Baselines für Domain Controller, Memberserver und Workgroup-Systeme, sodass ein DC nicht dieselbe Konfiguration erhält wie ein Applikationsserver. Es enthält Drift Control, das über eine Aktualisierungsaufgabe standardmäßig alle vier Stunden Abweichungen erkennt und korrigiert. Und es lässt sich über das Windows Admin Center oder Azure Policy auswerten, was die Compliance-Berichterstattung ohne zusätzliches Tooling ermöglicht.

Der Preis dafür ist Disziplin bei den Quellen. Wenn dieselbe Einstellung parallel per GPO und per OSConfig gesetzt wird, kämpfen beide gegeneinander und die Konfiguration oszilliert. Entscheide dich pro Einstellung für einen Durchsetzungsweg und dokumentiere die Entscheidung.

Ein Domain Controller speichert alle Authentifizierungsgeheimnisse der Domäne. Seine Kompromittierung ist keine Störung, sondern der Totalverlust der Vertrauensbeziehung. Entsprechend rigoros ist die Härtung.

Ein DC übernimmt keine zweite Rolle. Kein Dateidienst, kein Webserver, keine Applikation, keine Verwaltungssoftware eines Drittanbieters. Jede zusätzliche Komponente bringt eigenen Code und eigene Schwachstellen in die Tier-0-Zone.

Die Verwaltung erfolgt von gehärteten Admin-Workstations (PAW) oder über JEA-Sitzungen, nicht vom Arbeitsplatzrechner mit E-Mail-Client und Browser. Netzseitig gehören DCs in ein eigenes Segment, dessen eingehende Kommunikation auf die tatsächlich benötigten Protokolle begrenzt ist: Kerberos, LDAP, DNS, SMB für Replikation und Gruppenrichtlinien, RPC mit festgelegtem Portbereich.

Die Durchsetzung erfolgt technisch über das Benutzerrecht "Anmelden verweigern", das für Tier-0-Konten auf allen Systemen der unteren Ebenen gesetzt wird. Ohne diese Sperre ist das Modell eine Absichtserklärung, kein Schutz.

Der Backup-Server gehört bewusst nach Tier 0. Er kann jeden Systemzustand lesen und zurückschreiben, was ihn funktional gleichwertig zu einem Domain Controller macht. In der Praxis steht er trotzdem oft in Tier 1, verwaltet von einem Team ohne Tier-0-Rechte, und wird damit zum bequemsten Weg in die Domäne.

Der Kerberos-Punkt hat 2026 eine Frist bekommen. Microsoft ändert das Standardverhalten der Domain Controller so, dass Tickets für Konten ohne explizit gesetzte Verschlüsselungstypen mit AES-SHA1 statt RC4 ausgestellt werden. Jedes Dienstkonto, NAS-System und jede Altanwendung, die weiterhin auf RC4 besteht und keine explizite Konfiguration trägt, verliert damit die Authentifizierungsfähigkeit. Prüfe deinen Bestand über die Ereignisse 4768 und 4769 im Sicherheitsprotokoll, die auf Server 2019 und neuer die tatsächlich genutzten Verschlüsselungstypen ausweisen.

Suche nach unbeschränkter Delegierung:

Die Mitgliedschaft in privilegierten Gruppen ist kein Zustand, sondern ein Prozess. Prüfe sie regelmäßig und dokumentiere Abweichungen.

Für lokale Administratorkennwörter gilt seit 2023 eine neue Ausgangslage. Das alte Microsoft LAPS als MSI-Installation ist abgekündigt, die Installation wird auf aktuellen Systemen blockiert. Der Nachfolger heißt Windows LAPS, ist seit dem April-2023-Update fester Bestandteil des Betriebssystems und braucht keinen Agenten mehr. Er speichert Kennwörter verschlüsselt im Active Directory oder in Entra ID, führt eine Kennworthistorie und verwaltet auf Server 2025 und Windows 11 24H2 zusätzlich Passphrasen sowie automatisch erzeugte Konten mit zufälligem Namen.

Wenn du noch Legacy-LAPS-GPOs im Einsatz hast, plane die Ablösung aktiv. Windows LAPS ist immer aktiv und interpretiert im Emulationsmodus die alten Richtlinien, was in Mischumgebungen zu Effekten führt, die niemand konfiguriert hat.

Ergänzend gehören kritische Konten in die Gruppe "Geschützte Benutzer". Sie unterbindet zwischengespeicherte Anmeldeinformationen, NTLM und schwache Kerberos-Verfahren. Die Voraussetzung dafür ist, dass alle Systeme und Anwendungen, die diese Konten nutzen, Kerberos mit AES beherrschen. Prüfe das vor der Aufnahme, sonst sperrst du deine Administratoren aus.

Ein ungepatchter Server ist eine bekannte Schwachstelle mit Betriebsvereinbarung. Die Verzögerung zwischen Verfügbarkeit und Einspielung eines Sicherheitsupdates ist eine der wenigen Größen im Hardening, die du direkt in Tagen messen kannst.

WSUS ist seit dem 20. September 2024 abgekündigt. Die Rolle wird weiterhin ausgeliefert, funktioniert und synchronisiert nach einer Rücknahme der ursprünglichen Pläne auch weiterhin Treiber, aber sie bekommt keine neuen Funktionen und keine Feature-Requests mehr. Ein Enddatum hat Microsoft nicht genannt.

Wie ernst die Lage bei einer stagnierenden Kernkomponente wird, hat der Oktober 2025 gezeigt. CVE-2025-59287 erlaubte über eine unsichere Deserialisierung in den WSUS-Reporting-Webdiensten die unauthentifizierte Codeausführung mit SYSTEM-Rechten. Der Patch aus dem regulären Patchday behob das Problem nicht vollständig, ein außerplanmäßiges Update folgte am 23. Oktober, und die Ausnutzung begann innerhalb von Stunden. CISA nahm die Lücke einen Tag später in den KEV-Katalog auf.

Die Lehre daraus ist keine Panik, sondern eine Regel: Update-Infrastruktur ist Tier-0-Infrastruktur. Ein WSUS-Server verteilt Code mit Systemrechten an deine gesamte Flotte. Er gehört nicht ans Internet, seine Ports 8530 und 8531 gehören auf Managementhosts begrenzt, und er gehört in dasselbe Härtungs- und Überwachungsregime wie ein Domain Controller.

Für kritische Sicherheitsupdates ist ein Fenster von 48 Stunden nach Freigabe ein realistischer Zielwert, wenn ein Rollback-Weg existiert. Für aktiv ausgenutzte Schwachstellen aus dem KEV-Katalog gilt kein Fenster, sondern ein Sofortmaßnahmenplan mit Isolation als Zwischenschritt, falls das Update nicht sofort einspielbar ist.

Hotpatching entschärft den häufigsten Grund für Verzögerung, nämlich das fehlende Wartungsfenster. Windows Server 2025 nimmt Sicherheitsupdates im laufenden Betrieb an, indem der Code im Speicher laufender Prozesse ersetzt wird. Neustarts bleiben in den Baseline-Monaten Januar, April, Juli und Oktober nötig, in den zwei Folgemonaten jeweils nicht. Die Funktion setzt Windows Server 2025 Standard oder Datacenter, eine Azure-Arc-Anbindung, aktivierte virtualisierungsbasierte Sicherheit und UEFI mit Secure Boot voraus. Seit dem 15. Mai 2026 entfällt die vorher fällige Gebühr von 1,50 US-Dollar pro CPU-Kern und Monat, Hotpatch über Azure Arc ist seither ohne Zusatzkosten verfügbar.

Der Nachweis gehört dazu. Ein Patchstand ohne Bericht ist im Audit wertlos. Erzeuge einen wiederkehrenden Konformitätsbericht, der Abweichungen benennt, und behandle Ausnahmen als dokumentierte Risikoakzeptanz mit Ablaufdatum.

Das Betriebssystem ist der sichtbare Teil. Darunter liegen BIOS, Baseboard Management Controller, RAID-Controller und Hypervisor, die eigene Schwachstellen mitbringen und für einen Angreifer besonders attraktiv sind, weil ihre Kompromittierung unterhalb jeder EDR-Sicht liegt. Nutze die Werkzeuge des Herstellers für einen geplanten Firmware-Stand, statt Updates nur bei Störungen einzuspielen.

Bei Drittanbietersoftware zählt vor allem, was mit hohen Rechten läuft: Backup-Agenten, Monitoring-Agenten, Datenbanktreiber und Laufzeitumgebungen. Diese Komponenten stehen selten in einem Patch-Prozess und laufen fast immer als SYSTEM.

Du kannst nur schützen, was du siehst, und du kannst nur aufklären, was du protokolliert hast. Die Standardkonfiguration von Windows reicht dafür nicht, weil sie zu grobe Ereignisse liefert und lokal manipulierbar ist.

Die Befehlszeilenprotokollierung aktivierst du über die administrative Vorlage "Befehlszeile in Prozesserstellungsereignisse einschließen". Ohne sie zeigt Ereignis 4688 nur den Prozessnamen, was bei powershell.exe genau nichts aussagt.

Lokale Protokolle sind für einen Angreifer mit Administratorrechten löschbar. Deshalb ist die Weiterleitung keine Komfortfunktion, sondern die Bedingung dafür, dass deine Beweiskette hält.

Windows Event Forwarding (WEF) liefert die Grundfunktion ohne zusätzliche Lizenzkosten und leitet definierte Ereignisse an einen Sammelserver weiter. Ein SIEM ergänzt Korrelation über Quellen hinweg, sodass ein fehlgeschlagener Anmeldeversuch am DC, eine geblockte Firewall-Verbindung und ein EDR-Alarm auf dem Client als ein Vorgang sichtbar werden. Sysmon ergänzt beides um Prozess-, Netzwerk- und Registry-Telemetrie, die Windows selbst nicht liefert.

Definiere Alarme statt Dashboards. Sinnvolle Startpunkte: Änderungen an Mitgliedschaften privilegierter Gruppen, Anmeldungen von Tier-0-Konten auf Systemen unterhalb von Tier 0, Löschen des Sicherheitsprotokolls (Ereignis 1102), Erstellen von Diensten (7045) und Schreibzugriffe auf die dMSA-Attribute msDS-ManagedAccountPrecededByLink und msDS-DelegatedMSAState.

Diese Ebene entscheidet, was ein Angreifer mit den Rechten anfangen kann, die er bereits hat. Sie zielt auf Zugriffskontrolle und auf die Mechanismen, über die sich Schadcode dauerhaft einnistet.

Vererbung ist bequem und deshalb der häufigste Grund für zu weite Rechte. An kritischen Pfaden, also Anwendungsverzeichnissen, Skriptablagen und Protokollverzeichnissen, deaktivierst du sie und setzt explizite ACLs, die nur dem Dienstkonto und Administratoren Zugriff geben.

Ein oft übersehener Punkt sind Verzeichnisse, aus denen Dienste Programme starten. Wenn eine Gruppe dort Schreibrechte hat, die keine Adminrechte besitzt, liegt eine Privilegienerhöhung offen: Der Angreifer tauscht die Binärdatei aus und wartet auf den nächsten Dienststart. Prüfe deshalb gezielt Schreibrechte in allen Pfaden, die in Dienstkonfigurationen auftauchen, inklusive nicht in Anführungszeichen gesetzter Dienstpfade mit Leerzeichen.

Die Erzeugung von 8.3-Kurznamen kannst du abschalten, weil sie ACL-Umgehungen über den Kurznamen ermöglicht und IO kostet. Achte auf den richtigen Wert: 1 deaktiviert die Erzeugung auf allen Volumes, 3 auf allen außer dem Systemvolume.

Bestehende Kurznamen bleiben dabei erhalten. Das Entfernen mit fsutil 8dot3name strip kann Anwendungen brechen, die Registry-Einträge mit Kurznamen führen, also nur nach Sicherung und Test.

Persistenz erkennst du nicht durch Härtung allein, sondern durch Vergleich. Nimm nach dem Hardening einen Referenzstand der Dienste, geplanten Aufgaben und Autostart-Einträge auf und prüfe periodisch gegen diesen Stand.

Lokale Konten sind der Weg, über den ein Angreifer die Domäne umgeht. Wenn dasselbe lokale Administratorkennwort auf 200 Servern gilt, reicht ein kompromittierter Host, um alle zu erreichen.

Das Umbenennen des Administratorkontos ist die schwächste Maßnahme dieser Liste, weil sich das Konto über die bekannte SID mit der Endung 500 weiterhin identifizieren lässt. Es kostet nichts und gehört in jede Baseline, aber verlasse dich nicht darauf. Die Wirkung kommt aus LAPS und aus der Sperre der Netzwerkanmeldung.

Alte Protokollversionen und schwache Cipher Suites hebeln jede sonstige Härtung auf der Transportstrecke aus, weil sie einen Downgrade-Pfad offen lassen.

Windows Server 2025 liefert TLS 1.0 und 1.1 bereits deaktiviert aus. Auf 2019 und 2022 setzt du die Werte selbst, jeweils getrennt für Client und Server unter HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.

TLS 1.3 ist ab Windows Server 2022 verfügbar und sollte aktiv bleiben. Prüfe vor der Abschaltung alter Versionen, welche Anwendungen betroffen sind. Typische Kandidaten sind ältere Datenbanktreiber, Java-Laufzeitumgebungen, Druckserver, Managementkarten und medizinische oder industrielle Steuerungssysteme.

Die Zielkonfiguration bevorzugt ECDHE für den Schlüsselaustausch und AES im GCM-Modus. RC4, 3DES, alle Suiten ohne Perfect Forward Secrecy und alles mit MD5 oder SHA-1 als Hash fliegen raus. Die Reihenfolge lässt sich per GPO unter Netzwerk > SSL-Konfigurationseinstellungen festlegen, wirkt aber nur, wenn die Anwendung Schannel nutzt. Anwendungen mit eigener TLS-Implementierung, etwa OpenSSL-basierte Dienste, konfigurierst du separat.

Diese Werkzeuge greifen dort, wo klassische Härtung endet: bei speicherbasierten Angriffen und bei der Ausführung von Code, den niemand freigegeben hat.

Credential Guard verlagert die Speicherung von Anmeldegeheimnissen in eine durch virtualisierungsbasierte Sicherheit (VBS) isolierte Umgebung. Ein Angreifer mit Kernelrechten auf dem Host kommt damit nicht mehr an NTLM-Hashes und Kerberos-TGTs im LSASS-Prozess heran, was die klassischen Auslesewerkzeuge weitgehend entwertet. Voraussetzung sind UEFI, Secure Boot und aktivierte Virtualisierungskomponenten. Auf Windows Server 2025 ist die Funktion auf geeigneten Systemen bereits standardmäßig aktiv.

Ergänzend aktivierst du LSA Protection, die den LSASS-Prozess als geschützten Prozess (PPL) ausführt und damit auch das Anhängen eines Debuggers unterbindet. Beide Mechanismen wirken zusammen: Credential Guard schützt den Inhalt, LSA Protection den Prozess.

Beachte die Grenzen. Credential Guard verhindert nicht, dass ein Angreifer Anmeldeinformationen abgreift, die nach der Kompromittierung neu eingegeben werden, und er schützt keine Konten, die sich interaktiv an einem bereits kompromittierten System anmelden. Deshalb bleibt das Tiering die primäre Maßnahme.

Whitelisting ist der wirksamste Einzelmechanismus gegen Ransomware, weil er die Ausführung unbekannter Binärdateien und Skripte unterbindet, unabhängig davon, ob ein Virenscanner sie kennt.

Der Einstieg gelingt über den Auditmodus. Lass die Richtlinie zunächst nur protokollieren, werte die Ereignisse aus und überführe sie schrittweise in Blockierregeln. Achte dabei auf die von Microsoft empfohlenen Blockierlisten für Anwendungen und Treiber, weil signierte, aber missbrauchbare Werkzeuge wie bestimmte Debugger oder Skripthosts sonst eine Umgehung offen lassen.

JEA definiert in einer PSSC-Datei, welche Cmdlets, Parameter und Werte ein Konto in einer Remoting-Sitzung ausführen darf. Die Ausführung erfolgt unter einem virtuellen Konto mit lokalen Adminrechten, während der aufrufende Benutzer keine hat.

Der Nutzen zeigt sich beim Servicedesk: Ein Mitarbeiter darf einen Dienst neu starten, ohne sich anmelden, Software installieren oder Protokolle löschen zu können. Jede Aktion landet zusätzlich im Transkript der Sitzung.

Microsoft Defender Antivirus ist auf Servern aktiv und liefert mit den ASR-Regeln Verhaltensblockaden, die klassische Angriffsmuster unterbinden, etwa das Erzeugen von Kindprozessen durch Office-Anwendungen oder das Ausführen potenziell verschleierter Skripte. Aktiviere die Regeln zuerst im Auditmodus, weil Serveranwendungen legitime Muster erzeugen, die den Regeln ähneln.

Aktiviere zusätzlich den Manipulationsschutz, damit ein Angreifer die Defender-Konfiguration nicht per Registry abschalten kann, und prüfe die Ausnahmen. Pauschale Ausschlüsse ganzer Laufwerke, die einmal für eine Datenbank eingerichtet wurden, sind ein verbreiteter blinder Fleck.

Härtung reduziert die Eintrittswahrscheinlichkeit. Sie senkt nicht den Schaden, wenn es doch passiert. Diesen Teil deckt die Wiederherstellungsfähigkeit ab, und sie ist im Ernstfall die Größe, an der alles hängt.

Vier Anforderungen sind nicht verhandelbar. Backups liegen auf unveränderlichem Speicher oder offline, weil Ransomware-Gruppen zuerst die Sicherungen suchen. Der Backup-Server authentifiziert sich nicht mit Domänenkonten, sonst nimmt die Kompromittierung der Domäne die Sicherung gleich mit. Für Active Directory existiert eine dokumentierte Forest-Recovery-Prozedur inklusive Systemstatussicherung mindestens zweier DCs pro Domäne. Und die DSRM-Kennwörter liegen dokumentiert an einem Ort, den du ohne funktionierende Domäne erreichst.

Der entscheidende Punkt ist der Test. Eine Wiederherstellungsprozedur, die nie durchgespielt wurde, ist eine Vermutung. Plane mindestens jährlich einen Restore-Test eines Domain Controllers in eine isolierte Umgebung, dokumentiere die benötigte Zeit und vergleiche sie mit der Erwartung der Geschäftsführung. Die Differenz zwischen beiden Zahlen ist meist das ehrlichste Ergebnis des gesamten Sicherheitskonzepts.

Hardening ist Technik und Nachweis zugleich. Wer ein Audit besteht, hat die Konfiguration nicht einfach gesetzt, sondern begründet, dokumentiert und überprüfbar gemacht.

Der praktische Nutzen liegt in der Umkehrung: Wenn du deine Baseline versioniert ablegst, Abweichungen mit Begründung und Ablaufdatum führst und Konformitätsberichte automatisiert erzeugst, erledigst du Technik und Nachweis in einem Arbeitsschritt. Genau das ist der Grund, warum OSConfig und das Security Compliance Toolkit mehr wert sind als eine handgepflegte Einstellungsliste.

Manuelles Härten skaliert nicht und ist nach dem dritten Server nicht mehr reproduzierbar. Diese Werkzeuge nehmen dir die Wiederholung ab.

Bei allen Baseline-Werkzeugen gilt dieselbe Regel: erst in einer Testumgebung anwenden, dann auf eine Pilotgruppe, dann in die Fläche. Eine Baseline mit über 300 Einstellungen verändert Verhalten, das seit Jahren als gegeben galt.

Windows Server Hardening ist 2026 kein Projekt mehr, das du abschließt, sondern ein Zustand, den du hältst. Der Unterschied zu früheren Jahren liegt in zwei Verschiebungen.

Wer seine RC4-Abhängigkeiten jetzt über die Ereignisse 4768 und 4769 auswertet, plant eine Migration. Wer wartet, betreibt an einem Dienstagmorgen Störungsbeseitigung.

Setze die Reihenfolge nach Wirkung, nicht nach Aufwand. Die größten Hebel sind das Tiering mit erzwungenen Anmeldeverboten, eindeutige lokale Administratorkennwörter über Windows LAPS, erzwungenes SMB Signing mit blockiertem NTLM, eine restriktive Host-Firewall mit begrenzten Managementpfaden und Anwendungskontrolle im Auditmodus als Vorstufe zum Blockieren. Diese fünf Maßnahmen schneiden mehr Angriffspfade ab als jede noch so lange Liste einzelner Registry-Werte.

Kritisch bleibt der Betrieb danach. Jede Härtung erzeugt Kompatibilitätsprobleme, jedes Kompatibilitätsproblem erzeugt Druck auf eine Ausnahme, und jede undokumentierte Ausnahme wird nach sechs Monaten zur unbemerkten Lücke. Führe deshalb Ausnahmen mit Begründung, Verantwortlichem und Ablaufdatum, und prüfe sie im selben Turnus wie deine Gruppenmitgliedschaften. Die Baseline mit Drift-Kontrolle ist dabei das Werkzeug, das dir diese Arbeit abnimmt, weil sie den Sollzustand beschreibt und aktiv wiederherstellt.

Dein Gewinn ist am Ende mehr als weniger Risiko. Es ist eine Umgebung, deren Zustand du kennst, deren Abweichungen du siehst und deren Wiederherstellung du getestet hast. Das ist der Unterschied zwischen einem Server, der sicher konfiguriert ist, und einem Server, von dem du das nur annimmst.