Powershell für Benutzer verbieten - BSI SYS.2.2.3.A22

Es gibt seit Jahren die Richtlinien "Zugriff auf die Eingabeaufforderung verhindern". Ich persönlich mag diese Richtlinie nicht, da sie dem Benutzer das erste Diagnose-Werkzeug im Troubleshooting entzieht. Die Klassiker ping, nslookup, ipconfig, hostname etc. werden vom Helpdesk immer wieder einmal eingefordert. Die CMD/Commandline ist bei weitem nicht so mächtig, wie die Powershell, die über ihre integrierten Methoden Remote auf weitere Systeme zugreifen kann, Software eigenständig runterladen kann und installieren kann etc.. Powershell und Windows Remote Management sind eine tolle Sache für Administratoren, aber nicht für die Benutzer.

Es gibt diverse Angriffsscenarien, wo die Powershell das Einfallstor darstellt. Die große Überschrift nennt sich "Fileless Malware" oder auch "Fileless Threat". Am Ende ist das Schweizer Taschenmesser, das der Administrator benötigt in die falschen Hände geraten.

Microsoft Windows Security Threat Protection Fileless Threats

Google Suche: Fileless Malware Integration Powershell

Google Suche: Privilege Escalation Powershell

Es gibt im Gegensatz zu der Eingangs genannten Richtlinien keinen Registry Key, der gesetzt werden kann, um die Powershell zu verbieten. Der Weg führt über die Dateisystemberechtigungen. Wir nehmen eine Gruppenrichtlinie und bearbeiten:

Computerkonfiguration \ Richtlinien \ Windows-Einstellungen \ Sicherheitseinstellungen \ Dateisystem

Wir fügen 4 neue Pfade ein, für die Powershell und die Powershell ISE, inkl. des SysWOW64 Ordners. Die aktuellen Dateiberechtigungen werden vom GP Editor automaitsch von der Datei gelesen und angezeigt. Wir entfernen den Eintrag der Benutzer. Das wiederholen wir auf allen 4 Einträgen. Optional wäre auch denkbar eine explizite "Powershell-Allow" Sicherheitsgruppe zu erstellen und diese zu berechtigen anstelle der Benutzer oder sogar anstelle der Administratoren. Es ist keine Rettung vor Mitgliedern der lokalen Administratoren, da sie sich immer berechtigen können. Sie müssten es aber erst einmal tun. Vielleicht scheitert der ambitionierte Benutzer an der Aufgabe, der ausversehen Adminrechte hat.

Das Raussuchen der Dateipfade im GPEditor ist etwas mühsam. Im Kontextmenü der Sicherheitseinstellungen kann eine Richtlinie importiert werden, hier wird nach einer *.inf Datei verlangt. Die wie folgt aussehen sollte:

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[File Security]
"%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe",0,"D:PAR(A;OICI;0x1200a9;;;S-1-15-2-1)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)"
"%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell_ise.exe",0,"D:PAR(A;OICI;0x1200a9;;;S-1-15-2-1)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)"
"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe",0,"D:PAR(A;OICI;0x1200a9;;;S-1-15-2-1)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)"
"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell_ise.exe",0,"D:PAR(A;OICI;0x1200a9;;;S-1-15-2-1)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)"

Ein Mitglied der Administratoren auf dem System kann die Powershell weiterhin nutzen. Wer die Powershell als Benutzer elevated starten möchte kann das jetzt NICHT(!) mehr, da wir den Benutzereintrag entfernt haben. Im Helpdesk ist die Sitzung oft mit dem Benutzer authentifiziert, dem geholfen wird. Der Administrator muss jetzt zuerst eine CMD über "ausführen als" starten und kann dann erst die Powershell nutzen.