Problem learning how to use custom rules

Secure moi

unread,

Sep 2, 2023, 8:33:05 PM9/2/23

to Wazuh | Mailing List

Hi all, been at this a while, and am failing to get any kind of custom rule to work. I'm aiming to start small, something as simple as possible. I have an ubuntu wazuh server, and primarily windows agents/clients. I am getting various alerts via email and in alerts.log and alerts.json.

I think my latest effort is failing because the default rules are taking precedence over my custom rule. In my latest log test, it seems like both my custom rule and default rule are firing but the overwrite=yes option in my custom rule isn't working.

Hope what follows helps:

I think the default rule is 18101,
<rule id="18101" level="0">
<if_sid>18100</if_sid>
<status>^INFORMATION</status>
<description>Windows informational event.</description>
</rule>

My attempt at an override rule is (at this point, the eventID is arbritrary until I get this work, so I'm using 16384 because I can see it in the windows client's event log)
<group name="windows,">
<rule id="18101" level="12"> overwrite="yes">
<category>ossec</category>
<decoded_as>windows_eventchannel</decoded_as>
<field name="win.system.eventID">^16384</field>
<description>TestRule</description>
<options>alert_by_email</options>
</rule>
</group>

and the log test results are (where it seems that the default rule is the one firing, that both it and my custom are firing, but the default is taking precedence so the level is 0 not 12, and the mail is false not true)

/var/ossec/bin/wazuh-logtest
Starting wazuh-logtest v4.5.1
Type one log per line

2023 Sep 02 11:52:47 WinEvtLog: Application: INFORMATION(16384): Microsoft-Windows-Security-SPP: SYSTEM: NT AUTHORITY: hostname: The Software Protection service has completed licensing status check. Application Id=55c92734-d682-4d71-983e-d6ec3f16059f Licensing Status= 1: 2a40c04d-4e5f-4e47-a2ff-3259b8d15b55, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )] 2: bbae06d4-42a6-4b8a-834a-c5b6154cf7c6, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )]

** Wazuh-Logtest: WARNING: (7612): Rule ID '18101' is duplicated. Only the first occurrence will be considered.

**Phase 1: Completed pre-decoding.
full event: '2023 Sep 02 11:52:47 WinEvtLog: Application: INFORMATION(16384): Microsoft-Windows-Security-SPP: SYSTEM: NT AUTHORITY: hostname: The Software Protection service has completed licensing status check. Application Id=55c92734-d682-4d71-983e-d6ec3f16059f Licensing Status= 1: 2a40c04d-4e5f-4e47-a2ff-3259b8d15b55, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )] 2: bbae06d4-42a6-4b8a-834a-c5b6154cf7c6, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )] '
timestamp: '2023 Sep 02 11:52:47'
program_name: 'WinEvtLog'

**Phase 2: Completed decoding.
name: 'windows'
parent: 'windows'
dstuser: 'SYSTEM'
extra_data: 'Microsoft-Windows-Security-SPP'
id: '16384'
status: 'INFORMATION'
system_name: 'hostname'
type: 'Application'

**Phase 3: Completed filtering (rules).
id: '18101'
level: '0'
description: 'Windows informational event.'
groups: '['windows']'
firedtimes: '1'
mail: 'False'

Help! Thx

Matias Braida

unread,

Sep 3, 2023, 7:52:14 AM9/3/23

to Wazuh | Mailing List

Hello Secure moi,
First of all, thanks for using Wazuh.

I have tested your rule using "wazuh-logtest" and I found some issues.

* The "rule id" tagline has a wrong symbol ">".

* The event is decoded using the decoder "windows" not "windows_eventchannel".

* The Windows event id (16384) is decoded as the field "id". So you need to use the tag "<id>" to match it.
Please take a look at this link: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#rules-id

* Finally I added the tag <if_sid> to keep the same parent as the original 18101 rule you are overwriting.
Please take a look at this link: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#if-sid

With these changes, the final custom rule is the following:

<if_sid>18100</if_sid>
<category>ossec</category>
<decoded_as>windows</decoded_as>
<id>^16384</id>

<description>TestRule</description>
<options>alert_by_email</options>
</rule>
</group>

I tested locally with "wazuh-logtest" and seems to be working ok.

Please let me know if this helps.
Regards

Matias Braida

unread,

Sep 4, 2023, 10:31:46 AM9/4/23

to Secure moi, Wazuh mailing list

Hi again,

I have tested using the event log string that you sent in your first message. The following one:

2023 Sep 02 11:52:47 WinEvtLog: Application: INFORMATION(16384): Microsoft-Windows-Security-SPP: SYSTEM: NT AUTHORITY: hostname: The Software Protection service has completed licensing status check. Application Id=55c92734-d682-4d71-983e-d6ec3f16059f Licensing Status= 1: 2a40c04d-4e5f-4e47-a2ff-3259b8d15b55, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )] 2: bbae06d4-42a6-4b8a-834a-c5b6154cf7c6, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )]

Here is the output of the tool "wazuh-logtest" using the rule modified as I told you earlier:

root@matias-X580VD:/var/ossec/bin# ./wazuh-logtest
Starting wazuh-logtest v4.8.0

Type one log per line

2023 Sep 02 11:52:47 WinEvtLog: Application: INFORMATION(16384): Microsoft-Windows-Security-SPP: SYSTEM: NT AUTHORITY: hostname: The Software Protection service has completed licensing status check. Application Id=55c92734-d682-4d71-983e-d6ec3f16059f Licensing Status= 1: 2a40c04d-4e5f-4e47-a2ff-3259b8d15b55, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )] 2: bbae06d4-42a6-4b8a-834a-c5b6154cf7c6, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )]

**Phase 1: Completed pre-decoding.
full event: '2023 Sep 02 11:52:47 WinEvtLog: Application: INFORMATION(16384): Microsoft-Windows-Security-SPP: SYSTEM: NT AUTHORITY: hostname: The Software Protection service has completed licensing status check. Application Id=55c92734-d682-4d71-983e-d6ec3f16059f Licensing Status= 1: 2a40c04d-4e5f-4e47-a2ff-3259b8d15b55, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )] 2: bbae06d4-42a6-4b8a-834a-c5b6154cf7c6, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )]'
timestamp: '2023 Sep 02 11:52:47'
program_name: 'WinEvtLog'

**Phase 2: Completed decoding.
name: 'windows'
parent: 'windows'
dstuser: 'SYSTEM'
extra_data: 'Microsoft-Windows-Security-SPP'
id: '16384'
status: 'INFORMATION'
system_name: 'hostname'
type: 'Application'

**Phase 3: Completed filtering (rules).
id: '18101'

level: '12'
description: 'TestRule'
groups: '['windows']'
firedtimes: '1'
mail: 'True'
**Alert to be generated.

Regarding the strings of the events that the agents capture and send to the manager, you can find them on the file "/var/ossec/logs/archives/archives.log".
There you will see all the events that the manager receives regardless they generate or not an alert.
To enable this option, please take a look at this link: https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/global.html#logall

