Using Auditbeat and ELK to monitor GTFOBins binaries.

At in.security our training courses are developed not only to provide the theory and hands-on understanding of a multitude of offensive techniques,  but with the added extra of being able to see, study and understand the attacks from a blue team perspective by viewing self-generated artefacts left within our in-LAB ELK stack.

This type of infrastructure can be very useful when searching for key indicators of compromise and post-exploitative activities, so in this quick post, we’re going to show how to quickly log and view access to binaries listed on GTFOBins using Auditbeat and ELK. It is assumed that you have a Linux host running the  Auditbeat agent and have these events shipped to ELK in some form.

Let’s start by getting a copy of the GTFOBins repo which contains a current list of all binaries that have some sort of ‘abuse ability’ documented for them.

git clone https://github.com/GTFOBins/GTFOBins.github.io.git ~/GTFOBins

Next, we need to see which of these binaries are available on the system we wish to audit so we can generate a rule for Auditbeat. This can be achieved using the following one-liner. 

for i in $(ls ~/GTFOBins/_gtfobins/ | sed ‘s/\..*$//’); do path=`which $i`; if [ “$path” ]; then echo ” -a always,exit -F path=`which $i` -F perm=x -k GTFOBINS”; fi; done

We should end up with something like the following (screenshot redacted, as the list may be quite long)… 

Take this output and paste it into your existing /etc/auditbeat/auditbeat.yml configuration.

Restart the the service, run a few of the GTFOBins binaries we’re now monitoring and get ready to view these interesting events in Kibana!

As we’ve tagged these events with ‘GTFOBins’ (using the -k switch in the above command), we can easily search for these with the filter: tags : “GTFOBINS”. In this example we’ve identified some suspicious activity!

As always, please do you own checks after implementing to ensure the desired data is collected as intended.