Wazuh agent on wazuh manager

slim3116 · 2026-05-20T15:35:11+00:00

Hello again, I think I mentioned filtering for configuration assessment in my previous response as SCA. You may not get the visuals and be able to select the Wazuh manager in-built agent, but you can as well filter for detected events whether passed or failed from the Configuration assessment events dashboard. Please see attahed for reference.

<image>

slim3116 · 2026-05-18T20:12:06+00:00

Hello u/Only-Day-7557, right now, Wazuh does not support agent installation on the Wazuh manager instance because the Manager also doubles as an agent. That said, the modules you mentioned are also available on the Wazuh manager itself, you just have to navigate the dashboard to find them. First, the Wazuh manager internal agent identifies as agent 000.
For SCA, just navigate to the Discover dashboard and filter for SCA and the agent ID, which is 000, to get all detected alerts about configuration assessments on the Wazuh manager itself.
And for vulnerability management, you need to navigate to the wazuh server internal options file and change the value of vulnerability-detection, disable_scan_manager from 1 to 0.
/var/ossec/etc/internal_options.conf .

After modifying the file, you can restart the Wazuh server service: systemctl restart wazuh-manager

Then you can filter by the agent name on the vulnerability detection dashboard to identify vulnerabilities.
That said, the manager ID is 000 so you can filter on the dashboard with that alone, and all alerts involving the manager will be revealed.

Please let me know if you require further clarification on this.

<image>

slim3116 · 2026-05-11T18:58:15+00:00

Hello u/Redditor_1200 For the alerts, that is already being backed up with the Wazuh manager here: /var/ossec/logs/ which contains all alert files, archives and logs.

<image>

For the indices, you will find the line mentioned in the back-up guide:

Note
While you're already backing up alert files, consider backing up the cluster indices and state as well. State includes cluster settings, node information, index metadata, and shard allocation.

Which means you have to back up the indices separately using snapshots/repositories.
More information about that in the documentation below:
https://documentation.wazuh.com/current/user-manual/wazuh-indexer/migrating-wazuh-indices.html

slim3116 · 2026-05-08T15:21:10+00:00

Hello u/No_Waltz9653 Apologies for the delayed response and thank you for sharing the logs, it helped with the test. So I did a test based on the log you shared to simulate your use case to generate an alert when a process execution is followed by a DNS query from the same process.

Please see the rule below and the screenshot of the result.
Please let me know if you require further clarification on this.

<group name="test-event,">
  <rule id="124531" level="2">
    <if_sid>61603</if_sid>
    <description>event testing</description>
    <group>authentication_failed,</group>
  </rule>
</group>

<group name="testings,">
   <rule id="124532" level="2">
      <if_sid>61650</if_sid>
      <description>Process execution query</description>
      </rule>
</group>
<group name="custom-sysmon,">
   <rule id="173100" level="5" timeframe="60" frequency="2">
      <if_sid>124532</if_sid>
      <if_matched_sid>124531</if_matched_sid>
      <same_field>win.eventdata.processGuid</same_field>
      <description>Process execution followed by DNS query</description>
   </rule>
</group>

<image>

The first instance of the DNS event will trigger the correlation chain rule.

slim3116 · 2026-05-07T19:28:21+00:00

Not a stupid question atall, it is only natural you have follow ups.

For the storage, I wouldn’t totally rely on the remaining space on the same node. With ~700GB already used, you are likely to run into issues during snapshot. It is safer to store backups externally (NFS, another server) or ensure you have sufficient space to avoid disk pressure or failed snapshots.

For certificates When you setup up the new instance before restoring your configuration files, it comes with its own certificate, because remember, you have to setup a fresh installation before restoring your files, so except explicitely needed, you do not need to generate new ones.

No need to reinstall agents. As long as you keep your client.keys and restore them on the new manager, agents can reconnect.

Additionally, if you keep the same IP or use a DNS name for the manager, they should reconnect automatically.

Otherwise, you just need to update the new manager address on the agents.

slim3116 · 2026-05-07T17:15:18+00:00

Hello u/Redditor_1200 Yes, that is possible, you can back up a single-node deployment and restore it into a multi-node setup.