Just as an example, this is the event log of a Windows event captured from the event channel in the agent. This line is taken from file "/var/ossec/logs/archives/archives.log":

2023 Sep 04 10:58:32 (DESKTOP-II31C7H) any->EventChannel {"win":{"system":{"message":"\"An account was successfully logged on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tDESKTOP-II31C7H$\r\n\tAccount Domain:\t\tWORKGROUP\r\n\tLogon ID:\t\t0x3E7\r\n\r\nLogon Information:\r\n\tLogon Type:\t\t5\r\n\tRestricted Admin Mode:\t-\r\n\tVirtual Account:\t\tNo\r\n\tElevated Token:\t\tYes\r\n\r\nImpersonation Level:\t\tImpersonation\r\n\r\nNew Logon:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tSYSTEM\r\n\tAccount Domain:\t\tNT AUTHORITY\r\n\tLogon ID:\t\t0x3E7\r\n\tLinked Logon ID:\t\t0x0\r\n\tNetwork Account Name:\t-\r\n\tNetwork Account Domain:\t-\r\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x2bc\r\n\tProcess Name:\t\tC:\\Windows\\System32\\services.exe\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\t-\r\n\tSource Network Address:\t-\r\n\tSource Port:\t\t-\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tAdvapi \r\n\tAuthentication Package:\tNegotiate\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\t-\r\n\tKey Length:\t\t0\r\n\r\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\r\n\r\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\r\n\r\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.\""}}}

From this line, you can test the event log string and test it in the tool "wazuh-logtest". The string to test is:

{"win":{"system":{"message":"\"An account was successfully logged on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tDESKTOP-II31C7H$\r\n\tAccount Domain:\t\tWORKGROUP\r\n\tLogon ID:\t\t0x3E7\r\n\r\nLogon Information:\r\n\tLogon Type:\t\t5\r\n\tRestricted Admin Mode:\t-\r\n\tVirtual Account:\t\tNo\r\n\tElevated Token:\t\tYes\r\n\r\nImpersonation Level:\t\tImpersonation\r\n\r\nNew Logon:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tSYSTEM\r\n\tAccount Domain:\t\tNT AUTHORITY\r\n\tLogon ID:\t\t0x3E7\r\n\tLinked Logon ID:\t\t0x0\r\n\tNetwork Account Name:\t-\r\n\tNetwork Account Domain:\t-\r\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x2bc\r\n\tProcess Name:\t\tC:\\Windows\\System32\\services.exe\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\t-\r\n\tSource Network Address:\t-\r\n\tSource Port:\t\t-\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tAdvapi \r\n\tAuthentication Package:\tNegotiate\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\t-\r\n\tKey Length:\t\t0\r\n\r\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\r\n\r\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\r\n\r\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.\""}}}

But remember that all events can have different formats depending on the nature and source of them. That's the reason for having multiple decoders in the manager. So you need to know what are you trying to capture in the agent. You can also look at events received by the manager in the "/var/ossec/logs/archives/archives.log" file.

I hope this helps you to understand how wazuh works.
Regards

PS: Please remember to send the messages to the Wazuh Google group to keep the conversation in the community group.

On Sun, Sep 3, 2023 at 5:34 PM Secure moi <sucu...@gmail.com> wrote:

Thx so much Matias, if there is a tangible way to express my appreciation, please let me know (sorry if that's gauche but it is sincere)?

Q may I ask you for the string you are using to use wazuh-testlog? I think the one I'm trying is wrong (it's not finding a decoder and I think it's because I'm not sure how to construct a test string correctly). In general, am interested in being able to construct a good test string from scratch (some of the ones I've found have to do with ssh and I'm not sure how translate them to another event...e.g., "Oct 15 21:07:00 linux-agent sshd[29205]: Invalid user blimey from 18.18.18.18 port 48928")

Q Once I get this working, to use it on other events do I just change the event ID?

Thx so much...really grateful

PS once this is working, I'll post info to show how

--

Matias S. Braida
Software Engineer

Secure moi

unread,

Sep 4, 2023, 11:17:44 AM9/4/23

to Wazuh | Mailing List

Awesome! Will digest, test, get back. Thx so much Matias:)

Secure moi

unread,

Sep 5, 2023, 3:56:19 PM9/5/23

to Wazuh | Mailing List

Hi Matias, how are you? Thx for all of your help, I hope I'm not over subscribing your good will (and really hoping I'm not just doing something dumb). Per below, I'm getting some results I can't explain. I am getting windows 16384 events in my archives.log but not (I don't think ) in either the alerts.log or alerts.json, nor am I getting emails alerts yet from my custom rule, but please read on. Hope what follows is useful...and thx again. PS I'm trying to mask email addresses, machine names etc. below...

1) Thx for your testing string example (in part I was asking because when constructing a rule if nothing shows up in archives.log, was wondering it if makes sense to construct a test string by hand, and if so how...or is there no point to this line of thinking?).

2) Part of what I can't explain yet is when I run your test string using "wazuh-logtest" I get the same results you get (tada!). When I run an event from my archives.log, I get a no decoder found. My archives.log example looks different than your test string, and assume this is user error on my part, or maybe I need to change something on my ossec.conf on my windows clients/agents?

I think the relevant section from my windows client's ossec.conf is:
<localfile>
<location>Application</location>
<log_format>eventchannel</log_format>
</localfile>

Part of what looks different is your test string has "WinEvtLog" and mine has " any->EventChannel", maybe this doesn't matter? Should I install sysmon on the clients?

Your String (that gets the same positive outcome):

2023 Sep 02 11:52:47 WinEvtLog: Application: INFORMATION(16384): Microsoft-Windows-Security-SPP: SYSTEM: NT AUTHORITY: hostname: The Software Protection service has completed licensing status check. Application Id=55c92734-d682-4d71-983e-d6ec3f16059f Licensing Status= 1: 2a40c04d-4e5f-4e47-a2ff-3259b8d15b55, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )] 2: bbae06d4-42a6-4b8a-834a-c5b6154cf7c6, 1, 0 [(0 [0xC004F014, 0, 0], [(?)(?)(?)(?)])(1 )(2 )]

From my wazuh server's archive.log (for one of my windows clients):
2023 Sep 05 12:51:52 (My-PC) any->EventChannel {"win":{"system":{"providerName":"Microsoft-Windows-Security-SPP","providerGuid":"{E23B33B0-C8C9-472C-A5F9-F2BDFEA0F156}","eventSourceName":"Software Protection Platform Service","eventID":"16384","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2023-09-05T16:51:52.2063835Z","eventRecordID":"224488","processID":"0","threadID":"0","channel":"Application","computer":"My-PC.domainname.domain","severityValue":"INFORMATION","message":"\"Successfully scheduled Software Protection service for re-start at 2123-08-12T16:51:52Z. Reason: RulesEngine.\""},"eventdata":{"data":"2123-08-12T16:51:52Z, RulesEngine"}}}

