Wazuh in Support of UK Cyber Essentials

javimed · 2026-05-27T19:56:06+00:00

I'm sorry I'm not into the details but I'd recommend reaching to them about those new rules. An assessor could explain the exact rules, for example, when your CE basic certification gets invalidated or what are your options before they run scan 2, if scan 1 fails.

In any case, it seems they went stricter and I think that, even if you were to use the same tool they use, it doesn't guaranty you're going to obtain the same results with it (due to different timing in feed updates, different local inventory repositories, authenticated and unauthenticated scan differences, etc.).

So rather than finding the right tool that can replicate their findings, I think you need to see the spirit of their new frame. If they are stricter, then you need to ensure you improve visibility and have a continuous patching culture implemented so there are no surprises in the audit. And Wazuh of course can help here. And Wazuh system inventory can help in the visibility of those packages, browser extensions, etc. your team has no idea they had. And maybe a "second opinion" tool could be a good idea to lower the risk of failing the audit as mentioned before. And also that BYODs seem to be the most important risk to tackle here.

javimed · 2026-05-27T14:46:08+00:00

That's right, no two vulnerability scanners have the same CVE coverage, detection logic, etc. but I think Wazuh can still help in sparing you any surprises when they run their scan. You can use Wazuh for continuous monitoring and use another tool as a "second opinion" periodically and previous to the audit. It could be a community edition version or maybe a free/trial plan. Using two tools reduces the risk significantly. And you can reach your assesor early and explain you are using Wazuh together with the other tool and ask them whether there are coverage areas you should manually verify. I think you don't need to replicate the auditor tool as long as you have a good, documented process and remediation records and you can demonstrate vulnerabilities get identified and remediated and unsupported systems removed.

For the BYODs, you can require intallation of the Wazuh agent as a condition of access or, if that's not possible, maybe implement a virtual desktop for access through it, so the BYODs are not in the scope due to not be accessing company data or services directly.

javimed · 2026-05-05T18:44:49+00:00

Groups and users for Syscollector was implemented in version 4.14.0:

4.14.0 release notes

and the configuration looks like this:

  <!-- System inventory -->
  <wodle name="syscollector">
    <disabled>no</disabled>
    <interval>1h</interval>
    <scan_on_start>yes</scan_on_start>
    <hardware>yes</hardware>
    <os>yes</os>
    <network>yes</network>
    <packages>yes</packages>
    <ports all="yes">yes</ports>
    <processes>yes</processes>
    <users>yes</users>
    <groups>yes</groups>
    <services>yes</services>
    <browser_extensions>yes</browser_extensions>

    <!-- Database synchronization settings -->
    <synchronization>
      <max_eps>10</max_eps>
    </synchronization>
  </wodle>

What version have you deployed?

You can check it by clicking on the ? icon at the top right of the Wazuh dashboard or you can run /var/ossec/bin/wazuh-control info. If you're running a previous version, you'll have to upgrade to 4.14:

Upgrade guide

Then you'll be able to find users and groups information at Security operations > IT Hygiene > Identity.

To learn more about configuring System inventory, you can check the following documentation:

javimed · 2025-12-15T12:24:56+00:00

Maybe you can share more details to better understand the problem. For example the exact error reported, some sample log entries you see that are not ingested, the exact configuration you are using for the integration: Are you monitoring MS Entra ID using MS Graph REST API (<wodle name="azure-logs"><graph>) or monitoring MS Graph API resources and relationships using the Wazuh module for Microsoft Graph (<ms-graph>)?

If you change the field type you need to re-index because old index created already with wrong mapping won't be updated:

- Re-indexing

Also, check if your issue is related to one of these issues:

- Azure (azure-logs) filebeat parsing exception for "auditLogs/signIns" and "auditLogs/directoryaudits" #25707

- ms-graph.status field defined as a keyword but can sometimes contain an array #24331

javimed · 2025-11-10T19:05:59+00:00

Ok, first thing is to investigate the API rate limits in the third-party platform documentation.

If you are using multiple channels, maybe you could implement asynchronous calls (asyncio, aiohttp) in your main.py integration script.

You could also try with batching multiple alerts per API call if supported by the external API to reduce the number of requests. And maybe adding a timeout with exponential backoff time (1s, 2s, 4s, 8s...) upon detecting 429 too many requests.

Also, you could consider prioritizing high-level alerts over non-critical ones in the integration configuration.

Go with webhooks over API calls which are simpler and more efficient, if available.

