Custom Windows event channel rule not working

646 views
Skip to first unread message

Colin Murphy

unread,
Oct 11, 2022, 11:51:47 AM10/11/22
to Wazuh mailing list
Hi all,

The last few days I’ve been having a tough time trying to create a rule that sends out an alert when there is an insecure LDAP binding being used against our domain controllers. I’m able to successfully see the logs in the archive.json file after I changed the logall_json setting to yes in ossec.conf, so I know my agents are configured properly.

Here are my custom rules for this:

        <rule id="100010" level="4">
                <if_sid>60000</if_sid>
                <field name="win.system.channel">^Directory Service$</field>
                <options>no_full_log</options>
                <description>Group of Windows rules for the Directory Service channel.</description>
        </rule>

        <!-- Insecure LDAP bind events -->
        <rule id="100011" level="12">
                <if_sid>100010</if_sid>
                <field name="win.system.eventID">^2889$</field>
                <description>Insecure LDAP bind used.</description>
        </rule>

The rule should be triggered when the event ID 2889 is encountered within the Directory Service eventchannel. No matter what I’ve tried, it will not log the alert. I was able to get it to match if i remove the if_sid from rule 100011 in the log tester, but not when an agent reports this event to the Wazuh manager.

Here’s an example in JSON format of the event in archive.json:

{"win":{"system":{"providerName":"Microsoft-Windows-ActiveDirectory_DomainService","providerGuid":"{0e8478c5-3605-4e8c-8497-1e730c959516}","eventSourceName":"NTDS LDAP","eventID":"2889","version":"0","level":"4","task":"16","opcode":"0","keywords":"0x8080000000000000","systemTime":"2022-10-10T21:40:07.182069300Z","eventRecordID":"4116181","processID":"632","threadID":"2664","channel":"Directory Service","computer":"dc-name","severityValue":"INFORMATION","message":"\"The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection. \r\n \r\nClient IP address:\r\n1.1.1.1:61493 \r\nIdentity the client attempted to authenticate as:\r\ndomain\\user \r\nBinding Type:\r\n1\""},"eventdata":{"data":"1.1.1.1:61493, domain\\\\user, 1"}}}

Any help is appreciated! 

Thanks,
Colin

Fabricio Brunetti

unread,
Oct 11, 2022, 2:22:34 PM10/11/22
to Wazuh mailing list
Hi Colin,

Hope you are doing well.
The log you provided triggers rule 60009 "Windows informational event." and not 60000.
To make your custom rules triggers simply change the if_sid tag in rule 100010 to 60009.

Regards,
Fabricio

Colin Murphy

unread,
Oct 11, 2022, 2:31:13 PM10/11/22
to Wazuh mailing list
Fabricio,

That worked! Thank you so much for your help. Now I'm off to write a decoder for this so I can extract some more data from the informational message.

Thank you,

Colin

Fabricio Brunetti

unread,
Oct 11, 2022, 2:58:46 PM10/11/22
to Wazuh mailing list
Sorry Colin, good thing you mentioned that, what you want to do cannot be done: the logs that come through windows event channel do not use traditional decoder so it's not possible to extract additional data from the message.
Sorry about that!

Good luck!
Fabricio

Colin Murphy

unread,
Oct 11, 2022, 3:45:12 PM10/11/22
to Wazuh mailing list
Now that you mention it, I remember reading the decoder for the event channel is built into Wazuh. No big deal, the main thing I wanted to accomplish here was send out an alert if this event happens - and it's working.

Thanks again!

Colin

Colin Murphy

unread,
Oct 12, 2022, 12:38:54 PM10/12/22
to Wazuh mailing list

Fabricio,

I'm having another issue writing a custom rule, for some reason I can't get this one to trigger either.

Essentially, what I want to happen is have an alert trigger if the event ID's (in Wazuh) 60109-60111 are triggered and it also affects one of our domain, server, or workstation admin accounts. I already tested the regular expression and it does match correctly so I think it's a rule issue. So for example, if the password changes or account gets locked for the username jdoewa, it will throw an alert. But if the user account jdoe gets locked, it will trigger the standard rules.

