Server 2008 Applocker powershell.exe verbieten aber Skript erlauben

Hallo,

in einer W2k8 R2 Umgebung werden per GPOs die AppLocker Richtlinien gesetzt. Ich möchte per Applocker verhindern, dass die Benutzer die Powershell.exe oder Powershell_Ise.exe öffnen können, aber im Anmeldeskript wird einen *.PS1 verwendet. Die benötigt die Powershell.exe um sich auszuführen. Das gleiche ist mit CMD.exe und Batchskripten.

In der alten 2003er Applocker Version der Softwareeinschränkung war es möglich die powershell.exe zu verbieten, aber das *.ps1 Skript wurde ausgeführt, wenn es explizit erlaubt wurde. Im neuen Applocker scheint das nicht mehr zu gehen. Das Skipt ist erlaubt, die Exe verboten, die Exe wird geblockt.

Hat einer Erfahrungen von euch mit dem Applocker und kann mir sagen, wie ich das umsetzte?

gruß,
Mexx

EDIT: Oder anders formuliert. In der alten Version war es möglich, ALLE Anwendungen unter %system32% zu verbieten und nur bestimmte zu erlauben. Beim Applocker ist das Verbot möchtiger als das erlauben. Verbiete ich alle, werden scheinbar Zusatzregel die im gleichen Ordner etwas erlauben ignoriert. Genau das Gegenteil soll geschehen und das war in der alten Version so.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 208140

Url: https://administrator.de/forum/server-2008-applocker-powershell-exe-verbieten-aber-skript-erlauben-208140.html

Ausgedruckt am: 11.04.2025 um 23:04 Uhr

28 Kommentare

Neuester Kommentar

Hi @mexx,

Kopie von powershell.exe unter anderem Namen anlegen (was kryptisches/zufälliges vielleicht?) und dann das Skript explizit mit dieser Anwendung ausführen.
Leider kann ich dir nicht AppLocker-spezifisch antworten, da ich damit ehrlich gesagt keine Erfahrung habe. Ich hoffe ich konnte dir trotzdem helfen.

Gruß,
@Snowman25

Das Powershell Skript wird per GPO gestartet und eine ganze Latte von Batchskripten werden per USRLOGON.CMD, welche vom Datev gebraucht wird gestartet. Ich kann nicht jeden Aufruf mit einer versteckten powershell.exe und cmd.exe manipulieren. Das ist keine Lösung, sorry.

Hallo mexx,

Hab mich mal kurz über AppLocker schlau gemacht und es auf einem meiner Server angeschaut.
Wenn du AppLocker (Software restriction Version 2) verwendest, dann kannst du eine Ausnahme für *.PS1 u.ä. festlegen.
Auch möglich ist, dass du einen ganz bestimmten Pfad ausschließt: Technet DD759051

Gruß
Snow

Die Ausnahme greift nicht. Ich habe *.ps1 hinzugefügt, den Pfad bis zur Datei und sogar den Hashwert der ps1-Datei. Die Powershell.exe wird verboten und obwohl das Skript ist als Ausnahme drin steht, wird das Skript nicht per powershell ausgeführt.

Nach allem was ich im Technet gelesen habe kommt mir nur noch eine Fehlkonfiguration in den Sinn.

Technet ee791868
Was ist das Ergebnis von Test-ApplockerPolicy mit der exportierten XML-Datei (wie im Link beschrieben)?
Beachte: Einschränkungen einer GPO greifen VOR AppLocker!

Gruß
Snow

Hi.

"You can use a combination of allow actions and deny actions. However, we recommend using allow actions with exceptions because deny actions override allow actions in all cases. Deny actions can also be circumvented. For example, if you configure a deny action for a file or folder path, the user can still run the file from any other path."
Das ist, was MS empfiehlt auf http://technet.microsoft.com/de-de/library/ee460942(v=ws.10).aspx

