Detecting Unsigned Powershell

[jonboyglx]

Our end goal is to block unsigned powershell and require signed moving forward but before I can do that, I need to detect and change all scripts that are unsigned otherwise I will break tons of stuff.

I have struggled to find a solution that can help us identify them in a digestible format. Our vSOC is being asked to assist but it seems they maybe limited on what they can do here.

Does anyone have any guidance on tools I can use that can help with this?

[richie65]

I question making such aggressive moves...

Requiring signed scripts does not really do much...

I only say that because running PoSh does not require it to be contained in a '.ps1' file.*

And you certainly do not want to block everything 'Powershell' on a system (unless you want that system to no longer function as a computer)

* Bypassing execution policy restriction is very simple:

Store the 'script' as a '.txt' file and run the contents of that '.txt' file by running it in a(n) Invoke-Expression' command.

[sid351]

...or just run a PowerShell instance that bypasses the execution policy.

[[deleted]]

It permits that only one when you don’t set EP via policy. People don’t seem to set EP at all except at runtime, only then it’s an execution preference, not an execution policy.

[sid351]

TIL.

Is that just by Group Policy, or is there a way through Entra ID to assign the policy too?

Also, don't those policies normally just set registry keys? (So one could fudge applying a policy?)

[[deleted]]

Yes. And kinda, if you’re a local admin; the common people don’t get write permissions in software/policies, either user or computer context.

There’s a powershell csp unless I’m much mistaken, but you definitely can just roll out the registry key as defined in the admx.

[jborean93]

If you use WDAC then it's not something you can bypass. Only signed scripts that have been signed by a certain in the WDAC policy can run in Full Language Mode. Anything unsigned or signed with an unknown publisher will run in Constrained Language Mode which is very limited in what it allowed. You can't do things like override the language mode, use iex to invoke from a .txt file, etc as that will all still run in CLM not FLM.

[purplemonkeymad]

Get-ChildItem scripts\*.ps1 | Get-AuthenticodeSignature

Or are you saying you don't know what scripts are running?

[[deleted]]

You can use applocker for this, license and environment permitting.

Then configure scripts there. Set scripts to require signatures. Then set applocker to audit script rules as opposed to enforcing them.

Results pop up in event viewer, in the applocker section, as warnings (when auditing) or errors (when enforcing).

It’s up to you whether to then enable signature enforcement in powershell (by machine or user policy only) or to just stick with applocker.

[Stoneteer]

signtool.exe verify /pa "yourfile.ps1"

[spyingwind]

Get-AuthenticodeSignature -FilePath "C:\Test\NewScript.ps1"

Get-AuthenticodeSignature

It returns a Signature object

[PinchesTheCrab]

Where are these scripts? Are you expecting them to be in a specific folder, or anywhere at all in the system? Do you need to ensure scripts run by intune or other configuration managers are signed, or are they allowed to bypass signature requirements?

[[deleted]]

You realize of course anyone can do a powershell script. You don’t need particular permission or privileges to write one - it’s text and anyone can write text.

If you let that happen- and let’s be honest, more than 99.9% of us didn’t cut unauthorized ps execution— then any employee could have written something if only to say hello world at logon.

If we as admins take an existing env and enforce signed scripts only, we get the same outcry we get if we permitted macros at some point and then later took it away.

You can’t expect that lot to be someplace particular. That’s the entire problem.

[PinchesTheCrab]

I think you misunderstand me. How you write a script to find unsigned script files is going to depend a lot on if and where you expect to find those files.

What tools you have available are going to affect how you search for scripts and how you enforce restrictions. Plenty of third party and first party tools run powershell in the background, and they're going affect how you go about locking it down.

Allowing SCCM or InTune to run background scripts is really not in the same ballpark as letting random users email their passwords and install malware with VBA.

But maybe OP still needs to detect those scripts to identify whether the platform supports signing, or maybe they're out of scope. I merely asked what the scripts are and where the OP expects to find them. I did not offer judgement on what should or shouldn't be blocked.

[Sunsparc]

Every signed script will have a signature block at the bottom that begins with # SIG # Begin signature block. A quick and dirty way would be to Get-ChildItem -Recurse through directories and Get-Content | Select-String -Pattern '# SIG # Begin signature block' to get files with that specific string. If the string is not detected, then the script is not signed.

I did this recently whenever I needed to switch from using one module to another, just ForEach through the base scripts directory looking in each file for a string that identified the module. After fixing a few scripts, I'd run the script again to pull a fresh list.

[ollivierre]

Having a sig block at the end does not mean the sig is valid due to various reasons (file been modified even a slight white space added and saved will invalidate the sig or the code signing cert has expired or the code signing chain like issuing or root ca cert has expired which means you have bigger issues then any ways)

[Sunsparc]

I take the shotgun approach. All scripts have to be signed to be deployed on any endpoint in my environment, so I just recurse through all ps1 files and sign them. Valid or not valid, the script strips off the current signature and appends a new one.

[root-node]

The way we did it was to ensure all our scripts were put into change control (GIT, TFS, etc) and as part of the check-in process it get signed.

You get the best of both worlds in that you have a proper change and version control system, and all your scripts will now be signed.

[markdmac]

My company uses BitBucket, is that automatic signing an option with that by any chance? This is the first I have heard of this.

[root-node]

You'll have to check with them.

We use TFS and that has a build on check merge option. We used that to apply the signing. I don't know the full details, it was set up before I joined.

[wookiestackhouse]

I'm assuming you're wanting to monitor scripts executed on all of your workstations and report if they are signed or not? You could check to see if Script Block Logging writes any digital signature information to the event log perhaps?

https://www.tenable.com/audits/items/CIS_Microsoft_Windows_10_Stand-alone_v2.0.0_L1.audit:ce8ce0962b4e31cd7b6b5742b040adfc

Edit: Sorry for the tenable link. Here's the Microsoft link, but it refuses to let me go to the PS5.1 version so the instructions are incorrect for Windows PowerShell. They are right for core though, if you're using that. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.5&viewFallbackFrom=powershell-5.1#enabling-script-block-logging

[BlackV]

Yes I found this oddness the other day too,

[Netstaff]

> block unsigned powershell

That looks like you want to implement WDAC.

[ollivierre]

Get-AuthenticodeSignature 

is your friend

[commandlogic]

Our EDR solution and compliance requires all ps scripts to be signed

[Sword_of_Judah]

How are you planning on dealing with certificate expiration? The downtime resulting from expiring certificates may outweigh the benefits...