AD Anmeldeskriptpfade: scriptPath-Ziele vor ACL-Änderungen prüfen

Was AD Anmeldeskriptpfade bedeuten

AD Anmeldeskriptpfade sollten inventarisiert und hinsichtlich ihrer Zuständigkeiten geprüft werden, bevor jemand Berechtigungen ändert. Ein ausgefülltes Benutzerattribut zeigt, wo ein Anmeldeskript konfiguriert ist; es sagt nichts darüber aus, ob das Ziel existiert, ob es noch verwendet wird oder wer seinen Inhalt ändern kann. Behandeln Sie den Pfad als Ausgangspunkt für die Erhebung von Nachweisen.

Microsofts Schemareferenz zu Script-Path beschreibt scriptPath als Pfad zum Anmeldeskript des Benutzers und erlaubt eine leere Zeichenfolge. Der Parameter ScriptPath von New-ADUser akzeptiert einen lokalen absoluten Pfad oder einen Pfad nach der Universal Naming Convention (UNC). Ein UNC-Wert ist somit eine dokumentierte Konfigurationsoption. Sein Vorhandensein allein belegt keine schwache Zugriffskontrolle.

Die sinnvollen Fragen sind konkret: Welcher Benutzer verweist auf welches Ziel, wer verantwortet die betriebliche Funktion, welche Clients verwenden es und welche Sicherheitsprinzipale können dieses Ziel verändern? Kontoverantwortlicher, Skriptbetreuer und Dateiserveradministrator können unterschiedliche Personen sein. Dokumentieren Sie jede Zuständigkeit, statt anzunehmen, dass der Dateisystembesitzer auch die betriebliche Nutzung genehmigt.

Funktionsweise: Zuweisung, Inhalt und Nutzung unterscheiden

Die Prüfung umfasst drei Ebenen. Das Verzeichnisattribut weist einen Pfad zu. Die referenzierte Datei und ihre Abhängigkeiten enthalten die Anweisungen. Das tatsächliche Anmeldeverhalten des Clients bestimmt, ob diese Anweisungen verwendet werden. Nachweise aus einer Ebene können die anderen nicht ersetzen.

Die Technik Network Logon Script von MITRE ATT&CK beschreibt den Missbrauch von Skripten, die über Active Directory oder Gruppenrichtlinien zugewiesen werden, und empfiehlt, Schreibzugriff auf benannte Administratoren zu beschränken. Sie beschreibt eine Ausführung mit den Rechten des zugewiesenen Benutzers. Leiten Sie aus einem Befund zu einem Netzwerkpfad keine SYSTEM-Ausführung ab. Um einen möglichen Missbrauch zu untersuchen, weisen Sie zunächst eine unberechtigte Möglichkeit nach, das Skript zu verändern oder seine Zuweisung umzulenken. Stellen Sie anschließend fest, dass ein relevanter Client den veränderten Inhalt verwendet. Dieser Artikel behauptet nicht, dass eines dieser Ereignisse eingetreten ist.

Unterscheiden Sie das Benutzerattribut scriptPath von Skripten, die innerhalb einer GPO konfiguriert sind. Wenn die Bereitstellung per Richtlinie beteiligt ist, nutzen Sie die separate Prüfung von GPO Read, Apply und Geltungsbereich. Die dortigen Fragen zu Read für Computer und gezieltem Apply betreffen das Abrufen und Anwenden von Richtlinien; sie belegen nicht, wer die Datei überschreiben kann, auf die das Benutzerattribut verweist.

Prüfen Sie außerdem den Inhalt im dafür vorgesehenen Prüfverfahren auf Abhängigkeiten und offengelegte Zugangsdaten. Die bestehende Prüfung von Zugangsdaten in SYSVOL-Dateien einschließlich Skripten behandelt dieses Thema. Ein Pfadinventar kann nicht feststellen, ob ein Skript ein Geheimnis enthält, und dieser Ablauf wiederholt nicht die separate cPassword-Untersuchung.

Erkennung: Benutzer inventarisieren, Ziele auflösen, beide ACLs prüfen

1. Konfigurierte Pfade inventarisieren, ohne deaktivierte Benutzer auszuschließen

