So for anyone who doesn’t know, I’m a bit of a Graylog fangirl. If my selfies were at all flattering I’d insert a pic of me sporting my Graylog t-shirt here. Although I leveraged Graylog at a previous job, I no longer use it day-to-day. For that reason, I went ahead and spun up an instance in my home lab to play with.
I wanted to work on a project that hadn’t been done before while also filling in another gap in my life since switching from DFIR to Intel/Threat Hunt: Memory Forensics. That’s when I recalled a project I’d bookmarked months earlier: vol2log. This is a set of Python scripts that perform the prep and communication necessary for shipping Volatility JSON output files to Graylog.
I started by setting up the inputs, grabbing a memory sample, and just playing with this project itself; seeing how everything looked coming into Graylog. It was very simple to use. Plus, not only does it ship the Volatility but it also checks for “potentially malicious processes” based on certain conditions being met. Essentially, it is looking for conditions with well-known processes that don’t align with common behavior, such as that described on the SANS memory forensics cheat sheet. For example, more than 1 process where only 1 should exist, incorrect parent processes, etc.
Now that I knew the kind of data I was working with, I threw together a few pipeline rules to normalize the field names across the various plugins and to add a useful message field (since the default for vol2log was simply “True”). Here is an example of one of those plugin rules:
rule "volatility pslist normalize"
to_string($message.plugin) == "pslist"
set_field("message", concat("pslist plugin found process with name ", to_string($message.process_name)));
With normalizations complete, I was able to create some visualizations. This was also the perfect opportunity to try Graylog 3’s “Enterprise Views” feature. Below are some shots of the view I created.
The next step for me was to improve the process a bit by throwing in some automation. With vol2log’s current set up, you’d have to run Volatility for each plugin and send to an output file and then run vol2log one-by-one for each plugin output. By adapting a bash script I had written a while back, I much improve this process by creating a method by which a user simply has to provide an output directory, the path to the memory image to analyze, the Graylog IP and port, and the name for the source. It then loops through the list of available plugins to run Volatility and then run vol2log. I’ve open sourced that script here: https://github.com/megan201296/vol2graylog.
The vol2log remote was also limited in the number of plugins is supported out of the box. I’m working on testing other plugins to see if they work with the existing vol2log “generic” processor and if so will add them to the default list script. For now, the list that will be run through is in the README of the repo.
To speed up the process of getting working with the data, I’ve also published a content pack that contains all the pipeline rules I made here: https://github.com/megan201296/graylog-content-packs. Since Views can’t be exported to content packs, I need to make a dashboard version in order to add it to the content pack, which I hope to do in the future.
I am still actively working on this project but wanted to share what I have so far since it is functional and fairly useful already. I hope to write up an example use case soon to show how I might leverage this project to analyze memory images of potentially infected hosts.
Feel free to submit issues or PRs to the repos. Feedback is extremely welcome!