Tested Custom Rule not showing on Wazuh

[Miran Ul Haq]

Hi Team,

I created a custom testing rule.

<group name="Test Group">
  <rule id="200001" level="6">
    <field name="win.system.eventID">^4648$</field>
    <description>Testing for logs from RDG Server to Host Server</description>
  </rule>
</group>

When I tested it on Wazuh Ruleset Test, it detected the rule successfully:

**Phase 3: Completed filtering (rules). id: '200001' level: '6' description: 'Testing for logs from RDG Server to Host Server' groups: '["Test Group"]' firedtimes: '1' mail: 'false' **Alert to be generated.

However, when I triggered this rule on wazuh, it's not showing on dashboard.

What am I missing? Kindly assist.

Thanks.

[Kevin Ledesma]

Hello Miran!

As the rule seems to work correctly, but the alert is not showing on dashboard, and other alerts are, this could be probably  because the event is not being captured at all. To check if the log is captured, you can use Wazuh archives, it is a file were all the captured events are stored, this feature should be enabled in order to see that file (it is mainly because this file trends to heavily grow in size), check this guide to enable this function.

Once you have the archive file working, you have to check in that file if the event appears once the log is generated, you could do something like this: tail -f /var/ossec/logs/archives/archive.json | egrep "A_PART_OF_YOUR_LOG"

In the case the event is not captured it is probably because the log is saved on a non-monitored file you have to configure wazuh-logcollector to capture the logs from the file, to do so you can follow this guide.

Otherwise, If the event is captured but the alert not being raised, it is because something is different between the actual log and the log you tested with, so the alert has to be reviewed.

I hope it helps! I you have any other issue or concern, feel free to post on any of Wazuh's community channels.

Have a nice day! 

[Miran Ul Haq]

Hi Kevin,

I fetched the logs from archives.log and tested on Ruleset Test Tool. So, it means the logs are being generated and correctly being recognized on the Test Tool. But for some reason not being captured in Wazuh.

I have shared my custom rule in the previous message. Could you share any possible solution or diagnosis?

Thanks,
Miran

[Kevin Ledesma]

Hello Miran! 

I see, about your rule, mi concern is that you are filtering by the eventID, are you sure that the log comes with the same eventID every time?

Apart from capturing the log from the archives.log, could you get the "original" log, I mean the log generated on the windows endpoint?  

To check if you rule is correct, I would need you to share a log, if you could capture at least two different logs of the same kind of event, it would be great, so we can be sure that the rule matches every time/

Thanks! 

[Miran Ul Haq]

Hi Kevin,

Correct, I am filtering the rule using eventID and the log would come from same eventID every time i.e. 4648.
Getting the logs from the original host would be a bit difficult due to rights and permissions. However, I can get multiple different logs from archives.log using same eventID and tested these logs in Rule Test which were identified correctly.

Please find below the results.

TEST 1:

TEST 2

[Kevin Ledesma]

Hi again!

About the EventID, my bad, these are specific to each type of Windows event, I've found an example log on the Windows docs.

For your rule, I see no <if_sid> is defined. That tag indicates to Wazuh to evaluate this rule when the rule with the defined ID is triggered (the one inside the <if_sid> tag). Check the docs for more info about it.

As there is no <if_sid> tag, and probably the log you are testing with is a Json, on the logtest the event is decoded as  json  and directly matches with your rule, but in the real world, the event is decoded as windows_eventchannel and matches with some level 0 rule, probably the rule 60000 that is the base rule for the windows events (maybe this post could be helpful). Could you share Phase 2 of the logtest to see what decoder is being used? 

Please take a look at the custom rules documentation they are helpful. Also, if you want, you can share the log you are testing with (first be sure it is sanitized without any critical/confidential/personal data) this way it will be easier to find what is going on.

I hope it helps! Have a nice day! 

Regards

[Miran Ul Haq]

Hi Kevin,

Apologies for the long gap. Got caught up in few things.

I really appreciate you explained the issue here. You were right, it is being decoded as JSON. Now, I am not sure which SID to add, to make it decode as windows_eventchannel

I tried with SID 92652, but still not working.

Please find below the logs and logtest result. 

Thanks.
Miran

WAZUH LOG TEST

