goSecurity BLOG

In meinem letzten BLOG zum Thema AppLocker habe ich den Grundaufbau der Regeln und wie Sie eine Grundsicherung mit Application Whitelisting erreichen können, beschrieben. Dabei mussten wir alles manuell konfigurieren. In diesem BLOG möchte ich AaronLocker, eine PowerShell-Sammlung, vorstellen, mit der Sie vieles automatisieren können und den AppLocker schneller und sicherer konfigurieren können.

Was ist AppLocker und AaronLocker

Bei AppLocker handelt es sich um ein Tool, um zu steuern, welche Anwendungen auf dem Windows System durch wen ausgeführt werden dürfen.

AaronLocker ist eine PowerShell-Toolsammlung, um AppLocker und Windows Defender Application Control (WDAC) so einfach wie möglich einzurichten. AaronLocker wurde von Aaron Margosis, einem ehemaligen Microsoft Mitarbeiter aus dem Microsoft Security Team, entwickelt. Die komplette Toolsammlung kann bei GitHub heruntergeladen werden. Der grosse Vorteil von AaronLocker ist, dass auch viele unsichere Pfade berücksichtigt werden, welche bei der Standard AppLocker-Installation noch offen bleiben.

Erste Schritte

Für die Testumgebung haben wir einen Domain Controller mit Windows Server 2019 und einen Client mit Windows 11 verwendet.

Laden Sie AaronLocker bei GitHub herunter und entpacken Sie die ZIP-Datei direkt im Root-Verzeichnis von Windows.

Im Verzeichnis vom entpackten Archiv befinden sich die folgenden Ordner:

Im Verzeichnis Dokumentation befindet sich eine ausführliche Dokumentation für die Nutzung der Toolsammlung. Im Verzeichnis AaronLocker ist die gesamte Toolsammlung.

Wechseln Sie in das AaronLocker-Verzeichnis und laden Sie AccessChk herunter. Mit AccessChk prüft AaronLocker, welche Verzeichnisse von Benutzern beschrieben werden können. Das ist sehr wichtig. Denn wenn der Benutzer beschreibbare Verzeichnisse hat, in welchen dieser Programme ausführen kann, kann der Benutzer wieder jegliche Programme ausführen.

Nach dem Ausführen der oben angegebenen Befehle sieht der Inhalt des AaronLocker Verzeichnisses ungefähr wie abgebildet aus.

Erster Testlauf

Starten Sie .\Create-Policies.ps1 um die ersten Richtlinien zu erstellen. Bei jedem Ausführen des Befehls wird ein neuer Richtliniensatz (Audit- und Enforce-Richtlinien) im Verzeichnis .\Outputs erstellt. Beim ersten Mal werden auch TXT- und XML-Dateien im Verzeichnis .\ScanResults mit den beschreibbaren Verzeichnissen erstellt. Um diese später zu aktualisieren, muss es manuell mit dem Skript .\Scan-Directories.ps1 erstellt werden.

Mit dem Parameter -Excel wird zusätzlich zu den Richtlinien eine Exceldatei generiert. So kann einfacher nachvollzogen werden, welche Regeln erstellt worden sind.

Um die Richtlinien zu testen, empfehlen wir Ihnen die Audit-Richtlinien zuerst zu verwenden. Dann wird die Blockierung der Programme nur im Event Log protokolliert. So können die Richtlinien dann weiter verbessert werden. Bevor wir Richtlinien verwenden, prüfen wir erstmal die Dateien im .\ScanResults Verzeichnis.

Anpassungen

Im Verzeichnis .\CustomizationInputs liegen mehrere PowerShell-Skripte, welche für die optimale Konfiguration von AppLocker verwendet werden können. In der Datei .\TrustedSigners.ps1 können beispielsweise die vertrauenswürdigen Signaturgeber hinterlegt werden und in der Datei .\KnownAdmins.ps1 die von uns bekannten Administratoren Konten, welche zusätzlich zu den Erkannten verwendet werden sollen. In jeder dieser Dateien befindet sich auch eine Beschreibung. Somit ist es fast selbsterklärend.

Bekannte Administratoren finden

AaronLocker versucht die Administratoren selbst zu erkennen. Leider funktioniert dies je nach Konfiguration der Systeme nicht immer sauber. Daher müssen wir die TXT- oder XML-Dateien im Verzeichnis .\ScanResults auf Administratoren prüfen.