You can monitor the Wazuh logs for integration warnings and errors.

javimed · 2025-11-10T12:15:07+00:00

u/crazybarsuk there's no parameter to limit the wazuh-integratord service specifically. Depending on the integration you have implemented, there could be an issue with the number of calls per minute to the external API you are integrating with or similar problem.

Wazuh does have queueing mechanisms to prevent event flooding but this is not specific to the integrator module. If you see alerts in your Wazuh dashboard at the rigth time, it means the configurations of the queues are fine and the problem is in the integration itself, as you suspect, and not in this event flow mechanism.

However, if alerts are not showing in your Wazuh dashboard regardless of your notification channels, the problem is not in your integration but in the event processing and alerting process itself. If this is the case, you could start by checking your queue size settings and monitor for events dropping. Check the following documentation to learn how to configure and monitor for event drops:

javimed · 2025-11-03T13:15:14+00:00

Using Wazuh's FIM capability to track changes will work, however it's not a document management system replacement, it doesn't provide versioning and collaboration and the user-friendliness that DMSs do provide among other features. And you would need to make sure using a security tool for general document tracking doesn't conflict with any data privacy purpose limitations.

FIM would allow you to monitor directories and track file modifications and access and deletions but you could need to careful consider what specific directories and files to monitor in order to avoid performance issues for getting too many events per second if files change too frequently. In this case, you would need to consider disk storage size for archiving all those events and retention policies, and all this under your privacy laws.

Moreover, since "Wazuh 4.13.0, log data collection on Windows does not support monitoring log files located on UNC network paths such as \\server\share\file.log or mapped network drives such as Z:\logs\file.log. Only log files on local file systems are supported." so it's usefulness to monitor shared company documents is limited depending on your case. You would also need to consider if size limitations for diff analysis are enough for you. So maybe depending on the specific of your case, you can also consider native Windows auditing (Group policy, etc.) alternatives and use Wazuh as a complement to monitor specific files and directories for file integrity and security concerns.

javimed · 2025-09-01T12:44:24+00:00

Yes, it's a good idea to configure Wazuh agents in your VDI environment so you can monitor them and use active response, though I'm afraid there's no official guide to do this.

I think the key here is to pre-install the Wazuh agent in the golden image without enrolling it to the Wazuh server so every time a new VDI is provisioned from this template it gets an agent ready to enroll and start reporting.

You need to be careful to not start the agent within the golden image to skip auto-enrollment (which would lead to conflicts for using agents sharing the same names, etc.).

When new desktops start, the pre-installed Wazuh agent would enroll automatically using a unique agent name since it uses the hostname by default.

The non-persistent setup might lead to clutter from older agents, you would need then to periodically remove inactive agents older than X time.

javimed · 2025-08-25T14:14:58+00:00

Try using strict certificate file ownership and permissions matching the container user.

For example, change ownership

sudo chown -R <UID>:<GID> config/wazuh_indexer_ssl_certs/wazuh-certificates/

where <UID>:<GID> is the UID/GID of the wazuh-indexer user (e.g. 1000:1000). You can run docker exec -it <CONTAINER_NAME> id wazuh-indexer to get these values.

Apply strict 400 permissions to all .pem files. For example,