Führen Sie die folgenden Beispiele in einer autorisierten Windows-Administrationsumgebung mit den erforderlichen Modulen aus. Es handelt sich um dokumentationsbasierte Beispiele, nicht um Befehle, die in einer Kundendomäne ausgeführt wurden. Ersetzen Sie die Beispielwerte für Server, Suchbasis, Identitäten und Pfade durch genehmigte Werte.

Die Referenz zu Get-ADUser dokumentiert -LDAPFilter, -SearchBase, -Server und das Abrufen zusätzlicher Attribute mit -Properties. Diese Abfrage inventarisiert Benutzer mit vorhandenem scriptPath, einschließlich deaktivierter Konten:

Get-ADUser -LDAPFilter '(scriptPath=*)' -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,SamAccountName,Enabled,scriptPath

Eine Alternative mit der Filtersyntax des Moduls lautet:

Get-ADUser -Filter 'scriptPath -like "*"' -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,SamAccountName,Enabled,scriptPath

Das Muster zur Prüfung auf ein vorhandenes Attribut ist aus Microsofts Active-Directory-Filterbeispielen abgeleitet. Format-List zeigt benannte Eigenschaften an; bewahren Sie das zugrunde liegende Inventar zusätzlich in Ihrem genehmigten Nachweissystem auf. Dokumentieren Sie den abgefragten Domänencontroller, die Suchbasis, den Erhebungszeitpunkt und sämtliche Fehler. Eine teilweise oder fehlgeschlagene Abfrage ist kein vollständiges Inventar.

Ordnen Sie jedem Benutzer den Pfad und einen zuständigen Verantwortlichen zu. Lassen Sie deaktivierte Konten als Lebenszyklusfälle sichtbar: Fragen Sie, ob die Zuweisung für eine geplante Rückkehr erhalten bleibt, aus einer Vorlage kopiert wurde oder veraltet ist. Aktivieren Sie kein Konto, um dessen Skript zu testen. Die Zuweisung eines deaktivierten Benutzers belegt keine aktuelle Nutzung; sie kann dennoch ein Ziel identifizieren, das andere Benutzer ebenfalls verwenden.

2. Das Ziel im tatsächlichen Clientkontext auflösen

Bewahren Sie den wörtlichen Attributwert auf, bevor Sie ihn interpretieren. Ermitteln Sie bei einer relativen Zeichenfolge die Auflösungsbasis auf dem relevanten Client und im betreffenden Anmeldeablauf; lösen Sie sie nicht relativ zum Arbeitsverzeichnis Ihrer administrativen Shell auf. Bestimmen Sie bei einem lokalen absoluten Pfad den Client, auf dem diese Datei vorhanden sein sollte. Identifizieren Sie bei einem Netzwerkpfad den tatsächlichen Server, die Freigabe und die Datei, die der Testclient erreicht. Halten Sie ungeklärte Fälle ausdrücklich fest.

Fragen Sie den Betreuer, von welchen Skripten, ausführbaren Dateien, Konfigurationsdateien oder anderen Ressourcen der Einstiegspunkt abhängt. Prüfen Sie auch diese Ziele. Nur die ACL des Einstiegspunkts zu ändern reicht nicht aus, wenn eine ungeprüfte Abhängigkeit die Anweisungen liefert, die das Skript verarbeitet.

Nach dem Auflösen einer möglichen Zieldatei verwendet dieses Beispiel die dokumentierten Parameter von Test-Path:

Test-Path -LiteralPath '\\files01.example.com\LogonScripts\onboarding.cmd' -PathType Leaf

Leaf prüft auf einen dateiartigen Endpunkt; -LiteralPath verhindert die Interpretation von Platzhaltern. Dokumentieren Sie Identität, Client und Fehler zusammen mit dem Ergebnis. Dieser Existenztest belegt weder eine erfolgreiche Ausführung bei der Anmeldung noch die Korrektheit des Skripts oder die Berechtigung, die Datei zu ändern. Bestätigen Sie die tatsächliche Nutzung durch einen genehmigten Pilottest mit dem Skriptverantwortlichen.

3. Freigabe- und Dateisystemberechtigungen unabhängig prüfen

