CB Connect 2020 early-bird discount pricing expires on February 21. Learn more and reserve your spot today!
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

__psscriptpolicytest powershell script blocks

__psscriptpolicytest powershell script blocks

Environment

  • Cb Protection, all versions
  • Windows 10 endpoint

Symptoms

  • After a Windows update, blocks are seen on powershell files with a __psscriptpolicytest suffix.

Cause

These files appear to be related to the OS attempting to check whether or not AppLocker is enabled, based on the contents of the .ps1 files seen thus far.

Resolution

  1. According to this article: Applocker, Windows 10, audit warning PS1 script , these files are created by App-V when syncing published apps upon login, and the files are then deleted afterwards.   Since then, it appears that the files are used in more cases than only when App-V is installed, and seems to be a 'normal' part of Windows 10 operation.
  2. The article also suggests that this was a "known issue" in 2016/2017, and that Microsoft renamed these scripts to use the __psscriptpolicytext prefix in order to allow applications such as Cb Protection to allow these to run based on the name.
  3. If the desire is to allow these files to execute, a rule would need to be put in place to allow the following:
    1. c:\windows\temp\__psscriptpolicytest*.ps1
    2. <LocalAppData>\temp\__psscriptpolicytest*.ps1
  4. Many customers are also choosing to block these files.  The sample rule listed below shows a method of allowing these to run, however security concerns for your specific environment should be taken in to account when deciding whether or not to allow these to run, or whether to create a block rule for these.

If you have older versions of Windows 10 (pre Creators edition), please read the Additional Information below for an extra path needed.

A screenshot of a sample rule is below...

Additional Information

Please note - the __psscriptpolicytest naming convention is used by Microsoft in Windows 10 versions of Creator and above.  Older versions of Windows 10 use a more random naming convention (8 characters dot 3 characters dot ps1), so the following line would need to be added to Path or File section to account for these older versions:

c:\windows\temp\????????.???.ps1

As a general rule, if you are getting these blocks after recent Windows updates, you can look at the path and naming convention of the files you see in your environment, and adjust accordingly, however the two paths mentioned in the resolution, and this additional path here for older Windows versions should resolve the blocks for most customers.

Related Content

Some articles related to these files:

Applocker, Windows 10, audit warning PS1 script

Deployment Research > Research

Labels (1)
Comments

I've uploaded the solution based on some additional blocks seen by one of our customers.   Originally, the process path for powershell was listed as C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.    However, blocks were also seen from powershell in c:\windows\syswow64\windowspowershell\v1.0\powershell.exe.  

Based on this, I've updated the solution to simply state *\powershell.exe, ensuring all paths are accounted for.

To keep the custom rule tight, you can add these two lines to PROCESS:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

or can instead just add this one line to PROCESS which covers both:

<windows>\sys?????\WindowsPowerShell\v1.0\powershell.exe

