Endpoint detection Superpowers on the cheap — part 1
In this blog series, I will talk about my endpoint detection stack focused on Windows environments and mostly based on Sysmon.
I feel I need to fire some form of disclaimer;
This series of posts are not a silver bullet. It will require tuning and real work to be truly effective in your environment.
That said this will also be your biggest benefit, that work will pay off in various strengths which will be discussed later.
ATT&CK
I must start this post by highlighting the great work accumulated in the MITRE ATT&CK framework. Most of you are familiar with it by now and if whether are or not, please schedule some dedicated time to properly go through it. It truly is a treasure trove for security people, regardless which side you're on. They describe it themselves as;
“ A framework for describing the behavior of cyber adversaries operating within enterprise networks. ”
Which simply put boils down to a comprehensive library of “what to look for”. They capture attacker tools and techniques in a generic way, guiding and encouraging you learn to adopt them for yourself. They don't give specifics, which will (hopefully) keep you from suffering from tunnel vision in trying to detect these techniques.
Sysmon
There are already a lot of great resources explaining all kinds of things about sysmon, I've learned a lot from Roberto Rodriguez and SwiftOnSecurity so check them out.
The most important part about sysmon which I do want to highlight are its sensing powers. Based on the configuration you provide it, it is able to log the following events;
- Process creation (with full command line and hashes)
- Process termination
- Network connections
- Various file events
- Driver/image loading
- Create remote threads
- Raw disk access
- Process memory access
- Registry access (create, modify, delete)
- Named pipes
- WMI events
These events will be stored in the Windows Event Log within Microsoft-Windows-Sysmon/Operational.
Configuration
There are quite some good configurations available on the internet already, despite that I still decided to create my own repository a couple of months ago for several reasons.
First and foremost I wanted to create something that is modular, which makes it easy to maintain, switch a small building block or add something that is specific to you or one of my customers. As I mentioned in the beginning of this blog, you'll need to be tuning. Some drivers, processes or other events which are operating fine for me and my customers might be extremely noisy in your environment.
Apart from that I wanted to map every capability I could interpret to the MITRE ATT&CK framework and track my coverage.
What I did is use a base template configuration, which is essentially an empty skeleton to be used on any configuration module.
Next I created subfolders per EventID type to be generated by Sysmon. Within these folders there are often 2 types of configuration XML files, include and exclude certain event types.
The above example will generate a log event whenever the Image (launched process) will end with regsvcs.exe or regasm.exe respectively. The corresponding MITRE technique is added behind each mapped item as a comment. Currently there is no support for log augmentation but my feature request to add this has been confirmed as being on the to-add list.
The above example prevents Sysmon from logging whenever one of the (Parent)Images is launched. These generate a lot of logging where the true negatives are expected to very slim.
This obviously is always a tradeoff between visibility and noise, in the end it should be a factor in the decision to accept the risk of missing it or not.
If we dig a little bit deeper into the configuration options there are a few notable things. One of the most important things is that each rule is considered as a single configuration, there is no way to stack options of for instance a process together with a specific command line. Each line will be processed by itself, which requires you to think it through.
To understand which options are available you can start Sysmon with the -s attribute, this will show you the currently supported schema, commandline parameters and filtering options. (the full schema is visible here)
The above image shows all configuration options that can be used to specify a configuration rule. Depending on your detectables you could also create multiple indicators for certain techniques should you so desire.
To specify each condition the following options are allowed; is,is not,contains,excludes,begin with,end with,less than,more than,image
All these modules can be merged into your configuration through a PowerShell module created by Matt Graeber, how to do this is mentioned in my git repo.
I strongly advise you to always run this generated configuration first on a representable set of machines within your network before deploying it enterprise wide.
You might want to add some driver of process exclusions for instance for not get flooded with events. There are touchpad drivers in existence for example that think it’s a great idea to use the Windows registry as a buffer to -all- mouse movements, trust me there are developers that do this… :)
Numbers
This repository is used by me and my colleagues (apart from the rest of the ppl that forked/cloned it) at several customers varying from several hundred to thousands of systems. Some will have some tailored configurations due to their specific needs. In general the currently running configuration does generate on average between 5–25 megabyte per day. This obviously depends on the local activity of the system and whether it is a workstation or a server. Regardless, these amounts are perfectly digestible in any SIEM/Logger/whatever you prefer to use.
Closing
This post focussed primarily on Sysmon and its configuration, next topics will cover;
- Part 2 — Deployment and maintenance
- How to start interpreting the logging to help you tune your config
- My Threat Hunting app for Splunk based on ATT&CK
- more
