Up to this point, we focused on setting traps,
actively hacking the hacker to discover them in our systems,
allowing us to cut them off and recover faster.
We're now going to flip that and look at ways to actively monitor and
audit our systems to harden our defenses and prevent the attacker from
getting into our networks in the first place.
PowerShell is free and widely‑available tool that comes standard across
Windows operating systems and is now open source and cross‑platform
compatible to be able to be executed in all sorts of devices.
I mean, what can go wrong?
Looking at the MITRE ATT&CK Matrix, attackers utilize PowerShell,
whether in phishing and malware campaigns or to
automate their attack essentially,
changing settings and registry keys to open backdoors,
pulling down files and other scripts, or executing a payload.
Because of this,
PowerShell has an execution policy that acts like a safety net of sorts to
control which scripts can be run and how far they can go.
The execution policy has seven levels that controls the amount of access the
script has or if it even can be executed in the first place.
These are applied at the system level, user level,
or a particular session,
but it also can be set at the group policy at the domain level.
Now going through these, AllSigned allows the script to run,
but only from a trusted publisher for both third‑party and locally created.
It will be prompted if a publisher is not trusted yet,
and the risk that the scripts may be signed,
but still malicious.
Bypass, nothing blocked, no warnings.
YOLO.
This policy should only be set when the scripts are incorporated
into a large program that controls the security.
Default,
this will set the default policy to restricted for Windows
clients and remote signed for Windows servers.
We will get into those here next.
RemoteSigned, default for servers.
Allows the script to run,
but requires a trusted publisher digital signature for third‑party scripts,
but not for locally‑written ones.
Restricted, default for clients.
Allows the individual commands to be ran, but not scripts.
Undefined means there is no policy set for the current scope.
If undefined in all scopes, the Default policy will take effect.
Finally, Unrestricted.
This is the default for all non‑Windows boxes.
Unsigned scripts can run, so there is a risk for malicious scripts to go through.
There will be warnings if the script is not local, though.
Okay, taking a look in our demo here,
I want to take a look to see what is my current
execution policy across all of our scope.
I could see that everything is now set to Restricted, which is the default.
If I wanted to set up a new policy, if I wanted to change that to,
let's say, Bypass.
I can run that really quick, so it's just a simple Set‑ExecutionPolicy.
I'm then going to set the policy to Bypass.
Now when I look at my policies, I then see there's the Bypass set.
I can also see what is the effective policy set.
So if I remove that list, I can just see which policy overwrites everything else.
So the Bypass policy is currently what will be
executed on when I try to open a script.
If I want to set that back to the Default,
I can just go back to my Set‑ExecutionPolicy and
change it back from Bypass to Default.
Now when I look at my execution policy again, I'm now on Restricted.
I will note you are required to have admin rights in order to set this.