Windows 10 Logon Script Execution location

Question

I'm looking for information regarding any changes that might have been made to how GPO logon scripts are executed in Windows 10 vs Windows 7.

I have a logon script (powershell) setup via GPO for Windows 7. In testing a Windows 10 image, this script appears to be first copied to my local profile temp folder (c:\users\myaccount\appdata\local\temp) with a random string for a name (dyyxi3ra.i2u.ps1) before it's executed. This is an issue because management software we use is blocking it via the rule that's set up. The rule's been in place and only just discovered this on my Windows 10 test image (7 is still humming along).

Does anyone know, is this expected behavior and is it a change from Windows 7? Google wasn't helpful, and TechNet was like looking for a needle in a haystack that I'm not sure the haystack even exists yet.

Thanks in advance.

ETA: This does appear to be normal behavior. At logon a second time, I received a similar message that a script was blocked and a different random string .ps1. It was again trying to run from the local profile temp folder.

I'm going to test by signing my script, but I have to update my code signing cert first. I'm hoping that the issue is with the execution policy and that this will resolve the issue.

ETA2: In my testing, it appears that any time a remotely stored script is executed, it copies something (the script itself?) to a temp file in the local profile temp folder. Logon scripts included. If anyone could point me toward some documentation on this, I'd appreciate it.

ETA3: Update on findings so far...

This appears to be some change between powershell V4 and earlier and V5. I installed WMF5 on my Windows 7 device and after doing so, I can duplicate the same behavior I'm seeing on the Windows 10 device.

I found an article that explains something similar to what I'm seeing, but they're using AppLocker.

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

I thought that perhaps Bit9 was detecting the powershell Language Mode and triggering off that, but changing the mode from FullLanguage to ConstrainedLanguage doesn't appear to make any difference in my environment.

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

I don't know if it triggers anything in anyone's mind, but the Powershell command prompt triggers a Bit9 notification, whereas Powershell ISE does not. I ran get-module in both to see what modules are being loaded and compared that between devices. At least one of the devices isn't loading any modules at launch, so I'm ruling a module out as being the culprit. What is different between powershell.exe and ISE that might cause an application whitelisting application to trigger?

Solution

The long and short of it is, for compatibility with AppLocker, Microsoft built into powershell v5 a write of a .ps1 file (and potentially a .psm1) to %temp% when launching to determine what Language Mode to start in.

It's good security practice to monitor scripts that launch from %temp%. Unfortunatly, if you use an application whitelisting application to do that (like Bit9 or AppLocker) and create a rule to monitor for powershell scripts using that directory based on file extension, there's a good chance every time powershell is launched it will trigger that rule.

At least in my case, that means any time a .ps1 file is run under user context (such as a powershell logon script), it will trigger the notification from the whitelisting app and potentially block the script. Script signing and execution policy setting were irrelevant in my testing.

Some relevant links for further information:

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

Comments

[Kage]

Personally i always put my scripts in \\domain\NETLOGON and point the login script GPO to there, it always seems to execute it from there.

[lightwing]

I don't think that will help. See ETA2. The only way I could get the script to run "normally" was to copy it locally into a non-system/non-userprofile location.