So talking about these logs.
I mean, it's great that we centralize them and everything,
but which logs do we actually enable?
Can you show me some of those and what that looks like?
So let's jump on, and what I'm going to do is we have a Windows 7 system here,
we're just going to go through and look at all the
different logs that we can turn on.
Well, let me rephrase that.
We're not going to look at every log that we can turn on
because that would take a little while.
I highly recommend looking at the cheat sheets in order to determine that.
If you're going to turn on specific logs,
I'm going to show you the logs that you should at least at a minimum turn on.
Okay, that's great.
Like a good baseline log configuration.
And would you possibly--- Why doesn't every log already come enabled?
Why wouldn't we already have that as a baseline with Windows?
Mostly because, well, probably because logs still take up space,
and there is even a very, very minor performance hit.
And Microsoft, I think, wants Windows to be customizable for everybody,
and so not everybody may want this.
They may not want to have all that extra disk space taken up.
In fact, if you look at the cheat sheets,
they recommend having it's something like 100 GB at
least for your security logs, or something really large.
Yeah, for it to archive into.
Yeah, at least in towards the gigabyte range,
maybe it's like 500 MB, but it's still very large,
much bigger than what the defaults are.
And that's a lot of space for some people,
and they may not want to have that turned on.
Yeah.
And that speaks to, and I'm sure you'll show me,
is when we're in the logs you can set them to archive,
or you can set them to overwrite, and you can increase the size of the logs.
But even the max size of the log is pretty small and doesn't,
like if we're looking at something like a domain controller,
will fill in.
I've seen domain controller logs fill in 2 minutes.
So if you're not archiving, then it's gone.
Exactly.
So one of the things that we're going to turn on is
logging for process execution, and I just want to show you this beforehand.
So I'm just going to clear the security logs here, and so now they're cleared.
Just like an attacker.
I'm going to launch a Command Prompt, and I'm just going to run Notepad,
and we'll run it with, let's see if I can find a file to open up here,
actually, we'll just run it with Notepad.
And if we go in here into the security logs,
refresh it, you see nothing showed up.
There was no indication that I launched a Command
Prompt or I launched the Notepad.
So we're going to go in, and we're going to turn those on.
And that's not just a Notepad thing.
That's anything we'd launch.
Windows is doing tons of stuff in the background right now.
None of that's being logged.
So the best way to do it is to go into Group Policy.
We're going to want to edit the Group Policy on the local system.
This can also be done remotely.
This can also be done remotely with Active Director,
pushing out of Group Policy, and so on.
And in fact, if you're in an organization, this is how you would do it.
You wouldn't go around to every single system.
So what you want to do is go to the Computer Configuration to Windows Settings,
let me open that up, Security Settings,
and then down here under Advanced Audit Policy Configuration,
you'll see System Audit Policies,
and these are all the different logs that you can turn on.
Now these are all of the category, on the right-hand side here,
we're seeing all of the different categories of logs that you can turn on.
I see they all say Not configured.
This is a default install, so nothing is configured by default.
So here, when I go to Detailed Tracking,
I'm going to drill down,
we can see a number of different logs that we can turn on or off.
And the ones that we really want to turn on are the Audit
Process Creation and Audit Process Termination.
So I'm just going to double-click on those and then Configure.
I want to see both Success and Fail events.
Yeah, and that's a good point too, success versus failure.
It's really good to see first.
You need to know when it fails also.
And then I'm also going to turn on Audit Process
Termination just so as an investigator, it's often useful for me to know,
not only when a process started, but also,
when it stopped.
So if we stopped right here,
we would be logging Process Creation and Process
Termination events within the log.
As soon as you click OK, it's doing it on the system,
which is great; however,
we're going to enhance it a little bit more because we want to
see everything that that process is doing.
And so what I'm going to do is I'm going to go back up here to the Group Policy.
I'm going to go, let me minimize this,
I'm going to go down from the Computer Configuration,
to Administrative Templates, to System, and then up here,
Audit Process Creation.
And you can see there's one item in here called Include
command line in process creation events.
And what this will do when we enable it is,
not only is it going to show us when a process starts,
it's going to show us the entire command line.
So think back to our demo with the PowerShell and the EncodedCommand.
If we had not turned this on, we would just see that PowerShell started up,
which is great.
It's great to know that PowerShell would start up.
However, by turning this on,
we're also going to see PowerShell -Encoded and
then that base-64-encoded string.
So it makes logging much more powerful for us to detect this,
and we'll look at a couple tools later on that will actually use this
information to detect these attacks automatically for us.
Awesome.
So this is an enabling capability for other tools to be able to detect it.
So I'm just clicking Enabled, OK, and then I am good to go.
I'm just to minimize this.
If we refresh here,
we can already see that there a number of logs that have already been created.
The ones that you want to focus on for process creation are 4688 events.
And let me do this, so I'm going to go back here,
I'm going to launch Notepad, and I'm going to give it a file to open up.
Okay.
I'm giving it something on command line.
So when I hit Enter, it opens that up.
Great.
Let me refresh.
And here, if we open up and go into this,
we can see not only do we show that Notepad was open,
but we can see the command line, and we see exactly what it opened up,
what was giving it to it on the command line.
Go back to the PowerShell thing,
we would see PowerShell alt -Encoded and so on right here in our logs.
And we were essentially logging these, we would have that as well.
That's awesome.
And so with that, if I just double-click say an icon,
does that show, it'll show up and say no command line?
It will.
You may either have no command line,
or if that icon it actually has a command line in the
background within the launch for that program,
then it would show up here as well.
So if the shortcut runs a command line to open the program,
then it will show up.
Which is great because generally the attack is not
running around clicking stuff, like that's not,
but the users are.
So you can look at things that don't have command lines
and kind of discard those as well, they're just opening up Word.
That's not a big deal.
But if Word was open via command line, then that's a little more interesting.
So we turned on process creation,
which is definitely something that's you'll want to do.
Let's also talk about PowerShell.
PowerShell is used for a lot of attacks like we've already seen.
Beyond just what we saw, the little snippet that we saw,
there can be a lot more that's going on that PowerShell can do,
and so you definitely want to turn on even more logging.
So what we'll do in order to do that is we'll jump back to Group Policy.
The great thing is all of this stuff can be configured in Group Policy.
You can configure it centrally, and so you're good to go.
The way that I'm going to configure it is for PowerShell 5,
and we'll talk a little bit about how you can do this
for PowerShell 2 through 4 as well.
But for PowerShell 5, you go to the Computer Configuration.
We're going to go back down to Administrative Templates,
to Windows Components, and then somewhere in here,
there should be a Windows PowerShell.
There it is.
So here, we've got Windows PowerShell.
And Windows PowerShell has a number of different logs that you can turn on.
We're not going to turn on every single one of these
because some of them can be very verbose,
and they can just add to the noise.
So we're only going to look at, turn on a couple.
the first thing that we're going to do is we're going to turn on Module Logging.
Module Logging,
whenever a module within PowerShell gets started up like a program,
or if it loads a library, or things like that,
when we turn this on, it will start logging it,
and so that will give us somewhat of a transcript of what
the PowerShell was doing as it ran.
Excellent.
Yeah, it's just additional information.
Transcript is a great word for it.
It's the step by step of happened, and modules loading are part of that.
So here, in order to enable that, I click on Enabled.
And then down here, you could see Show icon,
or the Show button, was turned on, so I click Show.
And here,
this is where you would list all of the module names that you want it to log.
But what we're going to do is we're just going to put * in
there because we want it to log everything.
Thanks, asterisk.
Exactly.
Yeah,
I was like I don't know that we're going to be able to put
every single module we want in there.
That's a lot.
No.
So you just, you tell it to log everything, and then it started to log.
The next thing that we're going to do is we're going to
turn on PowerShell Script Block Logging.
This is pretty easy to do.
This will log anytime, actually,
this logs a lot of the commands and functions that get loaded into PowerShell.
So you can almost pull out the exact code that the attacker is running.
And sometimes,
I know for using an invoke command or a remote command that's
executing additional PowerShell somewhere else,
sometimes the attack is called script block.
So likely, without those turned on, we're not getting anything except for yeah,
invoke command was ran, which is great,
but we need to know what script was ran inside of there.
And this is really easy to do.
You just click Enabled.
You do have an option of Log script block invocation start/stop events.
I don't turn that on.
I would not recommend turning that on because that's
what generates a lot of noise.
So but with just enabling this, it's more than sufficient for what we need.
So that's the second thing that we're going to turn on.
The third thing that we're going to turn on is actual PowerShell Transcription,
and what this means is you can think of this as once we turn this on,
it's almost like we are sitting behind the attacker looking over
their shoulder as they're using PowerShell.
We're going to get exact logs of everything that happened within PowerShell.
So the way we do that is we have to enable it,
and then we need to actually set up a directory to log it to.
And so I'm just going to set up a directory here called transcripts.
So you have to tell all the data where to go.
Yeah, you have to tell the data where to go.
I can see that being interesting for some tools to use too.
That makes it a centralized location for all the information.
Exactly.
And yeah, you can absolutely do this.
One of the recommendations that I've often seen is don't set
this to be on the local directory itself.
Set up a shared folder somewhere and have it logged to there instead.
I'm not going to turn on Include invocation headers.
It doesn't give you that much more information.
What we have here is more than sufficient.
So I'm going to click OK, and then PowerShell logging is turned on,
and we are good to go.
And we'll see what this looks like in that later on.
And those cheat sheets that we looked at earlier will tell you
as you turn these on what event number and IDs are correlated
with these auditing policies.
Now the catch to Windows PowerShell logging is that what we just
did I believe is only available for PowerShell 5.
When you want to log for PowerShell 2 through 4,
there's something else that you have to do.
So what you would do is, let me close out all this just so we're not seeing it,
I'm going to run Notepad because we're going to create a file,
and I'm actually going to run it as an administrator.
And the reason I'm doing that is because we're going to
save this file in a protected directory so we need to be
an administrator to do this.
But we're going to create a file,
and we're going to put some commands in this file.
So let me type in these commands.
(Typing) Well, this is neat.
I can kind of see what you're doing here.
So this is PowerShell commands for PowerShell so this is going to on session,
I'm assuming?
Yes.
Very cool.
Hence the dollar sign.
Dollar sign equals PowerShell in my mind.
So these commands,
these are going to turn on the module logging and the script block
logging for us within PowerShell 2 through 4.
So what I'm going to do is you just put these three commands,
and this is all within the Malware Archaeology PowerShell cheat sheet,
so you can just copy and paste it out.
But what I'm going to do is I'm going to take these,
and I'm going to save it into c:\windows\system32\windowspowershell\v1.
0.
It sounds like you're saving it for version 1.
0, but actually, this is the directory that's used for all PowerShell.
So regardless of version, it's always v1.
0 directory.
And then I'm going to call it profile.
ps1.
Let me just modify this.
There.
And so what that does is that created a profile for PowerShell that
will get run every time a PowerShell script gets run.
And so with these settings, it's going to log all that stuff for us.
Oh, that's excellent.
So is this able to be bypassed?
Because I know you can choose a profile that's used
occasionally when using remote commands and stuff.
Is this something that can be bypassed as long as they know you're doing it?
Yeah, an attacker, let's face it, an attacker once they get on a system,
if they have enough knowledge, they're going to be able to bypass a lot of this.
So yeah, there's always the chance that this is going to be bypassed,
but that doesn't mean that you shouldn't turn it on.
You should still turn on all of these things just so that you
have it logging and you have things going.
Yeah, you increase your likelihood of being able to catch something going on.
Awesome.
When these log, it's going to log into, under the Applications and Services Logs,
you're going to see a Windows PowerShell section,
that's where some of these are going to be logged.
And then if you drill down into Microsoft and then Windows,
there's an additional location.
That's even better for putting stuff in different locations to
make sure they don't get deleted as well.
There's going to be a PowerShell Operational log,
and that's where the majority of what we're going to
look for is going to be located at.
Okay, and that's always there,
but it just doesn't always log all this stuff until we need it.
Before we had turned all of this on, if we had gone in and looked at it,
PowerShell is going to be logging some things,
but we're not going to see a lot.