In this demo,
I will verify the Winlogbeat configuration as the event IDs necessary to
facilitate the detection of PowerShell execution anomalies.
Then, as I mentioned in the previous clip,
we need to enable PowerShell login explicitly.
When all of that is complete,
I will simulate malicious PowerShell activity and then pivot to the
Kibana web UI and look at what artifacts were generated.
This is the Winlogbeat configuration file from one
of the Windows 10 workstations.
The event IDs we need are 4688, 4103, and 4104.
We have verified the event IDs are configured,
now let's head over to the domain controller and check that we
have the PowerShell login GPOs configured.
We will start with the PowerShell module login,
which can be found under Policies, Admin Templates,
Windows Components, and if I scroll down a bit further,
we can see the Windows PowerShell.
This gives us the five settings we see in the window pane on the right.
I've already enabled Module Logging.
If you want to also enable Script Block Logging here,
you can, but I prefer to use a separate Group Policy Object for the flexibility.
I'm going to bring up the second window,
and here we can see we have Script Block Logging enabled.
The only thing left is to simulate adversarial PowerShell execution.
So let's go back to the Windows 10 machine,
and I'm going to execute an encoded PowerShell command.
Now, instead of telling you what it does,
when we visit the Kibana web UI,
you'll get to experience the value of having Winlogbeat
collect PowerShell logs. Remember, even if you can decode
what you see on the screen,
real‑world malware will not be as trivial. You may have to rely on the
PowerShell logs that contain the decoded contents.
Okay, so the command has executed,
let's head over to the Kibana UI and talk about detection.
One way we can approach finding anomalous PowerShell execution is to
understand if our environment uses encoded PowerShell commands.
This isn't common in the Globomantics environment, so we can start our hunt
using the event ID 4103 and check in if the command line field contains the
eNc string, which is shorthand for encoded command.
If I select and run the saved query I created earlier,
it appears we have 29 documents that have the eNc string.
I made the letter N uppercase to show that the text field was designed to allow
case insensitive searching. To get a better view of the details, I'm going to
select the fields process.command_line, agent.hostname, related.user, and the
activity.id, which we will use for correlation with the event ID 4104 in a
moment. Notice that the command line is still encoded and we can't tell if this
is benign or malicious.
Additionally, I only executed the PowerShell command once,
but it generated multiple log events.
I want to reduce some of the noise and scope the result to just the activity
ID, which groups events that are part of the same activity.
Then, I'm going to change the event code to 4104,
which is Script Block Logging, and this should give us the
decoded commands that were executed.
Let's get the filters from the earlier query out of the way.
Now, I need to add the powershell.file.script_block_text field, and voila,
we have the decoded commands.
It appears that the adversary attempted to create a scheduled task that
ran an executable daily at 7pm. Thanks to Winlogbeat, we were able to
collect this data and can perform remediation.
If we had other instances of legitimate encoded commands,
you would simply filter the known good out and that should
reveal the anomalous PowerShell executions.
We didn't look at event ID 4688 here because we were able to see the
command line execution from the 4103 event code.
If you do not enable Script Block Logging or Module Logging,
then event ID 4688 would at least be a starting point