>> SHAY BANON: And to continue with that, and to be honest, to give you a sense of what
you can actually do with our stack when it comes to the security space, it is a similar
story if you see when it comes to our operational logging, I would like to welcome Asawari on
what you can do with our stack when it comes to security.
>>ASAWARI SAMANT: Thank you.
As you gathered from Ryan's talk, detecting real attacker activity in your systems, your
infrastructure, is painstaking work.
What we will show you is not just how the Elastic Stack can be used to detect security
breaches, but how to do post-detection investigative work to see how the attacker got in and goes
about your systems.
A quick shout out to Justin and John with H&A security that helped us with this demo.
So for the next 8 minutes, I will step into the shoes of a security analyst at LabMe Inc.
And what you are seeing on the screen here is a sample of the security monitoring architecture
running at LabMe We have Beats running on all endpoint devices specifically WinLogBeat
that’s collecting all of the Windows event logs and Packetbeat that are collecting
all of the network packets.
All of this data flows into Logstash, where it is enriched and parsed, from there it gets
indexed into Elasticsearch, and then we use Kibana as the data exploration and visualization
layer for all of our investigative work.
Now, I just received an email in my inbox from a machine learning job that is alerting
me to a possible DNS exfiltration attempt to this covertc2.com domain.
So we will follow the link to investigate this further.
While this job is loading up, what this particular machine learning job is doing is looking for
unusually high information content on the subdomain feed of my DNS traffic.
And this particular red part contains the anomalies that trigger the alert.
So if I zoom in on one of these anomalies, not only is it telling me that this anomaly
is a severe anomaly based on this particular normalized severity score — but if I
zoom in here, machine learning is also doing influence analysis to highlight that this
host, HR02 and this domain covert.com, contributes to this anomaly in a significant, or meaningful,
way.
In other words it is highly likely that this DNS exfiltration attempt happened from
this host HR02 to this domain covertc2.com.
So it helps me to narrow the scope of what the next steps will be.
So next, I will say, what else was happening on the particular host, HR02, and to do that,
I will switch over to a Kibana dashboard that is set up to look at the Windows log events.
Now, this particular dashboard has already been filtered down to the two influencers
that were detected on that anomaly, so covert.com and HR02.
There's a lot to unpack on this dashboard as it is looking at a lot of events from Windows
event logs, but the one thing I want to zoom in on are what are the processes and services
that were started on this machine that spoke to this particular domain?
And the thing that stands out to me, as I'm doing that, is a whole bunch of DNS cat calls
that are run from the command line.
So here, you know that is a common utility that is used for DNS tunneling.
The other thing I notice here is that all of these command lines are run by this one
user, wgrimes.
So what I want to see is what else is he up to on this particular host.
So I will zoom out, add wgrimes as another keyword or filter, get rid of the domain here,
and, again, some interesting signals are starting to pop out.
I see this high use of net use command and probably something I want to look into.
but as I'm scrolling, the thing that catches my eye and worries me is that this user, wgrimes,
managed to successfully connect to this machine from this HR02 host.
And then I will say, uh-oh, this is not good, this is a red flag.
So at this point, I want to flip over and say, what else is happening on this particular
CEO machine that I should possibly be worrying about and taking remedial steps for?
I will get rid of the wgrimes user here, and I will change over to look at the 0 host instead
of the HR02 host.
And when I do that, there are things that begin stand out in the timeline plot.
I set the plot to flag interesting events and it flags things like new users added and
new services that were created.
And in addition to W Grimes connecting successfully to the CEO machine, there was another successful
anonymous log in.
And for those that use Kibana often, you may not recognize this particular visualization.
This was created using a visualization plugin that shipped in Kibana a few weeks ago, super
powerful and super flexible and allows you to create a lot of custom visualizations.
I encourage you to check it out.
So keep scrolling through my dashboard and getting a sense of what is happening on the
CEO host, I see a lot of login activity on the timeline, again things I need to look
into, and I notice here that a honeyfile, security speak for a sensitive or a critical
file, was accessed on the CEO host by this wgrimes user.
This is probably a miss on our end and something we should have been watching for and going
forward, I’ll probably have new tools set up to make sure that I'm alerted on honeyfiles
being touched.
At this part of the investigation, I will take a few remedial steps.
I’ll take HR02 and CEO, these possibly compromised machines off the network and do deeper forensic
analysis on them, change the credentials on this user wgrimes, and possibly even have
a conversation with Mr. Grimes.
(Laughter).
It is highly likely that this is a case of a compromised account, not a case of a
bad internal actor, but it is still good to know what Mr. Grimes may have, or may not
have, done that left this vulnerability in the system that got exploited.
After doing those things, my next steps in the analysis would be looking at all of
the network traffic — remember, we are collecting all of that Packetbeat data and we are setting
up dashboards to look at all of the network traffic — what were these hosts, HR02 and
CO, communicating with in the external world?
What ports are communicated on?
So there's a lot of rich things I can explore and investigate further, but I don't want
to give all of the fun away in this demo.
So what I will say is, if you want to see how the rest of the story unfolds, how did
the attacker get in, how did they steal the credentials, we do have a full-blown version
of this demo, running around the clock, in the demo showcase rooms tomorrow and Thursday.
If you are interested in seeing how this plays out, stop by the showcase rooms.
We skipped over a lot of the meaty details in this investigation but hopefully what the
demo showed you is how the Elastic Stack can be used to collect all of these logs and put
it in a single place and truly engage with them — where you are moving from one part
to the next part to the next part, answering all of these questions, and you are getting
answers back at the speed of thought.
Because, as an analyst, that ability to really engage with my data and do it quickly
is so important, especially in the security space, where time is of essence.
And I believe that reason, that ability to really engage with your data, is one of the
reasons that Elastic Stack is gaining popularity as a security platform for cyber security
professionals, including the likes of Elliott from Mr. Robot.
So do stop by the demo showcase rooms, and back to you, Shay.
(Applause).