Digging a little deeper on this, we can help secure this further by using the CmdLine Macro in the process to further verify how powershell.exe was instantiated and approve these files as they are written with a file creation control rule.  Below is an example from the Azure Backup agent launching Powershell.exe with a command line that loads the MSOnlineBackup module (the command line is much more detailed in the wild, but for visibility sake I've only included the import-module portion).  By using the command line issued to powershell.exe we make this rule only approve the files that are written with those path/pattern combinations if the MSOnlineBackup agent is what launched powershell.exe. (Process: <OnlyIf:Bit9Version:Atleast:8.0.0.0><CmdLine:* -import-module MSOnlineBackup  *>powershell.exe)

As with csamet​ example above, it was App-V, launching powershell.exe, so by finding the New Unapproved File to computer event in the console, and exposing the command line, you can add the process/command line combination to the rule to approve those files created when App-V is the source.  

msonline.PNG

Thanks for this article!  As of this morning (May 18, 2018) we started getting inundated with powershell blocks - the 8.3.ps1 pattern.  We found that the triggering powershell script still actually runs, even though CBP seems to be blocking the temp version (which strips out all signatures of the original PS1 script).  This seems to be related to a specific windows update, as this just started happening after updates rolled out for us in the last few days, but I can't tell you which one specifically.  In our case, the scripts are all over the place (and therefore so are the actual powershell commands) - relating to various applications, deployments, login scripts, monitoring tools, etc.  So we have to unfortunately be pretty generic in our rule:  Allow any powershell.exe to execute any 8.3.ps1 pattern in c:\windows\temp for the system account.  Then a separate rule for the __psscriptpolicytest pattern, as these seem to execute as the logged in user.

In my tests, the source script actually still runs, even though CBP produces a block on the temp version. So I am going to experiment with silently blocking the temp version - I'd rather do that than approve on write or execute.

I could not determine is these had and business impact so I created an advance rule that silently blocked this behavior.

I'm a bit confused by this. I am indeed experiencing the limitless amount of __psscriptpolicytest, however mine aren't related to App-V. I made a PS script to quickly copy any PS1 write so I could read it and my PS script says the following:

     # PowerShell test file to determine AppLocker lockdown mode 5/25/2018 1:45:17 PM

That's the entire file. Because it uses a timestamp, the hashes are forever different. I've done an RSOP dump, and went through our GPOs, we DO NOT have anything related to AppLocker enabled.

Any ideas?

I've gone the route of using a Silent Block on these but I'm still being flooded by blocks that get by. This is most likely due to a timing issue, the speed at which it's writing, executing it, and deleting it. I've had to make a similar adjustment to this with a FCC and EC as a backstop when ForeScout's CounterACT does this type of activity.

I just had another realization which is if I'm going the route of Silent Block, I don't need to care about file paths. If you're executing something that weird of ????????.???.ps1 you deserve to get blocked and if you're doing __psscriptpolicytest_z5kxut2f.zaj.ps1, no thank you either.

Paths:

1)  *\__psscriptpolicytest*.ps1

2)  *\????????.???.ps1

Proc:

1)  *\powershell.exe

So I switched to no specific paths, hopefully it speeds up the blocking, I really don't want to switch to a FCC + EC and allow and put strain on for reason because of this random Microsoft change. Makes no sense in my environment, no GPOs related to AppLocker or anything....so WHY?? I've googled deep for this and nothing else we're doing to set PS in ConstrainedLanguage mode or anything either. Very odd.

Also as a side note for anyone reading, we've personally experienced no issues in our environment doing this.

//Update 6/15/18: after having this rule implemented for a while: it has definitely sped up blocking by like 100x, I haven't had a single __psscriptpolicytest missed block come through and zero negatives reported still.

No concerns here.

Rule type: Advance

Execute: Block Silently

Path: c:\windows\temp\__psscriptpolicytest*.ps1

Process: powershell.exe

User: Local system

Just a word of caution here. If you block the files from being created/executed/deleted, Powershell will run in Constrained Language mode. Reference: PowerShell Constrained Language Mode | PowerShell Team Blog

This page explains some of what's going on:

PowerShell 5.0 and Applocker. When security doesn’t mean security - PKI Extensions

Yes I had initially thought that as well, but in our environment, I'm blocking it as seen above and I still receive the following:

Thoughts?

From my lab testing, it seems that blocking execution does not in fact restrict the language mode. However, blocking the creation of the file does. This may be a viable solution for those that either don't care about running in ConstrainedLanguage mode, are where that doesn't impact their script operation.

Please note in the screenshot below, I've added additional paths I've seen in testing, and note the <none> notifier to prevent user pop-ups.

Cool, looks good. That was the next thing I was going to test, but got busy with other things. I'm going to study our environment and see if indeed I can actually make the full transition to ConstrainedLanguage mode because I definitely see it being beneficial overall anyways.

Hello Jeff,

Are you saying that blocking the creation of the __psscript*.ps1 file will put all powershell scripts into Constrained Language Mode or just ones that App-V creates?

Thanks in advance!

Independent of App-V. Stay tuned to this page, as we may have a better solution going forward.

Working on getting this solution marked as "outdated", but for those watching...  there is a new article up with a better long term solution here to handling these powershell files.   You can see the new solution here:

Cb Protection: __psscriptpolicytest powershell script blocks

Article Information
Author:
Creation Date:
‎05-10-2018
Views:
2188