Verzeih die etwas unvollständige Antwort zuvor.
Applocker ist härter als SRP. Bei SRP konntest Du nicht gegen die Kindsprozesse absichern, also Skript A ist erlaubt und startet B, welches nicht erlaubt ist, ging. Mit Applocker nicht mehr.

Nimm also SRPs, wenn Du es unbedingt so haben willst.

Aber was doch gehen muss ist folgende Konfiguration. ich verbiete ALLE Skripte in dem ich bei Pfad * eintrage. Dann in der selben Regel unter Ausnahmen die Skripte mit Pfad angeben. So ist es und so geht es aber nicht. Gibt es für die Ausnahmen noch irgendwo eine Spezielle GPO?

Dein Missverständnis: Du hast doch Powershell.exe verboten, das Skript ruft diese aber auf. Bei SRP war das erlaubt, denn sobald das Skript erlaubt war, waren auch dessen Kindprozesse erlaubt. Applocker ist hierbei "leider" härter, Kindprozesse werden nicht erlaubt.

Die habe ich testweise mittlerweile wieder erlaubt. Ich ändere hiermit mal meine Frage.

Ich verbiete alle Skripte mit * und füge unter Ausnahmen die Skripte hinzu, die denoch erlaubt sind. Sie werden aber verboten. Ich habe das Gefühl die Ausnahmen werden ignoriert.

Meine Erfahrung mit Applocker war, dass die Ausnahmen funktionierten. Teste das mal mit einem naturbelassenen Server quer.

Na, bist Du weitergekommen?
Ich kann Dir vorschlagen, nur mit Whitelist zu arbeiten, da kannst Du wunderbar nur einzelne zulassen.

Ich muss das Thema mal aus der Versenkung holen, weil es nicht gelöst ist.

Ich habe nur ZULASSEN Regeln, keine einzige Verbotsregel. Ich erlaube nur bestimmte Anwendungen unterhalb von C:\Windows\System32. Die Anwendungen die erlaubt sind, funktionieren, die nicht explizit erlaubt sind, funktionieren nicht. Als gäbe es eine versteckte Verbotsregel.

Versteht das einer?

Änderst Du erneut die Frage, doch keine Verbote?

Es gibt wohl die Möglichkeit, Kindprozesse doch zuzulassen.

http://technet.microsoft.com/en-us/library/ee844118(v=ws.10).aspx

AppLocker rules either allow or prevent an application from launching. AppLocker does not control the behavior of applications after they are launched. Applications could contain flags passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll to be loaded. In practice, an application that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must thoroughly examine each application before allowing them to run by using AppLocker rules.
Note
Two flags that illustrate this condition are SANDBOX_INERT, which can be passed to CreateRestrictedToken, and LOAD_IGNORE_CODE_AUTHZ_LEVEL, which can be passed to LoadLibraryEx. Both of these flags signal AppLocker to circumvent the rules and allow a child .exe or .dll to be loaded.

Zitat von @DerWoWusste:

Änderst Du erneut die Frage, doch keine Verbote?

Kein Verbot. Nur Zulassen Regeln.

Aber keine allgemeingültige ich lasse alles unter C:\Windows\System32 Regel zu. Jetzt ist es aber so, dass unter System32 nur das geht, was erlaubt ist, obwohl es keine einzige verbotsregel gibt.

Es ist mit applocker doch immer nur erlaubt, was zugelassen ist.

Aha, na das ist doch einen Antwort. Also alles ist grundsätzlich verboten, ausser ich erlaube es.

Stellt sich die alte Frage, wie Powershell- und Batchskripte erlauben unc powershell.exe und cmd.exe verbieten?

Oder anders: CMD kann ich per GPO verhindern. Die Eingabeaufforderung ist gegenüber dem User gesperrt. So einen Konfiguration scheint es für die Powershell.exe nicht zu geben. Habt Ihr Ideen, wie ich die Powershell.exe IRGENDWIE vor dem User sperre?