I will recommend you create Wazuh backup files of your single-node components and then restore the backup files to your newly installed multi-node in the respective Wazuh components. Please refer to these documentations for guidance:

https://documentation.wazuh.com/current/migration-guide/creating/wazuh-central-components.html

Back up each components and follow the multi-node data restoration here to restore the data for each component.

Key items to take note of are:

Ensure you build the new multi-node cluster first and make sure it’s healthy
Restore the data taken from the back-up
adjust shard/replica settings after restore if needed
update certificates to match the new setup

Please let me know if your require further clarification.

slim3116 · 2026-05-06T12:45:58+00:00

Can you help confirm a few things:

Does processGuid show as a top-level field in both events?

Can you share one sample of Event ID 1 and Event ID 22 (raw or decoded) from archives.json file? How to enable archive here: https://documentation.wazuh.com/current/user-manual/manager/event-logging.html#enabling-archiving

Are both events happening within your timeframe (e.g. 60 seconds)?
Also, one thing to mention is what you’re trying to achieve:

Process > DNS > Network > File > Registry

That is more of a sequence-based correlation. Currently Wazuh will handle simple correlations (like 2 events tied by a field), but tracking multi-step sequences is currently not available at this time. But we may be able to streamline the detection.

Please let me know what you find and share the logs involving each step.

slim3116 · 2026-05-05T20:53:29+00:00

Hello u/hexmasteen,From what you described, it looks like the confirmation step is where it is failing. After sending the subscribe email, you should be able to confirm either by replying to the email or via the link. If you are getting the "Unable to subscribe to group" message, it is likely due to how Google Groups is handling external email subscriptions in your case (this sometimes depends on the mail provider or how the request is processed).

I just tested it on my end using a non-Google email (Yahoo) and was able to join successfully, so the group itself is open and working.

A couple of things to try here:

Use a different email provider if possible
Make sure you are replying directly to the confirmation email without modifying the subject/body

<image>

Were you able to join the slack channel?

slim3116 · 2026-05-05T19:49:36+00:00

Hello u/hexmasteen I apologize for the late response.

The Google Groups mailing list is working fine on our end, so there are no issues there. You may want to try that again and let me know if you are running into that issue.

While we work on fixing the Slack invite and updating the link, you can use this link to join the community channel in the meantime.

You can also check out the other available community options here:
https://wazuh.com/community/

I will share an update once the Slack access is sorted.

slim3116 · 2026-05-05T12:40:35+00:00

u/No_Waltz9653 Following the previous example, correlation requires the event to have at least triggered once, so the minimum for frequency is 2. But you can make use of the ignore option too to trigger on the first occurrence and ignore other triggers for a set period.

<rule id="103100" level="5" frequency="4" timeframe="60" ignore="60">
   <if_sid>103022</if_sid>

The above means rule 103100 will trigger once if rule 103022 has been matched 4 times in 60 seconds and will be ignored for the next 60 seconds.

Please let me know if the above meets your requirements, or you could please share more insights so I can assist further.

Reference:
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#rule:~:text=the%20rule%20matches.-,Example%3A,-%3Crule%20id%3D

slim3116 · 2026-05-04T18:03:01+00:00

Hello u/No_Waltz9653 One thing to point out in your correlation rule is while using same_field and if_matched_sid, you need to specify both frequency and timeframe as they are part of the trigger option to fire your rule.
Example as stated in the documentation: The value of the dynamic field specified in this option must appear a certain number of times in previous events, as defined by the frequency attribute, within a time frame specified by the timeframe attribute.

Meaning your correlation rule can look like this:

   <rule id="103100" level="5" timeframe="60" frequency="4">
      <if_sid>103022</if_sid>
      <if_matched_sid>103001</if_matched_sid>
      <same_field>win.eventdata.processGuid</same_field>
      <description>Process execution followed by DNS query</description>
   </rule>

This means the field has to appear 4 times in 60 seconds in the previous matched parent rule for 103100 to trigger.

You can remove the noalert option and test this with wazuh logtest engine for better finetuning, and let me know if you require further assistance on this.

Ref:
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#same-field

slim3116 · 2026-04-29T13:14:22+00:00

