again, and welcome back.
So as a security professional now,
you may find extreme value in being able to quickly view flow and
DNS‑related traffic as it pertains to your network connectivity.
So what we're going to do now is take a quick deep dive overview into how you
can quickly see that pairing of your Winlogbeat with your Packetbeat to
provide further security insights into your network.
So the first thing we're going to look at is the Hosts tab.
So we're going to go ahead and navigate to that now.
It's under Security and then Hosts.
Now,
the first items we'll see is just an overview of different events in
relation between our Win event logs and our Packetbeat logs.
We can verify this really by checking the activity data sources
that are being used in these graphs below.
To do that, we'll navigate over to the Data sources drop‑down,
and you can verify here that we have the following data source
indexes being used in a wildcard manner on this page.
So overall,
this first page just kind of gives us a bird's eye view
into source and destination type activity,
as well as activity on host in relation to user authentication events.
Now scrolling down, we'll see another tab called All hosts,
and that gives us more information around connected hosts,
the last time that they were seen, different OS version,
their names, their versioning,
just another quick look into what is communicating throughout your network.
So the next part of importance here that we may need to dig into
from a security perspective is authentications.
So this provides us with a high‑level overview graph of successful and failed.
Also they're not shown, but there are failed authentications that could occur.
If we scroll down, we see a more in‑depth look of these types of activities,
including last failed source destination,
the failure reason, timestamps, etc,
all helpful when performing investigations on different hosts.
The next tab we have here is Uncommon processes,
which highlights suspicious processes running that are not
common to the OS or are just not run very often.
We can quickly get a sense for what commands were run and the different
users that may be attempting to run these commands as well.
Next we have the Events tab.
Now the Events tab is a summarized view of what you
can also see in the Discover tab.
It provides a sequential look into the raw events as they occur and it
can be helpful to quickly see within a certain time period what might be
occurring on a system or between systems.
By looking at the event.action field,
you can actually see what type of event is in question,
whether it's an off event, a network or security event,
and then we can also observe the type of messages that
are being relayed in the raw format.
So this is just a quick way to see like,
okay, here's an overview, there's registry actions that were created,
registry values that were set, there's different files that were created.
And if we scroll down, we can get a sense more in depth of this type of activity.
If we expand this message field out a little bit and we hover over it,
it will actually provide us with the raw message or raw log
that came with that specific type of event,
which makes investigations quite simple.
Tie this into a specific security use case.
As a security professional,
you may be presented with threat hunting exercises or actual
investigations on alerts that you've created to better understand
maybe what's happening around a specific host.
This Hosts section in general can easily provide you with
a quick look into your environment.
Let's say, for example,
you know there was a phishing email that was going around and part
of this email was if you clicked on the link or interacted with
maybe a document that was attached,
it would attempt to set a registry value or make a
registry change on that user's local system.
With the Events tab,
we can quickly filter for registry events and get a list of all
hosts that had corresponding registry changes,
as well as any potential outbound connections established within the
given timeframe of the phishing email campaign.
Now as you can see that we looked at before,
this high‑level overview chart did give us a quick breakdown that there
was some registry value changes that attempted to load.
And then also if we were to just, let's say,
create a filter for just registry changes in general,
and then we looked and also looked for any outbound
external connections via Packetbeat,
we could further solidify a specific type of activity that could be
occurring and narrow our focus on any investigations.
So with that data in mind,
now that we have a solid understanding and an idea of how to
identify this activity that we've deemed important,
let's dive into how we can enable or create a custom alert around this data.
So the first thing we're going to do is we're going to
navigate to the Alerts section under Security and we're
going to click on Manage rules.
We're going to go down to Security, click on Alerts,
and then the right side of the screen here you'll see this Manage rules.
Out of the gate,
you'll see that ELK does come prebuilt with quite a few different rules.
You'll see there's around 600 or so prebuilt and included rules that are
activated or that you can activate upon creating your ELK instance.
So,
we're going to go ahead and just take a look at a couple of
these just to see kind of what they're made of in terms of
what Packetbeat maybe populating.
So I'm going to go ahead and just click on this Unusual DNS Activity alert.
Let's take a look at this.
So out of the gate, I mean, these are pretty straightforward rules.
They give you an example of what this alert or this rule is
generally looking for and will detect on.
It gives you the severity.
It gives you the link of how they actually created it.
And then also actually it's pretty nice,
they give you false positive examples,
which is really nice when doing investigations and you want to reference like,
okay, is this a legitimate detection or is it not?
And then on this right side they provide you with the makeup of the alert,
and this is an anomaly type alert.
So anything that reaches that score of 50 or more will trigger this rule.
But there are other types of alerts as well that we can
kind of dive into in and further refine.
So we're going to click back on the Rules section and we're
going to just do a quick little search on DNS and see what other
prebuilt DNS rules are included here.
Let's go ahead and click on this DNS Tunneling.
Another low‑‑‑ or actually better yet,
let's click on this DNS Activity to the Internet.
It's a medium.
So as you can see the left side, the About section has the same type of makeup.
It gives you the risk score, severity, the links of how they created the alert,
but then on the right side it's a little bit more specific as it tells you
the specific type of index patterns that are being used,
Packetbeat being one of them,
and then also it lists out the exact query of what it's looking for
for this type of DNS activity to the internet.
It's listing out all possible internal network subnets and looking
for anything that is communicating outbound.
And the best part about this is if you wanted to tweet this,
maybe remove some of them because, hey,
maybe you only have a 172 network and you can get rid of the rest of them,
in ELK you are able to do that.
So now that we've looked at a couple of good examples of DNS prebuilt rules,
let's go ahead and look into what it would look like to create our own type of
networking or Packetbeat‑related alert within the ELK system.
So what we're going to go ahead and do is click on the,
we're going to go back on Rules,
and we're going to click this button in the top
right corner called Create new rule.
Now, here we're going to choose the type of alert that we want to create.
For the purposes of this demo, we're just going to do a custom query,
which is already selected.
But depending on your fancy, you can go ahead and create a machine learning rule,
a threshold type rule, indicator match or even an event correlation.
Now by scrolling down,
you will see the index patterns that are being used in the current logic.
As you can see, both Packetbeat and Winlogbeat are being considered.
If you wanted to,
you could go through and exclude any of the other ones
that were not relevant to the search.
So in the Custom query section, this little search bar looking thing right here,
you'll go ahead and paste in your query that you would want
to change or start creating from scratch.
So as you can see, the text box is enabled with auto fill,
so as I click on it, this pop‑up just happened.
So if I just started typing in Win log, as you can see,
it fills in with all the possible indexes and data
sources that I can search from.
Now once you have determined your search,
you can actually test the search live against your dataset to
ensure it's triggering against live results.
So if I went in, and let's just try this,
just for purposes of the demo here, we're going to type in event,
let's see here, event, let's go event log.
We're just going to click that in there,
and we'll go ahead and put the wildcard in,
and then we'll scroll down here and we click this Preview results button.
And as you can see, it prepopulates, okay,
obviously that's a broad scoping search,
but it's looking at that specific data source for Win log events
and it's populating everything that it can see. That way you know
when you're creating your custom alerts,
okay, I'm working with the right dataset and it's actually getting data.
As you create your alerts and they get more specific, you can continue
to do this check if you know that there should be results there to
verify that you're narrowing your focus down based on timeframe of your
alert that's in question.
Okay, now that we've verified our data,
we're going to go ahead and click Continue.
We're just assuming that our prebuilt search that we put in there is
going to be the one that we're going with, so we click Continue, and
this will bring up the next section that we need to fill out, which
is the the Rules section.
Now in this section, this is where we'll put the name of our
rule, we'll just call it test, any description,
we can put any type of response notes we want in there or just
high level metrics around what to expect.
We can set our severity, as well as define the risk score that we
wanted to trigger on, as well as any tagging that may be needed in
order to further define what this rule is triggering against. Next we
have the Schedule rule section.
This is where we'll actually set the threshold of when this rule
will look at the logs and the specific log types and check for the
specific criteria that you've laid out.
Now I recommend anything from additional lookback time of 3 to 5
minutes or more and then have it run every 5 minutes.
This will ensure that you're checking it every 3 to 5 minutes or so and that
the rule is also running in that same timeframe as well.
That way there's no lag or you're not missing any gapage in your
data and you're getting a clean, concise look.
Okay, last but not least we have the Rule Actions section.
This is the section where we define what action we want the rule to
take when it triggers. We can have it do nothing and we just have to
look it up, we can have it set an email alert,
maybe a Slack alert, maybe just a notification within the console. All
these actions can be defined and performed here.
And once you have that done,
you just click Create and activate this rule in order for it
to be active and live in your environment.
And that's it.
At this point you're well equipped to be able to identify
both security and network‑related events,
as well as create meaningful custom alerts surrounding this data.