2) I hope I haven't misdiagnosed some of this, but stumbled on when I open up settings in my server's ossec.conf for email alerts, that I am getting alerts for 16384 events that are getting triggered off of rule "60642" (not 18101). Hope I didn't misdiagnose this is the first place but is possible and deep apology if so and it's muddied all of this up.... I changed my custom rule id to 60642 in my custom rules (the default rule is in "/var/ossec/ruleset/rules/0585-win-application_rules.xml" and I think relies on a couple of "<if_sid>s up the chain to rules 60640 and 60600, to /var/ossec/ruleset/rules/0575-win-base_rules.xml 60003 & 60000....60000 looks like the base ossec group rule).

I've shown the custome rule now using down below...

3) I am still am not getting alerts to come into my alerts.log or emails for event id 16384, so assume that's still a problem.

Sample Email (when I throttle back alert levels), this is what makes me think I should in my custom rule be overwriting default rule 60642
Wazuh Notification.
2023 Sep 03 12:53:57

Received From: (My-PC) any->EventChannel
Rule: 60642 fired (level 3) -> "Software protection service scheduled successfully."
Portion of the log(s):

{"win":{"system":{"providerName":"Microsoft-Windows-Security-SPP","providerGuid":"{E23B33B0-C8C9-472C-A5F9-F2BDFEA0F156}","eventSourceName":"Software Protection Platform Service","eventID":"16384","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2023-09-03T16:53:57.0229048Z","eventRecordID":"6107","processID":"6972","threadID":"0","channel":"Application","computer":"My-PC","severityValue":"INFORMATION","message":"\"Successfully scheduled Software Protection service for re-start at 2123-08-10T16:53:56Z. Reason: RulesEngine.\""},"eventdata":{"data":"2123-08-10T16:53:56Z, RulesEngine"}}}
win.system.providerName: Microsoft-Windows-Security-SPP
win.system.providerGuid: {E23B33B0-C8C9-472C-A5F9-F2BDFEA0F156}
win.system.eventSourceName: Software Protection Platform Service
win.system.eventID: 16384
win.system.version: 0
win.system.level: 4
win.system.task: 0
win.system.opcode: 0
win.system.keywords: 0x80000000000000
win.system.systemTime: 2023-09-03T16:53:57.0229048Z
win.system.eventRecordID: 6107
win.system.processID: 6972
win.system.threadID: 0
win.system.channel: Application
win.system.computer: My-PC
win.system.severityValue: INFORMATION
win.system.message: "Successfully scheduled Software Protection service for re-start at 2123-08-10T16:53:56Z. Reason: RulesEngine."
win.eventdata.data: 2123-08-10T16:53:56Z, RulesEngine

If I plug the top part of this into the logtest, it finds a decoder but does not get to or through phase 3
{"win":{"system":{"providerName":"Microsoft-Windows-Security-SPP","providerGuid":"{E23B33B0-C8C9-472C-A5F9-F2BDFEA0F156}","eventSourceName":"Software Protection Platform Service","eventID":"16384","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2023-09-03T16:53:57.0229048Z","eventRecordID":"6107","processID":"6972","threadID":"0","channel":"Application","computer":"My-PC","severityValue":"INFORMATION","message":"\"Successfully scheduled Software Protection service for re-start at 2123-08-10T16:53:56Z. Reason: RulesEngine.\""},"eventdata":{"data":"2123-08-10T16:53:56Z, RulesEngine"}}}

My custom rule now is:
<group name="windows,">
<rule id="60642" level="12" overwrite="yes">
<category>ossec</category>

<decoded_as>windows</decoded_as>
<id>^16384</id>
<description>TestRule</description>
<options>alert_by_email</options>
</rule>
</group>

When I plug a string from my archive.log into the log test tool, I get

/var/ossec/bin/wazuh-logtest
Starting wazuh-logtest v4.5.1
Type one log per line

2023 Sep 05 13:56:41 (MG-PC) any->EventChannel {"win":{"system":{"providerName":"Microsoft-Windows-Security-SPP","providerGuid":"{E23B33B0-C8C9-472C-A5F9-F2BDFEA0F156}","eventSourceName":"Software Protection Platform Service","eventID":"16384","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2023-09-05T17:56:41.5844472Z","eventRecordID":"973321","processID":"0","threadID":"0","channel":"Application","computer":"MG-PC","severityValue":"INFORMATION","message":"\"Successfully scheduled Software Protection service for re-start at 2123-08-12T17:56:41Z. Reason: RulesEngine.\""},"eventdata":{"data":"2123-08-12T17:56:41Z, RulesEngine"}}}

**Phase 1: Completed pre-decoding.
full event: '2023 Sep 05 13:56:41 (My-PC) any->EventChannel {"win":{"system":{"providerName":"Microsoft-Windows-Security-SPP","providerGuid":"{E23B33B0-C8C9-472C-A5F9-F2BDFEA0F156}","eventSourceName":"Software Protection Platform Service","eventID":"16384","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2023-09-05T17:56:41.5844472Z","eventRecordID":"973321","processID":"0","threadID":"0","channel":"Application","computer":"MG-PC","severityValue":"INFORMATION","message":"\"Successfully scheduled Software Protection service for re-start at 2123-08-12T17:56:41Z. Reason: RulesEngine.\""},"eventdata":{"data":"2123-08-12T17:56:41Z, RulesEngine"}}}'
timestamp: '2023 Sep 05 13:56:41'

**Phase 2: Completed decoding.

...but I don't get a phase 3 or feedback on the processing like your sample test string provides.

My server's ossec.config alert section is currently raised up and is

<jsonout_output>yes</jsonout_output>
<alerts_log>yes</alerts_log>
<logall>yes</logall>
<logall_json>yes</logall_json>
<email_notification>yes</email_notification>
<smtp_server>localhost</smtp_server>
<email_from>mye...@email.com</email_from>
<email_to>mye...@email.com</email_to>
<email_maxperhour>12</email_maxperhour>
<email_log_source>alerts.log</email_log_source>
<agents_disconnection_time>10m</agents_disconnection_time>
<agents_disconnection_alert_time>0</agents_disconnection_alert_time>
</global>

<alerts>
<log_alert_level>1</log_alert_level>
<email_alert_level>10</email_alert_level>
</alerts>

Again, I can find events in my archive.log but not in either alerts.log (I recently turned on the alerts.json and don't think I getting 16384 alerts prior to doing that) Am I on the wrong track here?

Thx again.

Matias Braida

unread,

Sep 6, 2023, 12:13:19 PM9/6/23

to Wazuh | Mailing List

Hello, Secure moi,

1) Yes, you are right. To construct a rule, it is easier if you could take the event string (from the archives.log) that the agent reports. Furthermore, seeing the entry in the archives.log, assures that the event is being communicated from the agent to the manager (the first step). If this is not the case, then you have another problem.

2) Maybe I was not clear enough in the example. The string I got from the file archives.log was the following:

