Sysmon 32 Bit Download
Stephanie Dejoode
We are going to be discussing ingesting this data internally and don't have a starting point yet -- but the plan is to enable sysmon on a handful of workstations and measure the ingest; but we're a few weeks away from that at this point. We've got about 6,000-7,000 workstations on campus we're interested in collecting this data from.
I'm interested in collecting sysmon from workstation and the scope is pretty much equal as you have. Can you, please share any calculation of what is (approximate is good) the volume of symon data per day I should expect from 1K hosts?
The volume of data for the universal forwarder to forward varies significantly depending on your sysmon configuration as well as the activity levels of users and background processes on monitored hosts. For a common logging baseline to plan against, a good starting point would be the IR community maintained SwiftOnSecurity GitHub repo. I would plan for about 160 GB/day for every 1000 hosts sending sysmon data with SwiftOnSecurity config.
Based upon the new logging enhancements to the IDR platform, I am confused as to whether or not these logs are now automatically being collected. The notification to customers states that all System/Security/Application logs on Windows Endpoints are now collected. If that is the case, where can I find my sysmon logs?
As a defender I am continuously testing, tuning and re-testing a plethora of detection ideas across many complementary detection frameworks. However, a skilled DFIR practitioner values the confidence gained from cross-validating one tool's results with those produced by similar tools. Over the past nine months I have spent significant time researching new obfuscation and evasion techniques, and a good portion of this time I have spent validating the effects of these techniques on numerous detection artifacts and tool sets. This blog post highlights a bug I found in Sysmon's event logging that contaminates process command line argument logging and adversely affects at least two different tools used for viewing Windows event logs.
First of all, I have been a fan of using Sysmon in my personal testing lab setup since its original release in 2014. Sysmon (System Monitor) is part of Microsoft's Sysinternals Suite and was written by Mark Russinovich (@markrussinovich) -- thanks, Mark! The Sysmon driver installs as a service and logs numerous Windows events to the Microsoft-Windows-Sysmon/Operational event log. Most recently updated on January 5, 2018, v7.01 supports twenty-two different Event IDs ranging from process execution events (EID 1 & 5), network connection events (EID 3), image load events (EID 7), named pipe events (EID 17 & 18), WMI events (EID 19, 20 & 21), all the way to registry events and much more!
Over the years there have been numerous blog posts written on using Sysmon as a data collection source for endpoint visibility and threat hunting. In addition, Sysmon configurations such as @SwiftOnSecurity's sysmon-config project ( -config) have popularized the filtering capabilities that Sysmon supports for data collection tuning. Finally, Microsoft recently published the Sysinternals Sysmon Suspicious Activity Guide ( -sysmon-suspicious-activity-guide/) which serves as an even better overview than what I am attempting to convey here.
At the end of the day, an increasing number of defenders rely on Sysmon for some level of endpoint visibility and it is worth cross-comparing Sysmon as a data source with similar but officially supported (by Microsoft) data sources before one begins or continues investing detection logic applied to data logged and collected from Sysmon. In particular, it is encouraged to test both the data source and the tooling used to query, aggregate and analyze the data source in question.