Now that was the hunt.
You found the needle in the stack of needles.
Now armed with the user, hostname, and process GUID from the anomalous activity,
you can leverage the investigative dashboards in Kibana to
attempt and get the rest of the story.
The user Ultron launched Rubeus to start.
So with Ultron in the user field, click Update,
and now this dashboard lights up with activity.
Zoom in on the active spikes for logons by system,
and you can see activity by this user, not just on the host in question,
but also on another host, exec‑01.
Look at the timing between the activity.
Just from a visual perspective, knowing that credential stealing tools were used,
this looks like the user laterally moved to exec‑01
directly after activity on hr‑01.
The event count per hosts shows more activity on hr‑01 than exec‑01,
characterizing hr‑01 as the primarily compromised device,
and then in the executed commands,
you can see the use of PowerShell to launch bitsadmin.exe to
transfer a file to the 10.102.5.94 address,
which you can quickly track back to hr‑01.
So hr‑01 has Kerberoasting activity right after we see
activity on exec‑01 by the same user transferring files with a
_____ bin back to the original host.
Bitsadmin as the _____ bin. It just means living off the LAN binary is an
existing service on Windows that's there natively that's often used to
transfer files or download files from the internet.
Now,
saying that that very quickly paints a picture feels
like a little bit of an understatement, but you're not even done yet.
Next step in the investigation is the Host Dashboard.
Using the host information from the Jupyter Notebook output,
hr‑01, you get the other side of the story.
Ultron is the primary user during this time period, so that lines up.
Scrolling down a bit, you can finally see ElastAlert output,
one of the services we didn't really talk about yet,
which has been running in the background against the logs
in the Elastic Stack using Sigma rules.
These rules are like Suricata or Snort signatures,
but for the endpoint logs and alert you to suspicious activity,
of which the number one is Eventlog_Cleared,
which absolutely lines up with the predominance of the
wevtutil.exe found in the Jupyter Notebook as well.
You started out with some intelligent relationship modeling that
teased out the Rubeus Kerberoasting activity,
or at least the executable launching, and had some clues
about something going on with wevtutil.
By using this output from the Jupyter Notebook to hunt
through the data in the Kibana dashboards,
you now have found the use of BITS admin to transfer data,
as well as a clear indicator that the wevtutil.exe was indeed used to clear
event logs on hr‑01 after the malicious activity was complete.
That's a pretty full story connecting the different events of the kill chain.
But one rock that you could cast is that you cannot guarantee that the
Rubeus executable was used for Kerberoasting or what account
permissions were leveraged if it was successful.
But, there is still one piece of information to investigate, the process GUID.
After entering the process GUID in the Process Investigation Dashboard, you
not only get a solid timeline of exactly when this process was ran, but also
the confirmation that Ultron ran Rubeus, in this case, to generate a Kerberose
ticket for the administrator account.
Phew, did you just get goosebumps, because I got goosebumps?
That is a rare level of clarity that came together
impressively fast once the initial hunt in the Jupyter
Notebook yielded suspicious activity.
Even for me, the first time I launched HELK,
I wasn't really feeling what all the hype was about.
It wasn't until I followed the hunt methodology,
thought of a hypothesis, and then used the tooling to validate my
hypothesis and investigate the clues that I came to really
appreciate the power of all these capabilities in one cohesive
package. Is there more to find?
Certainly, and there always will be.
But before you turn loose on your own network information,
I want to show you one last thing.
Back in the Jupyter Notebook under the sigma folder,
you will find all of the Sigma rules that can be ran against the logs
in Elasticsearch. Invoking the most prolific hacker methodology ever,
use Ctrl+F and you can find the rules for Rubeus, Windows Log
clearing events, and many more.
But at least at this time,
I didn't find any for BITS admin activity because that's a common
service that's used for downloading Windows updates.
But that was still something that was detected after following the output of
the enriched information and painted the whole picture.
The ElastAlert is a great finishing touch that did confirm suspicious things
about wevtutil after tracking down the suspicious process.