Wazuh 5.0.0 beta 2. Rules / Dashboard / índices.

[suricata]

Hola a todos, sé que aún está en beta 2 y queda mucho por hacer. Así que no sé si se podrá responder a esta pregunta.

He credo una regla muy básica con su integración y decoder, promocionado a custom, etc. El Test log lo hace perfecto y hace match en la regla. Ya me pasó con alertas sysmon que vi que no aparecía en el daschboard  Threat Hunting > Findings y tuve que buscarlas mediante curl y crear un Visualizador para verlas. En este caso no sé ya en qué índice buscar porque nos las veo por ningún sitio. 

Alguna pista de dónde buscar ?

Saludos y gracias.

[Md. Nazmur Sakib]

Hello!

I am setting up a Wazuh 5 environment to test this from my end. I will get back to you soon.

[suricata]

Hello !! 

Thanks, Nazmur.

To view sysmon events or alerts, I achieved it this way using curl:

curl -s -k -u admin:admin -X GET "https://localhost:9200/.ds-wazuh-events-*/_search?pretty" -H 'Content-Type: application/json' -d '
{
  "size": 1,
  "query": {
    "match": {
      "event.dataset": "sysmon"
    }
  }
}'

[Md. Nazmur Sakib]

I have tested with the same event.

I was able to see the alerts in the Threat Hunting > Findings

If you are seeing the logs in the  wazuh-events index, that means your decoders are working properly, but if the rules work, you should be able to see the alerts in the wazuh-findings-* index as well, and they will appear in the  Threat Hunting > Findings

I am sharing some screenshots as a reference from my test results.





Once we have the release ready, we will share the detailed documents for creating decoders and rules in 5.0.

Let me know if you need any further information.

[suricata]

Hi, Nazmur,

Thanks for replying.

I've made several attempts to log in with SSH to trigger the alert, but nothing happens. It might be the rule that's faulty, but the test log shows it as valid. Here's the YAML file for the rule:

id: 93d32016-b4f8-4bfe-97b7-ced8aa75890d
logsource:
  product: linux
tags:
  - attack.credential_access
  - attack.t1110
falsepositives:
  - Legitimate admin activity
level: medium
status: stable
enabled: true
detection:
  selection:
    event.original:
      - '*Failed password for*'
      - '*sshd*'
  condition: selection
metadata:
  title: SSH Failed Login
  author: Alfon Laboratorio
  description: Detecta intentos de login SSH fallidos
  references:
    - ''
  documentation: ''
  supports:
    - ''

------------------------------Decoder:--------------------------------

---
name: "decoder/sshd-custom/0"
metadata:
  title: "SSH Failed Login Decoder"
  description: "Decoder para SSH login fallido"
  author: "Alfon Laboratorio"
  date: "2026-05-26T11:04:22Z"
  modified: "2026-05-26T11:04:22Z"
  supports: []
enabled: true
check:
- process.name: "sshd"
parse|event.original:
- "Failed password for invalid user <user.name> from <source.ip> port <source.port>\
  \ ssh2"
- "Failed password for <user.name> from <source.ip> port <source.port> ssh2"
normalize:
- map:
  - event.category: "authentication"
  - event.type: "start"
  - event.outcome: "failure"
  - event.module: "sshd"
id: "830bc3f5-20a5-4c51-8eb3-d626427a796b"

[Md. Nazmur Sakib]

Okay. Let me test it and get back to you.

[Md. Nazmur Sakib]

Based on my findings, the issue was with your decoder. It was not decoding anything.

How the new rule engine works is:
Based on your decoders, the logs are normalized and saved in the wazuh-events-* indices.

Next, based on your rule and detector, it triggers an alert and saves it in the wazuh-findings-* indices.


The primary issue was that your decoder was not working. So no logs were saved to wazuh-events-* indices.





For your log. Add these two additional decoders to your space.
core-wazuh-message

--- name: "decoder/core-wazuh-message-custom/0" metadata: author: "Sakib" date: "2026-06-04T13:15:31Z" description: "Base decoder to process Wazuh message format, parses location part\ \ and enriches the events that comes from a Wazuh agent with the host information." documentation: "" modified: "2026-06-04T13:15:56Z" references: - "https://documentation.wazuh.com/" supports: [] title: "Wazuh message decoder" normalize: - map: - _tmp_json: "parse_json($event.original)" enabled: true id: "dff1f343-d262-4ad1-87af-ba4f5213e057"

syslog Header

--- name: "decoder/syslog/0" metadata: author: "Sakib" date: "2026-06-04T13:32:35Z" description: "Syslog header" documentation: "" modified: "2026-06-04T13:36:01Z" references: - "https://www.ietf.org/rfc/rfc3164.txt" - "https://www.ietf.org/rfc/rfc5424.txt" supports: [] title: "Syslog Decoder event" parents: - "decoder/core-wazuh-message-custom/0" parse|event.original: - "<event.start/Jun 14 15:16:01> <_tmp.hostname/fqdn> <_TAG/alphanumeric/->[<process.pid>]:<~/ignore/\ \ ><message>" - "<event.start/Jun 14 15:16:01> <_tmp.hostname/fqdn> <_TAG/alphanumeric/->:<~/ignore/\ \ ><message>" - "<event.start/2018-08-14T14:30:02.203151+02:00> <_tmp.hostname/fqdn> <_TAG/alphanumeric/->[<process.pid>]:\ \ <message>" - "<event.start/2018-08-14T14:30:02.203151+02:00> <_tmp.hostname/fqdn> <_TAG/alphanumeric/->:\ \ <message>" - "<event.start/ISO8601Z> <_tmp.hostname/fqdn> <_TAG/alphanumeric/->: <message>" - "<event.start/SYSLOG> <_tmp.hostname/fqdn><?~/ignore/ >(?: )<message>" - "<event.start/%Y %b %d %T> <_timezone> <_tmp.hostname/fqdn> <_tmp.host_ip> <_TAG/alphanumeric/->[<process.pid>]:<~/ignore/\ \ ><message>" - "<event.start/%Y %b %d %T> <_tmp.hostname/fqdn> <_tmp.host_ip> <_TAG/alphanumeric/->[<process.pid>]:<~/ignore/\ \ ><message>" normalize: - map: - event.kind: "event" - check: - _tmp.hostname: "exists()" map: - host.hostname: "$_tmp.hostname" - related.hosts: "array_append($host.hostname)" - check: - _TAG: "exists()" map: - process.name: "rename($_TAG)" - check: - _tmp.host_ip: "exists()" map: - host.ip: "array_append($_tmp.host_ip)" - check: - _tmp: "exists()" map: - _tmp: "delete()" enabled: true id: "c30ebc9a-782f-4854-9729-190c5469b8c1"


