Hi, With the new *sysmon decoders* it is necessary to split the current *windows decoder*. So, you must have the decoders in this order:
*<decoder name="windows">* <decoder name="Sysmon-EventID#1" <decoder name="Sysmon-EventID#1_new"> <decoder name="Sysmon-EventID#2"> <decoder name="Sysmon-EventID#3"> <decoder name="Sysmon-EventID#4"> <decoder name="Sysmon-EventID#5"> <decoder name="Sysmon-EventID#6"> <decoder name="Sysmon-EventID#7"> <decoder name="Sysmon-EventID#8"> *<decoder name="windows-EvtLog">* Please, pay attention to the last one. If you want to use sysmon decoders, *you need this decoder too*. Try to replace your current windows decoder with the above decoders (copy from line 174 to 418 of this file <https://github.com/wazuh/ossec-rules/blob/master/rules-decoders/ossec/decoders/windows_decoders.xml>). Remember that in this way you don't need the sysmon decoders in *local_decoder.xml.* As mentioned Santiago, if you prefer you can use the script *ossec_ruleset.py* with options *-r -u* to update all out-of-the-box rules. What is your OSSEC version?. On Wednesday, January 13, 2016 at 9:49:18 PM UTC+1, Brent Morris wrote: > > Thanks Santiago. > > My apologies if my message was curt. I haven't seen Wazuh and I knew the > existing Sysmon decoders work fairly well. When I looked at the ones on > Wazuh, they looked fairly different than the ones I know to work. I spent > a bit of time contributing back to Josh's Github repository for them and > hit the wall with some of the variations of sysmon logs > > Thanks for the explanation! I'll take a look at Wazuh. > > On Wednesday, January 13, 2016 at 12:25:36 PM UTC-8, Santiago Bassett > wrote: >> >> Hi, >> >> Wazuh ruleset includes more than 200 new rules and mapping with PCI DSS >> controls (tagging also out-of-the box OSSEC rules). We started this effort >> for some of the OSSEC deployments we are working on, and decided it was a >> good idea to put together a ruleset (specially for cases where OSSEC is >> used for PCI DSS or in Amazon AWS environments). Currently our team is >> maintaining these rules and actively developing new ones. >> >> Regarding Sysmon decoders, we recently modified them ( >> http://defensivedepth.com/2015/12/19/new-sysmon-ossec-decoders/), fixing >> a few issues and of course contributing back to ossec-hids repository. >> >> Info on how to install the ruleset can be found here: >> http://documentation.wazuh.com/en/latest/ossec_ruleset.html >> >> If you decide to use the automatic installation ( >> http://documentation.wazuh.com/en/latest/ossec_ruleset.html#automatic-installation), >> >> you can run: >> >> ossec_ruleset.py -a -u -s >> >> That will create a backup of your existing rules and decoders, install >> new ones, and modify your ossec.conf to include these lines: >> >> <decoder_dir>etc/ossec_decoders</decoder_dir> >> >> <decoder_dir>etc/wazuh_decoders</decoder_dir> >> >> Hope that helps, >> >> Santiago. >> >> >> >> >> >> >> >> On Wed, Jan 13, 2016 at 11:39 AM, Brent Morris <[email protected]> >> wrote: >> >>> You should try these for Sysmon events. >>> >>> >>> https://github.com/defensivedepth/Sysmon_OSSEC/blob/master/Sysmon_OSSEC-Decoders.xml >>> >>> I'm not familiar with wazuh, if it's a fork of OSSEC decoders/rules or >>> what? >>> >>> I can tell you that the ones I've linked will work without breaking >>> other things... >>> >>> On Wednesday, January 13, 2016 at 7:24:40 AM UTC-8, [email protected] >>> wrote: >>>> >>>> Hello, >>>> >>>> I incorporated wazuh's custom OSSEC decoders for sysmon events ( >>>> https://github.com/wazuh/ossec-rules/blob/master/rules-decoders/ossec/decoders/windows_decoders.xml) >>>> >>>> by placing these decoders into /var/ossec/etc/local_decoder.xml. However, >>>> when I did this, the normal windows rules in >>>> /var/ossec/rules/msauth_rules.xml would no longer fire. Obviously I >>>> created >>>> a conflict of some sort, but I'm not certain where. >>>> >>>> To expound, here is a sample log line: >>>> >>>> 2016 Jan 13 08:19:04 WinEvtLog: Security: AUDIT_SUCCESS(4733): >>>> Microsoft-Windows-Security-Auditing: (no user): no domain: foo.local: A >>>> member was removed from a security-enabled local group. Subject: Security >>>> ID: S-1-5-18 Account Name: foo-machine$ Account Domain: FOO Logon >>>> ID: 0x3e7 Member: Security ID: >>>> S-1-5-21-xxxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxx Account Name: - Group: >>>> Security ID: S-1-5-32-544 Group Name: Administrators Group Domain: >>>> Builtin Additional Information: Privileges: - >>>> >>>> >>>> Before adding a local_decoder.xml, this log line would be parsed as >>>> follows: >>>> >>>> **Phase 2: Completed decoding. >>>> decoder: 'windows' >>>> status: 'AUDIT_SUCCESS' >>>> id: '4733' >>>> extra_data: 'Microsoft-Windows-Security-Auditing' >>>> dstuser: '(no user)' >>>> system_name: 'foo-machine' >>>> >>>> **Phase 3: Completed filtering (rules). >>>> Rule id: '18217' >>>> Level: '12' >>>> Description: 'Administrators Group Changed' >>>> Info - Text: 'http://support.microsoft.com/kb/243330' >>>> **Alert to be generated. >>>> >>>> >>>> Now, it's parsed as such: >>>> >>>> **Phase 2: Completed decoding. >>>> decoder: 'windows' >>>> >>>> **Phase 3: Completed filtering (rules). >>>> Rule id: '18100' >>>> Level: '0' >>>> Description: 'Group of windows rules.' >>>> >>>> Why!?! >>>> >>>> Thanks! >>>> >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "ossec-list" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
