For my inaugural post, I'd like to share something I've been sitting on for the past two or so years... I've been a pretty heavy user of Dave Hull's Kansa framework for a number of years - not just for IR work, but also to facilitate threat hunting.
One of the things that has always annoyed me about Kansa (or any other kit comprised of a bunch of scripts) is that you're forced to either analyze a bunch of csv/json/txt/xml files individually, or grep over them. Both approaches have limitations, and I wanted something better. Having worked a lot with Splunk, I wanted the data I pulled with Kansa to be automagically ingested by Splunk. I guess I could have scripted a file transfer job to copy my Kansa data over to a folder monitored by a universal forwarder or something, but that seemed tedious.
And so, I continued to toil away, grep'ing through csv files and doing analysis on the command line until one day in 2016, I discovered the Splunk HTTP Event Collector (HEC). I immediately recognized this as the solution to my gripe and proceeded kludge'ing my desires in to Kansa. I knew my initial solution was... sub-optimal... but it worked and I promised myself I'd re-write the code to make it less kludgey. As I was wrapping up writing the code to send Kansa results directly to Splunk, I had just caught a presentation at the local BSides on GrayLog and had set up an instance to play around with. So, for the hell of it, I decided to include a GrayLog output option too.
Well, it took me 2+ years to keep that promise, but I finally did! I re-wrote the code for Splunk and GrayLog outputs and committed it to my Kansa fork. I also created a pull request to get it merged in to the master branch under Dave Hull's original project...
A few notes...
- Data is sent to the "services/collector" HEC endpoint because each log line/event retrieved is piped to ConvertTo-JSON. Also, if I remember correctly, this was the only option circa 2016. There's a new "services/collector/event" endpoint available, and I believe it can receive unstructured data, or non-JSON formatted structured data (XML, for all of your WinEvt logs). Anyway, I prefer to send JSON data in because Splunk will automagically parse it for you. It makes it really easy to set up scheduled searches for alertable conditions.
- A lot of organizations don't put Splunk Universal Forwarders on all of their workstations, or have a scalable way to get Windows Event Log off of workstations. This is a reasonably good way to do it. Hopefully you have good logging policies configured via GP.
- With respect to data representation in Splunk, the source is set to the sending Kansa module. If you have any TA's installed that are looking for a Windows Event Log name in the source field, this may be a bit of a bother to you.
- I wrote an additional module that will deploy sysmon. I'll commit it sometime in the near future because it is pretty handy to be able to push sysmon out during an incident. However, I think that centrally managing sysmon via GP or SCCM is a better option.
2. For the curious, my initial solution was to follow the example of the existing output types, but include all of the Splunk/GrayLog server parameters directly in the code of Kansa.ps1. So, if you wanted to change any of the server parameters, you'd need to edit the code of Kansa.ps1. Obviously this was sub-optimal, and configuration parameters belonged in a configration file. And so, that's what I set about doing this weekend.
3. Sorry ELK users - I haven't gotten around to writing an output option for ELK yet. Mostly because I don't use ELK all that much and partly because I hate Lucene (yes, I realize the hypocrisy with me writing a GrayLog output option, but you get to deal with that idiosyncracy).