Here's the rule:

        <rule id="100021" level="12">
                <if_sid>60109,60110,60111</if_sid>
                <field name="win.eventdata.targetUserName">^.+[d|s|w]a$</field>
                <description>IT administrative user account value changed.</description>
        </rule>

Right now when the event happens, it will trigger one of those three rules (depending on what I do), but not rule 10021 so no alert.

Thanks,
Colin

Fabricio Brunetti

unread,
Oct 13, 2022, 12:04:24 PM10/13/22
to Colin Murphy, Wazuh mailing list
Colin,

If it's not too troublesome, could you share a sample log for debugging purposes?

Thanks!
Fabricio

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/1Ebdrwd57cc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/6ef02e9b-b5c7-42d6-98f1-5a09f93222b4n%40googlegroups.com.

Fabricio Brunetti

unread,
Oct 13, 2022, 12:15:43 PM10/13/22
to Wazuh mailing list
Colin, 

I think I see the problem. Wazuh by default does not use standard regex expressions, it uses OS_regex (more info here). 
As you can see in that documentation the dot character works in the opposite way of the standard regex: "." matches a literal dot and "\." matches any character.
So you could either use:

<field name="win.eventdata.targetUserName">^\.+[d|s|w]a$</field>

Or tell Wazuh that for that field check to use pcre2 (standard) regex engine:
<field name="win.eventdata.targetUserName" type="pcre2">^.+[d|s|w]a$</field>

Pretty sure that's the issue. If this doesn't work we'll debug the rule.

Regards,
Fabricio

Colin Murphy

unread,
Oct 13, 2022, 6:06:09 PM10/13/22
to Wazuh mailing list
I actually ended up trying that and it worked for some additional rules I created. I ended up creating 3 rules - one for when an administrative account we use gets enabled or disabled for some reason, and the 3rd should track other changes to the users (for example, a password reset). I also fixed the regular expressions a bit to accommodate usernames that have capital letters at the end.

Here's the updated rules:

        <rule id="100021" level="12">
                <if_sid>60110</if_sid>
                <field name="win.eventdata.targetUserName" type="pcre2">^.+[dDsSwW][aA]$</field>

                <description>IT administrative user account value changed.</description>
        </rule>
        <rule id="100022" level="12">
                <if_sid>60103</if_sid>
                <field name="win.system.eventID">^630$|^629$|^4725$|^4726$</field>
                <field name="win.eventdata.targetUserName" type="pcre2">^.+[dDsSwW][aA]$</field>
                <description>IT administrative user disabled or deleted.</description>
        </rule>
        <rule id="100023" level="12">
                <if_sid>60103</if_sid>
                <field name="win.system.eventID">^624$|^626$|^4720$|^4722$</field>
                <field name="win.eventdata.targetUserName" type="pcre2">^.+[dDsSwW][aA]$</field>
                <description>IT administrative account enabled or created.</description>
        </rule>

100022 and 100023 work, will create duplicate logs (which is OK), but I ultimately wanted to do if_sid for 60109 and 60111 for these so they get triggered by the existing rules. To make them I just copied the rules off github and added in the field for my regex.

Here's an example of a log that I need to trigger 10021:

