In this demo,
we're going to enable rules and evaluate their effects
using a PCAP replay with captured traffic.
We have three goals from Globomantics for this demo.
First, we need to select the appropriate rule sets to detect an exploit.
We will determine the appropriate rule set by testing each of our
potential sets using a PCAP replay and evaluating the output.
Last, we need to ensure that we detect the threat with our selected rule sets.
Let's head over to our Suricata server and get started.
So we still have the emerging threats rules set loaded and noticed two
alerts when we tested this traffic on our first run.
We captured that traffic to a PCAP file,
and now we can enable each rule source and then test it using the same
traffic with the suricata ‑r option to replay that PCAP file.
Let's go ahead and start by using suricata‑update to enable the
threat hunting rules and check our results.
All right, we have enabled that source.
Now let's go ahead and run suricata‑update to download the latest
copy of the rules and put them into effect.
And it looks like it actually disabled ETOpen now,
so let's go ahead and re‑enable emerging threats open rule set.
And we'll run sudo suricata‑update again.
Perfect.
There we go, 30,000 rules loaded.
So now that our rules are updated,
let's go ahead and replay that captured traffic using suricata ‑r.
You should have this command in your history,
so let's go ahead and just run that same one again to replay that
log.pcap file like we did in the last demo.
Now we'll look at the output of that using a tail command.
One interesting thing that Suricata does when you run a packet replay mode,
it places the log files in the current working directory.
So we can just enter the command tail fast.log and
read the files from our PCAP replay.
You'll see a few different results from multiple tests that I've run,
but these last two are the latest from that last PCAP replay.
So you won't see any new alerts generated by adding our threat hunting rule set,
which means that it did not detect our exploit or the Meterpreter shell.
Let's try re‑enabling our custom rule source and see
if we get any different results.
Now let's run suricata‑update again. Even though we had the error, notice that
it still downloaded our example rules from our custom source.
So now we can test these rules with our PCAP replay. Let's
go ahead and run that command again.
Now let's take another look at our fast.log file, and now we have some
new alerts generated by our customer rule source.
We can see here that it's generating alerts based on the
use of a common reverse shell port, 4444.
And we have our emerging threats rules here again.
Let's go ahead and look at the entire fast.log file to see if we can see any
other alerts generated by our custom rule set. And our customer rule set
generated the alerts we would expect. We have an UnrealIRCd backdoor
attempt, we have inbound IRC traffic to our internal server, and we have a
possible successful exploit letting us know our systems are trying to
communicate out to port 4444,
which is the default port Metasploit uses when it sets up a reverse shell.
We also have the same two alerts we saw earlier and more
examples of communication between our internal server and
port 4444 on a remote host.
So re‑evaluating our three Globomantics goals,
we selected the appropriate rule sets to detect the exploit. We
determined the appropriate rule set for this particular exploit is
going to be our custom rule set by conducting two PCAP replay tests and
verifying that the third one did, in fact, detect the successful
exploit of our Metasploitable server.
So we've achieved our three Globomantics goals for this demo.