I've been using Kansa for years now, both as a way to gather a variety of forensic artifacts and logs, and as a tool for threat hunting. There was only one thing that really annoyed me about it though - all of the returned data was stored and analyzed on my local machine, and I always thought that manually analyzing csv and json files (or using the bundled analysis scripts) was a pain. There wasn't a whole lot of room for collaborative analysis, or the ability to look at Kansa output alongside other log/event sources. To remedy that, I added two additional output options - Splunk and GrayLog. Now Kansa output can now be analyzed right alongside other centrally logged data - awesome! My goal for this post is to show how enterprise DFIR can be established with little to no cost in less than 30 minutes.
Here's a brief outline of the steps required to set up Splunk & Kansa
- Download and install Splunk
- Configure Splunk's HTTP Event Collector (HEC)
- Download Kansa & configure Kansa
- Collect data!
Obviously, there's two major components we're going to need to download, install (where appropriate), and configure. First up is Splunk.
A note, though, before we begin. Splunk isn't Open Source software, but they do offer a 60-day trial for their enterprise offering. If the company you work for already licenses Splunk (and won't, for some reason, give you access to the HEC), you can sign up for a free developer license and all of the benefits of the enterprise offering (with a whopping 50GB ingest limit!) for no extra cost. There's also a free/community offering... but if I'm being honest, I don't really know what limitations come with it.
Head over to splunk.com and download the most recent version (as of this writing, it's 8.0.2). Once you've downloaded the installer, go ahead and run it. The first screen you should see is one prompting you to accept the licese agreement - check the box, then hit next.
Next you'll be prompted to create a user and password - do it, then hit next.
Finally, you're given one last chance to bail out, and also asked whether or not you want a shortcut dropped on your desktop. Check the box, or don't - it's up to you. But do click the install button.
Installation should take a minute or two - enough time that you could probably go get a drink, say hi to your family & pets, and come back to this:
Leave the "Launch browser with Splunk Enterprise" box checked and click Finish.
Configuring the HTTP Event Collector
Now you should be greeted with Splunk login page. Remember the creds you created during the install phase? You'll need those here. Enter them, then click the "Sign in" button (or hit enter - whatever suits you).
You'll be immediately greeted with a few pop-up windows. The first is something you see when you first log on - read it or disregard, it doesn't matter. The second talks about how Python 2 is end-of-life and that Splunk is still working on transition the code base to Python 3 - feel free to click through this too (or have them remind you in two weeks if you're interested). Anyway, those pop-ups aren't important to what we're doing here.
At the top of the Splunk window, towards the right hand side, click Settings, then Data Inputs.
Now you're presented with a list of methods of getting data in to Splunk. For our purposes, we're going to use the HTTP Event Collector (HEC) - click the "Add New" link to the right of the HEC list item.
The next few screens will be used to configure the token we'll be using with Kansa. First, we'll want to configure a name for the token. Call it whatever you want - we'll call this token "Kansa" since that is what it'll be used for. I don't recommend setting a Source Name Override (we'll see what later). Provide a description if you want... I typically don't. Anyway, after you've entered the appropriate information, click the green next button (which, interestingly, is towards the top of the screen).
Now we need to make a few important decisions. The first is setting your Sourcetypes. I strongly recommend leaving this set to the default selection of "Automatic" because Splunk will assign a Sourcetype to each log line according to the name of the Kansa module data is ingested. Your next big decision is selecting an App context - I generally change this to "Search and Reporting" since we're not associating this with a particular Splunk app which would apply additional settings or provide additional parsing/extraction on the data.
After that, scroll down and choose which Index we want Splunk to deposit the data in. I'll make it easy and go with main, but you can choose another existing index, or create a new one. Once you've selected your Index, click the review button at the top to move on to the final step.
If you're satisfied with the decisions you've made, click the green Submit button to wrap up this portion of the HEC configuration.
And this is where we think we're done with the "Configuring the HEC" portion of this little exercise... but we're really not. The part that Slunk hasn't told you at this point is that you're not really done (despite what it may tell you) - no, you have to activate the token... so, click on the Data Inputs link!
Note: clicking the Data Inputs link will open the Data Inputs section in a new tab. Hopefully your browser is nice and switches over to the new tab automatically.
Scroll down and click on the HTTP Event Collector link. Incidentally, notice that there's also a "1" in the Inputs column next to the HTTP Event Collector list item (woo - progress!)
This should open up a new screen where you can view details about all of your HEC tokens. At this moment, you should be able to see a very angry red box with a bang in it - if you mouse over it, it'll tell you that your tokens are disabled. Bummer. To fix this, click the edit link next to your token to bring up a token settings menu.
Click "Enable" (I believe it's selected by default... but I like to click it anyway, just to be sure). Then click the green "Save" button at the bottom right of the menu.
Hooray - our token is enabled! Make note of your token value and lets move on!
Downloading & configuring Kansa
The main Kansa repo is available here: https://github.com/davehull/kansa
If you have git installed, just do a git pull on that repo. If you don't have git installed, just navigate to the Kansa repo as linked above, click the green "Clone or Download" button, then click the "Download Zip" link.
Once you've downloaded Kansa, fire up Powershell and navigate to your Kansa directory - we'll need to unblock scripts that comprise Kansa so that they will run. In order to do so, just issue
Get-ChildItem -r | Unblock-File in the Kansa directory and all will be good.
Now, we'll go ahead and navigate to our Kansa directory in Windows Explorer and edit
logging.conf. I'm going to edit it with Notepad++, but feel free to use whatever text editor you have on hand - default appliations like WordPad or Notepad (use the "Open With" menu item for these options) will work just fine.
We'll need to edit two lines in
- Enter your HEC token on line 11 (it should start with
splHECToken) - don't surround your token value with quotes or anything, just enter the token value.
- Enter the name of the machine that's hosting your Splunk instance on line 12 (
splServerName) - same thing here - no quotes around the machine name.
Note: if you don't know the name of your machine, just open Powershell and enter
$env:COMPUTERNAME at the prompt.
And that's all for configuring things! Now we can actually start USING it all!
And now for the fun part!
Before we get started, I suppose I should mention that Powershell remoting needs to be enabled for all of this work... Here's a simple one liner to test:
[bool](Test-WSMan -ComputerName $env:COMPUTERNAME -ErrorAction SilentlyContinue). If that returns "True", then you're good to go. If not, well, make sure Powershell remoting is enabled on your target machine(s).
Open up Powershell, navigate to your Kansa directory, and enter something that looks a bit like this:
.\kansa.ps1 -Target dc2 -Credential (Get-Credential) -OutputFormat SPLUNK. You'll be prompted for credentials... Against one target, you can use a local admin's creds it should work fine. However, if you're going to specify several targets, you'll want to use domain level creds (note that I didn't say domain admin level creds).
And now we can go check Splunk...
Woo! Data! So... what sort of data have we collected, exactly?
Do note that the Source names are the same as the Kansa module that harvested the data.
One final thing... I made an improvement to the
Get-LogWinEvent module that hasn't been merged in to davehull/Kansa repo - the pull request has been submitted, but not approved at the time of this writing. The improvement I've submitted improves the parsing on Windows Event Logs. One of the more annoying aspect of WinEvt logs is that they're stored in XML, and some of the most useful information contained in the Message field of the log is buried several layers deep in the XML schema. But, I've improved the parsing of WinEvt logs so that all of the useful data in the Message field is now indexed and searchable!
Note that the data in the screenshot above is parsed out in the screenshot below! This isn't the normal behavior for
Get-LogWinEvent, or the
So... why is this important?
If you already have Splunk in your environment, then using Kansa to get additional host level information in to Splunk should be trivial. Many organizations don't gather all of their endpoint logs. In large orgs, that's a substantial amount of data, and could very well bust through your Splunk license. So, if you identify several Windows hosts that are compromised and want the logs off of them AND want those logs to be indexed and searchable in Splunk... well, now you have a way.
You can use Kansa to deploy additional binaries (like Sysmon, if it's not already being pushed out via some other tool) that can aid in your DFIR endeavors. So, doing that, plus being able to harvest WinEvt + Sysmon logs? That's pretty handy.
Also, one of my favorite modules is
Get-File, you can retrieve one or more files off of a target's file system. The file is returned to you as a Bas64 encoded Gzip'd string... So, now you can use Splunk as budget file storage mechanism for interesting files... or a really janky malware zoo.