If you want your Windows computer
to be significantly more secure, I've got three settings you're going to want
to change. Two of them are quick and easy, the third one takes a little bit more time,
but it's still not difficult and I'll walk you through it. First, let me quickly explain
some context, because I always think you should understand why you're doing something
instead of just blindly following a tutorial. You see, all the security settings I'm going
to be talking about involve PowerShell, which is an important component in Windows,
kind of like Command Prompt, but way more powerful. It's not only its own scripting
language, but also a command line interface, and it basically lets you do almost anything you
want on your computer through the command line. However, for that same reason, a lot of malware
will use PowerShell to get a foothold in your system. And apparently anywhere from 50
to 75% of malware will use PowerShell, at least partly, in its attack.
This could include running malicious script files or just running malicious
commands directly. And in this video, I'll show you how you can add protections
against three different methods of attacks. First, we'll be disabling an older version of
PowerShell that's also installed in Windows by default, but is very vulnerable. Second, I'll
show you how to limit the types of commands that PowerShell can run, which will block most of the
things that malware will usually try to do with PowerShell. And third, I'll show you how to set up
a policy to block PowerShell scripts from running, and more importantly, in a way that malware
can't bypass it the way it usually does. Again, that one will take a little bit more time, but mostly just because there's more for me
to explain. One final note before we jump in, it's important to remember that this is not
going to make your computer bulletproof or anything. There are a ton of ways that malware
can get you. This is just a way to get rid of some of the low-hanging fruit, and it's well
worth the low amount of effort these take. So let's get started. Alright, so first
we're going to remove PowerShell 2.0, which is a old version of PowerShell that's
included just for backwards compatibility, but it's very vulnerable and often used to
bypass the rules we're going to set up. So what you want to do is go into the start menu
and search for Turn Windows Features On and off. And then when that comes up, go and find
Windows PowerShell 2.0 and uncheck that. So it's unchecked, and then hit okay. It might
ask you to restart. You can do that now or later, but once that's done, you're set. Now to
be clear, this doesn't remove PowerShell altogether off your computer, just that really
old version that almost never gets used. Alright, next we're going to set up what is called
Constrained Language mode, which limits the types of commands that can be used by PowerShell,
whether running the command directly or in a script. And this one is important because even
though we're mostly going to be blocking scripts later, it'll still be allowed to run the same
commands individually, just not as a script. So we want to limit the actual commands that
can be run overall. I'm not going to get into the technical aspects of exactly what commands
it restricts, but Microsoft does have an article where you can read more about that if you want.
Alright, so we can start off by checking the current language mode on your computer by just
opening up PowerShell and running this command. You do $ExecutionContext.... I'll
put this in the description so you can just copy it. And by default,
it'll probably say Full Language, which means no restrictions. So what we need
to do is open up the start menu and search for Environment Variables and click where it
says, "Edit the System Environment Variables." Then it'll take you to the system properties in
the advanced tab. At the bottom of this window, click where it says Environment Variables.
And then at the bottom of this next window, below where it says system variables,
click New. And you're going to want to create a new variable with the name set to
two underscores and then PSLockDownPolicy, just like this, but there are two underscores in
the beginning, and set the variable value to four. And I'll put that in the description too, if
you just want to copy it. After hitting okay, it should all be applied. And now
if we go back into PowerShell, we're going to open a new window and you
type in the same command. It should say Constrained Language. Now I do want to
make an important point that this is not a hundred percent guarantee because
if malware has the correct access, it could just go and change that environment
variable and then run whatever it wanted. But that would require escalated privileges
and the malware would have to be programmed to look for that and change it. But this should
still help protect you if the malware needs PowerShell at the early stages to get going
in the first place. Alright now finally, for number three, we are going to
be dealing with PowerShell scripts. And this one takes a little bit more time to
explain, but stick around because I think this is actually the most important one. You see, by
default in Windows, PowerShell has what's called an execution policy that in theory should block
any scripts from running on the computer. So if you try to run a PowerShell script like this,
it will say that running scripts is disabled. And this might be getting a bit technical, but
if you use this command to list the execution policies of the different "scopes" they're called
on the computer, you'll see it says Undefined, the default, which blocks them like you saw.
However, it's not really even considered a security policy because it can be bypassed
so easily by just using a command like this, which changes the execution policy to be
bypassed without even running as an admin. And now after running that, I am able to run
that same exact script that was blocked before, really with just one command. So because it's so
easily bypassed, the execution policy is mostly there just to prevent the user from accidentally
running a script unintentionally. But that also means that malware can easily bypass it
just from running that command first. However, there is a way to block the
ability to bypass the execution policy, which I'll explain now. Alright so for this
first step, if you have Windows Home Edition, just hold on a second. If you have
Pro Edition, this is a bit easier. So in that case, just open up the Group
Policy Editor and navigate to Computer Configuration > Administrative Templates >
Windows Components, and then Windows PowerShell. And once you're here, hold on while I
explain what to do for Home Edition. For Windows Home Edition, you do not
have Group Policy Editor. So instead, you can use a program that's free called
Policy Plus, which can basically do a lot of the same thing. I'll put a link to it
in the description for the GitHub page. It is open source. So just go to the
releases page and download it. And when you run it for the first time, if it
asks you to download the policy settings, do that. And then once you have it open
and set up, we can get to the same place I just showed by selecting Computer
in the dropdown. And this here is basically the equivalent of the Administrative
Templates location in group policy editor. So from here in Policy Plus, just navigate to
Windows Components and then Windows PowerShell like before. Here it's the same for both Pro and
Home Edition. Just look on the right hand side and double click to open the "Turn on Script
Execution" settings. Here for most people, if you never run PowerShell scripts,
and I'm not talking about commands, but actual script files, you can just switch this
from Not Configured and change it to Disabled. This will block any users and admins from
being able to run PowerShell scripts, which is the default in Windows anyway.
This just makes it not possible to bypass, which I'll show you in a second.
You could also set this to Enabled, but select "Allow Only Signed Scripts" to allow
only scripts signed by trusted certificates, if you know what that means. But
if not disabled is probably fine. Then just hit OK. And if you're on Home Edition
with Policy Plus, there's one extra step. Just go to File > Save Policies, and that should
make it work. Now I do have one more thing you'll want to do, but first let me at least
show you that new setting in action. Now, if we go and use that same bypass command
before, you'll see that it gives an error saying how the bypass policy applied, but it
was overridden because of what we just did. There's a more specific scope, and you'll
see what that means in a second. If we try to run the script anyway, you can see it
was blocked from running just like before, despite using that bypass command. And
if we list the execution policies again, we can now see that the "MachinePolicy"
scope is set to Restricted, which is actually the same as Undefined,
just a more specific setting. And that will apply no matter what
other policies are applied at other scopes. And if you're wondering,
no, you can't just use the command to change the Machine Policy like we did
with the others. Even as administrator, you'll see that it does not let you do it here.
You have to do it through the Group Policy Editor. And the thing it mentioned before
about the "more specific scope", it's talking about that machine policy one
there. Now hold on, because like I said, there's one more thing to do. You see,
Microsoft also has a newer version of PowerShell that can be downloaded separately
called PowerShell 7. And this is different from the Windows PowerShell that we've been
using, which is built into Windows itself. Anyway, the thing is that PowerShell 7
does not actually respect the execution policies for Windows PowerShell, which is
what we just set. And this is important, even if you do not have PowerShell 7 installed,
because malware can just drop or bring along its own copy of PowerShell 7 and use that
to get around your execution policies. Therefore, we are also going to set up
some execution policies for PowerShell 7. And fortunately, this does not require
you to install PowerShell 7 to do so. It just takes a couple steps. And this way, even
if the malware includes its own copy of the PowerShell 7 executable, it should still
respect the policy to not run any scripts, hopefully blocking what the
malware is planning to do. Alright so to do this, basically it's the
same process for both Home and Pro editions, fortunately. But what you want to do is go
to the GitHub page, and I'll put this link in the description for PowerShell 7 and
go to the latest release. And download the one that ends in "win-x64.zip",
or whatever the latest version is. For this, it's 7.3.6. So once you download and
extract that, open up the folder. And we just need two files from in here. The rest we don't
care about. And those would be these two here, PowerShellCoreExecutionPolicy.admx and
adml. For PowerShellExecutionPolicy.admx, we're going to copy that into this
directory, C:\Windows\PolicyDefinitions. Then copy the PowerShellExecutionPolicy.adml
one, but for this, we're going to put it in a subfolder, the "en-US" folder
inside that PolicyDefinitions directory. And this is just
the English language folder, the adml file is a language file. So if
you use Windows with a different language, it might be a different named folder, but just
put it into that one, it should still work. Now in Group Policy Editor,
under Administrative Templates, you'll see a new thing for PowerShell Core,
which is PowerShell 7. In Policy Plus, you should see the same thing in PowerShell
Core. In both cases, again, on the right, open up the "Turn On Script Execution" settings,
and again, either set it to Disabled. Or for Enabled, you can just choose to have it use
whatever the Windows PowerShell setting is. So to kind of mirror that and keep up to date
with that. But if you don't use PowerShell 7, I would just set this to Disabled anyway.
And now you should theoretically be covered, because most of the time malware just bypasses it using that one command. But with this,
it's not going to be able to do that. So it's probably only going to be the most
sophisticated malware that will even account for something like that. You'll just have to remember
that if you do want to run a script at some point, you'll have to go and change that setting. I
believe that system files like Windows itself in the background can still run scripts,
it's just any users won't be able to. And also keep in mind, even
if you're not running scripts, you can still use commands with PowerShell. So
if you need to do something with PowerShell, usually you still can. So if you made it to this
point, your computer should be significantly more secure against certain types of attacks at
least. Again, this is not a bulletproof solution. There's plenty of other stuff they try to
do, but this covers some bases. Let me know down in the comments what you think. Did you
never know about this kind of stuff before, and now you have it set up? Let me
know. If you did enjoy this video, be sure to give it a big giant
thumbs up for the YouTube algorithm. And if you want to subscribe, I try
to make videos about twice a week, usually Wednesday and Saturday, so it should
be worth it. If you want to keep watching, the next video I'd recommend for advanced users
is where I went through how to kind of effectively "virus-proof" your computer in a way by setting
up an advanced Windows feature called AppLocker. Not for the faint of heart, but I think you'll
find it pretty interesting. You can just click on that right there. So thanks so much for
watching, and I'll see you in the next one.