Verwenden Sie auf dem identifizierten Dateiserver Get-SmbShare, um den Freigabenamen seinem lokalen Pfad zuzuordnen. Rufen Sie anschließend mit Get-SmbShareAccess die Freigabe-ACL ab. Diese Beispiele sind aus den dokumentierten -Name-Abfragen abgeleitet:

Get-SmbShare -Name 'LogonScripts' | Format-List -Property Name,ScopeName,Path

Get-SmbShareAccess -Name 'LogonScripts'

Führen Sie diese Befehle auf dem tatsächlichen Hostingserver aus. Wenn eine Freigabe mit einem bestimmten Scope beteiligt ist, identifizieren Sie diesen Scope und verwenden Sie den dokumentierten Parameter -ScopeName. Eine gleichnamige Freigabe auf einem anderen Server ist kein Nachweis für dieses Ziel. Bewahren Sie jeden Berechtigungsempfänger, jeden Allow- oder Deny-Eintrag und die jeweilige Zugriffsstufe auf.

Für NTFS ruft Get-Acl unter Windows den Sicherheitsdeskriptor der Ressource ab. Prüfen Sie nach Bestätigung des tatsächlichen lokalen Pfads die Datei und ihr übergeordnetes Verzeichnis:

Get-Acl -LiteralPath 'D:\LogonScripts\onboarding.cmd' | Format-List -Property *

Get-Acl -LiteralPath 'D:\LogonScripts' | Format-List -Property *

Dies sind Beispiele, keine Behauptung, dass diese Freigabe D:\LogonScripts zugeordnet ist. Erfassen Sie Besitz, Zugriffseinträge und Vererbung. Lösen Sie die Gruppen hinter jedem Berechtigungsempfänger auf, bevor Sie bestimmen, welche Benutzer den Inhalt ändern können. Die ACL-Auflistung ist ein Nachweis für diese Prüfung, keine Simulation des effektiven Zugriffs für jede Identität.

Microsofts Dateisicherheitsmodell bewertet angeforderte Rechte anhand des Tokens des Aufrufers und des Deskriptors des Objekts. Die Konstanten für Dateizugriffsrechte unterscheiden zwischen dem Schreiben von Dateidaten, dem Erstellen von Dateien in einem Verzeichnis und dem Löschen untergeordneter Objekte. Prüfen Sie sowohl die Möglichkeit, Inhalte zu verändern oder zu ersetzen, als auch die Verwaltung von Berechtigungen; das Lesen des Skripts ist eine andere Frage. Betrachten Sie die Nachweise zu Freigabe und NTFS gemeinsam für den konkreten Zugriffsweg.

Behebung: zuerst prüfen, dann gezielt korrigieren (Remediation)

1. Gewünschtes Verhalten und Schreibberechtigte abstimmen

Dokumentieren Sie für jede Zuweisung den betrieblich Verantwortlichen, die erwartete Clientgruppe, die genehmigten Betreuer und den erforderlichen Lesezugriff. Stufen Sie sie als erforderlich, veraltet oder ungeklärt ein. Machen Sie Unsicherheit sichtbar, statt sie als Erlaubnis zum Löschen zu behandeln. Ein gemeinsam genutztes Ziel kann mehrere Verbraucher haben; stimmen Sie seine Änderung daher mit allen betroffenen Verantwortlichen ab.

2. Einen Wiederherstellungsstand sichern und die Änderung im Pilot prüfen

Sichern Sie das aktuelle Attribut, den Zielinhalt, die Abhängigkeiten und beide Berechtigungssätze mit Ihrem genehmigten Sicherungsverfahren. Wählen Sie einen repräsentativen aktivierten Testbenutzer und einen Client. Legen Sie das erwartete Ergebnis und die Fehlerbedingungen vor dem Pilottest fest. Treffen Sie für deaktivierte Konten eine Lebenszyklusentscheidung, statt einen Anmeldetest zu erzwingen.

3. Das nachgewiesene Problem an seiner Quelle korrigieren

