Thread by @Purp1eW0lf

Let's quickly look at how Defenders can benefit from tools like Chainsaw, Sigma, docs from KAPE & Velociraptor, and Security Onion 🕵️‍♂️

We'll use real, shady data - fresh out the kitchen 🧑‍🍳

Along the way, I'll share some tips and shortcuts to cut faster through data and logs

🧵

We had an alert for a ScreenConnect session on a DC involving a PowerShell script called 'LAPSToolkit'

This COULD could be for legitimate auditing. But adversaries have been known to use ScreenConnect for their campaigns.

github.com/leoloobeek/LAP…

huntandhackett.com/blog/revil-the…

I don't want to waste anyone's time by highlighting false positives.

So we'd need to dig a bit deeper on the host, and see if any findings can contextualise this activity as legitimate or malicious.

To start, I'd like to pull some data from the machine

But which data? From where exactly? We don't have all the time in the world to take a full forensic image for every alert.

To specify which data, I go to the docs on Velociraptor's implementation of KAPE.

Searching with ctrl+f is my genius technique

github.com/Velocidex/velo…

My even clevererer technique for sourcing specific data on a machine is Google.

Googling: "ScreenConnect dfir", will bring up @_bjmac_ 's excellent blog post on digging deeper on ScreenConnect.

So from Velo and @_bjmac_ we have ideas to further investigate our initial alert.

For this investigation, we'll stick with pulling EVTXs*. But on some occasions we might go and get some forensic artefacts that will offer even MORE context for us.

*The pic below isn't how we pull logs IRL at work, but I do use this script in my homelab

gist.github.com/Purp1eW0lf/e0b…

Now we have some logs extracted, I'll deploy Chainsaw

We see ScreenConnect with EventID 7045, which offers insight into how it was first installed.

We now have a starting point for the first alert : it seems like ScreenConnect was installed, and shady activity followed.

Btw, because I leverage Chainsaw a tonne, I've ended up creating an alias.

This means I only have to type one word in my terminal and it will let rip on the hardcoded directory I always put data in.

github.com/countercept/ch…

It's worth noting how Chainsaw knew to bring this up for us.

Chainsaw leverages Sigma rules, which can pick specific parameters to alert a Defender for.

Using Sigma this way lets Chainsaw carve through our extracted logs with a very clever 'grep'.

github.com/SigmaHQ/sigma/…

Okay now we have a couple of things: our first alert about the PowerShell script, and a potential installation date.

To make these logs go further, I leverage Security Onion - specifically in the more lightweight, performant IMPORT deployment

[docs.securityonion.net/en/2.3/archite…]

Think of Security Onion's Import architecture like a rapid, smart ELK stack.

I use Security Onion a bunch, and have an alias that relies on password-less ssh key auth. It then transfers the EVTXs over to our Onion, and imports and ingests the logs.

Once in ELK, we can best contextualise ScreenConnect's activity, and determine that if the proceeding and subsequent activity around installation could be considered SUS

I'm not going to share more than that - mainly because we went back to our partner on this one👀

And thats all for now! Thanks to all the tool creators.

I recreated the real data so I could share a System.evtx log* and anyone interested can follow along this tweet thread and deploy the tools, as well as drop some un-redacted screenshots:

* mega.nz/file/IqQhFAAD#…