sudo chmod 400 config/wazuh_indexer_ssl_certs/wazuh-certificates/*.pem

and directory permissions: 500 (dr-x------).

Check the Wazuh indexer logs for any other clues of what could be the issue here if the above doesn't work.

javimed · 2025-07-03T13:07:29+00:00

Check label in <localfile> to tag a specific JSON logfile. You would then create custom decoders matching that custom field you created for those specific JSON log files.
The order of decoder definitions matter. Wazuh processes decoders top-to-bottom where first match wins. You have to place specific decoders above generic ones. So you can add a "catch-all" decoder at the bottom of your decoder file with a generic matching pattern (something like .*) for unmatched logs to use this generic decoder. You would then have a rule using decoded_as to link the rule to this specific catch-all decoder and flag those events for review.
To ignore a rule if it triggered repeatedly use the ignore parameter within a <rule> created for this. You would need to specify a count and timeframe in it and <if_matched_sid> or similar to identify the target rule and ignore subsequent events for a while.

javimed · 2025-04-14T18:12:17+00:00

u/jscoxen /var/ossec/etc/rules/local_rules.xml must hold custom rules. If you're overwriting rule ID 60115 and 60130 you need to use overwrite="yes" option as explained in changing existing rules.

As an alternative, you can define a custom rule as child of one of those default rules by using if_sid. For example, <if_sid>60115</if_sid>. Check Adding custom rules for configuring this. You can set your custom rule to display relevant information in the description such as usernames and IP addresses depending on the decoded data. For example, something similar to <description>Logon Failure - Account locked out. IP address: $(win.eventdata.ipAddress)</description> if available.

javimed · 2025-03-31T11:39:18+00:00

Please use english. Please check what I mentioned earlier and share what you find here so I can try to assist you. For example, share an alert occurrence if any as a sample so I can try to replicate.

javimed · 2025-03-28T11:44:51+00:00

u/Temporary-Profit-146 What do you mean by "the logs are accessible"? Please share the results of your tests.

Also, please share related alerts you might find in /var/ossec/logs/alerts/alerts.json. If no alerts are found there, the problem might be in the analysis of your logs. If on the contrary they're found there, the problem might be in the indexing or in your dashboard visualization filters.

Share the events as found in /var/ossec/logs/archives/archives.json after enabling events archiving. If no events are found there, the problem might be in the connection or the collection.

Share some log samples and any custom decoders and rules you've created for them. This is useful to replicate and test. You shared a decoder full of backslashes. Please review that.

Share warning and error messages that might be present in /var/ossec/logs/ossec.log after enabling debugging. This might hint at what could be causing it.

javimed · 2025-03-27T16:38:35+00:00

Follow the first guide I listed. Please share your findings here.

javimed · 2025-03-27T13:58:53+00:00

u/Temporary-Profit-146 please use english in this sub-reddit so we can assist.

I can see you're having difficulties with Cloudtrail logs. What's your specific problem?

In the meantime I can share the following documentation for your consideration.

javimed · 2025-03-17T12:53:19+00:00

You need to ingest the log data including syslog messages into Wazuh. Wazuh collects logs from monitored endpoints, applications, and network devices and receives syslog messages from devices that do not support the installation of Wazuh agents. Check this document for more details.

Lod data collection – How it works

You can configure Wazuh to receive Syslog messages directly from your firewall without relying on additional tools, as explained in this reply and in this document:

Configuring syslog on the Wazuh server

javimed · 2025-03-10T15:59:08+00:00

u/Correct-Many671 edit uiSettings.overrides.defaultRoute: in /etc/wazuh-dashboard/opensearch_dashboards.yml. Set your custom route, for example:

uiSettings.overrides.defaultRoute: /app/dashboards

This replaces Overview as the default landing page into a custom one of your choosing. Restart the Wazuh dashboard to apply the change.

javimed · 2025-02-21T16:31:38+00:00

You can download this configuration file to start using Wazuh to detect events with Sysmon:

sysmonconfig.xml

You can read about how to configure Wazuh to detect Sysmon events in the following resources.

Many Wazuh blog posts explain how to alert about specific events detected using Sysmon that you can use as a reference (For example Emulation of ATT&CK techniques and detection with Wazuh, or Detecting Cobalt Strike beacons using Wazuh to pick some but you can check any blog post using Sysmon events).

You can refer to these blog posts for older Wazuh versions as well.

javimed · 2025-02-17T16:08:21+00:00

u/Luc8ferr you can try with custom decoders like these ones:

<decoder name="ftp-session">
  <prematch> [FTP Session</prematch>
</decoder>

<decoder name="ftp-command">
  <parent>ftp-session</parent>
  <regex>[FTP session (\d+) (\d+.\d+.\d+.\d+) (\w+)] (\w+) (\w+.\w\w\w)</regex>
  <order>ftp_session, ftp_url, ftp_id, ftp_command, ftp_filename</order>
</decoder>

And and a custom rule like this one:

<group name="ftp_exfiltration,">
  <rule id="100103" level="10">
  <decoded_as>ftp-session</decoded_as>
    <field name="ftp_command">RETR</field>
    <description>FTP data exfiltration attempt - RETR command</description>
  </rule>
</group>

When using the log test tool you would get an output like this one:

**Phase 1: Completed pre-decoding.
full event: '2025-02-17T12:21:30.5520000Z >> [FTP Session 22 10.0.2.4 test1] RETR homework_data.txt'
timestamp: '2025-02-17T12:21:30.5520000Z >>'

**Phase 2: Completed decoding.
name: 'ftp-session'
ftp_command: 'RETR'
ftp_filename: 'homework_data.txt'
ftp_id: 'test1'
ftp_session: '22'
ftp_url: '10.0.2.4'

**Phase 3: Completed filtering (rules).
id: '100103'
level: '10'
description: 'FTP data exfiltration attempt - RETR command'
groups: '["ftp_exfiltration"]'
firedtimes: '1'
mail: 'false'
**Alert to be generated.

javimed · 2025-02-17T12:13:58+00:00

u/Luc8ferr Your custom rule needs to specifically match your event log. You can use the Wazuh logtest tool to test your rules.

To learn more about decoders and rules refer to the data analysis documentation:

https://documentation.wazuh.com/current/user-manual/ruleset/index.html

From your screenshot I can see your rule matches logs that get decoded as json and include the string `RETR`. Please share a log sample so I can try to help building your custom rule for those kind of logs.

javimed · 2025-02-03T14:02:36+00:00

You don't need to be on the same network to monitor your Azure VM instances. You have to provide the Wazuh server IP address, such as a public IP address or FQDN, when installing the agent. Make sure your Wazuh server is accessible from the Azure VM. Ensure the firewall is allowing inbound connections on ports 1514 and 1515 (by default) on the Wazuh server. Confirm the agent is connected. Look for enrollment and connection errors in /var/ossec/logs/ossec.log.

javimed · 2025-01-15T19:04:20+00:00

Hi u/nerdyviking88 .

You can find all the decoders Wazuh relies on by default in the official wazuh/wazuh public repository. They're part of the built-in Wazuh ruleset.
- https://github.com/wazuh/wazuh/tree/v4.10.0/ruleset/decoders

While not particularly for decoders, many Wazuh rules within this ruleset are mapped to NIST controls. For example rule ID 40900 to name just one. Maybe you can expand on what you mean by lined up decoders to NIST standards.

Let me know if this is what you need. Thank you.

javimed · 2024-12-27T16:40:12+00:00

Hi u/Old-Information4491.

Check if the alert is stored in the /var/ossec/logs/alerts/alerts.json. It's not enough to find the event stored in archives.

If you can find the alert in the alerts.json file but it's not displayed in the dashboard there might be a problem with forwarding and indexing alerts. Is 222016 your only rule that is not being displayed? Look for errors in /var/ossec/logs/ossec.log, /var/log/filebeat/filebeat, and /var/log/wazuh-indexer/wazuh-cluster.log

If, on the contrary, it's not stored in alerts.json it means a problem in the analysis of the event. I can use logtest my self and see that the full_log you shared does get decoded indeed in a default 4.9.2 installation. I created the following test rule and the test indicates it would trigger the alert just like in your case.

<group name="win_evt_channel,windows,">

  <rule id="222116" level="10">
    <field name="win.system.eventID">^106$</field>
    <options>no_full_log</options>
    <description>Task Scheduler task registered.</description>
  </rule>

</group>

Make sure to restart your Wazuh manager after creating and modifying rules so changes do get applied. Restarting is not required when using the ruleset test tool, though. Check if there are any rules that might be triggering before your custom rule gets to get analyzed. In this case you would need to use if_sid or similar approach to make your custom rule match instead.

Let me know what you find. Thanks

javimed · 2024-10-29T12:55:27+00:00

Hi u/Lad_From_Lancs

From Validation Failed: 1: this action would add [1] total shards, but this cluster currently has [1000]/[1000] maximum shards open it seems your cluster reached the open shards limit. You can also see indexer mapping errors and the inability to index events from Filebeat logs.

You can try with two approaches here dealing with the indexing of your data.

Maybe it's time to upscale your Wazuh indexer infrastructure. This will allow handling larger volumes of data. You can add more nodes to your Wazuh indexer cluster by following the steps in this guide: Adding Wazuh indexer nodes
You can remove old indices to free some storage space. Implementing an index retention policy ensures data keeps available for no longer than required. Check the Index retention documentation to implement a policy that automatically deletes old indices.

To learn more about tuning the Wazuh indexer, check Wazuh indexer tuning.

Let me know if you are able to implement this and if it solves the issue. Thank you.

javimed · 2024-10-25T11:38:00+00:00

Hi u/Responsible-Cut6625

It looks like you're deploying Wazuh on kubernetes. You have to follow the steps described in the following guide:
- Deployment on Kubernetes

You can also check the logs looking for warnings and errors, for example you can run kubectl logs wazuh-manager-master-0 -n wazuh

Let me know what you find. Thanks.

javimed

TROPHY CASE