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.
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.