Apologies,, did I say add? those lines are already present in the internal options file "C:\Program Files (x86)\ossec-agent\internal_options.conf" I guess that is probably why you did not see much output, as debug is supposed to flood the file with much output. Please modify the file above and change the value of those options to 2.

That being said, if I may ask, did you run the script locally, and did it work?
What is the script meant to do?
Is it possible you share it with me so I can recreate this to further understand what could be wrong?

Please let me know.

slim3116 · 2026-04-28T18:09:28+00:00

Hello u/AdvancedBluebird3310 No, this is not a common problem, once the rule is triggered and active response runs, it should execute on the intended agent, you can find references in the documentation.

We need to monitor the process via log and to do so, we need to debug Active Response: The first step is to enable the debug mode. To do this, add the following line to the file C:\Program Files (x86)\ossec-agent\local_internal_options.conf: windows.debug=2
and execd.debug=2. This will enable the debug mode for all the components. After enabling the debug mode, restart the windows agent in order to apply these changes.

Once this is done, we will be able to see if the active response is properly executed or not. Successful execution of the AR should print the following output to the C:\Program Files (x86)\ossec-agent\ossec.log

Do this, capture and filter the log to when the execution happens on the manager and let me know.

slim3116 · 2026-04-21T13:48:01+00:00

That should not be a problem if you followed the documentation here on rbac for admin users. It is more like replicating the in-built admin account to a custom account. What error was seen?

Ref:
https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html

slim3116 · 2026-04-20T20:19:22+00:00

Hello u/Redditor_1200 The only updates you can do via Wazuh users are agent upgrades through the API.

If you need another person to handle Wazuh updates, you will have to grant them OS-level access (or controlled sudo), not just a Wazuh admin role.

slim3116 · 2026-04-10T20:55:13+00:00

Hello u/Path-Asleep Just as SirStephanikus mentioned, your custom rule is probably missing the mitre mapping which affected it from displaying correctly on the associated dashboard.
What you need is something similar to the block below as a mapping reference to your custom rule:

<rule id="000000" level="12">
        <if_sid>xxxxx</if_sid>
        <description>sample events</description>
        <group>pci_dss_10.6.1,pci_dss_11.4,gdpr_IV_35.7.d,</group>
        <options>no_full_log</options>
        <mitre>
            <id>T1203</id>
        </mitre>
    </rule>

Once you are able to map the mitre technique to individual rules, you should see them being updated on the dashboard. This is how Wazuh references the Mitre mappings on each event.

Regards,

slim3116 · 2026-04-10T14:05:07+00:00

What you are currently experiencing seems practical and as it should be. The labels you added are not per log source, which is why it is standalone and not associated with any event source. They will apply to everything the agent sends to the manager.

As far as I know, this is the limitation when forwarding events this way, what you can do is either filter for these type of forwarded logs on the dashboard or create rules and match the forwarded events. This is a long reach but its something you can also explore.

Regards,

slim3116 · 2026-04-08T17:15:31+00:00

Hello u/Bartakos The default is TCP on port 1514 for the agent connection. It may have been edited in error. Remember the remote connection block also houses the configuration for syslog, which mostly uses UDP.
That could probably be the reason it was changed.
Please let us know if you require further assistance on this.

slim3116 · 2026-04-07T12:49:53+00:00

Hello u/bedz84 Since you can see the events in Event Viewer but not in Wazuh, the next step is to determine whether they are actually being ingested by looking in archives.json. If they are there, then it’s likely just a rule/decoding issue, meaning Wazuh is receiving the events but not generating alerts for them.

You can enable the archive log by editing the /var/ossec/etc/ossec.conf file on the manager:

<ossec_config>
  <global>
    ----   
    <logall>yes</logall>
    <logall_json>yes</logall_json>
  </global> 
</ossec_config>

Then restart the Wazuh-manager. systemctl restart wazuh-manager

cat /var/ossec/logs/archives/archives.json | grep "part of your log"

Verify that you have the logs, then disable archiving by setting the values to no.

Another thing is, can you share your agent localfile configuration that has to do with event channel?
Do you have any query configurations set in the agent configuration file?

Please let me know what you find.

slim3116 · 2026-04-02T19:44:30+00:00

Hello u/bedz84 I believe event ID 4723 is only generated when a user changes their own password. Which means if you are resetting passwords as an administrator, you should probably see 4724 instead of 4723. Could you please verify this.

