So let's go into our Windows environment, and we'll first look at
how we set execution policy levels, and then also we'll look at
how we remove execution policy levels.
So here we are on our Windows machine, and the first thing we're
going to do is look at getting our execution policy, and I can
simply type Get‑ExecutionPolicy.
This will allow me to see the execution policy that's
currently set for me as the specific individual.
If I now say Get‑ExecutionPolicy ‑List,
then you can see it gives you the breakdown of like,
well, this is the LocalMachine, this is the CurrentUser,
this is the Process, etc, so we can see very quickly if there's another
configuration that might be impacting what we're doing.
Now we can also go back to ExecutionPolicy and
obviously set a ‑Scope at this point.
So I can say LocalMachine, and of course,
LocalMachine is set to Remote, whereas if I go back to CurrentUser,
you'll see it's Undefined.
Now, if we were to set this value,
then of course we would have two specific policies in place.
So to set one,
we can say Set‑ExecutionPolicy, and I'm not just going to say Unrestricted,
I'm actually going to scope it down to say CurrentUser, and then
I can say ‑ExecutionPolicy, and let's say Unrestricted like so.
If I now rerun my ‑List option,
you'll see I've now got two ExecutionPolicy options available.
We have the LocalMachine that's configured for Remote and then
the CurrentUser that's set to Unrestricted.
So depending on what we set and how we set it will determine the
impact that it has on our PowerShell script.
So let me just clear this here.
Let's go back and say ExecutionPolicy here, and you'll see I can have
a Set option. Notice when I don't pass a value,
you can't tab through anything, you need to go through and type it
manually, whereas when we do Execution, Scope. Policy,
we can tab through the values, so just a bit of a tip there.
Sometimes you type and you forget to put it in,
you'll have to manually type it all out.
I'm always one for auto‑population and auto‑complete and IntelliSense
and everything else, so it works really well that way.
Now, of course, we do have another option available to us.
So I'm going to delete this here, where if I wanted to
relaunch a specific PowerShell option,
so I could say pwsh.exe, and I could say ‑ExecutionPolicy, like so,
so I'm going to pass that property, and I'm going to
say Unrestricted and press Enter.
Now this will now launch.
You can see it's in a different directory because I'm actually
inside a different subfolder when I go and launch PowerShell,
and it's now set to that value.
If I now say Get‑ExecutionPolicy, you'll see it says Unrestricted.
If I now say get the ‑List, you'll see that there's LocalMachine is Remote,
the CurrentUser is Unrestricted, and my Process is
Unrestricted, so now I have three different ones.
If I click exit out of here,
it's going to clear that down and say Get‑ExecutionPolicy,
Get‑ExecutionPolicy ‑List.
You'll see that my Process one has now gone back to Undefined.
So that pwsh, or the PowerShell executable, only lasts for the
duration of the session that you decide to set it to.
Now, of course,
our last thing here would be if we wanted to remove the value that's there.
So let's say I don't need the CurrentUser one now,
I can say Set‑Execution policy,
I'm going to say ‑ExecutionPolicy Undefined, and then my ‑Scope is
going to be CurrentUser, and now I can go back to my ‑List and you'll
see it's reset that value to Undefined.
Now, you may be wondering why we do this.
Why are we worried about execution policy? Well, ‑ExecutionPolicy
means we can control how things get executed,
whether it's commands, whether it's scripts,
etc. But what it really means is, especially when we start
investigating and looking at machines,
especially for you as a forensics person looking at it, is
sometimes when machines are compromised,
these values are changed. They are adjusted to allow
execution of other malicious type of scripts.
So if you come into a machine and you know,
for example,
that the corporate policy is always going to be RemoteSigned and all of
a sudden you get in and it's set to Unrestricted, there may be a chance
that however the machine was compromised,
they may have ran something like that,
which means there's a higher chance that malicious
PowerShell might have been executed.
So that was really simple.
We use Get‑ExecutionPolicy to retrieve either individual, well,
the current execution policy or a list based on the scopes, or we
can set the execution policy to be something or we can set it back
to empty by using the Undefined option.
In reality, what we should be doing from a security perspective,
is making sure that they are set to the least privileged version or the
lowest level that is required by end user machines.
And then we as administrators should only I suppose elevate up to
things like Unrestricted if and when we need it.