And update your existing decoder.

--- name: "decoder/sshd-custom/0" metadata: title: "SSH Failed Login Decoder" description: "Decoder para SSH login fallido" author: "Alfon Laboratorio" date: "2026-06-04T13:02:25Z" modified: "2026-06-04T14:04:38Z" references: - " " supports: [] parents: - "decoder/syslog/0" enabled: true definitions: isAuthProcess: "$process.name == sshd OR $process.name == sudo OR $process.name\ \ == groupadd OR $process.name == useradd OR $process.name == groupdel OR $process.name\ \ == groupmod OR $process.name == userdel OR $process.name == usermod OR $process.name\ \ == CRON" normalize: - map: - event.dataset: "system-auth" - event.kind: "event" - event.outcome: "success" - check: - process.name: "sshd" parse|message: - "<_system.auth.ssh.event> <_system.auth.ssh.method> for (?invalid user )<user.name>\ \ from <source.ip> port <source.port> ssh2(?:<~>)" - "<_system.auth.ssh.event> user <user.name> from <source.ip>(? port <source.port>)" - "Did not receive identification string from <source.ip>" - "subsystem request for <_system.auth.ssh.subsystem> by user <user.name>" - "<_system.auth.ssh.session.action>: Too many authentication <_system.auth.ssh.event>\ \ for <user.name> [preauth]" - "<user.name> [<~>][<~>]: <_system.auth.ssh.event>: <_system.auth.ssh.session.process_id>\ \ tty<~/literal/\\/>?<~/literal/s><_system.process.tty.char_device.major>" - "<_system.auth.ssh.event>: Read from socket failed: Connection reset by peer [preauth]" - "Received <_system.auth.ssh.event> from <source.ip>: <~>: [<~>]" - check: "$_system.auth.ssh.event == Accepted OR $_system.auth.ssh.event == USER_PROCESS" map: - event.action: "logged-in" - event.category: "array_append(authentication, session)" - event.outcome: "success" - event.type: "array_append(info)" id: "653ec149-b9b0-4c9e-8ebf-4fbd300b902e"


Now make the core-wazuh-message as the root decoder from Space 






Next, promote the decoders to custom.

Next, make sure to configure a detector for your rule.



These is my test result.



Let me know if this works for you.

[suricata]

Hi, Nazmur

Wonderful. Thank you so much for your reply. 

I'll try all that and let you know. The new way of creating rules is quite a drastic change, considering how simple it was before. Regards and thanks.

[suricata]

Hí, Nazmur.

I have everything now, the only thing I'm missing is the last part where you say:     "" Next, make sure to configure a detector for your rule.""

I can't find the detector anywhere. I only see the Standard Space, but not the Custom one. Is it possible that it's not there and needs to be created?

[Md. Nazmur Sakib]

Yes, you need to create the custom detector using your custom rule. Once you create the detector, you will be able to see the custom in the space section. The detector uses the rules to detect and save the detection in the wazuh-findings-* indices.

Check these screenshots for reference.

[suricata]

Hi,  Nazmur

Thanks.

I've been checking everything for a while, but I don't see any rules to add. And I don't understand why, because everything seems correct.  

[Md. Nazmur Sakib]

When you create the rule, make sure to add it to an integration you have created previously.


Promote the rules to custom.

After that, if you select the integration while making a detector, you will be able to see the rules on that integration.

[suricata]

Hi, Nazmur 

Thanks.

Yes, but that part was there from the beginning, I don't know why it's not showing up. When I edit the rule, it says "Linux," which I don't understand either; it looks fine in the screenshots. Even so, I edited the YAML (the visual editor won't let me) to specify it there.

Space Custom:

[suricata]

Hi, Nazmur

I recreated the rule again, and now I can create the Detector.

id: cf37032e-0c82-493b-841c-0a6f1eb09388
logsource:
  product: sshd-custom

tags:
  - attack.credential_access
  - attack.t1110
falsepositives:
  - Legitimate admin activity
level: medium
status: stable
enabled: true
detection:

  condition: selection

  selection:
    event.original:
      - '*Failed password for*'
      - '*sshd*'

    wazuh.integration.name:
      - sshd-custom
metadata:
  title: SSH Failed Login_v1
  author: Alfon @seguridadyredes Laboratorio
  description: Detecta intentos de login SSH fallidos V1

  references:
    - ''
  documentation: ''
  supports:
    - ''

  modified: '2026-06-05T11:43:41Z'

[suricata]

Hí,  Nazmur

I've tried several things and it seems it's been working for some time, only in: _index

.ds-wazuh-events-v5-access-management-000001

Now I just need to be able to see it in the Threat Hunting Dashboard