{"win":{"system":{"providerName":"Microsoft-Windows-Security-Auditing","providerGuid":"{54849625-5478-4994-A5BA-3E3B0328C30D}","eventID":"4738","version":"0","level":"0","task":"13824","opcode":"0","keywords":"0x8020000000000000","systemTime":"2022-10-12T17:48:12.311765300Z","eventRecordID":"781999188","processID":"632","threadID":"7020","channel":"Security","computer":"DOMAIN_CONTROLLER","severityValue":"AUDIT_SUCCESS","message":"\"A user account was changed.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-21-683610258-3400582236-3141874177-3656199\r\n\tAccount Name:\t\tcmurphyWA\r\n\tAccount Domain:\t\tDOMAIN_NAME\r\n\tLogon ID:\t\t0x180D1CD5F\r\n\r\nTarget Account:\r\n\tSecurity ID:\t\tS-1-5-21-683610258-3400582236-3141874177-3655050\r\n\tAccount Name:\t\tctestingwa\r\n\tAccount Domain:\t\tDOMAIN_NAME\r\n\r\nChanged Attributes:\r\n\tSAM Account Name:\t-\r\n\tDisplay Name:\t\t-\r\n\tUser Principal Name:\t-\r\n\tHome Directory:\t\t-\r\n\tHome Drive:\t\t-\r\n\tScript Path:\t\t-\r\n\tProfile Path:\t\t-\r\n\tUser Workstations:\t-\r\n\tPassword Last Set:\t-\r\n\tAccount Expires:\t\t-\r\n\tPrimary Group ID:\t-\r\n\tAllowedToDelegateTo:\t-\r\n\tOld UAC Value:\t\t0x10\r\n\tNew UAC Value:\t\t0x11\r\n\tUser Account Control:\t\r\n\t\tAccount Disabled\r\n\tUser Parameters:\t-\r\n\tSID History:\t\t-\r\n\tLogon Hours:\t\t-\r\n\r\nAdditional Information:\r\n\tPrivileges:\t\t-\""},"eventdata":{"targetUserName":"ctestingwa","targetDomainName":"DOMAIN_NAME","targetSid":"S-1-5-21-683610258-3400582236-3141874177-3655050","subjectUserSid":"S-1-5-21-683610258-3400582236-3141874177-3656199","subjectUserName":"cmurphyWA","subjectDomainName":"DOMAIN_NAME","subjectLogonId":"0x180d1cd5f","oldUacValue":"0x10","newUacValue":"0x11","userAccountControl":"    %%2080"}}}


Thanks again for your help!

Colin

Fabricio Brunetti

unread,
Oct 14, 2022, 1:47:54 PM10/14/22
to Wazuh mailing list
Hi Colin,

Sorry, I don't get what the problem is. Your log does trigger rule 10021.
Your rules are looking fine, let me know if you need any help.

Regards,
Fabricio

Vyom Thaker

unread,
Oct 14, 2022, 11:58:20 PM10/14/22
to Fabricio Brunetti, Wazuh mailing list, Mityangi Maheshwari
Looping my Team

Amit Eilat

unread,
Aug 1, 2023, 8:09:01 AM8/1/23
to Wazuh mailing list

Hi!
I'm having the exact same problem as Clolin's.
I have a new custom event ID generated on an agent's station
the event ID "4111", and the event log location "CustomChannel" (its right under the "Applications and Services Logs" tab)

I added a localfile block for the new custom event log, and when generated on the station, the worker does get the log (as i can see in archives.json)

the rules are exactly like Colin's:

<group name="windows,project's_name,">
        <!-- Classify to a channel -->
        <rule id="104000" level="0">
                <if_sid>60000</if_sid>
                <field name="win.system.channel">^CustomChannel$</field>
                <options>no_full_log</options>
                <description>blah blah blah</description>
        </rule>

        <rule id="104111" level="5">
                <if_sid>104000</if_sid>
                <field name="win.system.eventID">^4111$</field>
                <options>no_full_log</options>
                <description>blah blah blah</description>
        </rule>
</group>
-------------------------------------------------------------------------------------------------------------------------
It didn't work, and I didn't know what else to do :(((
Then I found this chat and tried to replace "60000" with "60009"

even with changing the 60000 rule to <decode_as>json</decode_as>, the logtest tool doesn't get to phase 3!!!!
I don't know what else to do

another thing worth mentioning is that I created a new xml file for rules of this project under /var/ossec/etc/ruleset


I really really hope you can help
Thank you 🙏🙏🙏
ב-יום שלישי, 11 באוקטובר 2022 בשעה 21:22:34 UTC+3, Fabricio Brunetti כתב/ה:
Reply all
Reply to author
Forward
0 new messages