So you've showed me quite a bit about enabling logging and
the stuff that's not done by default, and so those logs are now there,
but with all logging,
someone actually has to look at them or they're only so useful.
And no one really like scanning through logs visually.
The scroll wheel is not the best tool of detection.
And unfortunately, the Windows Event Viewer,
it's kind of hard to use to search through logs,
especially if you're looking at a local system,
and there are some better tools to do that.
So what we can do is look at the system with the malicious
document that launches the PowerShell that I've already
compromised the system here, and so we can look at what logs I get set off.
So the tool that I'm going to use here is called Event Log Explorer.
Event Log Explorer, it is a commercial tool,
but you can download it for free as well for limited use.
Event Log Explorer is essentially the Event Viewer on steroids.
It gives you a lot more searching and filtering capabilities,
which for an investigator is extremely powerful.
So this is another enhancement on the Windows Event Viewer.
Exactly.
So what I'm going to do here is I've opened up the local security logs on my PC,
which we've already compromised, again,
and you can see that there a lot of different logs that I've turned on
because I went in and I modified the logs based off of what Log-MD was
telling me what I needed to turn on,
so there's a lot more logs here that are being logged.
So based on the report that we got that we saw previously,
you've went ahead and enabled all those things,
and this is the result.
Yes, exactly.
And so we're going to cheat a little bit.
So we know that PowerShell was ran from our Word doc,
and so we're going to search for any event log that
has the word PowerShell in it.
If I was doing threat hunting, I would pretty much do the same thing.
I know that PowerShell is used in attacks,
so I'm going to search for any instances of PowerShell in my logs.
I love how simple that is.
It is.
It's very simple.
And we can see down here, we have a Process Creation event,
so let me open that up.
And here, we see our 4688 event, and just by looking at this,
you should see something jump out to you right away.
We see powershell.
exe, and then that EncodedCommand, and then that huge Base64 encoded string.
This definitely tells you something happened here.
As a threat hunter, or an investigator, or an analyst,
if I see this, big red flag.
We're going to start looking and seeing what's going on here.
So like you said before, you see EncodedCommand, it's probably nefarious.
It is.
Absolutely.
Now not only with this, this is a Process Creation event,
but we saw a lot more events.
So let me start scrolling through the events a little bit.
Yeah, so this doesn't even, that wasn't even the PowerShell logging.
That was a--- No, that was the security log.
We haven't even gotten to the PowerShell logging yet.
So here we're getting to another event, a Filtered Platform Connection.
This basically logs all network connections that are
occurring within your computer.
And I'm going to go up one more, and here we see that our Process ID,
and if we were to compare this Process ID to the previous
one from the Process Creation event, they're the same.
The application name, powershell.
exe, we can see that it connected to this IP address on port 443.
So now our logging not only has told us that this
PowerShell launched some encoded command,
but it also connected out to this IP address.
And then HTTPS.
And if we would look, this would be the IP address of Pastebin,
and if we were to see that, that should definitely set off red flags.
PowerShell does not connect out to Pastebin by default,
so something is going on here.
And Pastebin in particular may be something that
you're alerting on on the network side,
but actual malware is not going to go to something known like Pastebin.
It's going to go through a recently spun up community control,
or like a fast flux DNS, or something like that.
Exactly.
So let's go up a little bit more.
So we're going up one more event,
and we see that we have another Process Creation event,
and we know that this is not the same Process Creation
event as before for two reasons.
One, we look at the new Process ID here.
This is the Process ID of the process that's getting executed.
It's unique to every process on the system.
And so this is different than our previous one.
If we scroll down,
we can see that the command line is showing us something new here.
So what happened here is our original PowerShell,
remember, it went out to Pastebin, it downloaded more PowerShell to execute,
this is the more PowerShell that it executed.
So now not only do, within the logs, do we see the original stuff that happened,
we see what else it did.
It executed PowerShell again,
and now here's some new stuff that it downloaded and ran.
So and that binary text that came down that it downloaded wasn't detected
as executable or anything malicious is now running,
and this is the result.
And it looks like this is some more encoded string that we could go
in and try to figure out what it is and decode it.
If I remember right, this is just another Base64 code of string.
Would could use CyberChef to decode it and see what it is.
Yeah, and I also see gzip in there and MemoryStream.
So that's the part we're talking about fileless.
Is that what's streaming it directly into memory using that function call?
We would never find this code on disk anywhere.
There's no file that contains this.
It's all in-memory.
This is the fileless attack.
So if we didn't log it, there is no way to catch this.
If we didn't log it, we would not have seen this.
So this is just the Security event logs.
Let's go over and let's look at the PowerShell logs.
Scroll down here.
Here, we have the PowerShell Operational logs,
and you can see that it logged a lot.
Looking through this, the PowerShell 4103 logs,
these are the module logging, the modules that are being executed.
The 4104 logs are the script block logs.
And we can go in here,
and we can just start looking through and seeing what we're finding.
We're seeing bits and pieces of code.
Let's see if I can go and find something interesting.
Yeah, it lets you know when it pipes something,
so when we're changing from one function call to another.
It does.
Here we have, here is the host application.
We can see that this is the secondary PowerShell that was logged,
and we can start scrolling through here and trying to
figure out what had happened here.
Deconstructing the intention there.
And you can see it's not giving you a lot of information,
but it's definitely more information than if you would look normally.
Now this is great, but also remember, we turned on transcripts.
We turned on the PowerShell transcripts,
and the PowerShell transcripts, they're in the file,
and they show us exactly what happened.
Is that a time/date thing?
Is that automatic?
It's stored by time and date automatically.
So what I'm going to do here is I'm going to open up this first one.
Let me turn on Word wrap just so we can see everything.
And here,
this is almost like we were sitting behind the shoulder of the attacker.
Remember that in the initial command, we had this Base64 encoded string.
And then it downloads from the Pastebin.
But if you look below, the transcripts decoded the Base64 string for us.
So we don't even have to, if we didn't know how to do it, we wouldn't have to.
The transcript shows this to us.
And transcript, that's an automatic Windows feature as long as you enable it.
You have to enable it, but yeah, it's built in there.
So it'll automatically decode the Base64.
And this is just the first command.
We can jump over to the second command.
Actually, Windows just got some points for that.
instance of PowerShell.
So if we look at this one, here we've got this huge,
the new thing that was launched, and unfortunately,
in this case, it didn't decode it for us.
But if this has run more commands, we would see everything that had happened.
And think about how powerful this would be is if you had an attacker
that had launched a PowerShell command through one of the attack
toolkits and was interactively using it,
it would log everything here.
We would see everything that the attacker did--- As they did it.
---as they did it.
Again,
that's just like sitting over their shoulder and
watching what the attacker was doing.
Absolutely.
And that's not only great, so I'm certain that we can alert on this,
and I'm sure we'll get to that, but from a responding after the fact perspective,
it's really good to be able to put that timeline back
together and find out exactly what happened.
This is just immensely invaluable to anybody.
And this is just the PowerShell logs.
Remember, we also turned on Sysmon.
So let me go in here, I'm back in Event Log Explorer,
I open up Sysmon, and here we can see pretty much everything that we saw before.
And even better, you may have noticed that when we were looking at the 4688 logs,
it doesn't tell us the parent process.
I believe it gives us the parent process ID,
but it doesn't tell us what that process is.
So we kind of have to do some manual correlation there.
Sysmon shows that for us, which is great.
Here, we've got this Process Creation event.
We say that when Word was logged, Word was ran.
So otherwise, we would know this came from Microsoft.
We wouldn't have know that it came from Word.
And in fact, by looking at the command line,
we see the exact document that was what was run.
So as an investigator, if I didn't know where that document was,
now I do, and I can try to recover it if it's still on disk.
So that's really an incredible benefit of Sysmon.
Because I can see where the argument would be made like oh,
I already turned on all this logging for commands
and security events in PowerShell.
Why do I really need Sysmon?
And here is a great reason why.
So here,
I've kind of scrolled up until we found the process
creation event from Sysmon from PowerShell.
Here we see the EncodedCommand.
And even better, we see the parent process,
and it actually shows us the parent process command line as well.
So just in this, if we only had this one event,
we can tell a pretty good story as to what happened.
Somebody opened up a document, and that document ran PowerShell,
and here is what the PowerShell was.
And taking that back to our behavioral analysis we
were talking about is now in one log, we can say hey,
when PowerShell runs on Word, it's weird,
and now alert on that.
And in that one logged document, we have that event happening.
That's kind of a unique thing.
So if you see a PowerShell log, or a Sysmon log,
that has PowerShell executing, as well as Microsoft Word executing,
then that's something that you can alert on.
Attackers have lots of different techniques that they can do.
They can inject code into other processes.
So imagine if you're looking through your logs and you see calc,
the Windows Calculator, has launched PowerShell.
When will calc ever launch PowerShell?
But something like that.
These anomalies should stand out.
Yeah,
that's almost anything other than Task Scheduler running
PowerShell is probably pretty weird.
Or even PowerShell running PowerShell.
You should see PowerShell running PowerShell.
That makes sense.
Or if somebody is launching from the command line,
you should see the parent process being cmd.
exe or maybe even explorer.
exe.
Very rarely should you see it be Word, or Adobe,
or any other program for that matter.
So you could likely whitelist the things that you should see,
and then just say anything other than this so then
you've narrowed the case down a bit.
Absolutely.