Script security features added to PrimalScript

Malware, ransomware, and hackers from around the globe are all over the news lately. PowerShell has long been a known vector for installing malware of various types. However, singling out PowerShell is not quite fair. If you do not remember the “ILOVEYOU” virus, you can read about it here.

Any kind of application, script, batch file, etc., unwittingly launched with administrative privileges, can prove to be problematic.

PowerShell and Windows have gained numerous security features over VBScript and Windows 2000 since the time of the “ILOVEYOU” virus:

– Powershell scripts are, by default, no longer associated to run when double-clicked in File Explorer.
– You can set scripts to require digital signatures for local and/or remote files.
– We now have a split security token for admins, so you don’t always run full admin.
– Downloaded files get a ‘blocked’ attribute that prevents them from running.

These are just a few improvements, and there are certainly more. But, we all know that folks who work for a living sometimes take shortcuts; security measures get circumvented because they get in the way of, well, everything. It can be annoying having to do everything twice:
Run a script; oh, it’s blocked.
Run this script; oh, it’s not signed.
Run that script; oh, it needs elevation.

So you adjust what is needed, and then you do it again. The script you need to run doesn’t say “I am unsigned” or “I am blocked.” Until now.

PrimalScript 2021 and Script Explorer now indicate the state of your scripts and other files in the File Browser panel by displaying a color-coded icon before the file name.

It’s pretty straight forward; a ‘blocked’ file has a lock icon, a signed file has a green certificate icon, and a file without a valid signature stands out by, well, by not having an additional icon.


Unblocking a file is a simple right-click away.

”What is that green checkmark icon?” you ask.

It is called “Script Verification” which is a new feature we recently devised. Code signing certificates cost money. Some employers do not want to spring for the annual renewal of such certificates. Some companies still think digital signatures are not necessary ‘inside’ the network.


Another reason digital signatures may not be available is that your entire network is not connected to the internet. The whole process of signing, checking the signatures, and checking the counter-signatures is built around trusted Certificate Authorities – revocation servers and time stamp servers – all of which is an online process.

You can most certainly set this up inside your network, even timestamp servers, without internet access. But the reality is that this does not usually happen. I have not found anyone who has a working offline setup for this, so if you do, please let me know in the comments.

Depending on the requirements in your offline network, adding all of this infrastructure may be overkill. Or, for whatever reason, you cannot get a code signing certificate.

“Why is this so important anyway?” you wonder.

If I wanted to infect someone’s network, one easy way would be to find a script, preferably a complex PowerShell one, modify it with my payload and wait for someone to run it elevated. This can be a multi-stage process involving an email enticing you to click on a link that adds code to the latest modified script you have. Each time you run your trusty “adduser.ps1” it infects another script with its payload until one day you run one of these scripts elevated. Now its on. It can download whatever, install and modify anything it likes. You are unaware because all your scripts behave the same way they always have. Maybe they are a tad slower than usual, but who pays attention to that?

Digitally signed scripts prevent a scenario like the one above. A built-in checksum makes the signature invalid if the script was modified after it was signed. Essentially, changing a signed script renders the script ‘unsigned,’ even though it still contains the signature block comment.

This brings us back to the situation of how to proceed without having a digital certificate. Script Verification simply creates a checksum over your script and stores it in an extended attribute. If someone else modifies the script, the checksum no longer matches and then you get the yellow exclamation icon rather than the green checkmark icon.


It doesn’t always have to be a virus or ransomware attack; if your scripts reside on a network drive or cloud drive where multiple users have access, someone may have modified your application and not told you. It sure will help to see that at a glance, so keep an eye out for these status icons.

Additionally, we added some status check features to PrimalScript. They are, by default, turned off, but you can turn them on if needed.


Regardless of your execution policy, if turned on, PrimalScript will warn you if you attempt to run a file without a valid signature.


Remember that a signed but modified file is simply considered ‘unsigned’ by Windows.


Script verification has three states:
– Not verified, meaning it has no extended attribute.
– Verified, meaning that you have marked the file as good to go.
– Modified, which happens when a verified file gets modified after the fact.


Modified files are marked by a yellow icon with an exclamation mark.

Please remember that these features are also in Script Explorer, which you can freely distribute in your network.

We hope that these added features will make it a little easier to keep your script safe and secure.

As always, if you have any comments or suggestions, please use the comments or our support forums.