CONTENT:
At SOC Prime, we are captured with the mission of deriving maximum value from each security tool and enabling the effective protection from the emerging threats.
In August 2020, the SIGMA project adopted SOC Primeās Sysmon backend. The backend generates Sysmon rules to be added to a Sysmon configuration, which is mold-breaking for anyone using āincludeā base filtering for Sysmon.
Microsoft-Windows-Sysmon/Operational EventLog contains all events generated by Sysmon. Selection of the events (generated by the security products relying on EventLog) helps to bring overall event monitoring into line and makes it simple to analyze each of them separately.
The effective use of Sysmon as a detection tool relies on both effective and structured XML configuration schema. You can configure your Sysmon instance through its XML configuration file. Mind that logical operations that you employ to the fields may vary depending on the different schema versions.
You can check up the event types supported by the current Sysmon version here.
Sysmon Rules
With Sysmon Rules, you can set up filtering in the following ways:
You can implement up to 2 instances of each EventType – 1 āincludeā and 1 āexcludeā for the entire configuration, the default relation between filters is AND. If the filters match, they are included and placed in the EventLog using the AND logic.
The RuleGroup element provides an opportunity for picking up more detailed action events. By creating multiple Rule elements with multiple filters it is possible to construct rules of the complex logic.
A RuleGroup has a name and groupRelation options:
Also, you should remember that it is impossible to establish a prover actionable RuleGroup just with several elements of the same filter type (for example, Include-Include). For the āIncludeā filter type, there should be an āExcludeā filter attached to the RuleGroup using the AND groupRelation.
To update your existing configuration with Sysmon Rule from SOC Prime Threat Detection Marketplace:
3. Follow further instructions and insert the āincludeā filter value into the appropriate RuleGroup section:
4. Insert the āexcludeā filter value into the appropriate RuleGroup section:
The events triggered by a certain rule have the RuleName value added so that you can easily explore the details of the triggered event.
To get all content applicable for Sysmon, go to the Threat Detection Marketplace Content Search panel and choose Sysmon at the Platform bar.
Letās take, for example, the SIGMA rule āMicrosoft Binary Github Communicationā by Michael Hag and Florian Roth. This rule is looking for any network connection to github.com from binaries in C:\Windows\ (and all child directories).
Ensuring this activity is captured by our āincludeā based sysmon filter, we can use the Threat Detection Marketplaceās generated translation by selecting āsysmon.ā As seen below, the backend generates an āincludeā based Sysmon filter for the Sigma rule.
Alternatively, one might utilize the SIGMAC python program from the SIGMA repository to generate the sysmon configuration as well. Just set the SIGMAC –config and –target to āsysmonā:
Note: sysmon currently gives precedence to āexcludeā filters. So, you cannot, for instance, exclude everything in C:\windows\system32\ and selectively āincludeā interesting binaries (such as rundll32.exe). Therefore, it is possible that your sysmon configuration could contain an exclusion that causes some related āincludeā rules to fail (no events are generated even if the Include matches).
Subscribe to the Threat Detection Marketplace to reach over 90,000 Detection and Response rules, parsers, search queries, and other content mapped to CVE and MITRE ATT&CKĀ® frameworks. Want to craft your own detection content? Join our Threat Bounty Program and contribute to the global threat hunting initiatives.