Whitelisting Alerts (Still No Luck)

96 views
Skip to first unread message

Zero Two

unread,
May 30, 2024, 1:36:49 PM5/30/24
to Wazuh | Mailing List
(My previous thread keeps blocking replies)

I am trying to create a custom rule or modify an existing rule that would not create an alert for any Win ID 4662 event if  the associated user was adsync but nonetheless throw an alert if any other user was associated with the event.

Unfortunately I have not had any luck.


Here is the Windows Event XML that I would want excepted from the stock rule because of the active user is "adsync":

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
  <EventID>4662</EventID>
  <Version>0</Version>
  <Level>0</Level>
  <Task>14080</Task>
  <Opcode>0</Opcode>
  <Keywords>0x8020000000000000</Keywords>
  <TimeCreated SystemTime="2024-05-24T18:52:47.8899705Z" />
  <EventRecordID>31908609</EventRecordID>
  <Correlation />
  <Execution ProcessID="776" ThreadID="888" />
  <Channel>Security</Channel>
  <Computer>ad.foo.bar</Computer>
  <Security />
  </System>
- <EventData>
  <Data Name="SubjectUserSid">S-1-5-21-3553857315-2347844133-1096870106-4216</Data>
  <Data Name="SubjectUserName">adsync</Data>
  <Data Name="SubjectDomainName">foo.bar</Data>
  <Data Name="SubjectLogonId">0x154e5a09</Data>
  <Data Name="ObjectServer">DS</Data>
  <Data Name="ObjectType">%{19195a5b-6da0-11d0-afd3-00c04fd930c9}</Data>
  <Data Name="ObjectName">%{1b20f7f1-991f-4938-ae59-6c09f393eccf}</Data>
  <Data Name="OperationType">Object Access</Data>
  <Data Name="HandleId">0x0</Data>
  <Data Name="AccessList">%%7688</Data>
  <Data Name="AccessMask">0x100</Data>
  <Data Name="Properties">%%7688 {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} {19195a5b-6da0-11d0-afd3-00c04fd930c9}</Data>
  <Data Name="AdditionalInfo">-</Data>
  <Data Name="AdditionalInfo2" />
  </EventData>
  </Event>

Here is my custom rule located in /var/ossec/etc/rules/000100-custom_rules.xml:

<group name="False Positives">
  <rule id="000101" level="0">
    <if_sid>60103</if_sid>
    <field name="win.eventdata.subjectUserName">adsync</field>
    <field name="win.system.eventID">4662</field>
    <description>False Positive: Possible DCSync Attack</description>
  </rule>
</group>

However the following /var/ossec/etc/rules/local_rules.xml still takes precedence:

<group name="security_event, windows,">

  <!-- This rule detects DCSync attacks using windows security event on the domain controller -->

    <rule id="110001" level="12">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">^4662$</field>
    <field name="win.eventdata.properties" type="pcre2">{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}|{19195a5b-6da0-11d0-afd3-00c04fd930c9}</field>
    <options>no_full_log</options>
    <description>Directory Service Access. Possible DCSync attack</description>
  </rule>

...

</group>

Any thoughts?

Thank you!

Zero Two

unread,
May 30, 2024, 1:47:34 PM5/30/24
to Wazuh | Mailing List
Please delete.  Solution was found in prior thread (which I somehow missed)

https://groups.google.com/g/wazuh/c/KPEluSCC2kM/m/hW353UWxAwAJ

Thank you Fabian!

Sebastian Dario Bustos

unread,
May 30, 2024, 9:42:00 PM5/30/24
to Wazuh | Mailing List
Hi Zero Two,

Glad you found the solution, in general when you want to silence a specific event the best practice is to create a child rule of level `0` with the specific conditions for that particular event, in this way, when the conditions are matched they will not generate an alert.
Besides this, regarding to your custom rules file, it is not necesary to start the file with a number, it can have any name, also you can put your custom rules if is just one as in this case in the file local_rules.xml.  Please put IDs above 100000 for your custom rules since the lower ID's are reserved for the stock rules and on a later version may conflict, and in the case they have the same id with a stock rule, the stock rule will take precedence.

Regards.
Reply all
Reply to author
Forward
0 new messages