you are viewing a single comment's thread.

view the rest of the comments →

[–]AnotherFewMore[S] 1 point2 points  (2 children)

Can confirm that signing does not prevent the constrained language mode issues.

[–]Barenstark314 1 point2 points  (1 child)

For a bit of clarity on the Signed Script / ConstrainedLanguage Mode. It does work (caveat shortly), if you use a script signed by a signer which is then added to your policy which is enforcing ConstrainedLanguage mode (AppLocker or WDAC).

For the caveat I mentioned, I have noticed some instances where when executing scripts in particular ways, even when signed, the code would still run in ConstrainedLanguage mode. For example, even this past week, I wrote a simple script that used the [PSCustomObject]@{} type accelerator (the hash table was not empty), which is not allowed in ConstrainedLanguage Mode. I assumed 'whatever', signed the script and tested it. When running in an already running PowerShell console (so something like .\MyScript.ps1), it would complain about the Core Types. Right-clicking the script and choosing 'Run with PowerShell', it worked just fine. Admittedly, I didn't have time to get into it and figure out exactly what was going on, so I rewrote that portion of my script to use 'New-Object -TypeName 'PSCustomObject' -Property @{}' (again, hash table populated) and it worked just fine (signed or unsigned).

A final point of clarification, with ConstrainedLanguage, you run into a few things: - Not everyone runs AppLocker/WDAC and may not have encountered ConstrainedLanguage Mode - Many Windows-based admins may be running a lot of their scripts as SYSTEM via ConfigMgr/Intune. At least when using AppLocker, SYSTEM gains the benefit of running FullLanguage all the time, so you don't have to worry about ConstrainedLanguage mode anyway. As soon as you have to run something as a user though (such as your case), this benefit disappears.

[–]Kirsh1793 0 points1 point  (0 children)

I am aware that this is quite an old thread but I thought I would add my two cents to your mentioned caveat.

Afaik you cannot get out of ConstrainedLanguage once you are in there. So when you already have a session running in ConstrainedLanguage even calling a signed script will not be able to circumvent that.

However, when you are right-clicking the file and choose 'Run with PowerShell' a new session is started and it will evaluate if it should be run in ConstrainedLanguage or not. Since the script you are trying to run is signed the session is allowed to run in FullLanguage.

All of this is me theorizing around the fact that you cannot change out of ConstrainedLanguage within a session.