So we've talked a lot about fileless malware,
how it works,
and then quite a bit about how it's kind of the next level of
detection to be able to find this stuff.
It's not just simply drop an appliance on the rack and plugging it in.
It doesn't just show up like oh yeah, you've got PowerShell running in-memory,
by the way.
It's not a thing.
So at the end of that, every time it comes up is like well,
it's actually logging.
You have to enable this logging that's not enabled by default,
and then you have to monitor that.
Surprise!
So I think we're going to talk a little more about that is what do we
need to be logging to be able to find this stuff?
And I think a lot of people, or a lot of organizations,
or administrators,
they think that the default logging that occurs within Windows is sufficient,
and it's really not.
There is a lot of extra logging that you can turn on that would give you just
so much information about what's going on in the system.
In fact,
you could even do a full malware analysis on what malware is
doing if you have proper logging set up.
You wouldn't need to any extra tools or anything like that.
Just by focusing in on the logs, you can do this.
And again, a lot of them are not turned on by default,
and nobody turns them on, and even those that are turned on by default,
for example, like the WMI logs, they don't give you enough information.
WMI, I think, by default, just only logs error messages.
And so if an attacker is good and they've practiced,
then they don't generate errors, and so nothing ever gets logged.
And so what we'll look at is what you need to do in order to turn
these logs on and which logs you need to turn on.
Yeah, the attacker's stuff only has to work one time,
and then we have to be perfect every time.
It's the blue team fun.
And there are a lot of different logs that you can turn on.
When we look at the Windows, and we'll look at the interface here in a minute,
there are just all of these different options that you can turn on,
and you may not know what you need to turn on and where,
and so there are some really great resources out online of what you,
that will tell you what you need to turn on.
So probably the best one that I know if is if you go to malwarearchaeology.
com.
Malwarearchaeology.
com has a number of cheat sheets related to logging.
I love cheat sheets.
Yeah,
and these cheat sheets are for Windows; Windows Advanced; for if you use Splunk,
it tells you what you need to do in order to get Splunk in; it even,
down here at the bottom, it even has PowerShell Logging.
So in order to turn on PowerShell Logging there's its own cheat sheet there.
Specific stuff just for PowerShell.
Specific to there.
And they've even come out with,
a lot of people are using the MITRE ATT&CK framework now in order to
kind of correlate what their tools can do all that.
They've even gone in and shown,
mapped every single log within Windows to the MITRE ATT&CK framework.
So if you want to pick a specific attack in MITRE,
in MITRE ATT&CK framework,
it will tell you which logs you need to turn on in order to detect that.
So these cheat sheets are unbelievable.
I highly recommend using them.
They're going to tell you exactly what you need to
do and what you need to turn on.
Yeah.
And then not only how to detect that something is happening in general,
but like you said with the MITRE ATT&CK,
you can look at the pattern of behavior and match that to APTs
because that's kind of what an attacker is going to do.
Exactly.
That's exactly how it works.
In addition to Malware Archaeology,
one of the other tools that you want to use to enhance your logging is Sysmon.
Sysmon is from Microsoft.
It's a service that you can install.
It's free.
You install it, you use a configuration file for it,
and it just enhancing the logging that's on your system.
Yeah.
It's part of the Sysinternals.
It's part of the Sysinternals, Mark Russinovich stuff.
He has some amazing, yeah, he has some amazing tools out there.
This is just one of them,
and it really picks up Windows logging where the
normal Windows logging leaves off.
It has some enhancements for WMI logging.
It kind of, it will complement a lot of the Windows logging,
and so we're going to talk about how to turn on process creation logging.
It will do that as well.
And some people may think well, why should I turn on both?
Well, it's not a bad thing to turn on both.
So let's take the situation an attacker gets on a system.
One of the first things that they might do is clear your security logs.
So if you do have this logging turned on and you're
not sending it to someplace central, they've just cleared your logs,
your logs are gone.
Well, they may think to only clear the security logs.
If you also have Sysmon logging,
then you have a second place where this is going,
and you can start correlating information,
and you have a backup.
And the Sysmon logs sit in the event log structure,
but not inside the main ones.
So it's not the big five that include forwarded events.
You'd have to kind of dig down in there in order to find it.
Now, yeah, you can go and you can script it out and all that,
but--- Like anything else.
---but it's at least a backup, and it's going to be doing more things for you.
And the more you can do, the better off you're going to be in the long run.
So if you paired that with remote logging,
like you're forwarding your Windows event logs to a centralized source,
now you not only have a location on the endpoint,
you also have a centralized location with archived backups of everything,
so it's more unlikely that they'll be able to get to all the logs.
And then it becomes much more difficult for an attacker
to kind of wipe away their footprints.
They may be able to do it on the local system,
but as you're sending those logs to that central system,
now they would have to figure out how can they compromise the
central system and wipe the logs there,
which hopefully your central system is a bit more defended,
and it's going to be much more difficult for them to do that.
And when they do, the more that they have to pivot in the environment,
the more likely they are going to be to get caught.
This is a good business case.
It's not only good to centralize those logs for things like web servers so
that you can kind of look at your usage and plan out whether you need to
expand your data center and that kind of thing.
So this kind of also ties into a DevOps use case and a
business use case that security can also use.
Right, exactly.