Wenn das Ziel erforderlich ist, aber ein nicht vorgesehener Sicherheitsprinzipal es ändern kann, lassen Sie den Dateiserververantwortlichen die konkrete Rechtevergabe der Freigabe oder von NTFS im genehmigten Änderungsverfahren korrigieren. Prüfen Sie vererbte Rechte und Abhängigkeiten, bevor Sie die Änderung auswählen. MITREs Gegenmaßnahme unterstützt die Beschränkung der Schreibberechtigten für Skripte; sie schreibt keine universelle ACL für jede Umgebung vor.

Wenn die Zuweisung auf ein falsches Ziel verweist, ändern Sie das Attribut dieses Benutzers erst nach Validierung des Ersatzes. Die folgende Vorschau verwendet die dokumentierten Parameter ScriptPath und WhatIf von Set-ADUser:

Set-ADUser -Identity 'CN=PilotUser,OU=Users,DC=example,DC=com' -Server 'dc01.example.com' -ScriptPath '\\files01.example.com\LogonScripts\approved.cmd' -WhatIf

-WhatIf zeigt eine Vorschau der Operation, ohne sie anzuwenden. Dieser Befehl ist eine Option für die genehmigte Korrektur einer Zuweisung, keine Empfehlung, alle Benutzer auf UNC-Pfade umzustellen. Wenn eine Zuweisung veraltet ist, nehmen Sie sie nach Prüfung gemeinsamer Abhängigkeiten im vereinbarten Kontoverwaltungsverfahren außer Betrieb. Löschen Sie keine referenzierte Datei allein deshalb, weil ein Benutzer sie nicht mehr benötigt.

4. Konfiguration erneut lesen und autorisiertes Verhalten prüfen

Fragen Sie nach der genehmigten Änderung genau diesen Benutzer erneut ab:

Get-ADUser -Identity 'CN=PilotUser,OU=Users,DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,Enabled,scriptPath

Lesen Sie beide ACLs erneut, wenn Berechtigungen geändert wurden. Wiederholen Sie den vom Verantwortlichen genehmigten Clienttest und validieren Sie den erforderlichen Abruf sowie das erwartete Verhalten. Prüfen Sie gegebenenfalls mit dem autorisierten Zugriffstestverfahren der Organisation, dass ein nicht vorgesehener Schreibberechtigter keinen effektiven Änderungszugriff besitzt. Bewahren Sie Testkontext, Ergebnisse, Ausnahmen und die Entscheidung zur Wiederherstellung zusammen mit dem Inventar auf. Das erneute Lesen des Attributs allein kann die Auswirkungen des Skripts nicht validieren.

Wie EtcSec dies erkennt

Die EtcSec-Prüfung DANGEROUS_LOGON_SCRIPTS liefert eine Prüfliste. Im etc-collector-Commit 15fc6399c215eabc415c370b762303cfcd7a353a durchläuft dangerous-logon-scripts.go:46 die bereitgestellten Benutzer und wählt einen nicht leeren ScriptPath aus, wenn dieser irgendwo zwei aufeinanderfolgende Backslashes enthält oder mit // beginnt. Im Backslash-Zweig wird kein striktes UNC-Präfix verlangt. Der Befund hat den Schweregrad Medium, und Count ist die Zahl der passenden Benutzer, nicht die Zahl unterschiedlicher Dateien oder verwundbarer Freigaben.

In diesem Detect() gibt es keinen Disabled-Filter. Deaktivierte Benutzer können daher erscheinen, wenn sie in den Auditdaten bereitgestellt werden. Ein leerer Pfad passt nicht; relative Pfade und andere Zeichenfolgen außerhalb des Prädikats können dieser Prüfliste entgehen. Umgekehrt belegt eine passende Zeichenfolge kein gültiges, erreichbares UNC-Ziel.

Der LDAP-Provider fordert scriptPath in parser.go:49 an, kopiert es in ScriptPath bei parser.go:171 und ruft Benutzer über client.go:460 ab. Diese Prüfung liest weder die Zieldatei noch die Freigabe-ACL, die NTFS-ACL oder die effektive Ausführung. Ihre Ausgabe kann weder unberechtigten Schreibzugriff noch erfolgreiche Persistenz oder SYSTEM-Ausführung bestätigen. Auch Umfang und Vollständigkeit der Datenerhebung begrenzen die Aussagekraft der Liste.