Auch wenn es schwer und hart ist: die Skripte brauchen die Powershell.exe. Verbietest Du die (als Ausnahme einer Allow-Regel), kannst du keine .ps1-Dateien mehr ausführen.
Soll der User selbst denn Powershellskripte ausführen?

Ja, weil es Anmelde- und Funktionsskripte sind. Bei Batchskripten geht es doch aber auch. *.BAT Dateien funktionieren, öffne ich die CMD, kommt die Meldung, dass die Eingabeaufforderung selbst gesperrt ist. Das muss es doch unter Powershell geben.

Ich habe es nachgestellt: wenn ich die cmd verbiete und gleichzeitig per Ausnahme alle Batches unterhalb von einem Testordner erlaube, kann ich diese Batches nicht ausführen und das Log sagt dabei, dass die Ausführung der cmd.exe verweigert wurde. Ich kann Deinen Einwand somit widerlegen.

Der Titel des Themas müsste jetzt geändert werden. Lasst uns weg kommen von dem Applocker. Der macht seine Aufgaben richtig. Ich habe Powershell und CMD freigeben und es werden auch die entsprechenden Skripte ausgeführt.

Die CMD selbst, habe ich per GPO so gesperrt, dass die EXE zwar startet und Batchs ausführt, aber man kann als Anwender die CMD nicht nutzen. Die Eingabe funktioniert nicht.

Das gleiche oder irgendwas ähnliches will ich mit der Powershell machen. Wenn ich sie nicht per Applocker sperren kann, weil ich sie als Parser für *.PS1 brauche, muss es doch einen anderen Weg geben, mit dem ich verhindere, dass Anwender damit rumspielen können. Bei CMD kann man es ja auch.

Ja, kann gut sein, dass es eine Policy dafür gibt. Google nach "group policy reference", lad Dir die Exceltabelle runter und such nach powershell.

Nichts.

Aber ich habe eine Idee, mit der ich mich anfreunden könnte.

unter C:\Windows\System32\WindowsPowerShell\v1.0 kann man einen profile.ps1 ablegen. Das ist dann die Default Profile Datei. Nicht manipulierbar durch den Anwender. Die Defaultprofileskriptdatei wird bei jeden Öffnen der Powershell.exe ausgeführt. In Ihr könnte man die ein Verstecken der Powershell.exe hinterlegen. Ein minimieren des Fensters ist kein Problem, aber verstekcne? Also gänzlich unsichtbar? In Pascal geht das. :D

Das hier wäre eine Lösung:

Wie beschrieben, wird die Default Profile Datei beim Öffnen einer jeden Powershell.exe, ob automatisch per Loginskript oder manuell per %zahlreiche möglichkeiten% ausgeführt.

In der Profildatei steht dieser Code drin, der jede Powershell.exe unsichtbar macht. Der Prozess läuft zwar trotzdem, aber die Exe ist nicht bedienbar.

Add-Type -Name Window -Namespace Console -MemberDefinition '
[DllImport("Kernel32.dll")]
public static extern IntPtr GetConsoleWindow();

[DllImport("user32.dll")]
public static extern bool ShowWindow(IntPtr hWnd, Int32 nCmdShow);
'

function Hide-Console {
$consolePtr = [Console.Window]::GetConsoleWindow()
hide
[Console.Window]::ShowWindow($consolePtr, 0)
}

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
$Form = New-Object System.Windows.Forms.Form

Hide-Console

Wie das aussieht, hast du dann eine versteckte Powershell-Console (auf Kernelebene?)
Diese lässt sich vom Nutzer immer noch benutzen, wenn auch nicht direkt. Aber Tools wie z.B. AutoHotKey können Input an Fenster senden, die momentan nicht aktiv sind (oder sichtbar). Diese aber zu steuern indem man blind Input schickt... den Aufwand machen sich nur ambitionierte Cracker.
Für den Normaluser recht es deshalb.

Gruß,
Snow