Alright, you guys have been asking me for weeks
to make this video that I promised, and here it is. I'm going to be talking about how to set
up AppLocker, a very comprehensive tutorial. AppLocker is basically a tool in Windows 10 and 11
Pro editions and up that lets you create a locked down version of Windows using a whitelist or
AllowList strategy for what programs can even run. So no viruses can just run without
your knowledge because they are not explicitly allowed, for example.
And I've talked about previously how AppLocker is one of the big reasons
why I was not hacked a few weeks ago, even though I accidentally downloaded a
malicious script and it actually tried to run. Now I want to be clear, this is definitely not
for everyone. It is going to have a big trade-off in convenience versus security. You'll be
able to still run any programs you want, but you might have to occasionally go in and
create specific rules for every program. But at the same time, that also makes it theoretically
impossible, or at least extremely unlikely, that you'll accidentally run a virus, or more
likely a program you do trust will download something that is malicious and run it without
you knowing, which is what happened to me. Now of course, nothing is ever 100%. There
could be exploits that get around things, but I would say this is the strongest
security strategy you can use because it's proactive instead of reactive.
So if you're someone like me who is completely paranoid when it comes to computer
security, then this is right up your alley. But if you're someone who's
not exactly technically savvy, you probably want to maybe still
watch it to learn some things or two, but you might not want to go through all this.
Also, this will require you have Windows 10 or 11 Pro editions or higher. I tried to look for ways
to get around it. There doesn't seem to be any. I guess you could theoretically use the Windows
Pro Watermark Edition, but I'm not going to condone piracy. Before I jump in, I guess I'll
give you a quick outline for exactly the different major sections I'm going to be talking about, and
then probably some other topics within each one. And you can of course look at the description for
timestamps if you want to, maybe not skip around, if you are going to use AppLocker, I
would highly recommend the entire video, but if you want to come back to certain parts,
timestamps should be helpful. As you can tell by the length of this video, I was very
detailed in a lot of my explanations. I might seem to ramble or mumble at certain
points, but there will be subtitles. So you can just read those if I talk too fast.
Quick outline. First, I'm going to go over how to get to the AppLocker settings and also
how to create a custom shortcut to get to them much faster than the usual way, because
you're going to have to go into there every time you make a new rule. I'll then explain
how to look at the Event Viewer log to see what things have been blocked, which is also
essential for creating rules to allow things. And of course, I'll spend a considerable
amount of time on actually creating the rules, the different types of rules, how they
might interact. Then I have a whole section with really important info about
how AppLocker interacts with PowerShell specifically. It might seem like an
extra, but do not skip this section. It is critical to getting the full security
out of AppLocker because so many viruses do take advantage of PowerShell. You really
need to take care with that, and do some additional stuff that I'll go over. And that
will also include a section where I talk about PowerShell "execution policies", they're called,
which will block malicious scripts from running. But again, even if you know what execution policy
is, I go into way more detail about more stuff. So you still need to watch that. So yes, this
video is going to be very long. However, I do go over literally everything I know that I believe is
important. Of course, if I forget or need to make any corrections, I'll put a pinned comment. Or I
think you can usually have a thing pop out now. And I guess we can just go to the computer and get
started. The AppLocker settings are found here in the group policy editor, and you go to Computer
Configuration, Windows Settings, then Security Settings, Application Control Policies, and then
AppLocker. And here's where they all are. However, it's kind of a pain to navigate to this
through the Group Policy Editor every time. So there's actually a easier way where
you can create a snap in, it's called, where it takes you literally directly to here.
So that's what I'm going to show you how to do here. So what you can do is search for MMC.exe,
and should bring this up. What you'll do here is go to File, Add Remove Snap in, then look for
Group Policy Object right here, and hit Add, then you can just hit Finish, OK. Then here,
you're going to navigate to the AppLocker, just like we did. So now what we're going
to do is when we found it in this one that we just made, we're going to do New
Window From Here, and here we have a management console that leads directly to
the AppLocker. So we just need to save this. So we'll do File, Save As, and whatever. And
we could put it on the desktop or wherever. So I'll just put it in this folder, and
we can call this AppLocker Settings. Hit Save. And what we'll also want to
do is go to Options, and change this to either of these user modes, whatever full
access, because this will make it so it stays. Otherwise, it'll ask you to save every time.
And then, Yes, save that. So now every time we open it, it'll take us directly
to the AppLocker settings. Alright, now we're in the AppLocker settings, and you can
see there are different sections with rules for different types of files. There's executables,
Windows Installer, Scripts, Package App Rules. And before we even create any rules, what
we're going to want to do is right click, go to Properties, and then we can
basically change these from Enforce, Audit, or not configure, just uncheck it.
And then they won't be enforced, even if there are rules. And actually, what we're going
to want to do here is also enable it for DLLs. You don't necessarily have to create any DLL
rules, but I think you probably want to at least be able to see them, so they'll show up
here. And also, before we create any rules, we're going to want to change all of these to
Audit Only. And then later, once you know how AppLocker is going to behave, you can change
it to Enforce once you understand it a bit. If you just start creating rules and blocking
everything from the beginning, you might mess stuff up. So it's better to just audit it,
check the logs. So to actually see the logs, what you would do is go into the Event
Viewer. And normally, this is where you would have to go. You'd have to go into the
Application and Services, then Microsoft, Windows, then go down to AppLocker, and you're
going to see that there are different views. So here's the EXE and DLL one, and the MSI
& Script, and the other ones that we saw, the different groups that are over here. Now,
again, we don't want to have to scroll all the way into here every time. So what we can do
is just create a custom view. I did that here. And if you want to just copy the
settings, this is what they are. You just, for the event log events, you
just go and check what I just showed you, check this box. Or what I'll do is just put
in the description, this event custom view, I can export it as an XML file. And then all
you'll have to do is right click on Custom Views, Import Custom View, and then look
for the XML file that I gave you. And then you should be able to see
this. And this shows you issues or things that get blocked by AppLocker.
Or in this case, if it's in audit mode, it'll say something would have been prevented
from running. So that way you can again, get everything set up and know what
it's going to block ahead of time. So you don't get frustrated and make your computer
unusable before you have proper rules set up. Now, what you could even do if you wanted it
to open directly to here with a shortcut, like on your desktop. Again we can create
another snap in. So we're going to do the same thing, mmc.exe. Then we go to File,
Add Remove Snap In, look for Event Viewer. And don't forget to hit Add first. So it should
say Local Computer, is what we want to select. OK. Then just go to Custom View and AppLocker. And
we can do this a couple of different ways. So if you want to still have the rest of the
Event Viewer showing, what you could do is just right click on this and say new window
from here, like on the Event Viewer thing. And this will basically look the same as the
normal Event Viewer. And then if you click to select this, this will be open when you go to hit
File, Save As. Actually, first we want to again, go to options and then change this to just Full
Access whatever. Do not save changes to this console. We'll hit OK, and then hit File,
Save As, "Event Viewer AppLocker Blocked". And now if we go into here, it opens the
Event Viewer directly to our custom filter. So that should be easier. Alright, so
now we have everything set up. We can actually use our little shortcut to open
the AppLocker settings and we're ready to actually create some rules. And we can
start off with the executable rules, and you can right click and hit "Create Default
Rules" for all of these to get a starting point. But I personally don't actually like
these default rules. I think for my taste, they're a bit too permissive. But for you,
they might be perfect in a trade-off for what you want to deal with. So here by default, it's
going to allow all files that are located in the Program Files folder to run, any executable.
And all files located in the Windows folder. And then all admins are allowed to run
all files. However, if you're like me, where you're the only user on
the computer and you're an admin, you definitely want to delete this because
that will completely defeat the purpose. It does not ask you to escalate before it
allows it. It'll just allow you to do it. So I would keep that just deleted. And
then we can do the same thing for these other types of rules. So this is like an
MSI Installer. And again, just delete this. Script Rules. This is going to be
batch scripts or PowerShell scripts. Packaged App Rules. This is going to
be Microsoft Store stuff, I believe. And I think the default rule for this is just all
signed app packages. I don't know where the DLL one went. So I'm going to hit Apply there. So that
shows up now. And just do the same rules here. I should also explain which file types
actually apply for these various collections. I'll put them on the screen because
they're pretty easy to just list out. But if you do go to create a new rule,
it'll also show you. So if we do File Hash, for example, and then open the browser,
you'll see that it has a dropdown. And these are the two ones. So just be aware,
if you are looking for a specific file type, you might have to select in
here or it might not show up. And if we go to Scripts, we can see that it
does PowerShell, Batch File, Command Prompt, VBS Scripts and JavaScript. But it's not
going to block things like Python scripts or anything else. It's only these which are
effectively built into Windows. That's why. But it can't control everything.
It can't know everything because Python or some other scripting language,
Windows doesn't have control over that. So in that case, you would be blocking
the executable stage of whatever scripting language compiler would be running. Also,
to be clear, the rules are only going to apply to those specific file types. So if
you create a rule here that creates and Allow for literally anything, just whatever,
this will basically nullify all the rules. This will still only apply to the various script
types that I just showed you. So this won't do anything with executables. So that's why you
also want to make sure that you're putting the rules in the correct location, because
if you wanted to allow all scripts and you accidentally put it in the executables
section, then that's not going to be good. And that's also a common reason I found
where if I thought it should be running and it's still being blocked, sometimes I
just put the rule in the wrong place. Now, this is just a starting point. These
are not actually the rules that I use, but this would get you a pretty good starting
point. Now, one I like to do actually for all of these is to allow anything that
is signed by an EV certificate. Basically, to get a code signing certificate,
you have to go through a bunch of verification steps. It's very rare for malware to ever have
this. Very occasionally it happens, but usually it's caught pretty quick. So what we can do is
create a new rule, and then we're going to do Allow. And by the way, once you enable any rules,
it's basically like whitelisting or allow listing. So if there's any rules at all, then unless there is an allow rule for something,
it won't run. So you don't need to deny anything using deny rules for things to be
blocked. So right now, basically, we need to add things that we do want to allow. So we can do
Publisher, and it has you choose a reference file. And a reference file basically is anything
that's going to be signed by the company that you're looking for. In our case, we want anything
that is signed by Microsoft. So we can go into the windows and just do Regedit, for example.
And you can see it pre-fills this. However, we don't just want Microsoft to be
allowed to run in this particular rule. So what we can do is just do custom values, and
then we would set all of these to just be a star. And then this is, I think you can either leave
that blank. Oh ok. And then we'll hit next. And then it says add exceptions, but we're basically
allowing anything signed. So we can do "All Signed". Now, you might think, if you know
anything about code signed certificates, will this allow literally
anyone to self-sign a package? And the answer is no. It will only allow it to be run if it's a EV or Organizational
certificate signed by a root authority. So you will not be able to self-sign and have that count.
So it has to be like a trusted certificate. Now, I personally delete these two rules, all located in
the Windows folder and the Program Files folder. For a lot of people, this is probably fine to
allow files located in the Windows folder and the Program Files folder, because presumably by
the time an executable gets into those files, you already trusted the installer or the script
that would have put the things in there, if that makes sense. So it's not like you're downloading
malware directly into one of these folders. Usually first, there's going to be a script
that would copy it into there or something like that. I personally just deleted these,
but you might want to keep this in just so after you installed something or there's
something already in the Windows folder, you can trust it. But if you want to be
really secure, then you can just delete these. Now for the windows installer rules,
notice that there's already a default rule that says all digitally signed
windows installer file. And this is the same that we did. This actually says
0.0.0.0 and above. And then this one says All Windows Installer Folders that are
in the Windows slash Installer location. I believe you can just delete this without
really any consequence because anything that Microsoft puts out should still be signed. So you
could probably just delete that and not have any issues again, but I would do this in audit mode
first. Now for script rules, I would be more strict. So first let's create a rule that allows
again, EV signed scripts, code signed scripts. So we can just again, do the same thing. But
you're going to notice that nothing is showing up because it's restricted to just PowerShell
scripts, Batch Scripts, and we don't really want to go searching for a script that's signed
by Microsoft just as an example. So what we can actually do is type in Regedit again, and it'll
still open it even though it's not a script. And we're only using this as a reference
file. We don't actually care about it having to do this file specifically. And again,
we're just going to go do custom values, set all this. We can either set this to, you know, zero or a star, doesn't really matter. Just
hit Next. And again, we do "All Signed". And then I personally would delete that rule,
because in my case, the virus that I came across, the first thing it did was try to copy a script
a script into the C:\Windows\Temp directory. So if it was able to do that,
the script would have been able to just run because there was
a default rule for that. So I have all signed scripts, and I found that for the
most part, I believe scripts in the C:\Windows directory are all signed by Microsoft anyway.
So I don't think it should cause any problems, and you can always add exceptions or
allow rules specifically if you need it. And again, Program Files, you can decide
whether you want to allow this. Because again, probably if there's going to be malware, it's
going to have to be able to copy itself into the Program Files folder in the first place. And
presumably there would be rules like [for] the scripts or executables that are going to be
not allowing that to happen in the first place. But if you want like a double layer,
then you could just delete this. So I'll just show that here. Now for DLLs, I would have restrictions on these. DLLs are
actually executables in themselves and a lot of malware will be packaged within a DLL. So I
would definitely restrict that too. And again, same idea with this, with the DLLs located, you
can allow Microsoft DLLs, but this is a path rule. So I would probably again in audit
mode, try just deleting this one, but changing it to a publisher rule. Because
again, you don't know if malware is going to copy its DLL into the Windows folder and then
try to run it. So what we can do is same thing, but this time it's going to be a bit different.
So we can do Publisher again, reference file. Oh, that's why I couldn't find regedit
before, because I went into System32, but if you're just going to C:\Windows, you
should be able to do that. Hit OK. And remember, even if it's not a DLL, it'll still
show up. And here we can change the Scope. And I just realized that I could
have just dragged that up the whole time. So yeah, just do that instead of having to type
everything in manually. I guess you can do that too, but for the previous ones, that's probably
a lot easier. But we want to now allow anything that is created by Microsoft, obviously
to be allowed to run. So we're going to do Publisher and Next, and we're
going to say "All Microsoft". And so anything that's signed by Microsoft
Corporation will be allowed to run. And this applies throughout the entire system.
So presumably all the Microsoft DLLs are going to be signed. So I would delete that.
And then I would at least create a rule to allow signed DLLs. So we do the same thing,
and we can just drag it up to any publisher. Hit Next. Now I want to be clear that this
is kind of a redundant rule here. Because if there's all signed, then that's obviously going to
include Microsoft, but I just like to be explicit. And again, if you maybe don't
want this All Signed rule, then you have to create this one
separately anyway. And then again, I'm probably going to try and delete that,
see what happens, because we're in audit mode. And then for Packaged App
rules, all signed packages, that's probably fine from the get-go. Now
inevitably, you are going to come across programs that you want to run that maybe are
not signed or don't allow one of these rules, and you want to manually allow it. In that
case, what you're going to want to do is, well first, just so I can demonstrate
it, I'm going to change this to enforce. And then I have this example here. This is
an unsigned file, and if I try to run it, you can see it says "blocked by your
administrator". This is what would happen. It might not happen every time if it's running in
the background, but if you try to run it manually, this is usually what will come up,
and obviously you know what that is. If you're not sure what just tried to run, again,
you'd go back into the AppLocker Event Viewer and hit Refresh, and then look at the most recent
one. You can see, it'll tell you that "example.exe was prevented from running" and the location.
So say we wanted to explicitly allow this, what we would do is in the executable rules,
make sure it's in the right section... So we do Create New Rule, and then
it's an Allow rule. And probably you want to do File Hash. It's the most secure
one. You could do Path and use wildcards, I'll explain that in a second, but File Hash
will just allow that exact file. So we'll do Browse Files, find that, and you could
actually select multiple if you wanted. So if you had like a whole bunch, you could just
copy them all, but let's just do this. And again, if you don't see it, check to see if the
drop down, if it shows down there. So if it's a .com file or .exe, then you do
hit open, and here's where the list of multiple would show up if you have multiple
ones. So we can do "Manual Allow Example", and usually what I do, is I have a set of rules
that's just called "Manual Allows" like this, and then anytime there's something I want to
add, I don't create a whole new rule for it. I just add it to this one using this,
and it'll again make a whole list of it. So now this should run, and
now when we try to run it, it does, it works. It popped up. Now one thing
I should mention is sometimes it takes a second for the rules to kick in. So if you go and create
a allow rule and then immediately go and run it, and it's still blocked, just give it a second
because it might take a few seconds for the rule to kick in for whatever reason, and if it's
still not working after like 15 or 30 seconds, I would go check the rule to make sure that you
applied it correctly. Because I've done that, maybe I picked the wrong file or something like
that. And like I mentioned before, if you're in audit mode, you're going to get warnings in the
log, not an error. So here is an example of a DLL, and I'm in audit mode for DLLs remember, that "was
allowed to run but would have been prevented". And I forget what this is for, but "Native
Images", I'm pretty sure that's legit. So I would probably want to go
in and make sure that I allow anything that is legitimate before
I go and start enforcing it, because it might mess stuff up. DLLs are pretty
important. Now notice how we created these file hash allow rules, but there are these like,
path ones. So this allows an entire path. So %WINDIR% is the same as C:\Windows,
and then there's this asterisk, which is a wildcard. So we can create that,
for example, if there's a program or like a location where you don't care what's in there,
you just want to allow anything in there, maybe it's like a personal folder for
testing stuff. So we can do Create New Rule, and then hit Allow, and then we're going to select
Path, and here is where we would type it in. So we can just do like
Downloads slash Test Folder, and what you would then do is use a wildcard.
And you can construct this a few different ways actually. So if you do this, it's just
going to allow anything that's an executable, because this is an executable rule. If
you created this in the script section, it would allow any scripts to run, but
in this case it's just an executable. Or what you could do is, say you wanted to
only allow batch files within this certain directory. And I know this is in the
executable rule, but just pretend that it's a script rule. What you would do is,
if it's in the same exact folder as this, you could just do *.bat here. And I
do want to point out a difference. If you have a rule like this where it's *.Bat, it
will only allow it in this folder specifically, and you might think, well duh, but hold on. So
this would allow in the Downloads\TestFolder blah1.Bat to run. But let's say you also
had batch files in a subdirectory here. If the batch files are only
in the subdirectory like this, and this one wasn't here, then what you
could do is just create a rule like this. So TestFolder, and then this
basically says "any subdirectory", and then "any batch file in any subdirectory",
and this applies multiple down. And that would allow you to run this. But if you had batch
files that you wanted to allow in both this folder and subdirectories, you
actually have to create two rules. So you would have to create this one, and one for the main folder like this. So just be
aware that, took me a bit to figure that out. Now there are exceptions that you can create,
and it's basically the same thing that we did before. So you can create a Publisher, Path or
File Hash exception for a rule specifically. So say we wanted to create an
exception for this default rule, where it allows anything in the Program
Files folder except some publisher. We could again go into here, it'll ask you for
the reference file, or we could do a Path, or we could do a specific file that's not
allowed. Or we could also create a deny rule. Now deny rules might seem redundant
and unnecessary because everything is blocked by default unless there is an
allow rule specifying it. But you could use a deny rule because a deny rule
always overrides any allow rule. So if you literally had a rule to allow
a certain file hash, and then you had a deny rule for the same exact file hash,
and I actually went and created that here. So I have an example allow rule and a deny allow
rule. So you're like, well, which one wins? Well, let's find out. If we try to run it, you
can see it is blocked. So the deny rule always wins. So that can give you a little
bit more control. In some circumstances, it might be easier to just create deny
rules instead of exceptions for a bunch. And that could also be possible if you
might have overlapping allow rules. So say there is a allow rule that allows
files in the Program Files folder, and it's a signed file. So it would be
allowed by both of these rules instead of having to go into the exceptions
and creating it in both these rules. You could just create one deny rule in that case.
Now here I have a bunch of additional rules set up that I can explain. And what I'll do is actually
just export this policy so you guys can literally just import it. I'll put a link in the description
so you don't have to have all this set up. So by default, it'll allow all signed stuff, and
then you can add or change these as you want. So let me explain a couple of these first.
Some of these you might not have thought of. So these are ones, I call them "Toggle", or I label
it like this. And that's because some locations you might want to repeatedly allow, like this
Temp folder in the AppData. A lot of times, if you try to go to install a program, even if the
installer is signed, then you might get a issue with something that it uses during the install
process being blocked that you want to allow. So in that case, I have this deny rule that allows
anything in the temp folder. And what I can just do is change that to Allow, and then Deny it again
once the install is finished. And I have that for the executable as well. If you want to be more
secure about it, you can go and specifically name the file exactly as a Path, but that
might be a little bit more work. So that's what this "toggle" one is. Now for some
of these, I also have some legitimate programs blocked that are sometimes used by malware.
And because I don't really use these myself, I just have them blocked. So one is
Process Hacker. It is a legitimate program. It's similar to Process Explorer, but
a lot of times, again, malware might use it. A lot of antivirus actually blocks
it by default anyway. Fortunately, it actually has a... it's actually signed.
So I can just block that publisher, because I don't know what else they publish,
but probably not anything I'm familiar with. So I blocked that publisher, so that's going
to block any versions of Process Hacker. And the reason I don't do a hash is because
then you would need to block every single version of it, whereas all of them are probably
going to be signed. And you could think, well, what if they just, you know, use an unsigned
version? Well, then it would be blocked because it's not signed. So this should
specifically only block Process Hacker. I do the same thing for NirCMD, legitimate
program. In this case, I did have to use a hash because it's not signed. These are like
the 32 and 64 bit, and then there's two of them, I don't know why. However, the program has
not been updated in a while. The most recent version is from like 2019, and I don't think
he even has a place to download old versions. So just blocking in this case is fine for this
one with hashes. Now for the rest of these, block all screensaver files. I would recommend
that almost no one uses screensaver files anymore, and they are executables, not many
people know that. Now block ".com" files, these are another type of file that
not many people know are executables. I would definitely block this because
sometimes hackers have been known to name a file and use the .com to trick you into
thinking that the file names are referring to a website. Like YouTubers were getting hacked
because the file might be "Contract For Thing on Youtube.com", but the
.com is the actual file extension. So it's good to have this blocked
explicitly just in case, you know, you don't know if there is some allow rule you
have that might get caught up allowing this that you don't intend. So I would just block it, and
I do have exceptions for Microsoft of course, and then I also have a specific
file from Adobe for After Effects. I literally did a search on my computer,
and this was the only other .com file that was not from Microsoft. So I just added
a publisher rule for that specific file, and it's not a hash because if it
gets updated, it still is signed, so it'll still allow. So that is one thing to
consider if you want to allow a specific file that's signed, and you want it to continue
being allowed even through an update, you could do a publisher rule to allow and
just set it to file name, not the file version. So it'll allow anything by
that Publisher, Product Name, File Name. And you might be wondering,
wait a minute, if the file gets renamed, then it's gonna break the rule. But that's not
actually the case. So let me show you something. Here is a program that I publish. It's my AI
Meme Generator, and this is digitally signed, but before I signed it, I just had it named
AIMemeGenerator.exe. And the important thing to know is when a file is digitally
signed, it includes the original file name. So assuming it's digitally signed, there
should be in the details a Original File Name, and that is what the rule will be applied to. So
you could name this whatever you want. It's still going to allow it, even if it's a different
file name, because the original file name is the same. And that actually comes into play
in these rules that I have here, and I can explain why I'm blocking PowerShell. But basically
PowerShell is obviously very important to Windows. It's used by a lot of stuff. However,
a lot of times what malware will do is copy the PowerShell executable out of the Windows
directory somewhere else and then use it for malicious purposes. So what I did was create rules
for... I'll do the PowerShell regular one here first. So it's a deny rule for the Publisher, and
you might think, whoa, blocking Microsoft. But no, it's blocking PowerShell.exe, and you're
thinking, okay well that's gonna block it, right? But no, then you create an exception, and these
are where I found, personally, PowerShell to be located originally with Windows, where it should
be. So as long as PowerShell is running out of one of these directories, which it should be anyway,
it will be allowed to run, but if a program copies it anywhere else and then tries to use it, it
will be blocked. And remember, you could say, oh, well it's just gonna be allowed if they change
the file name because it's not PowerShell.exe anymore. But remember, it is gonna use the
original file name with the signed signature. Why don't I give a quick demonstration
of this. So I literally just copied PowerShell.exe from the Windows directory,
and why don't we rename it to "fakename". And then if we go into the AppLocker
settings, Executable, Create a New Rule, and then do a Publisher, and we
then use that as the reference file. You can see it still says PowerShell.exe
because that was the original signed name. So it doesn't matter what you rename it,
it'll still work. So renaming it won't do anything. And again you could say, well what
if they remove this signature? Well then it won't be signed anymore, and it won't
run at all. So that's how I have that. Now, if you decide to use this, I would
not rely 100% on these paths. This was the case in my computer, but depending
on when you watch this in the future, it might change. So just keep an eye on
that while in audit mode, or of course you can just not use this rule at all. And
then I also have a rule for PowerShell ISE. This is their IDE, basically. And that can be used
to run PowerShell scripts as well. Same thing. And then here actually is another one for PowerShell
7. This is a newer version of PowerShell that is installed separately, and this one is actually...
apparently the original file name is pwsh.dll, even though when I looked at it, it was .exe,
and that just goes to show that originally, apparently it was called PowerShell.dll.
But it doesn't matter what's called. And then here's where it is installed to. So
it's allowed to run out of these, but it's not if some malware brings its own copy, for example.
I also did create another rule for pwsh.exe, where I manually typed this in, because like I showed
you, the other one was dll. I wasn't sure if there might be versions of the PowerShell original where
it is .exe, so I just created that one as well. That might be unnecessary, but that's the case.
And again, the exceptions are the same. And again, like I said, what I'll do is export this
policy as an XML, put in the description, a link. So you can just install it yourself,
and it will replace all your current rules. So don't go and create a bunch of rules and then
import it, because it will overwrite everything. So you want to do this from the beginning. I
will have it configured as Audit Only to start, and then if you want to enforce these,
you're going to have to change them to enforced yourself. And I don't know if you'll
have to do this yourself, or if that will work with the policy that you import, but maybe
just check to make sure the DLLs are there. And again, if you see anything weird happening,
you're going to want to check in the event log viewer. Now I do also want to point out, you're
going to see a bunch of these entries for "PS SCRIPT TEST" thing .ps1, and this is okay. This is
basically just PowerShell, I think every time it runs, uses these scripts to check if AppLocker
is enabled and blocking PowerShell scripts. So these are normal. I would not create
any kind of rule to allow these. That's on purpose so that PowerShell will know
that it's blocked and run PowerShell in a constrained language mode, it's called.
I'm not going to really get into that, but if you see a bunch of these,
just know that that's normal. You might have to kind of dig through multiple of
these. They kind of show up and they're randomly named. Now another thing, if you don't know
what I'm talking about with PowerShell 7, and you don't have it installed, I would
just go into these exceptions and delete it and just block it altogether.
If you don't have it installed, there's no reason it should be running,
and this will just add some protection in case something tries to copy itself
into one of these locations to still run. Now I might add more rules before I upload them
that I don't have here, so don't be surprised if I add more. So what you do is just go to
AppLocker, Import Policy, find the XML file, and if you do want to create the default rules,
you can still do that at any point. So even though I have these all set up, you can still create
the default rules. They will still show up, and you can again just delete them if you
want and create them again whenever you want. So no worries there. And the same goes
for any of the other file types. Okay, now I need to explain something very
important with how AppLocker works with PowerShell scripts specifically. So I'm going
to be using this file as an example, test.ps1, and inside this, it's very simple, it just says
Write-Output "Hello from inside the script." Don't worry about this line just yet. And
right now my AppLocker policies only allow signed scripts, so if it's not signed, it
shouldn't be able to run and that script is not signed. So let's try and run this.
I'll type it in and should be blocked. But hold on, it says "Hello
from inside the script." It ran. And here's another crazy thing. Is if we
go in and refresh in the Event Viewer log, it says that it was prevented from
running, but it was not. And this is extremely important to understand. Basically,
AppLocker works differently with PowerShell scripts. It doesn't actually block them
from running, from my understanding. It just changes the allowed modules and commands
that can be given, and it's in something called constrained language mode. So if I uncomment
that and then run it again, that line is set to display the constrained language, or the actual
language mode, in this case constrained language. And this is really important to know because it
could give you a false sense of security if you have PowerShell scripts blocked and it says that
it was blocked, but it could have actually ran. And in my case, this actually was really
concerning in my previous video because I did see in the Event Viewer log that a malicious script
was prevented from running. And then afterwards, I learned that this is how PowerShell works
with AppLocker. It might not have actually been. And it took me a lot of testing to
realize that the way it was run through the Visual Studio, I guess... it still
wasn't allowed to run for whatever reason, it wasn't allowed to run. But I actually
tested all the stuff that it would have ran, all the commands, and it actually would
have worked. So I do not like that this is how it works, but that's just how it
has to work. So there's a couple ways to defend against this. But first, I will
demonstrate if you do actually allow a script. So we can go and allow this one. So if I do that, now I explicitly allowed this. And if I run it
again, you can see now it's in this full language mode. So it's unrestricted. So it will go into
full language mode if it's allowed. If it's not, it doesn't block the script from running, it
just blocks it from running in full language. Now that, from my understanding, is unique
to PowerShell scripts. If you block other types of script files like batch files,
it should still work. But just again, it's really important to know that. So one thing
you should definitely do, is go to "Turn Windows Features on and Off." And you're going to
want to look for Windows PowerShell 2.0. This is already unchecked for me, but
it should be enabled by default. And you want to uncheck this. Disable this
PowerShell 2.0. It's really just there for backwards compatibility. It is very
insecure and easy to bypass the AppLocker restrictions altogether. So uncheck
that, and it's a little bit better. Okay, now I want to tell you about
setting the execution policy, it's called, in PowerShell. Basically, that will allow
you to set which scripts are allowed to run, or any at all. So to see what it
currently is, you can use in PowerShell, "Get-ExecutionPolicy" space dash "List".
And it'll tell you, and probably by default, they're all going to be "undefined", which
is the equivalent of being "restricted". I'll put all the possible options here. Basically,
Bypass allows anything to run, no warnings or anything. Unrestricted allows anything to run,
but for some, it'll ask you if you want to trust the script writer. Then there's RemoteSigned,
which allows scripts that were created locally, but if they were downloaded from the internet,
they won't be able to run unless it's signed. That's not that reliable because it's really
easy to remove the marker that marks it from the web. Then there's AllSigned, which allows
any script that is signed with a code signing certificate. And then there's Restricted,
which allows no scripts to run at all, no PowerShell scripts. And these different
scopes are where these rules would apply. And like I just said, Undefined, by default is
the equivalent of Restricted. So by default, PowerShell scripts should not be
able to run on your system. However, it is extremely easy to bypass that,
which I'll show you in a second. And also the ordering of these here is the
ordering of the priority. So the machine policy wins against anything else and
local machine is the least prioritized. So since everything's undefined, if we
tried to run an example like test.ps1, it should say it will not work
"because running scripts is disabled on this system". And that's because
it's basically restricted. But like I said, it's extremely easy to bypass this. It's not
really even that much of a security feature. It's just so you accidentally don't run a script, but that means that malware can easily do
that. So if we were to do something like this, this command Set-ExecutionPolicy, ExecutionPolicy
Bypass, Scope is this process. So this is literally just going to ignore the execution
policy. So if I do it again, there it runs. So you can imagine this is not
even with admin privileges. Yeah, it would help if you yourself are
accidentally running a malicious script, but if the virus is using another program to run
a PowerShell command, it always is going to have the bypass parameter in there. There is a way to
stop that, which I'll go over in a second though. If you do want to, it might make sense
to set the execution policy as Restricted explicitly. So you could do this. So you
would have to be running this as admin, but this is the command you would use.
And then that would make the local machine restricted. But remember that can still be
bypassed. Now I said there is a way to block the bypassing of the rules, and that is using these
two options here, MachinePolicy and UserPolicy. However, those are only able to be set through
the Group Policy Editor. So you can only use that with Pro, but if you're watching this
video, AppLocker also requires pro, so you probably have that. So you can find that under
Administrative Templates, Windows Components, and this is under Computer Configuration, by
the way. And then down to Windows PowerShell. And here's the setting, "Turn on
Script Execution". So by default, it is not configured, and that just leaves
everything as undefined. If we do enabled, we can then choose it to be one of these.
And again, that's going to correspond to the MachinePolicy. So let's set
it, for example, to only signed scripts. And now if we get execution policy,
I probably have to run a new instance of it. Yep, now we can see that MachinePolicy is
AllSigned. So if we try to do that bypass again, it's going to give us an error, and it says
it updated your execution policy successfully, but the setting was overridden by a
policy defined at a more specific scope, which is what we just did. So
that's what this is talking about. And we do get execution policy again, we can see, yeah, the process is set to Bypass, but it's
AllSigned. So if we do .\test.Ps1 again, we can see that now it will not run, because the
group policy won, which is the AllSigned. Now, if you want to set the machine policy to
Restricted, you can just set this to Disabled. So we can just show that again, we do get
execution policy. Now it says Restricted. So this would not allow any scripts to run on the entire
computer at all. Even if you try to use a bypass, you would have to go into the group policy
settings. So if you don't use PowerShell at all, you're not running scripts specifically,
you can still run commands, but no scripts, then I would probably just do this. Because
it will stop a lot of malware techniques, from not being able to run because one of
the first things they do is try to bypass it. Now, some of them might use some kind
of [technique] to get around the Group Policy Editor. I'm not sure, but I'm sure
this will protect you against a lot. Now, while you're in here, I would also recommend
turning on this "Turn On PowerShell Script Block Logging" here, and go to Enable, turn that
on, and then yeah, just check it and okay. And now this will add logging in the Event
Viewer. And I believe it would appear under here, Microsoft, Windows, and then PowerShell.
And this should tell you whenever something tried to run that was indeed blocked,
and it'll actually tell you the error message that happened. So I believe this
is more reliable than the AppLocker thing. So I wanted that to show at the top. So I
right-clicked it, go to Create Custom View, and then go through the thing. It'll
put it under Custom Views right at the top here. And then apparently this
"Turn On PowerShell Transcription" would literally keep track of everything that
was typed into PowerShell and given out. So you might want to look at that one too,
if you wanted. Now, one final thing I really need to point out is if you have PowerShell 7
installed, which is a separate installation from Windows PowerShell, then it's going to not respect
these execution policies. So we can see that here, if we do Get... Type that in. We can see the
default for this is Undefined for everything. And then local machine is actually a RemoteSigned.
So this means that basically you can run all scripts on your computer unless it's remote,
which is not usual. So if we do test.ps1, you can see it ran. Whereas if we do
the same thing in Windows PowerShell, it does not run. So how do you deal with this? Well, you can change the Process, CurrentUser,
and LocalMachine policies. Again, these have to be done separately from what Windows
PowerShell does. However, if you want to do MachinePolicy and UserPolicy, you have
to do something extra. It's not really hard, but you have to do it. And what you need to do
is go into the installation path of PowerShell 7, which in my case, I installed
it through the Microsoft Store. So it's under Windows Apps and then Microsoft
PowerShell. If you installed it through like GitHub, it would be under Program Files
and then PowerShell, I believe. But same thing. Just go into there and then look for
this script right here. And what you want to do is navigate to there with PowerShell 7,
and make sure you're running it as admin. And it has to also be PowerShell 7, not Windows PowerShell. Then what you can
do is just go and copy the name of this, do dot slash, paste it, and run it. It won't show
anything, but when you go back into the group policy editor, now you will see a new thing under
Administrative Templates and PowerShell Core. You'll probably have to refresh this. I
already did this, that's why it shows up. And now you'll see basically the same
options you had in the other ones. And this is a separate one. So now there is
both the Windows PowerShell down here, and the PowerShell 7 version up here. It's under
PowerShell core. Now fortunately, as you can see, there is an option if you enable it to just
"Use [Windows] PowerShell Policy Settings". So this will just make it so it always uses that
other Windows PowerShell thing so you don't have to change both every time. Although I
do think you have to set this anyway, even though if you have this checked,
this doesn't matter, but you still have to enable it or else it'll give you an error.
So now if we open up a new one, if we do List, we can see that the machine policy is
AllSigned, just like it is over here. And actually just to show that it is indeed
copying the policy, and not just using this dropdown, I'll say allow all scripts
and open a new one. You can see it still says AllSigned. I don't know why it makes you
select that here, but it just does. But as long as you have this checked, you're good.
Now, if you're wondering which of these you should choose or whether to keep it at Disabled,
I personally keep it AllSigned just because I do use PowerShell occasionally, and I guess I could
always go in here and change it if I needed to, but I trust signed scripts, so I'm
just going to keep it like this. But again, if you don't use PowerShell
to run scripts specifically, like you could use it for commands and stuff
still, but if you don't run scripts, I would just keep this at disabled. And it
still lets Windows itself run like official scripts in the installation directory and
stuff. It's just any users can't run scripts. So I think in my opinion, it's important
to at least set this or Disabled, which will stop malware from being
able to just bypass the policy, which is really easy to do. Alright, finally I
realized I am talking a lot about signed files, but you might be wondering how do you
check if a file is actually signed? And that's pretty simple. I have a few examples
here. One is signed. So if you just right click it and go to Properties in Explorer, you'll
see a tab that says digital Signatures, that will not appear if a file is unsigned.
And you can see this is a PS1. This is actually a PowerShell script. So scripts
can be signed in addition to executables. Here's a EXE that is not signed. And you can
see that there is no Digital Signatures tab. But another thing you have to check is if
the signature is actually valid. And you could do that by clicking on it and hitting
details. And if it says the signature is OK, then it is trusted by Windows. If it says some
other thing, there's going to be an error message. It might be self-signed, which means
it might be... It's a signature, but it's not one that goes back to a root
authority. So you can't really trust where it came from. But if it says OK, then
it goes back to a root authority. And that's one that should be trusted by
AppLocker and allowed to run. Alright, so hopefully by now you know everything you need
to know about using AppLocker. And if you decide to go that route, then you should be prepared. Let
me know down in the comments if this is something you are going to do or if you're like, no, this
is too much for me. I don't want to deal with it. If you did enjoy this very long video, please
give it a giant thumbs up if you've reached this point for the YouTube algorithm, and maybe
consider subscribing if you haven't already. I try to make videos about twice a
week, usually Wednesday and Saturday, although I took an extra day on this one. And
if you want to keep watching, the next video I'd recommend is where I talked about that time I
almost got hacked and [AppLocker] helped me out. So I'll put that link right there. Thanks so much
for watching and I'll see you in the next one.
