Windows 10-Speicherort für die Ausführung des Anmeldeskripts

Ich suche nach Informationen zu Änderungen, die möglicherweise an der Ausführung von GPO-Anmeldeskripten in Windows 10 im Vergleich zu Windows 7 vorgenommen wurden.

Ich habe ein Anmeldeskript (Powershell) über GPO für Windows 7 eingerichtet. Beim Testen eines Windows 10-Images wird dieses Skript anscheinend zuerst in den Temp-Ordner meines lokalen Profils kopiert (c:\users\myaccount\appdata\local\temp) with a random string for a name (dyyxi3ra.i2u.ps1) before it ' s executed. Dies ist ein Problem, weil das Management software, die wir verwenden, blockiert es über die Regel, die eingerichtet ist. Die Regel wurde eingeführt und erst kürzlich auf meinem Windows 10-Testbild entdeckt (7 brummt immer noch mit).

Weiß jemand, ist dieses erwartete Verhalten und ist es eine Änderung von Windows 7? Google war nicht hilfreich, und TechNet war wie die Suche nach einer Nadel in einem Heuhaufen, dass ich nicht sicher bin, ob der Heuhaufen überhaupt noch existiert.

Danke im Voraus.

ETA: Dies scheint normales Verhalten zu sein. Mindestens eine Sekunde mal erhielt ich eine ähnliche Nachricht, dass ein Skript blockiert wurde und eine andere zufällige Zeichenfolge .ps1. It erneut versuchte, aus dem lokalen Profil Temp-Ordner auszuführen.

Ich werde testen, indem ich mein Skript signiere, aber ich muss zuerst mein Code-Signaturzertifikat aktualisieren. Ich hoffe, dass das Problem bei der Ausführungsrichtlinie liegt und dass dies das Problem löst.

ETA2: In meinen Tests scheint es, dass jedes Mal, wenn ein remote gespeichertes Skript ausgeführt wird, etwas kopiert wird (das Skript selbst?), um eine temp-Datei im lokalen Profil temp-Ordner. Anmeldeskripte enthalten. Wenn mich jemand auf eine Dokumentation dazu hinweisen könnte, würde ich es begrüßen.

ETA3: Aktualisieren Sie auf den bisher gewonnenen Erfahrungen...

Dies scheint eine Änderung zwischen Powershell V4 und früher und V5 zu sein. Ich habe WMF5 auf meinem Windows 7-Gerät installiert und kann danach dasselbe Verhalten duplizieren, das ich auf dem Windows 10-Gerät sehe.

Ich habe einen Artikel gefunden, der etwas Ähnliches erklärt wie das, was ich sehe, aber sie verwenden AppLocker.

Https://www.sysadmins.lv/blog-en/powershell-50-and-applocker-when-security-doesnt-mean-security.aspx

Ich dachte, dass Bit9 vielleicht den Powershell-Sprachmodus erkennt und diesen auslöst, aber das Ändern des Modus von FullLanguage in ConstrainedLanguage scheint in meiner Umgebung keinen Unterschied zu machen.

Https://technet.microsoft.com/en-us/library/dn433292.aspx

Ich weiß nicht, ob es ausgelöst wird irgendetwas im Kopf, aber die Powershell - Eingabeaufforderung löst eine Bit9-Benachrichtigung aus, während Powershell ISE dies nicht tut. Ich habe get-module in beiden ausgeführt, um zu sehen, welche Module geladen werden, und das zwischen Geräten verglichen. Mindestens eines der Geräte lädt beim Start keine Module, daher schließe ich ein Modul als Schuldigen aus. Was ist anders zwischen Powershell.exe und ISE, die dazu führen können, dass eine Anwendung Whitelisting-Anwendung ausgelöst wird?

Author: lightwing, 2016-10-06

1 answers

Die lange und kurze davon ist, für die Kompatibilität mit AppLocker, Microsoft in Powershell v5 ein Schreib einer .ps1-Datei (und möglicherweise ein .psm1) auf %temp% beim Start, um zu bestimmen, in welchem Sprachmodus gestartet werden soll.

Es ist eine gute Sicherheitspraxis, Skripte zu überwachen, die von %temp%gestartet werden. Leider, wenn Sie dazu eine Whitelisting-Anwendung für Anwendungen verwenden (wie Bit9 oder AppLocker) und eine Regel zum Überwachen von Powershell-Skripten erstellen, die dieses Verzeichnis basierend auf der Datei verwenden daher besteht bei jedem Start von Powershell eine gute Chance, dass diese Regel ausgelöst wird.

Zumindest in meinem Fall bedeutet dies, dass jedes Mal, wenn eine PS1-Datei im Benutzerkontext ausgeführt wird (z. B. ein Powershell-Anmeldeskript), die Benachrichtigung von der Whitelisting-App ausgelöst und möglicherweise blockiert wird das Skript . Skript signieren und execution policy-Einstellung irrelevant waren in meinen Tests.

Einige relevante links für weitere Informationen unter:

Https://www.sysadmins.lv/blog-en/powershell-50-and-applocker-when-security-doesnt-mean-security.aspx

Https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/

Https://community.spiceworks.com/topic/1451109-srp-whitelist-causing-odd-behavior-in-powershell-v5

 0
Author: lightwing,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2016-10-27 19:53:53