Dazu öffnen wir eine XML-Datei nach der anderen und prüfen den Knoten „Garantee“. Ist hier ein Administrator drin, fügen wir diesen in der Datei KnownAdmins.ps1 hinzu. In unserem Fall sind hier keine zusätzlichen Administratoren.

Unsichere Verzeichnisse finden

Alle unsicheren Verzeichnisse werden standardmässig von AaronLocker blockiert. Als unsicher gelten alle Verzeichnisse, welche von Nicht-Administratoren beschrieben werden können. Als unsicher gelten zudem alle Verzeichnisse, auf welche der Benutzer Schreibrechte hat.

Das sind unter anderem folgende:

• das Profilverzeichnis (C:\Users\%USERNAME%)
• Verzeichnisse, welche direkt unter C:\ liegen
• C:\ProgramData
• Standard Programm-Verzeichnisse (C:\Program Files, C:\Program Files (x86))

Mit dem folgenden Befehl können wir die beschreibbaren Verzeichnisse unter Windows, den Standard Programm-Verzeichnissen, ProgramData, AllUserProfiles und im Root durchsuchen. Es kann auch jedes Verzeichnis einzeln untersucht werden.

Mit dem folgenden Befehl können wir auch gezielt in einem bestimmten Verzeichnis suchen.

In der erstellten Exceldatei müssen wir alle Verzeichnisse prüfen, welche als unsicher gelten. Das ist in der ersten Spalte in der Exceldatei ersichtlich. Wir können prüfen, ob wir dieses Verzeichnis besser einschränken können und ob aus diesem Verzeichnis tatsächlich Anwendungen gestartet werden müssen.

In unserem Beispiel, müssen aus dem Tools-Verzeichnis Anwendungen ausgeführt werden. Somit fügen wir dieses Verzeichnis in die Datei UnsafePatsToBuildRulesFor.ps1 ein. Dadurch werden beim nächsten Generieren der Richtlinien die Anwendungen in diesem Verzeichnis geprüft und falls nötig eine Hash-Regel erstellt.

Nachdem wir die Administratoren und die unsicheren Verzeichnisse hinzugefügt haben, generieren wir die Richtlinien neu.

In der erstellten Exceldatei können wir nun die Änderungen überprüfen. Passt alles so weit, können wir die Richtlinien einspielen.

Regeln einspielen

Jetzt können wir die erstellten Richtlinien in den Gruppenrichtlinien aktivieren. Wenn wir bereits eine Gruppenrichtlinie, wie im letzten Blog beschrieben, erstellt haben, können wir die neuen Richtlinien einfach in diese übernehmen. Dabei werden die aktuellen Richtlinien durch die neuen ersetzt. Set-GPOAppLockerPolicy.ps1 nimmt automatisch die zuletzt erstellt Richtlinie aus dem Verzeichnis .\Output.

Sind die RSAT-Tools installiert, können die Richtlinien direkt mit PowerShell importiert werden. Falls nicht, können die XML-Dateien aus dem Verzeichnis .\Output auch manuell in die Gruppenrichtlinie importiert werden.

Mit diesem Befehl werden die aktuellen Richtlinien im Audit-Modus importiert.

Mit diesem Befehl werden die aktuellen Richtlinien im Enforce-Modus importiert.

Weitere Tipps

Die aktuellen AppLocker-Richtlinien, welche am Client gelten, können mit dem folgenden Befehl in eine Excel-Datei ausgelesen werden.

Eine weitere Möglichkeit gibt es mit den folgenden Befehlen. Hier wird zuerst eine XML-Datei an einem Client ausgelesen und mit dem Tool .\ExportPolicy-ToExcel.ps1 in eine Exceldatei umgewandelt.

Fazit

Mit AaronLocker können die Richtlinien einfach und relativ schnell erstellt werden. Damit es reibungslos funktioniert, ist eine hohe Standardisierung der Clients von Vorteil. Desto mehr die Best Practice Ansätze beim Einrichten der Clients eingehalten wurden, wie beispielsweise die Programme nur in den Standard Programm-Verzeichnissen zu installieren, desto einfacher ist die Ausrollung von AppLocker auf allen Clients. Für die Generierung der Richtlinie wird am besten ein Referenzclient verwendet, bei dem alle benötigten Programme eingesetzt werden.