2023 Sep 04 10:58:32 (DESKTOP-II31C7H) any->EventChannel {"win":{"system":{"message":"\"An account was successfully logged on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tDESKTOP-II31C7H$\r\n\tAccount Domain:\t\tWORKGROUP\r\n\tLogon ID:\t\t0x3E7\r\n\r\nLogon Information:\r\n\tLogon Type:\t\t5\r\n\tRestricted Admin Mode:\t-\r\n\tVirtual Account:\t\tNo\r\n\tElevated Token:\t\tYes\r\n\r\nImpersonation Level:\t\tImpersonation\r\n\r\nNew Logon:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tSYSTEM\r\n\tAccount Domain:\t\tNT AUTHORITY\r\n\tLogon ID:\t\t0x3E7\r\n\tLinked Logon ID:\t\t0x0\r\n\tNetwork Account Name:\t-\r\n\tNetwork Account Domain:\t-\r\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x2bc\r\n\tProcess Name:\t\tC:\\Windows\\System32\\services.exe\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\t-\r\n\tSource Network Address:\t-\r\n\tSource Port:\t\t-\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tAdvapi \r\n\tAuthentication Package:\tNegotiate\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\t-\r\n\tKey Length:\t\t0\r\n\r\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\r\n\r\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\r\n\r\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.\""}}}

Then from that string, I took the following part:

{"win":{"system":{"message":"\"An account was successfully logged on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tDESKTOP-II31C7H$\r\n\tAccount Domain:\t\tWORKGROUP\r\n\tLogon ID:\t\t0x3E7\r\n\r\nLogon Information:\r\n\tLogon Type:\t\t5\r\n\tRestricted Admin Mode:\t-\r\n\tVirtual Account:\t\tNo\r\n\tElevated Token:\t\tYes\r\n\r\nImpersonation Level:\t\tImpersonation\r\n\r\nNew Logon:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tSYSTEM\r\n\tAccount Domain:\t\tNT AUTHORITY\r\n\tLogon ID:\t\t0x3E7\r\n\tLinked Logon ID:\t\t0x0\r\n\tNetwork Account Name:\t-\r\n\tNetwork Account Domain:\t-\r\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x2bc\r\n\tProcess Name:\t\tC:\\Windows\\System32\\services.exe\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\t-\r\n\tSource Network Address:\t-\r\n\tSource Port:\t\t-\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tAdvapi \r\n\tAuthentication Package:\tNegotiate\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\t-\r\n\tKey Length:\t\t0\r\n\r\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\r\n\r\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\r\n\r\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.\""}}}

That part is the one that I put as an entry in the tool "wazuh-logtest".
There is a header for each entry to remove. In this specific case is: "2023 Sep 04 10:58:32 (DESKTOP-II31C7H) any->EventChannel ".

Try using the tool "wazuh-logtest" again removing this entry header and let me know the results. Maybe, there is another issue with the custom rule.

Regards

Secure moi

unread,

Sep 11, 2023, 2:53:27 PM9/11/23

to Wazuh | Mailing List

Hi Matias, hope you are well, am back, and

1) Got one rule working (wuhu!, thx Matias), am stuck on the next experiment (if ok, see #3). If I can get this 2nd one working, am hoping I'll have enough to proceed on my own:).

The rule that's working (log entries in archives.log, in alerts.log and .json, and triggering emails I'm receiving) is:
group name="customrules,">

<if_sid>60640</if_sid>
<field name="win.system.eventID">^16384$</field>
<options>no_full_log</options>
<description>Software protection service scheduled successfully.</description>

<options>alert_by_email</options>
</rule>
</group>

I'd started off thinking this would a new custom rule, not a change to an existing one. I've not needed a custom decoder for this rule to work, for me to be getting emails for it.

I think an aspect of all of this I didn't understand (and correct if this seems like I still don't) is the complexity & interaction between custom rules/decoders and default rules/decoders. E.g., I might not need a custom rule because a default one already exists (and my custom one might not work as a result) so it matters to try to determine that, or I might want to make a custom rule as a change to a default one with "overwrite="yes"> tag because I want to change the level etc. This makes the whole process deeper than I expected, and have with your help used wazuh-logtest and various grep statements to see if a default rule exists that I want to know about (there may be good documentation on all of this that I've missed and apologies if so) before embarking on developing a custom rule or decoder.

2) The wazuh-logtest test strings, the one in the documentation looks (https://documentation.wazuh.com/current/user-manual/ruleset/testing.html) like it has the header (e.g., Dec 25 20:45:02 MyHost example[12345]: User 'admin' logged from '192.168.1.100' ...am I mistaken? So am still a bit uncertain as to if this means take a straight log entry out of "archive.log" with the header and if that doesn't seem to work, strip the header out or is it "always strip the header out"?

3) Am trying one more experiment with rules here, I started thinking would be simple but am struggling. This one is to look at "chkdsk" results, and flag problems. Log events are showing up in archives.log but not alerts.log or alerts.json yet.