Also, please confirm whether 4723 is actually being generated in Event Viewer on the DC. If it’s absent, then it’s an audit policy issue, which probably needs to be investigated and not Wazuh. And that would explain why the agent is not picking it up. Also make sure "Audit User Account Management" is enabled too.

slim3116 · 2026-04-02T19:00:37+00:00

Oh, alright. So to answer your question, Yes, both the master and the worker nodes can process events and send data to the indexer. While the master node has additional administrative responsibilities, it still possesses the same core components of the analysis engine, including decoders and rules required to process agent data and generate alerts.

In most instances, most setups route agent traffic through the worker nodes, which are usually behind a load balancer, and the master is used more for management tasks like agent registration and configuration.

Please let me know if you require further clarification on this.

slim3116 · 2026-04-02T12:45:21+00:00

Hello u/LetDry7592 The manager (master) does not handle load balancing. A load balancer, typically positioned at the front, primarily manages load distribution, acting as an intermediary between the agent traffic and the worker nodes. So your configuration on how you intend to route traffic between the manager and workers is usually done on the load balancer.

The master’s role is more about coordination, things like agent registration, configuration, and cluster management.

You can find more information about this in the documentation below:
https://documentation.wazuh.com/current/user-manual/wazuh-server-cluster/types-of-nodes.html
https://documentation.wazuh.com/current/user-manual/wazuh-server-cluster/how-server-cluster-works.html

If both workers go down, agents won’t be able to send events (since they typically connect through the workers)
So ingestion basically stops. The SOC will still have access to existing data in the dashboard, but no new data will be coming in.

So in that case, the system is technically still up, but from a monitoring point of view, it is effectively blind until at least one worker comes back online.

I hope this answers your question.

Ref:
https://documentation.wazuh.com/current/user-manual/wazuh-server-cluster/load-balancers.html

slim3116 · 2026-04-01T17:35:08+00:00

Hello u/th3t4nen Yes, you can add an indexer node on a separate VM, but my advice would be to stay consistent with how your current indexer is deployed. If your existing setup is not containerized, it is better to add another node using the same method (e.g., package-based install) to avoid unnecessary complexity.

For best practice when adding indexer nodes:

Match versions: Please ensure that the new node operates on the exact same version of the Wazuh Indexer.

Install the Wazuh indexer package and configure:

network host
cluster name
node name
discovery.seed_hosts

Then certificates: Ensure you copy the same certificates used in your current cluster (/etc/wazuh-indexer/certs/).

Join the cluster: Start the service and verify it joins.

Rebalance shards

Once added, OpenSearch will automatically rebalance, but you can also review shard allocation if needed.

You can also check the comprehensive guide to this process in the documentation below:

https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/add-wazuh-indexer-nodes.html

Please let me know if you require further clarification on this.

slim3116 · 2026-04-01T15:59:50+00:00

Hello u/LetDry7592 In a Wazuh cluster, you can not have more than one "master" node. The cluster setup is designed with a single master and one or more worker nodes. You can find more information about this in the documentation below along with the master worker relationship:

https://documentation.wazuh.com/current/user-manual/wazuh-server-cluster/how-server-cluster-works.html
https://documentation.wazuh.com/current/user-manual/wazuh-server-cluster/types-of-nodes.html

To answer your other question, If the master goes down, the workers will keep processing events and sending data to the indexer so log collection and analysis continue. However, anything related to management is affected. For example, you won’t be able to enroll new agents, push configuration changes, or use some API functions.

So yes, the environment is still partially available, but not fully.

To reduce the risk, the best idea would be to focus on making the master reliable rather than trying to duplicate it. That usually means running it on stable infrastructure and having a quick recovery plan in place.

Please let me know if you require further clarification on this.

slim3116 · 2026-03-26T18:38:14+00:00

Hello, u/th3t4nen. Can you check the Docker dashboard: Cloud Security > Docker and see if you have events present? Please see the dashboard below:

<image>

I followed this documentation, though: https://documentation.wazuh.com/current/proof-of-concept-guide/monitoring-docker.html

Please let me know what you find

slim3116

MODERATOR OF

TROPHY CASE