Welcome back. Now it's time to demo how OSSEC can detect user
account creation on Microsoft Windows systems.
I'm going to start by showing you where the rule is located on
the OSSEC server and verify that it is enabled.
Then, I will create a user account on a Windows workstation using
a technique that cyber adversaries often use.
Lastly, we will go back to the OSSEC server and look at
the alert logs and discuss the results.
I've already brought up a remote SSH terminal connected to the OSSEC server.
I have an agent installed on a Windows workstation
that communicates with this server.
Much of the other configurations remain in their default state.
OSSEC comes preconfigured with many rules.
In this clip, we're only going to take a look at the msauth_rules.xmL file.
Maybe you've heard someone say trust, but verify. In this instance,
we can trust that the rules exist and are enabled, but we need to
verify that it wasn't changed, doing a new iteration of the
software, or for any other reason.
So how can we tell that this rule is enabled?
We can tell the rule is enabled because it's not commented
out, and the level is not equal to 0.
Each rule is enclosed in open and close tags, like HTML or XML. Before
switching to the Windows workstation, I'm going to monitor the alert log by
using the tail command to read from the end of the file.
When new alerts come in, they should automatically display on the screen.
Whoa,
I'm not sure if you saw that, but two alerts just came in
right as I started to monitor the alert log.
So let's move to the Windows box and put on our cyber adversary hat.
Here we are.
We've landed on a target, and we need to add a user to the
system for persistence. After that, PowerShell can be
leveraged to execute encoded commands.
Looking at the terminal,
you can see I've already set up a few variables that facilitate the simulation.
Don't worry if you don't understand what all these commands do, that's
not part of the exercise, it's just for transparency.
Next, I want to show you what user accounts currently exist on the system.
Cyber adversaries often check existing user accounts to identify the
naming convention that's used in your environment.
For instance,
some environments use firstname.lastname, some environments have first initial
and last name together, some environments have a mixture.
Now, we can execute the PowerShell command and check for new user accounts.
It looks like one account was created, Mr. Baggins. Technically, we
would need to also create a password for this user, but this is enough
to test the OSSEC user account creation rule.
If you're curious about the contents of the encoded command variable,
it just contains a Base64 encoded string.
These strings are a common occurrence in my work as a security engineer.
Okay,
so let's go back to the alert log we're monitoring on the
OSSEC server and see what results we have.
Nice.
You can see there are several logs that have been
generated that point to the new user account created. In
the output we have the rule number,
we have the rule title, we can also see the IP address and agent
name associated with the system that was infected.
Now,
if you're looking at this wall of text and wondering if there's a better way,
I'm happy to tell you that you can ship the alert logs to a security
incident and event management platform, like Splunk, Elastic,
you take your pick.
Unfortunately, that integration is outside the scope of this course.
However, good news,
I do provide some resources in the last module to help you get started.