Grundsätzliches Vorgehen

Folgendes grundsätzliches Vorgehen hat sich auf unseren Projekten bewährt.
Zunächst einigen wir uns mit dem Kunden, welcher Härtungsstandard genutzt wird und welche Systeme im Scope sind. Anschließend nutzen wir die Einstellungsdokumentation des Herstellers, um die aus unserer Erfahrung riskanten Einstellungen zu identifizieren und die Kundenumgebung entsprechend zu prüfen (Auswahl siehe nächste Abschnitte). Wurden alle im Vorfeld erkannten Probleme gelöst, beginnen wir mit dem Rollout der Härtung in Wellen. Wir beginnen mit wenigen Systemen und lassen durch den Anwendungsverantwortlichen die Funktionalität bestätigen. Laufen diese Systeme weiterhin fehlerfrei, wird der Rollout in inkrementell größer werdenden Wellen fortgesetzt.

Problematische Einstellungen beim Server härten

Microsoft selbst hat einen Artikel über problematische Einstellungen veröffentlicht. Viele der Themen sind nicht mehr aktuell, weil die betroffenen Betriebssystemversionen nicht mehr im Einsatz sind, es ist aber auf jeden Fall ratsam, das dennoch in der jeweiligen Umgebung zu prüfen. Oftmals gibt es doch noch ein Windows 2000 Server-System, das aus validen Gründen weiterbetrieben werden muss. Gerade in fertigenden Betrieben ist das leider oft der Fall, wenn das System Produktionsmaschinen steuert.

SMB v1

Dass SMB v1 veraltet und unsicher ist, ist spätestens nach Wanna Cry kein Geheimnis mehr. Nichtsdestotrotz sehen wir in Kundenumgebungen immer wieder, dass SMB v1 noch genutzt wird. Brisantestes Beispiel: Ein Vorstandsmitglied nutzte ein ungemanagedes Tablet, um auf ein altes NAS zuzugreifen, um dort abgelegte Präsentation anzusehen…

Es ist also ratsam in jeder Umgebung vor dem Härten zu prüfen, ob SMB v1 noch im Einsatz ist. Dazu kann man das Auditing in kleineren Umgebungen per PowerShell (Set-SmbServerConfiguration -AuditSmb1Access $true) einschalten oder in größeren Umgebungen folgenden Registry Key per GPO verteilen.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

“AuditSmb1Access”=dword:00000001

Das Auditing sollte mindestens auf allen Domain Controllern und File-Servern erfolgen. Die Logs kann man entweder per PowerShell einsammeln oder mittels Event Log Forwarding an einen Log Collector weiterleiten lassen. Beides ist hier schön beschrieben.

Wenn man weiß, welche Systeme noch SMB v1 nutzen, gilt es zu prüfen, warum das so ist. Entweder können die Systeme für SMB v2 oder v3 konfiguriert werden oder müssen ausgetauscht werden.

NTLM v1

Die NTLM (v1) Problematik ist sehr ähnlich zu SMB v1. Die Liste der Angriffe ist lang: ProxyLogon (CVE-2021-26855, CVE-2021-27065) und ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) von Orange Tsai, PetitPotam (VDB-179650) von topotam, sowie unterschiedliche Schwachstellen in unsicher konfigurierten Active Directory Certificate Services (ADCS) von Will Schroeder und Lee Christensen und vermutlich noch einige weitere.

Am besten wäre es, NTLM komplett abzuschalten. Diese Aufgabe wäre aber deutlich größer als nur auf „v2 only“ umzustellen. Die gängigen Härtungsstandards fordern v1 abzuschalten und nur v2 zu nutzen, weshalb wir uns in diesem Blog erstmal darauf beschränken.

In unseren Projekten war es ausreichend, die Überwachung auf dem Domain Controller per GPO zu aktivieren.

Grundsätzlich kann man das Audit aber auch auf Member Servern einschalten. Mehr dazu hier.

Um die Events einzusammeln, kann z.B. folgender PowerShell Befehl genutzt werden:

