We are also very interested in this natively supported, it would also be a nice feature with full customization of the sysmon_conf managed centrally from rapid7
Our events at the top would be:
Event ID 1: Process creation
Event ID 2: A process changed a file creation time
Event ID 3: Network connection
Event ID 4: Sysmon service state changed
Event ID 6: Driver loaded
Event ID 7: Image loaded
Event ID 8: CreateRemoteThread
Event ID 9: RawAccessRead
Event ID 10: ProcessAccess
Event ID 11: FileCreate
Event ID 12: RegistryEvent (Object create and delete)
Event ID 13: RegistryEvent (Value Set)
Event ID 14: RegistryEvent (Key and Value Rename)
Event ID 15: FileCreateStreamHash
Event ID 16: ServiceConfigurationChange
Event ID 17: PipeEvent (Pipe Created)
Event ID 18: PipeEvent (Pipe Connected)
Event ID 19: WmiEvent (WmiEventFilter activity detected)
Event ID 20: WmiEvent (WmiEventConsumer activity detected)
Event ID 22: DNSEvent (DNS query) ā This provides process correlation to queries besides user attribution
Event ID 25: ProcessTampering (Process image change)
You can also check the swiftonsecurity example on sysmonconf to see what is relevant and what is noise:
@nikolai_thoftgaard_jensen noted! Thanks so much for the detailed list of event codes. Our approach for the next phase of this project has been to get feedback from our customers (so thank you, again) & work with our detection engineering team to determine the detections they need to write in order to provide customers with more robust ATT&CK coverage. Looking through your list I do notice some overlap there, but we wonāt have our final list of events until we go through full testing.
I understand EET provides some of this capability but most clients donāt want to pay for this additional subscription, frankly this capability should be standard in any modern SIEM that wantās to be successful. This also greatly assists with a big weakness of IDR: Threat hunting.
Left a request for sysmon ingest 12 months ago, no action, ball has been dropped. Less than 12 months left on the contract, rapid 7 in my opinion is back to āproof of conceptā and the doors wide open for competitors (sysmon ingest) when we go back out to market. Such a shame, rapid7 you have a great product but your failing to ingest something basic like local sysmon from event viewer (not nxlog complex setup) is unexplainable (security 101 rapid7).
Please refer to the swiftonsecurity xml for sysmon basic config.
No money for extra module required rapid7, sysmon is a basic ingest your competitors do stock standard (walk up start inclusion).
@jason_williams - I understand your frustration here. We did begin implementation earlier this year and began a phased GA release of our Sysmon ingestion in late August (initially just process creation events). However, we are currently on hold due to customers reporting the blue screen of death on machines that are also running Visual Studio 2019: BSOD DRIVER_OVERRAN_STACK_BUFFER when attaching to w3wp.exe process with VS2019 - Microsoft Q&A
We are still committed to moving forward, but we need to make sure weāre providing customers with a safe fallback. If you have any interest, Iād be happy to setup a call so we can discuss further.
Yes! Thanks @ntalbot, I should have followed up with this thread. We have independently confirmed the fix and are finalizing testing now - but barring any major surprises we should be able to resume our phased release next week.
Highly anticipated feature! If you can bump my organization into one of the first phase groups for GA, sign us up! After all, authoring this idea post a year ago has not resulted in any early access
Iām jumping in here as a new customer to hopefully get some further traction on proper Sysmon Log ingestion. I had this conversation vaguely with sales and they said they did support Sysmon Logs. I guess I should have pressed a little harder on that question, but i would have never guessed that someone as big as Rapid7 wouldnāt natively support something as common as Sysmon Logging. Letās make this happen, Rapid7!
@john_keese after my last post I did work with the team to try and get the new component rolled out to your machines. Based on your interest, I should have assumed you already had a Sysmon deployment of your own - and the version weāre rolling out now will not try and merge our config file with yours, so the deployment just backs off. The next version weāre planning will actually handle this use case, but that last thing we want to do is disrupt your own Sysmon collection and security operations that may rely on it.
I had passed this info onto your CSM to close the loop but it looks like heās since left Rapid7, so Iāve connected with your current CSM. I would love to get your thoughts surrounding expectations / our current approach on this config file āmergeā so if you have any interest, Iāll work to setup a call.
@bwarren I appreciate you reaching out! The rollout we are focused on right now is changing how we collect process starts to leverage Sysmon. If you already have a large Sysmon deployment you are managing, then unfortunately we wonāt be pushing this out to your organization until the next release (same reasons as my response above to John). But if you do not have a large Sysmon deployment, then your organization is already part of rollout weāre gradually working through right now.
Was investigating running processes on a host in my environment yesterday andā¦hey! Sysmon is now installed across my environment! I gather from the presence of rapid7_sysmon_installer.exe that this was installed as a component of the Rapid7 agent.
It is so exciting to see this logging capability getting integrated as part of the InsightIDR offering! Can Rapid7 offer customers any information about when sysmon event data will be available for searching/alerting/analysis in the platform?
Right now weāre only collecting process start data. Later this year we will be adding more Event IDs to this capability. Unfortunately beyond ālater this yearā I donāt have more specifics for you at this time.