**Messages:INFO: (7202): Session initialized with token '6803386a'**Phase 1: Completed pre-decoding.full event: '{"win":{"system":{"providerName":"Microsoft-Windows-Security-Auditing","providerGuid":"{54849625-5478-4994-a5ba-3e3b0328c30d}","eventID":"4648","version":"0","level":"0","task":"12544","opcode":"0","keywords":"0x8020000000000000","systemTime":"2024-07-11T16:21:48.4801358Z","eventRecordID":"8353251","processID":"732","threadID":"7948","channel":"Security","computer":"xxxx","severityValue":"AUDIT_SUCCESS","message":"\"A logon was attempted using explicit credentials.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-20\r\n\tAccount Name:\t\txxxx\r\n\tAccount Domain:\t\txx\r\n\tLogon ID:\t\t0x3E4\r\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\r\n\r\nAccount Whose Credentials Were Used:\r\n\tAccount Name:\t\txxxx\r\n\tAccount Domain:\t\txx\r\n\tLogon GUID:\t\t{6b7dffd1-98ac-da92-3589-698f6c373a25}\r\n\r\nTarget Server:\r\n\tTarget Server Name:\tlocalhost\r\n\tAdditional Information:\tlocalhost\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x5e4\r\n\tProcess Name:\t\tC:\\Windows\\System32\\svchost.exe\r\n\r\nNetwork Information:\r\n\tNetwork Address:\t-\r\n\tPort:\t\t\t-\r\n\r\nThis event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials. This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command.\""},"eventdata":{"subjectUserSid":"S-1-5-20","subjectUserName":"xxxx","subjectDomainName":"xx","subjectLogonId":"0x3e4","logonGuid":"{00000000-0000-0000-0000-000000000000}","targetUserName":"xxxx","targetDomainName":"xx","targetLogonGuid":"{6b7dffd1-98ac-da92-3589-698f6c373a25}","targetServerName":"localhost","targetInfo":"localhost","processId":"0x5e4","processName":"C:\\\\Windows\\\\System32\\\\svchost.exe"}}}'**Phase 2: Completed decoding.name: 'json'win.eventdata.logonGuid: '{00000000-0000-0000-0000-000000000000}'win.eventdata.processId: '0x5e4'win.eventdata.processName: 'C:\\Windows\\System32\\svchost.exe'win.eventdata.subjectDomainName: 'xx'win.eventdata.subjectLogonId: '0x3e4'win.eventdata.subjectUserName: 'xxxx'win.eventdata.subjectUserSid: 'S-1-5-20'win.eventdata.targetDomainName: 'xx'win.eventdata.targetInfo: 'localhost'win.eventdata.targetLogonGuid: '{6b7dffd1-98ac-da92-3589-698f6c373a25}'win.eventdata.targetServerName: 'localhost'win.eventdata.targetUserName: 'xxxx'win.system.channel: 'Security'win.system.computer: 'xxxx'win.system.eventID: '4648'win.system.eventRecordID: '8353251'win.system.keywords: '0x8020000000000000'win.system.level: '0'win.system.message: '"A logon was attempted using explicit credentials.Subject:Security ID: S-1-5-20Account Name: xxxxAccount Domain: xxLogon ID: 0x3E4Logon GUID: {00000000-0000-0000-0000-000000000000}Account Whose Credentials Were Used:Account Name: xxxxAccount Domain: xxLogon GUID: {6b7dffd1-98ac-da92-3589-698f6c373a25}Target Server:Target Server Name: localhostAdditional Information: localhostProcess Information:Process ID: 0x5e4Process Name: C:\Windows\System32\svchost.exeNetwork Information:Network Address: -Port: -This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials. This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command."'win.system.opcode: '0'win.system.processID: '732'win.system.providerGuid: '{54849625-5478-4994-a5ba-3e3b0328c30d}'win.system.providerName: 'Microsoft-Windows-Security-Auditing'win.system.severityValue: 'AUDIT_SUCCESS'win.system.systemTime: '2024-07-11T16:21:48.4801358Z'win.system.task: '12544'win.system.threadID: '7948'win.system.version: '0'**Phase 3: Completed filtering (rules).id: '200001'level: '6'description: 'Testing for RDG to Host logs'groups: '["Test Group"]'firedtimes: '1'mail: 'false'**Alert to be generated.

[Kevin Ledesma]

Hello Miran! 

You are probably doing it right, but as on wazuh-logtest, the Windows events can only be tested when decoded as json, when you change the parent rule, or reverse the change on the rule 60000 to decode as windows_eventchannel, the log won't be matched on wazuh-logtest again.

 

In summary, to test the winevent we have this workaround that is changing the main winevent rule from decoded as  windows_eventchannel to decoded as json, and after the rule behavior is the expected, we have to undo the edit on the rule 60000 so Wazuh can match it as winevent.

I hope you find this useful! Feel free to ask through any of our community channels if you have other concerns.

Have a nice weekend! Regards, 

Kevin

[Miran Ul Haq]

HI Kevin,

I tested what you mentioned and it worked fine on Wazuh-Logtest, but not working on the actual environment. Any other suggestions on how can I make this work?

Thanks.

[Kevin Ledesma]

Hello Miran! 

What decoder is used when you try it on wazuh-logtest? if it says json you have to revert the changes on the rule 60000, as it's only for testing purposes.

The log should match with the Windows parent rules and be decoded as windows_eventchannel, then it will match with your rule and raise an alert on the actual environment

If it works on logtest but not in the real world, it is because of the decoder or previous matching rules, set if_sid with the less generic rule before yours, to check it, momentarily remove/comment your rule, and check which rule matches. Also, check the whole inheritance of that previous rule to see if the first one is the generic windows event rule (rule 60000) 

I hope you find this useful! Feel free to ask through any of our community channels if you have other concerns.