$Events = Get-WinEvent -Logname Security -FilterXPath “Event[System[(EventID=4624)]]and Event[EventData[Data[@Name=’LmPackageName’]=’NTLM V1′]]” | Select-Object `

@{Label=’Time’;Expression={$_.TimeCreated.ToString(‘g’)}},
@{Label=’UserName’;Expression={$_.Properties[5].Value}},
@{Label=’WorkstationName’;Expression={$_.Properties[11].Value}},
@{Label=’LogonType’;Expression={$_.properties[8].value}},
@{Label=’ImpersonationLevel’;Expression={$_.properties[20].value}}

Wie bei SMB v1 ist auch hier der nächste Schritt zu prüfen, warum hier mit NTLM v1 kommuniziert wird. Hier werden die Probleme beschreiben, die durch die Entfernung von NTLMv1 aus der IT-Infrastruktur entstehen können und gibt es eine hervorragende Liste mit Gründen und Lösungen (der Originallink zum Artikel von itconnect ist leider nicht mehr verfügbar). Wenn ein System ohnehin umkonfiguriert werden muss, ist das eine guter Zeitpunkt, direkt auf Kerberos umzusteigen, sofern die Applikation das unterstützt.

LDAP Signing und Channel Binding

Microsoft hat schon vor 3 Jahren versucht, LDAP Signing zu erzwingen (ADV190023). Aus gutem Grund. Siehe KrbRelayUP:

„This is essentially a universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings).”

Nun, wo liegt die Herausforderung, SMB Signing und Channel Binding zu erzwingen? Ähnlich wie bei den beiden Abschnitten zuvor, muss man erstmal rausfinden, welche Systeme unsigniert LDAP sprechen, um dann anschließend zu klären warum.

Auch hier kann man das Logging per Registry Key auf den DCs einschalten:

Reg Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v “16 LDAP Interface Events” /t REG_DWORD /d 2

Zusätzlich sollte das Channel Binding Token (CBT) signing event 3041 generiert werden. Dazu muss auf den Domain Controllern zusätzlich das Setting Domain controller: LDAP server channel binding token requirements auf „When Supported“ konfiguriert werden. Ansonsten werden nur die allgemeinen Events 3040 und 3041 erzeugt, die angeben, ob es nicht gesicherte Binds gab, aber keine Details welches System dies ausgelöst hat.

Die Bedeutung der verschiedenen Events kann man hier bei Microsoft nachlesen. Anschließend kann man obigen Powershell Code etwas anpassen, um die relevanten Events einzusammeln.

Mit der Liste der Systeme bewaffnet kann man nun mit den Server-Verantwortlichen sprechen und gemeinsam herausfinden, welche Applikation eine LDAP-Verbindung aufbaut. An der Tatsache, dass die Applikation das ohne Signierung tut, kann man in der Regel wenig ändern, allerdings unterstützt unserer Erfahrung nach (fast) jede Applikation LDAPS. Somit ist es in der Regel mit einer Änderung der Konfiguration in der Software getan.

Wir hatten allerdings auch schon den Fall, dass das Betriebssystem (Linux, Domain-joined) per LDAP kommuniziert hat und eine Änderung der Konfiguration nicht möglich war. Leider war für die eingesetzte Version des Betriebssystems kein OpenSSL Paket, welches Signing unterstützt, im Repository des Herstellers verfügbar. Somit musste der Server mit einer neueren Version des Betriebssystems neu installiert werden.

User Rights Assignments

Hin und wieder gibt es Probleme mit den User Right Assignments.

Zum Beispiel konfiguriert sowohl CIS als auch die MS Baseline: “Ensure ‘Access this computer from the network’  is set to ‘Administrators, Authenticated Users’”. Allerdings ist es bei der Verwendung von Defender for Identity notwendig, dass der genutzte Service Account eben dieses Recht hat, siehe hier.

Die User Rights Assignments können sowohl per GPO als auch lokal konfiguriert werden, was es schwierig macht, das Thema im Vorfeld abschließend zu prüfen. Wenn man den Enforce Adminstrator zum Härten nutzt, dann kann man beim Erstellen der Härtung die Einstellungen mit GPOs abgleichen und zumindest diesen Weg abschließend prüfen. Um lokal konfigurierte Einstellungen zu prüfen, könnte man ein Skript wie dieses auf allen Systemen ausführen und den Output kontrollieren.

Da die Probleme in diesem Bereich allerdings nicht so oft vorkommen, lassen wir es in der Regel darauf ankommen und finden die vereinzelten Applikationen durch die Tests der Anwendungsverantwortlichen.

Attack Surface Reduction Rules

Attack Surface Reduction ist ein recht neues Feature von Windows Defender. Es soll dabei helfen, Cyber-Angriffe zu verhindern. Eine ausführliche Blog-Serie gibt es hier.

Um die Angriffsfläche zu reduzieren, werden einige Funktionen unterbunden, was dazu führen kann, dass Applikationen nicht mehr ausgeführt werden können. Auch False Positives haben wir gesehen. Besonders auffällig ist die Regel “Block credential stealing from the Windows local security authority subsystem (lsass.exe)”. Hier haben wir öfters Meldungen gesehen, dass etwas geblockt wurde, die gemeldete Applikation aber trotzdem wie erwartet funktioniert hat.

Um auf Nummer sicher zu gehen, ist es ratsam, die Regeln erstmal im Audit Modus zu konfigurieren, die Meldungen im Eventviewer zu prüfen und erst wenn alle Probleme gelöst wurden, die Regeln in den Block-Modus zu schalten.

Die gängigen Härtungsstandards fordern nicht alle ASR Rules anzuschalten, wir halten das allerdings für eine gute Idee, auch wenn es etwas mehr Arbeit ist.

Problematische Einstellungen beim Client härten

Attack Surface Reduction Rules

Da es die Regeln auch auf Windows 10 und 11 gibt, gelten die Anmerkungen aus dem vorherigen Kapitel gleichermaßen hier. Die Regeln werden in der Microsoft Baseline für Windows 10 und in der CIS Microsoft Windows 10 Enterprise Benchmark aktiviert.

Applikationen und UNC-Pfade

Häufig werden Applikationen auf Netzwerk-Shares abgelegt und von dort über einen UNC-Pfad gestartet, um die Aktualisierung der Applikation zu vereinfachen. Nach dem Anwenden der Security Baseline für Windows erhält man in solchen Fällen möglicherweise ein Popup mit der Sicherheitswarnung: “The publisher could not be verified. Are you sure you want to run the software”. Mit einem Klick auf Run kann der Anwender die Applikation dennoch starten.

Diese Fehlermeldung ist für den Anwender lästig, lässt sich aber dadurch abschalten, indem man den UNC-Pfad in die Intranet-Zone aufnimmt. Dazu gibt es ein sogenanntes Site to Zone Mapping, das in der Registry gespeichert wird (die Zuordnung lässt für das ganze System oder für den Benutzer festlegen):

• • HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap
  • HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey

Beide Einstellungen lassen sich auch per Group Policy konfigurieren:

• • Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page
  • User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page

Dort wird der Name des Servers eingetragen, z.B. file://myserver1 mit einem Wert 2, der für die Intranet-Zone steht.

Microsoft Defender Smartscreen

Microsoft Defender Smartscreen blockiert Applikationen, die als potenziell gefährlich gelten. Dabei wird die ausgeführte Datei mit einer Liste von bekannter Schadsoftware abgeglichen. Dateien können an Microsoft zur Prüfung übermittelt werden. Sowohl die Microsoft Baseline für Windows 10 als auch der CIS Microsoft Windows 10 Enterprise Benchmark aktivieren Defender Smartscreen.

Beim Kunden erscheint dann folgende Fehlermeldung, wenn der Anwender die Applikation ausführen möchte:

Eigentlich ist diese Funktion von Defender Smartscreen für den Schutz von Anwendungen und Dateien aus dem Internet gedacht. Aber warum wurde in diesem Fall die Ausführung einer internen Anwendung blockiert? Die Ursache lag daran, dass ausführbare EXE-Datei als aus dem Internet stammend klassifiziert wurde. Defender SmartScreen schreibt dabei einen Event in sein Event log. Dabei wird in den Detaildaten des Events eine ZoneId mit dem Wert 3 angezeigt:

Hierbei handelt es sich um den sogenannten Zone Identifier. Dieser Zone Identifier wird von Browsern wie Microsoft Edge oder Internet Explorer bei heruntergeladenen Dateien in den Alternate Data Stream geschrieben (das ist eine Funktion des NTFS-Dateisystems zum Speichern zusätzlicher Metadaten). Ist der Zone Identifier gesetzt, wird eine Warnung in den Eigenschaften der Datei im Windows Explorer angezeigt:

Durch Klicken auf „Unblock“ oder mit dem PowerShell Cmdlet Unblock-File kann der Zone Identifier entfernt werden. Damit wird die Anwendung von Defender SmartScreen nicht mehr blockiert.

HTTP Authentication Schemes

Die Baseline für Microsoft Edge und der CIS Microsoft Edge Benchmark deaktivieren bei den unterstützten Authentifizierungsschemen Basic Authentication. Basic Authentication ist ein veraltetes und unsicheres Authentifizierungsverfahren und hier ist die klare Empfehlung, Anwendungen, die diese erfordern auf ein moderneres Anmeldeverfahren umzustellen.

Zum Troubleshooting kann Basic Authentication über folgende Group Policy-Einstellung wieder aktiviert werden:

Computer Configuration > Administrative Templates > Microsoft Edge > HTTP authentication > Supported authentication schemes

Dabei den Wert ‚basic‘ an die komma-separierte Liste anhängen (alle Wert müssen zwingend kleingeschrieben werden).

Junk-Mail-Schutz

Die Baseline Microsoft 365 Apps for Enterprise und der CIS Microsoft Office Outlook Benchmark setzen den Junk E-mail protection level auf „hoch“. Microsoft empfiehlt jedoch Kunden mit Exchange Online, die Filterung abzuschalten, da ansonsten False Positives im Junk Filter landen können. Dies wird mit folgender Group Policy-Einstellung erreicht:

User Configuration > Administrative Templates > Microsoft Outlook 2016 > Outlook Options > Preferences > Junk E-mail > Junk E-mail protection level

Office-Dateiformate

Ein immer wiederkehrendes Thema bei Härtung von Clients ist der Umgang mit älteren Office-Formaten. Die Microsoft 365 Apps for Enterprise Baseline und der CIS Microsoft Office Excel Benchmark gehen dabei recht restriktiv vor und deaktivieren alle älteren Office-Formate. Das betrifft alle alten Binärformate der Office-Version älter 2007, bevor Office moderne Dateiformate auf Basis von XML eingeführt hatte. Die meisten Unternehmen nutzen zumindest in Teilbereichen noch ältere Office-Formate und müssen daher die Microsoft Baseline in diesem Bereich wieder aufweichen.

Für Excel gibt es beispielsweise für jede Version und das damit verbundene Dateiformat eine separate Einstellung:

Um zum Beispiel das Öffnen von Excel 2003-Dokumenten freizuschalten, wird folgende Group Policy-Einstellung auf „Do not block“ gesetzt:

User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center > File Block Settings > Excel 97-2003 workbooks and templates

In aller Regel wird eine Aktivierung dieser Baseline zunächst eine Bestandsaufnahme erfordern, wenn die verwendeten Office-Formate im Detail nicht bekannt sind. Eine Problematik dabei ist, dass man der Dateiendung die genaue Version nicht immer ansieht. Beispielsweise steht die Dateiendung .xls für Excel-Dateien der Versionen angefangen von Excel 2 bis Excel 2003 und die Einstellungen erlauben es, das genaue Dateiformat für die jeweilige Version abzuschalten.

Wir stellen hier ein kleines Script zur Verfügung, das ein bestimmtes Verzeichnis inkl. Unterverzeichnisse nach Dateien mit der Endung .xls durchsucht und dabei die genaue Version feststellt. Das Script muss dabei allerdings die Datei öffnen, daher darf es auch nur auf vertrauenswürdige Dateien angewendet werden, weil beim Öffnen ggf. Macro-Code ausgeführt wird und bei Macros, die automatisch starten und z.B. eine Dialogbox anzeigen, müssen diese manuell weggeklickt werden.

Nachdem bekannt ist, welche Dateiformate vorhanden sind, sollte zunächst geprüft werden, inwieweit die älteren Dateiformate in die aktuellen XML-basierten Dateiformate von Office konvertiert werden können. Hierbei ist zu prüfen, ob es Applikationen gibt, die diese Dokumente automatisch verarbeiten (z.B. automatisierte Scan- und / oder OCR-Software) und nur das alte Format unterstützen.

Wenn ältere Office-Formate weiterhin benötigt werden, ist auch zu überlegen, ob das nur in Teilbereichen wie z.B. Controlling benötigt wird und diese Dateien dann auch nur für diese Bereiche im Unternehmen zu erlauben.

Fazit

Wir wollten Euch mit diesem Artikel einen Einblick in die grundlegende Vorgehensweise beim Einführen einer Härtung sowohl bei Windows Servern als auch Clients geben. Die beschriebenen Detailproblematiken sind eine Auswahl von Themen, die uns beim Kunden bei der Durchführung von Härtungsprojekten begegnen, haben aber keinen Anspruch auf Vollständigkeit. Wie üblich freuen wir uns auf Feedback 😊.