Hi. I'm Aaron Rosenmund,
and I'm here to introduce you to the magic in raw analytic power contained in
the surprisingly easy‑to‑use set of containers called HELK.
You might be asking, what's a HELK anyway?
And I'm glad you asked, because I'll tell you what, it is a prey turned
predator sentient ELK Stack hunting APTs where they live, normally uncontested
on your organization's endpoints in the Windows logs.
It was created by Roberto Rodriguez,
who on GitHub goes by Cyb3rWard0g, and is supported with
contributions from many other open source heroes.
And in the creator's own words,
it is one of the first public and free builds that combines
technologies to enable graph analysis of Windows logs data
to hunt for adversary activity.
So it is The Hunting ELK, where ELK stands for Elasticsearch,
Logstash, and Kibana, ELK being the very popular stack that it is for
building detection and monitoring capabilities. You can see some of
the hallmark scalable components,
namely the Kafka to Logstash pipeline for data ingesting with
queuing, normalization, and enrichment.
This project is mostly focused on a collection of Windows event
logs from user endpoints and servers alike.
Now, this may seem trivial for those of you that haven't done it before,
but this is where it really starts to bring something to the table that
you cannot find anywhere else. And potentially, one of the most useful
nuggets you will draw from this course, the reality of Windows event
logs is that every single log, even within the same provider,
say the security logs, is structured completely different.
If the fields are not common and the message blocks are just
text that need to be parsed to extract the useful data, and
just in general it's kind of a mess.
Included in this build are a number of custom Logstash filters called grok
filters that pull out the useful data and then take things like the network
logon attempts by source IP and normalize those fields so that you can
align them with the other log sources.
So take that, times everything else you could possibly imagine as an
atomic indicator or a point of investigation across Windows event logs
and Sysmon, domain names, URLs, blocked or allowed actions, SIDs,
UUIDs, the list goes on and on,
but a ton of work has gone into making this large set
of information usable for hunting.
And if that wasn't enough work already done, Cyb3rWard0g has stacked a
collection of data analysis tools on top of the Elastic Stack that allow you to
perform enhanced queries focused on graph analysis to identify connections
between data points that indicate malicious activity.
And you can find all of the code, open and free, at this GitHub location.
Everyone loves their frameworks,
and oftentimes they are great tools to categorize and make sense of the
never ending tasks and functions required to perform this thing that we
call security. Especially from the blue team perspective, the NIST
cybersecurity framework outlines many of the business and
organizational functions that make up what I like to call the full
circle of enterprise security.
Now, HELK itself falls pretty squarely inside the detection functional area.
This is a more technical area within the CSF.
There are a few categories here that have gaps
filled by this tool's capabilities,
namely anomalies and events and security continuous
monitoring. For the sake of these subcategories,
the term network applies to the actual network, as well as the endpoints and
devices. HELK detects events and analyzes attack methods,
and it does so by collecting correlating events from
multiple Windows‑based sources.
So, you'll noticed that you still have a gap here for network events,
network infrastructure, and any and all UNIX‑based systems.
Considering these Windows systems as part of the network and leveraging the
tool for continuous monitoring instead of one‑off hunts,
you can also fulfill the continuous monitoring detection function as well,
especially with one of the features we're going to cover called ElastAlert.
And just in case that wasn't enough framework action for you,
I'm now going to invoke the name of MITRE ATT&CK, but this time from
a different perspective. The data they have amassed on adversary
techniques includes not just categories,
techniques, and now sub‑techniques, but you can cross analyze that
information by detection method, tools used, and,
in this case, the data source required for the detection.
From the blue team perspective,
this is a great way to start getting after advanced adversary activity
you know you need to be concerned about. Step one, you have to have
the right data source. For HELK, we're analyzing data directly from
Windows operating system logs.
And from that data source,
thanks to the parsing and normalization work that is done,
you can detect advanced adversary techniques like Kerberoasting,
BITS jobs, and the clearing of event logs by
adversaries trying to hide their tracks.
Now this is not an exhaustive list,
but it is the list that I'm going to use as examples in the demonstration.
But first,
just to make sure that you have a good mental picture of where
this capability sits in the environment,
take a look at this basic diagram created to
represent some super generic network.
The idea for HELK is to grab logs from the Windows machines,
whether they're user endpoints or servers in the
datacenter, and collect them to a central point.
I describe it that way because HELK itself could be your central point, or,
as I highly recommend,
you can be using a centralized log server that is collecting Windows
logs through Windows Event Forwarding, or WEF.
In fact,
many audit frameworks like RMF or controls in Sys
require the use of centralized logging.
Once aggregated, the logs are combined,
normalized, and ingested into the HELK pipeline.
They're queued with Kafka,
so you're not going to miss any messages, and also so you have a point
you can leverage Kafka query language for real‑time querying of data. And
then, they're shoved through Logstash for parsing and dumped into an
Elastic index ready to be analyzed.
But step one, you need to have HELK up and running.