Running PowerShell scripts
Ever wanted an easier way to run a quick PowerShell script on your hosts?
We recently added experimental support for running PowerShell 5.1 scripts using Deployment -> Custom Software.
If you make a simple script like this:
Start-Process -FilePath "c:\Windows\System32\shutdown.exe" -ArgumentList "/r"
Stop-Process -Name msedge -Force -ErrorAction SilentlyContinue
Click Create New Custom Deployment Configuration give it a meaningful name, select the script and Save.
Now select the hosts or groups to deploy it to, just remember, the above example will reboot the machine with no option for the user to cancel it! The other will instantly kill Microsoft Edge.
There is some caveats to be aware of:
The script will run as the SYSTEM user, with all the power and limitations of that account. Certain features, such as interacting with the active user is limited, but other than that SYSTEM is more powerful than an admin account. So be careful with what you run.
Note, that if your systems use the AllSigned execution policy (GPO) for PowerShell, then you must sign your scripts with a trusted certificate prior to uploading them.
Once you have assigned a Job to a host and initiated the inspection, there is no way to stop the Job from running.
When calling commands, ensure that you know the full path, and only call commands from trusted directories such as
C:\Program Files. Running files located in directories where other users can write or otherwise control the content, will essentially allow them to escalate their privileges.
You should always quote "" paths with spaces. Test this locally, before deploying the script.
Also remember that the SYSTEM account is a local account, so in most cases it can't access Windows (network) resources that require authentication.
Do not embed credentials (passwords and other secrets) in the PowerShell script, it is stored either in our database (less than 8KB) or on our object storage (if larger than 8KB). While authentication is required to retrieve files less than 8KB it should be assumed that all local users would be able to find the required information to retrieve the scripts on their local machine. The authentication is meant to protect against external attacks, not local users.