my rule attempt is (I am assuming there is a default rule 1002 in /var/ossec/ruleset/rules/0020-syslog_rules.xml:

<rule id="1002" level="12" overwrite="yes">
<match>$Chkdsk</match>
<description>ChkdskScan</description>
<options>alert_by_email</options>
<group>gpg13_4.3,</group>
</rule>

The default rule had a level of 2, and a match statement of <match>$BAD_WORDS</match>. I've tried a number of different things (e.g., <if_sid>530</if_sid> for an attempt using a local file on the client, using custom rules with an <if_sid>1002</if_sid to try to use rule 1002 to trigger a custom rule).

I'm using as a logtest string the ugly one from archives.log (sorry, this is quite log):
2023 Sep 06 10:42:57 (MG-PC) any->EventChannel {"win":{"system":{"providerName":"Chkdsk","eventID":"26212","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2023-09-06T14:42:57.4893065Z","eventRecordID":"973394","processID":"0","threadID":"0","channel":"Application","computer":"MG-PC","severityValue":"INFORMATION","message":"\"Chkdsk was executed in read-only mode on a volume snapshot. \r\n\r\nChecking file system on C:\r\nThe type of the file system is NTFS.\r\nVolume label is OSDisk.\r\n\r\nWARNING! /F parameter not specified.\r\nRunning CHKDSK in read-only mode.\r\n\r\nStage 1: Examining basic file system structure ...\r\nCleaning up instance tags for file 0x19953.\r\n 836096 file records processed. \r\r\nFile verification completed.\r\n Phase duration (File record verification): 55.78 seconds.\r\n 29050 large file records processed. \r\r\n Phase duration (Orphan file record recovery): 0.00 milliseconds.\r\n 0 bad file records processed. \r\r\n Phase duration (Bad file record checking): 0.60 milliseconds.\r\n\r\nStage 2: Examining file name linkage ...\r\n 76080 reparse records processed. \r\r\n 1173980 index entries processed. \r\r\nIndex verification completed.\r\n Phase duration (Index verification): 3.73 minutes.\r\n 0 unindexed files scanned. \r\r\n Phase duration (Orphan reconnection): 7.40 seconds.\r\n 0 unindexed files recovered to lost and found. \r\r\n Phase duration (Orphan recovery to lost and found): 0.33 milliseconds.\r\n 76080 reparse records processed. \r\r\n Phase duration (Reparse point and Object ID verification): 279.81 milliseconds.\r\n\r\nStage 3: Examining security descriptors ...\r\nSecurity descriptor verification completed.\r\n Phase duration (Security descriptor verification): 725.96 milliseconds.\r\n 168943 data files processed. \r\r\n Phase duration (Data attribute verification): 0.39 milliseconds.\r\nCHKDSK is verifying Usn Journal...\r\n 33718840 USN bytes processed. \r\r\nUsn Journal verification completed.\r\n Phase duration (USN journal verification): 580.54 milliseconds.\r\n\r\nWindows has scanned the file system and found no problems.\r\nNo further action is required.\r\n\r\n 311459395 KB total disk space.\r\n 50097752 KB in 413842 files.\r\n 311952 KB in 168944 indexes.\r\n 0 KB in bad sectors.\r\n 956951 KB in use by the system.\r\n 65536 KB occupied by the log file.\r\n 260092740 KB available on disk.\r\n\r\n 4096 bytes in each allocation unit.\r\n 77864848 total allocation units on disk.\r\n 65023185 allocation units available on disk.\r\nTotal duration: 4.81 minutes (289035 ms).\r\n\""},"eventdata":{"binary":"00C20C008DE40800ADA70F00000000001C020000142701000000000000000000","data":" Checking file system on C: The type of the file system is NTFS. Volume label is OSDisk. WARNING! /F parameter not specified. Running CHKDSK in read-only mode. Stage 1: Examining basic file system structure ... Cleaning up instance tags for file 0x19953. 836096 file records processed. File verification completed. Phase duration (File record verification): 55.78 seconds. 29050 large file records processed. Phase duration (Orphan file record recovery): 0.00 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 0.60 milliseconds. Stage 2: Examining file name linkage ... 76080 reparse records processed. 1173980 index entries processed. Index verification completed. Phase duration (Index verification): 3.73 minutes. 0 unindexed files scanned. Phase duration (Orphan reconnection): 7.40 seconds. 0 unindexed files recovered to lost and found. Phase duration (Orphan recovery to lost and found): 0.33 milliseconds. 76080 reparse records processed. Phase duration (Reparse point and Object ID verification): 279.81 milliseconds. Stage 3: Examining security descriptors ... Security descriptor verification completed. Phase duration (Security descriptor verification): 725.96 milliseconds. 168943 data files processed. Phase duration (Data attribute verification): 0.39 milliseconds. CHKDSK is verifying Usn Journal... 33718840 USN bytes processed. Usn Journal verification completed. Phase duration (USN journal verification): 580.54 milliseconds. Windows has scanned the file system and found no problems. No further action is required. 311459395 KB total disk space. 50097752 KB in 413842 files. 311952 KB in 168944 indexes. 0 KB in bad sectors. 956951 KB in use by the system. 65536 KB occupied by the log file. 260092740 KB available on disk. 4096 bytes in each allocation unit. 77864848 total allocation units on disk. 65023185 allocation units available on disk. Total duration: 4.81 minutes (289035 ms)."}}}
2023 Sep 06 12:12:23 (MG-PC) any->EventChannel {"win":{"system":{"providerName":"Chkdsk","eventID":"26212","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2023-09-06T16:12:23.1086916Z","eventRecordID":"973400","processID":"0","threadID":"0","channel":"Application","computer":"MG-PC","severityValue":"INFORMATION","message":"\"Chkdsk was executed in read-only mode on a volume snapshot. \r\n\r\nChecking file system on C:\r\nThe type of the file system is NTFS.\r\nVolume label is OSDisk.\r\n\r\nWARNING! /F parameter not specified.\r\nRunning CHKDSK in read-only mode.\r\n\r\nStage 1: Examining basic file system structure ...\r\nCleaning up instance tags for file 0x19953.\r\n 836096 file records processed. \r\r\nFile verification completed.\r\n Phase duration (File record verification): 1.24 minutes.\r\n 29051 large file records processed. \r\r\n Phase duration (Orphan file record recovery): 0.00 milliseconds.\r\n 0 bad file records processed. \r\r\n Phase duration (Bad file record checking): 0.93 milliseconds.\r\n\r\nStage 2: Examining file name linkage ...\r\n 76080 reparse records processed. \r\r\n 1173980 index entries processed. \r\r\nIndex verification completed.\r\n Phase duration (Index verification): 4.41 minutes.\r\n 0 unindexed files scanned. \r\r\n Phase duration (Orphan reconnection): 7.42 seconds.\r\n 0 unindexed files recovered to lost and found. \r\r\n Phase duration (Orphan recovery to lost and found): 0.32 milliseconds.\r\n 76080 reparse records processed. \r\r\n Phase duration (Reparse point and Object ID verification): 276.55 milliseconds.\r\n\r\nStage 3: Examining security descriptors ...\r\nSecurity descriptor verification completed.\r\n Phase duration (Security descriptor verification): 147.47 milliseconds.\r\n 168943 data files processed. \r\r\n Phase duration (Data attribute verification): 0.37 milliseconds.\r\nCHKDSK is verifying Usn Journal...\r\n 34392472 USN bytes processed. \r\r\nUsn Journal verification completed.\r\n Phase duration (USN journal verification): 719.12 milliseconds.\r\n\r\nWindows has scanned the file system and found no problems.\r\nNo further action is required.\r\n\r\n 311459395 KB total disk space.\r\n 50355068 KB in 413907 files.\r\n 311964 KB in 168944 indexes.\r\n 0 KB in bad sectors.\r\n 957783 KB in use by the system.\r\n 65536 KB occupied by the log file.\r\n 259834580 KB available on disk.\r\n\r\n 4096 bytes in each allocation unit.\r\n 77864848 total allocation units on disk.\r\n 64958645 allocation units available on disk.\r\nTotal duration: 5.80 minutes (348103 ms).\r\n\""},"eventdata":{"binary":"00C20C00CEE408002BA80F00000000001C020000142701000000000000000000","data":" Checking file system on C: The type of the file system is NTFS. Volume label is OSDisk. WARNING! /F parameter not specified. Running CHKDSK in read-only mode. Stage 1: Examining basic file system structure ... Cleaning up instance tags for file 0x19953. 836096 file records processed. File verification completed. Phase duration (File record verification): 1.24 minutes. 29051 large file records processed. Phase duration (Orphan file record recovery): 0.00 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 0.93 milliseconds. Stage 2: Examining file name linkage ... 76080 reparse records processed. 1173980 index entries processed. Index verification completed. Phase duration (Index verification): 4.41 minutes. 0 unindexed files scanned. Phase duration (Orphan reconnection): 7.42 seconds. 0 unindexed files recovered to lost and found. Phase duration (Orphan recovery to lost and found): 0.32 milliseconds. 76080 reparse records processed. Phase duration (Reparse point and Object ID verification): 276.55 milliseconds. Stage 3: Examining security descriptors ... Security descriptor verification completed. Phase duration (Security descriptor verification): 147.47 milliseconds. 168943 data files processed. Phase duration (Data attribute verification): 0.37 milliseconds. CHKDSK is verifying Usn Journal... 34392472 USN bytes processed. Usn Journal verification completed. Phase duration (USN journal verification): 719.12 milliseconds. Windows has scanned the file system and found no problems. No further action is required. 311459395 KB total disk space. 50355068 KB in 413907 files. 311964 KB in 168944 indexes. 0 KB in bad sectors. 957783 KB in use by the system. 65536 KB occupied by the log file. 259834580 KB available on disk. 4096 bytes in each allocation unit. 77864848 total allocation units on disk. 64958645 allocation units available on disk. Total duration: 5.80 minutes (348103 ms)."}}}
2023 Sep 06 13:11:00 (MG-PC) any->EventChannel {"win":{"system":{"providerName":"Chkdsk","eventID":"26212","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2023-09-06T17:11:00.8631543Z","eventRecordID":"973404","processID":"0","threadID":"0","channel":"Application","computer":"MG-PC","severityValue":"INFORMATION","message":"\"Chkdsk was executed in read-only mode on a volume snapshot. \r\n\r\nChecking file system on C:\r\nThe type of the file system is NTFS.\r\nVolume label is OSDisk.\r\n\r\nWARNING! /F parameter not specified.\r\nRunning CHKDSK in read-only mode.\r\n\r\nStage 1: Examining basic file system structure ...\r\nCleaning up instance tags for file 0x19953.\r\n 836096 file records processed. \r\r\nFile verification completed.\r\n Phase duration (File record verification): 1.66 minutes.\r\n 29051 large file records processed. \r\r\n Phase duration (Orphan file record recovery): 0.00 milliseconds.\r\n 0 bad file records processed. \r\r\n Phase duration (Bad file record checking): 1.16 milliseconds.\r\n\r\nStage 2: Examining file name linkage ...\r\n 76081 reparse records processed. \r\r\n 1173980 index entries processed. \r\r\nIndex verification completed.\r\n Phase duration (Index verification): 3.72 minutes.\r\n 0 unindexed files scanned. \r\r\n Phase duration (Orphan reconnection): 7.41 seconds.\r\n 0 unindexed files recovered to lost and found. \r\r\n Phase duration (Orphan recovery to lost and found): 0.33 milliseconds.\r\n 76081 reparse records processed. \r\r\n Phase duration (Reparse point and Object ID verification): 293.83 milliseconds.\r\n\r\nStage 3: Examining security descriptors ...\r\nSecurity descriptor verification completed.\r\n Phase duration (Security descriptor verification): 257.68 milliseconds.\r\n 168943 data files processed. \r\r\n Phase duration (Data attribute verification): 0.36 milliseconds.\r\nCHKDSK is verifying Usn Journal...\r\n 34905840 USN bytes processed. \r\r\nUsn Journal verification completed.\r\n Phase duration (USN journal verification): 472.06 milliseconds.\r\n\r\nWindows has scanned the file system and found no problems.\r\nNo further action is required.\r\n\r\n 311459395 KB total disk space.\r\n 50531508 KB in 413933 files.\r\n 311964 KB in 168944 indexes.\r\n 0 KB in bad sectors.\r\n 957975 KB in use by the system.\r\n 65536 KB occupied by the log file.\r\n 259657948 KB available on disk.\r\n\r\n 4096 bytes in each allocation unit.\r\n 77864848 total allocation units on disk.\r\n 64914487 allocation units available on disk.\r\nTotal duration: 5.52 minutes (331744 ms).\r\n\""},"eventdata":{"binary":"00C20C00E8E4080060A80F00000000001D020000142701000000000000000000","data":" Checking file system on C: The type of the file system is NTFS. Volume label is OSDisk. WARNING! /F parameter not specified. Running CHKDSK in read-only mode. Stage 1: Examining basic file system structure ... Cleaning up instance tags for file 0x19953. 836096 file records processed. File verification completed. Phase duration (File record verification): 1.66 minutes. 29051 large file records processed. Phase duration (Orphan file record recovery): 0.00 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 1.16 milliseconds. Stage 2: Examining file name linkage ... 76081 reparse records processed. 1173980 index entries processed. Index verification completed. Phase duration (Index verification): 3.72 minutes. 0 unindexed files scanned. Phase duration (Orphan reconnection): 7.41 seconds. 0 unindexed files recovered to lost and found. Phase duration (Orphan recovery to lost and found): 0.33 milliseconds. 76081 reparse records processed. Phase duration (Reparse point and Object ID verification): 293.83 milliseconds. Stage 3: Examining security descriptors ... Security descriptor verification completed. Phase duration (Security descriptor verification): 257.68 milliseconds. 168943 data files processed. Phase duration (Data attribute verification): 0.36 milliseconds. CHKDSK is verifying Usn Journal... 34905840 USN bytes processed. Usn Journal verification completed. Phase duration (USN journal verification): 472.06 milliseconds. Windows has scanned the file system and found no problems. No further action is required. 311459395 KB total disk space. 50531508 KB in 413933 files. 311964 KB in 168944 indexes. 0 KB in bad sectors. 957975 KB in use by the system. 65536 KB occupied by the log file. 259657948 KB available on disk. 4096 bytes in each allocation unit. 77864848 total allocation units on disk. 64914487 allocation units available on disk. Total duration: 5.52 minutes (331744 ms)."}}}
2023 Sep 06 14:24:02 (MG-PC) any->EventChannel {"win":{"system":{"providerName":"Chkdsk","eventID":"26212","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2023-09-06T18:23:58.7304867Z","eventRecordID":"973410","processID":"0","threadID":"0","channel":"Application","computer":"MG-PC","severityValue":"INFORMATION","message":"\"Chkdsk was executed in read-only mode on a volume snapshot. \r\n\r\nChecking file system on C:\r\nThe type of the file system is NTFS.\r\nVolume label is OSDisk.\r\n\r\nWARNING! /F parameter not specified.\r\nRunning CHKDSK in read-only mode.\r\n\r\nStage 1: Examining basic file system structure ...\r\nCleaning up instance tags for file 0x19953.\r\n 836096 file records processed. \r\r\nFile verification completed.\r\n Phase duration (File record verification): 1.37 minutes.\r\n 29051 large file records processed. \r\r\n Phase duration (Orphan file record recovery): 0.00 milliseconds.\r\n 0 bad file records processed. \r\r\n Phase duration (Bad file record checking): 0.10 milliseconds.\r\n\r\nStage 2: Examining file name linkage ...\r\n 76085 reparse records processed. \r\r\n 1173998 index entries processed. \r\r\nIndex verification completed.\r\n Phase duration (Index verification): 5.87 minutes.\r\n 0 unindexed files scanned. \r\r\n Phase duration (Orphan reconnection): 7.53 seconds.\r\n 0 unindexed files recovered to lost and found. \r\r\n Phase duration (Orphan recovery to lost and found): 0.07 milliseconds.\r\n 76085 reparse records processed. \r\r\n Phase duration (Reparse point and Object ID verification): 368.46 milliseconds.\r\n\r\nStage 3: Examining security descriptors ...\r\nSecurity descriptor verification completed.\r\n Phase duration (Security descriptor verification): 8.13 seconds.\r\n 168952 data files processed. \r\r\n Phase duration (Data attribute verification): 0.07 milliseconds.\r\nCHKDSK is verifying Usn Journal...\r\n 35504840 USN bytes processed. \r\r\nUsn Journal verification completed.\r\n Phase duration (USN journal verification): 3.11 seconds.\r\n\r\nWindows has scanned the file system and found no problems.\r\nNo further action is required.\r\n\r\n 311459395 KB total disk space.\r\n 50698012 KB in 413848 files.\r\n 311968 KB in 168953 indexes.\r\n 0 KB in bad sectors.\r\n 958487 KB in use by the system.\r\n 65536 KB occupied by the log file.\r\n 259490928 KB available on disk.\r\n\r\n 4096 bytes in each allocation unit.\r\n 77864848 total allocation units on disk.\r\n 64872732 allocation units available on disk.\r\nTotal duration: 7.57 minutes (454444 ms).\r\n\""},"eventdata":{"binary":"00C20C009CE40800C1A70F000000000021020000142701000000000000000000","data":" Checking file system on C: The type of the file system is NTFS. Volume label is OSDisk. WARNING! /F parameter not specified. Running CHKDSK in read-only mode. Stage 1: Examining basic file system structure ... Cleaning up instance tags for file 0x19953. 836096 file records processed. File verification completed. Phase duration (File record verification): 1.37 minutes. 29051 large file records processed. Phase duration (Orphan file record recovery): 0.00 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 0.10 milliseconds. Stage 2: Examining file name linkage ... 76085 reparse records processed. 1173998 index entries processed. Index verification completed. Phase duration (Index verification): 5.87 minutes. 0 unindexed files scanned. Phase duration (Orphan reconnection): 7.53 seconds. 0 unindexed files recovered to lost and found. Phase duration (Orphan recovery to lost and found): 0.07 milliseconds. 76085 reparse records processed. Phase duration (Reparse point and Object ID verification): 368.46 milliseconds. Stage 3: Examining security descriptors ... Security descriptor verification completed. Phase duration (Security descriptor verification): 8.13 seconds. 168952 data files processed. Phase duration (Data attribute verification): 0.07 milliseconds. CHKDSK is verifying Usn Journal... 35504840 USN bytes processed. Usn Journal verification completed. Phase duration (USN journal verification): 3.11 seconds. Windows has scanned the file system and found no problems. No further action is required. 311459395 KB total disk space. 50698012 KB in 413848 files. 311968 KB in 168953 indexes. 0 KB in bad sectors. 958487 KB in use by the system. 65536 KB occupied by the log file. 259490928 KB available on disk. 4096 bytes in each allocation unit. 77864848 total allocation units on disk. 64872732 allocation units available on disk. Total duration: 7.57 minutes (454444 ms)."}}}

The logtest output I'm getting is:

Starting wazuh-logtest v4.5.1
Type one log per line

**Phase 1: Completed pre-decoding.
full event: '{"win":{"system":{"providerName":"Chkdsk","eventID":"26212","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2023-09-10T21:14:37.9799898Z","eventRecordID":"225196","processID":"0","threadID":"0","channel":"Application","computer":"SueBailey-PC.LSC2003.longfellow","severityValue":"INFORMATION","message":"\"Chkdsk was executed in read-only mode on a volume snapshot. \r\n\r\nChecking file system on C:\r\nThe type of the file system is NTFS.\r\nVolume label is OS.\r\n\r\nWARNING! /F parameter not specified.\r\nRunning CHKDSK in read-only mode.\r\n\r\nStage 1: Examining basic file system structure ...\r\n 891904 file records processed. \r\r\nFile verification completed.\r\n Phase duration (File record verification): 45.24 seconds.\r\n 30061 large file records processed. \r\r\n Phase duration (Orphan file record recovery): 0.00 milliseconds.\r\n 0 bad file records processed. \r\r\n Phase duration (Bad file record checking): 0.15 milliseconds.\r\n\r\nStage 2: Examining file name linkage ...\r\n 67145 reparse records processed. \r\r\n 1304598 index entries processed. \r\r\nIndex verification completed.\r\n Phase duration (Index verification): 2.85 minutes.\r\n 0 unindexed files scanned. \r\r\n Phase duration (Orphan reconnection): 10.43 seconds.\r\n 0 unindexed files recovered to lost and found. \r\r\n Phase duration (Orphan recovery to lost and found): 0.23 milliseconds.\r\n 67145 reparse records processed. \r\r\n Phase duration (Reparse point and Object ID verification): 154.00 milliseconds.\r\n\r\nStage 3: Examining security descriptors ...\r\nSecurity descriptor verification completed.\r\n Phase duration (Security descriptor verification): 133.09 milliseconds.\r\n 206348 data files processed. \r\r\n Phase duration (Data attribute verification): 1.53 milliseconds.\r\nCHKDSK is verifying Usn Journal...\r\n 34571576 USN bytes processed. \r\r\nUsn Journal verification completed.\r\n Phase duration (USN journal verification): 1.28 seconds.\r\n\r\nWindows has scanned the file system and found no problems.\r\nNo further action is required.\r\n\r\n 477651967 KB total disk space.\r\n 116020404 KB in 481484 files.\r\n 413544 KB in 206349 indexes.\r\n 4 KB in bad sectors.\r\n 1023271 KB in use by the system.\r\n 65536 KB occupied by the log file.\r\n 360194744 KB available on disk.\r\n\r\n 4096 bytes in each allocation unit.\r\n 119412991 total allocation units on disk.\r\n 90048686 allocation units available on disk.\r\nTotal duration: 3.80 minutes (228368 ms).\r\n\""},"eventdata":{"binary":"009C0D00E47E0A00425B12000000000075020000D40301000000000000000000","data":" Checking file system on C: The type of the file system is NTFS. Volume label is OS. WARNING! /F parameter not specified. Running CHKDSK in read-only mode. Stage 1: Examining basic file system structure ... 891904 file records processed. File verification completed. Phase duration (File record verification): 45.24 seconds. 30061 large file records processed. Phase duration (Orphan file record recovery): 0.00 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 0.15 milliseconds. Stage 2: Examining file name linkage ... 67145 reparse records processed. 1304598 index entries processed. Index verification completed. Phase duration (Index verification): 2.85 minutes. 0 unindexed files scanned. Phase duration (Orphan reconnection): 10.43 seconds. 0 unindexed files recovered to lost and found. Phase duration (Orphan recovery to lost and found): 0.23 milliseconds. 67145 reparse records processed. Phase duration (Reparse point and Object ID verification): 154.00 milliseconds. Stage 3: Examining security descriptors ... Security descriptor verification completed. Phase duration (Security descriptor verification): 133.09 milliseconds. 206348 data files processed. Phase duration (Data attribute verification): 1.53 milliseconds. CHKDSK is verifying Usn Journal... 34571576 USN bytes processed. Usn Journal verification completed. Phase duration (USN journal verification): 1.28 seconds. Windows has scanned the file system and found no problems. No further action is required. 477651967 KB total disk space. 116020404 KB in 481484 files. 413544 KB in 206349 indexes. 4 KB in bad sectors. 1023271 KB in use by the system. 65536 KB occupied by the log file. 360194744 KB available on disk. 4096 bytes in each allocation unit. 119412991 total allocation units on disk. 90048686 allocation units available on disk. Total duration: 3.80 minutes (228368 ms)."}}}'

**Phase 2: Completed decoding.
name: 'json'
win.eventdata.binary: '009C0D00E47E0A00425B12000000000075020000D40301000000000000000000'
win.eventdata.data: ' Checking file system on C: The type of the file system is NTFS. Volume label is OS. WARNING! /F parameter not specified. Running CHKDSK in read-only mode. Stage 1: Examining basic file system structure ... 891904 file records processed. File verification completed. Phase duration (File record verification): 45.24 seconds. 30061 large file records processed. Phase duration (Orphan file record recovery): 0.00 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 0.15 milliseconds. Stage 2: Examining file name linkage ... 67145 reparse records processed. 1304598 index entries processed. Index verification completed. Phase duration (Index verification): 2.85 minutes. 0 unindexed files scanned. Phase duration (Orphan reconnection): 10.43 seconds. 0 unindexed files recovered to lost and found. Phase duration (Orphan recovery to lost and found): 0.23 milliseconds. 67145 reparse records processed. Phase duration (Reparse point and Object ID verification): 154.00 milliseconds. Stage 3: Examining security descriptors ... Security descriptor verification completed. Phase duration (Security descriptor verification): 133.09 milliseconds. 206348 data files processed. Phase duration (Data attribute verification): 1.53 milliseconds. CHKDSK is verifying Usn Journal... 34571576 USN bytes processed. Usn Journal verification completed. Phase duration (USN journal verification): 1.28 seconds. Windows has scanned the file system and found no problems. No further action is required. 477651967 KB total disk space. 116020404 KB in 481484 files. 413544 KB in 206349 indexes. 4 KB in bad sectors. 1023271 KB in use by the system. 65536 KB occupied by the log file. 360194744 KB available on disk. 4096 bytes in each allocation unit. 119412991 total allocation units on disk. 90048686 allocation units available on disk. Total duration: 3.80 minutes (228368 ms).'
win.system.channel: 'Application'
win.system.computer: 'SueBailey-PC.LSC2003.longfellow'
win.system.eventID: '26212'
win.system.eventRecordID: '225196'
win.system.keywords: '0x80000000000000'
win.system.level: '4'
win.system.message: '"Chkdsk was executed in read-only mode on a volume snapshot.

Checking file system on C:
The type of the file system is NTFS.
Volume label is OS.

WARNING! /F parameter not specified.
Running CHKDSK in read-only mode.

Stage 1: Examining basic file system structure ...
891904 file records processed.
File verification completed.
Phase duration (File record verification): 45.24 seconds.
30061 large file records processed.
Phase duration (Orphan file record recovery): 0.00 milliseconds.
0 bad file records processed.
Phase duration (Bad file record checking): 0.15 milliseconds.

Stage 2: Examining file name linkage ...
67145 reparse records processed.
1304598 index entries processed.
Index verification completed.
Phase duration (Index verification): 2.85 minutes.
0 unindexed files scanned.
Phase duration (Orphan reconnection): 10.43 seconds.
0 unindexed files recovered to lost and found.
Phase duration (Orphan recovery to lost and found): 0.23 milliseconds.
67145 reparse records processed.
Phase duration (Reparse point and Object ID verification): 154.00 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
Phase duration (Security descriptor verification): 133.09 milliseconds.
206348 data files processed.
Phase duration (Data attribute verification): 1.53 milliseconds.
CHKDSK is verifying Usn Journal...
34571576 USN bytes processed.
Usn Journal verification completed.
Phase duration (USN journal verification): 1.28 seconds.

Windows has scanned the file system and found no problems.
No further action is required.

477651967 KB total disk space.
116020404 KB in 481484 files.
413544 KB in 206349 indexes.
4 KB in bad sectors.
1023271 KB in use by the system.
65536 KB occupied by the log file.
360194744 KB available on disk.

4096 bytes in each allocation unit.
119412991 total allocation units on disk.
90048686 allocation units available on disk.
Total duration: 3.80 minutes (228368 ms).
"'
win.system.opcode: '0'
win.system.processID: '0'
win.system.providerName: 'Chkdsk'
win.system.severityValue: 'INFORMATION'
win.system.systemTime: '2023-09-10T21:14:37.9799898Z'
win.system.task: '0'
win.system.threadID: '0'
win.system.version: '0'

It looks like the test never passes phase 3, and am hoping for a suggestion of what to do.

Thx as always for help.

Matias Braida

unread,

Sep 11, 2023, 3:53:49 PM9/11/23

to Wazuh | Mailing List

Hello again,

1) That rule looks good to me.
If a default rule already exists and you need to modify some settings like level, etc. it is easier to overwrite the default rule with the one you need.
But if you need a completely different rule based on a custom decoder or based on some existing rule that is different about the fields to match or any other cause, then a custom rule (and maybe a custom decoder) is necessary.

2) In the documentation example, the input string of the tool "wazuh-logtest" is:

Oct 15 21:07:00 linux-agent sshd[29205]: Invalid user blimey from 18.18.18.18 port 48928

Because the sshd logs (the one used in this example) contain a date at the beginning. But when you get the event from the "archives.log", you have the wazuh header (that you have to remove) and then the sshd event.
I try it locally and this is a sshd event as it figures in "archives.log":
2023 Sep 11 16:42:26 matias-X580VD->/var/log/auth.log Sep 11 16:42:25 matias-X580VD sshd[664439]: Invalid user invalid_user from 127.0.0.1 port 36644

So, you have to remove the wazuh header prior to entering the log in the tool "wazuh-logtest". In this case, the line without the wazuh header is:
Sep 11 16:42:25 matias-X580VD sshd[664439]: Invalid user invalid_user from 127.0.0.1 port 36644

3) Regarding this point, that seems to be an issue on another specific rule, Please open a new thread just to keep the order in the community for other users that look for solutions to similar issues to yours.

Regards

Secure moi

unread,

Sep 12, 2023, 8:57:31 AM9/12/23

to Wazuh | Mailing List

Great, thx Matias (again), will do on starting new thread for new rule. Appreciate the help!

Reply all

Reply to author

Forward