Hunting on custom log files with Chainsaw
The previous posts looked on how we could hunt on forged EVTX files. However, in the course of an incident response or advanced threat hunting, not all logs lies in properly formated EVTX files. For example, some firewalls export their logs in JSON format, some application will output XML. On Windows servers, these might eventually reach an event log but on Linux, it will most likely remains as it is. As I don’t like wasting my time, I want to leverage Sigma rules on JSON and XML files. Today, I focus my post on JSON files.
Creating EVTX for malicious activity
Previous post explained my process for developing Sigma rules to detect suspicious activity. A key element in developing such rules is the log file itself. While incident response will provides you plenty of (large) event logs with malicious activity, it might be time-consuming to read hundreds of thousands log lines to find the one you are interested in detecting. Or you might not even have the possiblity to get such event logs; For example, a new version of SysMon is released and you would like to test the new capabilities.
Developing Sigma rules with Chainsaw
From my experience, when you find evidence of malicious activity in a log file, there is probably more somewhere else, and the actor is likely to continue using the same tools and techniques unless you detect it. Instead of just looking at lines in a log file, when you discovered a malicious activity, write a detection rule that can be applied to all your systems for retro-hunting, added to your detection stack for future events, and shared with peers and partners to benefit the greater good.